Vì sao Claude làm sai: 3 prompt
MarkdownClaude viết sai vì vội viết mã mà chưa hiểu ý bạn. Tôi giải thích lý do và đưa ra 3 prompt sẵn dùng để Claude đặt câu hỏi trước.
Đọc toàn bộ bài viết
Điểm chính
Claude viết sai vì vội lao vào viết mã và tự điền những gì nó nghĩ bạn muốn. Thường thì nó đoán sai. Vấn đề hầu như không bao giờ nằm ở mô hình—ngay cả mô hình mạnh nhất cũng sẽ làm lệch mục tiêu khi nhiệm vụ mơ hồ. Tôi khắc phục chỉ bằng một cách: yêu cầu Claude phỏng vấn tôi trước, làm rõ ý định của tôi, rồi mới viết. Dưới đây là ba prompt sẵn dùng để bạn sao chép và dán.
Để biết thêm về cách sử dụng dịch vụ, hãy xem tài liệu Ailoot.
Vì sao Claude làm sai?
Điểm chính
Claude nhận một yêu cầu ngắn, lập tức tự điền những phần còn thiếu rồi vội viết mã dựa trên cách hiểu riêng về nhiệm vụ. Cách hiểu của nó khác với bạn. Đó là lý do bạn nhận được một diff tác động đến 14 tệp trong khi chỉ mong đợi thay đổi một dòng. Nguyên nhân là khoảng cách giữa điều bạn nói và điều bạn nghĩ trong đầu. Mô hình gần như không liên quan.
Bạn viết: “Thêm bộ lọc vào trang sản phẩm.” Trong đầu bạn, điều đó có nghĩa là vài ô đánh dấu và danh sách được cập nhật. Claude nghe cùng câu đó rồi quyết định xây dựng hẳn một công cụ lọc hoàn chỉnh: kho trạng thái riêng, logic trì hoãn đầu vào riêng, đồng bộ URL và cả tá hàm trợ giúp. Hàng trăm dòng mã trong khi chỉ cần vài tham số URL.
Trong trường hợp như vậy, kết luận rất rõ ràng: tác nhân không mắc lỗi; nó chỉ giải quyết một vấn đề lớn hơn nhiều so với mức cần thiết. Sai sót nằm ở việc mô tả kết quả mong muốn chưa đủ ngắn gọn và chính xác.
Từ khóa ở đây là “ý định”. Bạn có ý định đó trong đầu; Claude thì không. Nó nhìn thấy nội dung yêu cầu và mọi thứ trong ngữ cảnh của nó cho đến yêu cầu ấy. Sau đó, nó lấp chỗ trống bằng phỏng đoán. Yêu cầu càng ngắn, nó càng đoán nhiều—và kết quả càng xa điều bạn muốn.
Anthropic nói rõ điều này trong tài liệu Claude Code:
Nếu để Claude nhảy thẳng vào viết mã, nó có thể giải quyết sai vấn đề.
Tôi từng gặp chuyện này trong dự án của mình. Tôi yêu cầu sửa một màn hình phân quyền nhưng nhận được một diff ảnh hưởng đến một nửa mô-đun lân cận. Claude không có lỗi: tôi đưa cho nó một dòng, rồi nó tự điền phần còn lại. Từ đó, với mọi nhiệm vụ lớn hơn việc sửa lỗi chính tả, tôi bắt đầu bằng những câu hỏi—những câu hỏi Claude hỏi tôi.
Có thực sự là do mô hình không — và vì sao ngay cả mô hình mạnh nhất cũng làm lệch mục tiêu?
Điểm chính
Mô hình ít quan trọng hơn mọi người thường nghĩ. Với một nhiệm vụ mơ hồ, ngay cả mô hình mạnh nhất cũng sẽ làm lệch mục tiêu: nó nhận cùng những chỉ dẫn chưa đầy đủ rồi lấp chỗ trống bằng phỏng đoán của mình. Các nhà phát triển biết cách kiểm soát tác nhân sẽ đạt kết quả tương tự dù dùng mô hình hàng đầu hay mô hình tầm trung. Tất cả phụ thuộc vào việc bạn mô tả điều mình muốn rõ ràng đến đâu. Trong trường hợp này, sức mạnh của mô hình chỉ là yếu tố thứ yếu.
Mỗi tuần lại có một mô hình “thông minh hơn” mô hình trước, và lần nào chúng ta cũng có cảm giác đây chính là thời điểm AI cuối cùng sẽ hiểu mình chỉ từ vài từ. Nhưng sẽ không như vậy. Mô hình mạnh hơn viết mã nhanh hơn và xử lý logic phức tạp tốt hơn, nhưng vẫn không thể đọc được suy nghĩ của bạn. Nếu nhiệm vụ được mô tả kém, bạn sẽ nhận được thứ được viết rất trau chuốt nhưng vẫn sai.
Bài học dành cho bạn rất đơn giản. Chạy theo mô hình mới nhất để nó đoán tốt hơn là ngõ cụt. Học cách giao việc để nó không phải đoán sẽ ít tốn kém và đáng tin cậy hơn. Đó là nội dung tiếp theo.
Grilling là gì, và nó khắc phục sự lệch pha với AI như thế nào?
Điểm chính
Grilling là khi bạn yêu cầu AI phỏng vấn mình trước khi bắt đầu làm việc: AI đặt câu hỏi chi tiết về nhiệm vụ cho đến khi hai bên hiểu nhau. Mục đích là thu hẹp khoảng cách giao tiếp trước dòng mã đầu tiên.
Nghe có vẻ trái với trực giác. Chúng ta tìm đến AI để hoàn thành công việc nhanh hơn, vậy mà giờ lại được bảo phải làm nó chậm lại và yêu cầu nó hỏi trước. Nhưng năm phút trả lời câu hỏi trước khi viết mã có thể giúp tiết kiệm một giờ sửa lỗi sau đó.
Vấn đề không chỉ là bạn giải thích chưa rõ với Claude. Thường thì chính bạn cũng chưa suy nghĩ thấu đáo về nhiệm vụ—cần tính đến những trường hợp nào, ranh giới ở đâu, điều gì quan trọng nhất. Grilling dùng câu hỏi để giúp bạn làm rõ những điều đó. Kết thúc cuộc trò chuyện, bạn không chỉ có nhiệm vụ mà AI hiểu được, mà còn có chính nhiệm vụ của mình được diễn đạt đầy đủ và chi tiết.
Đó là cách context engineering hoạt động: phần việc chính diễn ra trước prompt, chứ không phải trong lúc viết prompt. Bạn không đi tìm cách diễn đạt kỳ diệu cho prompt; bạn xác định trước những gì mình cần ở Claude cho đến khi nó hiểu mà không cần giải thích thêm.
Làm thế nào để yêu cầu Claude đặt câu hỏi trước?
Điểm chính
Hãy mô tả ngắn gọn nhiệm vụ cho Claude và yêu cầu rõ ràng rằng nó phải phỏng vấn bạn trước khi bắt đầu làm việc: hỏi về chi tiết, trường hợp biên và ràng buộc, rồi cuối cùng tập hợp mọi thứ vào một tệp đặc tả. Đây là khuyến nghị chính thức của Anthropic—tài liệu Claude Code có sẵn mẫu prompt cho việc này. Sao chép mẫu, thay đổi phần mô tả và dán vào đầu phiên làm việc.
Anthropic không chỉ cho phép cách tiếp cận này mà còn khuyến nghị sử dụng. Tài liệu có mục “Để Claude phỏng vấn bạn”, kèm một prompt có sẵn. Đây là phiên bản thực tế:
Prompt
Prompt grilling—yêu cầu Claude phỏng vấn bạn
Tôi muốn xây dựng [mô tả ngắn gọn về nhiệm vụ].
Hãy phỏng vấn tôi thật kỹ trước khi viết bất kỳ đoạn mã nào. Hỏi về cách triển khai, giao diện, các trường hợp biên, rủi ro và sự đánh đổi. Đừng hỏi những điều hiển nhiên—hãy đào sâu vào những phần phức tạp mà có thể tôi chưa nghĩ tới.
Mỗi lần chỉ hỏi một câu và chờ câu trả lời của tôi. Với mỗi câu hỏi, hãy đề xuất ngay câu trả lời mà bạn khuyến nghị.
Tiếp tục cho đến khi chúng ta đã đề cập mọi thứ. Sau đó tổng hợp thành một bản đặc tả hoàn chỉnh trong tệp có tên SPEC.md.
Ba chi tiết khiến prompt này hữu ích thay vì chỉ để trang trí. Thứ nhất, “mỗi lần chỉ hỏi một câu”. Nếu AI dồn mười câu hỏi cùng lúc, bạn sẽ thấy quá tải và trả lời hời hợt. Thứ hai, “đề xuất câu trả lời của bạn”: bạn không phải nghĩ ra mọi thứ từ đầu; chỉ cần đồng ý hoặc sửa lại. Thứ ba, “tổng hợp thành đặc tả trong một tệp”: ý định được khơi gợi từ bạn sẽ trở thành tài liệu không bị thất lạc.
Anthropic mô tả lợi ích này theo mức độ công sức bỏ ra:
Thời gian dành cho việc hoàn thiện đặc tả có giá trị hơn thời gian dành để theo dõi quá trình triển khai.
Sau buổi phỏng vấn, hãy mở một phiên mới và đưa cho Claude bản đặc tả hoàn chỉnh. Ngữ cảnh sạch cùng ý định được nêu rõ—và Claude sẽ làm đúng ngay lần đầu.
Kỹ thuật “chứng minh cho tôi đây là kế hoạch tốt nhất”
Điểm chính
Đừng chỉ yêu cầu AI đặt câu hỏi—hãy yêu cầu nó bảo vệ cả quyết định của mình. Tôi thêm một yêu cầu vào nhiệm vụ: chứng minh rằng kế hoạch được đề xuất là phương án tốt nhất, chứ không chỉ là phương án đầu tiên xuất hiện trong đầu, và đã được suy xét trước nhiều bước. Điều này đưa Claude ra khỏi chế độ “Tôi sẽ làm gì đó tương tự” và chuyển sang chế độ phản biện, nơi nó kiểm tra công việc của mình trước khi bạn dành thời gian triển khai.
Grilling giúp làm rõ ý định của bạn. Nhưng AI còn có một thói quen khác: chọn giải pháp đầu tiên trông có vẻ hợp lý. Anthropic gọi đây là khoảng cách “tin tưởng nhưng xác minh”: Claude tạo ra cách triển khai có vẻ hợp lý nhưng không đứng vững trước các trường hợp biên. Cách khắc phục là yêu cầu bằng chứng trước khi viết mã.
Nếu bạn không thể kiểm tra kết quả, đừng gửi nó.
Tôi gần như luôn thêm một phần “chứng minh đi” vào prompt. Đây là nguyên văn:
Prompt
Prompt—yêu cầu AI bảo vệ kế hoạch của mình
Trước khi viết mã, hãy phân tích nhiệm vụ như một nhà phê bình.
Tìm 2-3 cách giải quyết. Với mỗi cách, hãy chứng minh cho tôi thấy rằng nó thực sự giải quyết nhiệm vụ của tôi thay vì chỉ thêm độ phức tạp không cần thiết. Đừng viết mã chỉ để viết mã.
Sau đó chọn một cách và chứng minh rằng đó là giải pháp tốt nhất, đã được suy tính trước nhiều bước. Điều gì sẽ hỏng khi dự án phát triển? Hiện giờ chúng ta đang bỏ sót điều gì?
Chỉ khi đó mới đề xuất cách triển khai.
Không có phần này, Claude đưa ra lựa chọn đầu tiên có thể thực hiện được. Có phần này, Claude tự loại bỏ những ngõ cụt, giải thích lựa chọn của mình và cho bạn thấy lập luận trước khi bất kỳ tệp nào bị động đến. Bạn đọc một đoạn ngắn chỉ mất hai phút thay vì dành một giờ tìm hiểu vì sao mã hoàn chỉnh lại không hoạt động như mong đợi.
Phân tích trước thất bại: yêu cầu AI tìm 10 lý do khiến dự án thất bại trước khi bắt đầu
Điểm chính
Phân tích trước thất bại là kỹ thuật yêu cầu AI tưởng tượng dự án đã thất bại và nêu ra lý do. Claude chuyển từ chế độ lạc quan “Tôi sẽ hoàn thành việc này” sang tìm kiếm những điểm yếu mà nếu không, có thể chỉ lộ ra sau một tuần làm việc. Bạn nhận được danh sách rủi ro trước khi đầu tư thời gian vào dự án và có thể giải quyết chúng trước.
Đây là kỹ thuật tôi yêu thích nhất, và nó liên quan đến tâm lý. Khi bạn yêu cầu AI “làm tốt”, nó được định hướng vào thành công và bỏ qua những lỗ hổng. Hãy yêu cầu nó tưởng tượng thất bại, nó sẽ bắt đầu nhìn thấy những gì trước đó đã bỏ qua. Prompt rất ngắn:
Prompt
Prompt phân tích trước thất bại—tìm khoảng trống trước khi bắt đầu
Hãy tưởng tượng rằng đã một năm trôi qua. Dự án chúng ta đang lên kế hoạch đã thất bại.
Hãy viết ra 10 lý do khiến chuyện đó xảy ra. Ban đầu chúng ta đã không tính đến điều gì, đã đánh giá thấp điều gì, đã cắt xén ở đâu, và giả định nào hóa ra là sai?
Sau đó, với từng lý do, hãy cho tôi biết chúng ta có thể sửa gì ngay bây giờ để giải quyết vấn đề đó.
Tôi chạy prompt này trước khi phê duyệt kế hoạch. Một nửa số lý do hóa ra vô lý, nhưng nửa còn lại là những cạm bẫy thật sự mà một tuần sau tôi sẽ gặp phải. Giải quyết chúng trong giai đoạn lập kế hoạch chỉ mất mười phút. Đụng phải chúng trong một dự án đã hoàn thành sẽ tốn vài ngày điều tra.
Cách kết hợp rất đơn giản: grilling làm rõ ý định, “chứng minh đi” bảo vệ quyết định, còn phân tích trước thất bại tìm ra những khoảng trống. Ba đoạn văn ngắn để dán vào trước khi viết mã. Chúng biến Claude từ một người thực thi vội vàng thành cộng sự biết suy nghĩ trước.
Vì sao ngữ cảnh quá tải khiến Claude hành xử ngớ ngẩn?
Điểm chính
Claude có một cửa sổ ngữ cảnh giới hạn—lượng thông tin nó có thể giữ trong đầu cùng lúc. Khi cửa sổ đầy hơn một nửa, nó bắt đầu mất các chi tiết quan trọng, nhầm lẫn những thỏa thuận trước đó và tự lấp chỗ trống thay vì nhớ lại. Một phiên dài nói đủ thứ trên đời là lý do phổ biến khiến đến cuối ngày AI làm điều hoàn toàn khác với điều hai bên đã thống nhất vào buổi sáng.
Ngay cả nhiệm vụ được mô tả hoàn hảo cũng sẽ đổ vỡ nếu bạn làm việc trong ngữ cảnh lộn xộn. Cách hoạt động như sau: mỗi yêu cầu mới của bạn đưa toàn bộ lịch sử trò chuyện vào ngữ cảnh làm việc của Claude. Phiên càng dài, cửa sổ càng đầy nhanh. Hãy giữ cho cửa sổ chỉ đầy tối đa một nửa; vượt quá mức đó, AI bắt đầu hành xử ngớ ngẩn và đánh mất những điều quan trọng đã thảo luận lúc đầu.
Đây là quy tắc giúp tôi bớt bực bội nhất: một nhiệm vụ, một cuộc trò chuyện. Hoàn thành một hàm rồi? Đóng cuộc trò chuyện và mở cuộc trò chuyện mới cho nhiệm vụ tiếp theo. Đúng là đôi khi làm mọi thứ trong một cửa sổ sẽ tiện hơn, nhưng bạn sẽ phải trả giá bằng việc mất ngữ cảnh và nhận câu trả lời lạc đề.
Anthropic gọi kiểu thất bại này là “phiên ngăn kéo chứa đồ linh tinh”. Cách khắc phục rất đơn giản: dùng /clear giữa các nhiệm vụ không liên quan để xóa cửa sổ và tránh mang sự lộn xộn từ nhiệm vụ trước sang nhiệm vụ mới.
Nếu bạn chạy các phiên dài mà không hiểu tiền và sự chú ý của AI đang đi đâu, tôi trình bày riêng trong hướng dẫn về token Claude Code được dùng vào đâu. Tôi cũng tập hợp những điều cơ bản về ngữ cảnh liên tục, thứ Claude đọc mỗi lần khởi động, trong hướng dẫn thiết lập CLAUDE.md.
Grilling hay Plan Mode—khác nhau ở đâu và kết hợp thế nào?
Điểm chính
Grilling và Plan Mode giải quyết hai nửa khác nhau của cùng một vấn đề. Grilling dùng câu hỏi để làm rõ ý định trước khi có kế hoạch. Plan Mode nhận một nhiệm vụ đã được hiểu rõ và trình bày kế hoạch thay đổi, không đụng đến thứ gì cho đến khi bạn phê duyệt. Hai cách hoạt động hiệu quả nhất khi kết hợp: trước tiên grilling làm rõ chúng ta đang xây dựng gì, sau đó Plan Mode chỉ rõ cách thực hiện.
Mọi người thường nhầm lẫn hai kỹ thuật này hoặc cho rằng chỉ cần một trong hai. Trên thực tế, chúng thuộc về những thời điểm khác nhau trong quy trình.
| Tính năng | Grilling | Plan Mode |
|---|---|---|
| Thời điểm | Trước kế hoạch—làm rõ ý định | Sau đó—tạo kế hoạch thay đổi |
| Ai hỏi ai | AI phỏng vấn bạn | Bạn đọc và phê duyệt kế hoạch |
| Kết quả nhận được | Đặc tả nhiệm vụ | Kế hoạch thay đổi theo từng tệp |
| Lợi ích chính | Ngăn câu “đó không phải điều tôi muốn” | Ngăn câu “đừng đụng vào bất cứ thứ gì khác” |
Anthropic mô tả quy trình làm việc chuẩn gồm bốn giai đoạn: đầu tiên là Explore (Claude tìm hiểu và đặt câu hỏi), tiếp theo là Plan (lập kế hoạch mà không thay đổi gì), rồi Implement (viết mã theo kế hoạch), cuối cùng là Commit (ghi nhận kết quả). Grilling diễn ra ở giai đoạn đầu; Plan Mode ở giai đoạn thứ hai. Để xem phân tích đầy đủ về giai đoạn hai, hãy xem hướng dẫn về Plan Mode trong Claude Code.
Có một lưu ý quan trọng từ chính Anthropic: đừng tạo gánh nặng này cho các nhiệm vụ nhỏ.
Nếu bạn có thể mô tả thay đổi trong một câu, hãy bỏ qua kế hoạch.
Với lỗi chính tả, đổi tên hoặc thay đổi một dòng, hãy viết yêu cầu trực tiếp, không cần phỏng vấn hay lập kế hoạch. Grilling hữu ích với nhiệm vụ mơ hồ và lỗi có thể gây tốn kém. Với việc đơn giản, nó chỉ làm bạn chậm lại.
5 lỗi khi xác định nhiệm vụ khiến AI làm sai
Điểm chính
Hầu hết lỗi AI đều bắt nguồn từ năm lỗi khi xác định nhiệm vụ: một câu chỉ dẫn mơ hồ, không có ràng buộc, yêu cầu “viết mã” mà thiếu bước “hiểu trước”, không định nghĩa thế nào là “hoàn thành”, và một phiên kéo dài vô tận cho mọi thứ. Mỗi lỗi đều khiến Claude tự lấp đầy nhiệm vụ bằng phỏng đoán. Dưới đây là biểu hiện của từng lỗi và cách thay thế.
Tôi đã tóm tắt các cạm bẫy thường gặp trong bảng. Bên trái là những gì mọi người thường làm và làm sai; bên phải là điều nên làm thay thế.
| Lỗi | Câu nói thường gặp | Nên làm gì thay thế |
|---|---|---|
| Chỉ dẫn ngắn và mơ hồ | “Làm bảng điều khiển tốt hơn” | Mô tả nhiệm vụ và bắt đầu một phiên grilling—để AI dùng câu hỏi làm rõ chi tiết |
| Không có ràng buộc | “Thêm phân quyền” | Nêu rõ điều gì không được phép hỏng, không được thêm thư viện nào và những gì nằm ngoài phạm vi |
| Yêu cầu “viết mã” ngay | Prompt—rồi bắt đầu viết mã | Trước tiên “hiểu và đặt câu hỏi”, sau đó mới viết mã |
| Không định nghĩa “hoàn thành” | Bạn mong AI tự đoán kết quả | Đưa ví dụ, ảnh chụp màn hình tham khảo hoặc bài kiểm tra cho thấy “hoạt động” nghĩa là gì |
| Một phiên cho mọi việc | Dành cả ngày trong một cuộc trò chuyện | Một nhiệm vụ, một cuộc trò chuyện mới để ngữ cảnh không bị lộn xộn |
Hãy xem lại prompt gần đây nhất mà AI trả lời sai. Gần như chắc chắn một trong năm lỗi này đã xảy ra. Thường gặp nhất là lỗi đầu tiên: bạn đưa ra một cụm từ ngắn rồi mong Claude tự điền phần còn lại thật chính xác. Nó đã điền phần còn lại—chỉ là không theo cách bạn nghĩ.
Tiếp theo: xây dựng hệ thống để AI hiểu bạn chỉ từ vài từ
Điểm chính
Các prompt riêng lẻ sửa từng nhiệm vụ riêng lẻ. Để AI hiểu bạn mà không cần giải thích dài dòng mỗi lần, bạn cần một hệ thống: grilling làm rõ ý định cho từng nhiệm vụ, Second Brain lưu trữ kiến thức dự án, còn context engineering kết nối mọi thứ Claude đọc trước khi thấy prompt. Khi đó, lý do khiến nó làm sai sẽ biến mất: nó luôn có đủ ngữ cảnh để khỏi phải đoán.
Ba prompt trong hướng dẫn này—grilling, “chứng minh đi” và phân tích trước thất bại—xử lý nhiệm vụ cụ thể trước mắt. Như vậy đã là một bước tiến lớn: bạn sẽ không còn nhận được diff 14 tệp khi tất cả những gì bạn muốn chỉ là thay đổi một dòng.
Nhưng grilling có giới hạn. Mỗi lần đều phải làm rõ ý định của bạn từ đầu sẽ rất mất thời gian. Thay đổi thực sự đến khi một phần ngữ cảnh luôn sẵn có: trong thư mục kiến thức về dự án, trong tệp CLAUDE.md mà Claude đọc mỗi lần khởi động và trong phương pháp làm việc của bạn được mã hóa thành skills. Khi đó, AI bắt đầu nhiệm vụ với hiểu biết về doanh nghiệp, mục tiêu và phong cách của bạn—và hiểu bạn chỉ từ vài từ vì bạn đã chuẩn bị trước một nửa ngữ cảnh.
Bài phân tích gần đây của Anthropic cho thấy khối lượng công việc này lớn đến mức nào: các nhà phát triển sử dụng AI trong khoảng 60% công việc nhưng chỉ có thể hoàn toàn tin cậy AI với 0-20% nhiệm vụ. Phần còn lại đòi hỏi sự hiểu biết, giám sát và khả năng giải thích cần xây dựng điều gì của bạn. Đó là kỹ năng đáng phát triển, chứ không phải chạy theo mô hình thông minh nhất.
Nguồn
Hãy tìm hiểu Ailoot.
Xem thêm chi tiết
Câu hỏi thường gặp
Khi nào dùng lời nhắc phỏng vấn thay vì đi thẳng vào mã?
Khi kết quả, ngoại lệ hoặc giới hạn chưa rõ và sai tốn kém. Hỏi từng câu, lưu thỏa thuận ở SPEC.md; lỗi chính tả hay thay một dòng rõ có thể yêu cầu trực tiếp.
Cần kiểm gì trước chấp nhận kế hoạch đề xuất?
Yêu cầu hai hoặc ba cách, so mỗi cách đáp ứng spec và giới hạn. Chạy lời nhắc pre-mortem, xem lý do thất bại và xử lý rủi ro liên quan trước triển khai.