中推圈都在教怎么写 Skill，但你可能正在重复 MCP 的错误 | 写给管理者

最近中推圈在疯传”怎么写 Claude Skills”。

这让我想起去年4月，老板大笔一挥决定搞 MCP。不到百人的团队,不到一年时间，搞出了上百个 MCP。

当时各团队竞相汇报 MCP，很多人还挺骄傲的。

结果呢？真正常用的不到10个。

现在 Skill 的风要来了。我猜2个月后，国内会大热。

但我也猜，大部分公司会重蹈覆辙。

为什么？因为大家又在把”组织变革”的问题，当成”工具采购”的问题来解决。

1. 先说说 MCP 的教训

去年4月，MCP 刚出来的时候，团队很兴奋。

“终于可以让 AI 连接数据库了！” “可以读业务服务了！” “可以调用API了！”

为什么最后大部分没人用？

做了个连 Jira 的 MCP，没人用。因为工作流程根本没变，AI 只是”查询工具”，还不如直接打开 Jira。

做了个连业务服务的 MCP，用了两次就不用了。因为还得去专门定制 mcp，跟直接写接口区别不大。

做了个连代码库的 MCP，团队说”挺好”，但实际使用频率很低。因为大家的工作方式没变，AI 还是”辅助工具”而不是”工作方式”。

问题不是工具不好，是我们没想清楚工作方式该怎么变。

现在 Skill 来了。我看到的趋势是：大家又在重复同样的错误。

教程满天飞，都在讲”怎么写 Skill”。但很少有人问：为什么要写 Skill？它解决的是什么问题？

2. Skill：不只是工具，更像是镜子

Skill 用下来，最大的收获不是学会了怎么写。

而是看清了一个问题：大部分组织还在用前 AI 时代的方式运作。

Skill 不是工具升级，它更像是一面镜子，照出了组织该怎么改变。

要理解这一点，得先看看 Skill 是什么。

如果你一直在关注 AI 工具的发展，应该经历过这样的演进：

最早是写 prompt 模板，把常用的提示词保存下来，每次对话时复制粘贴进去。

后来有了 MCP（Model Context Protocol），可以让 AI 连接外部工具和数据源，比如连接后端服务、查询数据库。

现在又出现了 Skills。

这三者的区别，用个不太严谨的类比来说：

Prompt 像是每次给 AI 发”使用说明书”。“你要注意这个，要遵循那个规范”。AI 看到了，但下次对话又得重新说一遍。

MCP 让 AI 可以”调用外部能力”。需要什么数据就去取，需要执行什么操作就去做。但 AI 还是在被动响应你的指令。

Skill 则是把某个领域的知识、工作流程、判断标准，直接内化成 AI 的一项”能力”。它知道在什么情况下该做什么，不需要你每次提醒。

但用久了你会发现，这不只是工具升级。

3. 为什么 Skill 会出现：技术演进遇到瓶颈

通用大模型已经很强了。写代码、分析数据、写文档，很多事情都能做。

但有个根本问题：它们对你的业务一无所知。

说白了，它不知道你们用什么技术栈、踩过什么坑、为什么选了这个架构方案。你们的代码规范、文档习惯，它全都不了解。

之前怎么解决这个问题？

一种方式是每次对话都把这些信息喂给 AI。写好 prompt 模板，每次复制粘贴。但很累，而且 AI 只在当前对话里”记住”，下次又得重来。

另一种方式是用 RAG（检索增强生成）。把文档、代码库扔进知识库，AI 需要时去检索。但检索到的只是”参考资料”，AI 还得自己理解、自己判断。

这些方案都在尝试”提醒” AI，而不是让 AI 真正”内化”知识。

Skill 在解决这个问题。不是提供参考资料，而是把整套工作流程、判断标准、最佳实践，打包成能力模块。AI 加载这个 Skill 之后，就”知道”该怎么做。

这不是某个公司的产品创新。当通用能力足够强之后，下一步必然是适配特定组织和场景。

4. Skill 揭示的问题：AI 效果为什么天差地别

我在团队里推 AI coding，几十个人，都配了工具，也做了培训。

效果…怎么说呢，一言难尽。

有些人用 AI 写出来的代码质量很高，符合规范，逻辑清晰，稍微改改就能合并。

