Cách dùng Vibe Coding để tìm và sửa lỗi trong dự án

• Bùi Tấn Lực
• 103
• 12/10/2026

Trong quá trình phát triển phần mềm, việc tìm và sửa lỗi thường tiêu tốn nhiều thời gian hơn dự kiến. Một lỗi nhỏ trong xử lý dữ liệu có thể khiến nhiều chức năng hoạt động sai, trong khi một thay đổi tưởng chừng đơn giản lại có thể gây ra lỗi ở những phần khác của hệ thống. Với các dự án có nhiều tệp mã nguồn, thư viện phụ thuộc và quy trình xử lý phức tạp, việc xác định chính xác nguyên nhân càng trở nên khó khăn.

Vibe Coding mang đến một cách tiếp cận mới bằng cách kết hợp mô tả vấn đề bằng ngôn ngữ tự nhiên với khả năng phân tích, đề xuất và chỉnh sửa mã nguồn của AI. Thay vì tự đọc toàn bộ chương trình để tìm từng dòng có khả năng gây lỗi, lập trình viên có thể cung cấp thông tin về hiện tượng gặp phải, yêu cầu AI kiểm tra luồng xử lý và đề xuất phương án khắc phục.

Tuy nhiên, sử dụng AI không đồng nghĩa với việc chỉ cần sao chép thông báo lỗi rồi yêu cầu sửa là có thể giải quyết triệt để vấn đề. Nếu không cung cấp đủ ngữ cảnh, AI có thể sửa nhầm nguyên nhân, tạo ra lỗi mới hoặc thay đổi hành vi vốn đang hoạt động đúng. Vì vậy, điều quan trọng là phải biết cách tổ chức quá trình tìm lỗi, kiểm chứng giả thuyết và đánh giá kết quả sau khi sửa.

Bài viết này hướng dẫn cách dùng Vibe Coding để tìm và sửa lỗi trong dự án theo một quy trình thực tế, từ việc thu thập thông tin ban đầu đến phân tích nguyên nhân, chỉnh sửa mã nguồn và xác nhận chương trình đã hoạt động đúng.

Vibe Coding giúp tìm và sửa lỗi trong dự án như thế nào?

Vibe Coding là phương pháp phát triển phần mềm trong đó lập trình viên sử dụng ngôn ngữ tự nhiên để mô tả yêu cầu, trao đổi với AI và định hướng quá trình tạo hoặc chỉnh sửa mã nguồn. Khi áp dụng vào việc xử lý lỗi, phương pháp này biến AI thành một công cụ hỗ trợ phân tích và sửa chữa, thay vì chỉ sử dụng để viết chức năng mới.

AI có thể đọc những đoạn mã được cung cấp, phân tích mối liên hệ giữa các hàm, giải thích thông báo lỗi, đưa ra giả thuyết về nguyên nhân và đề xuất cách khắc phục. Khi được tích hợp vào môi trường phát triển có quyền truy cập mã nguồn, công cụ còn có thể tìm kiếm tệp liên quan, chỉnh sửa mã và hỗ trợ chạy các lệnh kiểm tra phù hợp.

Phân biệt tìm triệu chứng và tìm nguyên nhân gốc

Một trong những giá trị quan trọng nhất của Vibe Coding là hỗ trợ lập trình viên đi từ hiện tượng quan sát được đến nguyên nhân thực sự gây ra lỗi. Hai vấn đề này không phải lúc nào cũng nằm ở cùng một vị trí.

Ví dụ, người dùng nhấn nút đăng nhập nhưng hệ thống liên tục trả về thông báo không hợp lệ. Nguyên nhân có thể nằm ở giao diện gửi sai tên trường dữ liệu, API xử lý không đúng định dạng, truy vấn cơ sở dữ liệu không tìm thấy tài khoản hoặc logic xác thực có điều kiện sai.

Nếu chỉ yêu cầu AI sửa thông báo đăng nhập, công cụ có thể đề xuất thay đổi phần giao diện mà không giải quyết được vấn đề. Ngược lại, nếu yêu cầu AI lần theo luồng dữ liệu từ thao tác người dùng đến kết quả xác thực, khả năng xác định đúng nguyên nhân sẽ cao hơn.

Khi sử dụng Vibe Coding để tìm lỗi, nên phân biệt ba cấp độ sau:

• Triệu chứng: Hiện tượng có thể quan sát được, chẳng hạn trang trắng, dữ liệu không hiển thị hoặc API trả về mã lỗi.
• Nguyên nhân trực tiếp: Thành phần khiến hiện tượng xảy ra, chẳng hạn biến nhận giá trị null nhưng vẫn được sử dụng như một đối tượng.
• Nguyên nhân gốc: Lý do khiến trạng thái không hợp lệ xuất hiện, chẳng hạn dữ liệu đầu vào không được kiểm tra hoặc một hàm trước đó không trả về kết quả như thiết kế.

Việc phân biệt các cấp độ này giúp tránh tình trạng sửa biểu hiện bên ngoài nhưng để nguyên vấn đề bên trong. Một phương án sửa tốt cần giải quyết được nguyên nhân phù hợp với bằng chứng, đồng thời hạn chế ảnh hưởng đến những chức năng không liên quan.

Những loại lỗi AI có thể hỗ trợ xử lý

Vibe Coding có thể hỗ trợ nhiều công việc gỡ lỗi khác nhau, nhưng mức độ hiệu quả phụ thuộc vào thông tin đầu vào, công cụ đang sử dụng và khả năng kiểm tra thực tế của môi trường phát triển.

Loại lỗi	Khả năng hỗ trợ của AI	Thông tin nên cung cấp
Lỗi cú pháp	Phát hiện dấu ngoặc thiếu, câu lệnh sai cấu trúc hoặc cách sử dụng cú pháp không hợp lệ.	Đoạn mã, thông báo lỗi và phiên bản ngôn ngữ.
Lỗi logic	Phân tích điều kiện, vòng lặp, giá trị trả về và luồng xử lý có thể dẫn đến kết quả sai.	Kết quả mong muốn, kết quả thực tế và các bước tái hiện.
Lỗi API	Kiểm tra phương thức HTTP, cấu trúc dữ liệu, cách xử lý phản hồi và các nhánh lỗi.	Request, response, mã trạng thái và đoạn mã liên quan.
Lỗi cơ sở dữ liệu	Hỗ trợ phân tích truy vấn, kiểu dữ liệu, quan hệ giữa các bảng và cách xử lý kết quả.	Cấu trúc bảng, truy vấn, thông báo lỗi và dữ liệu mẫu đã ẩn thông tin nhạy cảm.
Lỗi giao diện	Kiểm tra sự kiện, trạng thái giao diện, điều kiện hiển thị và quá trình gọi API.	Mô tả thao tác, lỗi trên trình duyệt và mã nguồn liên quan.
Lỗi môi trường	Đối chiếu cấu hình, phiên bản thư viện và sự khác biệt giữa các môi trường chạy.	Thông tin môi trường, log khởi động và cấu hình đã loại bỏ bí mật.
Lỗi hiệu năng	Đề xuất điểm nghẽn tiềm năng và cách đo đạc để xác minh.	Thời gian thực thi, log, số liệu đo và đoạn mã cần phân tích.

Không nên mặc định AI có thể tự phát hiện mọi lỗi chỉ bằng cách đọc mã nguồn. Một số vấn đề chỉ xuất hiện khi chương trình chạy với dữ liệu cụ thể, khi có nhiều người dùng thao tác đồng thời hoặc khi hệ thống kết nối với dịch vụ bên ngoài. Trong các trường hợp này, AI cần kết hợp với log, công cụ gỡ lỗi, kiểm thử và dữ liệu quan sát từ môi trường thực tế.

Chuẩn bị dự án trước khi sử dụng AI gỡ lỗi

