पहला कार्य पूरा करना

📚 सीरीज नेविगेशन: पिछला लेख 05 · DeepSeek जैसे अन्य मॉडल्स को जोड़ना "मॉडल बदलने" के तरीके को स्पष्ट करता है। कॉन्फ़िगरेशन भाग यहाँ समाप्त होता है—यह लेख आपको वास्तविक काम शुरू करना सिखाएगा, Codex से कोड में बदलाव करवाकर, निर्देश देने से लेकर diff देखने तक की पूरी प्रक्रिया को पूरा करना। अगला लेख 07 · डेस्कटॉप ऐप का अवलोकन डेस्कटॉप इंटरफ़ेस के बारे में है।

दोस्तों, बात शुरू करने से पहले मैं अपनी एक बेवकूफी बताता हूँ जो मैंने Codex का उपयोग शुरू करते समय की थी।

वह पहली रात थी जब मैंने Codex CLI इंस्टॉल किया था, और मैं यह देखने के लिए उत्सुक था कि क्या यह कोड बदल सकता है। मैंने सीधे कंपनी की मुख्य रिपॉजिटरी में प्रवेश किया, जो दो साल पुरानी थी और जिसमें सैकड़ों फाइलें थीं, और सीधे निर्देश दिया "यूजर मॉड्यूल को रिफैक्टर करें, यह बहुत बिखरा हुआ है"। Codex ने कुछ सेकंड तक फाइलें पढ़ीं, टर्मिनल पर बहुत सारे लॉग्स दिखे, और उसने एक साथ कई बदलाव कर दिए—जो सात या आठ फाइलों में फैले थे। मैंने सोचा "सब ठीक ही होगा", और बिना ध्यान से देखे 'सहमत' पर क्लिक कर दिया।

नतीजा क्या हुआ? उसने कोड को रिफैक्टर तो किया, लेकिन साथ ही दो ऐसे एपीआई के नियमों को भी बदल दिया जिन्हें मुझे नहीं बदलना था, जिससे सारे टेस्ट फेल होने लगे। मुझे उसके किए गए बदलावों को एक-एक करके ठीक करने और यह समझने में लगभग एक घंटा लगा कि क्या रखना है और क्या हटाना है। उस रात मेरी सबसे बड़ी सीख यह नहीं थी कि "Codex खराब है", बल्कि यह थी कि "मैंने सबसे महत्वपूर्ण काम—diff की जांच करना—छोड़ दिया था।"

सच कहें तो, इस लेख में मैं आपको इसी जांच की आदत के बारे में बताना चाहता हूँ। आज हम बड़े प्रोजेक्ट्स पर काम नहीं करेंगे, बल्कि तीन लाइनों का एक छोटा प्रोजेक्ट बनाएंगे, और पांच मिनट में "निर्देश देना → सैंडबॉक्स में बदलाव → diff देखना → बदलाव रखना या हटाना" की पूरी प्रक्रिया को पूरा करेंगे, ताकि आपको Codex के सही उपयोग का अनुभव हो सके। हम डेस्कटॉप ऐप और CLI दोनों रास्तों को देखेंगे।

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

• टर्मिनल या ऐप खोलने से लेकर पहला कार्य पूरा करने तक की पूरी प्रक्रिया, जिसका आप पालन कर सकते हैं
• "diff की जांच" करने की आदत—जो एक सामान्य उपयोगकर्ता और एक कुशल उपयोगकर्ता के बीच का मुख्य अंतर है
• डेस्कटॉप ऐप और CLI दोनों प्रक्रियाओं की चरण-दर-चरण जानकारी और अपेक्षित आउटपुट
• कुछ उपयोगी सुझाव (जैसे निर्देश अस्वीकार करने के बाद क्या कहें, या गलत बदलाव होने पर वापस कैसे जाएं)

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

---

01 शुरुआत में छोटे प्रोजेक्ट पर काम करें, बड़े प्रोजेक्ट पर नहीं

