Claude Opus 5 के लिए Anthropic की आधिकारिक प्रॉम्प्ट गाइड

Opus 5 उत्कृष्ट है, लेकिन इसका व्यवहार पहले से अलग है, जिससे इसे संभालना मुश्किल हो जाता है।

हालांकि, यह मॉडल की कोई समस्या नहीं है। इसका कारण यह है कि पिछले मॉडलों के लिए सही रहे अनुरोध विधियों और सेटिंग्स का अभी भी उपयोग किया जा रहा है।

Anthropic ने आधिकारिक तौर पर Opus 5 के लिए एक प्रॉम्प्ट गाइड जारी किया है।

इसमें कहा गया है कि जिन निर्देशों को पहले "सही" माना जाता था, वे अब प्रतिकूल हैं।

यदि आप यह जाने बिना इसका उपयोग करना जारी रखते हैं, तो आप उन्हीं कार्यों के लिए पहले से अधिक टोकन खर्च करते रहेंगे।

क्या यह परिचित लगता है?

• प्रतिक्रियाएँ इतनी लंबी होती हैं कि पढ़ना थकाऊ हो जाता है
• कार्यों के दौरान लाइव कमेंट्री बहुत विस्तृत होती है
• यह काम के दायरे को उन क्षेत्रों में विस्तारित करता है जो आपने नहीं मांगे थे
• यह कई उप-एजेंट लॉन्च करता है, जिससे लागत आसमान छूने लगती है
• यह हर बार अनावश्यक रूप से लंबे दस्तावेज़ लिखता है

यदि इनमें से एक भी आप पर लागू होता है, तो यह लेख आपके लिए मददगार होगा।

ये सभी व्यवहार हैं जिन्हें आधिकारिक गाइड कहता है कि "इन निर्देशों से ठीक किया जा सकता है।"

इस लेख में, मैं आधिकारिक गाइड में बताए गए 11 बदलावों और समाधानों को सरल तरीके से पेश करूँगा।

अंत में, मैंने आज से ध्यान देने योग्य बिंदुओं को संक्षेप में बताया है, इसलिए कृपया इसे बुकमार्क करें और इसका पूरा उपयोग करें।

एक त्वरित प्रचार के रूप में, मैं वर्तमान में Claude Code की पाठ्यपुस्तक, इंस्टॉलेशन विधियाँ, और मुद्रीकरण रणनीतियों सहित 55 प्रमुख लाभ मुफ्त में दे रहा हूँ। आप इन्हें नीचे दिए गए लिंक से तुरंत प्राप्त कर सकते हैं, इसलिए यदि आपने अभी तक नहीं लिया है, तो कृपया लें।

↓

https://utage-system.com/line/open/cwgwX1a35XDK?mtid=FNAamIuYaEet

अब, मुख्य विषय पर आते हैं।

**

क्या जारी किया गया?

Anthropic के आधिकारिक दस्तावेज़ीकरण में विशेष रूप से Opus 5 के लिए एक प्रॉम्प्ट पेज जोड़ा गया है।

यह केवल एक सुविधा सूची नहीं है। यह एक व्यावहारिक पेज है जो "Opus 5 पिछले मॉडलों से इन मामलों में अलग है, इसलिए इसे इस तरह निर्देशित करें" पर केंद्रित है। केवल प्रॉम्प्टिंग से संबंधित प्रदर्शन सुधार सूचीबद्ध हैं।

एक पूर्व शर्त के रूप में, आधिकारिक गाइड कहता है कि Opus 4.8 के लिए लिखे गए प्रॉम्प्ट अभी भी काफी हद तक काम करेंगे। हालांकि, कुछ ऐसे व्यवहार हैं जिनमें ट्यूनिंग की आवश्यकता होती है।

दूसरे शब्दों में, यह काम करता है, इसलिए आपको पता नहीं चलता। बिना ध्यान दिए बर्बादी के लिए भुगतान करते रहना सबसे नुकसानदेह पैटर्न है।

