Kỹ thuật Prompt Claude Opus 5: Ngừng yêu cầu kiểm tra lại

Hầu hết hướng dẫn di chuyển cho bạn biết điều gì sẽ phá vỡ mã của bạn. Hướng dẫn này tập trung vào những điều có thể phá vỡ trong lời nhắc (prompt) của bạn.

Dùng thử Apidog ngay hôm nay

Claude Opus 5 ra mắt vào ngày 24 tháng 7 năm 2026, và Anthropic đã phát hành một hướng dẫn tạo lời nhắc chuyên biệt cùng với nó. Hướng dẫn đó ghi nhận một điểm đáng chú ý: một số hướng dẫn từng cải thiện Opus 4.8 lại làm Opus 5 hoạt động kém hơn — đáng kể về chi phí, độ dài phản hồi, và trong một trường hợp còn gây lỗi hoàn toàn.

Lý do đơn giản: Opus 5 vốn đã tự thực hiện một số thao tác mà trước đây bạn phải yêu cầu. Khi prompt cũ vẫn tiếp tục yêu cầu các thao tác đó, hướng dẫn của bạn chồng chéo với hành vi mặc định của mô hình. Kết quả là hai lượt xác minh thay vì độ chính xác gấp đôi.

Hướng dẫn này đi qua từng thay đổi hành vi đã được ghi nhận, kèm các đoạn prompt bạn có thể sao chép vào system prompt ngay hôm nay. Nó cũng bao gồm hai chế độ lỗi xuất hiện khi tắt tính năng suy nghĩ — trường hợp mà prompt Opus 5 có thể tạo đầu ra có vẻ hợp lệ nhưng âm thầm phá vỡ vòng lặp tác nhân.

Nếu bạn vẫn đang đánh giá các thay đổi ở cấp độ mã, hãy xem hướng dẫn di chuyển từ Opus 4.8 sang Opus 5. Nếu muốn quan sát các hành vi này trên tải trọng request/response thực tế, bạn có thể dùng Apidog để gửi cùng một prompt với nhiều cấu hình và so sánh kết quả.

Tóm tắt trong một dòng

Opus 5 xác minh nhiều hơn, viết nhiều hơn, ủy quyền nhiều hơn và tự giải thích nhiều hơn Opus 4.8. Prompt Opus 4.8 thường được điều chỉnh để đẩy mô hình đến những hành vi này. Với Opus 5, các hướng dẫn đó có thể khiến mô hình vượt quá mức cần thiết.

Vì vậy, phần lớn công việc là loại bỏ thay vì thêm prompt. Những gì nên bổ sung là các ràng buộc: giới hạn độ dài, giữ đúng phạm vi và không tạo tác nhân phụ.

1. Xóa các hướng dẫn xác minh

Đây là thay đổi quan trọng nhất.

Anthropic cho biết Opus 5 tự xác minh công việc mà không cần nhắc. Mô hình có thể đọc lại nội dung vừa tạo, kiểm tra phép tính, chạy lại kiểm thử hoặc tìm các trường hợp biên chưa được nêu trong yêu cầu.

Đó cũng là hành vi mà nhiều prompt cho Opus 4.8 từng yêu cầu bằng các câu như:

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.

Giữ các câu này có thể dẫn đến xác minh quá mức. Mô hình chạy các lượt kiểm tra mặc định, rồi chạy thêm những lượt bạn yêu cầu. Trong các tác vụ agent dài, token phát sinh từ việc này có thể tạo ra chi phí đáng kể.

Cách triển khai

Tìm các hướng dẫn xác minh mang tính toàn cục trong system prompt và xóa chúng.

Nếu có một bước thật sự quan trọng cần xác minh rõ ràng, chỉ áp dụng ràng buộc cho bước đó:

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.

Điểm khác biệt rất quan trọng:

• “Xác minh mọi thứ” là một hệ số nhân chi phí.
• Một ngoại lệ được giới hạn cho một bước cụ thể là một cơ chế kiểm soát.

Nếu đang theo dõi chi tiêu API khi di chuyển, hãy kết hợp thay đổi này với các đòn bẩy cache và batch trong bảng phân tích giá Opus 5, cùng với hướng dẫn cắt giảm hóa đơn API Claude.

