Tiêu đề gốc: 4 quy tắc CLAUDE.md của Karpathy đã giảm tỷ lệ mắc lỗi của Claude từ 41% xuống 11%. Sau 30 cơ sở mã, tôi đã thêm 8 cơ sở nữa
Tác giả gốc: @Mnilax
Biên soạn bởi: Peggy, BlockBeats

Ghi chú của biên tập viên: Tháng 1 năm 2026, Andrej Karpathy về Claude Những phàn nàn về việc viết mã dẫn đến một tệp có vẻ nhỏ nhưng cực kỳ quan trọng trong quy trình lập trình AI: CLAUDE.md. Forrest Chang sau đó đã sắp xếp những vấn đề này thành 4 quy tắc ứng xử, cố gắng hạn chế những sai lầm phổ biến của Claude trong quá trình mã hóa: giả định thầm lặng, kỹ thuật quá mức, vô tình phá hủy mã không liên quan và thiếu tiêu chí thành công rõ ràng.

Nhưng vài tháng sau, kịch bản sử dụng của Claude Code không còn chỉ là "để mô hình viết một đoạn mã". Khi các tác nhân nhiều bước, kích hoạt chuỗi móc, tải kỹ năng và cộng tác cơ sở nhiều mã trở thành tiêu chuẩn, các chế độ lỗi mới cũng bắt đầu xuất hiện: các mô hình vượt khỏi tầm kiểm soát trong các nhiệm vụ dài, các bài kiểm tra vượt qua mà không xác minh logic thực, quá trình di chuyển đã hoàn thành nhưng các lỗi bị âm thầm bỏ qua và các kiểu mã hóa khác nhau được trộn không chính xác.

Tác giả của bài viết này đã thử nghiệm 30 cơ sở mã trong vòng 6 tuần và thêm 8 quy tắc mới vào 4 quy tắc ban đầu của Karpathy, cố gắng giải quyết các vấn đề mới sau khi lập trình AI chuyển từ hoàn thành một lần sang cộng tác dựa trên tác nhân.

Sau đây là nội dung gốc:

Vào cuối tháng 1 năm 2026, Andrej Karpathy đã gửi một chuỗi tweet phàn nàn về cách viết mã của Claude. Anh ấy xác định ba loại vấn đề điển hình: đưa ra các giả định không chính xác mà không có lời giải thích, phức tạp hóa mọi thứ quá mức và gây ra những thiệt hại không liên quan đến mã mà lẽ ra ngay từ đầu không nên thay đổi.

Forrest Chang nhìn thấy chuỗi tweet này, sắp xếp các khiếu nại thành 4 quy tắc hành vi, viết chúng thành một tệp CLAUDE.md riêng và xuất bản lên GitHub. Dự án này đã nhận được 5.828 sao vào ngày đầu tiên lên mạng và được thu thập 60.000 lần trong vòng hai tuần. Nó hiện có 120.000 sao, khiến nó trở thành kho lưu trữ mã một tệp phát triển nhanh nhất vào năm 2026.

Sau đó, tôi đã thử nghiệm nó với hơn 30 kho lưu trữ 6 tuần.

4 quy tắc này thực sự hiệu quả. Những lỗi từng xảy ra khoảng 40% đã giảm xuống dưới 3% đối với những nhiệm vụ áp dụng những quy tắc này. Nhưng vấn đề là mẫu này ban đầu được tạo ra để sửa lỗi xảy ra khi Claude đang viết mã vào tháng 1.

Đến tháng 5 năm 2026, các vấn đề mà hệ sinh thái Claude Code gặp phải đã khác nhau: xung đột giữa các tác nhân, kích hoạt chuỗi hook, xung đột tải kỹ năng và gián đoạn quy trình làm việc nhiều bước giữa các phiên, v.v.

Vì vậy, tôi đã thêm 8 quy tắc nữa. Dưới đây là phiên bản 12 quy tắc đầy đủ của CLAUDE.md: tại sao mỗi quy tắc lại đáng được thêm vào và 4 vị trí mà mẫu Karpathy ban đầu lặng lẽ bị hỏng.

Nếu muốn bỏ qua phần giải thích thì hãy copy và sử dụng trực tiếp, đồng thời để file đầy đủ ở cuối bài viết.

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