1. प्रतिक्रियाएँ लंबी होती हैं। प्रयास कम करने से बातचीत की मात्रा कम नहीं होती

Opus 5 की प्रतिक्रियाएँ पिछले मॉडलों की तुलना में लंबी होती हैं। यह आधिकारिक तौर पर स्वीकार किया गया है।

मुश्किल बात यह है कि "effort" (सोचने की क्षमता) कम करने से बातचीत की मात्रा में कमी की गारंटी नहीं मिलती। आधिकारिक गाइड स्पष्ट रूप से कहता है, "Effort सोचने की मात्रा को नियंत्रित करता है, बात करने की मात्रा को नहीं।"

यदि आप लंबाई कम करना चाहते हैं, तो आपको स्पष्ट रूप से लंबाई का निर्देश देना होगा। यहाँ आधिकारिक गाइड द्वारा प्रदान किया गया निर्देश है:

1प्रतिक्रियाओं को छोटा और सीधा रखें।
2प्रस्तावना और अस्वीकरण को कम से कम करें, और उत्तर के लिए कैरेक्टर काउंट का उपयोग करें।
3जब मैं स्पष्टीकरण माँगूँ, तब तक केवल मुख्य बिंदुओं का सारांश लौटाएँ जब तक कि मैं यह न कहूँ कि मैं अधिक विस्तार से जानना चाहता हूँ।

जिनके पास लंबे CLAUDE.md या सिस्टम प्रॉम्प्ट हैं, वे इसे लिखें और फिर अंत में एक छोटा रिमाइंडर रखें। आधिकारिक गाइड भी इस विधि की सिफारिश करता है।

1<tone_preference>
2आउटपुट को संक्षिप्त रखें।
3</tone_preference>

लंबे निर्देश सेट के बीच में दबे निर्देश कम प्रभावी होते हैं। अंत में एक रिमाइंडर इसकी भरपाई करता है।

जो सेटिंग्स का उपयोग नहीं करते, उनके लिए यह और भी आसान है। जब आपको लगे कि यह बहुत लंबा है, तो वहीं "इसे छोटा रखें" कहें।

2. कार्यों के दौरान बहुत अधिक लाइव कमेंट्री

Opus 5 काम करते समय बहुत बात करता है। यह हर बार यह घोषित करता है कि वह क्या करने वाला है, और प्रति संदेश आउटपुट पिछले मॉडलों से अधिक लंबा होता है।

इसे कम करने का तरीका "लाइव कमेंट्री मत दो" कहना नहीं है। आप लिखते हैं कि आप कब और किस रूप में रिपोर्ट चाहते हैं।

1काम शुरू करने से पहले, आप जो करने जा रहे हैं उसके बारे में केवल एक वाक्य कहें।
2काम के दौरान केवल तभी रिपोर्ट करें जब आपको कुछ महत्वपूर्ण मिले या जब आप दिशा बदलें।
3समाप्त होने पर, पहले निष्कर्ष लिखें। पहले वाक्य में "आपने क्या किया" और "आपको क्या मिला" का उत्तर दें, और विवरण बाद के लिए छोड़ दें।

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

3. लिखे गए दस्तावेज़ हमेशा लंबे होते हैं

बातचीत की लंबाई के अलावा, फ़ाइलों में लिखी गई चीज़ें (रिपोर्ट, md दस्तावेज़, सारांश) भी लंबी होती हैं।

यह उन लोगों के लिए प्रभावी है जो AI से शोध परिणामों को मार्कडाउन में सेव करवाते हैं। लंबाई के मानक के लिए बस एक पंक्ति जोड़ने से फर्क पड़ता है।

1फ़ाइलों में लिखे गए दस्तावेज़ों को आवश्यक लंबाई के भीतर रखें।
2सामग्री को न छोड़ें, लेकिन केवल जगह भरने के लिए अध्याय, एक ही सामग्री की बार-बार की गई सारांश, या मानक प्रस्तावना से इसे लंबा न करें।

