Tóm tắt nhanh
- Boris Cherny, người tạo Claude Code tại Anthropic, cho rằng prompt tốt cần nêu rõ việc cần làm, mức độ nỗ lực muốn AI bỏ ra và cách kiểm chứng kết quả.
- Ví dụ ông chia sẻ là yêu cầu Claude làm website tương tác kể lại tập Acquired về The Home Depot; prompt dùng ngôn ngữ tự nhiên, kèm định hướng sản phẩm và cho phép mô hình lặp lại.
- Đây là ba nguyên tắc để giao việc rõ hơn, không phải công thức bắt buộc cho mọi tác vụ hay chỉ dùng được với Claude.
- Với code, bước kiểm chứng nên gắn với tiêu chí cụ thể như chạy test hoặc build, thay vì chỉ yêu cầu AI tự thấy hài lòng.
Boris Cherny, người tạo Claude Code tại Anthropic, đúc kết cách viết prompt thành ba ý: nói rõ mục tiêu, cho biết mức nỗ lực cần thiết và yêu cầu công cụ tự kiểm tra kết quả. Cách tiếp cận này đáng chú ý vì nó đặt trọng tâm vào việc giao một đầu việc có tiêu chí nghiệm thu, thay vì tìm một mẫu câu thần kỳ để dán vào mọi yêu cầu.
Mục tiêu rõ quan trọng hơn một khuôn prompt dài
Ngày 6/10/2026, Cherny chia sẻ prompt dùng để tạo một website tương tác đồng hành với tập podcast Acquired về The Home Depot. Ông muốn trang kể lại toàn bộ tập, làm nổi bật những bài học kinh doanh, có tính tương tác và mang phong cách trực quan như các ấn phẩm báo chí lớn. Prompt cũng gợi ý tranh màu nước, ảnh lịch sử và OpenCV, nhưng không áp đặt chi tiết từng màn hình hay cách triển khai.
Theo explainx.ai, tập podcast dài 3 giờ 35 phút được chuyển thành 17 chương, kèm dòng thời gian có thể tua, hình minh họa và các trực quan hóa dữ liệu tương tác. Quy mô đầu ra không đến từ một danh sách dài các lệnh định dạng; phần quan trọng là Cherny nói rõ sản phẩm cần phục vụ việc gì và người xem nên nhận được điều gì.
Đó là khác biệt giữa mô tả mục tiêu và kê sẵn từng thao tác. Nếu người dùng chỉ nói “làm một trang đẹp”, mô hình phải tự đoán đẹp nghĩa là gì. Còn khi giao cả mục đích, đối tượng nội dung và vài tham chiếu phong cách, AI có cơ sở để chọn cách thể hiện mà không bị khóa vào một bộ khung cứng.
Hãy nói rõ khi nào công việc cần mô hình đầu tư thêm
Trong prompt, Cherny viết “use lots of tokens and iterate till you’re proud of it” — hãy dùng nhiều token và tiếp tục lặp cho đến khi thấy sản phẩm đủ tốt. Đây là cách báo cho mô hình rằng nhiệm vụ cần thời gian lập kế hoạch và chỉnh sửa, thay vì trả về bản đầu tiên thật nhanh.
Ý này không đồng nghĩa lúc nào cũng nên yêu cầu mức suy luận cao nhất. Một câu hỏi tra cứu ngắn không cần tiêu tốn nhiều lượt suy nghĩ; còn một website có nhiều chương, biểu đồ và hình ảnh cần xử lý nhiều phần ăn khớp với nhau. Người dùng nên khớp mức nỗ lực với hậu quả của sai sót và độ phức tạp của đầu ra. Với các công cụ có tùy chọn effort, yêu cầu bằng ngôn ngữ tự nhiên cũng có thể bổ sung cho thiết lập đó.
Cụm “đến khi tự hào” trong prompt mang tính định hướng, nhưng bản thân nó chưa phải chuẩn nghiệm thu. Mô hình có thể lặp lại mà vẫn bỏ sót lỗi, hoặc hiểu “đẹp” và “tốt” khác người giao việc. Khi cần đầu ra đáng tin cậy, hãy mô tả thêm điều kiện hoàn thành có thể quan sát được.
AI cần một cách kiểm tra kết quả, không chỉ lời khen đầu ra
Với phần mềm, cách kiểm chứng có thể là chạy unit test, kiểm tra build hoặc thử một luồng sử dụng cụ thể. Một yêu cầu như “tạo trang đăng nhập, sau đó chạy bộ test hiện có và sửa các lỗi phát sinh; báo lại nếu test nào chưa chạy được” giúp phân biệt sản phẩm đã qua kiểm tra với sản phẩm chỉ trông có vẻ hoàn chỉnh.
Với nội dung không có bộ test tự động, tiêu chí vẫn có thể cụ thể: kiểm tra đủ các chương, đối chiếu số liệu với tài liệu gốc, xác nhận mọi nút tương tác hoạt động và thử giao diện trên màn hình nhỏ. Nếu không có bước này, AI dễ kết thúc bằng một lời khẳng định rằng nó đã hoàn thành mà không đưa ra bằng chứng.
Chính ví dụ của Cherny cũng cho thấy ba yếu tố không phải biểu mẫu cứng. Prompt yêu cầu mô hình lặp lại, nhưng không chỉ rõ một phép kiểm thử cụ thể. Điều đó không phủ nhận nguyên tắc kiểm chứng; nó chỉ cho thấy độ chi tiết cần thay đổi theo đầu việc. Một tác phẩm trực quan có thể cần rà soát thủ công, còn code thường có công cụ kiểm tra rõ ràng hơn.
Ba nguyên tắc dùng được ngoài Claude, nhưng không thay thế đánh giá
Mục tiêu, mức nỗ lực và kiểm chứng là những thói quen giao việc có thể áp dụng với ChatGPT, Gemini hoặc mô hình chạy cục bộ. Chúng không phụ thuộc vào một câu lệnh đặc biệt. Tuy vậy, cách mỗi mô hình xử lý cùng một yêu cầu có thể khác nhau; người dùng vẫn cần điều chỉnh mức chi tiết, quyền truy cập công cụ và tiêu chí đánh giá cho hệ thống mình đang dùng.
Với lập trình viên, phần dễ áp dụng nhất là viết tiêu chí nghiệm thu trước khi giao việc: tính năng nào phải có, lệnh nào phải chạy và kết quả nào được xem là đạt. Với yêu cầu sáng tạo, có thể đưa mẫu tham chiếu và mô tả mục đích, sau đó yêu cầu mô hình tự rà soát theo một danh sách ngắn. Đừng biến ba ý này thành một prompt dài bắt buộc cho cả việc nhỏ lẫn việc lớn; giá trị của chúng nằm ở chỗ giúp hai bên hiểu đúng nhiệm vụ và biết lúc nào có thể dừng.
Nguồn tham khảo: XDA Developers; explainx.ai