Trước khi yêu cầu AI sửa mã nguồn, cần chuẩn bị một phạm vi làm việc rõ ràng. Đây là bước dễ bị bỏ qua nhưng có ảnh hưởng lớn đến chất lượng kết quả. Nếu AI không hiểu cấu trúc dự án, không biết lỗi xảy ra trong hoàn cảnh nào hoặc không có cách xác nhận kết quả, các đề xuất sửa chữa thường mang tính phỏng đoán.

Khoanh vùng chức năng đang gặp lỗi

Không nên bắt đầu bằng yêu cầu chung chung như kiểm tra toàn bộ dự án và sửa tất cả lỗi. Với một hệ thống có nhiều chức năng, yêu cầu này dễ khiến AI tập trung vào những đoạn mã không liên quan, đề xuất thay đổi quá rộng hoặc đưa ra một danh sách vấn đề khó kiểm chứng.

Thay vào đó, hãy xác định rõ chức năng đang gặp sự cố. Nếu lỗi xảy ra khi người dùng lưu thông tin cá nhân, phạm vi ban đầu có thể bao gồm biểu mẫu giao diện, hàm xử lý sự kiện, API cập nhật thông tin, lớp nghiệp vụ và truy vấn cơ sở dữ liệu liên quan.

Việc khoanh vùng không có nghĩa là chỉ kiểm tra đúng một tệp. Một lỗi có thể bắt nguồn từ thành phần khác với nơi biểu hiện được nhìn thấy. Mục tiêu là xác định luồng xử lý có liên quan để AI lần theo các thành phần cần thiết mà không thay đổi toàn bộ dự án.

Với một dự án PHP, chẳng hạn, luồng xử lý lưu thông tin khách hàng có thể đi qua các thành phần sau:

1. Biểu mẫu HTML thu thập dữ liệu từ người dùng.
2. JavaScript kiểm tra dữ liệu và gửi yêu cầu đến máy chủ.
3. PHP tiếp nhận request và kiểm tra dữ liệu đầu vào.
4. Lớp nghiệp vụ xử lý quy tắc cập nhật thông tin.
5. Truy vấn cơ sở dữ liệu ghi nhận thay đổi.
6. Máy chủ trả về kết quả để giao diện thông báo cho người dùng.

Nếu thông tin không được lưu, cần kiểm tra từng điểm chuyển tiếp trong luồng này thay vì mặc định truy vấn SQL là nguyên nhân. Cách tiếp cận tương tự cũng áp dụng cho các dự án sử dụng Laravel, Node.js, Python, Java hoặc những công nghệ khác.

Thu thập thông báo lỗi và cách tái hiện

AI thường đưa ra nhận định chính xác hơn khi có dữ liệu thực tế thay vì chỉ nhận mô tả rằng chương trình không hoạt động. Trước khi viết prompt, hãy thu thập những thông tin có thể quan sát và tái hiện được.

• Các bước gây ra lỗi: Người dùng đã làm gì trước khi lỗi xuất hiện?
• Kết quả thực tế: Hệ thống hiển thị thông báo nào, trả về dữ liệu gì hoặc dừng ở bước nào?
• Kết quả mong muốn: Chức năng cần hoạt động như thế nào khi không có lỗi?
• Thông báo lỗi: Nội dung exception, stack trace, mã trạng thái HTTP hoặc lỗi trên trình duyệt.
• Thời điểm phát sinh: Lỗi xuất hiện sau khi cập nhật mã nguồn, nâng cấp thư viện, thay đổi cấu hình hay nhập một loại dữ liệu mới?
• Phạm vi ảnh hưởng: Lỗi xảy ra với tất cả người dùng hay chỉ một trường hợp dữ liệu nhất định?

Ví dụ, mô tả “chức năng tìm kiếm bị lỗi” chưa cung cấp đủ thông tin. Mô tả cụ thể hơn sẽ hữu ích hơn: “Khi tìm kiếm từ khóa có dấu tiếng Việt, hệ thống trả về kết quả rỗng. Tìm kiếm từ khóa không dấu vẫn hoạt động. Lỗi xuất hiện trên môi trường triển khai sau khi chuyển cơ sở dữ liệu, còn môi trường phát triển vẫn trả về kết quả bình thường”.

Từ thông tin này, AI có thể ưu tiên kiểm tra cách chuẩn hóa chuỗi, bộ mã hóa ký tự, collation của cơ sở dữ liệu và sự khác biệt cấu hình giữa hai môi trường. Đây vẫn là các giả thuyết cần kiểm chứng, nhưng có cơ sở rõ ràng hơn so với việc sửa mã theo cảm tính.

Bảo vệ mã nguồn và dữ liệu trước khi chỉnh sửa

AI có thể đề xuất thay đổi nhiều tệp trong quá trình gỡ lỗi. Vì vậy, cần bảo đảm rằng mọi chỉnh sửa đều có thể được xem xét, so sánh và khôi phục khi cần thiết.

• Tạo một nhánh Git riêng cho việc xử lý lỗi hoặc lưu lại trạng thái ổn định trước khi sửa.
• Kiểm tra các thay đổi chưa được commit để tránh ghi đè công việc đang thực hiện.
• Sao lưu dữ liệu quan trọng trước khi chạy các thao tác có thể ảnh hưởng đến cơ sở dữ liệu.
• Không cung cấp mật khẩu, API key, token truy cập hoặc dữ liệu cá nhân thật cho AI nếu không cần thiết.
• Không tự động chạy các lệnh xóa dữ liệu, thay đổi cấu trúc cơ sở dữ liệu hoặc triển khai lên máy chủ thật khi chưa xem xét tác động.
• Ưu tiên sử dụng dữ liệu thử nghiệm và môi trường phát triển để tái hiện lỗi.

Đặc biệt, khi sử dụng công cụ Vibe Coding có quyền đọc hoặc ghi tệp trong dự án, cần kiểm tra phạm vi quyền truy cập và các lệnh mà công cụ có thể thực thi. Không nên cho phép AI tự ý thay đổi cấu hình bảo mật, vô hiệu hóa cơ chế xác thực hoặc loại bỏ các bước kiểm tra chỉ để khiến thông báo lỗi biến mất.

Mục tiêu của việc chuẩn bị là tạo ra một môi trường mà trong đó mọi giả thuyết đều có thể được kiểm chứng, mọi thay đổi đều có thể truy vết và mọi kết quả không đạt yêu cầu đều có thể khôi phục.

Cách viết prompt để AI xác định đúng nguyên nhân gây lỗi

Chất lượng của prompt ảnh hưởng trực tiếp đến cách AI phân tích và xử lý vấn đề. Một yêu cầu tốt không nhất thiết phải dài, nhưng cần xác định được hiện tượng, phạm vi kiểm tra, những gì đã biết và kết quả cần đạt.

Thay vì yêu cầu AI lập tức viết lại đoạn mã, hãy hướng dẫn công cụ thực hiện quá trình phân tích theo từng bước. Cách làm này giúp giảm nguy cơ sửa sai nguyên nhân và tạo ra cơ sở để đánh giá từng đề xuất.

Sử dụng cấu trúc prompt gồm bốn thành phần

Một prompt gỡ lỗi có thể được xây dựng từ bốn thành phần chính: bối cảnh, hiện tượng, phạm vi phân tích và yêu cầu đầu ra.

• Bối cảnh: Giới thiệu ngôn ngữ lập trình, framework, chức năng và môi trường đang sử dụng.
• Hiện tượng: Mô tả các bước tái hiện, kết quả thực tế, kết quả mong muốn và thông báo lỗi.
• Phạm vi phân tích: Chỉ rõ những tệp hoặc luồng xử lý cần kiểm tra, đồng thời cho phép AI đề xuất mở rộng phạm vi nếu có bằng chứng.
• Yêu cầu đầu ra: Yêu cầu nêu giả thuyết, dẫn chứng từ mã nguồn, cách kiểm tra và phương án sửa tối thiểu.

