प्रोग्रामरों के लिए Prompt Engineering Playbook

(addyo.substack.com)

23 पॉइंट द्वारा GN⁺ 2025-06-06 | 1 टिप्पणियां | WhatsApp पर शेयर करें

AI coding assistant डेवलपर्स की productivity बढ़ाते हैं, लेकिन उनके output की quality काफी हद तक prompt engineering पर निर्भर करती है
प्रभावी नतीजे पाने के लिए समृद्ध context, स्पष्ट goal, उदाहरण, role assignment, iterative improvement जैसे नियमों का पालन करना चाहिए
debugging, refactoring, नई feature implementation जैसे प्रमुख development tasks के लिए prompt design patterns और उदाहरण दिए गए हैं
अच्छे prompts में उद्देश्य, language, environment, error messages, input/output examples जैसी ठोस जानकारी होनी चाहिए
नए engineer भी follow कर सकें ऐसी prompt design विधि दी गई है, जिसमें वास्तविक AI responses की तुलना और comments शामिल हैं

अवलोकन: सफल prompt engineering का महत्व

हाल के समय में डेवलपर्स AI coding assistants का उपयोग करके function autocomplete, bug fixes, और पूरे module लिखने तक अपने workflow को तेज कर रहे हैं
लेकिन AI response की quality निर्णायक रूप से prompt की quality पर निर्भर करती है
अच्छे prompts स्पष्ट और रचनात्मक code solutions को प्रेरित करते हैं, जबकि अस्पष्ट या कमजोर prompts सीमित और बेअर्थ जवाबों तक ले जाते हैं
यह playbook रोज़मर्रा के development tasks में लागू की जा सकने वाली प्रभावी prompt design विधियों को व्यावहारिक रूप से व्यवस्थित करती है

प्रभावी code prompts के मूल सिद्धांत

समृद्ध context दें: AI को project या intent पहले से नहीं पता होता, इसलिए इस्तेमाल की जा रही language, framework, library, error message, code का उद्देश्य जैसी सभी प्रासंगिक जानकारी स्पष्ट लिखें
स्पष्ट goal या question रखें: “कोड क्यों नहीं चल रहा?” जैसे अस्पष्ट सवाल की जगह, अपेक्षित परिणाम और वर्तमान स्थिति को साफ़ तौर पर बताएं
जटिल काम को बाँटें: बड़े feature development जैसे काम एक ही बार में न माँगें; उन्हें छोटे steps में बाँटकर क्रमिक रूप से आगे बढ़ें
input/output examples या expected behavior शामिल करें: वास्तविक input-output या behavior examples देने से AI की समझ काफी बेहतर होती है ("few-shot prompting")
role (persona) का उपयोग करें: “React senior developer की तरह code review करो” या “performance expert की तरह optimize करो” जैसी भूमिकाएँ देकर AI response का स्तर बेहतर किया जा सकता है
conversation के माध्यम से iterative improvement करें: AI के पहले जवाब के आधार पर follow-up requests या revisions मांगकर धीरे-धीरे मनचाहा परिणाम प्राप्त करें
code consistency बनाए रखें: AI code style, naming, और comments को संदर्भ के रूप में देखता है, इसलिए code की consistency और clarity हमेशा बनाए रखें

debugging के लिए prompt patterns

व्यवस्थित debugging prompt design विधि

समस्या और symptoms को स्पष्ट लिखें: language, feature का उद्देश्य, expected behavior, actual error message, code snippet जैसी समृद्ध जानकारी दें
step-by-step या line-by-line analysis मांगें: logic errors या subtle bugs के लिए “हर लाइन पर variable trace करो” या code के हिस्सों की व्याख्या करवाकर कारण पता करें
minimum reproducible code का उपयोग करें: जटिल बड़े codebase की जगह, error पैदा करने वाले सबसे छोटे code sample को निकालकर समस्या पर फोकस करें
सीधे सवाल और follow-up requests करें: “bug कहाँ हो रहा है?”, “corrected code दो” जैसे स्पष्ट और दोहराए जा सकने वाले feedback requests करें

उदाहरण: खराब prompt बनाम बेहतर prompt

समस्या वाला code उदाहरण

