22 ਅਕਤੂ 2025·8 ਮਿੰਟ
ਗੈਰ-ਇੰਜੀਨੀਅਰ LLM ਪੀਅਰ-ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਨਾਲ ਅਸਲ ਉਤਪਾਦ ਕਿਵੇਂ ਸ਼ਿਪ ਕਰਦੇ ਹਨ
ਇੱਕ ਵਰਤੋਂਯੋਗ ਮਾਰਗਦਰਸ਼ਿਕ ਜੋ ਗੈਰ-ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ LLM ਨਾਲ ਜੋੜ ਕੇ ਅਸਲ ਉਤਪਾਦ ਸ਼ਿਪ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ: ਵਰਕਫਲੋ, ਪ੍ਰਾਂਪਟ, ਟੈਸਟਿੰਗ ਅਤੇ ਸੁਰੱਖਿਅਤ ਰਿਲੀਜ਼ ਆਦਤਾਂ।
ਇੱਕ ਵਰਤੋਂਯੋਗ ਮਾਰਗਦਰਸ਼ਿਕ ਜੋ ਗੈਰ-ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ LLM ਨਾਲ ਜੋੜ ਕੇ ਅਸਲ ਉਤਪਾਦ ਸ਼ਿਪ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ: ਵਰਕਫਲੋ, ਪ੍ਰਾਂਪਟ, ਟੈਸਟਿੰਗ ਅਤੇ ਸੁਰੱਖਿਅਤ ਰਿਲੀਜ਼ ਆਦਤਾਂ।
“LLM ਨਾਲ ਪੀਅਰ-ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ” ਉਸ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਨਾ ਹੈ ਜਿਵੇਂ ਤੁਸੀਂ ਕਿਸੇ ਮਦਦਗਾਰ ਟੀਮਮੀਟ ਨਾਲ ਕਰਦੇ ਹੋ: ਤੁਸੀਂ ਲਕੜੀ-ਚੀਜ਼ (goal) ਬਿਆਨ ਕਰਦੇ ਹੋ, ਮਾਡਲ ਇੱਕ ਰਵਾਇਤ ਸੁਝਾਉਂਦਾ ਅਤੇ ਕੋਡ ਡਰਾਫਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਰੀਵਿਊ, ਚਲਾਉਣ ਅਤੇ ਰਾਹ-ਦਿਖਾਉਂਦੇ ਹੋ। ਤੁਸੀਂ ਅਜੇ ਵੀ ਉਤਪਾਦ ਫੈਸਲਿਆਂ ਲਈ ਡਰਾਈਵਰ ਹੋ; LLM ਤੇਜ਼ ਟਾਈਪਿਸਟ, ਸਮਝਾਉਣ ਵਾਲਾ ਅਤੇ ਦੂਜਾ ਨਜ਼ਰ-ਟੀਮ ਹੈ।
ਇਸ ਵਰਕਫਲੋ ਲਈ, ਸ਼ਿਪਿੰਗ ਦਾ ਮਤਲਬ “ਮੈਂ ਆਪਣੀ ਲੈਪਟਾਪ 'ਤੇ ਕੁਝ ਬਣਾਇਆ” ਨਹੀਂ ਹੁੰਦਾ। ਸ਼ਿਪਿੰਗ ਦਾ ਮਤਲਬ ਹੈ:
ਇਹ ਕਿਸੇ ਵੀਅਦਿ-ਟੂਲ ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਤੁਹਾਡੀ ਓਪਰੇਸ਼ਨ ਟੀਮ ਹਫ਼ਤੇ ਵਿੱਚ ਵਰਤਦੀ ਹੈ, 10 ਗਾਹਕਾਂ ਲਈ ਪੇਡ ਪਾਇਲਟ, ਜਾਂ ਇੱਕ MVP ਜੋ ਸਾਈਨਅਪ ਇਕੱਠੇ ਕਰਦਾ ਹੈ ਅਤੇ ਮੰਗ ਸਾਬਤ ਕਰਦਾ ਹੈ।
LLM ਨੂੰ ਆਪਣੇ ਡਰਾਫਟਿੰਗ ਅਤੇ ਸਿੱਖਣ ਲਈ ਸਾਥੀ ਸਮਝੋ:
ਤੁਹਾਡਾ ਕੰਮ ਹੈ ਉਤਪਾਦ ਦੀ ਹਕੀਕਤ ਜਾਂਚਣਾ:
LLM ਤੁਹਾਨੂੰ ਜ਼ੀਰੋ ਤੋਂ ਕੰਮ ਕਰਨ ਯੋਗ ਡਰਾਫਟ ਤੱਕ ਤੇਜ਼ੀ ਨਾਲ ਲੈ ਜਾ ਸਕਦੇ ਹਨ, ਪਰ ਉਹ ਵੀ ਗਲਤੀਆਂ ਕਰਦੇ ਹਨ: ਪੁਰਾਣੇ APIs, ਗੁੰਮ ਹੋਏ ਕਦਮ, ਭਰੋਸੇਯੋਗ-ਪਰ-ਗਲਤ ਧਾਰਨਾਵਾਂ। ਜਿੱਤ ਪਹਿਲੀ ਕੋਸ਼ਿਸ਼ 'ਚ ਸਹੀ ਕੋਡ ਨਹੀਂ—ਇਹ ਇੱਕ ਤਿੱਘਾ ਲੂਪ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਪੁੱਛ ਸਕਦੇ ਹੋ “ਇਹ ਕਿਉਂ ਫੇਲ ਹੋਇਆ?” ਅਤੇ ਉਪਯੋਗੀ ਅਗਲਾ ਕਦਮ ਮਿਲਦਾ ਹੈ।
ਇਹ ਅੰਦਾਜ਼ ਖਾਸ ਕਰਕੇ ਫਾਉਂਡਰਾਂ, ਓਪਰੇਟਰਾਂ, ਡਿਜ਼ਾਈਨਰਾਂ ਅਤੇ PMs ਲਈ ਚੰਗਾ ਹੈ ਜੋ ਵਰਕਫਲੋਜ਼ ਨੂੰ ਸਾਫ਼ ਤਰੀਕੇ ਨਾਲ ਵੇਰਵਾ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਟੈਸਟ ਅਤੇ ਇਟਰੇਟ ਕਰਨ ਲਈ ਤਿਆਰ ਹਨ। ਜੇ ਤੁਸੀਂ ਇੱਕ ਸਪਸ਼ਟ ਸਮੱਸਿਆ-ਬਿਆਨ ਲਿਖ ਸਕਦੇ ਹੋ ਅਤੇ ਨਤੀਜਿਆਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ LLM ਨੂੰ ਆਪਣੇ ਪੀਅਰ ਵਜੋਂ ਵਰਤ ਕੇ ਅਸਲੀ ਸਾਫਟਵੇਅਰ ਸ਼ਿਪ ਕਰ ਸਕਦੇ ਹੋ।
ਜੇ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਇਹ ਵਰਕਫਲੋ “ਪੀਅਰਿੰਗ” ਵਰਗਾ ਹੋ ਜਾਵੇ ਅਤੇ “ਔਜ਼ਾਰਾਂ ਜੁਗਲਿੰਗ” ਘੱਟ, ਤਾਂ ਇੱਕ ਸਮਰਪਿਤ vibe-coding ਵਾਤਾਵਰਨ ਵਰਤਣਾ ਮਦਦਗਾਰ ਹੋ ਸਕਦਾ ਹੈ। ਉਦਾਹਰਣ ਵੱਜੋਂ, Koder.ai ਚੈਟ-ਚਲਿਤ ਬਿਲਡਿੰਗ ਦੇ ਆਸ-ਪਾਸ ਬਣਾਇਆ ਗਿਆ ਹੈ (ਪਲਾਨਿੰਗ ਮੋਡ, ਸਨੈਪਸ਼ਾਟ, ਰੋਲਬੈਕ), ਜੋ ਉਸ ਲੂਪ ਨਾਲ ਵਧੀਆ ਤਰੀਕੇ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਇਸ ਗਾਈਡ ਵਿੱਚ ਵਰਤੋਂਗੇ।
AI-ਸਹਾਇਤ ਤਿਆਰ ਕਰਨ ਦੀ ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਰੁਕਾਵਟ ਹੈ ਅਸਪਸ਼ਟ ਬੁਨਿਆਦੀ ਲਕੜੀ ਨਾਲ ਸ਼ੁਰੂ ਕਰਨਾ (“ਇੱਕ ਵਧੀਆ CRM”) ਬਜਾਏ ਇੱਕ ਖਤਮ ਕਰਨ ਯੋਗ ਸਮੱਸਿਆ। LLM ਨਾਲ ਪੀਅਰ-ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਉਸ ਵੇਲੇ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਟਾਰਗੇਟ ਸੰਗ੍ਰਹਿਤ, ਪਰਖਣਯੋਗ ਅਤੇ ਕਿਸੇ ਅਸਲੀ ਵਿਅਕਤੀ ਨਾਲ ਜੁੜਿਆ ਹੋਵੇ ਜੋ ਇਸ ਨੂੰ ਵਰਤੂ।
ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਯੂਜ਼ਰ ਅਤੇ ਇੱਕ ਕੰਮ ਜੋ ਉਹ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ ਚੁਣੋ। ਜੇ ਤੁਸੀਂ ਯੂਜ਼ਰ ਦਾ ਨਾਮ ਨਹੀਂ ਲੈ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਲਗਾਤਾਰ ਆਪਣੀ ਰਾਏ ਬਦਲਦੇ ਰਹੋਗੇ—ਅਤੇ ਮਾਡਲ ਹਰ ਨਵੇਂ ਦਿਸ਼ਾ ਲਈ ਖੁਸ਼ੀ-ਖੁਸ਼ੀ ਕੋਡ ਜਨਰੇਟ ਕਰ ਦੇਵੇਗਾ।
ਚੰਗੀ ਸਮੱਸਿਆ ਇਸ ਤਰ੍ਹਾਂ ਲੱਗਦੀ ਹੈ:
ਇੱਕ ਸਪੱਸ਼ਟ “ਡਿਫ਼ਿਨੀਸ਼ਨ ਆਫ ਡਨ” ਇਕ ਵਾਕ ਵਿੱਚ ਯੂਜ਼ ਕਰੋ ਜੋ ਤੁਸੀਂ ਪਰਖ ਸਕਦੇ ਹੋ:
For [who], build [what] so that [outcome] by [when], because [why it matters].
ਉਦਾਹਰਣ:
“ਫ੍ਰੀਲੈਂਸ ਡਿਜ਼ਾਈਨਰਾਂ ਲਈ, 6 ਖੇਤਰਾਂ ਤੋਂ ਇੱਕ ਇਨਵੌਇਸ PDF ਤਿਆਰ ਕਰਨ ਵਾਲਾ ਇਕ ਛੋਟਾ ਵੈੱਬ ਟੂਲ ਬਣਾਓ, ਤਾਂ ਜੋ ਉਹ ਇਸ ਹਫ਼ਤੇ 3 ਮਿੰਟ ਤੋਂ ਘੱਟ ਵਿੱਚ ਬਿੱਲ ਭੇਜ ਸਕਣ, ਕਿਉਂਕਿ ਦੇਰੀਆਂ ਨਕਦੀ ਪ੍ਰਭਾਹ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦੀਆਂ ਹਨ।”
ਤੁਹਾਡਾ MVP “ਵਰਜਨ 1” ਨਹੀਂ; ਇਹ ਸਭ ਤੋਂ ਛੋਟਾ ਹਿੱਸਾ ਹੈ ਜੋ ਉਤਰ ਦਿੰਦਾ ਹੈ: ਕੀ ਕਿਸੇ ਨੂੰ ਫਿਕਰ ਹੋਵੇਗਾ?
ਉਸਨੂੰ ਇਰਾਦਨਾਕਾਰ ਤੌਰ ਤੇ ਸਧਾਰਨ ਰੱਖੋ:
ਜੇ ਮਾਡਲ ਵਾਧੂ ਫੀਚਰ ਸੁਝਾਏ, ਤਾਂ ਪੁੱਛੋ: “ਕੀ ਇਹ ਕੀਮਤ ਸਾਬਤ ਕਰਨ ਵਿੱਚ ਵਾਧਾ ਕਰਦਾ ਹੈ ਜਾਂ ਸਿਰਫ਼ ਕੋਡ ਦੀ ਮਾਤਰਾ ਵਧਾਉਂਦਾ ਹੈ?”
ਪਾਬੰਧੀਆਂ ਅਚਾਨਕ ਸਕੋਪ ਕ੍ਰੀਪ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਖਤਰਨਾਕ ਚੋਣਾਂ ਤੋਂ ਰੋਕਦੀਆਂ ਹਨ:
ਇਹ ਟੁਕੜੇ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਤੁਸੀਂ ਸਮੱਸਿਆ ਨੂੰ ਉਹ ਲੋੜਾਂ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹੋ ਜਿਨ੍ਹਾਂ ਤੇ LLM ਕਾਰਵਾਈ ਕਰ ਸਕਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਆਪਣੀ ਸੋਚ ਕਿਸੇ ਮਿਤਰਾ ਨੂੰ ਸਮਝਾ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਲੋੜਾਂ ਲਿਖ ਸਕਦੇ ਹੋ। ਤੀਕਾ ਇਹ ਹੈ ਕਿ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ (ਅਤੇ ਕਿਸ ਲਈ) ਬਿਆਨ ਕਰੋ ਬਿਨਾਂ ਤੁਰੰਤ ਹੱਲਾਂ ਤੇ ਛਲਾਂਗ ਮਾਰਦੇ। ਸਪੱਸ਼ਟ ਲੋੜਾਂ LLM ਨੂੰ ਤੇਜ਼, ਸਹੀ ਅਤੇ ਸਹਿਯੋਗਯੋਗ ਬਣਾਉਂਦੀਆਂ ਹਨ।
5–10 ਛੋਟੀ “As a… I want… so that…” ਵਾਕਾਂਸ਼ ਲਿਖੋ। ਸਧਾਰਾ ਰੱਖੋ।
ਜੇ ਕੋਈ ਸਟੋਰੀ “ਅਤੇ ਇਸ ਤੋਂ ਬਾਦ…” ਨੂੰ ਮੰਗਦੀ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਦੋ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡੋ। ਹਰ ਸਟੋਰੀ ਨਾਨ-ਇੰਜੀਨੀਅਰ ਦੁਆਰਾ ਟੈਸਟ ਕੀਤੇ ਜਾਣ ਯੋਗ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।
ਇਹ ਦਸਤਾਵੇਜ਼ ਉਹ ਹੁੰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਪ੍ਰਾਂਪਟ ਵਿੱਚ ਪੇਸਟ ਕਰੋਗੇ। ਸ਼ਾਮਲ ਕਰੋ:
ਤੁਸੀਂ ਡਿਜ਼ਾਈਨ ਸਕਿਲ ਨਹੀਂ ਲੋੜ। ਸਕ੍ਰੀਨ ਅਤੇ ਹਰ ਇੱਕ ਵਿੱਚ ਕੀ ਹੈ ਲਿਸਟ ਕਰੋ:
ਇੱਕ ਖੁਰਦਰਾ ਫਲੋ ਅੰਦੇਸ਼ਾ ਘਟਾਉਂਦਾ ਹੈ: ਮਾਡਲ ਸਹੀ ਰੂਟਸ, ਕੰਪੋਨੈਂਟਸ ਅਤੇ ਡੇਟਾ ਬਣਾ ਸਕਦਾ ਹੈ।
v1 ਲਈ ਡਿਫ਼ਿਨੀਸ਼ਨ ਆਫ ਡਨ ਲਿਖੋ, ਜਿਵੇਂ: “ਇੱਕ ਨਵਾਂ ਯੂਜ਼ਰ ਸਾਈਨ ਅਪ ਕਰ ਸਕੇ, ਆਈਟਮ ਸੰਭਾਲ ਸਕੇ, ਆਪਣੀ ਲਿਸਟ ਵੇਖ ਸਕੇ ਅਤੇ ਸ਼ੇਅਰ ਕਰ ਸਕੇ; ਗ਼ਲਤੀਆਂ ਸਪਸ਼ਟ ਸੁਨੇਹੇ ਦਿਖਾਉਣ; ਡੇਟਾ ਰੀਫ੍ਰੇਸ਼ ਤੋਂ ਬਾਅਦ ਬਚਿਆ ਰਹੇ।”
ਫਿਰ ਇੱਕ ਛੋਟਾ ਬੈਕਲੌਗ (5–8 ਆਈਟਮ) ਰੱਖੋ, ਹਰ ਇੱਕ ਯੂਜ਼ਰ ਸਟੋਰੀ ਨਾਲ ਜੁੜਿਆ ਅਤੇ ਇੱਕ ਸਧਾਰਨ ਸਵੀਕ੍ਰਿਤੀ ਚੈੱਕ ਨਾਲ।
ਤੁਹਾਡਾ ਪਹਿਲਾ ਸਟੈਕ “ਹਮੇਸ਼ਾ ਲਈ” ਫੈਸਲਾ ਨਹੀਂ ਹੈ। ਇਹ ਟ੍ਰੇਨਿੰਗ-ਹਵੀਆਂ ਹਨ ਜੋ ਤੁਹਾਨੂੰ ਇੱਕ ਉਪਯੋਗੀ ਚੀਜ਼ ਖਤਮ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਨਗੇ। ਲਕੜੀ ਇਹ ਹੈ ਕਿ ਵਿਕਲਪ ਘੱਟ ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਆਪਣੀ ਤਵੱਜੋ ਉਤਪਾਦ 'ਤੇ ਦੇ ਸਕੋ।
ਕਿਹਾੜੇ ਬਣਾਉਂਦੇ ਹੋ ਇਸ ਦੇ ਅਧਾਰ ਤੇ ਚੁਣੋ, ਜੋ ਇੰਪ੍ਰੈੱਸ ਕਰਨ ਵਾਲਾ ਲੱਗਦਾ ਹੈ ਉਸ ਦੇ ਅਨੁਸਾਰ ਨਹੀਂ:
ਜੇ ਤੁਸੀਂ ਸ਼ੱਕ ਵਿੱਚ ਹੋ, ਤਾਂ ਇੱਕ ਛੋਟਾ ਵੈੱਬ ਐਪ ਚੁਣੋ—ਇਹ ਸ਼ੇਅਰ ਅਤੇ ਟੈਸਟ ਕਰਨਾ ਸਭ ਤੋਂ ਆਸਾਨ ਹੈ।
ਉਹ ਟੂਲ ਚੁਣੋ ਜੋ ਬਹੁਤ ਉਦਾਹਰਣ, ਪੇਮਾਨੇ-ਅਨੁਕੂਲ ਡਿਫ਼ਾਲਟ ਅਤੇ ਸਰਗਰਮ ਕਮਿਿਊਨਿਟੀ ਰੱਖਦੇ ਹਨ। “ਬੋਰੀ” ਦਾ ਮਤਲਬ:
ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਤੁਹਾਡਾ LLM ਪੀਅਰ-ਪ੍ਰੋਗ੍ਰਾਮਰ ਲੋਕਪ੍ਰਿਯ ਸਟੈਕਾਂ ਵਿੱਚ ਵੱਧ ਅਸਲ-ਦੁਨੀਆ ਦੇ ਪੈਟਰਨ ਅਤੇ ਗਲਤੀਆਂ ਦੇਖ ਚੁੱਕਾ ਹੋਵੇਗਾ, ਜੋ ਡੈੱਡ ਏਂਡਾਂ ਘਟਾਉਂਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਸਟੈਕ ਖੁਦ ਨਹੀਂ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ, ਤਾਂ ਇੱਕ ਪਲੇਟਫਾਰਮ ਵਰਤਣ ਦਾ ਵਿਕਲਪ ਹੈ ਜੋ ਇਸਨੂੰ ਤੁਹਾਡੇ ਲਈ ਸਟੈਂਡਰਡ ਕਰਦਾ ਹੈ। ਉਦਾਹਰਣ ਵਜੋਂ Koder.ai ਇੱਕ ਪ੍ਰਗਮੈਟਿਕ ਸੈਟਅਪ (React ਅੱਗੇ, Go ਬੈਕਐਂਡ, PostgreSQL ਡੇਟਾ ਲਈ, ਅਤੇ Flutter ਮੋਬਾਇਲ ਲਈ) ਡਿਫ਼ਾਲਟ ਕਰਦਾ ਹੈ, ਜੋ ਗੈਰ-ਇੰਜੀਨੀਅਰਾਂ ਲਈ ਫੈਸਲੇ ਥੱਕਾ ਘਟਾ ਸਕਦਾ ਹੈ।
ਕੋਡ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਉੱਤਰ ਦਿਓ: ਕੌਣ ਇਸਨੂੰ ਚਲਾਉਣ ਦੀ ਲੋੜ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਕਿਵੇਂ?
ਇਹ ਚੋਣ authentication ਤੋਂ ਫ਼ਾਈਲ ਐਕਸੇਸ ਤੱਕ ਹਰ ਚੀਜ਼ ਪ੍ਰਭਾਵਤ ਕਰਦੀ ਹੈ।
ਲਿਖੋ:
ਇੱਕ ਸਧਾਰਨ ਨੋਟ ਜਿਵੇਂ “ਟਾਸਕ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸਟੋਰ ਕਰਨ; ਕੋਈ ਨਿੱਜੀ ਡੇਟਾ ਨਹੀਂ; ਐਡਮਿਨ-ਓਨਲੀ ਪਹੁੰਚ” ਬਾਅਦ ਵਿੱਚ ਦਰਦਨਾਕ ਰੀਵਰਕ ਨੂੰ ਰੋਕਦਾ ਹੈ।
LLM ਉਹ ਵੇਲੇ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਇਕ ਵਿਵਰਣ, ਹੱਦਾਂ ਅਤੇ ਫੀਡਬੈਕ ਦਿੰਦੇ ਹੋ—ਇਸਨੂੰ ਕੋਡ ਵਿੱਕੇ ਅੰਦਰ ਇੱਕ ਸਲConsistency: ਉਹੀ ਪ੍ਰਾਂਪਟ ਹਰ ਵਾਰੀ ਵਰਤੋਂ ਤਾਂ ਜੋ ਤੁਸੀਂ ਅੰਦਾਜ਼ਾ ਲਾ ਸਕੋ ਕਿ ਕੀ ਜਵਾਬ ਆਏਗਾ।
ਇੱਕ ਸਿਮਪਲ ਸਟ੍ਰਕਚਰ ਵਰਤੋ ਜੋ ਤੁਸੀਂ ਕਾਪੀ/ਪੇਸਟ ਕਰ ਸਕਦੇ ਹੋ:
ਉਦਾਹਰਣ:
Context: We’re building a simple invoice tracker web app. Current files: /server.js, /db.js, /ui.
Goal: Add an “Export CSV” button on the invoices list.
Inputs: Fields to include: id, client, amount, status, createdAt.
Constraints: Keep existing endpoints working. No new libraries. Output must be a downloadable CSV.
(ਨੋਟ: ਕੋਡ ਬਲਾਕਾਂ ਦੇ ਅੰਦਰ ਦੀ ਸਾਮੱਗਰੀ ਨਾ ਬਦਲੋ.)
ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਦੀ ਬੇਨਤੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੁੱਛੋ: “ਇੱਕ ਕਦਮ-ਦਰ-ਕਦਮ ਯੋਜਨਾ ਪੇਸ਼ ਕਰੋ ਅਤੇ ਉਹ ਫਾਇਲਾਂ ਦੱਸੋ ਜੋ ਤੁਸੀਂ ਬਦਲੋਗੇ।” ਇਹ ਸ਼ੁਰੂ ਵਿੱਚ ਗਲਤਫ਼ਹਮੀਆਂ ਫੜ ਲੈਂਦਾ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਇਕ ਚੈੱਕਲਿਸਟ ਦਿੰਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਬਿਲਡ ਵਾਤਾਵਰਨ ਨੂੰ ਵਰਤ ਰਹੇ ਹੋ ਜੋ ਇਸਨੂੰ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਤਾਂ ਮਾਡਲ ਨੂੰ ਕਹੋ ਕਿ ਉਹ “ਪਲਾਨਿੰਗ ਮੋਡ” ਵਿੱਚ ਰਹੇ ਜਦ ਤੱਕ ਤੁਸੀਂ ਕਦਮ ਮਨਜ਼ੂਰ ਨਾ ਕਰੋ। (Koder.ai ਖਾਸ ਤੌਰ 'ਤੇ ਪਲਾਨਿੰਗ ਮੋਡ ਸਮਰਥਨ ਕਰਦਾ ਹੈ।)
“ਪੂਰੇ ਫੀਚਰ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖੋ” ਦੀ ਬਜਾਏ, “/ui/InvoicesList ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਬਟਨ ਜੋੜੋ ਅਤੇ ਮੌਜੂਦਾ ਐਂਡਪੋਇੰਟ ਨਾਲ ਵੇਅਰ ਕਰੋ” ਵਰਗੇ ਨਿਰਦੇਸ਼ ਦਿਓ। ਛੋਟੀਆਂ ਬੇਨਤੀਆਂ ਅਣਚਾਹੇ ਤੋੜ-ਫੋੜ ਨੂੰ ਘਟਾਉਂਦੀਆਂ ਹਨ ਅਤੇ ਰੀਵਿਊ ਆਸਾਨ ਬਣਾਉਂਦੀਆਂ ਹਨ।
ਹਰ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਪੁੱਛੋ: “ਤੁਸੀਂ ਕੀ ਬਦਲਿਆ ਅਤੇ ਕਿਉਂ, ਤੇ ਮੈਂ ਮਨੁਅਲ ਤੌਰ 'ਤੇ ਕੀ ਜਾਂਚਾਂ ਕਰਾਂ?” ਇਹ ਮਾਡਲ ਨੂੰ ਉਸ ਸਮੇਂ ਦਾ ਟੀਮਮੀਟ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਫੈਸਲੇ ਵਿਚਾਰਾਂ ਨੂੰ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ।
ਇੱਕ ਰਨਿੰਗ ਨੋਟ (ਦਸਤਾਵੇਜ਼ ਜਾਂ /PROJECT_MEMORY.md) ਵਿੱਚ ਫੈਸਲੇ, ਚਲਾਏ ਕਮਾਂਡਾਂ ਅਤੇ ਇੱਕ ਛੋਟਾ ਫਾਇਲ ਨਕਸ਼ਾ ਸੰਭਾਲੋ। ਜਦੋਂ ਮਾਡਲ ਗੁੰਝਲਦਾਰ ਹੋਵੇ ਤਾਂ ਇਸਨੂੰ ਪ੍ਰਾਂਪਟ ਵਿੱਚ ਪੇਸਟ ਕਰੋ—ਇਹ ਸਿਰ੍ਹਾ ਸੰਦਰਭ ਤੁਰੰਤ ਬਹਾਲ ਕਰ ਦਿੰਦਾ ਹੈ।
LLM ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਣ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਇਸਨੂੰ “ਮੇਰੀ ਪੂਰੀ ਐਪ ਜਨਰੇਟ ਕਰੋ” ਬਟਨ ਸਮਝਣ ਦੀ ਬਜਾਏ, ਇਸਨੂੰ ਟੀਮਮੀਟ ਵਾਂਗ tighter ਲੂਪ ਵਿੱਚ ਵਰਤੋ। ਤੁਸੀਂ ਇੱਕ ਛੋਟੀ ਚੀਜ਼ ਕਰੋ, ਜਾਂਚੋ ਕਿ ਇਹ ਕੰਮ ਕਰਦੀ ਹੈ, ਫਿਰ ਅੱਗੇ ਵਧੋ।
10–30 ਮਿੰਟ ਵਿੱਚ ਖਤਮ ਕੀਤੀ ਜਾ ਸਕਣ ਵਾਲੀ ਟੁਕੜੀ ਚੁਣੋ: ਇੱਕ ਸਕਰੀਨ, ਇਕ ਫੀਚਰ, ਜਾਂ ਇੱਕ ਫਿਕਸ। ਲਕੜੀ ਲਿਖੋ ਕਿ ਕੀ “ਡਨ” ਹੈ।
ਉਦਾਹਰਣ: “‘Create Project’ ਫਾਰਮ ਜੋੜੋ. ਡਨ ਜਦੋਂ ਮੈਂ ਸਬਮਿਟ ਕਰ ਸਕਾਂ, ਸਫਲਤਾ ਸੁਨੇਹਾ ਵੇਖਾਂ, ਅਤੇ ਨਵਾਂ ਪ੍ਰੋਜੈਕਟ ਰੀਫ੍ਰੇਸ਼ ਤੋਂ ਬਾਅਦ ਲਿਸਟ ਵਿੱਚ ਆਏ।”
ਮਾਡਲ ਤੋਂ ਕਦਮ-ਦਰ-ਕਦਮ ਮਾਰਗ ਦਿਖਾਉਣ ਲਈ ਕਹੋ, ਜਿਸ ਵਿੱਚ ਸਹੀ ਟਰਮੀਨਲ ਕਮਾਂਡਾਂ ਅਤੇ ਫਾਇਲ ਸੰਪਾਦਨ ਸ਼ਾਮਲ ਹੋਣ। ਆਪਣੀ ਵਾਤਾਵਰਨ (OS, ਐਡੀਟਰ, ਭਾਸ਼ਾ) ਦੱਸੋ ਅਤੇ ਪਾਠੋਗਿਆ ਕੋਡ ਮੰਗੋ।
ਉਪਯੋਗੀ ਪ੍ਰਾਂਪਟ: “ਹਰ ਬਦਲਾਅ ਦੀ ਸਧਾਰਨ ਅੰਗਰੇਜ਼ੀ ਵਿੱਚ ਵਿਆਖਿਆ ਕਰੋ, ਜਿੱਥੇ ਲਾਜ਼ਮੀ ਹੋਵੇ ਕੋਡ ਵਿੱਚ ਟਿੱਪਣੀਆਂ ਜੋੜੋ, ਅਤੇ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਛੋਟਾ ਰੱਖੋ ਤਾਂ ਜੋ ਮੈਂ ਅਨੁਸਰਨ ਕਰ ਸਕਾਂ।”
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਆਲ-ਇਨ-ਵਨ ਟੂਲ ਵਿੱਚ ਕੰਮ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇਹ ਲੂਪ ਇੱਕ ਵਰਕਸਪੇਸ ਵਿੱਚ ਰੱਖ ਸਕਦੇ ਹੋ: ਚੈਟ ਲਈ ਬਦਲਾਅ, ਸਾਂਝਾ ਕਰਨ ਲਈ ਹੋਸਟਿੰਗ/ਡਿਪਲੋਇ ਅਤੇ ਜਦੋਂ ਚਾਹੋ ਤਦ ਸੋর্স ਕੋਡ ਐਕਸਪੋਰਟ।
ਬਦਲਾਅ ਤੋਂ ਫੌਰاً ਐਪ ਚਲਾਓ। ਜੇ ਕੋਈ ਏਰਰ ਆਉਂਦਾ ਹੈ, ਇਹਦਾ ਪੂਰਾ ਆਉਟਪੁੱਟ ਮਾਡਲ ਨੂੰ ਪੇਸਟ ਕਰੋ ਅਤੇ ਉਸ ਛੋਟੀ ਜਿਹੀ ਫਿਕਸ ਲਈ ਪੁੱਛੋ ਜੋ ਤੁਹਾਨੂੰ ਅਨਬਲੌਕ ਕਰੇ।
ਆਪਣੇ “ਡਨ” ਪਰਿਭਾਸ਼ਾ ਨਾਲ ਜੁੜੀ ਛੇਤੀ ਮਨੁਅਲ ਜਾਂਚ ਕਰੋ। ਫਿਰ ਇਸਨੂੰ ਇੱਕ ਸਧਾਰਨ ਚੈੱਕਲਿਸਟ ਨਾਲ ਲੌਕ ਕਰੋ:
ਇਹ ਲੂਪ ਦੁਹਰਾਓ। ਨੰਨ੍ਹੇ, ਪ੍ਰਮਾਣਿਤ ਕਦਮ ਵੱਡੀਆਂ ਅਨਜਾਣ ਛਲਾਂਗਾਂ ਨਾਲੋਂ ਬੇਹਤਰ ਹਨ—ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਤੁਸੀਂ ਅਜੇ ਵੀ ਕੋਡਬੇਸ ਸਿੱਖ ਰਹੇ ਹੋ।
ਡੀਬੱਗਿੰਗ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਜ਼ਿਆਦਾਤਰ ਗੈਰ-ਇੰਜੀਨੀਅਰ ਅਟਕ ਜਾਂਦੇ ਹਨ—ਨਾਹ ਕਿ ਉਹ “ਬਹੁਤ ਤਕਨੀਕੀ” ਹੈ, ਪਰ ਕਿਉਂਕਿ ਫੀਡਬ4਼ ਬਹੁਤ ਸ਼ੋਰ ਹੈ। ਤੁਹਾਡਾ ਕੰਮ ਉਸ ਸ਼ੋਰ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਪ੍ਰਸ਼ਨ ਵਿੱਚ ਬਦਲਣਾ ਹੈ ਜਿਸਦਾ LLM ਜਵਾਬ ਦੇ ਸਕੇ।
ਜਦੋਂ ਕੁਝ ਟੁੱਟਦਾ ਹੈ, ਉਰਜਨਾ ਦੇ ਨਾਲ ਪੈਰਫਰੇਜ਼ ਕਰਨ ਦੀ ਥਾਂ, ਸਹੀ ਏਰਰ ਸੁਨੇਹਾ ਅਤੇ ਥੋੜ੍ਹੀਆਂ ਲਾਈਨਾਂ ਉੱਪਰ-ਥੱਲੇ ਪੇਸਟ ਕਰੋ। ਇਹ ਜੋ ਤੁਸੀਂ ਉਮੀਦ ਕੀਤੀ ਸੀ ("should") ਅਤੇ ਜੋ ਵਾਸਤਵ ਵਿੱਚ ਹੋਇਆ ("did") ਜੋੜੋ। ਇਹ ਵੱਖਰਾ ਕਰਨ ਦੀ ਚੀਜ਼ ਅਕਸਰ ਗੁਮ ਹੋਦੀ ਹੈ।
ਜੇ ਸਮੱਸਿਆ ਬਰਾਊਜ਼ਰ ਵਿੱਚ ਹੈ, ਤਾਂ ਸ਼ਾਮਲ ਕਰੋ:
ਜੇ ਇਹ ਕਮਾਂਡ-ਲਾਈਨ ਐਪ ਹੈ, ਤਾਂ ਸ਼ਾਮਲ ਕਰੋ:
ਇੱਕ ਸਧਾਰਣ ਪ੍ਰਾਂਪਟ ਸਟ੍ਰਕਚਰ ਜੋ ਕੰਮ ਕਰਦਾ ਹੈ:
ਤਰਜੀਹ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਇਹ ਮਾਡਲ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਦੱਸਣ ਵਾਲੀ ਚੀਜ਼ਾਂ ਬਹੁਤ ਲੰਬੀਆਂ ਸੂਚੀ ਨਹੀਂ ਹੋਣੀਆਂ, ਜੋ ਤੁਹਾਨੂੰ ਖੁੰਝਲ ਵਿੱਚ ਨਹੀਂ ਪਾਉਂਦੀਆਂ।
ਡੀਬੱਗਿੰਗ ਦੁਹਰਾਈ ਜਾਂਦੀ ਹੈ। (ਨੋਟਸ ਐਪ ਜਾਂ /docs/troubleshooting.md) ਵਿੱਚ ਲਿਖੋ:
ਅਗਲੀ ਵਾਰੀ ਜੇ ਓਹੀ ਕਿਸਮ ਦੀ ਸਮੱਸਿਆ ਆਏ—ਗਲਤ ਪੋਰਟ, ਗੁੰਮ ਡਿਪੈਂਡੇੰਸੀ, ਗਲਤ ਨਾਮ ਵਾਲਾ env var—ਤਾਂ ਤੁਸੀਂ ਕਈ ਮਿੰਟਾਂ ਵਿੱਚ ਹੱਲ ਕਰ ਲਵੋਗੇ।
ਤੁਹਾਨੂੰ “ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ” ਸਿੱਖਣ ਦੀ ਲੋੜ ਨਹੀਂ, ਪਰ ਤੁਹਾਨੂੰ ਇੱਕ ਨੰਨ੍ਹਾ ਮਾਨਸਿਕ ਮਾਡਲ ਚਾਹੀਦਾ ਹੈ:
ਹਰ ਬਗ ਨੂੰ ਇੱਕ ਛੋਟੀ ਜਾਂਚ-ਤਫ਼ਤੀਸ਼ ਵਾਂਗ ਦੇਖੋ—ਸਬੂਤ, ਧਾਰਨਾਵਾਂ ਅਤੇ ਇੱਕ ਛੋਟਾ ਟੈਸਟ। LLM ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ, ਪਰ ਤੁਸੀਂ ਹੀ ਦਿਸ਼ਾ ਨਿਰਦੇਸ਼ਕ ਹੋ।
ਤੁਸੀਂ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਇੱਕ QA ਇੰਜੀਨੀਅਰ ਹੋਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ ਕਿ ਜਿਆਦਾਤਰ ਉਤਪਾਦ ਨੁਕਸਾਨ ਕਰਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਫੜ ਸਕੋ। ਤੁਹਾਨੂੰ ਇੱਕ ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਤਰੀਕਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਇਹ ਜਾਂਚੇ ਕਿ ਤੁਹਾਡੀ ਐਪ ਉਹੀ ਕਰ ਰਹੀ ਹੈ ਜੋ ਤੁਸੀਂ ਵਾਅਦਾ ਕੀਤਾ।
ਆਪਣੀਆਂ ਲਿਖੀਆਂ ਲੋੜਾਂ ਲਓ ਅਤੇ ਮਾਡਲ ਨੂੰ ਕਹੋ ਕਿ ਇੱਕ ਦੱਸ-ਟੈਸਟ ਸੈੱਟ ਬਣਾਏ: ਸਧਾਰਨ ਫਲੋ, ਐਜ ਕੇਸ ਅਤੇ ਫੇਲ ਕੇਸ। ਉਹਨਾਂ ਨੂੰ ਸਪਸ਼ਟ ਅਤੇ ਦੇਖਣਯੋਗ ਰੱਖੋ।
ਉਦਾਹਰਣ ਟੈਸਟ: “ਜਦੋਂ ਮੈਂ 200 ਰੋਜ਼ ਵਾਲੀ .csv ਅੱਪਲੋਡ ਕਰਦਾ ਹਾਂ, ਐਪ ਸਫਲਤਾ ਸੁਨੇਹਾ ਦਿਖਾਉਂਦਾ ਅਤੇ 200 ਆਈਟਮ ਇੰਪੋਰਟ ਕਰਦਾ।”
ਆਟੋਮੈਟੇਡ ਟੈਸਟ ਉਨ੍ਹਾਂ ਹਾਲਤਾਂ ਲਈ ਵਾਧੇਯੋਗ ਹਨ ਜਦੋਂ ਉਹ ਆਸਾਨ ਹਨ ਅਤੇ ਤੇਜ਼ ਚੱਲਦੇ ਹਨ। ਮਾਡਲ ਨੂੰ ਕਹੋ ਕਿ ਸਾਫ਼-ਫੰਕਸ਼ਨਾਂ, ਇਨਪੁੱਟ ਵੈਲੀਡੇਸ਼ਨ ਅਤੇ ਆਹਮ API ਐਂਡਪੋਇੰਟ ਲਈ ਟੈਸਟ ਜੋੜੇ। ਹੋਰ ਸਭ ਲਈ—UI ਪੋਲਿਸ਼, ਕਾਪੀ, ਲੇਆਊਟ—ਮਨੁਅਲ ਚੈੱਕਲਿਸਟ ਵਰਤੋ।
ਇੱਕ ਚੰਗਾ ਨਿਯਮ: ਜੋ ਕੁਝ ਖਾਮੋਸ਼ੀ ਨਾਲ ਟੁੱਟਦਾ ਹੈ, ਉਹਨੂੰ ਆਟੋਮੈਟ ਕਰੋ; ਜੋ ਕੁਝ ਦਰਸਾਏ ਗਿਆ ਹੈ ਉਹਨੂੰ ਚੈੱਕਲਿਸਟ 'ਤੇ ਰੱਖੋ।
এক ছোট ਮੈਨੁਅਲ ਸਕ੍ਰਿਪਟ ਲਿਖੋ ਜੋ 2–5 ਮਿੰਟ ਵਿੱਚ ਮੁੱਖ ਕੀਮਤ ਸਾਬਤ ਕਰੇ। ਇਹ ਹਰ ਵਾਰੀ ਤੁਸੀਂ ਬਿਲਡ ਸਾਂਝਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਚਲਾਉਣ ਲਈ ਹੈ।
ਉਦਾਹਰਣ ਸੰਰਚਨਾ:
ਗੈਰ-ਇੰਜੀਨੀਅਰ ਅਕਸਰ ਸਿਰਫ ਖੁਸ਼ ਰਸਤੇ ਟੈਸਟ ਕਰਦੇ ਹਨ। ਮਾਡਲ ਤੋਂ ਤੁਹਾਡੇ ਫਲੋਜ਼ ਦੀ ਸਮੀਖਿਆ ਕਰਵਾਓ ਅਤੇ ਸੁਝਾਓ ਕਿ ਕਿੱਥੇ ਚੀਜ਼ਾਂ ਫੇਲ ਹੋ ਸਕਦੀਆਂ ਹਨ:
ਇਕ ਸਧਾਰਾ ਲਿਸਟ (ਨੋਟਸ ਐਪ ਠੀਕ ਹੈ) ਰੱਖੋ ਜਿਸ ਵਿੱਚ:
ਫਿਰ ਇਸਨੂੰ ਆਪਣੇ ਪੀਅਰ-ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਥਰੇਡ ਵਿੱਚ ਪੇਸਟ ਕਰੋ ਅਤੇ ਪੁੱਛੋ: “ਮੁਮਕਿਨ ਕਾਰਨ ਨਿਰਧਾਰਿਤ ਕਰੋ, ਫਿਕਸ ਸੁਝਾਓ, ਅਤੇ ਰਿਗ੍ਰੈਸ਼ਨ ਟੈਸਟ ਜਾਂ ਚੈੱਕਲਿਸਟ ਆਈਟਮ ਜੋੜੋ ਤਾਂ ਜੋ ਇਹ ਮੁੜ ਨਾ ਆਵੇ।”
LLM ਨਾਲ ਪੀਅਰ-ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਤੁਹਾਨੂੰ ਤੇਜ਼ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਅਸਾਨ ਵੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਅਕਸਮਾਤਿਕ ਤੌਰ 'ਤੇ ਕੁਝ ਲੀਕ ਕਰ ਬੈਠੋ। ਕੁੱਝ ਸਧਾਰਨ ਆਦਤਾਂ ਤੁਹਾਨੂੰ, ਤੁਹਾਡੇ ਯੂਜ਼ਰ ਅਤੇ ਭਵਿੱਖ ਨੂੰ ਬਚਾਉਂਦੀਆਂ ਹਨ—ਬਿਨਾਂ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਪੂਰੇ ਤੌਰ 'ਤੇ ਕੰਪਲਾਇੰਸ ਕਸਰਤ ਬਣਾਏ।
ਆਪਣੇ LLM ਚੈਟ ਨੂੰ ਇੱਕ ਸਾਰਜਨਿਕ ਥਾਂ ਸਮਝੋ। ਕਦੇ ਵੀ API ਕੀ, ਪਾਸਵਰਡ, ਨਿੱਜੀ ਟੋਕਨ ਜਾਂ ਡੇਟਾਬੇਸ ਕਨੈਕਸ਼ਨ ਸਟਰਿੰਗ ਵਗੈਰਾ ਪੇਸਟ ਨਾ ਕਰੋ।
ਜੇ ਮਾਡਲ ਨੂੰ ਪਤਾ ਹੋਣਾ ਲਾਜ਼ਮੀ ਹੈ ਕਿ ਕਿੱਥੇ ਕੀ ਜਾਵੇਗਾ, ਤਾਂ YOUR_API_KEY_HERE ਵਰਗਾ ਪਲੇਸਹੋਲਡਰ ਸਾਂਝਾ ਕਰੋ ਅਤੇ ਪੁੱਛੋ ਕਿ ਇਹਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਕਿਵੇਂ ਵਾਇਰ ਕਰਨਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਅਸਲੀ ਗਾਹਕ ਉਦਾਹਰਣਾਂ ਨਾਲ ਡੀਬੱਗ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਜੋ ਵੀ ਕਿਸੇ ਨੂੰ ਪਛਾਣ ਸਕਦਾ ਹੋ ਉਸਨੂੰ ਹਟਾ ਦਿਓ: ਨਾਂ, ਈਮੇਲ, ਫੋਨ ਨੰਬਰ, ਪਤੇ, ਆਰਡਰ ID, IP ਪਤੇ ਅਤੇ ਫ੍ਰੀ-ਟੈਕਸਟ ਨੋਟਸ।
ਇੱਕ ਚੰਗਾ ਨਿਯਮ: ਸਿਰਫ ਡੇਟਾ ਦੀ ਸ਼ਕਲ (ਫੀਲਡ ਅਤੇ ਕਿਸਮ) ਅਤੇ ਇੱਕ ਛੋਟਾ ਨਕਲੀ ਨਮੂਨਾ ਸਾਂਝਾ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਯਕੀਨ ਨਹੀਂ, ਤਾਂ ਮੰਨੋ ਕਿ ਇਹ ਸੰਵੇਦਨਸ਼ੀਲ ਹੈ।
ਪਰੋਟੋਟਾਈਪ ਲਈ ਵੀ, ਸੀਕ੍ਰੇਟਸ ਨੂੰ ਕੋਡ ਅਤੇ ਰੀਪੋ ਤੋਂ ਬਾਹਰ ਰੱਖੋ। ਲੋਕਲ ਤੌਰ 'ਤੇ env vars ਵਿੱਚ ਰੱਖੋ, ਅਤੇ ਸਟੇਜਿੰਗ/ਪ੍ਰੋਡ ਉੱਤੇ ਆਪਣੀ ਹੋਸਟਿੰਗ ਪਲੇਟਫਾਰਮ ਦੇ ਬਿਲਟ-ਇਨ ਸੀਕ੍ਰੇਟ ਸਟੋਰੇਜ ਵਰਤੋ।
ਜੇ ਤੁਸੀਂ ਕਈ ਕੀਜ਼ ਇਕੱਠੇ ਕਰ ਰਹੇ ਹੋ (ਭੁਗਤਾਨ, ਈਮੇਲ, ਐਨਾਲਿਟਿਕਸ), ਤਾਂ ਇਕ ਸਧਾਰਾ ਸੀਕ੍ਰੇਟਸ ਮੈਨੇਜਰ ਬਰੋਪਨ ਕਰਨ 'ਤੇ ਵਿਚਾਰ ਕਰੋ—ਇਹ “ਕਾਪੀ/ਪੇਸਟ ਕੀ ਫੈਲਾ” ਰੋਕਦਾ ਹੈ।
ਸੁਰੱਖਿਆ ਸਿਰਫ਼ ਹੈਕਰਾਂ ਬਾਰੇ ਨਹੀਂ; ਇਹ ਅਕਸਮਾਤੀ ਤੋੜ-ਹੁੱਸਨ ਤੋਂ ਵੀ ਬਚਾਉਂਦੀ ਹੈ।
ਮਾਡਲ ਨੂੰ ਇਹ ਬਿਨਾਂ ਸੀਕ੍ਰੇਟ ਸਾਂਝੇ ਕੀਤੇ ਮੈਂਟ ਵਿੱਚ ਯੋਜਨਾ ਕਰਨ ਲਈ ਕਹੋ: “ਇਸ ਐਂਡਪੋਇੰਟ env vars ਤੋਂ ਸੀਕ੍ਰੇਟ ਲੋਡ ਕਰੇ; ਕੋਈ ਸੀਕ੍ਰੇਟ ਚੈਟ ਵਿੱਚ ਨਾ ਪੇਸਟ ਕਰੋ।”
ਇੱਕ ਛੋਟਾ ਨੋਟ ਬਣਾਓ ਜੋ ਜਵਾਬ ਦਿੰਦਾ:
ਇਹ ਇੱਕ-ਪੰਨਾ ਨੋਟ ਭਵਿੱਖੀ ਫੈਸਲਿਆਂ ਨੂੰ ਮਦਦ ਕਰਦੀ ਹੈ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਯੂਜ਼ਰਾਂ, ਟੀਮ ਜਾਂ ਸਲਾਹਕਾਰ ਨੂੰ ਸਮਝਾਉਣਾ ਆਸਾਨ ਬਣਾਉਂਦੀ ਹੈ।
ਜੋ ਕੁਝ ਤੁਹਾਡੇ ਲੈਪਟਾਪ 'ਤੇ ਚੱਲਦਾ ਹੈ ਉਹ ਇੱਕ ਵੱਡੀ ਇੱਕ ਮੀਲ ਦਾ ਪੱਥਰ ਹੈ—ਪਰ ਇਹ “ਉਤਪਾਦ” ਨਹੀਂ ਹੁੰਦਾ ਜਦ ਤੱਕ ਹੋਰ ਲੋਕ ਇਸਨੂੰ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਵਰਤ ਨਹੀਂ ਸਕਦੇ। ਚੰਗੀ ਖਬਰ: ਤੁਹਾਨੂੰ ਜਟਿਲ DevOps ਸੈਟਅਪ ਦੀ ਲੋੜ ਨਹੀਂ; ਤੁਹਾਨੂੰ ਇੱਕ ਸਧਾਰਨ ਡਿਪਲੋਇਮੈਂਟ ਰਸਤਾ, ਇੱਕ ਛੋਟਾ ਚੈੱਕਲਿਸਟ ਅਤੇ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਜਲਦੀ ਦੇਖਣ ਦਾ ਤਰੀਕਾ ਚਾਹੀਦਾ ਹੈ।
ਇੱਕ ਚੋਣ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਦੋ ਵਾਕਾਂ ਵਿੱਚ ਆਪਣੀ ਟੀਮਮੀਟ ਨੂੰ ਸਮਝਾ ਸਕੋ:
ਜੇ ਤੁਸੀਂ ਅਣਿਸ਼ਚਿੱਤ ਹੋ, ਤਾਂ ਆਪਣੇ LLM ਪੀਅਰ ਨੂੰ ਪੁੱਛੋ ਕਿ ਤੁਹਾਡੇ ਸਟੈਕ ਅਤੇ ਪਾਬੰਧੀਆਂ ਦੇ ਆਧਾਰ 'ਤੇ ਇੱਕ ਅਭਿਆਸ ਸੁਝਾਓ ਅਤੇ ਇੱਕ ਕਦਮ-ਦਰ-ਕਦਮ ਡਿਪਲੋਇ ਸਕ੍ਰਿਪਟ ਤਿਆਰ ਕਰੋ ਜੋ ਤੁਸੀਂ ਫਾਲੋ ਕਰ ਸਕੋ।
ਜੇ ਤੁਸੀਂ ਸ਼ੁਰੂ ਵਿੱਚ ਡਿਪਲੋਇਮੈਂਟ ਨਾਲ ਸਿਆਣਪ ਛੱਡਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਉਹ ਪਲੇਟਫਾਰਮ ਚੁਣੋ ਜੋ ਹੋਸਟਿੰਗ ਤੇ ਡਿਪਲੋਇਮੈਂਟ ਨੂੰ ਬਿਲਡਿੰਗ ਨਾਲ ਇੱਕੋ ਵਰਕਫਲੋ ਵਿੱਚ ਬੰਨ੍ਹਦਾ ਹੈ। Koder.ai ਡਿਪਲੋਇਮੈਂਟ/ਹੋਸਟਿੰਗ ਅਤੇ ਸੋর্স ਕੋਡ ਐਕਸਪੋਰਟ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ—ਜੋ ਜਦੋਂ ਤੁਸੀਂ ਤੁਰੰਤ ਕੰਮ ਕਰਨ ਵਾਲੀ ਲਿੰਕ ਸਾਂਝੀ ਕਰਨੀ ਚਾਹੁੰਦੇ ਹੋ ਪਰ ਫਿਰ ਵੀ ਆਪਣੀ ਇੰਫ੍ਰਾਸਟਰੱਕਚਰ 'ਤੇ ਜਾਵਣ ਦਾ ਵਿਕਲਪ ਰੱਖਣਾ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਲਾਭਦਾਇਕ ਹੈ।
ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਚੈੱਕਲਿਸਟ ਚਲਾਓ ਜੋ ਆਮ ਗਲਤੀਆਂ ਰੋਕੇ:
ਸਧਾਰਾ ਨਿਯਮ: ਜੇ ਤੁਸੀਂ 30 ਸਕਿੰਟ ਵਿੱਚ ਆਪਣੀ ਰੋਲਬੈਕ ਦੀ ਵਿਆਖਿਆ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਤੁਹਾਡੀ ਰਿਲੀਜ਼ ਪ੍ਰਕਿਰਿਆ ਤਿਆਰ ਨਹੀਂ ਹੈ।
ਟਿੱਪ: ਜੋ ਵੀ ਟੂਲ ਤੁਸੀਂ ਵਰਤਦੇ ਹੋ, ਰੋਲਬੈਕ ਨੂੰ ਪਹਿਲੀ-ਕਲਾਸ ਅਦਤ ਬਣਾਓ। ਸਨੈਪਸ਼ਾਟ + ਰੋਲਬੈਕ (Koder.ai ਵਰਗੇ) ਅਕਸਰ ਜ਼ਿਆਦਾ ਅਕਲੋ-ਸਮਝ ਹੋਰਨਿਆਂ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਲਈ ਮਨੋਵਿਗਿਆਨਕ ਰਾਹਤ ਦਿੰਦੇ ਹਨ।
ਤੁਹਾਨੂੰ ਜ਼ਿਆਦਾ ਲਗਜ਼ਰੀ ਡੈਸ਼ਬੋਰਡ ਦੀ ਲੋੜ ਨਹੀਂ:
ਮਾਨੀਟਰਿੰਗ “ਕਿਸੇ ਯੂਜ਼ਰ ਨੇ ਕਿਹਾ ਇਹ ਟੁੱਟਿਆ” ਨੂੰ “ਅਸੀਂ ਠੀਕ ਏਰਰ ਵੇਖ ਰਹੇ ਹਾਂ ਅਤੇ ਇਹ ਕਦੋਂ ਸ਼ੁਰੂ ਹੋਇਆ” ਵਿੱਚ ਬਦਲਦੀ ਹੈ।
ਇੱਕ ਛੋਟਾ ਬੀਟਾ ਗਰੁੱਪ (5–20 ਲੋਕ) ਬੁਲਾਓ ਜੋ ਤੁਹਾਡੇ ਟਾਰਗੇਟ ਯੂਜ਼ਰ ਨੂੰ ਮਿਲਦਾ-ਜੁਲਦਾ ਹੋਵੇ। ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਕੰਮ ਦੇਵੋ ਅਤੇ ਫੀਡਬੈਕ ਦੇਵੋ:
ਫੀਡਬੈਕ ਨੂੰ ਨਤੀਜਿਆਂ 'ਤੇ ਕੇਂਦ੍ਰਿਤ ਰੱਖੋ, ਨਾ ਕਿ ਫੀਚਰ-ਇਛਾਵਾਂ 'ਤੇ।
ਜੇ ਤੁਸੀਂ ਪ੍ਰੋਟੋਟਾਈਪ ਨੂੰ ਭੁਗਤਾਨਯੋਗ ਬਣਾਉਣ ਤੇ ਲੈ ਜਾ ਰਹੇ ਹੋ, ਤਾਂ ਰਿਲੀਜ਼ ਯੋਜਨਾ ਨੂੰ ਆਪਣੇ ਉਤਪਾਦ ਯੋਜਨਾ ਦਾ ਹਿੱਸਾ ਬਣਾਓ (ਬਿਲਿੰਗ, ਸਪੋਰਟ, ਅਤੇ ਉਮੀਦਾਂ)। ਜਦੋਂ ਤੁਸੀਂ ਤਿਆਰ ਹੋ, /pricing ਤੇ ਵਿਕਲਪ ਅਤੇ ਅਗਲੇ ਕਦਮ ਵੇਖੋ।
ਜੇ ਤੁਸੀਂ Koder.ai 'ਤੇ ਬਣਾਉਂਦੇ ਹੋ, ਨੋਟ ਕਰੋ ਕਿ ਉੱਥੇ free, pro, business, ਅਤੇ enterprise ਟੀਅਰ ਹਨ—ਤਾਂ ਜੋ ਤੁਸੀਂ ਛੋਟੇ ਪੱਧਰ 'ਤੇ ਸ਼ੁਰੂ ਕਰ ਸਕੋ ਅਤੇ ਸਿਰਫ਼ ਜਦੋਂ ਲੋੜ ਹੋਵੇ ਅੱਪਗ੍ਰੇਡ ਕਰੋ।
ਇੱਕ ਵਾਰੀ ਸ਼ਿਪ ਕਰਨਾ ਰੋਮਾਂਚਕ ਹੈ। ਮੁੜ-ਮੁੜ ਸ਼ਿਪ ਕਰਨਾ (ਅਤੇ ਹਰ ਵਾਰੀ ਬਿਹਤਰ ਕਰਨਾ) ਉਹ ਹੈ ਜੋ ਉਤਪਾਦ ਨੂੰ ਅਸਲੀ ਬਣਾਉਂਦਾ ਹੈ। “ਵੀਕੈਂਡ ਪ੍ਰੋਜੈਕਟ” ਅਤੇ “ਉਤਪਾਦ” ਵਿੱਚ ਫਰਕ ਇੱਕ ਇਰਾਦਪੂਰਣ ਫੀਡਬੈਕ ਲੂਪ ਹੈ।
ਰਾਇ ਇੱਕੱਠੀ ਕਰੋ, ਪਰ ਕੁਝ ਸੰਕੇਤਾਂ ਨੂੰ ਟਰੈਕ ਕਰੋ ਜੋ ਸਿੱਧੇ ਮੂਲ੍ਯ ਨਾਲ ਜੁੜੇ ਹਨ:
ਇਸ ਚੱਕਰ ਵਿੱਚ ਤੁਸੀਂ ਕਿਹੜੇ ਮੈਟ੍ਰਿਕ ਲਈ ਪ੍ਰਾਥਮਿਕਤਾ ਦੇ ਰਹੇ ਹੋ, ਮਾਡਲ ਨੂੰ ਦੱਸੋ। ਇਹ ਤੁਹਾਨੂੰ ਉਹ ਬਦਲਾਅ ਪ੍ਰਾਥਮਿਕ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ ਜੋ ਨਤੀਜੇ ਸੁਧਾਰਦੇ ਹਨ, ਬੱਸ ਸੋਹਨੇ ਪੁਨਰੂਪ ਕਰਨ ਨਾਲ ਨਹੀਂ।
ਛੋਟੀ ਚਕ੍ਰਾਂ ਖਤਰੇ ਘਟਾਉਂਦੀਆਂ ਹਨ। ਇੱਕ ਹਫਤਾਵਾਰ ਰਿਥਮ ਇਸ ਤਰ੍ਹਾਂ ਹੋ ਸਕਦਾ ਹੈ:
ਮਾਡਲ ਨੂੰ ਕਹੋ ਕਿ ਕੱਚੇ ਫੀਡਬੈਕ ਨੂੰ ਬੈਕਲੌਗ ਵਿੱਚ ਤਬਦੀਲ ਕਰੇ:
“ਇੱਥੇ 20 ਯੂਜ਼ਰ ਨੋਟ ਹਨ. ਉਨ੍ਹਾਂ ਨੂੰ ਸਮੂਹਬੱਧ ਕਰੋ, ਟਾਪ 5 ਥੀਮ ਪਛਾਣੋ, ਅਤੇ ਪ੍ਰਭਾਵ-ਵਿਰੁੱਧ-ਪਰਿਆਸ ਅਨੁਸਾਰ 8 ਟਾਸਕ ਸੁਝਾਓ. ਸਵੀਕ੍ਰਿਤੀ ਮਾਪਦੰਡ ਸ਼ਾਮਲ ਕਰੋ.”
ਇੱਕ ਹਲਕੀ “What's new” ਸੈਕਸ਼ਨ ਭਰੋਸਾ ਬਣਾਉਂਦਾ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਇੱਕੋ ਗੱਲ ਨੂੰ ਦੁਹਰਾਉਣ ਤੋਂ ਰੋਕਦਾ ਹੈ (“ਅਸੀਂ ਪਹਿਲਾਂ ਇਹ ਹੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਚੁੱਕੇ ਹਾਂ”)। ਦਰਜਾਬੰਦੀ ਉਪਯੋਗਕਰਤਾ-ਸਮਰਥ (ਉਦਾਹਰਨ: “Export ਹੁਣ CSV ਸਹਾਇਤਾ ਕਰਦਾ ਹੈ”) ਰੱਖੋ ਅਤੇ ਜਿੱਥੇ ਲੋੜ ਹੋਵੇ ਉਦਾਹਰਣ ਦੇਵੋ।
ਜੇ ਤੁਸੀਂ ਵਾਰ-ਵਾਰ ਸ਼ਿਕਾਇਤਾਂ ਵੇਖਦੇ ਹੋ: ਧੀਰਜੀ, ਮਦਰਭਰੇਓਂ ਗਲਤੀਆਂ, ਕ੍ਰੈਸ਼ ਜਾਂ ਗਲਤ ਨਤੀਜੇ, ਤਾਂ ਨਵੇਂ ਫੀਚਰ ਜੋੜਨਾ ਬੰਦ ਕਰੋ। “ਫੰਡਾਮੈਂਟਲਜ਼ ਸਪ੍ਰਿੰਟ” ਚਲਾਓ ਜੋ ਭਰੋਸੇਯੋਗਤਾ, ਸਪਸ਼ਟਤਾ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ 'ਤੇ ਕੇਂਦ੍ਰਿਤ ਹੋਵੇ। ਉਤਪਾਦ ਨੀਰਸ ਫੀਚਰ #37 ਦੀ ਕਮੀ ਕਰਕੇ ਫੇਲ ਨਹੀਂ ਹੁੰਦੇ—ਉਹ ਅਸਲਕਾਰ ਦੀਆਂ ਮੁੱਖ ਚੀਜ਼ਾਂ ਜਦੋਂ ਲਗਾਤਾਰ ਕੰਮ ਨਹੀਂ ਕਰਦੀਆਂ।
LLM ਉਨ੍ਹਾਂ ਪੈਟਰਨਾਂ (CRUD ਸਕ੍ਰੀਨ, ਸਧਾਰਨ APIs, UI ਟਵੀਕ) ਨੂੰ ਤੇਜ਼ ਕਰਨ ਵਿੱਚ ਮਹਾਨ ਹਨ, ਪਰ ਉਹ ਅਜੇ ਵੀ ਪ੍ਰਡਿਕਟੇਬਲ ਤਰੀਕੇ ਨਾਲ ਕੁਝ ਮੁਸ਼ਕਲੀਆਂ ਨਾਲ ਜੂਝਦੇ ਹਨ। ਸਭ ਤੋਂ ਆਮ ਫੇਲ ਮੋਡ ਹੈ ਭਰੋਸੇਯੋਗ-ਪਰ-ਗਲਤ ਆਊਟਪੁੱਟ—ਕੋਡ ਜੋ ਦਿਖਣ ਵਿੱਚ ਯਥਾਰਥ ਲੱਗਦਾ ਹੈ ਪਰ ਛੁਪੇ ਹੋਏ ਐਜ ਕੇਸ ਬੱਗ, ਸੁਰੱਖਿਆ ਗੈਪ ਜਾਂ ਸੁਖਮ ਸਮਝੌਤਿਆਂ ਨਾਲ ਭਰਿਆ ਹੁੰਦਾ ਹੈ।
ਛੁਪੇ ਬੱਗ: off-by-one ਤਰ੍ਹਾਂ ਦੀਆਂ ਗਲਤੀਆਂ, ਰੇਸ ਕੰਡੀਸ਼ਨ ਅਤੇ ਸਟੇਟ ਸਮੱਸਿਆਵਾਂ ਜੋ ਕੁਝ ਕਲਿੱਕਾਂ ਤੋਂ ਬਾਅਦ ਹੀ ਸਮਣਦੀਆਂ ਹਨ।
ਪੁਰਾਣੀ ਜਾਣਕਾਰੀ: APIs, ਲਾਇਬ੍ਰੇਰੀ ਵਰਜਨ ਅਤੇ ਬਿਹਤਰ ਅਭਿਆਸ ਬਦਲ ਸਕਦੇ ਹਨ; ਮਾਡਲ ਪੁਰਾਣੀ ਸਿੰਟੈਕਸ ਜਾਂ ਡਿਪ੍ਰੀਕੇਟ ਕੀਤੇ ਪੈਕੇਜ ਸੁਝਾ ਸਕਦਾ ਹੈ।
ਓਵਰਕਾਨਫਿਡੈਂਸ: ਇਹ ਕਹਿ ਸਕਦਾ ਹੈ ਕਿ ਕੁਝ ਕੰਮ ਕਰਦਾ ਹੈ ਬਿਨਾਂ ਅਸਲ ਵਿੱਚ ਇਸਨੂੰ ਵੇਰੀਫਾਈ ਕੀਤੇ। ਦਾਵਿਆਂ ਨੂੰ ਹਿਪੋਥੇਸਿਸ ਮੰਨੋ ਅਤੇ ਚਲਾਕੀ ਨਾਲ ਜਾਂਚੋ।
ਜੇ ਤੁਸੀਂ ਇਹ ਵੇਖੋ ਤਾਂ ਰੁਕੋ ਅਤੇ ਆਸਾਨ ਕਰੋ ਪਹਿਲਾਂ:
ਸਹਾਇਤਾ ਜਲਦੀ ਲੲੈਓ ਜੇ:
ਤੁਸੀਂ ਫੈਸਲੇ ਕਰਦੇ ਹੋ: ਕੀ ਬਣਾਉਣਾ ਹੈ, “ਡਨ” ਦਾ ਕੀ ਮਤਲਬ, ਅਤੇ ਕਿਹੜੇ ਖਤਰੇ ਸਵੀਕਾਰਣਯੋਗ ਹਨ। ਮਾਡਲ ਕਾਰਜ ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ, ਪਰ ज़ਿੰਮੇਵਾਰੀ ਤੁਸੀਂ ਹੀ ਧਾਰੋ।
ਇੱਕ ਹੋਰ ਵਿਆਹ-ਕਾਰੂ ਆਦਤ: ਆਪਣਾ ਕੰਮ ਪੋਰਟੇਬਲ ਰੱਖੋ। ਚਾਹੇ ਤੁਸੀਂ ਪਰੰਪਰਾਗਤ ਰੀਪੋ ਵਿੱਚ ਕੰਮ ਕਰੋ ਜਾਂ ਕਿਸੇ ਪਲੇਟਫਾਰਮ (ਜਿਵੇਂ Koder.ai) 'ਤੇ, ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਸੀਂ ਆਪਣਾ ਸੋর্স ਕੋਡ ਐਕਸਪੋਰਟ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਆਪਣੀ ਬਿਲਡ ਨੂੰ ਦੁਹਰਾਈ ਜਾ ਸਕਦੀ ਹੈ। ਇਹ ਇਕੋ ਸ਼ਰਤ ਤੁਹਾਨੂੰ ਟੂਲ ਲੌਕ-ਇਨ ਤੋਂ ਬਚਾਉਂਦੀ ਅਤੇ ਜਦੋਂ ਜ਼ਰੂਰਤ ਹੋਵੇ ਇੰਜੀਨੀਅਰ ਮਦਦ ਲੈਣ ਨੂੰ ਆਸਾਨ ਕਰਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਇੱਕ ਪ੍ਰਾਇਕਟਿਕਲ ਅਗਲਾ ਕਦਮ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ /blog/getting-started ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਜਦੋਂ ਵੀ ਤੁਹਾਡਾ ਬਿਲਡ ਆਪਣੀ ਸਹਿਮਤੀ ਤੋਂ ਵੱਡਾ ਮਹਿਸੂਸ ਹੋਵੇ, ਇਸ ਚੈੱਕਲਿਸਟ 'ਤੇ ਵਾਪਸ ਆਓ।
ਇਹ ਇੱਕ ਵਰਕਫਲੋ ਹੈ ਜਿਥੇ ਤੁਸੀਂ ਉਤਪਾਦ ਦੇ ਫੈਸਲੇ ਅਤੇ ਸੱਚਾਈ ਦੀ ਜਾਂਚ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਰਹਿੰਦੇ ਹੋ, ਜਦਕਿ LLM ਤੁਹਾਡੀ ਮਦਦ ਕਰਦਾ ਹੈ ਕੋਡ ਡਰਾਫਟ ਕਰਨ, ਮਿਡਿਸ਼ਨਾਂ ਸਮਝਾਉਣ, ਵਿਕਲਪ ਪੇਸ਼ ਕਰਨ ਅਤੇ ਟੈਸਟ ਸੁਝਾਉਣ ਵਿੱਚ.
ਤੁਸੀਂ ਗੋਲ ਅਤੇ ਸੀਮਾ ਦੱਸਦੇ ਹੋ; ਇਹ ਇੱਕ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਪ੍ਰਸਤਾਵ ਰੱਖਦਾ ਹੈ; ਤੁਸੀਂ ਇਸਨੂੰ ਚਲਾਉਂਦੇ ਹੋ, ਵੇਰਵਾ ਜਾਂਚਦੇ ਹੋ ਅਤੇ ਅਗਲਾ ਕਦਮ ਨਿਰਦੇਸ਼ਤ ਕਰਦੇ ਹੋ।
ਇਸ ਸੰਦਰਭ ਵਿੱਚ, “ਸ਼ਿਪਿੰਗ” ਦਾ ਮਤਲਬ ਹੈ:
ਜੇ ਇਹ ਸਿਰਫ਼ ਤੁਹਾਡੇ ਲੈਪਟਾਪ 'ਤੇ ਚੱਲਦਾ ਹੈ ਅਤੇ ਪੂਨਰਾਵਰਤ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ, ਤਾਂ ਇਹ ਅਜੇ ਸ਼ਿਪ ਨਹੀਂ ਮੰਨਿਆ ਜਾਵੇਗਾ।
LLM ਡਰਾਫਟਿੰਗ ਅਤੇ ਤੇਜ਼ੀ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ:
ਇਹ ਇਕ ਤੇਜ਼ ਸਹਿਯੋਗੀ ਹੈ, ਪਰ ਅਧਿਕਾਰ ਨਹੀਂ।
ਆਉਟਪੁੱਟ ਨੂੰ ਤੱਕੜੇ ਤਰੀਕੇ ਨਾਲ ਇੱਕ ਹਿਪੋਥੇਸਿਸ ਮੰਨੋ ਅਤੇ ਚਲਾਉਂਦੇ ਤੱਕ ਪ੍ਰਮਾਣਿਤ ਕਰੋ। ਆਮ ਫੇਲਯਾਪਨ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
ਕਾਮਯਾਬੀ ਦਾ ਮਤਲਬ ਪਹਿਲੀ ਕੋਸ਼ਿਸ਼ 'ਚ ਬਿਲਕੁਲ ਸਹੀ ਕੋਡ ਨਹੀਂ, ਬਲਕਿ ਇੱਕ ਤਿੱਗਾ ਲੂਪ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਪੁੱਛ ਸਕਦੇ ਹੋ “ਇਹ ਕਿਉਂ ਫੇਲ ਹੋਇਆ?” ਅਤੇ ਉਪਯੋਗੀ ਅਗਲਾ ਕਦਮ ਮਿਲੇ।
ਇੱਕ ਸਮੱਸਿਆ ਚੁਣੋ ਜੋ ਸੀਮਤ, ਪਰਖਣਯੋਗ ਅਤੇ ਕਿਸੇ ਅਸਲੀ ਉਪਭੋਗਤਾ ਨਾਲ ਜੁੜੀ ਹੋਵੇ। ਮਦਦਗਾਰ ਪੈਟਰਨ:
ਜੇ ਤੁਸੀਂ ਨਹੀਂ ਦੱਸ ਸਕਦੇ ਕਿ ਇਹ ਕਿਸ ਲਈ ਅਤੇ ਕਿਵੇਂ ਵਧੀਆ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਭਟਕ ਜਾਵੋਗੇ।
For [who], build [what] so that [outcome] by [when], because [why it matters].
ਫਿਰ ਇਸਨੂੰ ਸਵੀਕ੍ਰਿਤੀ ਦੀ ਜਾਂਚਾਂ ਵਿੱਚ ਬਦਲੋ (ਕਿ ਤੁਸੀਂ ਕਲਿੱਕ/ਵੇਖ/ਉਤਪਾਦ ਕੀ ਕਰਕੇ ਪੁਸ਼ਟੀ ਕਰੋਗੇ) ਤਾਂ ਜੋ ਤੁਸੀਂ ਯਕੀਨ ਕਰ ਸਕੋ ਕਿ ਇਹ ਸੱਚਮੁਚ ਮੁਕੰਮਲ ਹੋਇਆ।
ਆਪਣੇ ਲਿਖੇ ਹੋਏ ਲੋੜਾਂ ਤੋਂ ਇੱਕ ਨੰਨ੍ਹੀ ਟੈਸਟ ਸੈੱਟ ਬਣਾਓ। ਉਹਨਾਂ ਨੂੰ ਵਿਵਰਤ ਅਤੇ ਨਿਰੀਖਣਯੋਗ ਰਖੋ।
ਉਦਾਹਰਣ ਪ੍ਰਾਂਪਟ:
“ਇਹ ਰਹੀਆਂ ਮੇਰੀਆਂ ਲੋੜਾਂ. 10 ਟੈਸਟ ਕੇਸ ਤਿਆਰ ਕਰੋ: 6 ਸਧਾਰਨ ਫਲੋ, 2 ਐਜ ਕੇਸ ਅਤੇ 2 ਫੇਲ ਹੋਣ ਵਾਲੇ ਕੇਸ. ਹਰ ਇਕ ਲਈ ਕਦਮ ਅਤੇ ਉਮੀਦਿਤ ਨਤੀਜਾ ਦਿਓ.”
ਟੈਸਟਾਂ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਲਿਖੋ ਕਿ ਕੋਈ ਨਾਨ-ਇੰਜੀਨੀਅਰ ਵੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕੇ।
ਕੁਝ ਬੁਨਿਆਦੀ ਨਿਯਮ ਵਰਤੋ:
YOUR_API_KEY_HERE ਵਰਗੇ ਪਲੇਸਹੋਲਡਰ ਵਰਤੋਜੇ ਤੁਸੀਂ auth, payments ਜਾਂ ਨਿੱਜੀ ਡੇਟਾ ਸੰਭਾਲ ਰਹੇ ਹੋ, ਤਾਂ ਇੰਜੀਨੀਅਰ ਦੀ ਸਹਾਇਤਾ ਜਲਦੀ ਲੈਣ 'ਤੇ ਵਿਚਾਰ ਕਰੋ।