有些人用 AI 写出来的代码一看就知道是 AI 生成的。命名随意、结构混乱、没考虑边界情况，code review 要来回好几轮。

这不是工具熟练度的问题，也不只是 prompt 写得好不好。

本质是：AI 是放大器。你对工程的理解有多深，AI 就能帮你走多远。

你的 prompt 背后体现的是你的工程经验、对问题的理解、对质量的判断。这些东西，AI 不会自己补上。

在 AI 时代，个人能力差异不只是被放大了。高手和新手之间的差距，从2倍变成了100倍。

高手用 AI 效率翻倍，质量还能保持。新手用 AI 确实快了，但质量很难保证。

这对组织是个麻烦。你不可能指望每个人都是高手。

传统方式是：Code Review、结对编程、导师制。通过人来传递经验和规范。但很慢，也很依赖”那个高手有没有时间”。

Skill 提供了另一种可能：把高手的经验和判断标准固化下来，让 AI 执行时自动遵循。

新手调用这个 Skill，AI 就能按照高手的标准工作。

这不是消除差异，而是改变”经验传递”的方式。

5. Skill 的本质：从人驱动到 AI 自驱动

团队里有个高手，写组件又快又好。代码结构清晰、性能优化到位、边界情况都考虑了。新人看他的代码能学到很多，但要自己写出那个水平，得花很长时间。

传统方式：新人写代码 → 高手 Code Review → 指出问题 → 新人改 → 再 Review。一个组件可能来回三四轮。高手累，新人也挫败。

现在可以这样：把高手的开发流程、代码规范、常见优化手法、容易踩的坑，打包成一个 frontend-design Skill。新人写代码时，AI 加载这个 Skill，自动按这套标准生成代码。

关键变化：高手的角色变了。

以前高手要”手把手教”，现在高手只需要”定义标准”。具体的代码生成、规范检查，AI 来做。高手的时间可以用在更有价值的地方，比如设计架构、解决疑难问题。

新人的角色也变了。以前是”写代码 → 等 Review → 改”，现在是”调用 Skill → AI 生成代码 → 人做决策和调整”。

这就是从”人驱动”到”AI 自驱动”的转变。

人的角色变了：定义标准、做决策。执行的活，AI来干。

这看起来是技术问题，但背后是组织运作方式的改变。当 AI 可以”自驱动”完成大量执行工作，人应该做什么？组织应该怎么分工？

举个我们正在试的例子：让 PM 用 AI 完成产品从 0 到 1 的全流程。从需求分析、竞品调研、原型设计、PRD 撰写，到开发实现、测试上线。没错，PM 自己做开发。这就是角色边界模糊的极端实验。

效果怎么说呢，目前一般。AI 能跑完流程，但产出质量还不够稳定，很多地方还是要人介入调整。

但方向我觉得是对的。问题不在于 AI 能不能做，而在于我们还没找到最合适的人机协作方式。Skill 还在调，这本身就是探索的一部分。

6. Skill 照出的组织脆弱性

一个技术架构师离职了。就在上个季度。

走之前做了交接，留了文档，但还是带走了很多东西：为什么当初选这个技术方案、踩过哪些坑、哪些地方是为了兼容历史问题做的妥协、未来的演进方向是什么。

这些东西很难写进文档。文档只能告诉你”现在是什么样”，但说不清楚”为什么是这样”以及”遇到新问题该怎么判断”。

新来的架构师得花几个月摸清楚整个系统。遇到问题时，不确定该怎么改，怕动了之后引发连锁反应。团队的技术演进速度明显慢下来。

这暴露了一个问题：组织的知识资产太依赖个人。

人在，知识就在。人走了，知识也跟着流失了一大半。剩下的文档和代码，只是”静态快照”，缺少”动态判断能力”。

Skill 在这个场景下能做什么？

可以把架构师的设计思路、技术选型逻辑、权衡标准，甚至踩过的坑和解决方案，都沉淀成一个 Skill。

新人遇到问题时，AI 不只是告诉他”现在是什么样”，而是能基于这套标准，给出”为什么这样设计”以及”遇到新情况该怎么判断”。