function mapUsersById(users) {
  const userMap = {};
  for (let i = 0; i <= users.length; i++) {  
    const user = users[i];
    userMap[user.id] = user;
  }
  return userMap;
}
const result = mapUsersById([{ id: 1, name: "Alice" }]);

खराब prompt:

“mapUsersById function काम क्यों नहीं कर रहा?”

AI का जवाब: “array खाली हो सकती है या user में id नहीं हो सकती” जैसी अस्पष्ट अटकलें
context की कमी और अस्पष्टता के कारण सिर्फ सामान्य सलाह मिलती है

बेहतर prompt:

“mapUsersById function को user array को id के आधार पर map करना चाहिए, लेकिन [ {id: 1, name: "Alice"} ] input देने पर TypeError: Cannot read property 'id' of undefined error आ रहा है। code यह है: [code included] expected result { "1": ... } है। इस समस्या का कारण और समाधान क्या है?”

AI का जवाब: loop condition (i <= users.length) range से बाहर जा रही है, इसलिए आखिरी iteration में undefined बन रहा है; i < users.length करने का सुझाव देता है
ठोस context, error message, expected behavior देने से सटीक समाधान मिलता है

अतिरिक्त debugging prompt strategies

bug के संभावित कारणों की list मांगें (“TypeError के possible causes?” आदि)
code logic को खुद समझाकर review मांगें (“मेरी व्याख्या सही है या नहीं, समस्या बताओ”)
edge-case test cases मांगें (“ऐसे 2 inputs सुझाओ जिन पर यह function fail हो सकता है”)
सावधान code reviewer की role दें (“इस code को review करके issues और improvements समझाओ”)

refactoring/optimization के लिए prompt patterns

स्पष्ट improvement goals बताएं

“refactor करो” कहना अस्पष्ट है, इसलिए readability, performance, maintainability, code duplication हटाना जैसे ठोस goals बताएं
पूरा code (या आवश्यक context), environment, language, framework version पर्याप्त रूप से दें
changes की व्याख्या भी मांगें (“code के साथ improvement points भी बताओ”)
“TypeScript expert के रूप में latest conventions के अनुसार” जैसी role assignment से अपेक्षित quality बढ़ाई जा सकती है

उदाहरण: refactoring prompts की तुलना

मूल code

(duplicate fetch, inefficient data structures जैसी समस्याएँ शामिल)

async function getCombinedData(apiClient) {
  // Fetch list of users
  const usersResponse = await apiClient.fetch('/users');
  if (!usersResponse.ok) {
    throw new Error('Failed to fetch users');
  }
  // ... (rest omitted)
}

अस्पष्ट prompt

“getCombinedData function को refactor करो”

AI मनमाने ढंग से parallel fetch, error messages merge करना आदि बदलाव कर सकता है (क्योंकि requirements स्पष्ट नहीं हैं)

स्पष्ट goals वाला prompt

“duplication हटाओ, performance सुधारो, दोनों fetch को parallel करो, error messages अलग रखो, और data merging को efficient तरीके से सुधारो। comments और improvement points की explanation भी दो”

AI का जवाब: parallel fetch, अलग error handling, efficient map data structure जैसी चीज़ों को लक्ष्य के अनुरूप refactor करके विस्तार से समझाता है

अतिरिक्त refactoring tips

step-by-step requests करें (“पहले readability, फिर algorithm optimization”)
अलग approaches मांगें (“इसे functional style में भी implement करो”)
code+explanation format मांगकर सीखने और tutorial-style समझ को बढ़ाएं
final code के लिए tests जोड़ने को कहें

नई feature implementation के लिए prompt patterns

step-by-step code generation को प्रोत्साहित करें

पहले high-level description दें कि कौन-सी feature बनानी है, फिर धीरे-धीरे उसे छोटे हिस्सों में बाँटें
existing similar code, project patterns, इस्तेमाल की जा रही libraries जैसी working context जानकारी दें
comments या TODO को prompt की तरह इस्तेमाल करके IDE में सीधे AI के coding flow को guide करें
input/output examples या test cases देकर expected result स्पष्ट करें
अगर पहला result कमजोर हो, तो तुरंत specific improvements या code style expectations जोड़कर दोबारा request करें

उदाहरण: React ProductList component बनाना

