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

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

ลองใช้ Apidog วันนี้

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

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

บทความนี้สรุปวิธีปรับพรอมต์ให้ใช้งานได้จริง พร้อมตัวอย่างที่คัดลอกไปใช้ใน system prompt ได้ทันที รวมถึงโหมดความล้มเหลวเมื่อปิดการคิด (thinking) ซึ่งอาจทำให้ agent loop มีข้อมูลเสียหายแบบตรวจพบได้ยาก

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

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

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

แนวทางหลักคือ ลบคำสั่งที่ซ้ำซ้อน แล้วเพิ่มเฉพาะข้อจำกัดที่วัดผลได้ เช่น:

• จำกัดความยาว
• จำกัดขอบเขตงาน
• จำกัดจำนวน subagent
• ห้ามเพิ่มการเปลี่ยนแปลงที่ไม่ได้ร้องขอ

1. ลบคำสั่งตรวจสอบงานแบบทั่วไป

Anthropic ระบุว่า Opus 5 ตรวจสอบงานของตัวเองโดยค่าเริ่มต้น เช่น อ่านสิ่งที่เขียนซ้ำ ตรวจสอบการคำนวณ ทดสอบใหม่ และมองหากรณีขอบเขต

ดังนั้นให้ค้นหาและลบคำสั่งลักษณะนี้ออกจาก system prompt:

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.

คำสั่งเหล่านี้อาจทำให้โมเดลเพิ่มรอบการตรวจสอบที่มันทำอยู่แล้ว ส่งผลให้ใช้ token และเวลาเพิ่มขึ้น โดยเฉพาะ agent workflow ที่ทำงานหลายรอบ

หากมีขั้นตอนเสี่ยงสูงที่ต้องตรวจสอบจริง ๆ ให้ระบุเฉพาะจุดนั้นแทน:

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.

หลักการคือ:

• อย่าสั่งให้ “ตรวจสอบทุกอย่าง”
• ระบุขั้นตอนเดียวที่ต้องตรวจสอบ
• ระบุจำนวนรอบและขอบเขตของการตรวจสอบ

หากกำลังติดตามค่าใช้จ่าย API ดูรายละเอียดราคา Opus 5 และคู่มือลดค่าใช้จ่าย Claude API

2. จำกัดความยาวให้ชัดเจน เพราะ effort ไม่ได้ควบคุมความยาวคำตอบ

Opus 5 มักสร้างคำตอบที่ยาวกว่า Opus 4.8 ทั้งรายงาน สรุป เอกสารออกแบบ และ README

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

ตัวอย่าง:

• ลด effort จาก xhigh เป็น medium อาจลด reasoning token
• แต่คำตอบที่มองเห็นได้อาจยังยาวพอ ๆ เดิม

ดูรายละเอียดระดับค่าได้ในคู่มือพารามิเตอร์ 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.

สำหรับงานโค้ด ให้จำกัดคำอธิบายแทนที่จะจำกัด diff:

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 โดยเฉพาะเมื่อมีงานหลายส่วนและเครื่องมือรองรับการสร้าง agent เพิ่ม

การกระจายงานอาจมีประโยชน์ แต่ subagent แต่ละตัวมี context และค่า token ของตัวเอง หากคุณต้องควบคุมต้นทุนหรือ latency ให้กำหนดนโยบายให้ชัดเจน

ห้ามสร้าง 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 สำหรับงานที่ thread หลักมีบริบทเพียงพออยู่แล้ว เช่น อ่านไฟล์เดียว หรือตัดสินใจเล็กน้อยที่ไม่ต้องทำงานขนาน

หากต้องการออกแบบ subagent อย่างตั้งใจ ดูคู่มือสร้าง Claude Code subagent

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

Opus 5 อาจขยายขอบเขตงานมากกว่าที่ร้องขอ เช่น เมื่อขอให้แก้ test ที่ล้มเหลว โมเดลอาจ refactor helper เปลี่ยน type signature หรือเพิ่ม test case ใหม่

พฤติกรรมนี้อาจมีประโยชน์สำหรับงานใหญ่ แต่ไม่เหมาะกับงานเล็กที่ต้องการ 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. ปิดการบรรยายการแก้ไข หากผลลัพธ์ต้องเข้า parser หรือ pipeline

