Giải pháp cho vấn đề tư duy nông ở Claude Opus 5

Tổng quan

Ngay sau khi chuyển Claude Code sang Opus 5, tôi nhận thấy sự gia tăng đột ngột các phản hồi dạng văn xuôi dài dòng và xu hướng "suy nghĩ nông" (không có khả năng tư duy cấu trúc).

Sau khi điều tra, vấn đề không phải do mô hình kém hay các quy tắc bị hỏng; mà là prompt hệ thống nội bộ được cung cấp cho Opus 5 trong thế hệ Claude 5 đã thay đổi đáng kể, và các quy tắc cũ không được viết dựa trên tiền đề mới này.

Bài viết này ghi lại quá trình cô lập nguyên nhân và sửa đổi quy tắc để phù hợp với prompt hệ thống mới. Nó dành cho người dùng Claude Code, những người cảm thấy hiệu quả của CLAUDE.md hoặc các quy tắc của họ đã thay đổi kể từ khi nâng cấp lên thế hệ mô hình mới.

Vấn đề

Sử dụng cùng một phiên và cùng một quy tắc, những điều sau đây xảy ra ngay sau khi chuyển mô hình sang Opus 5:

• Các giải thích tình huống trở nên nhạt nhẽo, dài dòng dạng văn xuôi mà không có tiêu đề hoặc phần.
• Giải thích nguyên nhân dừng lại ở một lớp duy nhất (liệt kê các triệu chứng song song mà không đào sâu vào "lý do").
• Không có tiêu chí đánh giá nào được đưa ra khi đề xuất nhiều lựa chọn.
• Các danh mục hoặc số thứ tự được thiết lập trong một lượt bị sắp xếp lại thành các cấu trúc khác trong lượt tiếp theo.
• Mô hình sẽ bỏ qua việc phản hồi đầu vào của tôi và ngay lập tức chuyển sang thực thi công cụ (tác vụ).

Phần khó chịu là ngay cả khi được nhắc "suy nghĩ sâu hơn", nó vẫn trả về các câu trả lời rời rạc trong khi vẫn ở trạng thái suy nghĩ nông. Việc sửa lỗi lặp đi lặp lại không hiệu quả, dẫn đến tranh luận thay vì thảo luận hiệu quả.

Đó không chỉ là vấn đề về chất lượng phản hồi đơn lẻ; mà toàn bộ quá trình suy luận thông qua đối thoại đã bị phá vỡ.

Manh mối chính

Điều này không xảy ra với các mô hình khác sử dụng cùng một quy tắc (chi tiết về sự khác biệt này có trong phần phụ lục). Nếu bản thân các quy tắc đã bị suy giảm, vấn đề lẽ ra phải xuất hiện trên tất cả các mô hình. Vì chỉ có mô hình thay đổi, tôi bắt đầu điều tra dựa trên giả định rằng "môi trường mà các quy tắc giả định" đã thay đổi.

Nguyên nhân: Thay đổi trong Prompt Hệ thống được cung cấp cho Opus 5

Trong thế hệ Claude 5 của Claude Code, prompt hệ thống nội bộ đã được giảm khoảng 80% so với các thế hệ trước. Bằng cách đo lường prompt thực tế được gửi đến Opus 5 (bằng cách vô hiệu hóa các tiêm kiểu đầu ra và yêu cầu mô hình trích dẫn prompt của chính nó; dòng Claude Code v2.1, tháng 7 năm 2026), cấu trúc như sau:

1. Nhận dạng, Tuyên bố vai trò và Chính sách bảo mật — Phần mở đầu.
2. Thông số kỹ thuật của Harness (# Harness) — Giải thích về môi trường thực thi, chẳng hạn như đầu ra được hiển thị dưới dạng markdown.
3. Thông tin môi trường và Mô tả tính năng (# Hướng dẫn theo phiên / # Bộ nhớ / # Môi trường / # Quản lý ngữ cảnh) — CWD, trạng thái git, ID mô hình, bộ nhớ và cơ chế nén ngữ cảnh.
4. Kỷ luật phạm vi (# Cung cấp công việc) — Không thu hẹp hoặc mở rộng phạm vi yêu cầu khi chưa được phép.
5. Nghi thức sửa lỗi (# Sửa lỗi) — Giữ các sửa lỗi ngắn gọn mà không thêm lời xin lỗi hoặc đoạn mở đầu.

Hai đặc điểm cụ thể liên quan trực tiếp đến các triệu chứng đã xuất hiện:

• Đặc điểm 1: Không có hướng dẫn nào về kiểu phản hồi. Không có quy tắc nào về văn xuôi so với cấu trúc, sử dụng tiêu đề hoặc bảng biểu, hay sự ngắn gọn — các quy tắc định dạng vốn rất phong phú trong các thế hệ trước đã hoàn toàn biến mất.
• Đặc điểm 2: Một chính sách tự chủ "Hành động trước" đã được thêm vào. Trích dẫn nguyên văn: "Khi bạn có đủ thông tin để hành động, hãy hành động." và "Nếu bạn đang cân nhắc một lựa chọn, hãy đưa ra một đề xuất, không phải một khảo sát đầy đủ."

Đọc lại các triệu chứng thông qua hai đặc điểm này, mọi thứ trở nên rõ ràng. Vì không có quy tắc về kiểu phản hồi, xu hướng đầu ra thô của mô hình — văn xuôi phẳng — xuất hiện. Chính sách "đề xuất thay vì khảo sát" khuyến khích việc bỏ qua các tiêu chí đánh giá.

Bạn có thể nghĩ, "Nếu các quy tắc trống, thì các quy tắc tùy chỉnh của tôi lẽ ra phải trở thành thẩm quyền duy nhất và hoạt động tốt hơn?" Trong thực tế, điều ngược lại đã xảy ra. Khoảng trống này không phải là một khoảng trống dành cho người dùng; nó được ủy quyền cho hành vi mặc định được tích hợp sẵn trong mô hình trong quá trình huấn luyện. "Prompt tinh gọn" giả định rằng các mô hình thế hệ mới tuân theo các hành vi được nội bộ hóa mà không cần hướng dẫn chi tiết. Thay vì được lấp đầy bởi các quy tắc của bạn, khoảng trống được lấp đầy bởi các mặc định được huấn luyện trước của mô hình. Và mặc định của Opus 5 là văn xuôi ngắn gọn, hành động trước khi xác nhận.

Các quy tắc cũ của tôi sử dụng các hướng dẫn chung chung như "phân tích tình huống một cách có cấu trúc", "thêm tiêu chí đánh giá vào nhiều lựa chọn" và "phản hồi trước khi hành động". Chúng được viết với giả định rằng chúng sẽ được đọc cùng với một prompt hệ thống nặng về kiểu phản hồi. Mặc dù đủ tốt vào thời điểm đó, nhưng chúng quá yếu về cả tính cụ thể (đặt tên cho văn bản gốc) và cách phân phối (đến được mô hình ngay trước khi hành động) để ghi đè lên các mặc định đã được huấn luyện. Đây là bản chất thực sự của các triệu chứng.

Bản thân Anthropic gọi sự giảm thiểu này là "prompt hệ thống tinh gọn" trong nhật ký thay đổi (v2.1.154), phản ánh sự thay đổi trong triết lý thiết kế: "Các mô hình thế hệ mới đã nội bộ hóa các hành vi thông qua huấn luyện, vì vậy các hướng dẫn chi tiết có thể gây ra xung đột hoặc mâu thuẫn." Để biết giải thích chi tiết, hãy xem Prompt Hệ thống Claude Code Giảm 80% — Triết lý Thiết kế Prompt cho Thế hệ Fable 5. Để biết nguồn chính, hãy tham khảo Nhật ký thay đổi Claude Code và Hướng dẫn Prompt Claude Fable 5 (Hướng dẫn Chính thức).

Tóm lại, các triệu chứng được xác định bởi sự kết hợp của "các quy tắc × prompt thực tế được gửi đến mô hình đó." Bạn không thể tìm ra nguyên nhân bằng cách chỉ nhìn vào các quy tắc. Bài học đầu tiên là bản cập nhật mô hình cũng là bản cập nhật prompt hệ thống.

Biện pháp 1: Xác định các mâu thuẫn và ghi đè bằng cách đặt tên cho văn bản gốc

Đầu tiên, tôi đối chiếu tất cả các quy tắc với prompt hệ thống mới để xác định xem chúng nói ngược lại ở đâu. Đối với các quy tắc nhằm ghi đè chính sách hệ thống, tôi đã viết lại chúng để trích dẫn rõ ràng văn bản gốc và tuyên bố quyền ưu tiên.

Bắt đầu với những gì không hiệu quả: thêm các điều chung chung như "viết nhiều lựa chọn với tiêu chí đánh giá" là không hiệu quả.

Khi được đặt cùng với chính sách hệ thống "đưa ra một đề xuất, không phải một khảo sát đầy đủ", không có manh mối nào về việc cái nào được ưu tiên. Bằng cách đặt tên cho xung đột, quyền ưu tiên trở nên rõ ràng.

Đối với những thứ hoàn toàn không có trong prompt, như các quy tắc kiểu phản hồi, hướng dẫn hoạt động để "lấp đầy khoảng trống" thay vì ghi đè.

Tôi cũng sửa đổi cách viết các điều kiện kích hoạt. Các điều kiện như "đối với các thay đổi quan trọng" hoặc "nếu được đánh giá là môi trường sản xuất" sẽ thất bại ngay khi mô hình không phân loại tình huống theo cách đó. Tôi đã thay đổi các bộ kích hoạt thành các dữ kiện có thể quan sát được như "đã nhận được ngắt" hoặc "lời nói của người dùng có chứa một sự sửa lỗi."

Biện pháp 2: Mô tả các hành động mong muốn thay vì các điều cấm

Các quy tắc cũ là sự tích lũy của những "điều không nên làm." Các điều cấm giúp phát hiện vi phạm nhưng không truyền đạt được phải làm gì thay thế. Khi một điều cấm xung đột với một chính sách hệ thống mới, mô hình tìm ra một lỗ hổng: "tuân theo chính sách hệ thống trong khi tránh điều cấm." Tôi đã chuyển đổi các hạn chế tiêu cực thành các mô tả về hành vi mong muốn.

• Trước đây: "Không đề xuất một commit nếu các bài kiểm tra chưa hoàn tất."
• Sau đó: "Khi đề xuất một commit, hãy bao gồm kết quả chạy sản phẩm từ góc nhìn của người dùng cuối trong nội dung chính."

Tôi đã kiểm tra các quy tắc được viết lại dựa trên các tiêu chí sau, đặc biệt là đối với các biểu thức xung đột với Prompt Hệ thống:

1. Quy tắc có tự chứa đựng không? (Phạm vi, ví dụ và tiêu chí trong một chỗ)
2. Bộ kích hoạt có phải là một dữ kiện có thể quan sát được không?
3. Nó có mâu thuẫn với prompt hệ thống nội bộ không?
4. Nó có mô tả hành vi mong muốn không? (Không chỉ là danh sách các lệnh cấm)
5. Có một tiêu chí duy nhất để đánh giá không? (Không phải là danh sách các kịch bản)
6. Sự nhấn mạnh (IMPORTANT) có được dành riêng cho những gì thực sự không thể bỏ qua không?
7. Nó có được viết như trạng thái cuối cùng mong muốn không? (Không ép buộc các mẫu hoặc bước trước tiên)
8. Việc tuân thủ có thể được xác định sau khi thực tế không?

Tôi đã thu hẹp các dấu nhấn mạnh (IMPORTANT) chỉ còn các cổng bảo mật và phê duyệt. Một tài liệu mà mọi thứ đều được nhấn mạnh cũng giống như một tài liệu không có gì được nhấn mạnh.

Biện pháp 3: Chọn "Lớp" để phân phối hướng dẫn

Vấn đề không chỉ là văn bản. Claude Code có ít nhất bốn đường dẫn để phân phối hướng dẫn đến mô hình và chúng khác nhau đáng kể về hiệu quả.

Vì API là phi trạng thái, nội dung từ tất cả các đường dẫn được gửi đến mô hình trong mọi yêu cầu (mọi lượt). Sự khác biệt nằm ở "khi nào nội dung được hoàn thiện" và "nó được đặt ở đâu trong prompt = mức độ gần với hành động đang được thực hiện."

Đáng ngạc nhiên, output style — mà tài liệu nói "thay thế prompt hệ thống" — đã được phân phối dưới dạng tệp đính kèm trong mọi lượt theo nhật ký phiên.

Tôi đã viết hai loại hướng dẫn trong output style này: Kiểu phản hồi (Biện pháp 1: viết có cấu trúc, thêm tiêu chí) và Quy trình (phản hồi người dùng trước khi bắt đầu công việc). Kết quả là hỗn hợp.

Trong khi các hướng dẫn về Kiểu phản hồi cho thấy sự cải thiện, vấn đề Quy trình — bỏ qua phản hồi để bắt đầu công việc — đã không dừng lại thông qua output style. Cuối cùng tôi đã ngăn chặn thói quen này bằng cách sử dụng một hook UserPromptSubmit để tiêm một dòng duy nhất ngay sau mỗi lời nói của người dùng: "Viết một phản hồi cho lời nói này (câu trả lời, hoặc sự thừa nhận và kế hoạch) trong nội dung chính trước khi thực thi các công cụ."

Chi phí là khoảng 50 token cho mỗi lời nói. Ngay cả 100 lời nói cũng chỉ tốn 5.000 token, không đáng kể so với ngữ cảnh 200K. Quy tắc chung tôi rút ra rất đơn giản: Các hướng dẫn được phân phối "ngắn gọn, mọi lúc, ngay trước hành động" là hiệu quả nhất. Nhiều hướng dẫn không hiệu quả không phải do nội dung xấu; chúng chỉ không có sẵn tại thời điểm hành động.

Kết quả

Dưới đây là kết quả đã được xác nhận cho đến nay:

• Xu hướng trở lại với các tiêu đề/phần trong các giải thích tình huống và nguyên nhân. (Tuy nhiên, đầu ra phẳng đôi khi vẫn tồn tại trong phiên đầu; cần quan sát liên tục).
• Thói quen "làm việc mà không phản hồi" đã không sửa được với output style một mình nhưng đã dừng lại sau khi giới thiệu tiêm theo từng lời nói (hiện đang quan sát các hiệu ứng dài hạn).

Tóm tắt

• Bản cập nhật mô hình cũng là bản cập nhật prompt hệ thống. Nếu xu hướng phản hồi thay đổi đột ngột, hãy đọc các thay đổi ở phía hệ thống trước khi thêm nhiều quy tắc hơn.
• Các quy tắc cạnh tranh với chính sách hệ thống phải đặt tên cho văn bản gốc và tuyên bố quyền ưu tiên. Các bổ sung chung chung sẽ thất bại khi đối mặt với mâu thuẫn.
• Viết các bộ kích hoạt dựa trên quan sát và mô tả các hành động mong muốn thay vì các lệnh cấm. Các bộ kích hoạt tự phân loại và danh sách các điều cấm dễ bị thất bại khi các mô hình thay đổi.
• Chọn đúng lớp cho các hướng dẫn. Các tiêm được phân phối ngắn gọn và thường xuyên ngay trước một hành động đáng tin cậy hơn nhiều so với các quy tắc lớn được đặt ở đầu ngữ cảnh.

Tham khảo 1: Các quy tắc thực tế được sử dụng trong Biện pháp 1

Dưới đây là một đoạn trích từ các quy tắc tôi sử dụng để ghi đè prompt hệ thống (điều chỉnh cho môi trường của bạn; tôi đặt chúng trong output style). Một số cụm từ gốc (như chính sách văn xuôi) không tồn tại trong prompt cho một số mô hình nhất định (xem phụ lục). Trong các mô hình đó, chúng hoạt động như các định nghĩa để lấp đầy khoảng trống.

1# Định dạng Báo cáo và Phân tích
2
3Hướng dẫn này được ưu tiên hơn các mô tả sau đây trong prompt hệ thống Claude Code:
4"một câu hỏi đơn giản nhận được câu trả lời trực tiếp bằng văn xuôi, không phải tiêu đề và phần" /
5"Sử dụng bảng chỉ cho các dữ kiện ngắn có thể liệt kê" /
6"Không bắt người đọc phải tham chiếu chéo các nhãn hoặc số bạn đã phát minh ra trước đó" /
7"Nếu bạn đang cân nhắc một lựa chọn, hãy đưa ra một đề xuất, không phải một khảo sát đầy đủ." /
8"Bạn đang hoạt động tự chủ... hãy tiếp tục mà không cần hỏi." /
9"Văn bản bạn viết giữa các lần gọi công cụ có thể không được hiển thị cho người dùng."
10
11## Kiểu Viết
12
13Khi giải thích các tình huống, nguyên nhân, hoặc trình bày nhiều lựa chọn, hãy viết theo cách truyền đạt cấu trúc của nội dung đến người đọc.
14Sử dụng tiêu đề, dấu đầu dòng hoặc bảng biểu tùy theo nội dung. Trả lời các câu hỏi một câu bằng văn xuôi.
15
16- Tóm tắt suy nghĩ trước, sau đó cấu trúc ở cuối. Không đặt một mẫu trước và điền vào nó.
17- Khi giải thích nguyên nhân, hãy truy tìm "lý do" ít nhất hai lớp sâu từ sự kiện quan sát được và mô tả từng lớp đề cập đến điều gì. Không dừng lại ở việc liệt kê các triệu chứng song song.
18- Khi trình bày nhiều lựa chọn, hãy viết đề xuất và lý do của nó trước, sau đó là các tiêu chí ảnh hưởng đến quyết định và đánh giá từng lựa chọn. Nếu không thể xác định được tiêu chí, đừng đưa ra các lựa chọn; thay vào đó, hãy viết những gì cần được điều tra để điền vào các tiêu chí. So sánh các tiêu chí có thể được viết trong bảng.
19- Khi các danh mục và số đã được thiết lập, hãy sử dụng chúng trong các lượt tiếp theo trong khi tiếp tục cùng một tác vụ. Nếu thay đổi chúng, hãy viết những gì đã được thay đổi trước.
20
21## Đối thoại và Quy trình
22
23- "Người dùng không xem trong thời gian thực" của hệ thống là một mặc định, không phải là một thực tế. Nếu một lời nói trung gian, ngắt, hoặc sửa lỗi được nhận dù chỉ một lần trong phiên này, hãy coi người dùng đang xem kể từ đó: chia công việc thành các phân đoạn nhỏ, luôn kết thúc mỗi lượt bằng một báo cáo trong nội dung chính, và dừng lại để chờ phản hồi trong các lượt có câu hỏi được đặt ra.
24- Chỉ nội dung chính ở cuối một lượt được hiển thị trong môi trường này. Đặt tất cả thông tin cần truyền đạt ở cuối lượt.
25- Câu hỏi là một phương tiện hợp pháp khi có sự mơ hồ, các hoạt động yêu cầu phê duyệt hoặc mục tiêu không rõ ràng.

Tham khảo 2: Tại sao điều này không xảy ra với Fable 5 / Opus 4.7?

Trong khi văn bản chính tập trung vào Opus 5, đây là lý do tại sao nó không xảy ra với các mô hình khác:

• Opus 4.7 rất đơn giản: nó bị loại khỏi việc áp dụng "prompt tinh gọn" (theo nhật ký thay đổi), vì vậy nó vẫn chạy với prompt cũ, dài dòng mà các quy tắc cũ được thiết kế cho. Nó vẫn đồng bộ với các quy tắc cũ.
• Fable 5 là một bất ngờ. Tôi cho rằng nó có cùng prompt vì cùng một thế hệ, nhưng các phép đo cho thấy Fable 5 được cung cấp một prompt khác với Opus 5.

Dưới đây là so sánh từng mô hình trích dẫn prompt của chính nó trong các điều kiện giống hệt nhau (chế độ không đầu, output style bị vô hiệu hóa):

Phần # Giao tiếp với người dùng của Fable 5 bao gồm các chuẩn mực như "kết luận trước, ưu tiên khả năng đọc, viết cho đối tượng." Ngoài "đưa ra một đề xuất, không phải một khảo sát đầy đủ", nó bao gồm chính sách văn xuôi "một câu hỏi đơn giản nhận được câu trả lời trực tiếp bằng văn xuôi, không phải tiêu đề và phần." Bởi vì bản thân prompt chứa các chuẩn mực viết này, định dạng đầu ra ít có khả năng bị sụp đổ hơn, và trong các quan sát của tôi, nó duy trì sự tuân thủ các quy tắc của người dùng.

Tóm lại, vấn đề xuất hiện mạnh mẽ ở Opus 5 vì ba yếu tố hội tụ:

1. Nó được cung cấp một prompt không có quy tắc kiểu viết nào, để lộ xu hướng đầu ra thô.
2. Các chính sách như "hành động khi có đủ thông tin" và "đề xuất thay vì khảo sát" khuyến khích hành động ngay lập tức và bỏ qua các tiêu chí.
3. Các quy tắc cũ vẫn dựa trên prompt chi tiết cũ và không được định hình để lấp đầy khoảng trống mới này.