CLAUDE.md của Claude Code là tệp bị đánh giá thấp nhất trong toàn bộ hệ thống công nghệ lập trình AI. Hầu hết các nhà phát triển thường mắc ba loại sai lầm:

Đầu tiên, coi nó như một thùng rác ưa thích, nhét tất cả thói quen của họ vào đó và cuối cùng nó mở rộng lên hơn 4.000 mã thông báo và tỷ lệ tuân thủ quy tắc giảm xuống 30%.

Thứ hai, đừng sử dụng nó nữa và nhắc lại mỗi lần. Điều này dẫn đến lãng phí token gấp 5 lần và thiếu tính nhất quán giữa các phiên.

Thứ ba, sao chép một mẫu và quên nó đi. Nó có thể hoạt động trong hai tuần, nhưng khi cơ sở mã thay đổi, nó sẽ trở nên không hợp lệ trước khi bạn kịp nhận ra.

Tài liệu chính thức của Anthropic nêu rõ: CLAUDE.md mang tính chất tư vấn. Claude theo dõi nó khoảng 80% thời gian. Khi bạn vượt quá 200 dòng, mức độ tuân thủ sẽ giảm đáng kể do các quy tắc quan trọng bị quên lãng.

Mẫu của Karpathy giải quyết vấn đề này: một tệp, 65 dòng, 4 quy tắc. Đây là mức cơ bản tối thiểu.

Nhưng giới hạn trên có thể cao hơn. Sau khi thêm 8 quy tắc sau, nó không chỉ đề cập đến các vấn đề về viết mã mà Karpathy đã phàn nàn vào tháng 1 năm 2026 mà còn cả các vấn đề về điều phối Tác nhân chỉ xuất hiện vào tháng 5 năm 2026 - những vấn đề này không tồn tại khi mẫu ban đầu được viết.

4 quy tắc gốc

Nếu bạn chưa xem kho lưu trữ của Forrest Chang, trước tiên hãy xem phiên bản cơ bản này:

Quy tắc 1: Hãy suy nghĩ trước khi viết mã.

Đừng im lặng giả định. Giải thích các giả định của bạn và phơi bày sự đánh đổi. Đặt câu hỏi trước khi đoán. Khi có giải pháp đơn giản hơn, hãy chủ động đưa ra phản đối.

Quy tắc 2: Đơn giản trước tiên.
Sử dụng mã tối thiểu để giải quyết vấn đề. Đừng thêm các tính năng tưởng tượng. Đừng thiết kế các lớp trừu tượng cho mã dùng một lần. Nếu một kỹ sư cấp cao cho rằng nó quá phức tạp thì nó nên được đơn giản hóa.

Quy tắc 3: Sửa đổi phẫu thuật.
Chỉ thay đổi những gì cần thiết. Không "tối ưu hóa" mã, nhận xét hoặc định dạng liền kề một cách thuận tiện. Đừng cấu trúc lại thứ gì đó không bị hỏng. Luôn nhất quán với phong cách hiện tại của bạn.

Quy tắc 4: Thực hiện có mục tiêu trong đầu.
Trước tiên, hãy xác định tiêu chí thành công, sau đó lặp lại theo vòng lặp cho đến khi quá trình xác minh hoàn tất. Đừng bảo Claude phải làm gì ở mỗi bước mà hãy nói cho anh ấy biết kết quả thành công sẽ như thế nào và để nó tự lặp lại.

4 quy tắc này giải quyết được khoảng 40% các dạng lỗi mà tôi thấy trong các phiên Mã Claude không được giám sát. 60% vấn đề còn lại được ẩn giấu trong những vùng trống bên dưới.

8 cái mới của tôi và tại sao

Mỗi quy tắc đó đều xuất phát từ một khoảnh khắc thực tế: 4 quy tắc ban đầu của Karpathy không còn đủ nữa. Dưới đây trước tiên tôi sẽ nói về kịch bản đó và sau đó đưa ra các quy tắc tương ứng.

Quy tắc 5: Đừng để người mẫu làm những công việc phi ngôn ngữ

Sử dụng Claude để: phân loại, soạn thảo, tóm tắt, trích xuất thông tin từ văn bản phi cấu trúc. Không sử dụng Claude để xử lý: định tuyến, thử lại, xử lý mã trạng thái, chuyển đổi xác định. Nếu mã trạng thái đã trả lời câu hỏi, hãy để mã thông thường trả lời câu hỏi.

