Tiêu đề Ban đầu: Quy tắc 4 CLAUDE.md của Karpathy đã giảm lỗi của Claude từ 41% xuống còn 11%. Sau 30 bộ mã nguồn, tôi đã thêm 8 quy tắc

Biên tập viên: Vào tháng 1 năm 2026, Andrej Karpathy đã ghi chú về cách Claude viết mã, đưa ra một tập hợp các quy tắc hành vi có vẻ như nhỏ nhưng cực kỳ quan trọng trong luồng làm việc lập trình AI: CLAUDE.md. Sau đó, Forrest Chang đã tổ chức những vấn đề này thành 4 quy tắc hành vi, cố gắng hạn chế các lỗi thường gặp của Claude khi lập trình: giả định im lặng, quá mức kỹ thuật, ảnh hưởng âm thầm đến mã không liên quan và thiếu tiêu chuẩn thành công rõ ràng.

Nhưng vài tháng sau đó, việc sử dụng mã Claude không còn chỉ là "làm cho mô hình viết một đoạn mã" nữa. Khi các tác nhân đa bước, kích hoạt chuỗi hook, tải kỹ năng và cộng tác đa kho mã trở nên phổ biến, các mẫu thất bại mới cũng bắt đầu xuất hiện: mô hình mất kiểm soát trong nhiệm vụ dài, kiểm tra qua mặt nhưng không xác minh logic thực sự, di cư hoàn chỉnh nhưng bỏ qua lỗi một cách im lặng, pha trộn sai lầm các phong cách mã khác nhau.

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

Dưới đây là bản dịch:

Vào cuối tháng 1 năm 2026, Andrej Karpathy đã tweet về cách Claude viết mã. Anh ấy đã chỉ ra ba loại vấn đề điển hình: giả định sai lầm mà không có hướng dẫn, quá mức phức tạp, và gây thiệt hại không liên quan cho mã gốc.

Forrest Chang đã nhìn thấy loạt tweet này, tổ chức những phàn nàn thành 4 quy tắc hành vi, viết vào một tệp CLAUDE.md riêng và đăng lên GitHub. Dự án này đã nhận được 5.828 sao ngôi sao trong ngày đầu tiên ra mắt, được ưa thích 60.000 lần trong hai tuần, và hiện đang có 120.000 sao ngôi sao, trở thành kho mã duy nhất phát triển nhanh nhất trong năm 2026.

Sau đó, trong vòng 6 tuần, tôi đã thử nghiệm nó với 30 kho mã.

Bốn quy tắc này thực sự hiệu quả. Tỉ lệ lỗi xảy ra một khoảng 40% trong quá khứ đã giảm xuống dưới 3% trong các nhiệm vụ phù hợp với các quy tắc này. Tuy nhiên, vấn đề là, mẫu này ban đầu được tạo ra để giải quyết vấn đề lỗi khi Claude viết mã vào tháng 1.

Vào tháng 5 năm 2026, các vấn đề mà Claude Code đối mặt đã khác đi: Xung đột giữa các Agent, kích hoạt chuỗi hook, xung đột tải kỹ năng, và ngắt các quy trình làm việc đa bước xuyên phiên.

Vì vậy, tớ đã thêm vào 8 quy tắc khác. 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 đáng được thêm vào và mẫu gốc của Karpathy sẽ bị thất bại âm thầm ở 4 địa điểm.

Nếu bạn muốn bỏ qua lời giải thích, vui lòng sao chép và sử dụng trực tiếp, tệp đầy đủ được đặt ở cuối tài liệu.

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

CLAUDE.md của Claude Code là tệp được đánh giá thấp nhất trong toàn bộ ngăn xếp công nghệ lập trình AI. Đa số nhà phát triển thường mắc ba loại lỗi:

Thứ nhất, họ xem nó như một thùng rác ưa thích, xếp tất cả thói quen của họ vào đó, rồi cuối cùng phình to lên thành hơn 4000 mã thông báo, tỷ lệ tuân thủ quy tắc giảm xuống còn 30%.

Thứ hai, họ đơn giản không sử dụng, mỗi lần đều nhập lại từ đầu. Điều này sẽ dẫn đến lãng phí mã thông báo gấp 5 lần, và thiếu tính nhất quán giữa các phiên khác nhau.

Thứ ba, họ sao chép một mẫu rồi không quan tâm nữa. Nó có thể hiệu quả trong hai tuần, nhưng khi cơ sở mã thay đổi, nó sẽ trở nên vô hiệu mà bạn không hề hay biết.

Tài liệu chính thức của Anthropic nói rất rõ rằng: CLAUDE.md nguyên bản chỉ mang tính khuyến nghị. Claude sẽ tuân thủ các quy tắc khoảng 80% thời gian. Khi vượt quá 200 dòng, tỷ lệ tuân thủ sẽ rõ rệt giảm đi, vì các quy tắc quan trọng sẽ bị làm chìm dưới tiếng ồn.

Mẫu của Karpathy giải quyết vấn đề này: một tệp, 65 dòng, 4 quy tắc. Đó là mức cơ sở thấp nhất.

Nhưng giới hạn trên vẫn có thể cao hơn. Sau khi thêm vào 8 quy tắc dưới đây, nó sẽ không chỉ áp dụng cho vấn đề viết mã mà Karpathy đã phàn nàn vào tháng 1 năm 2026, mà còn bao gồm cả vấn đề sắp xếp Agent mà mới xuất hiện vào tháng 5 năm 2026 – những vấn đề này chưa tồn tại khi mẫu gốc được tạo ra.

4 Quy Tắc Gốc

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

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

Đừng giả định mà không nói ra. Hãy giải thích giả định của bạn, làm sáng tỏ các điểm cân nhắc. Hỏi trước khi phỏng đoán. Khi có một giải pháp đơn giản hơn, hãy đề xuất ý kiến phản đối một cách tích cực.

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

Quy tắc 3: Sửa chữa như phẫu thuật.
Chỉ sửa những phần cần phải sửa. Đừng "tinh chỉnh" mã lân cận, chú thích hoặc định dạng theo cách suôn sẻ. Đừng làm mới một cái gì đó chưa hỏng. Giữ cho kiểu dáng hiện tại đồng nhất.

Quy tắc 4: Thực hiện hướng mục tiêu.
Xác định tiêu chuẩn thành công trước, sau đó lặp lại quá trình cho đến khi xác minh hoàn tất. Đừng nói cho Claude từng bước làm gì, thay vào đó, hãy nói với nó mục tiêu thành công sẽ như thế nào, để nó tự lặp lại.

Bốn quy tắc này có thể giải quyết khoảng 40% mẫu thất bại mà tôi đã thấy trong phiên hội thoại Claude Code không có sự giám sát. Khoảng 60% còn lại của vấn đề ẩn giấu trong những khu vực trắng như dưới đây.

Tám quy tắc tôi thêm vào và lý do

Mỗi quy tắc đều xuất phát từ một thời điểm thực: Bốn quy tắc ban đầu của Karpathy không còn đủ. Dưới đây, tôi sẽ nói về tình huống đó trước, sau đó cung cấp quy tắc tương ứng.

Quy tắc 5: Không để mô hình thực hiện công việc không ngôn ngữ

Bạn có thể sử dụng Claude để: phân loại, viết nháp, tóm tắt, trích xuất thông tin từ văn bản không cấu trúc. Đừng sử dụng Claude để: định tuyến, thử lại, xử lý mã trạng thái, chuyển đổi xác định. Nếu một 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. Do đó, mô hình bắt đầu quyết định một số vấn đề mà mã cố định nên xử lý: liệu có nên thử lại cuộc gọi API lần nữa, làm thế nào để định tuyến một tin nhắn, khi nào nên nâng cấp xử lý. Kết quả là, mỗi tuần quyết định của bạn sẽ khác nhau. Bạn sẽ nhận được một if-else không ổn định, tính theo mỗi token 0,003 USD.

