Claude Code का काम 'हो गया' नहीं, सबूत से पूरा करें: जांच चेकलिस्ट

शुक्रवार की रात मैंने Claude Code से कहा, “एक आर्टिकल लिखकर publish तक कर देना,” और सोने चला गया। अगली सुबह log देखा तो पूरे आत्मविश्वास के साथ लिखा था—“पूरा हो गया। आर्टिकल publish कर दिया गया।” मैंने निश्चिंत होकर public URL खोला, और स्क्रीन पर जो दिख रहा था वह पिछले आर्टिकल का title था।

build पास हो चुका था। URL भी 200 लौटा रहा था। लेकिन h1 tag किसी और page का ही रह गया था। diff की जांच मैंने पूरी तरह AI पर छोड़ दी थी, और बस “चल गया” इस एक शब्द पर भरोसा कर बैठा था।

उस पल मुझे समझ आया कि अटकाव Claude Code की समझदारी में नहीं, बल्कि मेरे “काम बंद करने के तरीके” में था। AI को जितना ज़्यादा दायरा सौंपते हैं, काम खत्म होने के बाद “असल में क्या-क्या जांचा गया” यह अपने हाथ में न रखें तो हर बार झूठी “हो गया” रिपोर्ट में फंसते रहेंगे।

इस लेख में मैं वही “सबूत छोड़ने का ढांचा” copy-paste करने लायक code के साथ बता रहा हूं।

मुख्य बातें

• AI के “हो गया” पर भरोसा मत कीजिए। build, public URL, h1, CTA—जो मशीन से जांचा गया, सिर्फ वही सबूत को ही “पूरा हुआ” का आधार बनाइए।
• संपादन शुरू करने से पहले “इस काम में क्या जांचना है” एक वाक्य में तय करें, और जांच का command भी पहले ही चुन लें।
• publish के बाद हर बार एक ही क्रम में देखें—h1 → canonical → लेख की शुरुआत → CTA। क्रम तय हो तो चूक कम होती है।
• सबूत (screenshot, URL, अगला देखने वाला आंकड़ा) एक पंक्ति के note में छोड़ दें, ताकि कल का आप या automation वही फैसला दोबारा न करे।
• एकदम परफेक्ट आर्टिकल एक बार में निकालने से बेहतर है—अगले दिन जांचा जा सकने वाला आर्टिकल निकालना। संचालन के लिहाज़ से यही मज़बूत है।

“हो गया” अकेले से हादसा क्यों होता है

Claude Code काम के बीच की प्रगति को शब्दों में summary करके देता है। दिक्कत यहीं है—जब काम सच में सही हुआ हो और जब बिगड़ गया हो, दोनों हालत में summary लगभग एक ही चेहरे के साथ लौटती है।

build पास होने का मतलब बस इतना है कि “syntax टूटा नहीं है।” public URL का 200 लौटाना भी सिर्फ इतना कहता है कि “server ने कुछ लौटाया।” वह “कुछ” इस बार बनाया गया आर्टिकल है या नहीं—यह बिल्कुल अलग बात है।

मेरे शुक्रवार वाले हादसे में भी build और 200, दोनों पास थे। बिगड़ा था सिर्फ एक बिंदु पर—URL और page का अंदरूनी content आपस में मेल खाते हैं या नहीं। उसी एक जगह को कोई नहीं देख रहा था।

इसलिए “पूरा हुआ” का फैसला AI के शब्दों पर नहीं, बल्कि आपके तय किए गए जांच-बिंदुओं को एक-एक करके निपटाने के नतीजे पर टिकाइए। अगर जांच की पूरी प्रक्रिया का आधार ही डगमगाता हो, तो पहले Claude Code की शुरुआत कैसे करें से बुनियादी प्रवाह जमा लें—फिर इस लेख के steps आसानी से बैठ जाएंगे।

15 मिनट में चलने वाला जांच loop

हर बार अलग-अलग तरीके से जांचेंगे तो व्यस्त दिन कोई-न-कोई step ज़रूर छूटेगा। क्रम तय कर लीजिए ताकि बिना दिमाग़ खपाए loop चल जाए।

