प्रॉम्प्ट (Prompt) लिखने की कला: Codex से सही परिणाम प्राप्त करना

📚 सीरीज नेविगेशन: पिछला लेख 12 · 斜杠 (slash) कमांड्स और शॉर्टकट्स चैट में क्रेडेंशियल्स जैसे मॉडल बदलना, संदर्भ साफ़ करना और कोटा देखने के बटनों को समझाता है। यह लेख एक पायदान आगे की बात करता है: शॉर्टकट्स समझने के बाद, निर्देश (प्रॉम्प्ट) सही तरीके से कैसे लिखा जाए। एक ही कोडिंग कार्य के लिए निर्देश सही न होने पर Codex का परिणाम बिल्कुल अलग हो सकता है।

सभी कहते हैं कि "AI कोडिंग टूल कितना मजबूत है, यह उसके मॉडल पर निर्भर करता है"—लेकिन मैं इस बात से असहमत हूँ।

सच तो यह है कि: एक ही GPT-5 मॉडल और एक ही प्रोजेक्ट में, निर्देश देने की सही समझ रखने वाला व्यक्ति तीन वाक्यों में काम पूरा करवा लेता है, और गलत निर्देश देने वाला पांच बार सुधार करवाने के बाद भी असंतुष्ट रहता है। मॉडल काफी शक्तिशाली है, लेकिन समस्या उसकी कोडिंग क्षमता में नहीं, बल्कि उसे दिए गए निर्देश (प्रॉम्प्ट) में होती है। यदि आप केवल इतना कहेंगे कि "इस बग को ठीक करें", तो उसे खुद अनुमान लगाना होगा—कि किस फ़ाइल में, क्या एरर है, और उसे कैसे बदलना है। और यदि उसने गलत अनुमान लगाया, तो आप दोष टूल को देंगे, जबकि गलती टूल की नहीं, निर्देश की थी।

पिछले साल मुझसे ऐसी ही एक गलती हुई थी। मेरे एक Node प्रोजेक्ट में 500 एरर आ रही थी, और मैंने सीधे लिख दिया "लॉगिन एपीआई काम नहीं कर रही, ठीक करें", और एरर लॉग भी नहीं दिया। Codex ने प्रोजेक्ट में खोज की और एक ऐसे हिस्से में बदलाव कर दिया जो वास्तव में एरर का कारण नहीं था—एरर एक ऐसे एनवायरनमेंट वेरिएबल के कारण थी जिसके बारे में उसने कभी पढ़ा ही नहीं था। तब मुझे समझ आया कि Codex की कोडिंग सीमा मेरे निर्देशों की सीमा पर निर्भर करती है।

इसलिए इस लेख में हम प्रॉम्प्ट के कोई रटे-रटाए फॉर्मेट नहीं सीखेंगे, बल्कि इस मूल बात को समझेंगे कि Codex को कोडिंग के लिए किस जानकारी की आवश्यकता होती है, ताकि निर्देश स्वतः ही सही लिखे जा सकें।

इस लेख को पढ़ने के बाद, आपको मिलेगा:

• "गलत निर्देश बनाम सही निर्देश" की तुलनात्मक तालिका, जिससे कोडिंग में एरर्स कम होंगी
• प्रॉम्प्ट लिखने का "चार-चरणीय" ढांचा: लक्ष्य, कार्य क्षेत्र, सीमाएं, और सत्यापन—जिससे Codex को अनुमान लगाने की आवश्यकता नहीं होगी
• बड़े कार्यों को छोटे और समझने योग्य चरणों में विभाजित करने की तकनीक
• /goal (लक्ष्य मोड) का उपयोग करके कोडिंग के नियमों को फिक्स करना

⚠️ निर्देश, पैरामीटर्स और डिफ़ॉल्ट व्यवहार Codex के आधिकारिक दस्तावेज़ों पर आधारित हैं; मॉडल के नाम, सेटिंग्स बदल सकते हैं।

---

