Cách dùng AI để lập trình: quy trình làm việc giảm rủi ro

Nguyên tắc để AI hỗ trợ lập trình an toàn

Cách tốt nhất để dùng AI cho lập trình là bắt nó chậm lại đúng vào những lúc mà đoán mò là nguy hiểm. AI có thể giải thích đoạn code lạ, biến thông báo lỗi thành các giả thuyết, phác thảo test, rà soát diff và gợi ý tái cấu trúc. Nó cũng có thể bịa ra API, bỏ sót các phụ thuộc ngầm, bám quá sát đoạn code bạn dán vào, hoặc tạo ra một bản vá trông sạch sẽ nhưng lại đổi mất hành vi mà bạn muốn giữ nguyên.

Hãy áp dụng nguyên tắc này: AI được đề xuất, còn kho code của bạn mới là bên quyết định. Nguồn sự thật là chính codebase, ca tái hiện lỗi, bộ test, log lúc chạy, yêu cầu sản phẩm và sự rà soát của con người. Một bạn lập trình cặp AI tốt phải giúp bạn suy luận từ những thứ đó chứ không thay thế chúng.

Nguyên tắc	Vì sao quan trọng	Hãy yêu cầu mô hình
Tái hiện lỗi trước	Tránh những bản vá ngẫu hứng	"Nhắc lại hành vi lỗi và bằng chứng trước khi đề xuất code."
Giữ phạm vi nhỏ	Giảm rủi ro hồi quy	"Đề xuất thay đổi nhỏ nhất mà vẫn an toàn và liệt kê các tệp bị chạm tới."
Giữ nguyên hành vi	Bảo vệ người dùng và các cam kết	"Nêu tên những bất biến mà thay đổi này không được phá vỡ."
Bắt buộc có test	Làm cho câu trả lời kiểm chứng được	"Viết test hỏng trước khi sửa và đạt sau khi sửa."
Rà soát trước khi merge	Bắt được những sai lầm đầy tự tin	"Rà soát diff này về tính đúng đắn, bảo mật và các trường hợp biên bị bỏ sót."

Điều này đúng với mọi mô hình. OpenAI, Anthropic và các nhà cung cấp khác đều công bố tài liệu mô tả các năng lực, kích thước ngữ cảnh và cách dùng công cụ khác nhau. Những năng lực đó hữu ích, nhưng chúng không thay thế được một quy trình có kỷ luật. Với công việc kỹ thuật, hãy đánh giá mô hình theo đúng tiêu chuẩn bạn dùng cho một đồng nghiệp: nó có hỏi thêm phần bối cảnh còn thiếu, có làm giảm sự mơ hồ, có tôn trọng ràng buộc, và có để lại dấu vết cho bạn kiểm chứng hay không?

Quy trình gỡ lỗi

Một quy trình gỡ lỗi bằng AI đáng tin cậy có năm chặng: tái hiện, khoanh vùng, đặt giả thuyết, vá và xác minh. Đừng mở đầu bằng "sửa cái này giúp tôi". Hãy mở đầu bằng bằng chứng. Đưa cho mô hình câu lệnh gây lỗi, thông báo lỗi nguyên văn, hành vi mong đợi, hành vi quan sát được, đoạn code liên quan, chi tiết môi trường, và mọi thay đổi gần đây có thể là nguyên nhân.

Chặng 1: ghi lại ca tái hiện. Với code phía backend, hãy đưa vào request, response, mã trạng thái, log và bài test đang hỏng. Với code phía frontend, hãy đưa vào đường dẫn trang, thao tác người dùng, lỗi trên console trình duyệt, phản hồi mạng, trạng thái component và mô tả ảnh chụp màn hình nếu cần. Với lỗi build, hãy đưa vào câu lệnh, trình quản lý gói, phiên bản Node và toàn bộ thông báo lỗi quanh chỗ hỏng đầu tiên.

