原文标题：Karpathy’s 4 CLAUDE.md rules cut Claude mistakes from 41% to 11%. After 30 codebases, I added 8 more
原文作者：@Mnilax
编译：Peggy，BlockBeats

Biên tập viên lưu ý: Tháng 1 năm 2026, Andrej Karpathy đã phàn nàn về cách Claude viết mã, dẫn đến một tài liệu 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 đó đã tổng hợp các vấn đề này thành 4 quy tắc hành vi, nhằm hạn chế các lỗi phổ biến của Claude khi lập trình: giả định âm thầm, quá mức phức tạp, gây hại cho mã không liên quan, và thiếu tiêu chuẩn thành công rõ ràng.

Nhưng sau vài tháng, các tình huống sử dụng 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 đa bước, chuỗi hook kích hoạt theo chuỗi, tải skill và hợp tác nhiều kho mã trở thành bình thường, các mô hình thất bại mới bắt đầu xuất hiện: mô hình mất kiểm soát trong nhiệm vụ dài, vượt qua kiểm thử nhưng không xác minh logic thực, bỏ qua lỗi một cách âm thầm sau khi chuyển đổi, và trộn lẫn phong cách mã sai lệch.

Tác giả đã thử nghiệm 30 kho mã trong vòng 6 tuần, và dựa trên 4 quy tắc ban đầu của Karpathy, đã thêm 8 quy tắc nữa để bao phủ các vấn đề mới phát sinh khi lập trình AI chuyển từ hoàn thiện đơn lẻ sang hợp tác theo nhóm.

Dưới đây là nguyên bản:

Về cuối tháng 1 năm 2026, Andrej Karpathy đã đăng một chuỗi tweet phàn nàn về cách Claude viết mã. Ông chỉ ra ba loại vấn đề điển hình: giả định sai mà không giải thích, quá mức phức tạp, và gây hại cho mã không liên quan vốn không nên thay đổi.

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

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

4 quy tắc này thực sự hiệu quả. Các lỗi từng xuất hiện với xác suất khoảng 40%, trong các nhiệm vụ phù hợp, đã giảm xuống dưới 3%. Nhưng vấn đề là, mẫu này ban đầu được thiết kế để giải quyết các lỗi xuất hiện khi Claude viết mã tháng 1.

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

Vì vậy, tôi đã thêm 8 quy tắc nữa. Dưới đây là phiên bản đầy đủ gồm 12 quy tắc của CLAUDE.md: lý do mỗi quy tắc đáng để có mặt, và nơi nguyên mẫu của Karpathy có thể âm thầm thất bại trong 4 điểm.

Nếu bạn muốn bỏ qua phần giải thích, sao chép trực tiếp, tệp đầy đủ ở cuối bài.

Tại sao điều này 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 kỹ thuật lập trình AI. Hầu hết các nhà phát triển thường mắc ba loại lỗi:

Thứ nhất, coi nó như thùng rác sở thích, bỏ tất cả thói quen vào, cuối cùng mở rộng lên hơn 4000 tokens, tỷ lệ tuân thủ quy tắc giảm còn 30%.

Thứ hai, hoàn toàn không dùng, mỗi lần lại prompt lại từ đầu. Điều này gây lãng phí token gấp 5 lần, và giữa các phiên không nhất quán.

Thứ ba, 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 theo thời gian kho mã thay đổi, sẽ vô tình mất hiệu lực.

Tài liệu chính thức của Anthropic nói rõ: CLAUDE.md về bản chất chỉ mang tính gợi ý. Claude khoảng 80% thời gian sẽ tuân theo. Khi vượt quá 200 dòng, tỷ lệ tuân thủ rõ ràng giảm, vì các quy tắc quan trọng bị nhiễu bởi nhiễu loạ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. Đây là mức tối thiểu.

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

4 quy tắc ban đầu

Nếu bạn chưa xem kho của Forrest Chang, hãy bắt đầu với phiên bản cơ bản này:

Quy tắc 1: Trước khi mã hóa, hãy suy nghĩ.

Đừng làm giả định âm thầm. Phải giải thích giả định của bạn, phơi bày các cân nhắc. Trước khi đoán, hãy hỏi. Khi có giải pháp đơn giản hơn, hãy chủ động phản đối.

Quy tắc 2: Ưu tiên đơn giản.
Dùng ít mã nhất có thể để giải quyết vấn đề. Đừng thêm chức năng tưởng tượng. Đừng thiết kế trừu tượng cho mã dùng một lần. Nếu một kỹ sư dày dạn nghĩ nó quá phức tạp, hãy đơn giản hóa.

