System Prompt với tiêu chí rõ ràng

Những điều bạn cần biết

Sai lầm lớn nhất trong prompt engineering ở môi trường production là dựa vào những chỉ dẫn mơ hồ. Các cụm từ như "hãy thận trọng", "chỉ báo cáo những phát hiện có độ tin cậy cao" hay "hãy dùng phán đoán tốt nhất của bạn" không đưa ra cho model bất kỳ ranh giới quyết định nào có thể hành động được. Chúng nghe có vẻ hợp lý — và chính vì vậy đề thi hay dùng chúng làm phương án gây nhiễu.

Cách tiếp cận đúng là dùng tiêu chí phân loại rõ ràng (explicit categorical criteria), xác định chính xác model nên gắn cờ điều gì và bỏ qua điều gì. So sánh hai system prompt sau đây cho một pipeline review code trong CI/CD:

Cách tiếp cận sai:

Review this code. Be conservative. Only report high-confidence findings.

Cách tiếp cận đúng:

Flag comments only when claimed behaviour contradicts actual code behaviour. Report bugs and security vulnerabilities. Skip minor style preferences and local patterns.

Prompt đầu tiên không cho model bất kỳ tiêu chí nào để áp dụng. "Thận trọng" mang nghĩa khác nhau tùy ngữ cảnh, còn "độ tin cậy cao" là một ngưỡng chủ quan mà model không thể tự hiệu chỉnh. Prompt thứ hai cung cấp các hạng mục cụ thể: cái gì cần báo cáo (bug, lỗ hổng bảo mật), cái gì cần bỏ qua (style, các quy ước cục bộ), và một điều kiện kích hoạt rõ ràng cho việc gắn cờ comment (mâu thuẫn giữa hành vi được khai báo và hành vi thực tế của code).

Vấn đề niềm tin bị đánh sập bởi dương tính giả

Tỷ lệ dương tính giả (false positive) cao ở một hạng mục sẽ phá hủy niềm tin của developer vào tất cả các hạng mục khác. Đây là một insight then chốt mà đề thi kiểm tra. Nếu những phát hiện "documentation mismatch" của bạn sai đến 40% số lần, developer sẽ ngừng đọc cả những phát hiện "lỗ hổng bảo mật" — dù những phát hiện đó chính xác tới 98%. Niềm tin không giới hạn ở từng hạng mục riêng lẻ; nó lan ra toàn bộ output.

Cách khắc phục nghe có vẻ phản trực giác nhưng lại hiệu quả: tạm thời tắt các hạng mục có tỷ lệ dương tính giả cao trong lúc bạn cải thiện prompt cho những hạng mục đó. Điều này lập tức khôi phục niềm tin vào các hạng mục đang hoạt động tốt. Sau đó bạn lặp lại quá trình tinh chỉnh tiêu chí của hạng mục có vấn đề bằng các ví dụ code cụ thể, và chỉ bật lại nó khi độ chính xác đã được cải thiện.

Đây không phải là từ bỏ hạng mục đó — mà là ưu tiên niềm tin của toàn hệ thống hơn là sự đầy đủ của từng hạng mục.

Hiệu chỉnh mức độ nghiêm trọng bằng ví dụ code

Việc định nghĩa các mức độ nghiêm trọng (severity) đòi hỏi ví dụ code cụ thể, chứ không phải mô tả bằng văn xuôi. So sánh:

Mô tả bằng văn xuôi (không đủ):

Critical: Issues that could cause system failures or data loss Minor: Issues that affect code readability but not functionality

Cách tiếp cận bằng ví dụ code (đúng):

Critical — Unsanitised user input in SQL query: query = f"SELECT * FROM users WHERE id = {user_input}" Minor — Inconsistent variable naming: userName vs user_name in the same module

Mô tả bằng văn xuôi buộc model phải tự diễn giải "có thể gây ra lỗi hệ thống" nghĩa là gì. Ví dụ code loại bỏ hoàn toàn sự mơ hồ đó. Khi model nhìn thấy các mẫu code thực tế đã được phân loại ở từng mức độ nghiêm trọng, nó sẽ đưa ra phân loại nhất quán qua các lần gọi khác nhau.

Tại sao lọc theo độ tin cậy lại thất bại

Đề thi thường xuyên đưa ra "chỉ báo cáo những phát hiện có độ tin cậy cao" như một đáp án gây hấp dẫn. Nghe có vẻ như kỹ thuật tốt — lọc theo độ tin cậy, chỉ giữ lại những tín hiệu mạnh. Nhưng độ tin cậy do chính LLM tự báo cáo lại được hiệu chỉnh rất kém. Model thường tự tin cao độ vào những phát hiện sai, trong khi lại không chắc chắn về những phát hiện đúng. Điểm tin cậy có ích cho việc định tuyến (gửi những phát hiện có độ tin cậy thấp cho con người review, như đã trình bày ở Task Statement 4.6), nhưng chúng không thể thay thế cho các tiêu chí rõ ràng xác định ngay từ đầu thế nào là một phát hiện hợp lệ.

Thứ tự ưu tiên là: tiêu chí rõ ràng trước, định tuyến theo độ tin cậy sau. Đừng bao giờ bỏ qua bước đầu tiên.

Bẫy thi

Tình huống luyện tập

Không tìm thấy câu hỏi luyện tập "q-4-1-001".

Bài tập thực hành

Nguồn tham khảo

• Claude Certified Architect Foundations Exam Guide — Task Statement 4.1 — Anthropic
• Prompt Engineering Overview — Anthropic
• Building with Claude API (Skilljar) — Anthropic