Một bản sửa đáng tin cần giải thích được vì sao lỗi xảy ra và có cách kiểm tra lại. Với AI agent, hãy giữ vòng lặp ngắn: tái hiện, đặt giả thuyết, kiểm chứng rồi mới sửa.
A reliable fix explains why the failure occurred and provides a way to verify it. Keep the AI-assisted loop short: reproduce, form a hypothesis, test it, then fix.
Trong bài nàyOn this page
1. Ghi trạng thái trước khi thử sửa1. Capture the state before editing
Ghi phiên bản mã, môi trường, đầu vào, kết quả mong đợi và lỗi nguyên văn. Xác định lỗi luôn xảy ra hay phụ thuộc thời điểm, tài khoản hoặc dữ liệu. Nếu không tái hiện được, thu thập thêm bằng chứng trước khi thay nhiều thành phần.
systematic-debugging giúp giữ thứ tự này. Cài và đọc runbook trước; sau đó giao cho agent một phạm vi hẹp:
Record the source revision, environment, inputs, expected outcome and exact error. Determine whether it is consistent or depends on timing, account or data. If reproduction is missing, gather evidence before changing several components.
systematic-debugging helps preserve this order. Install and read the runbook, then give the agent a narrow scope:
Điều tra lỗi tổng giỏ hàng bỏ qua số lượng sản phẩm.
Trước tiên tạo ca tái hiện nhỏ nhất và ghi expected/actual.
Đưa ra một giả thuyết kèm bằng chứng trước khi sửa.
Không đổi dependency hoặc refactor phần ngoài phạm vi.
Sau bản sửa, chạy lại ca lỗi và kiểm tra các trường hợp liên quan.Investigate a cart total that ignores item quantity.
First create the smallest failing case and record expected/actual.
State one evidence-backed hypothesis before editing.
Do not change dependencies or refactor unrelated code.
After the fix, repeat the failing case and relevant boundary checks.2. Tạo ca lỗi tối thiểu2. Create a minimal failing case
Đây là ví dụ Python minh họa, dùng giá nguyên theo đơn vị xu và số lượng nguyên không âm. Nó chỉ tính tiền hàng, chưa bao gồm thuế, giảm giá hay kiểm tra dữ liệu đầu vào. Lưu đoạn sau vào tệp thử riêng và chạy bằng Python 3 thông thường; assertion phải thất bại.
This illustrative Python example uses integer cents and nonnegative integer quantities. It covers a subtotal, without tax, discounts or input validation. Save it in a separate scratch file and run normal Python 3; the assertion is expected to fail.
def cart_total(items):
return sum(item["price_cents"] for item in items)
items = [{"price_cents": 1250, "quantity": 2}]
assert cart_total(items) == 2500Actual là 1.250; expected là 2.500. Ca lỗi không cần database, API hay UI nên có thể kiểm tra nhanh. Trong dự án thật, giữ ca tối thiểu đủ thể hiện lỗi và lưu fixture theo quy ước test hiện có.
The actual subtotal is 1,250; the expected subtotal is 2,500. No database, API or UI is needed to demonstrate it. In a real project, keep the minimal inputs that preserve the failure and use the existing fixture conventions.
3. Kiểm tra một giả thuyết tại một thời điểm3. Test one hypothesis at a time
Giả thuyết cụ thể: hàm chỉ cộng price_cents, không đọc quantity. Thay số lượng 2 bằng 3 mà kết quả không đổi sẽ củng cố giả thuyết. Đọc luồng dữ liệu để xác nhận giá truyền vào là đơn giá, chưa phải thành tiền của dòng.
Nếu upstream đã nhân số lượng, thêm phép nhân ở đây có thể tạo lỗi mới. Vì vậy, cần đối chiếu hợp đồng dữ liệu hoặc test của nơi gọi. Với lỗi nhiều tầng, theo dấu một đầu vào qua từng ranh giới và tránh ghi token, thông tin đăng nhập hoặc dữ liệu riêng vào log.
A specific hypothesis is that the function sums price_cents without reading quantity. Changing quantity from 2 to 3 while the total stays constant supports that explanation. Follow the input path to establish that the price is a unit price rather than an already computed line total.
If upstream code already multiplies quantity, doing it again would introduce a defect. Check the data contract or caller tests. For failures crossing several layers, trace one input across boundaries without logging tokens, credentials or private data.
4. Sửa đúng nguyên nhân và giữ kiểm tra hồi quy4. Fix the cause and retain regression checks
Với hợp đồng dữ liệu đã nêu, bản sửa nhỏ là nhân đơn giá với số lượng cho từng dòng. Đoạn sau có cả ca ban đầu và kiểm tra giỏ trống, nhiều dòng:
Under the stated input contract, the small fix multiplies unit price by quantity for each row. This version includes the original case, an empty cart and multiple rows:
def cart_total(items):
return sum(
item["price_cents"] * item["quantity"]
for item in items
)
assert cart_total([{"price_cents": 1250, "quantity": 2}]) == 2500
assert cart_total([]) == 0
assert cart_total([
{"price_cents": 1250, "quantity": 2},
{"price_cents": 300, "quantity": 3},
]) == 3400Đưa assertion vào bộ test hiện có của dự án để nó chạy trong CI. Tránh thêm một framework chỉ để kiểm tra phép tính này. Với sửa đổi ảnh hưởng hợp đồng API hoặc nhiều tầng, chạy thêm các test tương ứng; ghi rõ nếu chưa có môi trường thực hiện.
Move the assertions into the existing test suite so CI exercises them. A new framework is unnecessary for this arithmetic. If the fix affects an API contract or multiple layers, run the corresponding checks and identify any unavailable environment.
5. Bàn giao cả bằng chứng và giới hạn5. Report evidence and limits
Báo cáo nên nêu ca lỗi trước sửa, nguyên nhân, phần mã thay đổi và các kiểm tra đã chạy sau sửa. Nếu chỉ kiểm tra hàm thuần, đừng mô tả rằng toàn bộ checkout hoặc thanh toán đã được xác minh.
Review diff cuối để loại thay đổi thừa và xác nhận không bỏ mất logging hoặc test tạm cần chuyển thành regression test. Một ví dụ thực phức tạp hơn là race condition khi VAS cập nhật manifest JSON; ở đó, kiểm tra phải điều khiển thời điểm giữa các tiến trình.
Report the pre-fix failure, cause, changed code and post-fix checks. If only a pure function was exercised, do not claim the entire checkout or payment flow was verified.
Review the final diff for unrelated edits and make sure useful temporary checks become maintained regression tests. A more complex real example is the race condition in VAS manifest updates, where testing must control timing between processes.