เทคนิคพร้อมท์ Claude Opus 5: ไม่ต้องสั่งให้ตรวจสอบซ้ำ

คู่มือการย้ายข้อมูลส่วนใหญ่จะบอกคุณว่าอะไรเสียไปในโค้ดของคุณ คู่มือนี้จะเกี่ยวกับสิ่งที่เสียไปในพรอมต์ของคุณ

Claude Opus 5 เปิดตัวเมื่อวันที่ 24 กรกฎาคม 2026 และ Anthropic ได้เผยแพร่ คู่มือการใช้งานพรอมต์โดยเฉพาะ พร้อมกับการเปิดตัว คู่มือดังกล่าวได้บันทึกสิ่งหนึ่งที่ควรให้ความสนใจ: คำสั่งหลายอย่างที่ทำให้ Opus 4.8 ทำงานได้ดีขึ้น กลับทำให้ Opus 5 แย่ลง ไม่ใช่แย่ลงเพียงเล็กน้อย แต่แย่ลงอย่างเห็นได้ชัดในแง่ของค่าใช้จ่ายที่สูงขึ้น ความละเอียดที่มากขึ้น และในบางกรณีก็ใช้งานไม่ได้เลย

เหตุผลนั้นง่ายมาก Opus 5 ทำสิ่งที่คุณเคยต้องขอหลายอย่างด้วยตัวเองอยู่แล้ว เมื่อพรอมต์เก่าของคุณยังคงร้องขออยู่ คำสั่งนั้นจะไปเสริมกับพฤติกรรมที่โมเดลมีอยู่แล้ว คุณจะได้รับการตรวจสอบซ้ำสองครั้ง ไม่ใช่ความแม่นยำที่เพิ่มขึ้นเป็นสองเท่า

คู่มือนี้จะอธิบายการเปลี่ยนแปลงพฤติกรรมแต่ละอย่างที่บันทึกไว้ พร้อมกับตัวอย่างโค้ดพรอมต์ที่คุณสามารถคัดลอกและวางลงในพรอมต์ระบบของคุณได้ทันที นอกจากนี้ยังครอบคลุมถึงโหมดความล้มเหลวสองอย่างที่ปรากฏขึ้นเมื่อคุณปิดการคิด ซึ่งเป็นจุดเดียวที่พรอมต์ของ Opus 5 สามารถสร้างผลลัพธ์ที่ดูเหมือนปกติแต่แอบแฝงการทุจริตในวงจรเอเจนต์ หากคุณยังคงทำงานกับการเปลี่ยนแปลงระดับโค้ด คู่มือการย้ายจาก Opus 4.8 ไป Opus 5 จะครอบคลุมเรื่องเหล่านั้นแยกต่างหาก และหากคุณต้องการดูว่าพฤติกรรมเหล่านี้เปลี่ยนแปลงอย่างไรในเพย์โหลดคำขอและคำตอบจริง Apidog เป็นวิธีที่ตรงไปตรงมาในการส่งพรอมต์เดียวกันด้วยการตั้งค่าที่แตกต่างกันและเปรียบเทียบผลลัพธ์

สรุปในหนึ่งบรรทัด

Opus 5 ตรวจสอบมากขึ้น เขียนมากขึ้น มอบหมายงานมากขึ้น และอธิบายตัวเองมากขึ้นกว่าที่ Opus 4.8 เคยทำ พรอมต์ Opus 4.8 ของคุณถูกปรับแต่งมาเพื่อผลักดันโมเดลไปสู่พฤติกรรมเหล่านั้น แต่ตอนนี้มันกลับผลักดันเลยไป

ดังนั้นงานจึงเป็นการลบ คุณส่วนใหญ่กำลังลบคำแนะนำออก ไม่ใช่เพิ่มเข้าไป ส่วนที่คุณเพิ่มเข้ามาคือข้อจำกัด: ให้สั้นลง, อยู่ในขอบเขต, อย่าสร้างตัวช่วย

1. ลบคำสั่งการตรวจสอบของคุณ

นี่คือประเด็นสำคัญ และเป็นเหตุผลของหัวข้อนี้

