Một Lý Thuyết Thiết Kế Mới Cho Kỷ Nguyên Mà Nhiều Quy Tắc Hơn Lại Khiến AI Yếu Đi
Vào ngày 25 tháng 7 năm 2026, Thariq Shihipar của nhóm Claude Code đã công bố "Những Quy Tắc Mới của Kỹ Thuật Ngữ Cảnh cho Mô Hình Claude 5."
https://x.com/trq212/status/2080710971228918066?s=20
Tiết lộ gây sốc nhất là điều này:
Anthropic đã giảm hơn 80% system prompt cho Claude Code trên Claude Opus 5 và Claude Fable 5. Mặc dù vậy, họ báo cáo không có sự suy giảm hiệu suất nào có thể đo lường được trong các đánh giá về khả năng lập trình.
Cho đến gần đây, cách để cải thiện độ chính xác của AI là thêm nhiều quy tắc, viết quy trình chi tiết, liệt kê các điều cấm và cung cấp lượng lớn các câu chuyện thành công.
Tuy nhiên, ở thế hệ Claude 5, lẽ thường đó đang bắt đầu đảo ngược.
Thêm quá nhiều quy tắc không làm cho AI thông minh hơn; nó thực sự khiến AI yếu đi.
Điều mà Thariq, một thành viên của nhóm phát triển Claude Code, đã chứng minh lần này không chỉ là một mẹo prompt. Đó là sự thay đổi trong chính "triết lý thiết kế thông tin" được sử dụng để điều khiển các tác nhân AI.
Có ba điểm chính rút ra từ bài viết này:
Thứ nhất, điều quan trọng trong tương lai sẽ không phải là khả năng viết prompt dài, mà là khả năng thiết kế "cái gì, khi nào và ở cấp độ phân cấp nào" để hiển thị thông tin cho AI.
Thứ hai, CLAUDE.md và Skills không phải là những nhà kho để nhồi nhét kiến thức. Chúng là các hệ thống định vị để Claude truy xuất thông tin cần thiết vào thời điểm cần thiết.
Thứ ba, trong kỷ nguyên của kỹ thuật ngữ cảnh Claude 5, bạn không nên viết các quy tắc để ngăn AI đưa ra phán đoán; bạn cần tạo ra một môi trường nơi AI có thể phán đoán một cách chính xác.
Điều này không chỉ dành riêng cho Claude Code.
Nó áp dụng trực tiếp vào thiết kế của tất cả các tác nhân AI: sản xuất bài viết, tạo trang web, phát triển ứng dụng, chỉnh sửa video, nghiên cứu, AI nội bộ, hỗ trợ khách hàng và hỗ trợ bán hàng.
Kỹ Thuật Ngữ Cảnh (Context Engineering) Thực Chất Là Gì?
Nhiều người nghĩ rằng chỉ những tin nhắn được gửi đến AI mới là "prompt."
Ví dụ, giả sử bạn yêu cầu Claude Code như sau:
Hãy sửa màn hình đăng nhập này để có thiết kế cao cấp hơn.
Tuy nhiên, thông tin mà Claude thực sự nhận được không chỉ là một câu này.
System prompt của Claude Code, CLAUDE.md của dự án, CLAUDE.md toàn cục của người dùng, tên và mô tả Skill, nội dung của Skill được gọi, định nghĩa công cụ MCP, các cuộc trò chuyện trước đây, các tệp đã tải, kết quả thực thi lệnh, Auto-memory, thư mục làm việc hiện tại, các thiết kế được tham chiếu và kết quả kiểm thử — tất cả được tập hợp lại thành một ngữ cảnh khổng lồ.
Trong Claude Code, ngay cả trước khi người dùng gõ tin nhắn đầu tiên, CLAUDE.md, Auto-memory, tên công cụ MCP và mô tả Skill đã có trong ngữ cảnh. Khi công việc bắt đầu, các tệp đã tải và kết quả công cụ được thêm vào, và ngữ cảnh ngày càng lớn khi cuộc trò chuyện kéo dài.
Nói cách khác, prompt chỉ là "yêu cầu hiện tại."
Ngữ cảnh là toàn bộ môi trường làm việc quyết định cách Claude diễn giải yêu cầu đó, ưu tiên điều gì, sử dụng công cụ nào, thực thi đến mức độ nào và coi điều gì là câu trả lời đúng.
Tôi nghĩ sẽ dễ hiểu nếu bạn nghĩ về nó theo cách này:
Prompt là mệnh lệnh. Ngữ cảnh chính là công ty.
Nếu bạn yêu cầu một nhân viên tài năng "tạo tài liệu này," nhưng các quy tắc nội bộ, thông tin khách hàng, tài liệu quá khứ, công cụ có sẵn, tiêu chuẩn chất lượng và thẩm quyền phê duyệt lại lộn xộn, họ sẽ không thể làm tốt công việc.
AI cũng vậy.
Ngay cả khi bạn liên tục trau chuốt prompt, nếu ngữ cảnh xung quanh mâu thuẫn, lỗi thời, phình to và bị ô nhiễm bởi thông tin không liên quan, hiệu suất sẽ không được cải thiện.
Quan Niệm Sai Lầm Rằng "Càng Nhiều Thông Tin Càng Thông Minh"
Nếu cửa sổ ngữ cảnh (context window) trở thành 1 triệu token, bạn có thể đưa vào rất nhiều thông tin.
Do đó, nhiều người nghĩ:
"Nếu nó vừa, tôi nên nhồi nhét mọi thứ vào."
Tuy nhiên, cửa sổ ngữ cảnh không phải là một nhà kho.
Nó là bộ nhớ làm việc và tài nguyên chú ý của AI.
Anthropic cũng giải thích rằng hiệu suất không tự động tăng lên khi khối lượng ngữ cảnh tăng lên; thay vào đó, "sự mục nát ngữ cảnh" (context rot) có thể xảy ra, nơi độ chính xác và hiệu suất thu hồi (recall) giảm khi lượng thông tin tăng lên. Đối với các tác nhân chạy trong thời gian dài, cần sử dụng tính năng nén (compaction), các ghi chú có cấu trúc và đa tác nhân để ngăn chặn sự ô nhiễm ngữ cảnh.
Ví dụ, giả sử lệnh sau được viết trong CLAUDE.md:
Không viết comment trong code.
Trong một Skill khác, nó nói:
Luôn thêm comment chi tiết cho các xử lý phức tạp.
Hơn nữa, người dùng yêu cầu:
Vui lòng bao gồm nhiều comment cho người mới bắt đầu.
Claude không chỉ phải viết code. Nó phải xem xét mức độ ưu tiên của ba lệnh này, phạm vi áp dụng của chúng, ý định hiện tại của người dùng và các quy ước của codebase.
Một mô hình mới có thể sẽ đưa ra phán đoán hợp lý vào cuối cùng. Tuy nhiên, nó sẽ tiêu tốn một phần sức mạnh suy luận đáng lẽ được dùng cho việc thiết kế code vào việc "kiểm soát giao thông giữa các lệnh."
Đây là vấn đề của thiết kế ngữ cảnh cũ.
Sự ma sát giữa các thông tin khiến AI yếu hơn so với chính lượng thông tin đó.
Tôi gọi đây là Nợ Ngữ Cảnh (Context Debt).
Cũng giống như nợ kỹ thuật (technical debt) tích tụ trong code, nợ tích tụ trong prompt, CLAUDE.md, Skills và Memory.
Các quy tắc được thêm vào để ngăn chặn thất bại trong quá khứ vẫn tồn tại mãi mãi.
Các hướng dẫn trở nên không cần thiết khi mô hình được cải thiện không bị xóa.
Những người khác nhau thêm các lệnh tương tự bằng các cách diễn đạt khác nhau.
Các API cũ, cấu hình cũ và quy trình làm việc cũ vẫn còn.
Kết quả là, mặc dù AI đã trở thành mô hình mới nhất, nhưng chỉ có ngữ cảnh xung quanh vẫn phình to như trước đây.
Hiệu suất mô hình càng cao, các bánh xe tập luyện cũ càng trở thành chướng ngại vật.
Tại Sao 80% Quy Tắc Có Thể Bị Xóa Trong Claude 5?
Sự thay đổi lớn trong thế hệ Claude 5 không chỉ là lượng kiến thức.
Khả năng diễn giải các tình huống mơ hồ, tiếp tục công việc dài hạn, tích hợp ý định người dùng với môi trường xung quanh, quản lý các tác nhân phụ và xác minh công việc của chính nó đã được cải thiện.
Anthropic giải thích rằng đối với Claude Fable 5, tính tự chủ dài hạn, tỷ lệ chính xác ngay lần đầu cho các vấn đề phức tạp, phán đoán hành động tiếp theo trong các tình huống mơ hồ, đánh giá code và ủy quyền cho các tác nhân phụ đã được cải thiện kể từ Claude Opus 4.8. Hơn nữa, vì hiệu suất làm theo hướng dẫn (instruction-following) đã tăng lên, việc kiểm soát hành vi bằng các chính sách ngắn trở nên dễ dàng hơn mà không cần phải liệt kê từng hành động riêng lẻ.
Các mô hình trước đây cần các lan can chi tiết để tránh những thất bại tồi tệ nhất.
"Đừng viết comment."
"Đừng tự ý tạo tài liệu."
"Đừng refactor không cần thiết."
"Đừng thêm các tính năng mà người dùng không yêu cầu."
"Luôn tuân theo thứ tự này."
"Khi sử dụng công cụ này, hãy gọi nó chính xác như ví dụ này."
Vào thời điểm đó, những quy tắc này có giá trị thực tế.
Tuy nhiên, các mô hình mới có thể phán đoán chính xác hơn trước về việc liệu "comment có cần thiết trong tình huống này" hay "refactoring có nên được bao gồm trong thay đổi này" hay không, dựa trên code xung quanh, ý định người dùng và bản chất của dự án.
Vì vậy, Anthropic đã xóa các lệnh cấm chi tiết và thay thế chúng bằng các chính sách cấp cao hơn.
Ví dụ, thay vì viết nhiều dòng quy tắc về comment, giờ đây họ thay đổi cách suy nghĩ thành:
Viết theo cùng một cách với code xung quanh. Khớp khối lượng comment, cách đặt tên và thành ngữ với code hiện có.
Đây không phải là loại bỏ các quy tắc.
Đó là đưa ra các tiêu chí phán đoán và để mô hình tự đưa ra phán đoán.
Quy Tắc Mới 1
Từ "Đưa Ra Quy Tắc Cho Claude" Đến "Đưa Ra Tiêu Chí Phán Đoán Cho Claude"
Trong kỹ thuật ngữ cảnh cũ, việc chỉ định chi tiết các hành động của AI được coi là đức hạnh.
Trong kỹ thuật ngữ cảnh mới, bạn giảm các quy tắc đầy ngoại lệ và chỉ ra hướng phán đoán.
Các ví dụ tồi bao gồm:
- Luôn giữ tên biến ngắn
- Không viết comment
- Giữ hàm dưới 30 dòng
- Không tạo tệp mới
- Không thêm thư viện bên ngoài
- Cấm refactoring
- Luôn viết định nghĩa kiểu trong types.ts
Một số điều này có thể đúng, và một số có thể sai tùy thuộc vào trường hợp.
Để tuân theo quy tắc "hàm dưới 30 dòng," một sự tách biệt khó đọc hơn có thể xảy ra.
Để tránh tạo tệp mới, các tệp hiện có có thể trở nên phình to.
Để tránh thêm thư viện, các triển khai tùy chỉnh không hoàn chỉnh có thể ra đời.
Một cách viết tốt hơn như sau:
Khớp cấu trúc, cách đặt tên, mật độ comment và mức độ trừu tượng của code hiện có. Giữ phạm vi thay đổi ở mức tối thiểu cần thiết để đạt được yêu cầu. Chỉ giới thiệu các phụ thuộc hoặc trừu tượng mới nếu chúng rõ ràng làm cho việc triển khai đơn giản hơn so với hiện tại.
Ở đây, có các nguyên tắc phán đoán chung cho mọi tình huống.
Điều một mô hình mới cần không phải là được dạy câu trả lời đúng từng cái một. Đó là được cho biết nên coi trạng thái nào là tốt, nên ưu tiên điều gì và nên chọn loại đánh đổi nào.
Tuy nhiên, có một điều cần cẩn thận ở đây.
"Để nó phán đoán" không có nghĩa là "bạn không cần chỉ định gì cả."
Các ranh giới rõ ràng là cần thiết cho các hành động có tính không thể đảo ngược hoặc tác động cao, chẳng hạn như xóa, gửi, xuất bản, thanh toán, triển khai và sử dụng thông tin cá nhân.
Những gì nên để cho phán đoán là các lĩnh vực phụ thuộc nhiều vào ngữ cảnh và có thể đảo ngược, chẳng hạn như phương pháp triển khai, phương pháp diễn đạt, phương pháp nghiên cứu và cấu trúc code.
Ngược lại, bảo mật, luật pháp, thông tin bí mật, tiền bạc, xuất bản ra bên ngoài và các hoạt động phá hủy nên tiếp tục được kiểm soát rõ ràng.
Tóm lại, nguyên tắc mới là thế này:
Để việc thực thi có thể đảo ngược cho phán đoán, và đặt ranh giới cho việc thực thi không thể đảo ngược.
Quy Tắc Mới 2
Từ "Đưa Ra Hàng Loạt Ví Dụ" Đến "Thiết Kế Giao Diện Tốt"
Trong các tác nhân AI trước đây, việc hiển thị nhiều ví dụ về các lệnh gọi công cụ (tool calls) rất hiệu quả để khiến AI sử dụng công cụ một cách chính xác.
Tuy nhiên, các ví dụ có tác dụng phụ.
Trong khi Claude học cách sử dụng chúng từ các ví dụ, nó cũng bị kéo về phạm vi tìm kiếm được hiển thị bởi các ví dụ đó.
Ngay cả khi một sự kết hợp, thứ tự hoặc tham số khác phù hợp hơn, việc chọn một phương pháp tương tự như các ví dụ trong quá khứ trở nên dễ dàng hơn.
Đó là lúc thiết kế giao diện công cụ trở nên quan trọng.
Ví dụ, giả sử một công cụ Todo có các trạng thái sau:
pending
in_progress
completed
Hơn nữa, nếu nó được định nghĩa rằng "chỉ một mục có thể ở trạng thái in_progress tại một thời điểm," Claude có thể hiểu các chuyển đổi trạng thái của công cụ mà không cần được cung cấp các ví dụ sử dụng dài dòng.
Các công cụ tốt có các thuộc tính sau:
- Vai trò rõ ràng từ tên công cụ.
- Phạm vi được bao phủ bởi một công cụ là rõ ràng.
- Tên tham số không mơ hồ.
- Các lựa chọn được định nghĩa dưới dạng enum.
- Giá trị trả về cho thành công và thất bại đã được biết.
- Các giá trị mặc định an toàn được đặt.
- Giá trị trả về chứa thông tin cần thiết cho phán đoán tiếp theo.
Anthropic cũng giải thích rằng các công cụ dành cho tác nhân không nên chỉ bao bọc các API của con người như cũ. Việc tăng số lượng công cụ không phải lúc nào cũng tốt hơn; không gian tên (namespace), ngữ cảnh được trả về, hiệu quả token, mô tả và thiết kế đánh giá là quan trọng. Vì các công cụ nổi bật trong ngữ cảnh, chúng phải được thiết kế xoay quanh các hành động chính mà mô hình thực sự nên thực hiện.
Tuy nhiên, cũng là một sai lầm khi hiểu rằng "không cần ví dụ nữa."
Trong hướng dẫn prompt chính thức của Claude, một số lượng nhỏ các ví dụ chất lượng cao vẫn được coi là hiệu quả như một phương tiện để ổn định định dạng đầu ra, phong cách và cấu trúc. Trong hướng dẫn Skills chính thức, nó được giải thích rằng các ví dụ đầu vào/đầu ra có hiệu quả trong các lĩnh vực mà chất lượng phụ thuộc vào các ví dụ cụ thể, chẳng hạn như commit message.
Tóm lại:
Đừng lạm dụng các ví dụ để dạy cách sử dụng công cụ. Hãy làm cho giao diện công cụ trở nên dễ hiểu.
Mặt khác, các ví dụ đáng để sử dụng trong các lĩnh vực khó giải thích "câu trả lời đúng" chỉ bằng lời nói, chẳng hạn như giọng điệu, sở thích thiết kế và các định dạng đầu ra đặc biệt.
Nói cách khác, bạn không xóa các ví dụ. Bạn giới hạn công việc của các ví dụ.
Quy Tắc Mới 3
Từ "Bắt Nó Đọc Mọi Thứ Trước" Đến "Chỉ Tiết Lộ Khi Cần Thiết"
Trước đây, thiết kế phổ biến là viết mọi thứ vào CLAUDE.md vì sợ rằng Claude sẽ không tìm thấy thông tin cần thiết.
- Phương pháp đánh giá code.
- Phương pháp kiểm thử.
- Phương pháp triển khai.
- Quy tắc viết.
- Quy tắc thiết kế.
- Thông số kỹ thuật API.
- Cấu trúc thư mục.
- Danh sách thư viện.
- Các lỗi đã biết.
Điều này là bởi vì mọi người nghĩ rằng nếu họ đặt mọi thứ ở đầu, Claude sẽ không bỏ lỡ nó.
Tuy nhiên, điều này giống như bắt mọi nhân viên trong một công ty đọc tất cả các sổ tay nội bộ mỗi sáng trước khi bắt đầu làm việc.
Ngay cả khi công việc hôm nay là kế toán, bạn bắt họ đọc sổ tay bán hàng, sổ tay tuyển dụng, sổ tay chỉnh sửa video và sổ tay khắc phục sự cố.
Thông tin có tồn tại, nhưng tỷ lệ thông tin cần thiết cho công việc hiện tại giảm xuống.
Khái niệm cốt lõi của kỷ nguyên Claude 5 là Tiết Lộ Dần Dần (Progressive Disclosure).
Lúc đầu, bạn chỉ hiển thị sự tồn tại và lối vào của thông tin.
Nếu nó trở nên cần thiết, hãy đọc nội dung Skill.
Nếu cần thêm chi tiết, hãy đọc các tệp tham chiếu trong Skill.
Nếu cần tính toán hoặc xác minh, hãy chạy một script.
Trong Claude Skills, những gì được tải khi khởi động về cơ bản là siêu dữ liệu như tên và mô tả của Skill. Nội dung Skill được tải khi Skill đó trở nên cần thiết. Hơn nữa, các tệp phụ trợ được tham chiếu từ nội dung cũng có thể được tải thêm khi cần. Các tập lệnh có thể được thực thi mà không cần đưa code vào ngữ cảnh, chỉ nhận kết quả.
Ví dụ, một Skill xử lý PDF sẽ được chia như sau:
pdf-processing/
├── SKILL.md
├── extraction.md
├── forms.md
├── ocr.md
├── validation.md
└── scripts/
├── inspect_pdf.py
└── validate_output.py
Trong SKILL.md, bạn không viết tất cả các quy trình.
Bạn chỉ viết tệp nào cần đọc trong tình huống nào.
Xử lý PDF
Đối với trích xuất văn bản thông thường, hãy tham khảo extraction.md.
Chỉ tham khảo forms.md nếu bạn cần điền vào biểu mẫu đầu vào.
Chỉ tham khảo ocr.md nếu trích xuất văn bản thất bại do nội dung tập trung vào hình ảnh.
Xác minh theo các tiêu chí trong validation.md trước khi tạo ra đầu ra cuối cùng.
Nếu Claude chỉ đang thực hiện trích xuất PDF thông thường, nó không cần đọc các mô tả cho OCR hoặc xử lý biểu mẫu.
Điều này cho phép bạn làm nhẹ ngữ cảnh hiện tại mà không cắt giảm lượng thông tin.
Điều quan trọng không phải là "giảm kiến thức."
Đó là ngăn chặn sự cư trú vĩnh viễn của kiến thức.
Quy Tắc Mới 4
Từ "Viết Những Điều Quan Trọng Nhiều Lần" Đến "Viết Một Lần Ở Một Nơi"
Các mô hình trước đây đôi khi tiếp nhận các hướng dẫn ở cuối ngữ cảnh mạnh mẽ hơn so với ở đầu.
Do đó, một thiết kế đã được sử dụng, nơi cùng một lệnh được viết lặp đi lặp lại trong system prompt, CLAUDE.md, Skill và mô tả công cụ.
Tuy nhiên, sự trùng lặp các lệnh có vấn đề.
Đầu tiên, nó tiêu tốn token.
Tiếp theo, sự khác biệt được sinh ra giữa các lệnh khi cách diễn đạt thay đổi một chút.
Hơn nữa, chỉ một nơi được cập nhật, và những nơi khác vẫn cũ.
Ví dụ, system prompt nói "Luôn chạy kiểm thử," Skill nói "Chỉ chạy kiểm thử nếu có thời gian," và CLAUDE.md nói "Kiểm thử đơn vị là đủ."
Khi điều này xảy ra, thông tin được tăng lên để nhấn mạnh làm cho phán đoán trở nên mơ hồ.
Trong thiết kế mới, một "bản chính" (master copy) được quyết định cho mỗi lệnh.
- Thẩm quyền và vai trò trên toàn sản phẩm: System prompt.
- Các ngoại lệ cụ thể của kho lưu trữ: CLAUDE.md.
- Quy trình cho các tác vụ cụ thể: Skill.
- Cách sử dụng công cụ: Mô tả công cụ.
- Thông số kỹ thuật cho các sản phẩm bàn giao hiện tại: Tệp tham chiếu.
- Kiến thức được khám phá trong quá khứ: Memory.
Đừng sao chép cùng một thông tin qua nhiều lớp.
Điều này giống như Nguyên tắc Một Nguồn Sự Thật (Single Source of Truth) trong thiết kế phần mềm.
Kỹ thuật ngữ cảnh đang trở thành một vấn đề về kiến trúc thông tin hơn là một kỹ thuật viết lách.
Quy Tắc Mới 5
Từ "Tích Lũy Ký Ức Trong CLAUDE.md" Đến "Phân Chia Công Việc Giữa CLAUDE.md và Auto-memory"
Trước đây, khi có điều gì đó bạn muốn Claude nhớ, phương pháp thêm nó vào CLAUDE.md đã được sử dụng.
Tuy nhiên, CLAUDE.md được tải mỗi lần.
Nếu bạn tiếp tục thêm thông tin gỡ lỗi chỉ hữu ích một lần, thói quen làm việc cá nhân, các bản sửa lỗi trong quá khứ và các giải pháp tạm thời, nó sẽ nhanh chóng trở nên phình to.
Claude Code hiện có Auto-memory.
Đó là sự phân chia công việc: CLAUDE.md dành cho các hướng dẫn vĩnh viễn do con người viết, và Auto-memory dành cho những kiến thức mà chính Claude khám phá ra trong quá trình làm việc.
Auto-memory lưu trữ các lệnh xây dựng (build commands), những điều được khám phá trong quá trình gỡ lỗi, thông tin chi tiết về kiến trúc, sở thích lập trình, thói quen làm việc, v.v. Claude không lưu mọi thứ; nó chọn thông tin mà nó đánh giá là sẽ hữu ích trong các cuộc trò chuyện trong tương lai. Auto-memory được bật theo mặc định và được quản lý theo từng dự án.
Đừng nhầm lẫn vai trò của chúng.
Trong CLAUDE.md, hãy viết những điều bạn chắc chắn muốn Claude tuân theo.
Trong Auto-memory, hãy đặt những điều Claude đã học được từ kinh nghiệm.
Ví dụ, nội dung sau đây phù hợp với CLAUDE.md:
Không lưu trữ số tiền dưới dạng số dấu phẩy động; luôn xử lý chúng dưới dạng số nguyên trong đơn vị tiền tệ nhỏ nhất.
Đây là một quy tắc thiết kế dự án.
Mặt khác, nội dung sau đây phù hợp với Memory:
Nếu kiểm thử thanh toán thất bại trong môi trường cục bộ, rất có thể là do một tiến trình Webhook cũ đang chiếm cổng (port).
Đây là kiến thức được khám phá trong quá trình làm việc.
Tuy nhiên, bạn cũng không nên tin tưởng Auto-memory một cách vô điều kiện.
Claude có thể ghi lại một sự trùng hợp ngẫu nhiên như một quy tắc chung.
Các giải pháp tạm thời cũ có thể vẫn còn sau khi cập nhật.
Thông tin không chính xác có thể được lưu lại.
Do đó, Memory cần được quản lý vệ sinh.
Trong hướng dẫn chính thức của Claude Fable 5, một thiết kế được khuyến nghị, nơi một kiến thức được lưu trong một tệp, một bản tóm tắt được đặt ở đầu, nó không trùng lặp với thông tin hiện có và các ký ức được phát hiện là sai lầm sẽ bị xóa.
Memory không phải là một nghĩa địa.
Đó là một nơi để lưu trữ các giả thuyết, kiến thức và lịch sử sửa chữa ở dạng có thể cập nhật được.
Quy Tắc Mới 6
Từ "Thông Số Kỹ Thuật Văn Bản Đơn Giản" Đến "Tài Liệu Tham Khảo Mật Độ Cao"
Trong AI trước đây, việc tóm tắt thông số kỹ thuật bằng Markdown ngắn gọn được khuyến khích.
Tất nhiên, Markdown vẫn hữu ích.
Tuy nhiên, thế hệ Claude 5 có thể xử lý các tài liệu tham khảo phức tạp và mật độ cao hơn.
Ví dụ, hãy xem xét trường hợp tạo một thiết kế web.
Thay vì nói với nó bằng văn bản:
Làm cho nó có nền trắng, cao cấp, với lề rộng và tiêu đề lớn.
Việc chuyển một bản mockup HTML gần giống với thực tế có thể truyền đạt cấu trúc, lề, kích thước phông chữ, hệ thống phân cấp và mối quan hệ giữa các thành phần với độ chính xác cao hơn.
Ảnh chụp màn hình chỉ hiển thị hình thức bên ngoài.
Với HTML, nó có thể đọc cấu trúc, kiểu dáng, giá trị, thiết kế đáp ứng và ý nghĩa của các thành phần.
Code là một ngôn ngữ hướng dẫn mật độ rất cao cho AI.
Điều tương tự cũng có thể nói về kiểm thử.
Thay vì chỉ viết trong thông số kỹ thuật:
Từ chối các địa chỉ email không hợp lệ.
Hãy đặt một bài kiểm thử như sau:
1it("từ chối một địa chỉ không có tên miền", async () => {2 const result = await registerUser({3 email: "user@",4 password: "valid-password"5 });67 expect(result.error.code).toBe("INVALID_EMAIL");8});
Bài kiểm thử này bao gồm định dạng đầu vào, tên hàm, giá trị trả về, cấu trúc lỗi và hành vi mong đợi.
Kiểm thử không chỉ là một phương tiện xác minh.
Chúng là các thông số kỹ thuật có thể thực thi được mà Claude có thể đọc trực tiếp.
- Đối với thiết kế: Các bản mockup HTML.
- Đối với viết lách: Các bài viết đã được phê duyệt và tiêu chí chất lượng (rubrics).
- Đối với API: Thông số kỹ thuật OpenAPI và kiểm thử.
- Đối với video: Code và timeline bố cục thực tế.
- Đối với bảng tính: Các mẫu hoàn chỉnh và công thức.
Trong kỹ thuật ngữ cảnh, điều quan trọng không chỉ là "viết mô tả," mà là chuyển đổi chính câu trả lời đúng thành một dạng có thể tham chiếu được.
Quy Tắc Mới 7
Từ "Bắt Claude Tự Suy Ngẫm" Đến "Để Một Người Xác Minh Khác Phán Xét"
Từ đây trở đi, đây là kết luận quan trọng của riêng tôi dựa trên thông báo này và hướng dẫn chính thức của Claude 5.
Sau khi để Claude làm một công việc, chỉ cần hỏi chính Claude đó rằng:
Hãy suy nghĩ xem bạn có mắc lỗi gì không.
...là không đủ.
Claude đã làm công việc đó bị kéo về phía các tiền đề mà nó đã áp dụng, thông tin nó đã tải lên và cách suy nghĩ của nó.
Thật khó để tìm ra những gì bạn đã bỏ lỡ khi vẫn ở trong cùng một ngữ cảnh.
Vì vậy, trong kỷ nguyên Claude 5, bạn độc lập hóa việc xác minh.
Hãy để người thực hiện chỉ làm phần thực hiện.
Chuyển các thông số kỹ thuật, sản phẩm bàn giao và tiêu chí đánh giá cho một tác nhân phụ với một ngữ cảnh mới, độc lập.
Cho tác nhân phụ đó thấy code thực tế, kết quả kiểm thử, màn hình và các bản diff (khác biệt), thay vì lời giải thích của người làm việc.
Anthropic cũng tuyên bố rằng đối với các tác vụ dài hạn, việc chỉ định các phương pháp tự xác minh và sử dụng một tác nhân phụ xác minh độc lập với một ngữ cảnh mới có xu hướng hiệu quả hơn so với việc tự phê bình đơn giản. Ngoài ra, trong các phương pháp hay nhất của Claude Code, nó được giải thích rằng điều quan trọng là chuẩn bị các phán đoán đạt/không đạt mà chính Claude có thể thực thi, chẳng hạn như kiểm thử, xây dựng (build) và ảnh chụp màn hình so sánh.
Đây là cốt lõi của kỹ thuật vòng lặp (loop engineering).
- Tạo ra.
- Quan sát.
- So sánh với tiêu chí.
- Sửa chữa.
- Xác minh lại.
Ngữ cảnh mạnh nhất để cải thiện chất lượng AI không phải là một câu lệnh dài.
Đó là một cơ chế có thể quan sát thất bại.
Hãy Nghĩ Về Thiết Kế Ngữ Cảnh Kỷ Nguyên Claude 5 Trong 6 Lớp
Tôi sẽ chia ngữ cảnh của Claude Code hoặc một tác nhân AI tùy chỉnh thành 6 lớp sau:
Lớp 1: System Prompt
Ở đây, hãy viết vai trò như một sản phẩm, thẩm quyền, mối quan hệ với người dùng và các ranh giới không bao giờ được vượt qua.
Nếu bạn đang tạo một tác nhân tùy chỉnh, nó sẽ giống như thế này:
Bạn là một tác nhân kiểu thực thi hỗ trợ phát triển phần mềm cho người dùng. Nếu người dùng yêu cầu một thay đổi, hãy thực hiện nghiên cứu, triển khai và xác minh cần thiết. Nếu đó chỉ là một câu hỏi hoặc tư vấn, hãy trả về một đánh giá và không tự ý thực hiện thay đổi. Tiến hành tự động với các thao tác cục bộ có thể đảo ngược. Xin xác nhận cho các thao tác có tác động đến môi trường dùng chung, chẳng hạn như xuất bản ra bên ngoài, gửi, thanh toán, xóa và triển khai. Khi báo cáo tiến độ, chỉ nêu các sự kiện có thể được xác nhận bằng kết quả công cụ thực tế.
Đừng viết cách viết React hoặc định dạng commit message ở đây.
System prompt là hiến pháp của sản phẩm.
Nó không phải là sổ tay công việc.
Lớp 2: CLAUDE.md
Ở đây, hãy viết thông tin cụ thể cho kho lưu trữ và nguy hiểm nếu không biết mỗi lần.
Ví dụ:
Dự án
Dịch vụ quản lý thanh toán B2B.
Các ràng buộc không rõ ràng
- Lưu trữ số tiền dưới dạng số nguyên trong đơn vị tiền tệ nhỏ nhất.
- Không truy xuất dữ liệu khách hàng nếu không có tenant_id.
- Định nghĩa kiểu được tập hợp trong packages/contracts.
- Nếu bạn thay đổi lược đồ DB, hãy chạy Skill kiểm tra tương thích.
Quy ước cụ thể của dự án
- Ưu tiên các components/ui hiện có cho UI và không tăng các thành phần cơ bản mới.
- Sử dụng thư viện thời gian dùng chung cho xử lý ngày tháng. Không thao tác trực tiếp với Date tiêu chuẩn.
Hướng dẫn theo yêu cầu
- Sử dụng /release-check để xác minh trước khi phát hành.
- Tham khảo Skill payment-safety khi thay đổi xử lý thanh toán.
Điều quan trọng là không viết các giải thích chung về React, danh sách tất cả các thư mục hoặc các phụ thuộc có thể hiểu được bằng cách nhìn vào package.json.
Hướng đến lối viết khiến người đọc cảm thấy "kiến thức của tôi đã được nâng lên" chứ không phải "nó đã được giải thích." Đừng sắp xếp thông tin một cách đồng đều; hãy thêm nhịp điệu theo mức độ quan trọng. Đừng kết thúc chỉ bằng lý thuyết trừu tượng; hãy bao gồm các ví dụ cụ thể để người đọc có thể hình dung ra bối cảnh. Về nhịp điệu của văn bản, hãy tham khảo các mẫu đã được phê duyệt. Sau khi viết, hãy đánh giá bằng voice-rubric.md và kiểm tra sự lặp lại của các kết thúc và cách diễn đạt bằng detect-repetition.py.
Độc giả chính là những người Nhật không phải kỹ sư muốn sử dụng AI tạo sinh cho công việc. Hãy viết chi tiết đến mức có thể thực sự thử được, chứ không chỉ là tóm tắt những điều chung chung. Phân biệt giữa sự thật và suy luận, và xác nhận thông tin gốc đối với những thông tin có tính thời sự. Theo nguyên tắc, không sử dụng bảng; hãy so sánh trong dòng chảy của văn bản.
Hãy kiểm tra thiết kế bối cảnh (context design) của dự án này dành cho thế hệ Claude 5.
Mục tiêu: - CLAUDE.md - CLAUDE.md lồng nhau - .claude/rules - .claude/skills - subagents - hooks - Cài đặt MCP - Auto-memory - Mô tả công cụ
Mục đích: Giảm trùng lặp, mâu thuẫn, ràng buộc quá mức, các bánh xe tập đi cũ và thông tin không cần tải mọi lúc, đồng thời giữ lại khả năng phán đoán của Claude.
Đừng thay đổi tệp ngay lập tức; trước hết hãy báo cáo kết quả kiểm tra.
Phân loại từng mục như sau: 1. Luôn cần thiết ở cấp hệ thống 2. Các cạm bẫy cụ thể của kho lưu trữ cần giữ lại trong CLAUDE.md 3. Quy trình cần chuyển sang Skills 4. Thông tin chi tiết cần chuyển sang tệp tham khảo 5. Xử lý xác định cần chuyển đổi thành script hoặc kiểm thử 6. Kiến thức thu được từ công việc phù hợp với Auto-memory 7. Ứng viên cho việc trùng lặp, mâu thuẫn hoặc xóa bỏ
Đặc biệt kiểm tra: - Có thông tin nào trong CLAUDE.md có thể hiểu được bằng cách đọc codebase không? - Các lệnh giống nhau có được viết ở nhiều nơi không? - Có các lệnh cấm đoán không phải lúc nào cũng đúng không? - Có các đặc tả quy trình quá mức dành cho các mô hình cũ không? - Nội dung Skill có quá dài không? - Hệ thống phân cấp tham khảo có quá sâu không? - Bạn có đang bù đắp cho việc thiếu mô tả công cụ bằng cách thêm các ví dụ sử dụng đồ sộ không? - Bạn có đang quản lý các quy tắc có thể kiểm chứng chỉ bằng văn bản không? - Ranh giới cho bảo mật, tính bảo mật, tiền bạc, xóa bỏ và xuất bản ra bên ngoài có được duy trì không?
Nếu bạn đề xuất xóa hoặc di chuyển, hãy chắc chắn viết lý do và rủi ro.
Cuối cùng, hãy thiết kế 5 tác vụ đánh giá đại diện để so sánh cấu hình hiện tại với cấu hình mới. Chỉ thực hiện các thay đổi sau khi trình bày kết quả kiểm tra.