这不是说 AI 能替代架构师。但它能把架构师的判断标准和经验留下来，让组织不那么脆弱。

AI Native 的组织和传统组织的一个重要区别：知识资产不再依附于个人，而是可以被固化、复用、传承。

组织的韧性，会因此变得不一样。

7. 从 Skill 看到的更大图景：组织必须重构

Skill 为什么是范式转变，而不只是工具迭代？

因为它指向组织运作方式的改变。

当 AI 可以”自驱动”完成大量执行工作，当知识可以被固化和复用，组织会发生什么变化？

我观察到三个趋势，它们是层层递进的：

1. 很多固化流程的岗位会进一步消失

那些”按照既定流程执行任务”的工作，会越来越多地被 AI 接管。不只是简单的重复劳动，还包括那些”有流程可依”的复杂工作。

比如按照模板写文档、按照规范写测试用例、按照 Checklist 做代码审查。这些工作需要专业知识，但一旦流程清晰，AI 就能做得很好。

说难听点：如果你的工作可以写成 SOP，那 AI 迟早能做。

2. 工程师和产品经理的界限会模糊

执行成本降低之后，角色边界自然就模糊了。

以前产品经理写需求，工程师写代码，是因为”写代码”需要专门技能和大量时间。

但当 AI 可以快速生成代码，界限就不那么清晰了。懂产品的人，可以直接用 AI 把想法变成原型。懂技术的人，可以快速验证产品方案的可行性。

角色会更加”端到端”。从想法到实现，中间的环节会压缩。

3. 工作流的核心变成”AI 的自主性”

当执行工作被 AI 接管、角色边界模糊之后，工作流本身也得重新设计。

以前的工作流：人分解任务 → 人执行 → 人检查。

未来的工作流：人定义目标和标准 → AI 自主规划和执行 → 人做决策和调整。

AI 的自主性会越来越强。不是你告诉它每一步该做什么，而是你告诉它要达成什么目标、要遵循什么标准，它自己去完成。

这需要组织重新设计工作流程、重新定义岗位职责。

这三个变化是连锁反应：执行被接管 → 角色边界模糊 → 工作流重构。本质都指向一件事：组织的价值创造方式变了。

这些变化正在发生。方向很清楚。

推动这种转变，需要投入成本。时间成本（员工学习和适应）、金钱成本（AI 订阅费用）、试错成本（允许失败和探索）、组织成本（调整架构带来的混乱期）。

很多管理者会犹豫，因为短期内看不到明确的 ROI。

但不改变的风险，可能比改变更大。

8. 一把手必须站出来

这不是”买几个 AI 工具”就能解决的问题。

给员工配了 GitHub Copilot 或者 ChatGPT 订阅，然后期待效率提升。几个月下来发现，有人用得很好，有人根本不用，整体效果不明显。

问题在哪？工具只是表层，底层是组织的运作方式没有变。

工作流程还是按照”人做所有事情”设计的，考核标准还是按照”人的产出”来定的，知识管理还是依赖个人和文档。在这种情况下，AI 只是一个”可选的辅助工具”，而不是工作方式的一部分。

要真正转向 AI Native，需要一把手站出来推动。

为什么必须是一把手？

因为这涉及到：

• 重新设计工作流程 — 谁来做？怎么试错？
• 调整考核标准 — 用 AI 之后，怎么衡量个人贡献？
• 改变组织架构 — 哪些岗位要合并？哪些要新增？
• 投入试错成本 — 允许一段时间的混乱和探索

这些事情，不是某个部门或某个人能推动的。必须是一把手明确表态、亲自推动。

舍得短期利益

更关键的是，一把手要有勇气舍得短期利益。

员工学习 AI 工具需要时间，这段时间产出会下降。调整工作流程会带来混乱期，效率会打折。试错和探索会有失败，意味着要接受浪费。

如果不愿意承担这些短期代价，就永远停留在”给大家买个工具”的层面，然后抱怨”AI 也没那么神奇”。

等待的代价

很多管理者想：我们再等等，等 AI 更成熟一点，等市场上有更清晰的最佳实践。

但等待的成本是：你的竞争对手已经开始重构组织了。

他们的团队已经在用 AI Native 的方式工作，效率和创新速度已经拉开差距。等你”准备好”的时候，可能已经晚了。