Có thể sử dụng mẫu prompt sau để bắt đầu một phiên gỡ lỗi:

Hãy đóng vai trò là lập trình viên hỗ trợ phân tích lỗi trong dự án hiện tại.

Bối cảnh:
- Ngôn ngữ và framework: [ghi công nghệ đang sử dụng].
- Chức năng gặp lỗi: [mô tả chức năng].
- Môi trường xảy ra lỗi: [local, staging hoặc production].

Hiện tượng:
- Các bước tái hiện: [liệt kê từng bước].
- Kết quả thực tế: [mô tả hiện tượng].
- Kết quả mong muốn: [mô tả hành vi đúng].
- Thông báo lỗi hoặc log: [dán thông tin đã loại bỏ dữ liệu nhạy cảm].

Yêu cầu:
1. Kiểm tra luồng xử lý liên quan trước khi đề xuất sửa mã.
2. Xác định các nguyên nhân có khả năng xảy ra và nêu bằng chứng cho từng nguyên nhân.
3. Phân biệt điều đã xác minh với giả thuyết chưa được kiểm tra.
4. Đề xuất cách kiểm chứng nguyên nhân bằng log, kiểm thử hoặc dữ liệu đầu vào phù hợp.
5. Chưa chỉnh sửa mã nguồn khi chưa xác định được nguyên nhân có cơ sở.
6. Ưu tiên phương án sửa nhỏ nhất, không thay đổi hành vi của các chức năng không liên quan.
7. Nêu rõ những kiểm thử cần thực hiện sau khi sửa.

Trước tiên, hãy phân tích và trình bày kế hoạch kiểm tra.
Không tự ý thay đổi cấu trúc dự án hoặc loại bỏ các cơ chế bảo mật hiện có.

Mẫu này có thể dùng với nhiều công cụ Vibe Coding khác nhau. Nếu công cụ có khả năng đọc toàn bộ workspace, có thể yêu cầu nó tìm các tệp liên quan trực tiếp trong dự án. Nếu chỉ sử dụng chatbot thông thường, cần cung cấp thêm các đoạn mã và cấu trúc dữ liệu cần thiết để AI không phải suy đoán về những thành phần chưa được nhìn thấy.

Yêu cầu AI đưa ra bằng chứng thay vì đoán lỗi

Một hạn chế thường gặp khi sử dụng AI là câu trả lời nghe có vẻ hợp lý nhưng chưa chắc phản ánh đúng trạng thái của chương trình. AI có thể nhận diện một mẫu lỗi phổ biến rồi áp dụng cách sửa quen thuộc, ngay cả khi nguyên nhân thực tế nằm ở nơi khác.

Để hạn chế vấn đề này, hãy yêu cầu AI chỉ ra vị trí mã nguồn liên quan và giải thích vì sao vị trí đó có thể tạo ra hiện tượng đang gặp phải. Nếu chưa có đủ bằng chứng, công cụ cần nêu thông tin còn thiếu và đề xuất cách thu thập thêm dữ liệu.

Ví dụ, khi một API trả về lỗi 500, không nên mặc định yêu cầu AI sửa hàm xử lý request. Mã trạng thái này chỉ cho biết máy chủ gặp lỗi trong quá trình xử lý; nguyên nhân cụ thể có thể liên quan đến exception chưa được xử lý, cấu hình sai, dịch vụ phụ thuộc không khả dụng hoặc truy vấn dữ liệu thất bại.

Một yêu cầu phân tích phù hợp hơn là:

Hãy phân tích nguyên nhân khiến API cập nhật thông tin trả về lỗi 500.

Trước khi sửa:
- Xác định vị trí phát sinh exception từ log hoặc stack trace.
- Lần theo dữ liệu từ request đến hàm xử lý và lớp truy cập dữ liệu.
- Kiểm tra các giả thuyết dựa trên mã nguồn và bằng chứng hiện có.
- Nếu chưa đủ thông tin, hãy nêu rõ log hoặc dữ liệu cần bổ sung.

Không tự ý thêm try-catch để che giấu lỗi, không trả về thành công
khi thao tác thất bại và không loại bỏ các bước xác thực đầu vào.

Hãy báo cáo nguyên nhân đã xác minh, nguyên nhân còn nghi ngờ
và cách kiểm tra trước khi đề xuất bản sửa.

Cách yêu cầu này giúp AI tập trung vào việc giải thích cơ chế phát sinh lỗi, thay vì chỉ tạo ra một đoạn mã mới. Đây cũng là cơ sở để lập trình viên quyết định có nên chấp nhận đề xuất sửa chữa hay cần thu thập thêm bằng chứng.

Quy trình dùng Vibe Coding để truy tìm lỗi trong mã nguồn

Sau khi chuẩn bị thông tin và xây dựng prompt, bước tiếp theo là đưa AI vào quy trình phân tích có kiểm soát. Không nên yêu cầu công cụ vừa tìm lỗi, vừa viết lại toàn bộ chức năng, vừa tự đánh giá kết quả trong một lần thực hiện. Tách quá trình thành các bước nhỏ giúp dễ xác định sai lệch và giảm phạm vi ảnh hưởng khi có vấn đề.

Bước 1: Để AI lần theo luồng xử lý liên quan

Trước tiên, yêu cầu AI xác định những thành phần có liên quan đến chức năng gặp lỗi. Tùy cấu trúc dự án, các thành phần này có thể bao gồm giao diện, bộ định tuyến, controller, service, model, truy vấn cơ sở dữ liệu, cấu hình và thư viện phụ thuộc.

AI cần làm rõ dữ liệu được tạo ra ở đâu, đi qua những hàm nào, được biến đổi như thế nào và tại vị trí nào kết quả bắt đầu khác với mong đợi. Việc lần theo luồng xử lý đặc biệt hữu ích với những lỗi không xuất hiện trực tiếp trong tệp chứa thông báo lỗi.

Ví dụ, một trang quản trị hiển thị sai tổng số đơn hàng. Vấn đề có thể không nằm ở câu lệnh hiển thị giao diện mà ở điều kiện lọc đơn hàng, cách tính tổng trong truy vấn hoặc việc dữ liệu bị cộng hai lần khi kết hợp nhiều bảng.

Prompt có thể viết như sau:

Hãy lần theo luồng xử lý của chức năng tính tổng số đơn hàng.

Xác định:
- Điểm bắt đầu tiếp nhận yêu cầu.
- Các hàm và truy vấn tham gia tính toán.
- Điều kiện lọc dữ liệu đang được áp dụng.
- Cách kết quả được chuyển đến giao diện.
- Những vị trí có khả năng làm sai lệch kết quả.

Chỉ phân tích và báo cáo trước, chưa sửa mã.
Với mỗi nhận định, hãy nêu tệp hoặc đoạn mã liên quan
và giải thích bằng chứng hỗ trợ nhận định đó.

Sau bước này, bạn nên nhận được một sơ đồ xử lý bằng văn bản hoặc danh sách các thành phần liên quan. Nếu AI bỏ qua một bước quan trọng hoặc suy diễn về hàm không tồn tại, hãy yêu cầu kiểm tra lại mã nguồn trước khi tiếp tục.

Bước 2: Thu hẹp phạm vi bằng giả thuyết có thể kiểm chứng

Khi đã hiểu luồng xử lý, hãy yêu cầu AI sắp xếp các nguyên nhân tiềm năng theo mức độ phù hợp với bằng chứng. Không nên yêu cầu liệt kê thật nhiều nguyên nhân chung chung, vì điều đó dễ khiến quá trình gỡ lỗi mất phương hướng.

