最近技术圈最荒诞又最真实的一幕：一个叫“同事.skill”的GitHub项目，5天狂揽超6600颗星，冲上热搜。紧接着，“前任.skill”“老板.skill”“父母.skill”——十几个衍生项目排着队冒了出来。网友辣评：“同事，散是Token，聚是Skill。”
但这波热度真正让人后背发凉的，不是Skill本身有多强，而是社交媒体上蔓延开的那种恐慌——如果员工的技能可以被炼化成Skill，是不是被炼化的那个人，就可以很容易被替代了？
有人在网络上写道：“大模型+同事skill+记忆插件=你的同事。”
作为一名一线技术专家，我每天都能听到团队里这样的声音：“这东西会不会让我明天就失业？”今天不聊焦虑，用工程视角拆开Skill的底层逻辑，看看它到底解决了什么问题，以及它离替代人还差多远。
目录
- 一、现象——技能打包，席卷全网
- 二、本质——Skill不是新技术，是工程补丁
- 三、核心机制拆解——三层披露与Harness哲学
- 四、产品对比——三种AI编程范式
- 五、工程落地启示——你该怎么用
- 六、趋势判断——脚手架会越来越薄
一、现象——技能打包，席卷全网
2025年10月，Anthropic为Claude正式发布Skills功能。两个月后，Anthropic将Agent Skills发布为开放标准，微软、OpenAI、Cursor、GitHub相继采纳。
这条时间线很重要。Skill并非横空出世的新物种。从发布到爆火，中间隔了将近半年。真正让它在国内出圈的不是技术本身，而是“炼化同事”这个戏剧性的叙事。
同事.skill做的事情，是把一个人的聊天记录、工作文档和行为模式提炼成一份Markdown格式的指令文件，然后让大模型按照这份指令来模拟回应。它模拟的是表达风格和工作流程的外壳。至于模拟那个人真正的专业判断力？还差得很远。
但恐慌已经传开了。各个技术社群都在讨论同一个问题：我的技能，是不是也能被打包成一个Skill？
要回答这个问题，得先搞懂Skill到底是什么。
二、本质——Skill不是新技术，是工程补丁
说白了，Skill的本质就是结构化的提示词。
它和你在对话框里手写的Prompt之间，不存在智能程度的质变。区别仅在三个工程维度：第一，Skill可以被AI自动发现和按需加载，不用每次手动粘贴；第二，它能携带参考文档和脚本，形成一个自包含的指令包；第三，它遵循开放标准格式，理论上可跨平台复用。
Skill不涉及深度学习意义上的知识蒸馏，不改变模型本身的参数，不创造任何新的推理能力。它只是在模型之上叠加了一层可复用的任务指令。
如果大模型是一个什么都懂但什么都不精的通才毕业生，Skill就是你递给他的工作手册。手册写得再详细，通才还是那个通才。
核心在于，Skill解决的不是模型能力问题，而是工程化问题。
在没有Skill的时代，你要让AI做一件特定的事——比如“按公司品牌规范写PRD”——你得每次手动粘贴一大段提示词。有了Skill，这段提示词被打包成一个可被AI自动发现和加载的模块。AI看到相关任务，自己就去翻对应的手册。
这就是全部。
那么问题来了：既然这么简单，为什么大家都在讨论它？
因为Skill暴露了一个更大的趋势：AI编程正在从“大模型能力竞赛”转向“工程化落地竞赛” 。
三、核心机制拆解——三层披露与Harness哲学
3.1 渐进式披露：不让Skill撑爆上下文
Skill的核心设计理念是“渐进式披露”。一个技能的信息分三个层次，AI按需逐步加载：
- 第一层 元数据：每个Skill的SKILL.md开头都有YAML格式的名称和描述。AI启动时只加载这部分到系统提示中，大概占几十个token，几乎不占上下文窗口。
- 第二层 SKILL.md正文：如果AI判断某个Skill与当前任务相关，它会加载完整的Markdown指令文件。里面包含任务的具体步骤、注意事项、示例等。
- 第三层 附加文件与脚本：对于更复杂的场景，Skill可以附带脚本文件（Python/Shell）或参考文档。只有当需要时，AI才会调用或读取这些文件。
这套机制的核心价值是：让Skill可以包含海量信息，却不怕超出上下文窗口限制。一个文档处理Skill可以附带完整的PDF规范文档，但AI只有在你真的需要填表时才会去翻那部分内容。
flowchart TD
A[用户请求] --> B{AI 检索可用Skills}
B --> C[加载元数据<br>name + description<br>~几十个token]
C --> D{判断相关性}
D -->|相关| E[加载SKILL.md全文<br>任务指令+示例]
D -->|不相关| F[继续使用通用能力]
E --> G{是否需要脚本/附加文件}
G -->|是| H[加载/执行脚本<br>或读取参考文档]
G -->|否| I[执行任务]
H --> I
I --> J[返回结果]
F --> J
3.2 Harness：为什么Agent的难点不在模型
真正值得关注的不是Skill本身，而是Skill运行的那个系统。
Claude Code的TypeScript源代码跨越了约1900个文件，超过51万行代码。这还不包括模型权重。这么多代码在做什么？围在模型外面搭一套运行时。
这套“外壳”被逆向工程师称为Harness：一个本地运行时环境，把LLM包裹在工具、记忆和编排逻辑之中，让模型能在现实世界里行动。
Harness的核心是一个叫TAOR的循环：Think-Act-Observe-Repeat。
这里有一个非常反直觉的设计哲学：Orchestrator被设计得极其“愚蠢”，只负责驱动循环、执行工具调用、感知结果。所有的推理、决策、何时停止，全部都交给模型。运行时不知道代码是什么，不知道文件在哪，它只是跑循环，让模型决定下一步。
运行时越笨，架构越稳定。
把智能下沉到模型，把确定性留给框架。这和早期LangChain试图在框架层做各种“聪明编排”的路线形成了鲜明对比。Claude Code的做法是，TAOR循环的核心逻辑大约只有50行，但给了模型无限的操作空间。
3.3 工具设计哲学：四个原语就够了
同样，在工具层也遵循这个“笨”的哲学。Claude Code没有给模型配备100个专项工具，而是只提供四种能力原语：Read、Write、Execute、Connect。其中Bash是通用适配器，允许模型使用任何人类开发者会用的工具——git、npm、docker，全部通过shell组合完成。
不要构建100个工具，给模型一个shell，让它自己组合。
这就是为什么Skill看起来“太简单”但仍然有效的原因。Skill本质上是在这个Harness框架之上的一种声明式扩展方式。它不改变框架本身，只是给模型提供更好的“工作手册”。
四、产品对比——三种AI编程范式
理解了Skill的底层逻辑，再看当前AI编程工具的格局，会发现一个有意思的分层。
2026年3月The Pragmatic Engineer的调查数据显示了一个清晰的分化：Claude Code以46%的好评率成为最受欢迎的AI编程工具，远超Cursor的19%和GitHub Copilot的9%。
这三种工具代表了三种完全不同的范式：
GitHub Copilot 是最易触达的选择，嵌入式完成在日常IDE中，适合行级补全和简单问答。它本质上是一个“增强版自动补全”，不试图理解你的整个项目。
Cursor 提供最深度的AI-IDE集成，把AI嵌入到了编辑体验的每一层。它是一个AI原生的IDE，适合需要深度整合的场景。
Claude Code 拥有最强的推理能力，但它不是IDE。它在终端里运行，通过Bash访问所有开发工具。它是一个自主Agent，能自己决定下一步做什么。
观点句：真正拉开的差距不是“谁写的代码更准”，而是“谁能在真实工程环境中稳定跑完多步任务”。Copilot的优势在即时响应，Claude Code的优势在任务闭环。
目前很多开发者其实在混合使用：用Copilot做行内补全，用Cursor做多文件编辑，用Claude Code做终端自动化和Git工作流。
这说明了一个趋势：工具不是替代关系，而是分工关系。
Skill协议被Anthropic开源后，Cursor和GitHub也宣布支持。这意味着Skill正在成为一种跨平台的“技能格式标准”。你写的一个Skill，理论上可以在不同的AI编程工具上复用。
五、工程落地启示——你该怎么用
回到最核心的问题：Skill能替代人吗？
不能。至少在可预见的未来，不能。
Skill的本质是工作手册，不是大脑。它能把标准化的流程变成可复用的指令包，但它不产生新的判断力。如果一个人每天的工作就是重复执行一套固定流程——写特定格式的文档、跑固定的测试用例、按固定模板回复邮件——那确实可以被Skill替代。但如果你的工作涉及需要判断力的决策，Skill帮不了你。
观点句：Skill替代的不是人，而是人身上那些“可以被写成手册”的部分。
那么，作为工程师，你现在该怎么用Skill？
第一，把重复的工作流程固化下来。 如果你发现自己在反复对AI说同一段话，那就是一个Skill的候选。把你的团队代码规范、测试用例模板、PR模板打包成Skill。
第二，利用Skill做团队经验沉淀。 OpenClaw的设计思路值得参考：SOUL.md定义人格，AGENTS.md沉淀踩坑经验，SKILL.md固化规范。让Agent在犯过一次错之后，下次不再犯同样的错。这就是“会学习的测试助手”的本质。
第三，不要盲目收集Skill。 社交媒体上频繁出现Skill分享帖，很多人心态是“装得越多，我的AI就越强大”。这种心态本身就是对Skill机制的误读。Skill是按需加载的，AI每次只调用与当前任务相关的那一个或几个Skill，其余的全部沉默。装了500个Skill，和装了5个Skill相比，对单次任务的输出质量没有任何影响。
观点句：真正有用的Skill，解决的是高度标准化、重复性强的流程问题，不是“炼化人的经验”。
Anthropic官方生态中使用率最高的Skill集中在文档处理领域——Excel、Word、PowerPoint、PDF的读写Skill是最早内置的，也是复用频率最高的。这说明了一个朴素的规律：Skill最擅长的是让AI帮你做那些你不愿意做的重复劳动，而不是让AI学会你花了十年才积累的专业判断。
六、趋势判断——脚手架会越来越薄
从更大的时间尺度看，Skill的流行标志着一个转折点。
AI编程的第一个阶段是“模型能力竞赛”——谁的参数多、谁的上下文长、谁的推理准。现在这个阶段正在收尾。2026年的市场格局已经很清晰：Claude在编码任务中占据主导，DeepSeek以成本优势切入，但真正的差异化正在从模型层转向工程层。
第二阶段是“工程化落地竞赛”。Skill就是这种竞赛的产物。它不是在模型层解决问题，而是在Harness层解决问题——如何让模型更好地和现有工具协作，如何把人类经验低成本地注入模型的工作流。
随着模型能力持续提升，Harness层会越来越薄。
这是Claude Code设计者的核心判断：随着模型变得更强，脚手架应该变薄，而不是变厚。硬编码的脚手架应该随着模型能力提升而被主动删除，架构随时间推移越来越薄。
今天的Skill，本质上是在当前模型能力有限的情况下，给AI写的“拐杖”。当模型足够强时，很多拐杖就不需要了。比如，如果模型已经能从“按公司品牌规范写文档”这句话中理解全部隐含规则，你就不需要再写一个SKILL.md来教它。
但这个“足够强”的时刻，可能比很多人想象的要远。
真正的专业判断力——那些无法被写成文档的、隐藏在多年实践经验中的直觉和权衡——短期内的Skill还学不会。Skill能学会的是“怎么做”，学不会的是“为什么这么做”。
所以，回到那个让人恐慌的问题：你的技能会被Skill替代吗？
如果你的技能可以被写成一份清晰的操作手册，答案是肯定的。如果你的技能依赖于经验积累的判断力、跨领域知识的迁移能力、对人性和组织的理解——答案是，短期内不会。
Skill不是炼化人，而是炼化流程。
一个更有意思的问题留给你：你现在的系统中，有哪些环节的决策可以被固化、被标准化、被打包成一个Skill？如果把这些决策从人身上剥离出去，你的角色还剩下什么？
这不是焦虑。这是一个工程问题。而工程问题，总有解法。
