测试通过，审查也过了，这时候最容易松一口气说一句完成了。但真正的链路还差两步，把这次修改正式提交，把这次经验沉淀下来。
只做到代码能跑，短期看没问题，长期会出现一个麻烦。每次都像第一次做，重复的解释和重复的坑会一直在。
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，还有没有未完成的事项，有没有需要人工确认的风险。