01 गलत निर्देश की कमियाँ

पिछले उदाहरण को देखें। "लॉगिन एपीआई काम नहीं कर रही, ठीक करें" निर्देश में Codex के लिए आवश्यक जानकारी की बहुत कमी थी:

• कौन सी लॉगिन एपीआई? उसे पूरे प्रोजेक्ट में खोजना होगा।
• एरर क्या है? क्या एरर लॉग है, और एरर किस परिस्थिति में आती है? उसे कुछ नहीं पता।
• सही व्यवहार क्या होना चाहिए? उसे सामान्य कोडिंग नियमों के अनुसार अनुमान लगाना होगा।

जैसा कि लेख 06 में बताया गया था, Codex एजेंट लूप (agent loop) में काम करता है—सोचना, कोडिंग करना, टेस्ट रन करना। लेकिन यदि चक्र के पहले चरण "सोचो" में ही अधूरी जानकारी दी जाएगी, तो वह गलत दिशा में काम करेगा।

सादृश्य: डिलीवरी एड्रेस देना। यदि आप केवल "पार्क एवेन्यू सोसाइटी" लिखेंगे, तो डिलीवरी बॉय को हर बिल्डिंग में खोजना होगा और वह गलत डिलीवरी भी कर सकता है। लेकिन यदि आप "पार्क एवेन्यू सोसाइटी, विंग बी, फ्लैट 302, गेट पर हरा गमला" लिखेंगे, तो वह सीधे पहुँचेगा। पता जितना स्पष्ट होगा, काम उतना ही आसान होगा। Codex के निर्देश भी उसी पते की तरह हैं।

आधिकारिक दस्तावेज़ों के अनुसार निर्देशों की तुलना:

परिदृश्य	❌ गलत निर्देश	✅ सही निर्देश
बग फिक्स करना	"लॉगिन एपीआई काम नहीं कर रही, ठीक करें"	"सेशन टाइमआउट के बाद POST /api/login कॉल करने पर 500 एरर आ रही है। पहले src/auth/ में टोकन रिफ्रेश लॉजिक की जांच के लिए टेस्ट लिखें, फिर सुधार करें और टेस्ट रन करके पुष्टि करें"
टेस्ट लिखना	"parser.py के लिए टेस्ट लिखें"	"parser.py के parse_date फ़ंक्शन के लिए टेस्ट लिखें, जिसमें खाली स्ट्रिंग और इनवैलिड फॉर्मेट की एरर कंडीशन्स शामिल हों; mock का उपयोग न करें और pytest चलाकर पुष्टि करें"
नया फीचर जोड़ना	"प्रोजेक्ट में एक्सपोर्ट फीचर जोड़ें"	"पहले report.py में export_csv फ़ंक्शन को देखें, और उसी स्टाइल में export_json जोड़ें; बाहरी लाइब्रेरीज़ इम्पोर्ट न करें"
कोड समझना	"इस मॉड्यूल को समझाएं"	"transform मॉड्यूल का git इतिहास देखें और समझाएं कि इसके एपीआई में समय के साथ क्या बदलाव हुए हैं"

अंतर समझें: सही निर्देश Codex को फालतू अनुमान लगाने से बचाते हैं। इससे कोडिंग सही होती है।

💡 संक्षेप में: गलत निर्देश में जानकारी की कमी होती है जिससे Codex को अनुमान लगाना पड़ता है, सही निर्देश में उसे आवश्यक सभी विवरण पहले ही दे दिए जाते हैं।

---

02 प्रॉम्प्ट का "चार-चरणीय" ढांचा: लक्ष्य / कार्य क्षेत्र / सीमाएं / सत्यापन

क्रेडेंशियल्स क्या होनी चाहिए, इसे समझने के लिए एक सरल ढांचा याद रखें—लक्ष्य, कार्य क्षेत्र, सीमाएं, और सत्यापन। इसे कोडिंग चेकलिस्ट की तरह उपयोग करें: इनमें से कोई भी बिंदु छूटने पर Codex अपने अनुसार निर्णय लेगा।