पहले निष्कर्ष देखते हैं: पहली बार Codex का उपयोग करते समय, कभी भी अपने वास्तविक प्रोजेक्ट पर काम न करें, बल्कि तीन लाइनों का एक छोटा टेस्ट प्रोजेक्ट बनाएं।

क्यों? जैसा कि मैंने ऊपर बताया—वास्तविक प्रोजेक्ट में फाइलें अधिक होती हैं, निर्भरताएं जटिल होती हैं, Codex फाइलों को पढ़ने में समय लेता है, और वह क्या बदल रहा है यह देखना आपके लिए कठिन होता है, जिससे आप बिना सोचे-समझे यस (Yes) चुन सकते हैं। छोटे प्रोजेक्ट में केवल दो-तीन लाइने होती हैं, जिससे आप उसके किए बदलाव को तुरंत देख सकते हैं।

सादृश्य: साइकिल चलाना सीखते समय खाली सड़क चुनना। कोई भी सीधे भारी ट्रैफ़िक वाली सड़क पर नहीं जाता—पहले खाली गली चुनी जाती है, जहाँ गिरने पर चोट न लगे और संतुलन का अभ्यास हो सके। छोटा प्रोजेक्ट वही खाली गली है: यदि कुछ गड़बड़ हुई, तो डिलीट करके दोबारा बनाना केवल तीस सेकंड का काम है।

किसे इस नियम का पालन अवश्य करना चाहिए:

• जिन्होंने पहले कभी कमांड लाइन का उपयोग नहीं किया है—लॉग्स देखकर घबराहट हो सकती है, इसलिए वास्तविक प्रोजेक्ट का तनाव न लें।
• जो दूसरे कोडिंग टूल्स से आ रहे हैं—जैसे यदि आप Claude Code के अभ्यस्त हैं, तो हो सकता है कि Codex का सैंडबॉक्स और अनुमोदन नियम आपकी अपेक्षा से अलग काम करे (जैसा कि लेख 02 और लेख 05 में बताया गया था)।
• जो जल्दी काम पूरा करना चाहते हैं—शुरुआत में एक बार पूरी प्रक्रिया को चलाकर देखना बाद में समय बचाता है।

टर्मिनल खोलें (Mac में Terminal, Windows में PowerShell) और यह डायरेक्टरी बनाएं:

mkdir hello-codex
cd hello-codex

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

अब इसमें एक साधारण Python फ़ाइल बनाएं। Mac / Linux के लिए:

echo 'def add(a, b):
    return a + b' > main.py

Windows PowerShell में: एक नई फ़ाइल main.py बनाएं और उसमें यह कोड लिखकर सहेजें:

def add(a, b):
    return a + b

💡 संक्षेप में: पहली बार Codex का उपयोग करते समय, एक छोटा प्रोजेक्ट बनाएं—ताकि बदलाव स्पष्ट दिखें और कुछ गलत होने पर आसानी से दोबारा शुरू किया जा सके।

---

02 निर्देश स्पष्ट देना: "सोचो→करो→देखो" का चक्र

प्रोजेक्ट तैयार होने के बाद, काम शुरू करने से पहले समझें कि निर्देश कैसे देना है।

Codex कोई जादुई टूल नहीं है—आप जैसा निर्देश देंगे, वैसा ही उत्तर मिलेगा। लेख 02 में बताया गया था कि यह एक एजेंट (Agent) है जो लूप में काम करता है: मॉडल को कॉल करना, फाइलें पढ़ना, बदलना और काम पूरा करना। सरल शब्दों में—सोचो → करो → देखो।

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

• जांच की सुविधा दें: निर्देश में एरर सुधारने के नियम, परीक्षण कमांड्स आदि शामिल करें ताकि Codex खुद काम की पुष्टि कर सके।
• काम को विभाजित करें: बड़े कार्यों को छोटे-छोटे चरणों में बांटें ताकि जांच करना आसान हो; यदि विभाजित करना न आए, तो Codex से कहें कि वह पहले एक योजना (plan) बनाकर दे।

उदाहरण देखें:

