06 ਜਨ 2026·8 ਮਿੰਟ
ਨਿਰੰਤਰ AI-ਤਿਆਰ ਐਪ ਲਈ ਇੱਕ-ਪੰਨੇ ਐਪ ਸਪੈਕ ਟੈਮਪਲੇਟ
ਇੱਕ-ਪੰਨੇ ਐਪ ਸਪੈਕ ਟੈਮਪਲੇਟ ਵਰਤੋ ਤਾਂ ਕਿ ਧੁੰਦਲੇ ਵਿਚਾਰ ਨੂੰ Planning Mode ਲਈ ਸਪੱਸ਼ਟ ਪ੍ਰੋਂਪਟਾਂ ਵਿੱਚ ਬਦਲਿਆ ਜਾ ਸਕੇ — ਯੂਜ਼ਰ, jobs-to-be-done, ਐਂਟਿਟੀਆਂ ਅਤੇ ਐਜ ਕੇਸ ਕਵਰ ਹੋਣ।
ਇੱਕ-ਪੰਨੇ ਐਪ ਸਪੈਕ ਟੈਮਪਲੇਟ ਵਰਤੋ ਤਾਂ ਕਿ ਧੁੰਦਲੇ ਵਿਚਾਰ ਨੂੰ Planning Mode ਲਈ ਸਪੱਸ਼ਟ ਪ੍ਰੋਂਪਟਾਂ ਵਿੱਚ ਬਦਲਿਆ ਜਾ ਸਕੇ — ਯੂਜ਼ਰ, jobs-to-be-done, ਐਂਟਿਟੀਆਂ ਅਤੇ ਐਜ ਕੇਸ ਕਵਰ ਹੋਣ।
ਧੁੰਦਲਾ ਵਿਚਾਰ ਡੇਰਿਮਿੰਗ ਲਈ ਠੀਕ ਹੈ। ਬਣਾਉਣ ਲਈ ਇਹ ਠੀਕ ਨਹੀਂ।
ਜਦੋਂ ਤੁਸੀਂ AI ਬਿਲਡਰ ਨੂੰ ਬਿਨਾਂ ਹੋਰ ਵੇਰਵੇ ਦੇ “ਅੱਡਾ ਐਪ ਲਈ habit ਟਰੈਕ ਕਰਨ ਲਈ” ਕਹਿੰਦੇ ਹੋ, ਤਾਂ ਉਸਨੂੰ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣਾ ਪੈਂਦਾ ਹੈ। ਉਹ ਅਨੁਮਾਨ ਹਰ ਪ੍ਰੋਂਪਟ ਨਾਲ ਬਦਲਦੇ ਹਨ, ਇਸ ਲਈ ਐਪ ਵੀ ਬਦਲਦਾ ਹੈ। ਤੁਸੀਂ ਐਸੇ ਸਕ੍ਰੀਨ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ ਜੋ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ, ਡਾਟਾ ਜੋ build ਦੌਰਾਨ ਨਾਮ ਬਦਲਦਾ ਹੈ, ਅਤੇ ਫੀਚਰ ਜੋ ਆਉਂਦੇ, ਚਲੇ ਜਾਂਦੇ, ਫਿਰ ਵੱਖਰੇ ਰੂਪ ਵਿੱਚ ਵਾਪਸ ਆ ਜਾਂਦੇ ਹਨ।
ਇਹ ਅਸੰਗਤਤਾ ਆਮ ਤੌਰ 'ਤੇ ਕੁਝ ਥਾਵਾਂ 'ਤੇ ਵੇਖੀ ਜਾਂਦੀ ਹੈ:
“Planning Mode” ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇਕ ਸਧਾਰਣ ਰੁਕਾਵਟ ਹੈ। ਤੁਸੀਂ ਉਹ ਫੈਸਲੇ ਲਿਖਦੇ ਹੋ ਜੋ AI ਆਮ ਤੌਰ 'ਤੇ ਖੁਦ ਸੋਚ ਲੈਂਦਾ। ਮਕਸਦ ਹੈ ਇਕਸਾਰਤਾ: ਇੱਕ ਹੀ ਚੋਣਾਂ ਦੀ ਸੈੱਟ ਜੋ UI, ਬੈਕਏਂਡ ਅਤੇ ਡੈਟਾਬੇਸ ਫਾਲੋ ਕਰ ਸਕਦੇ ਹਨ।
ਮਕਸਦ ਪਰਫੈਕਸ਼ਨ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਐਸਾ ਬਿਲਡ ਹੈ ਜੋ ਤੁਸੀਂ ਬਿਨਾਂ ਅਨਗਿਣਤ ਅਨੁਮਾਨਾਂ ਦੀ ਮਰੰਮਤ ਕਰਨ ਦੇ ਦੁਬਾਰਾ ਸੁਧਾਰ ਸਕਦੇ ਹੋ। ਜੇ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਰਾਏ ਬਦਲਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਛੋਟੀ ਸਪੈਕ ਅਪਡੇਟ ਕਰਦੇ ਹੋ ਅਤੇ ਇਕੋ ਲਾਜਿਕ ਨਾਲ ਦੁਬਾਰਾ ਬਣਾਉਂਦੇ ਹੋ।
ਇਸੇ ਲਈ ਇੱਕ-ਪੰਨੇ ਦਾ ਐਪ ਸਪੈਕ ਟੈਮਪਲੇਟ ਵਰਤਣਾ ਮਹੱਤਵਪੂਰਣ ਹੈ। ਇਹ ਲੰਮਾ PRD ਨਹੀਂ ਹੈ ਅਤੇ ਨਾ ਹੀ ਹਫ਼ਤਿਆਂ ਦੇ ਡਾਇਗ੍ਰਾਮ। ਇਹ ਇੱਕ ਪੰਨਾ ਹੈ ਜੋ ਚਾਰ ਗੱਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: ਕੌਣ ਯੂਜ਼ਰ ਹਨ, ਉਹ ਕੀ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਨ, ਕਿਹੜਾ ਡਾਟਾ ਹੈ (ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ), ਅਤੇ ਕਿਹੜੇ ਐਜ ਕੇਸ ਜਾਂ ਨਾ-ਬਨਾਏ ਜਾਣ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਪਹਿਲੇ ਸੰਸਕਰਨ ਨੂੰ ਫੈਲਣ ਤੋਂ ਰੋਕਦੀਆਂ ਹਨ।
ਉਦਾਹਰਨ: “ਇੱਕ booking ਐਪ” ਜ਼ਿਆਦਾ ਸਪੱਸ਼ਟ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਫੈਸਲਾ ਕਰ ਲੈਂਦੇ ਹੋ ਕਿ ਇਹ ਇੱਕ ਸਿੰਗਲ ਸੈਲੂਨ ਮਾਲਕ ਲਈ ਹੈ ਜਾਂ ਇੱਕ ਮਾਰਕੀਟਪਲੇਸ ਲਈ, ਅਤੇ ਕਿ ਗਾਹਕ ਰੀਸ਼ੈਡਿਊਲ, ਰੱਦ ਜਾਂ ਨੋ-ਸ਼ੋ ਕਰ ਸਕਦੇ ਹਨ ਜਾਂ ਨਹੀਂ।
ਇੱਕ-ਪੰਨੇ ਐਪ ਸਪੈਕ ਟੈਮਪਲੇਟ ਇੱਕ ਛੋਟੀ ਨੋਟ ਹੈ ਜੋ ਧੁੰਦਲੇ ਵਿਚਾਰ ਨੂੰ ਸਪੱਸ਼ਟ ਨਿਰਦੇਸ਼ਾਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ। ਤੁਸੀਂ “ਪੂਰਾ ਉਤਪਾਦ ਡਿਜ਼ਾਈਨ” ਨਹੀਂ ਕਰ ਰਹੇ; ਤੁਸੀਂ ਆਪਣੇ AI ਬਿਲਡਰ ਨੂੰ ਇੰਨੀ ਸੰਰਚਨਾ ਦੇ ਰਹੇ ਹੋ ਕਿ ਉਹ ਹਰ ਵਾਰ ਇੱਕੋ ਫੈਸਲੇ ਕਰੇ।
Page ਵਿੱਚ ਚਾਰ ਬਲਾਕ ਹੁੰਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਇਹ ਇੱਕ ਪੰਨੇ 'ਤੇ ਫਿੱਟ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਸੰਭਵ ਹੈ ਕਿ ਪਹਿਲੀ ਬਣਤ ਲਈ ਤੁਹਾਡੇ ਕੋਲ ਬਹੁਤ ਜ਼ਿਆਦਾ ਫੀਚਰ ਹਨ।
ਇੱਕ ਪੰਨਾ ਲਾਭਕਾਰੀ ਬੰਧਨਾਂ ਲੱਗਾਉਂਦਾ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਪ੍ਰਭਾਵੀ ਯੂਜ਼ਰ ਦੀ ਚੋਣ ਕਰਨ, ਸਭ ਤੋਂ ਛੋਟੀ ਕਾਮਯਾਬ ਫਲੋ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਅਤੇ “ਸਭ ਕੁਝ ਸਪੋਰਟ ਕਰੋ” ਵਰਗੀਆਂ ਅਸਪਸ਼ਟ ਗਾਰੰਟੀਆਂ ਤੋਂ ਬਚਣ ਲਈ ਧੱਕੇ ਦਿੰਦਾ ਹੈ। ਇਹੀ ਬੰਧਨ AI-ਤਿਆਰ ਐਪ ਨੂੰ ਸਕ੍ਰੀਨਾਂ 'ਤੇ ਇੱਕੋ ਸੋਚ ਰੱਖਣ ਤੋਂ ਰੋਕਦੇ ਹਨ।
“ਕਾਫ਼ੀ ਚੰਗਾ” ਬੀਦੀਆਂ ਸਧਾਰਨ, ਟੈਸਟੇਬਲ ਬਿਆਨਾਂ ਵਰਗੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਜੇ ਕੋਈ ਇਸਨੂੰ ਪੜ੍ਹ ਕੇ ਪੁੱਛ ਸਕੇ, “ਅਸੀਂ ਕਿਵੇਂ ਜਾਣਾਂ ਕਿ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ?” ਤਾਂ ਤੁਸੀਂ ਠੀਕ ਪੱਧਰ 'ਤੇ ਹੋ।
ਇੱਕ ਛੋਟਾ ਮਾਪਦੰਡ:
ਭਾਸ਼ਾ ਸਾਦੀ ਰੱਖੋ। ਉਹ ਲਾਈਨਾਂ ਲਿਖੋ ਜੋ ਤੁਸੀਂ ਸਿੱਧਾ ਪ੍ਰੋਂਪਟਾਂ ਵਿੱਚ ਪੇਸਟ ਕਰ ਸਕੋ, ਜਿਵੇਂ “A manager can approve or reject a request, and the requester gets a status update.”
20 ਮਿੰਟ ਦਾ ਟਾਈਮਰ ਸੈੱਟ ਕਰੋ ਅਤੇ “ਬਿਲਡ ਕਰਨ ਲਾਇਕ ਸਪੱਸ਼ਟ” ਲਈ ਕੋਸ਼ਿਸ਼ ਕਰੋ, ਨਾ ਕਿ “ਪਰਫੈਕਟ” ਲਈ। ਮਕਸਦ ਅਨੁਮਾਨ ਹਟਾਉਣਾ ਹੈ ਤਾਂ ਜੋ ਤੁਹਾਡਾ AI ਬਿਲਡਰ ਹਰ ਵਾਰ ਉਹੀ ਫੈਸਲੇ ਕਰੇ।
ਇੱਕ ਵਾਕ ਵਿੱਚ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: ਕੌਣ ਲਈ ਹੈ, ਅਤੇ ਉਹ ਕੀ ਨਤੀਜਾ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ?
ਉਦਾਹਰਨ: “ਕੁੱਤੇ ਪਾਲਣ ਵਾਲਿਆਂ ਲਈ ਇੱਕ ਮੋਬਾਈਲ ਐਪ ਜੋ walks ਅਤੇ vet visits ਇਕੱਠੇ ਟਰੈਕ ਕਰਦਾ ਹੈ।”
ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਵਾਕ ਵਿੱਚ ਨਹੀਂ ਕਹਿ ਸਕਦੇ, ਤਾਂ ਸੰਭਵ ਹੈ ਕਿ ਵਿਚਾਰ ਅਸਲ ਵਿੱਚ ਦੋ ਐਪ ਹਨ।
ਅਗਲੇ, 1 ਤੋਂ 3 ਯੂਜ਼ਰ ਕਿਸਮਾਂ ਨਾਂ ਦਿਓ ਜਿਵੇਂ ਅਸਲੀ ਲੋਕ, ਨਾ ਕਿ ਅਬਸਟ੍ਰੈਕਟ ਭੂਮਿਕਾਵਾਂ। “Owner,” “Vet,” ਅਤੇ “Family member” “User A” ਨਾਲੋਂ ਵਧੀਆ ਹਨ। ਹਰ ਇੱਕ ਲਈ ਇੱਕ ਛੋਟੀ ਲਾਈਨ ਜੋ ਉਹ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਚਿੰਤਾ ਕਰਦੇ ਹਨ ਜੋੜੋ।
ਫਿਰ 3 ਤੋਂ 7 jobs-to-be-done ਇਸ ਫਾਰਮੈਟ ਵਿੱਚ ਲਿਖੋ: “When [situation], I want to [action], so I can [result].” ਉਨ੍ਹਾਂ ਨੂੰ ਟੈਸਟੇਬਲ ਰੱਖੋ। “When I finish a walk, I want to log distance and notes, so I can spot patterns” “track health” ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਸਪੱਸ਼ਟ ਹੈ।
ਹੁਣ ਆਪਣੇ Entities ਅਤੇ ਮੁੱਖ ਫੀਲਡ ਨੂੰ ਬਿਨਾਂ ਡੈਟਾਬੇਸ ਭਾਸ਼ਾ ਦੇ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਸੋਚੋ “ਚੀਜ਼ਾਂ ਜੋ ਐਪ ਯਾਦ ਰੱਖਦੀ ਹੈ।” ਕੁੱਤੇ ਵਾਲੇ ਐਪ ਲਈ: Dog (name, age), Walk (date, duration, notes), Visit (date, clinic, cost). ਜੇ ਕੋਈ ਫੀਲਡ ਕਿਸੇ ਸਕ੍ਰੀਨ ਜਾਂ ਜੌਬ ਵਿੱਚ ਵਰਤੀ ਨਹੀਂ ਹੋ ਰਹੀ, ਤਾਂ ਉਹਨੂੰ ਛੱਡ ਦਿਓ।
ਅੰਤ ਵਿੱਚ ਦੋ ਛੋਟੇ ਬਲਾਕ ਭਰੋ: edge cases ਅਤੇ non-goals. Edge cases ਛੇਤੀ ਪਰ ਆਮ ਹਨ (“ਕੋਈ ਇੰਟਰਨੈਟ ਨਹੀਂ”), “ਇੱਕੋ ਨਾਂ ਵਾਲੇ ਦੋ ਕੁੱਤੇ” ਆਦਿ। Non-goals ਉਹ ਚੀਜ਼ਾਂ ਹਨ ਜੋ ਤੁਸੀਂ ਹੁਣ ਨਹੀਂ ਬਣਾਉਂਦੇ (“ਕੋਈ ਭੁਗਤਾਨ ਨਹੀਂ”, “ਕੋਈ ਸੋਸ਼ਲ ਫੀਡ ਨਹੀਂ”)।
ਆਖ਼ਿਰ ਵਿੱਚ, ਹਰ ਬਲਾਕ ਨੂੰ ਉਹ ਪ੍ਰੋਂਪਟ ਬਣਾਓ ਜੋ ਤੁਹਾਡਾ ਬਿਲਡਰ ਫਾਲੋ ਕਰ ਸਕੇ। ਸੰਰਚਨਾ ਨੂੰ ਲਗਾਤਾਰ ਰੱਖਣਾ (purpose, users, jobs, entities, edge cases) ਸਿਸਟਮ ਨੂੰ ਸਕ੍ਰੀਨ, ਡਾਟਾ ਅਤੇ ਫਲੋ ਜਨਰੇਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਜੋ ਐਕਸ-ਮੇਲ ਹੋਣ।
ਜੇ ਤੁਹਾਡਾ ਸਪੈਕ “ਸਭ ਲਈ” ਕਹਿੰਦਾ ਹੈ, ਤਾਂ AI ਬਿਲਡਰ ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਚੀਜ਼ਾਂ ਬਾਰੇ ਅਨੁਮਾਨ ਲਗਾਉਣੇ ਪੈਂਦੇ ਹਨ। ਇੱਕ-ਪੰਨੇ ਸਪੈਕ ਵਿੱਚ, ਯੂਜ਼ਰਾਂ ਨੂੰ ਉਦੇਸ਼ (ਉਹ ਕਿਹੜਾ ਕੰਮ ਕਰਨ ਆਏ) ਦੇ ਆਧਾਰ ਤੇ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, demographic ਦੀ ਥਾਂ। ਉਦੇਸ਼ ਸਕ੍ਰੀਨ, ਡਾਟਾ ਅਤੇ ਪਰਮਿਸ਼ਨਾਂ ਬਾਰੇ ਸਪੱਸ਼ਟ ਚੋਣਾਂ ਦਿੰਦਾ ਹੈ।
2–4 ਯੂਜ਼ਰ ਕਿਸਮਾਂ ਨਾਂ ਦਿਓ, ਹਰ ਇੱਕ ਦੇ ਇੱਕ ਮੁੱਖ ਲਕਸ਼ ਦੇ ਨਾਲ। ਵਧੀਆ ਉਦਾਹਰਨ: “Customer placing an order,” “Team member fulfilling orders,” “Manager reviewing performance.” ਧੁੰਦਲੇ ਉਦਾਹਰਨ: “18–35,” “busy professionals,” ਜਾਂ “admins” (ਜੇ ਤਸੀਂ ਨਹੀੰ ਦੱਸਦੇ ਕਿ ਉਹ ਕੀ admin ਕਰਦੇ)।
ਹਰ ਵਾਰੀ ਇੱਕੋ ਹੀ ਵਾਕ-ਰਚਨਾ ਵਰਤੋ: “When..., I want to..., so I can...”. ਇਹ ਐਪ ਨੂੰ ਨਤੀਜਿਆਂ 'ਤੇ ਕੇਂਦਰਤ ਰੱਖਦੀ ਹੈ ਅਤੇ ਤੁਹਾਡੇ AI ਬਿਲਡਰ ਨੂੰ ਸਥਿਰ, ਟੈਸਟੇਬਲ ਲੋੜਾਂ ਦਿੰਦੀ ਹੈ।
ਹੇਠਾਂ ਕੁਝ ਹਕੀਕਤੀ JTBD ਉਦਾਹਰਨ ਹਨ ਜਿਹਨਾਂ 'ਚ “ਪੂਰਾ ਹੋਣਾ” ਸਪੱਸ਼ਟ ਦਿਖਾਇਆ ਗਿਆ:
Success criteria ਮਹੱਤਵਪੂਰਣ ਹਨ ਕਿਉਂਕਿ ਉਹ “ਚੰਗਾ ਲੱਗਦਾ ਹੈ” ਦੀ ਅਸਪਸ਼ਟਤਾ ਹਟਾਉਂਦੇ ਹਨ। ਉਹ ਬਿਲਡਰ ਨੂੰ ਦੱਸਦੇ ਹਨ ਕਿ UI ਨੂੰ ਕੀ ਆਗਿਆ ਦੇਣੀ ਹੈ ਅਤੇ ਬੈਕਐਂਡ ਨੂੰ ਕੀ ਸਟੋਰ ਕਰਨਾ ਹੈ।
ਪੂਰਾ ਸੁਰੱਖਿਆ ਯੋਜਨਾ ਲਿਖੋ ਦੀ ਲੋੜ ਨਹੀਂ। ਸਿਰਫ਼ ਸਾਫ਼-ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਦੱਸੋ ਕਿ ਕੌਣ ਕੀ ਕਰ ਸਕਦਾ ਹੈ।
ਉਦਾਹਰਨ: “Members ਆਪਣੀਆਂ ਆਈਟਮ ਬਣਾਉ ਅਤੇ ਸੋਧ ਸਕਦੇ ਹਨ। Managers ਕਿਸੇ ਵੀ ਆਈਟਮ ਨੂੰ ਸੋਧ ਸਕਦੇ ਅਤੇ ਸਥਿਤੀ ਬਦਲ ਸਕਦੇ ਹਨ। Owners ਯੂਜ਼ਰਾਂ ਅਤੇ ਬਿਲਿੰਗ ਨੂੰ ਪ੍ਰਬੰਧਿਤ ਕਰ ਸਕਦੇ ਹਨ।”
ਜੇ ਤੁਸੀਂ Planning Mode ਦਾ ਉਪਯੋਗ Koder.ai ਵਿੱਚ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਯੂਜ਼ਰ ਕਿਸਮਾਂ, JTBD ਲਾਈਨਾਂ ਅਤੇ ਪਰਮਿਸ਼ਨ ਭਰੋਸੇਯੋਗ ਇਨਪੁਟ ਬਣ ਜਾਂਦੇ ਹਨ। ਇਹ AI ਨੂੰ ਵਾਧੂ ਰੋਲ ਬਣਾਉਣ ਜਾਂ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਨੂੰ ਮਿਲਾਉਣ ਤੋਂ ਰੋਕਦੇ ਹਨ।
Entities ਉਹ “ਚੀਜ਼ਾਂ” ਹਨ ਜੋ ਤੁਹਾਡੀ ਐਪ ਟਰੈਕ ਕਰਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਸਪੱਸ਼ਟ ਨਾਂ ਦਿੰਦੇ ਹੋ ਤਾਂ ਤੁਹਾਡਾ AI ਬਿਲਡਰ ਸਕ੍ਰੀਨ, ਫਾਰਮ ਅਤੇ ਡੇਟਾਬੇਸ ਉਹੀ ਤਰੀਕੇ ਨਾਲ ਬਣਾ ਸਕਦਾ ਹੈ। ਇਹ mismatched fields ਅਤੇ ਬੇਕਾਰ ਵਾਧੂ ਫੀਚਰਾਂ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।
ਸ਼ੁਰੂ ਕਰੋ ਆਪਣੇ ਕੋਰ ਨਾਉਂ ਦੀ ਲਿਸਟ ਨਾਲ। ਜੇ ਐਪ “ਪ੍ਰੋਜੈਕਟਾਂ ਪ੍ਰਬੰਧਨ” ਲਈ ਹੈ ਤਾਂ ਨਾਉਂ ਹੋ ਸਕਦੇ ਹਨ Project, Task, Comment. ਜੇ “ਹੁਅਰਕੱਟ ਬੁੱਕਿੰਗ” ਲਈ ਹੈ ਤਾਂ Booking, Service, Customer, Staff ਹੋ ਸਕਦੇ ਹਨ।
ਹਰ ਐਂਟਿਟੀ ਲਈ ਫੀਲਡ ਆਮ ਬੋਲਚਾਲ ਦੀ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖੋ, ਡੇਟਾਬੇਸ ਦੀ ਭਾਸ਼ਾ ਵਿੱਚ ਨਹੀਂ। ਸੋਚੋ ਕਿ ਇੱਕ ਵਿਅਕਤੀ ਫਾਰਮ ਵਿੱਚ ਕੀ ਟਾਈਪ ਕਰੇਗਾ।
ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਫੀਲਡ ਨੂੰ ਇੱਕ ਵਾਕ ਵਿੱਚ ਸਮਝਾ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਇਹ ਸ਼ਾਇਦ ਪਹਿਲੇ ਸੰਸਕਰਨ ਲਈ ਬਹੁਤ ਵੇਰਵਾ ਹੈ।
ਇਹ ਦੱਸੋ ਕਿ ਐਂਟਿਟੀਆਂ ਕਿਵੇਂ ਜੁੜਦੀਆਂ ਹਨ:
“ਇੱਕ user ਨੂੰ ਬਹੁਤ ਸਾਰੇ projects ਹੋ ਸਕਦੇ ਹਨ.” “ਹਰ task ਇੱਕ project ਨਾਲ ਸਬੰਧਤ ਹੈ.” “ਇੱਕ comment ਇੱਕ task ਨਾਲ ਜੁੜਿਆ ਹੈ ਅਤੇ ਇੱਕ ਲੇਖਕ ਹੈ.”
ਇਸ ਨਾਲ ਬਿਲਡਰ ਨੂੰ ਲਗਾਤਾਰ ਸੂਚੀਆਂ, ਡੀਟੇਲ ਪੇਜਾਂ ਅਤੇ ਫਿਲਟਰ ਬਣਾਉਣ ਲਈ ਕਾਫੀ ਢਾਂਚਾ ਮਿਲਦਾ ਹੈ।
ਕੁਝ ਡਾਟਾ ਨਿਯਮ ਜੋ ਗੁੰਝਲਦਾਰ ਵਰਤਾਰ ਨੂੰ ਟਾਲਦੇ ਹਨ:
ਅੰਤ 'ਚ, ਉਹ ਚੀਜ਼ਾਂ ਨਾਂ ਦਿਓ ਜੋ ਤੁਸੀਂ ਹੁਣ ਨਹੀਂ ਸਟੋਰ ਕਰੋਗੇ। ਉਦਾਹਰਨ: “v1 ਵਿੱਚ ਕੋਈ ਫਾਈਲ ਅਟੈਚਮੈਂਟ ਨਹੀਂ”, ਜਾਂ “ਹੁਣ ਸਿਰਫ਼ ਬੁੱਕਿੰਗ, ਸਟਾਫ਼ ਸ਼ੈਡਿਊਲ ਨਹੀਂ”। ਇਹ ਬਾਹਰਕੀਆਂ ਐਪ ਨੂੰ ਗਲਤ ਦਿਸ਼ਾ ਵਿੱਚ ਵਧਣ ਤੋਂ ਰੋਕਦੀਆਂ ਹਨ।
ਪਹਿਲੀ ਵਰਜਨ ਤਦੋਂ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਇਸ ਦੇ ਸਕ੍ਰੀਨਾਂ ਦੀ ਗਿਣਤੀ ਘੱਟ ਤੇ ਸਥਿਰ ਹੋਵੇ। ਜੇ ਤੁਸੀਂ ਹਰ ਸਕ੍ਰੀਨ ਜੋ ਐਪ ਨੂੰ ਭਵਿੱਖ ਵਿੱਚ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ ਤਿਆਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋਗੇ, ਤਾਂ AI ਬਿਲਡਰ ਹਮੇਸ਼ਾ ਅਨੁਮਾਨ ਲਗਾਉਂਦਾ ਰਹੇਗਾ, ਅਤੇ UI ਹਰ build ਨਾਲ ਘੁੰਮਦਾ ਰਹੇਗਾ।
ਮੁੱਖ ਕੰਮ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ ਘੱਟੋ-ਘੱਟ ਸਕ੍ਰੀਨਾਂ ਨਾਂ ਦਿਓ। ਜ਼ਿਆਦਾਤਰ MVPs ਲਈ 3–6 ਸਕ੍ਰੀਨ ਕਾਫੀ ਹੁੰਦੇ ਹਨ:
ਫਿਰ happy path ਨੂੰ ਛੋਟੀ ਕਹਾਣੀ ਵਜੋਂ ਲਿਖੋ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤਕ।
ਉਦਾਹਰਨ: “ਯੂਜ਼ਰ ਸਾਈਨ-ਇਨ ਕਰਦਾ ਹੈ, ਲਿਸਟ 'ਤੇ ਆਂਦਾ ਹੈ, ਖੋਜ ਕਰਦਾ ਹੈ, ਇੱਕ ਆਈਟਮ ਖੋਲ੍ਹਦਾ ਹੈ, ਇੱਕ ਫੀਲਡ ਸੋਧਦਾ ਹੈ, ਸੇਵ ਕਰਦਾ ਹੈ, ਅਤੇ ਲਿਸਟ ਵਾਪਸ ਆ ਜਾਂਦਾ ਹੈ।”
ਹਰੇਕ ਸਕ੍ਰੀਨ ਲਈ ਮੁੱਖ ਐਕਸ਼ਨਾਂ ਨੂੰ ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ ਨੋਟ ਕਰੋ। “ਹਰ ਚੀਜ਼ ਕਰੋ” ਵਾਲੇ ਸਕ੍ਰੀਨ ਤੋਂ ਬਚੋ। 2–4 ਐਕਸ਼ਨ ਚੁਣੋ ਜੋ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਮੱਤਵਪੂਰਨ ਹਨ: create, edit, search, export, archive ਆਦਿ।
ਇਹ ਵੀ ਤੈਅ ਕਰੋ ਕਿ ਕੀ ਤੇਜ਼ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਕੀ “ਠੀਕ-ਠਾਕ” ਹੋ ਸਕਦਾ ਹੈ। “ਤੇਜ਼” ਆਮ ਤੌਰ 'ਤੇ ਮਤਲਬ ਹੈ ਕਿ ਲਿਸਟ ਨੂੰ ਜਲਦੀ ਖੋਲ੍ਹਨਾ, ਖੋਜ ਦਾ ਜਵਾਬ ਤੇਜ਼ ਹੋਣਾ, ਅਤੇ ਸੇਵ ਤੁਰੰਤ ਮਹਿਸੂਸ ਹੋਣਾ। “ਠੀਕ-ਠਾਕ” ਵਿੱਚ export ਕੁਝ ਸਕਿੰਟ ਲੈ ਸਕਦਾ ਹੈ, ਬੁਨਿਆਦੀ analytics, ਜਾਂ ਮੂਲ settings ਸ਼ਾਮਲ ਹੋ ਸਕਦੇ ਹਨ।
ਆਖਿਰ 'ਚ, ਪ੍ਰਤੀ ਭੂਮਿਕਾ ਇੱਕ ਲਾਈਨ ਵਿੱਚ ਰੋਲ ਅਤੇ ਐਕਸੈਸ ਕੈਪਚਰ ਕਰੋ:
ਇਹ ਸਕ੍ਰੀਨਾਂ ਨੂੰ ਪੂਰਵਾਨੁਮਾਨਯੋਗ ਬਣਾਉਂਦਾ ਹੈ, ਪਰਮਿਸ਼ਨ ਸਰਪ੍ਰਾਈਜ਼ ਘਟਾਉਂਦਾ ਹੈ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਮੁੜ-ਲਿਖਾਈ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ।
ਅਧਿਕਤਰ ਰੀਰਾਇਟ ਇੱਕੇ ਕਾਰਨ ਕਰਕੇ ਹੁੰਦੇ ਹਨ: ਐਪ ਖੁਸ਼ੀ ਦੇ ਰਸਤੇ 'ਤੇ ਠੀਕ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ, ਫਿਰ ਅਸਲ ਜੀਵਨ ਆਉਂਦਾ ਹੈ ਤੇ ਟੁੱਟ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਵਧੀਆ ਇੱਕ-ਪੰਨੇ ਸਪੈਕ ਟੈਮਪਲੇਟ ਐਜ ਕੇਸ ਅਤੇ ਨੋਨ-ਗੋਲ ਲਈ ਜਗ੍ਹਾ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਉਹ ਛੋਟੀ ਜਗ੍ਹਾ ਘੰਟਿਆਂ ਦੀ ਬਚਤ ਕਰਦੀ ਹੈ।
ਹਰ jobs-to-be-done ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਪੁੱਛੋ: ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ? ਸਧਾਰਨ ਰੱਖੋ, ਤਕਨੀਕੀ ਨਹੀਂ। ਤੁਸੀਂ ਅਸਪਸ਼ਟਤਾ ਦੂਰ ਕਰ ਰਹੇ ਹੋ ਤਾਂ ਕਿ ਬਿਲਡਰ ਹਰ ਵਾਰ ਇੱਕੋ ਫੈਸਲਾ ਕਰੇ।
ਆਮ ਐਜ ਕੇਸ ਜੋ ਲਿਖਣ ਯੋਗ ਹਨ:
ਫਿਰ ਜਵਾਬ ਦਾ ਫੈਸਲਾ ਕਰੋ। ਵਿਸ਼ੇਸ਼ ਹੋਵੋ: “ਐਕਸ਼ਨ ਰੋਕੋ ਅਤੇ ਸਪੱਸ਼ਟ ਸੁਨੇਹਾ ਦਿਖਾਓ,” “ਡ੍ਰਾਫਟ ਵਜੋਂ ਸੇਵ ਕਰਨ ਦਿਓ,” ਜਾਂ “ਇੱਕ ਵਾਰੀ ਰੀਟ੍ਰਾਈ, ਫਿਰ ਫੇਲ 'ਤੇ ਬਟਨ ਦਿਖਾਓ।” ਇਹ ਨਿਯਮ ਸਿੱਧਾ-ਸਿੱਧਾ consistent prompts ਵਿੱਚ ਤਰਜਮਾ ਹੁੰਦੇ ਹਨ।
ਇਕ-ਦੋ ਲਾਈਨਾਂ ਵਿੱਚ ਪ੍ਰਾਈਵੇਸੀ ਅਤੇ ਸੁਰੱਖਿਆ ਦੀਆਂ ਉਮੀਦਾਂ ਜੋੜੋ। ਉਦਾਹਰਨ: “ਘੱਟੋ-ਘੱਟ ਡਾਟਾ ਇਕੱਠਾ ਕਰੋ,” “ਯੂਜ਼ਰ ਆਪਣਾ ਖਾਤਾ ਅਤੇ ਸਾਰਾ ਨਿੱਜੀ ਡਾਟਾ ਮਿਟਾ ਸਕਦਾ ਹੈ,” ਅਤੇ “ਨਿੱਜੀ ਆਈਟਮ ਪਹਿਲਾਂ ਛੁਪਾਓ।” ਜੇ ਤੁਹਾਡੀ ਐਪ ਵਿੱਚ ਯੂਜ਼ਰ-ਜਨਰੇਟ ਕੀਤੀ ਸਮੱਗਰੀ ਹੈ, ਤਾਂ ਰਿਪੋਰਟ ਅਤੇ ਸਪੈਮ ਨਾਲ ਕੀ ਕਰਨਾ ਹੈ ਇਹ ਵੀ ਨੋਟ ਕਰੋ, ਭੰਗਾਰ v1 ਵਿੱਚ ਭੀ ਸਾਦਾ ਹੋ ਸਕਦਾ ਹੈ।
ਆਖਿਰ 'ਚ, ਨੋਨ-ਗੋਲ ਲਿਖੋ ਤਾਂ ਕਿ ਸਕੋਪ ਕ੍ਰੀਪ ਰੋਕਿਆ ਜਾ ਸਕੇ। ਵੱਡੇ ਲੁਭਾਵੇ ਫੀਚਰ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਹੁਣ ਨਹੀਂ ਕਰੋਗੇ।
ਕੁਝ ਸਪੱਸ਼ਟ ਨੋਨ-ਗੋਲ ਉਦਾਹਰਨ:
ਊਦਾਹਰਨ: ਜੇ ਜੌਬ “ਇਵੈਂਟ ਬਣਾਉਣਾ” ਹੈ, ਤਾਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਕਿ ਜਦੋਂ ਤਾਰੀਖ ਪਿਛਲੀ ਹੋ, ਸਿਰਲੇਖ ਖਾਲੀ ਹੋ ਜਾਂ ਉਹੀ ਇਵੈਂਟ ਦੋ ਵਾਰੀ ਬਣਾਇਆ ਜਾਵੇ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ। ਉਹ ਸਪੱਸ਼ਟਤਾ ਅਗਲੇ ਰੀਰਾਇਟ ਨੂੰ ਰੋਕਦੀ ਹੈ।
ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ consistent ਨਤੀਜੇ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਇਹ ਹੈ ਕਿ ਇੱਕ-ਪੰਨੇ ਸਪੈਕ ਦੇ ਹਰ ਬਲਾਕ ਨੂੰ ਇੱਕ ਛੋਟੀ, ਸਿਧੀ ਹਦਾਇਤ ਵਿੱਚ ਬਦਲੋ। ਇਸਨੂੰ ਇੰਝ ਸੋਚੋ ਕਿ ਤੁਸੀਂ ਬਿਲਡਰ ਨੂੰ ਇੱਕ-ਇੱਕ ਕਾਰਡ ਦੇ ਰਹੇ ਹੋ ਜੋ ਉਹ ਆਰਡਰ ਵਿੱਚ ਫਾਲੋ ਕਰੇ, ਨਾਂ ਕਿ ਇੱਕ ਵੱਡਾ, ਧੁੰਦਲਾ অনੁਰੋਧ।
ਹਰ ਬਲਾਕ (Users, Jobs, Entities, Screens, Edge cases, Non-goals) ਨੂੰ ਇੱਕ-ਇੱਕ ਨਿਰਦੇਸ਼ ਵਿੱਚ ਬਦਲੋ ਜਿਸ ਵਿੱਚ ਸਪੱਸ਼ਟ ਨਾਉਂ ਅਤੇ ਕਿਰਿਆ ਹੁੰਦੇ ਹਨ। “ਸਾਫ਼” ਵਰਗੀਆਂ ਰਾਏਂਤੋਂ ਬਚੋ ਜਦ ਤੱਕ ਤੁਸੀਂ ਇਹ ਵੀ ਨਾ ਦੱਸੋ ਕਿ “ਸਾਫ਼” ਦਾ ਕੀ ਮਤਲਬ ਹੈ।
ਦੋ-ਕਦਮੀ ਚੱਕਰ ਵਰਤੋ: ਪਹਿਲਾਂ ਬਣਾਓ, ਫਿਰ ਸਪੈਕ ਨਾਲ ਵੈਰੀਫਾਈ ਕਰੋ।
ਇੱਕ ਛੋੱਟਾ definition of done ਜੋ ਬਿਲਡਰ ਨੂੰ ਬਤਾਏ ਕਿ ਰੁਕਣ ਕਦੋਂ ਹੈ:
ਕੇਵਲ ਉਹ constraints ਜੋ ਸੱਚਮੁੱਚ ਮਾਮਲੇ ਵਿਚ ਮਹੱਤਵਪੂਰਨ ਹਨ ਸ਼ਾਮਲ ਕਰੋ: ਲਾਜ਼ਮੀ ਡਿਵਾਈਸ (mobile-first), ਲਾਜ਼ਮੀ auth (admin-only actions), ਜਾਂ ਲੋੜੀਦਾ stack (React frontend, Go backend, PostgreSQL) ਜੇ ਤੁਹਾਡਾ ਪLatਫਾਰਮ ਇਸਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ ਸੋਧ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਸਪੈਕ ਬਲਾਕ ਦਾ ਹਵਾਲਾ ਦਿਓ, ਕੋਡ ਦਾ ਨਹੀਂ।
ਉਦਾਹਰਨ: “Entities ਬਲਾਕ ਅਪਡੇਟ ਕਰੋ: ‘Subscription’ ਸ਼ਾਮਲ ਕਰੋ ਫੀਲਡ X ਅਤੇ Y. ਫਿਰ ਸਿਰਫ ਪ੍ਰਭਾਵਿਤ APIs ਅਤੇ ਸਕ੍ਰੀਨਾਂ ਨੂੰ ਪੁਨਰ-ਤਿਆਰ ਕਰੋ, ਅਤੇ validation ਕਦਮ ਫਿਰ ਚਲਾਓ।”
ਇਹ ਤਰੀਕਾ ਯੋਜਨਾ ਨੂੰ ਸਥਿਰ ਰੱਖਦਾ ਹੈ ਪਰ ਤੁਹਾਨੂੰ ਸੁਰੱਖਿਅਤ ਤੌਰ 'ਤੇ ਇਟਰੇਟ ਕਰਨ ਦਿੰਦਾ ਹੈ।
ਕਲਪਨਾ ਕਰੋ ਤੁਸੀਂ ਇੱਕ ਸਧਾਰਣ appointment reminder tracker ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ ਇੱਕ ਛੋਟੀ ਸੈਲੂਨ ਲਈ। ਮਕਸਦ ਪੂਰੇ booking ਸਿਸਟਮ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਹਲਕਾ-ਫੁਲਕਾ ਥਾਂ ਹੈ appointments ਸੰਭਾਲਣ ਅਤੇ reminders ਭੇਜਣ ਲਈ।
ਹੇਠਾਂ ਇੱਕ-ਪੰਨੇ ਸਪੈਕ ਟੈਮਪਲੇਟ ਤਰ੍ਹਾਂ ਭਰਿਆ ਹੋਇਆ ਹੈ।
APP: Appointment Reminder Tracker
GOAL: Track appointments and send reminders. No payments, no online booking.
USERS
1) Owner/Staff: creates and manages appointments, wants fewer no-shows.
2) Client: receives reminders, wants an easy way to confirm.
JOBS TO BE DONE (JTBD)
1) As staff, I add an appointment in under 30 seconds.
2) As staff, I see today's schedule in time order.
3) As staff, I mark a client as confirmed or no-show.
4) As staff, I resend a reminder when asked.
5) As a client, I confirm from a message without creating an account.
ENTITIES (DATA)
- Client: id, name, phone, email (optional), notes
- Appointment: id, client_id, service, start_time, duration_min, status (scheduled/confirmed/canceled/no_show)
- Reminder: id, appointment_id, channel (sms/email), send_at, sent_at, result (ok/failed)
- StaffUser: id, name, role (owner/staff)
Relationships: Client 1-to-many Appointment. Appointment 1-to-many Reminder.
EDGE CASES (WHAT BREAKS NAIVE BUILDS)
1) Duplicate client (same phone, different name)
2) Overlapping appointments for the same staff
3) Time zone changes (travel, daylight saving)
4) Client has no email, SMS only
5) Reminder send fails, needs retry and visible status
6) Appointment edited after reminder scheduled
7) Client cancels after confirmation
8) Same-day appointment created 10 minutes before start
9) Phone number format varies (+1, spaces, dashes)
10) Deleting a client with future appointments
ਹੁਣ ਇਸਨੂੰ Planning Mode app building ਵਿੱਚ ਪੇਸਟ ਕਰਨ ਲਾਇਕ ਇੱਕ ਪ੍ਰੋਂਪਟ ਬੰਡਲ ਵਿੱਚ ਬਦਲੋ। ਸਖਤ ਰੱਖੋ ਤਾਂ ਜੋ ਬਿਲਡਰ ਹਰ ਵਾਰ ਇੱਕੋ ਚੋਣ ਕਰੇ।
PLANNING MODE PROMPT BUNDLE
1) Build an MVP web app with these entities and relationships exactly as written.
2) Required screens: Login (StaffUser), Today Schedule, Client List, Client Detail, Appointment Create/Edit.
3) Required flows: create client, create appointment for a client, confirm/cancel/no-show, schedule reminders, resend reminder.
4) Constraints: no payments, no public booking page, no client accounts.
5) Edge-case handling: implement validation and UI feedback for all 10 edge cases listed.
6) Output: database schema, API endpoints, and UI behavior notes per screen.
ਗੰਦੇ ਨਤੀਜੇ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਧੁੰਦਲੇ ਸਪੈਕ ਅਤੇ ਫੀਚਰ ਵਿਸ਼ਲਿਸਟ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ। AI ਬਿਲਡਰ ਉਹੀ ਕਰੇਗਾ ਜੋ ਤੁਸੀਂ ਮੰਗਦੇ ਹੋ, ਪਰ ਉਹ ਤੁਹਾਡੀ ਸੋਚ ਪੜ੍ਹ ਨਹੀਂ ਸਕਦਾ। ਛੋਟੇ-ਛੋਟੇ ਖਾਲੀਆਂ ਜਗ੍ਹਾ ਵੱਡੇ ਫਰਕ ਬਣ ਜਾਂਦੀਆਂ ਹਨ।
ਇਹ ਫਲ਼ਤੁਆਂ ਸਭ ਤੋਂ ਵੱਧ ਇਕਸਾਰਤਾ ਤੋੜਦੀਆਂ ਹਨ, ਅਤੇ ਇੱਕ-ਪੰਨੇ ਸਪੈਕ ਟੈਮਪਲੇਟ ਉਨ੍ਹਾਂ ਨੂੰ ਠੀਕ ਕਰਦਾ ਹੈ:
ਜੇ ਤੁਸੀਂ Planning Mode Koder.ai ਵਿੱਚ ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਬੁਨਿਆਦੀ ਗੱਲਾਂ ਹੋਰ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੋ ਜਾਂਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਯੋਜਨਾ ਵਾਰ-ਵਾਰ ਪ੍ਰੋਂਪਟਾਂ ਦਾ ਸਰੋਤ ਬਣ ਜਾਂਦੀ ਹੈ। ਸਪੱਸ਼ਟ jobs, ਛੋਟਾ ਡਾਟਾ ਮਾਡਲ, ਸਪੱਠ ਪਰਮਿਸ਼ਨ ਅਤੇ ਟੈਸਟੇਬਲ ਸਫਲਤਾ ਨਿਯਮ ਹਰ ਨਵੇਂ ਸਕ੍ਰੀਨ ਨੂੰ ਬਾਕੀ ਨਾਲ ਮਿਲਾਉਂਦੇ ਹਨ।
ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੇ ਇੱਕ-ਪੰਨੇ ਸਪੈਕ ਟੈਮਪਲੇਟ 'ਤੇ ਇੱਕ ਤੇਜ਼ ਨਜ਼ਰ ਮਾਰੋ। ਮਕਸਦ ਉਹ ਖਾਮੀਆਂ ਹਟਾਉਣਾ ਹੈ ਜੋ AI ਬਿਲਡ ਨੂੰ ਅਨੁਮਾਨ ਲਗਾਉਣ 'ਤੇ ਮਜਬੂਰ ਕਰਦੀਆਂ ਹਨ। ਉਹ ਅਨੁਮਾਨ ਰੀਰਾਇਟਾਂ ਵਿੱਚ ਬਦਲ ਜਾਂਦੇ ਹਨ।
ਤੇਜ਼ ਪੂਰਨਤਾ ਜਾਂਚ:
ਜੇ ਤੁਸੀਂ ਇੱਕ ਸਧਾਰਨ ਸਕੋਰਿੰਗ ਵਿਚਾਰ ਲੈਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਹਰ ਖੇਤਰ ਨੂੰ 0 ਤੋਂ 2 ਤੱਕ ਦਰਜਾ ਦਿਓ:
ਕਮਾਈ ਲਈ ਘੱਟੋ-ਘੱਟ 7/10 ਦਾ ਤੁਹਾਡਾ ਲਕਸ਼ ਹੋਵੇ। ਜੇ Entities ਜਾਂ Edge cases 2 ਤੋਂ ਘੱਟ ਹਨ, ਪਹਿਲਾਂ ਉਹਨਾਂ ਨੂੰ ਠੀਕ ਕਰੋ।
ਪਹਿਲੇ ਬਿਲਡ ਤੋਂ ਬਾਅਦ, ਐਪ ਨੂੰ ਹਰ job-to-be-done ਦੇ ਮੁਕਾਬਲੇ ਜਾਂਚੋ ਅਤੇ mismatches ਨੋਟ ਕਰੋ। ਹਰ ਤਬਦੀਲੀ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ snapshot ਲਵੋ। ਜੇ ਨਵਾਂ ਇਟਰੇਸ਼ਨ ਚੀਜ਼ਾਂ ਨੂੰ ਖਰਾਬ ਕਰਦਾ ਹੈ, ਤਾਂ rollback ਕਰੋ ਅਤੇ ਇੱਕ ਛੋਟੀ ਸੋਧ ਕੋਸ਼ਿਸ਼ ਕਰੋ।
ਜੇ ਤੁਸੀਂ Koder.ai (koder.ai) ਵਰਤ ਰਹੇ ਹੋ, Planning Mode ਵਿਹਾਰਕ ਥਾਂ ਹੈ ਇਹ ਇੱਕ-ਪੰਨੇ ਸਪੈਕ ਨੂੰ “ਸਰੋਤ-ਸਚ” ਵਜੋਂ ਰੱਖਣ ਲਈ ਅਤੇ ਸਿਰਫ ਜੋ ਬਦਲਿਆ ਹੈ ਉਹ ਦੁਬਾਰਾ ਜਨਰੇਟ ਕਰਨ ਲਈ।
ਸਪੈਕ ਨੂੰ ਜ਼ੁਰੀਏ ਰੱਖੋ ਜਿਵੇਂ ਤੁਸੀਂ ਅੱਗੇ ਵਧਦੇ ਹੋ। ਜਦੋਂ ਤੁਸੀਂ ਕੋਈ ਬਦਲਾਵ ਮਨਜ਼ੂਰ ਕਰਦੇ ਹੋ, ਉਸੇ ਦਿਨ ਸਪੈਕ ਅਪਡੇਟ ਕਰੋ। ਜਦੋਂ ਤੁਸੀਂ ਕੋਈ ਬਦਲਾਵ ਰੱਦ ਕਰਦੇ ਹੋ, ਤਾਂ ਲਿਖੋ ਕਿ ਕਿਉਂ, ਤਾਂ ਜੋ ਅਗਲੀ ਪ੍ਰੋਂਪਟ ਇੱਕੋ ਜਿਹੀ ਰਹੇ।
Planning Mode ਉਹ ਛੋਟੀ ਰੁਕਾਵਟ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਸਕ੍ਰੀਨ ਅਤੇ ਕੋਡ ਜਨਰੇਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਮੁੱਖ ਫੈਸਲੇ ਲਿਖ ਕੇ ਰੱਖਦੇ ਹੋ। ਮਕਸਦ ਹੈ ਇਕਸਾਰਤਾ: ਉਹੀ ਯੂਜ਼ਰ, ਫਲੋ ਅਤੇ ਡਾਟਾ ਨਾਮ UI, ਬੈਕਐਂਡ ਅਤੇ ਡੇਟਾਬੇਸ ਵਿੱਚ ਇਕੋ ਹੋਣ, ਤਾਂ ਜੋ ਹਰ ਵਾਰ ਨਵੇਂ ਅਨੁਮਾਨਾਂ 'ਤੇ ਆਧਾਰਿਤ ਮੁੜ-ਬਨਾਉਣ ਨਾ ਹੋਵੇ।
ਇੱਕ-ਪੰਨੇ ਦੇ ਮਕਸਦ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਇਹ ਚਾਰ ਬਲਾਕ ਭਰੋ:
ਜੇ ਇਹ ਇੱਕ ਪੰਨੇ 'ਚ ਫਿੱਟ ਨਹੀਂ ਹੁੰਦਾ, ਤਾਂ v1 ਲਈ ਫੀਚਰ ਕੱਟੋ।
ਇਹ ਪ੍ਰੈਕਟਿਕਲ ਅਤੇ ਇਰਾਦੇ-ਅਧਾਰਤ ਰੱਖੋ। ਕੁਝ ਯੂਜ਼ਰ ਕਿਸਮਾਂ ਨਾਂ ਦਿਓ ਅਤੇ ਉਹ ਕੀ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਨ, ਇੱਕ ਇਕ-ਪੰਤੀ ਲਾਈਨ ਵਿੱਚ।
ਉਦਾਹਰਨ: “Owner/Staff ਜੋ ਮੁਲਾਕਾਤਾਂ ਬਣਾਉਂਦਾ/ਸੰਭਾਲਦਾ ਹੈ” “Admin” ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਸਪੱਸ਼ਟ ਹੈ। ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਭੂਮਿਕਾ ਨੂੰ ਇੱਕ ਲਾਈਨ ਵਿੱਚ ਵੇਖਾ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਉਹ ਸ਼ਾਇਦ ਬੇਕਾਰ ਹੈ।
ਹਰ ਜੌਬ ਇੱਕ ਟੈਸਟੇਬਲ ਫਾਰਮੈਟ ਵਿੱਚ ਲਿਖੋ:
ਫਿਰ ਇੱਕ ਛੋਟਾ definition of done ਜੋ ਦੱਸੇ ਕਿ ਕੀ ਸੇਵ ਕੀਤਾ ਜਾਂ ਅਪਡੇਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਬਿਲਡਰ ਨੂੰ ਬੇਸਰੂਪ ਕਦਮਾਂ ਜਾਂ ਅਣਜਾਣ ਸਕ੍ਰੀਨਾਂ ਬਣਾਉਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।
“ਜਿਨ੍ਹਾਂ ਚੀਜ਼ਾਂ ਐਪ ਯਾਦ ਰੱਖਦੀ ਹੈ” ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖੋ ਅਤੇ ਹਰ ਏਕ ਨੂੰ 3–7 ਫੀਲਡ ਦਿਓ ਜੋ ਸਕ੍ਰੀਨਾਂ 'ਤੇ ਵਰਤੇ ਜਾਣਗੇ।
ਉਦਾਹਰਨ: Appointment: start time, duration, status, service, client. ਜੇ ਕੋਈ ਫੀਲਡ ਕਿਸੇ ਜੌਬ ਜਾਂ ਸਕ੍ਰੀਨ ਵਿੱਚ ਵਰਤੀ ਨਹੀਂ ਜਾਂਦੀ, ਤਾਂ v1 ਲਈ ਉਸਨੂੰ ਛੱਡ ਦਿਓ।
ਰਿਸ਼ਤੇ ਸਧਾਰਨ ਵਾਕਾਂ ਵਿੱਚ ਲਿਖੋ:
ਫਿਰ ਕੁਝ ਬੁਨਿਆਦੀ ਨਿਯਮ ਜੋ ਗਲਤ ਵਰਤBehavior ਤੋਂ ਬਚਾਏ: required fields, unique fields, defaults. ਇਹ ਸੂਚਨਾ ਸੂਚੀਆਂ, ਫਾਰਮਾਂ ਅਤੇ ਫਿਲਟਰਾਂ ਨੂੰ ਮੈਚ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦੀ ਹੈ।
ਪਹਿਲੀ ਵਰਜਨ ਲਈ 3 ਤੋਂ 6 ਸਕ੍ਰੀਨਾਂ ਦਾ ਇੱਕ ਛੋਟਾ ਸੈੱਟ ਅਕਸਰ ਕਾਫੀ ਹੁੰਦਾ ਹੈ:
ਹਰ ਜੌਬ ਲਈ ਇਕ “happy path” ਲਿਖੋ (ਆਰੰਭ → ਐਕਸ਼ਨ → ਸੇਵ → ਪੁਸ਼ਟੀ) ਤਾਂ ਕਿ ਫਲੋ ਘੁੰਮਣ ਨਾ ਲੱਗੇ।
ਹੇਠਾਂ ਕੀ ਆਮ ਤੌਰ 'ਤੇ ਟੁੱਟਦਾ ਹੈ, ਉਨ੍ਹਾਂ ਚੀਜ਼ਾਂ ਨੂੰ ਲਿਖੋ:
ਹਰ ਇੱਕ ਲਈ ਇਛਿਤ ਵਤੀਰਾ ਵੀ ਦਿਓ: “ਐਕਸ਼ਨ ਰੋਕੋ ਅਤੇ ਸਪੱਸ਼ਟ ਸੁਨੇਹਾ ਦਿਖਾਓ”, “ਦਫ਼ਤਰ ਰੂਪ ਵਿੱਚ ਸੇਵ ਕਰਨ ਦਿਓ”, ਜਾਂ “ਇੱਕ ਵਾਰੀ ਰੀਟ੍ਰਾਈ, ਫਿਰ ਬਟਨ ਦਿਖਾਓ” ਆਦਿ।
ਹਰ ਬਲਾਕ ਨੂੰ ਇੱਕ ਛੋਟੀ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ ਵਿੱਚ ਬਦਲੋ ਜੋ ਬਿੱਲਡਰ ਚਲਾ ਸਕੇ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰ ਸਕੇ।
ਸਧਾਰਣ ਸੀਕਵੈਂਸ:
ਇਹ ਇਕ ਵੱਡੇ, ਧੁੰਦਲੇ ਪ੍ਰੋਂਪਟ 'ਤੇ ਨਿਰਭਰ ਰਹਿਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।
ਸਪੈਕ ਨੂੰ ਪਹਿਲਾਂ ਅਪਡੇਟ ਕਰੋ, ਫਿਰ ਸਿਰਫ ਜਿਹੜੇ ਹਿੱਸੇ ਪ੍ਰਭਾਵਿਤ ਹੁੰਦੇ ਹਨ ਉਹ ਦੁਬਾਰਾ ਬਣਵਾਓ।
ਉਦਾਹਰਨ: “Entities ਬਲਾਕ ਅੱਪਡੇਟ ਕਰੋ: ‘Subscription’ ਸ਼ਾਮਲ ਕਰੋ ਫੀਲਡ X ਅਤੇ Y; ਪ੍ਰਭਾਵਿਤ APIs ਅਤੇ ਸਕ੍ਰੀਨਾਂ ਨੂੰ ਰੀ-ਜਨਰੇਟ ਕਰੋ; ਫਿਰ ਸਪੈਕ ਦੇ ਮੁਕਾਬਲੇ ਪੁਸ਼ਟੀ ਕਰੋ।”
ਇਸ ਤਰੀਕੇ ਨਾਲ ਸਪੈਕ ਇੱਕ ਸਚਾਈ ਦਾ ਸਰੋਤ ਰਹਿੰਦਾ ਹੈ ਅਤੇ scattered edits ਤੋਂ ਬਚਾਅ ਹੁੰਦਾ ਹੈ।