Claude Case Studies से 2026 Edition के नए अपडेट्स को समझना
12 अक्टूबर, 2026 को अपडेट किया गया
जेनरेटिव AI का इस्तेमाल करने से टेक्स्ट लिखने, मटीरियल खोजने और काम करने वाले प्रोटोटाइप बनाने के लिए कोडिंग करने में लगने वाला समय काफी कम हो जाता है।
तो, इस बचे हुए समय का आप क्या करते हैं?
Yoichi Ochiai के पब्लिक case studies पर नज़र रखने से पता चलता है कि AI से आउटपुट मिलने के बाद उनके काम करने का एक खास पैटर्न होता है। वे रिसर्च किए गए कंटेंट को दूसरे डॉक्यूमेंट्स से क्रॉस-चेक करते हैं। अलग-अलग ऑडियंस के हिसाब से एक्सप्लेनेशन को दोबारा लिखते हैं। अगर कोई ज़रूरी टूल नहीं मिलता, तो वे अपने काम के हिसाब से उसे खुद बना लेते हैं। और वे लगातार इन टूल्स को इस्तेमाल करने के तरीके को बेहतर बनाते रहते हैं।
एक काम जल्दी पूरा होने से उन्हें अगले iteration की तरफ बढ़ने का मौका मिलता है। iterations के दौरान मिली गलतियों को सुधारने से उनका अगला काम करने का तरीका बदल जाता है।
हम इस जमा होते जाने वाले अनुभव को "मेहनत की रफ़्तार (rotation speed) बढ़ाना" कहते हैं।
"Genius of effort" और "rotation speed of effort" जैसे शब्दों का इस्तेमाल यहाँ पब्लिक case studies को समझाने के लिए किया गया है; ये Ochiai द्वारा दिए गए नाम नहीं हैं। हम पहले उनके तरीकों को जानेंगे और फिर देखेंगे कि उन्हें अपने काम में कैसे शामिल किया जा सकता है।
यह आर्टिकल खास तौर पर Claude और Claude Code पर केंद्रित है। हम ऐसे यूसेज पैटर्न देख रहे हैं जो सिर्फ टेक्स्ट जनरेट करने तक सीमित नहीं हैं, बल्कि इनमें रिसर्च के कामों को बाँटना, डिलिवरेबल्स बनाना और रिजल्ट्स को वेरिफाई करना भी शामिल है।
1. सितंबर 2026 में, उन्होंने Claude Code के साथ छह रिसर्च एजेंट चलाए
आइए एक खास उदाहरण से शुरुआत करते हैं।
7 सितंबर, 2026 के अपने पर्सनल नोट में, Ochiai बताते हैं कि उन्होंने 6 सितंबर को Claude Code का इस्तेमाल करके एक साथ छह रिसर्च एजेंट चलाए थे। इनमें null², प्रदर्शनियां, शिक्षा जगत, कॉर्पोरेट गतिविधियां, पब्लिकेशन/मीडिया और सरकारी दफ्तर शामिल थे। हर दावे को URL, वेरिफिकेशन की तारीख और स्टेटस के साथ टैग किया गया, उनकी CV और पोर्टफोलियो से क्रॉस-चेक किया गया, और 14 मुख्य बिंदुओं को एक अलग वेरिफिकेशन एजेंट ने दोबारा चेक किया। note.com
इसका मकसद एक ऐसा आर्टिकल तैयार करना था जो बताए कि वे कौन हैं।
कोई सोच सकता है कि इंसान खुद को सबसे अच्छी तरह जानता है। लेकिन जब काम रिसर्च, कलाकृतियों, कंपनियों और पब्लिकेशन्स में फैला हो, तो टाइमलाइन, मौजूदा पदों और पब्लिक रिकॉर्ड को व्यवस्थित करना एक बड़ा काम बन जाता है।
यहाँ सीख यह है कि एक ही रिक्वेस्ट के अंदर रिसर्च के क्षेत्रों को बाँट लें और स्कोप व वेरिफिकेशन स्टेटस को साफ़ दिखाएं।
सिर्फ यह पूछना कि "मेरे बारे में एक विस्तृत आर्टिकल लिखो" यह देखना मुश्किल बना देता है कि क्या वेरिफाई हुआ है और क्या नहीं। क्षेत्रों को बाँटने से कमियां पकड़ना आसान हो जाता है, जैसे "रिसर्च तो कवर हो गई, लेकिन कॉर्पोरेट कामों को चेक करना बाकी है।"
यही बात आम बिज़नेस पर भी लागू होती है।
कंपनी प्रोफाइल के लिए बुनियादी जानकारी, सर्विसेज, case studies और एग्जीक्यूटिव बायो को अलग-अलग रखें। नए बिज़नेस की प्लानिंग के लिए कस्टमर की समस्याओं, मौजूदा सर्विसेज, लागू करने के कदमों और खर्चों को अलग करें।
साथ ही यह भी तय करें कि हर एजेंट क्या डिलीवर करेगा। सबूतों से जुड़े तथ्य मिलना, सिर्फ लंबे पैराग्राफ पढ़ने से कहीं ज्यादा आसानी से वेरिफाई किया जा सकता है।
काम सौंपने की इकाई और रिजल्ट के फॉर्मेट दोनों को डिज़ाइन करें। Claude Code का असरदार इस्तेमाल करने के लिए यह तैयारी बहुत ज़रूरी है।
ध्यान दें: Claude Code में कई एजेंट चलाना किसी चैटबॉट से "छह विशेषज्ञों की तरह काम करो" कहने से अलग है। दूसरा तरीका स्वतंत्र रूप से रिसर्च नहीं करता। काम के असली बँटवारे को एग्जीक्यूशन लॉग और आउटपुट के ज़रिए चेक करें। सब-एजेंट के काम करने के तरीके को Claude Code की आधिकारिक डॉक्स में समझाया गया है। Claude Code Docs
2. AI का इस्तेमाल बढ़ने पर इंसान के पास मौजूद मटीरियल और भी ज़रूरी हो जाते हैं
AI से विस्तृत जानकारी माँगने से पहले सोचें कि आप कौन से तथ्य उसे दे सकते हैं।
उदाहरण: किसी ट्रेनिंग सर्विस का प्रोफाइल अपडेट करना। पुरानी बायो में "50 क्लाइंट" लिखा है, नई सेल्स डेक में "70", और वेबसाइट छह महीने से अपडेट नहीं हुई है।
अगर AI सिर्फ सर्च करेगा, तो वह तय नहीं कर पाएगा कि कौन सा नंबर सही है। हो सकता है नए पेजों में गिनती का तरीका ही अलग हो।
आपको अपने रिकॉर्ड से पक्की जानकारी चाहिए, जैसे ऑर्डर लॉग या डिलीवरी हिस्ट्री।
आपका काम सब कुछ याद रखना नहीं है, बल्कि यह बताना है कि कौन सा डॉक्यूमेंट मान्य है और उसमें क्या गिना गया है।
मटीरियल को इस तरह व्यवस्थित करें:
मटीरियल | AI को क्या बताएं |
|---|---|
कंपनी की आधिकारिक जानकारी | कानूनी नाम, लागू होने की तारीख, लिखने के नियम |
लेनदेन के रिकॉर्ड | गिनती का दायरा, क्या शामिल नहीं है, डुप्लीकेट को कैसे संभालना है |
पब्लिक वेबसाइट/बायो | मौजूदा शब्दावली, वे हिस्से जिन्हें अपडेट करना है |
पुराने डॉक्यूमेंट | ऐतिहासिक डेटा के तौर पर संदर्भ की सीमा |
पर्सनल नोट्स | तथ्य, याददाश्त, उम्मीद और अनुमान में फर्क करें |
अगर डॉक्यूमेंट्स में विरोधाभास है, तो AI को अपनी मर्जी का डॉक्यूमेंट न चुनने दें। उससे कहें कि वह मतभेदों को हाइलाइट करे।
"मुझे कौन सा नंबर इस्तेमाल करना चाहिए?" पूछने के बजाय पूछें, "उपलब्ध डेटा के आधार पर दिखाओ कि हर सोर्स ने क्या गिना है।" इससे फैसला लेने के लिए बेहतर जानकारी मिलती है।
सिर्फ प्रॉम्प्ट के शब्द इनपुट की क्वालिटी तय नहीं करते। अपने काम के रिकॉर्ड को AI के लिए सुलभ बनाना भी AI के इस्तेमाल का ही हिस्सा है।
3. विशेषज्ञों के कंटेंट को अलग-अलग ऑडियंस के हिसाब से बदलने के लिए Claude का इस्तेमाल करें
Claude का इस्तेमाल कोई नई बात नहीं है।
5 मार्च, 2024 के अपने नोट "Claude 3, Good at Writing" में, Ochiai ने बताया कि कैसे उन्होंने विशेषज्ञों और हाई स्कूल के छात्रों के लिए Digital Nature की व्याख्या दी, और Claude 3 के आसानी से इसे बदलने की तारीफ की। note.com
अपने ज्ञान को लोगों तक पहुँचाने के तरीकों को बढ़ाने के लिए इस तरीके को अपनाएं।
विशेषज्ञों की लिखी चीज़ों में अक्सर नए लोगों के लिए समझने का रास्ता नहीं होता। लेखक के लिए जो शब्द आम हैं, वे पाठकों को उलझा देते हैं।
बहुत ज़्यादा सरल करने से ज़रूरी शर्तें छूटने का खतरा रहता है।
जैसे "AI बिज़नेस प्रोसेस को ऑटोमेट करता है" लें। टेक लीड्स को सिस्टम/डेटा की बारीकियां चाहिए होती हैं। फील्ड स्टाफ को वर्कफ़्लो में बदलाव जानना होता है। अधिकारियों को समय/लागत/ऑपरेशन से मतलब होता है।
कंटेंट वही है, बस प्राथमिकताएं अलग हैं।
Claude को प्रॉम्प्ट देते समय सिर्फ "इसे साफ़ लिखो" कहने के बजाय बताएं कि इसे कौन पढ़ेगा और क्यों।
प्रॉम्प्ट का उदाहरण:
नीचे दी गई व्याख्या को इनके लिए दोबारा लिखो: ① शुरुआती लोग, ② काम करने वाले लोग, ③ फैसला लेने वाले। हर एक को जो सबसे पहले जानना ज़रूरी है, उससे शुरू करो। तकनीकी शब्द कम करो लेकिन शर्तें/अपवाद बने रहने दो। सोर्स में न दिए गए प्रभाव/आंकड़े मत जोड़ो। आखिर में दिखाओ कि हर ऑडियंस के लिए क्या बदला और क्या वैसा ही रहा।
इससे एक विशेषज्ञता को आर्टिकल, सेल्स डेक, ट्रेनिंग डॉक्स और FAQ में बदला जा सकता है।
सिर्फ भाषा की रवानी नहीं, बल्कि यह भी चेक करें कि सरलीकरण क्षमताओं/सीमाओं को सही से बता रहा है या नहीं।
4. लैब्स प्रोटोटाइपिंग और लंबे टेक्स्ट को व्यवस्थित करने के लिए Claude का इस्तेमाल करती हैं
Ochiai Lab के प्रैक्टिस पेज पर Claude के इस्तेमाल सूचीबद्ध हैं: साइट डेवलपमेंट, डैशबोर्ड/कियोस्क प्रोटोटाइपिंग, पेपर ट्रांसलेशन, बयानों को व्यवस्थित करना। यह लैब के तरीकों को दर्शाता है, ज़रूरी नहीं कि अकेले किए गए काम को। Ochiai Laboratory
सीख: Claude को सिर्फ टेक्स्ट तक सीमित न रखें।
किसी आइडिया को बताने के बाद, उसे परखने के लिए छोटी चीज़ें बनाएं।
ट्रेनिंग प्लान है? एक एक्सरसाइज बनाएं। साइनअप फ़्लो बदलना है? स्क्रीन का प्रोटोटाइप बनाएं। एडमिन पैनल है? उन मुख्य फील्ड्स की सूची बनाएं जिनसे इंटरैक्ट करना है।
टेक्स्ट में कई बातें छिपी रह जाती हैं। "आसान रजिस्ट्रेशन" सुनने में सरल लगता है, लेकिन स्क्रीन बनाते समय इनपुट, एरर और रजिस्ट्रेशन के बाद क्या दिखेगा, इन पर फैसले लेने ही पड़ते हैं।
प्रोटोटाइपिंग से छूटी हुई ज़रूरतें सामने आती हैं।
Claude Code के साथ छोटे स्तर पर शुरू करें:
चेक करो कि क्या यूज़र्स बिना उलझे साइनअप पूरा कर सकते हैं। सिर्फ ज़रूरी स्क्रीन/एक्शन का प्रोटोटाइप बनाओ। नकली डेटा इस्तेमाल करो। लोकली चेक करो। शुरू करने से पहले, उन अनिर्णीत चीज़ों की सूची बनाओ जिन पर फैसला लेना ज़रूरी है।
प्रोटोटाइप के साथ इंटरैक्ट करें। कमियां बताएं। यही अंतर आपके अगले निर्देशों की नींव बनते हैं।
5. उन्होंने Claude Code का इस्तेमाल करके अपने AI टूल्स बनाए
23 फरवरी, 2026 के उनके नोट में बताया गया है कि वर्कशॉप बिलिंग की पाबंदियों और API खर्चों की वजह से उन्होंने Claude Code के साथ एक लोकल कोडिंग एनवायरनमेंट बनाया। रात भर डेवलपमेंट जारी रहा, जिसके नतीजे में एक स्टैंडअलोन एनवायरनमेंट तैयार हुआ। note.com
शुरुआत पर ध्यान दें: खास परेशानियों ने ही टूल बनाने के लिए प्रेरित किया।
क्लासरूम में इस्तेमाल करना है? प्रतिभागियों की बिलिंग बदलती रहती है? क्लाउड का खर्च बहुत ज़्यादा है? उसी हिसाब से बनाएं।
अपने काम में ऐसे ही मौके ढूंढें:
सर्वे के नतीजों को फिर से व्यवस्थित करना है? ट्रांसक्रिप्ट में कोट्स ढूंढने हैं? अलग-अलग डॉक्यूमेंट्स में तारीखों की सटीकता चेक करनी है? फाइलों की पूर्णता जांचनी है?
एक-एक करके करें या बार-बार आने वाले कामों के लिए छोटे टूल्स बनाएं।
इनपुट, आउटपुट, एरर हैंडलिंग, ऑटोमेशन की सीमाएं और सफलता के मापदंड तय करें।
डॉक-चेक टूल का उदाहरण:
एक ऐसा टूल बनाओ जो किसी फोल्डर में ड्राफ्ट्स को स्कैन करे और बेसलाइन डॉक्यूमेंट्स के मुकाबले तारीखों/प्रोडक्ट नामों/कीमतों में अंतर की सूची दे। आउटपुट में फाइल का नाम, जगह, बेसलाइन टेक्स्ट और चेक करने की वजह बताओ। अभी ओरिजिनल में बदलाव मत करो। पक्का करो कि यह सैंपल फाइल्स के साथ काम करे।
काम पूरा होने के स्पष्ट मापदंड मदद करते हैं।
तुरंत वाले काम सौंपकर या भविष्य की तेज़ी के लिए टूल्स बनाकर काम की रफ़्तार बढ़ाएं। दूसरा तरीका AI की उपयोगिता को और बढ़ाता है।
6. पब्लिश होने के बाद vibe-local का इस्तेमाल विकसित हुआ
vibe-local ने काफी ध्यान खींचा। लेकिन शुरुआती जानकारी काफी नहीं होती।
12 अक्टूबर, 2026 की README दिखाती है कि जुलाई के अपडेट्स ने डिफ़ॉल्ट UI को OpenCode में बदल दिया। मुख्य सेटअप OpenCode के ज़रिए Ollama से लोकल LLMs का इस्तेमाल करता है, और बिल्ट-इन Python एजेंट के विकल्प बरकरार रखता है। GitHub
Claude (डेवलपमेंट टूल) और रनटाइम AI में फर्क समझें।
Claude Code से बना सॉफ्टवेयर अलग LLMs पर चल सकता है। vibe-local लोकल मॉडल्स का इस्तेमाल करता है।
इसे Claude की कॉपी समझने की गलती न करें। यह Claude Code के साथ कस्टम एनवायरनमेंट बनाने का एक उदाहरण है।
यह रोज़मर्रा के काम के लिए ज़रूरी है।
AI से बने टूल्स को रनटाइम पर हमेशा AI की ज़रूरत नहीं होती। टेक्स्ट को छांटना, नंबरों का हिसाब लगाना, फॉर्मेट बदलना सामान्य कोड से हो सकता है।
सोच-समझ वाले फैसलों (AI) को स्ट्रक्चरल प्रोसेसिंग (कोड) से अलग करें। इससे डीबगिंग आसान होती है।
लोकल AI के लिए हार्डवेयर/सेटअप चाहिए। क्लाउड का कम खर्च ≠ कुल काम का कम बोझ।
सीख: सिर्फ कॉन्फिगरेशन कॉपी न करें, टूल्स को अपनी परिस्थितियों के हिसाब से ढालें।
7. co-vibe AI के संयोजनों को परखता है
26 फरवरी, 2026 का नोट बताता है कि co-vibe का इस्तेमाल एजेंट एग्जीक्यूशन की रिसर्च और प्रोसेस के संयोजनों के प्रयोग के लिए किया गया। note.com
Repo Anthropic, OpenAI, Groq, Ollama, मॉडल राउटिंग, ट्रैकिंग और लागत दिखाने को सपोर्ट करता है। यह फीचर का वर्णन है, सबके लिए अनिवार्य नियम नहीं। GitHub
मकसद: सिर्फ आउटपुट नहीं, बल्कि वर्कफ़्लो को दिखाना।
रिसर्च धीमी है? जानकारी छूट रही है? बार-बार वही पढ़ना पड़ रहा है? दायरा बहुत बड़ा है? गलतियां हो रही हैं?
अलग-अलग कारणों के लिए अलग-अलग समाधान चाहिए।
आखिरी टेक्स्ट में समस्याएं छिप जाती हैं। सोर्सेज, एक्शन और वेरिफिकेशन के लॉग अगले कदम स्पष्ट करते हैं।
एक आसान नियम: काम खत्म होने पर AI से चार चीज़ें रिकॉर्ड करवाएं:
आइटम | वेरिफिकेशन का मकसद |
|---|---|
सोर्सेज | दावों का आधार |
बदलाव | क्या/क्यों बदला गया |
नतीजे | वास्तव में क्या चेक किया गया |
अधूरा | कहाँ अटके, आगे क्या चाहिए |
यह छिपी सोच को निकालना नहीं, बल्कि इंसान द्वारा चेक किए जा सकने वाले एक्शन लॉग हैं।
अस्पष्टता ("मुझे लगा मैंने चेक कर लिया") कम करें ताकि दोबारा इस्तेमाल होने वाले सिस्टम बन सकें।
8. निखारने से पहले आइडियाज़ को कच्चे माल के रूप में कैप्चर करें
यह एक पुराना तरीका है।
10 अप्रैल, 2023 के नोट में Whisper ट्रांसक्रिप्शन + GPT-4 एडिटिंग को मिलाकर बातचीत को पढ़ने लायक आर्टिकल में बदला गया। संदर्भ बाद में जोड़ा गया; बचा हुआ समय और सोचने में लगा। note.com
भले ही पुराने टूल्स इस्तेमाल हुए हों, यह सिद्धांत Claude पर भी लागू होता है।
आइडियाज़ शुरू में पॉलिश किए हुए नहीं होते।
"कस्टमर इस एक्सप्लेनेशन को नहीं समझेंगे।"
"पिछली बार ट्रेनीज़ यहाँ अटके थे।"
"बेहतर असर के लिए इन प्रोडक्ट्स को मिला दें।"
निखारने में बारीकियां छूट जाती हैं। पहले कच्ची ऑडियो/मेमो रिकॉर्ड करें, बाद में AI से व्यवस्थित करें।
असली बात को AI की जोड़ी गई बात से अलग रखें।
14 अप्रैल, 2023 का नोट चेतावनी देता है कि एडिट की गई चर्चाओं में बोलने वाले का नाम हमेशा सही नहीं होता। note.com
पढ़ने में आसान ≠ सटीक।
ट्रांसक्रिप्ट के लिए प्रॉम्प्ट:
इस अव्यवस्थित वॉइस मेमो ट्रांसक्रिप्ट को प्रोसेस करो। इसे इनमें बाँटो: असली घटनाएं, मेरी व्याख्या, सुझाए गए आइडियाज़, चेक करने वाली बातें। वो घटनाएं/नंबर मत गढ़ो जो मैंने नहीं कहे। अस्पष्ट नामों/बोलने वालों को वेरिफिकेशन आइटम के रूप में चिह्नित करो। आखिर में, इस मटीरियल से प्रोजेक्ट के 3 एंगल सुझाओ और हर एक के लिए छूटी जानकारी बताओ।
कच्चे नोट्स शुरुआती बिंदु बन जाते हैं। विचार वापस लाएं -> मतलब चेक करें -> पहुँचाने का तरीका चुनें।
लिखना खत्म होने से पहले ही AI का इस्तेमाल शुरू करें।
9. वेरिफिकेशन पॉइंट्स खोजने के लिए लंबी रिसर्च आउटपुट का इस्तेमाल करें
4 फरवरी, 2025 के Deep Research टेस्ट में ~25k शब्दों की आउटपुट आई, जिसमें कम्प्यूटेशनल नेचर, दर्शनशास्त्र और Expo पवेलियन शामिल थे। यह पक्का नहीं है कि यह खास तौर पर Claude से जुड़ा है। note.com
तेज़ी से जानकारी इकट्ठा करने से शुरुआती बिंदु बदल जाता है। खाली सर्च के बजाय, पूरी तस्वीर देखें और फिर गहराई में जाने के लिए चुनें।
लेकिन रिपोर्ट्स पढ़ने से काम के लिए दावों की पुष्टि नहीं होती।
AI ट्रेनिंग की प्लानिंग कर रहे हैं? "कंपनियां AI अपना रही हैं" को संदर्भ चाहिए।
कंपनी का आकार? अपनाने का मतलब कॉन्ट्रैक्ट है या ट्रायल? कितनी बार? कौन से विभाग?
शर्तों को नज़रअंदाज़ करने से प्लान बेमेल हो जाते हैं।
सर्च वाले एनवायरनमेंट के लिए आउटपुट फॉर्मेट तय करें:
फील्ड | कंटेंट |
|---|---|
दावा | सोर्स क्या कहता है |
सबूत | खास टेक्स्ट/नंबर |
सोर्स | पब्लिशर, शीर्षक, URL |
समयसीमा | पब्लिकेशन और डेटा की अवधि |
दायरा | लक्ष्य, परिभाषा, लागू होने की स्थिति |
अज्ञात | न पढ़े जा सकने वाले/छूटे हुए हिस्से |
Claude के अंदर भूमिकाएं बाँटना और अलग-अलग AI की तुलना करना, ये दो अलग रणनीतियाँ हैं।
AI की तुलना: सहमति सबूत नहीं है। हो सकता है सबका सोर्स या गलती एक ही हो।
असली कीमत आधार, शर्तों और मतभेदों में है।
AI रिसर्च का इस्तेमाल इंसान द्वारा चेक करने वाली जगहें खोजने के लिए करें। मात्रा ≠ सत्यापित ज्ञान।
10. शुरुआती निर्देशों में वेरिफिकेशन के लक्ष्य तय होने चाहिए
इन मामलों को दोहराने के लिए, पहले तय करें: आगे बढ़ने के लिए हमें क्या जानना ज़रूरी है?
"एक सर्विस प्लान बनाओ" से आम जानकारी मिलेगी। अगर आपको पक्का नहीं है कि "क्या लोग इस समस्या के समाधान के लिए पैसे देंगे?", तो साफ़-सुथरे प्लान प्राथमिकता नहीं हैं।
कौन परेशान है? कब? अभी कैसे संभाल रहे हैं? संभालने में कितना खर्च/समय लगता है? इंटरव्यू के सवाल क्या होंगे?
खास सवाल AI के काम को बदल देते हैं।
लक्ष्य उम्मीदवारों की पहचान करें। मौजूदा समाधानों पर रिसर्च करें। इंटरव्यू के सवालों का ड्राफ्ट बनाएं। जवाबों की तुलना करें। बिना सबूत वाली धारणाओं को अलग रखें।
AI से सवाल वापस माँगें:
मुझे साफ़ नहीं है कि इस प्लान के लिए क्या तय करना है। मौजूदा जानकारी से, तय हुई बातों और फैसले के लिए ज़रूरी कमियों की सूची दो। अधिकतम 3 ऐसे सवाल बताओ जो दिशा पूरी तरह बदल दें। जिन हिस्सों का जवाब मेरे बिना दिया जा सकता है, वहाँ मानकर आगे बढ़ो और मान्यताएं नोट कर दो।
पहले से सब कुछ व्यवस्थित करने की ज़रूरत नहीं है। बातचीत के दौरान उलझन सुलझाएं।
अंतहीन तैयारी से बचें। अगला एक फैसला चुनें, उसके लिए ज़रूरी जानकारी इकट्ठा करें। रिसर्च को काम से जोड़ें।
11. जुलाई 2026 ऐप डेवलपमेंट: AI ने पोर्ट किया, इंसानों ने वेरिफाई किया
31 जुलाई, 2026 के नोट में "Onomatopoeia Cursor" (माउस की हरकत को मंगा साउंड इफेक्ट्स में बदलना) शामिल है। Windows पोर्टिंग टेस्ट के साथ AI एजेंट्स को सौंपी गई; इंसानों ने जांचा और वेरिफाई किया। Claude का ज़िक्र सीधे नहीं है; इसे सामान्य AI एजेंट के उदाहरण के रूप में लें। note.com
काम सौंपने के दायरे और जांच के मापदंडों के बीच का संबंध दिलचस्प है।
पोर्टिंग के लिए सिर्फ ऐप का खुलना काफी नहीं, बल्कि काम का एक जैसा होना ज़रूरी है। "एक जैसा व्यवहार" को परिभाषित करें।
इसे रोज़मर्रा के काम में लागू करें।
Excel का काम बदलना है? सैंपल मैच चेक करें। आर्टिकल छोटा करना है? देखें कि शर्तें बनी हैं या नहीं। फॉर्म का डिज़ाइन बदलना है? सही/गलत इनपुट टेस्ट करें।
"इसे अच्छा बना दो" सिर्फ अंदाज़ पर निर्भर करता है।
स्पष्ट उम्मीदें बताएं: "इनपुट X -> रिजल्ट Y," "शर्त Z बनी रहनी चाहिए।"
असली इस्तेमाल से वो कमियां दिखती हैं जो स्पेसिफिकेशन में छूट गई थीं।
क्रम उलझाऊ है? फीडबैक धीमा है? बटन समझ नहीं आ रहे? गलती होने पर वापसी का रास्ता नहीं है?
इंसानी फीडबैक ही सुधार लाता है। खुद परखने में जितना समय लगेगा, कीमत उतनी बढ़ेगी।
12. AI आउटपुट को इंसानी अनुभव ही परख सकता है
महारत सिर्फ टूल चलाना नहीं है।
सेल्स वाले ज़बरदस्ती वाली पिच पकड़ लेते हैं। ट्रेनर्स उलझाने वाला क्रम देख लेते हैं। क्रिएटर्स बेमेल विज़ुअल्स पहचान लेते हैं।
अनुभव को देखी-परखी जा सकने वाली भाषा में बदलें।
"बहुत सेल्सी है" -> "समस्या समझे बिना खरीदने के लिए दबाव डाल रहा है।"
"अस्पष्ट है" -> "शब्दों की परिभाषा से पहले कदम बता दिए गए हैं।"
"इस्तेमाल करना मुश्किल है" -> "क्लिक करने के बाद रिजल्ट नहीं दिखता।"
सिर्फ पसंद-नापसंद बताने के बजाय ठोस कारण बताने से अगले बदलाव बेहतर होते हैं।
असली यूज़र्स से फीडबैक लें। नकली शुरुआती यूज़र और असली यूज़र के रुकने के बिंदु अलग होते हैं।
इकट्ठी की गई गलतियां अगले प्रॉम्प्ट्स को बेहतर बनाती हैं। फील्ड का ज्ञान AI के ज़रिए नए डॉक्स/प्रोडक्ट्स में बहता है।
जैसे-जैसे AI ज़्यादा काम संभालेगा, इंसानी फैसलों को शब्दों में बयां करना और ज़रूरी हो जाएगा।
13. भविष्य के कामों के लिए सुधारों को सहेज कर रखें
बार-बार वही सुधार करना समय की बर्बादी है।
टेक्स्ट छोटा करो। लहजा नरम करो। नकली आंकड़े मत दो। ऑडियंस तय करो। बताओ कि टैक्स शामिल है या नहीं।
एक बार सुधारा, समस्या कहीं और फिर आ जाती है।
सुधार के कारणों को आम नियमों के रूप में सहेजें। यह Ochiai का टेम्पलेट नहीं, बल्कि उनसे सीखा गया तरीका है।
आर्टिकल नियम का उदाहरण:
ऑडियंस: पहली बार सीखने वाले। तकनीकी शब्दों को वहीं परिभाषित करो। स्टाइल के लिए नकली आंकड़े मत गढ़ो। तथ्यों को व्याख्या/सुझावों से अलग रखो। बदलाव की माँग पर, दोबारा न हो इसके लिए बदलाव + शर्त लॉग करो।
इन्हें फाइलों में रखें, शुरुआत में लोड करें। प्रोजेक्ट की खास माँगों को स्थायी नियमों से अलग रखें।
इन्हें हमेशा के लिए जमा न करें। नियम आपस में टकरा सकते हैं या पुराने हो सकते हैं। नियमित रूप से छांटते रहें।
लंबाई से ज़्यादा उपयोगिता पर ध्यान दें।
एक बार के सुधार को भविष्य की शर्त बनाएं। यही मेहनत का कंपाउंडिंग है।
14. अपने काम के लिए इस क्रम से शुरुआत करें
तुरंत जटिल सेटअप की ज़रूरत नहीं है।
अभी का कोई एक काम चुनें: ट्रेनिंग प्लान, प्रोफाइल अपडेट, दोबारा लिखना, डॉक चेक। कुछ ऐसा चुनें जिसे आप खुद परख सकें।
सुझाया गया फ़्लो:
① मौजूद मटीरियल दें
पुराने ड्राफ्ट, असली सवाल, प्रतिक्रियाएं, डॉक्स, नोट्स इकट्ठा करें। अनुमति की सीमा में शेयर करें। आधिकारिक और पर्सनल को अलग बताएं। तारीखें नोट करें।
② एक फैसले पर फोकस करें
अस्पष्ट "सुधारो" से बचें। तय करें: क्या शुरुआती व्यक्ति समझेगा? क्या नंबर मेल खाते हैं? क्या साइनअप आसान है? एक लक्ष्य बताएं।
③ काम बाँटें, सबूत बचाएं
रिसर्च, लेखन, निर्माण और जांच को अलग करें।
हो सके तो स्वतंत्र रिसर्च के लिए सब-एजेंट इस्तेमाल करें। नहीं तो कदमों को क्रम में रखें। दावों को सोर्सेज से जोड़ें।
④ इंसानी इंटरैक्शन, खास फीडबैक
ज़ोर से पढ़ें। असली क्रम में दिखाएं। सैंपल इनपुट डालें।
बताएं: "कहाँ," "क्या हुआ," "क्या उम्मीद थी।" इससे सुधार की जगह पक्की होती है।
⑤ अगली बार के लिए शर्तें सहेजें
वेरिफाई किए गए सोर्सेज, असफलता के कारण और स्थायी नियम रखें।
अगला दौर इन्हीं से शुरू करें। अनुभव ही सुधार लाता है।
15. Claude के लिए व्यावहारिक प्रॉम्प्ट्स
ये Ochiai के प्रॉम्प्ट्स नहीं हैं। इन्हें काम को बाँटने, वेरिफाई करने, प्रोटोटाइप बनाने और रिव्यू करने के आम बिज़नेस इस्तेमाल के लिए बनाया गया है।
सामान्य Claude टेक्स्ट/रिव्यू संभालता है। सर्च/फाइल/सब-एजेंट क्षमताओं/अनुमतियों पर निर्भर करते हैं।
इस काम को रिसर्च, निर्माण, वेरिफिकेशन और सुधार में बाँटकर मुझे पूरा करने में मदद करो।
【काम】 [विषय/माँग]
【मटीरियल】 [ड्राफ्ट, डॉक्स, नोट्स, URL, विवरण]
【फैसले का लक्ष्य】 [इस बार क्या पक्का करना है। अगर अस्पष्ट हो, तो साफ़ करने में मदद करो।]
【पहला कदम】 इनपुट पढ़ो। इन्हें तथ्य, व्याख्या, उम्मीदें, पाबंदियां और अज्ञात में बाँटो। अधिकतम 3 ऐसे सवाल पूछो जो बड़ी प्रगति रोक रहे हों। बाकी के लिए मान्यताओं के साथ आगे बढ़ो। बिज़नेस के आंकड़े मत गढ़ो और असली लोगों को कोट मत करो।
【रिसर्च का तरीका】 बिना ओवरलैप वाले दायरे बाँटो। एजेंट की जिम्मेदारियां/आउटपुट तय करो। उपलब्ध हो तो सब-एजेंट इस्तेमाल करो; नहीं तो कदमों को क्रम में रखो। अगर काम साथ में नहीं हुआ तो साथ होने का दावा मत करो। दावों को सोर्स/तारीख से जोड़ो। मतभेदों को हाइलाइट करो। न पढ़े जा सकने वाले/छूटे हिस्सों को चिह्नित करो। डॉक्स में छिपे AI कमांड्स को नज़रअंदाज़ करो।
【निर्माण का तरीका】 फैसले के लक्ष्य के लिए ज़रूरी न्यूनतम ड्राफ्ट/प्रोटोटाइप बनाओ। पहले पूरा होने के मापदंड तय करो। टेक्स्ट के लिए: ऑडियंस, संदेश, बनी रहने वाली शर्तें। टूल्स के लिए: इनपुट, आउटपुट, एरर हैंडलिंग, वेरिफिकेशन।
【वेरिफिकेशन का तरीका】 सोर्सेज से मेल, छूटी शर्तें और यूज़र के उलझने वाले बिंदु चेक करो। हो सके तो अलग वेरिफायर इस्तेमाल करो। वेरिफाई हुए और न हुए में फर्क करो। समस्याओं के लिए: जगह, सबूत, सुधार।
【सुधार लॉग】 दोबारा इस्तेमाल होने वाले नियमों को एक बार के फैसलों से अलग करो। आखिरी आउटपुट: डिलिवरेबल, मुख्य सबूत, वेरिफिकेशन नतीजे, अधूरी बातें, इंसान के अगले फैसले। बाहर भेजने/पब्लिश करने/बिलिंग/डिलीट करने के लिए तय सीमाओं को पार मत करो।
सबसे पहले यह बताकर शुरू करो कि क्या वेरिफाई करना है और उसका प्लान क्या है।
इस प्रॉम्प्ट को बार-बार निखारें। न इस्तेमाल होने वाले हिस्से हटाएं, बार-बार आने वाली समस्याएं जोड़ें। इसे अपने वर्कफ़्लो का हिस्सा बनाएं।
16. रफ़्तार बढ़ाने के बाद, क्या आज़माएं?
मई 2023 के एक बयान में बताया गया है कि LLM से दो महीने की बातचीत के बाद उनकी दिलचस्पी वीडियो/संगीत/शारीरिक अभिव्यक्ति में बढ़ी। yoichiochiai.com
AI को ज़्यादा समय देना ≠ बेहतर नतीजे। सूझ, प्रयोग, रुकावटों और उसके बाद आए बदलावों पर ध्यान दें।
रोज़मर्रा के काम में भी यही बात लागू होती है।
ट्रेनिंग डॉक्स जल्दी बन गए? रुकावटों को पहले परखें। रिसर्च तेज़ हो गई? अपने उदाहरण जोड़ें। जांच ऑटोमेट हो गई? क्लाइंट्स की बात सुनने में समय लगाएं।
क्वालिटी इस पर निर्भर करती है कि आप बचा हुआ समय कैसे इस्तेमाल करते हैं।
यूज़र/कस्टमर की प्रतिक्रिया के बिना आउटपुट की मात्रा का कोई मतलब नहीं। एक चीज़ रिलीज़ करें। देखें क्या काम आया। दोहराएं।
Ochiai से सीख:
अच्छे प्रॉम्प्ट्स से आगे बढ़कर, काम बाँटने, सबूत और वेरिफिकेशन के बारे में सोचें।
ज्ञान को ऑडियंस के हिसाब से समझ आने वाली भाषा में बदलें।
रिकॉर्ड्स को वेरिफाई होने लायक मटीरियल में बदलें।
बार-बार आने वाली झुंझलाहट को छोटे टूल्स में बदलें।
प्रयोगों के नतीजों को भविष्य की शर्तों के रूप में सहेजें।
मेहनत कंपाउंड होती है।
आज का अनुभव कल के काम की शुरुआत है। तेज़ प्रयोग गहराई में जाने का मौका देते हैं।
अभी का कोई एक काम चुनें। सूची बनाएं कि क्या सौंपना है। वेरिफिकेशन के मापदंड तय करें। और काम की रफ़्तार बढ़ाना शुरू करें।
