Đừng cầu nguyện khi dùng Codex: Xây dựng quy trình tác nhân đáng tin cậy với 4 trụ cột Phạm vi – Bộ nhớ – Ủy quyền – Bằng chứng

Có một cái bẫy mà gần như ai sử dụng Codex để phát triển phần mềm cũng rất dễ mắc phải: mở một câu chuyện, viết một lời nhắc thật dài, yêu cầu AI xây dựng một tính năng rồi… hy vọng kết quả cuối cùng sẽ hoạt động đúng.

Khi mọi thứ thuận lợi, bạn có cảm giác Giác Giác Giác Giác Codex cực kỳ thông minh. Nhưng chỉ cần thay đổi một dự án khác, một tính năng khác hoặc một ngày khác, kết quả có thể hoàn toàn trái ngược: mã thiếu nhất quán, AI sửa lỗi tệp, bỏ qua quy tắc của dự án hoặc tạo ra những thay đổi mà bạn không biết phải kiểm tra từ đâu.

Vấn đề thường không xảy ra ở nơi làm việc của bạn là chưa đủ lời nhắc hoặc.

Vấn đề là bạn đang sử dụng AI Agent như một chatbot , trong khi cách hiệu quả hơn là vận hành nó giống như một thành viên trong đội ngũ kỹ thuật .

Trong bài viết này, chúng tôi sẽ xây dựng một quy trình làm việc thực tế với Codex thông qua một dự án mẫu có tên Release Board . Vì chỉ yêu cầu Codex “hãy xây dựng tính năng này”, chúng tôi sẽ thiết lập một hệ thống gồm 4 yếu tố quan trọng:

Phạm vi – Bộ nhớ – Ủy quyền – Bằng chứng.

Đây chính là 4 xi lanh trụ giúp các biến nhắc nhở có thể gặp rủi ro khi một Tác nhân AI có thể lặp lại, kiểm soát và mở rộng.

Vì sao chỉ nhắc nhở hay chưa đủ?

Khi làm việc với AI Agent, nhiều người thường tập trung gần như toàn bộ chú thích vào lời nhắc.

Họ liên tục thử:

“Hãy viết mã tốt hơn.”
“Hãy kiểm tra kỹ năng hơn.”
“Đừng sửa những tập tin không liên quan.”
“Hãy góp ý kiến ​​trúc hiện tại.”

Nhưng càng làm như vậy, càng nhanh càng dài và càng khó quản lý.

Quan trọng hơn, những thông tin đó thường chỉ tồn tại trong một phiên bản. Khi bắt đầu một phiên bản mới, bạn phải giải nén từ đầu.

Một hệ thống AI Agent tốt cần nhiều hơn một lời nhắc.

Nó cần biết:

• Nó được phép làm gì?
• Nó được phép làm ở đâu?
• Quy tắc nào phải luôn được đưa vào?
• Công việc nào nên giao tiếp cho đại lý khác?
• Làm thế nào để chứng minh rằng kết quả thực sự đúng?

Từ đó, chúng ta có 4 lớp kiểm soát:

Phạm vi (Phạm vi)

Xác định ranh giới giới hạn của đại lý.

Bộ nhớ

Lưu lại các quy tắc và thời hạn định nghĩa của dự án.

Ủy quyền (Delegation)

Cho phép Agent chia công việc nhỏ cho các Agent  phụ khi cần thiết.

Bằng chứng (Evidence)

Không tin rằng mã đó chỉ đúng vì AI nói nó đúng. Tất cả những thay đổi cần có bằng chứng chỉ đặc biệt, hãy kiểm tra, xây dựng và xem trước trường môi trường.

Đây là cách chuyển từ:

“Tôi đang nói chuyện với AI.”

thành:

“Tôi đang điều hành một nhà phát triển phần mềm có AI tham gia.”

1. Cột trụ đầu tiên: Phạm vi (Scope)

Trước khi Codex sửa đổi bất kỳ dòng mã hóa nào, điều đầu tiên cần xác định là ranh giới hoạt động của nó .

Hãy tưởng tượng bạn thuê một trình quản lý mới vào dự án.

Bạn sẽ không nói:

“Cứ làm đi, muốn truy cập thì truy cập.”

Bạn sẽ xác định rõ:

• Đây là dự án thư mục.
• Đây là những tập tin được phép chỉnh sửa.
• Đây là những tài nguyên được phép sử dụng.
• Đây là những hoạt động cần hỏi trước.
• Đây là những quyền mà họ không được tự ý sử dụng.

Với AI Agent cũng vậy.

