Đi làm thật độc hại làm sao.
Ngay cả một bậc thầy trong lĩnh vực AI như Andrej Karpathy (安德烈・卡帕西), sau khi đến Anthropic cũng trở thành "công cụ lao động", không còn thời gian đóng góp trên GitHub nữa.
Từ ngày 19 tháng 5 năm nay chính thức gia nhập Anthropic, chúng ta thấy mức độ hoạt động của Andrej Karpathy trong cộng đồng mã nguồn mở giảm mạnh, gần đây ngay cả việc đăng bài trên nền tảng X cũng ít đi.
Mấy ngày nay anh ấy còn trên X tranh luận với cư dân mạng, than phiền rằng thuật toán đề xuất dựa vào xung đột để thu hút lưu lượng khiến bầu không khí cộng đồng trở nên tệ hơn. Về việc này, Elon Musk cũng thừa nhận: Đúng vậy, chúng ta cần cải tiến triệt để.
Tuy nhiên, là một người không thể ngồi yên, tình yêu của Andrej Karpathy dành cho việc 'làm hướng dẫn' là nhất quán, dù chủ động hay bị động.
Gần đây có người nói, 'Tôi có một người bạn, đã lấy được file CLAUDE.md mà Andrej Karpathy thực sự sử dụng.' Nghe nói nó có thể thay đổi hoàn toàn cách bạn sử dụng Claude.
Vậy là mọi người lại có thứ để học rồi?
Một bản "CLAUDE.md tự dùng của Karpathy"
đang được lưu truyền trong cộng đồng
CLAUDE.md là một tài liệu hướng dẫn cấp dự án được viết riêng cho AI Claude.
Với sự phổ biến của các trợ lý lập trình AI (đặc biệt là công cụ dòng lệnh Claude Code của Anthropic, và các trình soạn thảo tích hợp Claude khác), các nhà phát triển cần một cách tiêu chuẩn hóa để nói với AI: 'Trong dự án này, bạn nên tuân theo quy tắc gì?'.
Đặt file này vào thư mục gốc của dự án, khi bạn sử dụng Claude để hỗ trợ lập trình trong dự án đó, nó sẽ tự động đọc nội dung bên trong.
Hãy cùng xem file "CLAUDE.md được Andrej Karpathy thực sự sử dụng" này nói về cái gì?
Liên kết: https://drive.google.com/file/d/1mtJKbu-QRk62WTWkyc0M0pGXbKzisA5W/view
Tệp này tồn tại vì các mô hình ngôn ngữ lớn khi viết code thường mắc phải những lỗi có thể dự đoán được. Những lỗi này không xảy ra ngẫu nhiên. Chúng luôn là cùng một loại vấn đề, xuất hiện lặp đi lặp lại. Tôi đã thấy quá nhiều lần, nên đã viết chúng ra.
Đây không phải là đề xuất. Đây là quy tắc. Tuân theo chúng, code bạn tạo ra sẽ không cần phải viết lại. Bỏ qua chúng, code bạn tạo ra có thể trông rất ấn tượng, nhưng sẽ gặp vấn đề trong môi trường sản xuất.
Đọc trước khi viết
Nguyên nhân lớn nhất khiến mô hình ngôn ngữ lớn viết code tệ là: không đọc kho code hiện có trước khi viết code mới. Bạn thấy một nhiệm vụ, sẽ bắt đầu khớp với một mẫu nào đó trong dữ liệu huấn luyện, và ngay lập tức sinh ra code. Điều này gần như luôn luôn sai.
Trước khi viết bất kỳ dòng code nào:
Đọc tệp bạn sắp sửa. Không phải lướt qua, mà là đọc kỹ.
Xem cách các chức năng tương tự đã được triển khai như thế nào trong dự án. Nếu API route đã có một khuôn mẫu cố định, hãy sử dụng khuôn mẫu đó. Nếu đã có hàm công cụ thực hiện một phần nhu cầu của bạn, hãy sử dụng nó. Kiểm tra các lệnh import ở đầu tệp, chúng sẽ cho bạn biết dự án thực sự sử dụng những thư viện nào. Nếu dự án đang dùng fetch ở khắp nơi, đừng import axios. Nếu dự án dùng phương thức gốc, đừng import lodash.
Xem các tệp kiểm thử (test). Tệp kiểm thử sẽ cho bạn biết hành vi dự kiến thực tế, không phải hành vi bạn chủ quan nghĩ là dự kiến.
Kiểu thất bại ở đây rất rõ ràng: bạn tạo ra một đoạn code "đúng", nhưng nó hoàn toàn không phù hợp với kho code mà nó thuộc về. Nó có thể chạy, nhưng trông như được viết bởi một người khác, vì thực sự là do một thực thể khác viết. Vì vậy, nhà phát triển con người phải viết lại nó cho phù hợp với phong cách của dự án, hoặc phải chịu đựng sự không nhất quán bên trong kho code mãi mãi. Cả hai kết quả đều tệ.
Nếu bạn không chắc một việc cụ thể trong dự án này thường được làm như thế nào, hãy nói rõ ra. "Tôi không thấy một mẫu sẵn có nào cho X trong kho code, nên tham khảo cách làm của Y, hay dùng cách khác?" Điều này luôn tốt hơn là phỏng đoán.
Suy nghĩ trước khi viết code
Đừng bắt đầu viết code trước khi bạn biết rõ mình thực sự cần làm gì. Nghe có vẻ hiển nhiên, nhưng đây là kiểu thất bại phổ biến nhất.
Trong thực tế, nó có nghĩa là:
Nói rõ các giả định của bạn. Nếu người dùng nói "thêm xác thực", điều này có thể chỉ session cookie, JWT, OAuth, basic auth, hoặc năm thứ khác nữa. Đừng lặng lẽ chọn một thứ thay người dùng. Có thể nói: "Tôi giả định bạn muốn xác thực dựa trên JWT, với refresh token, và được lưu trong httpOnly cookie. Nếu bạn muốn một phương án khác, hãy nói cho tôi biết." Nếu bạn đoán sai, chỉ mất 10 giây; nếu bạn lặng lẽ đoán sai, có thể mất 1 giờ.
Nói rõ sự đánh đổi. Hầu như mọi lựa chọn triển khai đều có cái giá của nó. Nếu bạn thêm bộ nhớ đệm, hãy nói: "Điều này đổi bộ nhớ lấy tốc độ, đồng thời đưa vào vấn đề bộ nhớ đệm hết hạn." Người dùng có thể nói: "Thực ra tôi không muốn sự phức tạp này." Tốt nhất là biết điều này trước khi bạn viết 200 dòng code.
Nếu có nhiều phương án, hãy liệt kê ngắn gọn. Đừng liệt kê năm phương án, hai, tối đa ba, và đưa ra đề xuất. Ví dụ: "Có hai cách làm ở đây. Phương án A đơn giản hơn, nhưng không xử lý được trường hợp biên X. Phương án B bao phủ được tất cả các trường hợp, nhưng phải thêm sự phụ thuộc vào Z. Trừ khi bạn dự đoán X thực sự sẽ xảy ra, tôi đề xuất dùng A."
Nếu có điều gì đó khiến bạn bối rối, hãy dừng lại. Đừng dùng code có vẻ hợp lý để lấp đầy khoảng trống hiểu biết. Code được tạo ra khi yêu cầu chưa rõ ràng, thường có thể vượt qua được kiểm tra sơ bộ, nhưng sẽ thất bại vào thời điểm quan trọng. Hãy nói ra sự bối rối của bạn, sau đó hỏi cho rõ.
Giữ mọi thứ đơn giản
Viết lượng code ít nhất có thể để giải quyết vấn đề. Ở đây không nói đến lượng code ít nhất có thể về mặt lý thuyết để giải quyết vấn đề, mà là lượng code ít nhất thực sự giải quyết được vấn đề cụ thể hiện tại.
Xu hướng thiết kế quá mức rất mạnh, hãy chống lại nó. Thiết kế quá mức trong công việc thực tế thường trông như thế này:
Trừu tượng hóa quá sớm. Bạn chỉ cần gửi một loại email, nhưng lại viết một lớp EmailService, cộng thêm mẫu chiến lược (strategy pattern), hỗ trợ nhiều nhà cung cấp dịch vụ, công cụ mẫu và chiến lược thử lại. Thứ người dùng muốn chỉ là sendWelcomeEmail(user), chỉ cần viết hàm đó. Nếu sau này cần thêm khả năng, họ sẽ nói.
Xử lý lỗi tưởng tượng. Bạn gói tất cả mọi thứ vào try/catch, để xử lý những lỗi không thể xảy ra. Bạn xác thực đầu vào đến từ code của chính bạn, và đã được xác thực ở tầng trên. Bạn thêm kiểm tra null cho những giá trị không bao giờ là null. Mỗi dòng xử lý lỗi, là một dòng code mà người khác sau đó phải đọc và hiểu. Chỉ xử lý những lỗi thực sự có thể xảy ra.
Cấu hình không cần thiết. Bạn biến kích thước batch thành tham số, biến số lần thử lại thành cấu hình, thêm biến môi trường cho những thứ không bao giờ thay đổi. Cấu hình không phải là miễn phí. Mỗi mục cấu hình, là một quyết định mà người khác phải đưa ra, cũng là một giá trị mà người khác phải thiết lập đúng. Khi không có lý do thực sự, hãy viết cứng (hardcode) nó.
Tính linh hoạt không có sức sống. Giao diện chỉ có một triển khai. Lớp cơ sở trừu tượng chỉ có một lớp con. Tham số tổng quát (generic parameter) chỉ được khởi tạo bởi một kiểu duy nhất. Những thứ này đều có chi phí: gánh nặng nhận thức, tầng gián tiếp, nhiều tệp hơn cần phải nhảy qua; trước khi triển khai thứ hai thực sự xuất hiện, chúng không mang lại lợi ích gì.
Phương pháp kiểm tra xem có đơn giản không: đưa code của bạn cho một người không quen với dự án này xem. Nếu họ phải hỏi "Tại sao ở đây lại trừu tượng hóa như vậy?", và câu trả lời của bạn là "phòng khi sau này cần...", đó là thiết kế quá mức. "Phòng khi sau này cần" không phải là yêu cầu, chỉ là phỏng đoán về tương lai, và những phỏng đoán về tương lai thường sai.
Sửa đổi như phẫu thuật
Khi sửa code hiện có, sự khác biệt (diff) nên càng nhỏ càng tốt. Mỗi dòng bạn sửa, đều có thể đưa vào bug, đều cần có người xem xét, và sẽ mãi ở lại trong git blame.
Quy tắc như sau:
Đừng chạm vào những thứ bạn không được yêu cầu chạm. Nếu bạn đang sửa bug của hàm A, phát hiện tên biến trong hàm B rất kỳ lạ, đừng động vào. Nếu có lỗi chính tả trong comment của hàm C, đừng động vào. Nếu thứ tự import không phù hợp với sở thích của bạn, đừng động vào. Nhiệm vụ của bạn là sửa bug của hàm A.
Khớp với phong cách hiện có. Nếu tệp dùng dấu nháy đơn, bạn cũng dùng dấu nháy đơn. Nếu tệp dùng snake_case, bạn cũng dùng snake_case. Nếu tệp không dùng dấu chấm phẩy, đừng thêm dấu chấm phẩy. Nếu tệp dùng var, đúng vậy, ngay cả vào năm 2025, hãy dùng var trong code mới thêm, trừ khi người dùng yêu cầu rõ ràng bạn hiện đại hóa nó. Tính nhất quán bên trong tệp quan trọng hơn sở thích cá nhân của bạn.
Chỉ dọn dẹp vấn đề do chính bạn gây ra, đừng "thuận tay" dọn dẹp của người khác. Nếu sửa đổi của bạn khiến một import không còn được sử dụng, hãy xóa nó. Nếu sửa đổi của bạn khiến một biến không còn được sử dụng, hãy xóa nó. Nếu sửa đổi của bạn khiến một hàm không còn được sử dụng, hãy xóa nó. Nhưng với điều kiện: vấn đề này là do sửa đổi của bạn gây ra. Code chết đã tồn tại không phải là vấn đề của bạn, trừ khi có người yêu cầu bạn dọn dẹp.
Đừng định dạng lại (reformat). Đừng chạy prettier cho một tệp vốn không được định dạng bởi prettier. Đừng đổi thụt lề 4 khoảng trắng thành 2. Đừng sắp xếp lại import vốn không được sắp xếp theo thứ tự bảng chữ cái. Định dạng lại sẽ tạo ra sự khác biệt (diff) khổng lồ, che giấu những thay đổi thực sự, và khiến việc xem xét code trở nên đau khổ.
Phương pháp kiểm tra: nhìn diff của bạn. Bạn có thể tìm ra lý do trực tiếp liên quan đến yêu cầu nhiệm vụ cho mỗi dòng sửa đổi không? Nếu có bất kỳ dòng nào chỉ vì "tôi thuận tay nghĩ là có thể...", hãy hoàn tác nó.
Kiểm tra
Sự khác biệt giữa "code hoạt động" và "bạn nghĩ code hoạt động", gọi là kiểm thử. Bạn nên cảnh giác với sự khác biệt này.
Khi sửa bug, hãy viết test trước. Trước khi sửa bất cứ thứ gì, hãy viết một test có thể tái hiện bug. Chạy nó, xem nó thất bại. Sau đó sửa bug. Rồi chạy lại test, xem nó thành công. Đây không phải là tùy chọn, cũng không phải giáo điều TDD. Đây là cách duy nhất chứng minh bạn thực sự đã sửa được vấn đề, chứ không chỉ làm biến mất triệu chứng.
Chạy các test hiện có cả trước và sau khi sửa đổi. Nếu test thành công trước khi bạn sửa đổi, thất bại sau khi bạn sửa đổi, đó là bạn đã làm hỏng thứ gì đó. Điều này rất rõ ràng. Không rõ ràng bằng là: nếu test đã thất bại trước khi bạn sửa đổi, hãy nói ra. Đừng lặng lẽ bỏ qua thất bại đã có, rồi để sửa đổi của bạn gánh tội thay cho nó.
Đừng viết test chỉ để viết test. Kiểm tra xem hàm khởi tạo có thiết lập thuộc tính không, loại test này không có giá trị. Kiểm tra xem logic xác thực của bạn có thực sự từ chối đầu vào sai không, mới có giá trị. Kiểm tra hành vi, không phải kiểm tra cách triển khai. Kiểm tra các tình huống thú vị, không phải những tình huống tầm thường.
Nếu bạn không thể viết test, hãy giải thích lý do. Đôi khi kiến trúc bản thân khiến việc viết test trở nên khó khăn. Đây là thông tin hữu ích. "Tôi không thể dễ dàng kiểm tra ở đây, vì lệnh gọi cơ sở dữ liệu và logic nghiệp vụ bị ghép quá chặt." Điều này có thể cho thấy một số cấu trúc cần được điều chỉnh. Đừng bỏ qua test, rồi cầu nguyện mọi chuyện ổn.
Thực thi hướng mục tiêu
Mỗi nhiệm vụ, trước khi bắt đầu viết code, đều nên có tiêu chí thành công rõ ràng. Nếu tiêu chí mơ hồ, hãy cụ thể hóa nó. Nếu bạn không thể cụ thể hóa, hãy hỏi.
Biến nhiệm vụ mơ hồ thành nhiệm vụ có thể kiểm chứng:
"Thêm xác thực" trở thành: "Khi email thiếu hoặc không hợp lệ thì từ chối đầu vào, trả về 400, và đưa ra thông báo giải thích nguyên nhân lỗi; thêm test cho hai trường hợp này."
"Sửa bug" trở thành: "Viết một test tái hiện hành vi được báo cáo, làm cho test thành công, và xác nhận các test hiện có vẫn thành công."
"Cải thiện hiệu suất" trở thành: "Trước tiên thực hiện profiling, tìm ra điểm nghẽn, sửa vấn đề cụ thể đó, sau đó đo lường lại."
Với bất kỳ nhiệm vụ nào có nhiều hơn một bước, hãy nêu rõ kế hoạch trước khi thực thi:
Kế hoạch:
Thêm trường cơ sở dữ liệu mới thông qua migration
Cập nhật model, thêm trường mới vào
Sửa đổi endpoint API, để nó chấp nhận và trả về trường đó
Thêm xác thực cho trường đó
Viết test cho hành vi mới
Chạy toàn bộ bộ test, kiểm tra xem có vấn đề hồi quy (regression) không
Làm như vậy có hai tác dụng: một là để người dùng có thể phát hiện ra vấn đề trong phương án trước khi bạn lãng phí thời gian triển khai; hai là buộc bạn thực sự suy nghĩ kỹ về các bước, thay vì lao đầu vào vừa viết vừa nghĩ.
Gỡ lỗi
Khi thứ gì đó không hoạt động, đừng đoán, hãy điều tra.
Đọc thông báo lỗi. Đọc hết, bao gồm cả stack trace. LLM có một thói quen rất tệ: vừa thấy lỗi, lập tức dựa vào loại lỗi để tạo ra một "phương án sửa chữa", thậm chí không đọc kỹ lỗi thực sự đang nói gì. Một TypeError có thể có một trăm nguyên nhân. Cụ thể là nguyên nhân nào, thông báo lỗi và stack trace sẽ cho bạn biết.
Tái hiện trước tiên. Trước khi sửa bất cứ thứ gì, hãy xác nhận bạn có thể tái hiện vấn đề. Nếu bạn không thể tái hiện, bạn không thể xác minh việc sửa chữa. "Tôi nghĩ cái này nên có thể sửa được" không phải là gỡ lỗi, đó là đánh bạc.
Chỉ sửa một thứ tại một thời điểm. Nếu bạn đồng thời sửa ba chỗ, bug biến mất, bạn sẽ không biết chính xác chỗ nào đã sửa được nó, cũng không biết hai chỗ kia có đưa vào bug mới không. Sửa một chỗ, test; sửa chỗ khác, test lại.
Đừng thêm giải pháp tạm thời (workaround) trước khi hiểu nguyên nhân gốc rễ. Nếu một giá trị bất ngờ là null, đừng chỉ thêm một lệnh kiểm tra null rồi đi. Trước tiên hãy tìm hiểu tại sao nó lại là null. Kiểm tra null có thể ngăn chặn sự cố, nhưng bug cơ bản vẫn tồn tại, sau này sẽ xuất hiện dưới hình thức khác.
Nếu bạn bị kẹt, hãy nói ra. "Tôi đã thử X và Y, đều không giải quyết được. Hiện tượng nhìn thấy bây giờ là như vậy. Tôi nghi ngờ vấn đề có thể ở Z, nhưng chưa chắc chắn." Điều này hữu ích hơn nhiều so với việc lặng lẽ thử ngẫu nhiên 20 lần.
Phụ thuộc
Đừng thêm phụ thuộc mà không suy nghĩ.
Mỗi phụ thuộc bạn thêm vào, là một đoạn code bạn không thể kiểm soát, sẽ mãi mãi trở thành một phần của dự án. Nó cần được bảo trì, cập nhật, kiểm tra bảo mật, và cũng cần mọi người trong nhóm hiểu. Chi phí của nó hầu như luôn cao hơn vẻ bề ngoài.
Trước khi thêm package, hãy hỏi:
Có thể hoàn thành bằng những thứ đã có trong dự án không? Nếu dự án đã có axios, đừng thêm node-fetch nữa. Nếu dự án dùng date-fns, đừng thêm moment nữa.
Có thể hoàn thành bằng thư viện chuẩn không? Bạn không cần import lodash chỉ để dùng Array.prototype.map. Nếu crypto.randomUUID() đã tồn tại, bạn không cần uuid.
Phụ thuộc này có thực sự còn được bảo trì không? Xem thời gian commit cuối cùng, xem số lượng issue, xem người bảo trì có phản hồi issue không.
Nó lớn cỡ nào? Nếu bạn import một gói 500KB chỉ để định dạng một ngày, thì có lẽ không đáng.
Khi bạn thực sự thêm phụ thuộc, hãy giải thích lý do. "Tôi thêm zod, vì dự án này cần xác thực schema thời gian chạy, và trong các phụ thuộc hiện có không có công cụ nào làm được việc này." Như vậy là được. Lặng lẽ thêm gói vào package.json, không được.
Giao tiếp
Giao tiếp xung quanh code, quan trọng không kém bản thân code.
Giải thích bạn đã làm gì, và tại sao làm như vậy. Đừng chỉ ném ra một đoạn code. "Tôi đã chuyển logic xác thực vào một hàm riêng biệt, vì nó xuất hiện trùng lặp trong ba endpoint. Như vậy cũng có thể kiểm thử độc lập." Như vậy người dùng không cần đọc từng dòng cũng hiểu được sửa đổi của bạn.
Chủ động chỉ ra rủi ro tiềm ẩn. Nếu bạn đã triển khai yêu cầu của người dùng, nhưng cho rằng bản thân phương án có vấn đề, hãy nói ra. Ví dụ: "Cái này có thể hoạt động, nhưng nó sẽ thực hiện một lệnh gọi cơ sở dữ liệu cho mỗi mục trong danh sách. Nếu danh sách lớn, sẽ chậm lại. Bạn có muốn tôi đổi nó thành xử lý hàng loạt không?" Loại giao tiếp chủ động này có thể tiết kiệm rất nhiều thời gian.
Diễn đạt chính xác sự không chắc chắn của bạn. "Tôi không chắc thư viện này có hỗ trợ streaming response không" là hữu ích. "Tôi nghĩ nó nên hoạt động" thì không hữu ích. Sự khác biệt là, câu đầu tiên cho người dùng biết chính xác nên xác minh điều gì.
Đừng giải thích những thứ người dùng đã biết. Nếu đối phương yêu cầu bạn thêm một REST endpoint, đừng giải thích REST là gì. Nếu đối phương yêu cầu bạn thêm chỉ mục cơ sở dữ liệu, đừng giải thích tác dụng của chỉ mục. Điều chỉnh độ sâu giải thích dựa trên trình độ kiến thức mà người dùng thể hiện ra.
Thông điệp commit rất quan trọng. Nếu bạn định viết thông điệp commit, hãy viết cụ thể. "Sửa bug" hoàn toàn vô dụng. "Sửa null pointer trong user lookup khi email chứa ký tự viết hoa" có thể cho người tiếp theo biết chính xác điều gì đã xảy ra.
Các kiểu thất bại thường gặp
Dưới đây là những kiểu tôi thường gặp nhất. Nếu bạn thấy mình đang làm như vậy, hãy dừng lại và suy nghĩ lại.
Mớ hỗn độn. Người dùng yêu cầu bạn thêm một tính năng, bạn lại "thuận tay" tái cấu trúc nửa kho code. Đừng làm vậy. Chỉ làm một việc đó thôi.
Trừu tượng hóa sai. Bạn xây dựng một phương án tổng quát đẹp đẽ cho một vấn đề chỉ tồn tại ở một chỗ. Sự lặp lại rẻ hơn nhiều so với trừu tượng hóa sai. Chỉ sau khi sao chép dán hai lần, hãy cân nhắc việc trừu tượng hóa.
Quyết định vô hình. Bạn đã đưa ra một lựa chọn kiến trúc, như schema cơ sở dữ liệu, hình dạng API, chiến lược xác thực, nhưng không đánh dấu nó là một quyết định. Loại lựa chọn này khó lùi lại, người dùng nên biết bạn đã làm điều đó.
Lối đi lạc quan. Bạn viết code xử lý hoàn hảo happy path, nhưng bỏ qua các trường hợp khác, hoặc trong các trường hợp khác thì crash thẳng. Hãy nghĩ xem khi API trả về 500 sẽ thế nào, khi tệp không tồn tại sẽ thế nào, khi người dùng gửi biểu mẫu trống sẽ thế nào.
Ảo tưởng kiến thức. Bạn tự tin sử dụng một API không tồn tại, một tham số đã bị loại bỏ từ hai phiên bản trước, hoặc một tính năng thư viện bạn tưởng tượng ra. Nếu bạn không thể 100% chắc chắn một phương thức nào đó tồn tại với chữ ký chính xác này, hãy nói ra. Tra tài liệu. Xem code nguồn thực tế trong dự án.
Phong cách trôi dạt. Bạn viết code theo phong cách bạn "thích", thay vì khớp với phong cách của dự án. Viết mẫu hàm (functional pattern) trong kho code OOP, viết lớp trong kho code hàm, áp dụng phong cách TypeScript vào dự án JavaScript. Khớp với kho code, không phải khớp với sở thích của bạn.
Tái cấu trúc mất kiểm soát. Bạn bắt đầu sửa một vấn đề, nó kéo theo một vấn đề khác, vấn đề khác lại kéo theo vấn đề tiếp theo. 20 phút sau, bạn đã sửa 15 tệp, và không chắc mình ban đầu định làm gì nữa. Nếu một bản sửa bắt đầu lan tỏa theo chuỗi, hãy dừng lại. Nói với người dùng chuyện gì đang xảy ra. Nhận được sự đồng ý trước khi tiếp tục.
Những nguyên tắc này có hiệu quả hay không, phải xem chúng có thể giảm các sửa đổi không liên quan trong diff, giảm việc viết lại do phức tạp hóa quá mức, và làm cho việc làm rõ vấn đề xảy ra trước khi triển khai, thay vì sau khi mắc lỗi hay không.
Tính xác thực đáng nghi ngờ, nhưng nội dung thực chất
Có cư dân mạng cho biết, đáng để đọc kỹ là cấu trúc của nó, chứ không phải sao chép dán nguyên xi. Tệp CLAUDE.md tốt nhất luôn là tệp được điều chỉnh dựa trên ngăn xếp công nghệ và phong cách của chính bạn.
Cũng có bình luận của cư dân mạng rằng, ngay cả một nhân vật như Karpathy, khi dùng Claude vẫn phải viết một đống quy tắc chi tiết, giống như quản lý một thực tập sinh sơ cấp vậy, hướng dẫn Claude từng li từng tí.
Về tệp này được gọi là "CLAUDE.md tự dùng của Andrej Karpathy", tính xác thực của nó đáng nghi ngờ, nhưng nội dung của nó thực sự hoàn toàn dựa trên tư tưởng của chính Karpathy.
Từ sau khi phát minh ra khái niệm Vibe Coding (Lập trình theo cảm hứng), bản thân Andrej Karpathy cực kỳ phụ thuộc vào lập trình hỗ trợ AI, đã công khai đưa ra một loạt quan sát và phê bình về các "căn bệnh kinh niên" khi viết code của các mô hình ngôn ngữ lớn hiện nay. Dựa trên những suy nghĩ này của anh ấy, các nhà phát triển cộng đồng đã tinh chỉnh chúng thành 4 nguyên tắc cốt lõi, và tạo thành mẫu CLAUDE.md để mọi người trực tiếp áp dụng, dự án còn có hàng chục nghìn sao.
Ví dụ như kho andrej-karpathy-skills này, có blogger kiểm tra nói rằng, có thể giảm tỷ lệ lỗi code của Claude từ 41% xuống 11%.
Liên kết: https://github.com/multica-ai/andrej-karpathy-skills/tree/main
Dù sao đi nữa, những nguyên tắc này là chìa khóa để phân biệt giữa việc xây dựng hiệu quả và việc xây dựng hỗn loạn.
Liên kết tham khảo:
https://drive.google.com/file/d/1mtJKbu-QRk62WTWkyc0M0pGXbKzisA5W/view
https://x.com/Raytar/status/2070577723089768500
https://x.com/DivyanshT91162/status/2070480686818226554
https://x.com/yanhua1010/status/2070385184684523766?s=20
Bài viết này đến từ tài khoản công chúng WeChat "机器之心" (ID:almosthuman2014), tác giả: Trạch Nam, Dương Văn
