MCP 的前车之鉴

去年4月 MCP 刚出来时，团队很兴奋：AI 终于能连数据库、读业务服务、调用 API 了。不到百人的团队，不到一年做了上百个 MCP。结果呢？真正常用的不到10个。

失败案例很典型：

  • 做了连 Jira 的 MCP，没人用——工作流程没变，AI 只是查询工具，还不如直接打开 Jira
  • 做了连业务服务的 MCP，用了两次就弃了——还得专门定制，跟直接写接口区别不大
  • 做了连代码库的 MCP，使用频率极低——大家的工作方式没变，AI 仍然只是"辅助工具"

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

Skill 是什么：从提示词到能力内化

理解 Skill 需要看清三者的演进关系：

  • Prompt：每次给 AI 发"使用说明书"，下次对话又得重新说一遍
  • MCP：让 AI 能调用外部能力，但仍在被动响应指令
  • Skill：把某个领域的知识、工作流程、判断标准直接内化成 AI 的一项能力——它知道在什么情况下该做什么，不需要你每次提醒

本质区别在于：Prompt 和 RAG 是在"提醒"AI，Skill 是让 AI 真正"内化"知识。通用大模型再强，也对你的业务一无所知——不知道你的技术栈、踩过的坑、选型的理由。Skill 把整套工作流程、判断标准、最佳实践打包成能力模块，加载后 AI 就"知道"该怎么做。

AI 是放大器：高手和新手的差距从2倍变成100倍

在团队里推 AI coding，几十个人都配了工具、做了培训，效果天差地别：

  • 有人用 AI 写出的代码质量很高，符合规范、逻辑清晰，稍微改改就能合并
  • 有人用 AI 写出的代码一看就是 AI 生成的——命名随意、结构混乱、不考虑边界情况，code review 来回好几轮

这不是工具熟练度的问题。AI 是放大器，你对工程的理解有多深，AI 就能帮你走多远。 Prompt 背后体现的是你的工程经验、问题理解和质量判断，这些 AI 不会自己补上。

Skill 提供了一种新的解法：把高手的经验和判断标准固化下来，让 AI 执行时自动遵循。 新手调用这个 Skill，AI 就能按高手的标准工作。

从"人驱动"到"AI 自驱动"

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

Skill 模式：把高手的开发流程、代码规范、常见优化手法、容易踩的坑打包成 Skill（比如 frontend-design）。新人写代码时 AI 加载这个 Skill，自动按标准生成代码。

关键变化：

  • 高手的角色：从"手把手教"变成"定义标准"，时间用在设计架构、解决疑难问题上
  • 新人的角色：从"写代码→等 Review→改"变成"调用 Skill→AI 生成代码→人做决策和调整"
  • 人的定位：定义标准、做决策；执行的活，AI 来干

Skill 照出的组织脆弱性

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

文档只能告诉你"现在是什么样"，说不清"为什么是这样"和"遇到新问题该怎么判断"。新来的架构师得花几个月摸清系统，团队技术演进速度明显下降。

Skill 在这个场景下的价值：把架构师的设计思路、技术选型逻辑、权衡标准、踩过的坑都沉淀下来。新人遇到问题时，AI 不只告诉他"现在是什么样"，还能给出"为什么这样设计"以及"遇到新情况该怎么判断"。

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

三个不可逆的趋势

  1. 固化流程岗位加速消失：按模板写文档、按规范写测试用例、按 Checklist 做代码审查——只要工作可以写成 SOP，AI 迟早能做
  2. 工程师和产品经理界限模糊：执行成本降低后，懂产品的人可以直接用 AI 把想法变成原型，懂技术的人可以快速验证产品方案，角色趋向"端到端"
  3. 工作流核心变成 AI 自主性：从"人分解任务→人执行→人检查"变成"人定义目标和标准→AI 自主规划和执行→人做决策和调整"

这三个变化是连锁反应：执行被接管 → 角色边界模糊 → 工作流重构。

怎么开始：5步落地法

不需要等完美的计划，现在就能动手：

  1. 选一个3-5人的小团队——最好是愿意尝试新东西的，不要一上来全员铺开
  2. 定一个具体可衡量的小目标——技术团队："用 AI 把 code review 时间减少30%"；运营团队："周报从2小时缩到30分钟"；销售团队："客户方案初稿从1天变成2小时"
  3. 给1个月时间探索、试错、总结——允许效率下降，允许犯错
  4. 每周 review 一次——不是汇报进度，而是一起看哪些 work、哪些不 work、为什么
  5. 把有效做法固化——写成文档、做成 Skill、形成团队共识，再扩散到其他团队

避坑清单：

  • 不要一上来全员铺开
  • 不要把"做了多少个 Skill"当 KPI
  • 不要期待立竿见影，给团队探索时间
  • 不要只买工具不改流程

关于 AI 写作的实践

这篇文章本身就是 AI Native 工作方式的一个例子：用微信输入法语音功能直接说给 Obsidian，输出1000多字碎片化想法，然后在 Claude Code 里让 AI 整理成结构化文章。

分工很清晰：

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

如果用传统方式，需要先理清逻辑、一个字一个字敲、反复调整结构，花大半天甚至一整天。当工作方式改变，产出效率就变了。

工具永远在迭代，Prompt → MCP → Skill，后面还会有新东西。但如果组织不变，换什么工具都一样。对于一人公司和独立开发者来说，好消息是：你就是决策者，不需要等"一把手站出来"——你自己就是一把手。从一个小场景开始试，效果会比读十篇文章更直接。