Cập nhật nguồn

Ngày kiểm tra nguồn chính thức: 2026-05-27. Các nhà cung cấp model, gateway, tool chuyển cấu hình và chính sách billing thay đổi thường xuyên. Trước khi dùng thật, hãy đối chiếu lại tài liệu chính thức của provider.

Codex có thể dùng OpenAI trực tiếp hoặc kết nối qua một provider/gateway khác tùy bề mặt sử dụng và cấu hình. Chương này tập trung vào cách nghĩ, không khuyến nghị một dịch vụ cụ thể.

Chọn phương án nào

| Phương án | Phù hợp | Ưu điểm | Rủi ro |
|

Khi dùng

• Chia câu hỏi theo PICO.
• Tạo bảng trích xuất chứng cứ.
• Tóm tắt paper đã có.
• Ghi giới hạn nghiên cứu.
• Chuẩn bị bản nháp literature review.

Cấu trúc thư mục

review/
  papers/
  extraction-table.md
  protocol.md
  notes/

Bước 1: Chia câu hỏi PICO

# Research question

- Population:
- Intervention:
- Comparator:
- Outcome:

Prompt:

Từ câu hỏi nghiên cứu này, hãy đề xuất PICO và từ khóa tìm kiếm.
Không kết luận hiệu quả điều trị.

Bước 2: Lập bảng chứng cứ

| Paper | Population | Intervention | Comparator | Outcome | Limitation | Note |
|

Cập nhật nguồn

Ngày kiểm tra nguồn chính thức: 2026-05-27. Chương này tham khảo bài OpenAI Work with Codex from anywhere. Điểm vào, khu vực hỗ trợ và tên UI có thể thay đổi theo phiên bản ChatGPT mobile App và Codex desktop App.

“Codex trên điện thoại” ở đây là điểm vào Codex trong ChatGPT mobile App. Nó không phải một ứng dụng Codex riêng và cũng không biến điện thoại thành chuột/bàn phím từ xa.

Bạn có thể hiểu như sau: Codex vẫn chạy trên desktop App, devbox hoặc môi trường đã được ủy quyền; điện thoại dùng để xem tiến độ, trả lời câu hỏi, phê duyệt và điều chỉnh tác vụ khi bạn rời máy.

Hãy cập nhật ChatGPT App lên bản mới nhất, rồi kết nối với Codex trên máy tính.

Sau khi kết nối, mở Codex trong ChatGPT mobile App để tiếp tục cùng thread, theo dõi trạng thái và phản hồi khi tác vụ cần xác nhận.

Có thể làm gì

Sau khi kết nối, mobile App có thể:

• Xem thread và trạng thái tác vụ.
• Đọc output, log terminal, screenshot, diff và kết quả test.
• Trả lời câu hỏi làm rõ của Codex.
• Phê duyệt hoặc từ chối lệnh, mạng và quyền cần xác nhận.
• Đổi hướng tác vụ hoặc bổ sung ngữ cảnh.
• Tạo tác vụ mới trên môi trường đã kết nối.

Nơi thực thi vẫn là desktop App hoặc môi trường remote. File, dependency, bí mật và quyền không chuyển sang điện thoại.

Điều kiện dùng

• Điện thoại đã cài và cập nhật ChatGPT App.
• Máy tính đã cài và cập nhật Codex desktop App.
• Cùng đăng nhập một tài khoản ChatGPT / OpenAI.
• Tài khoản, khu vực và gói đăng ký hỗ trợ Codex.
• Desktop App hoặc môi trường remote đang có project phù hợp.
• Bạn vẫn hiểu quyền khi tác vụ ghi file, chạy lệnh hoặc truy cập mạng.

Khi nào nên dùng

• Theo dõi tác vụ dài khi rời bàn làm việc.
• Chọn hướng xử lý khi Codex đưa ra vài phương án.
• Phê duyệt lệnh an toàn để tác vụ không bị kẹt.
• Yêu cầu Codex tóm tắt code, issue, tài liệu hoặc bối cảnh trước cuộc họp.
• Ghi nhanh một ý tưởng để Codex bắt đầu khám phá, sau đó quay lại máy để review diff.

Khi nào không nên dùng

Đừng dùng mobile để thay thế final review trên máy tính cho các việc:

• Merge code lớn.
• Thao tác production, secret, billing hoặc deploy.
• Review diff dài.
• Debug cần IDE, terminal hoặc GUI local.

Nếu phê duyệt lệnh trên điện thoại, chỉ duyệt lệnh bạn hiểu. Gặp xóa, ghi đè, deploy, gửi dữ liệu nhạy cảm hoặc đổi quyền, hãy dừng và kiểm tra trên máy tính.

Một workflow điển hình

1. Mở Codex desktop App và vào project.
2. Giao một task dài như debug test fail hoặc chỉnh tài liệu.
3. Rời máy, mở Codex trong ChatGPT mobile App.
4. Mở cùng thread đang chạy.
5. Đọc output, log, screenshot, test hoặc diff.
6. Khi Codex cần xác nhận, trả lời hoặc phê duyệt trên điện thoại.
7. Quay lại máy tính để review diff, chạy kiểm chứng và commit.

Khác gì Codex Cloud

| Tiêu chí | Mobile kết nối desktop | Codex Cloud |
|

Cập nhật nguồn

Ngày kiểm tra nguồn chính thức: 2026-05-27. Link tải và cách cài đặt phải ưu tiên OpenAI Codex product page và chatgpt.com/codex/cloud. Khả dụng có thể khác theo khu vực, hệ điều hành và gói tài khoản.

Trong tài liệu này, Codex desktop App là client chạy trên máy tính, không phải mobile App. Sau khi cài, bạn có thể mở dự án local, giao tác vụ, dùng Skills và Automations.

Tải App

Mở chatgpt.com/codex/cloud. Trang sẽ hiển thị nút tải tương ứng với hệ điều hành.

Trên macOS, chọn “Download for macOS” để tải file .dmg. Trên Windows, tải installer Windows, chạy file cài đặt và làm theo hướng dẫn. Nếu bạn làm việc chủ yếu trong terminal hoặc IDE, có thể bắt đầu với CLI hoặc extension rồi quay lại desktop App khi cần workflow nhiều tác vụ.

Cài trên macOS

1. Mở file .dmg đã tải.
2. Kéo biểu tượng Codex vào thư mục Applications.
3. Nếu macOS cảnh báo không xác minh được developer, vào System Settings -> Privacy & Security rồi chọn mở ứng dụng.

Đăng nhập

Mở App và đăng nhập bằng tài khoản ChatGPT / OpenAI.

Kiểm tra sau cài đặt

Sau khi đăng nhập, sidebar nên có các mục như Projects và Chats, đồng thời phần tài khoản hiển thị đúng user. Nếu giao diện tải bình thường và bạn tạo được một project thử nghiệm, cài đặt đã hoàn tất.

Bước tiếp theo: Đăng ký ChatGPT Plus / Pro

Cập nhật nguồn

Ngày kiểm tra nguồn chính thức: 2026-05-27. Giá và quyền lợi phải đối chiếu lại trên ChatGPT pricing và bài Help Center Using Codex with your ChatGPT plan.

Vì sao cần đăng ký

Tài khoản miễn phí có thể dùng ChatGPT cơ bản, nhưng Codex desktop App, Cloud task, nhiều agent song song và quota ổn định thường cần gói trả phí.

| Gói | Giá tham khảo | Codex |
|

Cập nhật nguồn

Ngày kiểm tra nguồn chính thức: 2026-05-27. Chương này tham khảo Codex App docs, Settings và Agent approvals and security. Tên mục trong UI có thể thay đổi theo phiên bản App.

Chat và Project

Khi mở Codex desktop App, bạn sẽ thấy hai kiểu làm việc chính: Chat và Project.

