Prompt cũ đang làm Claude tệ hơn: cách kiểm toán prompt, dùng prompt caching và thiết kế eval theo kỹ sư Anthropic

Trong bài thuyết trình "Your Old Prompts Are Making Claude Worse" tại AI Engineer New York, Lance Martin — thành viên đội ngũ kỹ thuật của Anthropic — cho rằng nhiều thói quen viết prompt phổ biến từ vài thế hệ mô hình trước nay đang làm tăng chi phí và giảm chất lượng đầu ra của các mô hình frontier như Claude. Bài viết này tổng hợp ba nội dung chính của bài talk: kiểm toán prompt để loại bỏ chỉ dẫn lỗi thời, dùng prompt caching đúng nguyên tắc khớp tiền tố, và thiết kế bộ đánh giá (eval) đủ tốt để tối ưu prompt bằng số liệu thay vì cảm tính.

Trả lời nhanh

• Các mô hình frontier hiện nay đã tự suy luận và tự kiểm tra kết quả. Những chỉ dẫn kiểu "hãy suy nghĩ từng bước", "hãy kiểm tra lại hai lần" hay "hãy thật kỹ lưỡng tối đa" là thói quen từ thời mô hình còn yếu; giữ lại chỉ tốn thêm token và có thể làm giảm chất lượng.
• Prompt cũng tích lũy "nợ" như code. Chỉ dẫn chồng chéo, mâu thuẫn nhau khiến mô hình khó tuân theo; giải pháp là kiểm toán prompt (prompt audit) định kỳ để loại bỏ phần thừa.
• Claude Code đã tích hợp sẵn prompt audit qua lệnh /claude-api prompt-audit cho code gọi API và /doctor prompt-audit (bí danh /checkup) cho chính cấu hình Claude Code.
• Prompt caching khớp theo tiền tố một cách nghiêm ngặt (strict prefix match): thay đổi một ký tự ở đầu prompt cũng làm vỡ toàn bộ cache phía sau. Hãy đặt nội dung cố định (system prompt, định nghĩa công cụ) lên đầu và nội dung thay đổi xuống cuối.
• Theo benchmark nội bộ mà Anthropic trình bày trong bài talk, dùng prompt caching đúng cách giảm tới 72% chi phí; một trường hợp tối ưu kiểu "leo đồi" (hill climbing) đã giảm 90% chi phí đồng thời tăng hiệu năng nhờ chuyển sang mô hình mạnh hơn ở mức effort thấp hơn.
• Eval tốt phải là eval mà mô hình "leo lên được": thang đo rõ ràng, có tập train/test tách riêng để tránh overfitting — tối ưu quá mức vào chính bài test.

Prompt audit là gì?

Prompt audit (kiểm toán prompt) là việc rà soát lại toàn bộ prompt đang dùng — system prompt, chỉ dẫn, ví dụ mẫu — để phân loại từng phần: giữ lại, loại bỏ, viết lại hoặc chuyển vị trí. Mục đích là loại bỏ những chỉ dẫn được thêm vào từ các thế hệ mô hình trước nhưng nay không còn tác dụng, hoặc tệ hơn là mâu thuẫn với nhau và kéo chất lượng đi xuống.

Prompt caching là gì?

Prompt caching là cơ chế lưu lại phần đầu (tiền tố) của prompt đã được mô hình xử lý, để các lượt gọi sau dùng lại thay vì xử lý từ đầu. Vì việc khớp cache diễn ra theo tiền tố một cách nghiêm ngặt, toàn bộ nội dung cố định phải đứng trước và giữ nguyên từng ký tự; chỉ cần một thay đổi nhỏ ở đầu, mọi cache phía sau đều không còn dùng được.

Vì sao những thói quen prompt cũ không còn hợp với mô hình frontier?

Theo Lance Martin, prompt có xu hướng phình lên theo thời gian giống như code: mỗi thế hệ mô hình, người dùng thêm vào một lớp "mẹo" — yêu cầu mô hình suy nghĩ từng bước, tự kiểm tra lại nhiều lần, viết nháp theo thẻ scratchpad, hay ép mô hình dùng công cụ thật nhiều để "chống lười". Những kỹ thuật này từng cần thiết khi mô hình còn yếu.