Anthropic ระบุว่า Opus 5 ตรวจสอบงานของตัวเองโดยไม่ต้องมีการแจ้งล่วงหน้า มันจะอ่านซ้ำสิ่งที่เขียน ตรวจสอบการคำนวณ ทำการทดสอบซ้ำ และมองหาขอบเขตที่คุณไม่ได้กล่าวถึง นั่นคือพฤติกรรมที่ทุกคนเคยป้อนด้วยมือใน Opus 4.8 ด้วยคำสั่งเช่น “ตรวจสอบงานของคุณให้รอบคอบก่อนตอบกลับ” หรือ “ตรวจสอบแต่ละขั้นตอน”

หากคุณยังคงใช้คำสั่งเหล่านั้น คุณจะได้รับการตรวจสอบที่มากเกินไป โมเดลจะทำการตรวจสอบที่มันจะทำอยู่แล้ว บวกกับสิ่งที่คุณร้องขอ และคุณต้องจ่ายสำหรับทุกโทเค็นของการตรวจสอบนั้น ในการทำงานแบบเอเจนต์ที่ยาวนาน นี่คือค่าใช้จ่ายจริง ไม่ใช่แค่ความผิดพลาดในการปัดเศษ

วิธีแก้ไขคือการลบ ค้นหารูปแบบเหล่านี้ในพรอมต์ระบบของคุณแล้วลบออก:

Double-check your work before responding.
Verify each step before moving to the next one.
Review your answer for errors, then revise it.
Check your reasoning carefully.
Make sure the output is correct before returning it.

หากคุณมีขั้นตอนที่มีความเสี่ยงสูงอย่างแท้จริงที่คุณต้องการให้มีการตรวจสอบโดยละเอียด ให้จำกัดขอบเขตการตรวจสอบนั้นไว้เฉพาะขั้นตอนนั้น แทนที่จะตั้งเป็นกฎทั่วไป:

Do not add general verification passes; you already verify by default.
The only exception: after writing the migration SQL, run it against the
schema dump once and report any mismatch. Do not re-verify anything else.

รูปแบบนั้นสำคัญ คำสั่ง “ตรวจสอบทุกอย่าง” ทั่วโลกบน Opus 5 คือตัวคูณต้นทุน ข้อยกเว้นที่กำหนดขอบเขตเดียวคือการควบคุม

หากคุณกำลังติดตามค่าใช้จ่าย API ตลอดการย้ายข้อมูลนี้ ตัวควบคุมแคชและแบตช์ใน รายละเอียดราคา Opus 5 จะทำงานร่วมกับสิ่งนี้ และ คู่มือการลดค่าใช้จ่าย Claude API ของเราครอบคลุมตัวควบคุมทั่วไป

2. สั่งให้กระชับอย่างชัดเจน เพราะ 'effort' ไม่ได้ช่วยเรื่องนี้

การตอบสนองเริ่มต้นของ Opus 5 นั้นยาวกว่าของ Opus 4.8 รวมถึงผลงานที่เป็นลายลักษณ์อักษรด้วย เช่น รายงาน, สรุป, เอกสารออกแบบ และ README ที่มันสร้างขึ้นเมื่อคุณขอเอกสาร

นี่คือส่วนที่ทำให้ผู้คนสับสน การลดพารามิเตอร์ effort ไม่ได้แก้ไขปัญหานี้ Effort ควบคุมว่าโมเดลคิดมากน้อยเพียงใด ไม่ได้ควบคุมว่าโมเดลเขียนมากน้อยเพียงใด การลดจาก xhigh เป็น medium จะช่วยลดโทเค็นในการคิดลง ในขณะที่การตอบสนองที่มองเห็นได้ยังคงยาวเท่าเดิม หากคุณคิดว่า effort เป็นตัวควบคุมความละเอียด ค่าใช้จ่ายของคุณจะไม่เปลี่ยนแปลงตามที่คุณคาดหวัง คู่มือพารามิเตอร์ effort ของ Opus 5 ครอบคลุมสิ่งที่แต่ละระดับเปลี่ยนแปลงไปจริง ๆ