Chặng 2: hỏi giả thuyết trước khi hỏi code. Một mô hình cẩn thận sẽ xếp hạng các nguyên nhân có khả năng và nêu bằng chứng cho từng cái. Nếu nó không phân biệt nổi giữa các nguyên nhân, hãy hỏi bước chẩn đoán nhỏ nhất. Bước đó có thể là một dòng log, một bài test hẹp, một lần kiểm tra kiểu dữ liệu, hoặc đọc thêm một tệp nữa.

Chặng 3: yêu cầu bản vá nhỏ nhất. Hãy dặn mô hình đừng đổi tên biến, đừng viết lại code xung quanh, đừng thêm phụ thuộc mới và đừng đổi hành vi công khai trừ khi nó giải thích được vì sao. Hãy yêu cầu nó trả về nguyên nhân gốc, phác thảo bản vá, các tệp bị chạm tới, test và rủi ro.

Chặng 4: chạy test tại máy. Kết quả của AI không phải là bước xác minh. Bước xác minh là câu lệnh hoặc luồng thao tác chứng minh được hành vi. Nếu chưa có test tự động nào, hãy nhờ mô hình tạo một bài test hồi quy trước, rồi mới hiện thực bản sửa.

Prompt gỡ lỗi:

Hãy đóng vai một người bạn gỡ lỗi cẩn thận. Chưa viết code vội. Trước hết hãy nhắc lại ca tái hiện, hành vi mong đợi, hành vi quan sát được và ba nguyên nhân gốc khả dĩ nhất. Xếp hạng từng nguyên nhân theo bằng chứng. Sau đó gợi ý bước chẩn đoán nhỏ nhất. Lỗi: [mô tả]. Câu lệnh hoặc thao tác người dùng: [dán vào]. Lỗi/log: [dán vào]. Code liên quan: [dán vào]. Ràng buộc: [công nghệ, tệp không được đụng, hành vi phải giữ nguyên].

Prompt sửa lỗi:

Dựa trên nguyên nhân gốc đã xác nhận, hãy đề xuất bản sửa nhỏ nhất mà vẫn an toàn. Trả về: nguyên nhân gốc, tệp/hàm cần đổi, phác thảo bản vá, test hỏng trước và đạt sau, các trường hợp biên, và rủi ro khi quay lui. Đừng tái cấu trúc code không liên quan. Bối cảnh: [dán vào].

Quy trình rà soát code

AI thường làm người rà soát tốt hơn làm người viết đầu tiên. Khi bạn nhờ nó rà một diff, nó có thể tìm ra các trường hợp biên bị bỏ sót, vấn đề bảo mật, giả định đã lỗi thời, chỗ thiếu test và những thay đổi hành vi. Điều then chốt là làm cho phần rà soát thật cụ thể. Nếu bạn hỏi "cái này ổn chứ?" bạn sẽ nhận được lời tán thành lịch sự. Nếu bạn hỏi về rủi ro sai đúng, khả năng cao bạn sẽ nhận được những phản biện hữu ích.

Hãy đưa cho mô hình phần diff, hành vi mong muốn, các test liên quan và mọi ràng buộc. Dặn nó bỏ qua các lỗi phong cách vặt vãnh trừ khi chúng ảnh hưởng tới khả năng bảo trì. Bạn muốn phần rà soát ưu tiên lỗi thật, không phải những lời bắt bẻ cho có.

Hạng mục rà soát	Câu hỏi AI phải trả lời
Tính đúng đắn	Diff này có thực sự đáp ứng yêu cầu không?
Rủi ro hồi quy	Hành vi sẵn có nào có thể vô tình bị đổi?
Bảo mật	Đầu vào, xác thực, khóa bí mật, quyền hạn hay nguy cơ injection đã được xử lý chưa?
Xử lý lỗi	Chuyện gì xảy ra khi gặp giá trị rỗng, hết thời gian chờ, thử lại, phản hồi hỏng hay trạng thái dở dang?
Test	Những khẳng định hành vi nào chưa được bao phủ?
Khả năng bảo trì	Thay đổi này có theo đúng nếp của dự án và có dễ hiểu không?