4. "हमेशा सत्यापित करें" और "दोबारा जाँच करें" अनावश्यक हैं

यह सबसे बड़ा बिंदु है।

स्पष्ट रूप से कहें तो, यदि आपकी सेटिंग्स में कुछ नहीं लिखा है, तो आप इसे वैसे ही छोड़ सकते हैं। यह आइटम "इसे हटाने के बारे में है यदि यह लिखा है" और "व्यक्तिगत निर्देशों में इसे न कहने के बारे में है।"

Opus 5 अपने काम को स्वयं सत्यापित करता है, भले ही उसे बताया न जाए। इसलिए, आधिकारिक गाइड कहता है कि यदि आपके प्रॉम्प्ट में सत्यापन का आदेश देने वाले निर्देश हैं, तो उन्हें हटा दें। इन प्रकारों का विशेष रूप से नाम लिया गया है:

• "गैर-तुच्छ कार्यों के लिए अंत में हमेशा एक सत्यापन चरण शामिल करें"
• "सत्यापन के लिए एक उप-एजेंट का उपयोग करें"
• "उत्तर देने से पहले दोबारा जाँच करें"

ये Opus 5 के अंतर्निहित सत्यापन के साथ ओवरलैप होते हैं और अति-सत्यापन का कारण बनते हैं। आधिकारिक विवरण कहता है, "इन्हें हटाने से गुणवत्ता में गिरावट के बिना बर्बाद टोकन कम होते हैं।" यह गुणवत्ता के साथ कोई समझौता नहीं है; यह केवल बर्बादी को समाप्त करता है।

यही बात तब भी लागू होती है यदि पुराने हार्नेस में सत्यापन चरण जोड़ने का कोई तंत्र बचा हुआ है।

दूसरी ओर, Opus 5 में सुधारों के लिए पिछले मॉडलों की तुलना में अधिक लाइव कमेंट्री है। यदि "मैं अपने पिछले बयान को सुधार रहा हूँ" बार-बार दिखाई देना परेशानी का कारण है, तो इसे हटाने के बजाय इसे सीमित करने के लिए निर्देश जोड़ें।

1पहले जो कहा था उसे केवल तभी सुधारें जब वह गलती मेरे कोड या निर्णय को बदल दे।
2सुधार को संक्षेप में बताएं और काम जारी रखें।
3मामूली टाइपो के लिए जो कुछ भी नहीं बदलते, उन्हें चुपचाप ठीक करें और आगे बढ़ें।

**

5. बिना पूछे दायरा बढ़ाना

Opus 5 अपने निर्णय के आधार पर काम के दायरे का विस्तार कर सकता है। यह वे कदम जोड़ता है जो आपने नहीं मांगे थे। यह फिर से तय करता है कि क्या किया जाना चाहिए।

उन कार्यों के लिए जहाँ आप दायरे को सीमित रखना चाहते हैं, स्पष्ट रूप से दायरे को बाँधें।

1वही करें जो मैंने पूछा, उसी दायरे में जो मैंने पूछा।
2मामूली निर्णय स्वयं लें। केवल तभी मुझसे जाँच करें जब व्याख्या के आधार पर परिणाम में महत्वपूर्ण परिवर्तन हो।
3यदि मेरा अनुरोध गलत लगता है या कोई बेहतर तरीका है, तो इसे एक वाक्य में बताएं और फिर अनुरोधित के अनुसार आगे बढ़ें।
4दायरे को अपने आप किसी और चीज़ में संकीर्ण, विस्तारित या न बदलें।
5अनुरोधित दायरे को अंत तक पूरा करें। वे काम न करें जो मैंने स्पष्ट रूप से नहीं मांगे थे।