ความยาวเป็นปัญหาของพรอมต์ ดังนั้นให้แก้ไขที่พรอมต์ กำหนดขีดจำกัดสูงสุดให้ชัดเจน แทนที่จะบอกว่า “ให้สั้นๆ” ซึ่งโมเดลจะตีความอย่างกว้างขวาง:

Response format: at most 150 words unless I ask for more.
No preamble, no restatement of my question, no summary at the end.
Lead with the answer, then the reasoning if it is needed.

สำหรับผลงานที่เป็นลายลักษณ์อักษร ให้กำหนดขีดจำกัดบนผลงานนั้นและระบุสิ่งที่ต้องละเว้น:

Write the migration doc at 800 words maximum.
Include: the breaking changes, the fix for each, and a rollback step.
Exclude: background on the old system, a glossary, and a conclusion section.
If a section would exceed its share, cut examples before cutting steps.

สำหรับงานที่เน้นโค้ด ข้อจำกัดที่เทียบเท่ากันจะเกี่ยวกับความคิดเห็น ไม่ใช่โค้ด:

Return the diff and nothing else.
No explanation of what you changed unless the change is non-obvious,
in which case one sentence above the hunk.

3. จำกัดการมอบหมายงานให้ subagent

Opus 5 มอบหมายงานให้ subagent ได้ง่ายกว่า Opus 4.8 เมื่อได้รับงานที่มีหลายส่วนและเครื่องมือที่รองรับการสร้างงาน มันจะกระจายงานออกไป

นั่นมักจะเป็นการตัดสินใจที่ถูกต้อง แต่ก็เป็นการตัดสินใจด้านต้นทุนที่โมเดลทำแทนคุณ และ subagent แต่ละตัวก็มีบริบทและค่าใช้จ่ายโทเค็นของตัวเอง สำหรับเวิร์กโหลดที่คำนึงถึงต้นทุนหรือความหน่วง ให้กำหนดตัวเลขแทนที่จะปล่อยให้เป็นการตัดสินใจของโมเดล:

Do not spawn subagents for this task. Handle it in this conversation.

หรือในกรณีที่การกระจายงานมีประโยชน์จริง ๆ แต่ควรมีขีดจำกัด:

You may delegate to at most 2 subagents, and only for independent
file-level work that can run in parallel.
Do research, planning, and final synthesis yourself in this thread.

รูปแบบที่ควรหลีกเลี่ยงคือการมอบหมายงานเพื่อประโยชน์ของตัวเอง: การสร้าง subagent เพื่ออ่านไฟล์เดียว หรือเพื่อตัดสินใจที่เธรดหลักมีบริบทอยู่แล้ว หากคุณสร้างด้วย subagent โดยตั้งใจ คู่มือของเราเรื่อง การสร้าง Claude Code subagent จะครอบคลุมถึงวิธีการกำหนดขอบเขต

4. จำกัดขอบเขตอย่างชัดเจนสำหรับงานที่เฉพาะเจาะจง

Opus 5 ขยายขอบเขตงาน ขอให้แก้ไขการทดสอบที่ล้มเหลว มันอาจจะทำการปรับโครงสร้างตัวช่วยที่การทดสอบเรียกใช้ อัปเดต signature ของประเภท และเพิ่มกรณีทดสอบอีกสองกรณี ขอให้เปลี่ยนชื่อตัวแปร มันอาจจะจัดระเบียบฟังก์ชันรอบข้างให้เรียบร้อย

บางครั้งนี่เป็นคุณสมบัติที่ดี แต่สำหรับงานที่แคบและเฉพาะเจาะจง มันไม่ใช่: การปรับโครงสร้างที่ไม่ได้รับการร้องขอหมายถึง diff ที่ใหญ่ขึ้นสำหรับผู้ตรวจสอบ และรัศมีผลกระทบที่ใหญ่ขึ้นสำหรับการเปลี่ยนแปลงที่ควรจะเป็นแค่บรรทัดเดียว

