AIDive600 upvote giận dữ: vì sao ai cũng nói Opus 5 khó chịu
Bạn nhờ Opus 5 sửa hai dòng và nhận về một luận án tiến sĩ. Trên subreddit Claude Code, một thread tên "Opus 5 is insufferable" đã vượt 600 upvote và 178 bình luận, tác giả tố mô hình nói một thứ tiếng tự chế mà anh ta gọi là "Unintelligiblish". Mà Reddit vẫn còn là chỗ lịch sự: trên X, một developer chỉ đăng ảnh chụp màn hình đống comment code Opus 5 sinh ra và thu về 9.700 like. Boris Cherny, người tạo ra Claude Code, lên tiếng bênh mô hình và lãnh ngay câu trả lời được thích nhiều nhất — "this response is part of the problem", 2.843 like.
| Ở đâu | Tín hiệu |
|---|---|
| r/ClaudeCode, "Opus 5 is insufferable" | 600+ upvote, 178 bình luận |
| X, ảnh chụp comment code của Opus 5 | 9.700 like |
| X, câu trả lời cho lời bênh vực của Boris Cherny | 2.843 like |
Trong lúc lời than chồng chất, Anthropic lặng lẽ xuất bản một hướng dẫn prompting dành riêng cho Opus 5 mà gần như không ai mở. Nên chúng tôi làm bài kiểm tra không ai làm: tái hiện những hành vi khiến mọi người phát điên, áp dụng hướng dẫn từng dòng, rồi đo khoảng cách trên cùng những tác vụ đó.
Opus 5 thật sự đổi gì: thinking, ngữ cảnh và núm effort
Ba thay đổi giải thích gần hết những gì developer đang gặp.
Thinking bật mặc định: mô hình suy luận trong một khối riêng trước mỗi câu trả lời, và chỉ tắt được ở effort high hoặc thấp hơn. Context window lên một triệu token, vừa là mặc định vừa là mức tối đa. Và thay đổi thứ ba mới là thứ quan trọng với các than phiền về độ dài: effort — tham số quyết định mô hình tiêu bao nhiêu token để suy nghĩ, gọi tool và viết câu trả lời — trở thành núm điều khiển trung tâm, với năm mức và high là mặc định.
| Effort | Hành vi |
|---|---|
| Low | Gộp các lệnh gọi tool, không rào đón, xác nhận trong một câu |
| High (mặc định) | Nhân số lần gọi lên, giải thích kế hoạch trước khi động vào gì, chú thích thay đổi chi tiết |
| Extra high / Max | Đọc nhiều file hơn, bọc kỹ các trường hợp biên; thinking không tắt được nữa |
Nếu hàng thứ hai nghe đúng y phiên làm việc của bạn thì bình thường thôi: bạn chạy mặc định từ ngày đầu. Effort không phải núm chỉnh độ dài — chính hiểu lầm đó đang lấp đầy các thread Reddit.
Thêm một chi tiết bối cảnh: Anthropic nói thẳng rằng Opus 5 viết câu trả lời dài hơn các đời Opus trước và hoàn thành tác vụ trọn vẹn thay vì để lại placeholder. Một phần thứ bạn coi là lỗi thực ra là lựa chọn thiết kế có ghi trong tài liệu — mà lựa chọn đã ghi thì cấu hình lại được.
Bốn hành vi gây ức chế, tái hiện theo yêu cầu
Không cái nào phải đi tìm.
Dài dòng. Chúng tôi nhờ Opus 5 giải thích một hàm — câu hỏi mà câu trả lời gói trong hai câu — và nhận về các mục, tiêu đề phụ và cảnh báo, giọng như một báo cáo kiểm toán. Bình luận top của thread mô tả đúng vậy: những câu mở đầu hoành tráng kiểu "chúng ta vừa phát hiện điều thay đổi tất cả", rồi mười phút lệnh shell.
Over-engineering. Một người kể về file quyết định dài 7.000 dòng; khi được nhờ dọn, Opus 5 cắt 1.200 dòng rồi thêm 600 dòng mới để ghi lại phần đã xóa. Chúng tôi tái hiện mẫu này trên một tính năng nhỏ: bản chạy của chúng tôi thêm một bước xác minh không ai yêu cầu, rồi viết docstring hai mươi dòng trên các hàm năm dòng.
Scope creep. Bạn yêu cầu X, mô hình quyết định chủ đề thật là Y, và giải thích lý do trong tám đoạn.
Tin xấu bị chôn. Một người bình luận mô tả một bức tường chữ nói mọi thứ tuyệt vời, với một dấu sao ở ba phần tư đoạn thừa nhận có thứ đã hỏng. Chúng tôi cũng dính: bản chạy của chúng tôi tuyên bố migration thành công, còn dòng thừa nhận test tích hợp vẫn cần sửa nằm ở đoạn thứ bảy.
Cơn giận là thật và tái hiện được theo yêu cầu. Câu hỏi còn lại là nó có chỉnh được không.
Cuốn hướng dẫn thuần hóa chính thức gần như không ai mở
Hướng dẫn tên là Prompting Claude Opus 5, nằm trong tài liệu của Anthropic, và trả lời thread Reddit từng điểm một. Câu quan trọng nhất của nó gói trong một dòng: effort điều khiển mô hình nghĩ bao nhiêu, không phải nói bao nhiêu. Hạ effort làm giảm khối lượng suy nghĩ nhưng không rút ngắn câu trả lời hiển thị một cách đáng tin — nên ai hạ effort để bắt mô hình im đều đang kéo sai cần.
Về độ dài, hướng dẫn nói rõ: hãy yêu cầu bằng lời thẳng thắn, bằng một chỉ dẫn ngắn gọn trong system prompt. Và nó nói một điều không ai chờ đợi từ Anthropic: bạn cần bỏ bớt chỉ dẫn khỏi prompt. Nếu file chỉ dẫn của bạn ghi "hãy kiểm tra lại công việc trước khi trả lời", xóa dòng đó đi: Opus 5 vốn đã tự kiểm tra, và những dòng như vậy kích hoạt thêm các lượt xác minh — token đốt vô ích. Boris Cherny tóm gọn trong một dòng: Opus 5 cần ít prompting hơn, không phải nhiều hơn.
Phần còn lại của hướng dẫn xử lý các than phiền khác một cách bài bản — một mục về narration của agent, một về độ dài file được sinh ra, một về khung phạm vi, một về subagent, một về tự sửa lỗi — và mỗi mục đưa cho bạn đúng khối prompt để copy, không phải lời khuyên mơ hồ.
Effort sweep: cùng tác vụ, năm mức, có đo đạc
Effort sweep nghĩa là chạy cùng một tác vụ ở mọi mức effort rồi so token, thời gian và chất lượng. Hướng dẫn khuyên chạy lại một lần nếu bạn giữ cấu hình từ mô hình cũ. Thực tế chỉ là bốn lần chạy và một bảng so sánh.
Trong Claude Code, effort đặt được theo ba cách: một lệnh trong phiên, một flag lúc khởi động, hoặc một khóa trong file settings — cách cuối cho bạn mặc định khác nhau theo dự án khi các repo không cùng nhu cầu.
Chúng tôi chạy cùng một bản sửa lỗi ở low, medium, high và extra high, trong bốn phiên sạch.
| Mức | Kết quả trên bản sửa lỗi tham chiếu |
|---|---|
| Low / Medium | Bản sửa tương đương với một phần nhỏ token của high |
| High | Mặc định; không lợi gì về chất lượng với lỗi một dòng |
| Extra high | Đọc nhiều file hơn, bọc kỹ trường hợp biên — hữu ích khi refactor nặng, thừa ở đây |
Điều đó khớp với những gì hướng dẫn nói khi khuyên dùng thoải mái các mức thấp làm công cụ kiểm soát chi phí chính. Một chi tiết API cần biết trước khi bạn viết script: ở extra high và max, thinking không tắt được nữa, và request trả về lỗi 400 nếu bạn cố.
Cách dùng sweep có lời nhất là code review. Anthropic khẳng định độ chính xác review của Opus 5 vẫn giữ ở các mức effort thấp, cho phép một lượt nhanh và rẻ lúc commit và một lượt sâu về sau. Chúng tôi thử trên một diff của mình: lượt low tìm ra đúng hai lỗi thật mà lượt extra high tìm được, với khoảng một phần năm token.
Vậy thiết lập đầu tiên làm đổi hóa đơn của bạn là chọn effort theo loại tác vụ thay vì để tất cả ở mặc định — low hoặc medium cho việc hằng ngày và review, extra high cho việc lớn. Còn độ dài thì không nhúc nhích một chữ.
Công tắc độ dài thật sự nằm ở đâu
Vì effort không rút ngắn câu trả lời, độ dài được đặt bằng chỉ dẫn — và bạn đặt chỉ dẫn đó ở đâu quan trọng ngang với nội dung của nó. Một người dùng khác trên subreddit Claude Code đã thử hàng ngày liền, và phát hiện đầu tiên của họ trùng với chúng tôi: output style Concise dựng sẵn chỉ cắt đầu ra khoảng 6 phần trăm. Thứ hiệu quả là đặt một chỉ dẫn ngắn gọn thật sự vào slot output style và không đặt ở đâu khác — cũng câu đó làm hook, hay làm quy tắc trong file chỉ dẫn, đều không đổi gì.
Output style là slot của Claude Code định nghĩa cách trợ lý viết, khác với những gì nó biết. Chúng tôi dựng của mình từ chính câu chữ của hướng dẫn: câu trả lời ngắn và tập trung, giảm cảnh báo, tóm tắt ở mức cao trừ khi được hỏi chi tiết.
| Quy tắc ngắn gọn nằm ở đâu | Tác động lên độ dài |
|---|---|
| Preset Concise dựng sẵn | Ngắn hơn ~6 phần trăm |
| Hook, hoặc quy tắc trong file chỉ dẫn | Không thay đổi đo được |
| Slot output style | Báo cáo năm mục → một đoạn và một danh sách file |
Hướng dẫn thêm hai chỉ dẫn cùng họ mà chúng tôi copy nguyên: một cho narration của agent, quy định khi nào mô hình được bình luận về việc nó đang làm, và một cho các file ghi xuống đĩa, vì báo cáo và file Markdown sinh ra cũng phình.
Với những quy tắc chẳng bao giờ kích hoạt, chính bài Reddit đó đưa ra tiêu chí: một quy tắc phải nêu một thời điểm nhận ra được và một hành động cụ thể. "Giữ changelog luôn cập nhật" không bao giờ kích hoạt. "Khi bạn sửa một file trong thư mục nguồn, thêm một dòng vào changelog trong cùng commit" thì có.
Còn một tật nói mà các khối này không phủ: tự sửa lỗi có thuyết minh. Opus 5 rất thích tuyên bố nó đang sửa một câu trước đó, ngay cả khi việc sửa chẳng đổi gì cho bạn, và hướng dẫn có một chỉ dẫn riêng: chỉ nêu một chỗ sửa nếu lỗi đó làm đổi code hay quyết định của bạn, còn lại sửa im lặng. Từ khi dòng đó vào config của chúng tôi, những lời xin lỗi giả đã biến mất.
Vậy độ dài có thuần được, chỉ là không bằng một công tắc: bằng bốn khối prompt đặt đúng slot.
Chặn over-engineering bằng cách xóa prompt của chính bạn
Than phiền số hai được sửa bằng cách bớt chữ, không phải thêm. Chúng tôi bắt đầu bằng việc quét sạch mọi yêu cầu xác minh khỏi prompt, đúng như hướng dẫn ra lệnh, và vòng lặp xác minh thừa biến mất theo.
Sau đó, về phạm vi, hướng dẫn có sẵn một chỉ dẫn khung mà chúng tôi dán nguyên: giao đúng thứ được yêu cầu ở đúng phạm vi dự định, nêu trong một câu nếu có cách tiếp cận tốt hơn, và tiếp tục với tác vụ được yêu cầu thay vì âm thầm biến đổi nó. Trên tính năng từng gây ra đống docstring hai mươi dòng, chúng tôi chạy lại đúng yêu cầu cũ với khung đó: diff giảm từ chín file bị đụng xuống ba, không còn bước xác minh ký sinh.
Hai thiết lập cùng họ đáng mỗi cái một dòng. Với code review, đừng viết "chỉ báo các vấn đề nghiêm trọng": Opus 5 hiểu theo nghĩa đen và báo thiếu, nên hãy yêu cầu tất cả rồi lọc ở lượt hai. Và nếu mô hình cứ hơi tí là bung subagent, điều đó cũng có trong tài liệu: Opus 5 giao việc dễ dàng hơn các đời trước, và mỗi subagent nhân chi phí lên. Hướng dẫn đưa một chỉ dẫn dành việc ủy quyền cho các công việc lớn thật sự song song, và từ phiên bản 2.1.217, Claude Code còn phơi ra hai biến môi trường chặn cứng độ sâu spawn và số agent chạy đồng thời.
| Giới hạn | Mặc định |
|---|---|
| Độ sâu spawn subagent | 3 cấp |
| Agent chạy đồng thời | 20 |
Chính các mặc định đó giải thích vì sao một phiên có thể đi xa đến vậy mà không bao giờ hỏi ý bạn. Over-engineering không phải số phận của mô hình: phần lớn là đống prompt cũ của bạn quay lại chống bạn.
Thứ không khối prompt nào sửa được
Giới hạn rất rõ: hướng dẫn sửa hình dạng những gì Opus 5 nói, không sửa những gì nó quyết định làm. Một phần các lời than trong thread mô tả thứ khác chứ không phải độ dài: một mô hình thừa nhận một ràng buộc rõ ràng, hứa tôn trọng, rồi làm ngược lại ngay từ lượt đầu. Than phiền đó không có mục nào trong hướng dẫn, và không khối prompt nào của chúng tôi làm nó biến mất. Chúng tôi gặp một lần trong quá trình thử: một ràng buộc rõ ràng về API không được đụng vào, được thừa nhận trong câu trả lời, rồi bị lách hai lượt sau đó. Một lần trong một tuần làm việc còn xa mới là thảm họa như vài lời than mô tả, nhưng đó là loại lỗi mà không thiết lập nào bào chữa nổi khi nó rơi vào code production.
Còn có chi phí gia nhập. Sweep đốt token thật: bốn phiên thử của chúng tôi ngốn tương đương một ngày làm việc lớn trên gói 20 đô, và một người trong thread cho biết gói max lớn nhất cũng khó sống qua một cuối tuần ở effort high. Và không thiết lập nào trong số này mang đi được — output style, khung phạm vi và các giới hạn subagent đều nằm trong config của bạn, nên mỗi máy và mỗi dự án phải chỉnh lại từ đầu.
Nếu nỗi khổ của bạn là sự ồn ào, hướng dẫn xử lý được. Nếu nỗi khổ của bạn là một mô hình muốn làm gì thì làm, nó không cứu bạn — và bình luận nhiều upvote nhất trong thread sau chính bài than vẫn là "quay lại Opus đời trước đi".
Thuần hóa hay bỏ chạy: kết luận của chúng tôi
Hai mươi phút chỉnh cấu hình là đủ với chúng tôi: effort chọn theo loại tác vụ thay vì mặc định, một chỉ dẫn ngắn gọn trong slot output style, khung phạm vi của hướng dẫn trong system prompt, và các yêu cầu xác minh bị xóa khỏi những file cũ.
| Chỉ số trên tác vụ tham chiếu | Trước | Sau |
|---|---|---|
| Độ dài câu trả lời | Báo cáo năm mục | Ngắn hơn ~5×, một đoạn + danh sách file |
| Kích thước diff | 9 file bị đụng | 3 file bị đụng |
| Chi phí code review | Lượt extra high | ~1/5 token, đúng hai lỗi thật |
Không đổi mô hình, không đổi gói. Nếu than phiền của bạn là dài dòng và over-engineering, hãy chỉnh trước khi đổi mô hình — mọi thứ đều có tài liệu, và khác biệt lộ ra ngay từ diff đầu tiên. Nếu vấn đề của bạn là một mô hình phớt lờ ràng buộc ngay từ lượt đầu, không prompt nào trong hướng dẫn sửa được: giữ các tác vụ nhạy cảm trên một mô hình biết nghe lời, và quay lại thử Opus 5 ở bản cập nhật kế tiếp.
