Prompt cũng nên được đối xử như code

Nếu prompt đang ảnh hưởng trực tiếp tới:

  • chất lượng câu trả lời
  • chất lượng code sinh ra
  • độ an toàn của hành vi agent

thì prompt không còn là “mẹo cá nhân” nữa. Nó là một phần của hệ thống làm việc.

Vì vậy, prompt nên có:

  • version
  • lịch sử thay đổi
  • owner
  • tiêu chí đánh giá

Vì sao đánh giá theo cảm giác là chưa đủ?

Nhiều team sửa prompt theo kiểu:

  • “bản này có vẻ hay hơn”
  • “mình thấy trả lời mượt hơn”
  • “lần này agent có vẻ thông minh hơn”

Vấn đề là cảm giác rất khó lặp lại.

Prompt tốt hơn phải được hiểu là:

  • bớt sai hơn
  • đúng format hơn
  • ít vượt scope hơn
  • ít cần sửa tay hơn

Với kế toán, có thể dịch các ý trên thành:

  • ít lệch số hơn
  • ít bỏ sót cột bắt buộc hơn
  • ít kết luận khi chưa đủ chứng từ hơn
  • ít phải sửa tay lại báo cáo hơn

Version prompt như thế nào?

Cách đơn giản nhất:

  • lưu prompt trong repo
  • mỗi thay đổi đi qua pull request
  • ghi rõ lý do sửa
  • nếu có thể, gắn ví dụ trước và sau

Ví dụ changelog prompt:

v1.2
- Làm rõ fallback khi thiếu dữ liệu
- Yêu cầu findings phải có file reference
- Giảm xu hướng lan man bằng length constraint

Chỉ cần làm được như vậy, team đã tốt hơn phần lớn các nhóm đang prompt theo trí nhớ.

Eval prompt là gì?

Eval là một tập bài kiểm tra nhỏ để xem prompt có đạt mục tiêu không.

Ví dụ với review agent, eval có thể gồm 5 case:

  1. Diff có bug null pointer
  2. Diff có regression performance
  3. Diff chỉ thay đổi format
  4. Diff thiếu context
  5. Diff có thay đổi bảo mật

Kỳ vọng không phải là output giống hệt nhau từng chữ. Kỳ vọng là:

  • có phát hiện đúng lỗi chính không
  • có giữ đúng format không
  • có bịa khi thiếu context không

Một nguyên tắc rất quan trọng: đổi từng thứ một

Khi sửa prompt, đừng đổi 5 chỗ cùng lúc.

Hãy đổi từng phần nhỏ:

  • thêm output contract
  • sửa fallback behavior
  • rút ngắn scope

Sau đó test lại.

Làm vậy bạn mới biết thay đổi nào thực sự có ích.

Những metric rất thực dụng để bắt đầu

Không cần hệ thống đo quá phức tạp ngay từ đầu. Team có thể dùng vài tiêu chí đơn giản:

  • Tỷ lệ output đúng format
  • Tỷ lệ phát hiện đúng lỗi quan trọng
  • Tỷ lệ cần người dùng sửa prompt lại
  • Tỷ lệ agent vượt scope
  • Tỷ lệ agent nói rõ khi không chắc

Nếu dùng cho nghiệp vụ dữ liệu hoặc kế toán, có thể thêm:

  • Tỷ lệ AI giữ đúng cấu trúc bảng yêu cầu
  • Tỷ lệ AI đánh dấu đúng các dòng “thiếu căn cứ”
  • Tỷ lệ AI không tự điền số liệu còn trống

Ý chính cần nhớ

Chuẩn hoá prompt mà không có version và eval thì mới đi được nửa đường.

Prompt mạnh không chỉ là prompt viết hay. Nó là prompt có thể đo, có thể review, và có thể cải tiến có kiểm soát.

Ở phần cuối, chúng ta sẽ gom lại thành một bộ Prompt Standard tối thiểu để team có thể áp dụng ngay trong repo.
Đọc tiếp Phần 5 — Bộ Prompt Standard tối thiểu cho team triển khai ngay.