Thời điểm đó như sau: Một phần mã sẽ gọi Claude để "quyết định xem có nên thử lại khi gặp phải lỗi 503". Ban đầu, nó hoạt động tốt, duy trì trong hai tuần, sau đó bất ngờ trở nên không ổn định, vì mô hình bắt đầu xem cả yêu cầu là một ngữ cảnh quyết định. Chiến lược thử lại trở nên ngẫu nhiên, vì prompt chính nó đã là ngẫu nhiên.

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

Ngân sách cho mỗi nhiệm vụ: 4,000 token. Ngân sách cho mỗi phiên: 30,000 token. Nếu một nhiệm vụ gần đạt đến giới hạn ngân sách, hãy tóm tắt trạng thái hiện tại, sau đó bắt đầu lại từ đầu. Đừng cố gắng ép buộc tiếp tục. Để rõ ràng vấn đề vượt quá ngân sách, tốt hơn là vượt ngân sách mà không lên tiếng.

Một tệp CLAUDE.md không có hạn chế ngân sách, đồng nghĩa với một tờ séc trắng không. Mỗi chu kỳ đều có thể bất ổn, biến thành một lần đổ dồn ngữ cảnh 50,000 token. Mô hình sẽ không tự dừng lại.

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

Quy tắc 7: Tiết lộ xung đột, không hài lòng trung bình

Nếu hai chế độ hiện có trong thư viện mã nguồn mâu thuẫn lẫn nhau, không nên trộn chúng lại. Chọn một trong hai chế độ, ưu tiên chọn chế độ cập nhật hoặc đã được kiểm tra kỹ hơn, giải thích lý do và đánh dấu chế độ còn lại cần dọn dẹp sau này. "Mã nguồn trung bình" cố gắng đồng thời thỏa mãn cả hai bộ quy tắc, là mã nguồn tồi nhất.

Khi hai phần trong thư viện mã nguồn mâu thuẫn lẫn nhau, Claude sẽ cố gắng phục vụ cả hai bên, kết quả tạo ra mã nguồn không nhất quán.

Thời điểm đó như sau: Trong một thư viện mã nguồn, có hai bộ quy tắc xử lý lỗi, một bộ sử dụng async/await kết hợp với try/catch rõ ràng, bộ khác sử dụng ranh giới lỗi toàn cầu. Mã nguồn mới viết bởi Claude sử dụng cả hai bộ quy tắc. Kết quả là xử lý lỗi được thực hiện hai lần. Tôi mất 30 phút mới hiểu, tại sao lỗi đã bị ủ một lần.

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

Trước khi thêm mã vào tệp, hãy đọc nội dung được xuất của tệp đó, các điểm gọi trực tiếp và bất kỳ hàm tiện ích chung nào mà rõ ràng có liên quan. Nếu bạn không hiểu tại sao mã hiện tại được tổ chức như vậy, hãy đặt câu hỏi trước, đừng thêm mã trực tiếp vào đó. "Theo tôi thì điều này không liên quan" là câu nói nguy hiểm nhất trong thư viện mã nguồn này.

Phương pháp "Phẫu thuật ngoại khoa" của Karpathy ra lệnh cho Claude không được sửa đổi mã kế bên. Nhưng nó không nói cho Claude: hãy hiểu rõ mã kế bên trước. Thiếu điều này, Claude sẽ viết mã mới xung đột với mã đã có hơn 30 dòng.

Thời điểm đó là như vậy: Claude đã thêm một hàm hoàn toàn giống như một chức năng hiện có bên cạnh mà không đọc trước hàm gốc, vì vậy hai hàm đó thực hiện cùng một công việc. Nhưng vì thứ tự import, hàm mới đã ghi đè lên hàm cũ, trong khi hàm cũ đã là tiêu chuẩn duy nhất trong thực tế trong 6 tháng.

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

