Nhiều người bắt đầu với AI bằng một câu hỏi trong ô chat: “Hãy viết giúp tôi đoạn này”. Cách đó hữu ích, nhưng nó mới chỉ là điểm bắt đầu. Khi công việc nằm trong một thư mục dự án, có nhiều tệp liên quan, có quy tắc cần giữ và có kết quả cần kiểm tra, bạn cần một cách làm khác: giao cho AI một nhiệm vụ có bối cảnh, để nó tự đọc, lập kế hoạch, thực hiện và báo lại.
Đó là cách tôi nhìn về Codex — một AI coding agent dành cho việc phát triển phần mềm. Bài viết này không hướng bạn chạy theo một công cụ mới. Tôi muốn đưa ra một khung làm việc đủ rõ để bạn thử Codex trên chính công việc đang nằm trước mặt.
Codex là gì?
OpenAI mô tả Codex là coding agent cho phát triển phần mềm: nó có thể giúp viết, xem xét và gỡ lỗi code. Codex có thể được dùng trong IDE, qua CLI, trên web và mobile, hoặc trong quy trình CI/CD thông qua SDK. Bạn có thể đọc mô tả đầy đủ trong tài liệu Code generation của OpenAI.
Điểm quan trọng nằm ở chữ agent. Codex không chỉ trả lời một đoạn code rồi chờ bạn tự ghép mọi thứ lại. Khi được cấp đúng quyền và đúng bối cảnh, nó có thể:
- đọc cấu trúc và các tệp liên quan trong dự án;
- tìm nơi cần thay đổi;
- lập kế hoạch trước khi sửa;
- thực hiện nhiều thay đổi liên quan;
- chạy lệnh kiểm tra, đọc lỗi và sửa tiếp;
- tóm tắt những gì đã làm để bạn xem xét.
Codex vẫn cần một người chịu trách nhiệm về mục tiêu, phạm vi và quyết định cuối cùng. Nó giúp rút ngắn vòng lặp từ vấn đề đến bản chạy được; nó không thay thế việc bạn hiểu mình đang xây thứ gì.
Khác biệt giữa chatbot và AI agent
| Chatbot thông thường | AI agent như Codex |
|---|---|
| Trả lời dựa trên phần bối cảnh bạn gửi. | Có thể đọc bối cảnh từ cả dự án và các tệp liên quan. |
| Thường đưa ra một gợi ý hoặc một đoạn code. | Có thể lập kế hoạch rồi thực hiện chuỗi bước liên quan. |
| Bạn tự chạy, tự kiểm tra kết quả. | Có thể chạy test, lệnh build hoặc kiểm tra định dạng khi được cho phép. |
| Phù hợp với câu hỏi nhỏ và độc lập. | Phù hợp với công việc có nhiều bước, nhiều tệp và cần lặp lại. |
Vì có khả năng hành động, agent cũng cần kỷ luật hơn. Một yêu cầu mơ hồ có thể tạo ra một thay đổi lớn nhưng không đúng ý. Một lệnh kiểm tra bị bỏ qua có thể khiến lỗi đi thẳng vào sản phẩm. Cách dùng tốt vì thế bắt đầu từ cách giao việc tốt.
Đừng bắt đầu bằng “hãy code cho tôi”
Hãy bắt đầu bằng một kết quả có thể kiểm tra. Thay vì nói “xây giúp tôi một trang dashboard”, hãy nói rõ:
- Kết quả: người dùng cần làm được gì sau khi trang hoàn thành?
- Bối cảnh: dự án đang dùng công nghệ nào, phần nào đã có sẵn?
- Ràng buộc: điều gì không được thay đổi, giới hạn về giao diện, hiệu năng hoặc dữ liệu?
- Kiểm chứng: thế nào là hoàn thành và cần chạy kiểm tra nào?
Một prompt mở đầu có thể đơn giản như sau:
Mục tiêu: thêm bộ lọc theo trạng thái cho danh sách dự án.
Bối cảnh:
- Đọc cấu trúc dự án trước khi sửa.
- Giữ nguyên API hiện tại và hệ thống màu đang dùng.
- Ưu tiên cách hiển thị tốt trên mobile.
Cách làm:
1. Tìm các file liên quan và mô tả ngắn cách chúng kết nối.
2. Đề xuất kế hoạch thay đổi, chưa sửa code.
3. Sau khi kế hoạch rõ, thực hiện thay đổi nhỏ nhất cần thiết.
4. Chạy kiểm tra phù hợp và báo lại file đã đổi, kết quả và phần còn rủi ro.Prompt này có một tác dụng quan trọng: nó buộc cả người giao việc và agent cùng nhìn vào kết quả, thay vì chỉ nhìn vào thao tác.
Quy trình năm bước tôi khuyên dùng
1. Cho Codex đọc trước khi yêu cầu sửa
Hãy bắt đầu bằng “hãy khảo sát”. Yêu cầu Codex đọc README, cấu trúc thư mục, các file cấu hình và những phần liên quan trực tiếp đến vấn đề. Ở bước này, mục tiêu là tạo bản đồ chung. Nếu agent sửa ngay sau một câu mô tả ngắn, nó dễ chọn sai điểm vào.
2. Yêu cầu một kế hoạch ngắn
Một kế hoạch tốt không cần dài. Nó nên trả lời ba câu hỏi: sẽ đổi file nào, vì sao đổi ở đó, và sẽ kiểm tra kết quả bằng cách nào. Nếu kế hoạch cho thấy phạm vi quá rộng, bạn có thể thu nhỏ trước khi có thay đổi thật.
3. Làm theo lát cắt nhỏ
Chia công việc thành những phần có thể kiểm tra độc lập: giao diện trước, dữ liệu sau; một luồng chính trước, các trạng thái biên sau. Mỗi lát cắt nhỏ giúp bạn đọc diff dễ hơn và giúp agent nhận phản hồi chính xác hơn.
4. Luôn yêu cầu chạy kiểm tra
“Đã sửa xong” chưa phải là “đã hoạt động”. Tùy dự án, kiểm tra có thể là unit test, lint, build, một lệnh truy vấn, hoặc mở trực tiếp màn hình liên quan. Nếu chưa có test, hãy yêu cầu Codex đề xuất một cách kiểm tra thủ công có thể lặp lại.
5. Đọc phần thay đổi trước khi chấp nhận
Hãy xem diff, các file mới và kết quả kiểm tra. Đặc biệt chú ý những thay đổi ngoài phạm vi, tên biến hoặc nội dung có vẻ hợp lý nhưng không khớp với nghiệp vụ. Agent giỏi giúp bạn đi nhanh hơn; quyết định cuối cùng vẫn nên thuộc về người hiểu sản phẩm.
Ba nhóm công việc Codex làm tốt
Gỡ lỗi có bối cảnh
Thay vì dán một thông báo lỗi rời rạc, hãy cho Codex biết lỗi xuất hiện sau thao tác nào, môi trường nào, log nào liên quan và kết quả mong đợi. Agent có thể lần theo luồng từ giao diện tới API rồi tới nơi dữ liệu được xử lý.
Thay đổi giao diện theo hệ thống
Codex hữu ích khi một thay đổi cần đồng bộ nhiều nơi: cùng một component xuất hiện ở nhiều màn hình, một breakpoint cần được tối ưu cho tablet và mobile, hoặc một token màu cần thay trên toàn hệ thống. Hãy yêu cầu nó tìm tất cả điểm dùng trước khi sửa một điểm.
Biến việc lặp lại thành workflow
Những việc như tạo báo cáo, chuẩn hóa dữ liệu, chuyển đổi định dạng, tạo nội dung từ một mẫu hoặc kiểm tra một nhóm file thường có thể biến thành script nhỏ. Giá trị không nằm ở một lần chạy nhanh; giá trị nằm ở việc lần sau bạn không phải làm lại từ trang trắng.
Một phiên làm việc 60 phút với Codex
- 10 phút đầu: mô tả kết quả và để Codex khảo sát dự án.
- 10 phút tiếp: đọc kế hoạch, bổ sung ràng buộc và thống nhất phạm vi.
- 25 phút: để Codex thực hiện lát cắt đầu tiên, chạy kiểm tra và sửa lỗi.
- 10 phút: đọc diff, thử luồng chính và ghi lại quyết định quan trọng.
- 5 phút cuối: yêu cầu Codex tóm tắt thay đổi, lệnh đã chạy và việc nên làm tiếp.
Khung thời gian này không phải công thức cứng. Nó chỉ giúp bạn tránh hai thái cực: giao một nhiệm vụ quá lớn rồi chờ kết quả mơ hồ, hoặc liên tục sửa từng dòng mà không có mục tiêu tổng thể.
Những lỗi thường gặp khi mới dùng AI agent
- Không nói rõ phạm vi: agent có thể chạm vào nhiều phần hơn bạn dự tính.
- Gộp quá nhiều mục tiêu: một prompt vừa muốn đổi giao diện, đổi dữ liệu và đổi kiến trúc sẽ khó kiểm tra.
- Không đưa tiêu chí hoàn thành: bạn không có cơ sở để biết kết quả đã đạt hay chưa.
- Tin vào câu trả lời thay vì kết quả: một báo cáo tự tin không thay thế được test và diff.
- Đưa dữ liệu nhạy cảm vào dự án: hãy kiểm tra quyền truy cập, secret, file môi trường và chính sách của tổ chức trước khi cho agent đọc hoặc sửa.
Codex phù hợp với ai?
Codex phù hợp nhất với người có một bài toán thật và sẵn sàng học cách mô tả bài toán đó. Bạn không cần là kỹ sư phần mềm lâu năm để bắt đầu, nhưng cần biết mình muốn cải thiện quy trình nào, dữ liệu nào được phép sử dụng và kết quả nào có thể kiểm tra.
Với developer, Codex có thể rút ngắn thời gian từ issue đến pull request. Với người làm sản phẩm, vận hành hoặc marketing có kỹ năng kỹ thuật cơ bản, Codex có thể giúp biến một quy trình lặp lại thành công cụ nhỏ. Với người mới, cách tốt nhất là bắt đầu từ một dự án cá nhân nhỏ, có thể khôi phục và có đầu ra rõ ràng.
Kết luận: học cách giao việc, không chỉ học cách hỏi
Codex đáng chú ý không phải vì nó viết ra nhiều code hơn. Nó đáng chú ý vì nó thay đổi đơn vị làm việc: từ một câu hỏi rời rạc sang một nhiệm vụ có bối cảnh, kế hoạch, hành động và kiểm chứng.
Nếu bạn muốn bắt đầu, hãy chọn một việc thật đang làm chậm bạn trong tuần này. Viết ra kết quả mong muốn, giới hạn và cách kiểm tra. Sau đó để Codex khảo sát trước, sửa một lát cắt nhỏ và báo cáo trung thực những gì nó đã làm. Qua vài vòng như vậy, bạn không chỉ có một đoạn code mới; bạn có một cách làm có thể lặp lại.
Gợi ý bước tiếp theo: lưu lại prompt đầu tiên, diff cuối cùng và bài học sau mỗi phiên. Đó sẽ là thư viện workflow riêng của bạn.