Chat phù hợp với hỏi đáp, phân tích ngắn hoặc tác vụ một lần. Mỗi chat độc lập và thường không gắn với một thư mục làm việc cố định.

Project phù hợp khi Codex cần đọc hoặc sửa file local: code, tài liệu, slide, báo cáo hoặc script. Các hội thoại trong cùng project chia sẻ một workspace.

Trong Project, thay đổi của Codex có thể được ghi trực tiếp vào thư mục local đã cấp quyền.

Ô nhập tác vụ

Ô nhập của Codex giống ChatGPT nhưng có thêm ngữ cảnh và quyền:

1. Thêm file, ảnh chụp hoặc tài liệu tham khảo.
2. Chọn model.
3. Chọn mức quyền của tác vụ.
4. Chọn thư mục làm việc.

Hãy coi mỗi tác vụ như một ticket nhỏ: nói mục tiêu, phạm vi, điều không được làm, cách kiểm chứng và định dạng bàn giao.

Cài đặt

Bấm avatar hoặc biểu tượng settings ở góc dưới để mở cài đặt.

Người mới không cần bật mọi thứ. Chỉ cần thiết lập đủ để chạy tác vụ đầu tiên: mode phù hợp, workspace đúng và quyền tối thiểu.

Bốn kiểm tra đầu tiên

1. Chọn đúng mode: code, web, script và repo nên dùng mode lập trình; viết tài liệu hoặc phân tích nhẹ có thể dùng mode thường ngày.
2. Không mở quyền tối đa ngay: bắt đầu bằng quyền đọc/ghi trong workspace, yêu cầu mạng hoặc lệnh nguy hiểm thì phê duyệt riêng.
3. Dùng thư mục thử nghiệm: đừng đưa repo quan trọng cho tác vụ đầu tiên.
4. Theo dõi quota và lỗi: nếu tác vụ chậm, bị giới hạn hoặc thường dừng, kiểm tra usage và gói tài khoản.

Các nhóm cài đặt quan trọng

| Nhóm | Dùng để làm gì | Khuyến nghị ban đầu |
|

Mục tiêu

Sau chương này, bạn nên chạy được một tác vụ ít rủi ro từ đầu đến cuối: chọn workspace, giao việc, xem Codex thực thi, kiểm tra file và ghi lại kết quả.

Bước 1: Tạo thư mục làm việc

Hãy dùng một thư mục thử nghiệm, ví dụ:

codex-first-task/

Trong đó tạo một file đơn giản:

# Ghi chú thử nghiệm

Tôi muốn dùng Codex để biến ghi chú này thành một checklist rõ ràng hơn.

Không dùng repo sản xuất hoặc thư mục chứa dữ liệu nhạy cảm cho lần đầu.

Bước 2: Chọn Chat hay Project

• Nếu chỉ hỏi đáp, dùng Chat.
• Nếu cần Codex đọc/sửa file, dùng Project.

Với tác vụ đầu tiên, nên dùng Project để hiểu vòng lặp file local.

Bước 3: Thêm thư mục làm việc

Trong Codex desktop App, chọn hoặc tạo Project rồi trỏ tới thư mục thử nghiệm. Kiểm tra lại đường dẫn trước khi gửi yêu cầu.

Bước 4: Giao tác vụ

Prompt mẫu:

Trong thư mục hiện tại, hãy đọc file ghi chú Markdown và chuyển nó thành một checklist rõ ràng.
Chỉ sửa file đó, không tạo file mới. Sau khi sửa, hãy tóm tắt thay đổi và nêu cách tôi tự kiểm tra.

Prompt này có đủ:

• Mục tiêu: chuyển ghi chú thành checklist.
• Phạm vi: chỉ một file.
• Ràng buộc: không tạo file mới.
• Bàn giao: tóm tắt và cách kiểm tra.

Bước 5: Quan sát và kiểm tra

Khi Codex chạy, hãy theo dõi:

• Nó có đọc đúng thư mục không.
• Nó có xin quyền ngoài phạm vi không.
• Nó có sửa đúng file không.
• Kết quả có đúng ý định không.

Nếu bạn đang trong Git repo, chạy:

git status
git diff

Nếu không dùng Git, mở file trực tiếp và kiểm tra nội dung.

Bước 6: Lặp lại nhỏ

Nếu kết quả chưa vừa ý, đừng yêu cầu “làm lại toàn bộ”. Hãy sửa bằng một prompt nhỏ:

Checklist này hơi dài. Hãy rút gọn còn tối đa 6 mục, giữ giọng văn rõ ràng và thực dụng.

Một tác vụ tốt thường là chuỗi thay đổi nhỏ, có kiểm tra sau mỗi bước.

Chuẩn hoàn thành

Bạn đã xong bài đầu tiên khi:

• Codex chỉ làm trong thư mục đã chọn.
• Bạn hiểu file nào bị sửa.
• Bạn tự kiểm tra được kết quả.
• Bạn biết cách yêu cầu chỉnh tiếp mà không mở rộng phạm vi quá mức.

Bước tiếp theo: Cơ chế thực thi tuần tự và song song

1. Thực thi tuần tự

Với một tác vụ thông thường, Codex thường đi theo thứ tự:

1. Đọc cấu trúc repo hoặc file liên quan.
2. Xác định điểm cần sửa.
3. Chạy lệnh kiểm tra nếu cần.
4. Sửa file.
5. Chạy test, build hoặc kiểm chứng.
6. Tóm tắt file đã đổi, kết quả kiểm chứng và rủi ro còn lại.

Prompt tốt:

Hãy đọc repo trước, tìm nguyên nhân test đang fail, chỉ sửa phần cần thiết.
Sau khi sửa hãy chạy test liên quan và tóm tắt diff.

Prompt yếu:

Sửa hết lỗi giúp tôi.

Tác vụ càng mơ hồ, Codex càng phải đoán. Khi đoán nhiều, phạm vi sửa dễ phình ra.

2. Khi nào nên song song

Song song phù hợp khi các phần việc độc lập:

• Đọc nhiều tài liệu nguồn khác nhau rồi tổng hợp.
• Kiểm tra nhiều module không phụ thuộc nhau.
• Chạy nhiều hướng debug riêng biệt.
• Làm nhiều task trên worktree/branch tách biệt.

Không nên song song khi bước sau phụ thuộc kết quả bước trước, hoặc khi nhiều tác vụ cùng sửa một file.

3. Cách giao việc song song an toàn

Hãy chia task theo đầu ra:

Hãy chia tác vụ thành ba nhánh độc lập:
1. kiểm tra lỗi build frontend,
2. kiểm tra lỗi test backend,
3. rà soát tài liệu deploy.
Mỗi nhánh chỉ đọc/sửa file trong phạm vi liên quan và báo kết quả riêng.

Nếu dùng Git, yêu cầu mỗi nhánh làm trên worktree hoặc branch riêng. Sau khi xong, bạn review từng diff trước khi hợp nhất.

4. Luôn yêu cầu kiểm chứng

Tác vụ chưa hoàn thành nếu chưa có bằng chứng kiểm chứng. Bằng chứng có thể là:

• pnpm test, npm test, pytest, cargo test.
• pnpm build hoặc build production.
• Screenshot UI.
• Log trước/sau.
• Link PR hoặc diff.
• Checklist tự kiểm tra.

Khi test không chạy được, Codex phải nói rõ lý do và phần nào chưa kiểm chứng.

5. Mẫu prompt thực dụng

Mục tiêu: sửa lỗi [mô tả lỗi].
Phạm vi: chỉ sửa trong [thư mục/file].
Không làm: không đổi API public, không format toàn repo, không cập nhật dependency nếu chưa cần.
Kiểm chứng: chạy [lệnh test/build].
Bàn giao: liệt kê file sửa, kết quả lệnh, rủi ro còn lại.