“ProductList नाम का React functional component बनाओ। /api/products से products array लाकर list में दिखाओ, और input box में product name डालने पर case-insensitive filtering हो। fetching के दौरान loading और error handling भी चाहिए।”

AI response: useState, useEffect से data fetch, input handling, filtering, error और loading UI implementation आदि शामिल करता है
अगर project में custom hook इस्तेमाल हो रहा हो, तो “इसे useProducts() hook का उपयोग करने के लिए refactor करो” जैसे अतिरिक्त निर्देश बार-बार दिए जा सकते हैं

practical prompt refinement के उदाहरण

“sorting feature जोड़ो: A-Z, Z-A dropdown होना चाहिए” जैसी क्रमिक feature expansion requests की जा सकती हैं
implementation flow को steps में बाँटकर, हर step के लिए अलग prompt देकर code quality और consistency बनाए रखी जा सकती है

निष्कर्ष

AI coding assistants की क्षमता का अधिकतम उपयोग करने के लिए prompt design एक core skill है
सफल prompts लिखने के लिए हमेशा ठोस context, उद्देश्य, उदाहरण, iterative feedback, role assignment को ध्यान में रखना चाहिए
AI को project के भीतर एक junior developer या code reviewer की तरह मानकर, उसे विस्तार से दिशा देना और धीरे-धीरे quality बढ़ाना ही सफलता की कुंजी है

1 टिप्पणियां

GN⁺ 2025-06-06

Hacker News राय

मेरे अनुभव में असली prompt engineering तकनीकें सिर्फ़ तीन ही हैं
- In Context Learning (कॉन्टेक्स्ट के भीतर examples देना, यानी one-shot या few-shot तरीका, zero-shot के मुकाबले)
- Chain of Thought (स्टेप-बाय-स्टेप सोचने का निर्देश देना)
- Structured output (जैसे JSON की तरह output format को साफ़-साफ़ तय करना)
  इसके अलावा इस लेख में बताए गए Role Prompting को भी जोड़ा जा सकता है
  RAG को मैं अलग श्रेणी में रखता हूँ क्योंकि उसमें model दिए गए context का summary बनाता है
  आखिरकार बाकी सब बस इस बात का सार है कि जो चाहिए उसे साफ़ और सरल भाषा में कैसे माँगा जाए
- prompt में context सबसे अहम तत्व है
  उदाहरण के लिए, Typescript से शुरू करके data science का सवाल पूछें तो अक्सर ठीक जवाब नहीं मिलता
  वही सवाल Python में पूछें तो जवाब काफ़ी बेहतर आता है
  LLM अभी भी domains के बीच knowledge transfer में कमज़ोर हैं, इसलिए उद्देश्य के हिसाब से सही context सेट करना ज़रूरी है
- Role prompting भी मुझे निजी तौर पर ज़्यादा अर्थपूर्ण नहीं लगता
  GPT-3 के समय ऐसा रहा हो, लेकिन ज़्यादातर LLM पहले से ही "expert" की भूमिका जानते हैं
  "prompt engineering" पर ज़रूरत से ज़्यादा फ़ोकस करना मुझे अपने-आप को धोखा देना लगता है
  requirements को साफ़ बताना, ज़रूरत हो तो examples जोड़ना, output या reasoning trace देखना, और मनचाहा न मिले तो उसे adjust करके फिर कोशिश करना — यही तरीका है
  और अगर कई बार कोशिश के बाद भी जवाब न मिले, तो AI की जगह अपने दिमाग़ से reasoning करना भी एक विकल्प है
- बहुत से लोगों की समस्या यह है कि वे "सब कुछ एक ही prompt में ठूँसने" की कोशिश करते हैं
  इसके बजाय एक बड़ा request एक साथ देने के बजाय उसे छोटे contexts वाले कई prompts में बाँटकर, हर एक के structured outputs को आपस में जोड़ने का तरीका बेहतर है
  हर prompt में उसके उद्देश्य और examples पर फ़ोकस करें, context overload से बचें
  तब ऊपर बताए गए तीनों core तरीके अपने-आप लागू हो जाते हैं
- तीसरे तरीके (Structured output) से जुड़ा एक applied case study मैंने और मेरे सहकर्मियों ने science क्षेत्र में किया है
  paper link