Trong Release Board của dự án, chúng tôi có thể thiết lập cấu hình config.tomltrong thư mục .codexđể xác định phạm vi hoạt động của Codex.

Họ tiêu rất lớn:

Codex được phép hoạt động trong môi trường làm việc nhưng không được mặc định có toàn quyền đối với máy tính hoặc mạng Internet.

Điều đặc biệt quan trọng là AI Agent không chỉ đọc mã.

Nó có thể:

• Tạo tập tin.
• tập tin.
• tập tin.
• Chạy lệnh.
• Chạy thử nghiệm.
• Thực hiện các thao tác Git.
• Và trong một số cấu hình, có thể truy cập tài nguyên bên ngoài.

Nếu bạn trao quyền ngay từ đầu, bạn đang tăng đáng kể phạm vi rủi ro.

Trình duyệt phê duyệt trình duyệt ứng dụng

Codex có nhiều khả năng kiểm soát quyền thực thi, từ công việc luôn yêu cầu phê duyệt cho đến những cấu hình tự động hóa mạnh hơn.

Trong quy trình này, đơn vị lựa chọn phù hợp là Custom , bởi vì chúng tôi muốn kiểm soát chính xác những tác nhân có thể tự động thực hiện.

Ví dụ, môi trường làm việc có thể bị giới hạn theo hướng:

• Chỉ được phép ghi trong lúc làm việc.
• Không được phép truy cập mạng nếu chưa được cấp quyền.
• Thiết bị cần thiết để hoạt động.
• Những hành động nằm ngoài phạm vi phải yêu cầu người xác định.

Điểm quan trọng ở đây không phải là tìm kiếm cấu hình “quyền tối đa”.

"Cấp độ cho đại lý đúng quyền cần thiết để hoàn thành công việc, không cấp nhiều hơn."

Đó chính là nguyên tắc đặc quyền tối thiểu – đặc quyền tối thiểu .

2. Cột trụ thứ hai: Bộ nhớ (Memory)

Sau khi xác định đại lý được phép làm gì, câu hỏi tiếp theo là:

Đại lý phải biết những gì?

Đây là nơi có nhiều AI Agent bị lỗi sử dụng.

Mỗi lần bắt đầu cuộc trò chuyện, họ lại viết một lời nhắc:

“Đây là dự án của tôi, đây là cấu trúc thư mục, đây là kiến ​​trúc, đây là quy tắc code, đây là những điều không được làm…”

Sau đó lặp lại một vài ngày từ đầu.

Tốt hơn là những kiến ​​thức có tính ổn định trong bộ nhớ của dự án .

Trong quy trình này, chúng tôi sử dụng agents.md.

Agent.md không phải là một lời nhắc

Một tập tin agents.mdtốt không nên chứa hàng trăm dòng chỉ để kể đến AI mọi thứ về dự án.

Nó nên giống như một sổ tay hành động rút gọn .

Ví dụ: file có thể mô tả:

• Mục tiêu của dự án.
• Quan trọng thư mục cấu trúc.
• Các quy tắc ước mã.
• Cách chạy dự án.
• Cách chạy thử nghiệm.
• Những tập tin này không thể chỉnh sửa tiện ích.
• Bảo vệ nguyên tắc.
• Tiêu chuẩn hoàn thành một nhiệm vụ.
• Những tác vụ này phải được kiểm tra trước khi kết thúc.

Điểm quan trọng là quy tắc này mang tính dài hạn .

Thay vì mỗi lần viết:

“Xin lưu ý rằng dự án sử dụng X, không thể sửa Y, phải chạy Z…”

Bạn đưa những thông tin đó vào bộ nhớ của dự án.

Sau đó, mỗi nhiệm vụ mới chỉ cần tập trung vào phần công việc cụ thể.

Đặt cạnh

Một cách hiệu quả khác là Codex không yêu cầu viết mã tức thời.

Thay vào đó, hãy bắt đầu bằng Plan mode .

Ví dụ, thay vì:

“Hãy xây dựng tính năng lọc trên Release Board.”

Bạn có thể yêu cầu:

“Hãy phân tích yêu cầu, kiểm tra hiện tại cấu hình, xác định những tệp cần thay đổi và đề xuất kế hoạch phát triển báo cáo. Chưa chỉnh sửa mã.”

Điều này tạo ra một khoảng dừng rất quan trọng.

AI phải:

1. Hiểu yêu cầu.
2. Kho lưu trữ kiểm tra.
3. Xác định hiện tại kiến ​​trúc.
4. Search link các thành phần.
5. Xác định ro.
6. ra kế hoạch.

