用 Codex 保持文档更新

让文档跟着代码变化，而不是等上线后再补。

官方概览

文档最好和源代码变更一起更新，而不是几周后再补。Codex 可以检查变更代码、测试、release notes、相关 issue 和 pull request 上下文，然后起草范围明确、结构匹配的文档更新。

这个流程适合开发者文档、README、changelog 草稿、迁移说明、runbook，或任何需要跟随频繁变化行为的内容。

使用方式

从需要记录的变更开始：分享 branch、pull request、commit、issue 或文件。
如果文档是公开的，明确说明未发布路线图、私有客户细节和内部上下文不得写入。
让 Codex 映射受影响文档，在起草前搜索功能名、配置 key、命令、示例和相关术语。
更新最小有用文档面，保留当前页面结构、术语、交叉链接和 frontmatter。
运行适合仓库的格式化和文档检查，并总结每条面向用户声明背后的证据。

给 Codex 的材料

变更代码和测试能让 Codex 分析实际行为，从而起草聚焦的文档更新。公开 release notes 或产品文档能帮助它匹配公开术语、可用性和功能状态。

Pull request 或 issue 上下文解释了变更发生的原因，以及哪些用户可见行为重要。本地文档检查则给 Codex 一个具体的完成标准。

让流程可重复

对于仓库级约定，可以把文档要求写进 AGENTS.md。例如：当用户可见行为变化时，检查文档、示例或 changelog 是否需要更新；公开文档只能包含公开信息或仓库中可见行为；保留现有术语和 frontmatter；最终交付前运行文档格式化和构建检查。

如果流程步骤更多，可以把它转成 skill，让未来的 Codex 线程遵循同样的来源检查、起草和验证循环。也可以把这个流程变成 thread automation，例如每周读取最近 PR 并根据变更更新文档。

官方 Starter Prompt 中文翻译

请基于以下来源更新 [产品/功能] 文档：
- [这个仓库/链接仓库] 中变更的源文件
- 提到新行为的现有文档页面
- 我下面提供的任何链接 issue、PR、release note 或公开参考

然后：
- 识别哪些内容面向用户
- 只更新需要变化的文档
- 不要把未发布路线图、私有客户细节和仅内部可见上下文写进公开文档
- 保持现有文档结构、术语和交叉链接
- 运行适合这次变更的文档检查

最终提交前，总结改了什么、验证了什么，以及哪些声明无法从可信来源证明。

[在这里放 release notes 或其他参考链接]