Dù có được nhắc "hãy đưa chỉ dẫn cụ thể hơn", tôi vẫn muốn được hỗ trợ ngay từ chính cái phần "cụ thể" đó.
Bạn có một thứ muốn xây dựng, nhưng lại khựng tay khi phải làm mớ nghiên cứu sơ bộ để hỏi AI. Cảm giác này thật tệ.
Ví dụ, giả sử bạn muốn một ứng dụng cho phép đăng ký các vụ việc và sắp xếp chúng theo hạn chót đang đến gần. Bạn nói được chừng đó. Nhưng nếu bị hỏi về cách lưu trữ dữ liệu hay phương pháp kiểm tra lỗi (bug), khối lượng tìm hiểu bỗng tăng vọt.
Trong lúc tìm hiểu, bạn bắt đầu cắt bỏ những tính năng ban đầu định làm, với suy nghĩ "lần này không có chắc cũng chẳng sao". Không phải vì làm chúng quá khó, mà vì bạn muốn giữ mọi thứ trong phạm vi mình tự xử lý được nếu có sự cố.
Thực ra tôi không muốn chuẩn bị từng chỉ dẫn nhỏ nhặt trước khi hỏi. Tôi muốn bạn phát hiện giúp những gì tôi có thể bỏ sót. Sẽ rất hữu ích nếu bạn đưa ra hai lựa chọn rõ ràng để tôi quyết định, rồi dựa vào đó mà triển khai công việc.
Đội ngũ phát triển chúng ta sẽ thiết lập trong bài viết này được tạo ra để tiến gần hơn tới mong muốn đó, sử dụng Claude Code và Codex.
- Claude Code: Đầu mối tiếp nhận yêu cầu. Tổng hợp các điểm cần xác nhận và phân chia công việc.
- Codex: Đảm nhiệm việc triển khai và kiểm tra.
Với một ứng dụng quản lý vụ việc, ngoài việc tạo giao diện, bạn còn phải chuẩn bị các tác vụ kiểm chứng. Chuyện gì xảy ra nếu để trống trường dữ liệu mà vẫn lưu? Dữ liệu có còn sau khi tải lại trang không? Nếu lỗi không sửa được, hãy tóm tắt các cách đã thử và triệu chứng còn lại để bàn giao cho agent khác.
Việc của con người là đưa ra các phán đoán cần thiết trong quá trình làm và kiểm chứng hoạt động thực tế ở bước cuối. Để việc này suôn sẻ, hãy tạo một cấu trúc nơi các đặc tả, thay đổi và kết quả kiểm chứng đều quay trở về tay bạn một cách trọn vẹn. Chúng ta sẽ xây dựng từng bước, từ cách kết nối, bàn giao tác vụ cho đến điều kiện dừng.
Giao Việc Cho Codex Trong Khi Vẫn Mở Claude
Có một cách để chuyển yêu cầu từ Claude Code sang Codex mà không cần dán câu trả lời cũ vào một AI khác. Đó là "plugin Codex dành cho Claude Code" do OpenAI phát hành.
Theo tài liệu chính thức, nó hỗ trợ các trường hợp như:
- Review (đánh giá) nhằm kiểm tra các thay đổi hiện tại
- Ủy thác việc điều tra hoặc sửa lỗi
- Chuyển giao hội thoại
Bài viết này hướng dẫn quy trình sử dụng plugin từ Claude Code trên môi trường local, dựa trên tài liệu chính thức được xác minh vào ngày 16 tháng 10 năm 2026.
Điều Kiện Tiên Quyết
- Môi trường có thể sử dụng Claude Code
- Git
- Node.js (yêu cầu chính thức: bản 18.18 trở lên)
- Tài khoản ChatGPT đã xác thực với Codex, hoặc một API key của OpenAI
Plugin sẽ gọi Codex trên máy local của bạn. Việc kết nối không có nghĩa là Codex chạy bằng hạn mức của Claude; Codex dùng bao nhiêu sẽ trừ vào hạn mức riêng của nó.
Ngoài ra, dù thiết lập này xử lý file local, quá trình suy luận của AI không nhất thiết diễn ra hoàn toàn trên máy tính của bạn. Hãy bắt đầu với một thư mục thực hành không chứa thông tin mật.
Cài Đặt Plugin
Trong ô nhập lệnh của Claude Code, hãy thực thi lần lượt các lệnh sau từ trên xuống dưới. Đây là các thao tác thêm plugin bên trong Claude Code, không phải lệnh dán vào terminal thông thường.
1/plugin marketplace add openai/codex-plugin-cc2/plugin install codex@openai-codex3/reload-plugins4/codex:setup
Lệnh cuối /codex:setup giúp bạn kiểm tra trạng thái cài đặt và xác thực của Codex. Nếu không tìm thấy Codex mà máy có npm, hướng dẫn cài đặt sẽ hiện ra; hãy đọc kỹ và làm theo.
Nếu chưa xác thực, hãy chạy codex login trong terminal và làm theo hướng dẫn.
Trên Windows, hãy đảm bảo môi trường chạy Claude và môi trường cài Codex không bị tách rời nhau. Đừng cài đi cài lại liên tục chỉ vì thấy báo "không tìm thấy".
Thử Review Trước
Hãy bắt đầu bằng một bản review không làm thay đổi code. Chuẩn bị một thay đổi nhỏ trong dự án thực hành có quản lý bằng Git và thực thi:
1/codex:review --background
- Kiểm tra tiến độ:
/codex:status
- Xem kết quả đã xong:
/codex:result
Khi có nhiều yêu cầu đang chạy, hãy chỉ định Job ID hiển thị trên màn hình để tránh nhầm lẫn kết quả.
Các Mẫu Công Khai Của Amazon Rất Hữu Ích Cho Việc Chia Tác Vụ
Để tham khảo cách phân vai trò, hãy xem các mẫu phát triển do AWS (bộ phận điện toán đám mây của Amazon) công bố. Trên GitHub aws-samples, có hai repository liên quan:
- sample-codex-agent-team (dành cho Codex)
- sample-claude-code-agent-team (dành cho Claude Code)
Bản dành cho Codex có sáu vai trò:
Quyết định cách dựng màn hình đăng ký khác hẳn với việc cân nhắc khả năng mở rộng hay chi phí bảo trì. Tách biệt việc triển khai tính năng khỏi tư vấn vận hành sẽ giúp câu hỏi gửi tới từng agent cụ thể hơn.
Review nhẹ nhàng không phải để xử lý qua loa những thay đổi rủi ro cao. Đây là cách phân chia nhằm tránh việc bắt các tác vụ ít rủi ro như sửa tài liệu hay thay thế máy móc phải trải qua khâu kiểm tra nặng nề mỗi lần.
Cách bàn giao tác vụ giữa hai mẫu cũng khác nhau:
- Bản Claude Code: Các agent lấy tác vụ từ danh sách chung (sử dụng tính năng thử nghiệm agent teams, cần cấu hình thêm)
- Bản Codex: Tiến hành theo kế hoạch công việc với các file trách nhiệm được chia rõ
Đây là hai mẫu độc lập. Chúng không tự động gộp thành một đội nếu bạn cài cả hai.
Ngoài ra, bản Codex có chứa cấu hình model dựa trên các thiết lập kết nối chưa công bố. Chính mẫu này cũng ghi rõ rằng nó sẽ không chạy trực tiếp trên tài khoản của mọi người. Thay vì copy nguyên xi vào các dự án quan trọng của công ty, hãy chỉ áp dụng logic phân vai trò và điều chỉnh cho phù hợp với môi trường bạn đang dùng.
Bài viết này bắt đầu với một cấu trúc nhỏ: Claude Code đóng vai trò giao diện, chuyển các tác vụ triển khai và kiểm tra giới hạn sang cho Codex.
Lưu ý: Đây là ví dụ vận hành mang tính tham khảo từ các mẫu công khai. Nó không phải sản phẩm đảm bảo tích hợp Claude và Codex trên AWS, cũng không phải báo cáo đo lường hành vi thực tế.
Thống Nhất Ý Nghĩa Của "Lưu Được" Trước Khi Xây Dựng
Khi không thể mô tả chi tiết thứ muốn xây dựng, đừng vội triển khai ngay. Trước tiên, hãy nhờ Claude liệt kê các mục cần xác nhận. Bạn không cần biết hết thuật ngữ kỹ thuật; chỉ cần chuyển chúng thành những câu hỏi bạn có thể trả lời.
Tôi muốn xây một ứng dụng quản lý vụ việc cá nhân. Trước tiên, hãy tổng hợp các đặc tả cần thiết và hỏi tôi từng câu một về những quyết định cần đưa ra. Với các lựa chọn kỹ thuật, hãy giải thích ngắn gọn tác động đến người dùng và lý do đề xuất. Đừng bắt đầu triển khai cho đến khi tôi đồng ý.
Ví dụ, về việc lưu trữ: Chỉ cần dữ liệu tồn tại trên cùng một trình duyệt là đủ, hay bạn muốn đồng bộ giữa điện thoại và máy tính? Hai nhu cầu này đòi hỏi cơ chế hoàn toàn khác nhau. Việc tự ý chọn một cách sẽ dẫn đến làm lại về sau.
Với bài tập này, hãy thu hẹp phạm vi:
- Trong phạm vi (In Scope): Dùng trên cùng PC/trình duyệt, dữ liệu vẫn còn sau khi tải lại
- Ngoài phạm vi (Out of Scope): Đồng bộ đa thiết bị, đăng nhập, công khai ra ngoài, dữ liệu khách hàng thật
Hãy định nghĩa tiêu chí hoàn thành bằng kết quả hoạt động, chứ không phải kiểu "dễ sử dụng":
- Đăng ký được vụ việc
- Sắp xếp theo hạn chót
- Đổi được trạng thái
- Để trống khi đăng ký sẽ hiện lý do
- Nội dung vẫn còn sau khi tải lại
Lưu Đặc Tả Và Yêu Cầu Tác Vụ Vào File
Lưu nội dung đã chốt vào docs/spec.md làm đặc tả chung cho mọi người tham chiếu. Tên file ở đây chỉ là ví dụ; chúng không tự động phân phối cho mọi AI, nên mỗi lần yêu cầu bạn phải dặn rõ "hãy đọc file này".
Lưu các đặc tả, tiêu chí hoàn thành và tính năng ngoài phạm vi đã chốt vào docs/spec.md. Không được viết những điều chưa quyết định thành đã xác nhận. Hãy tách riêng các hạng mục cần dừng triển khai khỏi các hạng mục cứ làm với thiết lập tạm thời.
Tiếp theo, tóm tắt yêu cầu tác vụ cho người triển khai vào docs/tasks.md. Chỉ nêu tên tác vụ là chưa đủ. Hãy kèm theo tài liệu cần đọc, các file được phép sửa, phần không được sửa, cách kiểm chứng và kết quả kỳ vọng.
Chia nhỏ đặc tả thành các đơn vị có thể triển khai. Ghi rõ file được giao, tác vụ điều kiện tiên quyết và cách kiểm chứng vào docs/tasks.md. Chốt trước các phần dùng chung giữa logic UI và lưu trữ. Không lên kế hoạch để hai agent cùng sửa một file một lúc.
Cho Cả Hai AI Xem Cùng Một Bản Đặc Tả
Các chỉ dẫn xuyên suốt có thể viết vào CLAUDE.md cho Claude và AGENTS.md cho Codex. Đây là cơ chế đã được tài liệu hóa. Tuy nhiên, đừng mặc định rằng một file sẽ hoạt động y hệt cho bên kia. Hãy để cả hai cùng tham chiếu một file đặc tả.
Giữ chỉ dẫn ngắn gọn:
- Vị trí file đặc tả
- Không tự ý thay đổi ngoài yêu cầu
Việc chép trùng đặc tả dễ dẫn đến một bên bị lỗi thời. Cách này giúp tránh điều đó.
Tách Biệt Workspace Trước Khi Làm Song Song
Nhiều AI cùng làm nghe có vẻ nhanh hơn, nhưng việc ghi đè cùng một file theo các chính sách khác nhau chỉ tạo thêm việc dọn dẹp cho con người.
Ở giai đoạn đầu làm song song, hãy ghép cặp "người dựng UI" với "người lập kế hoạch test". Triển khai UI và lưu trữ riêng rẽ khi chưa chốt định dạng sẽ làm tăng nguy cơ lệch pha.
Dùng Git Worktree Để Tách Thư Mục
Git worktree rất hữu dụng lúc này. Đây là tính năng chính chủ của Git cho phép tạo các thư mục làm việc riêng biệt cho cùng một dự án với các thay đổi khác nhau.
Trước khi tạo, hãy đảm bảo đặc tả và code nền đã được commit lên Git. Các file nháp chưa commit có thể không được chuyển sang vị trí mới. Kiểm tra xem tên branch và thư mục đích đã được dùng chưa.
1git worktree add -b feature/ui ../case-app-ui2git worktree add -b feature/storage ../case-app-storage3git worktree list
Ba lưu ý:
- Tạo thư mục không có nghĩa là đổi workspace của AI. Hãy mở các phiên làm việc riêng trong từng thư mục và kiểm tra vị trí/branch trước khi bắt đầu.
- Plugin dùng môi trường của bên gọi. Kết nối Claude/Codex không tự động cô lập chúng. Ban đầu, hãy tuân thủ nguyên tắc "một editor cho mỗi vị trí".
- Worktree chủ yếu chỉ cô lập file. Cơ sở dữ liệu hoặc cổng (port) dùng chung vẫn gây xung đột. Hãy tách riêng nơi lưu test/port hoặc khởi động tuần tự.
Giới Hạn Tác Vụ Chạy Đồng Thời Trong Codex
Để tăng số sub-agent trong Codex, hãy giới hạn luồng chạy đồng thời. Sub-agent nhận tác vụ giới hạn từ AI cha. Cấu hình hiện tại nằm trong .codex/config.toml:
1[agents]2enabled = true3max_concurrent_threads_per_session = 2
- Không khai báo trùng lặp
- Chỉ dùng trong các dự án đáng tin cậy (thiết lập dự án chỉ được nạp trong bối cảnh tin cậy)
- Giới hạn này áp dụng cho "các luồng đồng thời không tính agent chính trong phiên đó", chứ không phải tổng cộng trên toàn Claude/các phiên.
Con số 14 luồng trong mẫu của AWS chỉ là lựa chọn của họ, không phải quy chuẩn bắt buộc. Tham số max_threads của họ là tên gọi cũ; hãy dùng tên hiện hành.
Đừng Giải Thích Lại Từ Đầu Cho Người Triển Khai Mỗi Lần
Trong Codex, bạn định nghĩa agent tùy chỉnh qua các file TOML trong .codex/agents. Tạo file task-builder.toml với các điều kiện cần thiết:
1name = "task-builder"2description = "Chỉ triển khai phạm vi được giao từ đặc tả đã chốt"3developer_instructions = """4Đọc docs/spec.md và docs/tasks.md trước.5Chỉ triển khai phạm vi được giao; dừng và báo cáo nếu cần thay đổi đặc tả.6Không hoàn tác thay đổi của agent khác, không đọc thông tin mật hay phát tán ra ngoài.7Trả về các file đã sửa, test đã chạy, kết quả và những điểm chưa xác nhận.8"""
Tránh ghim cứng tên model ở đây. Mặc định nó sẽ kế thừa thiết lập của agent cha. Các model trong mẫu công khai có thể không khả dụng trên gói cước của bạn; việc ghim cứng tên không khả dụng sẽ khiến hệ thống dừng trước cả khi đọc mô tả vai trò.
Sau khi đặt file, hãy mở phiên Codex mới để kiểm tra xem nó có nhận diện không, rồi giao một tác vụ nhỏ. Nếu yêu cầu từ Claude, hãy chỉ định dùng task-builder trong Codex.
Yêu cầu Codex giao riêng phần logic lưu trữ trong docs/tasks.md cho task-builder. Xác nhận agent đã được nhận diện và đúng thư mục thực tế trước khi bắt đầu. Nếu không khả dụng, hãy báo cáo thay vì tự ý đổi cách làm.
Lưu ý: Việc ghi "không được thay đổi" khác với việc tước quyền ghi. Tài liệu chính thức nêu rõ sub-agent của Codex kế thừa quyền của agent cha (thiết lập sandbox). Đặt tên vai trò là "reviewer" không tự động tạo ra môi trường chỉ đọc an toàn.
Đổi Agent Nếu Việc Sửa Lỗi Bị Lặp Lại
Nếu AI báo "đã tìm ra nguyên nhân" nhưng thao tác đó vẫn lỗi, hãy ghi lại những gì đã thay đổi/chưa thay đổi thay vì vội lao vào sửa tiếp. Như vậy sẽ dễ bàn giao hơn.
Plugin chính thức có lệnh rescue để ủy thác việc điều tra/sửa lỗi cho Codex. Dù tên gọi là vậy, nó dùng cho các tác vụ có phạm vi rõ ràng, không chỉ riêng bug.
Ghi Rõ Việc Điều Tra Là Chỉ Đọc
Nếu chỉ phân tích nguyên nhân, hãy nói rõ là không được ghi dữ liệu. Theo quy trình nội bộ, rescue mặc định có quyền ghi trừ khi bạn chỉ định khác. Hãy tách bạch giữa điều tra và sửa lỗi.
1/codex:rescue --fresh Điều tra xem tại sao dữ liệu đăng ký biến mất khi tải lại, chế độ chỉ đọc. So sánh docs/spec.md với code. Trả về các bước tái hiện, nguyên nhân có bằng chứng, và những gì cần kiểm tra thêm. Không sửa file.
--fresh bắt đầu yêu cầu mới; --resume tiếp tục yêu cầu cũ (nếu bỏ qua sẽ có hộp thoại hỏi). Hãy chỉ định quyền khi resume. Nếu chuyển sang bước sửa lỗi, hãy khoanh vùng phạm vi.
1/codex:rescue --resume Chỉ sửa logic lưu trữ với thay đổi tối thiểu dựa trên nguyên nhân đã chốt. Không đổi UI/đặc tả. Đưa ra test thất bại trước đó và kết quả sau khi sửa.
Chuyển Toàn Bộ Hội Thoại Bằng Transfer
- Chỉ giao tác vụ → rescue
- Chuyển cả hội thoại sang Codex → transfer
1/codex:transfer
Theo tài liệu chính thức: Lệnh này tạo một luồng Codex tiếp nối hội thoại hiện tại của Claude Code, đồng thời hiển thị lệnh để tiếp tục. Hãy cập nhật Codex nếu chưa được hỗ trợ.
Chuyển hội thoại ≠ chuyển trạng thái máy tính. Các thay đổi chưa lưu, thông tin xác thực, ứng dụng đang chạy sẽ không đi theo. Hãy kiểm tra lại file và trạng thái ở nơi đến.
Kiểm Chứng Bằng AI Khác Sau Khi Có Báo "Xong"
Người triển khai tự test là tốt, nhưng nếu họ hiểu sai đặc tả thì test có qua cũng không khớp với hành vi bạn mong muốn.
Hãy cung cấp cho người kiểm tra bản đặc tả đã được con người xác nhận và các thay đổi thực tế, chứ không phải lời giải thích của người triển khai. Đừng chia sẻ đánh giá "đã sửa hoàn hảo"; hãy để họ tự kiểm tra mức độ tuân thủ.
Hãy so sánh độc lập docs/spec.md với các thay đổi thực tế. Chỉ ra những tiêu chí hoàn thành chưa đạt kèm bằng chứng. Không mặc định tin vào tự đánh giá của người triển khai. Tách riêng các lỗi tái hiện được, rủi ro tiềm ẩn và những điểm chưa kiểm chứng. Không tự ý sửa lúc này.
Hãy ghép cặp đối lập:
- Claude triển khai → Thêm một bản review thông thường của Codex làm bước kiểm tra riêng
- Codex triển khai → Nhờ Claude kiểm tra, có thể bổ sung thêm review mới từ Codex
Review Thông Thường vs Review Đối Kháng
Gọi review thông thường bằng /codex:review. So sánh branch hiện tại với main:
1/codex:review --base main
Nếu không có nhánh main, hãy dùng nhánh base thực tế. Đừng can thiệp vào các thay đổi trong lúc đang review.
Lưu ý: Review thông thường không nhận chỉ dẫn tự do kiểu "chỉ kiểm tra phần lưu trữ". Đặc tả chính thức cấm các chỉ thị ưu tiên. Muốn thách thức các giả định thiết kế hoặc rủi ro cụ thể, hãy dùng adversarial-review.
1/codex:adversarial-review --background Kiểm tra xem lỗi lưu có bị hiển thị thành công không, nếu sửa từ hai tab có mất dữ liệu không, xác minh lại các giả định thiết kế hiện tại.
Đây không phải giọng điệu gay gắt; nó nhằm thách thức các cách tiếp cận/giả định đã chọn. Cả hai loại review đều chỉ tìm vấn đề, không sửa code. Hãy xác nhận kết quả, rồi giao việc sửa chữa riêng.
Sắp xếp các phát hiện kèm tiêu chí hoàn thành tương ứng, tác động đến người dùng và cách kiểm chứng. Không tự động sửa các lỗi đòi hỏi thay đổi đặc tả; hãy đưa ra các lựa chọn/khác biệt để con người quyết định.
Ban Đầu Nên Bỏ Qua Review Gate
Một tùy chọn tự động hóa: "Review gate" sẽ chèn bản review của Codex mỗi khi Claude trả lời xong. Bật bằng /codex:setup --enable-review-gate.
Cảnh báo: Tài liệu chính thức lưu ý rủi ro vòng lặp sửa lỗi kéo dài giữa Claude/Codex sẽ ngốn hạn mức rất nhanh.
Hãy bắt đầu bằng review thủ công để hiểu các phát hiện. Tắt đi khi bạn vắng mặt. Dừng bằng /codex:setup --disable-review-gate và kiểm tra các yêu cầu đang chờ.
Lưu Lại Các Yêu Cầu Thành Công Cho Tác Vụ Sau
Thay vì dán lại đoạn chỉ dẫn dài dòng, hãy lưu các quy trình đã chạy tốt. Tính năng Skills cho phép lưu quy trình tác vụ vào file để dùng lại.
Theo tài liệu Anthropic: Đặt quy trình vào .claude/skills. Tạo thư mục team-brief chứa file SKILL.md với các bước kiểm tra trước khi bàn giao.
1---2name: team-brief3description: Tổng hợp phạm vi và cách kiểm chứng từ đặc tả4disable-model-invocation: true5---6Đọc docs/spec.md và docs/tasks.md, chỉ nhắm vào các thay đổi hiện tại.7Tổng hợp phạm vi, những gì cấm sửa, điều kiện tiên quyết, tiêu chí hoàn thành và cách kiểm chứng.8Soạn nội dung yêu cầu cho các agent, để lại những điểm chưa chốt cho con người xác nhận.9Không sửa code, không phát tán ra ngoài hay khởi chạy Codex trong quy trình này.
Gọi trong Claude Code:
1/team-brief Muốn thêm tính năng sắp xếp theo hạn chót
Đây là lệnh tùy chỉnh, không có sẵn. disable-model-invocation: true đảm bảo con người là người quyết định thời điểm. Claude sẽ không tự khởi chạy. Quy trình này không ép AI phải khởi chạy hay kiểm tra; hãy thử "chỉ dùng lại phần chuẩn bị" trước.
Dynamic Workflows Cho Tác Vụ Lớn
Với phạm vi lớn hơn, Claude Code cung cấp Dynamic workflows (công bố tháng 5 năm 2026), cho phép kịch bản hóa nhiều agent. Khả dụng trên các gói trả phí/API.
- Chat thông thường: Claude tự chọn tác vụ tiếp theo mỗi lần
- Dynamic workflows: Kịch bản hóa các nhánh/thu thập kết quả, có thể chạy lại
Ví dụ: Điều tra lỗi lưu, kiểm tra đầu vào, lỗi vỡ giao diện trên nhiều màn hình riêng biệt, sau đó đối chiếu kết quả. Đừng khởi chạy đống agent khổng lồ cho một ứng dụng nhỏ; hãy cân nhắc khi cần áp dụng cùng một bộ kiểm tra trên diện rộng.
Tạo Dynamic workflow điều tra các màn hình đã tách, xác minh phát hiện bằng các agent riêng. Trình bày trước mục tiêu, số lượng agent và điều kiện thoát. Không sửa code; chỉ thực thi phạm vi nhỏ sau khi được duyệt.
Mẹo:
- Bật qua
/configtrong gói Pro
- Theo dõi tiến độ/mức tiêu thụ bằng
/workflows, có thể dừng bất cứ lúc nào
- Chọn quy mô (nhỏ, v.v.) trong
/config; tài liệu chính thức gọi đây là ước tính, không phải giới hạn cứng. Đừng mặc định rằng số lượng agent được đảm bảo.
Tính năng này chạy agent phía Claude. Codex không tự động tham gia. Hãy dùng cho việc điều tra/kiểm chứng nội bộ của Claude trước; coi việc giao cho Codex là một giai đoạn riêng.
Chạy Thử Ứng Dụng Quản Lý Vụ Việc Từ Đầu Đến Cuối
Kết nối các thành phần thành một bản dựng ứng dụng hoàn chỉnh. Dưới đây là ví dụ phát triển mang tính giải thích, không phải báo cáo trải nghiệm đã hoàn thiện; hãy tự xác minh trong môi trường của bạn.
Mục Tiêu Xây Dựng
- Các trường: Tên vụ việc, hạn chót, trạng thái, ghi chú
- Trạng thái: Chưa bắt đầu / Đang làm / Hoàn thành
- Tìm kiếm theo tên vụ việc
- Xem các vụ việc chưa xong sắp xếp theo hạn chót
Yêu Cầu Ban Đầu
Gửi cho Claude. Nhắm vào thư mục thực hành mới, không dùng dự án quan trọng đang có.
Xây ứng dụng quản lý vụ việc cá nhân trong thư mục thực hành. Trước tiên hãy xác nhận môi trường và đặc tả. Bao gồm đăng ký/sửa/tìm kiếm/sắp xếp/lưu trữ cho tên, hạn chót, trạng thái, ghi chú. Loại trừ đăng nhập, đồng bộ, công khai ra ngoài.
Ứng viên lưu trữ: localStorage. Không có đồng bộ/sao lưu đa thiết bị; xóa dữ liệu trình duyệt là mất hết. Đừng đưa thông tin sản xuất giá trị vào đây.
Dựng Nền, Định Nghĩa Phần Dùng Chung
Một agent duy nhất dựng phần nền. Xác minh ứng dụng khởi chạy được, màn hình trống hiển thị đúng. Commit đặc tả/code nền lên Git trước khi tách workspace nếu cần.
- Giao cho agent UI: Các trường cần hiển thị, ánh xạ hành động
- Giao cho agent Storage: Định dạng bản ghi, cách đọc/thêm/cập nhật, xử lý lỗi
Không để bên nào tự bịa tên trường. Nếu trường trạng thái là status, cả hai phải dùng nó. Đừng vì tiện mà đổi một bên thành state; mọi thay đổi dùng chung phải chuyển về Claude để điều chỉnh.
Gửi Yêu Cầu Triển Khai Cho Codex
Chỉ định rõ nơi được phép ghi VÀ các bằng chứng đầu ra bắt buộc.
1/codex:rescue --fresh Đọc docs/spec.md và docs/tasks.md. Chỉ triển khai logic lưu trữ và test được giao. Trả về các file đã sửa, lệnh đã chạy, kết quả test và những điểm chưa xác nhận. Dừng và báo cáo nếu cần đổi đặc tả hoặc đụng vào phần của agent khác.
Trong lúc đó, Claude không được sửa ngang các file tương tự. Hãy tập trung vào kiểm tra hoàn thành/chuẩn bị dữ liệu test; quyết định bước tiếp theo sau khi có kết quả.
Chuẩn Bị Dữ Liệu Kiểm Chứng
- Hạn chót hôm qua, "Chưa bắt đầu"
- Hạn chót hôm nay, "Đang làm"
- Hạn chót tuần sau, "Hoàn thành"
- Nhiều vụ việc cùng hạn chót
- Tên vụ việc rất dài
Giúp việc kiểm tra sắp xếp/hiển thị trở nên cụ thể.
Ghi rõ luật chi tiết vào đặc tả:
- Sắp xếp: Cùng hạn chót thì xếp theo thứ tự đăng ký
- Trường trống: Tên/hạn chót là bắt buộc; ghi chú thì tùy chọn. Hiển thị rõ các trường thiếu.
- Ngày tháng: Định nghĩa giả định về thời điểm chuyển ngày. Nếu múi giờ/xử lý thời gian làm lệch ngày, ứng dụng trông đẹp mấy cũng vô dụng.
Chốt luật trước giúp tránh việc kiểm tra thiếu nhất quán sau khi triển khai.
Tích Hợp Và Kiểm Thử
Khi các phần đã sẵn sàng, nhờ Claude đọc danh sách thay đổi/kết quả test và xác nhận tích hợp. Nếu dùng worktree, hãy gom thay đổi vào một branch kiểm chứng duy nhất. Chạy lại các test vốn đã qua ở từng phần sau khi tích hợp.
Dùng Playwright để tự động hóa UI. Các hướng dẫn hiện tại cung cấp CLI/Skills cho AI agent; MCP không phải cách duy nhất.
Hãy tách bạch "cơ chế AI điều khiển trình duyệt" khỏi "test có thể lặp lại". Dùng Playwright Test cho các luồng từ đăng ký đến tải lại có thể chạy đi chạy lại.
Tạo Playwright Tests kiểm chứng việc đăng ký, từ chối khi để trống, tìm kiếm, đổi trạng thái, sắp xếp theo hạn chót, lưu trữ. Tách riêng cấu hình khởi chạy/dữ liệu test. Không được thay đổi hành vi ứng dụng hay tiêu chí hoàn thành chỉ để test chạy qua.
Thiết lập cho dự án thực hành mới:
1npm init playwright@latest
Nếu đã cài rồi, hãy kiểm tra cấu hình khởi chạy/test hiện có trước khi thêm mới.
Đảm bảo trình duyệt đã được cài, cấu hình khởi chạy ứng dụng, sau đó chạy:
1npx playwright test2npx playwright show-report
Quan trọng: Đừng coi việc không tìm thấy test nào hoặc tất cả bị bỏ qua là "đạt".
Khi thất bại, hãy khoanh vùng nguyên nhân: Lỗi logic lưu trữ hay test đang tìm một nút bấm không tồn tại? Đừng xóa test chỉ để bảng xanh lè; hãy quyết định mục tiêu sửa lỗi dựa trên đặc tả gốc.
Con Người Kiểm Chứng Lần Cuối
Tự mắt kiểm tra giao diện. Có chữ nào bị ẩn không? Các vụ việc sắp đến hạn có dễ tìm không? Báo cáo test chạy qua không đảm bảo trải nghiệm người dùng (UX) tốt.
Nhận bốn mục từ Claude, thay vì những đoạn log dài dằng dặc:
- Cách khởi chạy
- Các hành vi đã kiểm chứng
- Những giới hạn còn lại
- Các ứng viên cần sửa tiếp theo
Tự tay đăng ký một mục, tải lại trang, xác minh dữ liệu còn đó. Sau đó mới đánh dấu hoàn thành.
Điểm Dừng Của Việc Cố Chấp Sửa Lỗi
Khi phạm vi nhóm mở rộng, hãy định nghĩa điểm kết thúc. Chúng ta đang luẩn quẩn với cùng một bug hay đang giải quyết các vấn đề nối tiếp nhau? Trạng thái mập mờ sẽ cản trở việc ra chỉ dẫn tiếp theo.
Đặt Tiêu Chí Dừng
Dùng quy tắc "tối đa hai lần sửa cho mỗi vấn đề" làm kim chỉ nam. Đây không phải khuyến nghị chính thức, mà là luật vận hành để trả quyền quyết định về cho con người khi bế tắc.
Nếu cùng một bug vẫn không sửa được sau hai lần thử, hãy dừng mọi thay đổi thêm. Tóm tắt các hành động đã thử, thay đổi đã thực hiện, triệu chứng còn lại và những quyết định cần đưa ra. Không lan man sang các tính năng không liên quan.
Chỉ dặn dò thôi chưa chắc AI sẽ dừng. Hãy theo dõi mức tiêu thụ, hủy các yêu cầu chạy ngầm không cần thiết bằng /codex:cancel. Xác minh xem agent có thực sự dừng không.
Theo Dõi Chi Phí Riêng
Hạn mức Codex xác thực qua ChatGPT khác với giá tính theo API key. Các agent chạy song song sẽ ngốn tài nguyên suy luận/công cụ.
Đừng đẩy những lần sửa văn bản nhỏ nhặt qua cả hai AI/bản review lớn.
Phân loại:
- Tác vụ một mình làm được
- Tác vụ cần góc nhìn thứ hai
- Tác vụ có thể chạy song song độc lập
Giúp bạn quyết định phân bổ công sức/hạn mức.
Cẩn Thận Với Cấu Hình Model Cũ
Cấu hình model cũ sẽ gây lỗi. Cập nhật từ OpenAI: GPT-5.5 đã ngừng hỗ trợ cho Codex xác thực qua ChatGPT vào ngày 15 tháng 10 năm 2026 (giờ JST). Xác thực bằng API key không bị ảnh hưởng.
Cập nhật các cấu hình/file vai trò cũ sang model hiện đang khả dụng. Hãy kiểm tra các model có thể chọn và thiết lập suy luận được chấp nhận, chứ không chỉ đổi tên.
Kiểm Tra Quyền Và Hooks
Quyền của Claude không phải lúc nào cũng truyền sang Codex. Hãy xác minh quyền thực thi ở cả hai bên. Thực hành mà không dùng thông tin xác thực của môi trường production. Yêu cầu phê duyệt riêng cho việc xóa, phát tán ra ngoài, hay phát sinh chi phí.
Hãy kiểm tra các hook trong những mẫu công khai trước khi sử dụng. Hook sẽ tự động chạy vào những thời điểm đã định; hãy xem thực tế đoạn mã nào đang được thực thi, chứ đừng chỉ nhìn vào những phần bổ sung cho có vẻ tiện lợi.
Đo lường "Xây dựng nhanh"
Đừng chỉ so sánh mỗi thời gian tạo mã.
- Số lần bạn phải giải thích lại yêu cầu
- Thời gian tích hợp/sửa lỗi
- Số lỗi còn sót lại so với tiêu chí hoàn thành
Hãy tính cả những yếu tố này để quyết định xem cách phân chia công việc đó có hiệu quả cho lần sau hay không.
Bắt đầu với những công cụ nhỏ dùng hàng tuần
Những người không chuyên về kỹ thuật sẽ dễ gặt hái thành công nhất ở các tác vụ mà họ có thể tự mình đánh giá tính chính xác.
- Theo dõi yêu cầu hỏi đáp
- Kiểm tra hạn chót đơn hàng
- Định dạng CSV với thứ tự sắp xếp nhất quán
Hãy bắt đầu từ những trường hợp sử dụng mà bạn có thể mô tả rõ ràng.
Bạn muốn ưu tiên những việc gần đến hạn? Loại bỏ các mục đã xong? Nhận cảnh báo khi thiếu dữ liệu đầu vào? Chính những nhu cầu hàng ngày đó sẽ trở thành tiêu chí hoàn thiện cho AI.
Không cần phải giỏi lập trình trước; hãy tạo bản mẫu dựa trên các điều kiện, rồi vừa dùng vừa sửa. Lưu ý: Các hệ thống chứa dữ liệu khách hàng hoặc dịch vụ công cộng cần được kiểm định chuyên nghiệp, chứ không chỉ dừng lại ở mức bản mẫu hoạt động tốt.
Nhân sự ban đầu như vậy là đủ:
- Claude lo phần tổng hợp đặc tả
- Codex thực thi một tác vụ
- Kiểm chứng kết quả trả về bằng một góc nhìn khác
Hãy lưu lại các câu lệnh hữu ích và phương pháp kiểm chứng để không phải giải thích lại từ đầu khi làm ứng dụng tiếp theo.
Cảm ơn bạn đã đọc.
LINE Open Chat "Chiến lược tốc độ AI của Niku" đang phát miễn phí bộ tài liệu 8 món.
- Hướng dẫn nhập môn Codex/Claude Code
- Chỉ dẫn copy-paste
- Bảng tra cứu nhanh
- 50 mini app
- 50 prompt tạo ảnh
- Hướng dẫn cài đặt yomiyasu
- Công cụ tạo tiêu đề
- Quy trình/mức doanh thu kiếm tiền trên X
Nhận tại đây 👇 https://x.gd/VtPmw