Opus 5 อาจบรรยายว่ามันเปลี่ยนแนวทางระหว่างตอบอย่างไร เช่น บอกว่าวิธีก่อนหน้าผิด อธิบายเหตุผล และเล่าว่าแก้ไขอะไร

สำหรับการสนทนาแบบ interactive สิ่งนี้อาจเป็นประโยชน์ แต่สำหรับผลลัพธ์ที่ส่งเข้า parser, UI หรือโมเดลอื่น ข้อความเหล่านี้คือ noise

ใช้คำสั่งนี้:

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.

หาก pipeline ต้องการข้อมูลแบบมีโครงสร้าง ให้ใช้ structured output เพื่อบังคับ schema แทนการหวังให้โมเดลรักษารูปแบบจากคำสั่งเพียงอย่างเดียว

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

ส่วนก่อนหน้านี้เป็นการปรับแต่งต้นทุนและรูปแบบผลลัพธ์ ส่วนนี้เกี่ยวข้องกับความถูกต้องของ agent workflow

Anthropic ระบุสิ่งผิดปกติสองแบบที่อาจเกิดกับ Opus 5 เมื่อปิดการคิดด้วย:

{
  "thinking": {
    "type": "disabled"
  }
}

1. Tool call ปรากฏเป็นข้อความธรรมดา

โมเดลอาจสร้างสิ่งที่ดูเหมือน tool call แต่ใส่ไว้ในข้อความตอบกลับแทนที่จะส่งเป็นบล็อก tool_use ที่มีโครงสร้าง

ผลคือ:

1. ไม่มี tool ใดถูกเรียกใช้งานจริง
2. ข้อความดังกล่าวอาจถูกบันทึกลง conversation history
3. รอบถัดไปอาจตีความว่าการเรียก tool สำเร็จแล้ว
4. ความผิดพลาดสะสมใน agent loop และตรวจจับย้อนกลับได้ยาก

2. แท็ก XML ภายในรั่วไปยังผลลัพธ์

แท็กเช่น <thinking> อาจปรากฏในข้อความที่ผู้ใช้เห็น ปัญหานี้รุนแรงขึ้นหากคุณ render ผลลัพธ์เป็น HTML หรือ parse เพื่อดึงโครงสร้าง

อย่าเพิ่มคำสั่งที่เอ่ยชื่อแท็กโดยตรง เช่น “ห้ามแสดงแท็ก <thinking>” เพราะการใส่ token ของแท็กลงใน context อาจเพิ่มโอกาสที่แท็กจะรั่วออกมา

แนวทางที่ Anthropic แนะนำคือ เปิดการคิดไว้ แล้วลดต้นทุนด้วย effort ระดับต่ำแทน:

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

การตั้งค่านี้ช่วยลดต้นทุนโดยไม่ต้องรับความเสี่ยงจากการปิด thinking

ข้อควรระวังเพิ่มเติม:

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

หากจำเป็นต้องปิด thinking จริง ๆ ให้เพิ่ม validation ใน agent loop แทนการแก้ด้วย prompt:

function validateAssistantResponse(content: string) {
  const looksLikeUnexecutedToolCall =
    /(?:tool_use|function_call|<tool_call|invoke)/i.test(content);

  if (looksLikeUnexecutedToolCall) {
    throw new Error(
      "Rejected assistant response: possible unexecuted tool call in text content."
    );
  }
}

ตรวจสอบข้อความตอบกลับก่อน append ลง conversation history และหยุด workflow ด้วย error ที่ชัดเจน หากพบรูปแบบที่คล้าย tool call แต่ไม่มี structured tool-use block

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

การอ่านพรอมต์อย่างเดียวไม่พอสำหรับประเมินผล เพราะพฤติกรรมที่สำคัญ เช่น ความยาวคำตอบ จำนวนรอบตรวจสอบ และจำนวน subagent จะสะท้อนผ่าน token usage และโครงสร้างของ payload

คุณสามารถตั้งค่าการทดสอบใน Apidog ได้ตามขั้นตอนนี้:

1. สร้าง request ไปยัง Anthropic Messages endpoint โดยกำหนด "model": "claude-opus-5"
2. เก็บ API key เป็น environment variable แทนการใส่ลงใน request body
3. บันทึก system prompt ของ Opus 4.8 และเวอร์ชันที่ปรับสำหรับ Opus 5 เป็น request คนละรายการ
4. ส่งทั้งสอง request ด้วย input เดียวกัน
5. เปรียบเทียบบล็อก usage ใน response:
   • output token บอกได้ว่าข้อจำกัดความกระชับได้ผลหรือไม่
   • input token และ cache field ช่วยตรวจว่าการแก้ prompt กระทบ prefix cache หรือไม่
6. ทดสอบหลายระดับของ effort เพื่อแยกผลของ reasoning token ออกจากความยาวคำตอบ
7. ตรวจสอบ streaming response เพื่อยืนยันว่า tool call มาในบล็อก tool_use แบบมีโครงสร้าง ไม่ใช่ข้อความธรรมดา

ขั้นตอนสุดท้ายช่วยตรวจจับความล้มเหลวของ tool call ก่อนนำไป production

ดาวน์โหลด Apidog หากต้องการรันทดสอบแบบเคียงข้างกัน และดูรูปแบบ request แบบเต็มได้ในคู่มือการใช้งาน Opus 5 API

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

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

Anthropic กล่าวถึงประเด็นเหล่านี้ในประกาศเปิดตัว ของตนเอง ดังนั้นควรมอง Opus 5 ว่าเป็นความสามารถระดับแนวหน้าในราคาประมาณครึ่งหนึ่งของระดับแนวหน้า โดยมีขีดจำกัดตามที่ระบุไว้

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

System prompt ตัวอย่างสำหรับงาน agent ที่คุมต้นทุน

ใช้เป็นจุดเริ่มต้นได้ดังนี้:

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.

พรอมต์นี้มีเป้าหมายชัดเจน:

• ไม่สั่งให้ตรวจสอบซ้ำ
• จำกัดความยาวผลลัพธ์
• ปิดการสร้าง subagent
• จำกัดขอบเขตการแก้ไข
• ห้ามใส่คำบรรยายการเปลี่ยนแนวทาง

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

เริ่มจาก prompt นี้ แล้วทดสอบระดับ effort กับ evaluation ของคุณเอง เพราะระดับ effort ถูกปรับเทียบใหม่จากเวอร์ชัน 4.8

อ่านเพิ่มเติม:

• คู่มือพารามิเตอร์ effort
• การใช้ Opus 5 ใน Claude Code
• Claude Opus 5 คืออะไร
• ภาพรวมโมเดลของ Anthropic

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

ฉันควรลบ “ตรวจสอบงานของคุณให้รอบคอบ” ออกจากพรอมต์จริงหรือไม่?

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

ทำไม Opus 5 ยังตอบยาวแม้ใช้ effort ระดับต่ำ?

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

ฉันจะหยุด Opus 5 ไม่ให้สร้าง subagent ได้อย่างไร?

สั่งโดยตรง:

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

หากต้องการให้กระจายงาน ให้กำหนดจำนวนสูงสุดและอนุญาตเฉพาะงานอิสระที่ทำพร้อมกันได้

ทำไมจึงเห็นแท็ก <thinking> ในผลลัพธ์?

สิ่งนี้อาจเกิดเมื่อปิด thinking อย่าใส่คำสั่งที่เอ่ยชื่อแท็ก เพราะอาจเพิ่มโอกาสที่แท็กจะปรากฏ แนวทางที่แนะนำคือเปิด thinking ไว้และใช้ effort ระดับต่ำเพื่อควบคุมค่าใช้จ่าย

จะเกิดอะไรขึ้นหาก tool call กลับมาเป็นข้อความธรรมดา?

ไม่มี tool ถูกเรียกจริง และข้อความนั้นอาจถูกบันทึกใน conversation history จนรอบถัดไปเข้าใจผิดว่าการทำงานเสร็จแล้ว ตรวจสอบ response ก่อนบันทึกลงประวัติ และควรเปิด thinking ไว้แทนการปิดใช้งาน