Prompt rà soát code:

Hãy rà soát diff này như một người bảo trì khó tính nhưng thực tế. Tập trung vào tính đúng đắn, rủi ro hồi quy, bảo mật, trường hợp biên và test còn thiếu. Bỏ qua lỗi phong cách vặt vãnh trừ khi chúng tạo ra rủi ro bảo trì thật sự. Trả về một bảng gồm vấn đề, mức ưu tiên, bằng chứng lấy từ diff, cách sửa đề xuất và test cần có. Hành vi mong muốn: [dán vào]. Diff: [dán vào]. Test hiện có: [dán vào].

Với các thay đổi rủi ro cao, hãy dùng quy trình so sánh bản vá giữa nhiều mô hình trong Whizi. Chạy cùng một prompt rà soát qua hai hoặc ba mô hình. Nếu một mô hình tìm ra một vấn đề khả dĩ, đừng chấp nhận ngay; hãy kiểm tra xem vấn đề đó có thật trong codebase hay không. Mục tiêu không phải là gom thêm nhiều ý kiến. Mục tiêu là mở rộng bề mặt rà soát trước khi bạn merge.

Quy trình tái cấu trúc kèm test

Tái cấu trúc cùng AI là việc rủi ro, vì nhiều lần tái cấu trúc được đánh giá bằng những gì không thay đổi. Mô hình có thể làm code trông đẹp hơn trong khi lặng lẽ đổi hành vi, cách xử lý lỗi, thời điểm chạy hoặc các cam kết công khai. Một quy trình tái cấu trúc an toàn hơn bắt đầu bằng việc xác định các bất biến trước khi động vào phần hiện thực.

Bước 1: mô tả mục tiêu tái cấu trúc. Ví dụ: giảm trùng lặp, tách một component quá lớn, tách riêng lớp truy cập dữ liệu, đơn giản hóa các nhánh rẽ, chuyển đổi một lớp bọc API, hoặc làm code dễ test hơn. Sau đó nêu rõ những gì phải giữ nguyên: chữ ký hàm công khai, hành vi của các route, tên sự kiện, cấu trúc phản hồi, dữ liệu phân tích, phân quyền, hành vi trợ năng và kỳ vọng về hiệu năng.

Bước 2: yêu cầu một kế hoạch theo từng chặng. Một kế hoạch tái cấu trúc do AI đưa ra phải quay lui được. Mỗi chặng chỉ nên chạm vào một vùng nhỏ, có test kèm theo, và tạo ra một trạng thái trung gian vẫn chạy được. Hãy tránh viết lại toàn bộ trong một lần trừ khi đoạn code rất nhỏ và đã được test kỹ.

Bước 3: viết test mô tả hành vi hiện tại. Trước khi đổi code, hãy nhờ AI xác định hành vi hiện tại và phác thảo các test chốt lại những trường hợp quan trọng. Những test này đặc biệt hữu ích với code cũ mà ý đồ ban đầu không còn rõ. Chúng nên bao gồm đầu vào bình thường, đầu vào ở biên, các nhánh lỗi, và một ca hồi quy gắn với chính lý do bạn tái cấu trúc.

Bước 4: làm từng chặng một. Sau mỗi chặng, hãy chạy test và xin một lượt rà soát tập trung. Nếu mô hình đề xuất một tầng trừu tượng rộng, hãy bắt nó chứng minh rằng tầng đó thật sự loại bỏ được trùng lặp hoặc rủi ro. Nếu không, cứ giữ code buồn tẻ và cục bộ.

Prompt lập kế hoạch tái cấu trúc:

Hãy lập một kế hoạch tái cấu trúc theo từng chặng. Mục tiêu: [mục tiêu]. Code hiện tại: [dán vào]. Ràng buộc: giữ nguyên hành vi công khai, hạn chế xáo trộn, theo đúng nếp sẵn có, tránh thêm phụ thuộc mới, mỗi chặng đều test được. Trả về: các bất biến, sơ đồ phụ thuộc, các chặng, tệp bị chạm tới, test cho từng chặng, rủi ro khi quay lui, và danh sách kiểm tra khi rà soát.

