09 ਮਾਰਚ 2026·8 ਮਿੰਟ
ਪਹਿਲੇ ਪ੍ਰਾਂਪਟ ਕਿਉਂ ਅਸਫਲ ਹੁੰਦੇ ਹਨ: ਸੰਦਰਭ ਚਾਲਾਕ ਬੋਲਣ ਤੋਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੈ
ਪਤਾ ਲਗਾਓ ਕਿ ਪਹਿਲੇ ਪ੍ਰਾਂਪਟ ਅਕਸਰ ਕਿਉਂ ਫੇਲ ਹੁੰਦੇ ਹਨ: ਬਹੁਤ ਵਾਰੀ ਗਲਤੀ ਸ਼ਬਦਾਂ ਦੀ ਨਹੀ, ਸਗੋਂ ਨਮੂਨਾ ਡੇਟਾ, ਯੂਜ਼ਰ ਭੂਮਿਕਾਵਾਂ, ਅਤੇ ਅਪਤੀਆਂ ਦੀ ਘਾਟ ਹੁੰਦੀ ਹੈ।
ਪਹਿਲਾ ਪ੍ਰਾਂਪਟ ਅਕਸਰ ਕਿਉਂ ਨਾਕਾਮ ਰਹਿੰਦਾ ਹੈ
ਜੋ ਵਿਅਕਤੀ ਪ੍ਰਾਂਪਟ ਲਿਖ ਰਿਹਾ ਹੈ ਉਸ ਲਈ ਪਹਿਲਾ ਪ੍ਰਾਂਪਟ ਸਪਸ਼ਟ ਲੱਗ ਸਕਦਾ ਹੈ ਪਰ ਫਿਰ ਵੀ ਉਹ ਨਤੀਜੇ ਨਾਲ ਮਿਲ ਨਹੀਂ ਪੈਂਦਾ। ਮੁੱਦਾ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਬਦਬੰਦੀ ਨਹੀਂ ਹੁੰਦਾ — ਮੁੱਦਾ ਇਸ ਗੱਲ ਦਾ ਹੁੰਦਾ ਹੈ ਕਿ ਬੇਨਤੀ ਦੇ ਪਿੱਛੇ ਕਿਹੜੇ ਤੱਥ ਗੈਰਹਾਜ਼ਰ ਹਨ।
ਲੋਕ ਅਕਸਰ ਕਮਜ਼ੋਰ ਪ੍ਰਾਂਪਟ ਨੂੰ ਹੋਰ ਹੋਸ਼ਿਆਰ, ਲੰਬਾ ਜਾਂ ਪੌਲਿਸ਼ ਕੀਤਾ ਹੋਇਆ ਬਣਾਕੇ ਠੀਕ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ। ਪਰ ਵਧੀਆ ਵਾਕ-ਰਚਨਾ ਉਸ ਜਾਣਕਾਰੀ ਦੀ ਭੂਮਿਕਾ ਨਹੀਂ ਨਿਭਾ ਸਕਦੀ ਜੋ ਪਹਿਲਾਂ ਹੀ ਸ਼ਾਮਲ ਹੀ ਨਹੀਂ ਸੀ। ਜਦੋਂ ਮਾਡਲ ਕੋਲ ਕਾਫ਼ੀ ਸੰਦਰਭ ਨਹੀਂ ਹੁੰਦਾ, ਤਾਂ ਵੀ ਉਸਨੂੰ ਜਵਾਬ ਦੇਣਾ ਹੁੰਦਾ ਹੈ—ਅਤੇ ਉਹ ਖਾਲੀਆਂ ਠਹਿਰਾਂ ਨੂੰ ਸੰਭਾਵਤ ਅਨੁਮਾਨਾਂ ਨਾਲ ਭਰ ਲੈਂਦਾ ਹੈ।
ਇਹ ਅਨੁਮਾਨ ਸ਼ੁਰੂ ਵਿੱਚ ਲਾਭਕਾਰੀ ਲੱਗ ਸਕਦੇ ਹਨ, ਪਰ ਬਾਅਦ ਵਿੱਚ ਦਿਖਾਈ ਦੇਣ ਵਾਲੀਆਂ ਖਾਮੀਆਂ ਸਾਹਮਣੇ ਆਉਂਦੀਆਂ ਹਨ। ਨਤੀਜਾ ਤੁਹਾਡੇ ਉਪਭੋਗਤਿਆਂ, ਤੁਹਾਡੇ ਡੇਟਾ ਜਾਂ ਉਸ ਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਹਾਡਾ ਉਤਪਾਦ ਸੰਭਾਲਦਾ ਹੈ।
"ਮੇਰੀ ਟੀਮ ਲਈ ਇੱਕ CRM ਬਣਾਓ" ਵਰਗਾ ਬਿਆਨ ਪਰਿਆਪਤ ਲੱਗਦਾ ਹੈ, ਪਰ ਇਹ ਬੁਨਿਆਦੀ ਸਵਾਲ ਛੱਡ ਦਿੰਦਾ ਹੈ:
- ਇੱਕ ਗਾਹਕ ਰਿਕਾਰਡ ਕਿਵੇਂ ਦਿਖਦਾ ਹੈ?
- ਰੋਜ਼ਾਨਾ ਇਹ ਸਿਸਟਮ ਕੌਣ ਵਰਤਦਾ ਹੈ?
- ਜਦੋਂ ਡੇਟਾ ਅਧੂਰਾ ਜਾਂ ਅਸਧਾਰਨ ਹੋਵੇ ਤਾਂ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ?
- ਕਿਸ ਕਾਰਵਾਈ ਨੂੰ ਕਿਸ ਭੂਮਿਕਾ ਦੁਆਰਾ ਰੋਕਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ?
ਇਨ੍ਹਾਂ ਵੇਰਵਿਆਂ ਤੋਂ ਬਿਨਾਂ ਮਾਡਲ ਤੁਹਾਡੀ ਸਮੱਸਿਆ ਹੱਲ ਨਹੀਂ ਕਰ ਰਿਹਾ—ਉਹ ਇਸਦੀ ਇੱਕ ਔਸਤ ਵਰਜਨ ਹੱਲ ਕਰ ਰਿਹਾ ਹੈ।
ਇਹ ਗੱਲ ਚੈਟ-ਆਧਾਰਿਤ ਐਪ ਬਿਲਡਰਾਂ ਵਿੱਚ ਵੀ ਸਾਹਮਣੇ ਆਉਂਦੀ ਹੈ। ਜੇ ਕੋਈ Koder.ai ਨੂੰ ਇੱਕ ਅੰਦਰੂਨੀ ਟੂਲ ਬਣਾਉਣ ਲਈ ਕਹਿੰਦਾ ਹੈ, ਤਾਂ ਪਲੇਟਫਾਰਮ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਪਹਿਲਾ ਨਤੀਜਾ ਫਿਰ ਵੀ ਮਿਲੇ ਹੋਏ ਸੰਦਰਭ 'ਤੇ ਨਿਰਭਰ ਕਰੇਗਾ। ਜੇ ਪ੍ਰਾਂਪਟ ਵਿੱਚ ਨਮੂਨਾ ਰਿਕਾਰਡ, ਟੀਮ ਭੂਮਿਕਾਵਾਂ ਜਾਂ ਖਾਸ ਕੇਸ ਦਰਜ ਨਹੀਂ ਕੀਤੇ ਗਏ, ਤਾਂ ਐਪ ਸਾਫ਼-ਸੁਥਰਾ ਤਾਂ ਲੱਗ ਸਕਦਾ ਹੈ ਪਰ ਮਹੱਤਵਪੂਰਨ ਹਿੱਸੇ ਗਲਤ ਹੋ ਸਕਦੇ ਹਨ।
ਕਮਜ਼ੋਰ ਪਹਿਲੇ ਨਤੀਜੇ ਹਮੇਸ਼ਾਂ ਇਹ ਦੱਸਦੇ ਨਹੀਂ ਕਿ AI ਇਹ ਕੰਮ ਨਹੀਂ ਕਰ ਸਕਦਾ—ਅਕਸਰ ਇਹ ਦੱਸਦੇ ਹਨ ਕਿ ਕੰਮ ਦੀ ਵਿਆਖਿਆ ਹੀ ਘੱਟ ਸੀ। ਮਾਡਲ ਨੇ ਸਿਰਫ਼ ਸਿਰਲੇਖ ਪੜ੍ਹਿਆ, ਕੰਮ ਦੇ ਚਲਦੇ-ਫਿਰਦੇ ਵੇਰਵੇ ਨਹੀਂ।
ਵਾਸਤਵਿਕ ਤਬਦੀਲੀ ਉਦੋਂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਪੁੱਛਣਾ ਛੱਡ ਦਿੰਦੇ ਹੋ, "ਮੈਂ ਇਸਨੂੰ ਹੋਰ ਸੁਨਦਰ ਤਰੀਕੇ ਨਾਲ ਕਿਵੇਂ ਬਿਆਨ ਕਰਾਂ?" ਅਤੇ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹੋ, "ਮੈਂ ਕਿਹੜੀਆਂ ਗੱਲਾਂ ਮੰਨ ਰਿਹਾ/ਰਹੀ ਹਾਂ ਕਿ ਮਾਡਲ ਪਹਿਲਾਂ ਹੀ ਜਾਣਦਾ ਹੈ?" ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕੋ ਵਾਕ ਨੂੰ ਪੰਜ ਵਾਰੀ ਦੁਹਰਾਉਣ ਦੀ ਬਜਾਏ ਜ਼ਿਆਦਾ ਤੇਜ਼ ਨਤੀਜੇ ਲਾਂਦਾ ਹੈ।
ਉਹ ਤਿੰਨ ਤੱਤ ਜੋ ਲੋਕ ਛੱਡ ਜਾਂਦੇ ਹਨ
ਜ਼ਿਆਦਤਰ ਪਹਿਲੇ ਪ੍ਰਾਂਪਟ ਫੇਲ ਇਸ ਲਈ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਸੰਦਰਭ ਘਟ ਹੁੰਦਾ ਹੈ, ਨਾ ਕਿ ਕਿਉਂਕਿ ਸ਼ਬਦ ਗਲਤ ਹਨ। ਲੋਕ ਵਾਕ-ਰਚਨਾ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਦੇ ਹਨ, ਹੋਰ ਰੁਖ ਅਪਣਾਉਂਦੇ ਹਨ, ਅਤੇ ਵਾਧੂ ਨਿਰਦੇਸ਼ ਜੋੜਦੇ ਹਨ। ਪਰ ਵੱਡੀ ਸਮੱਸਿਆ ਇਹ ਹੁੰਦੀ ਹੈ ਕਿ ਮਾਡਲ ਦੇ ਕੋਲ ਅਜੇ ਵੀ ਜਵਾਬ ਦੇਣ ਦੇ ਬਹੁਤ ਸਾਰੇ ਢੰਗ ਬਚ ਜਾਂਦੇ ਹਨ। ਤਿੰਨ ਕਿਸਮ ਦਾ ਸੰਦਰਭ ਉਹ ਚੋਣਾਂ ਜ਼ੁੜੀਆਂ ਘਟਾ ਦਿੰਦੇ ਹਨ: ਅਸਲੀ ਸੈਂਪਲ ਡੇਟਾ, ਉਪਭੋਗਤਾ ਭੂਮਿਕਾਵਾਂ, ਅਤੇ ਅਪਤੀਆਂ।
ਸੈਂਪਲ ਡੇਟਾ ਕੰਮ ਨੂੰ ਸੰਕੁਚਿਤ ਕਰ ਦਿੰਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਗਾਹਕ ਡੈਸ਼ਬੋਰਡ ਮੰਗਦੇ ਹੋ, ਤਾਂ ਉਹ ਦਸ ਵੱਖ-ਵੱਖ ਚੀਜ਼ਾਂ ਦਾ ਮਤਲਬ ਹੋ ਸਕਦਾ ਹੈ। ਕੁਝ ਉਦਾਹਰਨੀ ਰਿਕਾਰਡ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਕਿਹੜੇ ਫੀਲਡ ਮੌਜੂਦ ਹਨ, ਕਿਹੜੇ ਗੰਦਲੇ ਹਨ, ਅਤੇ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਕੀ ਮਹੱਤਵਪੂਰਨ ਹੈ।
ਉਪਭੋਗਤਾ ਭੂਮਿਕਾਵਾਂ ਉਤਨੀ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੀਆਂ ਹਨ। ਇੱਕ ਫਾਊਂਡਰ, ਸੇਲਜ਼ ਰੈਪ, ਮੈਨੇਜਰ, ਅਤੇ ਸਪੋਰਟ ਏਜੰਟ ਨੂੰ ਇੱਕੋ ਜਿਹੀ ਸਕਰੀਨ, ਟੋਨ, ਜਾਂ ਪਰਮਿਸ਼ਨਾਂ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। ਜੇ ਤੁਸੀਂ ਭੂਮਿਕਾਵਾਂ ਛੱਡ ਦਿਓਗੇ, ਤਾਂ ਮਾਡਲ ਸਭ ਨੂੰ ਮਿਲਾ ਕੇ ਇੱਕ ਅਧੂਰਾ ਜਵਾਬ ਤਿਆਰ ਕਰੇਗਾ ਜੋ ਕਿਸੇ ਲਈ ਵੀ ਢੀਠੀ ਤਰ੍ਹਾਂ ਠੀਕ ਨਹੀਂ ਬੈਠਦਾ।
ਅਪਤੀਆਂ ਉਹ ਹਿੱਸਾ ਹਨ ਜਿਸਨੂੰ ਲੋਕ ਬਹੁਤ ਦੇਰ ਨਾਲ ਨੋਟਿਸ ਕਰਦੇ ਹਨ। ਜੇ ਭੁਗਤਾਨ ਫੇਲ ਹੋ ਜਾਵੇ, ਕੋਈ ਫੀਲਡ ਗਾਇਬ ਹੋਵੇ, ਕਿਸੇ ਯੂਜ਼ਰ ਕੋਲ ਕੇਵਲ ਪੜ੍ਹਨ ਦੀ ਆਗਿਆ ਹੋਵੇ, ਜਾਂ ਦੋ ਰਿਕਾਰਡ ਟਕਰਾਅ ਵਿੱਚ ਹੋਣ, ਤਾਂ ਕੀ ਹੋਵੇ? ਇਨ੍ਹਾਂ ਨਿਯਮਾਂ ਬਿਨਾਂ, ਮਾਡਲ ਅਨੁਮਾਨ ਨਾਲ ਭਰ ਦਿੰਦਾ ਹੈ।
ਕਿਸੇ ਨੂੰ Koder.ai ਵਿੱਚ ਚੈਟ ਰਾਹੀਂ ਸਾਦਾ CRM ਬਣਾਉਣ ਦੀ ਸੂਝ ਲਵੋ। "ਮੇਰੀ ਟੀਮ ਲਈ CRM ਬਣਾਓ" ਵਿਆਪਕ ਹੈ। ਪਰ ਜੇ ਤਿੰਨ ਨਮੂਨਾ ਸੰਪਰਕ ਜੋੜੋ, ਦੱਸੋ ਕਿ ਸੇਲਜ਼ ਰੈਪ ਡੀਲਾਂ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰ ਸਕਦੇ ਹਨ ਜਦਕਿ ਮੈਨੇਜਰ ਰਿਪੋਰਟ ਨਿਰਯਾਤ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਇਹ ਵੀ ਦੱਸੋ ਕਿ ਜੇ ਲੀਡ ਕੋਲ ਈਮੇਲ ਨਹੀਂ ਹੈ ਤਾਂ ਕੀ ਹੋਵੇ—ਤਾਂ ਨਤੀਜਾ ਕਾਫੀ ਜਿਆਦਾ ਉਪਯੋਗੀ ਬਣ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਮਾਡਲ ਹੁਣ ਇੱਕ ਨਿਰਧਾਰਿਤ ਸਮੱਸਿਆ ਹੱਲ ਕਰ ਰਿਹਾ ਹੈ ਨਾ ਕਿ ਕੋਈ ਕਲਪਨਾ।
ਇਹ ਵੇਰਵੇ ਪ੍ਰਾਂਪਟ ਨੂੰ ਬੇਕਾਰ ਲੰਬੇ ਨਹੀਂ ਬਣਾਉਂਦੇ; ਉਹ ਕੰਮ ਨੂੰ ਹੋਰ ਛੋਟਾ, ਸਪਸ਼ਟ ਅਤੇ ਘੱਟ ਗਲਤ-ਫਹਮੀ ਵਾਲਾ ਬਣਾਉਂਦੇ ਹਨ।
ਸੈਂਪਲ ਡੇਟਾ ਧੁੰਦਲੇ ਬੇਨਤੀਆਂ ਨੂੰ ਵਾਸਤਵਿਕ ਬਣਾਉਂਦਾ ਹੈ
ਜਦੋਂ ਮਾਡਲ ਤੁਹਾਡੇ ਡੇਟਾ ਨੂੰ ਅਸਲ ਰੂਪ ਵਿੱਚ ਵੇਖ ਸਕਦਾ ਹੈ, ਪ੍ਰਾਂਪਟ ਕਾਫ਼ੀ ਬਿਹਤਰ ਹੋ ਜਾਂਦੀ ਹੈ। ਬਹੁਤ ਲੋਕ ਕੰਮ ਦਾ ਵਰਣਨ ਤਾਂ ਕਰਦੇ ਹਨ ਪਰ ਕਦੇ ਵੀ ਕੱਚਾ ਸਮੱਗਰੀ ਨਹੀਂ ਦਿਖਾਉਂਦੇ।
ਜੇ ਤੁਸੀਂ ਇੱਕ ਸੰਖੇਪ, ਇੱਕ ਸਾਰ, ਇੱਕ ਟੇਬਲ, ਜਾਂ ਕੁਝ ਸਾਫ਼-ਸੁਥਰੇ ਕਰਨ ਵਾਲਾ ਨਿਯਮ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ 3 ਤੋਂ 5 ਛੋਟੇ ਉਦਾਹਰਨ ਜੋ ਅਸਲ ਚੀਜ਼ਾਂ ਵਰਗੀਆਂ ਹੋਵਣ ਸ਼ਾਮਲ ਕਰੋ। ਉਹ ਗੋਪਨੀਯ ਨਹੀਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਤੇ ਨਾ ਹੀ ਪਰਫੈਕਟ—ਸਿਰਫ਼ ਇਨਪੁਟ ਦੀ ਆਕਾਰ-ਅਕਾਰ ਦਿਖਾਉਣ ਲਈ ਕਾਫ਼ੀ ਹੁੰਦੀਆਂ ਹਨ।
ਉਦਾਹਰਨ ਵਜੋਂ, ਇੱਕ ਫਾਊਂਡਰ ਜੋ Koder.ai ਵਿੱਚ ਇੱਕ ਸਧਾਰਣ CRM ਬਣਾਉ ਰਿਹਾ ਹੈ, ਲੀਡ ਸਕੋਰਿੰਗ ਨਿਯਮ ਮੰਗ ਸਕਦਾ ਹੈ। "ਨਵੀਆਂ ਲੀਡਾਂ ਨੂੰ urgence ਅਤੇ ਬਜਟ ਆਧਾਰ 'ਤੇ ਸਕੋਰ ਕਰੋ" ਸੁਨਦਰ ਲੱਗਦਾ ਹੈ, ਪਰ ਫਿਰ ਵੀ ਕਾਫ਼ੀ ਅਨਿਸ਼ਚਿਤਤਾ ਰਹਿੰਦੀ ਹੈ। ਇੱਕ ਵਧੀਆ ਪ੍ਰਾਂਪਟ ਵਿੱਚ ਕੁਝ ਨਮੂਨਾ ਲੀਡਾਂ ਹੋਣਗੀਆਂ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਕੰਪਨੀ ਆਕਾਰ, ਬਜਟ ਰੇਂਜ, ਮੰਗੀ ਗਈ ਵਿਸ਼ੇਸ਼ਤਾ, ਅਤੇ ਟਾਈਮਲਾਈਨ ਵਰਗੇ ਫੀਲਡ ਹੋਣ।
ਚੰਗਾ ਸੈਂਪਲ ਡੇਟਾ ਆਮ ਤੌਰ 'ਤੇ ਚਾਰ ਚੀਜ਼ਾਂ ਦਿਖਾਉਂਦਾ ਹੈ:
- ਉਹ ਆਮ ਕੇਸ ਦਿਖਾਉਂਦਾ ਹੈ ਜੋ ਮਾਡਲ ਵੱਧਤਰ ਵੇਖੇਗਾ
- ਇੱਕ ਅਜਿਹਾ ਕੇਸ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ ਜੋ ਅਜੀਬ ਹੋਵੇ, ਜਿਵੇਂ ਕੋਈ ਗਾਇਬ ਫੀਲਡ ਜਾਂ ਗੰਦਲੀ ਨੋਟ
- ਸਧਾਰਣ ਨਕਲੀ ਨਾਮ ਅਤੇ ਨੰਬਰ ਵਰਤਦਾ ਹੈ
- ਤੁਸੀਂ ਜੋ ਫੋਰਮੈਟ ਵਾਪਸ ਚਾਹੁੰਦੇ ਹੋ ਉਹੀ ਨਮੂਨਾ ਮਿਲਦਾ ਹੈ
ਆਖਰੀ ਪੁਆਇੰਟ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਇਨਪੁਟ ਸਪੋਰਟ ਟਿਕਟਾਂ ਦੀ ਸੂਚੀ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਲਈ ਆਈਡੀਆਲ ਆਉਟਪੁਟ ਪ੍ਰਾਇਰਟੀ, ਮਾਲਿਕ, ਅਤੇ ਅਗला ਕਦਮ ਵਾਲੀ ਟੇਬਲ ਹੈ, ਤਾਂ ਇਕ ਉਦਾਹਰਨ ਉਸ ਸਰਚਨਾ ਵਿੱਚ ਦਿਖਾਓ। ਮਾਡਲ ਅਕਸਰ ਉਸ ਪੈਟਰਨ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ।
ਇੱਕ ਕਮਜ਼ੋਰ ਪ੍ਰਾਂਪਟ ਕਹਿੰਦੀ ਹੈ, "ਇਹ ਆਰਡਰਾਂ ਨੂੰ ਵਿਵਸਥਿਤ ਕਰੋ।" ਇੱਕ ਮਜ਼ਬੂਤ ਪ੍ਰਾਂਪਟ ਕਹਿੰਦੀ ਹੈ, "ਹੇਠਾਂ ਦਿੱਤੇ ਉਦਾਹਰਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਹਰ ਆਰਡਰ ਨੂੰ JSON ਵਿੱਚ ਬਦਲੋ ਜਿਸ ਵਿੱਚ customer_name, item_count, rush, ਅਤੇ notes ਹੋਣ।" ਹੁਣ ਕੰਮ ਨਿਰਧਾਰਿਤ ਹੋ ਗਿਆ ਹੈ।
ਸੈਂਪਲ ਡੇਟਾ ਛੁਪੇ ਹੋਏ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਵੀ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਵਿਖਾ ਦਿੰਦਾ ਹੈ। ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਕੁਝ ਐਨਟਰੀਆਂ ਵਿੱਚ ਤਾਰੀਖ ਵਰਤੀ ਗਈ ਹੈ, ਹੋਰ "ASAP" ਲਿਖਦੇ ਹਨ, ਅਤੇ ਇਕ ਗਾਹਕ ਨੇ ਕੀਮਤ ਖਾਲੀ ਛੱਡੀ। ਜਦੋਂ ਇਹ ਕੇਸ ਦਿਖਾਈ ਦੇਂਦੇ ਹਨ, ਤਾਂ ਮਾਡਲ ਉਹਨਾਂ ਨੂੰ ਜ਼ਿਆਦਾ ਭਰੋਸੇਯੋਗ ਢੰਗ ਨਾਲ ਸੰਭਾਲ ਸਕਦਾ ਹੈ ਨਾ ਕਿ ਬੇਸੁਧ ਅਨੁਮਾਨ ਲੈ ਕੇ।
ਉਪਭੋਗਤਾ ਭੂਮਿਕਾਵਾਂ ਸਹੀ ਜਵਾਬ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ
ਜੇ ਮਾਡਲ ਨਹੀਂ ਜਾਣਦਾ ਕਿ ਜਵਾਬ ਕਿਸ ਲਈ ਹੈ, ਤਾਂ ਉਹ ਸਹੀ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦਾ। ਇੱਕ ਫਾਊਂਡਰ, ਇੱਕ ਮੈਨੇਜਰ, ਅਤੇ ਇੱਕ ਗਾਹਕ ਇਕੋ ਜਿਹੇ ਡੈਸ਼ਬੋਰਡ ਦੀ ਮੰਗ ਕਰ ਸਕਦੇ ਹਨ ਪਰ ਹਰੇਕ ਨੂੰ ਬਹੁਤ ਵੱਖਰੀਆਂ ਚੀਜ਼ਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ ਕਹਿੰਦੇ ਹੋ, "ਪ੍ਰੋਜੈਕਟ ਡੈਸ਼ਬੋਰਡ ਬਣਾਓ," ਤਾਂ AI ਨੂੰ অনুমਾਨ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਕਿ ਹਰ ਵਿਅਕਤੀ ਨੂੰ ਕੀ ਦੇਖਨਾ ਅਤੇ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਅਨੁਮਾਨ ਅਕਸਰ ਉਟਪਟ ਨੂੰ ਗਲਤ ਰੂਪ ਵਿੱਚ ਲੈ ਜਾਂਦਾ ਹੈ—ਜਿਵੇਂ ਕਿ ਗੰਦੇ ਸਕਰੀਨ, ਗੁੰਮੇਲ ਕਨਟਰੋਲ, ਜਾਂ ਅਜਿਹੀ ਪਹੁੰਚ ਜੋ ਗਲਤ ਲੱਗੇ।
ਜਦੋਂ ਤੁਸੀਂ ਪ੍ਰਾਂਪਟ ਲਿਖਦੇ ਹੋ, ਹਰ ਭੂਮਿਕਾ ਨੂੰ ਨਾਮ ਦਿਓ ਅਤੇ ਉਸ ਦੀਆਂ ਸਪਸ਼ਟ ਸੀਮਾਵਾਂ ਦੱਸੋ। ਕਹੋ ਕਿ ਕੌਣ ਰਿਕਾਰਡ ਬਣਾਉਂਦਾ/ਸੰਪਾਦਿਤ ਕਰਦਾ ਹੈ, ਕੌਣ ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ, ਕੌਣ ਸਿਰਫ਼ ਵੇਖ ਸਕਦਾ ਹੈ, ਅਤੇ ਹਰ ਭੂਮਿਕਾ ਕਿਸ ਚੀਜ਼ ਨੂੰ ਕਦੇ ਨਹੀਂ ਦੇਖ ਸਕਦੀ।
ਇਹ ਆਖਰੀ ਹਿੱਸਾ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਇੱਕ ਗਾਹਕ ਨੂੰ ਆਪਣੀ ਆਰਡਰ ਟਰੇਕ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੋ ਸਕਦੀ ਹੈ ਪਰ ਉਹ ਹੋਰ ਗਾਹਕਾਂ ਦੇ ਡੇਟਾ ਨੂੰ ਕਦੇ ਨਹੀਂ ਵੇਖਣਾ ਚਾਹੀਦਾ। ਇੱਕ ਮੈਨੇਜਰ ਮਨਜ਼ੂਰੀ ਦੇ ਸਕਦਾ ਹੈ ਪਰ ਬਿਲਿੰਗ ਸੈਟਿੰਗਸ ਨਹੀਂ ਬਦਲ ਸਕਦਾ। ਇੱਕ ਐਡਮਿਨ ਨੂੰ ਪੂਰੀ ਦਿੱਖ ਅਤੇ ਅਕਾਉਂਟ ਕੰਟਰੋਲ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।
ਛੋਟਾ ਉਦਾਹਰਨ ਇਸਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ। ਸੋਚੋ ਤੁਸੀਂ Koder.ai ਵਿੱਚ CRM ਜਾਂ ਕਲਾਇੰਟ ਪੋਰਟਲ ਬਣਾ ਰਹੇ ਹੋ। ਜੇ ਤੁਹਾਡਾ ਪ੍ਰਾਂਪਟ ਕਹਿੰਦਾ ਹੈ, "Founder ਰਿਕਾਰਡ ਸਿਰਜ, ਸੰਪਾਦਿਤ, ਮਨਜ਼ੂਰ ਅਤੇ ਸਾਰੇ ਡੀਲ ਵੇਖ ਸਕਦਾ ਹੈ। Sales managers ਆਪਣੀ ਟੀਮ ਦੀਆਂ ਡੀਲਾਂ ਸੰਪਾਦਿਤ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਨਿਰਧਾਰਤ ਸੀਮਾ ਤੱਕ ਛੂਟ ਮਨਜ਼ੂਰ ਕਰ ਸਕਦੇ ਹਨ। Customers ਸਿਰਫ਼ ਆਪਣੇ ਕੋਟਸ ਅਤੇ ਇਨਵਾਇਸ ਵੇਖ ਸਕਦੇ ਹਨ," ਤਾਂ ਪਲੇਟਫਾਰਮ ਪਹਿਲੇ ਤੋਂ ਹੀ ਬਿਹਤਰ ਫੈਸਲੇ ਕਰ ਸਕਦਾ ਹੈ।
ਓਵਰਲੈਪ ਆਮ ਗੱਲ ਹੈ, ਪਰ ਇਹ ਸਪਸ਼ਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਕਈ ਵਾਰ ਇੱਕ ਮੈਨੇਜਰ ਵੀ ਮਨਜ਼ੂਰ ਕਰਨ ਵਾਲਾ ਹੋ ਸਕਦਾ ਹੈ। ਕਈ ਵਾਰ ਸਪੋਰਟ ਲੀਡ ਗਾਹਕ ਰਿਕਾਰਡ ਸੰਪਾਦਿਤ ਕਰ ਸਕਦਾ ਹੈ ਪਰ ਉਹਨਾਂ ਨੂੰ ਨਿਰਯਾਤ ਦੀ ਆਗਿਆ ਨਹੀਂ ਹੋਊਣੀ ਚਾਹੀਦੀ। ਜੇ ਦੋ ਭੂਮਿਕਾਵਾਂ ਸ਼ੇਅਰ ਕਰਦੀਆਂ ਹਨ, ਤਾਂ ਦੱਸੋ। ਜੇ ਕਿਸੇ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਤਰੀਕੇ ਵਿੱਚ ਵੱਖਰਾ ਹੈ, ਤਾਂ ਉਸਦਾ ਜ਼ਿਕਰ ਕਰੋ।
ਚੰਗੇ ਪ੍ਰਾਂਪਟ ਸਿਰਫ਼ ਫੀਚਰ ਵੇਰਵਾ ਨਹੀਂ ਦਿੰਦੇ—ਉਹ ਜ਼ਿੰਮੇਵਾਰੀ ਵੇਰਵਾ ਦਿੰਦੇ ਹਨ। ਜਦੋਂ ਮਾਡਲ ਇਹ ਜਾਣ ਲੈਂਦਾ ਹੈ ਕਿ ਹਰ ਵਿਅਕਤੀ ਕੌਣ ਹੈ, ਤਾਂ ਸਹੀ ਜਵਾਬ ਦੇਣਾ ਕਾਫੀ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ।
ਅਪਤੀਆਂ ਅਜਿਹੇ ਅਲਬੇ ਲਹਿਜ਼ੇ ਰੋਕਦੀਆਂ ਹਨ
ਅਸਲੀ ਉਦਾਹਰਨਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ
ਕੁਝ ਵਾਸਤਵਿਕ ਰਿਕਾਰਡ ਪੇਸਟ ਕਰੋ ਅਤੇ Koder.ai ਢੰਗ ਸਹੀ ਢਾਂਚਾ ਬਣਾਏਗਾ।
ਇੱਕ ਪ੍ਰਾਂਪਟ ਸਪਸ਼ਟ ਲੱਗ ਸਕਦਾ ਹੈ ਪਰ ਅਸਲ ਡੇਟਾ ਮੈਸੀ ਹੋਣ 'ਤੇ ਡਿੱਠਾ ਹੋ ਸਕਦਾ ਹੈ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਉਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਨਿਰਦੇਸ਼ ਸਿਰਫ਼ ਆਮ ਰਾਹ ਨੂੰ ਕਵਰ ਕਰਦੇ ਹਨ ਪਰ ਅਜਿਹੇ ਕਿਨ੍ਹੇ ਕੇਸ ਨਹੀਂ ਦੱਸਦੇ ਜੋ ਅਸਲ ਵਰਤੋਂ ਵਿੱਚ ਆਉਂਦੇ ਹਨ।
ਜੇ ਤੁਸੀਂ ਵਧੀਆ ਨਤੀਜੇ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਕੇਵਲ ਆਈਡੀਆਲ ਇਨਪੁਟ ਨਹੀਂ ਦੱਸੋ—ਇਹ ਵੀ ਦੱਸੋ ਕਿ ਜਦੋਂ ਕੁਝ ਗਾਇਬ, ਰੀਪੀਟ, ਗਲਤ, ਜਾਂ ਖਾਲੀ ਹੋਵੇ ਤਾਂ ਕੀ ਹੋਵੇ। ਇਹ ਛੋਟੇ ਨਿਯਮ ਅਕਸਰ ਸ਼ਾਨਦਾਰ ਵਰਕਿੰਗ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੇ ਹਨ।
ਇੱਕ ਸਧਾਰਣ CRM ਫਾਰਮ ਬਾਰੇ ਸੋਚੋ। ਇੱਕ ਸਾਫ਼ ਟੈਸਟ ਕੇਸ ਵਿੱਚ ਪੂਰਾ ਨਾਮ, ਈਮੇਲ, ਕੰਪਨੀ, ਅਤੇ ਫੋਨ ਨੰਬਰ ਹੁੰਦੇ ਹਨ। ਅਸਲ ਸਬਮਿਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਇਸਨੇਮਾਂ ਨਹੀਂ ਹੁੰਦੇ। ਕੋਈ ਫੋਨ ਖਾਲੀ ਛੱਡ ਦੇਂਦਾ ਹੈ, ਕਿਸੇ ਨੇ ਇੱਕੋ ਹੀ ਈਮੇਲ ਦੋ ਵਾਰੀ ਦਿੱਤੀ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਤੀਜਾ ਕਿਸੇ ਤਾਰੀਖ ਫੀਲਡ ਵਿੱਚ ਗਲਤ ਡੇਟ ਟਾਈਪ ਕਰਦਾ ਹੈ।
ਕੁਝ ਸਿੱਧੇ ਨਿਯਮ ਬਹੁਤ ਅਕਸਮਾਤੀ ਵਰਤਾਰਿਆਂ ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ:
- ਜੇ ਕੋਈ ਲਾਜ਼ਮੀ ਫੀਲਡ ਗਾਇਬ ਹੈ, ਤਾਂ ਰਿਕਾਰਡ ਨੂੰ ਅਧੂਰਾ ਮਨੋ ਅਤੇ ਮੰਗੋ ਕਿ ਲੋੜੀਂਦਾ ਮੁੱਲ ਪੋਰੇ ਕਰੋ।
- ਜੇ ਇੱਕ ਵਿਕਲਪਿਕ ਫੀਲਡ ਖਾਲੀ ਹੈ, ਤਾਂ ਬਿਨਾਂ ਰੁਕਾਵਟ ਦੇ ਅੱਗੇ ਵਧੋ।
- ਜੇ ਡੁਪਲੀਕੇਟ ਮਿਲਦਾ ਹੈ, ਤਾਂ ਨਵਾਂ ਰਿਕਾਰਡ ਬਣਾਉਣ ਦੀ بجائے ਮੌਜੂਦਾ ਨੂੰ ਅਪਡੇਟ ਜਾਂ ਫਲੈਗ ਕਰੋ।
- ਜੇ ਇਨਪੁਟ ਕਿਸੇ ਫਾਰਮੈਟ ਨਿਯਮ ਨੂੰ ਤੋੜਦਾ ਹੈ, ਤਾਂ ਛੋਟੀ ਗਲਤੀ ਸੰਦੇਸ਼ ਵਾਪਸ ਕਰੋ ਜਿਸ ਵਿੱਚ ਫੀਲਡ ਦਾ ਨਾਮ ਹੋਵੇ।
- ਜੇ ਕੋਈ ਨਤੀਜੇ ਨਹੀਂ ਮਿਲਦੇ, ਤਾਂ ਅਨੁਮਾਨ ਲਗਾਉਣ ਦੀ بجਾਏ ਖਾਲੀ ਸਥਿਤੀ ਦਿਖਾਓ।
ਆਖਰੀ ਬਿੰਦੂ ਆਸਾਨੀ ਨਾਲ ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਬਹੁਤ ਸਾਰੇ ਪ੍ਰਾਂਪਟ ਸਿਸਟਮ ਨੂੰ "ਮਦਦ" ਕਰਨ ਲਈ ਕਹਿੰਦੇ ਹਨ, ਇਸ ਲਈ ਉਹ ਖਾਲੀਆਂ ਠਹਿਰਾਂ ਨੂੰ ਗਲਤ ਅਨੁਮਾਨ ਨਾਲ ਭਰ ਦਿੰਦੇ ਹਨ। ਇੱਕ ਵਧੀਆ ਪ੍ਰਾਂਪਟ ਦੱਸਦਾ ਹੈ ਕਿ ਕਦੋਂ ਰੁਕਣਾ ਹੈ, ਕਦੋਂ ਫਾਲੋ-ਅੱਪ ਸਵਾਲ ਪੁੱਛਣਾ ਹੈ, ਅਤੇ ਕਦੋਂ ਕਾਰਵਾਈ ਤੋਂ ਇਨਕਾਰ ਕਰਨਾ ਹੈ।
ਇਹ ਵੀ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ ਕਿ ਜਦੋਂ ਕੋਈ ਬਿਜ਼ਨਸ ਨਿਯਮ ਟੁੱਟ ਜਾਂਦਾ ਹੈ ਤਾਂ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਉਦਾਹਰਨ ਵਜੋਂ, ਜੇ ਇੱਕ ਰਿਫੰਡ ਦੀ ਬੇਨਤੀ 30 ਦਿਨਾਂ ਤੋਂ ਪੁਰਾਣੀ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਪ੍ਰੋਸੈਸ ਨਾ ਕਰੋ—ਨਿਯਮ ਵੇਰਵਾ ਦਿਓ ਅਤੇ ਮੈਨੁਅਲ ਸਮੀਖਿਆ ਲਈ ਭੇਜੋ। ਜੇ ਕੋਈ ਯੂਜ਼ਰ ਆਪਣੀ ਟੀਮ ਤੋਂ ਬਾਹਰ ਕਿਸੇ ਨੂੰ ਟਾਸਕ ਸੌਂਪਦਾ ਹੈ, ਤਾਂ ਤਬਦੀਲੀ ਅਸ्वीਕਾਰ ਕਰ ਦਿਓ ਅਤੇ ਕਾਰਨ ਦੱਸੋ।
ਤੁਹਾਨੂੰ ਹਰ ਚੀਜ਼ ਦੀ ਭਵਿੱਖਬਾਣੀ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ। ਸਿਰਫ ਕੁਝ ਅਜਿਹੀਆਂ ਅਪਤੀਆਂ ਨੂੰ ਕਵਰ ਕਰੋ ਜੋ ਅਸਲ ਨੁਕਸਾਨ, ਉਲਝਣ, ਜਾਂ ਸਮਾਂ ਜਪਨ ਵਾਲੀਆਂ ਹੋਣ। ਇਹ ਅਕਸਰ ਇੱਕ ਡੈਮੋ ਜੋ ਸਮਾਰਟ ਲੱਗਦਾ ਹੈ ਅਤੇ ਇੱਕ ਵਰਕਫਲੋ ਜਿਸ 'ਤੇ ਲੋਗ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹਨ ਵਿਚਕਾਰ ਦਾ ਫਰਕ ਹੁੰਦਾ ਹੈ।
ਕਦਮ-ਬ-ਕਦਮ ਮਜ਼ਬੂਤ ਪ੍ਰਾਂਪਟ ਲਿਖਣ ਦਾ ਤਰੀਕਾ
ਸਧਾਰਨ ਸ਼ੁਰੂ ਕਰੋ। ਸਭ ਤੋਂ ਵਧੀਆ ਪ੍ਰਾਂਪਟ ਆਮਤੌਰ 'ਤੇ ਇੱਕ ਸਪਸ਼ਟ ਵਾਕ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਕੀ ਨਤੀਜਾ ਚਾਹੀਦਾ ਹੈ ਦੱਸਦਾ ਹੈ—ਨਾ ਕਿ ਲੰਬਾ ਵੇਰਵਾ, ਨਾ ਕੋਈ ਚਾਲਾਕੀ। ਜਿਵੇਂ: ਸਾਈਨਅਪ ਫਲੋ লিখੋ, ਸਹਾਇਤਾ ਟਿਕਟਾਂ ਦਾ ਸਾਰ ਦਿਓ, ਜਾਂ ਸੇਲਜ਼ ਟੀਮ ਲਈ CRM ਯੋਜਨਾ ਬਣਾਓ।
ਫਿਰ ਕ੍ਰਮਵਾਰ ਤੌਰ 'ਤੇ ਘੱਟ-ਘੱਟ ਕੰਮ ਲਈ ਲੋੜੀਂਦਾ ਸੰਦਰਭ ਜੋੜੋ:
- ਨਤੀਜਾ ਸਾਧਾ ਭਾਸ਼ਾ ਵਿੱਚ ਦੱਸੋ। ਕਹੋ ਕਿ ਤੁਸੀਂ AI ਤੋਂ ਕੀ ਉਮੀਦ ਕਰਦੇ ਹੋ ਅਤੇ ਇਹ ਕਿਸ ਲਈ ਹੈ।
- ਨਿਯਮਾਂ ਨੂੰ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਥੋੜਾ ਜਿਹਾ ਅਸਲੀ ਇਨਪੁਟ ਨਮੂਨਾ ਸ਼ਾਮਲ ਕਰੋ।
- ਸ਼ਾਮਲ ਲੋਕਾਂ ਨੂੰ ਨਾਮ ਦਿਓ ਅਤੇ ਹਰ ਕਿਸ ਦੀ ਪਹੁੰਚ/ਜ਼ਿੰਮੇਵਾਰੀ ਦੱਸੋ।
- ਅਪਤੀਆਂ ਸਵੇਰੇ ਹੀ ਦਰਜ ਕਰੋ, ਜਿਵੇਂ ਗਾਇਬ ਡੇਟਾ, ਰੋਕਿਆ ਹੋਇਆ ਐਕਸ਼ਨ, ਅਤੇ ਅਣਪੱਕੇ ਕੇਸ।
- ਪਹਿਲਾ ਡ੍ਰਾਫਟ ਮੰਗੋ, ਫਿਰ ਇੱਕ-ਇੱਕ ਹਿੱਸੇ ਨੂੰ ਸੁਧਾਰੋ।
ਇੱਕ ਛੋਟਾ ਉਦਾਹਰਨ ਦਿਖਾਂਦਾ ਹੈ ਕਿ ਇਹ ਕਿਉਂ ਕੰਮ ਕਰਦਾ ਹੈ। "ਟਾਸਕ ਐਪ ਬਣਾਓ" ਕਹਿਣ ਦੀ ਥਾਂ, ਕਹੋ: "ਪੰਜ-ਵਿਆਕਤੀ ਮਾਰਕੀਟਿੰਗ ਟੀਮ ਲਈ ਟਾਸਕ ਐਪ ਬਣਾਓ। ਮੈਨੇਜਰ ਕੰਮ ਅਸਾਈਨ ਕਰ ਸਕਦਾ ਹੈ। ਟੀਮ ਮੈਂਬਰ ਸਿਰਫ ਆਪਣੇ ਟਾਸਕ ਅਪਡੇਟ ਕਰ ਸਕਦੇ ਹਨ। ਜੇ ਡਿਊ ਡੇਟ ਗਾਇਬ ਹੋਵੇ ਤਾਂ ਟਾਸਕ ਨੂੰ unscheduled ਮਾਰਕ ਕਰੋ। ਇਸ ਸੈਂਪਲ ਡੇਟਾ ਦੀ ਵਰਤੋਂ ਕਰੋ..."
ਇਸ ਵਰਜਨ ਨਾਲ ਮਾਡਲ ਨੂੰ ਕੁਝ ठੋਸ ਮਿਲਦਾ ਹੈ। ਸੈਂਪਲ ਡੇਟਾ ਆਕਾਰ ਦਿਖਾਉਂਦਾ, ਭੂਮਿਕਾਵਾਂ ਸੀਮਾਵਾਂ ਸੈਟ ਕਰਦੀਆਂ, ਅਤੇ ਅਪਤੀਆਂ ਅਜਿਹੀਆਂ ਗਲਤ ਫਰਮੇਸ਼ਨਾਂ ਨੂੰ ਰੋਕਦੀਆਂ ਹਨ।
ਜੇ ਤੁਸੀਂ ਚੈਟ-ਆਧਾਰਿਤ ਬਿੱਲਡਰ ਜਿਵੇਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਕ੍ਰਮ ਪਲੇਟਫਾਰਮ ਨੂੰ ਸਕ੍ਰੀਨਾਂ, ਲਾਜਿਕ, ਜਾਂ ਡੇਟਾਬੇਸ ਸੰਰਚਨਾ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਯੋਜਨਾ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ। ਵਧੀਆ ਪ੍ਰਾਂਪਟ ਆਮਤੌਰ 'ਤੇ ਸ਼ਬਦਾਂ ਦੀ ਨਾ ਹੋ ਕੇ, ਤੱਥਾਂ ਦੇ ਬਾਰੇ ਹੁੰਦੇ ਹਨ।
ਇੱਕ ਰੁੱਖਾ ਉਦਾਹਰਨ
ਐਡਜ ਕੇਸ ਪਹਿਲਾਂ ਹਲ ਕਰੋ
ਡੁਪਲੀਕੇਟ, ਖਾਲੀ ਫੀਲਡ ਅਤੇ ਮਨਜ਼ੂਰੀਆਂ ਵਰਗੀਆਂ ਅਪਤੀਆਂ ਵਰਣਨ ਕਰੋ ਤਾਂ ਕਿ ਤੁਹਾਡੇ ਐਪ ਨੇਜਾਇਜ਼ ਤਰੀਕੇ ਨਾਲ ਵਰਤੋਂ ਨਾ ਕਰੇ।
ਇੱਕ ਫਾਊਂਡਰ ਚੈਟ-ਆਧਾਰਿਤ ਬਿੱਲਡਰ ਨੂੰ "ਸਰਲ ਕਲਾਇੰਟ ਇੰਟੇਕ ਐਪ ਬਣਾਓ" ਕਹਿ ਕੇ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਹੈ।
ਇਹ ਸਪਸ਼ਟ ਲੱਗਦਾ ਹੈ, ਪਰ ਨਤੀਜਾ ਆਮਤੌਰ 'ਤੇ ਜਨਰਿਕ ਹੁੰਦਾ ਹੈ। ਐਪ ਬੁਨਿਆਂਦੀ ਫੀਲਡ ਜਿਵੇਂ ਨਾਮ, ਈਮੇਲ, ਫੋਨ ਅਤੇ ਨੋਟਸ ਸ਼ਾਮਲ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਹਰ ਕਿਸੇ ਲਈ ਇੱਕੋ ਵਰਕਫਲੋ ਵੀ ਬਣਾਉਂਦਾ, ਫਰੰਟ ਡੈੱਸਕ ਸਟਾਫ, ਮੈਨੇਜਰ, ਅਤੇ ਸੇਵਾ ਸਟਾਫ ਵਿਚਕਾਰ ਕੋਈ ਫ਼ਰਕ ਨਹੀਂ ਰੱਖਦਾ।
ਪਹਿਲਾ ਨਤੀਜਾ ਨਿਕਮਮ ਨਹੀਂ ਹੁੰਦਾ—ਇਹ ਸਿਰਫ਼ ਪ੍ਰਾਂਪਟ ਦੀ ਹੱਦਾਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਸਿਸਟਮ ਕੋਲ ਕੋਈ ਨਮੂਨਾ ਗਾਹਕ, ਸਟਾਫ ਭੂਮਿਕਾਵਾਂ, ਜਾਂ ਮੈਸੀ ਹਾਲਤਾਂ ਲਈ ਨੀਤੀਆਂ ਨਹੀਂ ਹੁੰਦੀਆਂ।
ਇੱਕ ਮਜ਼ਬੂਤ ਪ੍ਰਾਂਪਟ ਨਿਮਨਲਿਖਤ ਵੇਰਵੇ ਜੋੜਦਾ ਹੈ:
- ਤਿੰਨ-ਚਾਰ ਆਮ ਗਾਹਕ ਰਿਕਾਰਡ ਨਮੂਨੇ
- ਹਰ ਰੋਜ਼ ਐਪ ਵਰਤਣ ਵਾਲੇ ਲੋਕਾਂ ਦੀਆਂ ਭੂਮਿਕਾਵਾਂ
- ਡੁਪਲੀਕੇਟ, ਗਾਇਬ ਫੀਲਡ, ਅਤੇ ਡਰਾਫਟ ਸਬਮਿਸ਼ਨ ਲਈ ਨੀਤੀਆਂ
ਉਦਾਹਰਨ ਵਜੋਂ, ਪ੍ਰਾਂਪਟ ਕਹਿ ਸਕਦਾ ਹੈ ਕਿ ਫਰੰਟ ਡੈੱਸਕ ਵਰਕਰ ਇੰਟੇਕ ਫਾਰਮ ਬਣਾਉ ਅਤੇ ਸੰਪਾਦਿਤ ਕਰ ਸਕਦਾ ਹੈ; ਮੈਨੇਜਰ ਰਿਕਾਰਡ ਮਨਜ਼ੂਰ ਜਾਂ ਮਰਜ ਕਰ ਸਕਦਾ ਹੈ; ਅਤੇ ਸੇਵਾ ਸਟਾਫ ਨੂੰ ਸਿਰਫ਼ ਨਿਰਧਾਰਿਤ ਗ੍ਰਾਹਕ ਦਿੱਸਣ। ਇਹ ਅਨੁਭਵ ਇੱਕ ਨਵਾਂ ਗਾਹਕ ਜਿਸਦਾ ਪੂਰਾ ਵੇਰਵਾ ਹੋਵੇ, ਇੱਕ ਮੁੜ ਆਉਣ ਵਾਲਾ ਗਾਹਕ ਜਿਸਦਾ ਫੋਨ ਨੰਬਰ ਬਦਲਿਆ ਹੋਵੇ, ਅਤੇ ਇੱਕ ਰੈਫ਼ਰਲ ਜਿਸਦੀ ਜਾਣਕਾਰੀ ਅਧੂਰੀ ਹੋਵੇ—ਇਹ ਤਿੰਨ ਨਮੂਨੇ ਸ਼ਾਮਲ ਹੋ ਸਕਦੇ ਹਨ।
ਫਿਰ ਅਪਤੀਆਂ ਅਸਲ ਫ਼ਰਕ ਬਣਾਉਂਦੀਆਂ ਹਨ। ਜੇ ਉਹੋ ਹੀ ਈਮੇਲ ਜਾਂ ਫੋਨ ਦੋ ਵਾਰੀ ਆਵੇ, ਤਾਂ ਸਟਾਫ ਨੂੰ ਨਵਾਂ ਰਿਕਾਰਡ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਚੇਤਾਵਨੀ ਦਿਖਾਓ। ਜੇ ਫਾਰਮ ਵਿੱਚ ਲਾਜ਼ਮੀ ਵੇਰਵੇ ਨਾ ਹੋਣ, ਤਾਂ ਉਸਨੂੰ ਡਰਾਫਟ ਵਜੋਂ ਸੇਵ ਕਰੋ ਨਾ ਕਿ ਪੂਰਾ ਇਨਟੇਕ ਵਜੋਂ ਦਰਸਾਓ।
ਇਨ੍ਹਾਂ ਵੇਰਵਿਆਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ 'ਤੇ ਅਗਲਾ ਨਤੀਜਾ ਆਮ ਤੌਰ 'ਤੇ ਧੰਨਵਾਦ ਯੋਗ ਹੋ ਜਾਂਦਾ ਹੈ। ਫੀਲਡ ਘੱਟ ਰੈਂਡਮ ਲੱਗਦੇ ਹਨ। ਸਕਰੀਨ ਨੌਕਰਿਆਂ ਨਾਲ ਮਿਲਦੇ ਹਨ। ਵਰਕਫਲੋ ਆਮ ਗਲਤੀਆਂ ਨੂੰ ਬਿਨਾਂ ਉਪਭੋਗਤਾ ਨੂੰ ਹੁਣੇ-ਹੁਣੇ ਨਿਰਕਾਰ ਹੋਣ ਦੇ ਸੰਭਾਲਦਾ ਹੈ।
ਸ਼ਬਦਬੰਦੀ ਬਹੁਤ ਹੋਸ਼ਿਆਰ ਨਹੀਂ ਹੁੰਦੀ—ਸੰਦਰਭ ਹੀ ਅਮੀਰ ਹੁੰਦਾ ਹੈ।
ਸਮਾਂ ਖਰਾਬ ਕਰਨ ਵਾਲੀਆਂ ਆਮ ਗਲਤੀਆਂ
ਬਹੁਤ ਸਾਰੀ ਪ੍ਰਾਂਪਟ ਸਮਾਂ ਇਹ ਸੋਚ ਕੇ ਖਰਾਬ ਹੁੰਦੀ ਹੈ ਕਿ ਕਿਵੇਂ ਚਮਕਦਾਰ ਲਗਣਾ ਹੈ ਨਾ ਕਿ ਕਿਵੇਂ ਸਪਸ਼ਟ ਹੋਣਾ ਹੈ। ਲੋਕ ਪਾਲਿਸ਼ ਕੀਤੇ ਹੋਏ ਨਿਰਦੇਸ਼ ਲਿਖਦੇ ਹਨ ਜਿਵੇਂ ਕਿ ਉਹ ਬੋਰਡਰੂਮ ਨੂੰ ਬ੍ਰੀਫ ਕਰ ਰਹੇ ਹੋਣ, ਪਰ ਮਾਡਲ ਨੂੰ ਫਿਰ ਵੀ ਅਨੁਮਾਨ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਕਿ ਉਹਨਾਂ ਦਾ ਕੀ ਮਤਲਬ ਹੈ।
ਇੱਕ ਸਧਾਰਨ ਪ੍ਰਾਂਪਟ ਜਿਸ ਵਿੱਚ ਅਸਲੀ ਵੇਰਵੇ ਹੋਣ ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਭਲੇ-ਭਲੇ, ਪਰ ਅਸਪਸ਼ਟ ਪ੍ਰਾਂਪਟ ਨਾਲੋਂ ਬਿਹਤਰ ਹੁੰਦੀ ਹੈ। "ਅਜੇਹਾ ਗਾਹਕ ਅੱਪਡੇਟ ਲਿਖੋ ਜੋ ਵਿਹੜੇ ਦੀਆਂ ਸਟੋਰ ਮੈਨੇਜਰਾਂ ਲਈ ਹੋਵੇ" ਇਹ ਪਹਿਲਾਂ ਹੀ "ਪ੍ਰੋਫੈਸ਼ਨਲ ਟੋਨ ਵਿੱਚ ਇੱਕ ਪ੍ਰਭਾਵਸ਼ালী ਸੰਪਰਕ ਦਸਤਾਵੇਜ਼ ਬਣਾਓ" ਤੋਂ ਵਧੀਆ ਹੈ।
ਇੱਕ ਆਮ ਗਲਤੀ ਇਹ ਹੈ ਕਿ ਨਿਯਮਾਂ ਨੂੰ ਢੇਰ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਪਰ ਇੱਕ ਵੀ ਉਦਾਹਰਨ ਨਹੀਂ ਦਿੱਤੀ ਜਾਂਦੀ। ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਫੌਰਮੇਟ, ਟੋਨ, ਜਾਂ ਵੇਰਵੇ ਦੀ ਲੈਵਲ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਛੋਟੀ ਉਦਾਹਰਨ ਦਿਖਾਓ। ਇੱਕ ਛੋਟੀ ਉਦਾਹਰਨ ਪੰਜ ਵਾਧੂ ਲਾਈਨਾਂ ਨਿਰਦੇਸ਼ ਦੇਣ ਨਾਲੋਂ ਤੇਜ਼ੀ ਨਾਲ ਅਨੁਮਾਨ ਘਟਾ ਦਿੰਦੀ ਹੈ।
ਦੂਜੀ ਗਲਤੀ ਇਹ ਹੈ ਕਿ ਭੁੱਲ ਕੇ ਇਹ ਨਹੀਂ ਦੱਸਦੇ ਕਿ ਅਸਲ ਵਿਚ ਕਿਸ ਨੇ ਨਤੀਜੇ ਵਰਤਣੇ ਹਨ। ਫਾਊਂਡਰ, ਸਪੋਰਟ ਏਜੰਟ, ਅਤੇ ਪਹਿਲੀ ਵਾਰੀ ਆਏ ਗਾਹਕ ਲਈ ਇੱਕੋ ਜਵਾਬ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ। ਜੇ ਤੁਸੀਂ ਉਪਭੋਗਤਾ ਭੂਮਿਕਾਵਾਂ ਛੱਡ ਦਿਓ, ਤਾਂ ਨਤੀਜਾ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਸਹੀ ਹੋ ਸਕਦਾ ਹੈ ਪਰ ਦਰਸ਼ਕ ਲਈ ਗਲਤ।
ਇਹ ਐਪ ਬਿਲਡਿੰਗ ਵਿੱਚ ਵੀ ਨਜ਼ਰ ਆਉਂਦਾ ਹੈ। ਜੇ ਪ੍ਰਾਂਪਟ ਕਹਿੰਦਾ "ਟੀਮ ਲਈ ਡੈਸ਼ਬੋਰਡ ਬਣਾਓ" ਪਰ ਕਦੇ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਟੀਮ ਕੌਣ ਹੈ, ਤਾਂ ਨਤੀਜਾ ਭਟਕੀ ਹੋ ਸਕਦਾ ਹੈ। ਸੇਲਜ਼ ਮੈਨੇਜਰ, ਵੇਅਰਹਾਊਸ ਲੀਡ, ਅਤੇ ਖਾਤਾਂਕਾਰੀ—ਤਿੰਨਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਸਕਰੀਨਾਂ, ਸ਼ਬਦਾਂ ਅਤੇ ਕਾਰਵਾਈਆਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਐਜ ਕੇਸ ਇੱਕ ਹੋਰ ਚੁੱਪ ਸਮਾਂ-ਖਾਣ ਵਾਲੀ ਗਲਤੀ ਹੈ। ਟੀਮਾਂ ਅਕਸਰ ਅਪਤੀਆਂ ਨੂੰ ਪਹਿਲੇ ਡ੍ਰਾਫਟ ਤੋਂ ਬਾਅਦ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਦਿੰਦੀਆਂ ਹਨ ਅਤੇ ਫਿਰ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਸੁਧਾਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੀਆਂ ਹਨ। ਇਸ ਨਾਲ ਅਜਿਹੇ ਵਿਵਹਾਰ ਹੁੰਦੇ ਹਨ—ਜਿਵੇਂ ਫਾਰਮ ਨਵੇਂ ਯੂਜ਼ਰਾਂ ਲਈ ਵਧੀਆ ਕੰਮ ਕਰਦੇ ਹਨ ਪਰ ਮੁੜ ਆਉਣ ਵਾਲੇ ਯੂਜ਼ਰਾਂ, ਐਡਮਿਨਾਂ, ਜਾਂ ਅਧੂਰੇ ਡੇਟਾ ਵਾਲਿਆਂ ਲਈ ਫੇਲ।
ਕੁਝ ਮੁੱਖ ਗਲਤੀਆਂ ਜੋ ਫਿਰ-ਫਿਰ ਦੋਹਰਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ:
- ਜੋ ਅਸਲ ਸਮੱਸਿਆ ਸੰਦਰਭ ਦੀ ਘਾਟ ਹੈ ਉਸਨੂੰ ਬਦਲਣ ਦੀ ਬਜਾਏ ਵਾਕ-ਰਚਨਾ ਬਦਲਨਾ
- ਨਿਯਮ ਜੋੜਨਾ ਪਰ ਕੋਈ ਸੈਂਪਲ ਡੇਟਾ ਨਾ ਦੇਣਾ
- ਟੋਨ, ਫੋਰਮੈਟ, ਅਤੇ ਦਰਸ਼ਕ ਨੂੰ ਇਕੱਠੇ ਬਦਲਣਾ
- ਸਿਰਫ਼ ਹੈਪੀ ਪਾਥ ਦੀ ਜਾਂਚ ਕਰਨਾ
- ਨਤੀਜਿਆਂ ਨੂੰ ਸੁਧਾਰਣ ਤੋਂ ਪਹਿਲਾਂ ਅਪਤੀਆਂ ਦੀ ਪਰਿਭਾਸ਼ਾ ਨਾ ਕਰਨੀ
ਆਖਰੀ ਗਲਤੀ ਇਹ ਹੈ ਕਿ ਸੁਧਾਰ ਦੌਰਾਨ ਬਹੁਤ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਇਕੱਠਾ ਬਦਲੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਜੇ ਤੁਸੀਂ ਲਕੜੀ, ਦਰਸ਼ਕ, ਉਦਾਹਰਨ, ਅਤੇ ਪਾਬੰਦੀ—ਸਭ ਕੁਝ ਇੱਕ ਹੀ ਵਾਰੀ ਬਦਲ ਦੇਂਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਪਤਾ ਨਹੀਂ ਲੱਗੇਗਾ ਕਿ ਕਿਹੜਾ ਤੱਤ ਮਦਦ ਕਰ ਰਿਹਾ ਹੈ। ਇੱਕ ਵਾਰ ਵਿੱਚ ਇੱਕ ਵੱਡਾ ਚੀਜ਼ ਬਦਲੋ, ਅਤੇ ਪ੍ਰਾਂਪਟ ਤੇਜ਼ੀ ਨਾਲ ਸੁਧਰੇਗਾ।
ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਤੇਜ਼ چੈੱਕ
ਤਰੀਕਿਆਂ ਨੂੰ ਦੁਹਰਾਉਂਦੇ ਸਮੇਂ ਪ੍ਰਗਟ ਨਹੀਂ ਹੋਂਦੇ ਰਹੋ
ਬਿਹਤਰ ਸੰਦਰਭ ਦੀ ਜਾਂਚ ਕਰਨ ਅਤੇ ਐਪ ਵਰਜਨਾਂ ਦੀ ਤੁਲਨਾ ਕਰਨ ਵੇਲੇ ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਦੀ ਵਰਤੋਂ ਕਰੋ।
ਅਕਸਰ ਪ੍ਰਾਂਪਟ ਸਾਦਾ ਕਾਰਨਾਂ ਕਰਕੇ ਨਾਕਾਮ ਰਹਿੰਦਾ ਹੈ, ਨਾ ਕਿ ਇਸ ਲਈ ਕਿ ਸ਼ਬਦ ਪ੍ਰਯੋਗ ਕਾਫ਼ੀ ਨਹੀਂ ਸੀ। ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਇਸਨੂੰ ਇਕ ਅਣਜਾਣ ਵਿਅਕਤੀ ਵਾਂਗ ਪੜ੍ਹੋ। ਜੇ ਕੋਈ ਵਿਅਕਤੀ ਬਿਨਾ ਪਿੱਛੋਕੜ ਦੇ ਨਹੀਂ ਸਮਝ ਸਕਦਾ ਕਿ ਕੰਮ ਕੀ ਹੈ, ਸਫਲਤਾ ਕਿਵੇਂ ਮਾਪੀ ਜਾਵੇਗੀ, ਅਤੇ ਕੀ ਟਾਲਣਾ ਹੈ, ਤਾਂ ਮਾਡਲ ਅਨੁਮਾਨ ਲਗਾਏਗਾ।
ਇਹ ਗੱਲ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਟੂਲ ਨੂੰ ਚੈਟ ਰਾਹੀਂ ਕਿਸੇ ਐਪ, ਪੰਨਾ, ਜਾਂ ਵਰਕਫਲੋ ਦਾ ਹਿੱਸਾ ਬਣਾਉਣ ਲਈ ਕਹਿੰਦੇ ਹੋ—ਛੋਟੇ ਖੱਲ-ਖੱਲੇ ਪ੍ਰਾਂਪਟ ਪੂਰੇ ਨਤੀਜੇ 'ਚ ਵੱਡੇ ਗੈਪ ਬਣ ਸਕਦੇ ਹਨ।
ਭੇਜਣ-ਤੋਂ-ਪਹਿਲਾਂ ਸਧਾਰਨ ਚੈੱਕਲਿਸਟ
- ਇੱਕ ਸਾਧਾ ਵਾਕ ਵਿੱਚ ਕੰਮ ਦਰਜ ਕਰੋ।
- ਇੱਕ ਜਾਂ ਦੋ ਨਮੂਨਾ ਇਨਪੁਟ ਅਤੇ ਉਮੀਦ ਕੀਤਾ ਹੋਇਆ ਆਉਟਪੁਟ ਸ਼ਾਮਲ ਕਰੋ।
- ਹਰ ਉਪਭੋਗਤਾ ਭੂਮਿਕਾ ਦਾ ਨਾਮ ਦੱਸੋ।
- ਕੁਝ ਅਪਤੀਆਂ ਸ਼ਾਮਲ ਕਰੋ।
- ਕਹੋ ਕਿ ਜੇ ਕੁਝ ਅਸਪਸ਼ਟ ਹੋਵੇ ਤਾਂ ਮਾਡਲ ਨੂੰ ਪਹਿਲਾਂ ਸਵਾਲ ਪੁੱਛਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਨਹੀਂ।
ਆਖਰੀ ਪੁਆਇੰਟ ਅਕਸਰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਬਹੁਤ ਸਾਰੇ ਘਟੀਆ ਨਤੀਜੇ ਇਸ ਲਈ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਮਾਡਲ ਮਦਦਗਾਰ ਬਣਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ ਅਤੇ ਖਾਲੀਆਂ ਠਹਿਰਾਂ ਨੂੰ ਆਪਣੇ ਆਪ ਪੂਰ ਕਰ ਲੈਂਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਉਹ ਰੁਕੇ ਅਤੇ ਸਵਾਲ ਪੁੱਛੇ, ਤਾਂ ਸਪਸ਼ਟ ਦੱਸੋ।
ਇਕ ਸਧਾਰਨ ਟੈਸਟ ਸਹਾਇਕ ਹੈ: ਪ੍ਰਾਂਪਟ ਇਕ ਵਾਰੀ ਪੜ੍ਹ ਕੇ ਦੇਖੋ, ਕੀ ਤੁਸੀਂ ਇਹ ਸਵਾਲਾਂ ਬਿਨਾਂ ਅਨੁਮਾਨ ਦੇ ਜਵਾਬ ਦੇ ਸਕਦੇ ਹੋ?
- ਇਹ ਕਿਸ ਲਈ ਹੈ?
- ਉਹ ਕੀ ਇਨਪੁਟ ਦੇਣਗੇ?
- ਉਮ੍ਹੀਦ ਕੀਤਾ ਹੋਇਆ ਆਉਟਪੁਟ ਕੀ ਹੋਵੇਗਾ?
- ਕੀ ਕਦੇ ਵੀ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ?
- ਜਦੋਂ ਜਾਣਕਾਰੀ ਗਾਇਬ ਹੋਵੇ ਤਾਂ ਮਾਡਲ ਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?
ਜੇ ਕਿਸੇ ਦਾ ਜਵਾਬ ਧੁੰਦਲਾ ਹੈ, ਤਾਂ ਪ੍ਰਾਂਪਟ ਅਜੇ ਵੀ ਘੱਟ ਨਿਰਧਾਰਿਤ ਹੈ। ਕੁਝ ਹੋਰ ਵੇਰਵੇ, ਖ਼ਾਸ ਕਰਕੇ ਸੈਂਪਲ ਡੇਟਾ, ਭੂਮਿਕਾਵਾਂ, ਅਤੇ ਅਪਤੀਆਂ, ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਹੋਰ ਗੁੰਝਲਦਾਰ ਵਾਕ ਲਿਖਣ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਮਦਦਗਾਰ ਹੁੰਦੇ ਹਨ।
ਪ੍ਰਾਇਕਟਿਕ ਅਗਲੇ ਕਦਮ
ਜੇ ਤੁਸੀਂ ਕੱਲ੍ਹ ਵਧੀਆ ਨਤੀਜੇ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਚਮਕਦਾਰ ਵਰਣਨ ਲੱਭਣ ਦੀ ਸ਼ੁਰੂਆਤ ਨਾ ਕਰੋ। ਪਹਿਲਾਂ ਇੱਕ ਦੁਹਰਾਏ ਯੋਗ ਪ੍ਰਾਂਪਟ ਟੈਮਪਲੇਟ ਸੇਵ ਕਰੋ। ਇੱਕ ਸਧਾਰਨ ਢਾਂਚਾ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ: ਲਕ੍ਹ, ਉਪਭੋਗਤਾ ਭੂਮਿਕਾ, ਸੈਂਪਲ ਇਨਪੁਟ, ਉਮੀਦ ਕੀਤਾ ਆਉਟਪੁਟ, ਅਤੇ ਅਪਤੀਆਂ।
ਫਿਰ ਇੱਕ ਛੋਟੀ ਸੰਦਰਭ ਲਾਇਬ੍ਰੇਰੀ ਬਣਾਓ। ਕੁਝ ਅਸਲੀ ਡੇਟਾ ਉਦਾਹਰਨ, ਆਮ ਐਡਜ ਕੇਸ, ਅਤੇ ਪਹਿਲਾਂ ਦੇਖੇ ਗਏ ਗਲਤੀਆਂ ਸੰਭਾਲ ਕੇ ਰੱਖੋ। ਇੱਕ ਸਪੋਰਟ ਰਿਪਲਾਈ ਲਈ ਇਹ ਹੋ ਸਕਦਾ ਹੈ: ਇੱਕ ਆਮ ਟਿਕਟ, ਇੱਕ ਗੁੱਸੇ ਵਾਲਾ ਗਾਹਕ ਸੰਦੇਸ਼, ਅਤੇ ਇੱਕ ਅਜਿਹਾ ਬੇਨਤੀ ਜੋ ਤੁਰੰਤ ਸੌਂਪਣ ਦੀ ਬਜਾਏ escalating ਦੀ ਲੋੜ ਰੱਖਦੀ ਹੋਵੇ।
ਇੱਕ ਲਾਇਣੀ ਰੁਟੀਨ ਸਧਾਰਨ ਹੈ:
- ਇੱਕੋ ਜਿਹੇ ਕਾਰਜਾਂ ਲਈ ਇੱਕੋ ਟੈਂਪਲੇਟ ਦੁਹਰਾਓ
- ਇੱਕ ਜਾਂ ਦੋ ਵਾਸਤਵਿਕ ਨਮੂਨੇ ਜੋੜੋ
- ਸ਼ਾਮਲ ਉਪਭੋਗਤਾ ਭੂਮਿਕਾਵਾਂ ਦਾ ਨਾਮ ਲਵੋ
- ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਅਪਤੀਆਂ ਸ਼ਾਮਲ ਕਰੋ
- ਪਹਿਲਾ ਜਵਾਬ ਦੇਖੋ ਅਤੇ ਲਿਖੋ ਕਿ ਕਿਹੜਾ ਸੰਦਰਭ ਗਾਇਬ ਸੀ
ਆਖਰੀ ਕਦਮ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਜਦੋਂ ਨਤੀਜਾ ਕਮਜ਼ੋਰ ਹੋਵੇ, ਬਹੁਤ ਲੋਕ ਉਸੀ ਨਿਰਦੇਸ਼ ਨੂੰ ਤਿੰਨ ਵਾਰੀ ਦੁਹਰਾਉਂਦੇ ਹਨ। ਤੇਜ਼ ਸਿਖਲਾਈ ਆਮ ਤੌਰ 'ਤੇ ਗੁੰਮੇਲ ਸੰਦਰਭ ਨੂੰ ਸਿੱਧਾ ਕਰਨ ਨਾਲ ਹੁੰਦੀ ਹੈ, ਨਾ ਕਿ ਵਾਕ-ਰਚਨਾ ਫਿਰ ਤੋਂ ਪਾਲਿਸ਼ ਕਰਨ ਨਾਲ।
ਜੇ ਜਵਾਬ ਬਹੁਤ ਜਨਰਿਕ ਲੱਗੇ, ਤਾਂ ਸੈਂਪਲ ਡੇਟਾ ਜੋੜੋ। ਜੇ ਟੋਨ ਜਾਂ ਵੇਰਵਾ ਗਲਤ ਹੈ, ਤਾਂ ਉਪਭੋਗਤਾ ਭੂਮਿਕਾ ਸਪਸ਼ਟ ਕਰੋ। ਜੇ ਅਜਿਹੇ ਕੇਸਾਂ 'ਚ ਫੇਲ ਹੋ ਰਿਹਾ ਹੈ, ਤਾਂ ਆਮ ਅਪਤੀਆਂ ਸਾਫ਼-ਸਾਦਾ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖੋ।
ਆਪਣੇ ਨੋਟ ਛੋਟੇ ਰੱਖੋ। ਹਰ ਮੁੜ-ਦਹਰਾਏ ਕਾਰਜ ਲਈ ਇਕ ਛੋਟੀ ਦਸਤਾਵੇਜ਼ੀ ਰਾਹਤਕ ਹੈ। ਸਮੇਂ ਦੇ ਨਾਲ, ਤੁਸੀਂ ਇੱਕ ਐਸਾ ਪ੍ਰਾਂਪਟ ਸੈੱਟ ਬਣਾਓਗੇ ਜੋ ਭਰੋਸੇਯੋਗ ਅਤੇ ਤੇਜ਼ ਹੋਵੇਗਾ।
ਇਹੀ ਵਿਚਾਰ ਚੈਟ ਰਾਹੀਂ ਸੋਫਟਵੇਅਰ ਬਣਾਉਣ ਵੇਲੇ ਵੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਨਾ ਕਿ ਕੇਵਲ ਲਿਖਤ ਲਈ। Koder.ai ਲੋਕਾਂ ਨੂੰ ਚੈਟ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਵੈੱਬ, ਸਰਵਰ, ਅਤੇ ਮੋਬਾਈਲ ਐਪ ਬਣਾਉਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਪਹਿਲੀ ਬਿਲਡ ਦੀ ਗੁਣਵੱਤਾ ਵੀ ਤੁਹਾਡੇ ਦਿੱਤੇ ਸੰਦਰਭ 'ਤੇ ਬਹੁਤ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਜੇ ਇੱਕ ਫਾਊਂਡਰ CRM ਮੰਗਦਾ ਹੈ ਅਤੇ ਉਹ ਸੈਂਪਲ ਗਾਹਕ ਰਿਕਾਰਡ, ਸੇਲਜ਼ ਰੈਪ ਅਤੇ ਮੈਨੇਜਰ ਲਈ ਰੋਲ ਨੀਤੀਆਂ, ਅਤੇ ਕੁਝ ਅਪਤੀਆਂ ਜਿਵੇਂ ਡੁਪਲੀਕੇਟ ਸੰਪਰਕ ਜਾਂ ਮਨਜ਼ੂਰੀ ਕਦਮ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ, ਤਾਂ ਨਤੀਜਾ ਆਮ ਤੌਰ 'ਤੇ ਬਹੁਤ ਨਜ਼ਦੀਕੀ ਹੁੰਦਾ ਹੈ ਕਿ ਵਪਾਰ ਨੂੰ ਕੀ ਲੋੜ ਹੈ।
ਤੁਹਾਨੂੰ ਦਿਨ ਇਕ ਤੇ ਪਰਫੈਕਟ ਪ੍ਰਾਂਪਟ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਲੋੜ ਨਹੀਂ—ਜੋ ਕੰਮ ਕੀਤਾ ਉਸ ਪ੍ਰਾਂਪਟ ਨੂੰ ਸੇਵ ਕਰੋ, ਕੁਝ ਚੰਗੀਆਂ ਉਦਾਹਰਨਾਂ ਆਪਣੇ ਨਜ਼ਦੀਕ ਰੱਖੋ, ਅਤੇ ਪਹਿਲੇ ਨਤੀਜੇ ਨੂੰ ਛੋਟਾ ਟੈਸਟ ਸਮਝੋ। ਜਦੋਂ ਤੁਸੀਂ ਸਮਝਦੇ ਹੋ ਕਿ ਕਿਹੜਾ ਸੰਦਰਭ ਘਟ ਰਿਹਾ ਹੈ, ਤਾਂ ਹੋਰ ਚਮਕਦਾਰ ਲਫ਼ਜ਼ਾਂ ਦੇ ਪਿੱਛੇ ਦੌੜਨ ਦੀ ਬਜਾਏ ਉਸ ਨੂੰ ਮੁਰੰਮਤ ਕਰੋ। ਅਗਲਾ ਨਤੀਜਾ ਆਮ ਤੌਰ 'ਤੇ ਜ਼ਿਆਦਾ ਤੇਜ਼ੀ ਨਾਲ ਬਿਹਤਰ ਹੋਵੇਗਾ।