Bước tiếp theo: Quản lý quyền

Ba chế độ thường gặp

| Chế độ | Khi dùng | Ghi chú |
|

Skill là gì

Skill là một bộ hướng dẫn cục bộ cho một loại tác vụ. Nó thường mô tả:

• Khi nào được kích hoạt.
• Những bước cần làm.
• File mẫu, script hoặc asset đi kèm.
• Quy tắc kiểm chứng và đầu ra.

Ví dụ Skill tốt: “khi tạo slide deck, dùng template này, render ảnh preview, kiểm tra lỗi chữ tràn và xuất .pptx”.

Plugin là gì

Plugin là gói năng lực lớn hơn, có thể gồm Skills, MCP server, app hoặc connector. Plugin phù hợp khi bạn cần cả hướng dẫn lẫn công cụ gọi ra ngoài.

Ví dụ:

• GitHub plugin để đọc PR, CI và issue.
• Documents plugin để tạo/sửa file Word.
• Spreadsheets plugin để xử lý workbook.
• Cloudflare plugin để làm Workers, D1, R2 hoặc Agents.

MCP nằm ở đâu

MCP là cách Codex kết nối công cụ ngoài như browser, Figma, Notion, database hoặc hệ thống nội bộ. Nếu Skill là “quy trình”, MCP là “cánh tay” để gọi công cụ.

Một workflow mạnh thường kết hợp:

Skill hướng dẫn cách làm
+ MCP cung cấp tool/API
+ AGENTS.md cung cấp quy tắc của repo
+ test/build để kiểm chứng

Khi nào nên tạo Skill

Nên tạo Skill khi:

• Bạn lặp lại cùng một tác vụ nhiều lần.
• Tác vụ có quy tắc kiểm chứng rõ.
• Có template, script hoặc checklist cố định.
• Muốn đội nhóm làm cùng một chuẩn.

Chưa nên tạo Skill khi quy trình còn mơ hồ, mỗi lần làm một kiểu hoặc chưa có cách kiểm chứng.

Lưu ý khi dùng

• Chỉ bật plugin/skill cần thiết cho tác vụ.
• Không đưa secret vào Skill.
• Skill nên ngắn, có tiêu chí kích hoạt rõ.
• Nếu workflow đòi hỏi công cụ ngoài, ghi rõ quyền và rủi ro.
• Sau mỗi lần chạy thành công, cập nhật Skill bằng bài học thực tế.

Bước tiếp theo: Tự động hóa

Có thể hiểu automation thế nào

Một automation tốt có bốn phần:

1. Khi nào chạy.
2. Cần kiểm tra nguồn nào.
3. Điều kiện nào được xem là bất thường.
4. Kết quả cần báo theo định dạng nào.

Ví dụ:

Mỗi sáng thứ Hai, kiểm tra các issue gắn label bug trong repo này,
tóm tắt issue mới, issue quá 7 ngày chưa cập nhật và đề xuất người phụ trách.

Trường hợp phù hợp

• Nhắc review PR quá hạn.
• Kiểm tra link tài liệu định kỳ.
• Tóm tắt issue hoặc changelog hằng tuần.
• Theo dõi CI hoặc release note.
• Nhắc gia hạn chứng chỉ, dependency hoặc tài liệu cần cập nhật.

Trường hợp không nên tự động hóa

• Deploy production.
• Xóa dữ liệu.
• Chuyển tiền, thanh toán, đổi billing.
• Gửi email/tin nhắn hàng loạt mà chưa duyệt nội dung.
• Thao tác với dữ liệu khách hàng nhạy cảm.

Các việc này có thể dùng Codex để chuẩn bị báo cáo, nhưng bước quyết định nên giữ lại cho người.

Quy trình tạo automation

1. Viết tác vụ bằng ngôn ngữ cụ thể.
2. Chạy thủ công một lần để xem kết quả.
3. Sửa prompt đến khi output ổn định.
4. Thêm lịch hoặc điều kiện kích hoạt.
5. Ghi rõ cách dừng, sửa hoặc xoá automation.

Checklist trước khi bật

• Nguồn dữ liệu có ổn định không?
• Tác vụ có cần quyền mạng, repo hoặc tài khoản không?
• Output có quá dài hoặc thiếu cấu trúc không?
• Có thể gây spam thông báo không?
• Có cần approval trước khi hành động không?

Bước tiếp theo: Hình đại diện desktop

Khi nào nên dùng

• Bạn muốn nhận biết trạng thái tác vụ dễ hơn.
• Bạn thường ghi hình hoặc chụp ảnh màn hình hướng dẫn.
• Bạn muốn workspace có dấu hiệu thị giác riêng.

Cài đặt

Tùy phiên bản App, mục này có thể nằm trong phần appearance, personalization hoặc desktop companion. Nếu không thấy, hãy kiểm tra bản cập nhật hoặc tài liệu chính thức hiện tại.

Chuẩn bị asset

Nên dùng ảnh:

• Nền trong suốt nếu App hỗ trợ.
• Tương phản tốt trên nền sáng và tối.
• Không chứa thông tin cá nhân.
• Kích thước vừa phải để không che UI quan trọng.

Lưu ý

Đừng để yếu tố cá nhân hóa làm bạn bỏ qua phần quan trọng hơn: quyền, workspace, diff và kiểm chứng. Với tác vụ đội nhóm hoặc quay video training, nên dùng hình trung tính để tránh lộ thông tin cá nhân.

Bước tiếp theo: Cài đặt và đăng nhập CLI

Cài extension

Mở VS Code Marketplace và tìm extension Codex/OpenAI chính thức hiện có. Vì tên và vị trí mở có thể thay đổi, hãy ưu tiên link từ tài liệu OpenAI hoặc repo chính thức.

Mở cửa sổ Codex

Sau khi cài, đăng nhập cùng tài khoản ChatGPT / OpenAI. Mở panel hoặc command palette của extension.

Cách dùng hiệu quả

Tác vụ trong IDE nên bám sát ngữ cảnh đang mở:

Giải thích hàm đang chọn, chỉ ra rủi ro edge case và đề xuất test cần bổ sung.

Hãy sửa vùng chọn để xử lý input rỗng.
Không đổi public API. Sau đó nêu test nên chạy.

Tác vụ phù hợp trong IDE

• Giải thích đoạn code.
• Sửa một hàm hoặc component nhỏ.
• Tạo test cho vùng chọn.
• Review diff cục bộ.
• Viết comment hoặc docs sát code.

Khi nào dùng App hoặc CLI thay vì IDE

| Nhu cầu | Điểm vào phù hợp |
|

Khi nào dùng

• Debug CI hoặc test fail trong repo GitHub.
• Làm tác vụ dài không phụ thuộc file local chưa commit.
• Tạo PR cho thay đổi nhỏ đến vừa.
• Chạy nhiều nhánh phân tích song song.
• Giao việc từ ChatGPT mà không mở IDE.

Cách dùng cơ bản

Bước 1: Mở Codex Cloud

Vào điểm vào Codex trong ChatGPT hoặc URL cloud hiện tại của Codex.

Bước 2: Kết nối repo

Ủy quyền GitHub hoặc provider được hỗ trợ, chọn repo và branch. Kiểm tra kỹ quyền truy cập của tổ chức.

Bước 3: Giao tác vụ

Prompt nên có:

• Mục tiêu.
• Branch hoặc phạm vi file.
• Điều không được làm.
• Lệnh test/build.
• Yêu cầu tạo PR hay chỉ báo cáo.

Ví dụ:

Trong repo này, hãy sửa lỗi CI ở workflow test.
Không đổi dependency nếu chưa cần. Sau khi sửa, chạy test liên quan
và mở draft PR với mô tả thay đổi.