Quy tắc của Karpathy không bao gồm điều này. Sau đó, mô hình bắt đầu quyết định các vấn đề cần được xử lý bằng mã xác định: có nên thử lại lệnh gọi API hay không, cách định tuyến thông báo và thời điểm chuyển cấp xử lý. Kết quả là, các đánh giá thay đổi theo từng tuần. Những gì bạn nhận được là một if-else không ổn định được tính phí ở mức 0,003 USD cho mỗi mã thông báo.

Khoảnh khắc đó giống như thế này: có một đoạn mã gọi Claude đến "xác định xem có nên thử lại khi gặp lỗi 503 hay không." Lúc đầu, nó hoạt động tốt trong hai tuần, sau đó đột nhiên trở nên không ổn định do mô hình cũng bắt đầu coi nội dung yêu cầu là bối cảnh. Chính sách thử lại trở nên ngẫu nhiên vì bản thân lời nhắc là ngẫu nhiên.

Quy tắc 6: Đặt ngân sách mã thông báo cứng, không có ngoại lệ

Ngân sách nhiệm vụ cá nhân: 4.000 mã thông báo. Ngân sách một phiên: 30.000 token. Nếu một nhiệm vụ sắp đạt đến giới hạn ngân sách, hãy tóm tắt trạng thái hiện tại và bắt đầu lại. Đừng nhấn vào. Sẽ tốt hơn nếu vạch trần các khoản bội chi ngân sách một cách rõ ràng hơn là âm thầm chi tiêu quá mức.

CLUDE.md không có ràng buộc về ngân sách là một tấm séc trống. Mỗi chu kỳ có khả năng vượt khỏi tầm kiểm soát và biến thành một bãi chứa bối cảnh gồm 50.000 mã thông báo. Mô hình sẽ không tự dừng lại.

Thời điểm đó là: một phiên gỡ lỗi kéo dài 90 phút. Mô hình tiếp tục lặp lại trên cùng một đoạn thông tin lỗi 8KB và dần dần quên đi những bản sửa lỗi mà nó đã thử. Cuối cùng, nó bắt đầu đề xuất các lựa chọn mà tôi đã loại bỏ 40 tin nhắn trước đó. Nếu có ngân sách mã thông báo, quy trình này sẽ kết thúc ở phút thứ 12.

Quy tắc 7: Đưa ra xung đột, không thỏa hiệp

Nếu hai mẫu đã xung đột với nhau trong cơ sở mã của bạn, đừng trộn lẫn chúng. Chọn một trong các mẫu, ưu tiên mẫu mới hơn hoặc được thử nghiệm nhiều hơn, giải thích lý do và gắn cờ cho mẫu còn lại để dọn dẹp tiếp theo. "Mã trung bình" cố gắng đáp ứng hai bộ quy tắc cùng một lúc là loại mã tồi tệ nhất.

Khi hai phần của cơ sở mã xung đột với nhau, Claude sẽ cố gắng làm hài lòng cả hai bên cùng một lúc, dẫn đến một mớ mã không mạch lạc.

Khoảnh khắc đó diễn ra như thế này: có hai nhóm mẫu xử lý lỗi trong cơ sở mã, một nhóm là không đồng bộ/chờ cộng với thử/bắt rõ ràng và nhóm còn lại là ranh giới lỗi toàn cục. Mã mới mà Claude viết sử dụng cả hai bộ. Kết quả là việc xử lý lỗi được thực hiện hai lần. Tôi phải mất 30 phút để tìm ra lý do tại sao lỗi này lại bị nuốt hai lần.

Quy tắc 8: Đọc trước, viết sau

Trước khi thêm mã vào một tệp, hãy đọc bản xuất của tệp, người gọi trực tiếp và bất kỳ chức năng tiện ích chia sẻ rõ ràng nào có liên quan. Nếu bạn không hiểu tại sao mã hiện tại lại được sắp xếp như vậy, trước tiên hãy đặt câu hỏi, đừng chỉ thêm nội dung vào đó. "Nó có vẻ không liên quan đến tôi" là câu nói nguy hiểm nhất trong cơ sở mã này.

