Skill + CLI Workflow：把一次经验变成长期能力

这段时间我越来越强烈地感觉到，AI 协作里最容易被浪费的东西，不是 token，也不是模型调用次数。

真正被浪费的，是一次次已经跑通的经验。

你让 agent 分析一个帖子，第一次它摸索了一遍页面结构、登录态、正文和回复怎么抓、怎么区分观点和证据。下一次换一个帖子，如果所有步骤又重新靠对话临时组织，这次经验就没有真正进入系统。

你让 agent 排查一台服务器，第一次它知道了应该先看 inventory、再看日志、再做只读验证、最后把非敏感事实写回知识库。下一次如果还要从头提醒，这个流程也没有真正沉淀。

AI 编码和 agent 工作流的上限，不只取决于模型会不会做一次任务，而取决于系统能不能把一次任务变成下一次的起点。

这就是我做 skill-cli-workflow 的原因。

Prompt 不是能力

很多人会把一次有效协作归结为“我写了一个好 prompt”。

这当然有用。但 prompt 有一个天然问题：它太容易停留在会话里。

一次 prompt 能让当前任务跑通，却不一定能回答几个更重要的问题：

• 这个流程以后还会不会出现？
• 哪些步骤是稳定的，哪些只是这次碰巧有效？
• 成功能不能被验证？
• 哪些动作有安全边界？
• 该写进 AGENTS.md、Skill、CLI，还是只写进记忆？
• 什么时候应该升级，什么时候应该克制？

如果这些问题没有被回答，prompt 就只是一次对话里的临时组织能力。

它不是系统资产。

真正的能力资产，应该能在下一次任务开始时被触发、被执行、被验证、被复盘。

Skill 和 CLI 的分工

我现在更愿意把 agent 能力分成两层：

Skill 负责编排，CLI 负责执行。

Skill 不应该变成一篇长理论文章，也不应该承担复杂执行逻辑。它更像一份给 agent 的操作手册：遇到什么情况、先判断什么、调用什么工具、哪些边界不能碰、最后怎么验证。

CLI 则是实际执行层。它必须能离开模型单独运行，能在终端里复现，能通过 doctor 检查环境，能把机器可读结果写到 stdout，把人类日志写到 stderr。涉及写入时，默认应该 dry-run，真正修改必须显式 --apply 或 --yes。

这个分工看起来朴素，但它能解决很多 agent 工具链里的老问题：

• Skill 太重，agent 每次读一堆背景，执行却不稳定。
• 脚本太散，路径、依赖、参数、输出格式都靠临时记忆。
• MCP 被当成本地脚本壳，协议价值不大，排障成本却变高。
• AGENTS.md 被塞满细节，最后全局上下文越来越噪。

Skill + CLI 的意义，不是为了追求形式完整，而是把“什么时候做”和“怎么执行”拆开。

MCP 不是敌人

这套工作流不是“反 MCP”。

MCP 适合承担协议层职责：远端服务、多客户端集成、动态工具发现、schema 暴露、权限隔离、生态插件。这些场景里，MCP 有它自己的价值。

但如果一个 MCP 只是把本地脚本包了一层，而且真实需求是本地高频执行、终端复现、环境检查、结构化输出和安全确认，那它未必是最合适的形态。

这时候 CLI 往往更直接。

关键不在于 MCP 或 CLI 谁更先进，而在于这个能力到底需要什么边界。

如果需要协议，就保留 MCP。 如果需要可复现执行，就沉淀 CLI。 如果需要 agent 自动识别和编排，就再加 Skill。

工具形态应该服务流程，而不是反过来让流程迁就工具形态。

AGENTS.md 只应该做路由

我以前很容易把一些有用规则写进 AGENTS.md。

这很危险。

AGENTS.md 是全局入口。它适合写硬约束和短路由，比如“写入某些仓库前必须 fetch”“服务器重大变更后必须回写长期记录”“沉淀重复流程时先用 skill-cli-workflow 判断形态”。