सादृश्य: कारपेंटर को काम सौंपना। एक कुशल कारपेंटर काम शुरू करने से पहले चार बातें पूछेगा—क्या बनाना है (लक्ष्य), किस कमरे में काम करना है (कार्य क्षेत्र), क्या सावधानी रखनी है (सीमाएं), और काम पूरा होने की जांच कैसे होगी (सत्यापन)।

प्रत्येक भाग का विवरण:

तत्व	क्या स्पष्ट करता है	उदाहरण	न होने पर क्या होगा
लक्ष्य (Goal)	क्या काम करना है	"खाली इनपुट होने पर 0 रिटर्न करें"	वह काम का गलत अनुमान लगा सकता है
कार्य क्षेत्र (Scope)	किस फ़ाइल या फ़ंक्शन में काम करना है	"केवल stats.py के average फ़ंक्शन को बदलें"	वह पूरे प्रोजेक्ट में बदलाव कर सकता है
सीमाएं (Constraint)	क्या नहीं करना है, या क्या नियम हैं	"नई लाइब्रेरी इम्पोर्ट न करें", "विंडोज़ कम्पैटिबिलिटी का ध्यान रखें"	वह अपनी पसंद का पैकेज इम्पोर्ट कर सकता है
सत्यापन (Verification)	काम सही होने की पुष्टि कैसे होगी	"pytest चलाकर देखें", "eslint एरर चेक करें"	वह कोड लिखकर बिना जांचे काम समाप्त कर देगा

इनमें से सत्यापन को अक्सर लोग भूल जाते हैं, लेकिन यह बहुत आवश्यक है। दस्तावेज़ों में लिखा है:

Codex तब अधिक सटीक परिणाम देता है जब वह अपने काम की जांच खुद कर सके। निर्देश में एरर चेक करने के कमांड्स, टेस्ट फाइलें और प्रोजेक्ट रूल्स शामिल करें।

यदि आप सत्यापन के नियम नहीं बताएंगे, तो Codex कोड लिखने के बाद काम पूरा मान लेगा, और एरर ढूंढने का काम आपका होगा। लेकिन यदि आप टेस्ट चलाने की कमांड या चेक करने का नियम बता देंगे, तो वह लूप में खुद काम जाँचेगा: कोडिंग करना → टेस्ट रन करना → एरर होने पर कोड सुधारना, जब तक कि टेस्ट पास न हो जाए।

मेरा एक उदाहरण: मैंने एक प्रोजेक्ट में ईमेल सत्यापन फ़ंक्शन लिखवाया, और निर्देश इस प्रकार दिया:

在 src/validators.py 里加一个 validate_email 函数（目标）。
只动这个文件，别碰别的（范围）。
用标准库 re 实现，别引第三方库（约束）。
写完补三个测试：user@example.com 为真、invalid 为假、user@.com 为假，
跑 pytest 确认全过（验证）。

(चीनी प्रॉम्प्ट का अर्थ: "src/validators.py में validate_email फ़ंक्शन जोड़ें (लक्ष्य)। केवल इस फ़ाइल को बदलें (कार्य क्षेत्र)। पाइथन re का उपयोग करें, बाहरी लाइब्रेरी नहीं (सीमा)। तीन टेस्ट जोड़ें और pytest चलाएं (सत्यापन)।")

इस स्पष्ट निर्देश से Codex ने सीधे सही फ़ाइल खोजी, कोड लिखा, टेस्ट बनाए और उन्हें रन करके पुष्टि की। उसे कहीं भी अनुमान लगाने की आवश्यकता नहीं पड़ी क्योंकि नियम पूरी तरह स्पष्ट थे।

💡 संक्षेप में: प्रॉम्प्ट में लक्ष्य, कार्य क्षेत्र, सीमाएं, और सत्यापन चारों बातें स्पष्ट करें; सत्यापन के लिए टेस्ट कमांड अवश्य लिखें ताकि वह खुद कोड चेक कर सके।

