别再只让 Codex 干活：每月做一次使用诊断，它会替你升级工作流

Codex 用得越久，很容易出现一种错觉：

今天少一个 Skill，明天缺一个 Automation，后天又觉得应该建一个专门的 Subagent。

能力越装越多，工作流却不一定更顺。相反，你可能开始记不清哪个 Skill 负责什么、哪些自动化仍在运行、同一种任务为什么有三套相似流程。

前几天，我看到 Vaibhav（VB）Srivastav 发了一篇很有意思的帖子（https://x.com/reach_vb/status/2058538305872949490 ）。

他的思路不是继续问 Codex“你还能帮我做什么”，而是让 Codex 回顾最近 30 天的真实工作记录，找出那些反复发生、耗时、容易出错、值得标准化的人工流程。

然后，只把高置信度、当前尚未覆盖的部分，沉淀成 Skill、Custom Subagent 或 Automation。

我照着这套思路跑了一遍。

结果不是一口气生成十几个新工具。

在一批重复出现的数据报告、内容生产、知识库归档、监控简报和网站诊断任务里，Codex 最终只建议我扩展一个已有能力。

这反而让我觉得，这次诊断是有效的。

太长不看的，可以直接拉到文章后面，复制提示词给codex，让它开始帮你诊断工作流及生成可复用的skills.

Codex 重度用户真正缺的，不一定是能力

轻度使用 Codex 时，我们关心的是“这件事它能不能做”。

重度使用一段时间后，问题会发生变化：

• 相似任务做过很多次，却仍然每次从头解释；
• 一个流程横跨多个会话，关键背景经常丢失；
• 已经有 Skill，后来又做出一个功能重复的新 Skill；
• 自动化越来越多，但没人检查它是否仍有价值；
• 某个流程只做过两次，就被过早封装，后续输入一变，维护成本比手工重做还高。

所以，月度诊断的目标不是“发现更多可以自动化的事情”。

真正的目标是回答三个问题：

1. 过去一个月，我在哪些事情上反复付出了相同成本？
2. 这些事情中，哪些已经有能力覆盖，只是没有被正确复用？
3. 剩下的缺口里，哪些已经稳定到值得沉淀？

这三个问题，比“帮我创建几个 Skills”重要得多。

原帖为什么在评论区越改越长

VB 最早的版本很短，也更偏开发任务：回看最近的编码工作，找出可重复流程，然后决定做成 Skill、Subagent 还是 Automation。

评论区很快补出了几个现实问题。

有人问：Codex App 能不能跨项目看到所有会话？如果历史不完整，结论会不会失真？

有人建议：不只看 Codex，会不会也应该检查其他 Agent 的会话记录？

有人主张把它设置成每周后台任务，让 Agent 持续自我改进。

也有人提醒，最关键的能力其实是“选择最小可用方案”。大多数自动化之所以臃肿，不是因为做不到，而是没人愿意说“不需要做”。

还有人提出更尖锐的质疑：如果需要一大段复杂规范，才能让 Agent 判断什么值得自动化，这本身是不是一种新的流程负担？

这些反馈共同推动了更新版提示词。它不再只是“扫描历史，然后创建能力”，而是增加了四道约束：

• 先规定证据来源和读取顺序；
• 至少重复两次，或明显会持续发生；
• 先检查现有 Skills、Agents 和 Automations，优先复用；
• 先输出候选清单，再只创建高置信度的缺失能力。

这几道约束，决定了诊断是在治理系统，还是在制造新的系统垃圾。

我实际跑完后，只扩展了一个能力

这次诊断，我让 Codex 先回顾最近 30 天的 Sessions 和任务总结，再用 Memory 与 Rollout Summary 识别跨会话反复出现的工作模式，最后盘点现有 Skills、Custom Agents 和 Automations。

它找到了不少重复工作：

• 把外部内容整理进个人知识库；
• 把研究资料改写成公众文章和视频；
• 定期生成数据报告；
• 检查邮件、日历和业务风险；
• 对网站和营销链路进行诊断；
• 从多个来源汇总固定格式的简报。

如果只看“是否重复”，这些都可以被打包成新能力。

但加入“是否已经覆盖”这道检查后，结论完全不同。

内容生产已经有完整工作流；数据分析已经有专用 Skills；监控和简报已经存在 Automations；部分网站诊断也已经沉淀成可复用能力。

最终，真正值得动手的只有一个缺口：知识库归档流程已经反复发生，步骤稳定，但现有 Skill 缺少对归档结构、双向链接和日志更新的自动校验。

所以我没有再创建一个新的“知识库 Agent”，而是扩展原有 Skill，补上校验脚本和更清晰的调用入口。

然后用两个样本验证：

• 一个真实的历史归档案例；
• 一个与历史数据隔离的测试案例。

两次都满足预期结束条件，才算完成。

这次体验让我更确定：一次好的诊断，价值不在于创建了多少能力，而在于它替你排除了多少不该创建的能力。

每月做一次，具体检查什么

我现在把 Codex 月度诊断拆成六步。

第一步：先盘点事实，不急着提方案

按下面的顺序读取证据：

1. 最近 30 天的 Codex Sessions 和 Task Summaries；
2. Memory 与 Rollout Summary；
3. 如果启用了 Chronicle，用它发现 Codex 之外的重复线索，再回到邮件、日历、文档或项目记录确认；
4. 当前已有的 Skills、Custom Agents 和 Automations。

这个顺序很重要。

Sessions 告诉你最近实际做了什么，Memory 和 Rollout 帮你识别跨会话模式，现有能力清单则负责阻止重复建设。

Chronicle 适合找线索，不适合单独充当最终证据。