Người dùng có thể xem các kế hoạch trước khi thực hiện.

Sau khi thiết lập kế hoạch cụ thể, các quy tắc thuộc tính dài có thể được lọc vào agents.md.

Như vậy, bộ nhớ không còn là “Bộ nhớ AI” thứ hai.

Nó trở thành tài liệu vận hành có thể kiểm soát được bằng Git .

3. Cột trụ thứ ba: Ủy quyền (Delegation)

Khi dự án lớn hơn, một đại lý duy nhất không nhất thiết phải làm tất cả.

Đây là Phái đoàn khái niệm – Ủy quyền trở nên quan trọng.

Hãy hình dung một đội ngũ nhỏ:

• Agent chính đóng vai trò Tech Lead.
• Một nghiên cứu đặc biệt.
• Một nhân viên QA.
• Một bài đánh giá về đại lý.
• Một tác nhân thực hiện một mô-đun độc lập.

Agent chính không nhất thiết phải tự mình làm mọi công việc.

Nó có thể chia nhỏ công việc và giao tiếp cho các đại lý phụ.

Tuy nhiên, bài hát không có nghĩa là chạy càng nhiều càng tốt .

Bạn phải kiểm soát sự phụ thuộc giữa các công việc.

Mô hình 1: Git Worktree cho công việc độc lập

Một cách rất hữu ích là sử dụng Git Worktree để tạo môi trường làm việc riêng cho từng nhiệm vụ.

Ví dụ:

Agent A đang phát triển module điều khiển bảng.

Tác nhân B đang xây dựng một mô-đun khác.

If hai nhiệm vụ không sửa cùng một tập tin, chúng có thể được thực hiện độc lập.

Điều này giúp giảm nguy cơ:

• Agent này ghi đè các thay đổi của Kia Agent.
• Xung đột nhất.
• Một công việc vô tình của đại lý đang được thực hiện ở một nhánh khác.

Nhưng có một nguyên tắc cực kỳ quan trọng:

Chỉ chạy song khi công việc thực hiện độc lập.

Nếu hai nhân viên cùng chỉnh sửa một tập tin hoặc thay đổi một phần kiến ​​trúc, việc chạy bài hát có thể tạo ra mọi chất phức tạp hơn thay vì nhanh hơn.

AI Agent càng mạnh thì việc quản lý xung đột càng quan trọng.

Mô hình 2: QA Nhân viên phụ trách

Một cách sử dụng Delegation rất hiệu quả đã tạo ra một đại lý kiểm tra chất lượng chuyên nghiệp.

Sau khi đại lý hoàn thành mã chính xác, thay vì yêu cầu chính nó tự đánh giá:

“Hãy kiểm tra mã của bạn xem có lỗi nào không.”

Bạn có thể giao nhiệm vụ cho một đại lý phụ QA độc lập.

Nhiệm vụ có thể được xác định rõ ràng:

"Hãy kiểm tra toàn bộ các thay đổi trong hiện tại của nhánh. Không thể chỉnh sửa bất kỳ tệp nào. Chỉ phân tích và trả lời báo cáo về các vấn đề được tìm thấy."

Điều này tạo ra sự phân biệt giữa:

người thực hiện và người kiểm tra .

QA đại lý có thể kiểm tra:

• Lý luận.
• Trường hợp ngoại lệ.
• Hồi quy.
• Bài kiểm tra còn thiếu.
• Vi phạm quy tắc.
• Những thay đổi không liên quan.
• Các vấn đề về hiệu suất hoặc bảo mật.

Sau đó, nó không trả về báo cáo.

Ví dụ:

P1: Lỗi nghiêm trọng, cần xử lý ngay.

P2: Lỗi quan trọng, nên sửa trước khi phát hành.

P3: Vấn đề nhỏ hoặc cải thiện chất lượng.

Con người đã xem báo cáo trước đó.

Chỉ sau khi xác định vấn đề thực sự cần sửa, tác nhân chính mới được phép thực hiện những thay đổi cần thiết.

Đây là một điểm rất quan trọng:

Agent QA không nên kiểm tra tất cả các thông số vừa phải.

Nếu tự động sửa, bạn sẽ mất đi một lớp kiểm soát độc lập.

4. Cột trụ thứ tư: Bằng chứng (Evidence)

Đây có thể là phần quan trọng nhất trong toàn bộ quy trình.

Trí tuệ nhân tạo có thể:

“Tôi đã hoàn thành.”

Nhưng câu nói đó không được chứng minh.

Trí tuệ nhân tạo có thể:

“Tất cả các bài kiểm tra đều đạt.”

Nhưng bạn vẫn cần biết thử nghiệm nào đã chạy, chạy trong môi trường nào và thay đổi thực tế là gì.

Vì vậy, trước khi phát hiện, chúng ta cần một chuỗi bằng chứng.

Kiểm tra các sự kiện khác trước khi nhập kết quả

Đầu tiên là xem Git diff.

Diff giúp bạn trả lời những câu hỏi rất cơ bản:

• Những tập tin nào đã được thay đổi?
• Thay đổi bao nhiêu dòng?
• Có tập tin nào được sửa ngoài dự án không?
• Có đoạn mã nào bị xóa không?
• Có thay đổi cấu hình nào không?
• Agent có một lỗi sửa lỗi không có liên kết?

Đây là một trong những lớp kiểm soát đơn giản nhưng cực kỳ hiệu quả.

Một tính năng nhỏ mà công việc tạo ra các thay đổi nuôi dưỡng tập tin bất ngờ là dấu hiệu bạn cần dừng lại và kiểm tra.

Chạy thử nghiệm

Tiếp theo là bài kiểm tra.

Không chỉ hỏi AI:

“Bạn chưa có bài kiểm tra?”

Mà phải thực thi thử nghiệm này trong quy trình.

Có thể bao gồm:

• Kiểm thử đơn vị.
• Kiểm thử tích hợp.
• Kiểm thử toàn diện.
• Xơ vải.
• Kiểm tra kiểu dữ liệu.
• Xây dựng.

Mỗi loại thử nghiệm cung cấp một loại bằng chứng khác nhau.

Và nếu thử nghiệm thất bại thì đó không phải là lúc để AI “cố thuyết phục” cho rằng mọi thứ vẫn ổn.

Đó là tín hiệu cần quay lại và xử lý sự cố.

Xây dựng một lớp bằng chứng chỉ khác

Một đoạn mã có thể vượt qua nhiều thử nghiệm nhưng vẫn không thể xây dựng toàn bộ ứng dụng.

Vì vậy, build cần được xem như một bước độc lập.

Quy trình nên vòng đẹp:

Thay đổi → So sánh → Kiểm tra → Biên dịch → Xem trước → Đánh giá → Sản phẩm

Không phải:

Nhập lệnh → Viết mã → Triển khai.

Điểm khác biệt giữa hai quy trình này chính là sự khác biệt giữa mã hóa AI được hỗ trợ và hệ thống phát triển phần mềm có kiểm soát.

Xem trước khi sản xuất

Với Release Board, có thể thay đổi yêu cầu Pull để tạo môi trường Preview, tạo Vercel Preview.

Đây là một bước cực kỳ quan trọng.

Bởi vì có những lỗi mà test không thể phát hiện được.

Ví dụ:

• Giao diện bị phá vỡ.
• Độ sai vị trí trí.
• Văn bản bị.
• "Responsive" không đúng.
• Trình diễn vật liệu gần gũi.
• Đang tải trạng thái không hoạt động.
• Một thao tác của người dùng không giống như dự kiến.

Bạn có thể có một thử nghiệm tuyệt vời nhưng vẫn cần mở trình duyệt và sử dụng sản phẩm như một người dùng thực tế.

Với Release Board, chúng tôi có thể kiểm tra trực tiếp:

• Số lượng phát hành có sẵn.
• Các mục đang bị chặn.
• Hỏi đáp về trạng thái.
• Giao diện điều khiển bảng.
• Luồng thao tác chính.

Quan trọng nhất:

Tất cả những điều này xảy ra trên môi trường Preview, không phải Production.

Khách hàng không thể nhìn thấy sự thay đổi.

Người dùng thực sự không bị ảnh hưởng.

Bạn có thể kiểm tra, phát hiện lỗi và sửa lại một cách an toàn.

Chỉ khi mọi thứ được kiểm tra, thay đổi mới được phát triển chính thức.

Bốn cột trụ kết hợp với nhau như thế nào?

Bây giờ hãy xem lại toàn bộ quy trình.

1. Phạm vi – Phạm vi

Quyết định:

Đại lý được phép làm gì?

2. Bộ nhớ – Memory

Quyết định:

Đại lý phải ghi lại những quy tắc nào?

3. Ủy quyền – Phi đoàn

Quyết định:

Công việc nào nên chia cho đại lý khác?

4. Bằng chứng – Bằng chứng

Quyết định:

Làm thế nào để biết kết quả thực sự chính xác?

Bốn yếu tố này bổ sung cho nhau.