❌ अस्पष्ट निर्देश	✅ स्पष्ट निर्देश
"इस फ़ंक्शन को ठीक करें"	"add फ़ंक्शन में टाइप एनोटेशन जोड़ें, और गैर-संख्या इनपुट होने पर TypeError थ्रो करें"
"यह टेस्ट क्यों फेल हो रहा है"	"pytest चलाएं, एरर ढूंढें, ठीक करें और फिर से टेस्ट चलाकर पुष्टि करें"
"प्रोजेक्ट को रिफैक्टर करें"	"अभी बदलाव न करें, पहले रिफैक्टर करने की योजना दिखाएं, पुष्टि के बाद हम काम शुरू करेंगे"

अंतिम लाइन बहुत उपयोगी है—बड़े कार्यों के लिए पहला निर्देश हमेशा यही होना चाहिए: "पहले योजना बताएं, अभी कोड न बदलें"। यह काम को सुरक्षित रखता है।

💡 संक्षेप में: Codex "सोचो→करो→देखो" चक्र में काम करता है, इसलिए स्पष्ट निर्देश और जांच नियम बताएं; बड़े काम के लिए पहले योजना मांगें।

---

03 पहला कार्य: कोड पढ़ना, बदलना नहीं

पहले कार्य के लिए, मैं सुझाव दूंगा कि आप उसे कोड समझाने के लिए कहें, बदलने के लिए नहीं।

इसके दो कारण हैं: पहला, पुष्टि करना कि Codex आपकी फाइलों को पढ़ पा रहा है (नए उपयोगकर्ताओं को अक्सर संदेह होता है कि क्या उसने कोड पढ़ा भी है या नहीं); दूसरा, समझाने वाले कार्य में कोई जोखिम नहीं होता—वह केवल पढ़ता है और बोलता है, कोड में कोई बदलाव नहीं करता।

सादृश्य: नए सहकर्मी का पहला दिन। आप उससे कहेंगे कि "पहले कोड को समझें और मुझे बताएं कि यह क्या करता है"। आप उसे सीधे मुख्य मॉड्यूल बदलने के लिए नहीं कहेंगे।

टर्मिनल या ऐप में टाइप करें:

解释 main.py 这个文件在做什么，用新手能听懂的话说

(कोड ब्लॉक के कारण चीनी प्रॉम्प्ट को ही रहने दें, इसका अर्थ है: "main.py फ़ाइल क्या कर रही है, इसे सरल भाषा में समझाएं")

Codex फ़ाइल को पढ़ेगा—आपको फ़ाइल अलग से अपलोड करने की आवश्यकता नहीं होती, वह खुद डायरेक्टरी से फ़ाइल पढ़ लेता है। वह आपको समझाएगा कि यहाँ एक add फ़ंक्शन है जो दो इनपुट्स a और b लेता है और उनका योग लौटाता है।

इस चरण के सफल होने का अर्थ है: Codex सही से काम कर रहा है, लॉगिन क्रेडेंशियल सही हैं, और वह आपके कंप्यूटर की फाइलों को पढ़ सकता है। अब आप आगे काम करवा सकते हैं।

निर्देशों की तीन श्रेणियां होती हैं:

निर्देश का प्रकार	क्या करता है	उदाहरण	जोखिम
विश्लेषण	कोड समझना और समझाना	"इस कोड का मतलब समझाएं"	कोई जोखिम नहीं, फ़ाइल नहीं बदलती
संशोधन	कोड बदलना	"इस फ़ंक्शन में टाइप एनोटेशन जोड़ें"	फ़ाइल बदलती है, diff जांचना आवश्यक
जनरेशन	नया कोड बनाना	"इसके लिए टेस्ट फ़ाइल बनाएं"	फ़ाइल बनती/बदलती है, diff जांचना आवश्यक

मैं जब भी किसी नए प्रोजेक्ट पर काम शुरू करता हूँ, तो पहला निर्देश हमेशा यही देता हूँ: "प्रोजेक्ट का स्ट्रक्चर समझाएं"। इससे मुझे प्रोजेक्ट समझने में मदद मिलती है।

