提高 chatgpt 和 codex 工作效率：把经验变成可复用的工作流

本周可访问的记录共有 49 条，包括 30 条 codex 任务和 19 条 chatgpt 对话。记录覆盖代码审查、环境部署、接口验证、文档整理和学习任务。部分早期对话正文不可访问，因此下面只依据可以核对的事实，不补充猜测。

和前几周相比，我已经开始限制并发任务，本周同时活跃的任务从 4 个下降到 2 个；我也开始用问题台账区分“现场已处理”和“代码已修复”，并把镜像构建沉淀成 skill。这些习惯已经产生效果，下一步应该继续把经验前移，减少事后整理和范围反复确认。

1 在进入新环境前先建立可执行的 runbook

本周完成了一次较复杂的组件安装和真实功能验证，结束后才提出把步骤、兼容问题、验证和回滚方法整理成 runbook。最终结果是成功的，但很多有效命令和判断依据仍先存在于长对话和现场操作中，再由人工回忆整理。

上周“把现场修复纳入源码和交付闭环”的建议已经部分采纳：问题台账能够区分现场处理、代码提交和验证状态。不过，可复用文档仍然偏向任务结束后补写。

如果 runbook 在安装完成后才创建，第二套环境仍可能重复经历探索过程。把前置检查、配置入口、安装步骤、停止条件、验证和回滚提前写出来，第一次实施就可以同时验证 runbook，而不是只验证环境。

新环境任务开始前，先创建最小 runbook，至少包括：

适用范围
前置检查
现场参数
安装或修改步骤
停止条件
验证命令
回滚方法
已知限制

执行过程中只修正与实际不一致的地方。任务结束时交付经过实测的 runbook，而不是重新整理聊天记录。

下一次同类环境部署中，所有关键步骤都能在执行前从 runbook 找到；现场新增的临时步骤不超过 1 个，第二套环境不再依赖历史聊天命令。

本周的接口任务中，多次出现“这些接口是否在需求中”“还有哪些没有测试”“哪些能力仍需要完成”的确认。根因不是测试不足，而是原始需求描述的是能力范围，实际验证使用的是具体接口，二者没有在开始时建立一一对应关系。

之前“开始任务前写清结果和完成标准”的建议已经被采用，但对接口任务来说，仅有文字目标还不够，需要一张可持续更新的验收矩阵。

没有矩阵时，很容易把页面中发现的附加接口误当成必须交付项，也容易把已经调用但正向场景被外部依赖阻塞的接口写成“尚未测试”。这会增加讨论回合，也让完成状态难以判断。

接口任务开始时先创建下面的表格，确认后再测试：

需求能力	实际接口	正向场景	失败场景	证据	状态
示例能力	`GET /api/example`	正常返回	无权限、参数错误	请求与响应摘要	pass / blocked / out of scope

只测试矩阵中确认的范围。新发现的接口先放入“候选补充”，说明价值后再决定是否纳入，不在执行过程中自动扩大任务。

下一项接口任务中，100% 的需求都有对应接口和状态；测试过程中关于范围的往返确认不超过 1 次，最终不存在含义不清的“未测试”。

本周 chatgpt 主要用于概念解释和方案讨论，codex 主要用于代码、环境、文档和验证，分工已经比较合理。一个典型流程是先在 chatgpt 中讨论工具和演示场景，再把对话引用到 codex 中完成实际部署。

这种方式已经比把所有事情放在同一条长对话中更清晰，但直接传递完整对话仍会带入大量背景。引用内容还可能只是截断预览，codex 需要重新判断哪些是最终决定、哪些只是讨论过程。

讨论记录适合帮助理解，不适合作为执行规格。codex 真正需要的是当前目标、已确认方案、操作边界、相关资源和完成标准。交接内容越明确，重新读取和澄清的成本越低。

每次从 chatgpt 转到 codex 前，先生成一张交接卡：

目标：最终要得到什么结果。
已确认方案：讨论后选择了哪一种做法。
上下文：相关项目、文件、环境或参考资料。
约束：允许修改什么，哪些操作需要暂停。
完成标准：需要哪些功能和验证证据。

然后把交接卡作为 codex 的主提示，原对话只作为补充参考。OpenAI 官方文档也建议提示中明确目标、上下文、约束和完成标准，让 codex 更少假设并产出更容易审阅的结果。OpenAI Docs

下周所有 chatgpt 到 codex 的任务交接都包含这 5 项；codex 开始执行前不再需要重新询问已在 chatgpt 中确定的目标或边界。