Việc "sửa đổi phẫu thuật" của Karpathy yêu cầu Claude không được thay đổi mật mã liền kề. Nhưng nó không nói với Claude: trước tiên hãy hiểu mã liền kề. Nếu không có điều này, Claude có thể đã viết mã mới xung đột với mã hiện có cách đó 30 dòng.

Vấn đề là thế này: Claude thêm một hàm mới có cùng chức năng bên cạnh hàm hiện có, vì nó không đọc hàm gốc trước. Cả hai chức năng đều làm điều tương tự. Nhưng do thứ tự nhập khẩu, chức năng mới sẽ ghi đè chức năng cũ, vốn là tiêu chuẩn duy nhất trên thực tế trong 6 tháng.

Quy tắc 9: Kiểm thử không phải là tùy chọn, nhưng bản thân kiểm thử không phải là mục tiêu

Mọi kiểm thử đều phải mã hóa "tại sao hành vi này lại quan trọng", chứ không chỉ "nó làm gì". Một thử nghiệm như `expect(getUserName()).toBe('John')` sẽ vô giá trị nếu hàm thực sự nhận được ID được mã hóa cứng. Nếu bạn không thể viết một bài kiểm thử thất bại khi logic nghiệp vụ thay đổi thì bản thân hàm đó đã sai.

"Thực thi theo định hướng mục tiêu" của Karpathy ngụ ý rằng thử nghiệm có thể coi là tiêu chí để thành công. Nhưng trên thực tế, Claude coi "vượt qua bài kiểm tra" là mục tiêu duy nhất của mình, vì vậy anh ấy sẽ viết một số mã có thể vượt qua các bài kiểm tra nông cạn nhưng lại phá vỡ những thứ khác.

Thời điểm đó là thế này: Claude đã viết 12 bài kiểm tra cho chức năng xác thực và tất cả đều vượt qua. Nhưng logic xác thực trong môi trường sản xuất bị hỏng. Những thử nghiệm đó chỉ xác minh rằng hàm "trả về thứ gì đó" thay vì xác minh rằng nó trả về đúng thứ. Hàm này vượt qua bài kiểm tra vì nó trả về một hằng số.

Quy tắc 10: Các hoạt động kéo dài cần có điểm kiểm tra

Trong các nhiệm vụ nhiều bước, sau khi hoàn thành mỗi bước, hãy tóm tắt những gì đã làm, những gì đã được xác minh và những gì còn lại. Đừng tiếp tục từ một vị trí mà bạn không thể giải thích rõ ràng cho tôi. Nếu bạn thấy mình lạc lối, hãy dừng lại và xác định lại tình hình hiện tại của mình.

Tương tác mặc định với các mẫu của Karpathy là một lần. Nhưng công việc thực sự của Claude Code thường bao gồm nhiều bước: tái cấu trúc trên 20 tệp, xây dựng các tính năng trong một phiên, gỡ lỗi trên nhiều lần xác nhận. Nếu không có điểm kiểm tra, một bước sai có thể bị mất và tất cả tiến trình trước đó có thể bị mất.

Thời điểm đó là thế này: một nhiệm vụ tái cấu trúc gồm 6 bước đã gặp trục trặc ở bước 4. Vào thời điểm tôi phát hiện ra, Claude đã hoàn thành bước 5 và 6 bên cạnh trạng thái lỗi. Việc tháo rời và sửa chữa mất nhiều thời gian hơn là làm lại toàn bộ nhiệm vụ. Nếu có điểm kiểm tra, bước 4 sẽ bộc lộ vấn đề.

Quy tắc 11: Quy ước được ưu tiên hơn tính mới

Nếu cơ sở mã sử dụng snake_case và bạn thích CamelCase: hãy sử dụng snake_case. Nếu cơ sở mã của bạn sử dụng các thành phần dựa trên lớp và bạn thích hook hơn: hãy sử dụng các thành phần dựa trên lớp. Bất đồng là một cuộc thảo luận khác. Trong cơ sở mã, tính nhất quán được ưu tiên hơn sở thích cá nhân. Nếu bạn thực sự nghĩ rằng một quy ước là có hại, hãy nói như vậy. Đừng âm thầm tạo ra một con đường rẽ nhánh.

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

