Cách lập trình bằng AI: quy trình 5 bước cho đội nhỏ

Cách lập trình bằng AI hiệu quả là biến nó thành một bước trong quy trình có kiểm chứng, không phải một công cụ dùng tuỳ hứng. Năm bước dưới đây — cắt lát, đóng gói ngữ cảnh, sinh thay đổi, chạy cổng kiểm thử, review — giữ cho tốc độ tăng mà không đánh đổi chất lượng.

Tóm tắt nhanh

• AI là người gõ, không phải người quyết. Mọi quyết định về yêu cầu, dữ liệu và đánh đổi vẫn thuộc về đội.
• Việc quan trọng nhất trước khi hỏi AI là cắt việc thành một lát có thể kiểm chứng được. Lát càng rõ, đầu ra càng đúng.
• Ngữ cảnh quyết định chất lượng: tệp mẫu, quy ước, lược đồ dữ liệu, kiểm thử hiện có, lỗi đã biết và định nghĩa hoàn thành.
• Cổng kiểm thử phải tồn tại trước khi dùng AI ở quy mô lớn, không phải sau.

Nguyên tắc: AI là người gõ, không phải người quyết

Mô hình ngôn ngữ tạo ra đoạn mã hợp lý theo ngữ cảnh. Nó không biết khách hàng của bạn là ai, quy tắc kinh doanh nào là bắt buộc, và dữ liệu nào không được phép lộ. Ba loại hiểu biết đó nằm ở người, và phải được đưa vào quy trình dưới dạng đặc tả và kiểm thử.

Hệ quả thực hành: đừng bắt đầu bằng câu hỏi "AI làm được việc này không". Bắt đầu bằng câu hỏi "tôi có mô tả được việc này đủ rõ để kiểm tra kết quả không". Nếu không mô tả được, AI sẽ tạo ra một phiên bản hợp lý của yêu cầu, và bạn sẽ mất nhiều thời gian sửa hơn là tự viết.

Nguyên tắc thứ hai: mọi thay đổi đều có người chịu trách nhiệm. Không phải "đội", mà một người cụ thể ký merge. Người đó chịu trách nhiệm về đoạn mã dù không tự gõ dòng nào. Đây là điều kiện để AI coding không trở thành vùng không ai kiểm soát.

Quy trình năm bước

Bước 1 — Cắt việc thành một lát kiểm chứng được

Một lát tốt có ba đặc điểm: mô tả được bằng một câu, có đầu vào và đầu ra rõ, và kiểm tra được bằng một bài kiểm thử. "Làm trang quản lý đơn hàng" không phải một lát. "Thêm bộ lọc theo trạng thái vào danh sách đơn hàng, trả về đúng tập kết quả" là một lát.

Lát càng nhỏ, ba lợi ích xuất hiện. Thứ nhất, bạn thấy ngay khi AI hiểu sai, thay vì phát hiện sau hai trăm dòng. Thứ hai, diff nhỏ nên review thật được. Thứ ba, khi phải làm lại, bạn chỉ mất một lát chứ không mất cả ngày.

Một cách kiểm tra lát cắt: nếu bạn không viết được tiêu chí nghiệm thu cho lát đó trong ba dòng, lát đó còn quá lớn.

Bước 2 — Đóng gói ngữ cảnh

Đây là bước quyết định chất lượng và cũng là bước hay bị bỏ nhất. Mô hình chỉ biết những gì được đưa vào. Sáu thứ nên đưa vào mỗi lần:

1. Tệp mẫu đúng quy ước. Một tệp tương tự đã có trong dự án, để mô hình bắt chước cấu trúc và cách đặt tên.
2. Quy ước dự án. Cách xử lý lỗi, cách trả kết quả, cách đặt tên, cách viết kiểm thử. Nên có một tệp hướng dẫn trong kho mã để mọi công cụ đọc cùng một nguồn.
3. Lược đồ dữ liệu. Tên bảng, tên cột, kiểu dữ liệu, quan hệ. Thiếu phần này, mô hình sẽ đoán tên trường và đoán sai.
4. Kiểm thử hiện có. Để mô hình biết hành vi nào đang được bảo vệ và không được làm hỏng.
5. Lỗi đã biết. Những chỗ dễ sai trong dự án, ví dụ múi giờ, đơn vị tiền tệ, phân quyền theo tổ chức.
6. Định nghĩa hoàn thành. Cụ thể: kiểm thử nào phải xanh, tệp nào được sửa, tệp nào không được chạm.

Sáu thứ này không cần viết lại mỗi lần. Chúng nên nằm trong kho mã và được cập nhật khi dự án thay đổi. Chi phí một lần, lợi ích mọi lần.

Bước 3 — Để AI sinh thay đổi

Ở bước này, yêu cầu cần ba phần: lát cắt cần làm, ngữ cảnh liên quan, và điều kiện dừng. Điều kiện dừng quan trọng: nói rõ khi nào thì dừng và báo lại thay vì tự mở rộng phạm vi.

