उन्नत तकनीकें और गति बढ़ाना: आपको धीमा करने वाला मॉडल नहीं, बल्कि आपका खराब संदर्भ है
📚 सीरीज नेविगेशन: पिछला अध्याय「30 मॉडल कैसे चुनें」"एक ही प्रॉम्प्ट के लिए कौन सा मॉडल चुनें और कितनी रीजनिंग शक्ति सेट करें" के बारे में था। यह अध्याय उसी कड़ी को आगे बढ़ाता है—केवल सही मॉडल चुनना ही काफी नहीं है, वास्तव में यह इस बात से तय होता है कि आप संदर्भ (context) कैसे प्रदान करते हैं, सत्रों (sessions) को कैसे प्रबंधित करते हैं, और एक साथ कई काम कैसे करते हैं। अगला अध्याय「32 Claude Code से माइग्रेशन」बताएगा कि पुराने उपयोगकर्ता आसानी से कैसे माइग्रेट कर सकते हैं।
पिछले अध्याय के अंत में मैंने एक बात कही थी: कई बार आपको धीमा करने वाला मॉडल की कमजोरी नहीं होती, बल्कि यह होता है कि आपका दिया गया संदर्भ (context) बहुत अव्यवस्थित है, जिससे यह भटक जाता है। यह अध्याय उसी कर्ज को चुकाने के बारे में है。
पहले मैं आपको अपना एक व्यक्तिगत उदाहरण दिखाता हूँ। मार्च 2025 में, मैं एक छोटा Python टूल बना रहा था, और एक सुविधा के कारण मुझे Codex के साथ पूरी दोपहर माथापच्ची करनी पड़ी—बाद में जब मैंने /status के सत्र इतिहास की जाँच की, तो मैंने पाया कि केवल इस एक आवश्यकता के लिए 11 पुनरावृत्तियां (rounds) हुईं, जिस दौरान इसने दो बार गलत फ़ाइल को संशोधित किया और एक बार उस कॉन्फ़िगरेशन को भी "अनुकूलित" कर दिया जिसे मैंने छूने तक के लिए मना किया था। समीक्षा करते समय मुझे एहसास हुआ: समस्या gpt-5.5 की नहीं थी, बल्कि मेरी थी जिसने पहले वाक्य में केवल इतना लिखा था "मुझे एक एक्सपोर्ट सुविधा जोड़ने में मदद करें", और बाकी के दस राउंड केवल उस संदर्भ को ठीक करने में बीत गए जिसे मुझे पहली बार में ही स्पष्ट कर देना चाहिए था。
सच कहें तो, AI प्रोग्रामिंग में सबसे बड़ी मंदी कभी भी मॉडल के सोचने में लगने वाले कुछ सरल सेकंड नहीं होती, बल्कि रीवर्क (rework) या दोबारा काम करना होती है। यदि आप पहली बार में स्पष्ट नहीं करते हैं, तो यह गलत दिशा में चला जाता है, और फिर आप इसे वापस लाते हैं—इस प्रक्रिया में दो-तीन बार में ही आधा घंटा बर्बाद हो जाता है। मॉडल चाहे कितना भी तेज़ क्यों न हो, वह "पहली बार में सही काम करने" से बचने वाले समय से तेज़ नहीं हो सकता。
यह अध्याय आपको कोई जादुई मंत्र नहीं सिखाएगा, बल्कि छह ऐसी बातें बताएगा जो वास्तव में रीवर्क को कम कर सकती हैं और पूरी प्रक्रिया को सुचारू बना सकती हैं。
इस अध्याय को पढ़ने के बाद, आपको मिलेगा:
- एक अंतर्ज्ञान के विपरीत (counter-intuitive) गति बढ़ाने का मंत्र: कम रीवर्क > अंधाधुंध गति की चाह, पहली बार में सही काम करना ही सबसे अधिक समय बचाने वाली "गति" है
- एक "अच्छे अनुरोध" का निश्चित नुस्खा: लक्ष्य + संदर्भ + सीमाएं + स्वीकृति मानदंड, साथ ही एक Before/After प्रॉम्प्ट तुलना तालिका
- संदर्भ विंडो (context window) को प्रबंधित करने के तीन तरीके:
/compactसंपीड़न (compression), आवश्यकतानुसार नया सत्र शुरू करना, और पूरी लाइब्रेरी को सौंपने के बजाय@के साथ विशिष्ट फ़ाइलों को सटीक रूप से लोड करना - कार्य के अनुसार स्तर कम करके समय और पैसा बचाने का विचार (पिछले अध्याय के मॉडल चयन से संबंधित)
- एक साथ कई कार्य चलाने और Codex को स्वयं सत्यापित करने देने का उन्नत तरीका
- एक व्यावहारिक अभ्यास जिसे आप तुरंत कर सकते हैं: एक अस्पष्ट आवश्यकता को चार-चरणीय प्रारूप में फिर से लिखना, और खुद देखना कि रीवर्क दर कैसे गिरती है
⚠️ इस अध्याय के कमांड, कॉन्फ़िगरेशन कुंजियाँ (config keys), और डिफ़ॉल्ट व्यवहार Codex आधिकारिक दस्तावेज़ों पर आधारित हैं; मॉडल के नाम, क्रेडिट (credit, Codex में उपयोग की गणना के लिए बिलिंग इकाई) गुणक, और
/fastआदि संस्करण के साथ बदल सकते हैं, यह आपके स्थानीयcodex --helpऔर वास्तविक आधिकारिक दस्तावेज़ों के अधीन है。
01 गति बढ़ाने का सार: कम रीवर्क, न कि अंधाधुंध गति की चाह
पहले अपनी मानसिकता को सही करें, अन्यथा बाद की सभी तकनीकें व्यर्थ सिद्ध होंगी。
जब शुरुआती लोग "गति बढ़ाने" के बारे में सोचते हैं, तो उनकी पहली प्रतिक्रिया अक्सर होती है "तेज़ मॉडल पर स्विच करना", "रीजनिंग शक्ति कम करना" या "एक्सेलेरेशन मोड चालू करना"। इन सब पर बाद में चर्चा की जाएगी, लेकिन ये केवल गौण (minor) बातें हैं। वास्तविक मुख्य कारक रीवर्क है。
类比：做菜。 यदि आप कोई डिश बनाने में धीमे हैं, तो ऐसा शायद ही कभी गैस की आंच कम होने के कारण होता है। अक्सर ऐसा इसलिए होता है क्योंकि आधा काटने के बाद आपको एहसास होता है कि आप प्याज खरीदना भूल गए, नमक बहुत अधिक डाल दिया और फिर से शुरू करना पड़ा, या रेसिपी के चरणों को गलत समझ लिया। वास्तव में समय बर्बाद करने वाली चीजें ये "शुरू से शुरू करना" होती हैं, न कि आंच का आकार। आंच को अधिकतम करने से भी ऐसा रसोइया नहीं बच सकता जो लगातार गलतियाँ कर रहा हो और दोबारा काम कर रहा हो。
AI प्रोग्रामिंग भी बिल्कुल वैसी ही है। Codex का गलत दिशा में जाना, गलत फ़ाइल को संशोधित करना, या आपके इरादे को गलत समझना, और फिर आपका इसे वापस लाकर दोबारा बताना—इस एक चक्र की लागत इसके कुछ सेकंड अधिक सोचने की तुलना में कहीं अधिक है。
आधिकारिक दस्तावेज़ में एक वाक्य है जिसने मुझ पर गहरी छाप छोड़ी, जिसका अर्थ है: Codex जब अपने काम को स्वयं सत्यापित कर सकता है, तो आउटपुट की गुणवत्ता स्पष्ट रूप से अधिक होती है। दूसरे शब्दों में, इसे पहली बार में ही सही और स्थिर दिशा में ले जाना, इसे तेज़ चलाने की तुलना में कहीं अधिक महत्वपूर्ण है。
मेरा खुद का एक बहुत ही विशिष्ट अनुभव रहा है। पिछले साल के अंत में, मैंने इसे "इस फ़ंक्शन को अनुकूलित (optimize) करने" के लिए कहा, बिना यह बताए कि क्या अनुकूलित करना है, क्या नहीं छूना है, और सफलता कैसे मापी जाएगी। इसने उत्साहपूर्वक फ़ंक्शन को फिर से लिखा, और साथ ही मेरे इंटरफ़ेस सिग्नेचर (interface signature) को भी बदल दिया, जिससे तीन कॉल करने वाले प्रोग्राम एरर देने लगे। मुझे इसके द्वारा "अनुकूलित" किए गए उस कचरे को साफ करने में बीस मिनट लगे। उस घटना के बाद मैंने एक कड़ा नियम बनाया: कभी भी अस्पष्ट "अनुकूलित करें" नहीं कहना है, बल्कि दो लाइनें अधिक लिखना बेहतर है。
इस प्राथमिकता क्रम को याद रखें, बाद के... पांच खंड इसी का विस्तार हैं:
| आपके विचार में गति बढ़ना | वास्तविक गति बढ़ाना |
|---|---|
| ❌ केवल तेज़ मॉडल पर स्विच करना | ✅ पहले वाक्य में ही स्पष्ट करना, रीवर्क चक्रों को कम करना |
| ❌ गति के लिए बिना सोचे-समझे रीजनिंग शक्ति कम करना | ✅ कार्य की कठिनाई के अनुसार कंप्यूटिंग पावर का मिलान करना (पिछले अध्याय में चर्चा की गई) |
| ❌ पूरा प्रोजेक्ट इसे पढ़ने के लिए सौंप देना | ✅ संबंधित फ़ाइलों को सटीक रूप से लोड करने के लिए @ का उपयोग करना |
| ❌ एक ही सत्र को सुबह से शाम तक खुला रखना | ✅ एक कार्य के लिए एक सत्र, समय पर संपीड़न करना या नया खोलना |
| ❌ परिवर्तन के बाद खुद एक-एक करके आँखों से जाँचना | ✅ स्वीकृति मानदंड देना, और इसे स्वयं परीक्षण चलाने और सत्यापित करने देना |
💡 एक वाक्य में सारांश: AI प्रोग्रामिंग में सबसे बड़ी मंदी रीवर्क है, गति बढ़ाने का पहला सिद्धांत "पहली बार में सही करना" है, न कि "तेज़ी से चलना"。
02 पर्याप्त संदर्भ दें, इसे अनुमान न लगाने दें: एक अच्छे अनुरोध का निश्चित नुस्खा
पिछले खंड में कहा गया था कि रीवर्क मुख्य कारण है, तो रीवर्क कहाँ से आता है? अधिकांशतः यह पहले वाक्य में स्पष्ट न करने के कारण आता है, जिससे Codex को अनुमान लगाना पड़ता है। जब यह अनुमान लगाता है, तो इसके गलत होने की संभावना होती है, और आपको दोबारा काम करना पड़ता है。
समानता: फूड डिलीवरी नोट。 यदि आप केवल "फ्राईड राइस" लिखते हैं, तो राइडर और शेफ केवल डिफ़ॉल्ट के अनुसार काम कर सकते हैं—इसमें प्याज हो सकता है, यह तीखा हो सकता है, या नमकीन हो सकता है। यदि आप लिखते हैं "यांगझोउ फ्राईड राइस, बिना प्याज के, हल्का तीखा, चावल थोड़े नरम", तो यह पहली बार में ही सही होगा। Codex को भेजे जाने वाले अनुरोधों के साथ भी ऐसा ही है; आपके द्वारा बचाया गया हर एक शब्द इसे अनुमान लगाने के लिए मजबूर करता है, और यदि अनुमान गलत हुआ, तो दोबारा काम करना पड़ेगा。
आधिकारिक "सर्वोत्तम प्रथाओं" में एक नुस्खा दिया गया है जिसका मैं आज तक पालन करता हूँ। एक अच्छे अनुरोध में डिफ़ॉल्ट रूप से ये चार चीजें शामिल होनी चाहिए:
- लक्ष्य (Goal): आप वास्तव में क्या बदलना या बनाना चाहते हैं?
- संदर्भ (Context): कौन सी फ़ाइलें, दस्तावेज़ या एरर इस कार्य से संबंधित हैं? उन्हें इंगित करने के लिए
@का उपयोग करें। - सीमाएं (Constraints): आपको किन नियमों या आर्किटेक्चर का पालन करना चाहिए, और किसे नहीं छूना चाहिए?
- स्वीकृति मानदंड (Done when): काम कब पूरा माना जाएगा? परीक्षण (testing) पास हो गए हैं, व्यवहार बदल गया है, या bug दोबारा दिखाई नहीं दे रहा है?
इन चारों को हर बार पूरा लिखने की आवश्यकता नहीं है, लेकिन लक्ष्य और स्वीकृति मानदंड को शायद ही कभी छोड़ा जा सकता है। अब जब मैं आवश्यकताओं को लिखता हूँ, चाहे मैं कितनी भी जल्दी में क्यों न हूँ, मैं अपने दिमाग में इन चार स्लॉट पर विचार करता हूँ。
| ❌ Before (अस्पष्ट, रीवर्क होना तय है) | ✅ After (चार-चरणीय प्रारूप, पहली बार में सफल होने की उच्च संभावना) |
|---|---|
| मुझे एक एक्सपोर्ट सुविधा जोड़ने में मदद करें | लक्ष्य: report.py में एक फ़ंक्शन जोड़ें जो रिपोर्ट को CSV के रूप में एक्सपोर्ट कर सके। संदर्भ: @export/json_export.py में मौजूदा लेखन पद्धति का संदर्भ लें। सीमाएं: मौजूदा Report डेटा क्लास का पुन: उपयोग करें, इसके फ़ील्ड को न बदलें। स्वीकृति: हेडर के साथ CSV एक्सपोर्ट करने में सक्षम हो, और tests/test_export.py सभी पास हो जाएं。 |
| यह फ़ंक्शन थोड़ा धीमा है, इसे अनुकूलित करें | लक्ष्य: 10,000 डेटा पर search() में 2 सेकंड लगते हैं, इसे 200ms से कम करें। संदर्भ: फ़ंक्शन @core/search.py में है。 सीमाएं: फ़ंक्शन सिग्नेचर और रिटर्न संरचना को बदलने की अनुमति नहीं है。 स्वीकृति: pytest tests/test_search.py::test_perf चलाएं, और पुष्टि करें कि लिया गया समय < 0.2s है。 |
| इस bug को ठीक करें | लक्ष्य: लॉगिन के बाद खाली पेज पर रीडायरेक्ट होने की समस्या को ठीक करें。 संदर्भ: रीप्रोड्यूस करने के चरण हैं "सही यूजरनाम और पासवर्ड दर्ज करें → लॉगिन पर क्लिक करें → व्हाइट स्क्रीन", संबंधित कोड @auth/login.py में है。 सीमाएं: क्रेडेंशियल वेरिफिकेशन लॉजिक को न बदलें。 स्वीकृति: रीप्रोड्यूस करने के चरणों को दोहराने पर होम पेज सामान्य रूप से लोड होना चाहिए。 |
क्या आपने अंतर देखा? दाहिनी ओर का विवरण अधिक लंबा नहीं है, बल्कि यह उस जानकारी को पूरा करता है जो पहले से ही आपके दिमाग में थी लेकिन आपने उसे टाइप नहीं किया था。 यदि आप इसे पूरा नहीं करते हैं, तो Codex को अनुमान लगाना होगा; यदि आप इसे पूरा करते हैं, तो यह सीधे लक्ष्य की ओर जाएगा。
जब मैंने उस Python टूल की समीक्षा की, तो मैंने पाया कि एक ही आवश्यकता के लिए, बाईं ओर की शैली का उपयोग करने पर मुझे औसतन 5 से 8 राउंड लगे, जबकि दाहिनी ओर के चार-चरणीय प्रारूप के साथ, अधिकांश समय यह 1 से 2 राउंड में ही पूरा हो गया。 वे दो अतिरिक्त लाइनें लिखने से बाद के तीन चक्र बच गए。
एक और आसान लेकिन प्रभावी तरीका है: यदि कार्य बहुत कठिन है और आप खुद नहीं जानते कि इसे कैसे समझाएं, तो इसे जबरदस्ती लिखने की कोशिश न करें, बल्कि पहले Codex को इसे व्यवस्थित करने दें。 आधिकारिक तौर पर प्लान मोड (Plan mode) का उपयोग करने की सिफारिश की जाती है, CLI में /plan या Shift+Tab का उपयोग करके इस पर स्विच करें। यह पहले संदर्भ एकत्र करेगा, आपसे कुछ प्रश्न पूछेगा, और एक योजना तैयार करेगा, और काम तभी शुरू करेगा जब आप सहमति देंगे। गलतफहमी के कारण काम को गलत दिशा में ले जाने के बजाय, एक मिनट का समय देकर इसे पहले योजना तैयार करने देना बेहतर है。
💡 एक वाक्य में सारांश: एक अच्छा अनुरोध = लक्ष्य + संदर्भ + सीमाएं + स्वीकृति मानदंड; आपके द्वारा बचाया गया हर एक शब्द Codex को अनुमान लगाने पर मजबूर करता है, और अनुमान गलत होने पर दोबारा काम करना पड़ता है。
03 संदर्भ विंडो (context window) को प्रबंधित करें: पूरी लाइब्रेरी को न सौंपें
दूसरा खंड "स्पष्ट रूप से बताने" के बारे में था, और यह खंड "बहुत अधिक न बताने" के बारे में है। ये दोनों विरोधाभासी लग सकते हैं, लेकिन वास्तव में ऐसा नहीं है—आवश्यकता इस बात की है कि प्रासंगिक जानकारी पूरी हो, और अप्रासंगिक जानकारी न हो。
प्रत्येक सत्र (जिसे Codex में thread कहा जाता है) की एक सीमा होती है, जिसे संदर्भ विंडो (context window) कहा जाता है। यह उस जानकारी की कुल मात्रा को दर्शाता है जिसे मॉडल एक बार में "याद" रख सकता है। जब यह भर जाता है, तो पुरानी जानकारी या तो संपीड़ित हो जाती है या हटा दी जाती, जिससे आउटपुट की गुणवत्ता गिरने लगती है。
समानता: एक ऑफिस डेस्क。 डेस्क का आकार सीमित होता है। यदि आप वर्तमान कार्य के लिए आवश्यक तीन फ़ाइलों को फैलाकर रखते हैं, तो काम करना आसान हो जाता है। यदि आप कैबिनेट से सैकड़ों दस्तावेज़ निकालकर डेस्क पर रख देते हैं, तो आपको वह फ़ाइल नहीं मिलेगी जिसकी आपको आवश्यकता है। Codex की संदर्भ विंडो भी इसी डेस्क की तरह है; आप इसे जितनी सटीकता से जानकारी प्रदान करेंगे, यह उतना ही केंद्रित रहेगा; यदि आप पूरी लाइब्रेरी को सौंप देंगे, तो यह अप्रासंगिक जानकारी से भ्रमित हो जाएगा。
इसे प्रबंधित करने के लिए, तीन तरीके याद रखें:
पहला तरीका: सटीक फ़ाइलें लोड करने के लिए @ का उपयोग करें, इसे पूरी लाइब्रेरी में खुद खोजने न दें。 यदि आप जानते हैं कि किन फ़ाइलों को संशोधित करना है, तो उन्हें सीधे @ के साथ निर्दिष्ट करें। इसे खोजने के लिए संदर्भ बर्बाद नहीं करना पड़ेगा, और काम तेज़ और सटीक होगा। मेरी उस दोपहर की समस्या का एक मूल कारण यह भी था कि मैंने फ़ाइलों को निर्दिष्ट नहीं किया था, और इसने संशोधन वाली जगह को खोजने के लिए सात या आठ अप्रासंगिक मॉड्यूल पढ़े—वह सारी जानकारी डेस्क पर जगह घेर रही थी。
第二个方法：सत्र लंबा होने पर /compact का उपयोग करें。 जब कोई बातचीत लंबे समय तक चलती है, तो पिछला संदर्भ बहुत अधिक जमा हो जाता है। /compact कमांड Codex को शुरुआती संदर्भ को एक सारांश में संपीड़ित करने के लिए कहता है, जिससे आगे काम करने के लिए जगह खाली हो जाती है। आधिकारिक तौर पर भी कहा गया है कि Codex आवश्यकतानुसार स्वचालित रूप से संपीड़ित करेगा, लेकिन मैन्युअल रूप से /compact चलाने से आप इसके प्रदर्शन में गिरावट आने से पहले ही जगह साफ कर सकते हैं。
तीसरा तरीका, जो आधिकारिक तौर पर बार-बार दोहराया गया है—एक कार्य के लिए एक सत्र, सुबह से शाम तक एक ही सत्र का उपयोग न करें。 आधिकारिक "सामान्य गलतियाँ" में विशेष रूप से उल्लेख किया गया है: "एक कार्य के लिए एक सत्र" के बजाय "एक प्रोजेक्ट के लिए एक सत्र" का उपयोग करने से संदर्भ बहुत भारी हो जाता है, और परिणाम लगातार खराब होते जाते हैं。
मेरा अब एक कड़ा नियम है: एक बार जब कोई आवश्यकता पूरी हो जाती है, तो अगली असंबंधित आवश्यकता के लिए मैं सीधे एक नया सत्र खोलता हूँ。 CLI में इसके लिए कुछ बहुत ही उपयोगी कमांड हैं:
/compact 把当前会话的早期上下文压缩成摘要，腾空间
/status 看当前会话状态，包括上下文还剩多少
/fork 基于当前会话另开一条线，保留原始记录
/resume 恢复之前存过的某个会话एक निर्णय सिद्धांत: संदर्भ "सटीक" होना चाहिए, "बहुत अधिक" नहीं। एक ही समस्या के लिए एक ही सत्र में बने रहें ताकि रीजनिंग श्रृंखला बनी रहे; यदि काम वास्तव में अलग दिशा में जाता है, तभी /fork करें या नया सत्र शुरू करें。
निर्णय का मानक बहुत सरल है: यदि यह अभी भी उसी समस्या का विस्तार है, तो मूल सत्र में बने रहें; यदि यह एक असंबंधित काम है, तो एक नया खोलें。 उस "इतिहास रिकॉर्ड" के मोह में न पड़ें, क्योंकि भारी संदर्भ का परिणाम केवल खराब आउटपुट होता है, जो किसी भी तरह से फायदेमंद नहीं है。
💡 一句话总结：上下文要准不要多，
@精准喂文件、/compact及时压缩、一个任务一个会话，是管好上下文窗口的三件套。
04 कार्य के अनुसार स्तर कम करना: सरल कार्यों के लिए फ्लैगशिप का उपयोग न करें
यह खंड पिछले अध्याय की निरंतरता में है और इसे संक्षेप में समझाया गया है—पिछला अध्याय मॉडल चयन के बारे में था, यहाँ हम केवल "गति बढ़ाने" के दृष्टिकोण को जोड़ रहे हैं。
समानता: यात्रा के लिए साधन चुनना。 आप नीचे से पानी की बोतल खरीदने के लिए कार नहीं चलाएंगे, बल्कि पैदल ही चले जाएंगे; और आप किसी दूसरे शहर की यात्रा के लिए साझा साइकिल का उपयोग नहीं करेंगे। कार्य की कठिनाई यह तय करती है कि कितनी कंप्यूटिंग पावर की आवश्यकता है, ठीक वैसे ही जैसे यात्रा की दूरी वाहन का चयन तय करती है。
विशिष्ट संचालन के लिए केवल एक सिद्धांत है: सरल और स्पष्ट दायरे वाले कार्यों के लिए, स्तर कम करके चलाएं。 आधिकारिक "सर्वोत्तम प्रथाओं" में दी गई रीजनिंग शक्ति की सिफारिशें बहुत स्पष्ट हैं—
- स्पष्ट दायरे वाले त्वरित कार्य:
lowका उपयोग करें, या इससे भी सरल कार्यों के लिए और कम स्तर का उपयोग कर सकते हैं - जटिल परिवर्तन, डिबगिंग:
mediumयाhighका उपयोग करें - लंबे, भारी और गहन रीजनिंग की आवश्यकता वाले कार्य: केवल तभी
xhighका उपयोग करें
模型层面同理，琐碎活儿、子代理跑的探活，用轻量的 gpt-5.4-mini 就够，没必要事事都搬旗舰 gpt-5.5 出来。改 typo、改个变量名、跑个简单查询，降到 gpt-5.4-mini + low，又快又省信用点。
मेरी अपनी ~/.codex/config.toml फ़ाइल में डिफ़ॉल्ट रूप से मध्यम स्तर सेट है, और केवल कठिन कार्यों का सामना करने पर ही मैं अस्थायी रूप से स्तर को बढ़ाता हूँ। मेरे पुराने व्यवहार की तरह डिफ़ॉल्ट रूप से gpt-5.5 + xhigh को लॉक न करें—एक वेरिएबल नाम बदलने के लिए इसके "गहन विचार" करने का एक मिनट तक इंतजार करने की मूर्खता का अनुभव मैं खुद कर चुका हूँ。 इसे कैसे कॉन्फ़िगर करें और चार स्विच करने के तरीके क्या हैं, इसके लिए अध्याय 30 देखें。
💡 एक वाक्य में सारांश: सरल कार्यों के लिए स्तर कम करें,
gpt-5.4-mini+lowतेज़ और किफायती हैं; फ्लैगशिप को केवल वास्तव में कठिन कार्यों के लिए बचाकर रखें।
05 समानांतर कार्य (Parallelism): एक साथ कई कार्य चलाएं
पिछले चार खंडों में केवल एक कार्य को सुचारू बनाने पर ध्यान दिया गया था। यह खंड एक अलग आयाम जोड़ता है—एक काम के पूरा होने का इंतजार न करें, बल्कि एक साथ कई काम चलाएं。
官方「常见错误」里有一条说得很直白：把 Codex 当成一个你得一步步盯着的工具，而不是跟你并行干活的搭子，是新手的典型误区。 你完全可以让它在一边吭哧吭哧重构，你这边继续干别的。
但有个前提坑——别让两条线同时改同一批文件。 它们会互相踩脚，改乱你的工作区。官方给的解法是 git worktrees（工作树），第 25 篇专门讲过。
समानता: नवीनीकरण (renovation) के दौरान कई कारीगरों का एक साथ काम करना。 यदि प्लंबिंग, बढ़ईगीरी और पेंटिंग का काम एक साथ करना है, तो उन्हें अलग-अलग कमरों में काम करना होगा, वे एक ही कमरे में एक-दूसरे से नहीं टकरा सकते। worktree प्रत्येक कार्य को एक स्वतंत्र "कमरा" आवंटित करने जैसा है, जिससे वे एक-दूसरे में हस्तक्षेप न करें。
समानांतरता (Parallelism) के दो सामान्य तरीके हैं, जो पिछले अध्यायों से संबंधित हैं:
| विधि | कैसे अलग करें | संबंधित अध्याय |
|---|---|---|
| एक साथ कई कार्य चलाना | प्रत्येक कार्य के लिए एक git worktree, स्वतंत्र निर्देशिका | अध्याय 25 worktrees |
| मुख्य कार्य + उप-कार्य (Sub-tasks) | मुख्य एजेंट कोर समस्या पर ध्यान केंद्रित करता है, और जाँच, परीक्षण और डिबगिंग सब-एजेंटों को सौंपता है | अध्याय 21 subagents |
सब-एजेंटों (subagents) के लिए आधिकारिक सिफारिश यह है: मुख्य एजेंट को मुख्य समस्या पर ध्यान केंद्रित करने दें, और स्पष्ट दायरे वाले कार्यों—कोड की खोज करना, परीक्षण लिखना, और समस्याओं का निवारण करना—को सब-एजेंटों को सौंप दें। इससे मुख्य कार्य बाधित नहीं होगा और समग्र गति बढ़ जाएगी。
现在我做稍大一点的需求，习惯是：主会话推进核心逻辑，同时另开 worktree 让 Codex 跑一遍测试和 lint。等我主线写完，它那边的检查结果也差不多出来了，两件事并着走，比串着干省一大截时间。
💡 一句话总结：让多条线并行跑，worktree 做隔离、子代理分活，但绝不让两条线同时改同一批文件。
06 इसे स्वयं सत्यापित करने दें: बार-बार पुष्टि करने के चक्रों को समाप्त करें
आखिरी तरीका, जो सबसे अधिक अनदेखा किया जाता है लेकिन सबसे अधिक फायदेमंद है—Codex को स्वयं सत्यापित करने दें, हर चीज को खुद आँखों से जाँचना बंद करें。
पहले खंड के सिद्धांत पर वापस जाएँ: रीवर्क सबसे बड़ी मंदी है। और आपका बार-बार पुष्टि करना भी एक मंदी है。 इसके काम पूरा करने के बाद, आप फ़ाइल खोलते हैं, एक-एक करके लाइनें देखते हैं, कुछ गलत पाते हैं, और फिर से बताते हैं—यह मैन्युअल चेकिंग का हर एक चक्र बहुत समय लेता है。
आधिकारिक तौर पर बहुत स्पष्ट रूप से कहा गया है: Codex अपने काम को सत्यापित करने में सक्षम होने पर बेहतर आउटपुट देता है, लेकिन इसके लिए आवश्यक है कि इसे पता हो कि "सफल कार्य" कैसा दिखता है। यह मानक आपके प्रॉम्प्ट या प्रोजेक्ट मैनुअल AGENTS.md से आ सकता है。
समानता: काम सौंपने से पहले चेकलिस्ट。 जब आप किसी जूनियर को काम सौंपते हैं, तो आप उसे एक चेकलिस्ट देते हैं जिसमें लिखा होता है "जमा करने से पहले खुद इन पांच चीजों की जांच करें"। वह खुद जांच करने के बाद काम सौंपता है, और आपको केवल एक त्वरित समीक्षा करनी होती है। यदि कोई चेकलिस्ट नहीं है, तो आपको खुद एक-एक करके गलतियाँ ढूंढनी होंगी, जिससे आप स्वयं बाधा (bottleneck) बन जाएंगे। Codex को स्वीकृति मानदंड प्रदान करना इसे यह चेकलिस्ट देने जैसा है。
विशिष्ट रूप से, इसे स्वयं ये कार्य करने दें (आधिकारिक "सर्वोत्तम प्रथाओं" से):
- परिवर्तनों के लिए परीक्षण लिखना या अपडेट करना
- संबंधित परीक्षण सूट चलाना
- lint, फ़ॉर्मेटिंग और टाइप चेकिंग चलाना
- यह पुष्टि करना कि अंतिम व्यवहार वैसा ही है जैसा आप चाहते थे
- किसी भी bug, रिग्रेशन (regression) या खतरनाक कोड को खोजने के लिए स्वयं diff की समीक्षा करना
CLI में /review कमांड बहुत उपयोगी है। यह बेस ब्रांच के आधार पर PR-शैली की समीक्षा कर सकता है, अप्रतिबद्ध (uncommitted) परिवर्तनों की समीक्षा कर सकता है, या आपके द्वारा दिए गए कस्टम नियमों के अनुसार समीक्षा कर सकता है。
अधिक टिकाऊ दृष्टिकोण: AGENTS.md में लिखें कि "काम कब पूरा माना जाएगा" और "कौन से परीक्षण चलाने हैं", ताकि यह हर बार स्वचालित रूप से सत्यापित कर सके। आपको हर बार प्रॉम्प्ट में इसे दोहराने की आवश्यकता नहीं होगी। यह अध्याय 11 में कवर किया गया है。
मेरी अब मानक प्रक्रिया यह है कि अनुरोध में सीधे यह पंक्ति जोड़ दी जाती है: "संशोधन के बाद एक बार pytest चलाएं, और सभी परीक्षण पास (green) होने के बाद ही मुझे सूचित करें"। यह परीक्षण चलाता है और पास होने की पुष्टि करने के बाद ही वापस आता है, जिससे मेरा "इसने कहा कि काम हो गया → मैंने परीक्षण चलाया → विफल हुआ → फिर से ठीक करने को कहा" का पूरा दो-चक्र का समय बच जाता है। स्पष्ट रूप से कहें तो, इसे सत्यापन का काम सौंपकर ही आप वास्तव में "इस पर नजर रखने" की चिंता से मुक्त हो सकते हैं。
💡 एक वाक्य में सारांश: स्वीकृति मानदंड प्रदान करना और Codex को स्वयं परीक्षण और समीक्षा करने देना बार-बार मैन्युअल पुष्टि के चक्रों को समाप्त कर सकता है। यह गति बढ़ाने का सबसे प्रभावी तरीका है।
07 वैसे, फास्ट मोड (Fast mode) जैसी छोटी तकनीकें
एक बार जब मॉडल और तीव्रता तय हो जाती है, तो अनुभव को अधिक सुविधाजनक बनाने के लिए दो छोटे स्विच होते हैं। केवल यह जानना पर्याप्त है कि वे मौजूद हैं, शुरुआत में इनके साथ छेड़छाड़ करने की आवश्यकता नहीं है。
Codex में एक फास्ट मोड (Fast mode) होता है, जो समर्थित मॉडलों की गति को लगभग 1.5 गुना बढ़ा सकता है, लेकिन इसकी लागत अधिक क्रेडिट है। आधिकारिक स्पष्टीकरण के अनुसार, यह वर्तमान में GPT-5.5 और GPT-5.4 का समर्थन करता है। GPT-5.5 फास्ट मोड में मानक दर से 2.5 गुना क्रेडिट लेता है, जबकि GPT-5.4 2 गुना लेता है。
CLI में इन कमांड का उपयोग करके इसे चालू/बंद और देख सकते हैं:
/fast on 开启快速模式
/fast off 关闭
/fast status 看当前状态यदि आप चाहते हैं कि यह डिफ़ॉल्ट रूप से चालू रहे, तो आप इसे ~/.codex/config.toml में कॉन्फ़िगर कर सकते हैं:
service_tier = "fast"
[features]
fast_mode = trueदो बातें ध्यान में रखें: पहली बात, फास्ट मोड केवल ChatGPT लॉगिन के माध्यम से उपलब्ध है। यदि आप API key का उपयोग करते हैं, तो मानक API मूल्य निर्धारण लागू होगा और इसका उपयोग नहीं किया जा सकेगा। दूसरी बात, यह गति बढ़ाने के लिए पैसे (क्रेडिट) खर्च करता है, यह मुफ्त नहीं है。
ईमानदारी से कहें तो, फास्ट मोड केवल "अंतिम मील" का एक छोटा सा तरीका है, यह मुख्य समाधान नहीं है。 पहले छह खंडों (आवश्यकताओं को स्पष्ट करना, संदर्भ को प्रबंधित करना, कार्य के अनुसार स्तर कम करना, समानांतरता, और स्वयं सत्यापन) द्वारा बचाया गया समय "चक्रों" और "पूरी रीवर्क प्रक्रियाओं" के रूप में मापा जाता है; फास्ट मोड केवल एकल प्रतिक्रिया समय को 1.5 गुना बचाता है। पहले छह चीजों को सही ढंग से करें, और फिर विचार करें कि क्या इस थोड़ी सी गति के लिए अधिक क्रेडिट खर्च करना उचित है。 मैं आमतौर पर इसे चालू नहीं रखता, केवल तभी /fast on करता हूँ जब मैं जल्दी में होता हूँ और काम इसके लायक होता है。
💡 एक वाक्य में सारांश: फास्ट मोड अधिक क्रेडिट खर्च करके 1.5 गुना गति प्रदान करता है, जो केवल एक अतिरिक्त सुविधा है; पहले छह तरीके पूरी रीवर्क प्रक्रिया को बचाते हैं, इसलिए पहले उन पर ध्यान दें।
08 व्यावहारिक अभ्यास: एक अस्पष्ट अनुरोध को चार-चरणीय प्रारूप में बदलें
केवल देखने से याद नहीं रहेगा। यह पांच मिनट का अभ्यास आपको "पहली बार में सफल होने" और "बार-बार रीवर्क करने" के बीच का अंतर समझाएगा。
पहला चरण: एक ऐसा अस्पष्ट अनुरोध खोजें जो आप आमतौर पर लिखते हैं。 उदाहरण के लिए:
帮我给这个项目加个日志功能दूसरा चरण: खंड 02 के नुस्खे के अनुसार इसे चार-चरणीय प्रारूप में बदलें。 अपने दिमाग में (या सीधे लिखकर) इन चार स्लॉट को पूरा करें:
目标：给项目加一个统一的日志工具，能按 INFO/ERROR 分级输出到控制台和文件。
上下文：参考 @utils/config.py 里读配置的写法，日志级别从配置读。
约束：用标准库 logging，不要引第三方日志库；不改现有任何函数签名。
验收：在 main 入口能 import 并打印一条 INFO 日志到 logs/app.log，文件能正常生成。तीसरा चरण: दोनों संस्करणों को अलग-अलग Codex को भेजें और रीवर्क चक्रों को गिनें。 पहले अस्पष्ट संस्करण के लिए एक सत्र खोलें, इसके काम पूरा होने की प्रतीक्षा करें (ध्यान दें कि यह आपसे कुछ प्रश्न पूछ सकता है, या खुद कोई योजना चुन सकता है), और गिनें कि आपकी संतुष्टि तक कुल कितने दौर लगे; फिर चार-चरणीय संस्करण के लिए एक नया सत्र खोलें और इसी तरह चक्रों को गिनें。
अपेक्षित परिणाम:
- अस्पष्ट संस्करण: Codex की सबसे अधिक संभावना है कि वह पहले पूछेगा "कहाँ आउटपुट देना है", "क्या स्तरों में विभाजित करना है", "किस लाइब्रेरी का उपयोग करना है", या सीधे कोई ऐसी योजना चुन लेगा जो शायद आप नहीं चाहते थे। आमतौर पर 3 या अधिक दौर लगेंगे。
- चार-चरणीय संस्करण: यह सीधे काम पर लग जाएगा, अधिकांशतः 1 से 2 दौर में काम पूरा हो जाएगा, और आउटपुट आपकी अपेक्षाओं के अधिक अनुरूप होगा。
इस अभ्यास का उद्देश्य यह नहीं है कि विशिष्ट रूप से कितने दौर लगे, बल्कि यह है कि आप स्वयं महसूस करें: वे चार अतिरिक्त लाइनें लिखने से बाद के कई रीवर्क दौर बच जाते हैं। यह सौदा हमेशा फायदेमंद होता है。
इस अभ्यास को पूरा करने के बाद, अपनी पसंदीदा चार-चरणीय सीमाएं और स्वीकृति आदतों को AGENTS.md में शामिल करें, ताकि आपको हर बार इसे मैन्युअल रूप से टाइप न करना पड़े。
💡 एक वाक्य में सारांश: अस्पष्ट संस्करण और चार-चरणीय संस्करण को खुद चलाकर चक्रों की गणना करें, आप सीधे देखेंगे कि कैसे चार अतिरिक्त लाइनें लिखने से रीवर्क बच जाता है।
सारांश
इस अध्याय में "गति बढ़ाने" को "तेज़ मॉडल पर स्विच करना" की गलतफहमी से बाहर निकाला गया है, और छह वास्तव में समय बचाने वाले तरीकों पर ध्यान केंद्रित किया गया है:
- मंत्र: कम रीवर्क > अंधाधुंध गति की चाह, पहली बार में सही करना ही सबसे अधिक समय बचाने वाली गति है।
- आवश्यकता स्पष्ट करना: लक्ष्य + संदर्भ + सीमाएं + स्वीकृति मानदंड; बचाए गए हर एक शब्द के लिए Codex को अनुमान लगाना पड़ता है।
- संदर्भ प्रबंधित करना:
@का उपयोग करके सटीक फ़ाइलें लोड करना, समय पर/compactसंपीड़न करना, और प्रत्येक कार्य के लिए एक सत्र रखना। - कार्य के अनुसार स्तर कम करना: सरल कार्यों के लिए
gpt-5.4-mini+lowका उपयोग करें, और फ्लैगशिप को कठिन कार्यों के लिए बचाएं। - समानांतरता: worktree के साथ अलगाव, सब-एजेंटों को काम सौंपना, और दो कार्यों को कभी भी एक ही समय में एक ही फ़ाइल को संशोधित करने की अनुमति न देना।
- स्वयं सत्यापन: स्वीकृति मानदंड प्रदान करना, इसे परीक्षण और समीक्षा चलाने देना, और मैन्युअल रिव्यू के समय को बचाना।
- फास्ट मोड जैसे छोटे तरीके केवल अतिरिक्त सुविधाएं हैं, पहले मुख्य बातों को सही ढंग से करें।
अब आप यह करने में सक्षम होने चाहिए: जब आपको कोई आवश्यकता मिले, तो सबसे पहले अपने दिमाग में चार-चरणीय प्रारूप पर विचार करें, न कि सीधे कोई अस्पष्ट बात लिख दें; संदर्भ को सटीक और साफ रखने के लिए @ और /compact का उपयोग करें; सरल कार्यों के लिए स्तर कम करना, जटिल कार्यों के लिए समानांतर काम करना, और सभी कार्यों को Codex द्वारा सत्यापित करवाना सीखें। इसे अपनी आदत (muscle memory) बना लें, और आपकी दैनिक उत्पादकता में भारी वृद्धि होगी—इसलिए नहीं कि मॉडल तेज़ हो गया है, बल्कि इसलिए कि आपने इसे भटकने से रोक दिया है।
अगला अध्याय〔32 Claude Code से माइग्रेशन〕विशेष रूप से उन पाठकों के लिए है: जो Claude Code से माइग्रेट करने वाले पुराने उपयोगकर्ता हैं। CLAUDE.md यहाँ किस फ़ाइल से मेल खाती है? अनुमतियाँ (permissions), Skill, और सब-एजेंट जैसी अवधारणाओं को यहाँ कैसे स्थानांतरित किया जा सकता है? कौन सी आदतें सीधे अपनाई जा सकती हैं और किसे बदलने की आवश्यकता है? एक छोटी सी बात पर विचार करें—Claude Code में सीखी गई ऐसी कौन सी आदत है जो Codex में आपके काम को धीमा कर सकती है? अगले अध्याय में इसका खुलासा होगा।