इसे शामिल करने से उन दुर्घटनाओं में कमी आती है जहाँ "एक फ़ाइल ठीक करें" पूरे प्रोजेक्ट को बदलने में बदल जाता है।

6. बहुत अधिक उप-एजेंट बनाना

Opus 5 पिछले मॉडलों की तुलना में अधिक आसानी से उप-एजेंटों को काम सौंपता है।

सौंपना अपने आप में बुरा नहीं है। आधिकारिक गाइड कहता है कि यह वास्तव में स्वतंत्र, बड़े कार्यों के लिए प्रभावी है। लेखक और सत्यापक को अलग करने का प्रारूप भी काम करता है, और इसका मूल्यांकन किया गया है कि एजेंटों के एक-दूसरे के काम को ओवरराइट करने की दुर्घटनाएँ दुर्लभ हैं।

समस्या तब है जब इसका उपयोग छोटे कार्यों के लिए किया जाता है। इकाइयों की संख्या के लिए लागत और समय सीधे जुड़ जाते हैं।

1केवल बड़े, स्वतंत्र कार्यों के लिए उप-एजेंटों को काम सौंपें जो समानांतर में किए जा सकते हैं (जैसे, एक विस्तृत श्रृंखला में कई फ़ाइलों पर शोध करना)।
2ऐसे कार्यों को उप-एजेंटों को न सौंपें जिन्हें आप स्वयं कुछ चरणों में पूरा कर सकते हैं।

उन लोगों के लिए भी एक तरकीब है जो सेटिंग्स नहीं लिखते। पूछते समय स्वयं इकाइयों की संख्या बताएँ। पहले संदेश में "उप-एजेंटों का उपयोग किए बिना स्वयं करें" या "यदि उपयोग करते हैं, तो अधिकतम X इकाइयाँ" डालें।

7. समीक्षाओं में "केवल मुझे प्रमुख मुद्दे बताएं" लिखने से चीज़ें छूटने का जोखिम बढ़ जाता है

Opus 5 कोड समीक्षाओं में मजबूत है। आधिकारिक गाइड कहता है कि एक बार में वास्तविक बग खोजने की इसकी दर अधिक है, और इसके द्वारा उठाए गए अतिरिक्त बिंदु अक्सर झूठे अलर्ट की तुलना में अधिक वास्तविक होते हैं। चूँकि कम प्रयास में भी सटीकता आसानी से नहीं गिरती, आप इसका उपयोग एक बार हल्की समीक्षा और बाद में गहन समीक्षा के लिए कर सकते हैं।

हालांकि, एक खतरा है। यदि आप समीक्षा प्रॉम्प्ट में "केवल प्रमुख समस्याओं की रिपोर्ट करें" या "रूढ़िवादी रहें" लिखते हैं, तो Opus 5 उस निर्देश का शाब्दिक रूप से पालन कर सकता है और रिपोर्टिंग कम कर सकता है।

आधिकारिक सिफारिश है कि "इसे सब कुछ रिपोर्ट करने दें और एक अलग चरण में फ़िल्टर करें।" इसे बाहर निकलने दें, फिर छोड़ दें। शुरू से ही इसे बाहर न निकलने देना नुकसान है।

पूछने का तरीका इस प्रकार है: "हर उस चीज़ की सूची बनाएं जिसके बारे में आप चिंतित हैं। उन्हें महत्व के अनुसार रैंक करें।" सूची देखने के बाद आप तय करें कि कौन से ठीक करने हैं।

8. low और medium को मुख्य effort स्तरों के रूप में उपयोग करें

Claude Code में, आप "/effort" से सोचने की मात्रा को बदल सकते हैं। Opus 5 में 5 स्तर उपलब्ध हैं: low, medium, high, xhigh, और max, जिसमें high डिफ़ॉल्ट है। केवल max उसी सत्र तक सीमित है; अन्य चार अगले सत्र में ले जाए जाते हैं।

