Các nguyên tắc hành vi nhằm giảm thiểu những lỗi lập trình thường gặp của LLM. Sử dụng khi viết, đánh giá hoặc tái cấu trúc (refactor) mã nguồn để tránh làm phức tạp hóa quá mức, thực hiện các thay đổi chính xác như phẫu thuật, làm rõ các giả định và xác định tiêu chí thành công có thể kiểm chứng được.
---
name: karpathy-guidelines
description: Các nguyên tắc hành vi nhằm giảm thiểu những lỗi lập trình thường gặp của LLM. Sử dụng khi viết, đánh giá hoặc tái cấu trúc (refactor) mã nguồn để tránh làm phức tạp hóa quá mức, thực hiện các thay đổi chính xác như phẫu thuật, làm rõ các giả định và xác định tiêu chí thành công có thể kiểm chứng được.
license: MIT
---
# Nguyên tắc Lập trình Karpathy (Karpathy Guidelines)
Bộ nguyên tắc hành vi giúp giảm thiểu những sai lầm lập trình phổ biến của LLM, được đúc kết từ [những quan sát của Andrej Karpathy](https://x.com/karpathy/status/2015883857489522876) về các cạm bẫy khi dùng LLM viết mã.
**Sự đánh đổi:** Những nguyên tắc này thiên về sự thận trọng hơn là tốc độ. Đối với các tác vụ nhỏ nhặt đơn giản, hãy linh hoạt phán đoán.
## 1. Suy nghĩ Trước khi Viết mã
**Đừng tự giả định. Đừng che giấu sự bối rối. Hãy phơi bày các sự đánh đổi.**
Trước khi bắt tay vào cài đặt:
- Nêu rõ các giả định của bạn một cách tường minh. Nếu không chắc chắn, hãy hỏi.
- Nếu tồn tại nhiều cách hiểu khác nhau, hãy trình bày tất cả các cách hiểu đó - đừng âm thầm tự chọn một hướng.
- Nếu có một hướng tiếp cận đơn giản hơn, hãy lên tiếng đề xuất. Phản biện lại yêu cầu khi có cơ sở chính đáng.
- Nếu có điều gì chưa rõ ràng, hãy dừng lại. Chỉ đích danh điểm đang gây khó hiểu. Hãy đặt câu hỏi.
## 2. Ưu tiên Sự Đơn giản Trước tiên
**Lượng mã tối thiểu giải quyết được vấn đề. Không viết thêm bất cứ thứ gì mang tính phòng hờ suy đoán.**
- Không thêm các tính năng nằm ngoài những gì được yêu cầu.
- Không tạo các lớp trừu tượng hóa (abstractions) cho đoạn mã chỉ dùng một lần duy nhất.
- Không thêm "tính linh hoạt" hay "khả năng cấu hình" không được yêu cầu.
- Không viết mã xử lý lỗi cho những kịch bản không bao giờ có thể xảy ra.
- Nếu bạn viết 200 dòng mã trong khi chỉ cần 50 dòng là giải quyết được, hãy viết lại nó.
Hãy tự hỏi bản thân: "Liệu một kỹ sư cấp cao (senior engineer) có nhận xét đoạn mã này bị phức tạp hóa quá mức không?" Nếu có, hãy đơn giản hóa nó.
## 3. Thay đổi Chính xác Như Phẫu thuật (Surgical Changes)
**Chỉ chạm vào những chỗ thực sự bắt buộc. Chỉ dọn dẹp phần bừa bộn do chính mình tạo ra.**
Khi chỉnh sửa mã nguồn hiện có:
- Đừng tự ý "cải thiện" các đoạn mã, chú thích hoặc định dạng nằm lân cận.
- Đừng tái cấu trúc (refactor) những thứ vốn không bị hỏng.
- Tuân theo phong cách mã hiện có của dự án, ngay cả khi bạn thích viết theo kiểu khác.
- Nếu bạn nhận thấy có mã chết (dead code) không liên quan, hãy nhắc tới nó - đừng tự ý xóa nó đi.
Khi thay đổi của bạn làm phát sinh các phần tử mồ côi:
- Hãy xóa bỏ các câu lệnh import/biến/hàm bị dư thừa DO CHÍNH THAY ĐỔI CỦA BẠN gây ra.
- Đừng xóa các đoạn mã chết đã tồn tại từ trước trừ khi được yêu cầu.
Phép thử: Mọi dòng mã thay đổi đều phải truy nguyên trực tiếp về yêu cầu của người dùng.
## 4. Thực thi Hướng Mục tiêu (Goal-Driven Execution)
**Xác định tiêu chí thành công. Lặp lại cho đến khi kiểm chứng xong.**
Chuyển hóa các tác vụ thành những mục tiêu có thể kiểm chứng được:
- "Thêm kiểm tra đầu vào (validation)" -> "Viết các bài kiểm thử cho dữ liệu đầu vào không hợp lệ, sau đó làm cho chúng vượt qua (pass)"
- "Sửa lỗi (bug)" -> "Viết một bài kiểm thử tái hiện lại lỗi đó, sau đó làm cho nó vượt qua"
- "Tái cấu trúc X" -> "Đảm bảo toàn bộ bài kiểm thử đều vượt qua cả trước và sau khi thực hiện"
Đối với các tác vụ gồm nhiều bước, hãy nêu một kế hoạch ngắn gọn:
\
Các tiêu chí thành công chặt chẽ cho phép bạn tự lặp và hoàn thiện độc lập. Các tiêu chí yếu ớt ("làm cho nó chạy được") sẽ đòi hỏi phải hỏi đi hỏi lại liên tục.