सॉफ़्टवेयर इंजीनियरों के लिए प्रॉम्प्ट इंजीनियरिंग के उदाहरण
डीबगिंग, रिफ़ैक्टरिंग, टेस्ट, आर्किटेक्चर, कोड समीक्षा और दस्तावेज़ीकरण के लिए ठोस प्रॉम्प्ट इंजीनियरिंग उदाहरण।
एक उपयोगी इंजीनियरिंग प्रॉम्प्ट सहायक को अलग-थलग आदेश से नहीं, बल्कि समस्या, साक्ष्य, सीमाओं और स्वीकृति मानदंड से तर्क करने देता है। नीचे के उदाहरण दिखाते हैं कि इससे डीबगिंग, रिफ़ैक्टरिंग, टेस्ट, आर्किटेक्चर, कोड समीक्षा और दस्तावेज़ीकरण का काम कैसे बदलता है।
हर बेहतर प्रॉम्प्ट उस निर्णय के बारे में जानबूझकर स्पष्ट है जो सहायक को लेना है। कार्य छोटा हो तो आप इसे संक्षिप्त कर सकते हैं, लेकिन वह जानकारी बनाए रखें जो उत्पाद के लिए गलत बदलाव को रोकती है।
अस्थिर checkout को डीबग करना
समस्या
कभी-कभी retry के बाद checkout अनुरोध सफल हो जाता है, लेकिन UI फिर भी पहली त्रुटि दिखाता है।
कमज़ोर प्रॉम्प्ट
अस्थिर checkout त्रुटि ठीक करें।
बेहतर प्रॉम्प्ट
लक्षण: checkout अनुरोध timeout के कारण एक बार विफल हो सकता है, फिर
automatic retry पर सफल हो सकता है। retry के बाद सफलता स्क्रीन दिखाई नहीं देती।
अपेक्षित: सफल retry त्रुटि स्थिति को बदल दे और अगले checkout चरण को
सक्रिय कर दे।
देखा गया: नेटवर्क लॉग में 200 response दिखता है, लेकिन पहला error banner बना रहता है।
दायरा: केवल checkout mutation, retry callback और screen state जाँचें।
सीमाएँ: मौजूदा payment provider integration और error copy बनाए रखें।
किसी अनुरोध के वास्तव में सफल होने से पहले त्रुटियाँ न छिपाएँ।
पहले दो या तीन साक्ष्य-आधारित परिकल्पनाएँ और उन्हें अलग पहचानने वाला सबसे छोटा
reproduction या log signal दें। फिर न्यूनतम fix और regression test प्रस्तावित करें।
यह क्यों काम करता है
प्रॉम्प्ट साक्ष्य को धारणा से अलग करता है। यह rewrite से पहले state-transition diagnosis माँगता है और payment integration को असंबंधित बदलाव से सुरक्षित रखता है।
दोहराए गए फ़ॉर्म लॉजिक का रिफ़ैक्टर
समस्या
तीन settings form एक ही loading, error और save-state code दोहराते हैं।
कमज़ोर प्रॉम्प्ट
डुप्लिकेशन हटाने के लिए इन फ़ॉर्म का रिफ़ैक्टर करें।
बेहतर प्रॉम्प्ट
account, notification और profile form save-state rendering को दोहराते हैं।
बिलकुल दोहराए गए व्यवहार और वे जगहें पहचानें जहाँ फ़ॉर्म अलग हैं।
परिणाम: public form props, validation timing, localized errors, analytics events
या keyboard behavior बदले बिना डुप्लिकेट rendering घटाएँ।
दायरा: तीन settings form और उनके सीधे tests।
गैर-लक्ष्य: कोई सामान्य form framework न बनाएँ या request ownership को
मौजूदा feature hooks से बाहर न ले जाएँ।
सबसे छोटा extraction सुझाएँ, सुरक्षित रखा गया contract दिखाएँ, और हर फ़ॉर्म के लिए
loading, failure और success के tests जोड़ें या अपडेट करें।
यह क्यों काम करता है
“डुप्लिकेशन हटाएँ” एक लक्ष्य है, डिज़ाइन नहीं। बेहतर प्रॉम्प्ट सहायक से वास्तविक साझा seam खोजने को कहता है और बहुत बड़े abstraction को रोकता है।
race condition का टेस्ट लिखना
समस्या
पुरानी धीमी query के search results नई query को overwrite कर सकते हैं।
कमज़ोर प्रॉम्प्ट
search के लिए टेस्ट जोड़ें।
बेहतर प्रॉम्प्ट
search race condition के लिए regression coverage जोड़ें।
परिदृश्य: उपयोगकर्ता "network" खोजता है, तुरंत query बदलकर
"terminal" करता है, और network response सबसे बाद में लौटता है।
अपेक्षित: UI केवल "terminal" के परिणाम दिखाता है। पुराना response उन्हें
बदल नहीं सकता।
मौजूदा test stack और accessible assertions का उपयोग करें। आंतरिक state नामों पर
assert न करें। अगर production code cancellation या freshness को स्पष्ट रूप से
व्यक्त नहीं कर सकता, तो टेस्ट लिखने से पहले आवश्यक सबसे छोटा बदलाव समझाएँ।
यह क्यों काम करता है
टेस्ट प्रॉम्प्ट समय, उपयोगकर्ता क्रिया और दिखाई देने वाला व्यवहार परिभाषित करता है। वह सुविधाजनक implementation detail को टेस्ट का contract नहीं बनने देता।
आर्किटेक्चर बदलाव का मूल्यांकन
समस्या
एक टीम तय कर रही है कि configuration के लिए दूसरी cache layer जोड़ी जाए या नहीं।
कमज़ोर प्रॉम्प्ट
ऐप को तेज़ बनाने के लिए configuration में caching जोड़ें।
बेहतर प्रॉम्प्ट
आकलन करें कि client-side configuration cache धीमी स्क्रीन को बेहतर बनाएगी या नहीं,
बिना stale entitlement या preference decisions बनाए।
संदर्भ: ऐप में पहले से configuration provider है और स्क्रीन authenticated user की
प्रतीक्षा करती है। हमने नहीं मापा है कि fetching या rendering bottleneck है।
तुलना करें: no cache, bounded in-memory cache और प्रस्तावित persistent
cache। freshness, invalidation, privacy, offline behavior और बदलाव को सही ठहराने
के लिए आवश्यक measurement का मूल्यांकन करें।
जब तक आप यह न बता दें कि कौन-सा विकल्प सुझाते हैं और क्यों, कुछ लागू न करें।
यह क्यों काम करता है
प्रॉम्प्ट “तेज़” को मापने योग्य बनाता है और सहायक से आधार पर सवाल उठाने को कहता है। cache अपने-आप performance सुधार नहीं होती।
जोखिमपूर्ण diff की समीक्षा
समस्या
एक pull request उसी फ़ीचर में permissions और उपयोगकर्ता को दिखाई देने वाले navigation को बदलता है।
कमज़ोर प्रॉम्प्ट
इस pull request की समीक्षा करें।
बेहतर प्रॉम्प्ट
इस diff की authorization regressions, locale-breaking navigation और
refactoring से छिपे व्यवहार परिवर्तनों के लिए समीक्षा करें।
हर बदले हुए permission decision को उसके caller तक ट्रेस करें। सत्यापित करें कि
internal links सक्रिय locale बनाए रखते हैं और denied states protected
data प्रकट नहीं करते।
केवल diff या उसके सीधे call sites के साक्ष्य वाले निष्कर्ष बताएँ।
style suggestions से पहले correctness और security को प्राथमिकता दें। missing
tests को पुष्टि किए गए defects से अलग सूचीबद्ध करें।
यह क्यों काम करता है
समीक्षा में threat model और दायरा है। इससे सामान्य प्रतिक्रिया माँगने की तुलना में छोटा और अधिक लागू करने योग्य परिणाम मिलता है।
tool बदलाव के बाद दस्तावेज़ीकरण अपडेट करना
समस्या
local setup command बदल गया है और getting-started guide अब पुरानी हो गई है।
कमज़ोर प्रॉम्प्ट
setup documentation अपडेट करें।
बेहतर प्रॉम्प्ट
वर्तमान package scripts के लिए local setup guide अपडेट करें।
हर दस्तावेज़ित command को package.json और repository के setup
instructions के साथ सत्यापित करें। prerequisites, अपेक्षित ready output, सामान्य failure
signals और सुरक्षित recovery path समझाएँ।
secrets, local environment से कॉपी किए गए values या ऐसे commands दस्तावेज़ित न करें
जिन्हें project वास्तव में नहीं चलाता। नए contributor के लिए एक छोटी validation checklist जोड़ें।
यह क्यों काम करता है
सहायक को सुघड़ लेकिन काल्पनिक guide लिखने के बजाय prose को repository के आधार पर तैयार करना पड़ता है।
अपने कार्य से मेल खाता उदाहरण चुनें
दोहराया जाने वाला पैटर्न सरल है: समस्या का नाम दें, दायरा सीमित करें, महत्वपूर्ण व्यवहार सुरक्षित रखें, साक्ष्य माँगें और सत्यापन परिभाषित करें। दोबारा इस्तेमाल किए जा सकने वाले ढाँचे के लिए बेहतर AI प्रॉम्प्ट कैसे लिखें से शुरू करें, फिर इंजीनियरिंग भूमिका के अनुसार व्यवस्थित वर्कफ़्लो के लिए डेवलपर्स के लिए प्रॉम्प्ट इंजीनियरिंग देखें।
production issues को और सख्त evidence trail चाहिए। किसी सहायक से live-system fix प्रस्तावित करने के लिए कहने से पहले production issues को डीबग करने के प्रॉम्प्ट टेम्पलेट देखें। जब किसी बग में shell output या script शामिल हो, समाधान स्वचालित करने से पहले ब्राउज़र में command-line workflow को पुन: उत्पन्न करें।
संदर्भ
ये दस्तावेज़ लिंक इस लेख में उपयोग किए गए कमांड के लिए आधिकारिक विवरण प्रदान करते हैं।