Mỗi giả thuyết nên đi kèm ba nội dung: lý do nghi ngờ, cách kiểm tra và kết quả dự kiến nếu giả thuyết đúng. Chẳng hạn, nếu tổng số đơn hàng cao hơn thực tế, một giả thuyết có thể là phép JOIN tạo ra nhiều dòng cho cùng một đơn hàng. Cách kiểm tra là so sánh số dòng truy vấn với số mã đơn hàng duy nhất và kiểm tra quan hệ giữa các bảng.

Để AI thực hiện việc này có hệ thống, có thể sử dụng prompt:

Dựa trên luồng xử lý đã phân tích, hãy lập danh sách tối đa
ba nguyên nhân có cơ sở nhất cho lỗi hiện tại.

Với từng nguyên nhân, hãy trình bày:
1. Bằng chứng trong mã nguồn hoặc log.
2. Vì sao nguyên nhân này có thể tạo ra hiện tượng đã mô tả.
3. Phép kiểm tra giúp xác nhận hoặc loại trừ nguyên nhân.
4. Kết quả dự kiến nếu giả thuyết đúng.
5. Mức độ ảnh hưởng nếu nguyên nhân được xác nhận.

Không xem giả thuyết là sự thật khi chưa có kết quả kiểm tra.
Ưu tiên các phép kiểm tra ít rủi ro và không làm thay đổi dữ liệu thật.

Cách làm này giúp chuyển quá trình gỡ lỗi từ việc thử nhiều cách sửa sang việc kiểm tra từng nguyên nhân có chủ đích. Khi một giả thuyết bị loại trừ, hãy cung cấp kết quả đó cho AI để tiếp tục phân tích dựa trên thông tin mới, thay vì lặp lại đề xuất cũ.

Bước 3: Tạo dữ liệu thử nghiệm để tái hiện lỗi

Nếu lỗi liên quan đến dữ liệu, cần xây dựng một trường hợp thử nghiệm có thể tái hiện ổn định. Đây là bước quan trọng vì một đoạn mã chỉ gây lỗi với một số giá trị đầu vào nhất định có thể vẫn hoạt động bình thường trong các trường hợp đơn giản.

Ví dụ, hàm tính giá trị đơn hàng có thể cho kết quả đúng khi tất cả sản phẩm đều có số lượng dương, nhưng tính sai khi đơn hàng có sản phẩm được giảm giá, số lượng bằng không hoặc dữ liệu thiếu trường tùy chọn.

Thay vì yêu cầu AI tự sửa hàm ngay lập tức, hãy yêu cầu tạo các trường hợp kiểm thử đại diện cho dữ liệu hợp lệ, dữ liệu biên và dữ liệu không hợp lệ. Với mỗi trường hợp, cần xác định rõ đầu vào và kết quả mong đợi.

Hãy xây dựng các trường hợp kiểm thử để tái hiện lỗi
trong hàm tính tổng giá trị đơn hàng.

Cần xem xét:
- Đơn hàng có một sản phẩm.
- Đơn hàng có nhiều sản phẩm.
- Sản phẩm có số lượng bằng 0 hoặc dữ liệu không hợp lệ.
- Sản phẩm có giảm giá.
- Đơn hàng không có sản phẩm.
- Dữ liệu thiếu hoặc sai kiểu tại những trường quan trọng.

Với mỗi trường hợp, hãy nêu đầu vào, kết quả mong đợi
và mục đích kiểm tra.

Không tự đặt ra quy tắc nghiệp vụ chưa được xác nhận.
Nếu quy tắc tính giá chưa rõ, hãy chỉ ra điểm cần làm rõ trước.

Các trường hợp kiểm thử cần phù hợp với quy tắc nghiệp vụ thực tế. Chẳng hạn, một đơn hàng có số lượng bằng không phải bị từ chối, được bỏ qua hay được giữ lại để xử lý đặc biệt là quyết định của hệ thống, không nên để AI tự suy ra.

Khi đã có trường hợp tái hiện ổn định, bạn có thể sử dụng nó làm cơ sở để xác minh nguyên nhân và đánh giá bản sửa ở những bước tiếp theo.

Bước 4: Đối chiếu hành vi trước và sau khi xảy ra lỗi

Nếu chức năng từng hoạt động đúng nhưng gần đây bắt đầu phát sinh lỗi, hãy tận dụng lịch sử thay đổi của dự án. Sự khác biệt giữa phiên bản hoạt động ổn định và phiên bản gặp lỗi thường cung cấp manh mối quan trọng hơn việc đọc mã nguồn một cách độc lập.

Với Git, có thể kiểm tra những tệp đã thay đổi, các commit gần đây và lịch sử chỉnh sửa của khu vực liên quan. AI có thể hỗ trợ giải thích tác động của từng thay đổi, xác định điều kiện mới được thêm vào hoặc phát hiện một nhánh xử lý bị loại bỏ ngoài dự kiến.

Prompt gợi ý:

Chức năng này hoạt động đúng ở phiên bản trước nhưng bị lỗi
sau một lần cập nhật mã nguồn.

Hãy đối chiếu phần thay đổi liên quan đến chức năng:
- Xác định những dòng mã có thể ảnh hưởng đến hành vi.
- Giải thích khác biệt về luồng xử lý trước và sau thay đổi.
- Kiểm tra các điều kiện mới, giá trị mặc định và lời gọi hàm.
- Đánh giá liệu thay đổi có giải thích được lỗi đang gặp hay không.

Chỉ đề xuất khôi phục hoặc chỉnh sửa khi có căn cứ.
Không xóa các thay đổi khác chưa được đánh giá.

Nếu chưa xác định được commit gây lỗi, có thể tiếp tục thu hẹp khoảng thời gian hoặc nhóm thay đổi cần kiểm tra. Tuy nhiên, không nên tùy tiện khôi phục toàn bộ mã nguồn cũ vì có thể làm mất các bản sửa lỗi hoặc yêu cầu nghiệp vụ đã được triển khai sau đó.

Kết thúc giai đoạn truy tìm, mục tiêu không phải là có thật nhiều nhận xét từ AI mà là xác định được nguyên nhân có bằng chứng, hoặc ít nhất là thu hẹp rõ ràng phạm vi cần điều tra thêm. Chỉ khi đó, việc chỉnh sửa mã nguồn mới có cơ sở vững chắc.

Cách dùng Vibe Coding để sửa lỗi mà không làm hỏng chức năng khác

Sau khi xác định được nguyên nhân có cơ sở, bước tiếp theo là yêu cầu AI đề xuất và thực hiện bản sửa phù hợp. Đây là giai đoạn cần kiểm soát chặt chẽ nhất, bởi một thay đổi có thể giải quyết lỗi đang gặp nhưng đồng thời làm sai lệch quy tắc nghiệp vụ, ảnh hưởng đến dữ liệu hoặc phá vỡ những chức năng vốn đang hoạt động bình thường.

Nguyên tắc quan trọng khi sử dụng Vibe Coding để sửa lỗi là thay đổi ít nhất có thể nhưng phải giải quyết đúng nguyên nhân. Không nên yêu cầu AI viết lại toàn bộ hàm hoặc xây dựng lại cấu trúc dự án nếu chỉ cần điều chỉnh một điều kiện xử lý. Phạm vi chỉnh sửa càng rõ ràng, việc kiểm tra và khôi phục khi có sự cố càng dễ dàng.

Yêu cầu AI đưa ra phương án sửa trước khi chỉnh sửa mã

Ngay cả khi nguyên nhân đã được xác định, không nên mặc định rằng chỉ có một cách khắc phục. AI có thể đề xuất nhiều phương án với mức độ ảnh hưởng khác nhau. Việc yêu cầu công cụ giải thích phương án trước khi thay đổi mã giúp lập trình viên đánh giá tính phù hợp của từng lựa chọn.

