把最近提交整理成发布说明，Codex CLI 能直接接进脚本

每次发版，都要把一串提交整理成用户看得懂的变化说明。AI 能帮忙概括，但如果仍要从聊天框里复制结果、删掉过程说明、再改成程序能读的格式，重复工作并没有消失。Codex CLI 的非交互模式，可以把这一步放进现有脚本。

这里值得看的入口是 codex exec。它接收一项任务，读取仓库或传入材料，完成后输出结果，不需要打开交互界面。OpenAI 官方文档把生成发布说明列为直接用途之一。

先让结果成为一个文件

官方示例让 Codex 总结最近十次提交，并把输出保存成 Markdown。按这个思路，可以从仓库目录运行下面的教学命令：

codex exec "根据最近10次提交生成中文发布说明，区分用户可见变化与内部维护，并标出依据的提交" > release-notes.md

这条命令没有在本文执行。它要说明的是输入与产物：仓库历史是材料，最终文字落到 release-notes.md，之后可以按项目流程编辑和审阅。

默认情况下，执行进度写到 stderr，只有最终代理回答进入 stdout。因此，终端里的过程与要保存的文章可以分开。也可以用 -o 或 --output-last-message 写最终回答文件，而不必从完整会话日志里再挑一遍。

发布说明的难点仍在事实对应。提交里写着“fix upload”，并不自动说明哪个用户遇到的问题已经解决。给任务附上相关 issue、变更范围，要求保留提交依据，才能让编辑有地方回查。缺少依据的影响判断，应该留待确认。

如果后续要把变化导入发布系统，官方提供两条不同路径。--json 把执行过程变成 JSON Lines，每一行是一条事件，包含线程、轮次、工具调用或消息等。它适合记录进度与执行过程，不是一份可以直接当发布条目使用的最终 JSON。

需要固定字段时，应看 --output-schema。你可以定义“版本说明、用户变化、内部维护、待确认事项”等 JSON Schema 字段，再让最终回答按结构返回，并用 -o 保存。这样，下游程序读的是稳定字段，编辑仍能检查每项内容的依据。

Schema 保证的是结果形状，不保证某次提交被分到了正确类别，也不证明描述的功能已经上线。把字段约束与事实核验分开，才能避免“能解析”被误认为“可发布”。

CLI 总览说明，Codex 可以检查本地文件、修改代码和运行已有工具；但整理发布说明通常只需要读取材料。非交互文档也给出默认只读沙箱，适合先把报告任务跑清楚，再决定是否需要写源码权限。

使用前仍需完成受支持的认证，并具备相应模型访问。CLI 代码与模型服务是两层，不能把开源客户端等同于无成本调用。对于已有 Git 和发版脚本的项目，我会从“生成一份带依据的 Markdown 草稿”开始；需要进一步集成时，再加最终 JSON 的契约。