Codex 常用功能与实用工作流

1. Codex 不只是代码补全

Codex 是面向软件开发工作的 coding agent。与只生成一段代码的聊天工具不同，它可以在获得授权后读取项目文件、 搜索调用关系、编辑代码、运行命令、检查 Git diff，并把验证结果一起交付。

Codex 提供 App、CLI、IDE 扩展和云端等不同使用方式。日常选择很简单：需要在编辑器旁快速问答时用 IDE 扩展； 偏爱终端工作流时用 CLI；需要并行线程、Worktree、可视化 diff 或定时任务时，Codex App 更合适。

2. 写清任务，而不是堆提示词

高质量请求通常包含四部分：目标、范围、约束和 完成标准。不必写得很长，但要让 Codex 知道什么可以改、什么不能动，以及怎样才算完成。

请修复登录页提交后偶发重复请求的问题。

范围：
- 先定位请求从哪里触发
- 尽量只修改登录表单相关文件
- 不引入新依赖

完成标准：
- 快速连续点击只发送一次请求
- 补充回归测试
- 运行项目现有的 lint、test 和 build
- 最后总结修改文件与验证结果

对小任务可以直接要求实现；对架构调整、迁移或不熟悉的仓库，先让 Codex 调查并给出简短方案，再开始修改。 如果你只想获得解释，要明确写“先不要修改代码”。

3. 阅读和理解代码库

Codex 很适合回答“这个功能到底怎么工作的”。它可以搜索入口、类型、配置和测试，沿调用链整理模块关系。 相比直接问“解释一下项目”，指定一个业务流程通常会得到更有用的结果。

先不要修改代码。

请梳理这个项目的认证流程：
1. 找到登录入口和路由
2. 追踪 token 的创建、保存和刷新
3. 说明相关模块之间的调用关系
4. 标出最可能引发登录失效的三个位置

请引用具体文件和行号。

还可以让它生成模块地图、找出废弃代码、比较两个实现、解释构建失败，或在修改前评估影响范围。 要求引用文件和行号，能让结论更容易核对。

4. 修改代码并完成验证闭环

Codex 的价值不在于“写完代码”，而在于把任务推进到可验证状态。一个完整循环通常包括： 阅读相关代码、做最小修改、补充测试、运行项目命令、检查 diff、总结结果。

请实现文章搜索的 URL 状态同步。

请按以下顺序执行：
1. 阅读现有文章列表和筛选逻辑
2. 给出简短实现方案
3. 修改代码
4. 运行静态检查和构建
5. 检查最终 diff，确认没有无关改动
6. 总结行为变化、测试结果和遗留风险

项目已有测试、lint、类型检查或构建命令时，直接要求 Codex 使用它们。前端任务还可以让它启动本地服务， 通过可用的浏览器工具检查布局、交互、控制台错误和不同视口下的表现。

如果命令失败，Codex 应继续定位原因；如果因为权限、网络或缺少凭据无法验证，也应明确说明哪些步骤没有完成。

5. 用 Review 检查改动

Codex App 的 Review 面板基于 Git 展示改动，可查看未提交内容、分支差异或最近一轮修改。 你可以在具体代码行留下评论，再让 Codex 逐条处理。也可以直接发起一次代码审查：

请审查当前未提交的改动。

重点检查：
- 行为回归和边界条件
- 异步竞态、错误处理和资源释放
- 安全问题
- 缺失或无效的测试

先按严重程度列出问题，并引用文件和行号；
如果没有发现问题，请明确说明剩余风险。

审查提示应强调“找问题”，而不是让它复述代码。好的结果会优先指出可复现的缺陷、风险和测试缺口， 并附上位置；格式、命名等低风险建议应排在后面。

参考： Codex App Review

6. 用 AGENTS.md 固化项目约定

如果每次任务都要重复说明包管理器、测试命令、目录边界和文档要求，可以把这些规则写进 AGENTS.md。 Codex 会在开始工作前读取它；子目录中的同名文件可以为特定模块补充更具体的规则。

# AGENTS.md

## 项目约定
- 使用 pnpm，不要生成 package-lock.json
- TypeScript 开启 strict，禁止使用 any 绕过类型错误
- 修改业务逻辑后运行 pnpm test
- 修改页面后运行 pnpm build
- 新增公共组件时同步更新 docs/components.md

## 提交要求
- 不要修改与任务无关的文件
- 提交信息使用简短中文

适合写入的内容包括：项目结构、常用命令、代码风格、测试要求、禁止事项和交付流程。 临时需求仍应放在当前任务里，不要把一次性的细节不断堆进项目指令。

参考： Custom instructions with AGENTS.md

7. Local、Worktree 与 Cloud

当多个任务会改同一仓库时，Worktree 尤其有用：每个线程拥有独立检出目录和改动，不会直接混入主工作区。 完成后再审查 diff、提交或合并。

8. 权限、沙箱与审批

Codex 通常在受限制的环境中工作。读取项目、修改工作区文件和运行普通检查可能直接执行； 联网、访问工作区之外的位置、调用桌面应用或执行高风险命令时，可能需要你批准。

审批前重点看三件事：命令将访问什么、为什么需要额外权限、影响范围是否足够小。 对删除文件、重置 Git 状态、发布或修改生产环境等操作，应保留人工确认。

9. Skills：把重复流程做成能力

Skill 是一组可复用的任务说明，可附带脚本、参考资料和模板。例如，可以把“生成并检查 Word 文档”、 “按团队格式发布版本”或“执行前端视觉回归”做成 Skill。

当任务明确点名某个 Skill，或任务与 Skill 描述匹配时，Codex 会加载完整工作流。 这比在每个对话里粘贴一大段步骤更稳定，也更容易在团队中共享。

参考： Agent Skills

10. Automations：让例行任务自动运行

Codex App 可以按计划在后台执行重复任务，并把有价值的结果放进收件箱。它适合独立、可重复、 有明确输出格式的检查，不适合需要频繁人工判断的模糊任务。

每个工作日上午 9 点检查依赖安全公告，
只报告影响当前锁文件版本的问题，并给出升级建议。

每周五总结本周提交：
按功能、修复、文档分类，附上关键 commit。

每天检查 CI 失败任务：
归纳失败原因，相同错误合并，只报告可行动的问题。

对 Git 项目，自动化可以在独立 Worktree 中运行，避免修改正在工作的目录。 创建前应明确频率、目标项目、是否允许写文件，以及“没有发现问题”时如何处理。

参考： Codex App Automations

11. 一套实用的日常工作法

1. 先给目标：说明要解决的用户问题，不要只指定一段实现。
2. 再给边界：列出允许修改的范围、兼容要求和禁止事项。
3. 要求调查：陌生项目先读入口、测试和项目指令，再开始编辑。
4. 要求验证：让 Codex 运行测试、类型检查、构建或浏览器检查。
5. 审查 diff：确认没有无关文件、调试代码、密钥或意外格式化。
6. 沉淀规则：重复出现的项目约定写入 AGENTS.md，重复工作流做成 Skill 或 Automation。

Codex 最擅长的是目标清楚、环境可检查、结果能验证的任务。把“帮我写代码”升级为 “调查、实现、验证并说明风险”，通常就能显著提高交付质量。