Khác desktop App thế nào

| Tiêu chí | Desktop App | Cloud |
|

Khi dùng

• Kiểm tra UI web.
• Thu thập thông tin từ trang đã đăng nhập.
• Test flow form nội bộ.
• Tự động hóa thao tác không có API.

Một workflow thường gặp

1. Mở trang test hoặc localhost.
2. Yêu cầu Codex mô tả cấu trúc trang.
3. Cho phép click/nhập trong phạm vi rõ.
4. Chụp screenshot.
5. Báo lỗi và bước tái hiện.

Prompt mẫu

Hãy mở trang dashboard staging, kiểm tra filter ngày.
Không xóa dữ liệu, không submit form production.
Chụp screenshot trước/sau và báo lỗi UI nếu có.

Kiểm tra trọng tâm

• Trang có đúng account/environment không.
• Codex có click đúng element không.
• Có gửi dữ liệu ra ngoài không.
• Screenshot có đủ bằng chứng không.
• Có thao tác nào cần rollback không.

Rủi ro

Trình duyệt chứa session thật. Không để Codex tự xác nhận thanh toán, đổi quyền, gửi email, xóa dữ liệu hoặc đăng nội dung khi chưa duyệt từng bước.

Repo và công cụ mã nguồn mở

• openai/codex
• Playwright MCP và các server MCP liên quan.
• Draw.io, Figma, Notion, Obsidian, HyperFrames và các công cụ trong từng case.

Tài liệu OpenAI

• OpenAI Codex
• Codex developer docs
• Codex Help Center

Về site này

Tài liệu này là bản việt hóa và tổ chức lại theo hướng thực hành. Khi phát hiện nguồn đã lỗi thời, hãy mở issue hoặc gửi PR kèm link chính thức và ngày kiểm tra.

Khi dùng

• Demo HTML tĩnh.
• Landing page thử nghiệm.
• Báo cáo nội bộ cần link chia sẻ.
• Prototype không cần backend.

Quy trình thủ công

1. Để Codex tạo hoặc sửa site.
2. Chạy build nếu có.
3. Mở file local để kiểm tra.
4. Upload thư mục output.
5. Mở link public và kiểm chứng.

Quy trình tự động qua API

Nếu DKFile hoặc dịch vụ tương tự có API:

Hãy build site, xác định thư mục output và chuẩn bị lệnh upload qua API.
Không gửi request thật cho đến khi tôi xác nhận.

Kiểm chứng

• Link public mở được.
• Asset không 404.
• Layout desktop/mobile ổn.
• Không upload secret hoặc file source không cần thiết.

Rủi ro

Public link có thể truy cập bởi người khác. Không upload tài liệu nội bộ, key, file .env, dữ liệu khách hàng hoặc bản nháp chưa được duyệt.

Cài đặt

Cài MCP server Draw.io theo tài liệu của tool bạn dùng, sau đó khai báo vào cấu hình Codex/MCP. Kiểm tra server hoạt động bằng một tác vụ nhỏ trước khi dùng trong dự án thật.

Prompt mẫu

Hãy đọc mô tả hệ thống dưới đây và tạo sơ đồ kiến trúc Draw.io.
Nhóm thành các lớp: Client, API, Worker, Database, External services.
Kết quả cần là file có thể chỉnh sửa, không chỉ ảnh.

Kiểm chứng

• Node chính có đủ không.
• Mũi tên có đúng chiều dữ liệu không.
• Nhãn có ngắn và rõ không.
• File mở được trong Draw.io không.
• Có thể chỉnh sửa từng node không.

Lưu ý

Sơ đồ kiến trúc thường lộ thông tin hệ thống. Không đưa secret, endpoint nội bộ nhạy cảm hoặc dữ liệu khách hàng vào prompt nếu chưa được phép.

Chuẩn bị

• CLI/tool Feishu đã đăng nhập.
• Quyền app phù hợp.
• Biết rõ tài liệu/base/chat nào được phép đọc hoặc ghi.
• Không đưa token vào prompt.

Prompt mẫu

Hãy đọc bảng Feishu [tên/link] và tạo báo cáo gồm:
tổng số task, task quá hạn, người phụ trách và đề xuất ưu tiên.
Chỉ đọc dữ liệu, không sửa bảng.

Tác vụ phù hợp

• Tóm tắt meeting notes.
• Tạo báo cáo base.
• Chuẩn hóa tài liệu.
• Tìm task quá hạn.
• Chuẩn bị agenda.

Rủi ro

Dữ liệu Feishu thường là dữ liệu tổ chức. Trước khi cho phép ghi, gửi tin nhắn hoặc mời người, hãy yêu cầu Codex mô tả hành động và chờ duyệt.

Cài đặt

Kết nối MCP theo hướng dẫn của tool. Chỉ cấp quyền file Figma cần thiết và tránh mở toàn bộ workspace nếu không cần.

Prompt mẫu

Hãy đọc frame Figma này và tóm tắt layout, component chính,
token màu, spacing và các breakpoint cần chú ý khi triển khai React.
Chưa viết code.

Tác vụ phù hợp

• Tạo implementation plan.
• So sánh UI hiện tại với design.
• Trích design token.
• Viết checklist QA frontend.
• Tạo component skeleton.

Rủi ro

Thiết kế có thể chứa thông tin sản phẩm chưa công bố. Kiểm soát quyền file, không chụp hoặc xuất asset nhạy cảm nếu chưa được phép.

Quy trình truyền thống

1. Mở GitHub Actions.
2. Tìm job fail.
3. Đọc log dài.
4. Tái hiện local.
5. Sửa code/config.
6. Push và chờ CI chạy lại.

Codex có thể hỗ trợ các bước đọc log, khoanh vùng lỗi, sửa và tạo PR.

Prompt mẫu

CI đang fail ở workflow [tên]. Hãy đọc log job fail,
xác định nguyên nhân, sửa nhỏ nhất trong repo và chạy test liên quan.
Sau đó tạo mô tả PR gồm nguyên nhân, thay đổi và kiểm chứng.

Kiểm chứng

• Log lỗi được trích đúng.
• Fix chạm đúng file.
• Test local hoặc command liên quan pass.
• PR mô tả rõ thay đổi.
• Không nâng cấp dependency hoặc đổi workflow ngoài phạm vi nếu chưa cần.

Khi Codex gặp lỗi môi trường

Yêu cầu phân loại:

Hãy phân biệt lỗi do môi trường CI, dependency cache,
test flaky hay regression từ code. Chưa sửa file.

Kết luận

CI fail tốt vì có bằng chứng khách quan. Hãy bắt Codex giữ liên kết giữa log, thay đổi và lệnh kiểm chứng.

Khi dùng

• Intro video cho sản phẩm.
• Motion graphic ngắn.
• Demo UI dạng video.
• Caption, overlay hoặc scene transition.

Quy trình

1. Mô tả mục tiêu video: thời lượng, khung hình, style, nội dung.
2. Để Codex tạo composition.
3. Preview trong browser.
4. Render video hoặc ảnh kiểm tra.
5. Sửa layout, timing và text overflow.

Prompt mẫu

Hãy tạo một video 15 giây giới thiệu tính năng [x].
Tỉ lệ 16:9, style hiện đại, có 3 scene, text tiếng Việt ngắn.
Sau khi tạo, chạy preview/render nếu tool hỗ trợ và báo output.

Kiểm chứng

• Canvas/scene không blank.
• Text không tràn hoặc chồng lên nhau.
• Animation đúng timing.
• Asset render được.
• File output phát được.

Cấu trúc đề xuất

wiki/
  raw/
  notes/
  index/
  assets/
  sources.md

Quy trình