Vấn đề là các mô hình frontier hiện nay đã tự biết suy luận, tự quyết định khi nào cần suy nghĩ sâu và tự soát lại kết quả mà không cần được nhắc. Khi người dùng vẫn nhồi các chỉ dẫn cũ vào prompt, hậu quả là hai mặt: tốn thêm tiền token cho những câu chữ không tạo giá trị, và các chỉ dẫn chồng chéo, mâu thuẫn có thể khiến mô hình xử lý kém đi. Tác giả bài chia sẻ trên Vietnam Java User Group — anh Linh Vu — nhận xét điều này khớp với trải nghiệm cá nhân của anh: prompt càng ngắn gọn, gãy gọn thì mô hình xử lý càng mượt và chuẩn.

Kiểm toán prompt bằng Claude Code được thực hiện như thế nào?

Bài talk giới thiệu cơ chế audit được tích hợp ngay trong Claude Code, với hai cửa vào: /claude-api prompt-audit dành cho code gọi Anthropic API và /doctor prompt-audit (bí danh /checkup) dành cho cấu hình Claude Code. Công cụ audit đọc prompt hiện tại, phân loại từng dòng theo bốn nhóm — giữ lại (keep), loại bỏ (remove), viết lại (rewrite), chuyển vị trí (move) — kèm mức độ tin cậy và đề xuất bản sửa dạng diff để người dùng duyệt trước khi áp dụng.

Điểm đáng chú ý là audit không xóa bừa: mỗi thay đổi đều được đề xuất kèm lý do, và kết quả cuối cùng vẫn do con người quyết định. Martin cũng minh họa bằng một eval nội bộ gồm 50 ticket hỗ trợ tổng hợp, mô phỏng việc chuyển từ Opus 4.8 lên 5.5: sau khi gỡ các thói quen cũ và chạy audit, chất lượng tăng trong khi chi phí giảm thêm.

Nguyên tắc vàng của prompt caching là gì?

Nguyên tắc được nhấn mạnh nhất là khớp tiền tố nghiêm ngặt: cache chỉ có giá trị khi phần đầu của prompt giống hệt nhau đến từng ký tự giữa các lượt gọi. Chỉ cần thay đổi một ký tự ở đầu — ví dụ chèn dấu thời gian vào system prompt — toàn bộ phần cache phía sau sẽ gãy và hệ thống phải trả giá token đầy đủ cho lượt đó.

Cách làm đúng là sắp xếp prompt theo thứ tự ổn định giảm dần: system prompt và định nghĩa công cụ (gần như không đổi) đặt lên đầu, ngữ cảnh ít thay đổi ở giữa, và nội dung hội thoại luôn thay đổi đặt ở cuối. Làm đúng cách này, Anthropic cho biết chi phí có thể giảm tới 72% trên các benchmark nội bộ của họ trong khi chất lượng giữ nguyên.

Tối ưu kiểu "leo đồi" giúp giảm chi phí ra sao?

Thay vì sửa prompt theo cảm tính, bài talk đề xuất vòng lặp hill climbing: đề xuất một thay đổi nhỏ (diff), chạy eval để đo, giữ lại nếu điểm tăng và hoàn nguyên (revert) nếu điểm giảm. Claude Code cũng có lệnh hỗ trợ tối ưu chi phí cho code gọi API trong bộ lệnh /claude-api.

Trường hợp ấn tượng nhất được trình bày: một hệ thống giảm được 90% chi phí đồng thời tăng hiệu năng, không phải bằng cách cắt prompt, mà bằng cách chuyển sang mô hình mạnh hơn nhưng đặt mức effort thấp hơn — mô hình mạnh xử lý đúng ngay từ ít lượt suy luận hơn, nên tổng chi phí lại rẻ hơn nhiều. Đây là con số Anthropic công bố trong bài talk; kết quả thực tế còn tùy workload của từng hệ thống.

Thiết kế eval thế nào để Claude cải thiện được mà không học vẹt?

Hill climbing chỉ hoạt động khi có một eval đáng tin để "leo". Theo bài talk, eval tốt cần ba yếu tố: thang đo (scorer) rõ ràng cho từng ca kiểm tra, tập dữ liệu tách thành train split và test split để thay đổi được thử trên train nhưng kết luận dựa trên test, và các ca kiểm tra chưa từng thấy (unseen) để phát hiện overfitting. Vòng lặp phân tích (Analyzer) đọc kết quả eval, lập giả thuyết về nguyên nhân lỗi, đề xuất diff cho prompt, rồi lại đo — một quy trình giống hệt cách kỹ sư tối ưu code bằng benchmark.

