सर्वश्रेष्ठ अभ्यास: केवल 'घिसे-पिटे उपदेशों' से हटकर, वास्तव में काम आने वाले कुछ नियम
📚 सीरीज़ नेविगेशन: पिछला लेख 35 कमांड और कॉन्फ़िगरेशन चीट शीट कमांड, कॉन्फ़िगरेशन कुंजियों और शॉर्टकट को एक चीट शीट में संकलित करता है जिसे आप दीवार पर चिपका सकते हैं। यह लेख एक अलग स्तर पर बात करेगा — यह "क्या फ़ीचर हैं" के बजाय यह बताएगा कि "इन फ़ीचर्स को एक साथ कैसे उपयोग किया जाए ताकि Codex वास्तव में आपका काम आसान बना सके"। अगला लेख 37 सामान्य समस्याओं का निवारण "समस्या आने पर क्या करें" के बारे में बताएगा।
सच कहूँ तो, जब मुझे पहली बार Codex मिला, तो मैंने एक बेवकूफी भरा काम किया: मैंने शुरू से अंत तक आधिकारिक best-practices पेज को पढ़ा, मुझे लगा कि हर बात सही है, और फिर... पेज बंद कर दिया, लेकिन अपने काम करने के तरीके में कोई बदलाव नहीं किया।
समस्या मुझमें नहीं थी — बल्कि अधिकांश तथाकथित सर्वश्रेष्ठ अभ्यासों में थी जो केवल घिसे-पिटे उपदेश होते हैं: "प्रॉम्प्ट स्पष्ट लिखें," "टेस्ट करना याद रखें," "छोटे-छोटे बदलाव करें" — सुनने में सब सही लगते हैं, लेकिन कोई यह नहीं बताता कि कितना स्पष्ट होना चाहिए, क्या टेस्ट करना है, और बदलाव कितने छोटे होने चाहिए। आप सहमति में सिर हिलाते हैं, लेकिन वापस जाकर उसी तरह काम करने लगते हैं। इस प्रकार की सामान्य सलाह वास्तव में ज़िम्मेदारी वापस आप पर डाल देती है।
इसलिए, इस लेख में मैं उन बड़ी-बड़ी बातों को दोहराने नहीं जा रहा हूँ जो कोई भी कह सकता है। मैंने आधिकारिक best-practices दस्तावेज़ों को गहराई से पढ़ा है और उनमें से उन नियमों को चुना है जिन्होंने वास्तव में मेरे काम करने के तरीके को बदला और जिन्हें मैंने खुद सत्यापित किया है। प्रत्येक नियम के साथ मैं आपको बताऊंगा कि "ऐसा क्यों करना है + वास्तव में इसे कैसे करें + ऐसा न करने पर क्या समस्याएं आएंगी।" हम केवल काम आने वाले नियमों को ही रखेंगे, और बड़ी-बड़ी दिखने वाली लेकिन बेकार बातों को हटा देंगे।
ईमानदारी से कहूँ तो, नीचे दिए गए अधिकांश नियमों को मैंने तब अपनाया जब मैंने पहले गलतियाँ कीं और नुकसान उठाया।
इस लेख को पूरा पढ़ने के बाद, आपको मिलेगा:
- Codex को एक "एकल उपकरण" के बजाय एक "टीम साथी" की तरह कॉन्फ़िगर करने की सोच
AGENTS.md(प्रोजेक्ट निर्देश) में वास्तव में क्या लिखना है और यह कितना लंबा होना चाहिए- एक पूर्ण चार-सूत्रीय प्रॉम्प्ट संरचना: "लक्ष्य + संदर्भ + बाधाएं + स्वीकृति," जिसे आप सीधे उपयोग कर सकते हैं
- अनुमतियों को परिदृश्यों के अनुसार कैसे विभाजित किया जाए, और शुरुआत कहाँ से करें
- जटिल कार्यों के लिए काम शुरू करने से पहले योजना बनाना क्यों आवश्यक है
- Codex को स्वयं जांच और परीक्षण करने की अनुमति देना, न कि आपको हर कदम पर नज़र रखनी पड़े
- ऑनलाइन (उत्पादन/production) समस्याओं के लिए पहले सबूत जुटाना, लॉग सुरक्षित करना और फिर सुधार करना
- "क्या न करें ❌ / सही तरीका क्या है ✅" की एक मिलान तालिका, जिसे आप सीधे अपना सकते हैं
⚠️ कमांड, कॉन्फ़िगरेशन कुंजियाँ और डिफ़ॉल्ट व्यवहार Codex के आधिकारिक दस्तावेज़ पर आधारित हैं; मॉडल के नाम और उपलब्धता आपके संस्करण और पैकेज के अनुसार बदल सकते हैं, हमेशा अपने स्थानीय
codex --help,/modelपैनल और~/.codex/config.tomlके वास्तविक व्यवहार को आधार मानें।
01 अपना नज़रिया बदलें: Codex आपका सिखाया जाने वाला साथी है, कोई साधारण टूल नहीं
पहले निष्कर्ष पर आते हैं: Codex का परिणाम इस बात पर निर्भर करता है कि आप उसे क्या मानते हैं।
बहुत से लोग (मेरे शुरुआती दिनों सहित) इसे एक सर्च बॉक्स की तरह उपयोग करते हैं जहां "एक सवाल पूछो और एक जवाब पाओ": समस्या भेजी, जवाब मिला और चले गए, और अगली बार फिर शून्य से शुरुआत की। इस तरह से उपयोग करने पर यह अपनी क्षमता का केवल 30% ही दे पाता है।
सादृश्य: Codex आपकी टीम में शामिल नए कर्मचारी की तरह है जो बहुत कुशल है लेकिन आपके प्रोजेक्ट के बारे में कुछ नहीं जानता। आप यह उम्मीद नहीं करेंगे कि वह पहले ही दिन सब कुछ जान जाएगा — आपको उसे एक इंडक्शन मैनुअल (AGENTS.md) देना होगा, बताना होगा कि कोड कैसे चलाना और टेस्ट करना है, और गलती होने पर उसे सुधारना होगा ताकि वह याद रख सके। आप उसे जितना अधिक सिखाएंगे, वह उतना ही बेहतर काम करेगा। इसके विपरीत, यदि आप हर बार एक नए कर्मचारी से काम कराएंगे, तो आपको हर बार शुरुआत से सब कुछ समझाना होगा।
आधिकारिक दस्तावेज़ों में एक बात मुझे बहुत पसंद आई, जिसका सार यह था: Codex को एक बार उपयोग होने वाले सहायक के रूप में देखने के बजाय, उसे एक ऐसे साथी के रूप में देखें जिसे आप लगातार कॉन्फ़िगर करेंगे और बेहतर बनाएंगे। इस लेख के बाद के सभी अभ्यास इसी विचार के इर्द-गिर्द घूमते हैं — अस्थायी और बार-बार होने वाले काम को स्थायी कॉन्फ़िगरेशन में बदलना।
मेरे लिए बदलाव का समय 2026 की शुरुआत में आया। उससे पहले, हर बार एक नया सत्र शुरू करते समय मुझे ये बातें बार-बार टाइप करनी पड़ती थीं: "इस प्रोजेक्ट में pnpm का उपयोग करें, npm का नहीं," "टेस्ट चलाने के लिए pnpm test का उपयोग करें," "कमिट संदेश हिंदी में होना चाहिए।" दिन में सात-आठ बार ऐसा करना पड़ता था। फिर एक दिन मैंने इन सभी को AGENTS.md में डाल दिया, और मेरी परेशानी समाप्त हो गई — तब मुझे एहसास हुआ कि मैं इतने स्मार्ट टूल का उपयोग बहुत गलत तरीके से कर रहा था।
💡 संक्षेप में: Codex को एक दीर्घकालिक टीम साथी मानना, न कि एक बार का टूल, सभी सर्वश्रेष्ठ अभ्यासों का आधार है।
02 AGENTS.md को सही ढंग से लिखें: उसे स्वचालित रूप से "प्रोजेक्ट संदर्भ" के साथ काम करने दें
ऐसा क्यों करना है। पिछले अनुभाग की समस्या का समाधान यही है। AGENTS.md आपके प्रोजेक्ट में रखी गई एक निर्देश फ़ाइल है, जिसे Codex सत्र शुरू करते समय स्वचालित रूप से पढ़ता है, आपको इसे बार-बार बताने की आवश्यकता नहीं होती। प्रोजेक्ट में जो नियम बार-बार लागू होते हैं, उन्हें एक बार लिखें और वे हमेशा के लिए काम करेंगे।
सादृश्य: AGENTS.md AI के लिए बनाया गया README है। सामान्य README मनुष्यों के लिए लिखा जाता है, जो बताता है कि प्रोजेक्ट क्या है और इसे कैसे चलाना है; AGENTS.md Codex के लिए लिखा जाता है, जो उसे आपके प्रोजेक्ट के नियम, निषिद्ध क्षेत्र (no-go zones) और काम पूरा होने के मानक बताता है।
कैसे करें। आधिकारिक तौर पर एक अच्छे AGENTS.md में ये भाग शामिल होने चाहिए:
- प्रोजेक्ट की संरचना और महत्वपूर्ण निर्देशिकाओं के स्थान
- प्रोजेक्ट को चलाने का तरीका
- बिल्ड, टेस्ट और लिनटर (lint) चलाने के कमांड
- प्रोजेक्ट के नियम और PR (Pull Request) की आवश्यकताएं
- बाधाएं और "क्या बिल्कुल नहीं करना है" की सीमाएं
- काम पूरा होने का पैमाना और सत्यापन का तरीका
शुरू करने का सबसे तेज़ तरीका CLI में /init चलाना है, जो वर्तमान फ़ोल्डर में एक बुनियादी AGENTS.md फ़ाइल बना देगा। लेकिन इसे सीधे उपयोग न करें — यह केवल एक टेम्पलेट है, आपको इसे अपने वास्तविक प्रोजेक्ट के अनुसार बदलना होगा।
AGENTS.md को विभिन्न स्तरों पर रखा जा सकता है: ~/.codex/ में रखा गया आपके व्यक्तिगत डिफ़ॉल्ट नियमों के लिए है; प्रोजेक्ट रूट में रखा गया टीम के साझा नियमों के लिए है; और उप-निर्देशिकाओं में रखा गया स्थानीय नियमों के लिए है। जो नियम वर्तमान फ़ोल्डर के सबसे पास होगा, वह सबसे पहले प्रभावी होगा।
गलत उदाहरण (जो मैंने किया था)। मैं शुरू में इसके विपरीत करता था: मैं "इस बार डेटाबेस को मत छुओ," "इस बार केवल इसी फ़ाइल को बदलो" जैसे अस्थायी निर्देशों को AGENTS.md में लिख देता था। परिणाम यह हुआ कि फ़ाइल बहुत लंबी हो गई और उसमें पुराने नियम भर गए, जिससे Codex भ्रमित होने लगा। बाद में मैंने सीखा:
अस्थायी आवश्यकताओं को प्रॉम्प्ट में लिखें, और दीर्घकालिक नियमों को
AGENTS.mdमें। छोटा और सटीक होना, बड़े और अस्पष्ट होने से बेहतर है।
आधिकारिक रूप से एक और अच्छी आदत बताई गई है जिसे अपनाया जा सकता है: जब Codex एक ही गलती दूसरी बार करे, तो उसे इसका विश्लेषण करने दें और उस सबक को AGENTS.md में जोड़ दें। इस तरह आपका निर्देश मैनुअल वास्तविक अनुभवों से समृद्ध होगा, न कि केवल आपके विचारों से।
💡 संक्षेप में: दीर्घकालिक नियमों को
AGENTS.mdमें रखें, जो छोटा, सटीक और वास्तविक होना चाहिए, न कि केवल हवा-हवाई बातें।
03 प्रॉम्प्ट केवल अपने विचारों पर आधारित न रखें: चार-सूत्रीय ढांचा अपनाएं
ऐसा क्यों करना है। पिछले लेख में प्रॉम्प्ट पर बात की गई थी, यहाँ एक सीधा ढांचा दिया जा रहा है। Codex अब बहुत शक्तिशाली है, आप प्रॉम्प्ट को साधारण लिखेंगे तो भी वह परिणाम दे देगा; लेकिन बड़े प्रोजेक्ट्स और महत्वपूर्ण कामों में यदि प्रॉम्प्ट अस्पष्ट होगा, तो उसे अंदाज़ा लगाना होगा और गलती होने पर आपको काम दोबारा करना होगा।
आधिकारिक रूप से सुझाया गया "बेहतरीन प्रॉम्प्ट फॉर्मूला" चार भागों में बंटा है, जिसे मैं एक फ़ॉर्म की तरह भरता हूँ:
| तत्व | इसका उत्तर क्या है | न भरने पर क्या होगा |
|---|---|---|
| लक्ष्य (Goal) | आप वास्तव में क्या बदलना या बनाना चाहते हैं | वह मुख्य बिंदु को छोड़ देगा और अनावश्यक काम कर देगा |
| संदर्भ (Context) | कौन सी फ़ाइलें, त्रुटियां (errors) या उदाहरण प्रासंगिक हैं (आप फ़ाइलों को @ से टैग कर सकते हैं) | वह गलत फ़ाइलों में खोजेगा और समय बर्बाद करेगा |
| बाधाएं (Constraints) | किन नियमों, संरचनाओं या सुरक्षा मानकों का पालन करना है | वह अपने तरीके से काम करेगा और कोडिंग शैली प्रभावित होगी |
| स्वीकृति (Done when) | काम पूरा होने की शर्तें क्या हैं | उसे लगेगा कि काम "चल रहा है" और वह बग्स आपके लिए छोड़ देगा |
कैसे करें। आपको हर प्रॉम्प्ट को किसी अनुबंध (contract) की तरह लिखने की आवश्यकता नहीं है। लेकिन जो काम थोड़ा भी जटिल हो या जिसमें आप गलती नहीं चाहते, काम सौंपने से पहले इन चारों बिंदुओं पर विचार कर लें: मुझे उससे क्या कराना है, प्रासंगिक फ़ाइलें कहाँ हैं, किसे नहीं छूना है, और काम पूरा कब माना जाएगा।
सादृश्य: यह किसी काम को शुरू करने से पहले निर्देश देने जैसा है। आप किसी से केवल यह नहीं कहेंगे कि "किचन को सुंदर बना दो" — आपको स्पष्ट करना होगा कि क्या डिज़ाइन चाहिए (लक्ष्य), नक्शा और पाइपलाइन कहाँ हैं (संदर्भ), मुख्य दीवारों को नहीं छूना है (बाधाएं), और काम पूरा होने पर लाइट, पानी और अलमारियां सही काम करनी चाहिए (स्वीकृति)। निर्देश जितना स्पष्ट होगा, काम उतना ही सही होगा।
मैं अक्सर स्वीकृति वाले भाग को भूल जाता था। शुरू में जब मैंने Codex से एक फॉर्म सत्यापन बदलने को कहा, तो मैंने केवल यह कहा कि "फ़ोन नंबर प्रारूप सत्यापन जोड़ें," यह नहीं बताया कि "ईमेल सत्यापन भी काम करना चाहिए और सभी टेस्ट पास होने चाहिए।" उसने फ़ोन नंबर सत्यापन तो जोड़ दिया, लेकिन ईमेल सत्यापन का कोड हटा दिया, जिसका पता मुझे काम पूरा होने के बाद टेस्ट चलाते समय चला। तब से, मैं "स्वीकृति" (Done when) को हमेशा स्पष्ट लिखता हूँ।
💡 संक्षेप में: प्रॉम्प्ट को मनमर्जी से न लिखें, बल्कि "लक्ष्य + संदर्भ + बाधाएं + स्वीकृति" के ढांचे में लिखें, और स्वीकृति को कभी न छोड़ें।
04 जटिल कार्यों के लिए पहले योजना बनाएं, फिर काम शुरू करें
ऐसा क्यों करना है। यदि कार्य जटिल या अस्पष्ट है और आप उसे सीधे कोड लिखने को कहेंगे, तो वह अंदाज़ा लगाता रहेगा और कोड लिखता जाएगा, जिससे गलत दिशा में जाने का खतरा बढ़ जाता है। काम से पहले योजना बनाने से आपको शुरुआत में ही सुधार करने का एक आसान मौका मिलता है।
सादृश्य: यह घर बनाने से पहले नक्शा देखने जैसा है। कोई भी बिल्डर बिना नक्शे के दीवारें खड़ी नहीं करता — गलत होने पर उसे तोड़ना बहुत कठिन होता है। योजना वही नक्शा है, जो कुछ लाइनों में होता है और कोड को दोबारा लिखने से बहुत सस्ता पड़ता है।
कैसे करें। आधिकारिक तौर पर कई तरीके दिए गए हैं:
- योजना मोड (Plan Mode) का उपयोग करें (अनुशंसित): CLI में
/planचलाएं, या स्विच करने के लिए Shift+Tab दबाएं। वह पहले संदर्भ एकत्र करेगा, प्रश्न पूछेगा, और एक योजना देगा। आपके सहमत होने के बाद ही वह काम शुरू करेगा। - उसे आपसे प्रश्न पूछने दें: यदि आप स्वयं भी स्पष्ट नहीं हैं, तो उससे कहें कि "पहले कोड मत लिखो, मुझसे प्रश्न पूछो और इस विचार को एक ठोस योजना में बदलो।"
PLANS.mdटेम्पलेट का उपयोग करें: बड़े और लंबे समय तक चलने वाले कार्यों के लिए एक योजना टेम्पलेट का उपयोग करें (आधिकारिक दिशा-निर्देशों के अनुसार)।
गलत उदाहरण। आधिकारिक तौर पर "जटिल कार्यों के लिए योजना न बनाना" एक बड़ी गलती माना गया है, और मेरा भी यही अनुभव है। पिछले साल मैंने Codex से एक मॉड्यूल को async/await में बदलने को कहा और योजना बनाने के बजाय सीधे काम शुरू कर दिया। उसने बदलाव तो किए लेकिन साथ ही एक महत्वपूर्ण वैश्विक त्रुटि हैंडलिंग (error handling) को भी बदल दिया, जिससे पूरा कोड खराब हो गया। मुझे git reset करके दोबारा शुरू करना पड़ा — इस बार मैंने पहले /plan का उपयोग किया, जिससे स्पष्ट हुआ कि कौन सी फ़ाइलें बदलनी हैं और किसे नहीं छूना है। इसके बाद काम सही तरीके से पूरा हुआ।
💡 संक्षेप में: कार्य जितना जटिल और अस्पष्ट हो, पहले
/planचलाकर योजना बनाएं और पुष्टि के बाद ही काम शुरू करें।
05 अनुमतियों का विभाजन: शुरुआत में नियम सख्त रखें, धीरे-धीरे ढील दें
ऐसा क्यों करना है。 Codex का अपना सैंडबॉक्स होता है, जिसमें दो मुख्य सेटिंग्स होती हैं: अनुमति नीति (approval policy) तय करती है कि वह कोई कमांड चलाने से पहले आपसे पूछे या नहीं, और सैंडबॉक्स स्तर (sandbox mode) तय करता है कि वह किन फ़ाइलों और निर्देशिकाओं में बदलाव कर सकता है। शुरुआत में ही उसे सारे अधिकार दे देना किसी नए ड्राइवर को बिना जांचे गाड़ी सौंपने जैसा है।
सादृश्य: यह नए इंटर्न को सिस्टम के अधिकार देने जैसा है। पहले दिन आप उसे केवल कोड पढ़ने और स्थानीय स्तर पर टेस्ट चलाने की अनुमति देते हैं; जब आप उस पर विश्वास करने लगते हैं, तो उसे फ़ाइलें बदलने और डेटाबेस से जुड़ने का अधिकार देते हैं। कोई भी पहले दिन ही मुख्य चाबियां नए कर्मचारी को नहीं सौंपता।
कैसे करें। आधिकारिक सलाह बहुत स्पष्ट है:
- नए उपयोगकर्ताओं को डिफ़ॉल्ट सेटिंग्स के साथ शुरुआत करनी चाहिए, जहां अनुमति और सैंडबॉक्स नियम सख्त होते हैं।
- जब आप काम करने के तरीके को समझ जाएं और आपको सहजता की आवश्यकता हो, तभी किसी विशिष्ट प्रोजेक्ट या परिदृश्य के लिए नियमों को ढीला करें, न कि एक बार में ही सब कुछ खोल दें।
| परिदृश्य | अनुशंसित स्तर | कारण |
|---|---|---|
| नया उपयोगकर्ता / अपरिचित प्रोजेक्ट | डिफ़ॉल्ट (पूछना आवश्यक, सख्त सैंडबॉक्स) | सुरक्षा के लिए पहले देखें कि वह क्या करना चाहता है |
| आपका विश्वसनीय प्रोजेक्ट, बार-बार होने वाले काम | अनुमति नीति में ढील दें | बार-बार 'सहमत' होने के बटन दबाने की परेशानी से बचें |
| अपरिचित स्क्रिप्ट / थर्ड-पार्टी कोड | सबसे सख्त स्तर | यह सुनिश्चित करने के लिए कि वह कोई अनपेक्षित कमांड न चलाए |
आधिकारिक तौर पर "काम को समझे बिना Codex को सिस्टम के पूर्ण अधिकार देना" एक आम गलती माना गया है। मेरा अपना अनुभव भी यही कहता है: एक बार मैंने बार-बार पूछने की प्रक्रिया से बचने के लिए अनुमति नीति को बहुत ढीला कर दिया था, और उसने एक कोड रिफैक्टरिंग के दौरान कुछ ऐसी अस्थायी फ़ाइलों को हटा दिया जिन्हें मैं रखना चाहता था — यह कोई बड़ी आपदा नहीं थी, लेकिन इसने मुझे सतर्क कर दिया। पुष्टि करने में लगने वाले कुछ सेकंड बचाना, जोखिम लेने से बेहतर है।
💡 संक्षेप में: शुरुआत में अनुमतियां सख्त रखें, देखकर ही अनुमति दें; केवल विश्वसनीय परिदृश्यों में ही ढील दें, एक बार में सब कुछ न खोलें।
06 उसे स्वयं सत्यापित करने दें: टेस्ट, जांच और समीक्षा उसे ही करने दें
ऐसा क्यों करना है। यह सबसे महत्वपूर्ण नियमों में से एक है। Codex को केवल कोड लिखने पर मत रोकें — उससे कहें कि वह टेस्ट लिखे, संबंधित जांच चलाए, और बदलावों की समीक्षा (review) करने के बाद ही आपको काम सौंपे। यदि आप ऐसा करते हैं, तो आपका बार-बार खुद टेस्ट करने और त्रुटियां होने पर उसे सुधारने का समय बच जाएगा।
लेकिन एक शर्त है: उसे पता होना चाहिए कि "सही काम" क्या है। यह मानक कहाँ से आएगा? या तो प्रॉम्प्ट से या AGENTS.md से (जो हमने सेक्शन 02 में देखा था)।
कैसे करें। आधिकारिक तौर पर स्वयं सत्यापन के लिए ये कदम सुझाए गए हैं, जिन्हें आप प्रॉम्प्ट में शामिल कर सकते हैं:
- इस बदलाव के लिए टेस्ट लिखना या उन्हें अपडेट करना
- संबंधित परीक्षणों (test suites) को चलाना
- लिनटर (lint), फॉर्मेटिंग और टाइप जांच चलाना
- यह पुष्टि करना कि अंतिम परिणाम आपकी आवश्यकताओं के अनुरूप है
- बदलावों (diff) की समीक्षा करना ताकि बग्स या जोखिमों का पता चल सके
CLI में /review कमांड बहुत उपयोगी है: यह PR (Pull Request) की शैली में बदलावों की तुलना कर सकता है, बिना कमिट किए गए बदलावों की जांच कर सकता है, या आपके विशिष्ट निर्देशों के अनुसार समीक्षा कर सकता है। यदि आपकी टीम की कोई code_review.md फ़ाइल है और वह AGENTS.md में निर्दिष्ट है, तो Codex उसी के अनुसार समीक्षा करेगा — इससे टीम के सभी सदस्यों के लिए समीक्षा का मानक एक समान रहता है।
गलत उदाहरण। आधिकारिक तौर पर "एजेंट को उसके काम का परिणाम न देखने देना" (यानी उसे बिल्ड और टेस्ट कमांड न बताना) एक आम गलती माना गया है। मेरा भी ऐसा एक अनुभव रहा है: मैंने उससे एक डेटा फ़ंक्शन बदलने को कहा और टेस्ट चलाने को नहीं कहा, उसने कहा "काम पूरा हो गया और कोड सही है," और मैंने मान लिया। लेकिन बाद में पता चला कि वह कोड कुछ विशिष्ट इनपुट्स पर क्रैश हो रहा था — उसे इसका पता नहीं चला क्योंकि उसने टेस्ट नहीं चलाए थे। अब मेरी आदत है: जब भी कोड में बदलाव हो, मैं प्रॉम्प्ट के अंत में लिखता हूँ "बदलाव के बाद <测试命令> चलाएं, और सभी टेस्ट पास होने पर ही मुझे बताएं।" यह एक लाइन आपका बहुत सा समय बचा सकती है।
💡 संक्षेप में: Codex को टेस्ट, जांच और समीक्षा करने दें, लेकिन इसके लिए उसे प्रॉम्प्ट या
AGENTS.mdके माध्यम से सही मानक बताएं।
07 ऑनलाइन समस्याओं के लिए पहले सबूत जुटाएं, फिर सुधार करें
ऐसा क्यों करना है। स्थानीय विकास को तो टेस्ट चलाकर सत्यापित किया जा सकता है। लेकिन ऑनलाइन समस्याओं में हमें कई कठिन प्रश्नों के उत्तर देने होते हैं: उपयोगकर्ता को क्या समस्या आ रही है, आप इसे कैसे दोहराएंगे, कौन सा लॉग इस अनुरोध से संबंधित है, और सुधार के बाद क्या इसे उसी उपयोगकर्ता पथ पर सत्यापित किया गया है।
अब मैं इसे प्रोजेक्ट के नियमों में शामिल करता हूँ: ऑनलाइन समस्याओं के लिए पहले सबूत जुटाएं, फिर स्थिति का आकलन करें, और फिर सुधार करें। Codex कोड में समस्या खोज सकता है, लेकिन यदि आप सीधे कहेंगे "इसे ठीक करें," तो वह सबसे संभावित कारण को ही वास्तविक कारण मान लेगा और केवल स्थानीय टेस्ट पास होने पर उसे ठीक मान लेगा। ऑनलाइन समस्याओं के लिए यह पर्याप्त नहीं है।
कैसे करें। पहले उससे कहें कि वह कोड न बदले, केवल सबूत एकत्र करे। प्रॉम्प्ट को इस प्रकार लिखा जा सकता है:
अभी कोड में कोई बदलाव न करें। कृपया सबूतों के आधार पर इस ऑनलाइन समस्या की जांच करें:
1. उपयोगकर्ता के पथ को दोहराएं, अनुरोध विधि, स्टेटस कोड, प्रतिक्रिया का सारांश और समय दर्ज करें।
2. उस समय के एप्लिकेशन लॉग देखें और केवल प्रासंगिक त्रुटियों को निकालें।
3. संबंधित कॉन्फ़िगरेशन, राउट्स, टास्क या डेटा टेबल खोजें, लेकिन उत्पादन (production) स्थिति में कोई बदलाव न करें।
4. "सत्यापित तथ्य / संभावित कारण / अगले चरण" के रूप में निष्कर्ष दें।
5. आउटपुट में संवेदनशील जानकारी जैसे टोकन (token), निजी लिंक, ईमेल, फ़ोन नंबर, ऑर्डर नंबर और आंतरिक पते छुपाएं (mask)।यह निर्देश Codex को सीधे सुधार करने के बजाय पहले सबूत जुटाने पर केंद्रित करता है। उसका निष्कर्ष सबूतों पर आधारित होना चाहिए: कौन सा अनुरोध फेल हुआ, लॉग में क्या त्रुटि थी, और कौन सा कॉन्फ़िगरेशन प्रभावित था।
मैं ऐसी समस्याओं के लिए AGENTS.md में एक नियम जोड़ देता हूँ:
## 线上问题处理 (ऑनलाइन समस्या निवारण)
- पहले समस्या को दोहराएं, स्टेटस कोड, प्रतिक्रिया सारांश, लॉग का समय और सत्यापन पाथ दर्ज करें।
- पुष्टि के बिना, उत्पादन (production) डेटा, अनुमतियां, दृश्यता, बिलिंग या टिकट स्थिति में कोई बदलाव न करें।
- आउटपुट में संवेदनशील जानकारी छुपाएं; टोकन, उपयोगकर्ता जानकारी, निजी लिंक, कुंजियाँ, आईपी या ऑर्डर नंबर न दिखाएं।
- सुधार के बाद मूल उपयोगकर्ता पाथ पर ही सत्यापन करें; स्थानीय टेस्ट पास होने का मतलब यह नहीं है कि ऑनलाइन समस्या हल हो गई है।
- यदि सत्यापन संभव न हो, तो बताएं कि कौन सा सबूत गायब है और उसे कौन पूरा कर सकता है।ये नियम Codex के लिए बहुत महत्वपूर्ण हैं। जब वह पढ़ेगा कि "सुधार के बाद मूल उपयोगकर्ता पाथ पर ही सत्यापन करें," तो वह केवल यूनिट टेस्ट चलाकर काम पूरा नहीं मानेगा; और जब वह पढ़ेगा कि "पुष्टि के बिना उत्पादन डेटा न बदलें," तो वह संवेदनशील कार्यों से पहले रुककर आपसे पूछेगा।
संवेदनशील जानकारी छुपाते समय काम की जानकारी न हटाएं। यदि आप सब कुछ हटा देंगे, तो समस्या की जांच करना कठिन हो जाएगा। संरचना को बनाए रखें और केवल संवेदनशील मानों को छुपाएं:
| मूल जानकारी | छुपाने के बाद का प्रारूप |
|---|---|
https://example.com/private/path?token=secret_value | https://example.com/private/path?token=<token> |
user@example.com | <user-email> |
order_20260201_123456 | <order-id> |
Authorization: Bearer ... | Authorization: Bearer <redacted> |
2026-02-01 14:03:22 status=500 | मूल समय और स्टेटस कोड बनाए रखें |
समय, स्टेटस कोड, त्रुटि का प्रकार और राउट की संरचना को बनाए रखा जाना चाहिए; केवल उपयोगकर्ता की पहचान, क्रेडेंशियल और निजी संपत्तियों से संबंधित जानकारी को छुपाया जाना चाहिए। इससे सुरक्षा भी बनी रहती है और समस्या की जांच भी की जा सकती है।
स्वीकृति का तरीका। ऑनलाइन कार्यों के लिए सत्यापन मूल पाथ पर ही होना चाहिए। यदि कोई API खराब थी, तो उसे दोबारा चलाकर नया स्टेटस कोड देखें; यदि कोई पेज खराब था, तो ब्राउज़र में जाकर जांचें; यदि कोई टास्क खराब था, तो उसके लॉग देखें। यदि आपके पास अनुमति नहीं है, तो यह स्पष्ट लिखें कि किस अनुमति या जानकारी की कमी है।
💡 संक्षेप में: ऑनलाइन समस्याओं में Codex को सीधे सुधार करने के बजाय पहले सबूत जुटाने को कहें; सुधार के बाद मूल पाथ पर जांच करें, और संवेदनशील जानकारी छुपाते समय स्टेटस कोड और त्रुटि का विवरण बनाए रखें।
08 बड़े कामों को उप-एजेंटों में बांटें, और एक थ्रेड में एक ही काम करें
ऐसा क्यों करना है। एक सत्र (session) केवल चैट का इतिहास नहीं है, बल्कि एक कार्य थ्रेड (working thread) है जिसमें संदर्भ जमा होता रहता है। थ्रेड जितना लंबा और मिश्रित होगा, काम की गुणवत्ता उतनी ही कम होती जाएगी। इसलिए थ्रेड को प्रबंधित करना सीधे परिणाम को प्रभावित करता है।
सादृश्य: यह आपकी वर्किंग टेबल को व्यवस्थित रखने जैसा है। यदि एक ही टेबल पर तीन अलग-अलग प्रोजेक्ट्स की फाइलें बिखरी होंगी, तो आपको चीज़ें ढूंढने और निर्णय लेने में कठिनाई होगी; यदि टेबल पर केवल एक ही काम की फाइल होगी, तो काम तेज़ी से होगा। Codex का सत्र भी उसकी वर्किंग टेबल की तरह है।
कैसे करें (दो नियम)।
पहला, एक थ्रेड में एक ही संबंधित काम करें। आधिकारिक नियम यह है: जब तक समस्या वही है, उसी थ्रेड में बने रहें — इससे उसे पूरी प्रक्रिया याद रहती है। जब काम वास्तव में अलग हो जाए, तभी /fork का उपयोग करके नया थ्रेड बनाएं। पूरे प्रोजेक्ट के लिए केवल एक ही थ्रेड का उपयोग करने से बचें, क्योंकि इससे संदर्भ बहुत बड़ा हो जाता है और परिणाम खराब होने लगते हैं।
दूसरा, छोटे-मोटे कामों को उप-एजेंट (subagent) को सौंपें। मुख्य थ्रेड को मुख्य काम पर केंद्रित रखें, और कोड की जांच, टेस्ट लिखना जैसे स्वतंत्र कार्यों को उप-एजेंट को सौंप दें ताकि मुख्य थ्रेड का ध्यान न भटके।
थ्रेड प्रबंधित करने के उपयोगी कमांड (अपने स्थानीय codex --help के अनुसार देखें):
/resume: किसी पुराने सत्र को फिर से शुरू करने के लिए/fork: पुराने इतिहास को बनाए रखते हुए एक नया थ्रेड शुरू करने के लिए/compact: थ्रेड लंबा होने पर संदर्भ को संक्षेप में संपीड़ित करने के लिए (Codex भी ऐसा स्वचालित रूप से करता है)/status: वर्तमान सत्र की स्थिति देखने के लिए
मेरी आदत है कि मैं "एक काम के लिए एक थ्रेड" का उपयोग करता हूँ और काम पूरा होने पर उसे आर्काइव कर देता हूँ। इस छोटे से बदलाव से Codex के उत्तरों की गुणवत्ता में सुधार हुआ है और वह पुराने संदर्भों से भ्रमित नहीं होता।
💡 संक्षेप में: एक थ्रेड में एक ही काम करें, और बड़े या अतिरिक्त कामों को उप-एजेंटों को सौंपें ताकि संदर्भ सीमित रहे।
09 चेकलिस्ट: "क्या न करें ❌ / सही तरीका क्या है ✅"
पिछले सभी अध्यायों के मुख्य बिंदुओं को आधिकारिक तौर पर अंत में "आम गलतियों" की सूची के रूप में दिया गया है। मैंने इसे एक तालिका के रूप में तैयार किया है ताकि आप आसानी से自查 (self-check) कर सकें — यदि बाईं ओर की कोई भी स्थिति मिलती है, तो उसे दाईं ओर के तरीके से बदलें।
| ❌ आम गलतियाँ | ✅ सही तरीका |
|---|---|
| दीर्घकालिक नियमों को प्रॉम्प्ट में बार-बार लिखना | उन्हें AGENTS.md या Skills में डालें, प्रॉम्प्ट में केवल अस्थायी निर्देश रखें |
| उसे बिल्ड और टेस्ट कमांड न बताना | AGENTS.md में स्पष्ट कोडिंग और टेस्टिंग निर्देश लिखें ताकि वह अपना परिणाम देख सके |
| जटिल कार्यों को बिना योजना के सीधे शुरू करना | पहले /plan से योजना बनाएं और पुष्टि के बाद ही काम शुरू करें |
| काम को समझे बिना पूरे अधिकार देना | शुरुआत में अनुमतियां सख्त रखें, और धीरे-धीरे आवश्यकतानुसार ढील दें |
| पूरे प्रोजेक्ट के लिए केवल एक ही थ्रेड का उपयोग करना | एक काम के लिए एक थ्रेड रखें, और आवश्यकता होने पर /fork करें |
| कई थ्रेड्स में एक ही फ़ाइल बदलना, बिना git worktree के | प्रत्येक समानांतर थ्रेड के लिए git worktree का उपयोग करके स्वतंत्र कार्यक्षेत्र बनाएं |
| अधूरे कामों को सीधे स्वचालित करने का प्रयास करना | पहले काम को मैन्युअल रूप से स्थिरता से चलाएं, फिर उसे स्वचालित या Skill बनाएं |
| उसके काम को लगातार देखते रहना, जिससे आप दूसरा काम न कर सकें | उसे पृष्ठभूमि में काम करने दें और आप अपना काम करें |
| ऑनलाइन समस्या को बिना दोहराए सीधे सुधारना | पहले समस्या के लक्षण, लॉग का समय और डेटा एकत्र करें |
| केवल स्थानीय टेस्ट पास होने पर समस्या को हल मानना | मूल उपयोगकर्ता पाथ पर ऑनलाइन जांच करें और लॉग व प्रतिक्रिया दर्ज करें |
| लॉग, लिंक या उपयोगकर्ता जानकारी सीधे सार्वजनिक PR में डालना | संवेदनशील जानकारी छुपाएं, लेकिन समय और स्टेटस कोड बनाए रखें |
इसे कैसे लागू करें। इस तालिका को केवल एक बार न पढ़ें। मेरा सुझाव है: जब भी आपको लगे कि Codex सही परिणाम नहीं दे रहा है या काम में परेशानी आ रही है, तो इस तालिका के बाएं कॉलम को देखें; आपको समझ आ जाएगा कि क्या कमी है। ये गलतियाँ मैंने स्वयं की हैं और इनसे सीखकर ही ये नियम बनाए हैं।
💡 संक्षेप में: इस तालिका से अपनी जांच करें, और बाएं कॉलम की गलतियों को दाएं कॉलम के तरीकों से बदलें। यह किसी भी सामान्य सलाह से अधिक उपयोगी है।
निष्कर्ष
इस लेख में हमने केवल सैद्धांतिक बातें न करके उन आठ व्यावहारिक नियमों को समझा जिन्हें आप सीधे लागू कर सकते हैं:
- नज़रिया: Codex को अपना टीम साथी मानें, यह सबसे महत्वपूर्ण है।
AGENTS.md: दीर्घकालिक नियमों को इसमें लिखें, जो छोटा और सटीक होना चाहिए।- प्रॉम्प्ट ढांचा: "लक्ष्य + संदर्भ + बाधाएं + स्वीकृति" का पालन करें, और स्वीकृति को न छोड़ें।
- पहले योजना: जटिल कार्यों के लिए पहले
/planचलाकर योजना बनाएं। - अनुमतियां: शुरुआत में नियम सख्त रखें, धीरे-धीरे आवश्यकतानुसार ढील दें।
- स्वयं सत्यापन: उसे टेस्ट चलाने और समीक्षा करने दें, और उसे सही मानक बताएं।
- ऑनलाइन समस्या: पहले सबूत जुटाएं, मूल पाथ पर जांच करें, और संवेदनशील जानकारी छुपाएं।
- थ्रेड प्रबंधन: एक सत्र में एक ही काम करें, और बड़े कार्यों को उप-एजेंट को सौंपें।
अब आप सक्षम हैं: Codex के किसी भी काम को व्यवस्थित तरीके से पूरा करने में। इन नियमों को अपनी आदत बना लें, जिससे Codex के साथ आपका काम आसान और सुरक्षित हो जाएगा।
अगले लेख 37 सामान्य समस्याओं का निवारण में, हम एक बहुत ही व्यावहारिक विषय पर बात करेंगे: सभी नियमों का पालन करने के बाद भी, कभी-कभी Codex से गलतियाँ हो सकती हैं — जैसे कमांड त्रुटि, कोड का खराब होना, या असामान्य व्यवहार। समस्या आना स्वाभाविक है, महत्वपूर्ण यह है कि हमें पता हो कि जांच कहाँ से शुरू करनी है। एक छोटी सी बात सोचें: यदि कोई समस्या आती है, तो आपकी जांच का पहला कदम क्या होना चाहिए? अगले लेख में हम इसी क्रम पर चर्चा करेंगे।