Một yêu cầu tốt có dạng: "Thêm bộ lọc trạng thái vào hàm danh sách đơn hàng trong tệp X, theo mẫu của hàm danh sách sản phẩm trong tệp Y. Chỉ sửa tệp X và tệp kiểm thử của nó. Nếu cần sửa tệp khác, dừng lại và báo."

Yêu cầu xấu có dạng: "Cải thiện trang đơn hàng". Không có phạm vi, không có mẫu, không có điều kiện dừng. Kết quả sẽ là một thay đổi lớn, khó review, và thường sai hướng.

Bước 4 — Chạy cổng kiểm thử

Cổng kiểm thử là thứ biến AI coding từ đánh bạc thành kỹ thuật. Bốn mức, áp dụng tuỳ mức rủi ro:

Điều quan trọng hơn số lượng kiểm thử là kiểm thử có thật sự bắt được lỗi. Cách kiểm tra: cố tình làm sai hành vi và xem kiểm thử có đỏ không. Một bài kiểm thử luôn xanh không bảo vệ được gì, và tệ hơn, nó tạo cảm giác an toàn giả.

Một quy tắc nhỏ có tác dụng lớn: khi AI viết kiểm thử, yêu cầu nó viết kiểm thử thất bại trước. Nếu kiểm thử không thất bại trên mã chưa sửa, nó không kiểm tra đúng thứ cần kiểm tra.

Bước 5 — Review và merge

Review là bước duy nhất xác nhận thay đổi đúng việc cần làm, không chỉ đúng như đã định. Ba việc phải làm:

1. Đọc toàn bộ diff. Không đọc mô tả. Mô tả có thể đúng ý nhưng diff làm việc khác.
2. Kiểm tra điểm nhạy cảm. Truy vấn dữ liệu, phân quyền, xử lý tệp, gọi dịch vụ ngoài, xử lý tiền và thời gian.
3. Xác nhận phạm vi. Không có tệp nào bị sửa ngoài dự kiến. Nếu có, hỏi vì sao trước khi merge.

Sau khi merge, ghi lại một dòng về thay đổi: làm gì, vì sao, và điều gì cần kiểm tra nếu có sự cố. Dòng này rẻ và giúp người sau hiểu bối cảnh.

Ví dụ xuyên suốt: thêm chức năng xuất báo cáo

Để thấy năm bước vận hành cùng nhau, xét một việc thật: thêm chức năng xuất báo cáo đơn hàng theo tháng.

Bước 1 — Cắt lát. Lát đầu tiên không phải "làm chức năng xuất báo cáo". Lát đầu tiên là: "trả về tổng số đơn và tổng doanh thu theo tháng cho một tổ chức, dạng JSON". Chưa có giao diện, chưa có tệp Excel. Lý do: phần tính toán là phần dễ sai nhất và cũng dễ kiểm thử nhất.

Bước 2 — Đóng gói ngữ cảnh. Đưa vào: lược đồ bảng đơn hàng, hàm truy vấn tương tự đã có, quy ước về múi giờ, quy ước về đơn vị tiền tệ, và kiểm thử hiện có của hàm tương tự.

Bước 3 — Sinh thay đổi. Yêu cầu rõ phạm vi: chỉ sửa tệp dịch vụ báo cáo và tệp kiểm thử của nó. Điều kiện dừng: nếu cần thêm cột vào bảng, dừng và báo, vì thay đổi lược đồ cần người quyết.

Bước 4 — Chạy cổng kiểm thử. Kiểm thử đơn vị cho phép tính theo tháng, bao gồm tháng không có đơn, đơn bị huỷ, và đơn có nhiều dòng. Kiểm thử tích hợp cho truy vấn thật trên dữ liệu mẫu.

Bước 5 — Review. Đọc diff, kiểm tra điều kiện lọc theo tổ chức, kiểm tra cách xử lý múi giờ, và xác nhận không có tệp ngoài phạm vi bị sửa.

Lát thứ hai mới là giao diện, lát thứ ba là xuất tệp. Mỗi lát qua đủ năm bước. Cách này có vẻ chậm hơn "yêu cầu AI làm cả chức năng", nhưng tổng thời gian thường ngắn hơn vì ít phải làm lại.

Bảng: năm bước, đầu vào và điều kiện qua bước

Bảng này dùng được như danh sách kiểm tra hằng ngày. Nếu một bước bị bỏ, bước sau sẽ phải làm bù, và thường làm bù bằng thời gian của người review.

Ai làm gì trong một đội nhỏ

Quy trình năm bước chỉ chạy được khi ba vai trò được giao rõ. Trong đội nhỏ, một người có thể giữ hai vai, nhưng không nên giữ cả ba cho cùng một thay đổi.

Với đội hai người, cách chia thực dụng là đổi vai theo thay đổi: người A đặt yêu cầu và review, người B thực hiện; thay đổi sau đổi lại. Việc đổi vai quan trọng hơn số người, vì nó tạo ra một người thứ hai thật sự đọc mã.