Mỗi bài kiểm tra phải mã hóa "tại sao hành vi này quan trọng", không chỉ "nó đã làm gì". Một bài kiểm tra như `expect(getUserName()).toBe('John')` là vô nghĩa nếu hàm đó thực ra nhận một ID cứng. Nếu bạn không thể viết ra một bài kiểm tra sẽ thất bại khi logic kinh doanh thay đổi, thì hàm đó chính nó đã sai.

Khái niệm "thực hiện theo mục tiêu" của Karpathy ngụ ý rằng kiểm thử có thể được coi là tiêu chí thành công. Nhưng trong thực tế, Claude sẽ xem 'kiểm thử qua' là mục tiêu duy nhất, vì vậy viết ra một số mã mà có thể vượt qua các bài kiểm tra sâu mà vẫn làm hỏng mọi thứ.

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

Luật 10: Các hoạt động chạy lâu cần có điểm kiểm tra

Trong các tác vụ nhiều bước, sau mỗi bước hoàn thành, tóm tắt những gì đã làm, xác minh những gì đã xác minh, còn lại gì. Không bao giờ tiếp tục từ trạng thái mà bạn không thể phác thảo được cho tôi. Nếu bạn thấy mình đã bị lạc, hãy dừng lại, phác thảo lại trạng thái hiện tại.

Karpathy trong mẫu mặc định giao tiếp là một lần duy nhất. Nhưng công việc viết mã thực sự của Claude Code thường là nhiều bước: tái cấu trúc qua 20 tệp, xây dựng tính năng trong một phiên, chỉnh sửa qua nhiều commit. Nếu thiếu điểm kiểm tra, nếu một bước sai lầm, toàn bộ tiến trình trước đó có thể mất.

Thời điểm đó là như vậy: một nhiệm vụ tái cấu trúc 6 bước bị lỗi ở bước 4. Khi tôi phát hiện ra, Claude đã tiếp tục hoàn thành bước 5 và bước 6 trên trạng thái lỗi đó. Thời gian phân ra và sửa sai kéo dài hơn nhiều so với việc làm lại toàn bộ nhiệm vụ. Nếu có điểm kiểm tra, việc phát hiện vấn đề ở bước 4 sẽ nhanh hơn.

Quy tắc 11: Thỏa thuận Ưu tiên hơn Sáng tạo

Nếu thư viện mã nguồn sử dụng snake_case, trong khi bạn thích hơn camelCase: Hãy sử dụng snake_case. Nếu thư viện mã nguồn sử dụng các thành phần dựa trên lớp (class-based), trong khi bạn thích hooks: Hãy sử dụng các thành phần dựa trên lớp. Sự không đồng ý sẽ là một cuộc thảo luận khác. Trong thư viện mã nguồn, tính nhất quán được ưu tiên hơn so với sở thích cá nhân. Nếu bạn thực sự tin rằng một thỏa thuận nào đó có hại, hãy đề xuất một cách rõ ràng. Đừng im lặng tạo ra một nhánh code mới.

Trong một thư viện mã nguồn mà mẫu đã có, Claude thích giới thiệu phong cách của chính mình. Ngay cả khi phong cách của Claude "tốt hơn", việc giới thiệu một bộ mẫu thứ hai mà mình chỉ đưa ra, vẫn tệ hơn bất kỳ một mẫu duy nhất nào.

Đó là lúc: Claude đã giới thiệu hooks vào một thư viện mã nguồn React dựa trên class component. Nó thực sự hoạt động. Nhưng nó đã làm hỏng mẫu kiểm tra ban đầu của thư viện, vì những kiểm tra đó phụ thuộc vào componentDidMount. Cuối cùng, đã mất nửa ngày để xóa nó và viết lại từ đầu.