第二步：把候选工作流放进同一张表

每个候选项至少记录六个字段：

没有这张表，Agent 很容易被“看起来很复杂”误导，把一次性项目误判为可复用流程。

第三步：先决定是否值得沉淀

我采用四道门槛：

• 至少发生两次，或者明显会持续发生且单次成本很高；
• 输入相对稳定，流程可以重复；
• 输出明确，或者有清晰的结束条件；
• 标准化后能明显改善速度、质量、一致性或可靠性。

只满足“做过两次”还不够。

如果两次执行时输入仍在剧烈变化，封装得越早，未来维护成本越高。

第四步：选择最小实现方式

不是所有重复工作都应该做成 Skill。

• Skill

：适合一套可复用的操作手册，例如固定的数据检查、文章审校或知识库归档流程。

• Custom Subagent

：适合可以独立委派的专业角色，例如限定范围的代码审查、竞品调查或专项证据核验。

• Automation

：适合有明确时间触发条件的检查、报告、提醒和监控。

• 扩展已有能力

：已有流程覆盖了八成，只缺一个步骤时，优先补齐，不重新造轮子。

Skip

：一次性工作、输入仍不稳定、证据不足、涉及敏感信息，或节省的时间不足以抵消维护成本。

“Skip”不是失败。

对重度用户来说，它可能是整套诊断里最有价值的输出。

第五步：候选清单和创建动作必须分开

先让 Codex 输出候选清单，包含证据日期、频率、信心等级、推荐方式和不创建的理由。

确认这张清单之后，再允许它创建能力。

这样做可以阻止 Agent 在分析过程中一边发现、一边兴奋地写文件，最后留下几个没有人维护的半成品。

我的建议是：一次月度诊断最多新建或扩展一到三个能力。

如果某个月出现十几个“高置信度缺口”，更可能是现有能力盘点不完整，或者候选标准太宽。

第六步：新能力必须经过双重验证

创建完成不等于可以使用。

至少做两类测试：

1. 用一个真实历史任务重跑，看它能否稳定复现合格结果；
2. 用一个隔离样本测试，看它是不是只记住了旧项目的特殊情况。

验收时不要只看“脚本运行成功”，还要看：

• 输出有没有漏掉关键字段；
• 证据能不能追溯；
• 失败时是否给出明确原因；
• 是否越权修改外部系统；
• 下个月再次运行时，是否仍然容易维护。

一段可以直接复制的月度诊断提示词

下面是我根据这次实测整理的精简版。它保留了原帖最重要的约束，也加入了重度用户更需要的验收和防膨胀规则。

回顾我最近 30 天的工作；如果历史不足 30 天，就使用全部可用历史。

证据读取顺序：
1. 最近的 Codex Sessions 与 Task Summaries；
2. Memory 与 Rollout Summary，用于识别跨会话重复模式；
3. Chronicle 只用于发现 Codex 之外的线索，重要结论回到原始数据源确认；
4. 已有 Skills、Custom Agents 和 Automations，优先复用或扩展。

寻找经常重复、耗时、容易出错、依赖大量上下文，且标准化后能明显提升效率的人工工作流。

只有同时满足以下条件，才进入候选：
- 至少发生两次，或明显会持续发生且重复成本较高；
- 输入稳定、流程可重复、输出明确或有清晰结束条件；
- 能显著提升速度、质量、一致性或可靠性；
- 当前没有合适能力覆盖。

先输出候选清单，包含：
- 工作流；
- 证据与日期；
- 出现频率和信心等级；
- 推荐方式：Skill、Custom Subagent、Automation、扩展已有能力或 Skip；
- 值得或不值得创建的原因。

候选清单完成后，只创建高置信度、当前缺失的能力。
每次最多新建或扩展 3 项。

新能力必须：
- 范围清晰；
- 基于真实数据来源；
- 有明确验收标准；
- 至少通过一个真实历史案例和一个隔离样本验证；
- 不执行未经授权的外部写入、发送或发布。

最终报告：
- 本次新建或扩展了什么；
- 哪些内容被刻意跳过，以及原因；
- 哪些工作仍需更多证据；
- 与上月相比，能力数量、重复劳动和维护成本发生了什么变化。

每月一次，还是每周一次

评论区有人建议每周运行，我认为可以分成两层。

每周只做轻量检查：记录新出现的重复工作和失败模式，不创建新能力。

每月再做一次完整诊断：跨会话归纳、盘点已有能力、评估候选项，并在证据足够时创建或扩展。

这样既不会错过高频问题，也能避免 Agent 每周都对系统结构动刀。

我已经把完整诊断设置为每月自动运行一次。下一次报告不只看新增了什么，还要检查上个月创建的能力有没有真正被使用。

下个月，别只看省了多少时间

一个新 Skill 或 Automation 是否值得保留，可以看五个指标：

• 实际调用次数；
• 节省的人工时间；
• 返工或错误是否减少；
• 输出被人工大改的比例；
• 维护它花了多少时间。

如果一个能力连续一个月没有被调用，或者维护成本已经接近手工重做成本，就应该考虑合并、降级甚至停用。

Agent 系统也需要定期做减法。

最后

Codex 重度用户和普通用户的区别，不是安装了多少 Skills，也不是同时运行多少 Agents。

真正的区别是：你是否开始把自己的使用记录，当成一份可以审计、可以优化的工作系统。

每个月回看一次。

找出重复劳动，确认真实缺口，复用已有能力，只实现最小方案，再用真实任务验证。

如果最后只新建了一个能力，甚至一个都没有，不必失望。

那很可能说明，你成功避免了一次没有必要的自动化。