2. Ràng buộc độ dài rõ ràng: giảm effort không làm câu trả lời ngắn hơn

Phản hồi mặc định của Opus 5 dài hơn Opus 4.8. Điều này cũng đúng với các sản phẩm viết: báo cáo, tóm tắt, tài liệu thiết kế hoặc README.

Một điểm dễ gây nhầm lẫn: giảm tham số effort không giải quyết độ dài phản hồi hiển thị.

effort kiểm soát lượng suy nghĩ của mô hình, không phải lượng nội dung mô hình viết ra. Khi giảm từ xhigh xuống medium, bạn giảm token suy nghĩ, trong khi phần trả lời hiển thị có thể vẫn dài tương tự.

Xem hướng dẫn tham số effort của Opus 5 để biết từng mức thực sự thay đổi điều gì.

Cách triển khai

Đặt giới hạn cụ thể thay vì chỉ nói “hãy ngắn gọn”:

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.

Với tài liệu viết tay, hãy giới hạn số từ và nêu rõ nội dung cần loại trừ:

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.

Với tác vụ chủ yếu là mã, ràng buộc nên áp dụng cho phần diễn giải thay vì mã:

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. Giới hạn việc ủy quyền cho tác nhân phụ

Opus 5 sẵn sàng ủy quyền cho tác nhân phụ hơn Opus 4.8. Khi nhận một nhiệm vụ nhiều phần trong môi trường hỗ trợ subagent, mô hình có thể phân tách công việc thành nhiều luồng.

Điều này thường hữu ích, nhưng mỗi tác nhân phụ có ngữ cảnh và chi phí token riêng. Với khối lượng công việc nhạy cảm về chi phí hoặc độ trễ, hãy đặt giới hạn rõ ràng thay vì để mô hình tự quyết định.

Không dùng tác nhân phụ

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

Cho phép nhưng giới hạn tác nhân phụ

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.

Tránh tạo tác nhân phụ chỉ để đọc một tệp hoặc đưa ra quyết định mà luồng chính đã có đủ ngữ cảnh để xử lý.

Nếu bạn chủ động xây dựng kiến trúc subagent, hãy xem hướng dẫn tạo tác nhân phụ Claude Code để giới hạn phạm vi ở phía framework.

4. Giới hạn phạm vi rõ ràng cho tác vụ hẹp

Opus 5 có xu hướng mở rộng phạm vi nhiệm vụ. Ví dụ, khi được yêu cầu sửa một lỗi kiểm thử, mô hình có thể đồng thời tái cấu trúc helper, cập nhật type signature và thêm test case.

Đôi khi đây là lợi thế. Nhưng với thay đổi mang tính phẫu thuật, nó làm diff lớn hơn, tăng thời gian review và mở rộng bán kính tác động của một thay đổi lẽ ra chỉ cần một dòng.

Cách triển khai

Xác định tệp, mục tiêu thay đổi và các hành động bị cấm:

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.

Câu cuối cùng rất quan trọng. Nó cung cấp một cách hợp lệ để mô hình báo cáo vấn đề ngoài phạm vi thay vì tự ý sửa hoặc bỏ qua phát hiện đó.

5. Tắt lời kể về quá trình sửa lỗi nếu pipeline không cần

Opus 5 có xu hướng mô tả các lần tự sửa nhiều hơn Opus 4.8. Khi thay đổi hướng xử lý giữa chừng, nó có thể nói rằng phương án trước đó sai, giải thích lý do, rồi trình bày cách tiếp cận mới.

Trong trao đổi tương tác, đây là thông tin hữu ích. Nhưng trong pipeline mà phản hồi được đưa vào parser, UI hoặc mô hình khác, phần kể chuyện này là nhiễu.

Cách triển khai

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.

Nếu phản hồi được đưa vào bộ nhớ có cấu trúc, hãy kết hợp ràng buộc này với structured output để định dạng được thực thi thay vì chỉ được yêu cầu.

Các chế độ lỗi khi tắt tính năng suy nghĩ

Các phần trước là điều chỉnh hành vi. Phần này liên quan trực tiếp đến độ chính xác.

