19 ਦਸੰ 2025·8 ਮਿੰਟ
ਵਾਇਬ ਕੋਡਿੰਗ ਸਮਝਾਈ ਗਈ: ਵਰਕਫਲੋ ਅਤੇ 3 ਅਸਲ ਬਿਲਡ ਉਦਾਹਰਣਾਂ
ਜਾਣੋ ਕਿ vibe coding ਕੀ ਹੈ, ਵਰਕਫਲੋ ਸਧਾਰਨ ਕਦਮਾਂ ਵਿੱਚ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ 3 ਪ੍ਰਯੋਗਿਕ ਉਦਾਹਰਣ (ਵੈੱਬ ਐਪ, API, ਮੋਬਾਈਲ) ਵੇਖੋ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਨਕਲ ਕਰ ਸਕਦੇ ਹੋ।
ਜਾਣੋ ਕਿ vibe coding ਕੀ ਹੈ, ਵਰਕਫਲੋ ਸਧਾਰਨ ਕਦਮਾਂ ਵਿੱਚ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ 3 ਪ੍ਰਯੋਗਿਕ ਉਦਾਹਰਣ (ਵੈੱਬ ਐਪ, API, ਮੋਬਾਈਲ) ਵੇਖੋ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਨਕਲ ਕਰ ਸਕਦੇ ਹੋ।
Vibe coding ਹੈ AI ਨੂੰ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਦੱਸ ਕੇ ਸੌਫਟਵੇਅਰ ਬਣਾਉਣਾ, ਫਿਰ ਨਤੀਜੇ ਤੇ ਦੁਹਰਾਉਂਦੇ ਰਹਿਣਾ ਜਦ ਤਕ ਇਹ ਤੁਹਾਡੀ ਉਮੀਦਾਂ ਅਨੁਸਾਰ ਕੰਮ ਨਾ ਕਰਨ ਲੱਗੇ।
ਮਕਸਦ ਸਧਾਰਾ ਹੈ: ਖਾਲੀ ਕੋਡ ਫਾਈਲ ਤੋਂ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਬਜਾਏ ਨਿਯਤ ਇਰਾਦੇ ਨੂੰ ਵਰਣਨ ਕਰਕੇ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰ ਰਹੇ ਸਕ੍ਰੀਨ, API ਅਤੇ ਫੀਚਰ ਤਿਆਰ ਕਰਨਾ। ਤੁਸੀਂ ਦੱਸਦੇ ਹੋ ਕਿ ਐਪ ਕਿਵੇਂ ਕੰਮ ਕਰੇ, ਕਿਹੜੇ ਡੇਟਾ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ "ਮੁੱਕਮਲ" ਕੀ ਵੇਖਣਾ ਹੈ। AI ਇਸਨੂੰ ਕੋਡ ਅਤੇ ਪ੍ਰੋਜੈਕਟ ਢਾਂਚੇ ਵਿੱਚ ਬਦਲਦਾ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਫੀਡਬੈਕ ਨਾਲ ਦਿਸ਼ਾ ਦਿੰਦੇ ਹੋ, ਜਿਵੇਂ "ਲੌਗਿਨ ਸਧਾਰਨ ਬਣਾਓ" ਜਾਂ "ਆਰਡਰਜ਼ ਨੂੰ ਸਟેટਸ ਅਤੇ ਟਾਈਮਸਟੈਂਪ ਨਾਲ ਸਟੋਰ ਕਰੋ।"
ਇਸਨੂੰ ਇੱਕ ਤੇਜ਼ ਜੂਨੀਅਰ ਡਿਵੈਲਪਰ ਦਾ ਨਿਰਦੇਸ਼ ਦੇਣ ਵਾਂਗ ਸੋਚੋ। ਇਹ ਬਹੁਤ ਸਾਰਾ ਕੋਡ ਤੇਜ਼ੀ ਨਾਲ ਲਿਖ ਸਕਦਾ ਹੈ, ਪਰ ਇਸਨੂੰ ਸਾਫ਼ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ ਅਤੇ ਆਕਸਮੀ ਦਰੁਸਤੀਆਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ 'ਤੇ, ਚੈਟ ਮੁੱਖ ਇੰਟਰਫੇਸ ਹੁੰਦਾ ਹੈ: ਤੁਸੀਂ ਐਪ ਵਰਣਨ ਕਰਦੇ ਹੋ, ਇਹ React ਵੈੱਬ UI, Go ਬੈਕਐਂਡ, ਅਤੇ ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ PostgreSQL ਡੈਟਾਬੇਸ ਸੈਟਅਪ ਜਨਰੇਟ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਫਿਰ ਤਬਦੀਲੀਆਂ ਦੀ ਸਮੀਖਿਆ ਕਰ ਸਕਦੇ ਹੋ, ਗਲਤ ਹੋਏ ਤਾਂ ਰੋਲਬੈਕ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਜਦੋਂ ਪੂਰਾ ਨਿਯੰਤਰਣ ਚਾਹੀਦਾ ਹੋਵੇ ਤਾਂ ਸੋਰਸ ਕੋਡ ਐਕਸਪੋਰਟ ਕਰ ਸਕਦੇ ਹੋ।
ਕੁਝ ਗਾਈਡਰੈਲਜ਼ ਉਮੀਦਾਂ ਸੈੱਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ:
Vibe coding ਅਕਸਰ ਦੋ ਕਿਸਮ ਦੇ ਲੋਕਾਂ ਨੂੰ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਲਾਭ ਪਹੁੰਚਾਉਂਦਾ ਹੈ: ਗੈਰ-ਟੈਕਨੀਕਲ ਬਿਲਡਰ ਜਿਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਸਾਫ਼ ਵਿਚਾਰ ਹੈ ਪਰ ਉਹ ਪੂਰੀ ਡੈਵ ਸਟੈਕ ਨਹੀਂ ਸਿੱਖਣਾ ਚਾਹੁੰਦੇ, ਅਤੇ ਉਦਯੋਗਪਤੀਆਂ ਦੀਆਂ ਟੀਮਾਂ ਜੋ ਕੌਂਸੈਪਟ ਤੋਂ ਵਰਕਿੰਗ ਪ੍ਰੋਟੋਟਾਈਪ ਜਾਂ ਅੰਦਰੂਨੀ ਟੂਲ ਤੱਕ ਤੇਜ਼ ਰਸਤਾ ਚਾਹੁੰਦੀਆਂ ਹਨ। ਜੇ ਤੁਸੀਂ ਸਧਾਰਨ ਜੁਮਲਿਆਂ ਵਿੱਚ ਆਪਣੇ ਇਰਾਦੇ ਦੀ ਵਿਆਖਿਆ ਕਰ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹੋ।
Vibe coding ਇੱਕ ਲੂਪ ਹੈ। ਤੁਸੀਂ ਜੋ ਚਾਹੁੰਦੇ ਹੋ ਦਰਸਾਉਂਦੇ ਹੋ, ਸਿਸਟਮ ਪ੍ਰੋਜੈਕਟ ਅਤੇ ਕੋਡ ਤਿਆਰ ਕਰਦਾ ਹੈ, ਤੁਸੀਂ ਚਲਾ ਕੇ ਵੇਖਦੇ ਹੋ ਕਿ ਕੀ ਹੋਇਆ, ਫਿਰ ਇਸਨੂੰ ਤੁਹਾਡੇ ਵਿਚਾਰ ਅਨੁਸਾਰ ਬਦਲਣ ਲਈ ਬੇਨਤੀ ਕਰਦੇ ਹੋ। ਕੰਮ ਹਰ ਲਾਈਨ ਟਾਈપ ਕਰਨ ਤੋਂ ਬਦਲ ਕੇ ਸਪਸ਼ਟ ਫੈਸਲੇ ਕਰਨ ਅਤੇ ਅੱਛੇ ਫੀਡਬੈਕ ਦੇਣ ਉੱਤੇ ਆ ਜਾਂਦਾ ਹੈ।
ਸਭ ਤੋਂ ਛੋਟੀ ਲਾਭਦਾਇਕ ਸਲਾਇਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਪੂਰੇ ਸੁਪਨੇ ਨਾਲ ਨਹੀਂ। ਦੱਸੋ ਕਿ ਐਪ ਕਿਸ ਲਈ ਹੈ, کون ਇਸਨੂੰ ਵਰਤਦਾ ਹੈ, ਅਤੇ "ਮੁੱਕਮਲ" ਕੀ ਹੋਵੇਗਾ।
ਇੱਕ ਸਧਾਰਨ ਤਰੀਕਾ ਇਹ ਹੈ: “Y ਲਈ X ਬਣਾਓ, ਇਹ A ਅਤੇ B ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ C ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ।” ਇੱਥੇ ਮਨੁੱਖਾਂ ਦੀ ਅਗਵਾਈ ਜ਼ਰੂਰੀ ਹੈ। ਤੁਸੀਂ ਫੀਚਰ, ਨਿਯਮ, ਅਤੇ ਪਹਿਲਾਂ ਕੀ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਚੁਣਦੇ ਹੋ।
ਸਿਸਟਮ ਤੁਹਾਡੇ ਲਈ ਬੋਰਿੰਗ ਹਿੱਸੇ ਬਣਾਉਂਦਾ ਹੈ: ਪ੍ਰੋਜੈਕਟ ਸੈਟਅਪ, ਰਾਊਟਿੰਗ, ਡੈਟਾਬੇਸ ਵਾਇਰਿੰਗ, ਬੇਸਿਕ UI, ਅਤੇ ਲਾਜਿਕ ਦਾ ਪਹਿਲਾ ਵਰਜਨ। Koder.ai ਵਰਗਾ vibe-coding ਟੂਲ ਇਸਨੂੰ ਘੰਟਿਆਂ ਦੇ ਸੈਟਅਪ ਅਤੇ ਬਾਇਲਰਪਲੇਟ ਦੀ ਥਾਂ ਚੈਟ ਰਾਹੀਂ ਕਰ ਸਕਦਾ ਹੈ।
ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ ਢਾਂਚਾ ਮੰਗੋ: “ਤਿੰਨ ਸਕ੍ਰੀਨ ਬਣਾਓ,” “ਲੌਗਿਨ ਜੋੜੋ,” “ਆਈਟਮਾਂ ਨੂੰ PostgreSQL ਟੇਬਲ ਵਿੱਚ ਸਟੋਰ ਕਰੋ,” ਜਾਂ “ਇੱਕ ਐਂਡਪੌਇੰਟ ਐਕਸਪੋਜ਼ ਕਰੋ ਜੋ JSON ਰਿਟਰਨ ਕਰੇ।” ਪਹਿਲੀ ਕੋਸ਼ਿਸ਼ 'ਤੇ ਪਰਫੈਕਟ ਕੋਡ ਦੀ ਪਿੱਛਾ ਨਾ ਕਰੋ। ਇੱਕ ਚੱਲਣਯੋਗ ਡਰਾਫਟ ਲਈ ਮੰਨੋ ਜੋ ਤੁਸੀਂ ਟਚ ਕਰ ਸਕੋ।
ਕੇਵਲ ਚੈਟ ਆਉਟਪੁੱਟ ਨੂੰ ਨਾ ਪੜ੍ਹੋ। ਐਪ ਚਲਾ ਕੇ ਅਸਲ ਸਿਗਨਲ ਲੱਭੋ।
ਉਸ ਚੀਜ਼ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਯੂਜ਼ਰ ਪਹਿਲਾਂ ਦੇਖਦੇ ਹਨ (ਕਿ ਸਕ੍ਰੀਨ ਠੀਕ ਲੱਗਦੀਆਂ ਹਨ ਅਤੇ ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਚਲਦੀਆਂ ਹਨ?), ਫਿਰ ਘੱਟ ਦਿੱਖੇ ਹਿੱਸਿਆਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ (ਡੇਟਾ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਸੇਵ ਅਤੇ ਲੋਡ ਹੁੰਦੀ ਹੈ?). ਇਸ ਦੇ ਬਾਅਦ ਕੁਝ ਏਜ ਕੇਸ ਟੈਸਟ ਕਰੋ: ਖਾਲੀ ਇੰਪੁੱਟ, ਨਕਲਾਂ, ਅਤੇ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਗਲਤ ਮੁੱਲ।
ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਸਮਾਂ ਹੋਵੇ, ਤਾਂ ਉਹ ਨਿਯਮਾਂ ਲਈ ਕੁਝ ਸਧਾਰਨ ਟੈਸਟ ਜ਼ੋਰ ਨਾਲ ਸ਼ਾਮਿਲ ਕਰੋ ਤਾਂ ਜੋ ਉਹ ਬਾਅਦ ਵਿੱਚ ਚੁਪ ਚਾਪ ਟੁੱਟਣ ਨਾ ਪਾਏਂ।
ਹੁਣ ਇਕ ਪ੍ਰੋਡਕਟ ਓਨਰ ਅਤੇ ਸਮੀਖਿਆਕਾਰ ਦੀ ਤਰ੍ਹਾਂ ਪ੍ਰਤੀਕ੍ਰਿਆ ਦਿਓ। ਦੱਸੋ ਕਿ ਕੀ ਗਲਤ ਹੈ, ਕੀ ਬਦਲਣਾ ਹੈ, ਅਤੇ ਕੀ ਰੱਖਣਾ ਹੈ। ਵਿਸ਼ੇਸ਼ ਬਣੋ: “ਲੇਆਊਟ ਰੱਖੋ, ਪਰ ਬਟਨ ਨੂੰ ਹੈਡਰ ਵਿੱਚ ਲਿਜਾਓ,” ਜਾਂ “ਨੈਗੇਟਿਵ ਰਕਮਾਂ ਨੂੰ 400 ਐਰਰ ਨਾਲ ਰਿਜੈਕਟ ਕਰੋ।”
ਕੁਝ ਲੂਪਾਂ ਤੋਂ ਬਾਅਦ, ਤੁਹਾਡੇ ਕੋਲ ਕੁਝ ਹੋਵੇਗਾ ਜੋ ਤੁਹਾਡੇ ਇਰਾਦੇ ਨਾਲ ਮਿਲਦਾ ਹੈ, ਸਿਰਫ਼ ਜਨਰੇਟ ਕੀਤੇ ਕੋਡ ਦਾ ਢੇਰ ਨਹੀਂ। ਤੇਜ਼ੀ ਹੀ “ਵਾਇਬ” ਹੈ, ਪਰ ਗੁਣਵੱਤਾ ਤੁਹਾਡੇ ਫੈਸਲਿਆਂ ਅਤੇ ਸਮੀਖਿਆ ਤੋਂ ਆਉਂਦੀ ਹੈ।
Vibe coding ਸਭ ਤੋਂ ਵਧੀਆ ਤਾਂ ਹੈ ਜਦੋਂ ਲਕੜੀ ਕਾਫ਼ੀ ਸਪਸ਼ਟ ਹੋ ਜੋ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਵਰਣਨ ਕੀਤੀ ਜਾ ਸਕੇ, ਅਤੇ "ਲਗਭਗ ਠੀਕ" ਹੋਣ ਦੀ ਲਾਗਤ ਘੱਟ ਹੋਵੇ। ਤੁਹਾਨੂੰ ਤੇਜ਼ ਫੀਡਬੈਕ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਪਹਿਲੇ ਕੋਸ਼ਿਸ਼ ਵਿੱਚ ਪਰਫੈਕਟ ਸਿਸਟਮ। ਜੇ ਤੁਸੀਂ ਨਤੀਜੇ ਵੱਲ ਇशਾਰਾ ਕਰਕੇ ਕਹਿ ਸਕਦੇ ਹੋ “ਹਾਂ, ਇਹ ਠੀਕ ਹੈ” ਜਾਂ “ਇਸ ਹਿੱਸੇ ਨੂੰ ਬਦਲੋ,” ਤਾਂ ਤੁਸੀਂ ਸਹੀ ਜ਼ੋਨ ਵਿੱਚ ਹੋ।
ਇਹ ਉਹਨਾਂ ਪ੍ਰੋਜੈਕਟਾਂ ਲਈ ਚੰਗਾ ਮੈਚ ਹੈ ਜਿੱਥੇ ਰਫ਼ਤਾਰ ਲੰਮੇ ਯੋਜਨਾਂ ਤੋਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਉਦਾਹਰਨ ਵਜੋਂ, ਇੱਕ ਛੋਟੀ ਟੀਮ ਜੋ ਸੇਲਜ਼ ਕਾਲ ਦੀ ਸਮੀਖਿਆ ਲਈ ਇਕ ਅੰਦਰੂਨੀ ਡੈਸ਼ਬੋਰਡ ਚਾਹੁੰਦੀ ਹੈ—ਤੁਸੀਂ ਸਕ੍ਰੀਨਾਂ, ਫੀਲਡ, ਅਤੇ ਕੁਝ ਨਿਯਮ ਵਰਣਨ ਕਰਦੇ ਹੋ, ਫਿਰ ਦੁਹਰਾਉਂਦੇ ਹੋ ਜਦ ਤਕ ਇਹ ਟੀਮ ਦੇ ਕੰਮ ਨਾਲ ਮਿਲ ਨਾ ਜਾਵੇ।
ਇਹ ਅਕਸਰ ਪ੍ਰੋਟੋਟਾਈਪ, ਅੰਦਰੂਨੀ ਟੂਲ (ਡੈਸ਼ਬੋਰਡ, ਐਡਮਿਨ ਪੈਨਲ, ਸਧਾਰਨ ਆਟੋਮੇਸ਼ਨ), ਅਤੇ ਮਿਆਰੀ ਫਲੋ ਨਾਲ ਸੰਕੁਚਿਤ MVPs ਲਈ ਚਮਕਦਾ ਹੈ। ਇਹ “ਗਲੂ” ਐਪਾਂ ਲਈ ਵੀ ਚੰਗਾ ਹੈ ਜੋ ਕੁਝ ਸਰਵਿਸਜ਼ ਨੂੰ ਜੋੜਦੇ ਹਨ, ਕਿਉਂਕਿ ਤੁਸੀਂ ਇਨਪੁੱਟ ਅਤੇ ਆਉਟਪੁੱਟ ਪਰਿਭਾਸ਼ਤ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਉਹਨਾਂ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹੋ।
ਜਦੋਂ ਲੋੜਾਂ ਕਠੋਰ, ਗਹਿਰੇ, ਜਾਂ ਛੋਟੇ-ਛੋਟੇ ਅਪਵਾਦਾਂ ਨਾਲ ਭਰੀਆਂ ਹੋਵਨ ਤਾਂ ਇਹ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ: ਜਟਿਲ ਕੰਪਲਾਇਂਸ ਨਿਯਮ (ਜਿੱਥੇ ਸ਼ਬਦਬੰਦੀ ਸਰਪ੍ਰਾਕ ਤੌਰ 'ਤੇ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੀ ਹੈ), ਭਾਰੀ ਪ੍ਰਦਰਸ਼ਨ ਟਿਊਨਿੰਗ (ਜਿੱਥੇ ਛੋਟੀ ਚੋਣਾਂ ਦੇ ਵੱਡੇ ਖ਼ਰਚ ਹੁੰਦੇ ਹਨ), ਅਤੇ ਵੱਡੇ ਲੈਗੇਸੀ ਸਿਸਟਮ (ਜਿੱਥੇ ਛੁਪੇ ਹੋਏ ਨਿਰਭਰਤਾਵਾਂ ਹਰ ਜਗ੍ਹਾ ਹਨ)। ਇੱਥੇ ਵੀ ਤੁਸੀਂ vibe coding ਵਰਤ ਸਕਦੇ ਹੋ, ਪਰ ਕੰਮ ਸਾਵਧਾਨ ਵਿਸ਼ੇਸ਼ਣਾਂ, ਸਮੀਖਿਆਵਾਂ, ਅਤੇ ਟੈਸਟਿੰਗ ਵੱਲ ਵੱਧ ਗਿਆ।
ਇਕ ਪ੍ਰਯੋਗਿਕ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਇੱਕ ਬਰੀਕ ਸਲਾਇਸ ਪਹਿਲਾਂ ਬਣਾਓ ਅਤੇ ਕੇਵਲ ਉਸੇ ਨੂੰ ਵਧਾਓ ਜੇ ਨਤੀਜਾ ਪੂਛੇ ਤੱਕ ਭਰੋਸੇਯੋਗ ਰਹੇ। ਇੱਕ ਸਕ੍ਰੀਨ, ਇੱਕ API ਰੂਟ, ਇੱਕ ਡੇਟਾ ਟੇਬਲ ਲਈ ਇੱਕ ਪੂਰਾ ਏਂਡ-ਟੂ-ਏਂਡ ਸਲਾਇਸ ਬਣਾਓ। ਜੇ ਉਹ ਸਲਾਇਸ ਸਾਫ਼ ਤਰੀਕੇ ਨਾਲ ਆ ਜਾਂਦੀ ਹੈ ਤਾਂ ਅਗਲਾ ਜੋੜੋ।
ਜਦੋਂ ਤੁਸੀਂ ਹੇਠਾਂ ਲਿਖੇ ਨਿਸ਼ਾਨ੍ਹੇ ਵੇਖੋ ਤਾਂ ਰੁੱਖੋ ਅਤੇ ਯੋਜਨਾ ਕਸਦੀ ਕਰੋ:
ਜੇ ਇਹ ਲੱਭੋ, ਤਾਂ ਰੁਕੋ ਅਤੇ ਸਪਸ਼ਟ ਨਿਯਮ, ਉਦਾਹਰਨ ਇੰਪੁੱਟ/ਆਉਟਪੁੱਟ, ਅਤੇ ਕੁਝ “ਪਾਸ ਹੋਣ-ਚਾਹੀਦਾ” ਟੈਸਟ ਲਿਖੋ। Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ planning mode ਅਤੇ snapshots ਤੁਹਾਨੂੰ ਇੱਕ ਚਲਦੀ ਹੋਈ ਵਰਜਨ ਗੁਆਣ ਤੋਂ ਬਿਨਾਂ ਦੁਹਰਾਉ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ।
ਵਧੀਆ vibe coding ਤੁਹਾਡੇ ਪਹਿਲੇ ਸੁਨੇਹੇ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਪ੍ਰੋਂਪਟ ਧੁੰਦਲਾ ਹੈ ਤਾਂ ਬਿਲਡ ਵੀ ਧੁੰਦਲਾ ਹੋਵੇਗਾ। ਜੇ ਤੁਹਾਡਾ ਪ੍ਰੋਂਪਟ ਵਿਸ਼ੇਸ਼ ਹੈ ਤਾਂ AI ਮਜ਼ਬੂਤ ਫੈਸਲੇ ਲੈ ਸਕਦਾ ਹੈ ਅਤੇ ਤੁਸੀਂ ਸਮੇਂ ਦੀ ਬਜਾਏ ਸਮੀਖਿਆ ਕਰ ਰਹੇ ਹੋਵੋਗੇ ਨਾ ਕਿ ਦੁਬਾਰਾ ਲਿਖਣ ਵਿੱਚ।
ਚੈਟ ਵਿੱਚ ਪੇਸਟ ਕਰਨ ਲਈ ਇੱਕ ਛੋਟਾ ਪ੍ਰੋਜੈਕਟ ਬ੍ਰੀਫ ਬਣਾਓ। ਇਸਨੂੰ ਸੰਕੁਚਿਤ ਰੱਖੋ: ਮੰਤਵ (ਇੱਕ ਵਾਕ), ਕੌਣ ਵਰਤਦਾ ਹੈ, ਕੁਝ ਸਕ੍ਰੀਨ ਜਿਨ੍ਹਾਂ 'ਤੇ ਤੁਸੀਂ ਕਲਿਕ ਕਰਨ ਦੀ ਉਮੀਦ ਰੱਖਦੇ ਹੋ, ਮੁੱਖ ਡੇਟਾ ਜੋ ਤੁਸੀਂ ਸਟੋਰ ਕਰਦੇ ਹੋ (ਅਤੇ ਜਿਹੜੇ ਫੀਲਡ ਮਾਇਆਨੇ ਰੱਖਦੇ ਹਨ), ਅਤੇ ਕੋਈ ਵੀ ਕਠੋਰ ਪਾਬੰਦੀਆਂ (ਮੋਬਾਈਲ-ਮਿੱਤਰ, UTC ਵਿੱਚ ਤਾਰੀਖਾਂ, ਡਾਰਕ ਮੋਡ, ਆਦਿ)।
ਫੀਚਰਾਂ ਦੀ ਵਰਣਨਾ ਉਦਾਹਰਣਾਂ ਨਾਲ ਕਰੋ, ਨਾਂ ਕਿ ਨਾਅਰੇ ਨਾਲ। “Users can manage tasks” ਨੇ ਸਪਸ਼ਟਤਾ ਨਹੀਂ ਦਿੰਦਾ। “A user can create a task with title, due date, and priority; mark it done; and filter by status” AI ਨੂੰ ਇਕ ਟੈਸਟ ਕਰਨਯੋਗ ਚੀਜ਼ ਦਿੰਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਐਸਾ ਕੋਡ ਚਾਹੁੰਦੇ ਹੋ ਜੋ ਤੁਸੀਂ ਸੰਭਾਲ ਸਕੋ, ਤਾਂ ਪਹਿਲਾਂ ਇੱਕ ਸਧਾਰਨ ਢਾਂਚਾ ਮੰਗੋ: ਕਿਹੜੇ ਪੇਜ਼ ਮੌਜੂਦ ਹਨ, ਕਿਹੜੇ ਟੇਬਲ ਲੋੜੀਂਦੇ ਹਨ, ਅਤੇ ਕਿਸ API ਐਂਡਪੌਇੰਟ ਉਹਨਾਂ ਨੂੰ ਜੋੜਦੇ ਹਨ। ਇਸ ਲਈ ਤੁਸੀਂ ਟੈਕਨੀਕਲ ਹੋਏ ਬਿਨਾਂ ਵੀ ਇਹ ਮੰਗ ਸਕਦੇ ਹੋ—ਸਧਾਰਨ ਸ਼ਬਦ ਕਾਫ਼ੀ ਹਨ।
ਇੱਥੇ ਇੱਕ ਪ੍ਰੋਂਪਟ ਹੈ ਜੋ ਤੁਸੀਂ ਅਨੁਕੂਲ ਕਰ ਸਕਦੇ ਹੋ (Koder.ai ਵਰਗੇ ਟੂਲਾਂ ਵਿੱਚ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ):
Build a small web app called “Team Tasks”.
Users: Admin, Member.
Goal: track tasks for a small team.
Screens:
1) Login
2) Task list (filter: All, Open, Done)
3) Task details
4) Admin: Users list
Data:
Task(id, title, description, status, due_date, created_by, assigned_to)
User(id, name, email, role)
Rules:
- Members can only edit tasks they created.
- Admin can view and edit everything.
Please propose:
- Pages/components
- Database tables
- API endpoints (CRUD)
Then generate the first working version.
ਸਕੋਪ ਨੂੰ ਨਿਯੰਤਰਿਤ ਰੱਖਣ ਲਈ, ਆਪਣੇ “v1” ਨੂੰ ਛੋਟੀ ਫੀਚਰ ਲਿਸਟ ਤੱਕ ਸੀਮਿਤ ਰੱਖੋ। ਇੱਕ ਲਾਭਦਾਇਕ ਲਾਈਨ ਜੋ ਜੋੜਨੀ ਚੰਗੀ ਰਹਿੰਦੀ ਹੈ: “If anything is unclear, ask up to 5 questions before building.” ਇਸ ਨਾਲ ਅਟਕਲੀਆਂ ਘੱਟ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਅਣਚਾਹੀਆਂ ਫੀਚਰ ਆਉਣ ਦੀ ਸੰਭਾਵਨਾ ਕੱਟਦੀ ਹੈ।
ਇੱਕ ਸਧਾਰਨ ਰਿਦਮ ਜੋ ਜ਼ਿਆਦਾਤਰ ਬਿਲਡਾਂ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ:
ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਇਕ-ਪੈਰਾ ਬ੍ਰੀਫ: ਕਿਸ ਲਈ ਹੈ, ਮੁੱਖ ਕੰਮ ਕੀ ਹੈ, ਅਤੇ "ਮੁੱਕਮਲ" ਦਾ ਕੀ ਮਤਲਬ ਹੈ। 2-3 ਮਸਟ-ਹੈਵ ਅਤੇ 2-3 ਨਾਈਸ-ਟੂ-ਹੈਵ ਸ਼ਾਮਲ ਕਰੋ, ਫਿਰ ਰੁਕੋ। ਜ਼ਿਆਦਾ ਵਿਸਥਾਰ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਅਕਸਰ ਗੁੰਝਲਦਾਰ ਬਣਾਉਂਦਾ ਹੈ।
ਅਗਲੇ, ਸਭ ਤੋਂ ਛੋਟਾ ਚੱਲਣਯੋਗ ਵਰਜ਼ਨ ਮੰਗੋ: ਇੱਕ ਕੋਰ ਫਲੋ ਏਂਡ-ਟੂ-ਏਂਡ, ਭਾਵੇਂ ਇਹ ਸਾਦਾ ਲੱਗੇ। ਇੱਕ ਬੁਕਿੰਗ ਐਪ ਲਈ ਇਹ ਹੋ ਸਕਦਾ ਹੈ: ਸੇਵਾ ਸੂਚੀ ਪੇਜ, ਸਮਾਂ ਚੁਣਨ ਪੇਜ, ਅਤੇ ਪੁਸ਼ਟੀ ਸਕ੍ਰੀਨ ਜਿਸ ਵਿੱਚ ਬੁਕਿੰਗ ਸੇਵ ਹੋਈ ਹੋਵੇ।
ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਹੈਪੀ ਪਾਥ ਦੀ ਜਾਂਚ ਕਰੋ, ਫਿਰ ਧੀਰੇ-ਧੀਰੇ ਵੱਧੋ। ਮੁੱਖ ਫਲੋ ਨੂੰ ਕਲਿਕ ਕਰੋ ਅਤੇ ਕੇਵਲ ਉਸ ਚੀਜ਼ ਨੂੰ ਠੀਕ ਕਰੋ ਜੋ ਰੁਕਾਅ ਬਣਦੀ ਹੈ। ਉਸ ਤੋਂ ਬਾਅਦ ਇੱਕ ਏਜ ਕੇਸ ਇਕ ਵਾਰੀ ਜੋੜੋ: ਡਬਲ-ਬੁਕਿੰਗ ਰੋਕਥਾਮ, ਟਾਈਮਜ਼ੋਨ ਹੈਂਡਲਿੰਗ, ਗੁੰਮ ਹੋਏ ਫੀਲਡ, ਬੰਦ ਦਿਨ।
ਜਦੋਂ ਕੁਝ ਕੰਮ ਕਰਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਚੈੱਕਪੌਇੰਟ ਕੈਪਚਰ ਕਰੋ (ਸਨੇਪਸ਼ੌਟ, ਟੈਗ, ਜਾਂ ਜੋ ਭੀ ਤੁਹਾਡਾ ਟੂਲ ਸਪੋਰਟ ਕਰਦਾ ਹੈ) ਤਾਂ ਜੋ ਤੁਸੀਂ ਅਗਲੇ ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਵਾਪਸ ਜਾ ਸਕੋ। ਇਹੀ ਜੱਗਾ ਹੈ ਜਿੱਥੇ Koder.ai ਵਰਗੇ ਟੂਲ ਵਿਹਵਾਰਕ ਤੌਰ 'ਤੇ ਸਹਾਇਕ ਸਾਬਤ ਹੁੰਦੇ ਹਨ: ਸਨੇਪਸ਼ੌਟ ਅਤੇ ਰੋਲਬੈਕ ਤਜਰਬਾ ਨਿੁਕਸਾਨ-ਰਹਿਤ ਬਣਾਉਂਦੇ ਹਨ।
ਆਖਿਰ ਵਿੱਚ, ਬਹੁਤ ਜ਼ਿਆਦਾ ਫੀਚਰਾਂ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਪੁਲਿਸ਼ ਕਰੋ। ਸਪਸ਼ਟ ਵੈਲਿਡੇਸ਼ਨ ਸਨੇਹੇ, ਲੋਡਿੰਗ ਸਟੇਟ, ਦੋਸਤਾਨਾ ਐਰਰ, ਅਤੇ ਸਮਝਦਾਰ ਡਿਫੌਲਟਸ ਉਹ ਚੀਜ਼ਾਂ ਹਨ ਜੋ ਐਪ ਨੂੰ ਹਕੀਕਤ ਜਿਹਾ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੀਆਂ ਹਨ।
ਇੱਕ ਛੋਟੀ ਟਾਸਕ ਟ੍ਰੈਕਰ ਸੋਚੋ ਜੋ ਤੁਸੀਂ ਲੈਪਟੌਪ 'ਤੇ ਵਰਤਦੇ ਹੋ: ਤੁਸੀਂ ਸਾਈਨ ਇਨ ਕਰਦੇ ਹੋ, ਆਪਣੀ ਲਿਸਟ ਵੇਖਦੇ ਹੋ, ਟਾਸਕ ਜੋੜਦੇ ਹੋ, ਸੋਧਦੇ ਹੋ, ਅਤੇ ਮੁਕੰਮਲ ਹੋਣ 'ਤੇ ਹਟਾ ਦਿੰਦੇ ਹੋ। Vibe coding ਵਿੱਚ, ਤੁਸੀਂ ਪਹਿਲਾਂ ਉਸ ਫਲੋ ਨੂੰ ਸਧਾਰਨ ਜੁਮਲਿਆਂ ਵਿੱਚ ਵੇਰਵਾ ਦਿੰਦੇ ਹੋ, ਫਿਰ ਬਿਲਡਰ ਨੂੰ ਚੱਲਣਯੋਗ ਸਕ੍ਰੀਨਾਂ ਅਤੇ ਡੇਟਾ ਬਣਾਉਣ ਲਈ ਕਹਿੰਦੇ ਹੋ।
ਸਕ੍ਰੀਨਾਂ ਅਤੇ ਐਕਸ਼ਨਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, טੈਕਨੋਲੋਜੀ ਨਾਲ ਨਹੀਂ। ਉਦਾਹਰਨ ਵਜੋਂ: ਇੱਕ ਸਾਇਨ-ਇਨ ਪੇਜ (ਈਮੇਲ + ਪਾਸਵਰਡ, ਸਾਈਨ ਆਊਟ), ਇੱਕ ਟਾਸਕ ਲਿਸਟ (ਲਿਸਟ, ਬਣਾਓ, ਸੋਧੋ, ਮਿਟਾਓ), ਅਤੇ ਵਿਕਲਪਕ ਟਾਸਕ ਡੀਟੇਲਸ ਵਿਊ (ਨੋਟਸ, ਡਿਊ ਡੇਟ, ਸਟੇਟਸ) ਅਤੇ ਇੱਕ ਬੇਸਿਕ ਸੈਟਿੰਗਸ ਸਕ੍ਰੀਨ।
ਫਿਰ, ਡੇਟਾ ਮਨੁੱਖੀ ਸ਼ਬਦਾਂ ਵਿੱਚ ਵੇਰਵਾ ਕਰੋ। “Schema ਡਿਜ਼ਾਈਨ ਕਰੋ” ਦੀ ਬਜਾਏ ਦੱਸੋ ਕਿ ਇੱਕ ਟਾਸਕ ਵਿੱਚ ਕੀ ਸਟੋਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: ਇੱਕ ਟਾਈਟਲ, ਵਿਕਲਪਕ ਨੋਟਸ, ਇੱਕ ਸਟੇਟਸ (todo/doing/done), ਇੱਕ ਵਿਕਲਪਕ ਡਿਊ ਡੇਟ, ਅਤੇ ਬਣਾਉਣ ਤੇ ਅਪਡੇਟ ਹੋਣ ਦੇ ਟਾਈਮਸਟੈਂਪ। ਇਹ ਵੀ ਨੋਟ ਕਰੋ ਕਿ ਟਾਸਕ ਇੱਕ ਯੂਜ਼ਰ ਨਾਲ ਜੁੜੇ ਹੁੰਦੇ ਹਨ।
ਜੇ ਤੁਸੀਂ vibe-coding ਪਲੇਟਫਾਰਮ ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਇੱਕ ਛੋਟਾ ਪਹਿਲਾ ਵਰਜਨ ਮੰਗੋ ਜੋ ਏਂਡ-ਟੂ-ਏਂਡ ਚੱਲਦਾ ਹੋਵੇ: React ਸਕ੍ਰੀਨਾਂ, ਇਕ Go ਬੈਕਐਂਡ, ਅਤੇ PostgreSQL ਡੈਟਾਬੇਸ ਵਿੱਥ ਵਰਣਨ ਕੀਤੇ ਫੀਲਡ। ਪਹਿਲੀ ਪਾਸ ਤੰਗ ਰੱਖੋ: ਸਾਇਨ ਇਨ, ਟਾਸਕ ਵੇਖੋ, ਟਾਸਕ ਜੋੜੋ। ਜਦੋਂ ਇਹ ਕੰਮ ਕਰੇ, ਫਿਰ ਦੁਹਰਾਓ।
ਅਮਲਕਾਰੀ ਰਿਦਮ ਹੈ “ਇਸਨੂੰ ਚਲਾਉ, ਫਿਰ ਸੁਧਾਰ ਕਰ।” ਇੱਕ ਹਕੀਕਤੀ ਕ੍ਰਮ ਇਹ ਹੋ ਸਕਦਾ ਹੈ:
ਹਰੇਕ ਰਾਊਂਡ ਇੱਕ ਹੋਰ ਚੈਟ ਬੇਨਤੀ ਹੁੰਦੀ ਹੈ ਜੋ ਪਹਿਲਾਂ ਦਿੱਤੇ ਕੰਮ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਬਦਲਾਅ ਬਹੁਤ ਵਿਸ਼ੇਸ਼ ਹੋਣ ਅਤੇ ਕੀ ਨਹੀਂ ਟੁੱਟਣਾ ਚਾਹੀਦਾ, ਇਹ ਯਕੀਨੀ ਹੋਵੇ।
ਇੱਕ ਛੋਟੀ ਵੈੱਬ ਐਪ ਲਈ ਵੀ ਕੁਝ ਵਿਸਥਾਰ ਇਹ ਫੈਸਲਾ ਕਰਦੇ ਹਨ ਕਿ ਇਹ ਹਕੀਕਤ ਵਿੱਚ ਚੰਗੀ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ:
ਇੱਕ ਚੰਗੀ ਦੁਹਰਾਉ ਬੇਨਤੀ ਅਜਿਹੀ ਹੁੰਦੀ ਹੈ: “Add a status filter with tabs (All, Todo, Doing, Done). Keep the database the same. Update the API so it can filter by status, and show a loading state when switching tabs.” ਛੋਟੀ, ਟੈਸਟਯੋਗ, ਅਤੇ ਗਲਤ ਸਮਝਣ ਮੁਸ਼ਕਲ।
API ਵਰਣਨ ਕਰਨਾ vibe coding ਲਈ ਸਭ ਤੋਂ ਆਸਾਨ ਜਗ੍ਹਾ ਹੈ ਕਿਉਂਕਿ ਕੰਮ ਜ਼ਿਆਦਾਤਰ ਨਿਯਮਾਂ ਦਾ ਹੁੰਦਾ ਹੈ: ਤੁਸੀਂ ਕਿਹੜਾ ਡੇਟਾ ਸਟੋਰ ਕਰਦੇ ਹੋ, ਕਿਹੜੀਆਂ ਕਾਰਵਾਈਆਂ ਮਨਜ਼ੂਰ ਹਨ, ਅਤੇ ਜਵਾਬ ਕਿਵੇਂ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।
ਸੋਚੋ ਇੱਕ ਛੋਟੇ ਸਟੋਰ ਸਿਸਟਮ ਬਾਰੇ ਜਿਸ ਵਿੱਚ ਦੋ ਚੀਜ਼ਾਂ ਹੋਣ: customers ਅਤੇ orders. ਤੁਹਾਡੇ ਵਾਕ ਬਹੁਤ ਸਧਾਰਨ ਹੋ ਸਕਦੇ ਹਨ: “Customers have name and email. Orders belong to a customer, have items, total price, and a status like draft, paid, shipped.” ਇਹ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਹੈ।
ਇਹ ਸਪਸ਼ਟ ਰੱਖੋ: ਤੁਸੀਂ ਕੀ ਕਰ ਸਕਦੇ ਹੋ, ਤੁਹਾਨੂੰ ਕੀ ਭੇਜਣਾ ਲਾਜ਼ਮੀ ਹੈ, ਅਤੇ ਤੁਹਾਨੂੰ ਕੀ ਵਾਪਸ ਮਿਲੇਗਾ।
ਤੁਸੀਂ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਦੀ ਰੂਪਰੇਖਾ ਦੇ ਸਕਦੇ ਹੋ (create, list, get one, update, delete) customers ਅਤੇ orders ਲਈ, ਫਿਰ ਕੁਝ ਫਿਲਟਰ ਜੋ ਤੁਹਾਨੂੰ ਪਤਾ ਹਨ (ਉਦਾਹਰਨ: list orders by customer_id and status). ਫਿਰ ਇਹ ਪਰਿਭਾਸ਼ਤ ਕਰੋ ਕਿ “not found”, “bad input”, ਅਤੇ “not allowed” ਲਈ ਐਰਰ ਕਿਵੇਂ ਵਰਤਣੇ ਹਨ, ਅਤੇ ਕਿਹੜੇ ਐਂਡਪੌਇੰਟ ਲੌਗਿਨ ਦੀ ਲੋੜ ਰੱਖਦੇ ਹਨ।
ਫਿਰ ਇਨਪੁੱਟ ਨਿਯਮ ਅਤੇ ਐਰਰ ਜਵਾਬ ਜੋੜੋ। ਉਦਾਹਰਨ ਨਿਯਮ: email ਵੈਧ ਅਤੇ ਯੂਨੀਕ ਹੋਣਾ ਚਾਹੀਦਾ; order items ਘੱਟੋ-ਘੱਟ 1 ਹੋਣ; total items ਦੇ ਜੋੜਾ ਦੇ ਬਰਾਬਰ ਹੋਣਾ ਚਾਹੀਦਾ; ਸਟੇਟਸ ਸਿਰਫ਼ ਅੱਗੇ ਵਧ ਸਕਦਾ ਹੈ (draft -> paid -> shipped)।
ਜੇ ਤੁਸੀਂ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਬੁਨਿਆਦੀ ਸੁਰੱਖਿਆ ਦੀ ਪਰਵਾਹ ਕਰਦੇ ਹੋ, ਤਾਂ token auth (bearer token), ਸਧਾਰਨ ਰੋਲ (admin vs support), ਅਤੇ rate limiting (ਉਦਾਹਰਨ: 60 requests per minute per token) ਮੰਗੋ। Koder.ai ਵਰਤ ਰਹੇ ਹੋ ਤਾਂ planning mode ਤੁਹਾਨੂੰ ਇਹ ਨਿਯਮਾਂ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਕਿਸੇ ਵੀ ਕੋਡ ਨੂੰ ਜਨਰੇਟ ਨਾ ਕੀਤਾ ਜਾਵੇ।
ਸ਼ੁਰੂ ਵਿੱਚ ਵਿਆਪਕ ਟੈਸਟਿੰਗ ਦਾ ਲਕਸ਼ ਨਹੀਂ ਰੱਖੋ। ਤੁਸੀਂ ਸਿਰਫ਼ ਇਹ ਪ੍ਰਮਾਣ ਚਾਹੁੰਦੇ ਹੋ ਕਿ API ਦਿੱਤੀਆਂ ਵਿਵਰਣਾਂ ਅਨੁਸਾਰ ਵਰਤਦਾ ਹੈ।
# Create customer
curl -X POST http://localhost:8080/customers \
-H "Authorization: Bearer <token>" \
-H "Content-Type: application/json" \
-d '{"name":"Mina Lee","email":"[email protected]"}'
# Expected: 201 + JSON with id, name, email
# Create order
curl -X POST http://localhost:8080/orders \
-H "Authorization: Bearer <token>" \
-H "Content-Type: application/json" \
-d '{"customer_id":1,"items":[{"sku":"A1","qty":2,"price":12.50}]}'
# Expected: 201 + status "draft" + computed total 25.00
# Bad input example (invalid email)
# Expected: 400 + {"error":"invalid_email"}
ਜੇ ਇਹ ਕਾਲਾਂ ਸਹੀ ਸਟੇਟਸ ਕੋਡ ਅਤੇ ਫੀਲਡ ਵਾਪਸ ਕਰਦੀਆਂ ਹਨ ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਚੱਲਣਯੋਗ ਬੇਸਲਾਈਨ ਹੈ। ਉਸ ਤੋਂ ਬਾਅਦ, pagination, ਬਿਹਤਰ ਫਿਲਟਰਨਗ, ਅਤੇ ਸਾਫ਼ ਐਰਰ ਸੁਨੇਹਿਆਂ ਨੂੰ ਜੋੜੋ ਫਿਰ ਹੋਰ ਫੀਚਰ ਜੋੜੋ।
ਇੱਕ ਚੰਗਾ ਮੋਬਾਈਲ ਉਦਾਹਰਨ ਇੱਕ ਸਧਾਰਣ habit tracker ਹੈ। ਮੋਬਾਈਲ ਐਪਾਂ ਛੋਟੇ ਸਕ੍ਰੀਨ, ਆਫਲਾਈਨ ਵਰਤੋਂ, ਅਤੇ ਡਿਵਾਈਸ ਫੀਚਰਾਂ ਕਾਰਨ “ਕਠਿਨ” ਲੱਗਦੀਆਂ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਸੀਮਾਵਾਂ ਪਹਿਲੇ ਬਿਲਡ ਤੋਂ ਪਹਿਲਾਂ ਵਿਆਖਿਆ ਕਰਦੇ ਹੋ ਤਾਂ ਨਤੀਜੇ ਵਧੀਆ ਹੁੰਦੇ ਹਨ, ਨਾ ਕਿ ਬੱਗ ਆਉਣ ਤੋਂ ਬਾਅਦ।
ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਐਪ ਦਾ ਨਾਮ ਅਤੇ ਪਹਿਲੇ ਦਿਨ ਦਾ ਇੱਕ ਕਾਰਜ ਦਿਓ: “ਰੋਜ਼ਾਨਾ ਆਦਤਾਂ ਨੂੰ ਤੇਜ਼ ਚੈੱਕ-ਇਨ ਨਾਲ ਟ੍ਰੈਕ ਕਰੋ।” ਫਿਰ ਉਹ ਸਕ੍ਰੀਨ ਲਿਖੋ ਜੋ ਤੁਸੀਂ ਉਮੀਦ ਰੱਖਦੇ ਹੋ। ਇਸ ਸੂਚੀ ਨੂੰ ਛੋਟਾ ਰੱਖਣਾ AI ਨੂੰ ਸਾਫ਼ ਨੈਵੀਗੇਸ਼ਨ ਚੁਣਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
ਇੱਕ ਮਜ਼ਬੂਤ ਪਹਿਲਾ ਵਰਜਨ:
ਫਿਰ, ਆਫਲਾਈਨ ਅਤੇ ਸਿੰਕਿੰਗ ਬਾਰੇ ਸਪਸ਼ਟ ਹੋਵੋ। ਬਹੁਤ ਸਾਰੀਆਂ ਮੋਬਾਈਲ ਐਪਾਂ ਨਜ਼ੁਕ ਡੇਟਾ ਨਾਲ ਨਕਾਰਾਤਮਕ ਪ੍ਰਭਾਵ ਪਾਂਦੀਆਂ ਹਨ। ਜੇ ਤੁਸੀਂ ਆਫਲਾਈਨ-ਫਰਸਟ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਕਹੋ: “ਸਭ ਕੁਝ ਆਫਲਾਈਨ ਕੰਮ ਕਰੇ। ਜੇ ਯੂਜ਼ਰ ਬਾਅਦ ਵਿੱਚ ਸਾਇਨ ਕੀਤਾ ਤਾਂ ਬੈਕਗ੍ਰਾਊਂਡ ਵਿੱਚ ਸਿੰਕ ਹੋਵੇ ਅਤੇ ਕਾਨਫਲਿਕਟ ਨੂੰ ਸਭ ਤੋਂ ਨਵੀਂ ਤਬਦੀਲ ਰੱਖ ਕੇ ਹੱਲ ਕੀਤਾ ਜਾਵੇ।” ਜੇ ਤੁਹਾਨੂੰ ਮੌਸਮ ਦੀ ਸਿੰਕਿੰਗ ਦੀ ਲੋੜ ਨਹੀਂ ਤਾਂ ਇਹ ਵੀ ਦੱਸੋ — ਲੋਕਲ-ਓਨਲੀ ਪਹਿਲਾ ਰਿਲੀਜ਼ ਅਕਸਰ ਤੇਜ਼ ਅਤੇ ਘੱਟ ਜੋਖਮ ਵਾਲਾ ਹੁੰਦਾ ਹੈ।
ਫਿਰ ਡਿਵਾਈਸ ਫੀਚਰਾਂ ਦੀ ਨਿਸ਼ਾਨਦਿਹੀ ਕਰੋ — ਭਾਵੇਂ ਤੁਸੀਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਯਕੀਨੀ ਨਾ ਹੋ ਕਿ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਵਰਤੋਂਗੇ, ਕਿਉਂਕਿ ਉਹ ਐਪ ਢਾਂਚੇ ਨੂੰ ਬਦਲ ਦਿੰਦੇ ਹਨ: ਨੋਟੀਫਿਕੇਸ਼ਨ (ਰੋਜ਼ਾਨਾ ਰਿਮਾਈਂਡਰ, ਟਾਈਮਜ਼ੋਨ ਹੈਂਡਲਿੰਗ), ਕੈਮਰਾ (ਤਸਵੀਰਾਂ ਜੁੜਨ ਲਈ), ਲੋਕੇਸ਼ਨ (ਆਮ ਤੌਰ 'ਤੇ ਲੋੜ ਨਹੀਂ), ਅਤੇ ਬਾਇਓਮੈਟਰਿਕ (ਜੇ ਨੋਟਸ ਸੰਵੇਦਨਸ਼ੀਲ ਹਨ)।
ਸੀਧੇ ਤੌਰ 'ਤੇ, ਇੱਕ ਪਲੇਟਫਾਰਮ ਦਿਸ਼ਾ ਚੁਣੋ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਵਧਾਓ। ਉਦਾਹਰਨ: “ਪਹਿਲਾਂ Android ਬਣਾਓ ਸਧਾਰਨ ਨੋਟੀਫਿਕੇਸ਼ਨ ਨਾਲ. iOS ਬਾਅਦ ਵਿੱਚ ਆ ਸਕਦਾ ਹੈ।” ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ Flutter ਮੰਗਣਾ ਅਮਲੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਇਕੋ ਕੋਡਬੇਸ ਰੱਖਦਾ ਹੋਇਆ ਵਿਚਾਰ ਨੂੰ ਇਕੱਠਾ ਕਰਦਾ ਹੈ।
ਇੱਕ ਕਾਰਗਰ ਪ੍ਰੋਂਪਟ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਚੰਗਾ ਨਤੀਜਾ ਦਿੰਦਾ ਹੈ:
“Build a Flutter habit tracker app with 4 screens: Onboarding, Daily List, Add Habit, Stats. Offline first using local storage. No login for v1. Daily reminder notification at a user-chosen time. Keep the UI clean with a bottom nav. Generate sample data for testing.”
ਉੱਥੋਂ, ਛੋਟੇ ਕਦਮਾਂ ਵਿੱਚ ਦੁਹਰਾਓ: ਨੈਵੀਗੇਸ਼ਨ ਚੈੱਕ ਕਰੋ, ਆਫਲਾਈਨ ਵਿਹੀਵਿਅਰ ਜਾਂਚੋ, ਰਿਮਾਈਂਡਰ ਜੋੜੋ, ਫਿਰ ਸਟੈਟਸ ਨਿਖਾਰੋ। ਛੋਟੀ ਲੂਪਾਂ ਵੱਡੇ ਰੀਰਾਈਟਸ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦੀਆਂ ਹਨ।
Vibe coding ਤੋਂ ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਮੁੱਲ ਪਾਉਣਾ ਇਸਨੂੰ ਛੋਟੀ, ਟੈਸਟਯੋਗ ਸ਼ਰਤਾਂ ਵਾਂਗ ਦੇਖਣ ਨਾਲ ਹੁੰਦਾ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਸਮੱਸਿਆਵਾਂ ਉਨ੍ਹਾਂ ਘੜੀਆਂ ਵਿੱਚ ਆਉਂਦੀਆਂ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਸਿੱਧੇ "ਮੁਕੰਮਲ ਉਤਪਾਦ" ਦੀ ਮੰਗ ਕਰਦੇ ਹੋ ਬਿਨਾਂ ਇਹ ਨਿਰਧਾਰਤ ਕੀਤੇ ਕਿ "ਚੱਲਣਯੋਗ" ਦਾ ਕੀ ਮਤਲਬ ਹੈ।
ਇੱਕ ਛੋਟਾ ਦ੍ਰਿਸ਼: ਤੁਸੀਂ ਇੱਕ ਬੁਕਿੰਗ ਵੈੱਬ ਐਪ ਬਣਾ ਰਹੇ ਹੋ। ਤੁਸੀਂ “ਕੈਲੰਡਰ ਅਤੇ ਭੁਗਤਾਨ” ਮੰਗਦੇ ਹੋ, ਅਤੇ ਟੂਲ ਸਕ੍ਰੀਨ, ਡੇਟਾਬੇਸ, ਅਤੇ ਭੁਗਤਾਨ ਸਟਰੱਬ ਜਨਰੇਟ ਕਰ ਦਿੰਦਾ ਹੈ। ਇਹ ਪੂਰਾ ਲੱਗਦਾ ਹੈ, ਪਰ ਤੁਸੀਂ ਇਹ ਕਦੇ ਪਰਿਭਾਸ਼ਤ ਨਹੀਂ ਕੀਤਾ ਕਿ ਜਦੋਂ ਕੋਈ ਦਿਨ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੁੱਕ ਹੋ ਜਾਵੇ ਤਾਂ ਕੀ ਹੋਵੇਗਾ, ਜਦੋਂ ਕਾਰਡ ਫੇਲ ਹੋਵੇ ਤਾਂ ਕੀ ਹੋਵੇਗਾ, ਜਾਂ ਯੂਜ਼ਰ ਭੂਤਕਾਲ ਵਿੱਚ ਬੁਕਿੰਗ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੇ ਤਾਂ। ਇਹ "ਛੋਟੇ" ਗੈਪ ਵੱਡੀਆਂ ਬੱਗ ਬਣ ਜਾਂਦੀਆਂ ਹਨ।
ਚਾਹੇ ਤੁਸੀਂ Koder.ai ਜਾਂ ਹੋਰ ਕੋਈ ਟੂਲ ਵਰਤ ਰਹੇ ਹੋ, ਇਹ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਸ਼ੁਰੂ 'ਚ ਚੈੱਕ ਕਰੋ (ਅੰਤ 'ਤੇ ਨਹੀਂ):
ਸਕੋਪ ਛੋਟਾ ਰੱਖੋ, ਪ੍ਰੋਂਪਟ ਵਿਸ਼ੇਸ਼ ਰੱਖੋ, ਅਤੇ ਬਦਲਾਅ ਕਦਮ-ਕਦਮ ਕਰਕੇ ਕਰੋ। ਇੱਥੇ vibe coding ਮਜ਼ੇਦਾਰ ਅਤੇ ਉਪਜਾਊ ਰਹਿੰਦੀ ਹੈ ਨਾ ਕਿ ਗੁੰਝਲਦਾਰ।
ਅੱਗੇ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਛੋਟੀ "ਕੀ ਇਹ ਅਸਲ ਹੈ?" ਜਾਂਚ ਕਰੋ। Vibe coding ਤੇਜ਼ ਹੈ, ਪਰ ਛੋਟੀਆਂ ਗਲਤੀਆਂ (ਟੁੱਟਾ ਬਟਨ, ਇੱਕ ਫੀਲਡ ਜੋ ਕਦੇ ਵੀ ਸੇਵ ਨਹੀਂ ਹੁੰਦੀ) ਆਖਰੀ ਪਲ ਤੱਕ ਛੁਪ ਸਕਦੀਆਂ ਹਨ।
ਮੁੱਖ ਫਲੋ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਇੱਕ ਪਹਿਲੀ ਵਾਰ ਵਰਤੋਂਕਾਰ ਵਾਂਗ ਕਲਿਕ ਕਰੋ ਅਤੇ ਐਪ ਦੀ ਮਦਦ ਨਾ ਕਰੋ।
ਫਿਰ ਰਿਲੀਜ਼ ਦੀ ਹਕੀਕਤ ਚੈੱਕ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਸ਼ਿਪ ਕੀਤਾ ਅਤੇ ਕੁਝ ਗਲਤ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਵਾਪਸ ਜਾਣ ਦਾ ਇੱਕ ਸੁਰੱਖਿਅਤ ਤਰੀਕਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਇੱਕ ਪਹਿਲਾ ਪ੍ਰੋਜੈਕਟ ਚੁਣੋ ਜੋ ਛੋਟਾ ਪਰ ਪੂਰਾ ਹੋ। ਇੱਕ ਚੰਗੀ ਸ਼ੁਰੂਆਤ ਇੱਕ ਇਕ-ਉਦੇਸ਼ ਟੂਲ ਹੈ ਜਿਸ ਵਿੱਚ ਇੱਕ ਮੁੱਖ ਸਕ੍ਰੀਨ ਅਤੇ ਇੱਕ ਡੇਟਾਬੇਸ ਟੇਬਲ ਹੋਵੇ (ਉਦਾਹਰਨ: ਇੱਕ ਸਧਾਰਨ ਬੁਕਿੰਗ ਲਿਸਟ, ਇੱਕ ਹਲਕਾ CRM, ਜਾਂ ਇੱਕ habit tracker). ਇਸਨੂੰ ਸੰਕੁਚਿਤ ਰੱਖੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਪੂਰਾ ਲੂਪ ਖਤਮ ਕਰ ਸਕੋ।
ਜੇ ਤੁਸੀਂ Koder.ai (koder.ai) ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ planning mode ਵਿੱਚ ਸ਼ੁਰੂ ਕਰੋ ਤਾਂ ਜੋ ਬਿਲਡ ਕੋਡ ਜਨਰੇਟ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਵੀ ਵਿਵਸਥਿਤ ਰਹੇ। ਇੱਕ ਛੋਟਾ ਸਲਾਇਸ ਬਣਾਓ, ਅਕਸਰ snapshots ਵਰਤੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਬਦਲਾਅ ਤੁਲਨਾ ਕਰ ਸਕੋ ਅਤੇ ਜ਼ਰੂਰਤ ਪੈਣ 'ਤੇ ਰੋਲਬੈਕ ਕਰ ਸਕੋ, ਅਤੇ ਜਦੋਂ ਤੁਸੀਂ ਪੂਰੀ ਨਿਯੰਤਰਣ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਸੋਰਸ ਕੋਡ ਐਕਸਪੋਰਟ ਕਰੋ।
ਇੱਕ ਵਾਕ ਵਿੱਚ ਆਪਣੀ “definition of done” ਲਿਖੋ (ਉਦਾਹਰਨ: “A user can add an item, see it in a list, and it stays after refresh”). ਉਹ ਇੱਕ ਵਾਕ vibe coding ਨੂੰ ਕੇਂਦ੍ਰਿਤ ਰੱਖਦਾ ਹੈ ਅਤੇ ਬਿਲਡ ਨੂੰ ਲੰਬੀ ਸੋਚ-ਵਿੱਚਕਾਰੋਂ ਬਚਾਉਂਦਾ ਹੈ।
Vibe coding ਉਹ ਹੈ ਜਿਸ ਵਿੱਚ ਤੁਸੀਂ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਦੱਸ ਕੇ ਸੌਫਟਵੇਅਰ ਬਣਾਉਂਦੇ ਹੋ, AI ਕੋਡ ਅਤੇ ਪ੍ਰੋਜੈਕਟ ਦੀ ਢਾਂਚਾ ਤਿਆਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਸਪਸ਼ਟ ਫੀਡਬੈਕ ਨਾਲ ਉਸਨੂੰ ਦੁਰੁਸਤ ਕਰਨ ਤਕ ਦੁਹਰਾਉ।
ਤੁਸੀਂ ਹੁਣ ਵੀ ਫੈਸਲੇ ਅਤੇ ਸਮੀਖਿਆ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੋ—“ਵਾਇਬ” ਤੇਜ਼ੀ ਹੈ, ਆਟੋਪਾਇਲਟ ਨਹੀਂ।
ਇੱਕ ਸਾਦਾ ਲੂਪ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ:
ਪਹਿਲਾਂ “ਚੱਲਣਯੋਗ ਡਰਾਫਟ” ਤਿਆਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ, ਫਿਰ ਨਿਖਾਰ ਲਿਆਉ।
ਚੈੱਟ ਵਿੱਚ ਪੇਸਟ ਕਰਨ ਲਈ ਇੱਕ ਮਿਨੀ-ਬ੍ਰੀਫ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:
ਫਿਰ ਲਿਖੋ: “If anything is unclear, ask up to 5 questions before building.”
ਪੂਰੇ ਉਤਪਾਦ ਨਾਲ ਸ਼ੁਰੂ ਨਾ ਕਰੋ। ਇੱਕ ਪਤਲਾ ਸਲਾਇਸ ਖਿੱਚੋ:
ਉਦਾਹਰਨ: “Login → list items → add item.” ਜੇ ਇਹ ਸਥਿਰ ਹੈ, ਤਦ ਅਗਲਾ ਸਲਾਇਸ ਜੋੜੋ।
ਇਸ ਕ੍ਰਮ ਵਿੱਚ ਤੇਜ਼, ਅਸਲੀ ਜਾਂਚ ਕਰੋ:
ਜੇ ਕੋਈ ਮਹੱਤਵਪੂਰਣ ਚੀਜ਼ ਹੈ, ਤਾਂ ਇੱਕ ਛੋਟਾ ਟੈਸਟ ਮੰਗੋ ਤਾਂ ਕਿ ਬਾਅਦ ਵਿੱਚ ਰਿਗਰੈਸ਼ਨ ਨਾ ਹੋਵੇ।
ਟਾਈਟ, ਟੈਸਟਬਲ ਫੀਡਬੈਕ ਦਿਓ। ਚੰਗੇ ਉਦਾਹਰਨ:
ਅਸਪਸ਼ਟ ਬੇਨਤੀਆਂ ਜਿਵੇਂ “make it modern” ਤੋਂ ਬਚੋ ਜਦ ਤੱਕ ਤੁਸੀਂ ਵਿਸ਼ੇਸ਼ ਉਦਾਹਰਨ ਨਾ ਦਿਓ।
ਜੇ ਤੁਸੀਂ ਇਹ ਨਿਸ਼ਾਨ੍ਹਾਂ ਵੇਖੋ ਤਾਂ ਰੁਕੋ ਅਤੇ ਇੱਕ ਸਪੱਸ਼ਟ ਯੋਜਨਾ ਲਿਖੋ:
ਇਸ ਵੇਲੇ, ਇੱਕ ਛੋਟਾ ਸਪੈੱਕ ਬਣਾਓ: ਉਦਾਹਰਨ ਇੰਪੁੱਟ/ਆਉਟਪੁੱਟ, “must pass” ਨਿਯਮ, ਅਤੇ 2–3 ਮੁੱਖ ਟੈਸਟ. ਫਿਰ ਇਕ ਵਾਰੀ ਵਿਚ ਇਕ ਸੋਧ ਲਾਗੂ ਕਰੋ।
ਇਹ ਉਹ ਸਮਾਂ ਹੈ ਜਦ ਤੱਕ ਤੁਸੀਂ ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਸਹਿਮਤੀ ਚਾਹੁੰਦੇ ਹੋ। ਮੰਗੋ:
ਜਦੋਂ ਇਹ ਯੋਜਨਾ ਤੁਹਾਡੇ ਮਨ ਦੇ ਅਨੁਸਾਰ ਹੋਵੇ, ਪਹਿਲਾ ਚੱਲਣਯੋਗ ਵਰਜ਼ਨ ਜਨਰੇਟ ਕਰੋ ਅਤੇ ਫਿਰ ਦੁਹਰਾਓ।
ਜਦੋਂ ਕੁਝ ਕੰਮ ਕਰਦਾ ਹੈ (ਉਦਾਹਰਨ: login + list + add स्थिर ਹਨ) ਤਾਂ ਸਨੇਪਸ਼ੌਟਾਂ ਨੂੰ ਚੈਕਪੌਇੰਟ ਵਜੋਂ ਵਰਤੋ। ਕੋਈ ਨਵਾਂ ਬਦਲਾਅ ਤੋੜਦਾ ਹੈ ਤਾਂ ਅਖੀਰਲੇ ਚੰਗੇ ਸਨੇਪਸ਼ੌਟ 'ਤੇ ਰੋਲਬੈਕ ਕਰੋ ਅਤੇ ਫਿਰ ਬਦਲਾਅ ਨੂੰ ਨਾਰੋਅਲੀ ਤਰੀਕੇ ਨਾਲ ਦੁਬਾਰਾ ਲਾਗੂ ਕਰੋ।
ਇਸ ਨਾਲ ਤੁਸੀਂ ਬਿਨਾਂ ਕੰਮ ਖੋਏ ਅਨੁਭਵ ਕਰ ਸਕਦੇ ਹੋ।
ਜਦੋਂ ਤੁਸੀਂ ਪੂਰੀ ਨਿਯੰਤਰਣ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਕੋਡ ਨਿਰਯਾਤ ਕਰੋ: ਡੀਪ ਕਸਟਮਾਈਜ਼ੇਸ਼ਨ, ਖਾਸ ਟੂਲਿੰਗ, ਕਠੋਰ ਸਮੀਖਿਆ, ਜਾਂ ਆਪਣੀ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਮੂਵ ਕਰਨ ਲਈ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਰਸਤਾ: ਪਲੇਟਫਾਰਮ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਓ ਅਤੇ ਦੁਹਰਾਓ, ਫਿਰ ਜਦੋਂ ਢਾਂਚਾ ਅਤੇ ਮੁੱਖ ਫਲੋਜ਼ ਸਥਿਰ ਹੋ ਜਾਵਣ ਤਾਂ ਐਕਸਪੋਰਟ ਕਰੋ।