1. Lưu nguồn gốc vào raw/.
2. Ghi metadata và link nguồn.
3. Yêu cầu Codex tóm tắt và trích ý chính vào notes/.
4. Tạo index theo chủ đề.
5. Định kỳ yêu cầu Codex tìm note trùng, link chết hoặc nguồn thiếu.

Prompt mẫu

Hãy đọc các file mới trong raw/, tạo ghi chú tiếng Việt trong notes/.
Mỗi ghi chú cần có summary, key ideas, source link và câu hỏi mở.
Không xóa file gốc.

Kiểm chứng

• Mỗi note có link nguồn.
• Không bịa citation.
• Tag nhất quán.
• Index cập nhật.
• File gốc còn nguyên.

Cài đặt

Tạo integration hoặc kết nối MCP theo tài liệu tool. Chỉ share những page/database cần thiết cho integration.

Prompt mẫu

Hãy đọc database roadmap trong Notion và tạo báo cáo:
tính năng đang làm, blocker, owner và mục quá hạn.
Chỉ đọc, không sửa database.

Tác vụ phù hợp

• Tóm tắt meeting notes.
• Tạo weekly report.
• Gom action items.
• Chuẩn hóa page template.
• Tạo brief từ knowledge base.

Khi cần ghi

Nếu muốn Codex tạo hoặc sửa page, yêu cầu nó mô tả trước thay đổi dự kiến. Với database quan trọng, dùng bản nháp hoặc page test trước.

Cài đặt

Nếu muốn dùng terminal trong Obsidian, cài plugin terminal phù hợp. Bạn cũng có thể mở vault bằng Codex desktop App hoặc CLI như một thư mục bình thường.

Prompt mẫu

Trong vault Obsidian này, hãy đọc thư mục notes/raw và tạo index theo chủ đề.
Không xóa ghi chú gốc. Mỗi mục index phải link về file nguồn.

Tác vụ phù hợp

• Tạo MOC/index.
• Chuẩn hóa tag/frontmatter.
• Tóm tắt bài viết đã lưu.
• Tạo checklist học tập.
• Quản lý ảnh minh họa trong thư mục asset.

Rủi ro

Knowledge base có thể chứa nhật ký, khách hàng hoặc dữ liệu cá nhân. Hãy giới hạn thư mục và yêu cầu Codex không đọc phần riêng tư.

Cài đặt

Cài Playwright MCP theo tài liệu hiện tại và khai báo tool cho Codex. Với dự án frontend, ưu tiên chạy trên localhost trước khi dùng trang production.

Prompt mẫu

Hãy mở trang http://localhost:3000, kiểm tra flow đăng nhập giả lập.
Chụp screenshot ở desktop và mobile. Không gửi form tới dịch vụ thật.
Báo lỗi UI, console error và bước tái hiện.

Kiểm chứng

• Trang có load không.
• Screenshot có đúng viewport không.
• Console có lỗi không.
• Click có tạo trạng thái mong muốn không.
• Codex có tránh thao tác production nguy hiểm không.

Rủi ro

Trình duyệt có thể chứa login state. Không để Codex thao tác thanh toán, xóa dữ liệu, gửi form nhạy cảm hoặc đổi quyền trên site thật nếu chưa xác nhận rõ.

Khi dùng

• Tạo deck nội bộ nhanh.
• Chuyển outline thành slide.
• Sinh bản nháp cho workshop, training hoặc báo cáo.
• Chuẩn hóa template slide trong đội.

Chuẩn bị

• Skill hoặc plugin tạo presentation.
• Nội dung đầu vào: chủ đề, đối tượng nghe, số slide, giọng văn.
• Thư mục output.
• Cách render hoặc kiểm tra preview.

Prompt mẫu

Hãy tạo một slide deck 8 trang về [chủ đề] cho [đối tượng].
Giọng văn thực dụng, ít chữ, mỗi slide có tiêu đề và 3 ý chính.
Sau khi tạo, hãy render preview nếu tool hỗ trợ và báo file output.

Kiểm chứng

• Slide có đúng số lượng không.
• Tiêu đề và nội dung có khớp mục tiêu không.
• Chữ có tràn khung không.
• Theme có nhất quán không.
• File .pptx hoặc output có mở được không.

Rủi ro

Codex có thể tạo nội dung nghe hợp lý nhưng thiếu nguồn. Với deck có số liệu, pháp lý, y tế hoặc tài chính, phải yêu cầu nguồn và người review.

Bối cảnh mẫu

Ứng dụng chạy trên server hoặc container. Một script Python lỗi khi xử lý dữ liệu. Bạn muốn Codex đọc log, tái hiện và sửa trong repo.

Quy trình

1. Kết nối server bằng phương thức an toàn.
2. Tạo môi trường dev/staging, không sửa production trực tiếp.
3. Thu thập log lỗi.
4. Yêu cầu Codex phân tích chỉ đọc.
5. Cho phép sửa trong repo.
6. Chạy test hoặc command tái hiện.
7. Ghi lại nguyên nhân và cách rollback.

Prompt mẫu

Đây là log lỗi từ server staging. Hãy phân tích nguyên nhân,
tìm file liên quan trong repo, chưa sửa file cho đến khi nêu kế hoạch.
Sau khi tôi duyệt, hãy sửa nhỏ nhất và chạy command tái hiện.

Kiểm chứng

• Lỗi ban đầu tái hiện được.
• Fix chạy qua command tái hiện.
• Log không còn stack trace cũ.
• Không sửa config production.
• Có rollback plan.

Rủi ro

Không để Codex chạy lệnh xóa dữ liệu, restart production, đổi firewall, đổi secret hoặc deploy nếu chưa có người chịu trách nhiệm duyệt.

Ba cách dùng

| Cách | Khi dùng |
|

File nằm ở đâu

Vị trí thường nằm trong thư mục cấu hình người dùng, ví dụ $CODEX_HOME hoặc thư mục tương đương theo hệ điều hành. Không đặt file chứa secret vào repo nếu không cần.

Ví dụ tối thiểu

model = "gpt-5"

[sandbox]
mode = "workspace-write"

[approval]
policy = "on-request"

Đây chỉ là ví dụ cấu trúc. Hãy dùng tên model và khóa cấu hình đúng với phiên bản Codex bạn đang chạy.

Hiểu theo mục đích

| Nhóm | Ý nghĩa |
|

Bốn lớp cấu hình

| Lớp | Vai trò |
|

Ba khái niệm

| Khái niệm | Vai trò |
|

Phân cấp rủi ro

| Mức | Ví dụ | Cách xử lý |
|

App phù hợp với gì

• Người mới muốn giao việc bằng UI.
• Tác vụ cần sửa file local.
• Workflow có ảnh, tài liệu, browser hoặc plugin.
• Nhiều task chạy song song trong cùng dự án.
• Tác vụ phi lập trình như viết tài liệu, slide, knowledge base.

Bản đồ năng lực

| Năng lực | Dùng khi |
|

Trường hợp phù hợp

• Giao task repo đã kết nối.
• Theo dõi tiến độ từ mobile.
• Hỏi Codex giải thích PR, issue hoặc lỗi.
• Gửi yêu cầu ban đầu trước khi quay lại máy tính review.
• Tạo task dài cho Cloud.

Viết task đầu tiên

Hãy đọc repo đã kết nối và tóm tắt cấu trúc, stack,
lệnh test/build và 3 task nhỏ phù hợp để bắt đầu.
Không tạo PR, không sửa file.

Sau đó mới giao sửa:

Hãy sửa lỗi tài liệu trong README.
Chỉ sửa README, không đổi code. Sau khi xong, tạo draft PR.

Người không lập trình có thể dùng gì

• Tóm tắt tài liệu repo.
• Tạo checklist release.
• Viết hướng dẫn onboarding.
• Tóm tắt issue hoặc PR.
• Theo dõi task đang chạy trên desktop/cloud.

