Codex लंबे समय तक काम कर सकता है, खासकर जब कोई /goal इसे एक स्थायी उद्देश्य देता है। सबसे कठिन हिस्सा यह है कि जब यह घंटों या दिनों तक काम करता है, नए कार्यान्वयन विवरण खोजता है, और कई प्रकार के सत्यापनों से गुज़रता है, तब भी दिशा-निर्देशन बनाए रखना।
कार्यान्वयन शुरू होने के बाद अक्सर शुरुआती धारणाएँ बदल जाती हैं। सहयोग मॉडल को उद्देश्य को संरक्षित करना चाहिए, साथ ही आपको और Codex दोनों को नए सबूत सामने आने पर योजना को संशोधित करने की गुंजाइश देनी चाहिए।
पिछले कुछ हफ्तों में, मैं पाँच प्रथाओं का उपयोग कर रहा हूँ:
- Codex को काम की योजना बनाने और रोडमैप बनाए रखने दें।
- मुख्य थ्रेड को समन्वय पर केंद्रित रखें।
- प्रत्येक माइलस्टोन के बाद रोडमैप का ऑडिट करें और कोड की समीक्षा करें।
- कंप्यूटर उपयोग परीक्षण के लिए स्थानीय थ्रेड का उपयोग करें।
- संक्षिप्त अपडेट और डैशबोर्ड के माध्यम से प्रगति की रिपोर्ट करें।
Codex में GPT Image 2 के साथ जनरेट किया गया
1. Codex को काम की योजना बनाने और रोडमैप बनाए रखने दें
मैं आमतौर पर /plan मोड के बजाय बातचीत से शुरुआत करता हूँ। मैं बताता हूँ कि मैं क्या बनाने की कोशिश कर रहा हूँ, मोटे विचार बताता हूँ, बाधाएँ साझा करता हूँ, और Codex को तब तक सवाल पूछने देता हूँ जब तक कि उसके पास प्रारंभिक योजना प्रस्तावित करने के लिए पर्याप्त संदर्भ न हो।
यह शुरुआती चर्चा को लचीला रखता है। मुझे Codex की मदद शुरू होने से पहले आधे-अधूरे विचारों को औपचारिक विनिर्देश में बदलने की ज़रूरत नहीं है। यह मेरा साक्षात्कार कर सकता है, जो समझा है उसे वापस प्रतिबिंबित कर सकता है, अंतराल की पहचान कर सकता है, और धीरे-धीरे बातचीत को एक कार्य योग्य योजना में बदल सकता है।
जैसे-जैसे प्रोजेक्ट आकार लेता है, मैं Codex से वर्तमान Goal सेट करने के लिए कहता हूँ। Goal मोड Codex को एक स्थायी उद्देश्य देता है, जिससे वह एक ही परिणाम की दिशा में कई चरणों में तब तक काम करता रह सकता है जब तक कि लक्ष्य पूरा, अवरुद्ध या बदल न दिया जाए।
मैं /goal के साथ स्वयं लक्ष्य निर्धारित कर सकता हूँ, लेकिन मैं आमतौर पर Codex से ऐसा करने के लिए कहता हूँ। Goal मोड हार्नेस के माध्यम से उजागर होता है, इसलिए Codex हमारी बातचीत, प्रोजेक्ट संदर्भ और अब तक जो कुछ भी सीखा है, उसे एक स्पष्ट उद्देश्य में संश्लेषित कर सकता है। यह उस उद्देश्य को पूरा मानने से पहले आवश्यक साक्ष्य को भी परिभाषित कर सकता है।
बड़े प्रोजेक्ट के लिए, मैं Codex से व्यापक रोडमैप को GOALS.md में लिखने के लिए कहता हूँ। यह एक अंतर्निहित Codex सुविधा के बजाय एक प्रोजेक्ट परंपरा है, और फ़ाइल का नाम आप जो चाहें रख सकते हैं।
मैं आमतौर पर GOALS.md को एक सपाट कार्य सूची के बजाय माइलस्टोन के आसपास व्यवस्थित करता हूँ। प्रत्येक माइलस्टोन रिकॉर्ड करता है:
- इच्छित परिणाम
- वर्तमान में दायरे में काम
- महत्वपूर्ण निर्णय
- ज्ञात अवरोधक
- आगे बढ़ने से पहले आवश्यक साक्ष्य
Codex प्रोजेक्ट के विकसित होने पर फ़ाइल को बनाए रखता है। नए निष्कर्ष किसी माइलस्टोन के दायरे को बदल सकते हैं, दूसरा पेश कर सकते हैं, या पूरा होने के लिए आवश्यक साक्ष्य को बदल सकते हैं।
एक समय में केवल एक Goal-मोड उद्देश्य सक्रिय होता है। जैसे-जैसे माइलस्टोन पूरे होते हैं, Codex GOALS.md को अपडेट करता है, अगले उद्देश्य को सक्रिय करता है, और उसकी दिशा में काम करना जारी रखता है।
2. मुख्य थ्रेड को समन्वय पर केंद्रित रखें
एक बार रोडमैप मौजूद होने के बाद, मैं मुख्य थ्रेड को उद्देश्य, बाधाओं, निर्णयों और वर्तमान प्रोजेक्ट स्थिति पर केंद्रित रखता हूँ।
यह तय करता है कि आगे क्या होना चाहिए, सीमित कार्यों को सौंपता है, और परिणामों का मूल्यांकन करता है। इसे हर कार्यान्वयन विवरण को ले जाने की आवश्यकता नहीं है।
एक कार्यकर्ता अपरिचित कोड पढ़ने, कई दृष्टिकोण आज़माने, या असफल परीक्षण का पता लगाने में एक घंटा बिता सकता है। समन्वयक को केवल उस जानकारी की आवश्यकता होती है जो व्यापक प्रोजेक्ट को प्रभावित करती है:
- कार्यकर्ता ने क्या सीखा
- क्या बदला
- सहायक साक्ष्य
- आगे क्या होना चाहिए
Codex इस कार्य को subagent को सौंप सकता है या एक अलग थ्रेड बना सकता है। कार्यात्मक रूप से, वे एक ही कार्य कर सकते हैं। मैं एक अलग थ्रेड का उपयोग करता हूँ जब मुझे उम्मीद होती है कि बाद में काम पर फिर से विचार करूँगा, क्योंकि यह Codex ऐप में दिखाई देता रहता है और अपना स्वयं का इतिहास रखता है।
यह विशेष रूप से तब उपयोगी हो जाता है जब कई काम समानांतर में चल रहे हों। मुख्य थ्रेड प्रोजेक्ट का समन्वय जारी रख सकता है जबकि प्रत्येक जाँच, कार्यान्वयन या समीक्षा का निरीक्षण करना आसान रहता है।
3. प्रत्येक माइलस्टोन के बाद रोडमैप का ऑडिट करें और कोड की समीक्षा करें
GOALS.md उस समय जो ज्ञात था उसे दर्शाता है जब Codex ने इसे अंतिम बार अपडेट किया था। माइलस्टोन के अंत तक, प्रोजेक्ट ने आमतौर पर कुछ नया खोजा होता है।
आगे बढ़ने से पहले, मैं दूसरे थ्रेड से रोडमैप की वर्तमान स्थिति से तुलना करने के लिए कहता हूँ:
- क्या माइलस्टोन वास्तव में पूरा हो गया है?
- क्या अगला लक्ष्य अभी भी सही है?
- क्या कोई माइलस्टोन गायब है?
- क्या नए साक्ष्य ने काम के क्रम को बदल दिया है?
- क्या पूर्णता की परिभाषा अभी भी मान्य है?
मैं प्रत्येक माइलस्टोन के अंत में यह ऑडिट चलाता हूँ, साथ ही जब भी नए साक्ष्य प्रोजेक्ट की दिशा को भौतिक रूप से बदलते हैं।
मैं कार्यान्वयन पर /review भी चलाता हूँ।
मान लीजिए कि साइन-इन फ़्लो के लिए कार्यान्वयन और रिमोट परीक्षण पूरे हो गए हैं। रोडमैप ऑडिट देख सकता है कि किसी ने वास्तविक साइन-इन किए गए ब्राउज़र में फ़्लो का परीक्षण नहीं किया है। उसी समय, /review पा सकता है कि नया पथ रिमोट परीक्षण पास होने के बावजूद टोकन को गलत तरीके से संग्रहीत करता है।
समन्वयक GOALS.md को अपडेट करता है, टोकन फिक्स सौंपता है, लापता ब्राउज़र सत्यापन जोड़ता है, और उसके बाद ही अगले माइलस्टोन को सक्रिय करता है।
मैं आमतौर पर ऑडिट और समीक्षाओं को अलग-अलग थ्रेड में रखता हूँ। एक subagent समान कार्य कर सकता है, लेकिन एक अलग थ्रेड एक दृश्य रिकॉर्ड छोड़ता है जिस पर मैं बाद में वापस आ सकता हूँ।
4. कंप्यूटर उपयोग परीक्षण के लिए स्थानीय थ्रेड का उपयोग करें
मेरे अधिकांश Codex सत्र एक रिमोट इंस्टेंस पर चलते हैं, ताकि मेरा लैपटॉप बंद होने पर भी काम जारी रह सके। कुछ जाँचें अभी भी मेरी स्थानीय मशीन पर निर्भर करती हैं:
- एक साइन-इन किया गया ब्राउज़र
- स्थानीय क्रेडेंशियल
- Xcode
- macOS अनुमतियाँ
- iOS सिम्युलेटर
रिमोट समन्वयक उन जाँचों में से एक के लिए एक स्थानीय थ्रेड बना सकता है। मैं रिमोट डिफ लागू करता हूँ या प्रासंगिक ब्रांच या कमिट चेक आउट करता हूँ ताकि स्थानीय थ्रेड सही कोड का परीक्षण करे।
स्थानीय थ्रेड ब्राउज़र या एप्लिकेशन संचालित करता है और स्क्रीनशॉट, लॉग और निष्कर्ष लौटाता है। जब कोई जाँच विफल होती है, तो एक रिमोट वर्कर समस्या को ठीक करता है और स्थानीय थ्रेड फिर से परीक्षण करता है।
एक सामान्य लूप इस तरह दिखता है:
- एक रिमोट वर्कर साइन-इन फ़्लो लागू करता है।
- रिमोट परीक्षण पास होते हैं।
- एक स्थानीय थ्रेड Codex Chrome एक्सटेंशन का उपयोग करता है।
- ब्राउज़र परीक्षण एक रीडायरेक्ट बग का खुलासा करता है।
- एक रिमोट वर्कर इसे ठीक करता है।
- स्थानीय थ्रेड जाँच दोहराता है।
प्रोजेक्ट डिफ़ॉल्ट रूप से रिमोट रहता है। मेरा कंप्यूटर केवल उन जाँचों के लिए जुड़ता है जिनकी आवश्यकता होती है। रिमोट थ्रेड स्थानीय थ्रेड के फिर से उपलब्ध होने की जाँच करता रह सकता है जब मैं अपना लैपटॉप फिर से खोलता हूँ।
5. संक्षिप्त अपडेट और डैशबोर्ड के माध्यम से प्रगति की रिपोर्ट करें
वर्कर थ्रेड आमतौर पर एक कार्य पर रिपोर्ट करते हैं। जब मैं प्रोजेक्ट पर वापस आता हूँ, तो मुझे समग्र स्थिति के दृश्य की आवश्यकता होती है:
- क्या पूरा हो गया है
- क्या बदला
- क्या बाकी है
- किस पर निर्णय की आवश्यकता है
मैं Codex से प्रोजेक्ट स्थिति बदलने पर रिपोर्ट करने के लिए कहता हूँ, तीन छोटे अनुभागों का उपयोग करते हुए:
**क्या हो गया
आगे क्या
कोई अवरोधक**
जो लगभग Codex के साथ दैनिक स्टैंडअप रखने जैसा है, हालांकि प्रति घंटा।
Codex वही अपडेट Slack के माध्यम से भेज सकता है, या तो सीधे संदेश के रूप में या समर्पित प्रोजेक्ट चैनल में।
जब मैं Codex ऐप में होता हूँ, तो मैं मुख्य थ्रेड को बाधित किए बिना जाँच करने के लिए /side का भी उपयोग करता हूँ। साइड थ्रेड से, मैं पूरा हो चुके काम, जो बाकी है, और क्या किसी चीज़ में मेरी मदद की ज़रूरत है—उदाहरण के लिए, मैन्युअल क्लिक, अनुमोदन, या क्लिकऑप्स का एक और टुकड़ा—का सारांश माँग सकता हूँ।
साइड थ्रेड से सारांश प्राप्त करना
साइड थ्रेड से मुख्य थ्रेड को मेरे निर्देश भेजने के लिए कहना
फिर मैं एक निर्देश स्पष्ट कर सकता हूँ, किसी अवरोधक को हल कर सकता हूँ, संदर्भ जोड़ सकता हूँ, या साइड थ्रेड से मुख्य थ्रेड को अद्यतन मार्गदर्शन वापस भेजने के लिए कह सकता हूँ।
कई माइलस्टोन या समानांतर कार्य प्रवाह वाले प्रोजेक्ट के लिए, मैं एक progress-dashboard.html भी बनाए रखता हूँ। यह अंतर्निहित Codex UI के बजाय एक कस्टम प्रोजेक्ट आर्टिफैक्ट है। यह दिखा सकता है:
- सक्रिय लक्ष्य
- पूर्ण किए गए माइलस्टोन
- साक्ष्य
- अवरोधक
- निर्णय
- हाल के अपडेट
जब मैं कई घंटों के बाद वापस आता हूँ, तो मैं हर वर्कर थ्रेड को पढ़े बिना प्रोजेक्ट की स्थिति को समझ सकता हूँ। Codex डैशबोर्ड को एक Site के रूप में भी तैनात कर सकता है ताकि यह दूरस्थ रूप से सुलभ रहे।
सारांश
मैं इस संरचना का उपयोग तब करता हूँ जब किसी प्रोजेक्ट में नई जानकारी सामने आने, कई स्वतंत्र कार्य शामिल होने, या एक से अधिक वातावरण से साक्ष्य की आवश्यकता होने की संभावना हो।
वर्कफ़्लो एक सरल चक्र का अनुसरण करता है। Codex प्रारंभिक बातचीत को एक रोडमैप में बदल देता है, एक माइलस्टोन सक्रिय करता है, काम सौंपता है, और आगे बढ़ने से पहले परिणाम की जाँच करता है। स्थानीय थ्रेड उन जाँचों को संभालते हैं जिनके लिए मेरी मशीन की आवश्यकता होती है, जबकि अपडेट और डैशबोर्ड मुझे सब कुछ शुरू से पुनर्निर्माण किए बिना प्रोजेक्ट पर वापस लौटने में मदद करते हैं।
महत्वपूर्ण हिस्सा प्रोजेक्ट की स्थिति को इतना अद्यतित रखना है कि अगला निर्णय उस चीज़ को प्रतिबिंबित करे जो Codex ने वास्तव में सीखा है।
इसे आज़माएँ
इसे एक नए Codex थ्रेड में पेस्ट करें:
इसे एक लंबे समय तक चलने वाले प्रोजेक्ट के रूप में समन्वयित करें।
मेरा साक्षात्कार करके शुरू करें कि मैं क्या बनाने की कोशिश कर रहा हूँ। मुझे बातचीत के माध्यम से मोटे विचारों और बाधाओं का वर्णन करने दें, फिर उस चर्चा को एक प्रारंभिक योजना में बदल दें।
साझा रोडमैप के रूप में GOALS.md बनाएँ। इसे माइलस्टोन के आसपास व्यवस्थित करें, प्रत्येक के लिए इच्छित परिणाम, दायरा, निर्णय, अवरोधक और आवश्यक साक्ष्य के साथ।
एक समय में एक Goal-मोड उद्देश्य सेट करें और बनाए रखें। सक्रिय उद्देश्य वर्तमान माइलस्टोन के अनुरूप होना चाहिए।
इस थ्रेड को उद्देश्य, बाधाओं, निर्णयों और प्रोजेक्ट स्थिति पर केंद्रित रखें। कार्यान्वयन को subagents या नए थ्रेड को सौंपें।
कार्यकर्ताओं को पूर्ण प्रतिलेखों के बजाय निष्कर्ष, परिवर्तन और साक्ष्य वापस करने की आवश्यकता है।
अलग-अलग थ्रेड का उपयोग करें जब मैं बाद में काम का निरीक्षण, जारी या समीक्षा करना चाह सकता हूँ। बाउंडेड काम के लिए subagents का उपयोग करें जिसे अपने स्वयं के दृश्य इतिहास की आवश्यकता नहीं है।
प्रत्येक माइलस्टोन के बाद, वर्तमान स्थिति के विरुद्ध GOALS.md का ऑडिट करने और कार्यान्वयन पर /review चलाने के लिए एक अलग थ्रेड का उपयोग करें। अगले उद्देश्य को सक्रिय करने से पहले रोडमैप को अपडेट करें।
कंप्यूटर उपयोग परीक्षण के लिए स्थानीय थ्रेड का उपयोग करें जो मेरे ब्राउज़र, डेस्कटॉप एप्लिकेशन, अनुमतियों, क्रेडेंशियल या डिवाइस स्थिति पर निर्भर करता है।
*जब प्रोजेक्ट की स्थिति बदलती है, तो केवल रिपोर्ट करें: - क्या हो गया - आगे क्या - कोई अवरोधक*
progress-dashboard.html बनाए रखें जब प्रोजेक्ट कई माइलस्टोन या कार्यकर्ताओं में फैला हो। सहमत साक्ष्य मौजूद होने तक पूर्णता घोषित न करें।
वैकल्पिक रूप से, आप इस लेख का Appshot भी ले सकते हैं और Codex से पूछ सकते हैं:
इस लेख से orchestrate-projects नामक एक पुन: प्रयोज्य Codex कौशल बनाएँ।
इन प्रथाओं को संरक्षित करें:
*- Codex को मेरा साक्षात्कार करने और प्रारंभिक योजनाएँ बनाने दें - GOALS.md को माइलस्टोन-आधारित रोडमैप के रूप में उपयोग करें - एक समय में एक Goal-मोड उद्देश्य सक्रिय रखें - मुख्य थ्रेड को समन्वय पर केंद्रित रखें - प्रत्येक माइलस्टोन के बाद रोडमैप का ऑडिट करें और /review चलाएँ - उस काम के लिए अलग-अलग थ्रेड का उपयोग करें जिस पर मैं फिर से विचार करना चाह सकता हूँ - कंप्यूटर उपयोग परीक्षण के लिए स्थानीय थ्रेड का उपयोग करें - संक्षिप्त अपडेट, Slack और progress-dashboard.html के माध्यम से प्रगति की रिपोर्ट करें*