💡 संक्षेप में: पहला कार्य केवल विश्लेषण का करवाएं—पुष्टि करें कि वह फाइलों को पढ़ पा रहा है, फिर बदलाव करवाएं; संशोधन और जनरेशन के लिए diff की जांच आवश्यक होगी।

---

04 मुख्य कार्य: बदलाव के बाद diff देखना

अब कोडिंग कार्य करवाते हैं। प्रॉम्प्ट में टाइप करें:

给 main.py 里的 add 函数加上类型注解，并补充基本的错误处理

(चीनी प्रॉम्प्ट का अर्थ: "main.py के add फ़ंक्शन में टाइप एनोटेशन और बुनियादी एरर हैंडलिंग जोड़ें")

यहाँ एक महत्वपूर्ण बात समझें—डिफ़ॉल्ट रूप से, प्रोजेक्ट डायरेक्टरी के भीतर फाइलों में बदलाव करते समय Codex आपसे बार-बार अनुमति नहीं मांगता। क्यों? जैसा कि लेख 02 में बताया गया था, डिफ़ॉल्ट अनुमति स्तर (Auto) में वर्कस्पेस डायरेक्टरी के भीतर काम करना सीमा के अंदर आता है, इसलिए वह सीधे बदलाव कर देता है। केवल सीमा से बाहर जाने (जैसे डायरेक्टरी से बाहर की फाइलें बदलना या इंटरनेट कनेक्टिविटी) पर ही वह अनुमति मांगता है। काम करने की प्रक्रिया:

1. संबंधित फ़ाइल खोजना (यहाँ main.py), और सैंडबॉक्स में बदलाव करना
2. बदलावों को diff (अंतर तुलना) के रूप में स्क्रीन पर दिखाना—टर्मिनल में आउटपुट दिखेगा और आप git diff से भी देख सकते हैं
3. आपकी अंतिम समीक्षा: diff देखना, सही होने पर रखना, और सही न होने पर वापस करना (जो हम आगे सीखेंगे)

बदलाव के बाद diff देखना ही सबसे महत्वपूर्ण सुरक्षा जांच है। वह बदलाव करके आपको अंतर दिखाता है, और यदि कुछ गलत हुआ तो आप उसे कमिट (commit) करने से पहले आसानी से रोलबैक कर सकते हैं।

⚠️ git diff के उपयोग के लिए आपका प्रोजेक्ट एक Git रिपॉजिटरी होना चाहिए। यदि git init नहीं चलाया गया है, तो एरर आ सकती है। काम शुरू करने से पहले git status से जांच कर लें। (Codex के टर्मिनल में दिखने वाले diff के लिए Git की आवश्यकता नहीं होती, वह वैसे भी दिखता है।)

सादृश्य: सहकर्मी द्वारा कोड में बदलाव करके आपको दिखाना। उसने कोड बदला है लेकिन अभी मुख्य ब्रांच में मर्ज नहीं किया है—आप कोड देखते हैं, सही होने पर मर्ज करते हैं, और गलत होने पर सुधार के लिए कहते हैं। diff वही रिव्यू प्रोसेस है।

⚠️ यदि आप चाहते हैं कि वह बदलाव करने से पहले भी आपसे पूछे, तो अनुमति मोड को /permissions लिखकर read-only (सिर्फ पढ़ने का मोड) पर सेट करें, या निर्देश में कहें "पहले योजना बताएं"। डिफ़ॉल्ट रूप से वह सीधे बदलाव करके आपको diff दिखाता है।

diff को कैसे समझें

diff में बदलावों को इस प्रकार दिखाया जाता है:

• - से शुरू होने वाली या लाल रंग की लाइनें हटाई गई हैं
• + से शुरू होने वाली या हरे रंग की लाइनें जोड़ी गई हैं
• बिना किसी चिह्न वाली लाइनें संदर्भ के लिए होती हैं

आपका main.py कोड इस प्रकार बदल जाएगा (विशिष्ट कोड थोड़ा अलग हो सकता है):

def add(a: float, b: float) -> float:
    if not isinstance(a, (int, float)) or not isinstance(b, (int, float)):
        raise TypeError("a 和 b 必须是数字")
    return a + b

