विधि · AI से सॉफ़्टवेयर · ओपन सोर्स
Urazuke, प्रमाण-विधि।
Urazuke (裏付け) जापानी शब्द है उस आधार के लिए जो किसी दावे को पीछे से थामे रहता है। यह कृत्रिम बुद्धिमत्ता से सॉफ़्टवेयर बनाने की मेरी विधि है जिससे मज़बूत और उत्पादन के लिए तैयार सॉफ़्टवेयर निकले, और प्रोजेक्ट के मालिक को कोड की एक भी पंक्ति न पढ़नी पड़े। मैंने इसे आज उत्पादन में चल रहे अपने तीन वास्तविक सिस्टमों से निकाला, हमेशा से चली आ रही सिस्टम इंजीनियरिंग और इस बात के सहारे कि इन सिस्टमों ने मुझे दिखाया कि मॉडल उसे कहाँ कमज़ोर ढंग से लागू करते हैं।
लेखक: Pablo Kuschniroff, Claude Code की सहायता से।
Creative Commons BY-SA 4.0 · आठ भाषाएँ · टूल-निरपेक्ष · स्रोत के रूप में उत्पादन में तीन सिस्टम · ओपन सोर्स और सहयोगी
मूल दावा
AI विधि को बाधित नहीं करती: वह उसे आगे बढ़ाती है।
मूल दावे से पहले एक स्पष्टीकरण जो मेरे लिए महत्त्वपूर्ण है: यह विधि हर ठोकर के बाद लगाए गए पैबंदों का संग्रह नहीं है। यह दो कारकों के मेल से बनी है। पहला है सिस्टम इंजीनियरिंग का मेरा अपना ज्ञान: सर्वेक्षण, आवश्यकताएँ, आकार-निर्धारण, प्रमाण के रूप में टेस्ट, दोहराने योग्य तैनाती, ऑडिट; यह मैं इन मॉडलों के अस्तित्व से बहुत पहले से लाया हूँ। दूसरा वह है जो उत्पादन के तीन सिस्टमों ने घटना-दर-घटना मुझे दिखाया: मॉडल उन सिद्धांतों को कहाँ कमज़ोर ढंग से लागू करते हैं, और इसलिए कहाँ लिखित रूप में कसना ज़रूरी है। निशान बताते हैं कि कठोरता कहाँ चाहिए; वे सिद्धांतों का मूल नहीं हैं।
उद्योग ने बीस साल पहले कोड के लेखक पर भरोसा करना छोड़ दिया। जब लेखन जूनियर, आउटसोर्स या बदलती टीमों के पास गया, पंक्ति-दर-पंक्ति समीक्षा असंभव हो गई, और उसकी जगह वह सब उगा जिसे आज हम सामान्य मानते हैं: स्वचालित टेस्ट, निरंतर एकीकरण, स्वीकृति मानदंड, ऐसी पाइपलाइनें जो हरे के बिना कुछ नहीं जाने देतीं। यही था सिस्टम इंजीनियरिंग का जवाब "जो लिखता है वह भरोसेमंद नहीं" को: उसका कोड मत पढ़ो, प्रमाण माँगो। मॉडल अगला लेखक है, पहला अविश्वसनीय नहीं।
मनुष्य का प्रयास कहाँ जाता है
मनुष्य केवल दो काम करता है: निर्णय लेता है, और उत्पादों की जाँच करता है। लिखना, बनाना, परखना, मापना और दस्तावेज़ बनाना मॉडल करता है। हर सीढ़ी कोड पढ़े बिना पूर्णता-जाँच पर समाप्त होती है।
प्रमाण स्वयं को सिद्ध करता है
जो टेस्ट आपने कभी विफल होते नहीं देखा, पता नहीं वह कुछ सिद्ध करता है या नहीं। बिना टेस्ट का मीटर झूठ बोलता है। बिना अंधे बिंदुओं की रिपोर्ट छिपाती है। गुणवत्ता नियंत्रण की स्वतंत्रता का अनुशासन, एक कदम और भीतर।
उत्पादों की लागत
पहले दस्तावेज़ीकरण महँगा था और पुराना पड़ जाता था। अब उसे फिर से बनाना मुफ़्त है, इसलिए नियम बन जाता है "उसी कमिट में" और "बिना AI, हाथ से दोहराने योग्य"। जो असंभव आदर्श था, वह गेट बन जाता है।
यह क्या है और क्या नहीं
एक ऐसे निर्माता पर लागू सिस्टम इंजीनियरिंग जो थकता नहीं और जिस पर यक़ीन नहीं किया जा सकता।
सिस्टम से आने वालों को यह जाना-पहचाना लगता है: सर्वेक्षण, आवश्यकताएँ, आकार-निर्धारण, डिज़ाइन, निर्माण, परीक्षण, तैनाती, संचालन, ऑडिट। वाइबकोडिंग से आने वालों को यह वह देता है जो उनके पास नहीं है, यानी ठीक ढाँचा।
यह क्या है
- एक विधि: किस क्रम में क्या करना है, मॉडल से क्या माँगना है, उसे क्या देना है, और कैसे जानें कि वह पूरा है।
- चार खंडों में चौबीस सीढ़ियाँ, हर एक के साथ अनुबंध: संदर्भ, प्रॉम्प्ट, अपेक्षित परिणाम, जाँच, चेतावनी संकेत।
- टूल-निरपेक्ष: Claude Code, Cursor, Codex CLI, Gemini CLI या Forge। हर उत्पाद एक फ़ाइल, एक टेस्ट या एक स्क्रिप्ट है।
- उत्पादन में तीन वास्तविक सिस्टमों से निकाली गई, हर नियम उस कमिट और ठोकर से बँधा जिसने उसे जन्म दिया।
यह क्या नहीं है
- प्रोग्रामिंग या किसी फ़्रेमवर्क का कोर्स नहीं।
- मॉडल से बेहतर लिखवाने के प्रॉम्प्ट-ट्रिक्स का संग्रह नहीं।
- शुक्रवार के डेमो प्रोटोटाइप की विधि नहीं: यह उसके लिए है जिसे बाद में भी चलते रहना है।
- हर प्रोजेक्ट के लिए काम करने वाली विधि नहीं। सीढ़ी 0 सीमा लिखित रूप में तय करती है।
सीढ़ी
चौबीस सीढ़ियाँ, चार खंड, चढ़ने के क्रम में।
सीढ़ियाँ उसी कालक्रम में क्रमांकित हैं जिसमें चढ़ी जाती हैं। शुरुआत वाली हर प्रोजेक्ट में एक बार; चक्र वाली हर बदलाव पर; उत्पादन में जाने वाली पहली तैनाती से पहले एक बार; संचालन वाली तब, जब सिस्टम जीवित हो। 23वीं चक्र बंद कर 0 पर लौटती है। हर सीढ़ी का आठ भागों वाला कार्ड और प्रॉम्प्ट सहित अनुबंध है। कोई समय-सीमा नहीं: पद्धति एक प्रक्रिया है, गति का वादा नहीं।
हर प्रोजेक्ट में एक बार, कार्यक्षमता लिखने से पहले
जिन पाँच को छोड़ने का सबसे ज़्यादा मन करता है और छोड़ना सबसे महँगा पड़ता है।
हर बदलाव पर, पूरे प्रोजेक्ट भर
हर लंबित मद के साथ जिस क्रम में होती हैं, उसी क्रम में। पहले दो ब्लॉकों पर सीखी और पूरे प्रोजेक्ट में अभ्यास की जाती हैं।
पहली तैनाती से पहले, एक बार
"चलता है" को "टिकता है" में बदलती हैं: ऑडिट, ताले, उत्पादन तक की पाइपलाइन, अवलोकनीयता, पर्सिस्टेंस, कमज़ोरियाँ, प्रदर्शन और मैनुअल।
जब सिस्टम जीवित हो चुका हो
चक्रीय रिपोर्ट वाली दो निगरानियाँ, निवासी एजेंट और वह पुनरावलोकन जो चक्र बंद कर 0 पर लौटता है।
तेरह सीढ़ियाँ जिन पर किसी प्रोजेक्ट में समझौता नहीं
- पात्रता (एक घंटा; महीने बचाता है)
- सहकार्य अनुबंध
- संक्षिप्त परिभाषा, "यह क्या नहीं है" सहित
- व्यवसाय के आँकड़ों से आकार-निर्धारण
- योजना के रूप में लंबित मदें
- मालिक और तारीख़ सहित निर्णय
- लाल देखे गए टेस्ट
- जाँचा गया / माना गया / अंधे बिंदु वाली रिपोर्ट
- संख्या सहित पुनरावलोकन
- पाइपलाइन में निर्भरताओं और रहस्यों की स्कैनिंग
- केंद्रीकृत त्रुटि संग्रह और रिपोर्ट
- पाइपलाइन में कोड गुणवत्ता, न्यूनतम
- लोगों द्वारा चलाए गए मैनुअल टेस्ट केस
समय-रेखा
हर सीढ़ी कब चढ़ी जाती है, और बीच में क्या होता है।
समय-रेखा के बिना पद्धति अच्छे इरादों की सूची भर है। यह किसी भी प्रोजेक्ट की समय-रेखा है: पाँच चरण, क्रम में, और हर चरण में सीढ़ियों के अलावा क्या होता है: आवश्यकताओं का संग्रह, इंफ्रास्ट्रक्चर, इंटीग्रेशन और तैनाती की पाइपलाइन, विकास, एंड-टू-एंड परीक्षण, मानवीय नज़र, मानवीय परीक्षण। कोई समय-सीमा नहीं: हर चरण उतना चलता है जितना सिस्टम माँगे।
संग्रह
आवश्यकता-इंजीनियरिंग की शास्त्रीय विधियों से मालिक के साथ सर्वेक्षण: साक्षात्कार, उपयोग-प्रकरण, अवस्थाओं सहित डोमेन मॉडल, स्क्रीन प्रोटोटाइप। गद्य में, जानबूझकर अधूरा: एजेंट प्रश्न पूछकर इसे पूरा करता है।
शुरुआत (सीढ़ियाँ 0 से 4)
पात्रता, अनुबंध, अर्थ-वृक्ष सहित परिभाषा, आकार-निर्धारण। और पूरा आरंभिक इन्फ़्रास्ट्रक्चर व CI/CD शृंखला: रिपॉज़िटरी, परीक्षण परिवेश, निरंतर एकीकरण, खाली सिस्टम की पहली तैनाती। मालिक URL खोलकर खाली स्क्रीन देखता है।
चक्र (सीढ़ियाँ 5 से 12)
एक-एक कार्यात्मक ब्लॉक। हर लंबित मद के साथ: विनिर्देश, निर्णय, लाल देखा गया टेस्ट, प्रवाह का शुरू-से-अंत टेस्ट, स्क्रीनशॉट जिसे मालिक देखता है। हर ब्लॉक के समापन पर: पूरा शुरू-से-अंत सूट और परीक्षण परिवेश में मानवीय परीक्षण।
उत्पादन में जाना (13 से 20)
दूसरे सत्र द्वारा ऑडिट। जो भुगतान लेता या भेजता है उसे बनाने से पहले ताले। परखे गए रोलबैक के साथ उत्पादन तक की शृंखला का समापन। तीन मैनुअल। सभी प्रवाहों पर मालिक के स्वीकृति-परीक्षण। साथ में तैनाती से पहले संचालन गुणवत्ता की चार सीढ़ियाँ: अवलोकनीयता, पर्सिस्टेंस, कमज़ोरियाँ, प्रदर्शन।
संचालन (21 से 23 और चक्र)
किसी व्यक्ति के नाम पर निवासी एजेंट। आवधिक ऑडिट। हर विकास पूरे चक्र से प्रवेश करता है और तैनाती शृंखला से निकलता है। हर चरण के समापन पर संख्याओं सहित पुनरावलोकन। दोनों निगरानियाँ, संसाधन और त्रुटियाँ, पहली तैनाती के सप्ताह में लगाई जाती हैं, चक्रीय रिपोर्ट के साथ जिसे मालिक पढ़ता है।
शुरू-से-अंत टेस्ट अंत में एक बार नहीं होते
हर लंबित मद के साथ, जिस प्रवाह को उसने छुआ। हर ब्लॉक के समापन पर, जितने प्रवाह मौजूद हैं वे सब। उत्पादन से पहले, ठीक उसी संस्करण के साथ सभी प्रवाह जिसे आगे बढ़ाना है। केवल तीसरा किया तो हफ़्तों की अनपरखी चीज़ें लेकर अंत तक पहुँचेंगे।
तीन उपयोग-स्थितियाँ
खाली फ़ोल्डर, पद्धति से बना सिस्टम, या विरासत में मिला सिस्टम: कहाँ से प्रवेश करें।
सीढ़ी एक खाली फ़ोल्डर को देखकर लिखी गई है, जो सीखने के लिए सबसे स्पष्ट स्थिति है, पर सबसे आम नहीं। एजेंट खोलने से पहले यह जानना ज़रूरी है कि आप तीन में से किस स्थिति में हैं, क्योंकि प्रवेश का रास्ता बदल जाता है। और तीसरी स्थिति, जो सिस्टम पहले से मौजूद है और इस पद्धति से नहीं जन्मा, उसका अपना रास्ता है: बिना दोबारा लिखे उसे सामान्यीकृत किया जाता है, और उसके बाद ही सीढ़ी चढ़ी जाती है।
नया प्रोजेक्ट
खाली फ़ोल्डर और एक माँग वाला मालिक। सीढ़ी 0 से प्रवेश और चौबीस सीढ़ियाँ क्रम से: पहली सुविधा से पहले एक सप्ताह की शुरुआत। मुख्य दस्तावेज़, अनुबंध और पाठ्यक्रम यही बताते हैं।
पद्धति सहित विकासात्मक-सुधारात्मक
सिस्टम सीढ़ी चढ़ चुका है: उसके पास अनुबंध, नक्शा, साक्ष्य के साथ बंद लंबित मदें, टेस्ट-सूट, तैनाती और मैनुअल हैं। सीढ़ी 5 से प्रवेश, एक ब्लॉक खोलकर, और चक्र का पालन। यही 15 का 0 पर लौटना है।
पद्धति रहित विकासात्मक-सुधारात्मक
एक चालू सिस्टम, उपयोगकर्ताओं के साथ, किसी और ने या आपने ही बिना साक्ष्य के बनाया। सामान्यीकरण के आठ स्टेशन (N0 से N7): जो इनपुट किसी ने नहीं लिखे उन्हें स्रोत-चिह्नों के साथ स्वतः-खोज से वापस लाना; सुरक्षा-बेल्ट को कठोर गेट बनाना; मॉड्यूल छूते ही कर्ज़ चुकाना। फिर, सुधारात्मक या विकासात्मक मोड में चक्र।
विकासात्मक-सुधारात्मक रास्ता पढ़ें → पाठ्यक्रम, भाग 2: विरासत वाला प्रोजेक्ट →
हर सीढ़ी का अनुबंध
कैसे माँगा जाए, क्या लौटना चाहिए, और कैसे जानें कि वह पूरा लौटा।
हर सीढ़ी पाँच खंडों के अनुबंध से चलती है। मॉडल के लिए प्रॉम्प्ट अंग्रेज़ी में हैं, दस्तावेज़ के आठों संस्करणों में एक जैसा एक ही टुकड़ा, और हर एक के नीचे पाठक की भाषा में व्याख्या कि हम क्या माँग रहे हैं और हर खंड वहाँ क्यों है।
आवश्यक संदर्भ
सामान्य रूप से नामित। सर्वेक्षण स्वभाव से अधूरे होते हैं; उन्हें फ़ॉर्म से नहीं, मॉडल प्रश्न पूछकर पूरा करता है।
प्रॉम्प्ट
शब्दशः। सबमें एक ही खंड: मॉडल आँकता है कि संदर्भ पर्याप्त है या नहीं, आगे बढ़ने से पहले जो कमी है वह माँगता है, और केवल व्यवसाय के पास मौजूद आँकड़े का न अनुमान लगाता है न गढ़ता है।
अपेक्षित परिणाम
उत्पाद की विस्तृत विशेषताएँ: कौन-सी फ़ाइल, कौन-से खंड, क्या छूट नहीं सकता।
पूर्णता-जाँच
जो मालिक कोड पढ़े बिना उत्पाद पर जाँचता है। एक भी "नहीं" हुआ तो सीढ़ी नहीं चढ़ी गई।
चेतावनी संकेत
वे लक्षण कि सीढ़ी ग़लत चढ़ी गई, भले ही चढ़ी हुई लगे। जो हफ़्तों बाद दिखते हैं, जब दर्द होने लगा हो।
एक उदाहरण प्रॉम्प्ट · सीढ़ी 7
docs/PENDING.md में उसके “दिया गया, जब, तब” स्वीकृति मानदंड और “कैसे सत्यापित होगा” के साथ; पहले से लागू किया गया बदलाव; docs/STATUS.md में टेस्ट-सूट का कमांड; और चल रहा टेस्ट वातावरण, जिस प्रवाह को छुआ जा रहा है उसके डेटा के साथ। दस्तावेज़ीकरण में हर प्रॉम्प्ट से पहले ऐसा ही एक ब्लॉक है: आप कौन-सी फ़ाइलें बनाते हैं, किस सामग्री के साथ, और न्यूनतम स्वीकार्य स्थिति क्या है।अंग्रेज़ी में क्यों: वही सामग्री दूसरी भाषा में 30 से 50 % अधिक टोकन लेती है, मॉडल अंग्रेज़ी में निर्देशों का अधिक सटीक पालन करते हैं, और पेशे की शब्दावली अंग्रेज़ी है। पर मैं नहीं चाहता कि अंग्रेज़ी बाधा बने: दस्तावेज़ीकरण में हर प्रॉम्प्ट के साथ दस्तावेज़ की भाषा में उसका अनुवाद और इस जैसा एक बटन है। मॉडल को अंग्रेज़ी चिपकाई जाती है; अनुवाद आपके समझने के लिए है। सभी "Reply in my language" पर समाप्त होते हैं।
आवश्यकता से लंबित मद तक
हमेशा की आवश्यकता-इंजीनियरिंग, ऐसी इकाइयों में बँटी जिन्हें मॉडल बना सके और आप जाँच सकें।
आवश्यकता चैट में ग्राहक का एक वाक्य नहीं है। यह वह वाक्य है जो दशकों से मौजूद विधियों से संसाधित हुआ है, जिन्हें मॉडल माँगने पर बहुत अच्छे से और न माँगने पर बहुत बुरे ढंग से लागू करता है: साक्षात्कार, उपयोग-प्रकरण, डोमेन मॉडल, स्वीकृति मानदंड, स्क्रीन प्रोटोटाइप, अनुरेखणीयता। विधि में तीन उत्पाद इन्हें थामे रखते हैं।
अर्थ-वृक्ष
सिस्टम एक वृक्ष के रूप में: डोमेन; नीचे, कर्ता, प्रक्रियाएँ (उपयोग-प्रकरण), अवस्थाओं सहित इकाइयाँ, स्क्रीन और एकीकरण; और हर नोड से लंबित मदें और निर्णय लटकते हैं। एजेंट इसे बनाता है, आप इसे सुधारते हैं, और यही एजेंट कोड छूने से पहले पढ़ता है। जो लंबित मद किसी नोड से नहीं लटकती वह दायरे से बाहर है, और यह दस सेकंड में दिख जाता है।
विस्तृत विनिर्देश हर लंबित मद में रहता है
पुराना पड़ने वाला लंबा विनिर्देश दस्तावेज़ विघटित हो जाता है: हर लंबित मद में उसका वृक्ष-नोड, ग्राहक के शब्दों में मूल कहानी, विवरण, निर्णय और तारीख़ सहित व्यावसायिक नियम, डेटा, स्क्रीन, किनारे के मामले, स्वीकृति मानदंड और जाँच का तरीका होता है। उस विनिर्देश को पढ़ना कोड पढ़ने के सबसे क़रीब है, और यही सही दूरी है।
बंद लंबित मदें दस्तावेज़ीकरण हैं
बंद मद मिटती नहीं: वह अपने विनिर्देश, उसे जन्म देने वाले निर्णय, जिस प्रमाण से बंद हुई, कमिट और तारीख़ के साथ रहती है। बंद मदों की कतार सिस्टम का कार्यात्मक इतिहास है; वहीं से परिवर्तन-लॉग, उपयोगकर्ता मैनुअल, और छह महीने बाद "सिस्टम ऐसा क्यों करता है" का उत्तर निकलते हैं।
किसी भी टूल के साथ
उत्पाद फ़ाइलें, टेस्ट और स्क्रिप्ट हैं। बदलता बस यह है कि वे कहाँ जाते हैं।
Claude Code
अनुबंध और दिनचर्याएँ प्रोजेक्ट की CLAUDE.md में जाती हैं; सीढ़ी के प्रॉम्प्ट हर सीढ़ी चढ़ते समय चैट में चिपकाए जाते हैं।
Cursor
दिनचर्याएँ .cursor/rules/ में हमेशा सक्रिय नियमों के रूप में; बाक़ी वैसा ही।
Codex CLI / Gemini CLI
रिपॉज़िटरी की जड़ में AGENTS.md या GEMINI.md में।
Yujin Forge
अनुबंध और दिनचर्याएँ सिद्धांत हैं, हर गेट पार करते समय प्रॉम्प्ट अपने-आप इंजेक्ट होते हैं, और लंबित मदों का रजिस्टर मूल है। वही विधि, कम कॉपी-पेस्ट के साथ। Forge जानें →
कोर्स
व्यावहारिक कार्यों सहित चौबीस पाठ, उत्पादन में एप्लिकेशन तक।
कोर्स-शैली का मैनुअल, हर सीढ़ी पर एक पाठ, विधि को अपने प्रोजेक्ट या मार्गदर्शक प्रोजेक्ट ("Turnera", रिमाइंडर, अग्रिम राशि और निजी डेटा वाली अपॉइंटमेंट डायरी: वह सब जो ज़रूरी है ताकि कोई सीढ़ी नक़ली न हो) पर लागू करने के लिए। उत्पादन-सूची पर समाप्त: चौबीस शर्तें जो मालिक कोड खोले बिना जाँचता है। पाठ्यक्रम का भाग 2 उसी क्लिनिक को विरासत में मिले सिस्टम ("विरासत वाली Turnera") के साथ लेता है और सुधारने व विकसित करने से पहले उसे सामान्यीकृत करना सिखाता है।
आपको क्या समझना है
हर सीढ़ी की अवधारणा, जैसे किसी व्यक्ति को समझाई जाती है, उस वास्तविक विफलता सहित जिसने उसे जन्म दिया।
कार्य, चरण-दर-चरण
एजेंट के लिए सटीक प्रॉम्प्ट और उसके लौटाए पर क्या करना है। जानबूझकर किए गए परीक्षण शामिल: एक प्रश्न अनुत्तरित छोड़ें और देखें वह क्या करता है।
जाँच और डिलिवरेबल
दिए गए पर, कोड खोले बिना, आप स्वयं से जो प्रश्न पूछते हैं, और वह फ़ाइल या प्रमाण जो अंत में मौजूद होना चाहिए।
आम ग़लतियाँ और मार्गदर्शक प्रोजेक्ट
पहली बार लगभग सबके साथ जो होता है, और हर पाठ Turnera पर लागू होकर कैसा दिखता है।
नए आने वाले के लिए
हाथ से प्रोग्रामिंग के बाद के युग में जूनियर डेवलपर।
अगर कोड मॉडल लिखता है, तो जूनियर कैसे सीखता है, क्या सीखता है, और क्या बनने के लिए? एक अलग दस्तावेज़: कौन-से प्रशिक्षण केंद्र वज़न खोते हैं, कौन-से पाते हैं, कौन-सी साक्षरता अब भी अनिवार्य है, उद्देश्य, और मेंटर के साथ बारह सप्ताह की योजना। पूरी पद्धति की तरह, शुरुआती स्तर पर लिखा हुआ।
टीम में
कई डेवलपर, हर एक अपने एजेंट के साथ, एक ही ब्रांच पर।
पद्धति एकवचन में लिखी है। यह दस्तावेज़ बताता है कि कई लोग हों तो यह कैसे लागू होती है: साझा ब्रांच के सात नियम (लंबित मद स्वामित्व की इकाई, छोटा और बार-बार इंटीग्रेट करना, निरंतर इंटीग्रेशन रेफ़री, अधूरा काम स्विच के पीछे, नक्शा टकराव-डिटेक्टर, नाम सहित निर्णय, कोड नहीं साक्ष्य की समीक्षा), सीढ़ियाँ कैसे बँटती हैं, और प्रॉम्प्ट।
पूरी सामग्री, आठ भाषाओं में
अपनी भाषा में पढ़ें।
स्पेनिश सत्य का स्रोत है; बाक़ी सात संस्करण अनुवाद हैं और भिन्नता होने पर स्पेनिश मान्य है। प्रॉम्प्ट सबमें एक जैसे हैं। हर भाषा में तीन दस्तावेज़: मुख्य दस्तावेज़ (मूल दावा, तीन सिस्टमों का सर्वेक्षण, चौबीस सीढ़ियाँ, वास्तविक विफलताएँ और शब्दावली), चौबीस अनुबंध, और कोर्स-मैनुअल। और संस्करण 5 से, हर भाषा में दो और दस्तावेज़: पहले से मौजूद सिस्टमों के लिए विकासात्मक-सुधारात्मक रास्ता, और विरासत वाले मार्गदर्शक प्रोजेक्ट के साथ पाठ्यक्रम का भाग 2।
विधि Creative Commons Attribution-ShareAlike 4.0 के तहत प्रकाशित है: श्रेय देकर और उसी लाइसेंस के तहत इसका उपयोग, अनुवाद और अनुकूलन किया जा सकता है। रिपॉज़िटरी सार्वजनिक और सहयोगी है: github.com/pkuschnirof/urazuke। सुधार फ़ोर्क से पुल रिक्वेस्ट द्वारा, प्रमाण सहित आते हैं, और समीक्षा के बाद मैं उन्हें मर्ज करता हूँ।
क्या यह किसी और नाम से पहले से मौजूद है? मैंने अक्टूबर 2026 तक मिलते-जुलते कामों की गहराई से खोज की (Uncle Bob और उनका "gauntlet", Tsumiki, Spec Kit, Consort, IACDM, Osmani और अन्य), क्या दावा करने के बजाय उद्धृत करना बेहतर है, क्या कहीं नहीं मिला, और सबसे गंभीर आपत्ति और उसका उत्तर। यह मुख्य दस्तावेज़ के भाग F, "संबंधित कार्य" में है (अंग्रेज़ी में)।
Forge में दो निष्पादन मैनुअल, चरण-दर-चरण और स्क्रीनशॉट सहित, असली अभ्यास प्रोजेक्ट पर बने: नया प्रोजेक्ट (Turnera) और मौजूदा प्रोजेक्ट (विरासत में मिला Turnera)। हर सीढ़ी पर जुटाए प्रमाण सहित (स्पेनिश में)।
अनूदित संग्रह के बाहर दो और दस्तावेज़: द्वारों की व्याख्या, अंग्रेज़ी में, क्योंकि यह उपकरण का दस्तावेज़ है और डेटा से उत्पन्न होता है; और इस पद्धति पर एआई मॉडलों के मूल्यांकन, स्पेनिश में।
यदि आप किसी उपकरण से इस पद्धति का उपभोग करेंगे, तो रिपॉज़िटरी पढ़ने की आवश्यकता नहीं: डेटा इंटरफ़ेस yujin.app/urazuke/api/ पर है। इसकी सूची प्रत्येक संसाधन को उसके विहित पते, संस्करण और हैश के साथ दर्ज करती है: gates.json, द्वारों की यांत्रिक परिभाषा, और prompts.json, प्रॉम्प्ट। हैश सामग्री से पुनर्गणित होता है, इसलिए पुरानी प्रतिलिपि स्वयं पकड़ में आ जाती है।
यह कहाँ से आई
उत्पादन में तीन सिस्टम, और तारीख़ व प्रमाण सहित दर्ज छियालीस मामले।
मैंने केवल-पठन में तीन रिपॉज़िटरियों का सर्वेक्षण किया जो आज वास्तविक लोगों के उपयोग के साथ उत्पादन में हैं: वह टूल जहाँ विधि बनी (पाँच महीनों में एक हज़ार नब्बे कमिट), पैसे और संवेदनशील डेटा वाले एक स्वास्थ्य संस्थान का स्वचालन सिस्टम (छह सौ इकतालीस लंबित मदें, सब बंद), और एक नागरिक संघ का ओमनीचैनल फ़्रंट डेस्क (पहला जहाँ माप व्यवस्थित रूप से निर्माण से पहले आता है)। विधि में मैं जिस भी मामले का हवाला देता हूँ वह संदर्भ दस्तावेज़ में क्रमांकित है, ताकि प्रक्रियाएँ साफ़ रहें और विवरण एक क्लिक दूर रहे। ग्राहक गुमनाम हैं; संख्याएँ, तारीख़ें और कमिट वास्तविक हैं।
जहाँ मॉडल स्पष्ट बात लागू करने में विफल होता है
वह मीटर जिसने दो बार झूठ बोला। सफलता बताकर रिपोर्ट की गई प्रमाणीकरण त्रुटि। चार में से तीन दावे जो ग़लत थे। हर एक ने मुझे बताया कि जो सिद्धांत मेरे लिए स्पष्ट था उसे कहाँ प्रॉम्प्ट का स्पष्ट खंड बनना था।
संख्याओं सहित पुनरावलोकन
मैंने साठ डॉलर और तिहत्तर मिनट बनाम नब्बे मिनट के साथ एजेंटों की पूरी टीम समाप्त कर दी। मैंने चौबीस-सत्ताईस मिनट बनाम ग्यारह के साथ तैनाती को बाँट दिया। सीढ़ी स्वयं यही है।
Pablo Kuschniroff, Claude Code की सहायता से
RPAForce / Yujin। विधि स्वयं पर लागू होती है: इसके निर्णय तारीख़ और शब्दशः वाक्यों सहित दर्ज हैं, और रिपॉज़िटरी 18 अक्टूबर 2026 से github.com/pkuschnirof/urazuke पर सार्वजनिक है।
अक्सर पूछे जाने वाले प्रश्न
अक्सर पूछे जाने वाले प्रश्न।
- क्या मुझे प्रोग्रामिंग आनी चाहिए?
- नहीं। आपको विवेक और निर्णय का समय रखने वाला डोमेन मालिक चाहिए, और रिपॉज़िटरी, कमिट और पुश क्या हैं इसकी बुनियादी समझ। विधि ठीक इसीलिए है कि मालिक कोड पढ़ने के बजाय प्रमाण जाँचे।
- क्या यह हर प्रोजेक्ट के लिए है?
- नहीं, और यह कोई कमी नहीं। दो बहिष्कारी शर्तें हैं: प्रमाण रखने के लिए एक मानक रिपॉज़िटरी, और प्रोग्राम से चलाई जा सकने वाली स्क्रीनें ताकि शुरू से अंत तक परीक्षण हो सके। सीढ़ी 0 सीमा लिखित में रखती है।
- क्या मुझे Forge या NAC3 चाहिए?
- नहीं। विधि टूल-निरपेक्ष है; हर उत्पाद एक फ़ाइल, टेस्ट या स्क्रिप्ट है। Forge गेटों और प्रॉम्प्ट-इंजेक्शन को स्वचालित करता है, पर सीढ़ी Forge के बिना भी मौजूद है। NAC3 वह साधन है जिससे आज हम स्क्रीन की परीक्षण-योग्यता पाते हैं, शर्त नहीं।
- दस्तावेज़ मेरी भाषा में है तो प्रॉम्प्ट अंग्रेज़ी में क्यों?
- क्योंकि मॉडल अंग्रेज़ी में निर्देशों का अधिक सटीक और कम टोकन में पालन करते हैं। हर प्रॉम्प्ट आठों संस्करणों में एक जैसा एक ही टुकड़ा है, नीचे आपकी भाषा में समझाया गया, और "Reply in my language" पर समाप्त होता है।
- छोटा प्रोजेक्ट शुरू से अंत तक कितना समय लेता है?
- मैं जानबूझकर कोई समय-सीमा नहीं देता। यह पद्धति कोड का एक बिट भी समझे बिना सिस्टमों को संचालन-योग्य और रखरखाव-योग्य बनाने की प्रक्रिया है; यह सिस्टम तेज़ी से बनाने की प्रक्रिया नहीं है, भले ही गति परिणाम के रूप में दिखे। पद्धति क्रम और गेट तय करती है; हर चरण में कितना समय लगे, यह आपके सिस्टम का आकार और जटिलता तय करते हैं।
- सुधार कैसे प्रस्तावित करूँ?
- प्रमाण के साथ: सीढ़ी 15 माँगती है कि हर पुनरावलोकन सीढ़ी में बदलाव के ठोस प्रस्ताव पर समाप्त हो, उस घटना सहित जो उसे उचित ठहराती है। प्रस्ताव github.com/pkuschnirof/urazuke पर फ़ोर्क से पुल रिक्वेस्ट द्वारा आते हैं और मर्ज से पहले मैं उनकी समीक्षा करता हूँ।
प्रमाण माँगो। उसका कोड मत पढ़ो।
एक विधि ताकि मॉडल बनाए और आप निर्णय लें और जाँचें। आठ भाषाओं में, खुले लाइसेंस के साथ, और तीन वास्तविक सिस्टमों की ठोकरों सहित ताकि आपको वही ठोकरें न खानी पड़ें।