Thời điểm đó là thế này: Claude đưa hook vào cơ sở mã React dựa trên các thành phần lớp. Nó thực sự hoạt động. Nhưng nó cũng phá vỡ mẫu thử nghiệm ban đầu của cơ sở mã, vì những thử nghiệm đó dựa vào thành phầnDidMount. Cuối cùng tôi phải mất nửa ngày để xóa và viết lại nó.

Quy tắc 12: Thất bại một cách rõ ràng chứ không phải âm thầm

Nếu bạn không chắc điều gì đó đã thành công, hãy nói như vậy. Bạn không thể nói "quá trình di chuyển đã hoàn tất" nếu 30 bản ghi bị bỏ qua một cách âm thầm. Bạn không thể nói "kiểm tra đã vượt qua" nếu bạn bỏ qua bất kỳ bài kiểm tra nào. Bạn không thể nói "tính năng khả dụng" nếu bạn chưa xác minh các trường hợp đặc biệt mà tôi yêu cầu. Mặc định bộc lộ sự không chắc chắn thay vì che giấu nó.

Claude Những thất bại đắt giá nhất thường là những thất bại trông có vẻ thành công. Một hàm "hoạt động" nhưng trả về dữ liệu không chính xác; quá trình di chuyển "hoàn thành" nhưng bỏ qua 30 bản ghi; một bài kiểm tra "vượt qua" nhưng chỉ vì bản thân khẳng định đó đã sai.

Thời điểm đó là thế này: Claude cho biết quá trình di chuyển cơ sở dữ liệu đã "hoàn thành thành công". Nhưng trên thực tế, nó âm thầm bỏ qua 14% số bản ghi gây ra vi phạm ràng buộc. Hành vi bỏ qua được ghi lại nhưng không được hiển thị rõ ràng. Chúng tôi phát hiện ra sự cố 11 ngày sau khi dữ liệu báo cáo bắt đầu hoạt động bất thường.

Kết quả dữ liệu

Tôi đã theo dõi cùng một nhóm 50 tác vụ tiêu biểu trong 6 tuần, bao gồm 30 cơ sở mã và thử nghiệm ba cấu hình.

Tỷ lệ lỗi đề cập đến: nhu cầu nhiệm vụ được sửa chữa hoặc viết lại cho phù hợp với mục đích ban đầu. Các lỗi được tính bao gồm: các giả định không chính xác thầm lặng, kỹ thuật quá mức, sự cố không liên quan, lỗi thầm lặng, vi phạm hợp đồng, thỏa hiệp mâu thuẫn và bỏ sót các điểm kiểm tra.

Tỷ lệ tuân thủ đề cập đến: khi áp dụng một quy tắc nhất định, xác suất Claude sẽ áp dụng quy tắc này một cách rõ ràng.

Kết quả thực sự thú vị không chỉ là tỷ lệ lỗi giảm từ 41% xuống còn 3%. Hơn nữa, việc mở rộng từ 4 lên 12 quy tắc đã tăng thêm một chút gánh nặng tuân thủ—tỷ lệ tuân thủ chỉ tăng từ 78% lên 76%—nhưng tỷ lệ lỗi lại giảm thêm 8 điểm phần trăm. Các quy tắc mới bao gồm các dạng lỗi không được bốn quy tắc ban đầu xử lý và chúng không cạnh tranh để giành được cùng một ngân sách chú ý.

Mẫu Karpathy sẽ ở đâu lặng lẽ thất bại?

Ngay cả khi các quy tắc mới không được thêm vào, mẫu 4 quy tắc ban đầu vẫn không đủ ở ít nhất 4 vị trí.

Đầu tiên, các nhiệm vụ Tác nhân dài hạn.
Quy tắc của Karpathy tập trung vào thời điểm Claude đang viết mã. Nhưng điều gì sẽ xảy ra khi Claude đang chạy một quy trình gồm nhiều bước? Mẫu ban đầu không có quy tắc ngân sách, không có quy tắc điểm kiểm tra và không có quy tắc "thất bại nặng nề". Vì thế đường ống sẽ trôi từ từ.

Thứ hai, tính nhất quán trên nhiều cơ sở mã.
"Khớp các kiểu hiện có" chỉ có một kiểu theo mặc định. Nhưng trong một monorepo có 12 dịch vụ, Claude phải chọn phong cách nào cho phù hợp. Các quy tắc ban đầu không cho nó biết cách lựa chọn. Vì vậy, nó chọn ngẫu nhiên hoặc trộn đều nhiều kiểu.