Ví dụ, một chức năng PHP bị lỗi khi nhận giá trị rỗng. Có thể khắc phục bằng cách kiểm tra đầu vào, thiết lập giá trị mặc định hoặc thay đổi logic xử lý. Tuy nhiên, ba cách này không tương đương nhau. Nếu giá trị rỗng phản ánh dữ liệu không hợp lệ, tự động thay bằng giá trị mặc định có thể khiến hệ thống lưu thông tin sai.

Hãy yêu cầu AI trình bày phương án sửa theo các tiêu chí sau:

• Nguyên nhân nào được giải quyết và bằng chứng xác nhận nguyên nhân đó là gì?
• Những tệp và hàm nào cần thay đổi?
• Phương án có ảnh hưởng đến dữ liệu đầu vào, dữ liệu đầu ra hoặc quy tắc nghiệp vụ không?
• Có thể sửa tại vị trí gây lỗi mà không thay đổi những thành phần khác không?
• Những trường hợp nào có thể phát sinh lỗi sau khi chỉnh sửa?
• Cần chạy những kiểm thử nào để xác nhận bản sửa?

Prompt dưới đây phù hợp khi bạn muốn AI đề xuất bản sửa có phạm vi giới hạn:

Nguyên nhân gây lỗi đã được xác định dựa trên các bằng chứng
đã kiểm tra trong dự án.

Hãy đề xuất phương án sửa theo các yêu cầu:
1. Chỉ thay đổi những thành phần cần thiết để giải quyết nguyên nhân.
2. Giữ nguyên giao diện và hành vi của các chức năng không liên quan.
3. Không tự ý thay đổi cấu trúc cơ sở dữ liệu, API hoặc quy tắc nghiệp vụ.
4. Không loại bỏ bước xác thực đầu vào và kiểm tra quyền truy cập.
5. Giải thích tác động của từng thay đổi.
6. Nêu các trường hợp cần kiểm thử sau khi sửa.

Trước tiên, hãy trình bày phương án và những rủi ro có thể có.
Chưa thực hiện chỉnh sửa cho đến khi phương án được đánh giá.

Trong các công cụ Vibe Coding có khả năng chỉnh sửa trực tiếp mã nguồn, bạn nên xem lại kế hoạch thay đổi trước khi cho phép công cụ thực hiện. Nếu phương án bao gồm nhiều tệp không liên quan đến lỗi, hãy yêu cầu AI giải thích lý do hoặc thu hẹp phạm vi.

Ưu tiên bản sửa nhỏ, dễ đọc và dễ kiểm chứng

Một bản sửa tốt không nhất thiết phải sử dụng kỹ thuật phức tạp. Trong nhiều trường hợp, điều chỉnh một điều kiện hoặc bổ sung bước kiểm tra đúng vị trí sẽ an toàn hơn việc thay đổi cả hàm xử lý.

Ví dụ, một đoạn mã JavaScript đọc thuộc tính của đối tượng người dùng trước khi xác nhận dữ liệu đã được tải có thể gây ra lỗi khi đối tượng chưa tồn tại. Nếu quy trình nghiệp vụ cho phép trạng thái chưa có dữ liệu, có thể xử lý trạng thái đó một cách rõ ràng thay vì viết lại toàn bộ thành phần giao diện.

Tuy nhiên, không nên áp dụng máy móc toán tử truy cập an toàn hoặc giá trị mặc định cho mọi trường hợp. Nếu dữ liệu người dùng bắt buộc phải tồn tại, việc âm thầm bỏ qua giá trị thiếu có thể che giấu lỗi nghiêm trọng. Bản sửa phải phù hợp với ý nghĩa của dữ liệu và yêu cầu của hệ thống.

Khi đánh giá mã do AI tạo ra, hãy chú ý những dấu hiệu cho thấy phạm vi chỉnh sửa đang vượt quá mức cần thiết:

• Viết lại các hàm không liên quan đến nguyên nhân đã xác định.
• Đổi tên hàng loạt biến, lớp hoặc phương thức trong quá trình sửa một lỗi nhỏ.
• Thay đổi định dạng dữ liệu trả về mà không có yêu cầu tương ứng.
• Thêm thư viện mới trong khi chức năng hiện tại có thể được sửa bằng các công cụ sẵn có.
• Loại bỏ điều kiện kiểm tra, xử lý ngoại lệ hoặc xác thực chỉ để chương trình chạy qua một trường hợp.
• Thay đổi nhiều tầng kiến trúc cùng lúc khiến khó xác định thay đổi nào thực sự giải quyết vấn đề.

Nếu AI đề xuất tái cấu trúc lớn, hãy tách công việc thành hai nhiệm vụ riêng: sửa lỗi hiện tại và cải thiện kiến trúc. Trước tiên cần khôi phục hành vi đúng bằng một bản sửa có thể kiểm chứng. Việc tái cấu trúc chỉ nên thực hiện khi có lý do rõ ràng và có đủ kiểm thử bảo vệ các chức năng liên quan.

Kiểm tra sự khác biệt trong mã nguồn sau mỗi lần sửa

Không nên chỉ đọc phần giải thích của AI rồi cho rằng mã nguồn đã được sửa đúng. Hãy kiểm tra trực tiếp các thay đổi được tạo ra bằng công cụ so sánh mã nguồn hoặc lịch sử thay đổi trong Git.

Việc xem diff giúp phát hiện những sửa đổi ngoài dự kiến như xóa nhầm điều kiện, thay đổi cấu hình, ghi đè đoạn mã khác hoặc vô tình đưa thông tin nhạy cảm vào tệp nguồn. Đây cũng là cách xác định chính xác AI đã sửa những gì và tại sao.

Nếu dự án sử dụng Git, có thể kiểm tra trạng thái và nội dung thay đổi bằng các lệnh sau:

git status
git diff
git diff --check

Lệnh git status cho biết những tệp đang có thay đổi. Lệnh git diff hiển thị phần nội dung được thêm, sửa hoặc xóa. Lệnh git diff --check giúp phát hiện một số vấn đề về khoảng trắng và dấu cách không cần thiết trong phần thay đổi.

Các lệnh này không chứng minh bản sửa đúng về mặt logic, nhưng giúp bạn kiểm soát phạm vi chỉnh sửa trước khi chạy kiểm thử hoặc đưa mã vào nhánh chính.

Kiểm thử để xác nhận lỗi đã được sửa triệt để

Một trong những sai lầm phổ biến khi dùng Vibe Coding là dừng lại ngay khi hiện tượng lỗi không còn xuất hiện. Trên thực tế, một chức năng hoạt động đúng với một đầu vào không có nghĩa là toàn bộ vấn đề đã được giải quyết. Bản sửa có thể chỉ xử lý được trường hợp cụ thể, trong khi những trường hợp biên vẫn gây lỗi hoặc một chức năng khác đã bị ảnh hưởng.

Vì vậy, sau mỗi lần chỉnh sửa, cần xác minh cả hai mục tiêu: lỗi ban đầu đã được khắc phục và những hành vi vốn đúng vẫn tiếp tục hoạt động bình thường.

Kiểm thử lại đúng trường hợp từng gây lỗi

Bước đầu tiên là chạy lại các thao tác đã tái hiện lỗi trước khi sửa. Nếu lỗi ban đầu không thể tái hiện một cách ổn định, cần kiểm tra xem môi trường, dữ liệu hoặc điều kiện thực thi có thay đổi hay không.

Ví dụ, nếu chức năng tìm kiếm trả về kết quả sai với từ khóa có dấu tiếng Việt, hãy sử dụng lại đúng từ khóa đó sau khi sửa. Không nên chỉ kiểm tra một từ khóa đơn giản khác rồi kết luận chức năng đã hoạt động đúng.

Hãy yêu cầu AI xây dựng một bảng đối chiếu kết quả trước và sau khi sửa, dựa trên những trường hợp đã được xác định:

Trường hợp kiểm tra	Kết quả trước khi sửa	Kết quả mong đợi	Kết quả sau khi sửa
Đầu vào hợp lệ thông thường	Ghi nhận hiện tượng ban đầu	Chức năng xử lý đúng	Điền kết quả thực tế
Đầu vào từng gây lỗi	Lỗi xuất hiện	Không còn lỗi, dữ liệu chính xác	Điền kết quả thực tế
Đầu vào rỗng hoặc thiếu trường	Ghi nhận hành vi trước đó	Xử lý theo quy tắc nghiệp vụ	Điền kết quả thực tế
Đầu vào biên hoặc dữ liệu đặc biệt	Ghi nhận hành vi trước đó	Kết quả đúng theo yêu cầu	Điền kết quả thực tế

Bảng này cần được điền bằng kết quả quan sát hoặc kết quả thực thi thực tế. Không nên để AI tự đánh dấu tất cả trường hợp là đạt nếu công cụ chưa thực sự chạy các phép kiểm tra.

Sử dụng kiểm thử tự động và kiểm thử hồi quy

Nếu dự án đã có bộ kiểm thử tự động, hãy chạy những bài kiểm thử liên quan sau khi sửa lỗi. Các bài kiểm thử này giúp xác minh rằng bản sửa đáp ứng yêu cầu và không làm hỏng hành vi đã được kiểm tra trước đó.

Với một dự án PHP sử dụng PHPUnit, chẳng hạn, có thể chạy bộ kiểm thử bằng lệnh sau nếu dự án đã cài đặt và cấu hình PHPUnit phù hợp:

./vendor/bin/phpunit

Nếu dự án sử dụng Composer và đã khai báo các script kiểm thử, hãy ưu tiên những lệnh được định nghĩa trong cấu hình dự án. Với dự án JavaScript, có thể sử dụng công cụ kiểm thử mà dự án đang triển khai thay vì cài thêm một framework mới chỉ để kiểm tra bản sửa.

Ngoài kiểm thử đơn vị, cần cân nhắc các cấp độ kiểm thử khác nhau:

• Kiểm thử đơn vị: Xác minh hàm hoặc thành phần nhỏ xử lý đúng đầu vào và trả về kết quả mong đợi.
• Kiểm thử tích hợp: Kiểm tra sự phối hợp giữa các thành phần như API, cơ sở dữ liệu và lớp nghiệp vụ.
• Kiểm thử đầu cuối: Xác minh luồng sử dụng thực tế từ giao diện đến kết quả cuối cùng.
• Kiểm thử hồi quy: Kiểm tra các chức năng liên quan để bảo đảm bản sửa không gây ra lỗi mới.

Không phải lỗi nào cũng cần chạy toàn bộ hệ thống kiểm thử. Với một thay đổi nhỏ, có thể bắt đầu bằng các bài kiểm thử trực tiếp liên quan rồi mở rộng phạm vi theo mức độ rủi ro. Tuy nhiên, những thay đổi ảnh hưởng đến xác thực, thanh toán, phân quyền hoặc dữ liệu quan trọng cần được kiểm tra kỹ hơn.

Nếu chưa có kiểm thử tự động, bạn có thể yêu cầu AI đề xuất các bài kiểm thử cho lỗi vừa xử lý. Sau đó, hãy xem xét và điều chỉnh chúng theo yêu cầu nghiệp vụ thực tế trước khi sử dụng làm cơ sở đánh giá.

Đối chiếu log và hành vi sau khi sửa

Không phải mọi lỗi đều có thể được xác nhận bằng một kết quả hiển thị trên giao diện. Với các lỗi liên quan đến hiệu năng, kết nối dịch vụ hoặc xử lý bất đồng bộ, cần kiểm tra thêm log và những dấu hiệu cho thấy quá trình thực thi đã diễn ra đúng.

Chẳng hạn, nếu một API trước đây thường xuyên trả về lỗi khi gọi dịch vụ bên ngoài, việc không còn thấy lỗi trong một lần thử chưa đủ để kết luận hệ thống ổn định. Cần xác minh rằng phản hồi được xử lý đúng, thời gian chờ hợp lý và các tình huống thất bại vẫn được kiểm soát.

Có thể yêu cầu AI hỗ trợ xây dựng danh sách kiểm tra sau sửa lỗi như sau:

Dựa trên bản sửa hiện tại, hãy lập danh sách kiểm tra xác minh.

Cần đánh giá:
- Trường hợp gây lỗi ban đầu đã hoạt động đúng chưa.
- Các nhánh xử lý thành công và thất bại có còn chính xác không.
- Có phát sinh exception hoặc cảnh báo mới không.
- Dữ liệu ghi vào và đọc từ cơ sở dữ liệu có đúng không.
- Những chức năng liên quan có bị ảnh hưởng không.
- Có thay đổi đáng kể về thời gian xử lý hoặc số lượng truy vấn không.

Phân biệt rõ các kiểm tra đã thực thi với các kiểm tra mới chỉ được đề xuất.
Không kết luận bản sửa thành công nếu chưa có bằng chứng phù hợp.

Với lỗi hiệu năng, hãy đo đạc trong điều kiện có thể so sánh trước và sau khi sửa. Với lỗi dữ liệu, cần kiểm tra kết quả thực tế trong môi trường thử nghiệm. Với lỗi bảo mật, cần xác minh cả trường hợp được phép và trường hợp phải bị từ chối.

Một bản sửa chỉ nên được xem là hoàn tất khi có bằng chứng phù hợp cho thấy nguyên nhân đã được xử lý, hành vi mong muốn được khôi phục và các rủi ro liên quan đã được đánh giá.

Cách xử lý những lỗi phức tạp bằng Vibe Coding

Trong dự án thực tế, không phải lỗi nào cũng có thể giải quyết bằng cách đọc một thông báo và chỉnh sửa một hàm. Một số lỗi chỉ xuất hiện khi có nhiều thành phần tương tác, khi dữ liệu lớn dần hoặc khi môi trường triển khai khác với môi trường phát triển.

Đối với các tình huống này, Vibe Coding phát huy hiệu quả khi được sử dụng để hỗ trợ điều tra có hệ thống, xây dựng giả thuyết và phân tích bằng chứng. AI không nên thay thế việc đo đạc, kiểm thử hoặc đánh giá rủi ro trong những phần quan trọng của hệ thống.

Lỗi chỉ xuất hiện trên môi trường triển khai

Một chức năng chạy bình thường trên máy cá nhân nhưng thất bại khi triển khai lên máy chủ thường liên quan đến sự khác biệt giữa hai môi trường. Những yếu tố cần kiểm tra bao gồm phiên bản ngôn ngữ, thư viện phụ thuộc, biến môi trường, quyền truy cập tệp, cấu hình máy chủ, kết nối cơ sở dữ liệu và các dịch vụ bên ngoài.

Ví dụ, một dự án PHP có thể hoạt động trên môi trường phát triển nhưng lỗi trên máy chủ vì phiên bản PHP khác nhau hoặc một tiện ích mở rộng cần thiết chưa được bật. Trong trường hợp này, sửa logic nghiệp vụ không phải hướng xử lý ưu tiên.

Hãy yêu cầu AI đối chiếu các thông tin môi trường có liên quan và tìm ra khác biệt có thể giải thích lỗi. Nên cung cấp thông tin phiên bản, log khởi động và cấu hình đã loại bỏ thông tin nhạy cảm, thay vì gửi toàn bộ tệp cấu hình chứa mật khẩu hoặc khóa truy cập.

Đặc biệt, không nên yêu cầu AI tự động hạ cấp thư viện, thay đổi quyền truy cập toàn bộ thư mục hoặc vô hiệu hóa cơ chế bảo mật để làm cho ứng dụng chạy được. Mỗi thay đổi môi trường cần có lý do kỹ thuật rõ ràng và được kiểm tra về tác động.