Anthropic ghi nhận hai lỗi có thể xuất hiện trên Opus 5 khi tắt tính năng suy nghĩ bằng:

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

Lệnh gọi công cụ xuất hiện dưới dạng văn bản thuần túy

Mô hình có thể tạo nội dung trông như một tool call, nhưng đặt nó trong phần văn bản phản hồi thay vì khối tool_use có cấu trúc.

Không có công cụ nào được thực thi.

Trong cuộc trò chuyện một lượt, lỗi này dễ nhận ra. Trong vòng lặp agent, nó có thể âm thầm gây lỗi:

1. Vòng lặp không phát hiện khối tool_use, nên không thực hiện hành động.
2. Văn bản giống tool call vẫn được ghi vào lịch sử hội thoại.
3. Các lượt sau đọc văn bản đó như thể hành động đã hoàn tất.
4. Lỗi tích lũy qua nhiều lượt.

Thẻ XML nội bộ bị lộ trong đầu ra

Các thẻ như <thinking> có thể xuất hiện trong phản hồi hiển thị cho người dùng.

Điều này không chỉ gây mất thẩm mỹ. Nó còn có thể phá vỡ giao diện HTML hoặc logic parser đang tìm cấu trúc cụ thể.

Điểm phản trực giác: không nên thêm prompt như “không bao giờ xuất thẻ <thinking>”. Việc đưa chuỗi token đó vào ngữ cảnh có thể làm tăng khả năng nó xuất hiện.

Biện pháp giảm thiểu

Khuyến nghị của Anthropic không phải là thêm prompt. Hãy giữ tính năng suy nghĩ bật và kiểm soát chi phí qua mức effort thấp hơn:

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

Cách này giúp giảm chi phí mà không gặp các lỗi liên quan đến việc tắt suy nghĩ.

Cũng cần lưu ý:

• Kết hợp thinking: {type: "disabled"} với effort là xhigh hoặc max sẽ trả về lỗi 400.
• Khi tắt suy nghĩ, mức effort bị giới hạn ở high.
• Tính năng suy nghĩ hiện bật theo mặc định. Nếu chỉ bỏ qua trường thinking, request sẽ chạy với suy nghĩ thích ứng thay vì tắt suy nghĩ như trên Opus 4.8.

Nếu buộc phải tắt suy nghĩ, hãy thêm kiểm tra phòng thủ vào vòng lặp agent thay vì thêm prompt. Ví dụ: từ chối bất kỳ lượt assistant nào có phần văn bản chứa chuỗi giống tool call chưa được thực thi trước khi thêm nó vào lịch sử hội thoại.

Hãy báo lỗi rõ ràng thay vì để một “lệnh gọi ma” đi vào bản ghi.

Kiểm tra thay đổi thay vì đoán

Thay đổi prompt khó đánh giá bằng cách chỉ đọc. Các hành vi cần theo dõi — độ dài phản hồi, số lượt xác minh, số tác nhân phụ — thường chỉ hiện rõ qua số token và cấu trúc payload.

Cách đáng tin cậy là gửi request và so sánh kết quả.

Bạn có thể thiết lập quy trình này trong Apidog, một nền tảng phát triển và kiểm thử API:

1. Tạo request đến Anthropic Messages API với "model": "claude-opus-5". Lưu API key trong biến môi trường thay vì dán trực tiếp vào body.
2. Lưu system prompt Opus 4.8 cũ và phiên bản Opus 5 đã rút gọn thành hai request riêng, dùng cùng một đầu vào.
3. So sánh khối usage trong từng response:
   • Output token cho biết ràng buộc độ dài có hiệu lực hay không.
   • Input token và trường cache cho biết việc sửa prompt có làm mất cache prefix hay không.
4. Nhân bản request ở các mức effort khác nhau để xác nhận token suy nghĩ giảm trong khi độ dài phản hồi hiển thị có thể không đổi.
5. Kiểm tra streaming response để xác nhận tool call được trả về dưới dạng khối tool_use có cấu trúc, không phải văn bản thuần túy.

Bước 5 giúp phát hiện lỗi tool call dưới dạng text trước khi đưa agent vào production.

