Hầu hết các 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 nói về những điều có thể phá vỡ trong lời nhắc (prompts) của bạn.
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 lại một điều đáng chú ý: một số hướng dẫn đã làm cho Opus 4.8 tốt hơn lại làm cho Opus 5 tệ hơn. Không phải tệ hơn một cách tinh tế. Mà tệ hơn một cách đáng kể về chi phí, đáng kể về độ dài, và trong một trường hợp còn bị hỏng hoàn toàn.
Lý do rất đơn giản. Opus 5 vốn dĩ đã tự thực hiện một số điều mà trước đây bạn phải yêu cầu. Khi lời nhắc cũ của bạn vẫn yêu cầu, hướng dẫn đó sẽ chồng chéo với hành vi mà mô hình đã có. Bạn sẽ nhận được gấp đôi số lần kiểm tra xác minh, chứ không phải gấp đôi độ chính xác.
Hướng dẫn này sẽ đi sâu vào từng thay đổi hành vi đã được ghi nhận với các đoạn lời nhắc bạn có thể sao chép và dán vào lời nhắc hệ thống của mình ngay hôm nay. Nó cũng bao gồm hai chế độ lỗi xuất hiện khi bạn tắt tính năng suy nghĩ, đây là trường hợp duy nhất mà một lời nhắc của Opus 5 có thể tạo ra đầu ra trông có vẻ ổn nhưng lại âm thầm làm hỏng một vòng lặp tác nhân. Nếu bạn vẫn đang xem xét các thay đổi cấp độ mã, hướng dẫn di chuyển từ Opus 4.8 sang Opus 5 sẽ đề cập riêng về chúng. Và nếu bạn muốn xem các hành vi này thay đổi trong các tải trọng yêu cầu và phản hồi thực tế, Apidog là một cách đơn giản để gửi cùng một lời nhắc với các cài đặt khác nhau 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 so với Opus 4.8. Lời nhắc Opus 4.8 của bạn được điều chỉnh để đẩy mô hình hướng tới những hành vi đó. Giờ đây, nó đã vượt qua chúng.
Vì vậy, công việc mang tính chất trừ bớt. Bạn chủ yếu xóa bỏ các hướng dẫn, chứ không phải thêm vào. Những bổ sung bạn thực hiện là các ràng buộc: ngắn gọn hơn, giữ nguyên phạm vi, không tạo ra các tác nhân phụ.
1. Xóa các hướng dẫn xác minh của bạn
Đây là điểm quan trọng nhất, và đó là lý do cho tiêu đề.
Anthropic tuyên bố rằng Opus 5 tự xác minh công việc của mình mà không cần nhắc nhở. Nó đọc lại những gì nó đã viết, kiểm tra các phép tính, chạy lại một bài kiểm tra và tìm kiếm trường hợp biên mà bạn không đề cập. Đó chính xác là hành vi mà mọi người đã thủ công nhắc Opus 4.8 với các dòng như “kiểm tra kỹ công việc của bạn trước khi phản hồi” hoặc “xác minh từng bước.”
Giữ lại những dòng đó và bạn sẽ gặp phải tình trạng xác minh quá mức. Mô hình chạy các lượt xác minh mà nó vốn dĩ sẽ chạy, cộng thêm những cái bạn yêu cầu, và bạn phải trả tiền cho mỗi token. Trong các lượt chạy tác nhân dài, đây là một hóa đơn thực sự, chứ không phải lỗi làm tròn.
Cách khắc phục là xóa bỏ. Tìm kiếm trong các lời nhắc hệ thống của bạn các mẫu sau và xóa chúng:
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.
Nếu bạn có một bước thực sự quan trọng mà bạn muốn có một lượt xác minh rõ ràng, hãy giới hạn nó cho bước đó thay vì biến nó thành một quy tắc toàn cụ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.
Hình thức đó rất quan trọng. Một hướng dẫn “xác minh mọi thứ” toàn cầu trên Opus 5 là một yếu tố nhân chi phí. Một ngoại lệ được giới hạn duy nhất là một sự kiểm soát.
Nếu bạn đang theo dõi chi tiêu API trong quá trình di chuyển này, các đòn bẩy bộ nhớ cache và hàng loạt trong bảng phân tích giá của Opus 5 sẽ kết hợp với điều này, và hướng dẫn cắt giảm hóa đơn API Claude của chúng tôi bao gồm các đòn bẩy chung.
2. Nhắc nhở về sự ngắn gọn một cách rõ ràng, vì nỗ lực sẽ không làm được điều đó
Các phản hồi mặc định của Opus 5 dài hơn của Opus 4.8. Các sản phẩm viết tay của nó cũng vậy: các báo cáo, bản tóm tắt, tài liệu thiết kế và tệp README mà nó tạo ra khi bạn yêu cầu một tài liệu.
Đây là phần khiến mọi người bối rối. Việc giảm tham số effort không khắc phục được điều này. Effort kiểm soát mức độ mô hình suy nghĩ. Nó không kiểm soát mức độ mô hình viết. Giảm từ xhigh xuống medium và bạn cắt giảm các token suy nghĩ trong khi phản hồi hiển thị vẫn giữ nguyên độ dài. Nếu bạn cho rằng effort là một nút điều chỉnh độ dài, hóa đơn của bạn sẽ không thay đổi như bạn mong đợi. Hướng dẫn tham số effort của Opus 5 đề cập đến những gì mỗi cấp độ thực sự thay đổi.
Độ dài là một vấn đề về lời nhắc, vì vậy hãy giải quyết nó trong lời nhắc. Hãy cụ thể về giới hạn thay vì nói “hãy ngắn gọn”, điều mà các mô hình diễn giải một cách rộng rãi:
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.
Đối với các sản phẩm viết tay, hãy đặt giới hạn cho sản phẩm và nêu rõ những gì cần bỏ:
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.
Đối với công việc nặng về mã, ràng buộc tương đương là về phần bình luận, không phải 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 ủy quyền tác nhân phụ
Opus 5 sẵn sàng ủy quyền cho các tác nhân phụ hơn Opus 4.8. Khi được giao một nhiệm vụ đa phần và một khung hỗ trợ tạo tác nhân phụ, nó sẽ phân tán ra.
Đó thường là quyết định đúng đắn. Nó cũng là một quyết định về chi phí mà mô hình đang đưa ra thay mặt bạn, và mỗi tác nhân phụ đều có ngữ cảnh riêng và chi phí token riêng. Đối với các khối lượng công việc nhạy cảm về chi phí hoặc độ trễ, hãy đặt một con số giới hạn thay vì để mô hình tự quyết định:
Do not spawn subagents for this task. Handle it in this conversation.
Hoặc, khi việc phân tán thực sự hữu ích nhưng cần được giới hạn:
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.
Mẫu cần tránh là ủy quyền vì lợi ích riêng của nó: một tác nhân phụ được tạo ra để đọc một tệp, hoặc để đưa ra một quyết định mà luồng chính đã có ngữ cảnh để đưa ra. Nếu bạn xây dựng với các tác nhân phụ một cách có chủ đích, hướng dẫn của chúng tôi về tạo tác nhân phụ Claude Code sẽ đề cập đến phía khung để giới hạn phạm vi của chúng.
4. Giới hạn phạm vi một cách rõ ràng đối với các nhiệm vụ hẹp
Opus 5 mở rộng phạm vi nhiệm vụ. Yêu cầu nó sửa một lỗi kiểm tra và nó cũng có thể tái cấu trúc trình trợ giúp mà bài kiểm tra gọi, cập nhật chữ ký kiểu và thêm hai trường hợp kiểm thử nữa. Yêu cầu nó đổi tên một biến và nó có thể dọn dẹp hàm xung quanh.
Đôi khi đây là một tính năng. Nhưng đối với một nhiệm vụ hẹp, mang tính phẫu thuật thì không: một hành động tái cấu trúc không được yêu cầu có nghĩa là một sự khác biệt lớn hơn để người xem xét đọc và một bán kính tác động lớn hơn cho một thay đổi lẽ ra chỉ là một dòng.
Xác định ranh giới là một ranh giới và nêu rõ những gì 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.
Điều khoản cuối cùng đó là nửa hữu ích. Nếu không có nó, mô hình không có cách nào được phép để nêu ra một vấn đề thực sự, vì vậy nó hoặc thực hiện thay đổi dù sao hoặc bỏ qua quan sát. Với nó, bạn sẽ nhận được một mối lo ngại được đánh dấu và một sự khác biệt không thay đổi.
5. Mong đợi nhiều hơn về lời kể sửa lỗi, và tắt nó đi nếu bạn không muốn
Opus 5 kể về các sửa lỗi của nó nhiều hơn Opus 4.8. Khi nó thay đổi suy nghĩ giữa chừng phản hồi, nó sẽ cho bạn biết: nó đánh dấu rằng một phương pháp tiếp cận trước đó đã sai, giải thích lý do và mô tả sự thay đổi.
Đối với công việc tương tác, điều này rất hữu ích. Đối với một đường ống mà phản hồi cung cấp cho một trình phân tích cú pháp, một giao diện người dùng hoặc một mô hình khác, lời kể đó là nhiễu nằm trong một trường lẽ ra phải chứa một câu trả lời.
Hướng dẫn ngắn gọn là:
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 bạn định tuyến các phản hồi vào bộ nhớ có cấu trúc, hãy kết hợp điều đó với các đầu ra có cấu trúc để định dạng được thực thi thay vì được yêu cầu.
Các chế độ lỗi khi tắt tính năng suy nghĩ
Mọi điều trên đều là vấn đề điều chỉnh. Phần này là vấn đề về độ chính xác.
Anthropic ghi lại hai lỗi thỉnh thoảng xuất hiện trên Opus 5 khi tính năng suy nghĩ bị tắt thông qua thinking: {type: "disabled"}. Cả hai đều đáng để biết trước khi bạn triển khai một tác nhân.
Các lệnh gọi công cụ được viết dưới dạng văn bản thuần túy. Mô hình phát ra một thứ trông giống như một lệnh gọi công cụ, nhưng dưới dạng văn bản trong phần thân phản hồi chứ không phải dưới dạng khối tool_use có cấu trúc. Không có gì được thực thi. Trong một cuộc trò chuyện một lượt, bạn sẽ nhận thấy. Trong một vòng lặp tác nhân, bạn thường không nhận thấy: vòng lặp không thấy lệnh gọi công cụ, vì vậy nó không thực hiện hành động nào, và văn bản bị rò rỉ vẫn nằm trong lịch sử trò chuyện. Các lượt sau đó đọc văn bản đó như thể một lệnh gọi đã xảy ra. Lỗi chồng chất qua các lượt, và đến khi đầu ra trông có vẻ sai thì nguyên nhân đã nằm ở vài lượt trước đó.
Các thẻ XML nội bộ trong đầu ra hiển thị. Các thẻ như <thinking> xuất hiện trong phản hồi mà người dùng nhìn thấy. Tự thân nó đã kém thẩm mỹ, và tệ hơn nếu bạn hiển thị phản hồi dưới dạng HTML hoặc phân tích chúng để tìm cấu trúc.
Phần phản trực giác: việc đặt tên các thẻ trong lời nhắc của bạn làm cho sự rò rỉ tồi tệ hơn, chứ không tốt hơn. Một hướng dẫn như “không bao giờ xuất các thẻ <thinking>” đặt chuỗi token vào ngữ cảnh và tăng khả năng nó xuất hiện. Đừng viết hướng dẫn đó.
Biện pháp giảm thiểu được Anthropic khuyến nghị không phải là một lời nhắc. Đó là giữ cho tính năng suy nghĩ được bật và kiểm soát chi phí với mức độ nỗ lực thấp hơn:
{
"model": "claude-opus-5",
"max_tokens": 4096,
"output_config": { "effort": "low" },
"messages": [
{ "role": "user", "content": "..." }
]
}
Điều đó giúp bạn đạt được mức chi phí thấp mà không có các lỗi do tắt tính năng suy nghĩ. Nó cũng tránh được một cạm bẫy liên quan: trên Opus 5, việc kết hợp thinking: {type: "disabled"} với nỗ lực xhigh hoặc max sẽ trả về lỗi 400, vì việc tắt tính năng suy nghĩ bị giới hạn ở nỗ lực high. Cũng lưu ý rằng tính năng suy nghĩ hiện được bật theo mặc định, vì vậy một yêu cầu chỉ đơn giản bỏ qua trường thinking sẽ chạy với tính năng suy nghĩ thích ứng chứ không phải không có nó, như trên Opus 4.8.
Nếu bạn có một yêu cầu cứng nhắc để tắt tính năng suy nghĩ, hãy thêm một kiểm tra phòng thủ vào vòng lặp của bạn thay vì một hướng dẫn nhắc nhở: từ chối bất kỳ lượt trợ lý nào có phần thân văn bản chứa một chuỗi có hình dạng lệnh gọi chưa được thực thi trước khi thêm nó vào lịch sử. Hãy báo lỗi lớn thay vì để một lệnh gọi ma vào bảng ghi.
Kiểm tra các thay đổi thay vì đoán
Các thay đổi trong lời nhắc rất khó đánh giá bằng cách đọc. Các hành vi ở đây (độ dài phản hồi, lượt xác minh, số lượng tác nhân phụ) hiển thị dưới dạng số lượng token và cấu trúc tải trọng, có nghĩa là cách trung thực để kiểm tra công việc của bạn là gửi các yêu cầu và so sánh.
Điều đó rất dễ dàng thiết lập trong Apidog, một nền tảng phát triển và kiểm thử API tất cả trong một:
- Xây dựng một yêu cầu đến điểm cuối Anthropic Messages với
"model": "claude-opus-5", và lưu khóa API của bạn dưới dạng biến môi trường thay vì dán vào phần thân. - Lưu lời nhắc hệ thống Opus 4.8 cũ của bạn và phiên bản Opus 5 đã cắt giảm của bạn dưới dạng hai yêu cầu đã lưu đối với cùng một đầu vào.
- So sánh khối
usagetrên mỗi phản hồi. Các token đầu ra cho bạn biết liệu ràng buộc ngắn gọn có được áp dụng hay không; các token đầu vào và các trường cache cho bạn biết liệu các chỉnh sửa lời nhắc của bạn có làm hỏng tiền tố cache hay không. - Nhân đôi yêu cầu qua các mức độ nỗ lực để tự mình thấy rằng các token suy nghĩ giảm trong khi độ dài hiển thị vẫn giữ nguyên.
- Kiểm tra phản hồi phát trực tuyến để xác nhận các lệnh gọi công cụ đến dưới dạng các khối
tool_usecó cấu trúc chứ không phải dưới dạng văn bản.
Bước năm là bước phát hiện lỗi lệnh gọi công cụ dưới dạng văn bản thuần túy trước khi nó đến giai đoạn sản xuất. Tải xuống Apidog nếu bạn muốn chạy song song các thử nghiệm này, và xem hướng dẫn sử dụng API Opus 5 để biết hình dạng yêu cầu đầy đủ.
Giới hạn trung thực
Cần nói rõ ràng, vì các hướng dẫn về lời nhắc có xu hướng đọc như thể mô hình là thứ cuối cùng bạn sẽ cần: Opus 5 không phải là đỉnh của 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”, và Opus 5 vẫn xếp sau Mythos 5 về khai thác an ninh mạng và nghiên cứu sinh học tự động. Anthropic đã nói cả hai điều này trong bài đăng ra mắt của mình. Khung chính xác là khả năng cấp độ tiên phong với một nửa giá tiền tiên phong, với một giới hạn được đặt tên ở trên nó.
Các tuyên bố về điểm chuẩn khi ra mắt (Frontier-Bench, ARC-AGI 3, OSWorld 2.0, CursorBench) đều là số liệu của Anthropic và chưa được sao chép độc lập tính đến ngày 25 tháng 7 năm 2026. Hãy coi chúng là báo cáo của nhà cung cấp, và chạy các đánh giá của riêng bạn trên các lời nhắc mà bạn thực sự triển khai.
Tổng hợp
Một lời nhắc hệ thống Opus 5 đã được cắt gọn cho một tác vụ tác nhân nhạy cảm về chi phí trông đại khái như thế này:
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 đó có năm dòng là ràng buộc và không có dòng nào yêu cầu mô hình cố gắng nhiều hơn. Đó chính là sự thay đổi. Trên Opus 4.8, bạn nhắc nhở để nâng cao mức sàn. Trên Opus 5, bạn nhắc nhở để đặt ra mức trần.
Bắt đầu từ đó, sau đó chạy một đợt kiểm tra effort trên các đánh giá của riêng bạn thay vì giữ lại cài đặt 4.8 của bạn, vì các cấp độ đã được hiệu chỉnh lại. Để biết cơ chế tham số, xem hướng dẫn tham số effort, để biết quy trình làm việc phía trình chỉnh sửa, xem sử dụng Opus 5 trong Claude Code, và để có cái nhìn toàn diện về mô hình, bắt đầu từ Claude Opus 5 là gì. Tổng quan về mô hình của Anthropic có bảng thông số kỹ thuật hiện tại.
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 lời nhắc của mình không? Có. Hướng dẫn tạo lời nhắc của Anthropic nói rằng Opus 5 tự xác minh mà không cần nhắc nhở, và các hướng dẫn xác minh được giữ lại sẽ gây ra 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ể thực sự cần kiểm tra rõ ràng, hãy giới hạn hướng dẫn cho riêng bước đó.
Tại sao Opus 5 lại dài dòng như vậy ngay cả ở mức độ nỗ lực thấp? Bởi vì nỗ lực kiểm soát quá trình suy nghĩ, chứ không phải độ dài đầu ra hiển thị. Việc giảm nỗ lực cắt giảm các token suy luận trong khi các phản hồi vẫn dài gần như vậy. Hãy đặt giới hạn từ hoặc định dạng trong chính lời nhắc.
Làm cách nào để ngăn Opus 5 tạo ra các tác nhân phụ? Hãy nói trực tiếp: “Không tạo tác nhân phụ; xử lý việc này trong cuộc trò chuyện này.” Nếu một số phân tán hữu ích, hãy đặt giới hạn số lượng và giới hạn nó cho công việc song song độc lập.
Tại sao tôi lại thấy các thẻ <thinking> trong đầu ra của mình? Lỗi này thỉnh thoảng xuất hiện khi tính năng suy nghĩ bị tắt. Đừng thêm hướng dẫn lời nhắc nêu tên các thẻ, vì điều đó làm tăng khả năng rò rỉ. Giải pháp được Anthropic khuyến nghị là giữ cho tính năng suy nghĩ được bật và sử dụng mức độ nỗ lực thấp hơn để kiểm soát chi phí.
Điều gì sẽ xảy ra nếu một lệnh gọi công cụ được trả về dưới dạng văn bản thuần túy? Không có gì được thực thi, và văn bản bị rò rỉ vẫn nằm trong lịch sử cuộc trò chuyện, nơi các lượt sau đó coi nó là một hành động đã hoàn thành. Hãy xác thực các lượt trợ lý trước khi thêm chúng vào lịch sử, và ưu tiên giữ cho tính năng suy nghĩ được bật thay vì tắt nó.