Lỗi phát sinh không ổn định

Các lỗi xuất hiện lúc có lúc không thường khó phân tích vì cùng một thao tác có thể tạo ra những kết quả khác nhau. Nguyên nhân có thể liên quan đến xử lý bất đồng bộ, trạng thái dùng chung, thời điểm hoàn thành của các tác vụ, giới hạn tài nguyên hoặc sự tương tác giữa nhiều yêu cầu.

Thay vì yêu cầu AI sửa ngay, hãy tập trung thu thập thông tin về thời điểm xảy ra lỗi, dữ liệu đầu vào, trình tự sự kiện và điều kiện thực thi. Với các hệ thống có nhiều tác vụ đồng thời, cần xác định liệu lỗi có liên quan đến tranh chấp dữ liệu hoặc thứ tự thực hiện hay không.

AI có thể giúp phân tích log, đề xuất điểm cần bổ sung thông tin theo dõi và xây dựng trường hợp kiểm thử nhằm tái hiện vấn đề. Tuy nhiên, nếu log chưa đủ hoặc lỗi phụ thuộc vào thời gian, việc xác nhận nguyên nhân có thể cần công cụ gỡ lỗi chuyên dụng và nhiều lần thử nghiệm.

Không nên thêm các khoảng chờ tùy ý hoặc thay đổi thứ tự thực thi chỉ vì một phương án như vậy làm lỗi ít xuất hiện hơn. Cần hiểu rõ cơ chế gây lỗi trước khi áp dụng giải pháp lâu dài.

Lỗi liên quan đến cơ sở dữ liệu và dữ liệu không nhất quán

Những lỗi liên quan đến dữ liệu cần được xử lý thận trọng vì một bản sửa sai có thể làm thay đổi hoặc mất dữ liệu quan trọng. AI có thể hỗ trợ đọc truy vấn, phân tích điều kiện JOIN, kiểm tra quan hệ giữa các bảng và xác định những trường hợp dữ liệu không đáp ứng giả định của chương trình.

Ví dụ, một chức năng thống kê trả về số lượng bản ghi lớn hơn thực tế có thể xuất phát từ việc kết hợp các bảng có quan hệ một-nhiều. Nếu phép JOIN tạo ra nhiều dòng cho cùng một đối tượng, việc tính tổng trực tiếp trên kết quả có thể làm sai số liệu.

Trong tình huống này, cần yêu cầu AI kiểm tra quan hệ dữ liệu, đối chiếu số lượng bản ghi và đề xuất truy vấn kiểm chứng chỉ đọc trước khi thay đổi logic tính toán. Không nên tự động xóa dữ liệu trùng lặp hoặc chạy lệnh cập nhật hàng loạt khi chưa hiểu nguồn gốc của dữ liệu đó.

Đối với lỗi liên quan đến giao dịch cơ sở dữ liệu, cần kiểm tra cả cách bắt đầu giao dịch, thời điểm commit, rollback và việc xử lý ngoại lệ. Chỉ sửa câu lệnh gây lỗi mà bỏ qua tính nhất quán của toàn bộ giao dịch có thể khiến hệ thống rơi vào trạng thái khó khôi phục.

Lỗi hiệu năng khi dự án có nhiều dữ liệu

Một chức năng có thể chạy tốt với vài trăm bản ghi nhưng chậm rõ rệt khi dữ liệu tăng lên hàng trăm nghìn bản ghi. Trong trường hợp này, AI có thể giúp xác định những vị trí đáng kiểm tra như truy vấn lặp, xử lý dữ liệu dư thừa, thuật toán có độ phức tạp cao hoặc việc tải quá nhiều dữ liệu cùng lúc.

Tuy nhiên, không nên tối ưu chỉ dựa trên cảm giác hoặc nhận xét của AI. Cần sử dụng số liệu đo thực tế để xác định thành phần nào đang tiêu tốn nhiều thời gian hoặc tài nguyên nhất.

Với dự án PHP sử dụng cơ sở dữ liệu quan hệ, có thể bắt đầu bằng việc đo thời gian thực thi truy vấn, kiểm tra số lượng truy vấn trong một request và phân tích kế hoạch thực thi bằng công cụ phù hợp với hệ quản trị cơ sở dữ liệu đang dùng.

Sau khi xác định được điểm nghẽn, hãy yêu cầu AI đề xuất phương án tối ưu và giải thích những đánh đổi có thể xảy ra. Ví dụ, thêm chỉ mục có thể cải thiện tốc độ đọc nhưng làm tăng chi phí cập nhật dữ liệu và dung lượng lưu trữ. Tối ưu một truy vấn riêng lẻ cũng không nhất thiết cải thiện toàn bộ thời gian phản hồi của ứng dụng.

Vì vậy, quy trình phù hợp là đo đạc, xác định điểm nghẽn, đưa ra phương án, thử nghiệm trong môi trường kiểm soát và đo lại kết quả sau thay đổi.

Những sai lầm cần tránh khi dùng Vibe Coding để gỡ lỗi

Vibe Coding có thể giúp rút ngắn thời gian phân tích và chỉnh sửa mã nguồn, nhưng hiệu quả sẽ giảm đáng kể nếu quá trình làm việc thiếu kiểm soát. Một số sai lầm dưới đây dễ khiến lập trình viên mất nhiều thời gian hơn hoặc tạo ra những vấn đề nghiêm trọng hơn lỗi ban đầu.

Yêu cầu sửa toàn bộ dự án khi chưa xác định phạm vi

Yêu cầu AI tìm và sửa mọi lỗi trong dự án nghe có vẻ tiết kiệm thời gian, nhưng thường tạo ra quá nhiều thay đổi khó kiểm chứng. AI có thể phát hiện những đoạn mã chưa hoàn hảo, đề xuất tái cấu trúc hoặc thay đổi các thành phần không liên quan đến sự cố đang gặp phải.

Thay vào đó, hãy bắt đầu bằng một lỗi cụ thể, xác định phạm vi ảnh hưởng và giải quyết theo từng bước. Khi một vấn đề được xử lý và kiểm chứng thành công, bạn có thể tiếp tục với lỗi tiếp theo.

Chấp nhận câu trả lời của AI mà không kiểm tra

AI có thể đưa ra giải thích mạch lạc nhưng vẫn nhầm lẫn về cấu trúc dự án, tên hàm, cách hoạt động của thư viện hoặc quy tắc nghiệp vụ. Một đoạn mã trông hợp lý chưa chắc tương thích với phiên bản công nghệ mà hệ thống đang sử dụng.

Hãy kiểm tra những nhận định quan trọng bằng mã nguồn, log, tài liệu kỹ thuật và kết quả thực thi. Nếu công cụ không có quyền chạy kiểm thử, bạn cần tự thực hiện các bước xác minh thay vì xem phần giải thích của AI là bằng chứng rằng bản sửa đã hoạt động.

Sửa nhiều vấn đề trong cùng một lần

Khi thay đổi đồng thời nhiều hàm, cấu hình và thư viện, việc xác định nguyên nhân nếu phát sinh lỗi mới sẽ trở nên khó khăn. Ngay cả khi chương trình chạy được sau cùng, bạn cũng khó biết thay đổi nào thực sự cần thiết.

Với những lỗi có phạm vi rõ ràng, nên chia công việc thành các thay đổi nhỏ và kiểm tra sau mỗi thay đổi có ý nghĩa. Nếu cần sửa nhiều thành phần phụ thuộc nhau, hãy yêu cầu AI giải thích thứ tự thực hiện và kiểm thử từng giai đoạn.

Che giấu lỗi thay vì xử lý nguyên nhân