ระบุขอบเขตว่าเป็นขอบเขต และระบุสิ่งที่ห้ามทำ:

Scope: change only the retry-count constant in src/client/http.ts.
Do not refactor surrounding code, do not rename anything, do not add
tests, do not update docs. If you believe another change is required,
stop and tell me instead of making it.

ข้อความสุดท้ายนั้นเป็นส่วนที่มีประโยชน์ หากไม่มีข้อความนี้ โมเดลจะไม่มีวิธีที่ได้รับอนุญาตในการแจ้งปัญหาที่แท้จริง ดังนั้นมันอาจจะทำการเปลี่ยนแปลงอยู่ดีหรือไม่ก็ละทิ้งข้อสังเกตไป แต่เมื่อมีข้อความนี้ คุณจะได้รับการแจ้งเตือนถึงข้อกังวลและ diff ที่ไม่เปลี่ยนแปลง

5. คาดหวังการบรรยายการแก้ไขที่มากขึ้น และปิดมันหากคุณไม่ต้องการ

Opus 5 บรรยายการแก้ไขของมันมากกว่า Opus 4.8 เมื่อมันเปลี่ยนใจกลางคันในการตอบสนอง มันจะบอกคุณ: มันจะแจ้งว่าวิธีการก่อนหน้านี้ผิดพลาด อธิบายเหตุผล และอธิบายการเปลี่ยนแปลง

สำหรับงานแบบโต้ตอบ สิ่งนี้มีประโยชน์ แต่สำหรับไปป์ไลน์ที่คำตอบส่งไปยัง parser, UI หรือโมเดลอื่น ๆ การบรรยายนั้นเป็นเพียงสัญญาณรบกวนที่อยู่ในช่องที่ควรจะมีคำตอบ

คำแนะนำสั้น ๆ คือ:

Do not narrate corrections or changes of approach.
Return only the final answer. If you revised your thinking, that
revision belongs in your reasoning, not in the response.

หากคุณส่งการตอบสนองไปยังที่เก็บข้อมูลแบบมีโครงสร้าง ให้จับคู่สิ่งนั้นกับเอาต์พุตที่มีโครงสร้างเพื่อให้มีการบังคับใช้รูปแบบแทนที่จะร้องขอ

โหมดความล้มเหลวเมื่อปิดการคิด

ทุกสิ่งที่กล่าวมาข้างต้นเป็นปัญหาในการปรับแต่ง ส่วนนี้เป็นปัญหาด้านความถูกต้อง

Anthropic ได้บันทึกสองสิ่งประดิษฐ์ที่ปรากฏขึ้นเป็นบางครั้งบน Opus 5 เมื่อปิดการคิดผ่าน thinking: {type: "disabled"} ทั้งสองอย่างนี้ควรทราบก่อนที่คุณจะนำเอเจนต์ไปใช้งานจริง

การเรียกใช้เครื่องมือที่เขียนเป็นข้อความธรรมดา โมเดลจะปล่อยสิ่งที่ดูเหมือนเป็นการเรียกใช้เครื่องมือ แต่เป็นข้อความในส่วนเนื้อหาของคำตอบแทนที่จะเป็นบล็อก tool_use ที่มีโครงสร้าง ไม่มีอะไรถูกดำเนินการ ในการสนทนาแบบรอบเดียว คุณจะสังเกตเห็น แต่ในวงจรเอเจนต์ คุณมักจะไม่สังเกตเห็น: วงจรไม่เห็นการเรียกใช้เครื่องมือ ดังนั้นจึงไม่มีการดำเนินการใด ๆ และข้อความที่รั่วไหลยังคงอยู่ในประวัติการสนทนา รอบถัดไปจะอ่านข้อความนั้นราวกับว่ามีการเรียกใช้เกิดขึ้น ความล้มเหลวจะสะสมไปเรื่อย ๆ ในแต่ละรอบ และเมื่อผลลัพธ์ดูผิดพลาด สาเหตุจะย้อนกลับไปหลายรอบแล้ว