Quy tắc 12: Phải Xuất hiện Thất bại Rõ ràng, Không Được Thất bại Lặng lẽ

Nếu bạn không chắc chắn rằng một điều gì đó đã thành công, hãy nói ra một cách rõ ràng. Nếu có 30 bản ghi bị bỏ qua một cách lặng lẽ, bạn không thể nói "di cư hoàn tất". Nếu bạn bỏ qua bất kỳ kiểm tra nào, bạn không thể nói "kiểm tra đã qua". Nếu bạn không xác minh những trường hợp biên mà tôi yêu cầu, bạn không thể nói "chức năng có sẵn". Mặc định phải tiếp tục sự không chắc chắn, thay vì che giấu nó.

Thất bại đắt giá nhất của Claude thường là những thất bại trông như thành công. Một hàm "chạy được", nhưng trả về dữ liệu sai; một lần di cư "hoàn thành", nhưng bỏ qua 30 bản ghi; một kiểm tra "đã qua", nhưng chỉ vì biểu đạt của nó đã sai.

Đó là lúc: Claude nói rằng một lần di cư cơ sở dữ liệu "hoàn tất". Nhưng thực tế, nó đã lặng lẽ bỏ qua 14% bản ghi gây xung đột ràng buộc. Hành vi bỏ qua đã được ghi vào nhật ký, nhưng không được tiết lộ rõ ràng. Mười một ngày sau, khi dữ liệu báo cáo bắt đầu bất thường, chúng tôi mới phát hiện vấn đề.

Kết quả Dữ liệu

Trong vòng 6 tuần, tôi đã theo dõi cùng một nhóm 50 nhiệm vụ đại diện, bao gồm 30 thư viện mã nguồn, và đã kiểm tra ba cấu hình khác nhau.

Tỷ lệ Lỗi đề cập đến việc: Công việc cần được sửa hoặc viết lại để phù hợp với ý định ban đầu. Các lỗi được tính gồm: Ước lượng lỗi Implied, Over-engineering, Destructive Irrelevance, Lỗi Implied, Vi phạm thỏa thuận, Conflict Implied, Thiếu checkpoint.

Tỷ lệ Tuân thủ đề cập đến: Khi một quy tắc nào đó áp dụng, khả năng mà Claude sẽ áp dụng rõ ràng quy tắc đó.

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%. Quan trọng hơn, từ 4 quy tắc mở rộng thành 12 quy tắc, gần như không tăng gánh nặng tuân thủ, tỷ lệ tuân thủ chỉ từ 78% xuống còn 76%, nhưng tỷ lệ lỗi lại giảm 8 điểm phần trăm. Các quy tắc mới mở rộng bao gồm các mẫu lỗi mà 4 quy tắc ban đầu không xử lý, chúng không cạnh tranh cho cùng một nguồn lực chú ý.

Mẫu Karpathy sẽ bí mật không hoạt động tại những nơi nào

Ngay cả khi không thêm quy tắc mới, mẫu 4 quy tắc ban đầu cũng ít nhất không đủ để sử dụng ở 4 nơi.

Thứ nhất, Công việc Agent chạy lâu dài.
Quy tắc của Karpathy chủ yếu dành cho thời điểm Claude đang viết mã. Nhưng khi Claude thực hiện một pipeline đa bước, điều gì sẽ xảy ra? Mẫu gốc không có quy tắc đề xuất, không có quy tắc checkpoint, cũng không có quy tắc "fail loudly". Do đó, pipeline sẽ dần dần trôi.

Thứ hai, Tính nhất quán giữa nhiều thư viện mã.
“Khớp với phong cách hiện có” mặc định chỉ có một phong cách. Nhưng trong một monorepo có 12 dịch vụ, Claude phải chọn để khớp với phong cách nào. Quy tắc ban đầu không cho biết cách chọn. Vì vậy, hoặc Claude sẽ chọn ngẫu nhiên, hoặc trộn hỗn hợp các phong cách.

