Codex 日常开发工作流 | Codex 原理与日常使用

预计阅读时间: 16 分钟

日常开发里，Codex 最有价值的不是一次性生成大段代码，而是稳定完成“理解 -> 修改 -> 验证 -> 总结”的循环。你可以把它当成一位能读仓库、能跑命令、能整理变更的搭档，但要用工程化方式给任务。

这一篇给出一套适合每天重复使用的流程。

任务入口：先把问题说成可验收结果

差的任务描述：

优化一下页面。

更好的任务描述：

优化学习页移动端导航：手机端要能看到学习入口，保持现有视觉风格，不移除备案号。
完成后运行 lint 和 build，并部署到 aigc-bot.com。

区别在于第二种描述包含：

Codex 可以补上下文，但不能替你猜业务目标。

适合的提示：

先看相关代码和文档，告诉我这个功能现在是怎么组织的，再开始改。

Codex 应该优先找：

如果项目有 AGENTS.md，它会先约束 Codex 的行为。没有 AGENTS.md 时，你可以在提示里临时说明。

简单任务可以直接做，例如修文案、加一个链接、改一个样式。复杂任务建议先计划，例如：

一个好计划不需要很长，但应该说明：

1. 改哪些文件。
2. 为什么这样改。
3. 哪些验证覆盖风险。
4. 哪些暂时不做。

计划不是为了拖慢开发，而是减少错误方向上的快速执行。

Codex 很容易一次读很多、改很多。你要鼓励它保持小步：

在真实项目中，“只改必要文件”比“顺手把代码整理漂亮”更重要。

不同任务需要不同验证：

任务类型	最小验证
文案/静态内容	build、页面 HTML 关键字检查
TypeScript 组件	lint、build
交互组件	lint、build、浏览器或截图检查
SEO 变更	sitemap、canonical、metadata、JSON-LD 检查
部署变更	配置测试、健康检查、live curl
数据写入	单元测试、幂等测试、备份/回滚路径

不要要求每次都跑全量测试到天荒地老，但风险越大，验证越要靠近真实行为。

完成实现后，追加一句：

请先 review 你自己的 diff，重点看回归、遗漏的 SEO/国际化/移动端问题，再给我结果。

自查不能替代人的 review，但能过滤很多低级问题：

如果项目要求直接在主干落地，Codex 仍然应该保持提交清晰：

git status --short
git diff --stat
npm run lint
npm run build
git add <files>
git commit -m "feat: add codex learning track"
git push origin main

部署也要记录：

build output path
release directory
symlink switch
live route checks
pageview/stat service state

这样以后排查问题，不需要从聊天记录里猜发生了什么。

帮我实现 <功能>。
约束：
- 复用现有组件和数据结构。
- 不引入新依赖，除非你先说明理由。
- 同步更新规划文档。
- 完成后运行 lint/build。

这个问题是 <现象>。
复现路径是 <步骤>。
请先定位根因，再给最小修复；如果需要改测试，请补一个能防回归的测试。

参考这张截图，优化 <区域>。
重点是移动端不溢出、信息层级更清楚、保持现有视觉 token。
完成后用截图或 HTML 检查验证。

请构建并部署到生产。
要求：
- 先确认 git 状态。
- 使用现有 release 目录模式。
- 保留备案号和 pageview 服务。
- 部署后检查关键路由和 sitemap。

遇到这些情况，应该停下来确认：

优秀的 Codex 使用者不是把所有事都交出去，而是知道什么时候该让代理继续、什么时候该收回来判断。