แท็ก XML ภายในที่ปรากฏในผลลัพธ์ที่มองเห็นได้ แท็กเช่น <thinking> ปรากฏในคำตอบที่ผู้ใช้เห็น ซึ่งดูไม่สวยงามด้วยตัวมันเอง และแย่กว่านั้นหากคุณเรนเดอร์คำตอบเป็น HTML หรือแยกวิเคราะห์เพื่อหาโครงสร้าง

ส่วนที่ขัดกับสัญชาตญาณ: การระบุชื่อแท็กในพรอมต์ของคุณจะทำให้การรั่วไหลแย่ลง ไม่ใช่ดีขึ้น คำสั่งเช่น “ห้ามแสดงแท็ก <thinking>” จะนำลำดับโทเค็นนั้นเข้าสู่บริบทและเพิ่มโอกาสที่จะปรากฏขึ้น อย่าเขียนคำสั่งนั้น

คำแนะนำของ Anthropic ในการบรรเทาปัญหาไม่ใช่พรอมต์เลย แต่คือการเปิดใช้งานการคิดและควบคุมค่าใช้จ่ายด้วยระดับ effort ที่ต่ำลงแทน:

{
  "model": "claude-opus-5",
  "max_tokens": 4096,
  "output_config": { "effort": "low" },
  "messages": [
    { "role": "user", "content": "..." }
  ]
}

นั่นจะทำให้คุณได้รับช่วงราคาที่ถูกลงโดยไม่มีข้อบกพร่องจากการปิดการคิด นอกจากนี้ยังหลีกเลี่ยงกับดักที่เกี่ยวข้อง: ใน Opus 5 การรวม thinking: {type: "disabled"} กับ effort xhigh หรือ max จะส่งคืนค่า 400 เนื่องจากความสามารถในการปิดการคิดถูกจำกัดไว้ที่ effort ระดับ high โปรดทราบด้วยว่าตอนนี้การคิดจะเปิดใช้งานโดยค่าเริ่มต้น ดังนั้นคำขอที่ละเว้นฟิลด์ thinking เพียงอย่างเดียวจะทำงานด้วยการคิดแบบปรับตัวได้ แทนที่จะไม่มีการคิดเลย เหมือนที่เคยเป็นใน Opus 4.8

หากคุณมีความจำเป็นอย่างยิ่งที่จะต้องปิดการคิด ให้เพิ่มการตรวจสอบเชิงป้องกันในลูปของคุณ แทนที่จะเป็นคำสั่งในพรอมต์: ปฏิเสธการตอบกลับของผู้ช่วยที่มีเนื้อหาข้อความประกอบด้วยสตริงที่ดูเหมือนการเรียกใช้ที่ยังไม่ถูกดำเนินการ ก่อนที่จะผนวกเข้ากับประวัติการสนทนา ให้แจ้งข้อผิดพลาดอย่างชัดเจนแทนที่จะปล่อยให้มีการเรียกใช้ที่ไม่มีอยู่จริงเข้าไปในบันทึก

ทดสอบการเปลี่ยนแปลงแทนการคาดเดา

การเปลี่ยนแปลงพรอมต์เป็นเรื่องยากที่จะประเมินโดยการอ่าน พฤติกรรมที่กล่าวถึงในที่นี้ (ความยาวการตอบสนอง, จำนวนการตรวจสอบ, จำนวน subagent) จะปรากฏเป็นจำนวนโทเค็นและโครงสร้างเพย์โหลด ซึ่งหมายความว่าวิธีที่ตรงไปตรงมาที่สุดในการตรวจสอบงานของคุณคือการส่งคำขอและเปรียบเทียบ

สิ่งนี้สามารถตั้งค่าได้อย่างตรงไปตรงมาใน Apidog ซึ่งเป็นแพลตฟอร์มการพัฒนาและทดสอบ API แบบครบวงจร:

