Kỹ thuật Verification-before-completion trong claude code Đảm bảo lỗi thực sự được khắc phục bằng bằng chứng cụ thể trước khi đánh dấu hoàn thành.

Kỹ thuật Verification-before-completion (Xác minh trước khi hoàn thành) là chốt chặn cuối cùng loại bỏ hội chứng "chạy ngon trên máy tôi" (It works on my machine). Trong quy trình vận hành hệ thống thực tế, việc một developer sửa xong code, không thấy báo lỗi và vội vã đánh dấu ticket Jira sang cột "Done" là nguyên nhân hàng đầu gây ra lỗi hồi quy (regression bug).

Kỹ thuật này yêu cầu thay đổi tư duy cơ bản: Code compile thành công không có nghĩa là lỗi đã được sửa. Lỗi chỉ thực sự được khắc phục khi có bằng chứng thực chứng đi kèm.

Dưới đây là 4 cấp độ xác minh bắt buộc để tạo ra bằng chứng cụ thể trước khi khép lại bất kỳ một tác vụ fix bug nào.

1. Bằng Chứng Cấp Độ Mã Nguồn (Code-Level Evidence)

Để chứng minh một lỗi đã được triệt tiêu, bằng chứng đầu tiên phải là một bài kiểm thử tự động. Nếu bạn sửa một lỗi chia cho 0 trong luồng tính toán phí trừ tiền thẻ vé tự động, bằng chứng không phải là đoạn code if (divisor === 0), mà là một bài test cố tình truyền số 0 vào và kỳ vọng hệ thống trả về đúng HTTP 400 thay vì sập toàn bộ tiến trình.

Quy trình hợp lệ:

• Viết bài test tái hiện đúng cái lỗi vừa văng (test đang báo Đỏ).

• Áp dụng code sửa lỗi.

• Chạy lại bài test (test báo Xanh).

• Bằng chứng: Một file *.spec.ts hoặc *_test.go được commit kèm theo đoạn code sửa lỗi.

2. Bằng Chứng Cấp Độ Môi Trường (Environment Parity)

Môi trường localhost luôn che giấu những rủi ro về mạng và cấu hình. Bằng chứng hợp lệ tiếp theo là kết quả thực thi trên môi trường staging hoặc qua Docker container giả lập kiến trúc production.

Nếu lỗi liên quan đến cấu hình Nginx reverse proxy, timeout của Redis cache, hoặc cấu trúc schema của PostgreSQL, bằng chứng phải là log thực thi từ các container này. Bạn cần tạo ra các kịch bản kiểm tra tải nhanh (ví dụ: dùng cURL hoặc Postman gửi hàng loạt request) để xác minh các lỗi như Race Condition đã thực sự biến mất khi chạy trong môi trường phân tán.

3. Bằng Chứng Từ Hệ Thống Giám Sát (Observability Evidence)

Đối với các kiến trúc backend phức tạp, đặc biệt là khi xử lý dữ liệu chuỗi thời gian hay log trạng thái thiết bị cứng liên tục, việc xác minh cần dựa trên dữ liệu tổng hợp thay vì một vài request đơn lẻ.

• Bằng chứng: Lịch sử truy vấn vào Elasticsearch, TimescaleDB hoặc hệ thống APM chứng minh tỷ lệ văng lỗi (Error Rate) của endpoint đó đã giảm thẳng đứng về 0.

• Hệ thống log không còn ghi nhận các exception rác liên quan đến luồng nghiệp vụ vừa can thiệp trong vòng ít nhất 30 phút sau khi deploy bản vá lên môi trường staging.

4. Ép Buộc AI Cung Cấp Bằng Chứng

Khi sử dụng các công cụ AI CLI (như Claude Code hoặc Cursor) để fix bug, trí tuệ nhân tạo rất hay có xu hướng báo cáo "Tôi đã sửa xong" ngay khi vừa thay đổi vài dòng code. Bạn phải thiết lập một rào chắn bằng Prompt để bắt AI xuất trình bằng chứng.

"Bạn vừa cập nhật logic xử lý luồng dữ liệu. Tuy nhiên, tôi chưa cho phép bạn kết thúc task này. Hãy viết một script Bash hoặc file kiểm thử dùng cURL gọi thẳng vào API mới sửa, cố tình truyền vào các tham số gây lỗi cũ, và in toàn bộ log HTTP Response ra terminal. Chỉ khi nào kết quả trả về đúng dữ liệu chuẩn xác và database cập nhật đúng trạng thái, task này mới được đánh giá là hoàn thành."

Việc đòi hỏi bằng chứng cụ thể biến quá trình fix bug từ một hành động mang tính cảm tính thành một khế ước kỹ thuật. Nó xây dựng tư duy phòng thủ vững chắc, đảm bảo mọi dòng code đưa lên production đều đã được kiểm định bằng những con số và log thực thi không thể chối cãi.