但它不适合承载完整方法论。

一旦把具体 CLI 参数、项目事实、一次性复盘、长篇流程都塞进 AGENTS.md，agent 每次启动都会背负一堆不一定相关的上下文。短期看是“记住了”，长期看是在污染所有任务。

所以我现在把层次拆开：

• AGENTS.md：只写路由和硬约束。
• Skill：写操作规程。
• CLI：做真实执行。
• Memory / all_in_one：记录事实、经验、决策和证据。
• Long-task：承接跨会话复杂任务。

这几个东西不是互相替代，而是各自站在自己的层级上。

不是每件事都值得沉淀

skill-cli-workflow 最重要的部分，其实不是鼓励我多做 Skill 或多写 CLI。

它真正重要的是加了一道反过度工程化检查。

一个流程要不要沉淀，至少要问几个问题：

• 它会重复吗？
• 它容易出错吗？
• 它能验证吗？
• 它跨越 repo、浏览器、服务器、知识库或登录态边界吗？
• 它需要状态或记忆吗？
• 未来的我或别人会复用吗？

如果答案都是否，那就直接执行。

如果只是一个小提醒，写一条记忆或 AGENTS.md 短路由可能就够了。

如果只是固定几步命令，脚本或 checklist 就够了。

只有当它高频、可验证、需要复现，或者需要 agent 自动识别和编排时，才值得升级成 CLI 或 Skill + CLI。

沉淀不是越多越好。真正有用的系统，应该同时有升级路径和降级能力。

一个能力的成熟度

我现在会用一个很简单的成熟度模型看这些能力：

• L0：临时执行。
• L1：记录流程。
• L2：Checklist 或脚本。
• L3：CLI。
• L4：Skill + CLI。
• L5：Skill + CLI + Memory + Long-task + 测试。
• L6：可分享、可安装、可配置的产品化能力。

这个模型的价值不是分类本身，而是防止我一上来就做大。

比如分析 linux.do 帖子，第一次做完后，不应该马上写一个复杂 CLI。更合理的是先沉淀成一个轻量 Skill：规定怎么抓来源、怎么区分作者主张和 Codex 推断、什么时候看评论、什么时候写回知识库。

等至少几次真实分析后，如果发现抓取、抽字段、生成来源对象草稿这些步骤稳定重复，再升级成 CLI。

这比一开始就搭平台更稳。

它什么时候用

skill-cli-workflow 不是只在任务结束后才用。

它有三种时机：

第一种是事前设计。 当我已经知道一个流程要长期复用，可以先判断它应该是脚本、CLI、Skill、MCP，还是只写进 AGENTS.md。

第二种是事中转化。 对话中突然发现“这个流程以后肯定还会再用”，就停一下，先做架构决策，再决定是否沉淀。

第三种是事后复盘。 一个陌生流程第一次跑通后，不要马上抽象。先让真实过程发生，再回头把它整理成可复用资产。

我更信任第三种。

因为真实任务会暴露很多设计前看不到的东西：访问限制、登录态、工具失败、验证方式、边界条件、哪些步骤其实不稳定。

没有真实样例，抽象很容易变成漂亮但没用的框架。

最终目标：能力工厂

所以 skill-cli-workflow 对我来说，不是一个单独的 Skill。

它更像一个能力工厂的入口。

每次遇到可复用流程，它先回答：

• 这件事值不值得沉淀？
• 现在该沉淀到哪一层？
• 哪些产物要建，哪些不要建？
• 安全边界在哪里？
• 怎么验证它真的可用？
• 下一次什么时候升级？

这套判断稳定下来之后，AI 协作就不再只是一次次对话。

每一次任务都会多一个可能性：它不只是被完成，还可能变成系统的一部分。

这才是我现在最在意的方向。

不是让 agent 多记一点话，而是让它参与构建一套会积累的工作系统。