1. สร้างคำขอหนึ่งรายการไปยัง Anthropic Messages endpoint ด้วย "model": "claude-opus-5" และจัดเก็บคีย์ API ของคุณเป็นตัวแปรสภาพแวดล้อม แทนที่จะวางลงในส่วนเนื้อหา
2. บันทึกพรอมต์ระบบ Opus 4.8 เก่าของคุณและเวอร์ชัน Opus 5 ที่ถูกปรับแต่งแล้วเป็นคำขอที่บันทึกไว้สองรายการที่ใช้กับอินพุตเดียวกัน
3. เปรียบเทียบบล็อก usage ในแต่ละการตอบกลับ โทเค็นเอาต์พุตจะบอกคุณว่าข้อจำกัดความกระชับมีผลหรือไม่ โทเค็นอินพุตและฟิลด์แคชจะบอกคุณว่าการแก้ไขพรอมต์ของคุณทำให้แคชพรีฟิกซ์เสียหรือไม่
4. ทำซ้ำคำขอในระดับ effort ต่างๆ เพื่อดูด้วยตัวคุณเองว่าโทเค็นการคิดลดลงในขณะที่ความยาวที่มองเห็นยังคงอยู่
5. ตรวจสอบการตอบกลับแบบสตรีมมิ่งเพื่อยืนยันว่าการเรียกใช้เครื่องมือมาถึงในรูปแบบของบล็อก tool_use ที่มีโครงสร้าง ไม่ใช่ในรูปแบบข้อความ

ขั้นตอนที่ห้าเป็นขั้นตอนที่ตรวจจับความล้มเหลวในการเรียกใช้เครื่องมือแบบข้อความธรรมดาก่อนที่จะถึงขั้นตอนการผลิต ดาวน์โหลด Apidog หากคุณต้องการรันสิ่งเหล่านี้เคียงข้างกัน และดู คู่มือการใช้งาน Opus 5 API สำหรับรูปแบบคำขอฉบับเต็ม

ขีดจำกัดที่แท้จริง

ควรกล่าวอย่างตรงไปตรงมา เนื่องจากคู่มือพรอมต์มักจะอ่านแล้วรู้สึกว่าโมเดลนี้คือโมเดลสุดท้ายที่คุณจะต้องใช้: Opus 5 ไม่ใช่จุดสูงสุดของชุดผลิตภัณฑ์ Claude Fable 5 ยังคงรักษาสถานะ “โมเดลที่ความสามารถสูงที่สุดที่เผยแพร่อย่างกว้างขวาง” และ Opus 5 ยังคงตามหลัง Mythos 5 ในด้านการหาประโยชน์จากช่องโหว่ด้านความปลอดภัยทางไซเบอร์และการวิจัยชีววิทยาอัตโนมัติ Anthropic กล่าวถึงทั้งสองสิ่งนี้ใน ประกาศเปิดตัว ของตนเอง การนำเสนอที่ถูกต้องคือความสามารถระดับแนวหน้าในราคาครึ่งหนึ่งของระดับแนวหน้า โดยมีขีดจำกัดสูงสุดที่ระบุไว้เหนือกว่า

การอ้างสิทธิ์ผลการทดสอบเกณฑ์มาตรฐานในการเปิดตัว (Frontier-Bench, ARC-AGI 3, OSWorld 2.0, CursorBench) ล้วนเป็นตัวเลขของ Anthropic เอง และยังไม่มีการจำลองซ้ำโดยอิสระ ณ วันที่ 25 กรกฎาคม 2026 โปรดถือว่าเป็นการรายงานจากผู้ขาย และทำการประเมินผลด้วยตัวคุณเองสำหรับพรอมต์ที่คุณนำไปใช้งานจริง

นำมารวมกัน

พรอมต์ระบบ Opus 5 ที่ถูกปรับแต่งสำหรับงานเอเจนต์ที่คำนึงถึงต้นทุนจะมีลักษณะประมาณนี้:

Do not add verification passes; you verify by default.
Responses: 150 words maximum, no preamble, no closing summary.
Do not spawn subagents. Handle this in one thread.
Stay strictly within the task I state. If another change seems
required, stop and tell me rather than making it.
Do not narrate corrections or changes of approach.