- संदर्भ के लिए, हमारी team prompt engineering से ज़्यादा fine tuning पर निर्भर करती है
  few-shot prompt तरीका हमारे case में असरदार नहीं था
मुझे अक्सर लगता है कि जब prompt बहुत लंबा या बहुत जटिल हो जाता है, तो model की cognitive performance उल्टा गिर जाती है
जटिल prompt से control का एहसास ज़रूर हो सकता है, लेकिन असल में यह हमेशा फ़ायदेमंद नहीं होता
इसलिए मेरा usage pattern स्वाभाविक रूप से बहुत simple और minimal prompts से मोटा-मोटी fit करने और फिर कुछ बार दोहराकर सुधारने की ओर चला गया है
- मैंने भी बिल्कुल यही approach अपनानी शुरू की
  1. केवल ज़रूरी context, assumptions और goal संक्षेप में देना
  2. जवाब देखकर शुरुआती prompt को revise करना
    यह तरीका cost-efficiency के लिहाज़ से भी अच्छा है
    agents इस्तेमाल करके $30 तक उड़ा दिए और codebase उलझ गया या फिर वापस मूल code पर लौट आया — ऐसा बहुत बार हुआ
    और मैं यह चेतावनी भी देना चाहूँगा कि अगर AI को अपने project में बहुत सारा code लिखने दें, तो बाद में वह code दिमाग़ में ठीक से नहीं रहता और maintain करना भी मुश्किल हो जाता है
- इस बात के भी सबूत हैं कि अगर prompt में experts वाली terminology इस्तेमाल करें तो performance बेहतर होती है
  आम तौर पर लोग रोज़मर्रा की भाषा में बात करें तो accuracy कम होती है, लेकिन किसी specific domain की vocabulary ज़्यादा reliable जवाबों की ओर ले जाती है
  training data की distribution भी यही दिखाती है
- मेरा भी ऐसा ही अनुभव रहा है
  लेकिन जब agent systems के system prompts देखता हूँ, तो वे अक्सर बेहद लंबे और जटिल होते हैं, इसलिए सवाल उठता है
  सच में ऐसे prompts कैसे काम करते हैं, यह जानने की जिज्ञासा है
  system prompt examples link
- कुछ कामों में मेरे एक सहकर्मी ने बहुत लंबा-चौड़ा prompt इस्तेमाल किया
  integration process में CRUD operations जोड़ते समय, मैंने प्रयोग के तौर पर उसे बस इतना छोटा कर दिया: "इसे <job role> के नज़रिए से analyze करो"
  नतीजे में दोनों outputs लगभग एक जैसे थे, बल्कि लंबे prompt में कुछ वाक्य ज्यों-के-त्यों output में दोहराए भी गए
  result अपने-आप में ठीक था, लेकिन आख़िरकार model (gemini 2.5) ने सिर्फ़ ज़रूरी जानकारी निकाली और बाक़ी अनावश्यक हिस्सों को भी output में मिला दिया
  यानी कम-से-कम इस task में verbosity model के "सोचने के तरीके" पर कोई खास दिलचस्प असर नहीं डाल पाई
- मैं भी इसी निष्कर्ष पर पहुँचा हूँ, लेकिन AI labs द्वारा दिए गए लंबे prompts के examples को कैसे समझना चाहिए, यह जानना चाहता हूँ
  Anthropic system prompt example
मुझे लगता है कि "prompt engineering" नाम की कोई अलग चीज़ है ही नहीं
कब से अर्थपूर्ण वाक्य ठीक से लिखना engineering कहलाने लगा, यह समझ नहीं आता
मुझे तो यह "software engineering" से भी एक कदम आगे की बात लगती है
हाँ, अफ़सोस की बात यह है कि आगे चलकर यह भी एक profession (prompt engineer) बन सकता है, और वाक्य लिखने की कोई ख़ास skill की तरह स्थापित हो सकता है
- असल में "ठीक से अर्थपूर्ण वाक्य" लिखना अनगिनत variables पर निर्भर करता है
  व्यवहार में testing, management, logging और version control तक शामिल हो जाएँ, तो यह सिर्फ़ intuition नहीं, engineering बन जाता है
  specific order/style/problem restatement जैसी structuring बहुत महत्वपूर्ण है
  अगर कई parameters वाले family models के साथ काम कर रहे हों, तो API-based models में हर version update पर पुराने prompts के साथ compatibility check करना पड़ता है
  ऐसे checks और tests भी prompt engineering की प्रक्रिया का हिस्सा हैं
  मुझे लगता है कि hype से चिढ़ने के चलते लोग कई बार मूल बात ही नज़रअंदाज़ कर देते हैं