Quy tắc 3: Sửa chữa theo kiểu phẫu thuật.
Chỉ sửa phần cần sửa. Đừng tiện tay “tối ưu” mã lân cận, chú thích hoặc định dạng. Đừng tái cấu trúc những phần chưa hỏng. Giữ phong cách phù hợp hiện có.

Quy tắc 4: Hành động hướng mục tiêu.
Đầu tiên, xác định tiêu chuẩn thành công, rồi lặp lại cho đến khi xác minh xong. Đừng nói cho Claude từng bước phải làm gì, mà hãy nói rõ kết quả thành công trông như thế nào, để nó tự lặp lại.

4 quy tắc này có thể giải quyết khoảng 40% các mô hình thất bại trong phiên Claude không giám sát. Phần còn lại, khoảng 60%, nằm trong các vùng trống dưới đây.

Tôi đã thêm 8 quy tắc nữa, và lý do

Mỗi quy tắc đều xuất phát từ một thời điểm thực tế: 4 quy tắc ban đầu của Karpathy đã không còn đủ nữa. Dưới đây tôi sẽ trình bày bối cảnh, rồi đưa ra quy tắc tương ứng.

Quy tắc 5: Đừng để mô hình làm việc phi ngôn ngữ

Có thể dùng Claude để: phân loại, phác 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 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 trạng thái mã đã trả lời câu hỏi, hãy để mã thông thường xử lý.

Quy tắc của Karpathy chưa bao gồm điểm này. Vì vậy, mô hình bắt đầu tự quyết định các vấn đề vốn thuộc về mã xác định: có nên thử API lần nữa, cách định tuyến một tin nhắn, khi nâng cấp xử lý. Kết quả là, mỗi lần đánh giá đều khác nhau. Bạn nhận được một dạng if-else không ổn định, tính phí theo token 0.003 USD.

Thời điểm đó là như thế này: có đoạn mã gọi Claude để “đánh giá xem có nên thử lại khi gặp 503 không”. Ban đầu chạy rất tốt, duy trì hai tuần, rồi đột nhiên trở nên không ổn định, vì mô hình bắt đầu xem cả thân yêu cầu như phần ngữ cảnh đánh giá. Chiến lược thử lại trở nên ngẫu nhiên, vì prompt cũng ngẫu nhiên.

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

Ngân sách nhiệm vụ: 4.000 tokens. Ngân sách phiên: 30.000 tokens. Nếu gần đến giới hạn, hãy tóm tắt trạng thái hiện tại rồi bắt đầu lại. Đừng cố gắng tiếp tục. Rõ ràng thể hiện vượt ngân sách còn tốt hơn là âm thầm vượt.

Không có giới hạn ngân sách, CLAUDE.md như một tấm séc trống. Mỗi vòng lặp có thể mất kiểm soát, thành một đợt đổ đầy ngữ cảnh 50.000 tokens. Mô hình sẽ không tự dừng lại.

Thời điểm đó là như thế này: một phiên debug kéo dài 90 phút. Mô hình liên tục lặp lại trên cùng một đoạn lỗi 8KB, dần quên các sửa đổi đã thử. Đến cuối, nó đề xuất 40 phương án tôi đã phủ nhận trước đó. Nếu có giới hạn token, quá trình này nên dừng lại ở phút thứ 12.

Quy tắc 7: Phơi bày xung đột, không trung hòa

Nếu hai chế độ trong kho mã mâu thuẫn, đừng trộn lẫn. Chọn một chế độ, ưu tiên chế độ mới hơn hoặc đã thử nghiệm nhiều hơn, giải thích lý do, và đánh dấu chế độ còn lại cần làm sạch sau này. “Mã trung bình” cố gắng thỏa mãn cả hai quy tắc là mã tồi nhất.

Khi hai phần của kho mã mâu thuẫn, Claude sẽ cố gắng chiều lòng cả hai, kết quả là ra mã rối rắm không nhất quán.

Thời điểm đó là như thế này: trong một kho mã có hai chế độ xử lý lỗi: một là async/await với try/catch rõ ràng, hai là lỗi toàn cục. Claude viết mã mới vừa dùng cả hai, dẫn đến xử lý lỗi bị lặp lại hai lần. Tôi mất 30 phút để hiểu tại sao lỗi bị nuốt hai lần.

Quy tắc 8: Đọc rồi mới viết

Trước khi thêm mã mới vào một tệp, hãy đọc phần xuất khẩu của tệp đó, các hàm gọi trực tiếp, và bất kỳ công cụ chia sẻ nào rõ ràng liên quan. Nếu không hiểu cách tổ chức mã hiện tại, hãy hỏi trước, đừng thêm tùy ý. “Theo tôi là không liên quan” là câu nguy hiểm nhất trong kho mã này.

