Nguyen Le PhongNguyen Le Phong

Điều AI không thể biết chỉ từ prompt

Một reflection thực tế về lý do prompt là chưa đủ: AI cần source context, runtime evidence, domain constraint và judgment của con người để trở thành trợ giúp engineering hữu ích.

Prompt nhìn khá rõ: làm import flow an toàn hơn. Nó gọi tên file, mô tả symptom, và yêu cầu test. Một model có thể tạo ra patch nghe hợp lý từ câu đó. Nhưng những fact quan trọng không nằm trong câu đó. Chúng nằm trong retry job cũ, support runbook, tenant boundary, file CSV kỳ lạ một customer vẫn gửi, và alert chỉ fire sau nửa đêm.

Một engineer nhìn laptop có các khối code trừu tượng trong khi các thẻ trống và system sketch nằm cạnh trên bàn.
Prompt có thể hỏi một câu trả lời, nhưng evidence xung quanh mới quyết định câu trả lời đó có thuộc về system hay không.

Đây là giới hạn đầu tiên nên tôn trọng. Prompt không phải là system. Nó là request từ một góc nhìn. Nó có thể chứa vấn đề visible, nhưng thường thiếu constraint khiến solution an toàn. AI có thể rất hữu ích trong frame nó nhận được. Nó yếu hơn nhiều trong việc biết frame nào đang thiếu.

Source code thay đổi điều này. Import thật, call site, test, feature flag, schema và error handling path kể một câu chuyện mà prompt không thể tự mang hết. Đôi khi fix được yêu cầu đã có trong một helper. Đôi khi change đúng phải nằm ở usecase, không phải handler. Đôi khi bug visible với user đến từ data shape, không phải function được gọi tên trong prompt. Không có source context, model đang đoán từ cái bóng.

Runtime evidence cũng quan trọng. Log, trace, failed job, database row, browser screenshot và exact error text giữ câu trả lời trung thực. Một explanation generated có thể nghe bình tĩnh mà vẫn sai về chuyện đã xảy ra. Change càng nghiêm túc, công việc càng nên chạm vào reality trước khi chạm vào production.

Domain rule là lớp còn thiếu khác. AI có thể infer pattern phổ biến, nhưng nó không tự biết invariant nào team bạn xem là thiêng. Nó không biết money phải append-only, tenant scoping phải xảy ra trong repository query, mobile client vẫn phụ thuộc một field deprecated, hay operational kill switch tồn tại vì một incident cũ từng làm đau user thật.

Vì vậy context engineering không chỉ là viết prompt dài hơn. Prompt dài có thể giúp, nhưng discipline sâu hơn là quyết định evidence nào assistant được phép dựa vào. Đưa spec cho nó. Đưa failing test. Đưa file liên quan. Đưa log. Rồi yêu cầu nó nói rõ uncertainty thay vì lấp gap bằng confidence.

Judgment của con người vẫn load-bearing vì phải có ai đó quyết định answer generated có fit system mình thật sự own hay không. Judgment đó không phải approval ceremony ở cuối. Nó shape câu hỏi, chọn source, từ chối shortcut nghe hợp lý nhưng không an toàn, và verify result. Con người không cần type từng dòng. Nhưng con người cần giữ responsibility ở gần.

Một thói quen hữu ích là bắt assistant chỉ ra grounding trong evidence local. File nào support điều này? Test nào sẽ fail nếu không có nó? Log line nào chứng minh symptom? Domain rule nào bảo vệ edge case? Nếu answer không chỉ ngược lại evidence, hãy xem nó là draft hypothesis, chưa phải implementation plan.

AI hữu ích hơn khi ta ngừng bắt prompt mang nhiều hơn sức chứa của nó. Prompt bắt đầu conversation. System mới kết thúc conversation đó. Trước khi accept một câu trả lời từ AI, evidence nào ngoài prompt sẽ làm bạn tự tin hơn rằng câu trả lời đó thuộc về system?

Bạn thấy bài viết thế nào?