Thứ ba, chất lượng kiểm tra.
"Việc thực hiện theo định hướng mục tiêu" sẽ coi việc "vượt qua bài kiểm tra" là thành công nhưng không chỉ rõ rằng bản thân bài kiểm tra đó phải có ý nghĩa. Kết quả là, Claude viết các bài kiểm tra hầu như không xác minh được gì ngoài việc đánh lừa nó rằng nó đáng tin cậy.

Thứ tư, sự khác biệt giữa môi trường sản xuất và giai đoạn nguyên mẫu.
4 quy tắc tương tự ngăn mã sản xuất bị thiết kế quá mức cũng có thể làm chậm quá trình phát triển nguyên mẫu. Bởi vì giai đoạn tạo mẫu đôi khi yêu cầu 100 dòng giàn giáo thăm dò để có được vòng bi của bạn trước tiên. Cách tiếp cận “đơn giản đầu tiên” của Karpathy có thể dễ dàng bị kích hoạt quá mức trong mã ban đầu.

8 quy tắc mới này không nhằm mục đích thay thế 4 quy tắc ban đầu của Karpathy mà để vá những lỗ hổng của chúng: mẫu ban đầu tương ứng với kịch bản viết mã tự động hoàn thành vào tháng 1 năm 2026; và đến tháng 5 năm 2026, Claude Code đã bước vào môi trường cộng tác dựa trên nhiều mã, nhiều bước, do Tác nhân điều khiển và các vấn đề mà cả hai gặp phải là khác nhau.

Điều gì đã không xảy ra công việc

Tôi đã thử một vài thứ khác trước khi quyết định áp dụng 12 quy tắc này.

Tham gia các quy tắc tôi thấy trên Reddit/X.
Hầu hết chúng chỉ là sự lặp lại 4 quy tắc ban đầu của Karpathy theo các thuật ngữ khác nhau hoặc các quy tắc dành riêng cho từng miền không thể khái quát hóa, chẳng hạn như "Luôn sử dụng lớp Tailwind". Cuối cùng chúng đã bị xóa.

Hơn 12 quy tắc.
Tôi đã thử nghiệm tới 18 mục. Ngoài 14 mục, tỷ lệ tuân thủ giảm từ 76% xuống 52%. Giới hạn 200 dòng là có thật. Sau khi vượt quá độ dài này, Claude sẽ bắt đầu khớp mẫu để "đây là các quy tắc" thay vì thực sự đọc từng quy tắc một.

Dựa vào các quy tắc tồn tại cho một số công cụ nhất định.
Ví dụ: "Luôn sử dụng eslint", một khi eslint không được cài đặt trong dự án, quy tắc này sẽ trở nên không hợp lệ và nó sẽ âm thầm không hợp lệ. Sau đó, tôi đã thay đổi nó thành một biểu thức không dựa vào các công cụ cụ thể, chẳng hạn như thay đổi "sử dụng eslint" thành "tuân theo kiểu đã được thực thi trong cơ sở mã".

Đưa ví dụ vào CLAUDE.md chứ không phải quy tắc.
Ví dụ chiếm nhiều ngữ cảnh hơn quy tắc. Bối cảnh được sử dụng bởi ba ví dụ gần như tương đương với 10 quy tắc và Claude có thể dễ dàng phù hợp với các ví dụ. Các quy tắc là trừu tượng, ví dụ là cụ thể. Vì vậy, nên sử dụng các quy tắc.

"Cẩn thận", "suy nghĩ cẩn thận" và "tập trung".
Tất cả đều là tiếng ồn. Việc tuân thủ các chỉ thị như vậy giảm xuống còn khoảng 30% vì chúng không thể được xác minh. Sau đó tôi đã thay thế chúng bằng những quy tắc mệnh lệnh cụ thể hơn, chẳng hạn như “nêu rõ các giả định”.

Bảo Claude hành động như một "kỹ sư cấp cao".
Vô ích thôi. Claude đã cảm thấy mình như một kỹ sư cấp cao. Câu hỏi thực sự không phải là liệu nó có nghĩ như vậy hay không, mà là liệu nó có làm như vậy hay không. Các quy tắc bắt buộc có thể thu hẹp khoảng cách này, nhưng các tín hiệu nhận dạng thì không.