Thứ ba, Chất lượng kiểm thử.
“Thực thi theo mục tiêu” sẽ coi “kiểm thử qua” là thành công, nhưng không nói rằng kiểm thử đó phải có ý nghĩa. Kết quả là, Claude viết một số kiểm thử gần như không xác minh điều gì, nhưng những kiểm thử này khiến nó nghĩ rằng mình chắc chắn.

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.
Cùng 4 quy tắc, có thể ngăn chặn việc quá mức kỹ thuật hóa mã sản xuất, nhưng cũng có thể làm chậm quá trình phát triển nguyên mẫu. Bởi vì đôi khi giai đoạn nguyên mẫu thực sự cần 100 dòng scaffold thăm dò, để hiểu rõ hướng đi. “Ưu tiên đơn giản” của Karpathy dễ kích hoạt quá mức ở mã đầu.

8 quy tắc mới không nhằm thay thế 4 quy tắc ban đầu của Karpathy, mà là để bổ sung cho chúng, bù đắp những hiat tại: mẫu gốc tương ứng với tình huống viết mã dựa vào tự động vào tháng 1 năm 2026; và đến tháng 5 năm 2026, Mã Claude đã bước vào một môi trường hợp tác đa bước, đa mã nguồn do Agent thúc đẩy, hai tình huống đối mặt với các vấn đề khác nhau.

Các phương pháp nào không hiệu quả

Trước khi quyết định cuối cùng về 12 quy tắc này, tôi cũng đã thử qua một số phương pháp khác.

Thêm các quy tắc tôi thấy trên Reddit / X.
Đa số trong số đó, hoặc chỉ đơn giản là tái diễn giải 4 quy tắc gốc của Karpathy dưới một cách diễn đạt khác, hoặc là các quy tắc cụ thể cho lĩnh vực không thể tổng quát hóa, chẳng hạn như "Luôn luôn sử dụng lớp Tailwind". Cuối cùng tôi đã xóa chúng.

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

Phụ thuộc vào các công cụ cụ thể.
Ví dụ, "Luôn luôn sử dụng eslint", một khi dự án không cài đặt eslint, quy tắc này sẽ trở nên không có hiệu lực, và không báo lỗi. Sau đó tôi đã thay đổi nó thành một biểu hiện không phụ thuộc vào công cụ cụ thể, chẳng hạn như chuyển "Sử dụng eslint" thành "Tuân theo phong cách đã được áp dụng mạnh mẽ trong cơ sở mã nguồn".

Đưa ví dụ trong CLAUDE.md thay vì là các quy tắc.
Ví dụ chiếm nhiều không gian nội dung hơn so với quy tắc. Ba ví dụ tiêu tốn nhiều không gian nội dung tương đương với 10 quy tắc, và Claude có thể dễ dàng quá mức khớp với ví dụ. Quy tắc trừu tượng, ví dụ cụ thể. Vì vậy, nên sử dụng quy tắc.

"Cẩn thận một chút", "Nghĩ một cách nghiêm túc", "Tập trung hơn chút".
Đây đều là tiếng ồn. Tỷ lệ tuân thủ của các chỉ thị này giảm xuống khoảng 30%, vì chúng không thể được kiểm tra. Sau đó tôi đã thay thế chúng bằng các quy tắc mệnh lệnh cụ thể hơn, chẳng hạn như "Rõ ràng nêu rõ giả thuyết".

Cho Claude biết phải hành xử như "kỹ sư cấp cao".
Điều này không hiệu quả. Claude luôn cảm thấy mình giống như một kỹ sư cấp cao. Vấn đề thực sự không phải là về việc nó có nghĩ như vậy, mà là về việc nó thực hiện như thế nào. Quy tắc mệnh lệnh có thể làm giảm khoảng cách này, trong khi từ nhận dạng vị thế không thể.