Thêm điều kiện bỏ qua dữ liệu, bắt mọi ngoại lệ rồi trả về kết quả mặc định hoặc vô hiệu hóa bước xác thực có thể khiến thông báo lỗi biến mất. Tuy nhiên, điều đó không đồng nghĩa với việc chức năng đã hoạt động đúng.

Một bản sửa an toàn cần xác định hành vi đúng khi thành công, khi dữ liệu không hợp lệ và khi hệ thống gặp sự cố. Nếu không thể xử lý lỗi tại chỗ, chương trình phải ghi nhận và phản hồi theo cách phù hợp, thay vì âm thầm tạo ra kết quả sai.

Đưa dữ liệu nhạy cảm vào công cụ AI

Log và mã nguồn có thể chứa thông tin xác thực, dữ liệu cá nhân hoặc thông tin nội bộ. Trước khi cung cấp dữ liệu cho công cụ AI, hãy loại bỏ các giá trị nhạy cảm không cần thiết và tuân thủ chính sách bảo mật của tổ chức.

Không nên chia sẻ mật khẩu, khóa bí mật, token truy cập hoặc dữ liệu khách hàng thật chỉ để AI có thêm ngữ cảnh. Trong nhiều trường hợp, dữ liệu giả lập có cấu trúc tương tự là đủ để phân tích và tái hiện lỗi.

Quy trình chuẩn để áp dụng Vibe Coding vào dự án thực tế

Để tránh làm việc theo kiểu thử lệnh liên tục mà không có phương pháp, bạn nên chuẩn hóa quy trình gỡ lỗi thành những bước có thể lặp lại. Quy trình này phù hợp với cả dự án mới lẫn hệ thống đã phát triển trong thời gian dài.

1. Ghi nhận lỗi: Mô tả hiện tượng, các bước tái hiện, kết quả mong muốn và mức độ ảnh hưởng.
2. Chuẩn bị dữ liệu: Thu thập log, thông báo lỗi, mã nguồn liên quan và thông tin môi trường cần thiết.
3. Khoanh vùng: Yêu cầu AI lần theo luồng xử lý và xác định các thành phần có liên quan.
4. Đặt giả thuyết: Liệt kê những nguyên nhân có cơ sở và xác định cách kiểm chứng từng nguyên nhân.
5. Xác minh nguyên nhân: Thực hiện kiểm tra bằng log, dữ liệu thử nghiệm, công cụ gỡ lỗi hoặc kiểm thử.
6. Đề xuất bản sửa: Chọn phương án có phạm vi thay đổi phù hợp và đánh giá rủi ro.
7. Kiểm tra mã nguồn: Xem diff, rà soát thay đổi ngoài dự kiến và xác nhận không ảnh hưởng đến các cơ chế quan trọng.
8. Chạy kiểm thử: Kiểm tra trường hợp gây lỗi, những trường hợp biên và các chức năng liên quan.
9. Đánh giá kết quả: Đối chiếu hành vi thực tế, log và kết quả kiểm thử trước khi chấp nhận bản sửa.
10. Lưu lại thông tin: Ghi nhận nguyên nhân, giải pháp, kiểm thử đã thực hiện và những lưu ý cần thiết cho lần bảo trì tiếp theo.

Quy trình này không bắt buộc phải thực hiện theo cùng một mức độ chi tiết cho mọi lỗi. Một lỗi cú pháp đơn giản có thể chỉ cần kiểm tra ngắn gọn, trong khi lỗi liên quan đến thanh toán, phân quyền hoặc dữ liệu quan trọng cần quy trình xác minh chặt chẽ hơn.

Điểm cốt lõi là mỗi thay đổi phải có mục đích rõ ràng và được đánh giá dựa trên bằng chứng. Vibe Coding nên giúp giảm thời gian tìm kiếm và thử nghiệm, không phải loại bỏ những bước cần thiết để bảo đảm chất lượng phần mềm.

Khi nào nên dùng Vibe Coding và khi nào cần gỡ lỗi thủ công?

Vibe Coding đặc biệt hữu ích khi cần đọc nhanh một phần mã nguồn chưa quen thuộc, phân tích luồng xử lý, giải thích thông báo lỗi, xây dựng trường hợp kiểm thử hoặc đề xuất phương án sửa. Công cụ cũng có thể hỗ trợ lập trình viên khám phá những khu vực của dự án mà họ chưa nắm rõ.

Tuy nhiên, có những trường hợp cần kết hợp AI với công cụ gỡ lỗi chuyên dụng hoặc sự đánh giá trực tiếp của người có kinh nghiệm. Những vấn đề liên quan đến tranh chấp dữ liệu đồng thời, lỗi chỉ xuất hiện trong điều kiện hiếm gặp, sự cố bảo mật hoặc dữ liệu bị sai lệch trên hệ thống đang vận hành thường cần nhiều bằng chứng thực tế hơn những gì có thể suy luận từ mã nguồn.

Tình huống	Cách tiếp cận phù hợp
Lỗi cú pháp hoặc lỗi đơn giản có thông báo rõ ràng	Dùng AI phân tích nhanh, sau đó chạy kiểm tra để xác nhận.
Lỗi logic trong một hàm cụ thể	Kết hợp phân tích mã, dữ liệu đầu vào và kiểm thử đơn vị.
Lỗi xảy ra giữa nhiều thành phần	Dùng AI lần theo luồng xử lý, kết hợp log và kiểm thử tích hợp.
Lỗi không ổn định hoặc phụ thuộc thời điểm	Kết hợp AI với công cụ gỡ lỗi, giám sát và thu thập dữ liệu thực thi.
Lỗi liên quan đến dữ liệu quan trọng	Ưu tiên kiểm tra có kiểm soát, sao lưu và đánh giá tác động trước khi sửa.
Lỗi bảo mật hoặc phân quyền	Kết hợp phân tích mã với quy trình kiểm tra bảo mật chuyên biệt.

Không nhất thiết phải lựa chọn giữa AI và phương pháp gỡ lỗi truyền thống. Cách hiệu quả hơn là sử dụng AI để rút ngắn thời gian phân tích, còn công cụ chuyên dụng và kết quả thực thi được dùng để xác minh những nhận định quan trọng.

Kết luận

Cách dùng Vibe Coding để tìm và sửa lỗi trong dự án hiệu quả không nằm ở việc viết prompt thật dài hoặc yêu cầu AI chỉnh sửa càng nhiều mã nguồn càng tốt. Điều quan trọng là xây dựng được quy trình làm việc có kiểm soát, bắt đầu từ việc mô tả chính xác hiện tượng, lần theo luồng xử lý, kiểm chứng nguyên nhân và chỉ thực hiện những thay đổi cần thiết.

Trong quá trình áp dụng, hãy yêu cầu AI giải thích bằng chứng cho các nhận định, phân biệt giả thuyết với nguyên nhân đã xác minh và đề xuất cách kiểm tra trước khi sửa. Sau khi chỉnh sửa, cần xem lại mã nguồn, chạy kiểm thử và xác nhận những chức năng liên quan vẫn hoạt động đúng.

Đối với các dự án PHP, website hoặc hệ thống phần mềm có nhiều thành phần, cách tiếp cận này giúp tận dụng khả năng phân tích của AI mà vẫn giữ được quyền kiểm soát đối với kiến trúc, dữ liệu và chất lượng mã nguồn. Khi được sử dụng đúng cách, Vibe Coding có thể trở thành một trợ lý gỡ lỗi hữu ích, giúp lập trình viên xử lý vấn đề nhanh hơn mà không đánh đổi tính ổn định của dự án.

Bùi Tấn Lực

Đánh giá

Chia sẻ nội dung đánh giá của bạn về Cách dùng Vibe Coding để tìm và sửa lỗi trong dự án
Email, Điện thoại của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *

Bình luận, Hỏi đáp