(चीनी एरर संदेश का अर्थ: "a और b संख्याएं होनी चाहिए")

diff देखते समय तीन बातें जांचें:

1. क्या उसने केवल उसी फ़ाइल को बदला है जिसके लिए कहा गया था?
2. क्या नया कोड सही और सुरक्षित लग रहा है?
3. क्या उसने कोई ऐसा कोड डिलीट तो नहीं कर दिया जिसे रखना आवश्यक था?

यदि सब सही है तो रखें, और यदि नहीं तो उससे बदलाव सुधारने के लिए कहें या रोलबैक करें। diff की जांच में केवल कुछ सेकंड लगते हैं, लेकिन यह बहुत महत्वपूर्ण है।

अनुमति संदेश कब दिखाई देता है

डिफ़ॉल्ट रूप से, प्रोजेक्ट के भीतर फ़ाइल बदलने पर कोई अनुमति प्रॉम्प्ट नहीं आता, वह बदलाव करके diff दिखाता है। अनुमति का प्रॉम्प्ट केवल तभी आता है जब वह कोई ऐसा कार्य करने की कोशिश करे जो सैंडबॉक्स की सीमा से बाहर हो—जैसे:

Codex का कार्य	डिफ़ॉल्ट अनुमति स्तर (Auto)	व्यवहार
प्रोजेक्ट डायरेक्टरी में फ़ाइल बदलना	सीधे करेगा, बिना पूछे	diff दिखाएगा
प्रोजेक्ट डायरेक्टरी में कमांड (जैसे टेस्ट) चलाना	सीधे करेगा, बिना पूछे	परिणाम दिखाएगा
सीमा से बाहर का कार्य (जैसे पैकेज इंस्टॉल करना)	अनुमति मांगेगा	Yes / No पूछेगा
प्रोजेक्ट डायरेक्टरी से बाहर की फाइलें बदलना, या इंटरनेट पहुंच	अनुमति मांगेगा	Yes / No पूछेगा

जब भी Yes / No का प्रॉम्प्ट आए, तो समझकर निर्णय लें।

नए उपयोगकर्ताओं के लिए एक नियम: शुरुआत में अनुमतियों को पूरी तरह ढीला न करें (जैसे never या पूर्ण पहुंच सेट करना)। यदि आप अनुमतियाँ पूरी तरह खोल देंगे, तो वह बिना पूछे बाहर के बदलाव भी कर देगा, और यदि कोड में कोई गड़बड़ी हुई तो उसे ठीक करना बहुत कठिन हो जाएगा। हमेशा सीमा को नियंत्रण में रखें।

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

---

05 अस्वीकार करने का मतलब कार्य रोकना नहीं है: निर्देश सुधारें

कई लोग सोचते हैं कि यदि उन्होंने Yes / No प्रॉम्प्ट में No चुन लिया या निर्देश अस्वीकार कर दिया, तो काम शुरू से करना होगा। ऐसा नहीं है। यह केवल निर्देश को सुधारने का एक अवसर है।

Codex एक सत्र/थ्रेड (Thread) में काम करता है—जिसमें पुरानी बातें सुरक्षित रहती हैं। यदि उसने कोई गलत बदलाव किया है, तो आप उसी सत्र में उसे सुधारने के लिए कह सकते हैं।

सादृश्य: रेस्टोरेंट में ऑर्डर बदलना। यदि खाना सही नहीं बना है, तो आप वेटर से कहते हैं कि "यह सही नहीं है, इसे थोड़ा कम तीखा करके दोबारा लाएं"। आपको रेस्टोरेंट बदलने की आवश्यकता नहीं होती।

उदाहरण के लिए: यदि उसने कोड बदलते समय कोई ऐसा पैकेज इम्पोर्ट कर लिया जो आपके सिस्टम में नहीं है, तो आप No चुनकर कह सकते हैं:

别引第三方库，用 Python 标准库 functools.lru_cache 实现就行