---

03 कार्य क्षेत्र और सीमाएं: "दिखाना" बताने से बेहतर है

कार्य क्षेत्र और सीमाओं को विस्तार से समझाने के बजाय सीधे फाइलों या कोड को संदर्भ में देना सबसे अच्छा तरीका है।

नियम: यदि आप कोड या एरर दिखा सकते हैं, तो उसे लिखकर समझाने में समय बर्बाद न करें। Codex सीधे कोड को बेहतर समझ सकता है।

1. फ़ाइल का संदर्भ देना

निर्देश में सीधे फ़ाइल का पाथ लिखें, जैसे:

参考 src/types/user.ts 里的类型定义，给 UserService 补上类型注解

(चीनी प्रॉम्प्ट का अर्थ: "src/types/user.ts के नियमों को देखकर UserService में टाइप एनोटेशन जोड़ें")

यह "यूजर फ़ाइल खोजें" कहने से कहीं बेहतर है। IDE एक्सटेंशन में यह काम और भी आसान है: वह आपके द्वारा खोली गई फाइलों और सिलेक्टेड कोड को खुद संदर्भ में ले लेता है। इसका मतलब है कि आपको पाथ भी लिखने की आवश्यकता नहीं होती, बस कोड सिलेक्ट करके प्रश्न पूछना होता है।

सादृश्य: फ़ाइल अटैच करना। कोड सिलेक्ट करना Codex को सीधे डेटा यूआरएल देने जैसा है, जिससे वह तुरंत काम शुरू कर देता है; जबकि विवरण लिखना उसे फ़ाइल खोजने का काम सौंपना है।

2. एरर लॉग सीधे पेस्ट करना

यदि कोई एरर आ रही है, तो "एरर आ रही है" लिखने के बजाय पूरा एरर लॉग चैट में पेस्ट कर दें:

运行测试时报了这个错，帮我定位原因：
TypeError: Cannot read properties of null (reading 'userId')
    at getUserProfile (src/services/user.ts:42:18)
    at async ProfileController.getProfile (src/controllers/profile.ts:15:20)

(चीनी निर्देश का अर्थ: "टेस्ट रन करने पर यह एरर आ रही है, कारण बताएं")

एरर लॉग में फ़ाइल का नाम, लाइन नंबर और कॉल स्टैक होता है, जिससे Codex सीधे user.ts:42 पर जाकर एरर ठीक कर सकता है।

3. विज़ुअल एरर्स के लिए इमेज का उपयोग

Codex इमेज क्रेडेंशियल्स का समर्थन करता है—आप चैट में इमेज पेस्ट या ड्रैग कर सकते हैं। डिज़ाइन की समस्या होने पर स्क्रीनशॉट अटैच करना सबसे सही तरीका है।

तुलना:

इनपुट	❌ लिखकर बताना	✅ सीधे प्रदान करना
फ़ाइल की जानकारी	"प्रोजेक्ट में ऑथ फ़ाइल है"	सीधे src/auth/session.ts पाथ लिखना
विशिष्ट कोड	"वह फ़ंक्शन जहाँ आईडी चेक होती है"	कोड को सिलेक्ट करना (IDE में स्वतः लोड)
एरर संदेश	"वहाँ अनडिफ़ाइंड की एरर है"	पूरा Stack Trace पेस्ट करना
डिज़ाइन एरर	"बटन थोड़ा बाईं ओर है"	स्क्रीनशॉट अटैच करना

💡 संक्षेप में: कोड सिलेक्ट करना, एरर लॉग पेस्ट करना और इमेज अटैच करना निर्देश को स्पष्ट बनाते हैं; लिखकर समझाने के बजाय सीधे कोड या एरर दिखाएं।

---

04 बड़े कार्यों को विभाजित करना

चार-चरणीय ढांचा एक निर्देश के लिए सही है। लेकिन यदि काम बहुत बड़ा है—जैसे "पूरा ऑथ सिस्टम बनाना"—तो उसे एक साथ करने पर Codex गलती कर सकता है क्योंकि कोड बहुत बड़ा हो जाएगा।

दस्तावेज़ों में स्पष्ट लिखा है:

Codex बड़े और जटिल काम को छोटे-छोटे चरणों में बांटने पर बेहतर परिणाम देता है। छोटे चरणों की जांच करना आपके लिए और टेस्ट करना Codex के लिए आसान होता है। यदि विभाजित करना न आए, तो Codex से योजना (plan) बनाने के लिए कहें।

यह कोडिंग को सुरक्षित रखता है—छोटे बदलावों को रिव्यू करना (diff देखना) आसान होता है, जबकि 10 फाइलों के बड़े बदलावों को समझना कठिन होता है।

सादृश्य: बड़ा काम टुकड़ों में करना।

विभाजन का उदाहरण:

बड़ा काम: ऑथ सिस्टम बनाना

विभाजित चरण:
चरण 1: डेटाबेस स्ट्रक्चर (यूजर टेबल) डिज़ाइन करना, पहले योजना बताना
चरण 2: रजिस्ट्रेशन फ़ंक्शन लिखना, टेस्ट करना
चरण 3: लॉगिन फ़ंक्शन (JWT जनरेट करना) लिखना, टेस्ट करना
चरण 4: टोकन वेरिफिकेशन मिडलवेयर लिखना, टेस्ट करना
चरण 5: लॉगआउट फ़ंक्शन लिखना, टेस्ट करना

यहाँ प्रत्येक चरण में सत्यापन (टेस्ट) शामिल है, और पहले चरण में केवल योजना मांगी गई है ताकि मुख्य स्ट्रक्चर सही बन सके।

विभाजन के लिए दो कंट्रोल्स:

• /plan (योजना मोड): Codex से पहले योजना बनवाना, और आपके अप्रूवल के बाद ही कोडिंग शुरू करना।
• चैट में कहना: निर्देश में लिखना "अभी कोड न बदलें, केवल योजना बताएं"।

कब विभाजित करना चाहिए:

कार्य	व्यवहार
स्पेलिंग ठीक करना, लॉग जोड़ना	सीधे निर्देश दें, योजना की आवश्यकता नहीं है
एक फ़ंक्शन में सुधार, टेस्ट जोड़ना	चार-चरणीय प्रॉम्प्ट दें
कई फाइलों में बदलाव, जटिल लॉजिक	पहले /plan से योजना बनवाएं
नया बड़ा मॉड्यूल या पूरा सिस्टम	छोटे-छोटे चरणों में विभाजित करें, प्रत्येक में टेस्ट रखें

💡 संक्षेप में: बड़े काम को छोटे चरणों में विभाजित करें ताकि हर चरण के बदलावों को रिव्यू करना आसान हो; विभाजन के लिए /plan का उपयोग करें।

---

05 लक्ष्य फिक्स करना: /goal मोड

सामान्य निर्देशों में सत्यापन केवल उसी सत्र में चलता है। यदि आप चाहते हैं कि वह तब तक कोड सुधारता रहे जब तक कि टेस्ट पास न हो जाए, तो लक्ष्य मोड (Goal mode) का उपयोग करें।

दस्तावेज़ों में लिखा है:

लक्ष्य निर्धारित करने पर, वह कोडिंग का मुख्य लक्ष्य बन जाता है। Codex इसके आधार पर यह तय करता है कि आगे क्या करना है और काम कब पूरा माना जाएगा।

वह काम पूरा होने की जांच स्वतः करेगा। यह जटिल और बड़े कार्यों के लिए उपयोगी है।

उपयोग के लिए चैट में /goal टाइप करें और निर्देश दें। नियम यह है कि लक्ष्य ऐसा होना चाहिए जिसकी जांच स्वतः की जा सके—जैसे:

/goal 把这个代码库从 JavaScript 迁到 TypeScript，要求在 strict 模式下编译通过，且不出现显式的 any 类型

(चीनी निर्देश का अर्थ: "प्रोजेक्ट को जेएस से टीएस में माइग्रेट करें, strict मोड में कंपाइल होना चाहिए और any का उपयोग नहीं होना चाहिए")

/goal 把首页的可交互时间（TTI）降到 1 秒以内

(चीनी निर्देश का अर्थ: "होमपेज का TTI 1 सेकंड से कम करें")

ये ऐसे लक्ष्य हैं जिनकी कोडिंग के बाद स्पष्ट जांच की जा सकती है। "कोड अच्छा करें" जैसे अस्पष्ट लक्ष्यों के लिए इसका उपयोग नहीं किया जा सकता।

कुछ महत्वपूर्ण बातें:

• /goal कमांड चालू करना: config.toml में [features] के तहत goals = true सेट करें या codex features enable goals चलाएं।

# ~/.codex/config.toml
[features]
goals = true

(कोड ब्लॉक को मूल रूप में रहने दें)

• योजना से लक्ष्य बनाना: यदि लक्ष्य समझ न आ रहा हो, तो पहले /plan से योजना बनवाएं और फिर उसे लक्ष्य पर सेट करें।
• चैट के दौरान सुधार: काम चलने के दौरान भी आप चैट में बदलाव (जैसे "इस लाइब्रेरी का उपयोग करें") कह सकते हैं।

तुलना:

विशेषता	सामान्य निर्देश	/goal लक्ष्य मोड
अवधि	एक चक्र में काम पूरा	काम पूरा होने (टेस्ट पास होने) तक चलता रहेगा
उपयुक्तता	छोटे कोडिंग कार्य	जटिल और बड़े कार्य
सत्यापन	आप खुद चेक करते हैं	वह खुद चेक करके सुधार करता है
सेटिंग्स	सीधे प्रॉम्प्ट	features.goals = true होना आवश्यक

💡 संक्षेप में: काम को ऑटो-चेक पर लगाने के लिए /goal मोड का उपयोग करें—लक्ष्य स्पष्ट और जांचने योग्य होना चाहिए; इसे सक्षम करने के लिए कॉन्फ़िगरेशन में goals = true होना चाहिए।

---

06 व्यावहारिक अभ्यास: दो अलग-अलग प्रॉम्प्ट्स की तुलना

अब हम एक व्यावहारिक तुलना करेंगे।

अभ्यास के लिए खाली फोल्डर बनाएं और टर्मिनल खोलें।

पहला कदम: टेस्ट फ़ाइल बनाना (Mac / Linux)

mkdir prompt-demo
cd prompt-demo
echo 'def average(nums):
    return sum(nums) / len(nums)' > stats.py

(विंडोज़ में फ़ाइल को नोटपैड से बनाएं)

इस कोड में एरर है: यदि इनपुट में खाली लिस्ट [] दी जाए, तो len 0 होने के कारण 'डिवाइड बाय जीरो' एरर आएगी।

दूसरा कदम: फोल्डर में Codex शुरू करना

codex

तीसरा कदम: गलत निर्देश (प्रॉम्प्ट) देकर देखना

चैट में लिखें:

@stats.py 帮我改改这个函数

(चीनी निर्देश का अर्थ: "stats.py के इस फ़ंक्शन को बदलें")

अपेक्षित परिणाम: Codex अनुमान लगाएगा कि आप क्या चाहते हैं—हो सकता है वह केवल कमेंट्स जोड़ दे, लेकिन उसे पता नहीं चलेगा कि आप खाली लिस्ट की एरर को ठीक करना चाहते हैं।

चौथा चरण: सही निर्देश (चार-चरणीय प्रॉम्प्ट) देना

चैट में लिखें:

@stats.py 里的 average 函数有个 bug：传入空列表时会因为除以零而崩溃。
期望行为是空列表返回 0（目标）。
只改这个函数，别动别的（范围）；用纯 Python 实现，别引库（约束）。
帮我修，并补一个测试：average([]) 应返回 0、average([2, 4]) 应返回 3，
跑 pytest 确认全过（验证）。

(चीनी निर्देश को ही रहने दें)

अपेक्षित परिणाम: Codex सीधे फ़ंक्शन में खाली लिस्ट की जांच जोड़ेगा, दो टेस्ट लिखेगा, टेस्ट रन करेगा और रिपोर्ट दिखाएगा। उसे कहीं भी अनुमान लगाने की आवश्यकता नहीं होगी।

पांचवां चरण: फ़ाइल की जांच करना

Codex से बाहर आएं और फ़ाइल देखें:

cat stats.py

अपेक्षित परिणाम: फ़ाइल में if not nums: return 0 जैसी एरर हैंडलिंग जुड़ी मिलेगी।

तुलना तालिका:

विशेषता	गलत निर्देश	सही निर्देश
लक्ष्य	स्पष्ट नहीं था	खाली लिस्ट पर 0 रिटर्न
कार्य क्षेत्र	फ़ाइल बताई थी, फ़ंक्शन नहीं	average फ़ंक्शन स्पष्ट
सीमा	नहीं थी	पाइथन इनबिल्ट, लाइब्रेरी नहीं
सत्यापन	नहीं था	टेस्ट क्रेडेंशियल्स और रन कमांड
परिणाम	फालतू बदलाव	सटीक सुधार

💡 संक्षेप में: इस अभ्यास से स्पष्ट होता है कि प्रॉम्प्ट में चारों बातें (लक्ष्य, कार्य क्षेत्र, सीमाएं, सत्यापन) लिखना सटीक कोडिंग के लिए कितना आवश्यक है।

---

07 कोडिंग निर्देश प्रवाह

पूरे प्रॉम्प्टिंग प्रोसेस का आरेख नीचे दिया गया है:

(आरेख की कोडिंग को मूल रूप में रहने दें)

यह दिखाता है कि बड़े काम के लिए /plan और कोडिंग के लिए चार-चरणीय प्रॉम्प्ट का उपयोग करके टेस्ट रन क्रेडेंशियल्स के साथ काम को पूरा किया जाता है।

---

08 सारांश

इस लेख में हमने प्रॉम्प्ट लिखने की कला को समझा:

नियम	विवरण	उदाहरण
चार-चरणीय प्रॉम्प्ट	लक्ष्य, कार्य क्षेत्र, सीमाएं, सत्यापन स्पष्ट करना	"average फ़ंक्शन में (कार्य क्षेत्र) खाली लिस्ट पर 0 रिटर्न करें (लक्ष्य), लाइब्रेरी न जोड़ें (सीमा), टेस्ट रन करें (सत्यापन)"
सीधे प्रदान करना	लिखकर समझाने के बजाय कोड/एरर दिखाना	फ़ाइल पाथ लिखना, कोड सिलेक्ट करना, पूरा एरर लॉग पेस्ट करना
विभाजन	बड़े काम को छोटे चरणों में बांटना	बड़े फीचर के लिए पहले /plan से योजना बनवाना
लक्ष्य मोड	ऑटो-चेक पर कोडिंग	/goal के साथ कस्टमाइज्ड लक्ष्य सेट करना

कोडिंग नियमों को स्थायी बनाने के लिए उन्हें AGENTS.md में लिखें।

अगले लेख 14 · कोडिंग प्रक्रियाएं में हम दैनिक कोडिंग के विभिन्न परिदृश्यों (बग ढूंढना, रिफैक्टर करना, टेस्ट लिखना) पर विस्तार से बात करेंगे।

---

अनुशंसित पठन

• पहला कार्य पूरा करना
• कमांड लाइन CLI का उपयोग
• टीम और एंटरप्राइज लेवल पर कोडिंग सुरक्षा