लोग अक्सर मेरे पास आकर पूछते हैं, "क्या Codex यह कर सकता है?"
फिर वे अगले दो या तीन मिनट यह समझाने में बिता देते हैं कि वास्तव में "यह" क्या है: वे किस समस्या को हल करना चाहते हैं, एप्लिकेशन को क्या करना चाहिए, और एक अच्छा परिणाम कैसा दिखेगा। कभी-कभी वे बताते हैं कि उन्होंने पहले से क्या प्रयास किया है, क्या काम किया, और क्या नहीं।
और मैं सोच रहा हूँ: आपको यह सब वास्तव में Codex से ही कह देना चाहिए।
वह पूरा स्पष्टीकरण पहले से ही प्रॉम्प्ट था।
प्रॉम्प्ट इंजीनियरिंग मर चुकी है। और मरी नहीं है।
अगर प्रॉम्प्ट इंजीनियरिंग का मतलब मदद माँगने से पहले एक गुप्त भाषा सीखना है, तो मुझे लगता है कि यह ज़्यादातर मर चुकी है। खासकर रीज़निंग मॉडल के साथ, आमतौर पर कोई जादुई कीवर्ड नहीं होता जो सही उत्तर को अनलॉक कर दे। मुझे नहीं लगता कि आपको सही प्रॉम्प्ट बनाने के लिए एक खाली स्क्रीन पर घंटों घूरते रहना चाहिए।
लेकिन यह पूरी तरह से मरी भी नहीं है, क्योंकि स्पष्टता अभी भी मायने रखती है। अस्पष्टता Codex के लिए काम को कठिन बना देती है, ठीक वैसे ही जैसे किसी और के लिए। अगर मैं इस लेख के पैराग्राफ को बिखेर दूं या ऐसी भाषा में बदल दूं जो आप समझते नहीं हैं, तो इसे समझना मुश्किल हो जाएगा। काल भी मायने रखता है: "मैंने यह कोशिश की" और "मैं चाहता हूँ कि तुम यह कोशिश करो" एक जैसी बात नहीं है।
आप वास्तव में क्या चाहते हैं? कौन सा संदर्भ मायने रखता है? Codex को किन सीमाओं के बारे में पता होना चाहिए? एक अच्छा परिणाम कैसा दिखेगा?
Codex से उसी तरह बात करें जैसे आप किसी ऐसे व्यक्ति से बात करेंगे जिसके साथ आप काम कर रहे हैं।
मैं परिणाम से शुरू करना पसंद करता हूँ: मेरा लक्ष्य क्या है? एजेंट के साथ यही बड़ा बदलाव भी है। हर कदम को स्क्रिप्ट करने और हर मध्यवर्ती आउटपुट के लिए पूछने के बजाय, मैं समझा सकता हूँ कि मैं क्या हासिल करना चाहता हूँ, सीमाएँ निर्धारित कर सकता हूँ, और Codex को रास्ता खोजने में मदद करने दे सकता हूँ।
गड़बड़ वाला संस्करण कहें
ज़्यादातर विचार साफ-सुथरे विनिर्देशों के रूप में नहीं आते। वे कुछ इस तरह सुनाई देते हैं:
"ठीक है, मेरे पास ये सारी फ़ाइलें हैं। फ़ॉर्मेट थोड़े अलग हैं। मुझे शुक्रवार तक एक रिपोर्ट चाहिए। मुझे लगता है कि ज़्यादातर डेटा मौजूद है, लेकिन यह एक एक्सपोर्ट थोड़ा अजीब है..."
यह ठीक है। बस इसे कहें।
जब आप बकबक करते हैं, तो आप अक्सर Codex को अधिक संकेत देते हैं। आप उस विवरण का उल्लेख करते हैं जिसे आपने पॉलिश किए गए प्रॉम्प्ट से हटा दिया होता। आप बीच में अपना मन बदल लेते हैं। आप कहते हैं, "असल में, नहीं, मुझे वह नहीं चाहिए।"
अपना मन बदलने से पता चलता है कि आप क्या नहीं चाहते। एक चक्कर एक छिपी हुई बाधा को प्रकट कर सकता है। ज़ोर से सोचने से आपको और Codex दोनों को कार्य को समझने में मदद मिलती है।
वॉइस डिक्टेशन के साथ, आप माइक्रोफ़ोन दबाते हैं, ब्रीफ़ के बारे में बात करते हैं, ट्रांसक्रिप्ट की जाँच करते हैं, और इसे भेज देते हैं।
अगर यह आपके सेटअप में उपलब्ध है, तो वॉइस मोड और आगे जाता है। आप फ़ॉलो-अप कर सकते हैं, बीच में टोक सकते हैं, दिशा बदल सकते हैं, या सोच का एक नया सूत्र उठा सकते हैं। आप इसका उपयोग कार्यों में समन्वय स्थापित करने के लिए भी कर सकते हैं: कोई दूसरा कार्य शुरू करें, किसी मौजूदा कार्य की जाँच करें, पूछें कि क्या अटका हुआ है, या पहले से चल रहे कार्य को निर्देशित करें।
मैं ईमानदार रहूँगा: कंप्यूटर से बात करना अभी भी थोड़ा अजीब लगता है। ऑफ़िस में, मैं अपने हाथ में एक DJI माइक पकड़ता हूँ। हेडफ़ोन जिसमें माइक्रोफ़ोन हो, वे भी काम करते हैं।
लेकिन यह एक अच्छे विचार को आपके दिमाग में फँसा रहने देने से बेहतर है, सिर्फ इसलिए कि आपको इसे लिखने का सही तरीका नहीं मिला है।
हास्यास्पद सवाल पूछें
इसका एक परिचित मीम संस्करण है:
"Codex, मेरे लिए एक अरब डॉलर का B2B SaaS बना दो। कोई गलती मत करना। एक ही बार में कर दो।"
आप एक ही बार में अरब डॉलर की कंपनी नहीं बना सकते। लेकिन बातचीत कुछ वास्तविक उजागर कर सकती है: एक ऐसी समस्या जिसे आप समझते हैं, कोई जिसे वह समस्या है, और एक पहला कदम जो उठाने लायक है। यह अच्छी पुरानी समस्या-समाधान है: एक जटिल समस्या को छोटे, प्राप्त करने योग्य चरणों में तोड़ना।
मूल्य स्वयं बातचीत में है। यह आपको एक हास्यास्पद सवाल से कुछ ऐसा ले जा सकती है जिसे आप आज ही शिप कर सकते हैं।
शुरू करने के कुछ व्यावहारिक तरीके
अगर विचार अभी भी धुंधला है, तो Codex से आपका इंटरव्यू लेने के लिए कहें:
"मैं अभी भी इसे समझ रहा हूँ। मुझसे एक बार में एक सवाल पूछो। किसी भी अस्पष्ट चीज़ पर दबाव डालो, फिर इसे कुछ ठोस में बदलने में मेरी मदद करो।"
या बहुत सीधे रहें:
- मेरे अंधे धब्बे क्या हैं?
- क्या चीज़ इसे विफल कर सकती है?
- मैं किस बारे में बहुत ज़्यादा सोच रहा हूँ?
- सबसे छोटा उपयोगी संस्करण क्या है?
- शुरू करने से पहले आपको क्या जानने की ज़रूरत है?
Codex का प्लान मोड तब उपयोगी होता है जब आप अधिक संरचना चाहते हैं। यह स्पष्ट करने वाले प्रश्न पूछ सकता है, विकल्प पेश कर सकता है, और कार्यान्वयन से पहले एक दृष्टिकोण पर काम कर सकता है।
लेकिन मुझे नहीं लगता कि हर विचार को वहाँ से शुरू करने की ज़रूरत है। कभी-कभी एक खुली बातचीत बेहतर बहती है। हम एक सहकर्मी के साथ हर बातचीत को योजना और निष्पादन में विभाजित नहीं करते हैं। पहले बात करें। समस्या के आकार को उभरने दें। जब काम को इसकी ज़रूरत हो तो एक योजना में आगे बढ़ें।
Codex के बारे में Codex से पूछें
"Codex से बात करने" का एक दूसरा अर्थ भी है: उससे अपने बारे में सवाल पूछें।
पूछें कि वह क्या देख सकता है। पूछें कि कौन सा मोड समझ में आता है। पूछें कि कौन से उपकरण उपलब्ध हैं। पूछें कि वह अपने काम को सत्यापित करने की योजना कैसे बनाता है।
अगर OpenAI Docs स्किल उपलब्ध है, तो Codex से दस्तावेज़ीकरण की जाँच करने के लिए कहें। आप सार्वजनिक Codex रिपॉजिटरी का निरीक्षण भी कर सकते हैं, या इसे क्लोन करके Codex से पूछ सकते हैं कि यह कैसे काम करता है।
अगर Codex निशाने से चूक जाए, तो पूछें क्यों
"तुमने यह किया, लेकिन मैं वास्तव में वह चाहता था। हम कहाँ गलत हो गए?"
हो सकता है कि आपका अनुरोध अस्पष्ट था। हो सकता है कि किसी AGENTS.md फ़ाइल या स्किल ने काम को अलग दिशा में खींच लिया हो। हो सकता है कि कोई प्लगइन, अनुमति या उपकरण उपलब्ध न हो। हो सकता है कि Codex ने कोई गलत धारणा बना ली हो।
पूछें कि उसने क्या समझा, उसने किन निर्देशों का पालन किया, क्या विफल रहा, और आप क्या और स्पष्ट कर सकते थे। Codex अक्सर अभी भी उपलब्ध संदर्भ का उपयोग करके सहयोग का ऑडिट करने में मदद कर सकता है।
जहाँ उपलब्ध हो, आप Codex के चलने के दौरान /side के साथ एक साइड चैट खोल सकते हैं, बिना मुख्य चैट को बाधित किए। पूछें कि क्या हो गया है, क्या बाकी है, क्या अटका हुआ है, और आप कैसे मदद कर सकते हैं। आप मूल रूप से स्टैंडअप पर उसके मैनेजर हैं।
अगर आप चाहते हैं कि कुछ सरल भाषा में समझाया जाए, तो ट्रांसक्रिप्ट में टेक्स्ट चुनें और "साइड चैट में पूछें" चुनें।
विचार को अपने दिमाग से बाहर निकालें
एक रोड ट्रिप पर, मैंने एक प्रेजेंटेशन के बारे में Codex से बात करना शुरू किया। वह बातचीत इस टॉक और इस लेख की संरचना बन गई। मैंने मोटे-मोटे विचार के बारे में बात की, कुछ बार अपना मन बदला, और चलता रहा।
अक्सर सबसे बड़ी बाधा मॉडल नहीं होती। यह हम होते हैं। हमें लगता है कि विचार तैयार नहीं है। हम सही प्रॉम्प्ट नहीं जानते। हमें चिंता है कि हमने इसे ठीक से समझाया नहीं है।
इंटरफ़ेस बेहतर होता जाएगा। और अगर आपके पास विचार हैं कि Codex से बात करना कैसा लगना चाहिए, तो मुझे वास्तव में उन्हें सुनना अच्छा लगेगा।
बस Codex से पूछें।