Bản đầy đủ 12 Quy Tắc trong CLAUDE.md

Dưới đây là phiên bản đầy đủ có thể sao chép và dán trực tiếp.

Tạm thời không thể hiển thị nội dung này 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. Dưới 12 quy tắc này, thêm các quy tắc riêng của dự án, chẳng hạn như ngăn xếp công nghệ, lệnh kiểm tra, mẫu lỗi, v.v. Tổng cộng không vượt quá 200 dòng, vượt qua con số này, tỷ lệ tuân thủ quy tắc sẽ giảm rõ rệt.

Cách Cài Đặt

Chỉ cần hai bước:

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

2. Dán quy tắc 5–12 của bài viết này dưới đây

Lưu tệp trong thư mục gốc của kho của bạn. Phần >> ở đây rất quan trọng, nó giúp thêm vào CLAUDE.md hiện có mà không ghi đè lên các quy tắc dự án bạn đã viết sẵn.

Mô Hình Tâm Lý Học

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

Mỗi quy tắc nên trả lời một câu hỏi: Nó ngăn chặn lỗi gì?

4 quy tắc của Karpathy ngăn chặn các mẫu thất bại mà anh ấy thấy vào tháng 1 năm 2026: Giả định im lặng, Quá mức kỹ thuật, Phá hoại không liên quan, Tiêu chuẩn thành công yếu kém. Chúng là cơ sở, không nên bỏ qua.

8 quy tắc do tôi thêm vào ngăn chặn các mẫu thất bại mới xuất hiện sau tháng 5 năm 2026: Vòng lặp Agent không có ràng buộc ngân sách, Nhiệm vụ đa bước không có điểm kiểm tra, Kiểm thử dường như đã thử nhưng thực tế chưa kiểm tra logic chính, và Vấn đề đóng gói sự thất bại im lặng thành thành công im lặng. Chúng là các bản vá tăng dần.

Tất nhiên, hiệu quả cụ thể phụ thuộc vào từng người. Nếu bạn không chạy pipeline đa bước, quy tắc 10 không quan trọng đối với bạn. Nếu thư viện mã của bạn chỉ có một kiểu kiến trúc thống nhất và đã được lint bắt buộc, quy tắc 11 là dư thừa. Sau khi đọc xong 12 quy tắc 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ự phạm phải, và xóa phần còn lại.

Một phiên bản CLAUDE.md chỉ chứa 6 quy tắc được tùy chỉnh cho các mẫu thất bại thực tế, hơn hẳn là một phiên bản có 12 quy tắc với 6 quy tắc mà bạn sẽ chẳng bao giờ cần sử dụng.

Kết Luận

Câu tweet của Karpathy vào tháng 1 năm 2026, về cơ bản, là một sự phàn nàn. Forrest Chang đã biến nó thành 4 quy tắc. Kết quả cuối cùng, 120 nghìn nhà phát triển đã Star cho kết quả đó. Và hầu hết họ, ngày hôm nay vẫn chỉ sử dụng 4 quy tắc đó.

Mô hình đã tiến bộ, hệ sinh thái cũng đã thay đổi. Agent đa bước, kích hoạt chuỗi hook, tải kỹ năng, cộng tác đa mã nguồn - những điều này đều chưa tồn tại khi Karpathy viết tweet đó. 4 quy tắc ban đầu không giải quyết được những vấn đề này. Chúng không phải là sai, mà là chưa đầy đủ.

Thêm 8 quy tắc mới. Trải qua 6 tuần, kiểm tra trên 30 kho mã nguồn. Tỷ lệ lỗi giảm từ 41% xuống còn 3%.

Hãy đánh dấu bài viết này vào tối nay, dán 12 quy tắc này vào tệp CLAUDE.md của bạn. Nếu nó giúp bạn tiết kiệm một tuần của Claude, hãy chia sẻ.

[Link gốc]

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia