Lỗi của agent không đắt lúc nó xảy ra. Đắt lúc bạn không biết.

TL;DR

Chi phí của lỗi agent không phải lúc lỗi xảy ra — là lúc bạn phát hiện ra. Phát hiện ngay: rẻ. Phát hiện sau một ngày: đắt hơn nhiều. Phát hiện khi khách hàng báo lại: có khi gấp hai chục lần. Output agent trông pro nên bạn hay bỏ qua bước verify — đó chính là lý do khoảng cách phát sinh. Hai câu thêm vào cuối prompt có thể đóng khoảng cách đó trước khi nó mở rộng.

Bạn nhờ agent viết một bản phân tích. Nó trả về chín trang, có bảng biểu, có bullet, trông như thứ bạn mất nửa ngày mới làm ra.

Bạn lướt qua. Trông ổn. Gửi đi.

Ba ngày sau khách phát hiện một con số trong bảng tóm tắt bị tính sai — cách tính đúng là logic khác hẳn. Bạn phải viết lại phần đó, giải thích với khách, và mất thêm một buổi làm việc để patch lại những chỗ khác có dùng con số kia.

Tổng cộng là bao nhiêu? Không phải thời gian đọc lại chín trang ban đầu — vì bạn đã không đọc. Là thời gian viết lại + giải thích + patch + chi phí niềm tin đã mất một phần. Tất cả đến từ một lỗi mà nếu phát hiện ban đầu thì sửa trong năm phút.

01Chi phí tăng theo khoảng cách phát hiện

Phát hiện ngay khi nhận output

1× — sửa trong 5 phút

Phát hiện sau khi đã dùng 1–2 ngày

5–8× — sửa + trace lại các chỗ đã dùng

Phát hiện khi người khác đã dựa vào

15–25× — sửa + giải thích + patch hệ quả

Cùng một lỗi, ba chi phí hoàn toàn khác nhau. Biến kiểm soát duy nhất là khoảng cách giữa lúc lỗi xảy ra và lúc bạn phát hiện — và khoảng cách đó hoàn toàn nằm trong tay bạn.

Nguyên lý này không mới. Trong phát triển phần mềm, người ta biết từ lâu: bug được bắt trong code review rẻ hơn nhiều bug được bắt ở staging, và cả hai rẻ hơn nhiều bug đến production. Với agent output, nguyên lý y hệt — chỉ là nó ít hiển nhiên hơn vì output trông pro và ít lúc nào gây ra lỗi rõ ràng ngay lập tức.

02Output nào có rủi ro phát hiện muộn cao nhất

Không phải mọi output đều bình đẳng. Bốn loại này thường là nguồn của những lỗi phát hiện muộn và đắt tiền nhất:

Cần verify kỹ hơn bình thường

Output có con số — tính toán, báo cáo, tổng hợp dữ liệuagent rất giỏi làm cho số trông hợp lý; không có nghĩa số đó đúng; verify bằng cách tính lại ít nhất một con số đại diện

Output sẽ được người khác dùng làm căn cứ quyết địnhnếu người đọc tiếp theo hành động theo output này mà không verify thêm, lỗi của bạn trở thành lỗi của họ

Output agent tổng hợp từ nhiều nguồnagent giỏi combine thông tin nhưng dễ bỏ sót mâu thuẫn giữa các nguồn hoặc flatten những nuance quan trọng

Output trong domain bạn ít biếtkhi bạn không đủ kiến thức để đánh giá, bạn dễ tin output trông-có-vẻ-chuyên nghiệp — đây là chỗ lỗi im lặng nguy hiểm nhất

Output trông pro không phải dấu hiệu của output đúng. Đôi khi là ngược lại — output sai nhưng được viết tốt dễ lọt qua hơn output sai mà trông sai.

03Hai câu để đóng khoảng cách ngay tại nguồn

Cách rẻ nhất để giảm chi phí lỗi không phải review kỹ hơn sau khi nhận output. Là cho agent biết trước điều kiện verify — để nó tự flag nghi vấn trước khi bạn phải tìm:

Yêu cầu nó tự đánh dấu phần không chắc

"Trong output, đánh dấu [CHECK] vào bất kỳ chỗ nào bạn không chắc chắn hoặc cần tôi xác nhận thêm. Đừng để những phần đó trông giống như phần chắc chắn."

Yêu cầu nó nêu giả định

"Sau phần output, liệt kê ngắn các giả định quan trọng bạn đã dùng để tạo ra kết quả này. Nếu giả định sai, output sẽ sai theo cách nào?"

Hai câu này làm một việc quan trọng: biến lỗi im lặng thành lỗi có nhãn. Output có [CHECK] thì bạn biết chỗ nào cần đọc kỹ. Danh sách giả định thì bạn biết điều kiện output còn đúng — và khi nào thì không.

Tốc độ của agent chỉ là giá niêm yết. Tốc độ thực lĩnh là sau khi trừ thời gian sửa lại những thứ không được verify đúng lúc. Khoảng cách giữa hai con số đó — bạn hoàn toàn có thể kiểm soát, và nó bắt đầu từ câu hỏi bạn thêm vào trước khi nhận kết quả.