Chỗ hỏng không nằm trong output — nó nằm trong một giả định ở bước hai

Khi kết quả sai mà không có dòng lỗi nào, đọc xuôi toàn bộ là cách chậm nhất. Chia đôi vùng nghi nhanh hơn nhiều

Đọc5 phút đọc
Chủ đềproduction · debugging · failure-modes
TL;DR

Output sai mà không có dòng lỗi nào, thì đọc tuần tự toàn bộ là cách chậm nhất — vì chỗ hỏng hiếm khi nằm trong output, nó nằm trong một giả định ở thượng nguồn rồi chảy xuôi xuống. Kỹ thuật thực chiến không phải đọc nhiều hơn mà là tìm thông minh hơn: chia đôi vùng nghi, hỏi đúng một câu xác nhận mỗi nhánh để loại đi một nửa, rồi lặp lại — bisect cho tới điểm hỏng thật trong vài câu hỏi, thay vì rà hết.

Agent làm xong một việc dài. Kết quả rõ ràng sai — con số không khớp, định dạng lệch, một thứ đáng lẽ có mà không có. Nhưng không có dòng lỗi nào. Không có gì đỏ lên chỉ chỗ. Bạn cuộn lên đầu, bắt đầu đọc lại sáu trăm dòng nó vừa làm, dòng một, dòng hai… và tới dòng hai trăm bạn vẫn chưa thấy gì sai. Mỗi bước, đọc riêng ra, đều có vẻ đúng.

Đó là vì bạn đang tìm sai chỗ. Cái sai không nằm ở nơi nó lộ ra. Nó nằm ở nơi nó bắt đầu — và hai nơi đó thường cách nhau rất xa.

01Lỗi chảy xuôi, nên đọc xuôi luôn đuổi theo cái bóng

Hãy hình dung công của agent như một dòng nước. Một giả định lệch ở thượng nguồn — nó hiểu sai một chữ trong yêu cầu, lấy nhầm một cột dữ liệu, đoán sai một định dạng — không gây lỗi ngay tại đó. Cái lệch đó trôi xuôi: mọi bước sau nó đều làm việc chăm chỉ và đúng đắn, chỉ là trên một tiền đề đã sai. Tới tận output cuối, cái lệch tích lại đủ lớn để bạn thấy. Nhưng tới lúc đó nó đã đi xa nơi nó sinh ra rất nhiều.

Đó là lý do đọc xuôi từ đầu là một cái bẫy thời gian. Bạn rà qua hàng loạt bước đúng — đúng so với tiền đề sai của chúng — và chúng trông đúng, vì chúng đúng thật. Bạn đang lội ngược dòng bằng cách bơi xuôi. Mỗi dòng đọc qua tốn công mà gần như không loại được gì, vì cái sai không phô ra ở bề mặt từng bước; nó nấp trong cái giao kèo giữa các bước.

Đọc xuôi toàn bộ

Rà từng bước từ đầu, theo thứ tự agent đã làm
Mỗi bước trông đúng — vì nó đúng so với tiền đề sai của nó
Đọc tuyến tính: nỗ lực tỉ lệ với độ dài, dễ nản và bỏ cuộc

Chia đôi vùng nghi

Bắt từ output sai, hỏi: nửa nào của đường đi đã hỏng?
Một câu xác nhận ở điểm giữa → loại được nguyên một nửa
Đọc theo log-nửa: vài câu hỏi là tới điểm hỏng thật

Khác biệt không phải chăm hơn hay lười hơn — là tuyến tính so với chia-đôi. Đọc xuôi sáu trăm dòng tốn công bằng sáu trăm; chia đôi liên tục thì khoảng mười câu hỏi là chạm đáy. Cùng một cái lỗi, hai cái giá rất khác.

02Bisect: chia đôi, hỏi xác nhận, loại nửa, lặp

Kỹ thuật mượn thẳng từ cách tìm một cuốn sách trong từ điển: bạn không lật từng trang, bạn mở giữa rồi quyết định nửa trước hay nửa sau. Áp vào việc truy lỗi agent, nó thành ba nhịp lặp lại:

CHIA ĐÔIHỎI XÁC NHẬNLOẠI NỬA · LẶP
Nhịp 1 — Chia đôi vùng nghi: cả đường đi gãy ở một trong bốn chỗ — hiểu sai yêu cầu, lấy sai đầu vào, logic sai, hay một bước trung gian sai. Chọn điểm giữa.

Nhịp 2 — Hỏi một câu xác nhận: "Ở bước này, giá trị X đang là bao nhiêu?" hoặc "Cho tôi xem đầu vào bạn dùng cho bước đó." Một dữ kiện kiểm được, không phải lời kể.

Nhịp 3 — Loại nửa rồi lặp: nếu điểm giữa còn đúng, lỗi ở nửa sau; nếu đã sai, lỗi ở nửa trước. Chia tiếp nửa còn lại.

Sức mạnh nằm ở nhịp hai: câu hỏi phải đòi một dữ kiện kiểm được, không phải một lời tự đánh giá. "Bước đó ổn không?" thì agent lại diễn cho bạn nghe — hỏi "giá trị cụ thể là gì" thì nó phải lộ ra cái thật.

Bốn vùng nghi ở nhịp một là cái khung tiện để chia: phần lớn lỗi nằm ở chỗ agent hiểu sai bạn muốn gì, hoặc lấy sai cái đầu vào — hai nguồn này thường ở thượng nguồn và bị bỏ qua nhiều nhất, vì ta hay mặc định "chắc nó hiểu đúng rồi" và lao xuống soi logic. Chia đôi buộc bạn kiểm cả cái mặc định đó, sớm, thay vì để nó là điểm mù.

03Tìm đúng điểm hỏng đáng hơn vá đúng triệu chứng

Có một cái lợi thứ hai, sâu hơn cả tốc độ. Khi đọc xuôi và mệt, người ta hay đầu hàng kiểu khác: thấy output sai thì vá ngay tại output — ép con số về đúng, chỉnh định dạng cho khớp. Cái lệch thượng nguồn vẫn còn nguyên; bạn chỉ dán băng lên chỗ máu chảy ra, không phải chỗ bị thương. Lần sau đầu vào hơi khác, nó lại chảy ra một kiểu khác, và bạn vá lại từ đầu.

Bisect không chỉ nhanh — nó dẫn bạn tới điểm hỏng thật, nơi đáng sửa. Sửa ở đó thì cả dòng nước phía dưới tự trong lại, một lần. Đó là khác biệt giữa dọn hậu quả và chữa nguyên nhân.

Nên lần tới output sai mà không có lỗi chỉ chỗ, đừng cuộn lên đầu và đọc. Hỏi một câu ở khúc giữa. Cái sai im lặng nhất vẫn để lại một dấu vết ở đúng cái bước nó sinh ra — bạn chỉ cần chia đôi đường đi đủ vài lần để dồn nó vào góc.

c
Người viết

Mỗi câu chuyện ở đây gói một bài học đã trả giá để học.

craftagentmột người vừa xây vừa học

Bạn đang xây gì với agent? Muốn trao đổi, phản biện, hay cùng làm một thứ gì đó — viết cho mình một dòng.

Viết thư hello@craftagent.cloud
58bài12cụmVI·ENsong ngữ

Nhận bài mới qua email

Ghi chép thực chiến về làm việc với AI agent — thi thoảng, không spam.