AI को एक ऐसा क्लाइंट बनाएँ जो आपके स्तर पर स्पेसिफिकेशन लिखे, मील के पत्थरों और सत्यापन-योग्य सफलता मानदंडों के साथ, पर कभी कोड नहीं।
इस पाठ को Kodokon में खोलेंबुनियादी बातें पार कर लेने के बाद, ट्यूटोरियल आपको आगे बढ़ाना बंद कर देते हैं: वे आपसे एक लकीर खिंचे रास्ते पर समाधान नकल करवाते हैं। एक सक्षम डेवलपर को जो आगे बढ़ाता है वह है वह प्रोजेक्ट जो उसके स्तर से थोड़ा ऊपर हो - इतना कठिन कि फैसले लेने पड़ें, इतना ढाँचाबद्ध कि आप फँसकर न रह जाएँ। समस्या: खुद को अंशांकित करना लगभग असंभव है, आप कुछ बहुत आसान या बहुत महत्वाकांक्षी चुन बैठते हैं। AI उस अंशांकन में उत्कृष्ट है, बशर्ते आप उसे सही भूमिका दें। गलत तरीका: "मेरे लिए एक खर्च-ट्रैकिंग ऐप कोड करो" - आपको तैयार उत्पाद और शून्य कौशल मिलता है। सही तरीका: AI उस क्लाइंट की भूमिका निभाता है जो स्पेसिफिकेशन लिखता है; डेवलपर आप हैं।
तुम एक प्रोजेक्ट क्लाइंट (प्रोडक्ट ओनर) हो। तुम स्पेसिफिकेशन लिखते हो, तुम कभी कोड नहीं लिखते।
मेरी प्रोफ़ाइल: मैं [भाषा/तकनीक] का नियमित अभ्यास करता हूँ। मुझे पहले से आता है: [ईमानदार सूची]। मैं जिन पर बेहतर होना चाहता हूँ: [लक्षित अवधारणाएँ, जैसे: async एरर हैंडलिंग, टेस्टिंग, मॉड्यूलों में बँटवारा]।
उपलब्ध समय: करीब [X] घंटे, [अवधि] में फैले हुए।
एक मिनी-प्रोजेक्ट के लिए स्पेसिफिकेशन लिखो:
- ज़रूरत ज़्यादा से ज़्यादा 5 लाइनों में, जैसे कोई असली क्लाइंट कहता (क्या, कभी कैसे नहीं)।
- 3 से 5 क्रमबद्ध मील के पत्थर, हर एक किसी कार्यशील और प्रदर्शन-योग्य चीज़ पर खत्म हो।
- हर मील के पत्थर के लिए: अवलोकन-योग्य सफलता मानदंड ("कमांड X, Y दिखाता है", "मामला Z एक साफ़ संदेश के साथ खारिज होता है" - न कि "कोड साफ़ है")।
- एक तकनीकी बाध्यता जो मुझे लक्षित अवधारणाओं का उपयोग करने पर मजबूर करे।
- 2 वैकल्पिक विस्तार अगर मैं जल्दी खत्म कर लूँ।
निषेध: कोई कोड स्निपेट नहीं, कोई थोपे गए फ़ंक्शन या लाइब्रेरी के नाम नहीं, कोई कार्यान्वयन के संकेत नहीं। कार्यान्वयन मेरा काम है।अंशांकन दो जानकारियों पर टिका है जो केवल आपके पास हैं: आपको पहले से क्या आता है (ईमानदार रहें, वरना प्रोजेक्ट बहुत आसान होगा) और आप किस पर काम करना चाहते हैं (एक या दो अवधारणाएँ, छह नहीं)। मील के पत्थर प्रोजेक्ट को एक फ़ीडबैक लूप में बदल देते हैं: हर कदम एक प्रदर्शन-योग्य व्यवहार देता है, जो आपको आर्किटेक्चर की मीनार बनाने में फँसने से रोकता है। रही बात अवलोकन-योग्य सफलता मानदंडों की, वे पूरा फर्क डालते हैं: "कोड साफ़ है" सत्यापित नहीं किया जा सकता, "किसी दूषित फ़ाइल को आयात करने पर बिना क्रैश हुए एक स्पष्ट एरर दिखता है" दस सेकंड में सत्यापित किया जा सकता है। एक अ-अवलोकन-योग्य मानदंड एक राय है; एक अवलोकन-योग्य मानदंड एक स्वीकृति परीक्षण है।
तुम निम्नलिखित प्रोजेक्ट के क्लाइंट हो: [स्पेसिफिकेशन दोहराओ या मौजूदा मील का पत्थर पेस्ट करो]।
मुझे लगता है मैंने मील का पत्थर [X] खत्म कर लिया है। यह रहा जो मेरा प्रोग्राम करता है, उपयोगकर्ता की नज़र से: [अवलोकन-योग्य व्यवहार बताओ, कोड नहीं]।
1. मील के पत्थर के हर सफलता मानदंड से गुज़रो: यह पक्का करने के लिए कि वह सचमुच पूरा हुआ है, मुझसे सटीक सवाल पूछो, किनारे के मामलों सहित (खाली इनपुट, सीमा से बाहर का मान, दो बार दोहराई गई क्रिया)।
2. अगर कोई मानदंड पूरा नहीं हुआ, तो बताओ कौन-सा और कैसे, बिना यह बताए कि उसे कैसे ठीक करना है।
3. अगर सब कुछ पास हो जाता है, तो अगला मील का पत्थर बताओ - फिर भी बिना कोड या कार्यान्वयन के संकेत के।यह सत्यापन-अनुष्ठान किसी असली प्रोजेक्ट के स्वीकृति परीक्षण को दोहराता है: क्लाइंट आपका कोड नहीं पढ़ता, वह व्यवहार से पूछताछ करता है। किनारे के मामलों पर सवाल ही असल कीमती हिस्सा हैं - वहीं आप खोजते हैं कि आपका कार्यान्वयन क्या नहीं संभालता। बचता है किसी भी एकल प्रोजेक्ट का नाज़ुक पल: अटक जाना। "मेरे लिए यह हिस्सा लिख दो" पर पलटने का लालच अपने चरम पर होता है। इसका मुकाबला क्रमिक संकेतों के प्रोटोकॉल से करें: हर स्तर थोड़ा और कहता है, और आप केवल उतना ही स्तर खर्च करते हैं जितना आपको फिर से चल पड़ने के लिए चाहिए।
मैं अपने प्रोजेक्ट [संदर्भ] पर अटक गया हूँ। रुकावट: [तुम क्या करने की कोशिश कर रहे हो, क्या आज़माया, कहाँ टूटता है]।
मुझे क्रमिक संकेत दो, एक बार में एक स्तर:
- संकेत 1: आम दिशा - दोबारा देखने लायक कोई अवधारणा या एक दिशा, एक वाक्य में।
- संकेत 2 (केवल अगर मैं माँगूँ): ज़्यादा सटीक - मेरे तरीके के किस हिस्से पर फिर से सोचना है।
- संकेत 3 (केवल अगर मैं माँगूँ): समाधान का सिद्धांत, सादी भाषा में समझाया, कोई कोड नहीं।
संकेत 1 से शुरू करो और मेरे जवाब का इंतज़ार करो। कोई स्तर कभी मत छोड़ो, भले ही मैं बेसब्र हो जाऊँ या ज़िद करूँ।