Quan hệ với Cloud

Trong nhiều trường hợp, ChatGPT là nơi bạn giao yêu cầu, còn Codex Cloud là nơi thực thi. Hãy kiểm tra task chạy ở môi trường nào trước khi cấp quyền hoặc đưa dữ liệu nhạy cảm.

Nhắc an toàn

Không dán secret, token, cookie, dữ liệu khách hàng hoặc thông tin thanh toán vào hội thoại. Với PR do Codex tạo, vẫn cần review và test trước khi merge.

CLI làm được gì

• Tóm tắt codebase.
• Sửa bug nhỏ.
• Bổ sung test.
• Chạy lệnh build/test/lint.
• Đọc log lỗi.
• Viết tài liệu kỹ thuật.
• Chuẩn bị mô tả PR.

Thứ tự học đề xuất

1. Cài đặt và đăng nhập CLI.
2. Chạy tác vụ chỉ đọc.
3. Chạy một sửa đổi nhỏ.
4. Viết AGENTS.md.
5. Đọc tùy chọn CLI.
6. Tạo profile an toàn trong config.toml.

Chế độ tương tác

Chạy trong repo:

codex

Prompt mẫu:

Chỉ đọc repo này. Hãy tóm tắt stack, thư mục chính,
lệnh test/build và những rủi ro trước khi sửa code.

Chế độ không tương tác

Một số phiên bản CLI hỗ trợ thực thi prompt trực tiếp:

codex exec "Tóm tắt repo hiện tại, không sửa file"

Hãy dùng cho tác vụ rõ đầu ra, ví dụ tạo báo cáo, kiểm tra checklist hoặc tóm tắt log.

Template tác vụ CLI

Sửa test fail

Test [tên test] đang fail. Hãy đọc log, tìm nguyên nhân,
chỉ sửa phần liên quan, chạy lại test đó và báo file đã đổi.

Cập nhật tài liệu

Hãy cập nhật README theo thay đổi trong package.json.
Không đổi code. Sau khi sửa, kiểm tra link và tóm tắt thay đổi.

Review PR local

Hãy xem git diff hiện tại theo góc độ code review.
Ưu tiên bug, regression, thiếu test và rủi ro vận hành.
Không sửa file.

Kết luận thực hành

CLI phù hợp nhất khi bạn có repo local, biết lệnh kiểm chứng và muốn xem diff rõ. Nếu cần UI, browser, automation hoặc nhiều tác vụ cùng lúc, chuyển sang desktop App hoặc Cloud.

Cloud phù hợp với gì

• Sửa lỗi CI trên GitHub.
• Tác vụ dài không cần máy local.
• Tạo draft PR.
• Review hoặc cập nhật tài liệu trong repo.
• Chia nhiều hướng phân tích song song.

Checklist trước khi giao task

• Repo và branch đã đúng chưa?
• Codex có quyền đọc/ghi phù hợp chưa?
• Có cần secret hoặc dependency đặc biệt không?
• Lệnh test/build là gì?
• Đầu ra mong muốn là báo cáo, commit hay PR?

Environments

Cloud environment nên mô tả rõ:

• Dependency cần cài.
• Lệnh setup.
• Biến môi trường không nhạy cảm.
• Test/build.
• Service nền nếu có.

Nếu tác vụ cần secret, dùng cơ chế secret chính thức của nền tảng, không dán vào prompt.

Internet access

Quyền mạng hữu ích để tải dependency hoặc đọc tài liệu, nhưng cũng tạo rủi ro gửi dữ liệu ra ngoài. Với repo nội bộ, hãy giới hạn domain và yêu cầu Codex báo rõ khi cần Internet.

Prompt mẫu

Hãy sửa lỗi CI trong workflow test.
Phạm vi: chỉ file cấu hình CI và test liên quan.
Không nâng cấp dependency nếu chưa cần.
Sau khi sửa, chạy test liên quan và mở draft PR.

Gợi ý cho đội nhóm

• Dùng branch riêng cho task cloud.
• Yêu cầu PR mô tả rõ Codex đã làm gì.
• Không tự merge PR do Codex tạo nếu chưa review.
• Ghi lại case thành playbook nếu task lặp lại.

IDE phù hợp với gì

• Giải thích đoạn code đang chọn.
• Sửa một hàm nhỏ.
• Tạo test cho component hiện tại.
• Gợi ý refactor cục bộ.
• Review diff nhỏ trước khi commit.

Cách viết tác vụ theo vùng chọn

Hãy giải thích vùng code đang chọn, nêu input/output,
edge case và test còn thiếu. Không sửa file.

Hãy sửa vùng chọn để xử lý trường hợp input rỗng.
Không đổi chữ ký hàm. Sau đó nêu test nên chạy.

Tác vụ tần suất cao

• “Tóm tắt file này trong 5 gạch đầu dòng.”
• “Tìm bug tiềm ẩn trong hàm đang chọn.”
• “Viết test cho nhánh lỗi.”
• “Đổi tên biến trong phạm vi nhỏ.”
• “Viết JSDoc/docstring cho API này.”

Phối hợp với CLI

Dùng IDE cho chỉnh sửa sát code, dùng CLI để chạy lệnh và kiểm tra toàn repo. Sau khi Codex sửa trong IDE, vẫn nên chạy test ở terminal.

Lưu ý

Đừng để IDE context quá hẹp khiến Codex bỏ qua tác động liên file. Nếu sửa có thể ảnh hưởng nhiều module, chuyển sang CLI hoặc App để Codex đọc repo rộng hơn.

Bảng đối chiếu

| Điểm vào | Phù hợp | Không phù hợp |
|

Bản đồ phương pháp

• Thiết kế tác vụ: viết mục tiêu, phạm vi, ràng buộc và đầu ra.
• Workflow phi lập trình: dùng Codex cho tài liệu, nghiên cứu, nội dung và vận hành.
• Team playbook: đưa Codex vào nhóm với rule, template và review.

Ba nguyên tắc

1. Bắt đầu nhỏ.
2. Luôn có cách kiểm chứng.
3. Biến tác vụ thành tri thức tái sử dụng.

Template vòng lặp tối thiểu

Mục tiêu:
Phạm vi:
Không làm:
Nguồn/ngữ cảnh:
Kiểm chứng:
Bàn giao:

Tài liệu

Ví dụ:

Hãy đọc các file trong docs/onboarding và tạo một checklist onboarding cho nhân viên mới.
Giữ link gốc, không bịa chính sách, và đánh dấu mục nào cần người phụ trách xác nhận.

Phù hợp cho README, FAQ, SOP, migration note, release note và tài liệu nội bộ.

Học tập và nghiên cứu

Codex có thể:

• Tóm tắt repo lạ.
• Tạo glossary.
• Chia lộ trình học theo chương.
• Lập bảng so sánh nguồn.
• Tạo câu hỏi tự kiểm tra.

Luôn yêu cầu nguồn và phần chưa chắc nếu nội dung có tính sự kiện.

Product và vận hành

Ví dụ:

Từ các issue đang mở, hãy nhóm vấn đề theo chủ đề,
nêu mức độ ảnh hưởng và đề xuất thứ tự xử lý.
Không đóng issue hoặc gắn label.

Knowledge management

Codex hữu ích khi cần dọn thư mục ghi chú, chuẩn hóa frontmatter, tạo index, phát hiện link chết hoặc biến ghi chú thành bài viết.

Ranh giới quan trọng: không để Codex tự công bố, gửi email hoặc sửa tài liệu chính sách nhạy cảm khi chưa có người review.

Sáu yếu tố

| Yếu tố | Câu hỏi |
|

Checklist triển khai