「Phẫu thuật cắt bỏ」 của Karpathy dặn Claude không sửa đổi mã lân cận. Nhưng nó không dặn: hãy hiểu mã lân cận trước. Không có bước này, Claude sẽ viết mã mâu thuẫn với mã đã có cách đây 30 dòng.

Thời điểm đó là như thế này: Claude thêm một hàm mới hoàn toàn giống hàm cũ bên cạnh, vì không đọc kỹ hàm cũ. Hai hàm làm cùng một việc, nhưng do thứ tự import, hàm mới ghi đè hàm cũ, vốn đã là chuẩn mực trong 6 tháng.

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

Mỗi kiểm thử phải giải thích “tại sao hành vi này quan trọng”, chứ không chỉ “nó đã làm gì”. Expect(getUserName()).toBe(‘John’) vô giá trị nếu hàm này nhận ID cố định. Nếu không viết được kiểm thử thất bại khi logic thay đổi, hàm đó sai.

“Thực thi hướng mục tiêu” của Karpathy cho phép dùng kiểm thử làm tiêu chuẩn thành công. Nhưng trong thực tế, Claude thường xem “đạt yêu cầu” là mục tiêu duy nhất, dẫn đến viết mã qua mặt kiểm thử nông cạn nhưng phá vỡ các phần khác.

Thời điểm đó là như thế này: Claude viết 12 kiểm thử cho một hàm xác thực, tất cả qua. Nhưng logic xác thực trong môi trường thực lại hỏng. Các kiểm thử chỉ kiểm tra hàm “trả về thứ gì đó”, chứ không xác minh đúng đắn. Hàm qua kiểm thử vì trả về hằng số.

Quy tắc 10: Các thao tác dài hạn cần checkpoint

Trong nhiệm vụ đa bước, sau mỗi bước, hãy tóm tắt đã làm gì, đã xác minh gì, còn lại gì. Đừng tiếp tục từ trạng thái bạn không thể tóm tắt rõ ràng. Nếu lạc lối, hãy dừng lại, trình bày lại trạng thái hiện tại.

Mẫu của Karpathy giả định tương tác một lần. Nhưng thực tế, Claude Code thường là nhiều bước: tái cấu trúc 20 tệp, xây dựng chức năng trong một phiên, debug qua nhiều commit. Nếu không có checkpoint, một bước sai có thể làm mất tất cả tiến trình trước đó.

Thời điểm đó là như thế nà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, Claude đã tiếp tục hoàn thành bước 5 và 6 dựa trên lỗi đó. Việc sửa chữa mất nhiều thời gian hơn làm lại toàn bộ nhiệm vụ. Nếu có checkpoint, lỗi sẽ được phát hiện ngay ở bước 4.

Quy tắc 11: Ưu tiên quy ước hơn sáng tạo

Nếu kho mã dùng snake_case, còn bạn thích camelCase: hãy dùng snake_case. Nếu kho dùng class-based components, còn bạn thích hooks: hãy dùng class-based. Ý kiến khác là một cuộc thảo luận khác. Trong kho, nhất quán quan trọng hơn sở thích cá nhân. Nếu bạn nghĩ quy ước nào đó có hại, hãy đề xuất rõ ràng. Đừng âm thầm tạo nhánh.

Trong kho đã có quy tắc rõ ràng, Claude thích tự đưa ra cách viết của riêng mình. Dù cách đó “tốt hơn”, việc thêm một chế độ nữa đã là điều tồi tệ hơn so với duy trì một quy tắc duy nhất.

Thời điểm đó là như thế này: Claude trong một kho React dựa trên class component, đã dùng hooks. Nó chạy được, nhưng phá vỡ các kiểm thử cũ dựa trên componentDidMount. Mất nửa ngày để xóa và viết lại.

Quy tắc 12: Phải rõ ràng thất bại, không âm thầm

Nếu không chắc chắn điều gì đã thành công, hãy rõ ràng. Nếu có 30 bản ghi bị bỏ qua âm thầm, không thể nói “hoàn tất chuyển đổi”. Nếu bỏ qua kiểm thử, không thể nói “kiểm thử thành công”. Nếu không xác minh các biên giới, không thể nói “chức năng hoạt động”. Luôn rõ ràng về sự không chắc chắn, đừng che giấu.