Phiên bản 12 quy tắc hoàn chỉnh của CLAUDE.md

Sau đây là phiên bản hoàn chỉnh có thể sao chép và dán trực tiếp.

Nội dung này hiện không thể hiển thị bên ngoài tài liệu Feishu

Lưu nó dưới dạng CLAUDE.md trong thư mục gốc của kho. Theo 12 quy tắc này, hãy thêm các quy tắc dành riêng cho dự án, chẳng hạn như ngăn xếp công nghệ, lệnh kiểm tra, chế độ lỗi, v.v. Tổng số không được vượt quá 200 dòng. Sau đó, tỷ lệ tuân thủ quy định sẽ giảm đáng kể.

Cách cài đặt

Hai bước:

1. Thêm 4 quy tắc cơ bản của Karpathy vào CLAUDE.md
curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md

2. Thêm các quy tắc trong bài viết này 5–12 Dán bên dưới

Lưu tệp vào thư mục gốc của kho lưu trữ. >> ở đây rất quan trọng. Chức năng của nó là thêm vào CLAUDE.md hiện có, thay vì ghi đè các quy tắc dành riêng cho dự án mà bạn đã viết.

Mô hình tinh thần

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

Mỗi quy tắc phải trả lời một câu hỏi: Nó ngăn ngừa những lỗi gì?

4 quy tắc của Karpathy bảo vệ khỏi những kiểu thất bại mà ông đã thấy vào tháng 1 năm 2026: những giả định thầm lặng, kỹ thuật quá mức, sự phá hủy không liên quan và tiêu chí thành công yếu. Đó là những điều cơ bản, đừng bỏ qua chúng.

8 quy tắc mới mà tôi đã thêm vào nhằm ngăn chặn các chế độ lỗi mới sẽ xuất hiện sau tháng 5 năm 2026: Vòng lặp tác nhân không có ràng buộc về ngân sách, nhiệm vụ nhiều bước không có điểm kiểm tra, các thử nghiệm có vẻ như đã được thử nghiệm nhưng thực tế lại không kiểm tra được logic chính và vấn đề đóng gói những thất bại thầm lặng thành những thành công thầm lặng. Chúng là những bản vá gia tăng.

Tất nhiên, tác dụng cụ thể ở mỗi người là khác nhau. Nếu bạn không chạy quy trình gồm nhiều bước thì Quy tắc 10 sẽ không quan trọng đối với bạn. Quy tắc 11 là không cần thiết nếu cơ sở mã của bạn chỉ có một kiểu thống nhất đã được lint thực thi. Sau khi đọc 12 điều này, hãy giữ lại những quy tắc thực sự tương ứng với những lỗi bạn thực sự đã mắc phải và xóa những lỗi còn lại.

Phiên bản CLAUDE.md với 6 quy tắc được điều chỉnh cho phù hợp với các chế độ lỗi thực tế sẽ tốt hơn phiên bản có 12 quy tắc, trong đó có 6 quy tắc bạn sẽ không bao giờ sử dụng.

Kết luận

Tweet của Karpathy vào tháng 1 năm 2026 về cơ bản là một lời phàn nàn. Forrest Chang đã biến nó thành 4 quy tắc. Cuối cùng, 120.000 nhà phát triển đã cho kết quả này một ngôi sao. Và hầu hết hiện nay họ vẫn chỉ sử dụng 4 quy tắc đó.

Mô hình đã phát triển và hệ sinh thái đã thay đổi. Tác nhân nhiều bước, móc nối, tải kỹ năng, cộng tác đa cơ sở mã - không cái nào trong số này tồn tại khi Karpathy viết dòng tweet đó. 4 quy tắc ban đầu không giải quyết được những vấn đề này. Họ không sai, họ không đầy đủ.

Đã thêm 8 quy tắc mới. 6 tuần thử nghiệm bao gồm 30 cơ sở mã. Tỷ lệ lỗi giảm từ 41% xuống 3%.

Đánh dấu bài viết này tối nay và dán 12 quy tắc này vào CLAUDE.md của bạn. Nếu nó giúp bạn tránh được Claude đi đường vòng trong một tuần, hãy chia sẻ nó.

[Liên kết gốc]