आधिकारिक सिफारिश यह है: high से शुरू करें, और जहाँ गुणवत्ता नहीं गिरती, वहाँ सक्रिय रूप से low और medium का उपयोग करें ताकि लागत और प्रतीक्षा समय के लिए मुख्य नियंत्रण के रूप में उपयोग किया जा सके। भारी कोडिंग या एजेंट कार्यों के लिए ही xhigh तक बढ़ाएँ।

साइड-हसलर्स के लिए, यह प्रासंगिक है क्योंकि यदि आप इसे नहीं छूते हैं, तो आप हल्के कार्यों के लिए भी उच्च सोचने की क्षमता के लिए भुगतान करते रहेंगे। फ़ाइलें खोजने या सरल टेक्स्ट जनरेशन के लिए high की आवश्यकता नहीं है।

आधिकारिक गाइड यह भी कहता है कि यदि आप पिछले मॉडल युग की सेटिंग्स को ले जा रहे हैं, तो आपको अपने कार्यों के साथ पुनः माप करना चाहिए।

आज करने के लिए एक काम है। हल्का कार्य शुरू करने से पहले "/effort medium" टाइप करें। भारी कार्यान्वयन में प्रवेश करने पर ही "/effort high" पर वापस जाएँ। यह अकेला प्रतीक्षा समय और खपत को बदल देगा।

**

9. शुरुआत में सभी विशिष्टताएँ प्रदान करें और इसे अकेला छोड़ दें

अब से, यह इस बारे में है कि प्रदर्शन में सुधार के कारण आपको पूछने का तरीका कैसे बदलना चाहिए।

आधिकारिक गाइड Opus 5 को "कठिन कोडिंग में सबसे मजबूत" के रूप में स्थान देता है। सूचीबद्ध विशेषज्ञता के क्षेत्रों में कई फ़ाइलों में सुविधाएँ जोड़ना, बड़े पैमाने पर रीफैक्टरिंग, और सुविधाओं को पूरी तरह से समाप्त करना शामिल है। यह भी स्पष्ट रूप से कहा गया है कि यह स्टब्स या "यह बाद के लिए है" प्लेसहोल्डर रखकर भागता नहीं है।

महत्वपूर्ण भाग यह है कि निर्देश कैसे दिए जाएँ। आधिकारिक तरीका यह है: प्रदर्शन सबसे अच्छा होता है जब आप शुरुआत में सभी कार्य विशिष्टताएँ देते हैं और फिर इसे चलने देते हैं।

Opus 5 में थोड़ा-थोड़ा करके निर्देश जोड़ना नुकसान है। पूछने से पहले सभी शर्तों को लिखना तेज़ है।

पहले संदेश में डालने के लिए ये चार चीज़ें पर्याप्त हैं: वे फ़ाइलें जिन्हें छूने की अनुमति है, कितनी दूर तक जाना है, जिन वादों को आप निभाना चाहते हैं, और यह तय करने की शर्तें कि यह समाप्त हो गया है। इसके चलने के बाद शर्तें जोड़ना सबसे धीमा है।

इसका उपयोग एक-पंक्ति सुधार जैसे हल्के कार्यों के लिए सामान्य रूप से किया जा सकता है, लेकिन आधिकारिक गाइड कहता है कि भारी कार्यों में पिछले मॉडलों से अंतर दिखता है।

10. छवियों के लिए घरेलू समाधान अनावश्यक हैं

चार्ट, दस्तावेज़ और आरेख पढ़ना, साथ ही UI और फ्रंट-एंड के स्वरूप को पुन: प्रस्तुत करना, मजबूत हो गया है।

आधिकारिक गाइड विशेष रूप से पिछले मॉडलों के लिए प्रॉम्प्ट में निर्मित छवि-संबंधित कामकाज की समीक्षा करने का उल्लेख करता है। वे अब आवश्यक नहीं रह सकते हैं।

