Cách dùng Vibe Coding để đọc và hiểu code có sẵn
Bùi Tấn Lực
- 104
- 12/10/2026
Khi tiếp nhận một dự án lập trình đã tồn tại, việc khó khăn không phải lúc nào cũng là viết thêm chức năng mới. Nhiều khi, thử thách lớn nhất là hiểu được code hiện tại đang hoạt động như thế nào, dữ liệu đi qua những thành phần nào, một chức năng được triển khai ở đâu và vì sao hệ thống lại phát sinh lỗi.
Với dự án có nhiều thư mục, hàng chục tệp phụ thuộc lẫn nhau hoặc sử dụng công nghệ chưa quen thuộc, việc đọc code theo cách truyền thống có thể mất nhiều giờ, thậm chí nhiều ngày. Đây là lúc Vibe Coding phát huy giá trị khi kết hợp khả năng phân tích của AI với quá trình kiểm tra mã nguồn thực tế của lập trình viên.
Thay vì tự đọc từng dòng code ngay từ đầu, bạn có thể yêu cầu AI lập bản đồ dự án, giải thích luồng xử lý, truy tìm nơi triển khai một chức năng và làm rõ các mối quan hệ giữa những thành phần liên quan. Quan trọng hơn, bạn có thể đặt câu hỏi tiếp nối để đi từ bức tranh tổng thể đến từng đoạn code cụ thể.
Tuy nhiên, AI không tự động hiểu chính xác toàn bộ dự án chỉ từ một câu lệnh. Muốn nhận được kết quả hữu ích, bạn cần cung cấp đúng ngữ cảnh, yêu cầu phân tích có trình tự và đối chiếu lời giải thích với mã nguồn thực tế.