(चीनी प्रॉम्प्ट का अर्थ: "बाहरी लाइब्रेरी इम्पोर्ट न करें, पाइथन की इनबिल्ट functools.lru_cache का उपयोग करें")

वह तुरंत पुरानी योजना को बदलकर नई योजना दिखाएगा, और सही होने पर आप अनुमति दे सकते हैं। इसके लिए सत्र से बाहर आने या दोबारा समझाने की आवश्यकता नहीं होती।

❌ गलत धारणा	✅ सही तरीका
अस्वीकार करने पर काम शुरू से करना होगा	अस्वीकार करना केवल निर्देश सुधारने का अवसर है
कोड गलत होने पर खुद ठीक करना होगा	उसे बताएं कि क्या गलत है, वह खुद ठीक करेगा
एरर आने पर सत्र बंद करना होगा	एक ही सत्र में बातचीत जारी रखें

💡 संक्षेप में: diff सही न होने पर घबराएं नहीं—उसी सत्र में Codex को बताएं कि क्या सुधारना है, वह उसे ठीक कर देगा।

---

06 गलतियाँ होने पर रोलबैक: Git है अंतिम विकल्प

यदि आपने बिना ध्यान से देखे बदलावों को यस (Yes) कर दिया और कोड बदल गया—तो क्या करें? कोई समस्या नहीं है, यदि आपने Git कमिट किया हुआ था।

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

सादृश्य: गेम का सेव पॉइंट। आप गेम खेलने से पहले सेव करते हैं, और हारने पर वहीं से दोबारा शुरू करते हैं। git commit वही सेव पॉइंट है।

प्रक्रिया: काम शुरू करने से पहले प्रोजेक्ट फोल्डर में चलाएं (केवल पहली बार git init आवश्यक है):

git init
git add -A && git commit -m "codex 动手前的存档点"

यदि बदलावों में कोई बड़ी गड़बड़ी हो गई है और आप पुराने कोड पर वापस जाना चाहते हैं:

git restore .

(कमांड को मूल रूप में रहने दें)

⚠️ git restore . उन सभी बदलावों को डिलीट कर देगा जो कमिट नहीं हुए थे। इसका उपयोग तभी करें जब आप पूरे बदलावों को हटाना चाहते हों।

यदि केवल कुछ बारीक सुधार करने हैं, तो आप बातचीत में भी कह सकते हैं:

刚才那次改动我不满意，帮我退回到改之前的样子

(चीनी प्रॉम्प्ट का अर्थ: "पिछला बदलाव सही नहीं था, पुराने कोड पर वापस जाएं")

दोनों विकल्पों की तुलना:

रोलबैक तरीका	कैसे करें	कब उपयोग करें	सीमा
बातचीत में कहना	Codex से सीधे कहें	छोटे और हाल के बदलावों के लिए	उसके समझने पर निर्भर
Git रोलबैक	git restore .	जब पूरी तरह से पुराने कोड पर वापस जाना हो	पहले कमिट किया होना आवश्यक है

मेरी आदत है: Codex से काम करवाने से पहले हमेशा git commit करना। यह कोडिंग को पूरी तरह सुरक्षित रखता है।

💡 संक्षेप में: कोडिंग में गड़बड़ी होने पर—पहले git commit करें, और आवश्यकता होने पर git restore . से रोलबैक करें; छोटे सुधारों के लिए बातचीत में भी कह सकते हैं।

---

07 अभ्यास 1: CLI में पूरे कार्य को चलाना

अब हम इस पूरी प्रक्रिया को CLI में चलाकर देखेंगे। टर्मिनल खोलें और इन चरणों का पालन करें:

पहला कदम: टेस्ट प्रोजेक्ट बनाना और Git कमिट करना (Mac / Linux)

mkdir hello-codex && cd hello-codex
echo 'def add(a, b):
    return a + b' > main.py
git init && git add -A && git commit -m "初始版本"

विंडोज़ के लिए: PowerShell खोलें, कमांड्स रन करें, और main.py को नोटपैड से बनाकर कोड सेव करें।