Skill 只是一个切入点。它让我看到了 AI 时代组织变革的一个侧面。

这不是关于某个工具有多厉害，而是关于你是否意识到组织必须改变，以及是否有勇气推动这个改变。

如果你是管理者，不妨问自己几个问题：

• 你的团队在用 AI，但工作流程变了吗？
• 你的核心员工离职，知识资产还能留下来吗？
• 你在为 AI 时代重构组织，还是只是给现有组织加了一些 AI 工具？
• 你还在等什么？

答案会很诚实。

如果你现在就想开始

不需要等完美的计划。可以这样试试：

1. 选一个 3-5 人的小团队 最好是愿意尝试新东西的，不要一上来就全员铺开。

2. 定一个小目标 目标要具体、可衡量。技术团队可以是”用 AI 把代码 review 时间减少 30%“；运营团队可以是”周报从2小时缩到30分钟”；销售团队可以是”客户方案初稿从1天变成2小时”。什么团队都能找到切入点。

3. 给他们 1 个月 探索、试错、总结。这期间允许效率下降，允许犯错。

4. 每周 review 一次 不是汇报进度，而是一起看：哪些 work，哪些不 work，为什么。

5. 把有效的做法固化下来 写成文档、做成 Skill、或者至少形成团队共识。然后再扩散到其他团队。

一个月后，你会有真实的数据和感受。这比现在纠结”要不要做”有用得多。

从小场景开始，快速验证，再逐步扩散。 这是最低风险的方式。

不要这样做

• 不要一上来就全员铺开，那是找死
• 不要把”做了多少个Skill”当KPI，那是形式主义
• 不要期待立竿见影，给团队时间探索
• 不要只买工具不改流程，那是浪费钱

9. 我的预判

Skill 会在2个月内在国内大热。

到那时，你会看到：

• 各种”Skill 教程”刷屏
• 公司开始要求”每个团队做几个 Skill”
• KPI 变成”做了多少个 Skill”

然后3个月后，你会听到：

• “Skill 也没那么神奇”
• “做了一堆，但没人用”
• “感觉跟 prompt 工程没啥区别”

这不是 Skill 的问题。

是因为大家又在把”组织变革”的问题，当成”工具采购”的问题来解决。

造工具不难。造有意思的工具也不难。

难的是：你敢不敢改造你的团队？

工具永远在迭代，组织能力才是护城河。

随着组织演进，会有新的工具出来。Prompt → MCP → Skill，后面还会有新东西。

但如果组织不变，换什么工具都一样。

工具要适配团队，或者改造团队。两者都不做，就是瞎搞。

如果你读到这里还不知道怎么开始，回去看第8章的5个步骤。今天就能动手。

后记：这篇文章是怎么写出来的

说到这里，可以分享一个细节。

这篇文章的观点，是我用微信输入法的语音功能，直接说给 Obsidian 的。想到什么说什么，不需要打字，不需要组织严密的逻辑。

然后在 Claude Code 里，跟 AI 一起把这些碎片化的想法整理成现在这个样子。

其实这篇文章本身，就是我拿来测试 Skill 的场景之一。Skill 还在调，边用边优化。

这就是我说的”AI Native 工作方式”。

人负责：观点、方向、判断、决策。 AI 负责：整理、结构化、补充细节、执行。 工具负责：连接和沉淀（Obsidian、Claude Code）。

我知道很多人会质疑：用 AI 写文章，还是你自己的东西吗？

我的想法是：AI 既然来了，如果非得让渡一些能力给它，我希望是整理和执行这部分，而不是思考能力。观点是我的，判断是我的，方向是我的。AI 帮我把这些变成结构化的文字。

如果用传统方式，我可能需要：

• 先在脑子里理清楚所有逻辑
• 打开文档一个字一个字敲
• 反复调整结构和表述
• 花大半天甚至一整天

现在效率完全不一样。这笔交易我觉得划算。

这不是炫技。这是在说：当工作方式改变，产出效率就变了。

我写这篇文章的方式，就是我在文章里说的那种方式。如果你的组织还没开始这样工作，不妨从一个小场景试试看。

效果会比读十篇文章更直接。

现在就去试。