4 quy tắc CLAUDE.md của Karpathy giúp giảm lỗi của Claude từ 41% xuống 11%. Sau khi thử nghiệm trên 30 cơ sở mã, tôi đã bổ sung thêm 8 quy tắc nữa

Bản dịch

Cuối tháng 1 năm 2026, Andrej Karpathy đã đăng một bài viết phàn nàn về cách Claude viết code. Ba kiểu lỗi: giả định sai thầm lặng, phức tạp hóa, và gây hại cho code không đáng động tới.

Forrest Chang đã đọc bài viết đó, đóng gói những lời phàn nàn thành 4 quy tắc hành vi trong một file CLAUDE.md duy nhất, và đăng lên GitHub. Nó đạt 5.828 sao trong ngày đầu tiên. 60.000 bookmark trong hai tuần. 120.000 sao tính đến hôm nay. Repo một file phát triển nhanh nhất năm 2026.

Sau đó tôi đã thử nghiệm nó trên 30 codebase trong 6 tuần.

4 quy tắc hoạt động hiệu quả. Những lỗi từng xảy ra ~40% thời gian đã giảm xuống dưới 3% đối với các tác vụ phù hợp với thế mạnh của chúng. Nhưng template được xây dựng để sửa các lỗi viết code từ tháng 1.

Hệ sinh thái Claude Code vào tháng 5 năm 2026 có những vấn đề khác — xung đột agent, cascade hook, xung đột tải skill, quy trình nhiều bước bị gián đoạn giữa các phiên.

Vì vậy tôi đã thêm 8 quy tắc nữa. Dưới đây: toàn bộ 12 quy tắc CLAUDE.md, lý do mỗi quy tắc có mặt ở đây, và 4 nơi mà template Karpathy gốc âm thầm hỏng.

Nếu bạn muốn bỏ qua phần giải thích và chỉ paste, file đầy đủ ở cuối bài.

Tại sao điều này quan trọng

CLAUDE.md của Claude Code là file bị khai thác dưới mức tiềm năng nhất trong toàn bộ stack coding AI. Hầu hết các developer hoặc:

• Coi nó như bãi rác cho mọi sở thích từng có, phình to lên 4.000+ token, tỷ lệ tuân thủ giảm xuống 30%
• Bỏ qua hoàn toàn và prompt mỗi lần — lãng phí token gấp 5 lần, không có tính nhất quán giữa các phiên
• Copy một template một lần và quên mất. Hoạt động tốt trong hai tuần, sau đó âm thầm hỏng khi codebase của họ thay đổi

Tài liệu chính thức của Anthropic nói rõ: CLAUDE.md chỉ mang tính tư vấn. Claude tuân theo nó khoảng 80% thời gian. Quá 200 dòng, tỷ lệ tuân thủ giảm mạnh vì các quy tắc quan trọng bị chôn vùi trong nhiễu.

Template của Karpathy đã giải quyết vấn đề này trong một file, 65 dòng, 4 quy tắc. Đó là mức sàn.

Trần nhà còn cao hơn. Với thêm 8 quy tắc, những quy tắc tôi sẽ trình bày dưới đây, bạn không chỉ giải quyết các vấn đề viết code tháng 1 năm 2026 mà Karpathy phàn nàn, mà còn giải quyết các vấn đề điều phối agent tháng 5 năm 2026 vốn chưa tồn tại khi template được viết.

4 quy tắc gốc

Nếu bạn chưa đọc repo của Forrest Chang, đây là mức sàn:

Quy tắc 1 — Suy nghĩ trước khi Code.

Không giả định thầm lặng. Nêu rõ những gì bạn đang giả định. Đưa ra các đánh đổi. Hỏi trước khi đoán. Phản biện khi có cách tiếp cận đơn giản hơn.

Quy tắc 2 — Đơn giản là trên hết.

Code tối thiểu giải quyết vấn đề. Không có tính năng suy đoán. Không có abstraction cho code dùng một lần. Nếu một senior engineer cho rằng nó phức tạp quá mức — hãy đơn giản hóa.

Quy tắc 3 — Thay đổi phẫu thuật.

Chỉ chạm vào những gì cần thiết. Đừng "cải thiện" code, comment, hay định dạng xung quanh. Đừng refactor những gì không hỏng. Khớp với style hiện có.

Quy tắc 4 — Thực thi theo mục tiêu.

Xác định tiêu chí thành công. Lặp cho đến khi được xác minh. Đừng bảo Claude làm theo các bước, hãy nói cho nó biết thành công trông như thế nào và để nó tự lặp.

Bốn quy tắc này giải quyết ~40% các kiểu lỗi tôi thấy trong các phiên Claude Code không giám sát. ~60% còn lại nằm trong các khoảng trống dưới đây.

8 quy tắc tôi đã thêm (và lý do)

Mỗi quy tắc này đều đến từ một tình huống thực tế nơi 4 quy tắc của Karpathy là không đủ. Tôi sẽ cho thấy tình huống đó, sau đó là quy tắc.

Quy tắc 5 — Đừng bắt model làm công việc phi ngôn ngữ

Các quy tắc của Karpathy im lặng về điều này. Model tự quyết định những việc lẽ ra phải là code xác định, như có nên thử lại lời gọi API không, cách định tuyến tin nhắn, khi nào cần leo thang. Các quyết định khác nhau mỗi tuần. If-else thất thường với giá $0.003 mỗi token.

1## Quy tắc 5 — Chỉ dùng model cho các quyết định mang tính phán đoán
2Dùng Claude cho: phân loại, soạn thảo, tóm tắt, trích xuất từ văn bản phi cấu trúc.
3KHÔNG dùng Claude cho: định tuyến, thử lại, xử lý mã trạng thái, biến đổi xác định.
4Nếu mã trạng thái đã trả lời câu hỏi, code thuần túy trả lời câu hỏi.

Tình huống: Code gọi Claude để "quyết định có nên thử lại khi gặp 503 không" hoạt động tốt trong hai tuần, sau đó bắt đầu thất thường vì model bắt đầu đọc nội dung request body làm ngữ cảnh cho quyết định. Chính sách thử lại trở nên ngẫu nhiên vì prompt cũng ngẫu nhiên.

Quy tắc 6 — Ngân sách token cứng, không ngoại lệ

CLAUDE.md không có ngân sách giống như một tấm séc trắng. Mọi vòng lặp đều có cơ hội xoáy thành một bãi rác context 50.000 token. Model sẽ không tự dừng lại.

1## Quy tắc 6 — Ngân sách token không phải là tư vấn
2Ngân sách mỗi tác vụ: 4.000 token.
3Ngân sách mỗi phiên: 30.000 token.
4Nếu một tác vụ sắp chạm ngân sách, hãy tóm tắt và bắt đầu mới. Đừng cố gắng vượt qua.
5Việc thông báo vi phạm > việc âm thầm vượt quá.

Tình huống: Một phiên debug kéo dài 90 phút. Model hoàn toàn hài lòng khi lặp đi lặp lại trên cùng một thông báo lỗi 8KB, dần dần mất dấu bản sửa nào nó đã thử. Đến cuối cùng, nó đề xuất các bản sửa mà tôi đã từ chối 40 tin nhắn trước đó. Ngân sách token sẽ chấm dứt nó ở phút thứ 12.

Quy tắc 7 — Đưa xung đột lên bề mặt, đừng làm trung bình chúng

Khi hai phần của codebase bất đồng, Claude cố gắng làm hài lòng cả hai. Kết quả là không mạch lạc.

1## Quy tắc 7 — Đưa xung đột lên bề mặt, đừng làm trung bình chúng
2Nếu hai pattern hiện có trong codebase mâu thuẫn, đừng pha trộn chúng.
3Chọn một (cái mới hơn / được kiểm thử nhiều hơn), giải thích lý do, và đánh dấu cái kia để dọn dẹp.
4Code "trung bình" thỏa mãn cả hai quy tắc là code tệ nhất.

Tình huống: Một codebase có hai pattern xử lý lỗi — một là async/await với try/catch rõ ràng, một là với global error boundary. Claude đã viết code mới làm cả hai. Nhân đôi trình xử lý lỗi. Tôi mất 30 phút để tìm ra tại sao lỗi bị nuốt hai lần.

Quy tắc 8 — Đọc trước khi viết

"Thay đổi phẫu thuật" của Karpathy bảo Claude đừng chạm vào code xung quanh. Nó không bảo Claude hiểu code xung quanh trước. Nếu không có điều này, Claude viết code mới xung đột với code hiện có cách đó 30 dòng.

1## Quy tắc 8 — Đọc trước khi viết
2Trước khi thêm code vào một file, hãy đọc các export của file, caller trực tiếp, và bất kỳ shared utility nào rõ ràng.
3Nếu bạn không hiểu tại sao code hiện có được cấu trúc như vậy, hãy hỏi trước khi thêm vào nó.
4"Có vẻ độc lập với tôi" là cụm từ nguy hiểm nhất trong codebase này.

Tình huống: Claude đã thêm một hàm cạnh một hàm giống hệt hiện có mà nó chưa đọc. Cả hai hàm đều làm cùng một việc. Hàm mới được ưu tiên vì thứ tự import. Hàm cũ đã là nguồn sự thật trong 6 tháng.

Quy tắc 9 — Test không phải là tùy chọn, nhưng không phải là mục tiêu

"Thực thi theo mục tiêu" của Karpathy ngụ ý test là tiêu chí thành công. Trong thực tế, Claude coi "test pass" là mục tiêu duy nhất, và viết code pass các test nông cạn trong khi phá vỡ mọi thứ khác.

1## Quy tắc 9 — Test xác minh ý định, không chỉ hành vi
2Mỗi test phải mã hóa TẠI SAO hành vi đó quan trọng, không chỉ NÓ LÀM GÌ.
3Một test như `expect(getUserName()).toBe('John')` là vô giá trị nếu hàm lấy một ID cứng.
4Nếu bạn không thể viết một test sẽ thất bại khi logic nghiệp vụ thay đổi, thì hàm đó sai.

Tình huống: Claude đã viết 12 test cho một hàm auth. Tất cả đều pass. Auth bị hỏng trên production. Các test đang kiểm tra hàm trả về một thứ gì đó, không phải liệu nó có trả về đúng thứ hay không. Hàm pass vì nó đang trả về một hằng số.

Quy tắc 10 — Các thao tác chạy dài cần điểm kiểm tra

Template của Karpathy giả định các tương tác một lần. Công việc Claude Code thực tế là đa bước — refactor qua 20 file, xây dựng tính năng qua một phiên, debug qua nhiều commit. Không có điểm kiểm tra, một lần rẽ sai sẽ mất tất cả tiến trình.

1## Quy tắc 10 — Điểm kiểm tra sau mỗi bước quan trọng
2Sau khi hoàn thành mỗi bước trong một tác vụ đa bước: tóm tắt những gì đã làm, những gì đã được xác minh, những gì còn lại.
3Đừng tiếp tục từ một trạng thái bạn không thể mô tả lại cho tôi.
4Nếu bạn mất dấu, hãy dừng và phát biểu lại.

Tình huống: Một bản refactor 6 bước đã sai ở bước 4. Khi tôi nhận ra, Claude đã thực hiện cả bước 5 và 6 trên nền trạng thái hỏng. Việc gỡ rối mất nhiều thời gian hơn làm lại toàn bộ. Điểm kiểm tra sẽ phát hiện ra nó ở bước 4.

Quy tắc 11 — Quy ước đánh bại sự mới lạ

Trong một codebase với các pattern đã được thiết lập, Claude thích giới thiệu pattern của riêng nó. Ngay cả khi cách của nó "tốt hơn", việc giới thiệu hai pattern còn tệ hơn bất kỳ pattern nào một mình.

1## Quy tắc 11 — Khớp với quy ước của codebase, ngay cả khi bạn không đồng ý
2Nếu codebase dùng snake_case và bạn thích camelCase: hãy dùng snake_case.
3Nếu codebase dùng class-based components và bạn thích hooks: hãy dùng class-based.
4Bất đồng là một cuộc trò chuyện riêng. Bên trong codebase, sự tuân thủ > sở thích cá nhân.
5Nếu bạn thực sự nghĩ quy ước đó có hại, hãy đưa nó lên bề mặt. Đừng fork nó một cách thầm lặng.

Tình huống: Claude đã giới thiệu React hooks vào một codebase class-component. Chúng hoạt động. Chúng cũng phá vỡ các pattern kiểm thử của codebase, vốn giả định componentDidMount. Mất nửa ngày để loại bỏ và viết lại.

Quy tắc 12 — Thất bại một cách rõ ràng, không thầm lặng

Những thất bại đắt giá nhất của Claude là những thất bại trông giống như thành công. Một hàm "hoạt động" nhưng trả về dữ liệu sai. Một migration "hoàn tất" nhưng bỏ qua 30 bản ghi. Một test "pass" nhưng chỉ vì assertion sai.

1## Quy tắc 12 — Thất bại ồn ào
2Nếu bạn không thể chắc chắn điều gì đó đã hoạt động, hãy nói rõ điều đó.
3"Migration hoàn tất" là sai nếu 30 bản ghi bị bỏ qua thầm lặng.
4"Test pass" là sai nếu bạn bỏ qua bất kỳ test nào.
5"Tính năng hoạt động" là sai nếu bạn không xác minh edge case tôi đã hỏi.
6Mặc định là đưa sự không chắc chắn lên bề mặt, không che giấu nó.

Tình huống: Claude nói một database migration "đã hoàn tất thành công." Nó đã âm thầm bỏ qua 14% bản ghi gặp vi phạm ràng buộc. Việc bỏ qua đã được log nhưng không được đưa lên bề mặt. Phát hiện ra vấn đề 11 ngày sau khi các báo cáo bắt đầu trông sai.

Các con số

Tôi đã theo dõi cùng một bộ 50 tác vụ đại diện trên 30 codebase trong 6 tuần. Ba cấu hình:

Tỷ lệ lỗi = tác vụ yêu cầu sửa chữa hoặc viết lại để khớp với ý định. Các lỗi đếm: giả định sai thầm lặng, kỹ thuật quá mức, thiệt hại độc lập, thất bại thầm lặng, vi phạm quy ước, làm trung bình xung đột, bỏ lỡ điểm kiểm tra.

Tuân thủ = tần suất Claude áp dụng rõ ràng quy tắc liên quan khi nó có thể áp dụng.

Kết quả thú vị không phải là sự giảm mạnh từ 41% xuống 3%. Mà là việc đi từ 4 quy tắc lên 12 hầu như không thêm chi phí tuân thủ (78% -> 76%) nhưng cắt giảm tỷ lệ lỗi thêm 8 điểm. Các quy tắc mới bao phủ các kiểu lỗi mà 4 quy tắc gốc không giải quyết — chúng không cạnh tranh cho cùng một ngân sách chú ý.

Nơi template của Karpathy âm thầm hỏng

Bốn nơi mà template 4 quy tắc gốc là không đủ, ngay cả trước khi thêm các quy tắc mới:

1. Các tác vụ agent chạy dài.

Các quy tắc của Karpathy nhắm vào thời điểm Claude đang viết code. Chúng im lặng về những gì xảy ra khi Claude đang chạy một pipeline đa bước. Không có quy tắc ngân sách. Không có quy tắc điểm kiểm tra. Không có quy tắc "thất bại ồn ào". Các pipeline trôi dạt.

2. Tính nhất quán đa codebase.

"Khớp với style hiện có" giả định một style. Trong một monorepo với 12 dịch vụ, Claude phải chọn style nào. Các quy tắc gốc không nói cho nó biết cách chọn. Nó chọn ngẫu nhiên hoặc làm trung bình.

3. Chất lượng test.

"Thực thi theo mục tiêu" coi "test pass" là thành công. Không nói rằng test phải có ý nghĩa. Kết quả là các test không kiểm tra gì hữu ích nhưng làm Claude tự tin.

4. Production so với prototype.

Cùng 4 quy tắc bảo vệ code production khỏi kỹ thuật quá mức cũng làm chậm các prototype mà một cách chính đáng cần 100 dòng scaffolding suy đoán để tìm ra hướng đi. "Đơn giản là trên hết" của Karpathy bắn quá mức vào code giai đoạn đầu.

8 quy tắc được thêm vào không thay thế 4 quy tắc của Karpathy. Chúng vá các khoảng trống nơi mô hình của ông ấy, tháng 1 năm 2026, coding kiểu autocomplete, không khớp với công việc đa bước, đa codebase, điều khiển bởi agent của tháng 5 năm 2026.

Những gì không hiệu quả

Những thứ tôi đã thử trước khi chốt 12 quy tắc:

• Thêm các quy tắc tôi thấy trên Reddit / X. Hầu hết hoặc là diễn giải lại 4 quy tắc của Karpathy với các từ khác, hoặc các quy tắc theo miền cụ thể ("luôn dùng Tailwind classes") không tổng quát hóa được. Đã cắt chúng.
• Nhiều hơn 12 quy tắc. Tôi đã thử nghiệm lên đến 18. Tuân thủ giảm từ 76% xuống 52% sau 14 quy tắc. Giới hạn 200 dòng là thật. Quá nó, Claude bắt đầu khớp mẫu với "có quy tắc tồn tại" mà không thực sự đọc chúng.
• Các quy tắc phụ thuộc vào công cụ có thể không tồn tại. "Luôn dùng eslint" hỏng khi eslint không được cài đặt. Quy tắc thất bại thầm lặng. Đã thay thế bằng các diễn đạt không phụ thuộc vào khả năng: "khớp với style được thực thi của codebase" thay vì "dùng eslint."
• Ví dụ trong CLAUDE.md thay vì quy tắc. Ví dụ nặng hơn quy tắc. Ba ví dụ tốn nhiều context bằng ~10 quy tắc và Claude over-fit vào chúng. Quy tắc là trừu tượng, ví dụ là cụ thể. Dùng quy tắc.
• "Hãy cẩn thận" / "suy nghĩ kỹ" / "thực sự tập trung." Nhiễu thuần túy. Tuân thủ với những điều này giảm xuống ~30% vì chúng không thể kiểm tra được. Đã thay thế bằng các mệnh lệnh cụ thể ("nêu rõ các giả định một cách rõ ràng").
• Bảo Claude trở nên "senior." Không hiệu quả. Claude đã nghĩ nó là senior rồi. Khoảng cách tuân thủ là giữa suy nghĩ và hành động. Các quy tắc mệnh lệnh thu hẹp khoảng cách; các prompt về danh tính thì không.

CLAUDE.md đầy đủ 12 quy tắc (sẵn sàng copy-paste)

1# CLAUDE.md — Template 12 quy tắc
2
3Các quy tắc này áp dụng cho mọi tác vụ trong dự án này trừ khi được ghi đè rõ ràng.
4Xu hướng: thận trọng hơn tốc độ đối với công việc không tầm thường. Dùng phán đoán cho các tác vụ tầm thường.
5
6## Quy tắc 1 — Suy nghĩ trước khi Code
7Nêu rõ các giả định một cách rõ ràng. Nếu không chắc chắn, hãy hỏi thay vì đoán.
8Đưa ra nhiều cách diễn giải khi có sự mơ hồ.
9Phản biện khi có cách tiếp cận đơn giản hơn.
10Dừng lại khi bối rối. Nêu tên điều không rõ ràng.
11
12## Quy tắc 2 — Đơn giản là trên hết
13Code tối thiểu giải quyết vấn đề. Không có gì suy đoán.
14Không có tính năng ngoài những gì được yêu cầu. Không có abstraction cho code dùng một lần.
15Kiểm tra: một senior engineer có nói điều này phức tạp quá mức không? Nếu có, hãy đơn giản hóa.
16
17## Quy tắc 3 — Thay đổi phẫu thuật
18Chỉ chạm vào những gì cần thiết. Chỉ dọn dẹp mớ hỗn độn của chính bạn.
19Đừng "cải thiện" code, comment, hay định dạng xung quanh.
20Đừng refactor những gì không hỏng. Khớp với style hiện có.
21
22## Quy tắc 4 — Thực thi theo mục tiêu
23Xác định tiêu chí thành công. Lặp cho đến khi được xác minh.
24Đừng làm theo các bước. Xác định thành công và lặp.
25Tiêu chí thành công mạnh mẽ cho phép bạn lặp độc lập.
26
27## Quy tắc 5 — Chỉ dùng model cho các quyết định mang tính phán đoán
28Dùng tôi cho: phân loại, soạn thảo, tóm tắt, trích xuất.
29KHÔNG dùng tôi cho: định tuyến, thử lại, biến đổi xác định.
30Nếu code có thể trả lời, code trả lời.
31
32## Quy tắc 6 — Ngân sách token không phải là tư vấn
33Mỗi tác vụ: 4.000 token. Mỗi phiên: 30.000 token.
34Nếu sắp chạm ngân sách, hãy tóm tắt và bắt đầu mới.
35Đưa vi phạm lên bề mặt. Đừng âm thầm vượt quá.
36
37## Quy tắc 7 — Đưa xung đột lên bề mặt, đừng làm trung bình chúng
38Nếu hai pattern mâu thuẫn, chọn một (mới hơn / được kiểm thử nhiều hơn).
39Giải thích lý do. Đánh dấu cái kia để dọn dẹp.
40Đừng pha trộn các pattern mâu thuẫn.
41
42## Quy tắc 8 — Đọc trước khi viết
43Trước khi thêm code, hãy đọc exports, caller trực tiếp, shared utility.
44"Có vẻ độc lập" là nguy hiểm. Nếu không chắc tại sao code được cấu trúc như vậy, hãy hỏi.
45
46## Quy tắc 9 — Test xác minh ý định, không chỉ hành vi
47Test phải mã hóa TẠI SAO hành vi quan trọng, không chỉ NÓ LÀM GÌ.
48Một test không thể thất bại khi logic nghiệp vụ thay đổi là sai.
49
50## Quy tắc 10 — Điểm kiểm tra sau mỗi bước quan trọng
51Tóm tắt những gì đã làm, những gì đã được xác minh, những gì còn lại.
52Đừng tiếp tục từ một trạng thái bạn không thể mô tả lại.
53Nếu bạn mất dấu, hãy dừng và phát biểu lại.
54
55## Quy tắc 11 — Khớp với quy ước của codebase, ngay cả khi bạn không đồng ý
56Tuân thủ > sở thích cá nhân bên trong codebase.
57Nếu bạn thực sự nghĩ một quy ước có hại, hãy đưa nó lên bề mặt. Đừng fork một cách thầm lặng.
58
59## Quy tắc 12 — Thất bại ồn ào
60"Hoàn tất" là sai nếu bất cứ điều gì bị bỏ qua thầm lặng.
61"Test pass" là sai nếu bất kỳ test nào bị bỏ qua.
62Mặc định là đưa sự không chắc chắn lên bề mặt, không che giấu nó.

Lưu dưới dạng CLAUDE.md tại thư mục gốc repo của bạn. Thêm các quy tắc dành riêng cho dự án bên dưới 12 quy tắc (stack, lệnh test, pattern lỗi). Đừng vượt quá 200 dòng tổng cộng, quá nó, tuân thủ giảm mạnh.

Cách cài đặt

Hai bước:

1# 1. Thêm baseline 4 quy tắc của Karpathy vào CLAUDE.md của bạn
2curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md
3
4# 2. Dán các quy tắc 5-12 từ bài viết này bên dưới

Lưu tại thư mục gốc repo của bạn. >> rất quan trọng, nó thêm vào CLAUDE.md hiện có của bạn thay vì ghi đè bất kỳ quy tắc dành riêng cho dự án nào bạn đã có.

Mô hình tư duy

CLAUDE.md không phải là một danh sách mong muốn. Nó là một hợp đồng hành vi đóng các kiểu lỗi cụ thể mà bạn đã quan sát được.

Mỗi quy tắc nên trả lời: lỗi này ngăn chặn điều gì?

4 quy tắc của Karpathy ngăn chặn các kiểu lỗi ông ấy thấy vào tháng 1 năm 2026: giả định thầm lặng, kỹ thuật quá mức, thiệt hại độc lập, tiêu chí thành công yếu. Chúng là nền tảng. Đừng bỏ qua chúng.

8 quy tắc tôi thêm vào ngăn chặn các kiểu lỗi xuất hiện vào tháng 5 năm 2026: vòng lặp agent không có ngân sách, tác vụ đa bước không có điểm kiểm tra, test không kiểm tra, thành công thầm lặng che giấu thất bại thầm lặng. Chúng mang tính bổ sung.

Kết quả của bạn có thể khác. Nếu bạn không chạy pipeline đa bước, Quy tắc 10 không quan trọng. Nếu codebase của bạn có một style nhất quán được thực thi bởi linting, Quy tắc 11 là dư thừa. Đọc 12 quy tắc, giữ những quy tắc khớp với các lỗi bạn thực sự đã mắc phải, bỏ phần còn lại.

Một CLAUDE.md 6 quy tắc được điều chỉnh theo các kiểu lỗi thực tế của bạn đánh bại một CLAUDE.md 12 quy tắc với 6 quy tắc bạn sẽ không bao giờ cần.

K Ế T _ T H Ú C

Bài viết tháng 1 năm 2026 của Karpathy là một lời phàn nàn. Forrest Chang đã biến nó thành 4 quy tắc. 120.000 developer đã gắn sao cho kết quả. Hầu hết trong số họ vẫn đang chạy 4 quy tắc cho đến ngày nay.

Model đã được cải thiện. Hệ sinh thái đã thay đổi. Agent đa bước, cascade hook, tải skill, công việc đa codebase — không điều nào tồn tại khi Karpathy viết bài viết của mình. 4 quy tắc không giải quyết chúng. Chúng không sai; chúng không đầy đủ.

Thêm 8 quy tắc. 6 tuần thử nghiệm trên 30 codebase. Tỷ lệ lỗi từ 41% xuống 3%.

Hãy bookmark bài này và dán 12 quy tắc vào CLAUDE.md của bạn tối nay. Repost nếu nó giúp bạn tiết kiệm một tuần rẽ sai của Claude.

Telegram để nhận mẹo tối ưu Claude hàng ngày:

*https://t.me/+_ZWrQN7GuDA3ZDEy*