1. इस काम में “क्या जांच लेने पर पूरा माना जाए” यह एक वाक्य में लिखें। उदाहरण: “इस slug का आर्टिकल सही h1 के साथ public URL पर दिख रहा हो।”
2. संपादन शुरू करने से पहले जांच में काम आने वाला command (build या diff दिखाना) तय कर लें। खत्म होने के बाद ढूंढने मत बैठिए।
3. बदलाव करने के बाद diff → build → public URL—इसी क्रम में देखें। बीच में मन बदले तो भी यह क्रम मत तोड़िए।
4. public URL पर h1, canonical, लेख की शुरुआत और CTA—सब अपेक्षा के मुताबिक लगे हैं या नहीं, यह आंखों से देखें।
5. बची हुई risk और “अगला सबसे छोटा कदम” बस एक पंक्ति में note कर दें।

यहां सबसे ज़रूरी बात है—AI को सौंपने वाला दायरा और इंसान के तय करने वाला दायरा शुरू में ही अलग कर लेना।

चरण	AI को सौंप सकते हैं	इंसान तय करे
विषय चुनना	मौजूदा titles पढ़कर विकल्प सुझाना	आख़िर में कौन-सा लिखना है
लेखन	लेख, code, headings का मसौदा	झूठ या पुरानी जानकारी तो नहीं घुसी
जांच	build चलाना, diff की summary	public URL का content सही है या नहीं, यह आख़िरी पुष्टि
publish	publish command चलाना	delete, production में बदलाव जैसे न-पलटने वाले काम की मंज़ूरी

जो काम पलटे नहीं जा सकते, उन्हें शुरुआत में पूरी तरह “इंसान से पूछो” पर सेट रखिए। जो काम सुरक्षित साबित हो जाएं, उन्हें बाद में automatic में बढ़ा दीजिए। इस सीमा-रेखा को खींचने की सोच अनुमति प्रबंधन गाइड में विस्तार से समझाई गई है।

copy-paste करने लायक अनुरोध का ढांचा

जांच को हर बार शून्य से शब्दों में ढालेंगे तो उस दिन के मूड के हिसाब से कुछ-न-कुछ छूट जाएगा। Claude Code को दिए जाने वाले अनुरोध को एक ढांचे में बांध दें तो जांच-बिंदु स्थिर रहते हैं।

इस आर्टिकल को publish कर दिया है। पूरा होने की रिपोर्ट देने से पहले, नीचे की बातें जांचकर नतीजा एक table में लौटाओ।
- build सफल हुआ या नहीं (command और exit code भी लिखो)
- public URL का h1, इस slug के आर्टिकल title से मेल खाता है या नहीं
- canonical उसी slug की ओर इशारा कर रहा है या नहीं
- लेख की शुरुआत, पिछले आर्टिकल या homepage की दोबारा इस्तेमाल की गई copy तो नहीं है
- CTA (मुफ्त PDF, उत्पाद, परामर्श) पाठक की स्थिति के हिसाब से सही क्रम में लगे हैं या नहीं
जो बिंदु जांच न पाओ, उसे ईमानदारी से "जांचा नहीं" लिखो। अंदाज़े से "OK" मत लिखो।

आख़िरी वाक्य असली असर करता है। “अंदाज़े से OK मत लिखो” यह साफ़ न कहें तो AI बिना जांचे बिंदुओं पर भी हल्के-से अच्छे चेहरे के साथ “कोई दिक्कत नहीं” लौटा देता है। अनुरोध बनाने की कला को और निखारना हो तो साथ में prompt डिज़ाइन का उन्नत तरीका भी पढ़ लीजिए।

copy-paste से चलने वाली जांच script

यही आज का असली हिस्सा है। यह script public URL को fetch करके मशीनी तरीके से तय करती है कि h1 अपेक्षित title है या नहीं। सिर्फ Node.js (18 या उससे ऊपर) से चलती है। AI के “हो गया” को नहीं, इस script के फ़ैसले को “पूरा हुआ” का आधार बनाइए।

