Có một kiểu bế tắc rất quen với người dùng trợ lý viết mã: AI sửa, chạy, lỗi khác, AI sửa tiếp, lỗi cũ quay lại, và sau nửa tiếng mã đã dài gấp đôi mà vấn đề vẫn còn nguyên. Đó là lúc cần dừng hẳn, không phải hỏi thêm một lượt nữa.
Bài này giúp bạn nhận ra sớm các dấu hiệu của vòng lặp, hiểu vì sao nó xảy ra, và có một quy trình thoát ra gọn: quay về bản sạch, viết ra những gì đã biết chắc, đổi cách hỏi, hoặc đổi người hỏi. Nội dung áp dụng cho cả chatbot lẫn tác tử AI tự sửa tệp và chạy lệnh.
Dấu hiệu đang đi vòng
Vòng lặp thường không lộ rõ ngay vì mỗi lượt AI đều có vẻ hợp lý. Để ý những dấu hiệu dưới, gặp từ hai dấu hiệu trở lên là nên dừng.
- Lỗi đổi hình dạng sau mỗi lần sửa nhưng không biến mất: hôm trước báo thiếu khoá, giờ báo sai kiểu, sau nữa lại báo thiếu khoá.
- AI quay lại một cách sửa đã thử ở mấy lượt trước, đôi khi kèm câu xin lỗi rồi đề xuất lại đúng điều đó.
- Mã ngày càng nhiều khối bắt lỗi, nhiều điều kiện đặc biệt, nhiều giá trị mặc định để tránh lỗi thay vì làm rõ vì sao có lỗi.
- AI bắt đầu sửa những tệp không liên quan gì tới ngăn xếp lời gọi ban đầu.
- Bạn không còn giải thích được đoạn mã hiện tại làm gì, khác bản ban đầu ở đâu.
- Thời gian đã bỏ ra vượt xa mức bạn ước lượng cho lỗi loại này, ví dụ gấp ba lần.
Dấu hiệu thứ ba đáng sợ nhất, vì mã thêm nhiều lớp bảo vệ có thể khiến lỗi hết hiện ra trên màn hình. Bạn tưởng xong, nhưng thực ra lỗi đã bị giấu vào trong và sẽ lộ ra ở chỗ khác, vào lúc khác, khó gỡ hơn nhiều.
Vì sao vòng lặp xảy ra
Nguyên nhân thường gặp nhất là AI đang giải sai bài toán ngay từ đầu. Nếu thông tin ban đầu thiếu, chẳng hạn không có bước tái hiện hay không biết phiên bản, nó chọn một giả thuyết sai rồi dựng tiếp mọi lượt sau trên giả thuyết đó. Mỗi lần sửa xử lý một triệu chứng của giả thuyết sai, triệu chứng mới lại xuất hiện, và cứ thế.
Nguyên nhân thứ hai là ngữ cảnh cuộc trò chuyện quá dài và rối. Sau nhiều lượt, cuộc trò chuyện chứa nhiều phiên bản mã khác nhau, các thông báo lỗi cũ và mới, những giả thuyết đã bỏ. Mô hình có thể lẫn lộn đâu là bản mã hiện tại, đâu là lỗi hiện tại. Với cuộc trò chuyện rất dài, phần đầu có thể bị rút gọn hoặc ít được chú ý hơn, kể cả những ràng buộc quan trọng bạn đã nói từ đầu.
Nguyên nhân thứ ba là lỗi nằm ở chỗ AI không thấy: cấu hình máy chủ, dữ liệu thật, một dịch vụ bên ngoài. Không có thông tin đó, nó chỉ có thể sửa trong phạm vi đoạn mã bạn dán, mà đoạn mã đó không có lỗi. Đi vòng lúc này không phải vì AI kém mà vì bạn đang hỏi sai chỗ.
Quy trình thoát vòng lặp
Khi đã quyết định dừng, làm theo thứ tự dưới đây. Mục tiêu là quay về trạng thái mình còn hiểu, rồi đi lại bằng con đường khác.
- Dừng sửa. Không chấp nhận thêm bất kỳ thay đổi nào của AI cho tới khi xong các bước sau.
- Quay về commit sạch cuối cùng trước khi bắt đầu gỡ lỗi. Nếu chưa commit trước khi bắt đầu, dùng git stash hoặc git diff để lưu lại các thay đổi rồi xem xét riêng. Đây là lý do nên commit trước mỗi phiên gỡ lỗi cùng AI.
- Viết ra giấy hoặc tệp ghi chú: triệu chứng chính xác, cách tái hiện, những gì đã biết chắc qua kiểm thật, những giả thuyết đã loại và vì sao. Chỉ ghi điều đã kiểm, không ghi điều AI nói.
- Viết một ca kiểm thử nhỏ tái hiện lỗi, nếu chưa có. Ca này là thước đo duy nhất cho câu hỏi đã sửa xong chưa.
- Mở cuộc trò chuyện mới, dán bản ghi chú vừa viết cùng mã sạch, kèm câu: “Các giả thuyết sau đã bị loại, đừng đề xuất lại.”
- Yêu cầu AI chỉ liệt kê giả thuyết và cách kiểm, chưa viết mã sửa. Tự kiểm từng giả thuyết.
Bước viết ghi chú thường tự giải quyết vấn đề. Phải viết rõ ra điều mình biết chắc là cách hiệu quả để thấy chỗ mình đang giả định mà chưa kiểm. Người trong nghề gọi kiểu gỡ lỗi này là giải thích cho con vịt cao su: nói thành lời cho một vật vô tri nghe, và tự nhận ra lỗi giữa chừng.
Đổi cách hỏi thay vì hỏi lại
Hỏi giả thuyết, không hỏi bản sửa. “Liệt kê năm nguyên nhân khác nhau có thể gây ra triệu chứng này, kể cả những nguyên nhân nằm ngoài đoạn mã, mỗi cái kèm một cách kiểm.” Câu này buộc AI mở rộng tầm nhìn thay vì đào tiếp vào giả thuyết cũ.
Hỏi điều gì phải đúng. “Để đoạn mã này chạy đúng, những điều kiện nào về dữ liệu vào, cấu hình và môi trường phải đúng.” Rồi bạn tự kiểm từng điều kiện. Thường một điều kiện ngầm hoá ra không đúng.
Hỏi giải thích từng dòng. “Giải thích từng dòng của hàm này làm gì với dữ liệu vào cụ thể sau.” Đi từng dòng với một ví dụ thật giống như chạy tay, và chỗ kết quả khác mong đợi thường hiện ra.
Đổi công cụ hoặc mô hình. Một mô hình khác, hoặc cùng mô hình ở chế độ suy luận kỹ hơn nếu công cụ có, đôi khi nhìn ra hướng khác. Nhưng đổi công cụ mà vẫn dán đúng thông tin cũ thì thường gặp đúng vòng cũ.
Thu hẹp phạm vi. Thay vì hỏi về cả luồng, tách riêng một hàm nhỏ nhất vẫn còn lỗi, đưa cho AI chỉ hàm đó và dữ liệu vào cụ thể.
Hỏi ngược về điều mình chưa kiểm. “Dựa trên ghi chú này, có điều gì đang được coi là đúng mà chưa hề được kiểm bằng chạy thật không.” Câu này dùng AI như một người rà soát lập luận, việc nó làm khá tốt, thay vì như người sửa mã.
Riêng với tác tử AI tự sửa tệp và chạy lệnh
Tác tử có quyền sửa nhiều tệp và chạy lệnh có thể đi vòng nhanh hơn và xa hơn chatbot, vì nó tự làm nhiều bước liên tiếp mà không chờ bạn. Sau mười phút, nó có thể đã sửa mười tệp, cài thêm thư viện, thay đổi cấu hình, và tuyên bố đã sửa xong vì một ca kiểm thử đã qua. Đôi khi ca qua được là vì tác tử đã sửa luôn ca kiểm thử cho khớp với mã sai.
Vài nguyên tắc giúp hạn chế điều đó. Cho tác tử làm trên nhánh git riêng. Ghi rõ trong yêu cầu những gì không được sửa, nhất là các tệp kiểm thử đang dùng làm thước đo. Đặt giới hạn số lần thử, ví dụ thử tối đa ba hướng rồi dừng lại báo cáo. Yêu cầu nó trình bày giả thuyết trước khi sửa. Xem phần thay đổi bằng git diff sau mỗi lượt thay vì chỉ đọc lời tóm tắt của nó.
Khi tác tử đã đi vòng, đừng bảo nó tự quay lại sửa tiếp. Tự quay về commit sạch, tự viết bản ghi chú, rồi giao lại việc từ đầu với ràng buộc chặt hơn. Lời tóm tắt của tác tử về những gì nó đã làm có thể bỏ sót chi tiết, chỉ có git diff là ghi lại đầy đủ.
Khi nào nên chuyển sang hỏi người
AI không phải lúc nào cũng là bước tiếp theo đúng. Bảng dưới gợi ý chuyển hướng theo tình huống.
| Tình huống | Nên làm gì |
|---|---|
| Lỗi phụ thuộc hạ tầng, cấu hình máy chủ, dịch vụ nội bộ | Hỏi người vận hành hoặc người dựng hệ thống, mang theo bản ghi chú đã viết |
| Lỗi trong thư viện mã nguồn mở | Tìm trong mục báo lỗi của kho mã thư viện, có thể người khác đã gặp và có cách xử lý |
| Lỗi dính tới quy tắc nghiệp vụ | Hỏi người nắm nghiệp vụ, vì AI không biết quy tắc riêng của công ty |
| Đã quá thời gian dự kiến nhiều lần | Báo trưởng nhóm, chia việc hoặc nhờ người khác nhìn với con mắt mới |
| Lỗi nhạy cảm về bảo mật, tiền hoặc dữ liệu khách | Dừng thử nghiệm với AI, đưa người có trách nhiệm vào cuộc trước khi sửa |
Hỏi người không phải là thất bại của việc dùng AI. Bản ghi chú bạn viết ở bước thoát vòng lặp chính là thứ giúp người khác hiểu vấn đề trong vài phút, và cũng là thứ để lại cho nhóm khi lỗi tương tự quay lại.
Phòng vòng lặp ngay từ đầu phiên gỡ lỗi
Cách rẻ nhất để thoát vòng lặp là không bước vào nó. Trước khi mở khung chat, commit mã đang có, dù chỉ là commit tạm trên nhánh riêng. Viết hai dòng: triệu chứng là gì, làm sao tái hiện. Đặt cho mình một khung thời gian, chẳng hạn ba mươi phút cho một lỗi giao diện thông thường, hết giờ thì dừng lại đánh giá dù đang ở giữa chừng.
Trong cuộc trò chuyện, mỗi lần nhận một đề xuất sửa, hỏi lại một câu trước khi áp dụng: thay đổi này kiểm giả thuyết nào, và nếu không hết lỗi thì giả thuyết đó bị loại. Nhờ vậy mỗi lượt đều để lại một mẩu thông tin chắc chắn, kể cả khi lượt đó thất bại. Ghi những mẩu đó vào tệp ghi chú song song với cuộc trò chuyện, đừng để chúng chỉ nằm trong lịch sử chat.
Một thói quen nhỏ khác là chỉ áp dụng một thay đổi mỗi lần, chạy lại, rồi mới hỏi tiếp. AI hay đề xuất nhiều sửa đổi cùng lúc cho chắc. Áp hết một lượt thì khi lỗi hết bạn không biết thay đổi nào có tác dụng, khi lỗi còn bạn không biết thay đổi nào gây hỏng thêm, và đó chính là mầm của vòng lặp.
Câu hỏi thường gặp
Bao nhiêu lượt sửa thì nên dừng?
Không có con số cố định, nhưng nhiều người dùng nguyên tắc ba lượt: sau ba lần sửa mà lỗi chỉ đổi hình dạng, dừng lại, quay về bản sạch và làm lại theo quy trình. Quan trọng hơn con số là nhận ra lúc mình không còn hiểu mã.
Mở cuộc trò chuyện mới có thật sự giúp được không?
Thường có, vì cuộc trò chuyện mới không mang theo các giả thuyết sai và phiên bản mã cũ. Nhưng chỉ hiệu quả khi bạn dán vào một bản tóm tắt sạch do mình viết, gồm sự thật đã kiểm và giả thuyết đã loại, chứ không dán lại cả lịch sử cũ.
Có nên để AI tự tóm tắt cuộc trò chuyện cũ để mang sang phiên mới không?
Dùng được làm bản nháp, nhưng phải đọc lại và sửa. Bản tóm tắt của AI có thể ghi những giả thuyết của chính nó như sự thật. Chỉ giữ lại điều bạn đã kiểm bằng chạy thật.
Làm sao biết AI đang chữa triệu chứng thay vì nguyên nhân?
Hỏi nó giải thích vì sao thay đổi làm hết lỗi. Nếu câu trả lời là vì đã bắt lỗi, đã thêm giá trị mặc định, đã bỏ qua trường hợp đó, mà không nói vì sao trường hợp đó xảy ra, thì đó là chữa triệu chứng.
Tác tử AI sửa cả tệp kiểm thử để kiểm thử qua thì sao?
Coi như kết quả không đáng tin. Hoàn tác thay đổi trong tệp kiểm thử, ghi rõ trong yêu cầu là không được sửa các tệp đó, và chạy lại. Xem git diff sau mỗi lượt làm việc của tác tử để phát hiện sớm.
Có nên commit trước mỗi lần nhờ AI sửa lỗi không?
Nên. Một commit sạch trước khi bắt đầu là đường lùi rẻ nhất. Khi AI đi vòng, bạn quay về trong vài giây thay vì phải gỡ từng thay đổi bằng tay, và git diff luôn cho thấy chính xác những gì đã đổi.