Các thất bại đắt nhất của Claude thường là những thất bại tưởng như thành công. Một hàm “chạy được” nhưng trả dữ liệu sai; một migration “hoàn tất” nhưng bỏ qua 30 bản ghi gây lỗi; một kiểm thử “đạt” nhưng chỉ vì sai lệch trong câu lệnh kiểm tra.

Thời điểm đó là như thế này: Claude nói một lần di chuyển database “hoàn tất”. Nhưng thực tế, nó âm thầm bỏ qua 14% bản ghi gây lỗi ràng buộc. Hành vi bỏ qua này ghi trong nhật ký nhưng không rõ ràng. 11 ngày sau, khi báo cáo dữ liệu bắt đầu bất thường, mới phát hiện ra vấn đề.

Kết quả dữ liệu

Trong 6 tuần, tôi theo dõi cùng một nhóm 50 nhiệm vụ tiêu biểu, bao phủ 30 kho mã, thử ba cấu hình khác nhau.

Tỷ lệ lỗi là: nhiệm vụ cần chỉnh sửa hoặc viết lại để phù hợp với ý định ban đầu. Bao gồm các lỗi: giả định sai âm thầm, quá mức phức tạp, gây hại không liên quan, thất bại âm thầm, vi phạm quy ước, xung đột trung hòa, bỏ qua checkpoint.

Tỷ lệ tuân thủ là: xác suất Claude rõ ràng áp dụng quy tắc khi phù hợp.

Kết quả thực sự thú vị không chỉ là lỗi giảm từ 41% xuống còn 3%. Quan trọng hơn, khi mở rộng từ 4 quy tắc lên 12, tỷ lệ tuân thủ chỉ giảm từ 78% xuống còn 76%, nhưng lỗi giảm 8 điểm phần trăm. Các quy tắc mới bao phủ các mô hình thất bại mà 4 quy tắc ban đầu không xử lý, không cạnh tranh chung về ngân sách chú ý.

Karpathy sẽ âm thầm thất bại ở những điểm nào

Ngay cả khi không thêm quy tắc mới, mẫu 4 quy tắc ban đầu của Karpathy ít nhất cũng không đủ ở 4 điểm sau:

Thứ nhất, nhiệm vụ tác nhân dài hạn.
Quy tắc của Karpathy chủ yếu nhắm vào lúc Claude viết mã. Nhưng khi Claude chạy một pipeline đa bước, chuyện gì xảy ra? Mẫu ban đầu không có quy tắc ngân sách, checkpoint, hay “thất bại rõ ràng”. Kết quả là, pipeline dần lệch hướng.

Thứ hai, nhất quán giữa nhiều kho mã.
“Phù hợp phong cách hiện có” chỉ có một phong cách. Nhưng trong một monorepo có 12 dịch vụ, Claude phải chọn phù hợp phong cách nào. Quy tắc ban đầu không hướng dẫn cách chọn. Nó có thể chọn ngẫu nhiên hoặc pha trộn các phong cách.

Thứ ba, chất lượng kiểm thử.
“Hành động hướng mục tiêu” xem “đạt” là thành công, nhưng không rõ kiểm thử phải có ý nghĩa gì. Kết quả là, Claude viết ra các kiểm thử gần như không xác minh gì, nhưng vẫn nghĩ là đã kiểm thử tốt.

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

Các quy tắc mới này không nhằm thay thế 4 quy tắc ban đầu của Karpathy, mà để sửa các chỗ còn thiếu: mẫu ban đầu phù hợp với cảnh viết mã tự động hoàn chỉnh tháng 1 năm 2026; còn tháng 5 năm 2026, Claude Code đã vào môi trường hợp tác đa bước, nhiều kho, các vấn đề khác nhau.

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

Trước khi xác định chính thức 12 quy tắc này, tôi đã thử một số phương án khác.

Thêm các quy tắc tôi thấy trên Reddit / X.
Hầu hết chỉ là cách diễn đạt khác của 4 quy tắc ban đầu của Karpathy, hoặc các quy tắc đặc thù không thể tổng quát như “luôn dùng Tailwind class”. Cuối cùng đều bỏ đi.

Hơn 12 quy tắc.
Tối đa tôi thử tới 18 quy tắc. Khi vượt 14, 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 giới hạn này, Claude bắt đầu ghép mẫu thành “có quy tắc” chứ không đọc từng quy tắc.

Dựa vào các công cụ nhất định.
Ví dụ “luôn dùng eslint”. Nếu dự án không cài eslint, quy tắc này vô hiệu, âm thầm vô hiệu. Sau đó tôi đổi thành “tuân theo phong cách đã được thực thi trong kho”, không phụ thuộc công cụ.

