0. 引言过去两年很多开发者对 AI 工具的使用方式是不断尝鲜。今天试 Claude Code明天试 Cursor后天装几个 MCP 插件再过几天又收藏一堆 Prompt 模板和工作流配置。每次试用时都会觉得很兴奋因为 AI 确实能把当下的任务做快。但过一段时间回头看会发现真正沉淀下来的东西并不多。这就是现在很多 AI 使用者面临的真实困境AI 让一次任务变快了但没有让下一次任务天然变准。每次都要重新解释项目背景重新强调编码规范重新纠正同一个错误。看过的技术视频还停留在印象里读过的书还躺在书架上调过的 Prompt 分散在聊天记录里踩过的坑只存在于某个深夜的记忆中。问题的本质不在于模型不够强而在于我们还没有把经验沉淀成 Agent 能调用的结构。看过的视频没有变成可触发的规则读过的书没有变成可检索的索引调过的流程没有变成可复跑的工作流。知识停留在了消费阶段没有进入资产化阶段。0.1 能力资产化的五个层级这篇文章要讲的就是如何把知识、流程、经验、判断和组织协作方式变成可调用、可编排、可进化、可治理的能力资产。这条路线可以拆成五个层级层级解决的问题代表形式知识资产化看过、读过、收藏过但用不上book-to-skill、NotebookLM 视频库技能资产化每次都要重复教 AI 同一套规则SKILL.md、团队规范 Skill流程资产化多个任务节点需要串联和并行Dynamic Workflows、skill-flow-orchestrator反馈资产化Skill 写完后仍然跑不准SkillEvolver、EmbodiSkill、Goal 训练组织资产化个人效率没有扩散成团队能力超级个体、超级团队、AI 原生组织直观理解是Skill 是能力的最小沉淀单元Workflow 是多个能力的调度方式自进化是能力持续变准的机制治理是能力长期可信的前提超级团队则是这些能力在组织里的扩散形态。如果只停留在聊天框AI 只是一个临时助手。如果开始沉淀 Skills 和 WorkflowsAI 才会变成一个可持续增强的工作系统。1. 为什么普通 AI 用法沉淀不了能力1.1 一次性对话的局限大多数人不是没有用 AI而是用法停留在一次性提问。遇到问题把背景丢进去让模型给答案不满意再补一句跑偏了再纠正一下。这套方式可以解决眼前任务但很难积累长期能力。因为每一次纠正都留在当前对话里下一次新对话又要重新来一遍。模型没有真正继承你的经验只是在当前窗口里临时配合你。更麻烦的是上下文本身也有边界。你不能把三个月看过的所有视频字幕、一本 400 页技术书、一个团队半年的 PRD 和几十份项目复盘都塞进同一个聊天框。即使上下文足够大直接塞原始材料也不一定好。材料越多模型越容易在总结阶段混入自己补出来的内容。最后看起来很顺但你不知道哪些来自原文哪些是模型的合理想象。1.2 知识存储与使用场景的脱节传统的知识传递主要依赖三种方式口头传授、文档记录和代码注释。这些方式在小团队中尚可运作但随着规模扩大和复杂度提升问题逐渐暴露。开发者经常遇到这样的场景看了几十小时的技术视频当时觉得收获很大但真正需要使用时却想不起具体细节。这种困境的根源在于知识的存储形式与使用场景脱节。视频和文档是线性的信息载体而实际工作场景是高度碎片化和情境化的。开发者需要的不是完整重温一遍视频内容而是在特定场景下快速获取相关的操作指南和注意事项。真正要解决的不是一次总结而是长期调用。1.3 AI 辅助开发带来的新挑战AI 编码助手的出现改变了开发方式但也引入了新的问题。开发者发现每次与 AI 对话时都需要重复说明项目规范、团队约定和个人偏好。AI 没有记忆每个会话都是全新的开始。这导致大量时间浪费在重复性的上下文建立上。更深层的问题是AI 生成的代码往往缺乏一致性。同一个需求不同时间询问可能得到完全不同的实现方案。这种随机性让代码库变得混乱维护成本急剧上升。团队需要花费大量精力进行代码审查和重构才能保持代码质量。此外AI 的能力边界不清晰开发者不知道在哪些场景下应该完全依赖 AI哪些场景下需要人工介入。2. Skills - 能力的最小单元2.1 什么是 SkillSkill 不是一个更好看的 Prompt而是 AI 时代的工作协议。它把触发场景、执行流程、参考资料、示例和确定性脚本放进同一个目录让 Agent 在特定任务里自动读取该读的规则而不是每次都靠用户临时补充上下文。按 Codex Skills 的设计一个 Skill 最少需要一个SKILL.md。它的 YAML frontmatter 里核心字段是name和description这两个字段决定 Agent 什么时候会考虑加载这个 Skill正文则在 Skill 触发后才进入上下文。进一步扩展时可以加入references/存放详细资料scripts/存放可执行脚本assets/存放模板、图片、字体或样板工程。面向 UI 和安装管理的额外信息可以放在agents/openai.yaml这类元数据文件里但它不是所有 Skill 的通用必需项。这一部分可以直接看原始资料OpenAI Codex Skills 官方文档、OpenAI Skills Catalog 仓库、OpenAI Skills Catalog 源码 ZIP、Anthropic Skill authoring best practices 和 Anthropic《The Complete Guide to Building Skills for Claude》PDF。这些链接比二手介绍更重要因为 Skill 的字段、目录和加载方式以后可能继续变化。2.2 Skill 的核心设计原则一个真正好用的 Skill不是提示词集合而是 Agent 在特定场景下的工作协议。根据 Agent Skills 设计模式总结的 14 个模式可以归纳为五大类核心原则第一类发现与选择description 字段不是给人看的摘要而是 AI 选择 Skill 的关键触发信号。它必须包含足够的触发关键词让 AI 能够在合适的场景找到这个 Skill。但只写触发条件还不够还需要明确的排除条款。如果只定义适用范围而不定义排除范围多个 Skill 容易在边界场景产生冲突。例如一个文档格式化 Skill 应该明确排除博客写作和代码注释场景。第二类上下文经济很多 Skill 会从头解释一遍模型已经知道的常识把 JSON、REST API、数据库这些概念都讲一遍。听起来完整实际上是在浪费上下文。Skill 写作的默认前提应该是模型已经足够聪明。真正值得写进 Skill 的是普通模型不知道、但你希望它稳定遵守的东西比如团队约定、项目边界、工具路径、踩坑经验。当 SKILL.md 越来越长就要做渐进式披露主文件只保留触发条件、核心流程和下一步该读什么长参考文档放进 references可执行脚本放进 scripts示例放进 examples。第三类指令校准不是所有场景都适合写成必须、永远、禁止。开放型任务需要判断空间高风险任务需要强约束半结构化任务需要模板和检查点。Skill 应该根据任务脆弱程度决定约束力度。如果规则有边界就最好解释原因。比如使用构造器注入因为字段注入会降低可测试性比永远禁止字段注入更稳。前者给了 Agent 推理依据后者只给了机械命令。第四类工作流控制多步骤任务需要执行清单、自纠正循环和计划-验证-执行模式。执行清单能防止遗漏步骤自纠正循环能让生成、验证、修复形成闭环计划-验证-执行能把风险挡在副作用发生之前。尤其是数据库操作、部署和批量改写不能上来就动手。第五类可执行代码只要某个操作确定性强、经常重复、值得单独测试就应该抽成脚本而不是每次让模型现场写。脚本执行后只把结果返回上下文既省 token也减少随机性。2.3 从视频知识到可调用 Skill一个典型场景是视频学习。你订阅了十几个 AI 工程实践频道三个月看了几十个小时视频里面有 Claude Code 配置、Agent 架构、MCP 实战等技巧。看的时候很有启发看完之后却很难复用。因为视频知识天然是线性的而工作任务是场景化的。将视频内容转化为 Skill 需要解决两个核心问题上下文爆炸和来源混淆。单个 30 分钟技术视频的字幕可能有 15000 个 token30 个视频就是 45 万 token直接塞给模型不仅超出上下文还容易在综合阶段混入模型自己的发挥。NotebookLM 和 Dynamic Workflows 的组合提供了更好的解决方案。NotebookLM 负责从原始视频中提取带引用的信息Dynamic Workflows 负责任务编排和并行处理。NotebookLM 可以直接把 YouTube URL 作为 source自动提取字幕并且回答时附带引用Workflow 则把每个视频分配给子 Agent最后汇总、去重、聚类并生成 Skill。如果要复现这条路线先看原始入口NotebookLM、notebooklm-mcp-cli 的 PyPI 页面 和 jacob-bd/notebooklm-mcp-cli GitHub 仓库。这里不要只看教程截图最好直接看安装包和仓库说明确认当前命令、认证方式和 MCP 配置有没有变化。整条流程分四步首先对每个 source 提问抽取技术技巧、配置方法和可复用流程其次对所有 JSON 结果做聚类要求至少三个视频提到才形成有效主题然后为每个主题生成完整 SKILL.md包含触发条件、核心规则和来源引用最后写入 skills 目录并生成 HTML 报告。这个流程最有价值的地方不是某一个工具而是把看过的视频变成了下次能自动触发的能力。知识不再停留在记忆里也不只是笔记而是成为 Agent 在相关场景下可以调用的上下文和操作规程。2.4 从书籍到可调用 Skill同样的逻辑也适用于书籍。一本四百页 PDF 直接丢进模型既贵又容易撑爆上下文普通 RAG 只是捞相似段落能不能拼出答案要看运气。book-to-skill 走的是第三条路先把书结构化再按需调用。book-to-skill 会先判断书籍类型。技术书走更精细的解析路线尽量保留表格、代码块和章节结构叙事类书籍则以文本提取为主。然后它把整本书整理成核心框架、章节索引、术语表、模式表和速查表。真正重要的是它不会每次都把整本书塞进上下文。SKILL.md 只像目录一样记录框架和路由具体章节拆成独立文件。你问到哪一章Agent 才读取哪一章。这就是 Skill 里的渐进式披露。当你需要了解某个具体概念时Skill 会引导 Agent 读取对应的 reference 文件而不是每次都加载全部内容。这里建议把原始链接直接放给读者book-to-skill GitHub 仓库、README Raw、SKILL.md Raw、源码 ZIP。如果读者要自己安装或改造Raw 文件和 ZIP 下载比文章里的转述更可靠。3. Workflows - 从单点能力到流程编排3.1 为什么需要 Workflow当你只有几个 Skill 时手动调用还可以接受。写前端时叫 frontend-design修 CI 时叫 gh-fix-ci写 PRD 时叫产品文档 Skill。但当任务变成一整条业务流程单点召唤就不够了。比如要做一个 App 注销功能方案可能需要先调研竞品方案再读取公司现有产品约束然后撰写 PRD最后审查方案。如果每一步都要人手动召唤一个 Skill人仍然是流程调度器。单个 Skill 沉淀的是一项能力Workflow 沉淀的是一条工作流。skill-flow-orchestrator 这类编排引擎解决的就是这个问题。它不替代具体业务 Skill而是把多个 Skill 组织成一个 DAG有向无环图。有的节点必须先后执行有的节点可以并行有的节点是可选路径有的节点负责汇总。3.2 Workflow 的核心抽象一个完整的 Workflow 系统包含几个关键抽象Workflow 是完整流程Step 是任务节点Artifact 是每一步产物Dependency 描述强弱依赖Window 负责并行窗口Checkpoint 是人工确认点Synthesis 负责最终综合。有了这层编排Skill 就不再只是工具按钮而是流程节点。上游节点的产物会结构化传给下游长耗时节点运行时其他弱关联任务可以同步推进每个阶段结束还能停下来让人确认方向。这解决了多个关键问题多个 skills 不知道谁先谁后上游产物无法稳定传给下游有些节点必须递进有些节点可以并行还要把多路产物综合为统一交付物。典型例子是 PRD 生成流程先用调研 skill 收集行业方案再用公司业务 skill 提供内部约束然后用 PRD skill 产出方案最后用审查 skill 做产品评审。过去要一个个召唤现在可以封装成一个 project_prd用户只需要给目标和输入资料。Dynamic Workflows 是类似逻辑。区别在于它可以根据用户的一条 prompt 动态生成调度程序把任务拆给多个子 Agent 并行跑。比如视频转 Skill 的例子里每个视频一个子 Agent最后统一聚类和生成报告。这里也有一个提醒编排不等于全自动。很多流程应该是半自动的尤其是涉及产品方向、上线风险、数据迁移和对外发布时。好的 Workflow 应该内置 checkpoint让人只在关键位置做判断。4. Skills 自进化 - 让能力越用越准4.1 为什么 Skill 写完不等于跑准很多 Skill 刚写完时看起来不错测试也能通过但一遇到真实任务就会差一点。标题不够有点击动机代码风格和团队不一致PRD 少了业务约束审查报告抓不住真正风险。过去我们调 Skill方式很像手动改稿跑一次不满意补一句再跑一次。这个过程当然有效但很慢因为每一轮只有一条路径每次都要人判断下一句该补什么。Skills 自进化提出了另一种方法不要每次都让人手动补规则而是给 Agent 一个目标让它围绕目标自己多路试错。人给靶子主 Agent 判断差距Agent Team 并行探索不同改法。比如标题 Skill 的训练不是把一个高点击标题塞回 Skill而是让 Agent 分析为什么这个标题有效关键词在哪里表达结构是什么悬念来自哪里。最后写回 Skill 的不是答案而是方法。跑对的路径留下跑偏的规则删除或降级。下一次处理新文章时它不会复用那个标题而是复用产生好标题的判断方式。4.2 技能感知反思区分技能缺陷和执行失误EmbodiSkill 提醒了一个关键问题失败不一定说明 Skill 有问题。可能是技能定义有缺陷也可能是 Agent 执行时漏了步骤。前者应该改 Skill后者应该记录执行注意事项而不是污染核心规则。原论文可以直接看EmbodiSkill arXiv 摘要页以及 PDF 原文。EmbodiSkill 的关键设计是四类技能感知反思Discovery Reflection 记录成功任务中发现的新技能Optimization Reflection 优化已经成功但效率不高的技能SkillDefect Reflection 在技能本身有缺陷时修改技能ExecutionLapse Reflection 在执行失误时不改技能只记录执行注意事项。如果每次失败都改技能Skill 很快会积累大量错误补丁反而降低泛化能力。真正要写回去的是可复用的方法、稳定的约束和高频的陷阱。4.3 SkillEvolver策略多样化与对比更新SkillEvolver 走的是更系统的路线。它每轮生成多个不同策略并行尝试把成功轨迹和失败轨迹摆在一起对比提炼差异再用独立 Auditor 做格式、一致性、可执行性等检查拦截有害更新。原论文可以直接看SkillEvolver arXiv 摘要页以及 PDF 原文。这套方法也解释了为什么 Skill 不能无限膨胀。每一次失败都写规则最后 SKILL.md 会变成杂乱的事故日志。进一步看Agent 优化不是简单换更强模型也不是给它更多工具。更稳的优化对象是四层闭环上下文有没有被正确压缩工具有没有被限制到必要范围分工有没有拆出 reviewer 和 auditor验证有没有固定任务集和合并门禁。真正可落地的做法是先选一条高频任务做 baseline记录成功率、失败类型、token、轮次、工具调用和人工重写比例。然后只针对最高频失败改一个变量再用同一批任务复测。没有 baseline 的优化通常只是把系统改得更复杂。5. Skills 治理——让能力库长期可用到这里问题已经从“怎么写一个好用的 Skill”变成了“怎么管好一柜子 Skill”。这就像家里的工具箱买一两件工具的时候扔进抽屉就行但工具一多没分类、没标签、坏的不丢最后想找把螺丝刀都得翻半天。Skill 也是一样。刚开始只有几个 Skill 时你能记住每一个的用途。但当全局目录、项目目录、团队仓库里塞了几十上百个 Skill混乱就会冒出来名字一样但内容不同的触发条件互相打架的老的没人维护、新的不断添加的最后 AI 不知道该用哪个人也不知道该删哪个。治理的本质就是给这柜子工具立规矩。5.1 先看证据再动手清理很多人想到治理第一反应是“写个脚本一键清理过期 Skill”。这个方向其实是错的。治理工具最有价值的不是“替你删”而是“先把事实摊开给你看”。举个例子skills-refiner 这类工具的工作流程是这样的脚本先扫一遍——这个 Skill 在哪个目录是不是软链接文件哈希是什么SKILL.md写得全不全里面有没有rm -rf这种危险命令最近有没有被触发过把这些事实列清楚之后AI 再来分析“这条记录可能意味着什么”最后由人来拍板留还是删。为什么不能让脚本直接删因为**“没记录”不等于“没用”**。一个 Skill 半年没被触发可能是没人用了也可能是它专门处理某种季度才出现的场景很久没改可能是过时了也可能是写得太好不需要改。如果工具自动删了恢复成本远高于多留几个废文件的成本。脚本负责事实AI 负责解释人负责动作——这个顺序不能反。5.2 治理要解决的就是这五个常见麻烦把治理拆开看其实就是五类问题在反复出现。下面这张表把它们一次列清。问题你会看到的现象该怎么办质量不稳定Skill 写得像随手记的便签触发条件含糊规则像口号检查description写没写清有没有排除条款、例子、验证方式触发冲突用户随便说一句话好几个 Skill 都举手说“我能做”拿真实输入跑一遍路由看到底谁会被选中功能重复新写的 Skill 其实只是老 Skill 的一部分别新建回去扩展老的依赖不清改了一个基础 Skill结果三条流程同时坏掉维护“谁用了它它用了谁”的对照表过期难判看着像过时了又不敢删先打“候选”标签观察一阵再归档这五类问题归根结底就一句话**Skill 一旦被别人复用它就不再是你的私人文件而是会影响 AI 行为的公共资产。**公共资产再小也得有最低限度的规则。5.3 质量门禁做最简单的版本就够…详情请参照古月居