• Có AGENTS.md ở repo chính.
• Có PR template ghi rõ Codex tham gia phần nào.
• Có lệnh test/build chuẩn.
• Có quy tắc secret và production.
• Có người review diff trước merge.
• Có nơi lưu case thành công/thất bại.

Dàn ý AGENTS.md đội nhóm

# AGENTS.md

## Tổng quan dự án
## Lệnh thường dùng
## Ranh giới thư mục
## Quy chuẩn code
## Yêu cầu test
## Ranh giới bảo mật
## Yêu cầu bàn giao PR

Template PR

## Bối cảnh

## Thay đổi

## Phần Codex tham gia

## Kiểm chứng

## Rủi ro

## Screenshot hoặc log

Câu hỏi retro

• Prompt ban đầu đã rõ chưa?
• Codex thiếu ngữ cảnh nào?
• Lệnh kiểm chứng có đủ không?
• Có thay đổi ngoài phạm vi không?
• Có nên cập nhật AGENTS.md hoặc Skill không?

Cách rollout

1. Bắt đầu với tài liệu hoặc test nhỏ.
2. Chọn một repo ít rủi ro.
3. Ghi lại 5 case đầu tiên.
4. Chuẩn hóa prompt và rule.
5. Mở rộng sang repo quan trọng hơn khi đã có review flow.

Giai đoạn 1: Khung đầy đủ

• Hoàn thiện cấu trúc guide, platform, configuration, practice, recipes và reference.
• Dịch giao diện site sang tiếng Việt.
• Đảm bảo build và link cơ bản hoạt động.

Giai đoạn 2: Hướng dẫn sâu hơn

• Bổ sung ảnh chụp tiếng Việt nếu có.
• Mở rộng từng chương theo workflow thực tế.
• Thêm checklist kiểm chứng cho từng tác vụ.

Giai đoạn 3: Case study dẫn dắt

• Tạo case có repo hoặc file mẫu.
• Ghi prompt, bước chạy, lỗi gặp phải và kết quả.
• Phân loại case theo mức rủi ro và đối tượng.

Giai đoạn 4: Cộng đồng hóa

• Mở issue template cho yêu cầu nội dung.
• Gắn nhãn good first issue.
• Cập nhật nguồn chính thức định kỳ.
• Mời đóng góp bản dịch, hình ảnh và ví dụ Việt Nam.

Cách đóng góp

1. Mở issue mô tả nội dung muốn thêm.
2. Ghi rõ đối tượng hưởng lợi.
3. Đính kèm nguồn chính thức hoặc repo minh họa nếu có.
4. Gửi PR nhỏ, mỗi PR tập trung một trang hoặc một case.

Bức tranh tổng thể

Codex là workflow dạng agent cho kỹ thuật phần mềm và công việc tri thức. Nó có thể xuất hiện ở nhiều nơi:

• CLI: gần terminal và repo local, phù hợp sửa nhanh, chạy lệnh, debug và kiểm chứng.
• Desktop App: phù hợp dự án local, nhiều tác vụ, Skills, Automations, subagents và plugin workflow.
• Web / Cloud / ChatGPT: phù hợp giao tác vụ dài, chạy song song, kết nối repo, tạo PR hoặc hỏi về code.
• IDE: phù hợp giải thích, sửa cục bộ, review và tác vụ bám sát editor.
• Tích hợp: GitHub, Slack, Linear, MCP và các hệ thống nội bộ giúp Codex đi vào chuỗi cộng tác.

Bốn giai đoạn

| Giai đoạn | Mục tiêu | Trang đề xuất | Chuẩn hoàn thành |
|

Cập nhật nguồn

Ngày kiểm tra nguồn chính thức: 2026-05-27. Lệnh cài đặt và yêu cầu phiên bản phải đối chiếu lại với openai/codex và tài liệu OpenAI hiện tại.

Kiểm tra trước khi cài

Kiểm tra Node.js:

node -v

Nếu dùng Windows PowerShell và bị chặn script .ps1, hãy gọi file .cmd:

npm.cmd -v
pnpm.cmd -v

Cài CLI

Tham khảo lệnh chính thức hiện tại của dự án Codex CLI. Nếu cài bằng npm, mẫu thường có dạng:

npm install -g @openai/codex

Sau khi cài, kiểm tra:

codex --version

Đăng nhập

Chạy:

codex

Làm theo hướng dẫn đăng nhập trong terminal hoặc trình duyệt. Nếu môi trường công ty chặn browser login, thử mạng khác hoặc đọc tài liệu CLI về auth token/API key.

Tác vụ chỉ đọc đầu tiên

Trong repo thử nghiệm, chạy:

codex

Prompt:

Chỉ đọc repo hiện tại. Hãy tóm tắt cấu trúc thư mục, stack chính,
lệnh cài đặt, lệnh test và rủi ro cần kiểm tra trước khi sửa code.
Không chỉnh sửa file.

Tác vụ chỉ đọc giúp bạn kiểm tra Codex hiểu repo mà chưa tạo thay đổi.

Khi cài lỗi

Kiểm tra theo thứ tự:

• Node.js có đúng version không.
• npm hoặc package manager có chạy được không.
• PATH có nhận lệnh codex không.
• Proxy/firewall có chặn package registry không.
• Bạn đang dùng PowerShell .ps1 hay .cmd.

Bước tiếp theo: Lần đầu để Codex sửa code

Chọn tác vụ đầu tiên

Tốt:

• Sửa lỗi chính tả trong README.
• Bổ sung một test nhỏ.
• Sửa một failing test đã có log rõ.
• Thêm validation đơn giản.

Không tốt:

• “Tối ưu toàn bộ codebase”.
• “Đổi framework”.
• “Sửa tất cả lỗi bảo mật”.
• “Deploy luôn lên production”.

Bước 1: Chỉ đọc lập bản đồ

Prompt:

Chỉ đọc repo. Hãy xác định stack, cấu trúc thư mục, lệnh test/build,
và đề xuất 3 tác vụ nhỏ phù hợp để Codex xử lý trước.

Bước 2: Giao việc nhỏ

Prompt mẫu:

Hãy sửa lỗi [mô tả] trong [file/module].
Không refactor ngoài phạm vi.
Sau khi sửa, chạy [lệnh test] và báo kết quả.

Bước 3: Quan sát quá trình

Trong lúc Codex chạy, chú ý:

• Nó có đọc đúng file không.
• Nó có chạy lệnh trong đúng thư mục không.
• Nó có xin quyền bất thường không.
• Nó có mở rộng phạm vi sửa không.

Nếu hướng đi sai, dừng và chỉnh prompt. Đừng để nó tiếp tục sửa trên giả định sai.

Bước 4: Kiểm tra diff

Sau khi xong:

git status
git diff

Đọc diff trước khi commit. Nếu có thay đổi ngoài phạm vi, yêu cầu Codex giải thích hoặc tự revert phần không liên quan.

Bước 5: Ghi lại trước commit

Một bàn giao tốt gồm:

• File đã sửa.
• Vì sao sửa.
• Lệnh đã chạy.
• Kết quả lệnh.
• Rủi ro còn lại.

Nếu lần đầu thất bại

Hãy giảm phạm vi:

• Chuyển sang chỉ đọc.
• Chỉ sửa một file.
• Cung cấp log lỗi cụ thể.
• Bỏ yêu cầu “tối ưu” hoặc “clean up”.
• Chạy test thủ công và đưa output cho Codex.

Chuẩn hoàn thành

Bạn hoàn thành bài này khi diff nhỏ, test liên quan chạy được hoặc lý do không chạy được được nêu rõ, và bạn hiểu toàn bộ thay đổi.

Bước tiếp theo: Dùng Codex trong VS Code

Vì sao cần AGENTS.md

Nếu không có rule file, mỗi lần giao việc bạn phải nhắc lại:

• Dùng package manager nào.
• Test/build chạy bằng lệnh nào.
• Thư mục nào không được sửa.
• Style code và format.
• Cách ghi kết quả.

AGENTS.md biến các quy tắc đó thành ngữ cảnh mặc định.

Đặt ở đâu

Thường đặt ở root repo:

AGENTS.md

Nếu mono-repo lớn, có thể thêm file ở từng package/module. Quy tắc gần file hơn nên cụ thể hơn.

Template đề xuất

# AGENTS.md

## Tổng quan dự án
Mô tả ngắn stack, mục tiêu và cấu trúc chính.

## Lệnh thường dùng
- Cài dependency: `pnpm install`
- Chạy dev: `pnpm dev`
- Test: `pnpm test`
- Build: `pnpm build`

## Quy tắc sửa đổi
- Giữ phạm vi nhỏ.
- Không format toàn repo nếu không được yêu cầu.
- Không đổi public API khi chưa nêu rõ.
- Không sửa file generated.

## Kiểm chứng
- Sau khi sửa code, chạy test liên quan.
- Sau khi sửa UI, chụp ảnh hoặc mô tả cách kiểm tra.
- Nếu không chạy được test, nói rõ lý do.

## Bảo mật
- Không đọc hoặc ghi secret.
- Không deploy, xóa dữ liệu hoặc đổi billing nếu chưa được duyệt.

## Bàn giao
- Liệt kê file sửa.
- Ghi lệnh đã chạy và kết quả.
- Nêu rủi ro còn lại.

Viết thế nào cho tốt

• Ngắn và cụ thể.
• Ưu tiên lệnh thật thay vì mô tả chung.
• Ghi điều cấm rõ ràng.
• Cập nhật khi workflow thay đổi.
• Không nhồi kiến thức không liên quan đến repo.

Phiên bản tối thiểu

# AGENTS.md

## Lệnh dự án
- Build: `pnpm build`
- Test: `pnpm test`

## Quy tắc
- Giữ thay đổi nhỏ.
- Không sửa file ngoài phạm vi tác vụ.
- Không commit hoặc push nếu chưa được yêu cầu.

## Bàn giao
- Nêu file đã sửa, lệnh đã chạy và rủi ro còn lại.

Bước tiếp theo: Sandbox và phê duyệt

Cần quan tâm điều gì

• Codex được đọc file nào?
• Codex được ghi file nào?
• Có được chạy lệnh không?
• Có được truy cập mạng không?
• Có được dùng credential hoặc secret không?
• Lệnh nguy hiểm có cần hỏi trước không?

Tác vụ ít rủi ro

Ví dụ:

• Tóm tắt repo.
• Sửa README.
• Bổ sung test nhỏ.
• Chạy lệnh test không ghi dữ liệu.

Với nhóm này, quyền ghi trong workspace và approval cho lệnh ngoài phạm vi thường đủ.

Tác vụ rủi ro cao

Ví dụ:

• Xóa hoặc move nhiều file.
• Cài dependency lớn.
• Chạy migration database.
• Deploy production.
• Gửi dữ liệu ra API bên ngoài.
• Thao tác billing, credential hoặc quyền truy cập.

Với nhóm này, yêu cầu Codex giải thích lệnh, tác dụng phụ và rollback trước khi duyệt.

Prompt an toàn

Trước mọi lệnh có thể xóa, ghi đè, cài dependency, truy cập mạng, deploy,
hoặc đọc secret, hãy dừng lại và giải thích lý do. Chờ tôi xác nhận rồi mới chạy.

Quy trình phê duyệt trong App

Khi Codex xin quyền, đừng chỉ nhìn dòng lệnh. Hãy kiểm tra:

• Thư mục hiện tại.
• File hoặc dịch vụ bị ảnh hưởng.
• Tác dụng phụ.
• Có cách rollback không.
• Lệnh có khớp mục tiêu ban đầu không.

Nếu không chắc, từ chối và yêu cầu phương án chỉ đọc hoặc ít rủi ro hơn.

Gợi ý cho đội nhóm

• Chuẩn hóa AGENTS.md.
• Ghi rõ lệnh nào được tự chạy.
• Cấm deploy/xóa dữ liệu nếu chưa có approval thủ công.
• Tạo playbook cho secret và production.
• Yêu cầu mỗi PR có phần “Codex đã làm gì” và “đã kiểm chứng thế nào”.

Bước tiếp theo: Codex Cloud

Codex không hiểu dự án

Triệu chứng:

• Trả lời chung chung.
• Sửa nhầm file.
• Không biết lệnh test/build.

Cách xử lý:

Chỉ đọc repo hiện tại. Hãy lập bản đồ thư mục, tìm package manager,
lệnh test/build và file cấu hình quan trọng. Không sửa file.

Sau đó thêm AGENTS.md với lệnh và ranh giới dự án.

Codex sửa quá rộng

Nguyên nhân thường là prompt mơ hồ hoặc không có phạm vi. Hãy yêu cầu:

Hãy dừng lại. Tóm tắt file đã sửa và vì sao.
Chỉ giữ lại thay đổi trong [file/module], không refactor ngoài phạm vi.

Luôn kiểm tra git diff trước khi tiếp tục.

Test không chạy được

Kiểm tra:

• Dependency đã cài chưa.
• Lệnh chạy đúng package manager chưa.
• Cần env var hoặc service nền không.
• Test fail do code mới hay do môi trường.

Yêu cầu Codex phân loại:

Hãy đọc log test và phân loại: lỗi do môi trường, dependency,
test flaky hay regression từ thay đổi hiện tại. Chưa sửa file.

Output không chính xác

Cho Codex thêm nguồn kiểm chứng:

• File liên quan.
• Log đầy đủ.
• Screenshot.
• Kết quả lệnh.
• Link tài liệu chính thức.

Đừng yêu cầu nó đoán trên mô tả thiếu dữ liệu.

Lỗi đăng nhập hoặc quyền

Kiểm tra:

• Đúng tài khoản ChatGPT / OpenAI chưa.
• Gói tài khoản có hỗ trợ Codex không.
• Khu vực hoặc proxy có chặn không.
• Workspace đã được cấp quyền chưa.
• Organization policy có hạn chế không.

Sau khi đổi provider không thấy phiên cũ

Một số lịch sử hoặc session có thể gắn với provider, profile hoặc bề mặt sử dụng. Hãy kiểm tra lại config, profile đang active và tài khoản đang đăng nhập. Không xóa cấu hình cũ nếu chưa backup.

Checklist khôi phục nhanh

1. Lưu trạng thái hiện tại bằng git status.
2. Không chạy lệnh xóa/ghi đè khi chưa hiểu lỗi.
3. Chạy lại tác vụ ở chế độ chỉ đọc.
4. Thu hẹp phạm vi còn một file hoặc một command.
5. Sau khi sửa, chạy test nhỏ nhất liên quan.
6. Ghi lại nguyên nhân và cách kiểm chứng vào tài liệu đội nhóm.

Tiếp theo nên đọc: Phương pháp thực hành

Danh sách case

| Case | Khi nên đọc |
|

OpenAI chính thức

• OpenAI Codex product page
• Codex developer docs
• Codex in ChatGPT Help Center
• OpenAI Codex CLI GitHub repo

Trang nên đọc

• Codex App docs.
• Codex CLI getting started.
• Agent approvals and security.
• Config basics.
• MCP/tool integration docs.

Cách dùng nguồn

• Dùng nguồn chính thức để xác nhận sự kiện.
• Ghi ngày kiểm tra vào trang có thông tin nhạy thời gian.
• Nếu dùng nguồn cộng đồng, nêu rõ đây không phải tài liệu chính thức.
• Với giá và quota, luôn kiểm tra trang hiện tại trước khi hướng dẫn người khác.