Đặt ví dụ trong CLAUDE.md thay vì quy tắc.
Ví dụ chiếm nhiều ngữ cảnh hơn quy tắc. Ba ví dụ tiêu tốn khoảng 10 quy tắc, và Claude dễ bị quá khớp với ví dụ. Quy tắc trừu tượng, ví dụ cụ thể. Nên dùng quy tắc.

“Chú ý hơn”, “suy nghĩ cẩn thận”, “tập trung hơn”.
Chỉ là nhiễu loạn. Các lệnh này tỷ lệ tuân thủ khoảng 30% vì không thể kiểm chứng. Sau đó tôi thay bằng lệnh rõ ràng hơn, như “giải thích giả định rõ ràng”.

Nói Claude phải như “kỹ sư dày dạn”.
Không có tác dụng. Claude đã nghĩ mình như vậy rồi. Vấn đề không phải nó có nghĩ thế không, mà là nó thực thi thế nào. Quy tắc mệnh lệnh có thể thu hẹp khoảng cách này, còn nhắc nhở về danh tính thì không.

Phiên bản đầy đủ 12 quy tắc của CLAUDE.md

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

Chưa thể hiển thị ngoài tài liệu Feishu này

Lưu nó vào thư mục gốc của kho, tên là CLAUDE.md. Dưới 12 quy tắc này, thêm các quy tắc riêng dự án như công nghệ, lệnh kiểm thử, lỗi thường gặp. Tổng không quá 200 dòng, quá dài sẽ làm giảm tỷ lệ tuân thủ.

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 CLAUDE.md của bạn
   curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md

2. Dán các quy tắc 5–12 từ bài này vào phía dưới

Lưu tệp vào thư mục gốc. Dấu “>>” này rất quan trọng, nó giúp thêm vào nội dung hiện có, không ghi đè quy tắc riêng của dự án.

Mô hình tư duy

CLAUDE.md không phải danh sách mong muốn, mà là cam kết hành vi để chặn các mô hình thất bại đã quan sát.

Mỗi quy tắc phải trả lời câu hỏi: nó có thể ngăn lỗi gì?

4 quy tắc của Karpathy, ngăn các thất bại tháng 1 năm 2026: giả định âm thầm, quá mức phức tạp, gây hại không liên quan, tiêu chuẩn thành công mỏng manh. Đây là nền tảng, đừng bỏ qua.

8 quy tắc bổ sung của tôi, ngăn các thất bại mới sau tháng 5 năm 2026: vòng lặp không giới hạn, nhiệm vụ đa bước không checkpoint, kiểm thử không đúng, và vấn đề âm thầm thành công. Chúng là các bản vá bổ sung.

Tất nhiên, hiệu quả cụ thể tùy người. Nếu bạn không chạy pipeline đa bước, quy tắc 10 không quan trọng lắm. Nếu kho mã chỉ có một phong cách, đã được lint bắt buộc, quy tắc 11 là thừa. Sau khi đọc 12 quy tắc này, giữ lại những quy tắc phù hợp với lỗi bạn từng mắc, bỏ phần còn lại.

Một phiên bản 6 quy tắc của CLAUDE.md phù hợp với thất bại thực tế sẽ tốt hơn một bản 12 quy tắc mà 6 quy tắc bạn không dùng.

Kết luận

Tweet của Karpathy tháng 1 năm 2026 thực chất 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 đã ấn nút sao cho kết quả này. Và phần lớn trong số đó vẫn chỉ dùng 4 quy tắc ban đầu.

Mô hình đã tiến bộ, hệ sinh thái đã thay đổi. Tác nhân đa bước, hook kích hoạt theo chuỗi, tải skill, hợp tác nhiều kho — tất cả đều chưa tồn tại khi Karpathy viết tweet đó. Các quy tắc ban đầu không giải quyết được các vấn đề này. Chúng không sai, mà là chưa đủ.

Thêm 8 quy tắc. 6 tuần, thử 30 kho mã. Lỗi giảm từ 41% xuống còn 3%.

Hôm nay, hãy lưu bài này, dán 12 quy tắc vào CLAUDE.md của bạn. Nếu giúp bạn tránh mất một tuần lạc lối, hãy chia sẻ lại.

[Link nguyên bản]

Tìm hiểu về tuyển dụng của BlockBeats tại các vị trí tuyển dụng

Tham gia cộng đồng chính thức của BlockBeats:

Telegram: https://t.me/theblockbeats

Telegram nhóm: https://t.me/BlockBeats_App

Twitter chính thức: https://twitter.com/BlockBeatsAsia