Tải xuống Apidog để chạy các thử nghiệm song song, và xem hướng dẫn sử dụng API Opus 5 để biết cấu trúc request đầy đủ.

Giới hạn trung thực

Cần nói rõ: Opus 5 không phải là đỉnh của toàn bộ ngăn xếp Claude.

Fable 5 vẫn giữ danh hiệu “mô hình có năng lực nhất được phát hành rộng rãi”, còn Opus 5 vẫn xếp sau Mythos 5 trong khai thác an ninh mạng và nghiên cứu sinh học tự động. Anthropic nêu cả hai điểm này trong bài đăng ra mắt.

Khung định vị chính xác là: khả năng cấp độ tiên phong với một nửa chi phí tiên phong, nhưng vẫn có một giới hạn năng lực rõ ràng ở phía trên.

Các tuyên bố benchmark khi ra mắt — Frontier-Bench, ARC-AGI 3, OSWorld 2.0 và CursorBench — đều là số liệu do Anthropic công bố và chưa được sao chép độc lập tính đến ngày 25 tháng 7 năm 2026. Hãy xem đó là báo cáo của nhà cung cấp, rồi chạy đánh giá của riêng bạn trên các prompt thực tế.

Tổng hợp

Một system prompt Opus 5 tối giản cho tác vụ agent nhạy cảm về chi phí có thể trông như sau:

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.

Sáu dòng, trong đó năm dòng là ràng buộc. Không có dòng nào yêu cầu mô hình “cố gắng hơn”.

Đó là thay đổi cốt lõi:

• Với Opus 4.8, bạn nhắc để nâng mức sàn.
• Với Opus 5, bạn nhắc để đặt mức trần.

Bắt đầu từ prompt này, sau đó chạy thử nghiệm effort trên bộ đánh giá của riêng bạn thay vì giữ nguyên cấu hình 4.8, vì các mức đã được hiệu chỉnh lại.

Để biết thêm chi tiết:

• Hướng dẫn tham số effort
• Sử dụng Opus 5 trong Claude Code
• Claude Opus 5 là gì
• Tổng quan mô hình của Anthropic

Câu hỏi thường gặp

Tôi có nên thực sự xóa “kiểm tra kỹ công việc của bạn” khỏi prompt không?

Có. Hướng dẫn prompting của Anthropic nói rằng Opus 5 tự xác minh mà không cần nhắc, và các hướng dẫn xác minh giữ lại có thể gây xác minh quá mức. Hãy xóa quy tắc toàn cục. Nếu một bước cụ thể cần kiểm tra, chỉ áp dụng hướng dẫn cho bước đó.

Tại sao Opus 5 vẫn dài dòng ngay cả ở mức effort thấp?

Vì effort kiểm soát quá trình suy nghĩ, không phải độ dài đầu ra hiển thị. Giảm effort làm giảm token suy luận trong khi phản hồi vẫn có thể dài gần như cũ. Hãy đặt giới hạn số từ hoặc định dạng trực tiếp trong prompt.

Làm cách nào để ngăn Opus 5 tạo tác nhân phụ?

Nói trực tiếp:

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

Nếu vẫn cần phân tách công việc, hãy giới hạn số lượng tác nhân phụ và chỉ cho phép chúng xử lý các phần độc lập có thể chạy song song.

Tại sao tôi thấy thẻ <thinking> trong đầu ra?

Lỗi này đôi khi xuất hiện khi tính năng suy nghĩ bị tắt. Đừng thêm prompt nhắc tên thẻ vì điều đó có thể làm tăng khả năng rò rỉ. Giải pháp được khuyến nghị là giữ suy nghĩ bật và dùng mức effort thấp hơn để kiểm soát chi phí.

Điều gì xảy ra nếu tool call được trả về dưới dạng văn bản thuần túy?

Không có công cụ nào được thực thi. Văn bản bị rò rỉ vẫn nằm trong lịch sử hội thoại và các lượt sau có thể hiểu nhầm rằng hành động đã hoàn tất. Hãy xác thực lượt assistant trước khi thêm vào lịch sử, đồng thời ưu tiên giữ tính năng suy nghĩ bật thay vì tắt.