// verify-publish.mjs
// इस्तेमाल: node verify-publish.mjs <public URL> "<अपेक्षित h1 title>"
// उदाहरण: node verify-publish.mjs https://claudecode-lab.com/hi/blog/foo/ "आर्टिकल title"

const [url, expectedH1] = process.argv.slice(2);

if (!url || !expectedH1) {
  console.error("URL और अपेक्षित h1 title—दोनों देने ज़रूरी हैं।");
  process.exit(2);
}

// public page को fetch करें
const res = await fetch(url, { redirect: "follow" });
const html = await res.text();

// h1 और canonical को मोटे तौर पर निकालें (सख़्त parser की ज़रूरत नहीं)
const h1 = (html.match(/<h1[^>]*>(.*?)<\/h1>/is)?.[1] ?? "")
  .replace(/<[^>]+>/g, "")
  .trim();
const canonical = html.match(/<link[^>]+rel=["']canonical["'][^>]+href=["']([^"']+)["']/i)?.[1] ?? "";

// हर जांच-बिंदु को एक-एक करके निपटाएं
const checks = {
  http200: res.status === 200,
  h1Matched: h1 === expectedH1,
  canonicalMatched: canonical.includes(new URL(url).pathname),
};

console.table(checks);

const allOk = Object.values(checks).every(Boolean);
if (!allOk) {
  console.error("कोई बिंदु जांचा नहीं गया या मेल नहीं खाया। publish को अभी 'पूरा' मत मानिए।");
  console.error(`मिला हुआ h1: ${h1 || "(खाली)"}`);
  process.exit(1);
}

console.log("सबूत पूरे हैं। इसे 'पूरा हुआ' मान सकते हैं।");

चलाना बस इतना है।

node verify-publish.mjs https://claudecode-lab.com/hi/blog/foo/ "आर्टिकल title"

अगर h1Matched false है, तो यह ठीक मेरे शुक्रवार वाले हादसे जैसी ही हालत है—URL ज़िंदा है पर content अलग है। जब तक exit code 0 न हो, publish को “पूरा” मत कहिए। बस इसी को नियम बना लेने से झूठी “हो गया” रिपोर्ट इसी जगह रुक जाती है।

इन हालात में यह काम आता है

1. आर्टिकल publish करने का काम यहीं HTTP 200 को ही सफलता समझने की ग़लती सबसे ज़्यादा होती है। ऊपर वाली script से जांच लें कि h1 और canonical एक ही slug की ओर इशारा करते हैं या नहीं—तो पिछले आर्टिकल की दोबारा इस्तेमाल की गई copy या homepage पर गिरने वाला fallback publish से पहले ही पकड़ में आ जाएगा।

2. CTA बदलना मुफ्त PDF या उत्पाद का button हिलाने के बाद, screenshot और “अगला देखने वाला आंकड़ा” एक ही note पंक्ति में रखें। बाद में “उस बदलाव से registration बढ़े या नहीं” यह याद्दाश्त से नहीं, record से ट्रैक कर पाएंगे।

3. सेटिंग या अनुमति बदलना CLAUDE.md या अनुमति की सेटिंग बदलें—तभी बदलाव से पहले और बाद में एक ही जांच command चलाइए। सेटिंग लिखने को लेकर झिझक बची हो तो पहले CLAUDE.md लिखने का तरीका सुधार लें, ताकि जांच का आधार पुख़्ता रहे।

आम गड़बड़ियां और उन्हें ठीक करना

सच कहूं तो इस ढांचे पर टिकने से पहले मैं कई बार इन्हीं गड्ढों में गिरा।

पहली—एक ही बार में सब कुछ ठीक करने के चक्कर में इतना बड़ा diff बना देना कि जांचा ही न जा सके। 40 files वाला diff न इंसान पढ़ पाता है, न AI। इसका इलाज सीधा है—एक बार में जांचने वाली चीज़ को एक वाक्य तक सीमित करें। जांच के क़ाबू से बाहर हो जाए तो काम को टुकड़ों में बांट दें।

दूसरी—local build पास होते ही काम पूरा मान लेना। local पर चलना और public URL पर सही दिखना—दोनों अलग बातें हैं। इलाज यह है कि publish के बाद ऊपर वाली script हर बार एक बार ज़रूर चलाएं। इसे अपने steps में जोड़ने तक मैंने भी कई बार ग़लत content publish किया।

तीसरी—सिर्फ CTA बढ़ाते जाना, पर यह न बताना कि पाठक किधर बढ़े। तीन button लगा दें पर पाठक चुन न पाए, तो कोई फ़ायदा नहीं। इलाज यह है कि पाठक की स्थिति (अभी command से झिझक है / बार-बार वाले काम से थका है / टीम में लागू करने की सोच रहा है) के हिसाब से कौन-सा CTA सही है, यह लेख में एक पंक्ति में बता दें।

अक्सर पूछे जाने वाले सवाल

Q. build पास हो जाए तो उतने से पूरा नहीं मान सकते? build सिर्फ इतना सबूत है कि syntax टूटा नहीं। public URL का content इस बार का आर्टिकल है या नहीं, यह अलग सवाल है। h1 और canonical तक देखने पर ही पूरा माना जाता है।

Q. जांच script हर बार हाथ से चलानी पड़ेगी? शुरू में हाथ से ही काफ़ी है। जब steps जम जाएं तो इसे publish command के तुरंत बाद अपने-आप चलने वाले रूप में बढ़ा लें। exit code 0 न हो तो publish रोक दो—ऐसा संचालन रखें तो हादसे घटते हैं।

Q. जांच भी पूरी तरह AI को क्यों न सौंप दें? पढ़ना और summary बनाना सौंप सकते हैं। लेकिन “public URL का content सही है या नहीं” की आख़िरी पुष्टि और न-पलटने वाले काम की मंज़ूरी इंसान के पास रहे। यह सौंप दिया तो झूठी “हो गया” रिपोर्ट रोकने वाला कोई नहीं बचेगा।

Q. क्या non-engineer भी यह जांच चला सकता है? हां, चला सकता है। script copy-paste से चलती है, और आंखों से देखने वाला तरीका तो बस क्रम याद रखने भर का है। command से ही झिझक हो तो non-engineers के लिए समझाइश से शुरू करें, ज़ोर नहीं पड़ेगा।

Q. note में क्या छोड़ना काफ़ी है? “इस बार क्या जांचा,” “क्या risk बची,” “अगला सबसे छोटा कदम”—बस ये तीन काफ़ी हैं। लंबी कार्यवाही की ज़रूरत नहीं। मक़सद सिर्फ इतना है कि कल का आप वही फ़ैसला दोबारा न करे।

असल में आज़माने पर क्या हुआ

शुक्रवार के ग़लत-content publish के बाद, मैंने “पूरा हुआ” का पैमाना “AI ने क्या कहा” से बदलकर “script का exit code 0 है या नहीं” कर दिया।

verify-publish.mjs को असल में करीब 10 publish पर चलाकर देखा, तो उनमें से 2 में h1Matched false लौटा। दोनों 200 लौटा रहे थे और देखने में पकड़ में नहीं आते। script न होती तो मैं फिर से दोबारा इस्तेमाल वाला page publish कर बैठता।

आंखों से देखने का क्रम तय करना भी असरदार रहा। h1 → canonical → लेख की शुरुआत → CTA, हमेशा एक ही क्रम में देखने लगा, तो “अरे, यह जगह पिछली बार भी छूटी थी” जैसी चूक लगभग ख़त्म हो गई। फ़ैसला दिमाग़ में करने के बजाय steps में बाहर निकाल दिया, उतने भर से रात की जांच हल्की हो गई।

समझदार AI ढूंढने के बजाय, गिरें तो भी पता चल जाए—ऐसा ढांचा पहले बिठा दीजिए। घुमावदार लगता है, पर सबसे तेज़ रास्ता यही है, यही मेरा अभी का निष्कर्ष है।

इस जांच के ढांचे को टीम का मानक बनाना हो, या अपनी publish flow में जोड़ना हो, तो प्रशिक्षण व परामर्श में हम साथ बैठकर इसे डिज़ाइन करेंगे। Claude Code का official दस्तावेज़ Anthropic के documentation पर देखा जा सकता है।