25 ਜੁਲਾ 2025·8 ਮਿੰਟ
ਕਿਵੇਂ LLM ਸਧਾਰਣ-ਅੰਗਰੇਜ਼ੀ ਵਿਚਾਰਾਂ ਨੂੰ ਫੁੱਲ-ਸਟੈਕ ਐਪਸ ਵਿੱਚ ਬਦਲਦੇ ਹਨ
LLMs ਕਿਸ ਤਰ੍ਹਾਂ ਸਧਾਰਣ-ਅੰਗਰੇਜ਼ੀ ਉਤਪਾਦ ਵਿਚਾਰਾਂ ਨੂੰ ਵੈੱਬ, ਮੋਬਾਈਲ ਅਤੇ ਬੈਕਐਂਡ ਐਪਸ ਵਿੱਚ ਬਦਲਦੇ ਹਨ: ਰਿਕਵਾਇਰਮੈਂਟਸ, UI ਫਲੋਜ਼, ਡਾਟਾ ਮਾਡਲ, APIs, ਟੈਸਟਿੰਗ, ਅਤੇ ਡਿਪਲੋਇਮੈਂਟ।
LLMs ਕਿਸ ਤਰ੍ਹਾਂ ਸਧਾਰਣ-ਅੰਗਰੇਜ਼ੀ ਉਤਪਾਦ ਵਿਚਾਰਾਂ ਨੂੰ ਵੈੱਬ, ਮੋਬਾਈਲ ਅਤੇ ਬੈਕਐਂਡ ਐਪਸ ਵਿੱਚ ਬਦਲਦੇ ਹਨ: ਰਿਕਵਾਇਰਮੈਂਟਸ, UI ਫਲੋਜ਼, ਡਾਟਾ ਮਾਡਲ, APIs, ਟੈਸਟਿੰਗ, ਅਤੇ ਡਿਪਲੋਇਮੈਂਟ।
"ਚਿੱਟੀ ਅੰਗਰੇਜ਼ੀ ਉਤਪਾਦ ਵਿਚਾਰ" ਅਕਸਰ ਇਰਾਦੇ ਅਤੇ ਉਮੀਦ ਦਾ ਮਿਲਾਪ ਹੁੰਦਾ ਹੈ: ਕਿਹੜਿਆਂ ਲਈ ਹੈ, ਕਿਹੜੀ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਕਰਦਾ ਹੈ, ਅਤੇ ਸਫਲਤਾ ਕਿਵੇਂ ਦੇਖਣੀ ਹੈ। ਇਹ ਕਈ ਵਾਰ ਕੁਝ ਵਾਕ ਹੋ ਸਕਦੇ ਹਨ ("ਕੁੱਤੇ ਦੇ ਘੁੰਮਣ ਵਾਲਿਆਂ ਦੀ ਨਿਯੁਕਤੀ ਲਈ ਐਪ"), ਇੱਕ ਰਫ਼ੂ ਵਰਕਫਲੋ ("ਗਾਹਕ ਦੀ ਬੇਨਤੀ → ਘੁੰਮਣ ਵਾਲਾ ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ → ਭੁਗਤਾਨ"), ਅਤੇ ਕੁਝ ਲਾਜ਼ਮੀ ਚੀਜਾਂ ("ਪੁਸ਼ ਨੋਟੀਫਿਕੇਸ਼ਨ, ਰੇਟਿੰਗ")। ਇਹ ਸੋਚ-ਵਿਚਾਰ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਹੈ—ਪਰ ਲਗਾਤਾਰ ਤਰੀਕੇ ਨਾਲ ਬਣਾਉਣ ਲਈ ਕਾਫ਼ੀ ਨਹੀਂ।
ਜਦੋਂ ਲੋਕ ਕਹਿੰਦੇ ਹਨ ਕਿ ਇੱਕ LLM ਇਕ ਵਿਚਾਰ ਨੂੰ "ਅਨੁਵਾਦ" ਕਰ ਸਕਦਾ ਹੈ, ਉਪਯੋਗੀ ਮਤਲਬ ਇਹ ਹੈ: ਧੁੰਦਲੇ ਲਕਸ਼ਾਂ ਨੂੰ ਨਿਰਧਾਰਤ, ਜਾਂਚਯੋਗ ਫੈਸਲਿਆਂ ਵਿੱਚ ਬਦਲਨਾ। "ਅਨੁਵਾਦ" ਸਿਰਫ਼ ਦੁਹਰਾਉਣਾ ਨਹੀਂ—ਇਹ ਢਾਂਚਾ ਜੁੜਦਾ ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ ਸਮੀਖਿਆ, ਚੁਣੌਤੀ, ਅਤੇ ਲਾਗੂ ਕਰ ਸਕੋ।
LLM ਮੁੱਖ ਬਿਲਡਿੰਗ ਬਲਾਕਾਂ ਦਾ ਪਹਿਲਾ ਡਰਾਫਟ ਤਿਆਰ ਕਰਨ ਵਿੱਚ ਚੰਗੇ ਹਨ:
ਆਮ "ਅੰਤ ਨਤੀਜਾ" ਇੱਕ ਫੁੱਲ-ਸਟੈਕ ਉਤਪਾਦ ਲਈ ਖ਼ਾਕਾ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਵੈੱਬ UI (ਅਕਸਰ ਐਡਮਿਨ ਜਾਂ ਡੈਸਕਟਾਪ-ਭਾਰ ਵਾਲੇ ਕੰਮਾਂ ਲਈ), ਇੱਕ ਮੋਬਾਇਲ UI (ਜਿਨ੍ਹਾਂ ਲਈ ਚਲਦੇ-ਫਿਰਦੇ ਵਰਤੋਂਕਾਰ), ਬੈਕਐਂਡ ਸਰਵਿਸਜ਼ (auth, ਬਿਜ਼ਨਸ ਲੌਜਿਕ, ਨੋਟੀਫਿਕੇਸ਼ਨ), ਅਤੇ ਡੇਟਾ ਸਟੋਰੇਜ (ਡਾਟਾਬੇਸ ਨਾਲ ਫਾਇਲ/ਮੀਡੀਆ ਸਟੋਰੇਜ)।
LLM ਤੁਹਾਡੇ ਉਤਪਾਦ ਦੇ ਟਰੇਡ-ਆਫ਼ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਨਹੀਂ ਚੁਣ ਸਕਦਾ, ਕਿਉਂਕਿ ਸਹੀ ਜਵਾਬ ਸੰਦਰਭ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ ਜੋ ਤੁਸੀਂ ਲਿਖਿਆ ਨਹੀਂ ਹੋ ਸਕਦੇ:
ਮਾਡਲ ਨੂੰ ਇਕ ਪ੍ਰਣਾਲੀ ਸਮਝੋ ਜੋ ਵਿਕਲਪ ਅਤੇ ਡਿਫਾਲਟ ਪੇਸ਼ ਕਰਦਾ ਹੈ, ਨਾ ਕਿ ਆਖ਼ਰੀ ਸੱਚ।
ਸਭ ਤੋਂ ਵੱਡੀਆਂ ਨਾਕਾਮੀਆਂ ਅਕਸਰ ਅਨੁਮਾਨਕਿਤ ਹੁੰਦੀਆਂ ਹਨ:
"ਅਨੁਵਾਦ" ਦਾ ਅਸਲ ਮਕਸਦ ਧਾਰਣਾਵਾਂ ਨੂੰ ਵਿਖਾਉਣਾ ਹੈ—ਤਾਂ ਜੋ ਤੁਸੀਂ ਉਹਨਾਂ ਦੀ ਪੁਸ਼ਟੀ, ਸੋਧ, ਜਾਂ ਰੱਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਜਾਣ ਸਕੋ।
ਕਿਸੇ LLM ਲਈ "ਮੈਨੂੰ X ਲਈ ਐਪ ਬਣਾਓ" ਨੂੰ ਸਕਰੀਨਾਂ, API ਅਤੇ ਡਾਟਾ ਮਾਡਲ ਵਿੱਚ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਹਾਨੂੰ ਇੱਕ ਅਜਿਹਾ ਉਤਪਾਦ ਬ੍ਰੀਫ ਚਾਹੀਦਾ ਹੈ ਜੋ ਡਿਜ਼ਾਈਨ ਲਈ ਕਾਫ਼ੀ ਵਿਸ਼ੇਸ਼ ਹੋਵੇ। ਇਹ ਕਦਮ ਧੁੰਦਲੇ ਇਰਾਦੇ ਨੂੰ ਸਾਂਝਾ ਲਕਸ਼ ਵਿੱਚ ਬਦਲਣ ਬਾਰੇ ਹੈ।
ਇੱਕ ਜਾਂ ਦੋ ਵਾਕਾਂ ਵਿੱਚ ਸਮੱਸਿਆ ਬਿਆਨ ਲਿਖੋ: ਕੌਣ ਸੰਘਰਸ਼ ਕਰ ਰਿਹਾ ਹੈ, ਕਿਸ ਨਾਲ, ਅਤੇ ਕਿਉਂ ਇਹ ਮਾਮਲਾ ਹੈ। ਫਿਰ ਮਨਜ਼ੂਰਯੋਗ ਸਫਲਤਾ ਮੈਟ੍ਰਿਕ ਜੋੜੋ ਜੋ ਨਿਰੀਖਣਯੋਗ ਹੋਣ।
ਉਦਾਹਰਨ: "ਜਿਸ ਤਰ੍ਹਾਂ ਇੱਕ ਕਲੀਨਿਕ ਲਈ ਫਾਲੋ-ਅੱਪ ਮਿਲਣੇ ਦਾ ਸਮਾਂ ਘਟਾਓ।" ਮੈਟ੍ਰਿਕ ਵਿੱਚ ਸੌਮਵਾਰ ਸ਼ਾਮਿਲ ਹੋ ਸਕਦਾ ਹੈ: ਔਸਤ ਸ਼ੈਡਿਊਲਿੰਗ ਸਮਾਂ, ਨੋ-ਸ਼ੋ ਦਰ, ਜਾਂ % ਮਰੀਜ਼ ਆਤਮ-ਸੇਵਾ ਰਾਹੀਂ ਬੁੱਕਿੰਗ ਕਰਦੇ।
ਮੁੱਖ ਉਪਭੋਗਤਾ ਕਿਸਮਾਂ ਦੀ ਸੂਚੀ ਬਣਾਓ (ਹਰ ਉਹ ਨਾਹ ਜੋ ਸਿਸਟਮ ਨੂੰ ਛੂਹ ਸਕਦਾ ਹੈ)। ਹਰ ਇੱਕ ਲਈ ਇੱਕ ਮੁੱਖ ਟਾਸਕ ਅਤੇ ਛੋਟੀ ਸਥਿਤੀ ਦਿਓ।
ਇੱਕ ਉਪਯੋਗੀ ਪ੍ਰੌਂਪਟ ਟੈਮਪਲੇਟ ਹੈ: “As a [role], I want to [do something] so that [benefit].” 3–7 ਕੋਰ Use cases ਦੇ ਟੀਚੇ ਰੱਖੋ ਜੋ MVP ਦਾ ਵਰਣਨ ਕਰਦੇ ਹਨ।
ਸੀਮਾਵਾਂ ਇੱਕ ਸਾਫ਼ ਪ੍ਰੋਟੋਟਾਈਪ ਅਤੇ ਇੱਕ ਸ਼ਿਪਯੋਗ ਉਤਪਾਦ ਵਿਚਕਾਰ ਅੰਤਰ ਹਨ। ਸ਼ਾਮਿਲ ਕਰੋ:
ਪਹਿਲੀ ਰਿਲੀਜ਼ ਵਿੱਚ ਕੀ ਹੈ ਅਤੇ ਕੀ ਮੁਲਤਵੀ ਹੈ — ਇਨ੍ਹਾਂ ਬਾਰੇ ਸਪਸ਼ਟ ਰਹੋ। ਇਕ ਸਧਾਰਨ ਨਿਯਮ: MVP ਫੀਚਰਾਂ ਨੂੰ ਮੁੱਖ ਉਪਯੋਗ ਕੇਸਾਂ ਨੂੰ ਏਂਡ-ਟੂ-ਏਂਡ ਸਮਰਥਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਬਿਨਾਂ ਮੈਨੂਅਲ ਵਰੇਕਰਾਉਂਡਸ ਦੇ।
ਚਾਹੋ ਤਾਂ ਇਸਨੂੰ ਇੱਕ ਪੰਨੇ ਵਾਲੇ ਬ੍ਰੀਫ ਵਜੋਂ ਕੈਪਚਰ ਕਰੋ ਅਤੇ ਅਗਲੇ ਕਦਮਾਂ (ਰਿਕਵਾਇਰਮੈਂਟਸ, UI ਫਲੋਜ਼, ਅਤੇ ਆਰਕੀਟੈਕਚਰ) ਲਈ "ਸੋর্স ऑफ਼ ਟਰੂਥ" ਵਜੋਂ ਰੱਖੋ।
ਇੱਕ ਸਧਾਰਣ-ਅੰਗਰੇਜ਼ੀ ਵਿਚਾਰ ਆਮ ਤੌਰ ਤੇ ਲਕਸ਼, ਅਨੁਮਾਨ, ਅਤੇ ਅਸਪਸ਼ਟ ਸਕੋਪ ਦਾ ਮਿਸ਼ਰਣ ਹੁੰਦਾ ਹੈ। ਇੱਕ LLM ਇੱਥੇ ਉਪਯੋਗੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਗੜਬੜ ਵਾਲੀ ਇਨਪੁਟ ਨੂੰ ਰਿਕਵਾਇਰਮੈਂਟਸ ਵਿੱਚ ਬਦਲ ਸਕਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਸਮੀਖਿਆ, ਸੋਧ ਅਤੇ ਮਨਜ਼ੂਰ ਕਰ ਸਕਦੇ ਹੋ।
ਹਰ ਵਾਕ ਨੂੰ ਯੂਜ਼ਰ ਸਟੋਰੀ ਵਜੋਂ ਦੁਬਾਰਾ ਲਿਖੋ। ਇਹ ਇਹ ਬਲਦਾ ਹੈ ਕਿ ਕੌਣ ਨੂੰ ਕੀ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਕਿਉਂ।
ਜੇਕਰ ਕੋਈ ਸਟੋਰੀ ਉਪਭੋਗਤਾ ਕਿਸਮ ਜਾਂ ਲਾਭ ਨਹੀਂ ਦੱਸਦੀ, ਤਾਂ ਉਹ ਸੰਭਵਤ: ਅਜੇ ਵੀ ਬਹੁਤ ਅਸਪਸ਼ਟ ਹੈ।
ਅਗਲੇ ਕਦਮ ਵਿੱਚ, ਸਟੋਰੀਜ਼ ਨੂੰ ਫੀਚਰਾਂ ਵਿੱਚ ਗਰੁੱਪ ਕਰੋ, ਫਿਰ ਹਰ ਇਕ ਨੂੰ ਮਸਟ-ਹੈਵ ਜਾਂ ਨਾਈਸ-ਟੂ-ਹੈਵ ਕਰੋ। ਇਹ ਡਿਜ਼ਾਈਨ ਅਤੇ ਇੰਜੀਨੀਅਰਿੰਗ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਸਕੋਪ ਡ੍ਰਿਫਟ ਨੂੰ ਰੋਕਦਾ ਹੈ।
ਉਦਾਹਰਨ: "ਪੁਸ਼ ਨੋਟੀਫਿਕੇਸ਼ਨ" ਨਾਈਸ-ਟੂ-ਹੈਵ ਹੋ ਸਕਦਾ ਹੈ, ਜਦਕਿ "ਬੁਕਿੰਗ ਨੂੰ ਰੱਦ ਕਰੋ" ਆਮ ਤੌਰ 'ਤੇ ਮਸਟ-ਹੈਵ ਹੁੰਦਾ ਹੈ।
ਹਰ ਸਟੋਰੀ ਹੇਠਾਂ ਸਧਾਰਨ, ਟੈਸਟ ਕਰਨਯੋਗ ਨਿਯਮ ਜੋੜੋ। ਚੰਗੇ ਅਸੈਪਟੈਂਸ ਕਰਾਈਟੇਰੀਆ ਵਿਸ਼ੇਸ਼ ਅਤੇ ਨਿਰੀਖਣਯੋਗ ਹੁੰਦੇ ਹਨ:
LLM ਅਕਸਰ "ਹੈਪੀ ਪਾਥ" ਨੂੰ ਡਿਫਾਲਟ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਖੁੱਲ੍ਹੇ ਐਡਜ ਕੇਸ ਮੰਗੋ ਜਿਵੇਂ:
ਇਹ ਰਿਕਵਾਇਰਮੈਂਟ ਬੰਡਲ ਬਾਅਦ ਦੇ ਆਉਟਪੁਟ (UI ਫਲੋਜ਼, APIs, ਅਤੇ ਟੈਸਟ) ਦੀ ਮੁਲਾਂਕਣ ਲਈ "ਸੋর্স ਆਫ ਟਰੂਥ" ਬਣ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਸਧਾਰਣ-ਅੰਗਰੇਜ਼ੀ ਵਿਚਾਰ ਤਦ ਹੀ ਬਣਾਉਣਯੋਗ ਬਣਦਾ ਹੈ ਜਦੋਂ ਇਹ ਯੂਜ਼ਰ ਯਾਤਰਾਵਾਂ ਅਤੇ ਸਕਰੀਨਾਂ ਨਾਲ ਸਪਸਟ ਨੈਵੀਗੇਸ਼ਨ ਵਿੱਚ ਬਦਲ ਜਾਵੇ। ਇਸ ਕਦਮ 'ਚ, ਤੁਸੀਂ ਰੰਗ ਵਾਰ ਨਹੀ ਚੁਣ ਰਹੇ—ਤੁਸੀਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰ ਰਹੇ ਹੋ ਕਿ ਲੋਕ ਕੀ ਕਰ ਸਕਦੇ ਹਨ, ਕਿਸ ਕ੍ਰਮ ਵਿੱਚ, ਅਤੇ ਸਫਲਤਾ ਕਿਵੇਂ ਲੱਭਦੀ ਹੈ।
ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਰਾਹਾਂ ਦੀ ਸੂਚੀ ਬਣਾਓ। ਬਹੁਤ ਸਾਰੇ ਉਤਪਾਦਾਂ ਲਈ, ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਬਣਾਉ ਸਕਦੇ ਹੋ:
ਮਾਡਲ ਇਹ ਫਲੋਜ਼ ਕਦਮ-ਦਰ-ਕਦਮ ਤਰੀਕੇ ਨਾਲ ਡਰਾਫਟ ਕਰ ਸਕਦਾ ਹੈ। ਤੁਹਾਡਾ ਕੰਮ ਇਹ ਪੱਕਾ ਕਰਨਾ ਹੈ ਕਿ ਕੀ ਲਾਜ਼ਮੀ ਹੈ, ਕੀ ਵਿਕਲਪਿਕ ਹੈ, ਅਤੇ ਕਿੱਥੇ ਉਪਭੋਗਤਾ ਸੁਰੱਖਿਅਤ ਤੌਰ 'ਤੇ ਬੰਦ ਕਰ ਕੇ ਬਾਅਦ ਵਿਚ ਮੁੜ ਸਕਦੇ ਹਨ।
ਦੋ ਡਿਲਿਵਰੇਬਲ ਮੰਗੋ: ਸਕਰੀਨ ਇਨਵੈਂਟਰੀ ਅਤੇ ਨੈਵੀਗੇਸ਼ਨ ਮੈਪ।
ਚੰਗਾ ਆਉਟਪੁਟ ਸਕਰੀਨਾਂ ਦੇ ਨਾਮ ਇੱਕਸਾਰ ਰੱਖਦਾ ਹੈ (ਉਦਾਹਰਨ: “Order Details” vs “Order Detail”), ਐਂਟਰੀ ਪੁਆਇੰਟ ਦੀ ਪਰਿਭਾਸ਼ਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਖਾਲੀ ਸਥਿਤੀਆਂ (no results, no saved items) ਸ਼ਾਮਿਲ ਕਰਦਾ ਹੈ।
ਰਿਕਵਾਇਰਮੈਂਟਸ ਨੂੰ ਫਾਰਮ ਫੀਲਡਜ਼ ਅਤੇ ਨਿਯਮਾਂ ਵਿੱਚ ਬਦਲੋ: ਲਾਜ਼ਮੀ/ਵਿਕਲਪਿਕ, ਫਾਰਮੈਟ, ਸੀਮਾਵਾਂ, ਅਤੇ ਦੋਸਤਾਨਾ ਤਰੁੱਟੀ ਸੁਨੇਹੇ। ਉਦਾਹਰਨ: ਪਾਸਵਰਡ ਨਿਯਮ, ਭੁਗਤਾਨ ਪਤਾ ਫਾਰਮੈਟ, ਜਾਂ "ਤਾਰੀਖ਼ ਭਵਿੱਖ ਵਿੱਚ ਹੋਣੀ ਚਾਹੀਦੀ"। ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਵੈਧਤਾ ਦੋਨੋ ਢੰਗ ਨਾਲ ਹੁੰਦੀ ਹੈ: ਇਨਲਾਈਨ (ਜਿਵੇਂ ਟਾਈਪ ਕਰਦੇ ਸਮੇਂ) ਅਤੇ ਫਾਰਮ ਸਬਮਿਟ 'ਤੇ।
ਪਾਠ ਆਕਾਰ ਪਾਠਯੋਗ, ਸਪਸ਼ਟ ਰੰਗ ਕਾਂਟਰਾਸਟ, ਵੈੱਬ 'ਤੇ ਫੁੱਲ ਕੀਬੋਰਡ ਸਹਿਯੋਗ, ਅਤੇ ਐਸੇ ਤਰੁੱਟੀ ਸੁਨੇਹੇ ਜੋ ਸਮਝਾਉਂਦੇ ਹਨ ਕਿ ਸਮੱਸਿਆ ਕਿਵੇਂ ਠੀਕ ਕਰਨੀ ਹੈ (ਸਿਰਫ਼ "Invalid input" ਨਾ)। ਹਰੇਕ ਫਾਰਮ ਫੀਲਡ ਦਾ ਲੇਬਲ ਹੋਵੇ ਅਤੇ ਫੋਕਸ ਆਰਡਰ ਮਾਨਸੂਸੀ ਹੋਵੇ।
"ਆਰਕੀਟੈਕਚਰ" ਐਪ ਦਾ ਖ਼ਾਕਾ ਹੈ: ਕਿਹੜੇ ਹਿੱਸੇ ਮੌਜੂਦ ਹਨ, ਹਰ ਹਿੱਸਾ ਕੀ ਜ਼ਿੰਮੇਵਾਰੀ ਨਿਭਾਉਂਦਾ ਹੈ, ਅਤੇ ਉਹ ਇਕ ਦੂਜੇ ਨਾਲ ਕਿਵੇਂ ਗੱਲ ਕਰਦੇ ਹਨ। ਜਦ ਇੱਕ LLM ਆਰਕੀਟੈਕਚਰ ਸੁਝਾਉਂਦਾ ਹੈ, ਤੁਹਾਡਾ ਕੰਮ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਹੈ ਕਿ ਇਹ ਹੁਣ ਬਣਾਉਣ ਲਾਇਕ ਸਧਾਰਨ ਅਤੇ ਭਵੀਸ਼ ਵਿੱਚ ਵਿਕਸਿਤ ਹੋਣ ਲਈ ਸਪਸ਼ਟ ਹੋਵੇ।
ਅਧਿਕਤਰ ਨਵੇਂ ਉਤਪਾਦਾਂ ਲਈ, ਇੱਕ ਇਕੱਲਾ ਬੈਕਐਂਡ (ਮੋਨੋਲਿਥ) ਸ਼ੁਰੂਆਤ ਲਈ ਸਹੀ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਕੋਡਬੇਸ, ਇੱਕ ਡਿਪਲੋਈ, ਇੱਕ ਡਾਟਾਬੇਸ। ਇਹ ਅਜ਼ਾਦੀ ਨਾਲ ਬਣਾਉਣ ਵਿੱਚ ਤੇਜ਼, ਡੀਬੱਗ ਕਰਨ ਵਿੱਚ ਆਸਾਨ, ਅਤੇ ਚਲਾਉਣ ਲਈ ਸਸਤਾ ਹੈ।
ਮੋਡਯੂਲਰ ਮੋਨੋਲਿਥ ਅਕਸਰ ਮਿੱਠਾ ਸਥਾਨ ਹੁੰਦਾ ਹੈ: ਹਾਲੇ ਵੀ ਇੱਕ ਡਿਪਲੋਈ, ਪਰ ਮੋਢਿਆਂ ਵਿੱਚ ਵੰਡਿਆ (Auth, Billing, Projects ਆਦਿ) ਸਾਫ਼ ਸੀਮਾਵਾਂ ਨਾਲ। ਵਰਕਫੋਲੇਟ ਨੂੰ ਵੰਡਣ ਦਾ ਫ਼ੈਸਲਾ ਇਸ ਸਮੇਂ ਕਰੋ ਜਦੋਂ ਵਾਸਤਵਿਕ ਦਬਾਅ ਹੋਵੇ—ਜਿਵੇਂ ਤੇਜ਼ ਟ੍ਰੈਫਿਕ, ਟੀਮ ਨੂੰ ਸੁਤੰਤਰ ਡਿਪਲੋਇ ਦੀ ਲੋੜ, ਜਾਂ ਸਿਸਟਮ ਦਾ ਕੋਈ ਹਿੱਸਾ ਵੱਖਰੀਂ ਤਰੀਕੇ ਨਾਲ ਸਕੇਲ ਕਰ ਰਿਹਾ ਹੋਵੇ।
ਜੇ ਮਾਡਲ ਤੁਰੰਤ "ਮਾਇਕਰੋਸਰਵਿਸਿਜ਼" ਸੁਝਾਏ, ਤਾਂ ਉਸ ਨੂੰ ਠੋਸ ਕਾਰਨ ਦਿਓ—ਭਵਿੱਖ ਦੇ ਅਨੁਮਾਨਾਂ ਦੀ ਬਜਾਏ ਵਰਤਮਾਨ ਲੋੜਾਂ 'ਤੇ ਆਧਾਰਤ।
ਇਕ ਵਧੀਆ ਆਰਕੀਟੈਕਚਰ ਆਉਟਲਾਈਨ ਅਵਸ਼્ય ਨਾਂਅ ਦਿੰਦੀ ਹੈ:
ਮਾਡਲ ਨੂੰ ਇਹ ਵੀ ਦੱਸਣਾ ਚਾਹੀਦਾ ਕਿ ਹਰ ਹਿੱਸਾ ਕਿੱਥੇ ਰਹੇਗਾ (ਬੈਕਐਂਡ vs ਮੋਬਾਈਲ vs ਵੈੱਬ) ਅਤੇ ਕਲਾਇੰਟ ਬੈਕਐਂਡ ਨਾਲ ਕਿਵੇਂ ਗੱਲ ਕਰਦੇ ਹਨ (ਆਮ ਤੌਰ ਪਰ REST ਜਾਂ GraphQL)।
ਆਰਕੀਟੈਕਚਰ ਅਸਪਸ਼ਟ ਰਹਿੰਦੀ ਹੈ ਜਦ ਤੱਕ ਤੁਸੀਂ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਤੈਅ ਨਹੀਂ ਕਰਦੇ: ਬੈਕਐਂਡ ਫਰੇਮਵਰਕ, ਡਾਟਾਬੇਸ, ਹੋਸਟਿੰਗ, ਅਤੇ ਮੋਬਾਈਲ ਢੰਗ (ਨেটਿਵ vs cross-platform)। ਮਾਡਲ ਨੂੰ ਇਹਨਾਂ ਨੂੰ "ਅਨੁਮਾਨ" ਵਜੋਂ ਲਿਖਣ ਲਈ ਕਹੋ ਤਾਂ ਜੋ ਹਰ ਕੋਈ ਜਾਣੇ ਕਿ ਕੀ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ।
ਵੱਡੇ ਰੀਰਾਈਟਾਂ ਦੀ ਥਾਂ, ਛੋਟੇ "ਐਸਕੇਪ ਹੈਚਜ਼" ਨੂੰ ਤਰਜੀਹ ਦਿਓ: ਹਾਟ ਰੀਡਸ ਲਈ ਕੈਸ਼ਿੰਗ, ਬੈਕਗਰਾਊਂਡ ਜਾਬ ਲਈ ਕਿਊ, ਅਤੇ ਸਟੇਟਲੇਸ ਐਪ ਸਰਵਰ ਤਾਂ ਜੋ ਤੁਸੀਂ ਹੋਰ ਇੰਸਟੈਂਸ ਜੋੜ ਸਕੋ। ਸਭ ਤੋਂ ਵਧੀਆ ਆਰਕੀਟੈਕਚਰ ਸੁਝਾਅ ਇਹ ਵਿਕਲਪ ਸਮਝਾਉਂਦੇ ਹਨ ਜਦੋਂ ਕਿ v1 ਸਧਾਰਨ ਰਿਹਾ।
ਉਤਪਾਦ ਵਿਚਾਰ ਅਕਸਰ ਨਾਊਨਜ਼ ਨਾਲ ਭਰਿਆ ਹੁੰਦਾ ਹੈ: "users," "projects," "tasks," "payments," "messages." ਡਾਟਾ ਮਾਡਲਿੰਗ ਉਹ ਕਦਮ ਹੈ ਜਿੱਥੇ ਇੱਕ LLM ਇਨ੍ਹਾਂ ਨਾਊਨਜ਼ ਨੂੰ ਇਸ ਗੱਲ ਵਿੱਚ ਬਦਲਦਾ ਹੈ ਕਿ ਐਪ ਨੂੰ ਕੀ ਸੰਭਾਲਣਾ ਹੈ—ਅਤੇ ਵੱਖ-ਵੱਖ ਚੀਜ਼ਾਂ ਕਿਵੇਂ ਜੁੜਦੀਆਂ ਹਨ।
ਸ਼ੁਰੂ ਕਰੋ ਮੁੱਖ ਐਂਟਿਟੀਜ਼ ਦੀ ਸੁਚੀ ਨਾਲ ਅਤੇ ਪੁੱਛੋ: ਕੀ ਕਿਸ ਨਾਲ ਸਬੰਧਤ ਹੈ?
ਉਦਾਹਰਨ ਲਈ:
ਫਿਰ ਰਿਸ਼ਤਿਆਂ ਅਤੇ ਪਾਬੰਦੀਆਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ: ਕੀ ਇੱਕ ਟਾਸਕ ਪ੍ਰੋਜੈਕਟ ਦੇ ਬਗੈਰ ਮੌਜੂਦ ਹੋ ਸਕਦਾ ਹੈ, ਕੀ ਟਿੱਪਣੀਆਂ ਸੋਧੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ, ਪ੍ਰੋਜੈਕਟ ਆર્કਾਈਵ ਹੋ ਸਕਦੇ ਹਨ, ਅਤੇ ਪ੍ਰੋਜੈਕਟ ਮਿਟਣ 'ਤੇ ਟਾਸਕਾਂ ਨਾਲ ਕੀ ਹੁੰਦਾ ਹੈ।
ਅਗਲਾ, ਮਾਡਲ ਇੱਕ ਪਹਿਲੀ-ਪਾਸ ਸਕੀਮਾ ਸੁਝਾਅ ਦੇਵੇਗਾ (SQL ਟੇਬਲ ਜਾਂ NoSQL ਕਲੈਕਸ਼ਨ)। ਇਸਨੂੰ ਸਿੱਧਾ ਅਤੇ ਫੈਸਲਿਆਂ 'ਤੇ ਕੇਂਦਰਿਤ ਰੱਖੋ ਜੋ ਬਿਹੇਵਿਅਰ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ।
ਇੱਕ ਆਮ ਡਰਾਫਟ ਸ਼ਾਮਿਲ ਹੋ ਸਕਦਾ ਹੈ:
ਜ਼ਰੂਰੀ: "status" ਫੀਲਡ, ਟਾਈਮਸਟੈਂਪ, ਅਤੇ ਯੂਨੀਕ ਪਾਬੰਦੀਆਂ ਜਲਦੀ ਕੈਪਚਰ ਕਰੋ (ਜਿਵੇਂ unique email). ਇਹ ਵੇਰਵੇ ਬਾਅਦ ਵਿੱਚ UI ਫਿਲਟਰ, ਨੋਟੀਫਿਕੇਸ਼ਨ, ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਚਲਾਉਂਦੇ ਹਨ।
ਅਧਿਕਤਰ ਅਸਲ ਐਪਾਂ ਨੂੰ ਸਾਫ਼ ਨਿਯਮਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਕਿ ਕੌਣ ਕੀ ਦੇਖ ਸਕਦਾ/ਕਰ ਸਕਦਾ। ਇੱਕ LLM ਮਲਿਕੀਅਤ ਨੂੰ ਸਪਸ਼ਟ ਕਰੇ (owner_user_id) ਅਤੇ ਐਕਸੈੱਸ ਨੂੰ ਮਾਡਲ ਕਰੇ (memberships/roles)। ਮਲਟੀ-ਟੈਨੈਂਟ ਉਤਪਾਦਾਂ ਲਈ, ਇੱਕ tenant/organization ਐਂਟਿਟੀ ਪੇਸ਼ ਕਰੋ ਅਤੇ tenant_id ਨੂੰ ਉਹਨਾਂ ਸਾਰਿਆਂ ਚੀਜ਼ਾਂ ਨਾਲ ਜੋੜੋ ਜਿਨ੍ਹਾਂ ਨੂੰ ਅਲੱਗ ਰੱਖਣ ਦੀ ਲੋੜ ਹੈ।
ਇਸ ਤੋਂ ਇਲਾਵਾ, ਦਰਸ਼ਾਓ ਕਿ ਅਨੁਮਤੀਆਂ ਨੂੰ ਕਿਵੇਂ ਨਿਭਾਇਆ ਜਾਵੇਗਾ: ਰੋਲ ਦੁਆਰਾ (admin/member/viewer), ਮਲਿਕੀਅਤ ਦੁਆਰਾ, ਜਾਂ ਦੋਹਾਂ ਦੁਆਰਾ।
ਆਖ਼ਰਕਾਰ, ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੀ ਲੋਗ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਕੀ ਮਿਟਾਇਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਉਦਾਹਰਨ:
ਇਹ ਚੋਣਾਂ ਕੰਪਲਾਇੰਸ, ਸਹਾਇਤਾ, ਜਾਂ ਬਿਲਿੰਗ ਦੇ ਸਵਾਲ ਆਉਣ ’ਤੇ ਅਣਪ੍ਰਸੰਦਿਤ ਹੈਰਾਨੀ ਤੋਂ ਬਚਾਉਂਦੀਆਂ ਹਨ।
ਬੈਕਐਂਡ APIs ਉਹਨਾਂ ਜਗ੍ਹਾਂ ਹਨ ਜਿੱਥੇ ਤੁਹਾਡੇ ਐਪ ਦੇ ਵਾਅਦੇ ਅਸਲ ਕਾਰਵਾਈਆਂ ਬਣਦੇ ਹਨ: "ਮੇਰੀ ਪ੍ਰੋਫਾਈਲ ਸੇਵ ਕਰੋ","ਮੇਰੇ ਆਰਡਰ ਦਿਖਾਓ","ਲਿਸਟਿੰਗਸ ਖੋਜੋ"। ਇੱਕ ਵਧੀਆ ਆਉਟਪੁਟ ਉਪਭੋਗਤਾ ਕਾਰਵਾਈਆਂ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਛੋਟੀ, ਸਪਸ਼ਟ ਐਂਡਪੋਇੰਟਸ ਦੀ ਸੈਟ ਵਿੱਚ ਬਦਲਦਾ ਹੈ।
ਮੁੱਖ ਚੀਜ਼ਾਂ ਦੀ ਸੂਚੀ ਬਣਾਓ ਜਿਨ੍ਹਾਂ ਨਾਲ ਉਪਭੋਗਤਾ ਇੰਟਰੈਕਟ ਕਰਦੇ ਹਨ (ਜਿਵੇਂ Projects, Tasks, Messages)। ਹਰ ਇਕ ਲਈ ਵੱਖਰਾ ਦੱਸੋ ਕਿ ਉਪਭੋਗਤਾ ਕੀ ਕਰ ਸਕਦੇ ਹਨ:
ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਐਂਡਪੋਇੰਟਸ ਨੂੰ ਮੇਪ ਕਰਦਾ ਹੈ ਜਿਵੇਂ:
POST /api/v1/tasks (create)GET /api/v1/tasks?status=open&q=invoice (list/search)GET /api/v1/tasks/{taskId} (read)PATCH /api/v1/tasks/{taskId} (update)DELETE /api/v1/tasks/{taskId} (delete)Create a task: user submits title and due date.
POST /api/v1/tasks
{
"title": "Send invoice",
"dueDate": "2026-01-15"
}
Response returns the saved record (including server-generated fields):
201 Created
{
"id": "tsk_123",
"title": "Send invoice",
"dueDate": "2026-01-15",
"status": "open",
"createdAt": "2025-12-26T10:00:00Z"
}
(ਨੋਟ: ਉਪਰੋਕਤ ਕੋਡ ਫ਼ਰਮੇਟ ਨੂੰ ਬਦਲਨ ਤੋਂ ਬਚਾਓ—ਕੋਡ ਬਲਾਕ ਅਕੇਲਾ ਰਹੇ।)
ਮਾਡਲ ਇੱਕਸਾਰ ਤਰੁੱਟੀਆਂ ਪੈਦਾ ਕਰੇ:
ਰੀਟ੍ਰਾਈਜ਼ ਲਈ, POST ਉੱਤੇ idempotency keys ਦੀ ਪ੍ਰਸ਼ੰਸਾ ਕਰੋ ਅਤੇ ਸਪਸ਼ਟ ਨਿਰਦੇਸ਼ ਦਿਓ ਜਿਵੇਂ "retry after 5 seconds."
ਮੋਬਾਈਲ ਕਲਾਇੰਟ ਧੀਰੇ-ਧੀਰੇ ਅੱਪਡੇਟ ਹੁੰਦੇ ਹਨ। ਵਰਜ਼ਨਡ ਬੇਸ ਪਾਥ (/api/v1/...) ਵਰਤੋ ਅਤੇ ਟੁੱਟਣ ਵਾਲੇ ਬਦਲਾਅ ਤੋਂ ਬਚੋ:
GET /api/version)ਸੁਰੱਖਿਆ "ਬਾਅਦ" ਦਾ ਕੰਮ ਨਹੀਂ ਹੈ। ਜਦੋਂ ਇੱਕ LLM ਤੁਹਾਡੇ ਵਿਚਾਰ ਨੂੰ ਐਪ ਵਿਸ਼ੇਸ਼ਤਾਂ ਵਿੱਚ ਬਦਲਦਾ ਹੈ, ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਸੁਰੱਖਿਅਤ ਡਿਫਾਲਟ ਸਪਸ਼ਟ ਹੋਣ—ਤਾਂ ਜੋ ਪਹਿਲੀ ਜਨਰੇਟ ਕੀਤੀ ਸੰਸਕਰਣ ਗਲਤੀ ਨਾਲ ਖੁਲੀ ਨਾ ਰਹਿ ਜਾਵੇ।
ਮਾਡਲ ਨੂੰ ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਲੋਗਿਨ ਵਿਧੀ ਅਤੇ ਇੱਕ ਫੈਲਬੈਕ ਸੁਝਾਓ, ਨਾਲ ਹੀ ਇਹ ਵੀ ਦੱਸੋ ਕਿ ਗਲਤ ਹੋਣ 'ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ (ਖੋਇਆ ਐਕਸੈਸ, ਸ਼ੱਕਸਪਦ ਲੌਗਿਨ ਆਦਿ)। ਆਮ ਚੋਣਾਂ ਵਿੱਚ ਸ਼ਾਮਿਲ ਹਨ:
ਇਸ ਨੂੰ session handling (ਛੋਟੇ-ਅੰਤਰ ਵਾਲੇ access tokens, refresh tokens, device logout) ਅਤੇ ਕੀ ਤੁਸੀਂ multi-factor authentication ਸਹਿਯੋਗ ਕਰਦੇ ਹੋ—ਇਹ ਸਪਸ਼ਟ ਕਰਨ ਲਈ ਕਹੋ।
Authentication ਯੂਜ਼ਰ ਦੀ ਪਹਚਾਣ ਕਰਦਾ ਹੈ; authorization ਪਹੁੰਚ ਸੀਮਿਤ ਕਰਦਾ ਹੈ। ਮਾਡਲ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਪੈਟਰਨ ਚੁਣਨ ਲਈ ਉਤਸਾਹਤ ਕਰੋ:
project:edit, invoice:export) ਲਚਕੀਲੇ ਉਤਪਾਦਾਂ ਲਈਇੱਕ ਚੰਗਾ ਆਉਟਪੁਟ ਨਮੂਨਾ ਨਿਯਮਾਂ ਨੂੰ ਸ਼ਾਮਿਲ ਕਰੇਗਾ ਜਿਵੇਂ: “Only project owners can delete a project; collaborators can edit; viewers can comment.”
ਮਾਡਲ ਨੂੰ ਜਨਰਲ ਵਾਅਦਾਂ ਦੀ ਥਾਂ ਨਿਰਧਾਰਤ ਸੁਰੱਖਿਆ ਉਪਾਇ ਲਿਖਵਾਓ:
ਇੱਕ ਬੇਸਲਾਈਨ ਥਰੈਟ ਚੈਕਲਿਸਟ ਮੰਗੋ: CSRF/XSS ਸੁਰੱਖਿਆ, secure cookies, ਅਤੇ ਸੇਫ਼ ਫਾਈਲ ਅਪਲੋਡ ਹੱਲ ਜੇ ਲੋੜ ਹੋਵੇ।
ਡਿਫਾਲਟ ਵਜੋਂ ਸਭ ਤੋਂ ਘੱਟ ਡਾਟਾ ਇਕੱਤਰ ਕਰੋ: ਸਿਰਫ਼ ਉਹ ਜੋ ਫੀਚਰ ਲਈ ਵਰਤੀਦਾ ਹੈ, ਘੱਟ ਤੋਂ ਘੱਟ ਸਮੇਂ ਲਈ।
ਮਾਡਲ ਨੂੰ ਨਿਮਨਲਿਖਤ ਸਾਧਾਰਣ-ਭਾਸ਼ਾਈ ਕਾਪੀ ਡ੍ਰਾਫਟ ਕਰਨ ਲਈ ਕਹੋ:
ਜੇ ਤੁਸੀਂ ਐਨਲਿਟਿਕਸ ਸ਼ਾਮਿਲ ਕਰਦੇ ਹੋ, ਤਾਂ opt-out (ਜਾਂ ਜਿੱਥੇ ਲਾਜ਼ਮੀ ਹੋਵੈ opt-in) ਅਤੇ ਇਸਨੂੰ ਸੈਟਿੰਗਜ਼ ਅਤੇ ਨੀਤੀ ਪੰਨਿਆਂ 'ਤੇ ਸਪਸ਼ਟ ਦਸਤਾਵੇਜ਼ ਕਰੋ।
ਇੱਕ ਵਧੀਆ LLM ਤੁਹਾਡੇ ਰਿਕਵਾਇਰਮੈਂਟਸ ਨੂੰ ਐਸਾ ਟੈਸਟ ਪਲਾਨ ਵਿੱਚ ਬਦਲ ਸਕਦਾ ਹੈ ਜੋ ਬਹੁਤ ਉਪਯੋਗੀ ਹੁੰਦਾ ਹੈ—ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ acceptance criteria ਨਾਲ ਜੋੜ ਕੇ ਮੰਗੋ।
ਮਾਡਲ ਨੂੰ ਆਪਣੀ ਫੀਚਰ ਲਿਸਟ ਅਤੇ acceptance criteria ਦਿਓ, ਫਿਰ ਕਹੋ ਕਿ ਹਰ ਮਾਪਦੰਡ ਲਈ ਟੈਸਟ ਜਨਰੇਟ ਕਰੇ। ਇੱਕ ਮਜ਼ਬੂਤ ਆਉਟਪੁਟ ਵਿੱਚ ਸ਼ਾਮਿਲ ਹੋਣਾ ਚਾਹੀਦਾ:
ਜੇ ਕੋਈ ਟੈਸਟ ਕਿਸੇ ਨਿਰਪੇਖ ਮਾਪਦੰਡ ਨਾਲ ਨਹੀਂ ਜੁੜਦਾ, ਤਾਂ ਉਹ ਸੰਭਵਤ: ਬੇਕਾਰ ਹੈ।
LLM ਫਿਕਸਚਰ ਵੀ ਸੁਝਾ ਸਕਦਾ ਹੈ ਜੋ ਲੋਕ ਅਸਲ ਵਿੱਚ ਐਪ ਨੂੰ ਜਿਵੇਂ ਵਰਤਦੇ ਹਨ ਉਸਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ: ਗੰਦੇ/ਵੱਖਰੇ ਨਾਮ, ਮਿਸਿੰਗ ਫੀਲਡ, ਟਾਈਮਜ਼ੋਨ, ਲੰਮਾ ਟੈਕਸਟ, ਅਤੇ "ਲਗਭਗ-ਡੁਪਲਿਕੇਟ" ਰਿਕਾਰਡ।
ਮੰਗੋ:
ਮਾਡਲ ਨੂੰ ਇੱਕ ਸਮਰਪਿਤ ਮੋਬਾਈਲ ਚੈੱਕਲਿਸਟ ਸ਼ਾਮਿਲ ਕਰਨ ਲਈ کہیں:
LLM ਟੇਸਟ ਸਕੈਲਿਟਨ ਤੇਜ਼ੀ ਨਾਲ ਲਿਖਣ ਵਿੱਚ ਕੁਸ਼ਲ ਹਨ, ਪਰ ਤੁਹਾਨੂੰ ਸਮੀਖਿਆ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ:
ਮਾਡਲ ਨੂੰ ਤੇਜ਼ ਟੈਸਟ ਲੇਖਕ ਸਮਝੋ, ਆਖ਼ਰੀ QA ਨਹੀਂ।
ਮਾਡਲ ਬਹੁਤ ਸਾਰਾ ਕੋਡ ਜਨਰੇਟ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਲਾਭ ਤਦ ਹੀ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇਹ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਸ਼ਿਪ ਕੀਤਾ ਜਾਵੇ ਅਤੇ ਤੁਸੀਂ ਲਾਂਚ ਦੇ ਬਾਅਦ ਦੇਖ ਸਕੋ ਕਿ ਕੀ ਹੋ ਰਿਹਾ ਹੈ। ਇਹ ਕਦਮ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਯੋਗ ਰੀਲੀਜ਼ਜ਼ ਬਾਰੇ ਹੈ: ਹਰ ਵਾਰੀ ਇੱਕੋ ਜਿਹੇ ਕਦਮ, ਘੱਟ ਤੋਂ ਘੱਟ ਅਚਾਨਕੀਕੇ ਨਾਲ।
ਹਰ ਪਲ-ਰਿਕਵੇਸਟ ਅਤੇ main ਸ਼ਾਖਾ 'ਤੇ merge ਹੋਣ 'ਤੇ ਇੱਕ ਸਧਾਰਨ CI ਪਾਈਪਲਾਈਨ ਸੈਟਅਪ ਕਰੋ:
ਭਾਵੇਂ ਮਾਡਲ ਨੇ ਕੋਡ ਲਿਖਿਆ ਹੋਵੇ, CI ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਕੋਈ ਬਦਲਾਅ ਅਜੇ ਵੀ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਕਿ ਨਹੀਂ।
ਤਿੰਨ ਮੁਹੌਲ ਪਕ ਕਰੋ:
ਕਨਫਿਗਰੇਸ਼ਨ ENV-vars ਅਤੇ secrets ਦੁਆਰਾ ਸੰਭਾਲੋ (ਕੋਡ-ਅੰਦਰ ਨਾ ਰੱਖੋ)। ਇੱਕ ਚੰਗੀ ਨਿਯਮ: ਜੇ ਕਿਸੇ ਵੈਲਯੂ ਨੂੰ ਬਦਲਣ ਲਈ ਕੋਡ ਬਦਲਣਾ ਪੈਂਦਾ, ਤਾਂ ਸਮਝੋ ਕਿ ਉਹ ਗਲਤ ਢੰਗ ਨਾਲ ਕਨਫਿਗਰ ਕੀਤਾ ਗਿਆ ਹੈ।
ਇੱਕ ਟਿਪੀਕਲ ਫੁੱਲ-ਸਟੈਕ ਐਪ ਲਈ:
ਤਿੰਨ ਸਿਗਨਲ ਲਈ ਯੋਜਨਾ ਬਣਾਓ:
ਇੱਥੇ AI-ਸਹਾਇਤ ਵਿਕਾਸ ਓਪਰੇਸ਼ਨਲ ਬਣਦਾ ਹੈ: ਤੁਸੀਂ ਸਿਮੂਲਟੇਨਿਆਸਲੀ ਕੋਡ ਜਨਰੇਟ ਹੀ ਨਹੀਂ ਕਰ ਰਹੇ—ਤੁਸੀਂ ਇੱਕ ਉਤਪਾਦ ਚਲਾ ਰਹੇ ਹੋ।
LLM ਇਕ ਅਸਪਸ਼ਟ ਵਿਚਾਰ ਨੂੰ ਕਿਸੇ ਚੀਜ਼ ਵਿੱਚ ਬਦਲ ਸਕਦਾ ਹੈ ਜੋ "ਪੂਰਾ ਯੋਜਨਾ" ਵਰਗਾ ਲੱਗਦਾ ਹੈ—ਪਰ ਸੂਤਰੀ prose ਖਾਮੀਆਂ ਛੁਪਾ ਸਕਦਾ ਹੈ। ਸਭ ਤੋਂ ਆਮ ਨੁਕਸਾਨ ਪੇਸ਼ਗੋਈ ਯੋਗ ਹਨ, ਅਤੇ ਤੁਸੀਂ ਕੁਝ ਦੁਹਰਾਏ ਯਥਾਰਥ ਅਭਿਆਸਾਂ ਨਾਲ ਉਹਨਾਂ ਨੂੰ ਰੋਕ ਸਕਦੇ ਹੋ।
ਜਿਆਦਾਤਰ ਨਰਮ ਆਉਟਪੁੱਟ ਚਾਰ ਮੁੱਖ ਮੁੱਦਿਆਂ 'ਤੇ ਵਾਪਸ ਜਾਂਦੇ ਹਨ:
ਮਾਡਲ ਨੂੰ ਕੰਕ੍ਰਿਟ ਸਮੱਗਰੀ ਦਿਓ:
ਹਰ ਡਿਲਿਵਰੇਬਲ ਲਈ ਚੈਕਲਿਸਟ ਮੰਗੋ। ਉਦਾਹਰਨ ਲਈ, ਰਿਕਵਾਇਰਮੈਂਟਸ "ਡਨ" ਨਹੀਂ ਮੰਨੇ ਜਾਣੇ ਚਾਹੀਦੇ ਜਦ ਤੱਕ ਉਹ acceptance criteria, error states, roles/permissions, ਅਤੇ measurable success metrics ਨਾ ਸ਼ਾਮਿਲ ਕਰਦੇ ਹੋਣ।
LLM ਆਊਟਪੁੱਟ ਤਦੋਂ ਭਟਕਦੇ ਹਨ ਜਦੋਂ ਸਪੈਸ, API ਨੋਟਸ, ਅਤੇ UI ਵਿਚਾਰ ਵੱਖ-ਵੱਖ ਥਰੈਡਾਂ 'ਚ ਰਹਿ ਜਾਂਦੇ ਹਨ। ਇੱਕ ਜੀਵੰਤ ਦਸਤਾਵੇਜ਼ ਰੱਖੋ (ਸੀਧਾ markdown ਫ਼ਾਈਲ ਵੀ ਠੀਕ ਹੈ) ਜੋ:
ਜਦੋਂ ਤੁਸੀਂ ਫਿਰ ਪ੍ਰੌਂਪਟ ਕਰਦੇ ਹੋ, ਤਾਂ ਨਵੀਂ ਬਦਲੀ ਸ਼ੁਰੂ ਕਰਦਿਆਂ ਕਹੋ: “Update only sections X and Y; keep everything else unchanged.”
ਜੇ ਤੁਸੀਂ ਅਮਲ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇੱਕ ਵਰਕਫਲੋ ਵਰਤੋ ਜੋ ਤੇਜ਼ iteration ਸਹਾਇਕ ਹੋ ਬਿਨਾਂ ਟਰੇਸਬਿਲਿਟੀ ਖੋਣ ਦੇ। ਉਦਾਹਰਨ ਲਈ, Koder.ai ਦੀ "planning mode" ਇਹਨਾਂ ਨਾਲ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਫਿੱਟ ਹੁੰਦੀ ਹੈ: ਤੁਸੀਂ spec (assumptions, open questions, acceptance criteria) ਨੂੰ ਲੌਕ ਕਰ ਸਕਦੇ ਹੋ, ਇੱਕ ਚੈਟ ਥ੍ਰੇਡ ਤੋਂ ਵੈੱਬ/ਮੋਬਾਈਲ/ਬੈਕਐਂਡ scaffolding ਜਨਰੇਟ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ snapshots/rollback ਉਪਰ ਨਿਰਭਰ ਕਰ ਸਕਦੇ ਹੋ ਜੇ ਕੋਈ ਬਦਲਾਅ regressions ਲਿਆਏ। ਸਰੋਤ ਕੋਡ ਐਕਸਪੋਰਟ ਖਾਸ ਤੌਰ 'ਤੇ ਉਪਯੋਗੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਤੁਹਾਡੀ ਜਨਰੇਟ ਕੀਤੀ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਤੁਹਾਡਾ ਰੇਪੋ ਏਲਾਈਨ ਰਹੇ।
ਇਹ ਹੈ ਕਿ "LLM ਅਨੁਵਾਦ" ਆਖ਼ਿਰਕਾਰ ਕਿਸ ਤਰ੍ਹਾਂ ਦਿੱਸ ਸਕਦਾ ਹੈ—ਨਾਲ ਹੀ ਉਹ ਚੈਕਪੋਇੰਟ ਜਿੱਥੇ ਮਨੁੱਖ ਨੂੰ ਰੁਕ ਕੇ ਅਸਲ ਫੈਸਲੇ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ।
ਸਧਾਰਣ-ਅੰਗਰੇਜ਼ੀ ਵਿਚਾਰ: “A pet-sitting marketplace where owners post requests, sitters apply, and payments are released after the job.”
ਇੱਕ LLM ਇਸਨੂੰ ਪਹਿਲੇ ਡਰਾਫਟ ਵਿੱਚ ਬਦਲ ਸਕਦਾ ਹੈ:
POST /requests, GET /requests/{id}, POST /requests/{id}/apply, GET /requests/{id}/applications, POST /messages, POST /checkout/session, POST /jobs/{id}/complete, POST /reviews.ਇਹ ਉਪਯੋਗੀ ਹੈ—ਪਰ ਇਹ "ਡਨ" ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਸੰਰਚਿਤ ਪ੍ਰਸਤਾਵ ਹੈ ਜਿਸਦੀ ਪੁਸ਼ਟੀ ਲੋੜੀਂਦੀ ਹੈ।
Product decisions: "application" ਨੂੰ ਕਦੋਂ ਵੈਧ ਮੰਨਿਆ ਜਾਵੇ? ਇੱਕ ਮਾਲਕ ਕਿਹੜੇ ਤਰੀਕੇ ਨਾਲ ਸਿੱਟਰ ਨੂੰ ਸਿੱਧਾ ਬੁਲਾਉ ਸਕਦਾ ਹੈ? ਇੱਕ ਰਿਕਵੇਸਟ ਕਦੋਂ "filled" ਮੰਨੀ ਜਾਵੇ? ਇਹ ਨਿਯਮ ਹਰ ਸਕਰੀਨ ਅਤੇ API ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ।
Security & privacy review: ਰੋਲ-ਅਧਾਰਤ ਪਹੁੰਚ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ (ਮਾਲਕ ਦੂਜੇ ਮਾਲਕਾਂ ਦੀ ਚੈਟ ਨਹੀਂ ਪੜ੍ਹ ਸਕਦੇ), ਭੁਗਤਾਨਾਂ ਦੀ ਰੱਖਿਆ ਕਰੋ, ਅਤੇ ਡਾਟਾ ਰਿਟੈਨਸ਼ਨ ਨਿਰਧਾਰਤ ਕਰੋ (ਉਦਾਹਰਨ: chats X ਮਹੀਨੇ ਬਾਅਦ ਡਿਲੀਟ)। ਦੁਰਵਿਵਹਾਰ ਨਿਯੰਤਰਣ ਜੋੜੋ: rate limits, spam ਰੋਕਥਾਮ, ਆਡਿਟ ਲੌਗ।
Performance tradeoffs: ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੀ ਚੀਜ਼ ਤੇਜ਼ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ (search/filter requests, chat). ਇਹ caching, pagination, indexing, ਅਤੇ background jobs ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ।
ਪਾਇਲਟ ਮਗਰੋਂ, ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ "repeat a request" ਜਾਂ "cancel with partial refund." ਇਸਨੂੰ updated requirements ਵਜੋਂ ਫੀਡ ਕਰੋ, ਪ੍ਰਭਾਵਿਤ ਫਲੋਜ਼/ਕੋਡ ਨੂੰ ਦੁਬਾਰਾ ਜਨਰੇਟ ਜਾਂ ਪੈਚ ਕਰੋ, ਫਿਰ ਟੈਸਟ ਅਤੇ ਸੁਰੱਖਿਆ ਚੈੱਕ ਦੁਬਾਰਾ ਚਲਾਓ।
"ਕਿਉਂ" ਨੂੰ ਦਸਤਾਵੇਜ਼ ਕਰੋ, ਸਿਰਫ਼ "ਕੀ" ਨਹੀਂ: ਮੁੱਖ ਕਾਰੋਬਾਰੀ ਨਿਯਮ, ਪਰਮੀਸ਼ਨ ਮੈਟ੍ਰਿਕਸ, API contracts, error codes, ਡਾਟਾਬੇਸ ਮਾਈਗ੍ਰੇਸ਼ਨ, ਅਤੇ ਰੀਲੀਜ਼/Incident response ਦਾ ਛੋਟਾ ਰਨਬੁੱਕ। ਇਹ ਉਹ ਹੈ ਜੋ 6 ਮਹੀਨੇ ਬਾਅਦ ਜਨਰੇਟ ਕੀਤਾ ਕੋਡ ਸਮਝਣਯੋਗ ਰੱਖਦਾ ਹੈ।
ਇਸ ਸੰਦਰਭ ਵਿੱਚ, “ਅਨੁਵਾਦ” ਦਾ ਮਤਲਬ ਹੈ ਇੱਕ ਧੁੰਦਲਾ ਖ਼ਿਆਲ ਨੂੰ ਨਿਰਧਾਰਤ, ਜਾਂਚਯੋਗ ਫੈਸਲਿਆਂ ਵਿੱਚ ਬਦਲਨਾ: ਰੋਲ, ਯਾਤਰਾਵਾਂ, ਰਿਕਵਾਇਰਮੈਂਟਸ, ਡਾਟਾ, API ਅਤੇ ਸਫਲਤਾ ਮਾਪਦੰਡ।
ਇਹ ਸਿਰਫ਼ ਫਿਰ ਤੋਂ ਲਿਖਣਾ ਨਹੀਂ—ਇਹ ਉਹ ਧਾਰਣਾਵਾਂ ਸਪਸ਼ਟ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ ਬਿਲਡ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਹਨਾਂ ਦੀ ਪੁਸ਼ਟੀ ਜਾਂ ਰੱਦ ਕਰ ਸਕੋ।
ਪ੍ਰਯੋਗਕ ਲਾਗੂ ਪਹਿਲਾ ਡਰਾਫਟ ਸ਼ਾਮِل ਹੋ ਸਕਦਾ ਹੈ:
ਇਸ ਨੂੰ ਇੱਕ ਖ਼ਾਕਾ ਡਰਾਫਟ ਸਮਝੋ ਜਿਸ ਦੀ ਤੁਸੀਂ ਸਮੀਖਿਆ ਕਰਦੇ ਹੋ—ਇਹ ਅੰਤਿਮ ਵਿਸ਼ਲੇਸ਼ਣ ਨਹੀਂ।
ਕਿਉਂਕਿ LLM ਤੁਹਾਡੇ ਹਕੀਕਤੀ ਸੰਦਰਭ, ਸੀਮਾਵਾਂ ਅਤੇ ਤਰਜੀحات ਨੂੰ ਆਪਣੀ ਤਰਫੋਂ ਨਹੀਂ ਜਾਣਦਾ, ਅਜੇ ਵੀ ਮਨੁੱਖੀ ਫੈਸਲੇ ਲਾਜ਼ਮੀ ਹਨ। ਮਨੁੱਖੀ ਨੂੰ ਫੈਸਲੇ ਲੈਣੇ ਚਾਹੀਦੇ ਹਨ:
ਮਾਡਲ ਨੂੰ ਵਿਕਲਪ ਪੇਸ਼ ਕਰਨ ਲਈ ਵਰਤੋਂ, ਫਿਰ ਮਨੁੱਖੀ ਦੇਖ-ਭਾਲ ਨਾਲ ਚੁਣੋ।
ਇਸਨੂੰ ਵਰਤਣ ਯੋਗ ਬਣਾਉਣ ਲਈ ਮਾਡਲ ਨੂੰ ਦੱਸਣਯੋਗ ਪ੍ਰੋਡਕਟ ਬ੍ਰੀਫ ਦੇਵੋ:
ਜੇ ਤੁਸੀਂ ਇਹ ਆਪਣੇ ਸਮਕਾਕਰ ਨੂੰ ਦੇ ਸਕਦੇ ਹੋ ਅਤੇ ਉਹ ਉਹੀ ਸਮਝਦੇ ਹਨ, ਤਾਂ ਬ੍ਰੀਫ ਕਾਫ਼ੀ ਹੈ।
ਲਕਰਾਂ ਵਾਲੀਆਂ ਖ਼ਾਸੀਅਤਾਂ ਵਿੱਚ ਟਰਨ ਕਰੋ:
ਇਹ ਤੁਹਾਡੀ UI, API ਅਤੇ ਟੈਸਟਾਂ ਲਈ "ਸੋਰਸ ਆਫ਼ ਟਰੂਥ" ਬਣ ਜਾਂਦਾ ਹੈ।
ਛੇਤਰੀ ਯਾਤਰਾਵਾਂ ਅਤੇ ਸਕਰੀਨਾਂ ਦੇ ਨਕਸ਼ੇ ਲਈ ਮਾਡਲ ਨੂੰ ਦੋ ਚੀਜ਼ਾਂ ਮੰਗੋ:
ਫਿਰ ਪੱਕਾ ਕਰੋ:
ਅੱਧਿਕਾਂਸ਼ ਨਵੇਂ ਉਤਪਾਦਾਂ ਲਈ ਮੁੱਖ ਸ਼ੁਰੂਆਤ: ਮੋਨੋਲਿਥ ਜਾਂ ਮੋਡਯੂਲਰ ਮੋਨੋਲਿਥ।
ਜੇ ਮਾਡਲ ਤੁਰੰਤ "ਮਾਇਕਰੋਸਰਵਿਸਿਜ਼" ਸੁਝਾਏ, ਤਾਂ ਉਸ ਤੋਂ ਵਾਜਿਬ ਕਾਰਨ ਮੰਗੋ (ਟ੍ਰੈਫਿਕ, ਅਲੱਗ ਡਿਪਲੋਈੰਗ ਦੀ ਲੋੜ, ਵਗੈਰਾ)। v1 ਲਈ ਛੋਟੇ "escape hatches" ਪ੍ਰਾਥਮਿਕਤ ਦਿੱਤੀ ਜਾਏ:
v1 ਨੂੰ ਅਸਾਨ ਬਣਾਓ ਅਤੇ ਜ਼ਰੂਰੀ ਤੌਰ ਤੇ ਡਿਬੱਗ ਕਰਨ ਯੋਗ ਰੱਖੋ।
ਮਾਡਲ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਲਿਖਵਾਉ:
ਇਹ ਫੈਸਲੇ UI ਫਿਲਟਰ, ਨੋਟੀਫਿਕੇਸ਼ਨ, ਰਿਪੋਰਟਿੰਗ ਅਤੇ ਸੁਰੱਖਿਆ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਉਂਦੇ ਹਨ।
ਇਹਨਾਂ ਗੁਣਾਂ ਦੀ ਮੰਗ ਕਰੋ:
/api/v1/...)POST ਲਈ idempotency keysਟੁੱਟੀ ਚੀਜ਼ਾਂ ਤੋਂ ਬਚਣ ਲਈ ਨਵੇਂ ਫੀਲਡ ਓਪਸ਼ਨਲ ਰੱਖੋ ਅਤੇ ਡੀਪ੍ਰਿਕੇਸ਼ਨ ਵਿੰਡੋ ਦਿਓ।
ਮਾਡਲ ਤੋਂ ਪ੍ਰਾਪਤ ਯੋਜਨਾ ਬਣਾਓ, ਪਰ ਉਸ ਨੂੰ acceptance criteria ਨਾਲ ਜੀਵੰਤ ਜੋੜੋ:
ਅਸਲੀ ਫਿਕਸਚਰ: ਸਮਾਂ ਖੇਤਰ, ਲੰਬਾ ਟੈਕਸਟ, ਨੇੜੇ-ਨਿਕਟ ਡੁਪਲਿਕੇਟ ਅਤੇ ਫਲੇਕੀ ਨੈੱਟਵਰਕ ਨੂੰ ਸ਼ਾਮਿਲ ਕਰੋ। ਜਨਰੇਟ ਕੀਤਾ ਟੈਸਟ ਆਰੰਭਿਕ ਨੁਕਤਾ ਹਨ—ਅੰਤਮ QA ਨਹੀਂ।
ਤੁਸੀਂ ਵਰਤਣ ਦੀ ਹੁਨਰ ਨਹੀਂ—ਪਰ ਵਿੱਕੀਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰ ਰਹੇ ਹੋ।