夜雨聆风最近 Greg Brockman 转发了一段面向 Codex 的自我优化 prompt，标题很短：self improvement prompt for codex。
这段 prompt 本身不复杂。它要求 Codex 回看最近一段时间的工作记录，找出反复出现、耗时、容易出错、上下文很重的流程，然后把这些流程沉淀成最小可复用资产：skill、子 agent，或者自动化任务。
我觉得它值得单独拿出来写，不是因为这是一段“神奇提示词”，而是因为它指出了 AI agent 使用方式里的一个重要变化。
过去我们更多是在问：这次任务怎么让 AI 做好？
现在问题开始变成：如果类似任务会反复出现，能不能让 AI 把这类工作变成系统能力？
这就是从一次性助手，到可积累工作系统的转变。
AI 很会做事，但不一定会积累
今天的 Codex、Claude Code、Cursor 已经能完成很多具体工作：读代码、修 bug、写测试、查文档、生成脚本、整理文章、分析日志。
但很多人的使用方式仍然停留在“一次性会话”里。
你让它做一次，它完成了。下周遇到相似问题，你再解释一遍。换个项目、换个上下文，又从头开始。
这里真正浪费的，不是模型能力，而是流程没有被沉淀。
很多高频工作其实有固定结构。比如排查某类线上错误、整理某类技术资讯、发布某个平台内容、做代码审查、生成周报、分析竞品动态。
这些任务每次细节不同，但输入、步骤、判断标准和输出格式往往很稳定。
如果每次都重新解释，本质上是在把可以复用的工作，当成临时劳动来处理。
Greg 转发的这段 prompt，就是在提醒我们：AI agent 不只可以执行任务，也可以观察你反复执行的任务，并把它们变成下次可直接调用的能力。
它真正解决的不是 prompt，而是工作复利
这段 prompt 的核心不是“怎么写出一个更强的提示词”，而是给 Codex 一个自我审计流程。
它要求 Codex 先看证据，再决定要不要封装流程。
证据来自最近的会话、任务摘要、Memory、Chronicle，以及已经存在的 skills、custom agents 和 automations。也就是说，它不是让 AI 凭空想象“用户可能需要什么”，而是从真实工作记录里提取模式。
这点非常关键。
很多自动化失败，不是因为技术做不到，而是因为过早封装了错误的东西。一个只出现过一次的任务、一个输入不稳定的流程、一个输出标准不清晰的操作，都不适合马上做成 skill。
否则最后会得到一堆看起来很专业，实际没人复用的工具。
好的 agent 系统不是越自动化越好，而是把真正重复、真正稳定、真正有收益的流程沉淀下来。
这就是工作复利的起点。
先问这个流程值不值得封装
这段 prompt 里最有工程味的地方，是它没有鼓励 Codex 什么都创建。
它给了一组筛选标准：这个任务是否至少出现过两次，或者明显会再次出现且重复成本高；它是否有稳定输入、可复现步骤、清晰输出或停止条件；它是否能明显提升速度、质量、一致性或可靠性；它是否已经被现有能力覆盖。
这些标准看起来很保守，但很重要。
因为 agent 的能力越强，越容易让人产生一种错觉：只要能自动化，就应该自动化。
实际不是这样。
一次性的事情不值得封装。边界模糊的事情不值得封装。证据不足的事情不值得封装。涉及敏感信息、判断责任或高风险操作的事情，也不能轻易交给自动化。
真正成熟的自我优化，不是让 AI “不断创造新工具”，而是让它学会判断：哪些事情应该沉淀，哪些事情应该跳过。
跳过本身也是能力。
Skill、子 agent、自动化不是同一件事
这段 prompt 还有一个很好的地方：它没有把所有复用都叫做“自动化”。
不同类型的重复工作，应该沉淀成不同形态。
Skill 适合稳定流程。 比如“查询 AI 热点并整理成中文简报”“按项目规范做代码审查”“把技术文章发布成微信公众号草稿”。它更像一份可执行 SOP，强调步骤、边界和输出格式。
子 agent 适合专门角色。 比如“安全审查员”“性能瓶颈分析员”“竞品研究员”。它不一定是固定流程，而是一个边界清楚、可以委派的专业任务。
自动化适合定时触发。 比如每天早上抓取 AI 新闻、每周生成项目状态报告、定期检查某个网页或指标变化。它的重点不是“现在帮我做”，而是“到时间自动做”。
Skip 也应该被认真记录。 因为很多任务看起来能封装，实际上还没有足够证据。把它们放进“暂不创建”的清单，比急着做一个半成品更好。
这个分类很实用。它让 agent 的自我改进不再是抽象口号，而变成一套资产管理机制。
最小可用，胜过宏大系统
这段 prompt 反复强调一个原则：选择最小合适形态。
能扩展已有 skill，就不要新建一个重叠 skill。能写一个窄流程，就不要设计一个大平台。能先做一个小自动化验证价值，就不要一上来设计完整 agent 生态。
这和好的工程习惯是一致的。
系统能力不是靠堆概念堆出来的，而是从高频、稳定、可验证的小流程里长出来的。
一个真正有用的 skill，应该窄、清楚、可执行。它应该告诉 AI 在什么场景下使用，先看哪些证据，如何处理异常，什么时候必须停下来问人，以及最后应该产出什么。
如果一个 skill 什么都想管，它很快就会变成另一个需要维护的大问题。
所以这段 prompt 最值得借鉴的，不是“创建更多能力”，而是“克制地创建能力”。
对个人和团队意味着什么
如果你长期使用 Codex，这类自我优化 prompt 可以变成一个周期性维护动作。
比如每两周让 Codex 回顾一次最近工作，输出一份候选清单：哪些流程重复出现了，证据是什么，频率如何，推荐做成 skill、子 agent、自动化，还是应该跳过。
然后只落地最明确的一两个。
对个人来说，这会让 AI 使用从“临时帮忙”变成“持续建设”。你不再只是让 AI 完成眼前任务，而是在逐步搭建自己的工作系统。
对团队来说，它也很有价值。
团队里很多隐性流程，其实散落在聊天记录、PR 评论、项目复盘和个人经验里。让 agent 定期从这些记录里寻找重复模式，可以帮助团队发现哪些工作值得标准化，哪些操作容易出错，哪些经验应该写成 playbook。
但前提是要有边界。
自我优化不应该变成无节制的工具生成，也不应该让 AI 擅自处理高风险事项。它更适合做发现、建议、初步封装和低风险流程沉淀。涉及权限、对外发布、资金、合同、隐私和安全的流程，仍然需要明确的人类审查节点。
真正的变化：AI 开始参与维护工作系统
过去我们评价 AI 编程工具，主要看单次任务能力：它能不能修 bug，能不能写测试，能不能理解代码库。
但下一阶段，更重要的可能是工作记忆和流程复利。
如果一个 agent 能持续观察你的工作模式，它就可以逐渐理解：你经常怎么写文章，怎么查资料，怎么做代码变更，怎么验收结果，哪些流程总是需要同样的上下文，哪些错误你已经重复踩过。
当这些模式被沉淀下来，agent 就不再只是每次都很聪明，而是开始变得越来越懂你的系统。
这才是 Codex 这类工具最有想象力的方向。
它不是单纯替你写更多代码，而是把你的工作方法逐步产品化。
最后
Greg 转发的这段 prompt，看起来只是一小段提示词，但它指向的是一个更大的变化：AI agent 不再只是任务执行器，而是在逐渐成为工作系统的维护者。
它会观察、归纳、封装、跳过，并在必要时把经验变成可复用能力。
对开发者和知识工作者来说，真正值得关注的不是“我能不能让 AI 多做一点”，而是：
我能不能让 AI 把我反复做的事情，变成下次不用重新解释的系统能力。
这才是 agent 工作流开始产生复利的地方。
参考资料
- Greg Brockman: self improvement prompt for codex
- Blockchain.News: Codex Boosts productivity with self-improvement prompt
#AI #智能体 #Codex #工程实践
