AI ਨਾਲ ਬਣੀ ਐਪ ਨੂੰ ਤੋੜੇ ਬਿਨਾਂ ਅੱਗੇ ਕਿਵੇਂ ਸੁਧਾਰੀਏ
AI ਨਾਲ ਬਣੀ ਐਪ ਨੂੰ ਤੋੜੇ ਬਿਨਾਂ ਸੁਧਾਰਨ ਲਈ, ਹਰ ਪ੍ਰੋਂਪਟ ਵਿੱਚ ਇੱਕ ਚੀਜ਼ ਬਦਲੋ, ਪ੍ਰੀਵਿਊ ਵਿੱਚ ਜਾਂਚੋ, ਅਤੇ ਅਗਲੇ ਕਦਮ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਚੈੱਕਪੌਇੰਟ ਸੇਵ ਕਰੋ। ਜੋ ਤੁਸੀਂ ਵੇਖਦੇ ਹੋ ਉਹ ਦੱਸੋ, ਇਹ ਨਹੀਂ ਕਿ ਤੁਹਾਡੇ ਖਿਆਲ ਅਨੁਸਾਰ ਕੋਡ ਕੀ ਕਰਦਾ ਹੈ; ਵੱਡੀਆਂ ਤਬਦੀਲੀਆਂ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਯੋਜਨਾ ਬਣਾਓ; ਅਤੇ ਜਦੋਂ ਕੋਈ ਤਬਦੀਲੀ ਗਲਤ ਹੋ ਜਾਵੇ, ਤਾਂ AI ਨੂੰ ਆਪਣੇ ਹੀ ਫਿਕਸ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਕਹਿਣ ਦੀ ਥਾਂ ਆਖਰੀ ਚੰਗੇ ਵਰਜਨ 'ਤੇ ਰੋਲਬੈਕ ਕਰੋ।
AI ਨਾਲ ਬਣੀ ਐਪ ਦਾ ਪਹਿਲਾ ਵਰਜਨ ਅਕਸਰ ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ ਤਿਆਰ ਹੋ ਜਾਂਦਾ ਹੈ। ਔਖਾ ਹਿੱਸਾ ਪੰਜਾਹਵੀਂ ਤਬਦੀਲੀ ਹੈ, ਜਦੋਂ ਹਰ ਨਵਾਂ ਪ੍ਰੋਂਪਟ ਕੁਝ ਅਜਿਹਾ ਤੋੜ ਸਕਦਾ ਹੈ ਜੋ ਪਹਿਲਾਂ ਕੰਮ ਕਰਦਾ ਸੀ। ਇਹ ਗਾਈਡ ਉਹ ਚੱਕਰ ਹੈ ਜੋ ਇਸਨੂੰ ਰੋਕਦਾ ਹੈ।
ਸੁਧਾਰ ਦਾ ਚੱਕਰ
- ਇੱਕ ਤਬਦੀਲੀ ਚੁਣੋ। ਇੱਕ ਫੀਚਰ, ਇੱਕ ਬੱਗ, ਇੱਕ ਪੇਜ।
- ਉਸਦਾ ਵੇਰਵਾ ਦਿਓ ਇਸ ਰੂਪ ਵਿੱਚ ਕਿ ਵਰਤੋਂਕਾਰ ਕੀ ਵੇਖਦਾ ਅਤੇ ਕਰਦਾ ਹੈ।
- ਵੱਡੀਆਂ ਤਬਦੀਲੀਆਂ ਲਈ, ਪਹਿਲਾਂ ਯੋਜਨਾ ਬਣਾਓ। ਯੋਜਨਾ ਮੰਗੋ, ਪੜ੍ਹੋ, ਫਿਰ ਬਣਾਓ।
- ਨਤੀਜਾ ਜਾਂਚੋ ਪ੍ਰੀਵਿਊ ਵਿੱਚ: ਤਬਦੀਲੀ ਅਤੇ ਉਸਦੇ ਨੇੜੇ ਦੇ ਫਲੋ।
- ਸੇਵ ਕਰੋ ਇੱਕ ਚੈੱਕਪੌਇੰਟ ਜਾਂ ਕਮਿਟ।
- ਦੁਹਰਾਓ।
ਹਰ ਕਦਮ ਇਸ ਲਈ ਹੈ ਕਿ ਤਬਦੀਲੀਆਂ ਛੋਟੀਆਂ ਅਤੇ ਵਾਪਸ ਕੀਤੀਆਂ ਜਾ ਸਕਣ।
ਕਦਮ 1: ਇੱਕ ਛੋਟੀ ਸੂਚੀ ਰੱਖੋ
ਪ੍ਰੋਂਪਟ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖੋ ਕਿ ਤੁਸੀਂ ਕੀ ਬਦਲਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਮਹੱਤਤਾ ਦੇ ਕ੍ਰਮ ਵਿੱਚ। ਇਸ ਨਾਲ ਤੁਸੀਂ ਇੱਕ ਸੁਨੇਹੇ ਵਿੱਚ ਦਸ ਇੱਛਾਵਾਂ ਦਾ ਪੈਰਾ ਭੇਜਣ ਤੋਂ ਬਚਦੇ ਹੋ, ਅਤੇ ਅੱਧ ਵਿਚਕਾਰ ਆਏ ਵਿਚਾਰਾਂ ਨੂੰ "ਹੁਣ ਨਹੀਂ" ਕਹਿ ਸਕਦੇ ਹੋ।
ਜੇ ਤਬਦੀਲੀ ਵੱਡੀ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਤੋੜੋ। "ਟੀਮ ਅਕਾਊਂਟ ਜੋੜੋ" ਇਸ ਤਰ੍ਹਾਂ ਬਣ ਜਾਂਦਾ ਹੈ: ਟੀਮਾਂ ਬਣਾਉਣਾ, ਇੱਕ ਮੈਂਬਰ ਨੂੰ ਸੱਦਾ ਦੇਣਾ, ਟੀਮਾਂ ਵਿਚਕਾਰ ਬਦਲਣਾ, ਡੇਟਾ ਨੂੰ ਮੌਜੂਦਾ ਟੀਮ ਤੱਕ ਸੀਮਿਤ ਕਰਨਾ। ਹਰ ਇੱਕ ਆਪਣਾ ਪ੍ਰੋਂਪਟ ਹੈ। ਯੂਜ਼ਰ ਸਟੋਰੀਆਂ ਲਿਖਣਾ ਇਹ ਕਰਨ ਦਾ ਚੰਗਾ ਤਰੀਕਾ ਹੈ।
ਕਦਮ 2: ਜੋ ਤੁਸੀਂ ਵੇਖਦੇ ਹੋ ਉਹ ਦੱਸੋ
AI ਤੁਹਾਡੀ ਸਕ੍ਰੀਨ ਨਹੀਂ ਵੇਖ ਸਕਦਾ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਨਾ ਦੱਸੋ। ਖਾਸ ਚੀਜ਼ਾਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰੋ, ਅਤੇ ਦੱਸੋ ਕਿ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:
ਫੋਨ 'ਤੇ ਪ੍ਰਾਈਸਿੰਗ ਪੇਜ 'ਤੇ, Pro ਕਾਰਡ ਦਾ ਬਟਨ ਸੱਜੇ ਕਿਨਾਰੇ ਤੋਂ ਕੱਟਿਆ ਜਾ ਰਿਹਾ ਹੈ। ਡੈਸਕਟਾਪ ਲੇਆਉਟ ਉਹੀ ਰੱਖੋ; 640px ਤੋਂ ਘੱਟ ਸਕ੍ਰੀਨਾਂ 'ਤੇ ਕਾਰਡਾਂ ਨੂੰ ਇੱਕ ਦੇ ਹੇਠਾਂ ਇੱਕ ਕਰੋ ਅਤੇ ਬਟਨਾਂ ਨੂੰ ਪੂਰੀ ਚੌੜਾਈ ਦਿਓ।
ਇਸਦੀ ਤੁਲਨਾ "ਪ੍ਰਾਈਸਿੰਗ ਪੇਜ ਮੋਬਾਈਲ 'ਤੇ ਮਾੜਾ ਲੱਗਦਾ ਹੈ" ਨਾਲ ਕਰੋ। ਪਹਿਲਾ ਇੱਕੋ ਵਾਰ ਕੀਤਾ ਅਤੇ ਜਾਂਚਿਆ ਜਾ ਸਕਦਾ ਹੈ; ਦੂਜਾ ਇੱਕ ਅਜਿਹੀ ਮੁੜ-ਡਿਜ਼ਾਈਨ ਨੂੰ ਸੱਦਾ ਦਿੰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਮੰਗੀ ਨਹੀਂ ਸੀ।
ਸਕ੍ਰੀਨਸ਼ਾਟ ਮਦਦ ਕਰਦੇ ਹਨ। ਜੇ ਤੁਹਾਡਾ ਬਿਲਡਰ ਤਸਵੀਰਾਂ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਲਗਾਓ ਅਤੇ ਸਮੱਸਿਆ 'ਤੇ ਗੋਲਾ ਲਗਾਓ।
ਕਦਮ 3: ਵੱਡੀਆਂ ਤਬਦੀਲੀਆਂ ਤੋਂ ਪਹਿਲਾਂ ਯੋਜਨਾ ਬਣਾਓ
ਜਿਸ ਵੀ ਚੀਜ਼ ਨਾਲ ਐਪ ਦੇ ਕਈ ਹਿੱਸੇ ਪ੍ਰਭਾਵਿਤ ਹੋਣ — ਨਵਾਂ ਡੇਟਾ ਮਾਡਲ, ਭੁਗਤਾਨ, ਵਰਤੋਂਕਾਰ ਭੂਮਿਕਾਵਾਂ — ਉਸ ਲਈ ਕੋਈ ਕੋਡ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਯੋਜਨਾ ਮੰਗੋ:
ਹੁਣੇ ਕੋਡ ਨਾ ਬਦਲੋ। ਮੈਂ ਚਾਹੁੰਦਾ ਹਾਂ ਕਿ ਵਰਤੋਂਕਾਰ ਟੀਮਾਂ ਨਾਲ ਸਬੰਧਤ ਹੋਣ ਅਤੇ ਸਿਰਫ਼ ਆਪਣੀ ਟੀਮ ਦੇ ਪ੍ਰੋਜੈਕਟ ਵੇਖਣ। ਤਬਦੀਲੀ ਦੀ ਯੋਜਨਾ ਬਣਾਓ: ਕਿਹੜੇ ਟੇਬਲ, ਪੇਜ ਅਤੇ API ਰੂਟ ਬਦਲਣਗੇ, ਮੌਜੂਦਾ ਵਰਤੋਂਕਾਰਾਂ ਦੇ ਡੇਟਾ ਨਾਲ ਕੀ ਹੋਵੇਗਾ, ਅਤੇ ਤੁਸੀਂ ਕਿਸ ਕ੍ਰਮ ਵਿੱਚ ਬਣਾਓਗੇ।
ਯੋਜਨਾ ਪੜ੍ਹੋ। ਜੇ ਇਹ ਗਲਤ ਹੈ, ਤਾਂ ਯੋਜਨਾ ਠੀਕ ਕਰਨਾ ਬਣਾਈ ਹੋਈ ਚੀਜ਼ ਨੂੰ ਵਾਪਸ ਕਰਨ ਨਾਲੋਂ ਬਹੁਤ ਸਸਤਾ ਹੈ।
ਕਦਮ 4: ਦੱਸੋ ਕਿ ਕੀ ਨਹੀਂ ਬਦਲਣਾ ਚਾਹੀਦਾ
AI ਟੂਲ ਕਈ ਵਾਰ ਉਹ ਚੀਜ਼ਾਂ "ਸਾਫ਼" ਕਰ ਦਿੰਦੇ ਹਨ ਜੋ ਤੁਸੀਂ ਮੰਗੀਆਂ ਨਹੀਂ ਸਨ। ਜੋ ਕੰਮ ਕਰਦਾ ਹੈ ਉਸਦੀ ਰੱਖਿਆ ਕਰੋ:
ਆਰਡਰ ਟੇਬਲ ਵਿੱਚ ਇੱਕ ਤਾਰੀਖ ਫਿਲਟਰ ਜੋੜੋ। ਟੇਬਲ ਦੇ ਕਾਲਮ, ਸਟਾਈਲਿੰਗ ਜਾਂ ਐਕਸਪੋਰਟ ਬਟਨ ਨਾ ਬਦਲੋ।
ਉਨ੍ਹਾਂ ਨਿਯਮਾਂ ਲਈ ਜੋ ਹਰ ਥਾਂ ਲਾਗੂ ਹੁੰਦੇ ਹਨ — ਬ੍ਰਾਂਡ ਰੰਗ, ਬੋਲਣ ਦਾ ਲਹਿਜ਼ਾ, "ਪੁਸ਼ਟੀ ਤੋਂ ਬਿਨਾਂ ਕਦੇ ਡੇਟਾ ਨਾ ਮਿਟਾਓ" — ਉਨ੍ਹਾਂ ਨੂੰ ਪ੍ਰੋਜੈਕਟ ਨੋਟਸ ਫਾਈਲ ਜਾਂ ਨੌਲੇਜ ਸੈਟਿੰਗ ਵਿੱਚ ਰੱਖੋ ਜੋ AI ਹਰ ਵਾਰ ਪੜ੍ਹੇ, ਹਰ ਵਾਰ ਦੁਹਰਾਉਣ ਦੀ ਥਾਂ।
ਕਦਮ 5: ਸਿਰਫ਼ ਤਬਦੀਲੀ ਤੋਂ ਵੱਧ ਜਾਂਚੋ
ਹਰ ਪ੍ਰੋਂਪਟ ਤੋਂ ਬਾਅਦ ਜਾਂਚੋ:
- ਤਬਦੀਲੀ ਆਪ। ਕੀ ਇਹ ਉਹ ਕਰਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਮੰਗਿਆ, ਡੈਸਕਟਾਪ ਅਤੇ ਫੋਨ ਦੋਵਾਂ 'ਤੇ?
- ਨੇੜੇ ਦੀਆਂ ਚੀਜ਼ਾਂ। ਉਸੇ ਪੇਜ 'ਤੇ ਹੋਰ ਚੀਜ਼ਾਂ, ਅਤੇ ਉਹ ਫਲੋ ਜੋ ਉਸੇ ਡੇਟਾ ਨੂੰ ਵਰਤਦੇ ਹਨ।
- ਮੁੱਖ ਰਸਤਾ। ਸਾਈਨ ਅੱਪ, ਲੌਗਇਨ, ਮੁੱਖ ਕਾਰਵਾਈ, ਭੁਗਤਾਨ। ਹਰ ਵੱਡੀ ਤਬਦੀਲੀ ਤੋਂ ਬਾਅਦ ਤੀਹ ਸਕਿੰਟਾਂ ਦੀ ਜਾਂਚ ਜ਼ਿਆਦਾਤਰ ਟੁੱਟਣ ਨੂੰ ਜਲਦੀ ਫੜ ਲੈਂਦੀ ਹੈ।
ਜੇ ਕੁਝ ਠੀਕ ਨਹੀਂ ਲੱਗਦਾ, ਤਾਂ ਉਸਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਦੱਸੋ — ਦੇਖੋ ਚੰਗੀ ਬੱਗ ਰਿਪੋਰਟ ਕਿਵੇਂ ਲਿਖੀਏ।
ਕਦਮ 6: ਢੇਰ ਲਾਉਣ ਦੀ ਥਾਂ ਰੋਲਬੈਕ ਕਰੋ
ਜਦੋਂ ਕੋਈ ਤਬਦੀਲੀ ਕੁਝ ਤੋੜ ਦੇਵੇ ਅਤੇ ਪਹਿਲਾ ਫਿਕਸ ਕੰਮ ਨਾ ਕਰੇ, ਤਾਂ ਰੁਕ ਜਾਓ। ਹਰ ਵਾਧੂ "ਫਿਕਸ" ਇੱਕ ਟੁੱਟੀ ਹਾਲਤ 'ਤੇ ਬਣਦਾ ਹੈ, ਅਤੇ ਸਮੱਸਿਆਵਾਂ ਵਧਦੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।
ਇਸਦੀ ਥਾਂ:
- ਆਖਰੀ ਵਰਜਨ 'ਤੇ ਰੋਲਬੈਕ ਕਰੋ ਜੋ ਕੰਮ ਕਰਦਾ ਸੀ (ਚੈੱਕਪੌਇੰਟ ਜਾਂ Git ਕਮਿਟ)।
- ਪਤਾ ਲਗਾਓ ਕਿ ਪ੍ਰੋਂਪਟ ਵਿੱਚ ਕੀ ਅਸਪਸ਼ਟ ਸੀ।
- ਛੋਟੀ ਜਾਂ ਸਾਫ਼ ਬੇਨਤੀ ਨਾਲ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰੋ।
ਉਸ ਤਬਦੀਲੀ ਨੇ ਡਰਾਫਟ ਸੇਵ ਕਰਨਾ ਤੋੜ ਦਿੱਤਾ। ਮੈਂ ਰੋਲਬੈਕ ਕਰ ਦਿੱਤਾ ਹੈ। ਇਸ ਵਾਰ: ਸਿਰਫ਼ ਆਟੋਸੇਵ ਸੂਚਕ ਹੈਡਰ ਵਿੱਚ ਟੈਕਸਟ ਵਜੋਂ ਜੋੜੋ। ਡਰਾਫਟ ਕਿਵੇਂ ਸੇਵ ਹੁੰਦੇ ਹਨ ਉਹ ਨਾ ਬਦਲੋ।
ਕਦਮ 7: ਜਾਣੋ ਕਿ ਦੁਬਾਰਾ ਬਣਾਉਣਾ ਕਦੋਂ ਸਹੀ ਹੈ
ਸ਼ੁਰੂ ਤੋਂ ਦੁਬਾਰਾ ਬਣਾਉਣ ਨਾਲ ਬਹੁਤ ਸਾਰਾ ਕੰਮ ਕਰਦਾ ਵੇਰਵਾ ਸੁੱਟਿਆ ਜਾਂਦਾ ਹੈ। ਇਹ ਉਦੋਂ ਹੀ ਯੋਗ ਹੈ ਜਦੋਂ:
- ਉਤਪਾਦ ਦਾ ਵਿਚਾਰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਦਲ ਗਿਆ ਹੈ।
- ਮੂਲ ਢਾਂਚਾ ਉਹ ਨਹੀਂ ਸੰਭਾਲ ਸਕਦਾ ਜੋ ਹੁਣ ਚਾਹੀਦਾ ਹੈ — ਉਦਾਹਰਨ ਲਈ, ਇਹ ਸਟੈਟਿਕ ਸਾਈਟ ਵਜੋਂ ਬਣਿਆ ਸੀ ਅਤੇ ਹੁਣ ਅਕਾਊਂਟ ਅਤੇ ਡੇਟਾਬੇਸ ਚਾਹੀਦੇ ਹਨ।
- ਪ੍ਰੋਜੈਕਟ ਅਜੇ ਲਗਭਗ ਖਾਲੀ ਹੈ।
ਜਦੋਂ ਦੁਬਾਰਾ ਬਣਾਓ, ਸੂਚੀ ਬਣਾਓ ਕਿ ਕੀ ਰੱਖਣਾ ਹੈ: ਨਾਮ, ਰੰਗ, ਲਿਖਤ, ਉਹ ਹਿੱਸੇ ਜੋ ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਪਸੰਦ ਸਨ।
ਉਦਾਹਰਨ ਪ੍ਰੋਂਪਟ
ਅੱਗੇ ਵਧਣ ਤੋਂ ਪਹਿਲਾਂ, ਸਾਰ ਦਿਓ ਕਿ ਐਪ ਹੁਣ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ: ਪੇਜ, ਉਹ ਡੇਟਾ ਜੋ ਇਹ ਸੰਭਾਲਦੀ ਹੈ, ਅਤੇ ਜੋ ਵੀ ਤੁਹਾਨੂੰ ਕਮਜ਼ੋਰ ਲੱਗਦਾ ਹੈ।
ਮੈਂ ਦੁਹਰਾਉਣ ਵਾਲੀਆਂ ਬੁਕਿੰਗਾਂ ਜੋੜਨਾ ਚਾਹੁੰਦਾ ਹਾਂ। ਸਭ ਤੋਂ ਛੋਟਾ ਵਰਜਨ ਕੀ ਹੋਵੇ ਜੋ ਫਾਇਦੇਮੰਦ ਹੋਵੇ? ਇਸਨੂੰ ਤਿੰਨ ਵੱਖਰੀਆਂ ਤਬਦੀਲੀਆਂ ਵਜੋਂ ਸੁਝਾਓ ਜੋ ਅਸੀਂ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਕਰ ਸਕੀਏ।
ਆਖਰੀ ਤਿੰਨ ਤਬਦੀਲੀਆਂ ਵੇਖੋ ਕਿ ਕੀ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਨੇ ਚੈੱਕਆਊਟ ਫਲੋ ਤੋੜਿਆ ਹੋ ਸਕਦਾ ਹੈ। ਅਜੇ ਸੰਪਾਦਿਤ ਨਾ ਕਰੋ।
ਆਮ ਗਲਤੀਆਂ
- ਇੱਕ ਪ੍ਰੋਂਪਟ ਵਿੱਚ ਦਸ ਬੇਨਤੀਆਂ। ਕੁਝ ਪੂਰੀਆਂ ਹੁੰਦੀਆਂ ਹਨ, ਕੁਝ ਅਧੂਰੀਆਂ, ਅਤੇ ਤੁਸੀਂ ਪਛਾਣ ਨਹੀਂ ਸਕਦੇ ਕਿਹੜੀਆਂ।
- ਅਸਪਸ਼ਟ ਫੀਡਬੈਕ। "ਇਹ ਟੁੱਟਿਆ ਹੈ" ਜਾਂ "ਇਸਨੂੰ ਵਧੀਆ ਬਣਾਓ" ਅੰਦਾਜ਼ਿਆਂ ਨੂੰ ਜਨਮ ਦਿੰਦਾ ਹੈ।
- ਨੇੜਲੀਆਂ ਚੀਜ਼ਾਂ ਕਦੇ ਨਾ ਜਾਂਚਣੀਆਂ। ਇੱਕ ਸਾਂਝੇ ਹਿੱਸੇ ਵਿੱਚ ਤਬਦੀਲੀ ਤਿੰਨ ਹੋਰ ਪੇਜ ਤੋੜ ਸਕਦੀ ਹੈ।
- ਫਿਕਸਾਂ ਨੂੰ ਫਿਕਸ ਕਰਨਾ। ਕਿਸੇ ਬੱਗ ਵਿੱਚ ਚਾਰ ਪ੍ਰੋਂਪਟ ਅੰਦਰ ਜਾ ਚੁੱਕੇ ਹੋ, ਤਾਂ ਰੋਲਬੈਕ ਕਰੋ।
- ਹਰ ਵਾਰ ਸੰਦਰਭ ਦੁਹਰਾਉਣਾ ਪ੍ਰੋਜੈਕਟ ਨੋਟਸ ਵਿੱਚ ਸਥਾਈ ਨਿਯਮ ਰੱਖਣ ਦੀ ਥਾਂ।
- ਫਸਣ 'ਤੇ ਦੁਬਾਰਾ ਬਣਾਉਣਾ। ਜ਼ਿਆਦਾਤਰ "ਸ਼ੁਰੂ ਤੋਂ ਕਰੋ" ਦੇ ਪਲ ਅਸਲ ਵਿੱਚ "ਦੋ ਕਦਮ ਪਿੱਛੇ ਰੋਲਬੈਕ ਕਰੋ" ਹੁੰਦੇ ਹਨ।
ਚੈੱਕਲਿਸਟ
- ਹਰ ਪ੍ਰੋਂਪਟ ਵਿੱਚ ਇੱਕ ਟੀਚਾ।
- ਮੈਂ ਜੋ ਵੇਖਦਾ ਹਾਂ ਅਤੇ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਉਹ ਦੱਸਦਾ ਹਾਂ।
- ਵੱਡੀਆਂ ਤਬਦੀਲੀਆਂ ਨੂੰ ਕੋਡ ਤੋਂ ਪਹਿਲਾਂ ਯੋਜਨਾ ਮਿਲਦੀ ਹੈ।
- ਮੈਂ ਦੱਸਦਾ ਹਾਂ ਕਿ ਕੀ ਨਹੀਂ ਬਦਲਣਾ ਚਾਹੀਦਾ।
- ਹਰ ਤਬਦੀਲੀ ਤੋਂ ਬਾਅਦ ਮੈਂ ਉਸਨੂੰ, ਉਸਦੇ ਨੇੜਲਿਆਂ ਨੂੰ ਅਤੇ ਮੁੱਖ ਰਸਤੇ ਨੂੰ ਜਾਂਚਦਾ ਹਾਂ।
- ਹਰ ਕੰਮ ਕਰਨ ਵਾਲੀ ਤਬਦੀਲੀ ਤੋਂ ਬਾਅਦ ਚੈੱਕਪੌਇੰਟ ਜਾਂ ਕਮਿਟ ਸੇਵ ਕਰਦਾ ਹਾਂ।
- ਜਦੋਂ ਫਿਕਸ ਫੇਲ੍ਹ ਹੋਵੇ, ਮੈਂ ਫਿਕਸਾਂ ਦਾ ਢੇਰ ਲਾਉਣ ਦੀ ਥਾਂ ਰੋਲਬੈਕ ਕਰਦਾ ਹਾਂ।
- ਸਥਾਈ ਨਿਯਮ ਪ੍ਰੋਜੈਕਟ ਨੋਟਸ ਵਿੱਚ ਹਨ ਜੋ AI ਹਰ ਵਾਰ ਪੜ੍ਹਦਾ ਹੈ।
Mythex 'ਤੇ ਸੁਧਾਰ
Mythex ਇਸ ਚੱਕਰ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਬਣਿਆ ਹੈ:
- Plan, Build ਅਤੇ Ask ਮੋਡ। Plan ਸੰਪਾਦਨ ਤੋਂ ਪਹਿਲਾਂ ਪਹੁੰਚ ਬਾਰੇ ਗੱਲ ਕਰਦਾ ਹੈ; Ask ਕੋਡ ਬਦਲੇ ਬਿਨਾਂ ਜਵਾਬ ਦਿੰਦਾ ਹੈ; Build ਤਬਦੀਲੀ ਕਰਦਾ ਹੈ। ਦੇਖੋ Chat।
- ਚੈੱਕਪੌਇੰਟ। ਹਰ ਸਫ਼ਲ ਵਾਰੀ ਤੋਂ ਬਾਅਦ, Mythex ਇੱਕ git ਚੈੱਕਪੌਇੰਟ ਸੇਵ ਕਰਦਾ ਹੈ; Revert to this point ਰੋਲਬੈਕ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਪਿਛਲਾ ਸੁਨੇਹਾ ਸੰਪਾਦਿਤ ਕਰਕੇ Discard & resend ਵੀ ਕਰ ਸਕਦੇ ਹੋ ਤਾਂ ਜੋ ਉਸ ਬਿੰਦੂ ਤੋਂ ਵੱਖਰਾ ਪ੍ਰੋਂਪਟ ਅਜ਼ਮਾਓ। ਦੇਖੋ Iterate without rebuilding।
- ਨੌਲੇਜ। ਪ੍ਰੋਜੈਕਟ ਸੈਟਿੰਗਾਂ → Knowledge ਵਿੱਚ ਸਥਾਈ ਨੋਟਸ ਹੁੰਦੇ ਹਨ ਜੋ ਏਜੰਟ ਹਰ ਸੁਨੇਹੇ 'ਤੇ ਮੰਨਦਾ ਹੈ।
/testਏਜੰਟ ਨੂੰ ਵੱਡੀ ਤਬਦੀਲੀ ਤੋਂ ਬਾਅਦ ਪ੍ਰੀਵਿਊ ਵਿੱਚ ਇੱਕ ਵਰਤੋਂਕਾਰ ਵਾਂਗ ਕਲਿੱਕ ਕਰਕੇ ਜਾਂਚਣ ਦਿੰਦਾ ਹੈ।
ਛੋਟੀਆਂ ਬੇਨਤੀਆਂ ਦੇ ਕ੍ਰੈਡਿਟ ਵੀ ਘੱਟ ਲੱਗਦੇ ਹਨ। ਪ੍ਰੋਂਪਟ ਲਿਖਣ ਬਾਰੇ ਜਾਣਨ ਲਈ, AI ਬਿਲਡਰਾਂ ਲਈ ਪ੍ਰੋਂਪਟ ਕਿਵੇਂ ਲਿਖੀਏ ਦੇਖੋ; ਜਦੋਂ ਕੁਝ ਟੁੱਟੇ, ਤਾਂ AI ਨਾਲ ਬਣੀ ਐਪ ਨੂੰ ਡੀਬੱਗ ਕਿਵੇਂ ਕਰੀਏ ਦੇਖੋ।
ਸਵਾਲ
ਫੀਚਰ ਜੋੜਦੇ ਸਮੇਂ ਮੇਰੀ AI ਨਾਲ ਬਣੀ ਐਪ ਕਿਉਂ ਟੁੱਟ ਜਾਂਦੀ ਹੈ?
ਆਮ ਤੌਰ 'ਤੇ ਇਸ ਲਈ ਕਿ ਹਰ ਪ੍ਰੋਂਪਟ ਇੱਕੋ ਵਾਰ ਬਹੁਤ ਕੁਝ ਮੰਗਦਾ ਹੈ, ਜਾਂ AI ਪਹਿਲੀਆਂ ਫਿਕਸਾਂ ਨੂੰ ਹੀ ਠੀਕ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ। ਹਰ ਪ੍ਰੋਂਪਟ ਵਿੱਚ ਇੱਕ ਤਬਦੀਲੀ ਮੰਗੋ, ਜਾਂਚੋ ਕਿ ਇਹ ਕੰਮ ਕਰਦੀ ਹੈ, ਇੱਕ ਚੈੱਕਪੌਇੰਟ ਸੇਵ ਕਰੋ, ਅਤੇ ਟੁੱਟੀ ਹਾਲਤ 'ਤੇ ਫਿਕਸਾਂ ਦਾ ਢੇਰ ਲਾਉਣ ਦੀ ਥਾਂ ਰੋਲਬੈਕ ਕਰੋ।
ਕੀ ਮੈਨੂੰ ਐਪ ਸ਼ੁਰੂ ਤੋਂ ਦੁਬਾਰਾ ਬਣਾਉਣੀ ਚਾਹੀਦੀ ਹੈ ਜਾਂ ਸੁਧਾਰਦੇ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ?
ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ ਸੁਧਾਰਦੇ ਰਹੋ। ਦੁਬਾਰਾ ਬਣਾਓ ਸਿਰਫ਼ ਉਦੋਂ ਜਦੋਂ ਉਤਪਾਦ ਦਾ ਵਿਚਾਰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਦਲ ਗਿਆ ਹੋਵੇ, ਢਾਂਚਾ ਉਹ ਨਾ ਸੰਭਾਲ ਸਕੇ ਜੋ ਹੁਣ ਚਾਹੀਦਾ ਹੈ, ਜਾਂ ਪ੍ਰੋਜੈਕਟ ਅਜੇ ਲਗਭਗ ਖਾਲੀ ਹੋਵੇ। ਜਦੋਂ ਦੁਬਾਰਾ ਬਣਾਓ, ਦੱਸੋ ਕਿ ਕੀ ਰੱਖਣਾ ਹੈ।
ਮੈਂ AI ਨੂੰ ਮੇਰੀ ਐਪ ਬਾਰੇ ਫੈਸਲੇ ਕਿਵੇਂ ਯਾਦ ਰਖਵਾਵਾਂ?
ਉਨ੍ਹਾਂ ਨੂੰ ਉਸ ਥਾਂ ਲਿਖੋ ਜਿੱਥੇ AI ਹਰ ਵਾਰ ਉਨ੍ਹਾਂ ਨੂੰ ਵੇਖੇ: ਪ੍ਰੋਜੈਕਟ ਨੋਟਸ ਜਾਂ ਨੌਲੇਜ ਫਾਈਲ, ਜਾਂ ਪ੍ਰੋਂਪਟਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਛੋਟਾ ਸਾਰ। ਦਰਸ਼ਕ, ਸਟਾਈਲ ਦੇ ਨਿਯਮ ਅਤੇ ਉਹ ਚੀਜ਼ਾਂ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਬਦਲਣੀਆਂ ਨਹੀਂ ਚਾਹੀਦੀਆਂ।
ਹਰ ਪ੍ਰੋਂਪਟ ਕਿੰਨਾ ਵੱਡਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ?
ਹਰ ਪ੍ਰੋਂਪਟ ਵਿੱਚ ਇੱਕ ਸਾਫ਼ ਟੀਚਾ: ਇੱਕ ਫੀਚਰ, ਇੱਕ ਬੱਗ, ਇੱਕ ਪੇਜ। ਜੇ ਤੁਸੀਂ ਨਤੀਜਾ ਇੱਕ-ਦੋ ਮਿੰਟਾਂ ਵਿੱਚ ਨਹੀਂ ਜਾਂਚ ਸਕਦੇ, ਤਾਂ ਤਬਦੀਲੀ ਸ਼ਾਇਦ ਇੱਕੋ ਵਾਰ ਮੰਗਣ ਲਈ ਬਹੁਤ ਵੱਡੀ ਹੈ।