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；
自动化越来越多，但没人检查它是否仍有价值；
某个流程只做过两次，就被过早封装，后续输入一变，维护成本比手工重做还高。
所以，月度诊断的目标不是“发现更多可以自动化的事情”。
真正的目标是回答三个问题：
过去一个月，我在哪些事情上反复付出了相同成本？
这些事情中，哪些已经有能力覆盖，只是没有被正确复用？
剩下的缺口里，哪些已经稳定到值得沉淀？
这三个问题，比“帮我创建几个 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 月度诊断拆成六步。
第一步：先盘点事实，不急着提方案
按下面的顺序读取证据：
最近 30 天的 Codex Sessions 和 Task Summaries；
Memory 与 Rollout Summary；
如果启用了 Chronicle，用它发现 Codex 之外的重复线索，再回到邮件、日历、文档或项目记录确认；
当前已有的 Skills、Custom Agents 和 Automations。
这个顺序很重要。
Sessions 告诉你最近实际做了什么，Memory 和 Rollout 帮你识别跨会话模式，现有能力清单则负责阻止重复建设。
Chronicle 适合找线索，不适合单独充当最终证据。
第二步：把候选工作流放进同一张表
每个候选项至少记录六个字段：
| 字段 | 要回答的问题 |
|---|---|
| 重复次数 | 过去 30 天发生了几次？ |
| 时间成本 | 每次大约需要多少人工时间？ |
| 出错风险 | 哪些步骤容易漏、容易错、需要返工？ |
| 输入稳定性 | 输入格式和前置条件是否已经稳定？ |
| 现有覆盖 | 是否已有 Skill、Agent 或 Automation？ |
| 验收条件 | 怎样判断这次执行真的完成？ |
没有这张表，Agent 很容易被“看起来很复杂”误导，把一次性项目误判为可复用流程。
第三步：先决定是否值得沉淀
我采用四道门槛：
至少发生两次，或者明显会持续发生且单次成本很高；
输入相对稳定，流程可以重复；
输出明确，或者有清晰的结束条件；
标准化后能明显改善速度、质量、一致性或可靠性。
只满足“做过两次”还不够。
如果两次执行时输入仍在剧烈变化，封装得越早，未来维护成本越高。
第四步：选择最小实现方式
不是所有重复工作都应该做成 Skill。
- Skill
：适合一套可复用的操作手册，例如固定的数据检查、文章审校或知识库归档流程。
- Custom Subagent
：适合可以独立委派的专业角色，例如限定范围的代码审查、竞品调查或专项证据核验。
- Automation
：适合有明确时间触发条件的检查、报告、提醒和监控。
- 扩展已有能力
：已有流程覆盖了八成，只缺一个步骤时，优先补齐，不重新造轮子。
- Skip
：一次性工作、输入仍不稳定、证据不足、涉及敏感信息，或节省的时间不足以抵消维护成本。
“Skip”不是失败。
对重度用户来说，它可能是整套诊断里最有价值的输出。
第五步：候选清单和创建动作必须分开
先让 Codex 输出候选清单，包含证据日期、频率、信心等级、推荐方式和不创建的理由。
确认这张清单之后，再允许它创建能力。
这样做可以阻止 Agent 在分析过程中一边发现、一边兴奋地写文件，最后留下几个没有人维护的半成品。
我的建议是：一次月度诊断最多新建或扩展一到三个能力。
如果某个月出现十几个“高置信度缺口”，更可能是现有能力盘点不完整，或者候选标准太宽。
第六步：新能力必须经过双重验证
创建完成不等于可以使用。
至少做两类测试：
用一个真实历史任务重跑，看它能否稳定复现合格结果；
用一个隔离样本测试，看它是不是只记住了旧项目的特殊情况。
验收时不要只看“脚本运行成功”，还要看：
输出有没有漏掉关键字段；
证据能不能追溯；
失败时是否给出明确原因；
是否越权修改外部系统；
下个月再次运行时，是否仍然容易维护。
一段可以直接复制的月度诊断提示词
下面是我根据这次实测整理的精简版。它保留了原帖最重要的约束，也加入了重度用户更需要的验收和防膨胀规则。
回顾我最近 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。
真正的区别是：你是否开始把自己的使用记录，当成一份可以审计、可以优化的工作系统。
每个月回看一次。
找出重复劳动，确认真实缺口，复用已有能力，只实现最小方案，再用真实任务验证。
如果最后只新建了一个能力，甚至一个都没有，不必失望。
那很可能说明，你成功避免了一次没有必要的自动化。
