Đây là bài thực hành tổng hợp toàn bộ kỹ năng của Module 6 — nơi lý thuyết về hallucination, ownership, review, và verification hội tụ thành một quy trình audit hoàn chỉnh mà bạn có thể áp dụng ngay vào công việc thật.
Bối Cảnh Tình Huống
Hãy tưởng tượng tình huống rất thực tế: bạn vừa gia nhập một team, hoặc vừa được giao tiếp quản một module được xây dựng phần lớn bởi một AI coding agent trong một "vibe coding session" (phiên code theo cảm hứng, ít kiểm soát) trước đó — có thể do chính bạn làm vội, hoặc do đồng nghiệp để lại. Module đó là hệ thống quản lý đơn hàng và khuyến mãi (order & promotion management) cho một nền tảng thương mại điện tử nhỏ: nhận đơn hàng, áp dụng coupon, tính phí vận chuyển, kiểm tra tồn kho, và ghi log giao dịch.
Codebase này đã "chạy được" — demo trông ổn, một vài test cơ bản pass — nhưng chưa từng trải qua một audit nghiêm túc. Nhiệm vụ của bạn: tiến hành một cuộc audit toàn diện, có hệ thống, để xác định module này có đủ an toàn để đưa vào production hay không, và nếu chưa, remediate (khắc phục) những vấn đề nghiêm trọng nhất trước khi ship.
Đây không phải bài tập tìm lỗi ngẫu nhiên — đây là mô phỏng chính xác công việc thực tế mà senior engineer làm khi được giao "thừa kế" một codebase AI-generated không rõ nguồn gốc chất lượng. Quy trình 6 giai đoạn dưới đây là khung làm việc bạn có thể tái sử dụng cho bất kỳ tình huống tương tự nào trong sự nghiệp.
Mẹo: Trước khi bắt đầu audit bất kỳ codebase AI-generated nào trong thực tế, luôn hỏi trước: "Ai đã tạo ra nó, theo quy trình nào, và đã qua review chưa?" — câu trả lời quyết định mức độ nghiêm ngặt cần áp dụng ngay từ đầu.
Giai Đoạn 1: Audit Ban Đầu — Đối Chiếu Spec vs. Thực Tế
Bước đầu tiên của mọi audit không phải đọc code — mà là xác định rõ code này lẽ ra phải làm gì, sau đó mới đối chiếu với nó thực sự làm gì.
Thu thập mọi spec/yêu cầu có sẵn. Đọc PR description, comment, ticket liên quan, hoặc README nếu có. Nếu không có spec chính thức nào, đây bản thân đã là một phát hiện audit quan trọng — codebase không có spec rõ ràng là rủi ro tự thân.
Tái tạo spec ngầm định từ chính code, một cách có ý thức phản biện. Đọc qua code ở mức tổng quan (không đi sâu logic) để hiểu "AI nghĩ nó đang làm gì" — sau đó so sánh với business context thực tế bạn biết về nền tảng thương mại điện tử này.
Lập bảng đối chiếu Spec vs. Reality với ít nhất các cột: Yêu cầu nghiệp vụ | Có được implement không | Ghi chú lệch pha. Ví dụ: "Coupon giảm tối đa 50%" — có code clamp giá trị này không, hay bị bỏ sót?
Xác định phạm vi (scope) thực tế của module — đôi khi AI-generated code làm nhiều hơn hoặc ít hơn scope thực sự cần, cả hai đều là vấn đề (làm ít hơn → thiếu tính năng; làm nhiều hơn → tăng bề mặt tấn công và bảo trì không cần thiết).
Kết quả của giai đoạn này nên là một danh sách rõ ràng: những điểm code khớp spec, những điểm lệch, và những điểm spec bản thân còn mơ hồ cần làm rõ trước khi có thể đánh giá đúng/sai.
Mẹo: Nếu không có spec viết sẵn, hãy tự viết ra một spec ngắn (5-10 gạch đầu dòng) dựa trên hiểu biết nghiệp vụ của bạn TRƯỚC KHI đọc chi tiết code — việc này ngăn code "dẫn dắt" bạn hiểu sai yêu cầu ban đầu.
Giai Đoạn 2: Hallucination Scan — Verify Những Gì Được Generate Thực Sự Tồn Tại
Áp dụng trực tiếp kỹ thuật đã học ở chủ đề "AI Hallucinations in Code": quét toàn bộ codebase để tìm API, package, hoặc pattern không tồn tại hay bị hiểu sai.
Build/compile toàn bộ project trước tiên. Đây là bộ lọc rẻ nhất và nhanh nhất — chạy ngay để loại bỏ các package/API hallucination hiển nhiên bị bắt bởi compiler/type checker.
Liệt kê toàn bộ dependency mới và verify trên registry thật. Với mỗi package trong package.json/requirements.txt/tương đương được thêm vào cho module này, kiểm tra: package có tồn tại thật, version có khớp, và có phải chính là package bạn nghĩ (không phải package giả mạo tên tương tự — rủi ro slopsquatting).
Grep để verify mọi tham chiếu tới utility/helper nội bộ. Nếu code gọi formatCurrency, validateStock, hay bất kỳ hàm nào được cho là "đã có sẵn trong project", verify bằng grep rằng nó tồn tại thật với đúng signature được dùng.
Đối chiếu comment với logic thực tế. Với mọi comment mô tả behavior ("xử lý mọi trường hợp coupon hết hạn"), verify code thực sự làm đúng điều đó — comment sai là dạng hallucination tinh vi rất phổ biến.
Verify schema database được giả định. Nếu code query field như order.shipping_region hay coupon.max_discount_percent, đối chiếu với schema migration/model thật để xác nhận field đó tồn tại đúng tên, đúng kiểu.
Ghi lại mọi hallucination phát hiện được kèm mức độ nghiêm trọng (compile-breaking, runtime-breaking, hay silent-wrong).
Mẹo: Dành riêng một file ghi chú tạm (ví dụ
audit-notes.mdtrong scratch folder, không commit) để liệt kê từng hallucination phát hiện được kèm số dòng — đây sẽ là nguyên liệu trực tiếp cho báo cáo remediation ở Giai đoạn 6.
Giai Đoạn 3: Tính Đúng Đắn Logic — Trace Qua Các Luồng Chính
Áp dụng kỹ thuật trace tay đã học: xác định các luồng nghiệp vụ quan trọng nhất của module (tạo đơn hàng, áp dụng coupon, tính phí vận chuyển, trừ tồn kho) và trace qua từng luồng với cả happy path lẫn boundary case.
Xác định top 3-5 luồng nghiệp vụ có rủi ro cao nhất, ưu tiên theo tiêu chí: ảnh hưởng tới tiền bạc (tính phí, áp dụng giảm giá), ảnh hưởng tới tính nhất quán dữ liệu (tồn kho), hoặc có nhiều điều kiện tương tác phức tạp (coupon + VIP + khu vực giao hàng).
Trace từng luồng với input cụ thể, cả case điển hình lẫn case biên. Ví dụ với luồng áp dụng coupon: trace với coupon hợp lệ thông thường, coupon hết hạn đúng lúc nửa đêm, coupon vượt ngưỡng giảm giá tối đa, hai request áp dụng cùng một coupon giới hạn số lượt đồng thời.
Đặc biệt chú ý tới thứ tự áp dụng các rule tương tác nhau (như ví dụ về phí vận chuyển + VIP + hải đảo đã bàn ở chủ đề trước) — đây là nơi lỗi logic tinh vi nhất thường ẩn náu trong hệ thống thương mại điện tử.
Kiểm tra tính nhất quán dữ liệu qua các bước. Nếu tạo đơn hàng bao gồm nhiều bước (trừ tồn kho, tạo bản ghi đơn hàng, ghi log) — điều gì xảy ra nếu một bước ở giữa thất bại? Có transaction hoặc cơ chế rollback không, hay dữ liệu có thể rơi vào trạng thái không nhất quán (tồn kho đã trừ nhưng đơn hàng không được tạo)?
Ghi lại mọi lỗi logic phát hiện được, phân loại theo mức độ ảnh hưởng: sai số liệu (financial impact), sai trạng thái dữ liệu (data integrity), hay sai trải nghiệm người dùng (UX, không ảnh hưởng dữ liệu).
Mẹo: Vẽ sơ đồ luồng đơn giản (dù chỉ trên giấy) cho luồng "tạo đơn hàng end-to-end" trước khi trace chi tiết — bức tranh tổng thể giúp bạn không bỏ sót bước nào và nhận ra ngay chỗ thiếu transaction/rollback.
Giai Đoạn 4: Audit Bảo Mật — Các Vấn Đề OWASP Top Hàng Đầu Trong Code AI-Generated
AI coding assistant có xu hướng lặp lại một số lỗ hổng bảo mật nhất định vì chúng phổ biến trong dữ liệu huấn luyện. Áp dụng checklist dựa trên OWASP Top 10, tập trung vào những lỗi thường gặp nhất trong code AI-generated:
Injection (A03): Query database có dùng string concatenation thay vì parameterized query/ORM an toàn không? Input coupon code, search term có được sanitize trước khi dùng trong query không?
Broken Access Control (A01): Đây là lỗi phổ biến bậc nhất trong AI-generated code — kiểm tra: mọi endpoint sửa đổi đơn hàng có verify đúng user sở hữu đơn hàng đó không (không chỉ kiểm tra đã đăng nhập)? Có endpoint nào quên hẳn authorization check, chỉ có authentication check?
Cryptographic Failures (A02): Nếu có lưu thông tin nhạy cảm (dù chỉ là mã coupon nội bộ hay thông tin khách hàng), có được xử lý đúng cách không — không log plaintext, không hardcode secret trong code?
Insecure Design (A04): Có rate-limiting cho việc thử mã coupon không (tránh brute-force mã giảm giá)? Có giới hạn số lần một user có thể tạo đơn hàng trong khoảng thời gian ngắn (tránh lạm dụng)?
Security Misconfiguration (A05): Error message trả về cho client có lộ thông tin nhạy cảm không (stack trace, tên bảng database, đường dẫn file server)?
Vulnerable Components (A06): Các package được thêm vào có phiên bản đã biết lỗ hổng không (chạy audit tool như npm audit)?
Identification and Authentication Failures (A07): Session/token liên quan tới đơn hàng có được validate đúng cách, không dễ đoán hoặc dễ giả mạo không?
Software and Data Integrity Failures (A08): Có validate input từ client trước khi tin tưởng dùng để tính toán tiền không (ví dụ giá sản phẩm có được lấy từ database, hay tin vào giá client gửi lên)? Đây là lỗ hổng cực kỳ phổ biến và nghiêm trọng trong hệ thống thương mại điện tử AI-generated.
Security Logging and Monitoring Failures (A09): Các hành động nhạy cảm (áp dụng coupon, thay đổi giá, hủy đơn hàng) có được log đủ để điều tra sau này không?
Server-Side Request Forgery (A10): Nếu module gọi ra service bên ngoài dựa trên input người dùng (ví dụ webhook URL), có validate và giới hạn đích đến không?
Mẹo: Ưu tiên tuyệt đối kiểm tra "giá sản phẩm/số tiền có được server tự tính toán và validate lại, không tin dữ liệu từ client" — đây là lỗ hổng tài chính nghiêm trọng nhất và thường gặp nhất trong code thương mại điện tử AI-generated.
Giai Đoạn 5: Audit Chất Lượng Test
Test tồn tại không đồng nghĩa với test có giá trị. Giai đoạn này đánh giá liệu bộ test hiện có (nếu có) có thực sự bảo vệ được codebase hay chỉ tạo cảm giác an toàn giả.
Đánh giá coverage theo luồng nghiệp vụ, không chỉ theo % dòng code. Một module có 90% code coverage nhưng không test case nào cho boundary condition của coupon vẫn là một bộ test yếu.
Kiểm tra test có thực sự fail khi logic sai không (mutation thủ công). Chọn 2-3 test quan trọng nhất, cố tình sửa lỗi logic trong code (ví dụ đổi <= thành <), chạy lại test — nếu test vẫn pass, test đó không có giá trị thực tế dù "trông giống" đang test đúng thứ cần test.
Kiểm tra test có cover boundary case đã xác định ở Giai đoạn 3 không. Đối chiếu danh sách boundary case bạn đã trace tay với danh sách test case hiện có — khoảng trống ở đây chính là ưu tiên cần bổ sung.
Kiểm tra test có mock quá mức khiến logic thật không được chạy không. Một lỗi phổ biến trong test AI-generated: mock toàn bộ business logic quan trọng, chỉ còn test cấu trúc gọi hàm (assert hàm được gọi) thay vì test kết quả tính toán thực tế.
Kiểm tra test có test đúng những gì spec yêu cầu, hay chỉ test những gì code hiện tại làm. Nếu test được AI generate sau khi có code (thay vì từ spec), rủi ro rất cao là test chỉ xác nhận lại hành vi hiện tại — kể cả khi hành vi đó sai.
Kết quả giai đoạn này nên là danh sách cụ thể: những test case quan trọng còn thiếu, và những test hiện có nhưng "vô dụng" cần viết lại.
Mẹo: Áp dụng bài kiểm tra nhanh "test có chết không" cho toàn bộ test suite trước khi tin tưởng nó: chạy
git stash, cố tình comment ra một điều kiện quan trọng trong code, chạy test — nếu không có test nào đỏ, bộ test này đang cho bạn cảm giác an toàn giả.
Giai Đoạn 6: Remediation — Fix, Document, và Hand Off
Audit chỉ có giá trị khi nó dẫn tới hành động cụ thể. Giai đoạn cuối này biến toàn bộ phát hiện thành các fix có ưu tiên rõ ràng và tài liệu bàn giao.
Sắp xếp ưu tiên theo ma trận mức độ nghiêm trọng x khả năng xảy ra. Lỗ hổng bảo mật cho phép sửa giá đơn hàng (nghiêm trọng cao, dễ khai thác) phải được ưu tiên tuyệt đối trước một hallucination về comment không khớp code (nghiêm trọng thấp).
Fix từng vấn đề với test bảo vệ đi kèm, không fix "chay". Mọi fix quan trọng nên có một test case chứng minh vấn đề đã tồn tại trước khi fix (test đỏ) và được giải quyết sau khi fix (test xanh).
Viết tài liệu remediation summary rõ ràng — không chỉ để báo cáo, mà để bất kỳ ai kế thừa module này sau bạn hiểu được lịch sử: vấn đề gì đã tồn tại, mức độ nghiêm trọng, đã fix gì, và những gì còn tồn đọng cần theo dõi tiếp.
Phân loại rõ "đã fix" vs "đã biết nhưng chưa fix" (known issues). Không phải mọi vấn đề audit phát hiện đều cần fix ngay — nhưng mọi vấn đề đều cần được ghi nhận minh bạch, không được để "biến mất" khỏi tầm nhìn của team.
Đề xuất cải thiện quy trình để tránh lặp lại, ví dụ: "Module tương lai nên yêu cầu spec rõ ràng trước khi dùng AI generate", hoặc "Cần checklist bảo mật bắt buộc trước khi merge PR liên quan tới thanh toán".
Mẹo: Trình bày remediation summary theo cấu trúc "Đã fix / Còn tồn đọng / Đề xuất cải thiện quy trình" — cấu trúc ba phần này giúp người đọc (kể cả không kỹ thuật) nắm được bức tranh đầy đủ trong vài phút.
Thực Hành: Audit Walkthrough Đầy Đủ
Bước 1: Generate codebase mục tiêu
Dùng prompt sau để tạo ra module cần audit (cố tình đủ phức tạp để chứa các lớp vấn đề đã bàn ở trên):
Viết một module Node.js/Express xử lý đơn hàng thương mại điện tử gồm:
- POST /orders: tạo đơn hàng từ danh sách sản phẩm (id, số lượng), áp dụng coupon nếu có,
tính phí vận chuyển (miễn phí nếu đơn > 500,000đ, phụ phí 20,000đ cho khu vực hải đảo),
trừ tồn kho tương ứng.
- POST /orders/:id/apply-coupon: áp dụng coupon cho đơn hàng đã tồn tại.
- Giá sản phẩm lấy từ bảng products trong database.
- Dùng bất kỳ ORM/database nào bạn thấy phù hợp.
Viết kèm test cơ bản.
Không sửa gì thêm — để nguyên trạng như một "bàn giao" thực tế.
Bước 2: Chạy spec-vs-reality check
Viết ra spec ngầm định bạn suy ra được (5-10 gạch đầu dòng) trước khi đọc kỹ code, sau đó đối chiếu với những gì code thực sự làm. Ghi lại mọi lệch pha vào bảng đối chiếu.
Bước 3: Chạy hallucination scan
Build project. Verify từng package trong dependency list trên registry thật. Grep verify mọi field database được dùng trong query có khớp với schema/model thật không.
Bước 4: Chạy authorization check
Đây là bước trọng tâm bảo mật: kiểm tra endpoint POST /orders/:id/apply-coupon — có verify user gọi endpoint này có sở hữu đơn hàng :id đó không, hay bất kỳ user đăng nhập nào cũng có thể áp coupon cho đơn hàng của người khác? Đây là lỗi Broken Access Control cực kỳ phổ biến trong code AI-generated.
Bước 5: Chạy security checklist
Đi qua toàn bộ checklist OWASP ở Giai đoạn 4. Đặc biệt kiểm tra: giá sản phẩm dùng để tính tổng đơn hàng có được lấy từ database (server tính) hay có bất kỳ chỗ nào tin vào giá trị client gửi lên không.
Bước 6: Viết test còn thiếu quan trọng nhất
Dựa trên khoảng trống phát hiện ở Giai đoạn 5, viết ít nhất 3 test case quan trọng nhất còn thiếu — ưu tiên test cho lỗ hổng authorization và test cho boundary case tính phí vận chuyển (đơn hàng đúng ngưỡng 500,000đ, kết hợp hải đảo).
Bước 7: Fix ba vấn đề nghiêm trọng nhất
Dựa trên ma trận ưu tiên đã học, chọn và fix 3 vấn đề nghiêm trọng nhất phát hiện được xuyên suốt audit (thường sẽ bao gồm: lỗ hổng authorization, một lỗi logic tính phí vận chuyển, và ít nhất một hallucination hoặc lỗ hổng liên quan tới tin dữ liệu client). Mỗi fix đi kèm test chứng minh trước/sau.
Bước 8: Viết remediation summary
Tổng hợp toàn bộ quá trình theo cấu trúc ba phần (Đã fix / Còn tồn đọng / Đề xuất cải thiện quy trình), sẵn sàng để chia sẻ với team hoặc dùng làm tài liệu bàn giao.
Bài thực hành này mô phỏng chính xác một buổi audit thực tế mà bạn nhiều khả năng sẽ phải làm trong sự nghiệp agentic engineering — và bộ khung 6 giai đoạn này là công cụ bạn có thể mang theo, áp dụng lại cho bất kỳ codebase AI-generated nào cần được "thừa kế" một cách có trách nhiệm.
Mẹo: Lưu lại toàn bộ quy trình 8 bước này thành một checklist template cá nhân (hoặc chia sẻ cho team) — đây là tài sản có thể tái sử dụng cho mọi lần "thừa kế" một AI-generated codebase trong tương lai, không chỉ riêng bài thực hành này.
Những điểm chính
- Audit một codebase AI-generated cần bắt đầu từ việc xác định spec thực sự là gì, trước khi đánh giá code đúng hay sai so với spec đó.
- Hallucination scan là bước bắt buộc: verify mọi package trên registry thật, grep xác nhận utility nội bộ tồn tại, đối chiếu comment với logic thực tế.
- Trace tay các luồng nghiệp vụ rủi ro cao nhất (đặc biệt luồng liên quan tới tiền và tồn kho), chú ý thứ tự áp dụng các rule tương tác và tính nhất quán dữ liệu qua nhiều bước.
- Lỗ hổng bảo mật phổ biến nhất trong AI-generated code thương mại điện tử: Broken Access Control (thiếu authorization check theo user sở hữu resource) và tin dữ liệu giá/tiền từ client thay vì server tự tính toán.
- Test tồn tại không đồng nghĩa có giá trị — dùng mutation thủ công để kiểm tra test có thực sự "chết" khi logic sai không.
- Remediation cần được ưu tiên theo mức độ nghiêm trọng x khả năng khai thác, đi kèm test bảo vệ, và tài liệu bàn giao rõ ràng theo cấu trúc Đã fix / Còn tồn đọng / Đề xuất cải thiện quy trình.
- Bộ khung 6 giai đoạn (Spec vs Reality, Hallucination Scan, Logic Correctness, Security Audit, Test Quality, Remediation) là công cụ tái sử dụng được cho mọi tình huống thừa kế AI-generated codebase trong thực tế nghề nghiệp.