Với đội một người, cần một cơ chế thay thế: viết tiêu chí nghiệm thu trước, chạy kiểm thử, và đọc diff trong một lượt riêng sau khi đã làm việc khác. Khoảng nghỉ giữa lúc viết và lúc review là thứ thay thế rẻ nhất cho người review thứ hai.

Năm lỗi thường gặp của đội mới dùng AI

Hỏi quá rộng. "Viết cho tôi module quản lý kho" tạo ra một khối mã không ai review được. Nên cắt nhỏ đến mức mỗi lần là một hàm hoặc một luồng.

Không đưa tệp mẫu. Mô hình sẽ tự chọn cấu trúc, và cấu trúc đó sẽ khác phần còn lại của dự án. Mỗi lần như vậy là một lần nợ kỹ thuật.

Chấp nhận kiểm thử luôn xanh. Đây là lỗi nguy hiểm nhất vì nó tạo cảm giác an toàn. Luôn kiểm tra bằng cách làm sai hành vi.

Không giới hạn phạm vi. Thay đổi lan sang tệp cấu hình, tệp triển khai hoặc tệp dùng chung. Nên nói rõ tệp nào được sửa và dừng lại khi cần mở rộng.

Bỏ qua review vì "kiểm thử đã xanh". Kiểm thử xác nhận hành vi đã định, không xác nhận hành vi đúng. Một thay đổi có thể qua kiểm thử nhưng làm sai yêu cầu.

Đo lường sau một tháng

Ba chỉ số đủ để biết quy trình có hiệu quả:

• Số lần phải làm lại mỗi lát. Nếu cao, vấn đề nằm ở bước 1 hoặc bước 2, không nằm ở mô hình.
• Thời gian review mỗi thay đổi. Nếu tăng liên tục, diff đang quá lớn hoặc ngữ cảnh đang thiếu.
• Số lỗi phát hiện sau phát hành. Đây là chỉ số cuối cùng, và là chỉ số quyết định có nên tiếp tục mở rộng.

Đừng đo bằng số dòng mã. Số dòng nhiều không phải thành tích; trong nhiều trường hợp nó là dấu hiệu của mã trùng lặp.

Câu hỏi thường gặp

Đội nhỏ nên bắt đầu từ việc gì khi lập trình bằng AI?

Nên bắt đầu từ viết kiểm thử cho mã đã có. Đây là việc có tiêu chí đúng sai rõ, kết quả kiểm tra được ngay, và tạo ra lưới an toàn cho mọi việc sau. Sau khi có kiểm thử, mới chuyển sang dùng AI để sửa mã, vì lúc đó bạn có cách phát hiện hồi quy.

Có cần viết đặc tả trước khi hỏi AI không?

Cần, nhưng không cần đặc tả dài. Một câu mô tả lát cắt cộng với tiêu chí nghiệm thu là đủ cho một lần. Điều không nên bỏ là tiêu chí nghiệm thu, vì đó là thứ duy nhất cho phép bạn biết kết quả đúng hay sai mà không phải đọc từng dòng.

Nên dùng một công cụ hay nhiều công cụ?

Nên bắt đầu với một công cụ và một phạm vi hẹp, đo kết quả, rồi mở rộng. Dùng nhiều công cụ cùng lúc làm khó so sánh và khó thống nhất quy ước. Khi đã có dữ liệu, việc chọn thêm công cụ cho từng loại việc sẽ có căn cứ hơn.

Làm sao giữ cho AI không sửa ngoài phạm vi?

Bằng cấu hình và bằng yêu cầu có điều kiện dừng. Nói rõ tệp nào được sửa, và yêu cầu dừng lại báo cáo nếu cần mở rộng. Sau đó kiểm tra danh sách tệp thay đổi trước khi review. Nếu chỉ dặn bằng lời mà không kiểm tra, thay đổi ngoài phạm vi sẽ lọt qua.

Cập nhật và kiểm chứng

Cập nhật tháng 10/2026. Nội dung được rà soát theo quy trình bốn chặng Khám phá, Đặc tả, Xây dựng, Bàn giao và đo lường mà WinSell áp dụng, và theo thông lệ kỹ thuật phần mềm đang áp dụng. Bài viết không mô tả hạ tầng nội bộ, không nêu giá dịch vụ và không sử dụng số liệu khách hàng của bất kỳ bên nào.

Ba mức can thiệp của AI được phân tích trong AI coding là gì, và mức tự chủ cao nhất trong AI coding agent là gì. Vì quy trình này chỉ hiệu quả khi cấu trúc mã đủ rõ để làm mẫu, nên đọc thêm kiến trúc phần mềm là gì. Nếu bạn cần một đội dựng quy ước, kiểm thử và cổng review trước khi mở rộng dùng AI, xem dịch vụ xây dựng phần mềm theo yêu cầu của WinSell. Báo giá sau khi chốt phạm vi.