- अगर हमारे मोहल्ले का barista अपने नाम के साथ coffee engineer लिखे, तो शायद उस पर ज़्यादा भरोसा हो जाए
- algorithms की लत के कारण आजकल consumers की पूरी sentences पढ़ने की क्षमता तक कमज़ोर हो गई है
- मुझे नहीं लगता कि "prompt engineer" की jobs को लेकर चिंता करने की ज़रूरत है
- AI sloperators बस अपने काम को ज़्यादा प्रभावशाली दिखाने की कोशिश में लगे रहते हैं
मेरे अनुभव में LLM जिस समस्या को हल नहीं कर पाते, उसे कितना भी "engineer" कर लें, prompt से अक्सर फ़र्क नहीं पड़ता
उसके बजाय उसे subproblems में बाँटकर थोड़ा-थोड़ा आगे बढ़ाना ही एकमात्र तरीका बचता है
अगर किसी का उल्टा अनुभव रहा हो, तो उदाहरण सुनना चाहूँगा
- LLM इस्तेमाल करने का एक अहम हिस्सा यह समझ विकसित करना है कि समस्या को सही तरह से कैसे तोड़ा जाए
  कब और कैसे तोड़ना है, और कब बस सीधे model को सौंप देना है — यह पहचानना ज़रूरी है
  जैसा लेख में भी कहा गया, यह तरह-तरह का know-how महत्वपूर्ण है
  आगे चलकर code को और बेहतर organize/comment करके LLM के साथ interaction सुधारने के बहुत तरीके सामने आएँगे
  LLM खुद भी धीरे-धीरे इसी दिशा में evolve होंगे, और शायद समस्या को तोड़ने के तरीके सुझाने तक पहुँच जाएँगे
- prompt engineering का लक्ष्य मनचाहे format में, और ज़्यादा तेज़ी से, अच्छे solutions पाना है
  आदर्श रूप से हम चाहेंगे कि model खुद ही सब समझकर जवाब दे, लेकिन व्यवहार में सवाल को optimize करना भी ज़रूरी है
prompts लिखते समय मेरी पुरानी आदतों के कारण अब भी natural language में निर्देश देना थोड़ा अटपटा लगता है
ऐसा महसूस होता है जैसे मुझे इसे किसी exact argument या SQL query की तरह लिखना चाहिए
chat की तरह या किसी tool से बात करते हुए निर्देश देना भी अजीब-सा लगता है
फिर भी, यह कि tools अब natural language instructions समझते हैं, accessibility को नाटकीय रूप से बढ़ाता है
इसके बावजूद, अपने-आप को किसी इंसान की तरह prompt लिखते देखना अब भी थोड़ा मज़ेदार लगता है
आजकल prompt guides जैसी चीज़ें बहुत ज़्यादा हैं
लेकिन मुझे लगता है कि वास्तव में उनकी उतनी ज़रूरत नहीं
tool को खुद इस्तेमाल करके, उससे familiar होकर और उसका usage सीखकर, आप स्वाभाविक रूप से समझ जाते हैं कि अच्छा prompt क्या होता है
- यह कुछ वैसा ही है जैसे पुराने समय में Google का craze और FOMO था
  कहा जाता था कि अगर इस पर किताबें नहीं ख़रीदीं तो आदिमानव की तरह पीछे रह जाओगे, जबकि हक़ीक़त में यह इतना simple क्षेत्र था कि एक दिन में सीखा जा सकता था, इसलिए ज़्यादा जटिल सोचने की ज़रूरत नहीं थी
- guides और tips वाले videos कुछ लोगों के लिए सच में मददगार होते हैं
  बहुत से लोग खुद से सुधार करने की इच्छा नहीं रखते, लेकिन एक बार कोई guide या expert का video देख लेने भर से उनका level ऊपर उठ जाता है
  मैं खुद भी दूसरों के usage patterns या community experiences से बार-बार tips सीखता हूँ
  सिर्फ़ अकेले practice करने से ऐसे tips पाना सीमित होता है