एक और बात है। छवियों के साथ सटीकता सबसे अधिक होती है जब आप इसे मॉडल को स्वयं क्रॉपिंग या दृश्य पुष्टि करने देने के लिए उपकरण देते हैं। यह स्पष्ट रूप से कहा गया है कि effort स्तर बढ़ाने की तुलना में उपकरण देना अधिक लागत प्रभावी है।

यदि Claude Code में इसका उपयोग कर रहे हैं, तो एक छवि चिपकाकर और राय माँगने के प्रारूप को रोकें। इसे छवि फ़ाइल का स्थान दें और इसे स्वयं खोलने, बड़ा करने और जाँचने दें, जबकि यह ठीक कर रहा हो। आपको effort स्तर बढ़ाने से पहले ऐसा करना चाहिए।

11. स्प्रेडशीट और Slides के लिए शैलियाँ पास करें

यह अब गैर-सरल फ़ार्मुलों सहित कई शीटों में स्प्रेडशीट बना सकता है। Slides भी एक सुव्यवस्थित संरचना के साथ आते हैं।

यहाँ आधिकारिक निर्देश केवल एक है: यदि कोई शैली या टेम्पलेट है जिसका आप इसे पालन करना चाहते हैं, तो इसे प्रॉम्प्ट में डालें।

उन लोगों के लिए जो हर बार बनाई गई सामग्री के स्वरूप को ठीक करते हैं, फिक्सिंग कार्य को बढ़ाने से पहले आपके द्वारा प्रदान की गई जानकारी को बढ़ाना तेज़ है।

सबसे तेज़ तरीका यह है कि आप स्वयं पहले बनाया गया एक दस्तावेज़ प्रदान करें और कहें, "इस प्रारूप से मिलान करें।" रंगों और फ़ॉन्ट को शब्दों में समझाने की तुलना में एक वास्तविक उदाहरण दिखाना तेज़ है।

सारांश

• प्रतिक्रिया और दस्तावेज़ की लंबाई effort स्तर से कम नहीं होती। स्पष्ट रूप से लंबाई का निर्देश दें।
• सत्यापन या दोबारा जाँच का आदेश देने वाले निर्देशों को हटा दें। Opus 5 बिना बताए ऐसा करता है।
• दायरे की बाधाओं और उप-एजेंट प्रतिनिधिमंडल की शर्तों को लिखना बेहतर है।
• समीक्षाओं के लिए, "इसे सब कुछ आउटपुट करने दें और बाद में फ़िल्टर करें।" इसे शुरू से फ़िल्टर न करने दें।
• low और medium को मुख्य effort स्तरों के रूप में उपयोग करें।
• विशिष्टताओं को थोड़ा-थोड़ा करके न दें; उन्हें शुरुआत में सभी दें और अकेला छोड़ दें। कार्य जितना भारी होगा, अंतर उतना ही बड़ा होगा।

जब मॉडल बदलता है, तो पूछने का "सही" तरीका भी पुराना हो जाता है।

पिछले साल सीखी गई युक्तियाँ अब केवल प्रतीक्षा समय और लागत बढ़ा रही होंगी।

मुझे उम्मीद है कि आप इसे बुकमार्क करेंगे और आज ही कम से कम एक चीज़ आज़माएँगे।

मैं आमतौर पर नवीनतम AI जानकारी और AI का उपयोग करके मुद्रीकरण विधियों के बारे में पोस्ट करता हूँ। यदि यह लेख मददगार था, तो कृपया मेरा अनुसरण करें।

अंत में,

मैं वर्तमान में Claude Code की पाठ्यपुस्तक, इंस्टॉलेशन विधियाँ, और मुद्रीकरण रणनीतियों सहित 55 प्रमुख लाभ दे रहा हूँ। यदि आपने अभी तक नहीं लिया है, तो कृपया उन्हें यहाँ प्राप्त करें।

https://utage-system.com/line/open/cwgwX1a35XDK?mtid=FNAamIuYaEet

संदर्भ पृष्ठ

https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5