Prompt viết unit test:

Hãy viết test trước khi đổi phần hiện thực. Dùng đúng lối viết test hiện có ở đây: [dán vào]. Hành vi phải giữ nguyên: [dán vào]. Code cần test: [dán vào]. Trả về tên test, phần chuẩn bị, đầu vào, kết quả mong đợi, và vì sao mỗi test lại quan trọng. Bao gồm luồng thuận lợi, trường hợp biên, trường hợp lỗi và ca hồi quy.

Các mẫu prompt

Prompt lập trình tốt không dài vì nó màu mè. Nó dài vừa đủ để xóa hết mơ hồ. Mô hình cần vai trò, nhiệm vụ, bối cảnh, ràng buộc, định dạng đầu ra và tiêu chí xác minh. Hãy lưu lại những prompt hiệu quả để AI trở thành một quy trình kỹ thuật lặp lại được thay vì một cuộc chat dùng một lần.

Prompt giải thích code:

Hãy giải thích đoạn code này cho một lập trình viên vừa gia nhập dự án. Nêu mục đích, đầu vào, đầu ra, luồng dữ liệu, phụ thuộc, các cách nó có thể hỏng, và những test giúp tăng độ tin cậy. Tách riêng phần sự thật nhìn thấy được trong code với phần giả định. Code: [dán vào].

Prompt lập trình an toàn:

Hãy rà soát đoạn code này về rủi ro bảo mật. Tập trung vào xác thực, phân quyền, injection, khóa bí mật, kiểm tra dữ liệu đầu vào, chuyển hướng không an toàn, xử lý tệp, rủi ro từ thư viện phụ thuộc và lộ lọt dữ liệu nhạy cảm. Chỉ trả về những vấn đề có bằng chứng, kèm mức ảnh hưởng, cách sửa đề xuất, và test hoặc bước kiểm tra thủ công. Code/diff: [dán vào].

Prompt so sánh bản vá giữa các mô hình:

Tôi đang so sánh các mô hình AI cho một nhiệm vụ lập trình. Chỉ dùng bối cảnh được cung cấp. Trả về nguyên nhân gốc, bản sửa nhỏ nhất mà an toàn, test, rủi ro, giả định và câu hỏi. Chấm mức độ tự tin từ 1 đến 5 và liệt kê bằng chứng nào sẽ làm bạn đổi câu trả lời. Nhiệm vụ: [dán vào]. Bối cảnh: [dán vào].

Danh sách kiểm tra trước khi bạn chấp nhận code do AI sinh ra:

• Mô hình đã nhắc lại đúng nhiệm vụ.
• Bản vá nhỏ hơn vấn đề, chứ không lớn hơn.
• Hành vi công khai và các cam kết đã được nêu tên.
• Test bám sát trực tiếp vào lỗi hoặc mục tiêu tái cấu trúc.
• Các trường hợp biên và nhánh lỗi đã được liệt kê.
• Các đầu vào nhạy cảm về bảo mật đã được rà soát.
• Diff theo đúng nếp sẵn có của dự án.
• Bạn đã chạy test, lint, build hoặc tái hiện thủ công tương ứng.
• Một con người đã rà soát bản diff cuối cùng.

Whizi hữu ích khi bạn muốn so sánh các bản vá mà không đổi đề bài. Hãy dán cùng một prompt gỡ lỗi hoặc rà soát vào nhiều mô hình, rồi chấm điểm kết quả theo bằng chứng, phạm vi, test và rủi ro. Hãy bắt đầu với các lựa chọn thay thế ChatGPT cho lập trình nếu bạn cần một hướng dẫn chọn mô hình, so sánh các gói tại bảng giá, hoặc tạo tài khoản để chạy quy trình này trên chính code của bạn.