从聊天记录到.skill文件一次关于 AI 经验打包、风格蒸馏与工程复用的技术复盘先别急着下定义先看几个让人一下子就懂的例子如果几年前有人说未来大家会把下面这些东西做成“技能包”很多人多半只会把它当成一个段子把某个升学与职业规划博主的判断方式做成张雪峰.skill把某个强人格主播的聊天风格做成童锦程.skill把一个即将离职的同事蒸馏成同事.skill把某个老板的汇报偏好和决策口味整理成老板.skill把团队里那个最会回消息、最会安抚情绪、最会推进合作的人做成一个随时可以调用的聊天风格 Skill听上去像玩笑可从近些年开始这件事已经越来越不像玩笑了。它开始带着很明显的工程味道出现。有人讨论目录结构有人讨论.skill的打包方式有人讨论怎样做版本管理也有人开始争论授权边界和伦理问题。更重要的是它不再只是“像不像”的娱乐而逐渐变成了“能不能复用”“能不能协作”“能不能沉淀”的工程问题。张雪峰.skill之所以引人注意并不是因为“模仿名人”足够抓眼球而是因为它背后提出了一个更根本的问题一个人的经验、视角和判断方式是否能够被结构化并在新的任务里重复使用童锦程.skill则把另一个维度照亮了。它提醒我们Skill 不一定只属于严肃知识工作。它也可以属于风格、语气、人格视角甚至属于一种“看世界的方式”。换句话说Skill 不只是知识工具它也可能是表达工具、关系工具、创作工具。而“同事.skill”则是最容易让技术圈一下子认真起来的那个例子。网上很多人讨论过一个特别形象的场景团队里有个同事要离职了。真正麻烦的不是他会不会被替代而是他脑子里那套没有写进文档的东西会不会一起跟着消失。比如某个客户为什么总在第二轮需求会上突然变脸某个老系统为什么千万不要动那几行配置某个老板更吃哪种汇报方式哪类 PRD 一看就知道后面会炸哪类需求讨论表面平静实际上已经偏航过去这些经验很难沉淀。写进制度太硬。只靠口口相传又太脆弱。于是很多人第一次认真地想能不能在离职前把这个同事“蒸馏”成一个 Skill这里说的“蒸馏”当然不是复制一个人更不是拿一个工具去替代一个活人。它真正的意思是把一个人最稳定、最可迁移、最有团队价值的那部分工作方法沉淀下来。也许可以是周报同事.skill教团队怎么写老板一眼能看懂的周报交付同事.skill保存某位核心成员在交付期的风险判断方式评审同事.skill复现某位老同事拆需求、看边界、抓问题的顺序当你接受这个想法之后Skill 这件事就会一下子从“有趣”变成“有用”。它不再只是模仿谁说话。它开始变成一种新的生产方式把本来会随人流失的经验变成团队可继承、可复用、可打包的资产。这篇文档就想把这件事讲清楚。它不会只停留在“什么是 Skill”的定义层面也不会只写成一份操作手册。它会同时回答三个问题Skill 到底是什么它和 Prompt、模板、插件、Agent 有什么区别为什么 Skill 会在 AI 项目里越来越重要我们为什么会开始认真地把风格、方法和经验做成一个可分发的技能包换句话说这是一篇“概念 工程 观察 复盘”的混合型技术长文。目录什么是 SkillSkill 和 Prompt、模板、插件、Agent 的区别为什么 Skill 会越来越重要一个 Skill 通常由什么组成.skill文件到底是什么几类典型而有趣的 Skill 例子为什么 2026 年大家突然开始认真谈 Skill一个 Skill 从工程角度看最终会长成什么从人物风格到团队方法Skill 处理的到底是什么怎样判断一个 Skill 到底好不好用如果一个团队要系统化地做 Skill应该怎么落地Skill 如何帮助项目开发风险、边界与伦理问题结语1. 什么是 Skill1.1 一个直接但不失准确的定义最简单地说Skill 可以理解成给 AI 使用的一份可复用、可触发、可分发的专业工作说明书。这句话里最重要的词不是“说明书”而是“可复用”。以前我们让模型做事常见方式是临时打一段 Prompt补一点背景再追加几条要求希望它这次刚好理解对。这种方式当然也能工作甚至在很多简单任务里非常高效。但它有一个天然缺点太依赖当下。依赖这次输入是否完整。依赖操作者是否足够会写 Prompt。依赖上下文有没有丢失。也依赖模型这次恰好没有理解偏。Skill 的思路不一样。它不是每次都从零开始教模型“这次你该怎么做”而是先把一类任务中稳定有效的做法沉淀下来。比如这类任务的目标是什么先看什么再看什么哪些地方容易误判哪些事不能做输出应该长成什么样必要时要参考哪些文档、脚本或素材这样一来模型进入任务时就不是“裸奔”的而是带着一套已经整理过的方法进入任务。这就是 Skill 的第一层价值。它试图把偶然成功慢慢改造成可重复成功。1.2 Skill 不是知识点而是能力单元很多人第一次接触 Skill会本能地把它理解成“给模型补充知识”。这只说对了一半。知识当然可以写进 Skill但 Skill 更重要的其实是能力组织。一个像样的 Skill 往往同时包含任务目标处理顺序判断标准风格边界常见错误输出要求参考资料辅助脚本所以 Skill 的本质并不是“知道了什么”而是“遇到这类问题时应该怎么做做到什么程度最后输出成什么样”。举个例子就很清楚了。“知道什么是 PRD”不是 Skill“拿到一个模糊需求后如何追问、如何澄清、如何拆出用户路径、如何形成适合产品和研发共同阅读的 PRD”才更接近 Skill再比如“知道某个人的语气很自然”不是 Skill“如何保留一种轻快、自然、会接球、会照顾情绪、又不显得过度修饰的表达方式”才是 Skill所以更准确地说Skill 是一个可执行的能力块。它面向的不是知识展示而是任务完成。1.3 Skill 是 AI 工程里的软中间件如果把 AI 项目想成一个系统最底层是模型上层是用户需求中间一定还需要很多结构把两者连接起来。Skill 就是这种中间层结构的一种典型形式。过去这些中间层信息往往散落在README 里某个飞书文档里某位老同事脑子里一个越来越长、越来越难维护的 system prompt 里若干零碎脚本和模板里Skill 的意义就是把这些分散、脆弱、难继承的东西收拢起来组织成一个可以打包、复用、调用和迭代的能力单元。它比普通 Prompt 更稳定。比完整插件更轻。比纯文档更能指导执行。又比硬编码规则更有弹性。所以我更愿意把 Skill 看成 AI 工程中的一种“软中间件”。2. Skill 和 Prompt、模板、插件、Agent 的区别Skill 这个词很容易让人混淆因为它看起来和 Prompt、模板、插件、Agent 都有重叠。但它们其实不是一回事。2.1 Skill 和 PromptPrompt 更像一次性的即时指令。比如帮我总结这篇文章用更专业的语气改写这段话模仿某个人的口吻回复我这些都是 Prompt。Prompt 的优点是快、轻、便宜、上手门槛低。缺点也很明显容易散容易失忆容易随人变化也容易随着任务复杂度提升而越来越长、越来越脆。Skill 则更像把一类 Prompt 背后的稳定规律沉淀下来。它不取代 Prompt但它让 Prompt 不需要每次从零重写。可以这样理解Prompt 是一次会话里的临时命令Skill 是一类任务的长期工作说明2.2 Skill 和模板模板强调的是输出结构。比如周报模板PRD 模板邮件模板会议纪要模板模板的价值在于让输出“长得对”。但模板不一定能保证任务“做得对”。Skill 不只规定输出长什么样还会规定先分析什么后分析什么哪些信息没补齐时不要强行生成哪些边界条件要特别留意最终输出如何贴合使用场景所以模板偏静态结构Skill 偏动态能力。2.3 Skill 和插件插件强调的是工具能力。比如读邮箱发消息查日历调接口读写文件插件回答的是“能不能做”。Skill 回答的是“应该怎么做更对、更稳、更符合团队要求”。插件像手Skill 像方法。插件是入口Skill 是操作规范。2.4 Skill 和 AgentAgent 是完整的执行体。它接任务、做推理、调工具、产出结果。Skill 则更像 Agent 的技能卡。一个 Agent 可以没有固定 Skill纯靠模型能力临场处理但当任务变复杂、变专业、变长期之后Agent 如果能调用不同 Skill它的稳定性和可维护性会明显上升。因此Agent 是行动者Skill 是能力模块很多未来看上去很“聪明”的 Agent本质上就是“通用模型 工具系统 一组高质量 Skill”。3. 为什么 Skill 会越来越重要3.1 因为团队真正缺的往往不是回答而是稳定回答大模型早就能回答很多问题。真正棘手的通常不是“它会不会”而是它这次会不会做偏不同同事用它时结果是否一致下周再用还能不能维持效果新人接手后会不会完全跑样Skill 解决的是稳定性。而稳定性恰恰是工程化的前提。3.2 因为很多关键经验本来就没法自然写成代码一个团队里真正高价值的经验很多时候并不是数据库 schema也不是 API 文档而是这种东西这类客户到底在乎什么这类需求通常会在哪一轮翻车某个老板更吃哪种表达逻辑某位前辈为什么一眼就能看出某个方案有坑这些经验过去很难沉淀。写进代码太硬写进文档太散只靠人带人又太脆弱。Skill 刚好提供了一种中间形态。它既足够柔软可以描述风格、方法和经验又足够结构化可以被模型稳定地调用。3.3 因为 Skill 是经验资产化的一种新方式以前大家谈资产多半想到代码资产设计资产数据资产但在 AI 工程时代还有一种越来越重要的资产经验资产。Skill 恰恰是经验资产最容易落地的一种形式。你可以把它看成某个专家的判断框架某个岗位的隐性工作方法某种输出风格的稳定复现方式一旦 Skill 化它就可以复制、分享、组合、迭代、版本管理。这和“某个人一走很多东西就跟着没了”相比是完全不同的组织能力。3.4 因为它让 AI 项目开始真正长出工程结构没有 Skill 的 AI 项目很多时候像一连串即兴发挥。有了 Skill 之后项目会开始出现典型的软件工程特征模块化可复用可测试可维护可版本化这意味着 AI 项目不再只停留在 Prompt 工程而是在慢慢形成自己的工程对象和工程规范。4. 一个 Skill 通常由什么组成一个完整 Skill往往不只是一页说明。它通常至少有下面几层结构。4.1 核心说明文件最关键的通常是SKILL.md。它像是这个 Skill 的总说明书里面会回答这个 Skill 是干什么的什么情况下应该触发它什么情况下不该用它执行时有哪些规则输出时有哪些约束4.2 参考材料很多 Skill 的细节太多不适合全部堆在主文件里。这时候通常会放一个references/目录用来存放按需读取的资料比如风格说明品牌语气文档行业知识项目背景样例集合4.3 脚本与辅助工具有些 Skill 还会带scripts/目录。比如文本清洗脚本日志分析脚本批量转换脚本自动生成文档的脚本这时 Skill 就不只是“教模型怎么说”而是“教模型在什么情况下该调用什么工具”。4.4 模板和资产有些 Skill 会携带模板或资产文件比如输出模板PPT 母版品牌素材标准格式文件4.5 打包结构和元信息如果 Skill 要被分享、安装、分发它就不再只是零散文件而会有更明确的组织方式。通常包括根目录的SKILL.md辅助资料所在的references/如有需要的scripts/或assets/最终打包后的.skill文件这一步很重要。因为从这一步开始它就不再是“几段灵感文字”而是真正可交付的技能制品。5..skill文件到底是什么.skill这个后缀听起来很特别但本质上并不神秘。在很多 Agent 或 Skill 生态里.skill的本质通常就是一个包含标准目录结构的压缩包只是把扩展名从.zip改成了.skill。为什么要多这一层后缀因为后缀本身就是协议。它告诉使用者这不是普通压缩包这是一个技能包它有预期的结构它面向的是 Agent 或 Skill 系统这会极大降低沟通成本。正如你一看到.docx就知道是文档一看到.pptx就知道是演示文稿看到.skill也会自然联想到这是一个可安装、可分发、可复用的能力包。6. 几类典型而有趣的 Skill 例子6.1 张雪峰 Skill把判断框架做成能力包这一类 Skill 最有启发性的地方不在于“像不像某个人说话”而在于它试图抽取一个人的判断方式。如果只是收集语录那更像收藏夹如果能提炼出他如何判断约束条件他如何切换问题视角他如何把模糊决策压缩成更现实的问题那么它才开始接近真正的 Skill。如果读者想继续顺着看真实案例可以直接参考GitHub 仓库alchaincyf/zhangxuefeng-skill展示页张雪峰.skill Gallery6.2 童锦程 Skill把视角做成接口这类 Skill 的价值在于“看问题的方式”。它不一定高知识密度但可能高人格密度。比如更直接地下结论更快识别关系中的强弱变化更擅长把抽象情绪翻译成具体互动策略对应的公开案例也可以继续看GitHub 仓库hotcoffeeshake/tong-jincheng-skill展示页童锦程.skill Gallery6.3 同事 Skill把离职风险变成知识沉淀“同事.skill”之所以有现实感是因为它天然连接着组织知识管理的问题。很多团队真正最害怕的不是某个人离开这件事本身而是他的经验没法交接他的判断没法复现他的工作方法没被结构化把这部分能力蒸馏成 Skill就是在把离散经验变成组织基础设施。这类案例的代表性项目包括GitHub 仓库titanwings/colleague-skill开放技能页同事.Skill — Open Agent Skill6.4 人物风格 Skill把表达方式做成可调用能力人物风格 Skill 之所以有意思不只是因为它更容易被感知更是因为它让大家第一次意识到原来很多过去只能“靠感觉学会”的东西也可以被结构化。这种 Skill 不一定总是服务于娱乐。它也可能服务于品牌内容生产客服风格统一社交媒体运营角色化产品设计熟人式沟通界面的构建它的关键从来不在于“像不像一个人”而在于“能不能比较稳定地复现一种交流方式”。6.5 Code Review Skill把资深工程师的审查方式产品化再技术一点说一个好的 Code Review Skill 往往比很多人想象中更实用。它可以规定优先看行为回归再看边界条件再看测试覆盖不要先纠结表面格式问题findings 要按严重度排序这类 Skill 本质上是在把资深工程师的经验沉淀成团队可继承的方法。7. 为什么 2026 年大家突然开始认真谈 Skill如果把时间往前倒两三年很多人虽然已经在大量使用大模型但工作方式其实还停留在“每次重写 Prompt”的阶段。那时候大家最常见的讨论是Prompt 应该怎么写System Prompt 应该有多长怎样让模型更听话怎样给足上下文这些讨论当然重要但它们大多集中在“单次交互”层面。也就是说大家想解决的是“这次怎么让它答对”。而 2026 年开始讨论突然变了。越来越多人开始关心这类任务能不能以后都这么做这个方法能不能交给别人复用这个风格能不能沉淀下来这个流程能不能打包成一个标准能力这其实意味着问题已经从“单次成功”转向“持续成功”。一旦问题发生这种变化Skill 几乎就是最自然会长出来的答案。为什么偏偏是这两年我觉得至少有四个原因。第一模型本身已经足够强。早期大家没有那么强烈的 Skill 意识一个重要原因是模型连很多基础活都做不稳自然谈不上把复杂方法沉淀成包。可当模型的通用理解、通用写作和通用推理都上来之后新的瓶颈就不是“模型笨不笨”而是“团队有没有把自己的方法整理出来”。这个时候Skill 的价值才真正凸显。第二AI 使用者正在从个人探索走向团队协作。一个人自己用模型可以靠手感可以靠临场发挥也可以靠记忆去维持某种 Prompt 风格。但一旦进入团队协作问题就完全不一样了。你需要让不同人用出大体一致的结果需要让新人能快速上手需要让经验能被继承。这些都在逼着团队从“写 Prompt”升级到“写 Skill”。第三大家终于意识到真正稀缺的不是模型能力而是人的方法论。模型越来越便宜能力越来越接近真正拉开差距的往往不再是“你接的是哪家模型”而是“你有没有把自己的工作流、表达风格、判断框架整理成系统化资产”。Skill 之所以被认真对待就是因为它恰好是方法论资产化最轻的一种载体。第四开源社区和内容社区都在强化这种感知。名人 Skill、同事 Skill、品牌 Skill、岗位 Skill 这些案例不断冒出来大家会突然发现原来 Skill 不是一个非常抽象的概念它完全可以贴着现实工作去长出来。你今天可以做一个聊天风格 Skill明天也可以做一个需求评审 Skill后天甚至可以做一个“老板汇报口味 Skill”。当案例足够多生态感就出现了。所以2026 年大家突然开始认真谈 Skill并不是因为这个词本身有什么魔力而是因为整个 AI 使用方式在成熟。我们从“怎么问”走到了“怎么沉淀”从“怎么答对一次”走到了“怎么长期复用”。而 Skill正好站在这个转折点上。8. 一个 Skill 从工程角度看最终会长成什么这一节不再去拆具体某一个 Skill 的内容而是退后一步从更工程化的角度来看一个 Skill 真正做完之后通常会呈现出什么形态。很多人第一次接触 Skill脑海里的想象其实很简单大概就是一段长 Prompt或者一页写满规则的说明文档。这个想象不能说完全错但它只看到了最表层。一个真正能复用、能协作、能长期维护的 Skill往往不会只是一页纸。它更像一个小型的能力包。这个包里最核心的不一定是“字多”而是“结构清楚”。它至少要回答几个问题它是干什么的它应该在什么情况下被调用它不应该处理什么它的执行顺序大致是什么它依赖哪些参考资料它最后要产出什么换句话说一个成熟 Skill 的关键不在于堆砌信息而在于把信息组织成一种可调用的秩序。8.1 Skill 的价值往往体现在“分层”上我们平时做很多文档时最大的毛病就是把所有东西都往一个文件里塞。背景、规则、例子、边界、补充说明、脚本调用方式全挤在一起。短期看省事长期看非常难维护。Skill 比普通文档更需要分层。因为它天然面向复用而只要一面向复用结构问题立刻就会变得重要。通常来说一个 Skill 至少会隐含三层触发层告诉系统或使用者这个 Skill 什么时候该用执行层告诉模型一旦用了之后该怎么做参考层告诉模型和维护者遇到细节问题时应该去哪里补背景这三层不一定非得明面上写成三个模块但它们几乎总会存在。只不过做得好的人会把它们拆开做得不够好的人会让它们混成一团。8.2 一个 Skill 好不好维护往往比它第一次好不好用更重要很多人第一次做 Skill注意力全部放在“能不能跑通”上。这当然合理。可如果一篇文档只看第一次运行是否成功往往会忽略掉一个更长期的问题它以后还能不能改从工程视角看一个 Skill 有两个生命周期它第一次被写出来的时候它后面被不断修改、替换、扩写、校准的时候真正痛苦的常常不是第一步而是第二步。因为一个 Skill 一旦开始被真实使用就几乎一定会遇到这些问题某些规则写得太死了需要放松一点某些描述太泛了需要更明确一点某些例子已经过时了需要替换某些边界原来没想到现在发现必须补上某些参考资料太散需要重新归档如果一个 Skill 结构不清晰后面每改一次都会像拆旧房子。反过来如果一开始就按“可维护”的思路组织那它就更像一个长期可用的模块而不是一份一次性产物。8.3 Skill 很像“会说话的软件构件”我越来越觉得Skill 这个东西特别有意思的一点在于它不是纯代码也不是纯文档。它更像一种介于两者之间的构件。它不像代码那样刚性不必精确到每一步都不可偏离但它也不像普通文档那样松散不只是写给人读、读完就结束。它的特别之处在于它既要被人理解也要被模型执行。从这个角度看Skill 很像一种“会说话的软件构件”它有接口感它有边界它有输入输出预期它有内部组织方式它甚至有版本和迭代路径只不过它的主要材料不是函数和类而是规则、样例、背景和方法。8.4 为什么很多 Skill 最后会走向“包”而不是“段落”如果你只是自己临时用用一段 Prompt 当然也可以。但一旦进入协作情况就会变。协作会天然地推动 Skill 走向“包”的形态而不只是“段落”。因为只要一协作下面这些问题就会自动冒出来别人怎么知道这个 Skill 是干什么的别人怎么快速知道它适不适合当前任务如果要修改改哪里最合适如果要补材料补在哪一层如果要分发交付形式是什么一段 Prompt 很难回答这些问题。一个包则可以。所以从工程演化的角度看Skill 之所以经常最终走向目录、走向标准结构、走向.skill打包并不是为了形式好看而是因为形式本身在为协作服务。8.5 Skill 的真正魅力是把“中间层经验”第一次安顿下来很多组织里最珍贵的不是纯知识也不是纯逻辑而是中间层经验。所谓中间层经验就是那种还没精确到足以写成代码但又绝不是随便说说的感觉已经在真实工作里被反复验证过却总是漂浮在不同人手里、不同文档里、不同习惯里Skill 的最大魅力就在于它特别适合安顿这种东西。它可以安顿方法。可以安顿风格。可以安顿套路。也可以安顿判断框架。从这个意义上看Skill 不只是“让 AI 更会做事”的工具它还是一种新的知识安置方式。它在帮团队处理一类过去最难处理的资产那些没有完全代码化、也没有完全制度化但又确实对结果有巨大影响的经验。8.6 所以一个 Skill 最终长成什么样并没有唯一答案讲到这里其实反而应该再退一步。因为很多人一接触 Skill就会特别想知道一个“标准答案”Skill 到底应该有几个文件规则到底应该写多长例子应该放多少到底是 Markdown 还是 JSON 更好这些问题当然都重要但它们没有一个放之四海而皆准的唯一答案。真正更重要的是这个 Skill 是否满足以下几件事别人一看就知道它大致是干什么的模型一调用就知道大致该怎么做后续维护者知道怎么补、怎么删、怎么改它在真实协作里能稳定发挥作用只要这几件事成立它的具体长相其实可以很灵活。也正因为如此我会更愿意把 Skill 看成一种“工程形态”而不是一张固定模板。它有共性但不必僵化。它讲结构但不等于讲死板。它真正要求的不是统一外观而是统一可复用性。9. 从人物风格到团队方法Skill 处理的到底是什么如果只看表面很多 Skill 的案例似乎差异很大。有的在模仿一个人的说话方式有的在保存某个同事的工作经验有的在统一品牌语气有的则在规范代码评审输出。可如果往深一点看这些东西其实都在处理同一类对象方法化但又尚未代码化的经验。这是一个非常关键的认识。因为它意味着Skill 真正处理的不是“文字”也不是“设定”而是那些已经在真实世界里被证明有用、却还没有找到合适容器的中间层能力。这类能力往往有几个特征它不是纯事实所以知识库装不下它不是纯逻辑所以代码写不出来它不是纯格式所以模板不够用它不是纯一次性指令所以 Prompt 太脆弱换句话说Skill 的出现其实是在替 AI 工程接住一类过去长期漂浮着的东西。9.1 为什么“风格”会成为 Skill 的高频入口人物风格、品牌风格、团队语气之所以经常成为 Skill 的切入口不是因为它们最重要而是因为它们最容易被感知。人对风格特别敏感。你很容易看出一段话“像不像某个人写的”也很容易感觉到一封邮件“像不像这个团队发的”。也正因为这种差异很容易被识别大家才会率先想到把它 Skill 化。但风格只是入口不是终点。真正更值得注意的是一旦你开始认真做风格 Skill你很快就会发现自己其实在处理的根本不是几个口头禅而是更深层的东西如何回应情绪如何安排节奏如何保持关系姿态如何决定说到什么程度如何在轻松和有效之间平衡也就是说所谓风格最后会把你带回方法。9.2 为什么“同事 Skill”会让工程师更有感觉如果说人物风格 Skill 让人感觉到“好玩”那同事 Skill 则更容易让工程师感觉到“这玩意儿是真的有用”。因为工程师天然很熟悉一种问题项目里真正最麻烦的不是显性的文档缺失而是隐性的经验消失。显性的东西缺了还能补。API 文档丢了可以重写配置忘了可以重新查流程断了可以重新画图。可隐性的东西一旦没了团队会出现一种特别微妙但特别致命的损耗明明都在做同样的事效果却变差了明明流程还在判断却不准了明明文档齐全协作却更费劲了这时候你才会意识到原来团队里真正稀缺的并不是信息本身而是“怎么用这些信息”的方法。而 Skill 最适合装的恰恰就是这层东西。9.3 Skill 的本质是把“怎么做”从人身上轻轻剥离出来这里要特别注意是“轻轻剥离”不是“彻底替代”。因为很多人一听到“把某个人做成 Skill”就会本能地有一种不适感好像这件事在把人降格成工具。这种警觉并不是没有道理所以边界必须讲清楚。但如果换个角度看Skill 真正做的事情其实更克制。它不是在复制一个完整的人而是在尝试把这个人身上那些已经被验证有用、而且适合迁移的工作方法提取出来。比如不是把一个产品经理整个人复制下来而是把他拆需求的方式提取出来不是把一个老板整个人复制下来而是把他读汇报时在意的重点提取出来不是把一个内容创作者整个人复制下来而是把她构建语气和节奏的方式提取出来这种“轻轻剥离”的能力其实非常有价值。因为它让经验第一次有机会脱离个体、进入系统。9.4 从这个角度看Skill 很像经验的压缩格式这也是我越来越喜欢用“压缩”来形容 Skill 的原因。经验原本是散的。它长在聊天里长在邮件里长在会议里长在某些临场判断里。它没有明确边界也没有统一格式甚至很多时候连拥有这份经验的人自己都说不清它到底是什么。而 Skill 做的事情很像一种压缩把散乱的表达压成稳定风格把分散的动作压成执行顺序把模糊的感觉压成边界说明把个人的手感压成团队可继承的能力单元当然压缩一定会有损失。Skill 不可能完整保留一个人的全部复杂性。但只要它能保留最重要、最可迁移、最有复用价值的部分这种压缩就是成立的。也正因为如此Skill 从来不该被吹成“复制某个人”而更适合被理解成“对某类经验的工程化压缩”。10. 怎样判断一个 Skill 到底好不好用很多人做完 Skill 之后最容易犯的一个错误是看着文档本身觉得“挺像那么回事”就默认它已经可用了。其实远远不够。一个 Skill 好不好用不是看它写得漂不漂亮也不是看它堆了多少规则而是看它在真实任务里能不能稳定地产生对的结果。换句话说Skill 也需要测试。10.1 第一种测试看它是否稳定最基础的测试不是看一次成功而是看多次调用是否还能保持同一风格、同一结构、同一判断方向。如果一个 Skill 只有在“刚好那个输入”下才看起来像样它就还不是一个成熟 Skill它更像一个碰巧写对的 Prompt。10.2 第二种测试看它是否抗干扰真实任务环境从来都不干净。输入会有噪声要求会临时变化甚至调用它的人自己也未必特别清楚想要什么。所以一个 Skill 是否成熟很大程度上要看它抗不抗干扰。比如当用户的问题比较乱时它还能不能抓住主线当上下文里混入不相关信息时它会不会被带偏当调用者提出和 Skill 风格相冲突的指令时它能不能维持边界真正强的 Skill不是“理想环境里很好看”而是“现实环境里也不容易崩”。10.3 第三种测试看它是否可交接这是一个特别容易被忽略但在团队里非常重要的测试维度。你可以把一个 Skill 丢给不参与制作的人让他直接用。如果对方能够快速理解这个 Skill 是干什么的什么时候该用它它会产出什么它有哪些边界那这个 Skill 才真正具备协作价值。因为 Skill 的意义不只是“作者自己以后能复用”而是“团队以后都能复用”。10.4 第四种测试看它是否可迭代一个坏 Skill 还有一个常见特征第一次写出来之后就再也改不动了。因为它没有分层没有模块没有留出修订空间。每次想改一点点都像在拆一团缠在一起的线。一个好的 Skill 则应该具备清晰的可迭代性哪些规则可以改哪些例子可以换哪些边界可以补哪些参考文件可以独立更新这也是为什么我一直认为 Skill 应该尽量做成“主说明 参考文档 可选脚本”的结构。因为只有结构清晰后续迭代才不会痛苦。10.5 第五种测试看它是否真的节省了团队成本最终Skill 不是为了看起来高级而是为了节省成本。这里的成本不只是 Token 成本更包括沟通成本培训成本出错成本返工成本风格不一致带来的协作成本如果一个 Skill 写完之后团队还是每次都要重新解释一遍还是经常生成跑偏的东西还是高度依赖制作它的那个人在旁边盯着那它就还没有真正完成它的使命。所以判断一个 Skill 是否好用最核心的问题其实只有一个它有没有把原本依赖人的稳定能力真正转移到可复用结构里去。11. 如果一个团队要系统化地做 Skill应该怎么落地很多人第一次做 Skill通常都是从一个具体小需求开始的。比如做一个人物风格 Skill做一个周报 Skill做一个 Code Review Skill。这当然很好也是最自然的起点。但如果一个团队真的要把 Skill 当成长期资产那它迟早会走到下一步不是“做一个 Skill”而是“做一套 Skill 体系”。11.1 先从高频、可重复、容易失真的任务开始不要一上来就想做一个无所不能的大 Skill。那样很容易写成一团巨大的说明文字既难触发又难维护。更好的方式是先从那些高频、可重复、而且特别容易因人而异的任务开始。比如周报生成需求澄清PRD 整理品牌语气改写面向老板的汇报风格转换代码评审输出这些任务有几个共同点出现频率高、重复成本大、风格要求强、组织里往往已经有隐性标准。它们特别适合 Skill 化。11.2 用“小而清晰”的原则而不是“又大又全”的冲动很多团队刚开始做 Skill 时很容易想一步到位。希望一个 Skill 既能分析需求又能写 PRD又能改语气又能顺手做汇报还能自动补几个老板喜欢的视角。结果通常是看起来什么都能做实际上什么都做不稳。更好的原则是“小而清晰”。一个 Skill 只解决一类相对稳定的问题。这样有几个好处触发条件更明确规则更容易写准测试更简单后期替换和组合都更轻松很多真正成熟的系统最开始都不是靠一个超级大模块取胜而是靠一堆边界清楚的小模块慢慢组合起来。11.3 给 Skill 做命名规范和目录规范一旦 Skill 开始变多命名和目录就会变得非常重要。否则很快就会出现这种混乱大家都记不住哪个 Skill 干什么文件名风格不统一有些 Skill 有参考文件有些没有有些 Skill 有脚本有些脚本放在莫名其妙的位置所以团队最好尽早建立最简单的规范。比如名字尽量直接反映用途每个 Skill 至少有一个SKILL.md参考资料统一放references/如有脚本统一放scripts/分发版本统一用.skill后缀你不需要一开始就把规范做得像工业标准但至少要保证“别人看到后能接手”。11.4 建立最简单的 Skill Registry当 Skill 变多之后团队最好维护一个最简单的索引页。它不一定非得是复杂系统哪怕只是一张表格或一份目录文档也会非常有帮助。这个索引里至少应该写清楚Skill 名称用途适用场景维护人最近更新时间是否已经测试过这一步的意义很大。因为 Skill 一旦从“个人作品”变成“团队资产”它就需要被发现、被理解、被管理。Registry 本质上就是团队的 Skill 地图。11.5 把 Skill 当成活资产而不是一次性交付物很多团队做文档时有一个老毛病一写完就当结束。Skill 如果也这么对待很快就会过时。真正应该做的是把 Skill 当成一种活资产。也就是说它可以迭代它应该校准它会因为团队风格变化而更新它会因为业务变化而重写部分规则你甚至可以把 Skill 想成一类“轻量软件模块”。它不一定写成代码但它同样需要维护。12. Skill 如何帮助项目开发很多人会先把人物风格 Skill 当成一个有趣的小玩具。但如果往项目里看它其实非常实用。12.1 帮团队复制高质量做法一个团队里总会有几种“某个人特别会”的能力特别会写周报特别会拆需求特别会做评审特别会给客户解释复杂问题特别会在群里稳住节奏这些能力如果能被 Skill 化整个团队的平均输出质量都会抬高。12.2 帮新人更快进入语境很多 onboarding 难不是因为资料不够而是因为资料没有方法感。Skill 恰好能补这一层。新成员不只是“看文档”而是可以直接调用团队已经整理好的能力模块快速理解这个团队怎么拆需求这个团队怎么做 code review这个团队怎么写对外说明这个团队怎么维持沟通风格12.3 帮 AI 输出更像团队真正想要的样子通用模型可以写东西但不一定像你团队的人写的。Skill 的作用就是缩小这个差距。让输出不仅“没错”而且“对味”。12.4 帮组织沉淀隐性知识未来很多团队的知识层可能会慢慢分成四类数据库里放事实文档里放规则代码里放逻辑Skill 里放方法和风格这会是一种非常有意思的组织知识结构。12.5 帮项目形成可组合的能力库当一个团队开始拥有多种 Skill 时就可以做组合需求分析 Skill用户研究 SkillPRD Skill品牌语气 Skill邮件整理 Skill代码评审 Skill项目复盘 Skill未来很多强 Agent 真正厉害的地方不一定只是模型更大而是背后挂着一整套高质量 Skill 库。13. 风险、边界与伦理问题Skill 很强但越强越要讲边界。13.1 风格模仿不等于人格复制一个 Skill 再像也不等于当事人本人。它可以模仿表达方式判断习惯消息节奏风格偏好但它不应该被误认为当事人真实授权发言当事人在当前时刻的真实态度当事人对所有问题的完整观点13.2 私人材料的使用必须谨慎如果素材来自聊天记录、邮件、内部文档那么合法性、伦理性、授权边界都要认真考虑。你可以主动为自己做 Skill但替别人做 Skill尤其是准备传播、共享、商业化时边界一定要非常清楚。13.3 归因错误会直接破坏质量人物 Skill 绝对不是“把素材丢给模型它自己悟”那么简单。它需要人工校对需要反馈回路也需要持续修正。这也是为什么人物 Skill 一旦要走向复用就必须从“像不像”升级到“准不准”。13.4 有趣的 Skill 也会带来误导风险比如把娱乐型人格 Skill 当成专业咨询工具把强风格表达误当成普适建议把“像某人”误当成“等于某人”这也是为什么一个成熟 Skill 应该写清楚适用范围非适用范围风险提示14. 结语如果只把 Skill 理解成一种新文件格式那就把它看小了。Skill 真正重要的地方在于它让我们第一次有了一种相对低门槛、但足够工程化的方法去处理这样一件事如何把人的经验、团队的方法、项目的风格、任务的套路整理成可复用、可分发、可继承的能力单元。这件事看起来像 Prompt 工程的升级实际上更接近软件工程、知识工程和组织经验管理的交叉点。它在做两种转化把零散经验转化为结构化能力把个人方法转化为团队资产也正因为如此我越来越觉得Skill 最值得重视的地方不在于它能不能“模仿得很像”而在于它第一次让很多原本漂浮在组织里的东西有了一个很适合落地的容器。过去你当然也可以做知识库也可以写 SOP也可以写模板也可以把某些逻辑做成工具。但在大量真实工作里真正最重要、最难保存的那部分东西往往既不是纯知识也不是纯流程更不是纯代码。它更像一种夹在中间的东西有方法但还没严格到能直接写成程序有风格但又不是纯审美偏好有经验但又不只是事实条目有判断但又很难被一句模板写完而 Skill 恰好特别适合装这种“夹层能力”。为什么我会说它像基础设施因为基础设施的一个典型特征就是一开始大家不太在意等用起来之后才发现没有它很多协作根本跑不顺。未来团队如果真的大量依赖 AI 协作就会越来越需要下面这些东西一套统一的表达方式一套统一的任务拆解方式一套统一的风险识别方式一套统一的输出质量下限如果这些东西全靠每个人临场发挥那团队规模一大就一定会乱。反过来如果这些东西能够慢慢 Skill 化那么很多原来必须靠“熟练老员工在场”才能维持的秩序就会逐渐变成一种更稳定的系统能力。从这个角度看Skill 很像过去软件工程里那些看起来不起眼、但一旦缺了就全局难受的东西。比如编码规范、组件库、CI 流程、Lint 规则、测试框架。它们刚出现时也经常被嫌麻烦、嫌形式主义。但后来大家都明白了真正的大规模协作离不开这些中间层秩序。Skill 很可能就是 AI 协作时代的其中一种新秩序。它不是最终目的。它也不会替代所有东西。但它会成为很多东西之间的连接面。连接人和模型连接经验和执行连接个人方法和团队资产连接一次次成功和长期稳定。一旦从这个角度去看Skill 就不再只是一个“有点新鲜的词”而会越来越像未来组织里一种非常自然的基础设施部件。到了那个时候Skill 就不会再只是一个有趣的新名词。它会成为 AI 项目开发里最重要的基础设施之一。附本文可延展的方向如果后续要继续扩写这篇文档还可以自然延展出几个方向Skill 的版本管理与测试方法如何为团队建立内部 Skill Registry人物 Skill 与品牌 Skill 的差异Skill、Workflow、Agent 之间的组合关系Skill 的合规与授权机制这些都非常值得继续写下去。因为 Skill 现在看起来像一个“新鲜玩意儿”但它很可能正在变成未来 AI 工程里最常见、也最关键的中间层对象之一。附可直接继续浏览的开源链接为了方便读者顺着看真实项目这里再集中放一组文中提到或相关的公开链接人物/同事类 Skill 聚合仓库tmstack/awesome-persona-skills“同事.skill”代表项目titanwings/colleague-skill“张雪峰.skill” 示例仓库alchaincyf/zhangxuefeng-skill“童锦程.skill” 示例仓库hotcoffeeshake/tong-jincheng-skill更偏“蒸馏方法论”的项目alchaincyf/nuwa-skill另一个 persona-skill 聚合页codeman008/awesome-distillhub-persona-skills