अपेक्षित परिणाम: hello-codex डायरेक्टरी में main.py फ़ाइल बनेगी और पहला Git कमिट पूरा होगा।

दूसरा चरण: डायरेक्टरी में Codex शुरू करना

codex

अपेक्षित परिणाम: Codex इंटरफ़ेस खुलेगा और इनपुट बॉक्स दिखाई देगा। यदि लॉगिन के लिए कहे, तो लॉगिन पूरा करें।

⚠️ हमेशा प्रोजेक्ट फोल्डर में जाकर ही codex कमांड चलाएं, डेस्कटॉप पर सीधे नहीं। Codex वर्तमान डायरेक्टरी को ही वर्कस्पेस मानता है और वहीं काम करता है।

तीसरा चरण: कोड समझाने के लिए कहना

解释 main.py 这个文件在做什么，用新手能听懂的话说

(चीनी प्रॉम्प्ट का अर्थ: "main.py फ़ाइल क्या कर रही है, सरल भाषा में समझाएं")

अपेक्षित परिणाम: Codex फ़ाइल को पढ़ेगा और आपको add फ़ंक्शन के बारे में समझाएगा। इसका अर्थ है कि वह फाइलों को पढ़ पा रहा है।

चौथा चरण: बदलाव करवाना और diff देखना

给 main.py 里的 add 函数加上类型注解，并补充基本的错误处理

(चीनी प्रॉम्प्ट का अर्थ: "add फ़ंक्शन में टाइप एनोटेशन और बुनियादी एरर हैंडलिंग जोड़ें")

अपेक्षित परिणाम: Codex फ़ाइल में बदलाव करेगा और बदलावों को diff (लाल और हरे रंग में) के रूप में टर्मिनल में दिखाएगा। diff की जांच करें।

पांचवां चरण: टर्मिनल में बदलावों की पुष्टि

Codex से बाहर आएं (इसके लिए Ctrl + C दबाएं या /exit टाइप करें), और टर्मिनल में फ़ाइल की जांच करें:

cat main.py

(विंडोज़ में type main.py चलाएं)

अपेक्षित परिणाम: फ़ाइल में बदलाव सुरक्षित मिलेंगे।

Git के माध्यम से भी बदलाव देख सकते हैं:

git diff

अपेक्षित परिणाम: टर्मिनल में Git diff दिखाई देगा जो Codex में दिखे diff के समान होगा।

💡 संक्षेप में: CLI में चलाने के लिए—प्रोजेक्ट डायरेक्टरी में Git कमिट करें → codex शुरू करें → विश्लेषण करवाएं → बदलाव करवाकर diff देखें → टर्मिनल में पुष्टि करें।

---

08 अभ्यास 2: डेस्कटॉप ऐप में काम करना

डेस्कटॉप ऐप में भी यही प्रक्रिया बिंदु-दर-बिंदु होती है (यह Mac और Windows के लिए है, Linux उपयोगकर्ता CLI का उपयोग करें)।

प्रक्रिया:

1. Codex App खोलें, लॉगिन करें (ChatGPT अकाउंट या API key से)।
2. प्रोजेक्ट फोल्डर चुनें—वही hello-codex फोल्डर चुनें जिसे हमने ऊपर बनाया था।
3. Local की पुष्टि करें—संदेश भेजने से पहले सुनिश्चित करें कि Local विकल्प चुना गया है ताकि काम आपके कंप्यूटर पर ही हो।
4. निर्देश दें—इनपुट बॉक्स में टाइप करें:

解释 main.py 这个文件在做什么，用新手能听懂的话说

विश्लेषण के बाद बदलाव का निर्देश दें:

给 main.py 里的 add 函数加上类型注解，并补充基本的错误处理

अपेक्षित परिणाम: Codex फ़ाइल में बदलाव करेगा और समीक्षा पैनल (review pane) में आपको diff दिखाएगा। यह ऐप का सबसे अच्छा हिस्सा है—ग्राफिकल इंटरफ़ेस में diff अधिक स्पष्ट दिखता है, और बगल में सेव, रोलबैक आदि के बटन होते हैं। सही होने पर आप वहां से कमिट कर सकते हैं, और गलत होने पर हटा सकते हैं।