หกบรรทัด โดยห้าบรรทัดเป็นข้อจำกัดและไม่มีบรรทัดใดที่ขอให้โมเดลพยายามมากขึ้น นั่นคือการเปลี่ยนแปลง ใน Opus 4.8 คุณป้อนพรอมต์เพื่อยกระดับพื้นฐาน ใน Opus 5 คุณป้อนพรอมต์เพื่อกำหนดขีดจำกัดสูงสุด

เริ่มต้นที่นั่น จากนั้นทำการทดสอบระดับ effort ด้วยการประเมินของคุณเอง แทนที่จะใช้การตั้งค่าของเวอร์ชัน 4.8 เนื่องจากระดับได้ถูกปรับเทียบใหม่ สำหรับกลไกของพารามิเตอร์ โปรดดู คู่มือพารามิเตอร์ effort สำหรับขั้นตอนการทำงานฝั่งเอดิเตอร์ โปรดดู การใช้ Opus 5 ใน Claude Code และสำหรับภาพรวมโมเดลทั้งหมด โปรดเริ่มต้นที่ Claude Opus 5 คืออะไร ภาพรวมโมเดล ของ Anthropic มีตารางข้อมูลจำเพาะปัจจุบัน

คำถามที่พบบ่อย (FAQ)

ฉันควรลบ “ตรวจสอบงานของคุณให้รอบคอบ” ออกจากพรอมต์ของฉันจริง ๆ หรือไม่? ใช่ คู่มือการสร้างพรอมต์ของ Anthropic ระบุว่า Opus 5 ตรวจสอบตัวเองโดยไม่ต้องมีพรอมต์ และคำสั่งการตรวจสอบที่นำมาจากเวอร์ชันเก่าจะทำให้เกิดการตรวจสอบที่มากเกินไป ให้ลบกฎทั่วไปออก หากมีขั้นตอนเฉพาะที่ต้องการการตรวจสอบอย่างชัดเจน ให้จำกัดขอบเขตคำสั่งนั้นไว้เฉพาะขั้นตอนนั้น

ทำไม Opus 5 ถึงพูดมากแม้จะใช้ effort ระดับต่ำ? เพราะ effort ควบคุมการคิด ไม่ใช่ความยาวของผลลัพธ์ที่มองเห็นได้ การลด effort จะลดโทเค็นการใช้เหตุผลลง ในขณะที่การตอบสนองยังคงยาวพอ ๆ กัน ให้กำหนดขีดจำกัดคำหรือรูปแบบในพรอมต์โดยตรง

ฉันจะหยุด Opus 5 ไม่ให้สร้าง subagent ได้อย่างไร? บอกโดยตรงว่า: “ห้ามสร้าง subagent ให้จัดการสิ่งนี้ในการสนทนานี้” หากการกระจายงานมีประโยชน์ ให้กำหนดขีดจำกัดเป็นตัวเลขและจำกัดให้เฉพาะงานอิสระที่สามารถทำงานพร้อมกันได้

ทำไมฉันถึงเห็นแท็ก <thinking> ในผลลัพธ์ของฉัน? สิ่งประดิษฐ์นี้จะปรากฏขึ้นเป็นบางครั้งเมื่อปิดการคิด อย่าเพิ่มคำสั่งในพรอมต์ที่ระบุชื่อแท็ก เพราะจะทำให้เกิดการรั่วไหลได้ง่ายขึ้น วิธีแก้ไขที่ Anthropic แนะนำคือให้เปิดใช้งานการคิดไว้ และใช้ระดับ effort ที่ต่ำลงเพื่อควบคุมค่าใช้จ่าย

จะเกิดอะไรขึ้นหากการเรียกใช้เครื่องมือส่งกลับมาเป็นข้อความธรรมดา? ไม่มีอะไรถูกดำเนินการ และข้อความที่รั่วไหลยังคงอยู่ในประวัติการสนทนา ซึ่งรอบถัดไปจะถือว่าเป็นการดำเนินการที่เสร็จสมบูรณ์ ตรวจสอบการตอบกลับของผู้ช่วยก่อนที่จะผนวกเข้ากับประวัติ และควรเปิดการคิดไว้แทนที่จะปิดใช้งาน