30 ਦਸੰ 2025·8 ਮਿੰਟ
Vibe Coding ਅਤੇ LLMs ਨਾਲ ਨਿੱਜੀ ਸਹਾਇਕ ਐਪ ਬਣਾਓ
vibe coding ਅਤੇ LLMs ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਨਿੱਜੀ सਹਾਇਕ ਐਪ ਡਿਜ਼ਾਈਨ, ਬਣਾਉਣ ਅਤੇ ਡਿਪਲੋਇਮੈਂਟ ਕਰਨ ਦੀ ਸਿੱਖਿਆ: UX, ਪ੍ਰੋੰਪਟ, ਟੂਲ, ਬੈਕਐਂਡ, ਪ੍ਰਾਈਵੇਸੀ, ਟੈਸਟਿੰਗ ਅਤੇ ਰੋਲਆਊਟ.
vibe coding ਅਤੇ LLMs ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਨਿੱਜੀ सਹਾਇਕ ਐਪ ਡਿਜ਼ਾਈਨ, ਬਣਾਉਣ ਅਤੇ ਡਿਪਲੋਇਮੈਂਟ ਕਰਨ ਦੀ ਸਿੱਖਿਆ: UX, ਪ੍ਰੋੰਪਟ, ਟੂਲ, ਬੈਕਐਂਡ, ਪ੍ਰਾਈਵੇਸੀ, ਟੈਸਟਿੰਗ ਅਤੇ ਰੋਲਆਊਟ.
"ਨਿੱਜੀ ਸਹਾਇਕ ਐਪ" ਦਾ ਮਤਲਬ ਕਈ ਚੀਜ਼ਾਂ ਹੋ ਸਕਦਾ ਹੈ: ਇੱਕ ਆਮ to-do ਲਿਸਟ ਤੋਂ ਲੈ ਕੇ ਕੈਲੇੰਡਰ ਟਕਰਾਅ ਨਿਪਟਾਉਂਦੀ ਅਤੇ ਈਮੇਲ ਡਰਾਫਟ ਕਰਦੀਆਂ ਟੂਲ ਤੱਕ। ਜੇ ਤੁਸੀਂ ਕੰਮ ਨੂੰ ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਪਰਿਭਾਸ਼ਿਤ ਨਹੀਂ ਕਰੋਗੇ, ਤਾਂ ਅੰਤੀਮ ਨਤੀਜਾ ਇੱਕ ਚਮਕਦਾਰ ਚੈਟ ਡੈਮੋ ਨਿਕਲ ਸਕਦਾ ਹੈ ਜੋ ਸੋਮਵਾਰ ਸਵੇਰੇ ਕਿਸੇ ਨੂੰ ਮਦਦ ਨਹੀਂ ਕਰੇਗਾ।
ਆਪਣਾ ਸ਼ੁਰੂਆਤ ਦਰਸ਼ਕ ਅਤੇ ਉਹਨਾਂ ਦੀ ਮੁੜ-ਆਉਣ ਵਾਲੀ ਦਰਦ ਦੀ ਪਰਿਭਾਸ਼ਾ ਕਰਨ ਨਾਲ ਕਰੋ। ਇੱਕ ਫਾਊਂਡਰ ਨੂੰ ਤੇਜ਼ ਮੀਟਿੰਗ ਤਿਆਰੀ ਅਤੇ ਫਾਲੋਅਪ ਚਾਹੀਦਾ ਹੋ ਸਕਦਾ ਹੈ; ਇੱਕ ਵਿਦਿਆਰਥੀ ਨੂੰ ਸਟਡੀ ਪਲਾਨ ਅਤੇ ਨੋਟ ਕੈਪਚਰ; ਇਕ ਓਪਰੇਸ਼ਨ ਮੈਨੇਜ਼ਰ ਨੂੰ ਕਾਰਜ ਟ੍ਰਾਇਜ ਅਤੇ ਦੈਨਿਕ ਸਥਿਤੀ ਸਾਰ. ਦਰਸ਼ਕ ਜਿੰਨਾ ਸਪਸ਼ਟ, ਉਤਨੀ ਆਸਾਨੀ ਨਾਲ ਤੁਸੀਂ ਨਿਰਣਾ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਸਹਾਇਕ ਨੂੰ ਕਿਹੜੇ ਟੂਲ ਚਾਹੀਦੇ ਹਨ—ਅਤੇ ਕਿਹੜੇ ਬਿਲਕੁਲ ਨਹੀਂ।
ਤੁਹਾਡੇ MVP ਨੂੰ ਇੱਕ ਛੋਟੀ ਸੈਸ਼ਨ ਵਿੱਚ ਉਪਯੋਗੀ ਨਤੀਜਾ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ ਪ੍ਰਾਇਕਟਿਕ ਨਿਯਮ ਇਹ ਹੈ ਕਿ ਯੂਜ਼ਰ ਐਪ ਖੋਲ੍ਹਨ ਤੋਂ 60–120 ਸਕਿੰਟ ਵਿੱਚ ਮੁੱਲ ਪ੍ਰਾਪਤ ਕਰੇ।
ਦੋ ਭਰੋਸੇਯੋਗ ਪਹਿਲੇ ਯਾਤਰਾਵਾਂ ਹਨ:
ਦੇਖੋ ਕਿ ਕੀ ਗੈਰ-ਮੌਜੂਦ ਹੈ: ਲੰਮਾ onboarding, ਜਟਿਲ ਸੈਟਿੰਗਜ਼, ਜਾਂ ਡੀਪ ਇਨਟੀਗ੍ਰੇਸ਼ਨ। ਤੁਸੀਂ "ਸਹਾਇਕ" ਅਨੁਭਵ ਨਕਲੀ ਤਰੀਕੇ ਨਾਲ ਦੇ ਸਕਦੇ ਹੋ—ਇੰਟਰਐਕਸ਼ਨ ਨੂੰ ਗੱਲਬਾਤੀ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੇ ਹੋਏ ਪਰ ਅੰਦਰਲੇ ਕਾਰਜਾਣਾ ਨਿਸ਼ਚਿਤ ਰੱਖ ਕੇ।
ਬਹੁਤ ਸਾਰੀਆਂ ਸਹਾਇਕ ਐਪਸ ਪਹਿਲੇ ਦਿਨ ਸਭ ਕੁਝ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਕੇ ਫੇਲ ਹੁੰਦੀਆਂ ਹਨ: ਵੌਇਸ, ਪੂਰੀ ਈਮੇਲ ਸਮਕਾਲੀਕਰਨ, ਕੈਲੇੰਡਰ ਲਿਖਣ ਦੀ ਪਹੁੰਚ, ਆਟੋਨੋਮਸ ਮਲਟੀ-ਸਟੈਪ ਕਾਰਵਾਈਆਂ, ਅਤੇ ਜਟਿਲ ਏਜੰਟ ਸੈਟਅੱਪ। MVP ਲਈ ਸਪਸ਼ਟ ਨਾਨ-ਗੋਲ ਬਣਾਓ—ਕੋਈ ਵੌਇਸ ਇਨਪੁੱਟ ਨਹੀਂ, ਕੋਈ ਦੋ-ਤਰਫ਼ਾ ਈਮੇਲ ਇਨਟੀਗ੍ਰੇਸ਼ਨ ਨਹੀਂ, ਕੋਈ ਬੈਕਗਰਾਊਂਡ ਆਟੋਨੋਮੀ, ਅਤੇ ਬੁਨਿਆਦੀ ਅਕਾਊਂਟਾਂ ਤੋਂ ਇਲਾਵਾ ਕੋਈ ਗਹਿਰਾ ਕ੍ਰਾਸ-ਡਿਵਾਈਸ ਸਿੰਕ ਨਹੀਂ। ਇਸ ਨਾਲ ਉਤਪਾਦ ਸੱਚਾ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਸੁਰੱਖਿਆ ਅਤੇ ਗੋਪਨੀਯਤਾ ਦਾ ਖਤਰਾ ਘੱਟ ਹੁੰਦਾ ਹੈ।
MVP ਨੂੰ "ਚੈਟਾਂ ਦੀ ਗਿਣਤੀ" ਨਾਲ ਮਾਪੋ ਨਾ। ਇਸਨੂੰ ਨਤੀਜਿਆਂ ਨਾਲ ਮਾਪੋ:
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਪਲੈਟਫਾਰਮ 'ਤੇ vibe-coding ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਸਪਸ਼ਟ ਯਾਤਰਾਵਾਂ ਅਤੇ ਮੈਟ੍ਰਿਕਸ ਬਣਾਉਣ ਨਾਲ ਬਿਲਡ ਗਤੀ ਹਕੀਕਤ ਬਣ ਜਾਂਦੀ ਹੈ: ਤੁਸੀਂ ਪਹਿਲੇ React/Flutter ਸਕ੍ਰੀਨਾਂ ਅਤੇ Go/PostgreSQL ਏਂਡਪਾਏਂਟ ਦੋ ਮੁੱਖ ਲੂਪਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਸਕੋਪ ਕਰ ਸਕਦੇ ਹੋ, ਫਿਰ snapshots ਅਤੇ rollback ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਦੁਬਾਰਾ ਸੁਧਾਰ ਕਰ ਸਕਦੇ ਹੋ।
ਨਿੱਜੀ ਸਹਾਇਕ ਐਪ ਦੀ ਕਾਮਯਾਬੀ ਇੰਟਰਐਕਸ਼ਨ ਦੇ ਅਨੁਭਵ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਯੂਜ਼ਰ ਨੂੰ ਇਹ ਮਹਿਸੂਸ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਐਪ ਇਰਾਦੇ ਨੂੰ ਸਮਝਦਾ ਹੈ, ਅਗਲਾ ਲਾਭਦਾਇਕ ਕਦਮ ਪੇਸ਼ ਕਰਦਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਉਹ ਸਿਰਫ਼ ਤੇਜ਼ ਜਵਾਬ ਚਾਹੁੰਦੇ ਹਨ ਤਾਂ ਰੁਕਾਵਟ ਨਹੀਂ ਪਾinda।
ਜ਼ਿਆਦਾਤਰ ਸਹਾਇਕ ਕੁਝ ਮੁੱਖ ਕੰਮਾਂ ਨੂੰ ਸਤਤ ਤਰੀਕੇ ਨਾਲ ਕਰਕੇ ਭਰੋਸਾ ਕਮਾ ਲੈਂਦੇ ਹਨ: ਬੇਨਤੀ ਨੂੰ ਸਮਝਣਾ, “ਮੈਮੋਰੀ” ਸਟੋਰ ਕਰਨਾ (ਪਸੰਦਾਂ ਅਤੇ ਹਲਕੀ-ਫਲਕੀ ਪ੍ਰੋਫ਼ਾਈਲ ਤੱਥ), ਟਾਸਕ ਅਤੇ ਰਿਮਾਈਂਡਰ ਮੈਨੇਜ ਕਰਨਾ, ਅਤੇ ਤੇਜ਼ ਸੰਖੇਪ ਬਣਾਉਣਾ (ਨੋਟ, ਮੀਟਿੰਗ ਜਾਂ ਲੰਮੇ ਸੁਨੇਹੇ)। ਪ੍ਰੋਡਕਟ ਡਿਜ਼ਾਇਨ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਇਹ ਸਮਰੱਥਾਵਾਂ ਵਾਯਕਤ ਰਹਿਣ ਅਤੇ ਐਪ ਨੂੰ ਇੱਕ ਭੂਤ-ਬਰਸ ਵਾਲੀ ਜਗ੍ਹਾ ਨਹੀਂ ਬਣਾ ਦਿੰਦੀਆਂ।
ਇੱਕ ਯੂਜ਼ਫੁਲ ਨਿਯਮ: ਹਰ ਸਹਾਇਕ ਸਮਰੱਥਾ ਲਈ ਦੋ ਰਾਹ ਹੋਣ ਚਾਹੀਦੇ ਹਨ (1) ਗੱਲਬਾਤੀ ਰਸਤਾ (ਉਦਾਹਰਨ: “ਮੈਨੂੰ ਕੱਲ 9 ਵਜੇ ਯਾਦ ਦਿਵਾਓ”) ਅਤੇ (2) ਇੱਕ ਦਿੱਖ ਵਾਲਾ UI ਜਿੱਥੇ ਵਰਖਣਾ ਅਤੇ ਸੋਧ ਕੀਤਾ ਜਾ ਸਕੇ (ਜਿਵੇਂ ਇੱਕ ਰਿਮਾਈਂਡਰ ਲਿਸਟ ਜਿਸਨੂੰ ਤੁਸੀਂ ਸਕੈਨ ਕਰ ਸਕੋ)।
ਚੈਟ-ਫ੍ਰਸਟ ਉਸ ਵੇਲੇ ਬਿਹਤਰ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਡਾ ਦਰਸ਼ਕ ਤੇਜ਼ੀ ਅਤੇ ਲਚਕ ਨੂੰ ਮਹੱਤਵ ਦਿੰਦਾ ਹੈ: ਇੱਕ composer, ਸੁਨੇਹਾ ਇਤਿਹਾਸ, ਅਤੇ ਕੁਝ ਸਮਾਰਟ ਸ਼ੌਰਟਕਟ.
UI-ਫ੍ਰਸਟ ਜਿਸ ਵਿੱਚ ਚੈਟ ਸਹਾਇਕ ਵਜੋਂ ਹੋਵੇ ਉਹ ਉਸ ਵੇਲੇ ਚੰਗਾ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਯੂਜ਼ਰ ਬਹੁਤ ਸਾਰੀਆਂ ਆਈਟਮਾਂ ਨੂੰ ਮੈਨੇਜ ਕਰਦੇ ਹਨ ਅਤੇ ਢਾਂਚੇ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਸ ਮਾਡਲ ਵਿੱਚ ਐਪ "Tasks" ਜਾਂ "Today" ਵਿਊ 'ਤੇ ਖੁਲਦਾ ਹੈ, ਅਤੇ ਚੈਟ ਬਦਲਾਅ ਲਈ ਸੰਦਰਭੀਕ ਸੰਦ ਹੁੰਦਾ ਹੈ (ਉਦਾਹਰਨ: “ਅੱਜ ਦੇ ਸਾਰੇ ਕੰਮ ਕੱਲ ਨੂੰ ਵਧਾ ਦਿਓ”)।
ਤੁਹਾਨੂੰ ਸਦਾ ਲਈ ਚੋਣ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ, ਪਰ ਸ਼ੁਰੂ ਵਿੱਚ ਇੱਕ ਡਿਫਾਲਟ ਹੋਮ ਸਕ੍ਰੀਨ ਅਤੇ ਮਨ-ਮਾਡਲ ਚੁਣੋ।
ਸਹਾਇਕ ਅਕਸਰ ਐਸੇ ਕਾਰਜ ਕਰਦੇ ਹਨ ਜੋ ਅਣਵਾਪਸੀ ਯੋਗ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ: ਨੋਟ ਮਿਟਾਉਣਾ, ਸੁਨੇਹਾ ਭੇਜਣਾ, ਕੁਝ ਕੈਂਸਲ ਕਰਨਾ, ਜਾਂ ਬਹੁਤ ਸਾਰੇ ਟਾਸਕ ਇੱਕ ਵਾਰੀ ਵਿੱਚ ਸੋਧਣਾ। ਇਹ ਕੰਮ ਜੋਖਮ ਵਾਲੇ ਮੰਨੋ। UX ਨੂੰ ਇੱਕ ਸਪੱਸਟ ਪੁਸ਼ਟੀ ਕਦਮ ਦੇ ਨਾਲ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿੱਥੇ ਕੀ ਹੋਵੇਗਾ ਉਸਦੀ ਸਧੀ-ਭਾਸ਼ਾ ਵਿੱਚ ਸਾਰ, ਅਤੇ ਕੰਮ ਮਗਰੋਂ ਤੁਰੰਤ undo ਉਪਲੱਬਧ ਹੋਵੇ।
ਇੱਕ ਮਜ਼ਬੂਤ ਪੈਟਰਨ ਹੈ: preview → confirm → execute → undo. preview ਉਸ ਸਥਾਨ ਹੈ ਜਿੱਥੇ ਯੂਜ਼ਰ ਗਲਤੀਆਂ ਫੜ ਸਕਦੇ ਹਨ (“Alex ਨੂੰ ਭੇਜਣਾ?” “12 ਟਾਸਕ ਮਿਟਾਉਣੇ?”)।
ਪਹਿਲੇ ਵਰਜ਼ਨ ਨੂੰ ਛੋਟਾ ਅਤੇ ਸੁੰਗਤ ਰੱਖੋ। ਇੱਕ ਪ੍ਰਾਇਕਟਿਕ ਘੱਟੋ-ਘੱਟ ਸੈੱਟ:
ਜੇ ਤੁਸੀਂ vibe-coding ਕਰ ਰਹੇ ਹੋ (ਉਦਾਹਰਣ ਲਈ, Koder.ai), ਇਹ ਸਕ੍ਰੀਨਾਂ MVP ਨਾਲ ਸਾਫ਼-ਸੁਥਰੇ ਤਰੀਕੇ ਨਾਲ ਮੇਪ ਹੁੰਦੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਜਨਰੇਟ ਕਰਕੇ ਉਹ ਅਸਲ ਫਲੋਜ਼ ਜਿਵੇਂ “ਟਾਸਕ ਕੈਪਚਰ ਕਰੋ”, “ਰਿਮਾਈਂਡਰ ਸੈੱਟ ਕਰੋ”, ਅਤੇ “ਗਲਤੀ undo ਕਰੋ” ਟੈਸਟ ਕਰ ਸਕਦੇ ਹੋ।
ਇੱਕ ਚੰਗਾ ਸਹਾਇਕ ਸਥਿਰ, ਅਨੁਮਾਨਯੋਗ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ ਹੈ—ਜਿਆਦਾ ਇੱਕ ਮਦਦਗਾਰ ਸਹਿਕਰਮੀ ਵਰਗਾ ਬਜਾਏ ਇਕ ਬੇਤਰਤੀਬ ਪਾਠ ਜਨਰੇਟਰ। ਤੁਸੀਂ ਇਹ ਸਿਖਰ ਤੇ ਜਲਦੀ ਪਹੁੰਚ ਸਕਦੇ ਹੋ ਜੇ ਪ੍ਰੋੰਪਟਿੰਗ ਨੂੰ ਸਧਾਰਨ, ਪੜਤਾਲਯੋਗ ਅਤੇ ਪਰਤਦਾਰ ਰੱਖੋ।
ਆਪਣੇ ਪ੍ਰੋੰਪਟ ਨੂੰ ਤਿੰਨ ਲੇਅਰਾਂ ਵਾਂਗ ਸਮਝੋ, ਹਰ ਇੱਕ ਦਾ ਵੱਖਰਾ ਮਕਸਦ:
ਇਸ ਵੰਡ ਨਾਲ ਰੋਕਥਾਮ ਹੁੰਦੀ ਹੈ ਕਿ ਕੋਈ ਯੂਜ਼ਰ ਬੇਨਤੀ "ਪਿਛਲੇ ਹਦਾਇਤਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰੋ" ਨਾ ਕਰ ਸਕੇ ਅਤੇ ਅਣਜਾਣੇ ਤਰੀਕੇ ਨਾਲ ਸਹਾਇਕ ਦੇ ਮੁੱਖ ਨਿਯਮਾਂ ਨੂੰ ਠੱਲੇ।
ਤੁਹਾਡਾ ਸਹਾਇਕ ਜ਼ਿਆਦਾ ਭਰੋਸੇਯੋਗ ਹੋਵੇਗਾ ਜੇ ਉਹ ਪਤਾ ਰੱਖੇ ਕਿ ਕਦੋਂ ਕਾਰਵਾਈ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਕਦੋਂ ਪੁੱਛਣਾ ਚਾਹੀਦਾ ਹੈ। ਨਿਰਧਾਰਤ ਕਰੋ ਕਿਹੜੇ ਆਪਰੇਸ਼ਨ read-only ਹਨ (ਸੁਰੱਖਿਅਤ ਰੂਪ ਵਿੱਚ ਆਪੋ-ਆਪ ਕਰਨ ਲਈ, ਜਿਵੇਂ ਨੋਟ ਖੋਜ), ਕਿਹੜੇ write actions ਹਨ (ਟਾਸਕ ਬਣਾਉ/ਅੱਪਡੇਟ, ਰਿਮਾਈਂਡਰ ਸ਼ੈਡਿਊਲ), ਅਤੇ ਕਿਹੜੇ ਅਪਰਿਵਰਤੀਯ ਜਾਂ ਮਹਿੰਗੇ ਹਨ (ਡੇਟਾ ਮਿਟਾਉਣਾ, ਬਾਹਰੀ ਸੇਵਾਵਾਂ ਨਾਲ ਸੰਪਰਕ ਕਰਨਾ, ਜਾਣਕਾਰੀ ਸਾਂਝਾ ਕਰਨਾ)।
ਲਿਖਤ ਅਤੇ ਅਪਰਿਵਰਤੀਯ ਕਾਰਵਾਈਆਂ ਲਈ ਪੁਸ਼ਟੀ ਲਾਜ਼ਮੀ ਰੱਖੋ: ਮਾਡਲ ਇੱਕ ਕਾਰਵਾਈ ਯੋਜਨਾ ਪ੍ਰਸਤਾਵ ਕਰੇ, ਫਿਰ ਸਪੱਸ਼ਟ ਮਨਜ਼ੂਰੀ ਦੀ ਉਡੀਕ ਕਰੇ।
ਜਦੋਂ ਮਾਡਲ ਨੂੰ ਕਿਸੇ ਟਾਸਕ ਜਾਂ ਰਿਮਾਈਂਡਰ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੋਵੇ, ਸਧਾਰਨ ਪਾਠ ਨਾਜੁਕ ਹੁੰਦਾ ਹੈ। JSON "ਐਕਸ਼ਨ ਆਬਜੈਕਟ" ਵਰਤੋ ਅਤੇ ਅਮਲ ਤੋਂ ਪਹਿਲਾਂ ਉਹਨਾਂ ਦੀ ਵੈਧਤਾ ਕਰੋ। ਬੇਨਤੀ ਕੀਤੀਆਂ ਫੀਲਡਾਂ ਸ਼ਾਮਲ ਕਰੋ: action, title, due_at, priority, ਅਤੇ timezone, ਅਤੇ ਜਦੋਂ ਕੁਝ ਗੁੰਮਰਾਹ ਹੋਵੇ ਤਾਂ ਰੱਦ ਕਰੋ ਜਾਂ ਮੁੜ ਪੁੱਛੋ। ਇਹ ਤੁਹਾਡੇ ਬੈਕਐਂਡ ਨੂੰ ਨਿਰਧਾਰਤ ਰੱਖਦਾ ਹੈ ਭਾਵੇਂ ਮਾਡਲ ਦੀ ਭਾਸ਼ਾ ਵੱਖਰੀ ਹੋਵੇ।
Guardrails ਜਟਿਲ ਹੋਣ ਦੀ ਲੋੜ ਨਹੀਂ। ਸੰਵੇਦਨਸ਼ੀਲ ਬੇਨਤੀਆਂ (ਆਤਮ-ਹੱਤਿਆ, ਗੈਰਕਾਨੂੰਨੀ ਕਾਰਵਾਈ, ਨਿੱਜੀ ਡੇਟਾ ਪਹੁੰਚ) ਲਈ ਇੱਕ ਛੋਟੀ ਨੀਤੀ ਸ਼ਾਮਲ ਕਰੋ ਅਤੇ ਇਨਕਾਰ ਪੈਟਰਨ ਤਿਆਰ ਕਰੋ ਜੋ ਫਿਰ ਵੀ ਮਦਦਗਾਰ ਮਹਿਸੂਸ ਹੋਣ: ਮੰਨੋ, ਇਨਕਾਰ ਕਰੋ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਵਿਕਲਪ ਪੇਸ਼ ਕਰੋ। ਮਾਡਲ ਨੂੰ ਇਹ ਵੀ ਦੱਸੋ ਕਿ ਜਦੋਂ ਜਾਣਕਾਰੀ ਨਾ ਹੋਵੇ ਤਾਂ "ਮੈਨੂੰ ਪਤਾ ਨਹੀਂ" ਕਹਿਣ ਅਤੇ ਇੱਕ ਸਪੱਸ਼ਟ ਸਵਾਲ ਪੁੱਛਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੇ।
ਇੱਕ ਵੱਡੇ ਮਹਾਂ-ਪ੍ਰੋੰਪਟ ਦੀ ਥਾਂ, ਇੱਕ ਛੋਟੀ ਗਿਣਤੀ ਦੇ ਦੁਬਾਰਾ ਵਰਤੇ ਜਾਣ ਯੋਗ ਬਿਹੇਵਿਅਰ ਰੱਖੋ ਜੋ ਤੁਹਾਡਾ ਸਹਾਇਕ ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ "call" ਕਰ ਸਕੇ: ਸੰਕਲਪਨ ਤੋਂ ਕਾਰਵਾਈਆਂ ਬਣਾਉਣਾ, assumptions ਅਤੇ ਖੁੱਲ੍ਹੇ ਸਵਾਲਾਂ ਨਾਲ ਯੋਜਨਾ ਡਰਾਫਟ ਕਰਨਾ, ਬੇਨਤੀ ਨੂੰ ਘੱਟ-ਮਿਤੀ ਜਾਣਚਣਾ, ਸੁਨੇਹਾ ਇੱਕ ਖਾਸ ਟੋਨ ਵਿੱਚ ਦੁਬਾਰਾ ਲਿਕھਣਾ, ਅਤੇ ਟਾਸਕ/ਇਵੈਂਟਾਂ ਨੂੰ JSON ਵਿੱਚ ਕੱਢਣਾ। ਇਹ ਵਿਚਕਾਰ ਦਾ ਸਥਾਨ ਹੈ: ਨਿਰਧਾਰਤ ਵਿਹੇਵਿਅਰ, ਆਸਾਨ ਟੈਸਟਿੰਗ, ਅਤੇ ਪ੍ਰੋੰਪਟ ਜਟਿਲਤਾ ਤੋਂ ਬਚਾਅ।
ਇੱਕ ਨਿੱਜੀ ਸਹਾਇਕ "ਸਮਝਦਾਰ" ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ ਹੈ ਜਦੋਂ ਇਹ ਦੋ ਚੀਜ਼ਾਂ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕਰਦਾ ਹੈ: ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਗੱਲ ਕਰਨਾ ਅਤੇ ਭਰੋਸੇਯੋਗ ਕਾਰਵਾਈਆਂ ਕਰਨਾ। ਸਭ ਤੋਂ ਤੇਜ਼ ਰਾਹ ਇਹ ਹੈ ਕਿ ਗੱਲਬਾਤ (LLM reasoning) ਨੂੰ ਕਾਰਜਾਂ ਤੋਂ ਅਲੱਗ ਰੱਖੋ (ਟੂਲ ਜੋ ਤੁਹਾਡੇ ਸਿਸਟਮ ਨੂੰ ਕਾਲ ਕਰਦੇ ਹਨ)।
MVP ਲਈ, ਇੱਕ single LLM + tools ਪੈਟਰਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: ਇੱਕ ਮਾਡਲ ਯੂਜ਼ਰ ਸੁਨੇਹਾ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਫ਼ੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਟੈਕਸਟ ਵਿੱਚ ਜਵਾਬ ਦੇਵੇ ਜਾਂ ਕਿਸੇ ਟੂਲ ਨੂੰ ਕਾਲ ਕਰੇ, ਫਿਰ ਨਤੀਜਾ ਵਾਪਸ ਕਰਦਾ ਹੈ। ਇਹ ਡਿਬੱਗ ਕਰਨ ਲਈ ਸਧਾਰਨ ਹੈ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਟਾਸਕ ਕੈਪਚਰ, ਨੋਟ ਖੋਜ ਅਤੇ ਰਿਮਾਈਂਡਰ ਲਈ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ।
ਜਿਵੇਂ-ਜਿਵੇਂ ਸਮਰੱਥਾਵਾਂ ਵੱਧਦੀਆਂ ਹਨ, ਇੱਕ coordinator + specialist agents ਪੈਟਰਨ ਲਾਭਦਾਇਕ ਹੋ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਕੋਆਰਡੀਨੇਟਰ ਬੇਨਤੀ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ ਅਤੇ ਵਿਸ਼ੇਸ਼ਜ್ಞਾਂ ਨੂੰ ਸੌਂਪਦਾ ਹੈ (ਉਦਾਹਰਣ ਲਈ, Tasks agent बनाम Notes agent), ਹਰ ਇੱਕ ਨਿਰਦੇਸ਼ਤ ਹਦਾਇਤਾਂ ਅਤੇ ਘੱਟ ਟੂਲਾਂ ਦੇ ਨਾਲ। ਇਸ ਨਾਲ ਟੂਲ ਦੇ ਗਲਤ ਉਪਯੋਗ ਦੀ ਸੰਭਾਵਨਾ ਘੱਟ ਹੁੰਦੀ ਹੈ ਅਤੇ ਜਦੋਂ ਤੁਸੀਂ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਵਧਾਉਂਦੇ ਹੋ ਤਾਂ ਪੱਖਪਾਤੀ ਕਾਫ਼ੀ ਹੋ ਜਾਂਦੀ ਹੈ।
ਟੂਲ ਛੋਟੇ, ਨਿਰਧਾਰਤ APIs ਹਨ ਜੋ ਸਹਾਇਕ invoke ਕਰ ਸਕਦਾ ਹੈ। ਟੂਲ ਇਨਪੁੱਟ ਸਖ਼ਤ ਅਤੇ ਆਉਟਪੁੱਟ ਸੰਰਚਿਤ ਰੱਖੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਉਹਨਾਂ ਦੀ ਵੈਧਤਾ ਕਰ ਸਕੋ ਅਤੇ ਜੋ ਹੋਇਆ ਉਸਦਾ ਲਾਗ ਰੱਖ ਸਕੋ।
ਆਮ ਟੂਲਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ: task create/update/complete, note search (keyword + time filters), reminder scheduling (time, channel, recurrence), preference lookup (time zone, working hours), ਵਿਕਲਪਿਕ agenda reads (ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਕੈਲੇੰਡਰ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਹੈ), ਅਤੇ audit-event writes।
ਅਮਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਖਾਸ ਯੋਜਨਾ ਮੋਡ ਕੀਤੋ: ਮਾਡਲ ਇੱਕ ਛੋਟੀ ਯੋਜਨਾ ਲਿਖਦਾ ਹੈ, ਫਿਰ ਟੂਲ ਚੁਣਦਾ ਹੈ ਜੋ ਇਸ ਨੂੰ ਪੂਰਾ ਕਰਨਗੇ। ਯੋਜਨਾ ਮਲਟੀ-ਸਟੈਪ ਬੇਨਤੀਆਂ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ ਜਿਵੇਂ "ਮੇਰੇ ਪ੍ਰੋਜੈਕਟ ਟਾਸਕ ਅਗਲੇ ਹਫ਼ਤੇ ਵੱਲ਼ ਖਿਸਕਾਓ ਅਤੇ ਸੋਮਵਾਰ ਨੂੰ ਯਾਦ ਦਿਵਾਓ", ਜਿੱਥੇ ਸਹਾਇਕ ਨੂੰ ਧਿਆਨ ਚਾਹੀਦਾ ਹੈ ਕਿ assumptions (ਟਾਈਮਜ਼ੋਨ, "ਪ੍ਰੋਜੈਕਟ ਟਾਸਕ" ਦੀ ਪਰਿਭਾਸ਼ਾ) ਦੀ ਪੁਸ਼ਟੀ ਕੀਤੀ ਜਾਵੇ।
ਕੋਈ ਵੀ ਟੂਲ ਜੋ ਸਾਈਡ-ਐਫੈਕਟ ਕਰਦਾ ਹੈ (ਟਾਸਕ ਬਣਾਉਣਾ, ਰਿਮਾਈਂਡਰ ਭੇਜਣਾ, ਡੇਟਾ ਬਦਲਣਾ) ਨੂੰ ਇੱਕ action-approval ਗੇਟ ਤੋਂ ਲੰਘਣਾ ਚਾਹੀਦਾ ਹੈ। ਅਮਲ ਵਿੱਚ, ਮਾਡਲ ਇੱਕ ਕਾਰਵਾਈ ਡਰਾਫਟ ਪ੍ਰਸਤਾਵ ਕਰਦਾ ਹੈ (ਟੂਲ ਨਾਂ + ਪੈਰਾਮੀਟਰ + ਉਮੀਦ ਕੀਤੀ ਨਤੀਜਾ), ਅਤੇ ਤੁਹਾਡੀ ਐਪ ਯੂਜ਼ਰ ਤੋਂ ਪੁੱਛਦੀ ਹੈ ਕਿ ਉਹ ਮਨਜ਼ੂਰ ਕਰੇ ਜਾਂ ਸੋਧੇ। ਇਹ ਇੱਕ ਸਿੰਗਲ ਚੈਕਪੋਇੰਟ ਗੈਰ-ਇਰਾਦਾ ਬਦਲਾਅ ਨੂੰ ਘੱਟ ਕਰਦਾ ਹੈ ਅਤੇ ਸਹਾਇਕ ਨੂੰ ਭਰੋਸੇਯੋਗ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ vibe-coding ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ Koder.ai ਵਰਤਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇਸ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹੋ ਟੂਲ ਇੰਟਰਫੇਸ, ਕੋਆਰਡੀਨੇਟਰ ਲਾਜ਼ਿਕ, ਅਤੇ approval UI ਨੂੰ ਵੱਖ-ਵੱਖ, ਟੈਸਟਯੋਗ ਕੰਪੋਨੈਂਟਾਂ ਵਜੋਂ ਜਨਰੇਟ ਕਰਕੇ—ਫਿਰ snapshots ਅਤੇ rollback ਰਾਹੀਂ ਜਦੋਂ ਵਿਹੇਵਿਅਰ ਸੁਧਾਰ ਹੋਵੇ ਤਾਂ ਦੁਬਾਰਾ ਸੋਧੋ।
ਇੱਕ ਨਿੱਜੀ ਸਹਾਇਕ "ਸਮਾਰਟ" ਮਹਿਸੂਸ ਕਰਦਾ ਹੈ ਜਦੋਂ ਇਹ ਸਹੀ ਚੀਜ਼ਾਂ ਯਾਦ ਰੱਖਦਾ ਹੈ ਅਤੇ ਬਾਕੀ ਭੁੱਲ ਜਾਂਦਾ ਹੈ। ਚਾਲ ਇਹ ਹੈ ਕਿ ਮਾਡਲ ਦੇ coherence ਲਈ ਜੋ ਲੋੜੀਂਦਾ ਹੈ ਉਸ ਨੂੰ ਵੱਖਰਾ ਕਰੋ ਜੇਕਰ ਨਾ ਤਾਂ ਯਾਦ ਰੱਖਣਾ ਗੋਪਨੀਯਤਾ ਖਤਰਾ ਅਤੇ ਰੀਟਰੀਵਲ ਸ਼ੋਰ ਵਧਾ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਸਭ ਕੁਝ ਸਟੋਰ ਕਰ ਲਓਗੇ ਤਾਂ ਗੋਪਨੀਯਤਾ ਰਿਸਕ ਵਧੇਗਾ; ਜੇ ਤੁਸੀਂ ਕੁਝ ਵੀ ਸਟੋਰ ਨਹੀਂ ਕਰੋਗੇ ਤਾਂ ਸਹਾਇਕ ਦੁਹਰਾਵਾਂ ਅਤੇ ਭਾਰਪਾਈ ਹੋਵੇਗਾ।
ਹਾਲੀਆ ਗੱਲਬਾਤ ਨੂੰ ਛੋਟੀ-ਅਵਧੀ ਦੀ ਮੈਮੋਰੀ ਵਜੋਂ ਤਰਜੀਹ ਦਿਓ: ਪਿਛਲੇ ਕੁਝ turns ਦਾ rolling window ਅਤੇ ਮੌਜੂਦਾ ਯੂਜ਼ਰ ਲਕੜੀ। ਇਸਨੂੰ ਤੰਗ ਰੱਖੋ—ਜ਼ੋਰ ਨਾਲ ਸਾਰ ਕਰਦਿਆਂ—ਤਾਂ ਜੋ ਤੁਸੀਂ ਬੇਵਜਹ ਟੋਕਨ ਖਰਚ ਨਾ ਕਰੋ ਅਤੇ ਪਹਿਲੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਦੁਹਰਾਉਣ ਤੋਂ ਬਚੋ।
ਲੰਬੇ ਸਮੇਂ ਦੀ ਮੈਮੋਰੀ ਉਹਨਾਂ ਤੱਥਾਂ ਲਈ ਹੈ ਜੋ ਸੈਸ਼ਨਾਂ ਤੋਂ ਬਚਣੇ ਚਾਹੀਦੇ ਹਨ: ਪਸੰਦਾਂ, ਸਥਿਰ ਪ੍ਰੋਫ਼ਾਈਲ ਤੱਥ, ਟਾਸਕ, ਅਤੇ ਨੋਟ ਜੋ ਯੂਜ਼ਰ ਮੁੜ ਵੇਖਣਾ ਚਾਹੁੰਦਾ ਹੈ। ਪਹਿਲਾਂ ਇਹਨਾਂ ਨੂੰ ਸੰਰਚਿਤ ਡਾਟਾ ਵਜੋਂ ਸਟੋਰ ਕਰੋ (ਟੇਬਲ, ਫੀਲਡ, ਟਾਈਮਸਟੈਂਪ) ਅਤੇ ਕੇਵਲ ਉਹੀ ਫ੍ਰੀ-ਟੈਕਸਟ ਸਟੋਰ ਕਰੋ ਜਦੋਂ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਸੁਲਝਾਉਣਾ ਮੁਮਕਿਨ ਨਾ ਹੋਵੇ।
ਸਹਾਇਕ ਲਈ ਇੱਕ ਪ੍ਰਾਇਕਟਿਕ ਸ਼ੁਰੂਆਤ ਇਹ ਹੈ ਕਿ ਉਹ ਉਹ ਜਾਣਕਾਰੀ ਸੇਵ ਕਰੇ ਜੋ ਯੂਜ਼ਰ ਦੁਆਰਾ ਬਣਾਈ ਗਈ ਜਾਂ ਯੂਜ਼ਰ-ਮਨਜ਼ੂਰ ਹੋਵੇ: ਪ੍ਰੋਫ਼ਾਈਲ ਅਤੇ ਪਸੰਦਾਂ (ਟਾਈਮਜ਼ੋਨ, ਵਰਕਿੰਗ ਘੰਟੇ, ਟੋਨ, ਡਿਫੌਲਟ ਰਿਮਾਈਂਡਰ), ਟਾਸਕ ਅਤੇ ਪ੍ਰੋਜੈਕਟ (ਸਥਿਤੀ, ਮਿਆਦ, ਦੁਹਰਾਵ, ਪ੍ਰਾਇਰਿਟੀ), ਨੋਟ ਅਤੇ ਹਾਈਲਾਈਟਸ (ਇਨਬਰਤੇ, ਫੈਸਲੇ), ਅਤੇ ਟੂਲ ਨਤੀਜੇ ਨਾਲ ਇੱਕ ਆਡਿਟ ਟਰੇਲ।
ਗੱਲਬਾਤ ਹਾਈਲਾਈਟਸ ਪੂਰੇ ਟਰਾਂਸਕ੍ਰਿਪਟ ਤੋਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਣ ਹਨ। ਹਰ ਗੱਲ ਕਹਿਣ ਦੀ ਥਾਂ, ਟਿਕਾਉ ਤੱਥ ਸਟੋਰ ਕਰੋ ਜਿਵੇਂ: "ਯੂਜ਼ਰ ਸੰਖੇਪ ਲਘੂ ਪਸੰਦ ਕਰਦਾ ਹੈ", "NYC ਲਈ ਉਡਾਨ ਸ਼ੁੱਕਰਵਾਰ ਹੈ", "ਬਜਟ ਸੀਮਾ $2,000 ਹੈ"।
ਰੀਟਰੀਵਲ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਯੋਜਨਾ ਕਰੋ ਜਿਵੇਂ ਮਨੁੱਖ ਚੀਜ਼ਾਂ ਲੱਭਦੇ ਹਨ: keywords, time ranges, tags, ਅਤੇ "ਹਾਲ ਹੀ ਵਿੱਚ ਬਦਲੇ"। ਪਹਿਲਾਂ ਨਿਰਧਾਰਤ ਫਿਲਟਰ ਵਰਤੋ (ਤਾਰੀਖਾਂ, ਸਥਿਤੀ, ਟੈਗ), ਫਿਰ ਜਦੋਂ ਬੇਨਤੀ ਧੁੰਦਲੀ ਹੋ ਤਾਂ ਨੋਟ ਬਾਡੀਆਂ 'ਤੇ semantic search ਸ਼ਾਮਲ ਕਰੋ।
ਹੈਲੂਸੀਨੇਸ਼ਨਾਂ ਤੋਂ ਬਚਣ ਲਈ, ਸਹਾਇਕ ਨੂੰ ਸਿਰਫ਼ ਉਹੀ ਤੇ ਆਧਾਰਿਤ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਇਹ ਹਕੀਕਤ ਵਿੱਚ ਰੀਟਰੀਵ ਕੀਤਾ (ریکਾਰਡ IDs, ਟਾਈਮਸਟੈਂਪ) ਅਤੇ ਜੇ ਕੁਝ ਨਹੀਂ ਮਿਲਦਾ ਤਾਂ ਸਪਸ਼ਟ ਸਵਾਲ ਪੁੱਛੇ।
ਮੈਮੋਰੀ ਪਾਰਦਰਸ਼ੀ ਬਣਾਓ। ਯੂਜ਼ਰ ਨੂੰ ਦੇਖਣ, ਸੋਧਣ, ਐਕਸਪੋਰਟ ਕਰਨ ਅਤੇ ਮਿਟਾਉਣ ਦੀ ਸਮਰੱਥਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ—ਖ਼ਾਸ ਕਰਕੇ ਲੰਬੇ ਸਮੇਂ ਵਾਲੇ ਤੱਥਾਂ ਲਈ। ਜੇ ਤੁਸੀਂ vibe-coding ਵਰਤ ਰਹੇ ਹੋ ਜਿਵੇਂ Koder.ai, ਤਾਂ "Memory Settings" ਨੂੰ ਇੱਕ ਪਹਿਲੀ-ਸ਼੍ਰੇਣੀ ਸਕ੍ਰੀਨ ਬਣਾਉਣ ਨਾਲ UX ਅਤੇ ਤੁਹਾਡੇ ਡਾਟਾ ਮਾਡਲ ਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਆਕਾਰ ਮਿਲਦਾ ਹੈ।
ਨਿੱਜੀ ਸਹਾਇਕ ਦੀ ਜ਼ਿੰਦਗੀ ਜਾਂ ਮੌਤ ਇੰਟਰਫੇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਜਿੱਥੇ ਲੋਕ ਅਸਲ ਵਿੱਚ ਇਸਨੂੰ ਵਰਤਣਗੇ, ਉਸ ਅਨੁਸਾਰ ਸਟੈਕ ਚੁਣੋ: ਵੈੱਬ ਅਕਸਰ "ਦੈਨਿਕ ਡ੍ਰਾਈਵਰ" ਉਪਯੋਗੀਤਾ ਲਈ ਤੇਜ਼ ਰਸਤਾ ਹੈ, ਜਦੋਂ ਕਿ ਮੋਬਾਇਲ ਨੋਟੀਫਿਕੇਸ਼ਨ, ਵੌਇਸ ਇਨਪੁੱਟ, ਅਤੇ ਆਨ-ਦ-ਗੋ ਕੈਪਚਰ ਲਈ ਜ਼ਰੂਰੀ ਹੈ।
ਇੱਕ ਪ੍ਰਾਇਕਟਿਕ ਰਵੱਈਆ ਇਹ ਹੈ ਕਿ ਪਹਿਲਾਂ React ਨਾਲ ਵੈੱਬ UI ਸ਼ੁਰੂ ਕਰੋ (ਤੇਜ਼ ਇਤਰਾਰ, ਆਸਾਨ ਡਿਪਲੋਯ), ਫਿਰ ਜਦੋਂ ਸਹਾਇਕ ਦੀ ਕੋਰ ਲੂਪ ਕੰਮ ਕਰੇ ਤਾਂ ਸਮਾਨ ਇੰਟਰਐਕਸ਼ਨ ਮਾਡਲ ਨੂੰ Flutter ਵਿੱਚ ਨਕਲ ਕਰੋ।
ਚੈਟ ਨੂੰ ਇੱਕ ਸੰਰਚਿਤ ਗੱਲਬਾਤ ਵਜੋਂ ਪਸੰਦ ਕਰੋ, ਸਿਰਫ਼ ਟੈਕਸਟ ਬਬਲਾਂ ਵਾਂਗ ਨਹੀਂ। ਵੱਖ-ਵੱਖ ਸੁਨੇਹਾ ਆਕਾਰ ਸੰਭਾਲੋ ਤਾਂ ਜੋ ਯੂਜ਼ਰ ਸਮਝ ਸਕਣ ਕਿ ਕੀ ਹੋ ਰਿਹਾ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਉਨ੍ਹਾਂ ਤੋਂ ਕੀ ਉਮੀਦ ਹੈ: ਯੂਜ਼ਰ ਸੁਨੇਹੇ, ਸਹਾਇਕ ਜਵਾਬ (ਸ਼ਾਮਿਲ streaming text), ਟੂਲ ਕਾਰਵਾਈਆਂ ("ਟਾਸਕ ਬਣਾਇਆ ਜਾ ਰਿਹਾ ਹੈ..."), ਪੁਸ਼ਟੀਆਂ (approve/deny), ਐਰਰ (retry ਵਿਕਲਪਾਂ ਨਾਲ), ਅਤੇ ਸਿਸਟਮ ਨੋਟਿਸ (offline, rate limits, degraded capability)।
React ਵਿੱਚ, streaming responses ਸਹਾਇਕ ਨੂੰ ਜ਼ਿਆਦਾ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਮਹਿਸੂਸ ਕਰਵਾ ਸਕਦੇ ਹਨ, ਪਰ rendering ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਰੱਖੋ: deltas ਜੋੜੋ, ਪੂਰੀ ਟ੍ਰਾਂਸਕ੍ਰਿਪਟ ਨੂੰ ਦੁਬਾਰਾ render ਕਰਨ ਤੋਂ ਬਚੋ, ਅਤੇ scroll ਵੇਵਹਾਈਵਿਅਰ ਨੂੰ ਇੰਸਾਨੀ ਰੀਡਿੰਗ ਦੀ ਇਜਾਜ਼ਤ ਦਿਓ।
ਯੂਜ਼ਰਾਂ ਨੂੰ ਫੀਡਬੈਕ ਦੀ ਲੋੜ ਹੈ, ਤੁਹਾਡੇ ਅੰਦਰੂਨੀ ਪ੍ਰੋੰਪਟ ਜਾਂ ਟੂਲ-ਚੇਨ ਦੇ ਵੇਰਵੇ ਨਹੀਂ। ਨਖ਼ੂਲ ਸੰਕੇਤ ਵਰਤੋ ਜਿਵੇਂ "ਇਸ 'ਤੇ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ" ਜਾਂ "ਤੁਹਾਡੇ ਨੋਟ ਚੈੱਕ ਕਰ ਰਿਹਾ ਹਾਂ", ਅਤੇ ਸਿਰਫ਼ ਯੂਜ਼ਰ-ਸੁਰੱਖਿਅਤ ਮੀਲਪੱਥਰ (ਸ਼ੁਰੂ ਹੋਇਆ, ਪੁੱਛ ਲਈ ਉਡੀਕ, ਹੋ ਗਿਆ) ਦਿਖਾਓ। ਇਹ ਹੋਰ ਵੀ ਮਹੱਤਵਪੂਰਣ ਹੋ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਮਲਟੀ-ਏਜੰਟ ਵਰਕਫਲੋਜ਼ ਸ਼ਾਮਲ ਕਰਦੇ ਹੋ।
ਸ਼ੁਰੂ ਵਿੱਚ ਹੀ ਇੱਕ settings ਸਕ੍ਰੀਨ ਜੋੜੋ, ਭਾਵੇਂ ਇਹ ਸਧਾਰਣ ਹੀ ਹੋਵੇ। ਲੋਕਾਂ ਨੂੰ ਟੋਨ (ਪੇਸ਼ੇਵਰ ਵਿਰੁੱਧ ਆਮ), verbosity (ਸੰਖੇਪ ਵਿਰੁੱਧ ਵਿਸਥਾਰ), ਅਤੇ ਪ੍ਰਾਈਵੇਸੀ ਵਿਕਲਪ (ਚੈਟ ਇਤਿਹਾਸ ਸਟੋਰ ਹੋਵੇ ਕਿ ਨਹੀਂ, ਰਿਟੇੰਸ਼ਨ ਅੰਤਰਾਲ, ਮੈਮੋਰੀ ਫੀਚਰ ਚਾਲੂ ਹੋਣ) 'ਤੇ ਨਿਯੰਤਰਣ ਦੇ ਦਿਓ। ਇਹ ਨਿਯੰਤਰਣ ਹੈਰਾਨੀਆਂ ਘੱਟ ਕਰਦੇ ਹਨ ਅਤੇ ਕੰਪਲਾਇੰਸ ਦੀਆਂ ਲੋੜਾਂ ਨਾਲ ਮੱਦਦ ਕਰਦੇ ਹਨ।
ਜੇ ਤੁਸੀਂ Koder.ai ਨਾਲ vibe-coding ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ React ਵੈੱਬ UI ਅਤੇ Flutter ਸਕ੍ਰੀਨਾਂ ਨੂੰ ਇੱਕੋ ਉਦੇਸ਼ ਤੋਂ ਜਨਰੇਟ ਕਰ ਸਕਦੇ ਹੋ, ਫਿਰ ਚੈਟ, ਸਟ੍ਰੀਮਿੰਗ, ਅਤੇ ਸੈਟਿੰਗਜ਼ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਇਤਰਾਰ ਕਰ ਸਕਦੇ ਹੋ ਬਿਨਾਂ UI ਪਲੰਬਿੰਗ ਵਿੱਚ ਫਸਣ ਤੋਂ।
UI ਵਿੱਚ ਜਾਦੂ ਲੱਗਦਾ ਹੈ, ਪਰ ਬੈਕਐਂਡ ਹੀ ਭਰੋਸੇਯੋਗ ਬਣਾਉਂਦਾ ਹੈ। ਲਕੜੀ ਦਾ ਲਕੜੀ ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਚੈਟ-ਚਲਿਤ ਵਿਹੇਵਿਅਰ ਨਿਰਧਾਰਤ ਹੋਵੇ: ਮਾਡਲ ਕਾਰਵਾਈਆਂ ਸੁਝਾ ਸਕਦਾ ਹੈ, ਪਰ ਸਰਵਰ ਫ਼ੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਅਸਲ ਵਿੱਚ ਕੀ ਹੋਵੇ।
ਸਹਾਇਕ ਵਿਹੇਵਿਅਰ ਨੂੰ ਇੱਕ ਛੋਟੀ ਸਥਿਰ endpoints ਸੈੱਟ ਵਿੱਚ ਤਰਜਮਾ ਕਰੋ। ਚੈਟ ਨੂੰ ਦਾਖ਼ਿਲੇ ਦੇ ਤੌਰ 'ਤੇ ਰੱਖੋ, ਫਿਰ ਹਰ ਇੱਕ ਚੀਜ਼ ਲਈ ਵੱਖ-ਵੱਖ ਸਰਾਧਨ ਉਪਲਬਧ ਕਰੋ ਜੋ ਸਹਾਇਕ ਮੈਨੇਜ ਕਰ ਸਕਦਾ ਹੈ। ਉਦਾਹਰਨ ਵਜੋਂ, ਸਹਾਇਕ ਟਾਸਕ ਡਰਾਫਟ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਅੰਤਿਮ create-task ਕਾਲ ਇੱਕ ਆਮ API ਬੇਨਤੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਜਿਸਦਾ ਸਖ਼ਤ schema ਹੋਵੇ।
ਇੱਕ ਸੰਕੁਚਿਤ ਸਰਫੇਸ ਜੋ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਕੇਲ ਹੋ ਜਾਵੇ ਉਹ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ: chat (send/receive ਅਤੇ ਵਿਕਲਪਿਕ ਟੂਲ ਰਿਕਵੈਸਟ), tool execution (approved tools ਚਲਾਓ ਅਤੇ ਸੰਰਚਿਤ ਨਤੀਜੇ ਵਾਪਸ ਕਰੋ), tasks CRUD (ਸਰਵਰ-ਸਾਈਡ ਵੈਧਤਾ ਦੇ ਨਾਲ), preferences, ਅਤੇ job/status endpoints ਲੰਬੇ-ਚੱਲਣ ਵਾਲੇ ਕੰਮਾਂ ਲਈ।
Authentication ਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਜੋੜਨਾ ਆਸਾਨ ਹੈ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਰੀਫੈਕਟਰ ਕਰਨਾ ਦਰਦਨਾਕ। ਨਿਰਧਾਰਿਤ ਕਰੋ ਕਿ ਇੱਕ ਯੂਜ਼ਰ ਸੈਸ਼ਨ ਕਿਸ ਤਰ੍ਹਾਂ ਦਰਸ਼ਾਇਆ ਜਾਂਦਾ ਹੈ (ਟੋਕਨ ਜਾਂ ਸਰਵਰ ਸੈਸ਼ਨਾਂ) ਅਤੇ ਬੇਨਤੀਆਂ ਨੂੰ ਕਿਵੇਂ ਸਕੋਪ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (user ID, org ID ਟੀਮਾਂ ਲਈ)। ਨਿਰਧਾਰਿਤ ਕਰੋ ਕਿ ਸਹਾਇਕ "ਚੁੱਪਚਾਪ" ਕੀ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਕੀ ਮੁੜ-ਪ੍ਰਮਾਣੀਕਰਨ ਜਾਂ ਪੁਸ਼ਟੀ ਦੀ ਲੋੜ ਹੋਵੇਗੀ।
ਜੇ ਤੁਸੀਂ tiers (free/pro/business/enterprise) ਦੀ ਯੋਜਨਾ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ entitlements ਨੂੰ ਦਿਨ ਪਹਿਲੇ ਤੋਂ API ਲੇਅਰ 'ਤੇ ਲਾਗੂ ਕਰੋ (ਰੇਟ ਲਿਮਿਟ, ਟੂਲ ਉਪਲਬਧਤਾ, ਐਕਸਪੋਰਟ ਅਧਿਕਾਰ), ਨਾ ਕਿ ਪ੍ਰੋੰਪਟਾਂ ਦੇ ਅੰਦਰ।
ਵੱਡੀ ਸਮੱਗਰੀ ਦੇ ਸੰਖੇਪ, ਇੰਪੋਰਟ, ਜਾਂ ਮਲਟੀ-ਸਟੈਪ ਏਜੰਟ ਵਰਕਫਲੋਜ਼ ਐਸਿੰਕ੍ਰੋਨਸ ਹੋਣ ਚਾਹੀਦੇ ਹਨ। ਜਵਾਬ ਤੇਜ਼ੀ ਨਾਲ ਇੱਕ job ID ਨਾਲ ਵਾਪਸ ਕਰੋ ਅਤੇ ਪ੍ਰਗਟੀ ਅਪਡੇਟ ਦਿਓ (queued → running → partial results → completed/failed)। ਇਸ ਨਾਲ ਚੈਟ ਰਿਸਪਾਂਸਿਵ ਰਹਿੰਦਾ ਹੈ ਅਤੇ timeout ਤੋਂ ਬਚਦਾ ਹੈ।
ਮਾਡਲ ਆਉਟਪੁੱਟਾਂ ਨੂੰ untrusted ਇਨਪੁੱਟ ਵਜੋਂ ਲਵੋ। ਹਰ ਚੀਜ਼ ਦੀ ਵੈਧਤਾ ਅਤੇ ਸੈਨਿਟਾਈਜ਼ ਕਰੋ: ਟੂਲ ਕਾਲਾਂ ਲਈ ਸਖ਼ਤ JSON schemas, ਅਣਜਾਣ-ਫੀਲਡ ਰੱਦ, type/range enforcement, ਸਰਵਰ-ਸਾਈਡ date/timezone ਸਧਾਰਨਿਕਰਨ, ਅਤੇ ਟੂਲ ਰਿਕਵੈਸਟ/ਨਤੀਜਿਆਂ ਦਾ ਲਾਗ auditability ਲਈ।
Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ scaffolding ਨੂੰ ਤੇਜ਼ ਕਰ ਸਕਦੇ ਹਨ (Go APIs, PostgreSQL backing, snapshots/rollback), ਪਰ ਕਥਨ ਉਹੀ ਹੈ: ਗੱਲਬਾਤ ਬਣਦੀ ਹੈ ਤੇ ਰਚਨਾਤਮਕ ਹੈ ਜਦਕਿ ਬੈਕਏਂਡ ਨਿਰਧਾਰਤ, ਸਖ਼ਤ, ਅਤੇ ਭਰੋਸੇਯੋਗ ਰਹਿੰਦਾ ਹੈ।
ਇੱਕ ਨਿੱਜੀ ਸਹਾਇਕ "ਸਮਾਰਟ" ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ ਹੈ ਜਦੋਂ ਇਹ ਨਿਰਧਾਰਤ ਤਰੀਕੇ ਨਾਲ ਯਾਦ ਰੱਖ ਸਕੇ, ਆਪਣੇ ਕੀਤੇ ਕਾਰਜਾਂ ਨੂੰ ਵਿਆਖਿਆ ਕਰ ਸਕੇ, ਅਤੇ ਗਲਤੀਆਂ ਨੂੰ ਰੱਦ ਕਰ ਸਕੇ। ਤੁਹਾਡਾ PostgreSQL ਸਕੀਮਾ ਇਹ ਸਭ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਸਹਾਇਤਾ ਕਰੇ: ਸਪਸ਼ਟ ਕੋਰ ਐਨਟੀਟੀਆਂ, ਸਪਸ਼ਟ provenance (ਕੋਣ ਤੋਂ ਹਰ ਆਈਟਮ ਆਇਆ), ਅਤੇ audit-friendly timestamps।
ਇੱਕ ਨਿੱਕੀ ਟੇਬਲ সেট ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਯੂਜ਼ਰ ਉਮੀਦਾਂ ਨਾਲ ਮਿਲਦਾ ਹੋਵੇ: users, conversations/messages, tasks/reminders, notes, ਅਤੇ (ਵਿਕਲਪਿਕ) embeddings ਜੇ ਤੁਸੀਂ retrieval ਸਕੇਲ ਕਰ ਰਹੇ ਹੋ। tasks/notes ਨੂੰ messages ਤੋਂ ਵੱਖ ਰੱਖੋ: messages ਰਾ ਵ transcript ਹਨ; tasks/notes ਸੰਰਚਿਤ ਨਤੀਜੇ ਹਨ।
Provenance ਨੂੰ ਪਹਿਲਾ-ਸ਼੍ਰੇਣੀ ਫੀਚਰ ਮੰਨੋ। ਜਦੋਂ LLM ਇੱਕ ਬੇਨਤੀ ਨੂੰ ਟਾਸਕ ਵਿੱਚ ਬਦਲਦਾ ਹੈ, ਤਾਂ tasks/notes 'ਤੇ source_message_id ਸਟੋਰ ਕਰੋ, ਕਿਸ ਨੇ ਬਣਾਇਆ ਇਸਦੀ track ਰੱਖੋ (user, assistant, ਜਾਂ system), ਅਤੇ ਜੇ ਤੁਸੀਂ tools/agents ਵਰਤਦੇ ਹੋ ਤਾਂ tool_run_id ਜੋੜੋ। ਇਹ ਵਿਹੇਵਿਅਰ ਨੂੰ ਵਿਆਖਿਆਯੋਗ ਬਣਾਉਂਦਾ ਹੈ ("ਮੰਗਵਾਈ ਤੇਰੇ ਸੁਨੇਹੇ ਤੋਂ ਮੰਗਲਵਾਰ ਨੂੰ 10:14 ਤੇ ਬਣਾਈ ਗਈ") ਅਤੇ debugging ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ।
ਸਾਰੀਆਂ ਟੇਬਲਾਂ ਵਿੱਚ consistency ਰੱਖੋ: created_at, updated_at, ਅਤੇ ਅਕਸਰ deleted_at ਸੌਫਟ ਡਿਲੀਟ ਲਈ। ਸੌਫਟ ਡਿਲੀਟ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਉਪਯੁਕਤ ਹੈ ਕਿਉਂਕਿ ਯੂਜ਼ਰ ਅਕਸਰ undo ਚਾਹੁੰਦੇ ਹਨ, ਅਤੇ ਤੁਹਾਨੂੰ compliance ਜਾਂ troubleshooting ਲਈ records ਸੰਭਾਲਣੇ ਪੈ ਸਕਦੇ ਹਨ।
ਅਪਰਿਵਰਤੀ ਆਈਡਾਂ (uuid) ਅਤੇ ਮੁੱਖ ਘਟਨਾਵਾਂ ਲਈ append-only audit log ਟੇਬਲ 'ਤੇ ਵਿਚਾਰ ਕਰੋ (task created, due date changed, reminder fired)। ਇਹ ਅਪਡੇਟ ਕੀਤੀ ਸਤ੍ਰਾਂ ਤੋਂ ਇਤਿਹਾਸ ਨੂੰ ਮੁੜ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੇ ਬਜਾਏ ਸਧਾਰਣ ਹੈ।
ਸਹਾਇਕ ਵਿਹੇਵਿਅਰ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਦਾ ਹੈ। ਮਾਈਗ੍ਰੇਸ਼ਨਾਂ ਦੀ ਯੋਜਨਾ ਪਹਿਲਾਂ ਤੋਂ ਬਣਾਓ: ਆਪਣਾ ਸਕੀਮਾ ਵਰਜ਼ਨ ਕਰੋ, ਵਿਨਸ਼_tbਕ ਬਦਲਾਵਾਂ ਤੋਂ ਬਚੋ, ਅਤੇ ਜੋੜ-ਵਧਾਓ ਕਦਮ (ਨਵਾਂ ਕਾਲਮ, ਨਵੀਂ ਟੇਬਲ) ਤਰਜੀਹ ਦਿਓ। ਜੇ ਤੁਸੀਂ vibe-coding ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ snapshots/rollback ਨਾਲ ਡੇਟਾਬੇਸ ਮਾਈਗ੍ਰੇਸ਼ਨ ਅਨੁਸ਼ਾਸਨ ਜੋੜੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਇਤਰਾਰ ਕਰ ਸਕੋ ਬਿਨਾਂ ਡਾਟਾ ਇੰਟੇਗ੍ਰਿਟੀ ਨੂੰ ਖਤਰੇ ਵਿੱਚ ਪਾਏ।
-- Example: tasks table with provenance and auditability
CREATE TABLE tasks (
id uuid PRIMARY KEY,
user_id uuid NOT NULL,
title text NOT NULL,
status text NOT NULL,
due_at timestamptz,
source_message_id uuid,
created_by text NOT NULL,
created_at timestamptz NOT NULL DEFAULT now(),
updated_at timestamptz NOT NULL DEFAULT now(),
deleted_at timestamptz
);
ਭਰੋਸੇਯੋਗਤਾ ਇੱਕ ਠੰਢੇ ਡੈਮੋ ਅਤੇ ਉਹ ਚੀਜ਼ ਹੈ ਜਿਸ 'ਤੇ ਲੋਕ ਵਾਸਤਵਿਕ ਕੰਮ ਦੇ ਸਕਦੇ ਹਨ। ਮੁਸ਼ਕਲ ਗੱਲ ਇਹ ਹੈ ਕਿ ਸਹਾਇਕ ਬੇਨਤੀਆਂ ਆਮ ਤੌਰ 'ਤੇ ਸਧਾਰਨ ਨਹੀਂ ਹੁੰਦੀਆਂ: ਯੂਜ਼ਰ ਸੰਜੇਦਗੀ ਘੱਟ, ਭਾਵੁਕ, ਅਸਥਿਰ, ਅਤੇ ਅਕਸਰ ਮੁੱਖ ਵੇਰਵਾ ਛੱਡ ਦਿੰਦੇ ਹਨ। ਤੁਹਾਡੀ ਟੈਸਟਿੰਗ ਰਣਨੀਤੀ ਨੂੰ ਇਸ ਹਕੀਕਤ ਨੂੰ ਦਰਸਾਉਣਾ ਚਾਹੀਦਾ ਹੈ।
(ਜਾਂ ਇਕੱਠਾ ਕਰੋ) ਇੱਕ ਛੋਟਾ ਪਰ ਪ੍ਰਤੀਨਿਧੀ ਬੇਨਤੀਆਂ ਦਾ ਸੈੱਟ: ਛੋਟੇ ਸੁਨੇਹੇ, ਅਸਪਸ਼ਟ ਹੁਕਮ, ਟਾਈਪੋ, ਵਿਰੋਧੀ ਸ਼ਰਤਾਂ, ਅਤੇ ਆਖਰੀ ਸਮੇਂ ਬਦਲਾਅ। ਖੁਸ਼ਮੰਦ ਪੱਥ (ਸਪਸ਼ਟ ਟਾਸਕ ਬਣਾਉਣਾ, ਨੋਟ ਕੈਪਚਰ) ਅਤੇ ਕਿਨਾਰੇ ਵਾਲੇ ਪੱਥ (ਮਿਸਿੰਗ ਤਰੀਖਾਂ, ਅਸਪਸ਼ਟ ਸਰਵਨਾਮ, ਇੱਕੋ ਨਾਮ ਵਾਲੇ ਕਈ ਲੋਕ, ਅਜਿਹੀਆਂ ਬੇਨਤੀਆਂ ਜੋ ਅਨੁਮਤੀਆਂ ਦੀ ਮੰਗ ਕਰਦੀਆਂ)।
ਇਹ ਉਦਾਹਰਨਾਂ ਤੁਹਾਡਾ golden set ਬਣ ਜਾਣ ਚਾਹੀਦਾ ਹੈ। ਹਰ ਵਾਰੀ ਜਦੋਂ ਤੁਸੀਂ prompts, tools, ਜਾਂ agent logic ਬਦਲੋ, ਇਹ ਚਲਾਓ।
ਸਹਾਇਕ ਐਪਸ ਲਈ, ਸਹੀ ਸਿਰਫ਼ ਆਖ਼ਰੀ ਟੈਕਸਟ ਜਵਾਬ ਨਹੀਂ ਹੈ। ਮੁਆਇਨਾ ਕਰੋ ਕਿ ਕੀ ਇਹ ਸਹੀ ਕਾਰਵਾਈ ਲਈ ਦਿੱਤਾ, ਲੋੜੀਅਤ ਸਮੇਂ ਪੁਸ਼ਟੀ ਕੀਤੀ, ਅਤੇ ਕੰਮ ਬਣਾਏ ਬਿਨਾਂ ਕਿਸੇ ਟੂਲ ਰન ਦੇ ਦਾਅਵੇ ਨਾ ਕੀਤੇ।
ਇੱਕ ਪ੍ਰਾਇਕਟਿਕ ਰੁਬ੍ਰਿਕ ਚੈੱਕ ਕਰਦਾ ਹੈ: task correctness, confirmation ਵਿਹੇਵਿਅਰ (ਖਾਸ ਕਰਕੇ ਮਿਟਾਉਣ/ਭੇਜਣ/ਖਰਚ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ), hallucinated actions (ਟੂਲ ਰਨ ਬਿਨਾਂ ਅਮਲ ਦਾ ਦਾਅਵਾ), tool discipline (ਜਰੂਰੀ ਹੋਣ 'ਤੇ ਟੂਲ ਵਰਤਣਾ; ਬਿਨਾਂ ਲੋੜ ਟੂਲ ਕਾਲ ਕਰਨੀ ਤੋਂ ਬਚਣਾ), ਅਤੇ recovery (ਅਸਫਲਤਾਵਾਂ ਅਤੇ retries ਦਾ ਸਾਫ਼ ਹੱਲ)।
ਹਰ ਪ੍ਰੋੰਪਟ ਤਬਦੀਲੀ ਵਿਹੇਵਿਅਰ ਨੂੰ ਅਚਾਨਕ ਬਦਲ ਸਕਦੀ ਹੈ। ਪ੍ਰੋੰਪਟਾਂ ਨੂੰ ਕੋਡ ਵਾਂਗ treat ਕਰੋ: ਉਹਨਾਂ ਨੂੰ ਵਰਜ਼ਨ ਕਰੋ, golden set ਚਲਾਓ, ਅਤੇ ਨਤੀਜਿਆਂ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਕਈ ਏਜੰਟ ਵਰਤਦੇ ਹੋ (planner/executor), ਤਾਂ ਹਰ ਪੜਾਅ ਦੀ ਟੈਸਟ ਕਰੋ—ਕਈ ਅਸਫਲਤਾਵਾਂ ਯੋਜਨਾ ਦੀ ਗਲਤੀ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਫੈਲ ਹੋ ਕੇ ਝੱਲ ਹੁੰਦੀਆਂ ਹਨ।
ਨਵਾਂ ਟੂਲ ਜੋੜਦੇ ਸਮੇਂ ਜਾਂ ਟੂਲ ਸਕੀਮਾ ਬਦਲਦੇ ਸਮੇਂ, ਨਿਸ਼ਾਨਦਾਰ ਰਿਗ੍ਰੈਸ਼ਨ ਕੇਸ ਜੋੜੋ (ਉਦਾਹਰਣ ਲਈ, "ਅਗਲੇ ਸ਼ੁੱਕਰਵਾਰ ਲਈ ਟਾਸਕ ਬਣਾਓ" ਹੋਰ ਵੀ ਮੁਲਾਸ਼ਤਾਂ ਦੇ ਨਾਲ ਤਾਰੀਖਾਂ ਨੂੰ ਇੱਕਸਾਰ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ)। ਜੇ ਤੁਾਡਾ ਵਰਕਫਲੋ snapshots ਅਤੇ rollback ਸਹਾਰਾ ਦਿੰਦਾ, ਤਾਂ ਮੁਕਾਬਲੇ ਵਾਪਸ ਕਰਨ ਲਈ ਉਹ ਵਰਤੋ ਜਦੋਂ ਮੁਲਾਂਕਣ ਘਟ ਜਾਂਦਾ ਹੈ।
ਟੂਲ ਕਾਲਾਂ, redact ਕੀਤੇ ਆਰਗੂਮੈਂਟ, ਟਾਈਮਿੰਗ, ਅਤੇ ਅਸਫਲਤਾ ਕਾਰਨਾਂ ਨੂੰ ਲਾਗ ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਜਵਾਬ ਦੇ ਸਕੋ: "ਮਾਡਲ ਨੇ ਕੀ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ?" ਅਤੇ "ਇਹ ਕਿਉਂ ਫੇਲ ਹੋਇਆ?" ਟੋਕਨ, ਨਿਜੀ ਡੇਟਾ, ਅਤੇ ਸੁਨੇਹੇ ਦੀ ਸਮੱਗਰੀ ਨੂੰ ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ ਰੀਡੈਕਟ ਕਰੋ, ਅਤੇ debugging ਲਈ ਜ਼ਰੂਰੀ ਜ਼ਿਆਦਾ ਨਹੀਂ ਸਟੋਰ ਕਰੋ—ਅਕਸਰ hashed user ID, ਟੂਲ ਨਾਂ, ਹਾਈ-ਲੈਵਲ ਇਰਾਦਾ, ਅਤੇ error class ਕਾਫ਼ੀ ਹੁੰਦੇ ਹਨ।
ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੀਤਾ ਗਿਆ, ਟੈਸਟਿੰਗ iteration ਨੂੰ ਇੱਕ ਨਿਯੰਤਰਿਤ ਲੂਪ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ: ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਭਰੋਸੇ ਨੂੰ ਤੋੜੇ।
ਨਿੱਜੀ ਸਹਾਇਕ ਐਪ ਤੇਜ਼ੀ ਨਾਲ ਸੰਵੇਦਨਸ਼ੀਲ ਸਮੱਗਰੀ ਦਾ ਡੱਬਾ ਬਣ ਜਾਂਦੀ ਹੈ: ਕੈਲੇੰਡਰ, ਸਥਾਨ, ਸੁਨੇਹੇ, ਦਸਤਾਵੇਜ਼, ਅਤੇ ਵੱਖ-ਵੱਖ ਨੋਟ ਜੋ ਯੂਜ਼ਰ ਗੁਪਤ ਰੱਖਣੇ ਚਾਹੁੰਦੇ ਹਨ। ਗੋਪਨੀਯਤਾ ਨੂੰ ਇੱਕ ਫੀਚਰ ਵਜੋਂ ਸੰਭਾਲੋ, ਨਾਂ ਕਿ ਸਿਰਫ਼ ਇੱਕ ਚੈੱਕਬਾਕਸ। ਜੋ ਕੁਝ ਘੱਟ ਸੰਭਾਲੋ ਅਤੇ ਜੋ ਕੁਝ LLM ਨੂੰ ਭੇਜੋ ਉਸ ਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ ਰੱਖੋ। ਜੇ ਕਿਸੇ ਫੀਚਰ ਨੂੰ ਪੂਰੇ ਸੁਨੇਹੇ ਇਤਿਹਾਸ ਦੀ ਲੋੜ ਨਹੀਂ, ਤਾਂ ਇਸਨੂੰ ਸਟੋਰ ਨਾ ਕਰੋ; ਜੇ ਕੋਈ ਬੇਨਤੀ ਇੱਕ ਛੋਟਾ ਸਾਰ ਨਾਲ ਜਵਾਬ ਕੀਤਾ ਜਾ ਸਕਦੀ ਹੈ, ਤਾਂ ਸਿਰਫ਼ ਉਹੀ ਸਾਰ ਭੇਜੋ।
Retention ਪਹਿਲਾਂ ਹੀ ਨਿਰਧਾਰਿਤ ਕਰੋ: ਤੁਸੀਂ ਕੀ ਸਟੋਰ ਕਰਦੇ ਹੋ (ਟਾਸਕ, ਨੋਟ, ਪਸੰਦ), ਕਿਉਂ ਸਟੋਰ ਕਰਦੇ ਹੋ, ਅਤੇ ਇਹ ਕਿੰਨਾ ਸਮਾਂ ਰੱਖਦੇ ਹੋ। ਮਿਟਾਉਣਾ ਅਸਲ ਅਤੇ ਪਰਖਯੋਗ ਬਣਾਓ: ਯੂਜ਼ਰ ਨੂੰ ਇੱਕ ਹੀ ਨੋਟ, ਇੱਕ ਪੂਰਾ ਵਰਕਸਪੇਸ, ਅਤੇ ਕੋਈ ਵੀ ਅਪਲੋਡ ਕੀਤੀ ਫਾਈਲ ਮਿਟਾਉਣੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਸੰਵੇਦਨਸ਼ੀਲ ਗੱਲਬਾਤਾਂ ਲਈ "forgetful mode" 'ਤੇ ਵਿਚਾਰ ਕਰੋ ਜਿੱਥੇ ਤੁਸੀਂ ਸਮੱਗਰੀ ਬਿਲਕੁਲ ਨਹੀਂ ਰੱਖਦੇ—ਸਿਰਫ਼ ਬਿਲਿੰਗ ਅਤੇ ਦੁਰਵਰਤਨ ਰੋਕਥਾਮ ਲਈ ਘੱਟੋ-ਘੱਟ ਮੈਟਾਡੇਟਾ।
API ਕੁੰਜੀਆਂ ਨੂੰ ਕਦਾਚਿਤ ਕਲਾਇੰਟ ਨੂੰ ਨਾ ਭੇਜੋ। ਪ੍ਰੋਵਾਈਡਰ ਕੁੰਜੀਆਂ ਅਤੇ ਟੂਲ ਕਰੀਡੈਂਸ਼ਲ ਸਰਵਰ 'ਤੇ ਰੱਖੋ, ਉਹਨਾਂ ਨੂੰ ਰੋਟੇਟ ਕਰੋ, ਅਤੇ ਪ੍ਰਤੀ ماحول ਪ੍ਰਸੰਗ ਦੇ ਅਨੁਸਾਰ scope ਕਰੋ। ਟ੍ਰਾਂਜ਼ਿਟ ਵਿੱਚ ਡੇਟਾ ਨੂੰ TLS ਨਾਲ ਅਤੇ ਰੈਸਟ ਵਿੱਚ (ਡੇਟਾਬੇਸ ਅਤੇ ਬੈਕਅੱਪ) ਇਨਕ੍ਰਿਪਟ ਕਰੋ। ਸੈਸ਼ਨ ਟੋਕਨਾਂ ਲਈ ਛੋਟਾ ਅਵਧੀ ਅਤੇ refresh flows ਵਰਤੋ; ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ hashes ਸਟੋਰ ਕਰੋ ਅਤੇ ਰੌ ਸ਼ ਪ੍ਰੋੰਪਟ ਜਾਂ ਟੂਲ ਆਉਟਪੁੱਟ ਲਾਗ ਕਰਨ ਤੋਂ ਬਚੋ।
ਕੁਝ ਯੂਜ਼ਰ ਡੇਟਾ ਰਿਹਾਇਸ਼ ਦੀ ਮੰਗ ਕਰ ਸਕਦੇ ਹਨ (ਖ਼ਾਸ ਮੁਲਕ/ਖੇਤਰ), ਖ਼ਾਸ ਕਰਕੇ ਕੰਮ ਵਾਲੇ ਸਹਾਇਕਾਂ ਲਈ। ਰੀਜਨ-ਅਵੈਅਰ ਡਿਪਲੋਇਮੈਂਟ ਪਹਿਲਾਂ ਹੀ ਯੋਜਨਾ ਬਣਾਓ: ਯੂਜ਼ਰ ਡੇਟਾ ਨੂੰ ਇੱਕ ਖੇਤਰ-ਸਮਰੱਥ ਡੈਟਾਬੇਸ ਵਿੱਚ ਰੱਖੋ ਅਤੇ ਕ੍ਰਾਸ-ਰੀਜਨ ਪਾਇਪਲਾਈਨਾਂ ਤੋਂ ਬਚੋ ਜੋ ਸਮੱਗਰੀ ਨੂੰ ਗੁਪਤ ਤੌਰ 'ਤੇ ਹੋਰ ਥਾਂ ਤੇ ਨਕਲ ਕਰ ਸਕਦੀਆਂ ਹਨ। Koder.ai AWS 'ਤੇ ਗਲੋਬਲੀ ਚੱਲਦਾ ਹੈ ਅਤੇ বিশেষ ਮੁਲਕਾਂ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਹੋਸਟਿੰਗ ਕਰ ਸਕਦਾ ਹੈ, ਜੋ ਰਿਹਾਇਸ਼ ਅਤੇ ਕ੍ਰਾਸ-ਬੋਰਡ ਟ੍ਰਾਂਸਫਰ ਦੀਆਂ ਲੋੜਾਂ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ ਜੇ ਤੁਹਾਨੂੰ ਇਹ ਲੋੜ ਹੋਵੇ।
ਸਹਾਇਕ ਅਕਸਰ ਦੁਰਵਰਤਨ ਲਈ ਲੱਖੇ ਹੋ ਜਾਂਦੇ ਹਨ: scraping, credential stuffing, ਅਤੇ "ਮਾਡਲ ਨੂੰ ਰਾਜ਼ ਖੋਲ੍ਹਣ ਲਈ ਮਜਬੂਰ ਕਰੋ" ਜਿਹੇ ਹਮਲੇ। ਇੱਕ ਪ੍ਰਾਇਕਟਿਕ ਬੇਸਲਾਈਨ ਵਿੱਚ ਸ਼ਾਮਲ ਹੈ: ਰੇਟ ਲਿਮਿਟ ਅਤੇ ਕੋਟਾ, ਸੰਦ-ਕਾਲਾਂ 'ਤੇ suspicious activity detection, ਸਖ਼ਤ ਟੂਲ ਅਨੁਮਤੀਆਂ (allow-list + ਸਰਵਰ-ਸਾਈਡ ਵੈਧਤਾ), ਪ੍ਰੋੰਪਟ-ਇੰਜੈਕਸ਼ਨ hygiene (ਬਾਹਰੀ ਟੈਕਸਟ ਨੂੰ untrusted ਮੰਨੋ; system rules ਤੋਂ ਅਲੱਗ ਕਰੋ), ਅਤੇ ਟੂਲ ਐਕਸਿਕਿਊਸ਼ਨ ਅਤੇ ਡੇਟਾ ਪਹੁੰਚ ਲਈ audit logs।
ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਵਿਹੇਵਿਅਰ ਅਨੁਮਾਨਕ ਹੋਵੇ: ਮਾਡਲ ਸੁਝਾਅ ਦੇ ਸਕਦਾ ਹੈ, ਪਰ ਤੁਹਾਡਾ ਬੈਕਐਂਡ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਆਗਿਆ ਹੈ।
ਨਿੱਜੀ ਸਹਾਇਕ ਐਪ ਇਕ ਇੱਕ-ਬਾਰੀ ਲਾਂਚ ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਇੱਕ ਚੱਕਰ ਹੈ: ਛੋਟੇ ਛੋਟੇ ਰਿਲੀਜ਼ ਛੱਡੋ, ਅਸਲ ਵਰਤੋਂ ਦੇਖੋ, ਵਿਹੇਵਿਅਰ ਨੂੰ ਕਸੋ, ਅਤੇ ਦੁਹਰਾਓ—ਬਿਨਾਂ ਭਰੋਸਾ ਟੁੱਟੇ। ਕਿਉਂਕਿ ਸਹਾਇਕ ਦਾ ਵਿਹੇਵਿਅਰ ਇੱਕ ਪ੍ਰੋੰਪਟ ਤਬਦੀਲੀ ਜਾਂ ਨਵੀਂ ਟੂਲ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਨਾਲ ਬਦਲ ਸਕਦਾ ਹੈ, ਤੁਹਾਨੂੰ ਡਿਪਲੋਇਮੈਂਟ ਅਨੁਸ਼ਾਸਨ ਦੀ ਲੋੜ ਹੋਵੇਗੀ ਜੋ ਕਨਫਿਗਰੇਸ਼ਨ ਅਤੇ ਪ੍ਰੋੰਪਟਾਂ ਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਕੋਡ ਵਾਂਗ ਮਾਨਦਾ ਹੈ।
ਹਰ ਨਵੀਂ ਸਮਰੱਥਾ ਅਚਾਨਕ ਤਰੀਕੇ ਨਾਲ ਫੇਲ ਹੋ ਸਕਦੀ ਹੈ: ਟਾਈਮਜ਼ੋਨ ਬਗ, ਮੈਮੋਰੀ ਗਲਤ ਤੱਥ ਸਟੋਰ ਕਰਨਾ, ਜਾਂ ਮਾਡਲ ਬਹੁਤ ਰਚਨਾਤਮਕ ਹੋ ਜਾਣਾ। ਫੀਚਰ ਫਲੈਗਸ ਤੁਹਾਨੂੰ ਨਵੀਂ ਟੂਲ ਅਤੇ ਮੈਮੋਰੀ ਵਿਹੇਵਿਅਰ ਨੂੰ ਕੁਝ ਯੂਜ਼ਰਾਂ ਜਾਂ ਅੰਦਰੂਨੀ ਖਾਤਿਆਂ ਤੱਕ ਸੀਮਿਤ ਕਰਨ ਦਿੰਦੇ ਹਨ ਬਿਨਾਂ ਸਭ ਨੂੰ ਝਲਸਾਉਣ ਦੇ।
ਸਧਾਰਣ ਰਣਨੀਤੀ:
ਰਿਵਾਇਤੀ ਐਪਾਂ ਵਿੱਚ ਰੋਲਬੈਕ ਬਿਨਾਰੀਆਂ ਨੂੰ ਪਿਛੇ ਲੈ ਜਾਂਦਾ ਹੈ; ਸਹਾਇਕ ਐਪਾਂ ਲਈ ਵਿਹੇਵਿਅਰ ਨੂੰ ਵੀ ਰੋਲਬੈਕ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਸਿਸਟਮ ਪ੍ਰੋੰਪਟ, ਟੂਲ ਸਕੀਮਾ, routing rule, ਸੁਰੱਖਿਆ ਨੀਤੀਆਂ, ਅਤੇ ਮੈਮੋਰੀ ਫਿਲਟਰਾਂ ਨੂੰ versioned deployables ਵਜੋਂ treat ਕਰੋ। snapshots ਰੱਖੋ ਤਾਂ ਜੋ ਤੁਸੀਂ last-known-good ਵਿਹੇਵਿਅਰ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਬਹਾਲ ਕਰ ਸਕੋ।
ਇਹ ਖ਼ਾਸ ਕਰਕੇ ਮੁਲਾਂਕਣੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ vibe coding ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਤਬਦੀਲੀਆਂ ਕਰ ਰਹੇ ਹੋ: Koder.ai snapshots ਅਤੇ rollback ਦਾ ਸਮਰਥਨ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਜੋ ਛੋਟੇ Text edits ਨਾਲ ਵੱਡੇ ਉਤਪਾਦ ਪ੍ਰਭਾਵ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ white-label ਸਹਾਇਕ (ਟੀਮਾਂ ਜਾਂ ਗ੍ਰਾਹਕਾਂ ਲਈ) ਦੇ ਰਹੇ ਹੋ, ਤਾਂ ਪਹਿਲੇ ਤੋਂ ਕਸਟਮ ਡੋਮੇਨਾਂ ਲਈ ਯੋਜਨਾ ਬਣਾਓ। ਇਹ auth callbacks, cookie/session ਸੈਟਿੰਗ, ਪ੍ਰਤੀ-ਟੇਨੈਂਟ ਰੇਟ ਲਿਮਿਟ, ਅਤੇ ਲਾਗ/ਡੇਟਾ ਵੱਖ-ਵੱਖ ਕਰਨ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਉਂਦਾ ਹੈ। ਇੱਕ-ਬ੍ਰੈਂਡ ਉਤਪਾਦ ਲਈ ਵੀ, ਵਾਤਾਵਰਨ (dev/staging/prod) ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਟੂਲ ਅਨੁਮਤੀਆਂ ਅਤੇ ਮਾਡਲ ਸੈਟਿੰਗਜ਼ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਟੈਸਟ ਕਰ ਸਕੋ।
ਸਹਾਇਕ ਮਾਨੀਟਰਿੰਗ ਉਤਪਾਦ ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਓਪਰੇਸ਼ਨ ਦੋਹਾਂ ਹੈ। latency ਅਤੇ errors ਨੂੰ ਟ੍ਰੈਕ ਕਰੋ, ਪਰ ਵਿਹੇवਿਅਰਲ ਸਿਗਨਲ ਜਿਵੇਂ cost per conversation, tool-call frequency, ਅਤੇ tool failure rate ਵੀ ਵੇਖੋ। ਮੈਟ੍ਰਿਕਸ ਨੂੰ sample ਕੀਤੀਆਂ ਗੱਲਬਾਤਾਂ ਨਾਲ ਜੋੜੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਦੇਖ ਸਕੋ ਕਿ ਬਦਲਾਅ ਨੇ ਨਤੀਜੇ ਸੁਧਾਰੇ ਹਨ—ਸਿਰਫ਼ throughput ਨਹੀਂ।
Vibe coding ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਕੀਮਤੀ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਨੂੰ ਇੱਕ ਅਸਲ ਪ੍ਰੋਟੋਟਾਈਪ ਦੀ ਲੋੜ ਹੋਵੇ—ਨਾ ਕਿ ਸਿਰਫ਼ ਸ਼ੀਟ। ਨਿੱਜੀ ਸਹਾਇਕ ਐਪ ਲਈ, ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਮਤਲਬ ਹੈ: ਇੱਕ ਚੈਟ UI, ਕੁਝ ਮੁੱਖ ਕਾਰਵਾਈਆਂ (ਟਾਸਕ ਕੈਪਚਰ, ਨੋਟ ਸੇਵ, ਰਿਮਾਈਂਡਰ), ਅਤੇ ਇਕ ਬੈਕਐਂਡ ਜੋ LLM ਦੇ ਰਚਨਾਤਮਕ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਨਿਰਧਾਰਤ ਰਹੇ। ਇੱਕ vibe-coding ਪਲੇਟਫਾਰਮ ਪਹਿਲੇ-ਕਾਮ-ਵਰਜ਼ਨ ਟਾਈਮਲਾਈਨ ਨੂੰ ਸੰਕੋਚਿਤ ਕਰਦਾ ਹੈ, ਤੁਹਾਡੇ ਉਤਪਾਦ ਵਰਣਨ ਨੂੰ ਕੰਮ ਕਰ ਰਹੀਆਂ ਸਕ੍ਰੀਨਾਂ, ਰੂਟਸ, ਅਤੇ ਸਰਵਿਸز ਵਿੱਚ ਤਬਦੀਲ ਕਰਕੇ ਜੋ ਤੁਸੀ ਚਲਾ ਕੇ ਸੁਧਾਰ ਸਕਦੇ ਹੋ।
ਸੰਭਾਲੋ ਕਿ ਸਹਾਇਕ ਨੂੰ ਸਧਾਰਣ ਭਾਸ਼ਾ ਵਿੱਚ chat ਵਿੱਚ ਵੇਰਵਾ ਕਰੋ: ਇਹ ਕਿਸ ਲਈ ਹੈ, ਇਹ ਕੀ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ MVP ਲਈ "ਪੂਰਾ" ਦਾ ਕੀ ਮਤਲਬ ਹੈ। ਛੋਟੇ ਕਦਮਾਂ ਵਿੱਚ ਦੁਹਰਾਓ।
ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ React ਵੈੱਬ ਇੰਟਰਫੇਸ ਜਨਰੇਟ ਕਰੋ (conversation view, message composer, ਇੱਕ ਹਲਕੀ "tools used" ਪੈਨਲ, ਅਤੇ settings ਪੇଜ), ਫਿਰ ਜਦੋਂ ਫਲੋਜ਼ ਠੀਕ ਲੱਗਣ, ਇੱਕ Flutter ਮੋਬਾਇਲ ਵਰਜ਼ਨ ਜੋੜੋ।
ਅਗਲੇ ਕਦਮ ਵਜੋਂ, Go ਬੈਕਐਂਡ ਨਾਲ PostgreSQL ਜਨਰੇਟ ਕਰੋ: authentication, conversations ਲਈ ਇੱਕ ਮਿੰਨੀਮਲ API, ਅਤੇ ਟੂਲ endpoints (create task, list tasks, update task). LLM ਵਿਹੇਵਿਅਰ ਨੂੰ ਇੱਕ ਪਤਲਾ ਪਰਤ ਰੱਖੋ: system instructions, tool schema, ਅਤੇ guardrails। ਫਿਰ prompts ਅਤੇ UI ਨੂੰ ਇੱਕੱਠੇ ਦੁਹਰਾਓ: ਜਦੋਂ ਸਹਾਇਕ ਗਲਤ ਧਾਰਨਾ ਲੈਂਦਾ ਹੈ, ਤਾਂ ਵਿਹੇਵਿਅਰ ਟੈਕਸਟ ਸਜੋ ਅਤੇ UX ਵਿੱਚ ਇੱਕ ਪੁਸ਼ਟੀ ਕਦਮ ਸ਼ਾਮਲ ਕਰੋ।
ਉਸ ਤਰ੍ਹਾਂ ਦੀਆਂ ਚੀਜ਼ਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ ਜੋ ਪਰਯੋਗਤੇਜ਼ੀ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਦੀਆਂ ਹਨ: planning mode (ਲਾਗੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸੁਝਾਅ), snapshots ਅਤੇ rollback (ਖਰਾਬ iterations ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਬਹਾਲੀ), ਡਿਪਲੋਇਮੈਂਟ ਅਤੇ ਹੋਸਟਿੰਗ ਨਾਲ ਕਸਟਮ ਡੋਮੇਨ (ਹਿੱਸੇਦਾਰਾਂ ਨੂੰ ਤੇਜ਼ ਪਹੁੰਚ), ਅਤੇ source code export (ਪੂਰੀ ਮਾਲਕੀ ਰੱਖਣ ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਵਾਲੇ ਪਾਈਪਲਾਈਨ ਵੱਲ ਜਾਣ ਲਈ)।
MVP ਤੋਂ ਬਾਹਰ ਸਕੇਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸੁਰੱਖਿਅਤ ਕਰੋ:
ਇਸ ਢਾਂਚੇ ਨਾਲ, Koder.ai (Koder.ai) ਇੱਕ عملي ਤਰੀਕਾ ਹੋ ਸਕਦਾ ਹੈ ਸੰਕਲਪ ਤੋਂ ਕੰਮ ਕਰਨ ਯੋਗ React/Go/PostgreSQL (ਅਤੇ ਬਾਅਦ ਵਿੱਚ Flutter) ਸਹਾਇਕ ਤਕ ਤੇਜ਼ੀ ਨਾਲ ਆਉਣ ਦਾ, ਜਦੋਂ ਕਿ ਵਿਹੇਵਿਅਰ ਨੂੰ ਟੈਸਟਯੋਗ ਅਤੇ ਵਾਪਸੀਯੋਗ ਰੱਖਦੇ ਹੋ।
ਇੱਕ ਮੁੱਖ ਦਰਸ਼ਕ ਅਤੇ ਇੱਕ ਮੁੜ-ਆਉਣ ਵਾਲੀ ਸਮੱਸਿਆ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, ਫਿਰ ਸਹਾਇਕ ਦਾ "ਕਾਮ" ਇੱਕ ਨਤੀਜੇ ਵਜੋਂ ਵਰਣਨ ਕਰੋ.
ਇੱਕ ਮਜ਼ਬੂਤ MVP ਨੌਕਰੀ ਬਿਆਨ ਦਾ ਉਦਾਹਰਣ:
ਜਦੋਂ ਨੌਕਰੀ ਸਪਸ਼ਟ ਹੁੰਦੀ ਹੈ, ਤੁਸੀਂ ਉਹ ਫੀਚਰ ਰੱਦ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਸਿੱਧਾ ਇਸ ਦਾ ਸਹਿਯੋਗ ਨਹੀਂ ਕਰਦੇ।
ਇੱਕ ਜਾਂ ਦੋ ਯੂਜ਼ਰ ਯਾਤਰਾਵਾਂ ਚੁਣੋ ਜੋ ਇੱਕ ਛੋਟੀ ਸੈਸ਼ਨ ਵਿੱਚ ਮੁੱਲ ਦੇਣ। ਲਕੜੀ ਦਾ ਨਿਯਮ: ਉਪਭੋਗੀ 60–120 ਸਕਿੰਟ ਵਿੱਚ ਫਾਇਦਾ ਮਹਿਸੂਸ ਕਰੇ.
ਦੋ ਭਰੋਸੇਯੋਗ MVP ਯਾਤਰਾਵਾਂ:
ਇਹ ਲੂਪ ਬਿਹਤਰ ਹੋਣ ਤੱਕ ਬਾਕੀ ਸਭ ਚੀਜ਼ਾਂ ਵਿਕਲਪੀ ਹਨ।
ਹਰ MVP ਲਈ ਸਪਸ਼ਟ ਨਾਂ-ਲਕੜੇ ਲਿਖੋ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਸਥਿਤੀ ਸੁਰੱਖਿਆ ਵਜੋਂ ਰੱਖੋ.
ਆਮ MVP ਨਾਨ-ਗੋਲਜ਼:
ਇਸ ਨਾਲ ਉਤਪਾਦ ਭਰੋਸੇਯੋਗ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਮੁੱਖ ਰੁਖੀਆਂ ਅਤੇ ਪ੍ਰਾਈਵੇਸੀ ਰਿਸਕ ਘੱਟ ਹੁੰਦੇ ਹਨ।
MVP ਨੂੰ "ਚੈਟ ਦੀ ਗਿਣਤੀ" ਨਾਲ ਨਾ ਮਾਪੋ; ਨਤੀਜਿਆਂ ਮੁੱਖ ਮਾਪੋ.
ਪ੍ਰਾਇਕਟਿਕਲ ਮੈਟ੍ਰਿਕਸ:
ਇਹ ਮੈਟ੍ਰਿਕਸ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਸਹਾਇਕ ਵਾਸਤਵ ਵਿੱਚ ਨਿਸ਼ਚਿਤ ਨੌਕਰੀ ਵਿੱਚ ਮਦਦ ਕਰ ਰਿਹਾ ਹੈ ਜਾਂ ਨਹੀਂ।
ਇੱਕ ਮੁੱਖ ਮਾਡਲ ਅਤੇ ਮੁੱਖ ਸਕ੍ਰੀਨ ਚੁਣੋ:
ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹੋ, ਪਰ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਸਪਸ਼ਟਤਾ UX ਡ੍ਰਿਫਟ ਨੂੰ ਰੋਕਦੀ ਹੈ।
ਕਿਸੇ ਵੀ ਜ਼ਰੂਰੀ ਕਾਰਵਾਈ ਲਈ preview → confirm → execute → undo ਪੈਟਰਨ ਵਰਤੋਂ.
ਅਚਛੇ ਉਦਾਹਰਣ:
ਸਹਾਇਕ ਕਾਰਵਾਈ ਦਾ ਖਾਕਾ ਪੇਸ਼ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਯੂਜ਼ਰ ਨੂੰ ਸਪੱਸ਼ਟ ਮਨਜ਼ੂਰੀ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਤੁਰੰਤ undo ਸੁਵਿਧਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
ਜੋ ਕੁਝ ਡੇਟਾ ਬਦਲਦਾ ਹੈ ਉਸ ਲਈ ਸਖਤ, ਵੇਧ-ਯੋਗ ਐਕਸ਼ਨ ਆਬਜੈਕਟ (ਅਕਸਰ JSON) ਵਰਤੋਂ.
ਮੁਫ਼ਤ-ਪাঠ 'ਤੇ ਨਿਰਭਰ ਕਰਨ ਦੀ ਥਾਂ, ਫ਼ੀਲਡਾਂ ਦੀ ਮੰਗ ਕਰੋ ਜਿਵੇਂ:
actiontitleਛੋਟੇ ਸਮੇਂ ਦੀ ਸੰਦਰਭ ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਦੀ ਮੈਮੋਰੀ ਨੂੰ ਵੱਖਰਾ ਕਰੋ.
ਮੈਮੋਰੀ ਪਾਰਦਰਸ਼ੀ ਬਣਾਓ: ਯੂਜ਼ਰ ਨੂੰ ਵੇਖਣ, ਸੰਪਾਦਿਤ ਕਰਨ, ਐਕਸਪੋਰਟ ਅਤੇ ਮਿਟਾਉਣ ਦੀ ਆਸਾਨੀ ਹੋਵੇ।
ਟਾਸਕਾਂ/ਨੋਟਾਂ ਨੂੰ ਪਹਿਲ-ਕਲਾਸ ਐਨਟੀਟੀ ਰੱਖੋ, ਨਾ ਕਿ ਸਿਰਫ ਚੈਟ ਟੈਕਸਟ.
ਘੱਟੋ-ਘੱਟ ਕਾਰਗਰ ਟੇਬਲਾਂ:
ਪ੍ਰੋਵੇਨੈਂਸ ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਵੱਖ-ਵੱਖ ਕਾਰਵਾਈਆਂ ਦੀ ਵਜ੍ਹਾ ਸਮਝਾ ਸਕੋ:
ਪ੍ਰੋੰਪਟ ਅਤੇ ਟੂਲ ਬਿਹੇਵਿਅਰ ਨੂੰ ਕੋਡ ਵਾਂਗ ਵਰਤੋਂ: ਵਰਜ਼ਨ, ਟੈਸਟ, ਅਤੇ ਰੋਲਬੈਕ.
ਭਰੋਸੇਯੋਗਤਾ ਅਭਿਆਸ:
Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਤੇਜ਼ ਇਤਰੇਸ਼ਨ ਲਈ ਸਨੇਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਦਿੱਤੇ ਹਨ, ਜੋ React/Flutter UI ਅਤੇ Go/PostgreSQL APIs ਨੂੰ ਇਕੱਠੇ ਸੁਧਾਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ।
due_attimezonepriority ਜਾਂ recurrenceਫਿਰ ਸਰਵਰ-ਸਾਈਡ ਤੇ ਵੈਧਤਾ ਕਰੋ ਅਤੇ ਗੁੰਝਲਦਾਰ/ਗੁੰਮਰਾਹ ਕਰਨ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਲਈ ਦੁਬਾਰਾ ਪੁੱਛੋ।
source_message_id ਬਣਾਈਆਂ ਆਈਟਮਾਂ 'ਤੇuser/assistant/system)tool_run_id ਜੇ ਤੂੰ tools/agents ਵਰਤਣਾ ਹੈਇਹ debugging ਅਤੇ undo ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।