दोनों माध्यमों की तुलना:

विशेषता	CLI (कमांड लाइन)	डेस्कटॉप ऐप
प्लेटफॉर्म	✅ Mac / Windows / Linux सभी में	❌ केवल Mac / Windows
जटिलता	कमांड लिखनी होती है	✅ केवल क्लिक करना होता है, आसान
diff देखना	टर्मिनल में टेक्स्ट diff	✅ ग्राफिकल पैनल, अधिक स्पष्ट
मल्टी-टास्किंग	कई टर्मिनल विंडो खोलने होंगे	✅ ऐप में आसानी से प्रोजेक्ट्स बदल सकते हैं
प्रक्रिया	निर्देश → बदलाव → diff जांच	दोनों में बिल्कुल समान

मेरा सुझाव: मैं कोडिंग के समय CLI का उपयोग करता हूँ (तेज़ और आसान होने के कारण); लेकिन जब बदलाव बहुत बड़े और diff लंबी होती है, तब मैं ऐप का उपयोग करता हूँ क्योंकि ग्राफिकल इंटरफ़ेस में कोड देखना आसान होता है।

💡 संक्षेप में: डेस्कटॉप ऐप में काम आसान होता है (केवल Mac/Windows पर), Local चुनना न भूलें; ग्राफिकल पैनल में diff देखना और कमिट करना आसान होता है, लेकिन मूल नियम CLI के समान ही हैं।

---

09 पूरी प्रक्रिया का आरेख

पूरे चक्र को एक आरेख के माध्यम से समझें:

इसमें सबसे महत्वपूर्ण diff की जांच है: जब बदलाव हो जाएं, तो अंतर देखें—सही होने पर Git कमिट करें, और गलत होने पर सुधार करवाएं या रोलबैक करें।

💡 संक्षेप में: पहला कार्य पूरा करने के लिए—निर्देश दें → Codex बदलाव करेगा → diff देखें → सही होने पर कमिट करें या गलत होने पर रोलबैक करें; diff की जांच आदत बना लें।

---

10 सारांश

इस लेख में हमने Codex के माध्यम से पहला कार्य पूरा किया:

चरण	क्रिया	मुख्य बिंदु
प्रोजेक्ट बनाना	डायरेक्टरी बनाना + Git कमिट	अभ्यास के लिए छोटा प्रोजेक्ट चुनें, काम से पहले सेव करें
निर्देश देना	सरल और स्पष्ट भाषा में	बड़े काम के लिए पहले योजना मांगें
विश्लेषण	"main.py समझाएं"	कोई जोखिम नहीं, फ़ाइल पहुंच की पुष्टि
संशोधन	"टाइप एनोटेशन जोड़ें..."	सीधे बदलाव करके diff दिखाएगा, पुष्टि करें
diff जांच	तीन बातें देखें: फ़ाइल, कोड और पुरानी चीजें	सबसे महत्वपूर्ण चरण, अनदेखा न करें
रोलबैक	Codex से कहना या git restore	Git सुरक्षा का अंतिम साधन है

यह बुनियादी चक्र—निर्देश देना → diff देखना → स्वीकार या अस्वीकार करना—आगे के सभी कार्यों का आधार है। बाकी सभी सुविधाएं इसी चक्र के ऊपर काम करती हैं। diff की जांच को कभी न भूलें।

---

अगले लेख 07 · डेस्कटॉप ऐप का अवलोकन में हम डेस्कटॉप ऐप की सभी सुविधाओं को विस्तार से समझेंगे: मल्टी-प्रोजेक्ट मैनेजमेंट, worktree अलगाव, इनबिल्ट ब्राउज़र और ऑटोमेशन टास्क आदि।

---

अनुशंसित पठन

• गैर-इंटरैक्टिव मोड codex exec: स्क्रिप्ट में Codex चलाना
• क्लाउड Codex Cloud: क्लाउड पर काम सौंपना
• कमांड लाइन CLI का उपयोग