Nếu chỉ có Phạm vi mà không có Bộ nhớ, tác nhân có thể có quyền đúng nhưng không thể hiểu được tính toán của dự án.

If has Memory but no Scope, tác nhân hiểu dự án nhưng có thể có quá nhiều quyền.

Nếu có Phạm vi và Bộ nhớ nhưng không có Ủy quyền, đặc nhiệm có thể trở thành nút thắt khi dự án lớn.

Nếu có cả ba nhưng không có bằng chứng thì bạn vẫn phải tin vào lời nói của AI.

Vì vậy:

Phạm vi giới hạn. Bộ nhớ duy trì kiến ​​trúc. Tăng cường quyền mở rộng. Kết quả kiểm tra bằng chứng. 

Đây mới là cách tư duy đúng khi làm việc với AI Agent

Điểm quan trọng nhất của phương pháp này không phải là một tập tin config.toml.

Cũng không phải agents.md.

Và càng không cần thiết phải có bao nhiêu đại lý.

Điều quan trọng là cách bạn thay đổi vai trò của AI trong quy trình phát triển phần mềm .

Vì coi AI là một chatbot:

“Tôi yêu cầu → AI trả lời.”

Hãy coi AI là một đội ngũ:

“Tôi xác định phạm vi → cung cấp bộ nhớ → phân chia công việc → kiểm tra bằng chứng → quyết định phát hiện.”

Đó là một sự thay đổi rất lớn về thứ tư.

Quy trình có thể tái sử dụng cho mọi dự án

Bạn hoàn toàn có thể áp dụng mô hình này cho nhiều loại dự án khác nhau.

Ví dụ, với một tính năng mới:

Bước 1 – Phạm vi

Xác định tác nhân được phép truy cập và thay đổi những gì.

Bước 2 – Trí nhớ

Đảm bảo agents.mdchứa các quy tắc quan trọng của dự án.

Bước 3 – Kế hoạch

Choose nhân vật yêu cầu và thiết lập kế hoạch trước khi viết mã.

Bước 4 – Thực hiện

Đại lý thực hiện công việc.

Bước 5 – Đại biểu

Nếu cần, giao những nhiệm vụ độc lập cho đại lý phụ.

Bước 6 – Kiểm tra phần mềm

Một nhân viên khác kiểm tra các thay đổi mà không tự động sửa mã.

Bước 7 – Bằng chứng

Kiểm tra các tính năng khác, kiểm tra, xây dựng và hoàn thiện các tiêu chí.

Bước 8 – Xem trước

Chuyển sang Preview môi trường.

Bước 9 –Đánh giá của người dùng

Người kiểm tra kết quả cuối cùng.

Bước 10 – Sản xuất

Chỉ phát triển khi toàn bộ bằng chứng đã đạt yêu cầu.

Đây không còn là một lời nhắc.

Đây là một quy trình hoạt động của AI Agent .

Kết luận: Đừng cầu nguyện để AI viết đúng code

Cái bẫy lớn nhất khi sử dụng Codex không phải là AI viết mã hóa thân thiện.

Mà chúng ta là giao thức cho AI quá nhiều quyền nhưng lại cung cấp quá ít cấu trúc.

Khi đó, mỗi lần AI cho kết quả tốt, chúng tôi nghĩ:

“Lời nhắc này thực sự tuyệt vời.”

Nhưng khi thu được tiền tệ lần này, chúng tôi lại cố gắng viết lời nhắc nhanh hơn.

Cách tiếp cận tốt hơn là xây dựng một hệ thống trong đó kết quả không phụ thuộc quá nhiều vào một lời nhắc có thể may mắn.

Hãy bắt đầu bằng Phạm vi để kiểm soát quyền.

Sử dụng bộ nhớ để lưu lại định thức và quy tắc dài hạn.

Sử dụng Ủy quyền để chia nhỏ và song hóa công việc một cách có thể kiểm soát.

Và cuối cùng, sử dụng Bằng chứng để kiểm tra mọi thay đổi trước khi người dùng đưa ra.

Phạm vi – Bộ nhớ – Ủy quyền – Bằng chứng.

Đó là 4 điểm kiểm soát có thể biến Codex từ một công cụ viết mã thành một thành viên thực sự trong quy trình phát triển phần mềm.

Và khi bạn đã xây dựng quy trình này một lần, bạn sẽ không chỉ sử dụng nó cho Release Board.

Bạn có thể tái sử dụng nó cho gần như mọi tính năng, mọi kho lưu trữ và mọi dự án phần mềm mà mình xây dựng cùng AI.