Vibe Coding giúp ích gì khi tiếp cận dự án có sẵn?
Vibe Coding là cách phát triển phần mềm thông qua việc diễn đạt yêu cầu bằng ngôn ngữ tự nhiên, sau đó sử dụng AI để hỗ trợ phân tích, tạo hoặc chỉnh sửa code. Khi áp dụng vào một dự án đã có, phương pháp này không nhất thiết nhằm viết thêm mã nguồn mà tập trung vào việc giúp người lập trình hiểu hệ thống nhanh hơn.
Thay vì yêu cầu AI viết lại một chức năng mà bạn chưa hiểu, hãy sử dụng AI như một trợ lý phân tích. Bạn đưa ra câu hỏi cụ thể, cung cấp tệp hoặc cho công cụ truy cập mã nguồn, rồi kiểm tra những giải thích mà AI đưa ra.
Rút ngắn thời gian làm quen với dự án
Một dự án thực tế có thể chứa nhiều thành phần như cấu hình, xử lý nghiệp vụ, truy vấn cơ sở dữ liệu, giao diện, xác thực người dùng và tích hợp API. Nếu bắt đầu từ một tệp bất kỳ, bạn dễ mất thời gian đọc những phần chưa cần thiết.
AI có thể giúp xác định điểm khởi đầu phù hợp bằng cách phân tích cấu trúc thư mục, nhận diện tệp cấu hình và tìm các thành phần quan trọng. Từ đó, bạn biết nên đọc tệp nào trước, chức năng nào phụ thuộc vào chức năng nào và khu vực nào cần chú ý.
Hiểu luồng xử lý thay vì chỉ hiểu từng dòng code
Biết một hàm thực hiện phép tính gì chưa đồng nghĩa với việc hiểu chức năng đó trong toàn bộ hệ thống. Bạn còn cần biết hàm được gọi từ đâu, dữ liệu đầu vào đến từ đâu, kết quả được sử dụng ở đâu và những điều kiện nào có thể khiến luồng xử lý thay đổi.
Vibe Coding cho phép bạn yêu cầu AI giải thích một chức năng theo trình tự thực thi. Cách tiếp cận này đặc biệt hữu ích với các dự án sử dụng nhiều lớp xử lý, nơi một thao tác của người dùng có thể đi qua giao diện, API, lớp nghiệp vụ và cơ sở dữ liệu.
Tiếp cận công nghệ chưa quen thuộc
Bạn có thể gặp một dự án PHP sử dụng kiến trúc MVC, một ứng dụng Python có nhiều module hoặc một hệ thống JavaScript sử dụng framework chưa từng làm việc. Thay vì học toàn bộ công nghệ trước khi đọc dự án, bạn có thể yêu cầu AI giải thích cách công nghệ đó được sử dụng trong chính mã nguồn đang có.
Ví dụ, khi gặp một middleware trong ứng dụng web, bạn có thể hỏi middleware này được gọi ở giai đoạn nào, kiểm tra điều kiện gì và ảnh hưởng ra sao đến request. Câu trả lời gắn với code thực tế thường hữu ích hơn một định nghĩa chung chung.
Chuẩn bị mã nguồn trước khi nhờ AI phân tích
Chất lượng phân tích phụ thuộc đáng kể vào phạm vi mã nguồn mà AI có thể tiếp cận. Nếu chỉ cung cấp một đoạn code rời rạc, AI có thể giải thích được cú pháp nhưng khó xác định chính xác vai trò của đoạn code trong hệ thống.
Xác định nguồn mã cần phân tích
Nếu sử dụng công cụ Vibe Coding có khả năng đọc thư mục dự án, hãy mở đúng thư mục gốc của ứng dụng. Nếu sử dụng AI qua giao diện trò chuyện thông thường, bạn có thể cung cấp cây thư mục cùng những tệp liên quan, sau đó bổ sung mã nguồn theo từng bước.
Trước tiên, hãy xác định những thông tin cơ bản sau:
- Ngôn ngữ lập trình: PHP, Python, JavaScript, Java hoặc công nghệ mà dự án đang sử dụng.
- Điểm khởi chạy: Tệp hoặc lệnh được dùng để khởi động ứng dụng.
- Cấu hình: Các tệp khai báo môi trường, thư viện và thiết lập hệ thống.
- Cấu trúc chính: Những thư mục chứa giao diện, xử lý nghiệp vụ, dữ liệu và kiểm thử.
- Mục tiêu tìm hiểu: Toàn bộ kiến trúc, một chức năng cụ thể hay nguyên nhân gây ra lỗi.
Không cần gửi toàn bộ dự án ngay từ đầu. Với hệ thống lớn, hãy bắt đầu bằng cấu trúc thư mục và những tệp cốt lõi. Sau khi xác định được các thành phần liên quan, bạn mới mở rộng phạm vi phân tích.
Kiểm tra những tệp quan trọng trước tiên
Mỗi ngôn ngữ và framework có quy ước tổ chức khác nhau, nhưng thường có một số nhóm tệp đáng đọc trước khi đi sâu vào nghiệp vụ.
| Nhóm tệp | Thông tin cần tìm | Mục đích |
|---|---|---|
| Tệp khởi chạy | Điểm bắt đầu thực thi chương trình | Hiểu ứng dụng được khởi động như thế nào |
| Tệp cấu hình | Thiết lập môi trường, kết nối và tùy chọn hệ thống | Xác định những yếu tố ảnh hưởng đến hoạt động của ứng dụng |
| Tệp khai báo thư viện | Các gói phụ thuộc và phiên bản liên quan | Nhận diện công nghệ mà dự án đang sử dụng |
| Tệp định tuyến | URL, phương thức HTTP và bộ xử lý tương ứng | Tìm đường đi từ request đến chức năng |
| Tệp xử lý nghiệp vụ | Điều kiện, quy tắc và thao tác dữ liệu | Hiểu chức năng thực sự hoạt động ra sao |
| Tệp kiểm thử | Các tình huống đầu vào và kết quả mong đợi | Đối chiếu hành vi dự kiến với cách triển khai |
Đây là thứ tự tham khảo, không phải quy tắc cố định. Chẳng hạn, nếu bạn cần hiểu một hàm tính giá sản phẩm, hãy bắt đầu từ hàm đó và truy ngược nơi gọi, thay vì đọc toàn bộ hệ thống theo thứ tự thư mục.
Bảo vệ thông tin nhạy cảm
Trước khi đưa mã nguồn vào công cụ AI, hãy kiểm tra xem dự án có chứa mật khẩu cơ sở dữ liệu, API key, token truy cập, khóa riêng tư hoặc dữ liệu khách hàng hay không. Không nên gửi những thông tin này vào công cụ chưa được phê duyệt hoặc môi trường không đáp ứng yêu cầu bảo mật của dự án.
Nếu cần minh họa cấu hình, hãy thay giá trị bí mật bằng dữ liệu giả. Đồng thời, không mặc định rằng việc ẩn một tệp khỏi kết quả hiển thị đồng nghĩa với việc công cụ không thể đọc tệp đó. Hãy kiểm tra quyền truy cập, quy tắc loại trừ và chính sách xử lý dữ liệu của công cụ đang sử dụng.
Quy trình sử dụng AI để hiểu code từ tổng thể đến chi tiết
Cách làm hiệu quả là chia quá trình phân tích thành nhiều bước có liên kết với nhau. Mỗi bước giải quyết một câu hỏi, tạo ra thông tin đầu vào cho bước tiếp theo và hạn chế việc AI đưa ra kết luận khi chưa có đủ ngữ cảnh.
Bước 1: Yêu cầu AI lập bản đồ dự án
Đừng bắt đầu bằng câu hỏi quá rộng như “Hãy giải thích toàn bộ code này”. Một dự án lớn có thể chứa hàng trăm tệp, khiến câu trả lời trở nên dài dòng nhưng không giúp bạn biết nên bắt đầu từ đâu.
Thay vào đó, hãy yêu cầu AI xác định kiến trúc tổng quan, vai trò của các thư mục và mối liên hệ giữa những thành phần chính. Bạn cũng nên yêu cầu công cụ phân biệt thông tin đã xác nhận từ mã nguồn với những nhận định chỉ mang tính suy đoán.
Ví dụ, với một dự án web PHP có sẵn, bạn có thể sử dụng prompt sau:
Hãy phân tích cấu trúc dự án PHP hiện tại để giúp tôi hiểu cách hệ thống hoạt động.
Yêu cầu:
1. Xác định điểm khởi chạy và cách ứng dụng tiếp nhận request.
2. Giải thích vai trò của các thư mục và tệp quan trọng.
3. Xác định các thành phần xử lý giao diện, nghiệp vụ và dữ liệu.
4. Tìm những tệp có khả năng liên quan trực tiếp đến chức năng chính.
5. Mô tả mối quan hệ giữa các thành phần dựa trên code thực tế.
6. Nêu rõ thông tin nào đã xác minh và thông tin nào chưa đủ căn cứ.
Chưa chỉnh sửa hoặc tạo lại bất kỳ tệp nào.
Hãy trình bày theo thứ tự ưu tiên để người mới tiếp quản
dự án có thể bắt đầu đọc code.
Kết quả cần đạt được không phải là bản mô tả mọi tệp trong dự án. Bạn cần một bản đồ đủ rõ để biết điểm bắt đầu, những thành phần quan trọng và hướng đọc tiếp theo.
Bước 2: Lần theo một chức năng cụ thể
Sau khi hiểu cấu trúc tổng thể, hãy chọn một chức năng quen thuộc, chẳng hạn đăng nhập, tìm kiếm sản phẩm hoặc tạo đơn hàng. Những chức năng có đầu vào và kết quả rõ ràng thường dễ dùng để khám phá kiến trúc của dự án.
Hãy yêu cầu AI lần theo luồng xử lý từ điểm người dùng bắt đầu thao tác đến khi hệ thống trả về kết quả. Với ứng dụng web, luồng này có thể bao gồm giao diện, request HTTP, router, controller, service, model, truy vấn cơ sở dữ liệu và phản hồi.
Không phải dự án nào cũng có đầy đủ các lớp trên. Một ứng dụng PHP viết theo kiểu thủ tục có thể xử lý nhiều công việc ngay trong một tệp, trong khi hệ thống sử dụng framework có thể tách chúng thành nhiều thành phần. AI cần mô tả kiến trúc thực tế thay vì áp đặt một mô hình lý tưởng lên mã nguồn.
Bước 3: Đọc những hàm quan trọng theo đúng ngữ cảnh
Khi đã xác định được các tệp liên quan, hãy chọn một hàm hoặc phương thức và yêu cầu AI giải thích từng phần theo chức năng. Thay vì chỉ hỏi một đoạn code có ý nghĩa gì, hãy tìm hiểu những yếu tố ảnh hưởng trực tiếp đến hành vi của nó.
- Hàm nhận những tham số nào và chúng đến từ đâu?
- Giá trị trả về được sử dụng ở đâu?
- Những điều kiện nào quyết định nhánh xử lý?
- Hàm có đọc, ghi hoặc thay đổi dữ liệu hay không?
- Có thể xảy ra lỗi hoặc trường hợp ngoại lệ nào?
- Những hàm khác nào được gọi bên trong?
Với mỗi kết luận quan trọng, hãy yêu cầu AI chỉ ra tên tệp, hàm hoặc đoạn code làm căn cứ. Nếu công cụ hỗ trợ điều hướng mã nguồn, bạn có thể mở trực tiếp vị trí được đề cập để kiểm tra.
Bước 4: Xây dựng sơ đồ phụ thuộc
Một chức năng thường không hoạt động độc lập. Hàm xử lý đơn hàng có thể phụ thuộc vào hàm kiểm tra tồn kho, phương thức tính giá, cơ chế xác thực và thao tác lưu dữ liệu.
Hãy yêu cầu AI liệt kê những thành phần gọi đến hàm đang xem xét, các hàm được gọi bên trong và dữ liệu được truyền giữa chúng. Khi cần, hãy giới hạn phạm vi vào một chức năng để tránh tạo ra sơ đồ quá phức tạp.
Thông tin này giúp bạn phân biệt code thực sự chịu trách nhiệm cho một hành vi với code chỉ hỗ trợ hoặc hiển thị kết quả. Đây cũng là cơ sở để đánh giá phạm vi ảnh hưởng trước khi sửa đổi dự án.
Bước 5: Xác minh lại bằng mã nguồn và kiểm thử
AI có thể diễn giải sai tên hàm, bỏ sót một nhánh điều kiện hoặc suy luận nhầm mối quan hệ giữa các thành phần. Vì vậy, không nên coi câu trả lời của AI là tài liệu chính thức của dự án khi chưa kiểm tra.
Hãy đối chiếu giải thích với code thực tế, kiểm tra các vị trí được dẫn ra và chạy những bài kiểm thử phù hợp nếu môi trường cho phép. Với chức năng quan trọng, cần kiểm tra cả trường hợp thành công, dữ liệu không hợp lệ, quyền truy cập không phù hợp và những lỗi có thể phát sinh.
Nếu kết quả phân tích chưa rõ, hãy yêu cầu AI giải thích lại một điểm cụ thể hoặc đưa ra căn cứ trực tiếp từ mã nguồn. Cách làm này giúp bạn dần hình thành hiểu biết có thể kiểm chứng, thay vì chỉ ghi nhớ một bản tóm tắt do AI tạo ra.
Cách viết prompt để AI giải thích code chính xác hơn
Prompt tốt không nhất thiết phải dài. Điều quan trọng là nêu rõ mục tiêu, phạm vi mã nguồn, mức độ giải thích mong muốn và cách trình bày kết quả. Với những câu hỏi quá chung chung, AI thường đưa ra kiến thức lập trình phổ thông thay vì giải thích đúng dự án của bạn.
Yêu cầu giải thích dựa trên code thực tế
Thay vì hỏi “Controller là gì?”, hãy hỏi controller cụ thể trong dự án đang xử lý request nào, gọi đến thành phần nào và trả về dữ liệu gì. Nếu muốn học thêm khái niệm, bạn có thể yêu cầu AI giải thích khái niệm đó ngay sau khi phân tích code.
Mẫu prompt có thể tái sử dụng:
Hãy giải thích hàm [tên hàm] trong tệp [đường dẫn tệp].
Tôi muốn biết:
- Mục đích của hàm trong dự án hiện tại.
- Ý nghĩa của từng tham số và giá trị trả về.
- Trình tự thực thi và các nhánh điều kiện.
- Những hàm hoặc thành phần mà hàm này phụ thuộc.
- Các tác động đến dữ liệu hoặc hệ thống bên ngoài.
- Những trường hợp lỗi có thể xảy ra.
Mỗi nhận định quan trọng cần có căn cứ từ code.
Không tự suy đoán hành vi của thành phần chưa được cung cấp.
Nếu thiếu thông tin, hãy nêu rõ cần kiểm tra thêm tệp nào.
Chỉ phân tích, không sửa đổi mã nguồn.
Chia câu hỏi lớn thành những câu hỏi nhỏ
Khi đọc một chức năng phức tạp, hãy đi theo trình tự: chức năng làm gì, được gọi từ đâu, nhận dữ liệu nào, xử lý ra sao, phụ thuộc vào những thành phần nào và có thể thất bại ở đâu.
Cách hỏi tuần tự giúp bạn phát hiện những điểm chưa hiểu để đào sâu đúng chỗ. Nếu yêu cầu AI trả lời tất cả trong một lần, phần giải thích có thể quá dài hoặc bỏ qua những chi tiết bạn thực sự cần.
Yêu cầu AI phân biệt sự thật và giả thuyết
Một trong những rủi ro khi dùng AI để đọc code là câu trả lời nghe rất hợp lý nhưng không đúng với hệ thống thực tế. Ví dụ, AI có thể cho rằng một hàm lưu dữ liệu vào cơ sở dữ liệu chỉ vì tên hàm chứa từ save, trong khi hàm đó thực tế chỉ chuẩn bị dữ liệu.
Để hạn chế vấn đề này, hãy yêu cầu AI chia kết quả thành ba nhóm: thông tin được xác nhận trực tiếp từ code, nhận định được suy ra từ các mối quan hệ đã quan sát và câu hỏi chưa đủ dữ liệu để kết luận.
Đặc biệt, nếu AI nói một hàm được gọi tại một vị trí cụ thể, hãy kiểm tra nơi gọi đó. Nếu AI khẳng định dữ liệu được ghi vào bảng nào, hãy tìm truy vấn hoặc lớp dữ liệu tương ứng thay vì chỉ dựa vào tên biến.
Điều chỉnh mức độ giải thích theo kinh nghiệm
Nếu bạn mới tiếp cận ngôn ngữ lập trình, hãy yêu cầu AI giải thích thuật ngữ, vai trò của từng thành phần và một ví dụ minh họa đơn giản. Nếu đã có kinh nghiệm, hãy tập trung vào luồng dữ liệu, thiết kế hệ thống, phụ thuộc, tác dụng phụ và những trường hợp biên.
Mục tiêu không phải là để AI diễn giải mọi dòng code bằng ngôn ngữ thông thường. Bạn cần hiểu những điểm có ảnh hưởng đến hành vi của hệ thống, biết cách kiểm tra chúng và có khả năng tự lần theo mã nguồn khi gặp vấn đề tương tự.
Thực hành phân tích một chức năng có sẵn bằng Vibe Coding
Để hiểu cách áp dụng Vibe Coding vào công việc thực tế, hãy xem xét một tình huống phổ biến: bạn tiếp nhận website PHP đã hoạt động nhưng chưa nắm rõ cách chức năng tìm kiếm sản phẩm được triển khai.
Yêu cầu của bạn không phải viết lại chức năng tìm kiếm mà là hiểu toàn bộ quá trình xử lý, xác định các thành phần liên quan và biết chính xác nơi cần kiểm tra khi kết quả tìm kiếm không đúng.
Bắt đầu từ cấu trúc thư mục và chức năng cần tìm
Giả sử dự án có cấu trúc đơn giản như sau:
website/
├── index.php
├── config/
│ └── database.php
├── controllers/
│ └── ProductController.php
├── models/
│ └── Product.php
├── views/
│ └── products/
│ └── search.php
└── routes/
└── web.php
Đây chỉ là cấu trúc minh họa, không phải quy ước bắt buộc của mọi dự án PHP. Mục tiêu của bước đầu tiên là xác định vai trò dự kiến của từng tệp, sau đó kiểm tra xem cách tổ chức thực tế có đúng như vậy hay không.
Bạn có thể yêu cầu AI phân tích theo hướng sau:
Tôi cần hiểu chức năng tìm kiếm sản phẩm trong dự án PHP hiện tại.
Hãy kiểm tra cấu trúc dự án và xác định:
1. Request tìm kiếm được tiếp nhận ở đâu.
2. Thành phần nào đọc từ khóa người dùng nhập.
3. Thành phần nào thực hiện xử lý nghiệp vụ.
4. Truy vấn dữ liệu được xây dựng ở đâu.
5. Kết quả được chuyển đến giao diện như thế nào.
Hãy dẫn ra đường dẫn tệp và tên hàm tương ứng.
Chỉ kết luận những gì có căn cứ từ mã nguồn.
Nếu chưa tìm thấy một thành phần, hãy nói rõ thay vì tự tạo ra.
Sau khi nhận kết quả, bạn cần kiểm tra những tệp mà AI chỉ ra. Nếu hệ thống sử dụng router tự động, một framework hoặc cơ chế định tuyến riêng, đường đi của request có thể khác với cấu trúc minh họa.
Lần theo dữ liệu từ đầu vào đến kết quả
Giả sử sau khi kiểm tra, bạn tìm thấy một đoạn code xử lý từ khóa tìm kiếm như sau:
$keyword = trim($_GET['keyword'] ?? '');
$products = $productModel->search($keyword);
Đoạn code này cho thấy chương trình lấy giá trị từ tham số GET có tên keyword, sử dụng chuỗi rỗng nếu tham số không tồn tại và loại bỏ khoảng trắng ở hai đầu bằng trim(). Sau đó, chương trình gọi phương thức search() trên đối tượng productModel và truyền từ khóa vào.
Tuy nhiên, chỉ từ hai dòng code trên, bạn chưa thể kết luận hệ thống tìm kiếm theo tên sản phẩm, mã sản phẩm hay mô tả. Bạn cũng chưa biết truy vấn có phân trang hay không, có giới hạn số kết quả hay không và dữ liệu được sắp xếp theo tiêu chí nào.
Đây là lúc cần đặt câu hỏi tiếp theo:
Hãy lần theo biến $products trong chức năng tìm kiếm.
Tìm phần khai báo hoặc khởi tạo $productModel,
sau đó mở phương thức search() được gọi trong đoạn code.
Giải thích:
- Từ khóa được sử dụng trong truy vấn như thế nào.
- Những trường dữ liệu nào được tìm kiếm.
- Có giới hạn số lượng kết quả hay không.
- Cách xử lý khi không có sản phẩm phù hợp.
- Những vấn đề cần kiểm tra về bảo mật và hiệu năng.
Chỉ dựa trên code hiện có.
Không chỉnh sửa bất kỳ tệp nào.
Qua từng câu hỏi, bạn sẽ xây dựng được một chuỗi thông tin liên kết: dữ liệu đầu vào, nơi tiếp nhận, phương thức xử lý, truy vấn dữ liệu và kết quả trả về. Đây chính là nền tảng để hiểu chức năng mà không cần đọc toàn bộ dự án.
Đọc truy vấn và đánh giá cách xử lý dữ liệu
Giả sử phương thức tìm kiếm có đoạn code sau:
public function search(string $keyword): array
{
$sql = "SELECT id, name, price
FROM products
WHERE name LIKE :keyword";
$stmt = $this->pdo->prepare($sql);
$stmt->execute([
'keyword' => '%' . $keyword . '%'
]);
return $stmt->fetchAll(PDO::FETCH_ASSOC);
}
Đoạn code trên sử dụng PDO để chuẩn bị và thực thi truy vấn với tham số liên kết. Từ đó, bạn có thể xác định một số hành vi cụ thể:
- Truy vấn lấy ba trường gồm mã sản phẩm, tên và giá.
- Điều kiện tìm kiếm chỉ áp dụng cho trường name.
- Hai ký tự phần trăm được thêm vào hai đầu từ khóa để tìm chuỗi con theo cách so khớp của toán tử LIKE.
- Kết quả được trả về dưới dạng mảng kết hợp.
Đồng thời, bạn cũng nhận ra những điểm cần tìm hiểu thêm. Phương thức không thể hiện giới hạn kết quả, chưa có tiêu chí sắp xếp và không tự xử lý riêng trường hợp từ khóa rỗng. Nếu số lượng sản phẩm lớn, việc tìm kiếm có thể cần được đánh giá về hiệu năng.
Cần lưu ý rằng tham số liên kết giúp tách dữ liệu đầu vào khỏi cấu trúc SQL, nhưng không có nghĩa mọi vấn đề bảo mật đều được giải quyết. Nếu yêu cầu tìm kiếm hỗ trợ ký tự đại diện theo nghĩa đen, bạn còn cần xem xét cách xử lý ký tự phần trăm và dấu gạch dưới trong từ khóa. Hiệu năng cũng phụ thuộc vào hệ quản trị cơ sở dữ liệu, dữ liệu thực tế và cách truy vấn được thực thi.
Thay vì yêu cầu AI viết lại phương thức ngay lập tức, hãy hỏi nó giải thích từng quyết định trong code và chỉ ra những rủi ro cần kiểm chứng. Như vậy, bạn vừa hiểu cách triển khai hiện tại vừa tránh vô tình thay đổi hành vi của hệ thống.
Dùng Vibe Coding để truy tìm nguyên nhân lỗi trong code cũ
Khi một chức năng hoạt động không đúng, việc đọc code bằng AI có thể giúp thu hẹp phạm vi tìm kiếm. Tuy nhiên, muốn tìm nguyên nhân chính xác, bạn cần cung cấp triệu chứng cụ thể thay vì chỉ nói rằng hệ thống đang bị lỗi.
Cung cấp đầy đủ thông tin về lỗi
Một báo cáo lỗi hữu ích nên có những thông tin như:
- Hành vi mong đợi: Hệ thống đáng lẽ phải làm gì.
- Hành vi thực tế: Kết quả đang xảy ra khác với mong đợi ở điểm nào.
- Cách tái hiện: Những thao tác hoặc dữ liệu dẫn đến lỗi.
- Thông báo lỗi: Nội dung lỗi và vị trí xuất hiện trong log, nếu có.
- Phạm vi ảnh hưởng: Lỗi xảy ra với mọi người dùng hay chỉ trong một số điều kiện.
- Thay đổi gần đây: Những cập nhật có thể liên quan đến thời điểm lỗi bắt đầu.
Không phải trường hợp nào cũng có đủ thông tin. Nếu chưa biết nguyên nhân, hãy bắt đầu bằng việc xác định các giả thuyết có thể xảy ra và những dữ liệu cần thu thập để phân biệt chúng.
Yêu cầu AI phân tích theo giả thuyết
Giả sử chức năng tìm kiếm đôi lúc không trả về sản phẩm dù sản phẩm đó tồn tại. Có nhiều khả năng cần kiểm tra: dữ liệu đầu vào không đúng, điều kiện truy vấn quá chặt, dữ liệu chứa ký tự đặc biệt, kết nối cơ sở dữ liệu gặp vấn đề hoặc kết quả bị lọc ở một bước khác.
Bạn có thể sử dụng prompt sau:
Chức năng tìm kiếm sản phẩm đôi lúc không trả về kết quả
dù sản phẩm tồn tại trong cơ sở dữ liệu.
Hãy phân tích code hiện tại để tìm nguyên nhân có thể xảy ra.
Yêu cầu:
1. Lần theo luồng xử lý từ đầu vào đến kết quả.
2. Liệt kê các giả thuyết có căn cứ từ code.
3. Với mỗi giả thuyết, chỉ rõ tệp hoặc đoạn code liên quan.
4. Đề xuất cách kiểm tra để xác nhận hoặc loại trừ giả thuyết.
5. Phân biệt nguyên nhân đã xác minh với khả năng chưa kiểm chứng.
6. Ưu tiên những bước kiểm tra ít rủi ro trước.
Chưa sửa code và không tự kết luận khi chưa đủ bằng chứng.
Cách yêu cầu này giúp bạn tránh việc AI chọn ngay một nguyên nhân nghe có vẻ hợp lý rồi đề xuất sửa code dựa trên giả định đó.
Kiểm tra nguyên nhân trước khi áp dụng bản sửa
Sau khi có danh sách giả thuyết, hãy kiểm tra từng giả thuyết bằng log, dữ liệu thử nghiệm, truy vấn hoặc bài kiểm thử phù hợp. Nếu một giả thuyết không đúng với kết quả quan sát, hãy loại bỏ nó và tiếp tục kiểm tra khả năng khác.
Khi đã xác định được nguyên nhân, bạn có thể yêu cầu AI đề xuất thay đổi nhỏ nhất có thể giải quyết vấn đề. Hãy yêu cầu công cụ giải thích vì sao bản sửa phù hợp, những hành vi nào có thể bị ảnh hưởng và cần kiểm thử những trường hợp nào.
Đối với lỗi liên quan đến thanh toán, phân quyền, dữ liệu khách hàng hoặc thao tác ghi dữ liệu quan trọng, cần thận trọng hơn. Hãy tái hiện lỗi trong môi trường thử nghiệm, sao lưu dữ liệu khi phù hợp và không chạy những thao tác có nguy cơ phá hủy dữ liệu trên hệ thống thật chỉ để kiểm tra một giả thuyết.
Những sai lầm cần tránh khi dùng AI đọc mã nguồn
Vibe Coding có thể tăng tốc quá trình làm quen với dự án, nhưng nếu sử dụng không đúng cách, nó cũng khiến bạn hiểu sai kiến trúc, bỏ qua những phụ thuộc quan trọng hoặc chấp nhận một bản giải thích thiếu căn cứ.
Đọc bản tóm tắt rồi cho rằng đã hiểu hệ thống
Bản tóm tắt giúp định hướng nhưng không thể thay thế việc kiểm tra các nhánh xử lý quan trọng. Hai hàm có tên gần giống nhau có thể phục vụ mục đích khác nhau, trong khi một chức năng có thể được triển khai qua nhiều lớp mà bản tóm tắt không đề cập hết.
Hãy chọn một vài luồng nghiệp vụ quan trọng để lần theo đầy đủ. Bạn chỉ nên coi mình đã hiểu một chức năng khi có thể giải thích đầu vào, trình tự xử lý, kết quả, phụ thuộc và những trường hợp ngoại lệ đáng chú ý.
Tin vào tên biến và tên hàm mà không kiểm tra cách triển khai
Tên hàm như validateUser(), saveOrder() hoặc sendNotification() gợi ý mục đích của code nhưng không chứng minh hàm thực sự làm gì. Hàm có thể chỉ kiểm tra một phần điều kiện, ghi dữ liệu vào bộ nhớ tạm hoặc gửi thông báo thông qua một cơ chế gián tiếp.
Khi đọc code bằng AI, hãy yêu cầu giải thích dựa trên phần thân hàm, những hàm được gọi và các tác động quan sát được. Đừng suy luận chức năng chỉ từ tên gọi.
Đưa quá nhiều code vào một câu hỏi
Cung cấp toàn bộ mã nguồn có vẻ giúp AI hiểu nhiều hơn, nhưng phạm vi quá lớn có thể khiến câu trả lời thiếu trọng tâm, khó kiểm chứng và bỏ sót chi tiết quan trọng.
Thay vì yêu cầu giải thích mọi thứ trong một lần, hãy bắt đầu từ chức năng cần tìm hiểu, sau đó mở rộng đến các thành phần có liên quan. Nếu cần xem xét toàn bộ kiến trúc, hãy chia kết quả thành từng phần và tổng hợp lại sau khi đã kiểm tra.
Cho phép AI sửa code khi mục tiêu chỉ là tìm hiểu
Trong giai đoạn khám phá, nên yêu cầu AI chỉ phân tích và giải thích. Nếu công cụ có quyền chỉnh sửa tệp, hãy kiểm tra chế độ hoạt động và quyền truy cập trước khi sử dụng.
Khi cần thực hiện thay đổi, hãy tách yêu cầu sửa code khỏi yêu cầu phân tích, xem phần chênh lệch trước khi chấp nhận và kiểm thử lại hành vi liên quan. Với dự án đang vận hành, sử dụng hệ thống quản lý phiên bản và làm việc trên nhánh riêng sẽ giúp việc xem xét hoặc hoàn tác thay đổi dễ dàng hơn.
Kiểm chứng mức độ hiểu code sau khi phân tích
Đọc lời giải thích của AI có thể tạo cảm giác đã nắm được vấn đề, nhưng hiểu thực sự đòi hỏi bạn có thể diễn giải lại cách hệ thống hoạt động và dự đoán được kết quả trong những tình huống cụ thể.
Tự giải thích lại luồng xử lý
Sau khi AI phân tích một chức năng, hãy thử mô tả bằng lời cách dữ liệu đi qua các thành phần. Nếu không thể giải thích vì sao một hàm được gọi, dữ liệu được biến đổi ở đâu hoặc kết quả được trả về như thế nào, bạn cần quay lại kiểm tra phần còn chưa rõ.
Bạn cũng có thể yêu cầu AI đặt câu hỏi kiểm tra kiến thức dựa trên chính code của dự án. Tuy nhiên, đáp án vẫn cần được đối chiếu với mã nguồn thay vì mặc định là đúng.
Kiểm tra các trường hợp đầu vào khác nhau
Với một chức năng tìm kiếm, hãy xem xét trường hợp có từ khóa, từ khóa rỗng, dữ liệu chứa khoảng trắng, ký tự đặc biệt và trường hợp không có kết quả. Với chức năng đăng nhập, hãy kiểm tra thông tin hợp lệ, mật khẩu sai, tài khoản không tồn tại và những điều kiện liên quan đến trạng thái tài khoản.
Mục tiêu là xác định liệu cách giải thích của AI có phù hợp với hành vi thực tế ở nhiều tình huống hay chỉ đúng với một ví dụ đơn giản.
Đối chiếu với kiểm thử và tài liệu dự án
Nếu dự án có unit test, integration test hoặc tài liệu nghiệp vụ, hãy sử dụng chúng để kiểm chứng cách hiểu của mình. Kiểm thử hiện có cũng có thể đã lỗi thời, vì vậy cần so sánh kết quả kiểm thử với yêu cầu và hành vi thực tế.
Nếu chưa có kiểm thử, hãy xây dựng những trường hợp kiểm tra tối thiểu cho chức năng quan trọng trước khi sửa đổi. Điều này giúp bạn phát hiện các hành vi bị thay đổi ngoài ý muốn khi áp dụng đề xuất từ AI.
Quy trình chuẩn để tiếp quản dự án bằng Vibe Coding
Để tránh phải phân tích lại từ đầu mỗi khi chuyển sang một chức năng khác, bạn nên lưu lại những thông tin đã được kiểm chứng trong quá trình khám phá dự án. Tài liệu này không cần quá dài nhưng phải dễ cập nhật và có thể dùng lại.
- Lập bản đồ hệ thống: Ghi lại điểm khởi chạy, các thành phần chính và vai trò của từng thư mục quan trọng.
- Chọn luồng nghiệp vụ: Ưu tiên những chức năng cốt lõi hoặc liên quan trực tiếp đến nhiệm vụ cần thực hiện.
- Lần theo dữ liệu: Xác định đầu vào, nơi xử lý, phụ thuộc, nơi lưu trữ và kết quả trả về.
- Kiểm chứng thông tin: Đối chiếu nhận định của AI với mã nguồn, log, kiểm thử và tài liệu có sẵn.
- Ghi lại kiến thức: Lưu sơ đồ luồng xử lý, các tệp liên quan và những điểm chưa được xác minh.
- Thay đổi khi cần thiết: Chỉ thực hiện chỉnh sửa sau khi hiểu phạm vi ảnh hưởng và xác định được cách kiểm thử.
- Cập nhật tài liệu: Bổ sung thông tin khi code hoặc kiến trúc thay đổi để tránh sử dụng những kết luận đã lỗi thời.
Với dự án lớn, không nhất thiết phải hiểu toàn bộ hệ thống trước khi bắt đầu làm việc. Bạn có thể ưu tiên phần liên quan trực tiếp đến nhiệm vụ hiện tại, đồng thời mở rộng hiểu biết khi phát sinh yêu cầu mới. Cách tiếp cận này thực tế hơn việc cố đọc tất cả tệp ngay từ đầu.
Khi nào nên dùng Vibe Coding để đọc code và khi nào cần tự phân tích?
AI phù hợp với những công việc cần tổng hợp thông tin, giải thích cấu trúc, lần theo quan hệ giữa các thành phần và đề xuất hướng kiểm tra. Tuy nhiên, không phải mọi nhiệm vụ đều nên giao hoàn toàn cho AI.
| Công việc | Vai trò phù hợp của AI | Điều cần tự kiểm tra |
|---|---|---|
| Khám phá dự án mới | Tóm tắt cấu trúc và đề xuất thứ tự đọc code | Điểm khởi chạy và kiến trúc thực tế |
| Hiểu một hàm | Giải thích tham số, điều kiện và giá trị trả về | Hành vi ở từng nhánh xử lý |
| Truy tìm lỗi | Đưa ra giả thuyết và hướng kiểm tra | Bằng chứng tái hiện và nguyên nhân thực tế |
| Đánh giá phụ thuộc | Liệt kê nơi gọi và các thành phần liên quan | Những đường gọi gián tiếp hoặc động có thể bị bỏ sót |
| Kiểm tra bảo mật | Hỗ trợ nhận diện điểm đáng ngờ trong code | Rủi ro thực tế và kết quả kiểm tra chuyên môn |
| Sửa đổi chức năng | Đề xuất bản sửa và trường hợp kiểm thử | Diff, hành vi hồi quy và kết quả trên môi trường phù hợp |
Đối với những hệ thống có yêu cầu bảo mật cao, dữ liệu quan trọng hoặc nghiệp vụ phức tạp, AI chỉ nên là công cụ hỗ trợ. Những kết luận ảnh hưởng đến kiến trúc, an toàn dữ liệu và hoạt động sản xuất cần được kiểm chứng bằng quy trình kỹ thuật phù hợp.
Câu hỏi thường gặp khi sử dụng Vibe Coding để đọc code
Người mới học lập trình có thể dùng Vibe Coding để hiểu dự án không?
Có. Người mới có thể yêu cầu AI giải thích thuật ngữ, vai trò của tệp và luồng xử lý bằng ngôn ngữ dễ hiểu. Tuy nhiên, bạn vẫn cần học những kiến thức cơ bản về ngôn ngữ lập trình, cấu trúc dữ liệu và cách chương trình thực thi để nhận biết khi nào lời giải thích chưa chính xác.
Có cần cung cấp toàn bộ mã nguồn cho AI không?
Không. Hãy cung cấp phạm vi mã nguồn phù hợp với câu hỏi. Khi tìm hiểu một chức năng, cấu trúc thư mục, điểm tiếp nhận request và các tệp liên quan thường là điểm khởi đầu tốt. Chỉ mở rộng phạm vi khi cần truy tìm phụ thuộc hoặc xác minh hành vi.
AI có thể hiểu chính xác một dự án chưa có tài liệu không?
AI có thể hỗ trợ tái dựng cách hoạt động của dự án từ mã nguồn, nhưng mức độ chính xác phụ thuộc vào khả năng truy cập code, chất lượng ngữ cảnh và mức độ phức tạp của hệ thống. Những quy tắc nghiệp vụ không được thể hiện trong code hoặc tài liệu có thể không thể xác định chắc chắn chỉ bằng phân tích mã nguồn.
Dùng Vibe Coding đọc code có làm giảm khả năng lập trình không?
Điều đó phụ thuộc vào cách sử dụng. Nếu chỉ sao chép câu trả lời và chấp nhận mọi kết luận, bạn có thể bỏ lỡ cơ hội rèn luyện tư duy phân tích. Ngược lại, nếu dùng AI để đặt câu hỏi, đối chiếu code, tự giải thích lại luồng xử lý và kiểm tra các giả thuyết, bạn có thể học cách đọc những dự án phức tạp hiệu quả hơn.
Có nên để AI tự sửa những đoạn code chưa hiểu rõ không?
Không nên bắt đầu bằng việc sửa code khi chưa hiểu chức năng hiện tại. Hãy yêu cầu AI phân tích trước, xác định nguyên nhân hoặc mục tiêu thay đổi, sau đó mới xem xét bản sửa nhỏ và kiểm thử. Đối với hệ thống quan trọng, cần có quy trình đánh giá và phê duyệt trước khi triển khai.
Kết luận
Sử dụng Vibe Coding để đọc và hiểu code có sẵn hiệu quả nhất khi bạn xem AI như một trợ lý phân tích, không phải nguồn kết luận tuyệt đối. Hãy bắt đầu từ cấu trúc dự án, chọn một chức năng cụ thể, lần theo dữ liệu qua từng thành phần và yêu cầu giải thích có căn cứ từ mã nguồn.
Điểm quan trọng nhất là luôn kết hợp lời giải thích với việc kiểm chứng. Khi đã xác định được luồng xử lý, các mối quan hệ phụ thuộc và những trường hợp ngoại lệ, bạn sẽ dễ dàng tiếp quản dự án, tìm nguyên nhân lỗi hoặc thực hiện thay đổi mà không phải đọc lại toàn bộ code từ đầu.
Đối với Web Mới, việc hiểu đúng mã nguồn cũng là nền tảng để bảo trì và phát triển website bền vững. Dù sử dụng AI để tăng tốc công việc, lập trình viên vẫn cần giữ quyền kiểm soát đối với mã nguồn, dữ liệu và quyết định kỹ thuật của dự án.
- 0 Bình luậ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 *