Codex中文官网

测试通过，审查也过了，这时候最容易松一口气说一句完成了。但真正的链路还差两步，把这次修改正式提交，把这次经验沉淀下来。 只做到代码能跑，短期看没问题，长期会出现一个麻烦。每次都像第一次做，重复的解释和重复的坑会一直在。 commit 要说明这次改了什么 commit 不是随便写一句 update 就行。好的 commit 能回答几件事，改了什么，为什么改，影响哪里。测试有没有过，也要写清楚。 常见的写法有 feat 用于新增功能，fix 用于修问题，style 用于调样式。refactor 用于重构，docs 用于改文档。中文项目也可以写成 feat 新增用户资料页，fix 修复登录后跳转异常。 PR 是给别人审查用的 项目走 GitHub 或者团队协作流程，提交之后通常还要写 PR。PR 不是走形式，它让别人快速知道这次做了什么，为什么做，改了哪些地方。怎么测试的，有什么风险，需要重点看哪里，也都写在里面。 一份好的 PR 描述分成三块，本次修改，测试结果，风险说明。本次修改写清楚动了哪些文件，测试结果列出跑过的命令和结论，风险说明标出需要重点确认的地方。 把这次的问题记下来 复盘要记录过程里遇到的问题，这一步比结果更重要，下次遇到类似情况可以少走弯路。 问题类型示例需求问题一开始需求描述不够清楚计划问题计划里漏掉了移动端修改问题顺手改了无关组件测试问题项目没有 typecheck 命令审查问题发现它误删了 fallback 逻辑沟通问题提示词没有明确不要新增依赖 记录格式可以很简单，写下问题，原因和解决办法。 好用的提示词留下来 某句提示词效果不错，就记下来，下次直接复用，不用每次重新想。 有效提示词适用场景为什么有效先不要写代码，先制定计划所有复杂需求防止它直接乱改一次只改一个功能点多步骤任务降低出错和回滚成本不要顺手重构无关代码老项目维护防止改动范围扩大不确定先停下来问业务逻辑不清楚时防止它自作主张 该固定的规则写进 AGENTS.md 有些规则以后每次都要遵守，只写在聊天里会丢，写进项目级 AGENTS.md 更稳。这份文件是写给 Codex 看的项目规则说明书，可以告诉它项目怎么运行，代码风格是什么，哪些目录不能动。修改前要先计划，测试要跑哪些检查，提交要说明哪些内容，也都写进去。 详细写法有专门一篇，这里记住一条就够，能被反复执行的规则才值得写进去。 文档跟着更新 这次修改如果影响了项目的使用方式，相关文档也要跟着改。 修改内容需要更新的文档新增功能README 和功能说明新增环境变量.env.example 和部署文档修改接口API 文档修改部署流程部署说明新增命令README 和开发指南 文档更新不是为了好看，是为了避免以后忘记。常见的有 README.md 讲项目介绍和常用命令，.env.example 放环境变量示例。docs 目录放详细文档，CHANGELOG.md 记版本更新，AGENTS.md 写工作规则。 这一段的交付结论就是几句话。能不能提交，能不能发 PR，还有没有未完成的事项，有没有需要人工确认的风险。