Prompt cho Claude Opus 5: phần lớn việc cần làm là xóa bớt
Opus 5 chạy tốt ngay với prompt viết cho Opus 4.8. Việc tinh chỉnh chủ yếu là gỡ đi những chỉ dẫn thừa — verify, double-check, be conservative — và thêm vài dòng kiểm soát độ dài, scope, subagent.
Contents
Hướng dẫn prompt chính thức cho Claude Opus 5 vừa lên, và điểm thú vị nhất của nó không phải là “thêm gì vào prompt” mà là bỏ gì đi. Anthropic nói thẳng: Opus 5 chạy tốt ngay với prompt bạn đang dùng cho Opus 4.8. Những chỗ cần chỉnh phần lớn là các câu chỉ dẫn từng hữu ích với model cũ, nay chồng lấn với hành vi sẵn có của model mới và chỉ làm tốn token.
1. Ba thứ nên xóa khỏi prompt cũ
Chỉ dẫn tự verify. Những câu kiểu “include a final verification step for any non-trivial task” hay “use a subagent to verify” — gỡ hết. Opus 5 tự kiểm tra công việc của mình mà không cần ai bảo; giữ lại các chỉ dẫn này gây over-verification, tốn token mà chất lượng không tăng. Điều tương tự áp dụng cho scaffolding cũ trong harness nếu nó chèn thêm một bước verify riêng.
Chỉ dẫn kiểm tra lại. “Double-check your answer”, “re-verify before responding” — cùng một cơ chế. Model đã tự bắt và tự sửa lỗi tốt; chỉ dẫn này cộng dồn lên hành vi có sẵn, đội chi phí mà không cải thiện kết quả.
Chỉ dẫn “hãy dè dặt” khi review code. Đây là cái bẫy tinh vi nhất. Opus 5 review code với cả precision lẫn recall cao — nó tìm ra bug thật với tỷ lệ cao mỗi lượt, và những phát hiện thêm phần lớn là vấn đề thật chứ không phải false positive. Nếu prompt review của bạn ghi “only report high-severity issues” hoặc “be conservative”, model sẽ làm đúng theo nghĩa đen và báo cáo ít đi. Cách đúng: bảo nó báo hết, rồi lọc ở một pass riêng.
Một hệ quả kèm theo: độ chính xác của việc review vẫn giữ được ở mức effort thấp. Nghĩa là bạn có thể chạy một pass nhanh lúc review, rồi để một pass kỹ hơn cho sau.
2. Ba tầng độ dài, ba chỗ chỉnh khác nhau
Câu trả lời của Opus 5 mặc định dài hơn các đời Opus trước. Chỗ nhiều người nhầm: tưởng hạ effort xuống là ngắn lại. Không phải. Effort điều khiển việc model nghĩ bao nhiêu, không phải nó nói bao nhiêu — hạ effort có thể giảm lượng suy nghĩ mà không rút ngắn phần hiển thị. Muốn ngắn thì phải yêu cầu bằng prompt.
Tầng 1 — độ dài hội thoại. Một câu ngắn là đủ:
Keep responses focused, brief, and concise. Keep disclaimers and caveats
short, and spend most of the response on the main answer. When asked to
explain something, give a high-level summary unless an in-depth explanation
is specifically requested.
Nếu system prompt dài, đặt thêm một nhắc lại ngắn gần cuối prompt:
<tone_preference>
Keep outputs reasonably concise.
</tone_preference>
Tầng 2 — tường thuật trong lúc làm việc agentic. Opus 5 hay thông báo trước khi làm gì đó, và mỗi lượt trong phiên agentic thường dài hơn model cũ. Muốn bớt, đừng nói “đừng nói nhiều” — hãy mô tả nhịp và hình dạng bạn muốn:
Before your first tool call, say in one sentence what you're about to do.
While working, give a brief update only when you find something important
or change direction. When you finish, lead with the outcome: your first
sentence should answer "what happened" or "what did you find," with
supporting detail after it for readers who want it.
Cần nhiều tường thuật hơn thì dùng đúng cần gạt đó theo chiều ngược lại. Nguyên tắc chung: ví dụ tích cực về phong cách bạn muốn hiệu quả hơn là chỉ dẫn về thứ không được làm.
Tầng 3 — file model ghi ra đĩa. Đây là tầng dễ bị bỏ sót. Report, tài liệu Markdown, bản tóm tắt mà Opus 5 viết ra file thường dài hơn model cũ — và nó độc lập với độ dài hội thoại. Nếu sản phẩm của bạn có tài liệu do Claude soạn:
Match the length of written documents to what the task needs: cover the
substance, but do not pad with filler sections, redundant summaries,
or boilerplate.
3. Giữ scope trong đúng phạm vi được giao
Ngoài chuyện tự verify, Opus 5 còn có xu hướng nới rộng phạm vi — thêm bước không ai yêu cầu, tự phán đoán xem task “thật ra nên là gì”. Với các task hẹp, ràng buộc rõ:
Deliver what was asked, at the scope intended. Make routine judgment calls
yourself, and check in only when different readings of the request would
lead to materially different work. If the request seems mistaken or a better
approach exists, say so in a sentence and continue with the task as asked
rather than quietly narrowing, widening, or transforming it. Finish the
whole task, and stop short of actions that are clearly beyond what was asked.
Đoạn này cân bằng hai đầu khá khéo: vừa chặn việc tự ý phình task, vừa không cho phép model tự thu hẹp lại phần khó — “finish the whole task” nằm đúng trong đó.
4. Chặn subagent nở nồi
Opus 5 giao việc cho subagent dễ dàng hơn các model trước. Việc này đáng tiền khi các nhánh công việc thực sự độc lập và đủ lớn, nhưng nhân đôi nhân ba chi phí lẫn thời gian khi bị áp cho task nhỏ. Nếu harness của bạn hỗ trợ subagent, hoặc nêu rõ trường hợp nào đáng delegate, hoặc đặt trần cứng số agent:
Delegate to a subagent only for large tasks that are genuinely independent
and parallelizable, such as a wide multi-file investigation. Do not delegate
work you can finish yourself in a handful of tool calls, and do not use
subagents to verify or double-check your own work. If one subagent can
complete the task, use one rather than several, and keep spawn counts low.
Chú ý câu “do not use subagents to verify” — nó lặp lại đúng luận điểm ở mục 1. Tin tốt: khi thực sự cần điều phối nhiều agent, Opus 5 làm tốt, pattern writer-verifier chạy hiệu quả và hiếm khi các agent ghi đè lên việc của nhau. Vấn đề chỉ là chi phí, không phải năng lực.
5. Đính chính: chỉ khi nó đổi được điều gì đó
Opus 5 tường thuật việc tự sửa lại phát biểu trước đó nhiều hơn các model cũ. Trong sản phẩm hướng người dùng cuối, việc này gây khó chịu. Giới hạn nó lại:
Only correct an earlier statement when the error would change the user's
code, conclusions, or decisions. State corrections plainly and briefly,
then continue the task. For slips that change nothing for the user, make
the fix and move on without noting it.
6. Nếu buộc phải tắt thinking
Opus 5 bật thinking mặc định, và chỉ tắt được ở effort high trở xuống. Khi tắt, hai hiện tượng lạ có thể xuất hiện trong output:
- Tool call bị viết thành văn bản. Model thỉnh thoảng viết lời gọi tool vào phần text hiển thị thay vì phát ra block
tool_usecó cấu trúc. Lượt đó vẫn kết thúc bình thường nhưng lời gọi không bao giờ chạy — và trong vòng lặp agentic, đoạn text rò rỉ đó nằm lại trong lịch sử hội thoại, kéo theo các lượt sau cũng lệch. Hay gặp nhất ở workload nhiều tool như search. - Thẻ XML nội bộ lọt ra ngoài. Model có thể phát ra thẻ
<thinking>hoặc các thẻ nội bộ khác vào phần trả lời. Nếu system prompt của bạn có luật bảo model đừng nghĩ hay đừng lập luận — gỡ đi, loại chỉ dẫn đó làm rò rỉ thẻ nhiều hơn.
Cách xử lý tốt nhất cho cả hai: đừng tắt thinking. Hãy giữ thinking và kiểm soát chi phí bằng effort thấp — với phần lớn tác vụ, thinking bật ở effort low cho kết quả tốt hơn thinking tắt ở cùng mức chi phí.
Nếu tích hợp của bạn buộc phải tắt, một chỉ dẫn gộp giảm nhẹ được cả hai:
When you use a tool, you may say a brief sentence first. If no tool can
express what the user asked for, say so instead of guessing. Do not include
internal or system XML tags in your response.
Lưu ý cách diễn đạt: chỉ dẫn gọi đích danh “thinking tags” kém hiệu quả hơn dạng tổng quát này — nên tránh nêu tên cụ thể.
7. Chạy lại effort sweep trên eval của bạn
Một khuyến nghị dễ bị bỏ qua: nếu bạn bê nguyên cấu hình effort từ model cũ sang, hãy chạy lại một effort sweep trên bộ eval của chính mình.
| Mức effort | Dùng khi |
|---|---|
low, medium | Cần rẻ và nhanh — chất lượng vẫn tốt ở phần lớn tác vụ. Dùng thoải mái làm cần gạt chính cho chi phí và độ trễ |
high (mặc định) | Điểm khởi đầu, rồi điều chỉnh theo eval |
xhigh | Coding và agentic work đòi hỏi cao |
Cùng logic đó cũng áp cho các bản vá prompt bạn từng viết để chữa điểm yếu vision của model cũ — Opus 5 mạnh ở biểu đồ, tài liệu, sơ đồ và việc dựng lại giao diện, nên hãy kiểm tra lại xem các workaround đó còn cần không. Với vision, cấp cho model tool để tự crop và tự đối chiếu là cần gạt kinh tế hơn là dồn vào thinking.
Nếu bạn chưa nắm hai trục model/effort, tôi đã tổng hợp ở bảng tra cứu theo từng tác vụ.
Tóm lại
Checklist ngắn khi mang một prompt cũ sang Opus 5:
- Xóa mọi chỉ dẫn verify, double-check, re-verify.
- Xóa “be conservative” trong prompt review — bảo nó báo hết rồi lọc riêng.
- Thêm chỉ dẫn độ dài cho cả ba tầng: hội thoại, tường thuật agentic, file ghi ra đĩa.
- Ràng buộc scope nếu task hẹp.
- Đặt luật hoặc trần cho subagent nếu quan tâm chi phí.
- Giữ thinking bật, hạ effort thay vì tắt.
- Chạy lại effort sweep — đừng bê nguyên cấu hình cũ.
Một quan sát cuối: gần như mọi mục trong danh sách trên đều là biến thể của cùng một ý — model mới đã tự làm nhiều thứ mà trước đây ta phải dặn. Prompt tốt cho Opus 5 là prompt nói mục tiêu và ranh giới, không phải prompt liệt kê các bước kiểm tra. Đây cũng chính là hướng dịch chuyển tôi đã ghi nhận khi viết về Fable 5.
Nguồn tham khảo
- Prompting Claude Opus 5 — Claude Platform Docs
- What’s new in Claude Opus 5 — Claude Platform Docs
- Effort — Claude Platform Docs
- Prompting best practices — Claude Platform Docs
Đối chiếu docs lần cuối ngày 28/07/2026.