उत्तर सौंपे बिना अपने अभ्यासों का सुधार करवाना

AI को इस तरह ढालें कि वह आपके काम का मूल्यांकन संकेतों और एक अंकन पैमाने के ज़रिये करे, कभी आपके लिए आपका कोड दोबारा लिखे बिना।

8 मिनट · 3 प्रश्न

आपने एक अभ्यास पूरा कर लिया है और आप जानना चाहते हैं कि यह कितना अच्छा है। स्वाभाविक प्रतिवर्त - अपना कोड "इसे मेरे लिए ठीक करो" के साथ पेस्ट करना - एक रणनीतिक गलती है: AI आपके समाधान को बेहतर तरीके से दोबारा लिख देगा, आप उसे पढ़ेंगे, सहमति में सिर हिलाएँगे… और कुछ भी नहीं सीखा होगा। एक उपयोगी सुधार आपको बताता है कि आप कहाँ गलत हुए और आपको इसे खुद ठीक करने देता है। ठीक यही आपको माँगना चाहिए।

तुम एक प्रोग्रामिंग अभ्यास मूल्यांकक हो। यह रहा अभ्यास का कथन, फिर मेरा समाधान।

कथन: [अभ्यास का कथन यहाँ पेस्ट करें]

मेरा समाधान: [अपना कोड यहाँ पेस्ट करें]

अंकन नियम, निरपेक्ष:
1. मेरा कोड कभी दोबारा मत लिखो, न पूरा और न ही टुकड़ों में। कोई सुधारा हुआ संस्करण नहीं, भले ही मैं माँगूँ।
2. पहले मुझे बताओ कि मेरा समाधान सही है, आंशिक रूप से सही है, या गलत है।
3. हर समस्या के लिए: संबंधित पंक्ति की ओर इंगित करो और मुझसे एक ऐसा प्रश्न पूछो जो मुझे दिशा दे, बिना समाधान दिए।
4. समस्याओं को गंभीरता के अनुसार क्रमबद्ध करो: वास्तविक bug, फिर भूला हुआ edge case, फिर style।
5. जब मैं एक ऐसा संस्करण सौंपूँ जिसे मैंने खुद सुधारा है, तो उसे उन्हीं नियमों के तहत फिर से मूल्यांकित करो।

अगर कोई समस्या ही नहीं है, तो स्पष्ट रूप से यह कहो और अभ्यास को कठिन बनाने के लिए मुझे एक अतिरिक्त बाधा पेश करो।

नियम 4 में क्रम-व्यवस्था पेशेवर दुनिया से सीधे आयातित एक आदत है: किसी code review में, आप हमेशा उसमें भेद करते हैं जो टूटता है (bug), जो टूटेगा (edge case: खाली array, ऋणात्मक मान, संख्या के बजाय पाठ) और जो खटकता है (style, नामकरण)। प्रतिक्रिया को गंभीरता के अनुसार छाँटना सीखना आपको उन वास्तविक code reviews के लिए तैयार करता है जिन्हें आप किसी टीम में अनुभव करेंगे।

एक साधारण "सही या गलत" से आगे जाने के लिए, एक अंकन पैमाना माँगें। मानदंडों में विभाजित एक स्कोर एक अस्पष्ट धारणा को एक सटीक निदान में बदल देता है: आप तुरंत देख लेते हैं कि आपका कमज़ोर बिंदु कार्यात्मक शुद्धता है, edge-case का संचालन है, या पठनीयता है - और इसलिए पहले किस पर काम करना है।

मेरे समाधान का मूल्यांकन निम्नलिखित अंकन पैमाने से करो, 20 अंकों में से:

- कार्यात्मक शुद्धता (8 अंक): क्या कोड सामान्य मामले में अपेक्षित परिणाम देता है?
- Edge cases (4 अंक): खाली input, चरम मान, अप्रत्याशित प्रकार।
- पठनीयता (4 अंक): स्पष्ट variable नाम, तार्किक संरचना, कोई बेवजह जटिलता नहीं।
- भाषा की सर्वोत्तम प्रथाएँ (4 अंक): उपयुक्त idioms, कोई अतिरेकी कोड नहीं।

प्रत्येक मानदंड के लिए: स्कोर, अधिकतम दो वाक्यों का औचित्य, और - यदि अंक कम हैं - बिना मुझे समाधान दिए सुधारने के लिए एक संकेत।

मेरे अगले प्रयास के लिए काम करने वाले प्राथमिकता क्षेत्र के साथ समाप्त करो।

पूरा कार्य-चक्र, जिसे एक पेशेवर दिनचर्या के रूप में याद रखें: आप इसे अकेले हल करते हैं, आप मूल्यांकक प्रॉम्प्ट के साथ सौंपते हैं, आप स्थानीकृत संकेत प्राप्त करते हैं, आप इसे खुद ठीक करते हैं, आप दोबारा सौंपते हैं - और केवल तभी जब आपका संस्करण टिक जाए तब आप पूछ सकते हैं: "अब जब मेरा समाधान सही है, मुझे दिखाओ कि एक अनुभवी डेवलपर इसे कैसे लिखता, और हर अंतर को समझाओ।" उस चरण पर, तुलना करना अब आपके सीखने की जगह नहीं लेता: यह उसे शिखर तक पहुँचाता है।

ज्ञान जांच

सुनिश्चित करें कि आपको इस पाठ के मुख्य बिंदु याद हैं।

1. सीखने के लिए "इसे मेरे लिए ठीक करो" एक बुरा प्रॉम्प्ट क्यों है?
   • क्योंकि AI इस तरह के अनुरोध को अस्वीकार कर देता है
   • क्योंकि AI आपके लिए समाधान दोबारा लिख देता है और आपको मरम्मत से वंचित कर देता है, जो वह क्षण है जब आप सीखते हैं
   • क्योंकि सुधार पढ़ने के लिए बहुत लंबा होगा
2. एक अच्छा मूल्यांकक समस्याओं को किस क्रम में क्रमबद्ध करता है?
   • फ़ाइल में उनके प्रकट होने के क्रम से
   • पहले style, bugs बाद में
   • वास्तविक bug, फिर भूला हुआ edge case, फिर style
   • बेतरतीब, सभी समस्याएँ बराबर हैं
3. AI से किसी अनुभवी डेवलपर का समाधान माँगना कब उचित है?
   • जैसे ही आप पाँच मिनट से ज़्यादा अटक जाएँ
   • कभी नहीं, यह हमेशा मना है
   • एक बार जब आपका अपना समाधान सही हो जाए, तुलना करने और अंतरों को समझने के लिए
   • शुरू करने से पहले, यह जानने के लिए कि कहाँ जाना है