- पहले "user story writing guide" जैसा एक formula हुआ करता था:
  “As a [role], I want to [task] so I can [objective]”
  experts हों या beginners, लगभग सभी को clear requirements communicate करने में मदद की ज़रूरत पड़ती है
  कोई developer कितना भी अच्छा क्यों न हो, unstructured requirements पर वह गलती कर सकता है या ग़लत समझ सकता है
- दूसरे लोग इस tool से productivity कैसे निकालते हैं, यह देखना भी काफ़ी उपयोगी है
  इससे ऐसे ideas मिल जाते हैं जो मैंने खुद miss किए होते
  trial and error से सब कुछ खुद करने से पहले, अगर किसी और के किए हुए अनुभव से थोड़ा भी सीख लें तो वह ज़्यादा efficient है
  निजी तौर पर, मेरे पास हर चीज़ खुद आज़माने का समय नहीं होता, इसलिए ऐसे अनुभवों की साझेदारी बहुत क़ीमती लगती है
- कुछ कम दिखाई देने वाले tricks भी ज़रूर होते हैं
  जैसे, मेरा अनुभव है कि prompt में “please” जैसे विनम्रता वाले शब्द पूरी तरह हटाए जा सकते हैं
बहुत पहले computer science graduate school में programming science (Science of programming) course के दौरान सीखी verification process को मैंने data engineering prompts लिखने में अच्छी तरह लागू किया
उदाहरण के लिए, "input(…) और assumptions(…) देकर, post-condition(…) को satisfy करने वाला spark code लिखने को कहना"
input, assumptions और result conditions को साफ़-साफ़ लिखने पर अच्छा code output मिल सकता है
संदर्भ पुस्तकें
1. Science of programming, David Gries
2. Verification of concurrent and sequential systems
prompt engineering को लेकर बहुत ज़्यादा उत्साहित होना मुझे कुछ ज़्यादा ही लगता है
बस code या error को copy-paste करके सीधा plain question पूछ दें, आजकल के models ज़्यादातर चीज़ें अपने-आप ठीक से संभाल लेते हैं
इसे बेवजह ज़रूरत से ज़्यादा पेचीदा बनाने की मुझे ज़रूरत नहीं लगती
कुछ दिन पहले Sergey Brin ने AI community में कम चर्चा होने वाली बात बताते हुए कहा कि "physical threat देने पर model performance बेहतर हो जाती है"
related article
- इससे YouTube के “Programmers are also human” में एक pro vibe coder का मज़ाक याद आता है, जो LLM commands के अंत में हमेशा “.. नहीं तो जेल जाओगे” जोड़ता है
- तो क्या इसी वजह से Google ने चुपचाप "Don't Be Evil" छोड़ दिया?
prompt लिखने को "engineering" कहना मुझे बहुत गंभीरता से लेने लायक नहीं लगता
- पहले जब prompt "engineering" का trend चल रहा था, तब एक मज़ेदार तुलना सुनी थी
  
  prompt engineer को कहना वैसा ही है जैसे Subway sandwich दुकान के कर्मचारी को "sandwich artist" कहना
  मज़ाक अपनी जगह, लेकिन engineer शब्द अब इतना व्यापक रूप से इस्तेमाल होने लगा है कि उसका लगभग कोई मतलब नहीं बचा
  Sandwich Artist info link
- आख़िरकार यह वही बहस है जो software engineering की बात आते ही बार-बार लौट आती है
- हो सकता है कि लोगों की कल्पना बस chat interface में बिल्ली की तस्वीर माँगने तक ही अटकी हो
  जबकि वास्तव में prompts API और automated workflows में भी इस्तेमाल होते हैं, इसलिए यह उससे कहीं ज़्यादा है
- अमेरिका में "sales engineer" जैसी job title भी होती है, लेकिन मेरे अनुभव में इनमें से कई लोगों को अपने बेचे जा रहे product के काम करने का तरीका तक नहीं पता होता
- IT वह जगह है जहाँ शब्द और उनके अर्थ गायब हो जाते हैं
  कभी-कभी तो लगता है कि क्या शब्दों का अपना मूल अर्थ होना भी ज़रूरी है?