Còn các agent chạy dài ngày thì sao?

Phần cuối bài talk bàn về độ tin cậy của agent chạy dài hạn: khi agent hoạt động theo lịch (scheduled), tự đọc nguồn dữ liệu, duy trì bộ nhớ qua các lượt chạy và giữ thông tin đăng nhập trong kho riêng (vault), bài toán không còn là viết prompt hay nữa mà là vận hành một hệ thống — có heartbeat giám sát, có quy tắc phán đoán rõ ràng và có điểm đến đầu ra được duyệt trước. Anthropic định hướng nhu cầu này bằng Claude Managed Agents, nền tảng agent được quản lý của hãng.

Bảng so sánh: thói quen cũ và cách làm mới

Thói quen cũ	Vấn đề	Cách làm mới
Thêm "hãy suy nghĩ từng bước" vào mọi prompt	Mô hình frontier đã tự suy luận; chỉ tốn thêm token	Bỏ mặc định, chỉ giữ khi eval chứng minh có ích
"Hãy kiểm tra lại hai lần", "hãy thật kỹ lưỡng tối đa"	Nghi thức thừa, tăng chi phí mà không tăng chất lượng	Để mô hình tự kiểm tra; đặt tiêu chí đầu ra rõ ràng thay cho khẩu hiệu
Ép định dạng nháp bằng thẻ scratchpad	Scaffold từ thời mô hình yếu, dễ mâu thuẫn với chỉ dẫn khác	Bỏ hoặc rút gọn tối đa
Chèn nội dung thay đổi (thời gian, dữ liệu động) lên đầu prompt	Làm vỡ prompt cache theo nguyên tắc khớp tiền tố	Cố định lên đầu, nội dung thay đổi xuống cuối
Sửa prompt theo cảm tính	Không đo được tiến bộ, dễ overfitting vào vài ca quen thuộc	Eval có train/test split + hill climbing theo số liệu

Câu hỏi thường gặp

Bỏ hẳn câu "hãy suy nghĩ từng bước" có làm Claude trả lời kém đi không?

Theo bài talk, với các mô hình frontier hiện nay thì không: mô hình đã tự suy luận và tự quyết định khi nào cần suy nghĩ sâu. Khuyến nghị thực tế là kiểm chứng bằng eval trên chính bài toán của bạn thay vì giữ câu lệnh này vì thói quen.

Chạy prompt audit bằng lệnh gì?

Trong Claude Code: /claude-api prompt-audit cho code gọi Anthropic API, và /doctor prompt-audit (bí danh /checkup) cho cấu hình Claude Code. Công cụ sẽ phân loại từng dòng prompt và đề xuất diff để bạn duyệt.

Vì sao chỉ sửa một ký tự ở đầu prompt mà cache mất hết?

Vì prompt caching khớp theo tiền tố một cách nghiêm ngặt: cache được tính cho chuỗi ký tự tính từ đầu prompt. Đổi bất cứ ký tự nào trong phần tiền tố sẽ khiến toàn bộ phần sau không còn khớp với bản đã cache.

Các con số giảm 72% và 90% chi phí có đáng tin không?

Đây là số liệu từ benchmark nội bộ của Anthropic, được trình bày trong bài talk của Lance Martin và chưa qua kiểm chứng độc lập. Mức giảm thực tế phụ thuộc vào cấu trúc prompt và workload của từng hệ thống; cách chắc chắn là tự đo bằng eval trên hệ thống của mình.

Eval "leo lên được" nghĩa là gì?

Nghĩa là bộ đánh giá có thang đo đủ mịn để mỗi cải tiến nhỏ của prompt đều cho thấy điểm số thay đổi đo được, đồng thời có tập test tách riêng để tránh việc prompt được tối ưu quá mức vào đúng những ca đã biết trước (overfitting).

---

Nguồn: bài chia sẻ của Linh Vu trên nhóm Vietnam Java User Group, tổng hợp từ video "Your Old Prompts Are Making Claude Worse" — Lance Martin, Anthropic, tại AI Engineer New York (kênh AI Engineer trên YouTube). Các số liệu về chi phí là benchmark nội bộ của Anthropic như được trình bày trong video, chưa được kiểm chứng độc lập.