Claude Code Skills 完全指南：为什么一个 Markdown 文件能改变 AI 的行为？

Skill 的本质：为什么一个 Markdown 文件能改变 AI 的行为？

这是「Claude Code Skills 完全指南」系列的第一篇。本系列共 10 篇，构成一套完整的知识体系。

写在前面

你大概率已经听说了 Claude Code Skills。也许你已经安装了几个。也许你在终端里输入 /frontend-design，看到 Claude 的输出确实变了，感到了一丝惊喜。

然后呢？

你不知道它为什么变了。你不知道它是怎么变的。你不知道如果它没有生效，该从哪里排查。你甚至不确定——那些你安装但从没用过的 Skills，是不是正在拖慢 Claude 的表现。

这些问题的答案，都藏在一个最基础的问题里：

一个 Markdown 文件，到底是如何改变一个 AI 模型的行为的？

理解这件事，是你构建、选择、调试所有 Skill 的起点。不理解它，后面的一切——Description 设计、模式选择、编排架构——都是在沙子上盖楼。

一、Skill 到底是什么？—— 最精确的定义

先清除一些常见的误解。

Skill 不是插件。它不是一段可以独立运行的程序。它不会给 Claude 添加新的"能力"，就像你不能通过给一个人念一段说明书让他突然会弹钢琴一样。

那它是什么？

Skill 本质上是结构化文档——Markdown 文件——教会 Claude Code 如何执行特定的业务操作。当你说出一句话，Claude 识别意图，加载对应的 Skill，然后按照其中的多步骤工作流来完成任务。

用一位技术分析者的话说得更直白：Skills 就是文字提示词。经过精心组织的文字提示词——但本质上还是文字提示词。

这听起来似乎平平无奇。但恰恰是这种"平平无奇"中藏着深刻的设计智慧。要理解这一点，我们需要先搞清楚 Skill 的物理结构。

一个 Skill 的完整形态

每个 Skill 是一个包含 SKILL.md 作为入口点的目录。它可以包含可选的支持文件——供 Claude 填充的模板、展示预期格式的示例输出、Claude 可以执行的脚本，或详细的参考文档。

一个典型的 Skill 目录长这样：

text

my-skill/
├── SKILL.md           # 主指令文件（必需）
├── templates/         # 模板文件
│   └── report.md
├── references/        # 参考资料
│   └── style-guide.md
├── examples/          # 示例输出
│   └── sample.md
└── scripts/           # 可执行脚本
    └── validate.sh

而 SKILL.md 自身由两部分组成：YAML frontmatter（在 --- 标记之间），告诉 Claude 什么时候使用该 Skill；以及 Markdown 正文，提供 Claude 在 Skill 被调用时遵循的指令。

一个最简示例：

YAML

---
name: explain-code
description: Explains code with visual diagrams and analogies.
  Use when explaining how code works, teaching about a codebase,
  or when the user asks "how does this work?"
---

Markdown

When explaining code, always include:
1. **Start with an analogy**: Compare the code to something from everyday life
2. **Draw a diagram**: Use ASCII art to show the flow
3. **Walk through the code**: Explain step-by-step what happens
4. **Highlight a gotcha**: What's a common mistake or misconception?

name 字段成为 /slash-command（输入 /explain-code 即可手动触发），description 帮助 Claude 决定何时自动加载它。

就是这样。没有 API 注册，没有编译步骤，没有运行时，没有依赖管理。一个文件夹，一个 Markdown 文件，放在正确的位置，就是一个完整的 Skill。

这引出了本文最核心的问题：如此简单的结构，凭什么能产生如此显著的行为改变？

二、核心原理：渐进式披露

2.1 为什么不能一次性把所有知识塞给 Claude？

在解释 Skill 怎么工作之前，我们需要先理解 Skill 被设计出来要解决的那个问题。

Agent 的上下文窗口空间不是免费的，填满它会带来复合成本。上下文窗口中的每一个 token 都从三个方面消耗你的资源：实际成本——显而易见的，你在按 token 付费，无论是直接的 API 使用还是间接的额度消耗；延迟——更多输入 token 意味着更慢的响应，这在注意力机制下扩展性很差；质量——最后，长上下文窗口还会导致质量下降。

这是一个你必须刻在脑子里的公式：信息越多 ≠ 效果越好。相反，无关信息是一种主动的伤害。

在其他条件相同的情况下，当上下文窗口充满聚焦、相关的内容（包括示例、相关文件、工具调用和工具结果）时，LLM 在任务上的表现会更好，远好于上下文窗口中有大量无关内容的情况。

一个不那么抽象的说法：对 Claude Code 的系统提示分析表明，它包含大约 50 条独立指令。根据你使用的模型不同，这已经占据了 agent 可靠遵循的指令总量的近三分之一——而这还是在加入 rules、plugins、skills 或用户消息之前。

也就是说，Claude 能同时"记住"和"遵循"的指令数量是有限的。每多一条无关指令，都在稀释它对真正重要的指令的关注。

这就是 Skill 的设计出发点：不是给 Claude 更多信息，而是在正确的时间给它正确的信息。

2.2 三级加载模型

构建 Skills 最重要的概念是渐进式披露（Progressive Disclosure）——只展示足够的信息帮助 Agent 决定下一步做什么，然后在它们需要时再揭示更多细节。

具体来说，Skills 通过三个层级渐进式加载上下文：Skill 摘要（元数据）、正文（详细指令）和引用文件（补充上下文），每个层级只在被需要时才触发。

让我画一张图来说清楚这三个层级：

text

┌─────────────────────────────────────────────────────────────┐
│                    第 1 级：元数据                             │
│                                                              │
│  始终加载 · 约 100 token · 所有 Skill 的 name + description   │
│                                                              │
│  作用：Claude 在每次会话开始时扫描这些元数据，                    │
│        用它们来判断哪些 Skill 与当前任务相关                     │
├─────────────────────────────────────────────────────────────┤
│                    第 2 级：完整指令                            │
│                                                              │
│  按需加载 · < 5,000 token · SKILL.md 的 Markdown 正文         │
│                                                              │
│  作用：当 Claude 判断某个 Skill 相关时，才读取完整指令            │
├─────────────────────────────────────────────────────────────┤
│                    第 3 级：支持文件                            │
│                                                              │
│  按需加载 · 大小不限 · 脚本、模板、参考文档                      │
│                                                              │
│  作用：只有当 SKILL.md 中的指令明确引用时，                      │
│        Claude 才会读取这些文件                                  │
└─────────────────────────────────────────────────────────────┘

这种渐进式披露架构非常高效：元数据加载阶段（约 100 token），Claude 扫描可用 Skills 以识别相关匹配；完整指令（< 5,000 token）仅在 Claude 判定该 Skill 适用时才加载；捆绑的资源和文件只在需要时加载。这种设计允许多个 Skills 同时可用而不会压垮 Claude 的上下文窗口。

用 Anthropic 官方的比喻来说：Claude 像你翻阅一本入职指南一样浏览你的 Skill，精确地获取每个任务所需的部分。

2.3 一个完整的加载过程演示

以一个 PDF 处理 Skill 为例，完整的加载过程如下：启动阶段，系统提示中包含简要信息："PDF Processing - Extract text and tables from PDF files, fill forms, merge documents"。用户请求："Extract the text from this PDF and summarize it"。Claude 调用：读取 SKILL.md，完整指令加载到上下文中。Claude 判断：表单填充不需要，所以 FORMS.md 不被读取。Claude 执行：使用 SKILL.md 中的指令完成任务。

注意那个关键细节：当用户询问关于营收的问题时，Claude 读取 SKILL.md，看到对 reference/finance.md 的引用，然后调用 bash 去读取那个文件。sales.md 和 product.md 留在文件系统上，消耗零上下文 token。

零上下文 token——这就是渐进式披露的核心价值。你可以安装 30 个 Skill，但如果当前任务只涉及 1 个，另外 29 个的完整指令和支持文件完全不会占用你宝贵的上下文空间。

2.4 关键设计含义

这种架构导致了一个被大多数人忽略的事实：

你的 Skill 能否被使用，完全取决于第 1 级——那大约 100 个 token 的 name 和 description。

这也意味着你的 description 承担了发现环节的全部重任。如果它很模糊，比如"helps with documents"，Claude 就不知道什么时候该调用它。要写得具体："Use when working with PDF files and need to extract text and tables." 默认情况下，Claude 自主决定何时使用一个 Skill，基于任务内容和 Skill 的 description。

Description 的写法将是本系列第 2 篇的完整主题。但现在你只需要记住一件事：description 不是给人读的说明，它是给模型读的触发器。

三、Skill 如何在底层改变 Claude 的行为？

理解了三级加载模型，接下来我们需要深入更底层的机制：Skill 的指令到底是如何被"注入"到 Claude 的行为中的？

3.1 上下文注入：一种精心设计的"欺骗"

Skill 选择机制在代码层面没有算法路由或意图分类。Claude Code 不使用 embedding、分类器或模式匹配来决定调用哪个 Skill。相反，系统将所有可用 Skills 格式化为文本描述，嵌入 Skill 工具的提示中，让 Claude 的语言模型自行做决定。这是纯 LLM 推理。没有正则表达式，没有关键词匹配，没有基于 ML 的意图检测。决策发生在 Claude 的 transformer 前向传播过程中，不是在应用代码里。

当 Claude 决定使用某个 Skill 后：

系统遵循一个简单的工作流：加载一个 Markdown 文件（SKILL.md），将其展开为详细指令，作为新的用户消息注入到对话上下文中，修改执行环境（可用工具、模型选择），然后在这个丰富的环境中继续对话。

这里有一个极其重要的细节：Skill 的指令被注入为"用户消息"。

这意味着，从 Claude 的"视角"来看，它就像突然收到了一条来自用户的、非常详细和专业的请求，告诉它应该按照什么步骤、什么标准、什么格式来完成接下来的工作。模型并不"知道"这是一个 Skill——它只是在处理一段高质量的、高度结构化的上下文信息。

3.2 这就是为什么"过程"和"知识"必须分开

理解了注入机制，就能理解一条关键的 Skill 设计原则：

良好结构化的 Claude Code Skill 的基本原则是将"做什么"和"知道什么"分离。过程（Process）= Claude 应该遵循的有序步骤来完成任务——这属于 SKILL.md。上下文（Context）= Claude 正确执行这些步骤所需的背景信息、规则、领域知识、示例和参考数据——这属于 reference 文件。

为什么非要分开？

因为当 SKILL.md 专注于过程时，Claude 确切地知道该如何处理它。但当它同时充当知识库时，模型必须自行判断哪些部分是指令、哪些是背景——而它并不总能做出正确判断。

这是一条反直觉但极其实用的规则：SKILL.md 要写得像食谱，不像百科全书。

食谱告诉你"第一步打鸡蛋，第二步加面粉"——这是过程。关于面粉的品种、鸡蛋的营养成分、烤箱的工作原理——这些知识放在别处，只在需要时查阅。

3.3 也解释了为什么有些 Skill "没什么用"

理解了上述原理，你就能理解一个重要的实验结果。

Vercel 的测评显示，一个压缩到 8KB 的文档索引直接嵌入 AGENTS.md（即始终加载到上下文中），实现了 100% 的通过率，而 Skills 即使在明确指示 agent 使用它们的情况下，也最高只达到 79%。没有那些指示时，Skills 的表现与完全没有文档时一模一样。

更具体地说：在 56% 的使用默认 Skill 配置的评测场景中，agent 根本没有调用 Next.js 文档 Skill。Agent 拥有获取信息的途径，却选择了不使用。结果是 53% 的通过率，与基线完全一致。

这说明了什么？

这与大量关于 LLM 校准的研究一致——模型系统性地高估了自己的知识。

换句话说：Claude 倾向于认为自己已经知道答案，所以不去查阅 Skill。 这不是 Skill 的 bug，这是 LLM 的本性。

但这并不意味着 Skills 没有价值。它意味着你需要理解 Skills 真正擅长什么。

四、Skill 真正的价值：两种类型，两种用法

Anthropic 在今年三月更新了官方指南，首次明确将 Skills 分为两类。这个分类框架是理解"什么时候该用 Skill、什么时候不该用"的关键。

4.1 能力提升型 Skill（Capability Uplift）

能力提升型 Skill 帮助 Claude 做一些基础模型要么做不到、要么做不一致的事。Anthropic 的文档创建 Skills 就是好例子。它们编码了某些技术和模式，使输出质量优于单纯的提示。

典型场景：精确的 PDF 文本定位、特定格式的图表生成、需要遵循严格规范的代码生成。

但这类 Skill 有一个重要特性：能力提升型 Skill 可能随着模型改进而变得不那么必要。Evals（评测）会告诉你那一天何时到来。

4.2 编码偏好型 Skill（Encoded Preference）

编码偏好型 Skill 记录的是 Claude 本身已经能做每一步的工作流，但 Skill 按照你团队的流程将它们串联起来。例如：一个按照设定标准审查 NDA 的 Skill，或一个从各个 MCP 拉取数据来起草周报的 Skill。

编码偏好型 Skill 更持久，但其价值取决于它对你实际工作流的忠实程度。Evals 验证的就是这种忠实度

4.3 为什么这个区分很重要？

因为 Vercel 那个"Skills 不如 AGENTS.md"的实验，测试的恰好是第一类——参考知识检索：API 语法、函数签名、特定框架版本的使用模式。测评评估的是参考知识检索——agent 需要知道特定框架版本的 API 语法、函数签名和使用模式。这类信息是事实性的、静态的、体积小——恰好是压缩性好、适合常驻上下文的知识。

但 Skills 真正闪光的场景是第二类——编排你的工作流。

五、真实案例：有 Skill 和无 Skill 的鸿沟

案例 1：LangChain 的内部评测——82% vs 9%

在 LangChain 的内部评测中，Claude Code 搭配 Skills 完成任务的成功率为 82%，但没有 Skills 时，成功率骤降至 9%。

这不是 26 个百分点的差距（像 Vercel 的测试那样），而是 73 个百分点的鸿沟。为什么？

因为 LangChain 测试的不是"Claude 是否知道某个 API"，而是"Claude 能否按照正确的步骤完成一个完整的工作流"。这正是编码偏好型 Skill 的主场。

在评测中，他们追踪的指标包括：Skill 是否被调用了？Skill 不相关时是否没被调用？Agent 是否完成了任务？一个任务可能涉及多个步骤，跟踪完成步骤数有助于区分"完全失败"和"差一点就成功"。Claude Code 完成任务用了多少轮？即使 Claude Code 不用 Skills 也能完成任务，使用 Skills 可能提高效率。Claude Code 用了多长的真实时间？

案例 2：一家真实公司用 Skills 运行整个业务

一位创始人已经在 8 个并行 worktree 中用 Claude Code 构建和发布软件。他让整个公司的运营都在 Claude Code 中完成。当他说"给我们的 alpha 用户起草一封邮件"，Claude 识别意图，加载 co-comms Skill，然后按照多步骤工作流执行：检测发件人（通过 git config）、加载发件人的声音配置、拉取发给同一收件人的历史邮件用于语调校准、起草消息、保存到磁盘、等待明确审批后才发送。

纯 Skills。没有 agent 编排其他 agent。没有工作流引擎。没有任务队列。

每个 Skill 是一个包含七个部分模板的单独 Markdown 文件：frontmatter、使用时机、上下文、流程、输出格式、护栏，以及一个无需外部系统连接即可工作的独立模式。

整个系统大约 2,000 行 Markdown，分布在 12 个 Skill 文件、5 个命令、2 个 agent 和少量规则中。它通过 MCP 服务器连接 8 个外部系统——Linear、Gmail、Google Calendar、Help Scout、Notion、Sentry、Stripe 和 Granola。数据库只用了 4 张表。

2,000 行 Markdown 运行一家公司。这就是 Skill 的力量——不在于技术的复杂性，而在于将人类工作流精确地编码为 AI 可执行的指令。

案例 3：安全审查——Skill 让输出从"不可预测"变为"结构化可靠"

一位 WooCommerce 插件开发者构建了一个安全审查 Skill。他的动机：Claude 的基线安全审查"感觉……不一致"。有时非常彻底，有时只是走过场。没有可预测的结构。这是一个完美的 Skill 候选场景。

他用 A/B 评测（Skill vs 基线 Claude）进行量化测试后发现：基线 Claude 达到 90.5%——遗漏了结构化的通过检查部分和一些 WooCommerce 特有的细微之处。而且，尽管 Skill 版本更加彻底，实际上还更快。

关键洞察：Skill 的价值不只是"做对了没有"，更是"每次都以同样的方式做对"。这正是编码偏好型 Skill 的核心价值——一致性。

六、常见误区

误区 1：「Skill 就是高级版提示词，我直接在 CLAUDE.md 里写不是一样吗？」

不一样，原因有三：

第一，加载时机不同。 CLAUDE.md 进入每一个会话，所以你必须确保其内容尽可能普遍适用。而 Skill 只在相关时加载。如果你在 CLAUDE.md 里塞了数据库建模指南，它会在你做前端工作时分散 Claude 的注意力。

第二，结构化程度不同。 Skill 有独立的目录来存放模板、脚本、参考文档、示例。Skills 添加了可选特性：一个存放支持文件的目录，通过 frontmatter 控制是你还是 Claude 来调用它们，以及 Claude 在相关时自动加载它们的能力。Claude Code Skills 遵循 Agent Skills 开放标准，可跨多个 AI 工具使用。

第三，可测试性不同。 Anthropic 推出了基准测试模式，使用你的评测来运行标准化评估。这可以在模型更新后或你迭代 Skill 本身时运行。它追踪评测通过率、耗时和 token 用量。CLAUDE.md 里的一段话很难做 A/B 测试，但一个 Skill 可以。

误区 2：「装得越多越好」

回忆第 2 节的原理：元数据层虽然只有约 100 token/Skill，但 你的 CLAUDE.md 应该包含尽可能少的指令——理想情况下只包括对你的任务普遍适用的指令。同理，30 个 Skill 的元数据就是 3,000 token 的系统提示膨胀。更重要的是——

在详细的构建/Lint/测试分项数据中，Skill 在某些指标上实际表现不如基线（测试通过率 58% vs 63%），这说明环境中未使用的 Skill 可能引入噪音或干扰。

未使用的 Skill 不是免费的。它可能让 Claude 表现更差。

误区 3：「Skill 写好就完事了」

一位开发者坦言：几个月来，他一直在用一种只能称为"hope and pray"的方法论来构建 Claude Code Skills。写好 SKILL.md。测试一次。发布。向 LLM 之神低声祈祷。然后继续过日子。Skill 真的在该触发时触发了吗？¯_(ツ)_/¯。它真的让 Claude 的输出变好了吗？说实话……不知道。

这引出了 Skill 开发中最重要的实践——而大多数人完全跳过了它。

七、你今天就应该做的 3 件事

Anthropic 官方的最佳实践文档中有一条看似简单、实则颠覆大多数人工作流的建议：

在写大量文档之前，先创建评测。 这确保你的 Skill 解决的是真实问题而非想象的问题。具体步骤：识别差距——在没有 Skill 的情况下让 Claude 跑代表性任务，记录具体的失败或缺失的上下文；创建评测——构建三个测试这些差距的场景；建立基线——度量没有 Skill 时 Claude 的表现；写最少的指令——创建刚好足够弥补差距和通过评测的内容；迭代——执行评测，与基线对比，精炼。

基于这条原则和本文的所有分析，这是你的行动清单：

✅ 行动 1：理解你已有的 Skill

打开你安装的任何一个 Skill 的目录。找到 SKILL.md。分别阅读 frontmatter（那大约 100 token 的元数据）和 Markdown 正文（那不超过 5,000 token 的指令）。问自己：

• 这个 Skill 是能力提升型还是编码偏好型？
• description 写的是给人看的摘要，还是给模型看的触发器？
• SKILL.md 里是纯过程（步骤），还是过程和知识混在一起？

✅ 行动 2：做一次 Before/After 对比

选一个你常用的 Skill。对同一个任务，分别在有 Skill 和无 Skill 的情况下运行。截图对比输出差异。如果差异不明显——恭喜你发现了一个需要删除的 Skill。

Anthropic 的建议：不要投机性地编写 Skill。在你有真实的、重复的任务时才构建它们。最好的 Skill 解决的是你经常遇到的问题。在创建一个 Skill 之前，问：我是否已经做了这个任务至少 5 次？我还会再做至少 10 次吗？如果两个答案都是"是"，那一个 Skill 就有意义。

✅ 行动 3：清理你的 Skill 库

列出你当前安装的所有 Skills。对每一个问：

1. 我能否说出它最近一次被触发的时间？
2. 它有没有经过 Before/After 对比测试？
3. 它解决的问题，我是否每周都遇到？

如果三个问题中任何一个的答案是"否"，认真考虑卸载它。记住：未使用的 Skill 留在环境中可能引入噪音，不如保持系统干净。

八、本文的知识框架总结

text

Skill 的本质
│
├── 物理结构
│   └── 一个目录 + SKILL.md（frontmatter + markdown 正文）+ 可选支持文件
│
├── 工作原理
│   ├── 渐进式披露：三级加载（元数据 → 指令 → 支持文件）
│   ├── 上下文注入：Skill 指令作为用户消息注入对话
│   └── 路由机制：纯 LLM 推理，无算法路由
│
├── 两种类型
│   ├── 能力提升型：教 Claude 做它做不好的事（可能随模型进步而过时）
│   └── 编码偏好型：编排 Claude 已会的步骤（持久但需要保持忠实度）
│
├── 核心价值
│   ├── 不是"更多信息"→ 是"正确时间的正确信息"
│   ├── 不是"让 Claude 更聪明"→ 是"让 Claude 更一致"
│   └── 不是"一次性指令"→ 是"可版本化、可测试、可组合的知识单元"
│
└── 关键约束
    ├── description 承担全部发现职责（约 100 token 决定生死）
    ├── 未使用的 Skill 不是免费的（可能引入噪音）
    └── 写完不是终点（需要评测和迭代）

下一篇预告

理解了 Skill 的本质后，我们面对的第一个实战问题是：为什么你精心编写的 Skill 不触发？

第 2 篇将深入 description 字段的设计科学。我会展示一个基于真实测试的完整框架，告诉你如何写出让 Claude 准确识别的 description——以及为什么大多数人写的 description 本质上是写给自己看的，而不是写给模型看的。

本文是「Claude Code Skills 完全指南」系列的第 1 篇，共 10 篇。全系列目录：

写完十篇文章之后，我站在这里回头看了一眼

文 / 一只阿木木

SECI模型系列 · 第10篇（终篇）

01

这个系列的第一篇文章，开头是这样写的——

"去年年底，我做了一件有点变态的事——我打开了自己过去三年收藏的所有文章、买过的所有课程、记过的所有笔记，做了一次彻底的知识审计。"

那次知识审计让我发现自己3年积累了2400篇收藏，但真正改变了我行为的不超过20个。转化率不到1%。

现在这个系列写完了。十篇文章，前后跨了差不多三个月。

今天我想再做一次审计。不是审计我的收藏夹，而是审计这三个月。

审计的问题只有一个——

写完这十篇文章之后，我这个人发生了什么变化？

不是"我知道了什么新东西"。那不重要。

而是——有没有什么东西，从我的笔记本搬进了我的身体？

02

先说一个让我自己意外的变化。

三个月前，如果有人问我"你做的事情本质上是什么"，我大概会说"写公众号"或者"做内容"或者"知识IP"。

这些说法都对。但它们都是在描述我做的动作。

写完这十篇文章之后，我对这个问题有了一个不同的回答。

我做的事情，本质上是外化。

把我脑子里的东西掏出来，变成别人能看懂的文字。

这个重新定义听起来好像只是换了个说法，没什么大不了的。

但它实际上改变了我对自己工作的理解——以一种非常具体的方式。

以前我觉得写文章的难点在于"写"——措辞、结构、节奏、标题。所以我花了大量时间学"怎么写"。

现在我觉得写文章的难点在于"掏"——你脑子里到底有没有东西可掏？如果有，你能不能把它从那团模糊的毛线球里一根一根抽出来？

"写"是手艺层面的事。可以学，可以练，可以靠技巧弥补。

"掏"是存量层面的事。你的隐性知识储备不够，再好的写作技巧也掏不出有价值的内容。

这个认识直接改变了我的时间分配。

三个月前，我大概把70%的精力花在"写"上——研究怎么取标题，怎么搭结构，怎么写开头。30%的精力花在"掏"上——阅读、思考、跟人交流。

现在反过来了。

我把大部分时间花在"让自己脑子里的东西变多、变深"——多读、多看、多跟人聊、多去真实的场景里泡着。然后在坐下来写的时候，我不再那么焦虑"怎么写"了。因为如果我真的有东西要说，写的过程反而是自然的。

最好的文章不是"写"出来的，是"掏"出来的。

这句话我在第三篇里写过。当时是作为一个"观点"写的。现在它变成了我真实的工作状态。

这就是内化。一个观点从"我写过它"变成了"我活在它里面"。

03

第二个变化跟"看人"有关。

我以前看一个厉害的人，会下意识地去分析他的"方法"——他用了什么框架？他的内容结构是怎样的？他的运营策略是什么？

现在我看一个厉害的人，第一反应变了。

我会先想：他的隐性知识是什么？

就是那些他不会在文章里写出来的、他自己可能都说不清楚的、但一直在驱动他做出好的判断和好的内容的那些东西——到底是什么？

比如有一个我很佩服的写作者。以前我分析他的文章结构、选题策略、语言风格，试图找到可以模仿的"技巧"。

现在我看他的文章时想的是另一类问题——

"他为什么对这个选题有感觉？他生活中一定经历了什么，让他对这个话题产生了真实的触动。那个经历是什么？"

"他在这里用了一个非常精准的类比。这个类比不是'想'出来的，是'见'出来的——他一定在某个瞬间看到了两个表面上毫无关系的东西之间的共通之处。那种'看到'的能力，是怎么长出来的？"

"他的文章有一种独特的节奏感。这种节奏感不是技巧，是品味。这种品味是从哪里来的？他读什么书？听什么音乐？跟什么人在一起？"

我开始透过一个人的显性输出去猜测他的隐性根基。

这个习惯直接改变了我"社会化"的方式。

以前我跟厉害的人交流，总想问"你是怎么做的"——我在索取方法论。

现在我更想知道的是"你是怎么想的"——你在面对这个问题的时候，脑子里最先冒出来的是什么？你犹豫了什么？你放弃了什么？你在什么地方觉得"不对"但说不清楚为什么？

前者问的是Techne。后者问的是隐性知识本身。

而我发现，当我开始问后一种问题的时候，对方反而更愿意跟我深聊。

因为几乎没有人问他们这类问题。所有人都在问"怎么做"。很少有人问"怎么想"。但"怎么想"恰恰是他们自己也没有完全想清楚的部分——被问到的时候，他们会停下来，认真地想一想，然后说出一些连他们自己都没有说过的东西。

这种对话的质量跟"请教方法论"的对话完全不是一个级别的。

SECI给了我一副看人的新眼镜。戴上之后，我看到的不再是别人外显的成果，而是成果下面那座冰山。

04

第三个变化最难描述。因为它不是认知层面的，而是身体层面的。

我写东西的"手感"变了。

三个月前我写文章，是这么一个流程：先想选题，然后列大纲，然后逐段填充，然后修改措辞，然后检查结构。像造房子一样，先画图纸再砌砖。

这个流程在前五篇左右的时候还管用。但到了第六篇第七篇，我发现自己的写法开始变了——

我不再先列大纲了。

我开始直接写。

从一个场景开始写。一个画面，一段经历，一个对话。写着写着，一个想法会从场景里"冒"出来。然后我跟着那个想法走。走到某个地方，另一个场景会冒出来。然后另一个想法从第二个场景里长出来。

整篇文章不是"搭建"出来的，而是"生长"出来的。

我不知道它最终会长成什么样。我写第一段的时候，不知道第五段会写什么。但我信任这个过程——如果我足够诚实地跟着感觉走，它最终会到达一个有意义的地方。

有时候到不了。写了两千字发现走进了死胡同。全部删掉重来。

但到了的那些时候，文章会呈现出一种用"先列大纲再填充"的方式写不出来的东西——一种有机的、活的、自己会呼吸的质感。

我不是在吹嘘自己写得有多好。这个系列里的十篇文章水平参差不齐，有些段落我自己回头看都觉得生硬。

我想说的是另一件事——

这种"写法的变化"不是我"决定"要改变的。它是自己发生的。

我没有在某一天早上起床后宣布"从今天起我要用新的方式写作"。我甚至没有意识到自己在改变。是写到第七篇第八篇的时候回头一看，才发现"咦，我现在写东西的方式跟三个月前不一样了"。

这就是内化的奇妙之处——

你不知道它什么时候发生的。你只能在事后回头看的时候发现它已经发生了。

就像面馆大叔说的"差在手上"。你的手不会在某一天突然变得不一样。它是在你日复一日的劳作中，一点一点、不知不觉地变了。

等你意识到的时候，它已经是一双新的手了。

05

但这三个月也有一些东西是没有变的。

我本来以为写完这个系列，我会变成一个"很懂知识管理"的人。

实际上我越写越觉得自己不懂。

第一篇的时候，我觉得SECI模型很清晰。四个象限，一个螺旋，逻辑自洽，简洁优美。

到了第八篇第九篇，我开始看到它的裂缝、它的边界、它解释不了的东西。每个象限展开之后都是一个巨大的领域——社会化背后是整个社会学习理论，外化背后是认知语言学和知识工程学，组合化在AI时代正在被彻底重写，内化涉及神经科学和行为心理学的深水区。

每一个方向展开下去都是几十年的学术研究。我只是摸到了门把手。

而Phronesis——实践智慧——那个东西就更不用说了。哲学家们争论了两千多年都没有争出一个共识。我一个写公众号的，怎么可能用一篇文章把它说清楚。

这个系列让我最深刻地感受到的一件事是：真正的学习不会让你觉得自己越来越懂。它会让你越来越清楚地看到自己有多不懂。

第一篇的时候，我站在SECI这座山的山脚下，看到一座山。我觉得"我大概知道这座山有多高了"。

十篇写完之后，我爬到了半山腰。我看到的不是山顶。我看到的是——这座山后面还有一整片山脉。

那片山脉的名字叫"我不知道的事"。

这种感觉不是挫败。它是一种奇怪的安心。

因为它意味着我还有很多东西可以去探索。螺旋还可以继续转。还有无数圈可以转。

那就继续转。

06

在写最后这篇文章之前，我把前面九篇全部重读了一遍。

读的时候我发现了一件让我有点感动的事。

这九篇文章，如果把它们连起来看，它们本身就构成了一个完整的SECI循环。

不是我设计的。是事后回头看才发现的。

第一篇和第二篇——我在做社会化。我在"泡"野中郁次郎的理论世界。读他的书，读别人对他的研究，感受这个理论的"气质"。那段时间我脑子里全是SECI，走路在想，吃饭在想，洗澡在想。不是在分析它，而是在"泡"在它里面。

第三篇到第六篇——我在做外化。我逼自己把对每一个象限的理解"掏"出来。写的过程极其痛苦。很多东西我以为自己懂了，一开始写才发现完全说不清楚。每一篇都是一次搏斗——跟自己脑子里那团模糊的东西搏斗，逼它变成清晰的句子。

第七篇和第八篇——我在做组合化。我开始把SECI跟其他东西连接起来——跟我自己的实践经验连接，跟AI时代的现实连接，跟其他理论框架连接，跟我观察到的企业案例连接。那些"连上了"的瞬间是这个系列里最让我兴奋的时刻。

第九篇和第十篇——我在做内化。我不再"讲解"SECI了。我在用SECI的视角回看自己的生活和选择。它不再是一个我在"介绍"的外部理论，它已经变成了我观察世界的一种方式。我不需要提醒自己"用SECI来分析"——我的眼睛自动就在用它看了。

十篇文章。一个完整的螺旋。

从"泡"到"掏"到"连"到"长在身上"。

最让我感慨的是——我在第一篇里写的那句话，"知识不是你'存'了多少，而是你'转'了几圈"，当时写下这句话的时候，我只是觉得"这个观点挺好的"。

十篇之后，这句话不再是一个观点。它变成了一段经历。我自己的经历。

我亲身转了一圈。

一圈而已。但足以让我理解这个螺旋的力量。

07

还有一件事我想在这最后一篇里说。

这个系列的十篇文章，总共大概五万多字。写的过程中我经历了几次低谷——觉得写不下去了，觉得没有新东西可写了，觉得自己在重复自己。

每次低谷的时候我都想过要不然就此收手，写个七八篇也差不多了。

但每次我都没有停。

不是因为我有多大的毅力。而是因为在每次低谷的底部，都发生了一件同样的事——

有一个人跟我说了一句话。

第四篇卡住的时候，是那个咨询朋友在电话里跟我说："你前三篇讲的都是'怎么做'，但你还没讲'为什么有些人做了但没用'。这个问题你自己有答案吗？"

这句话把我推进了第五篇——关于内化的那篇。

第七篇卡住的时候，是一个读者在后台给我发了一段很长的消息。他说他看完了前六篇，尝试用SECI模型重新设计自己的学习方式，但发现"我不是丰田也不是谷歌，我就一个人，这东西怎么用啊"。

这段消息把我推进了第七篇——关于一个人怎么转起来的那篇。

第九篇卡住的时候，是我偶然间读到了野中郁次郎晚年关于Phronesis的一篇论文。那篇论文里有一段话，他说他年轻时以为知识管理的核心问题是"如何创造知识"，到了老年才发现核心问题是"为了什么而创造知识"。

这段话把我推进了第九篇——关于实践智慧的那篇。

你看，每一次推我继续走的，都不是我自己的意志力。

是另一个人。

一个朋友的追问。一个读者的困惑。一个八十多岁的日本教授在论文里写的一段话。

知识螺旋从来不是一个人的事。

即使你是"一个人在转"——就像我在第七篇里写的那样——那个螺旋之所以能转起来，也是因为有别的人在别的地方、别的时间，用别的方式，把他们的东西传递给了你。

你以为你是一个人在写。其实你是一群人一起在写。

你以为你在创造知识。其实知识在通过你流动。

你只是这条河流中的一个弯道。水从上游来，经过你，流向下游。

你能做的，是让水经过你这段弯道的时候，变得稍微清澈一点。

08

好了。该说结尾了。

我不想做总结。这个系列的每一篇都有自己的核心观点，回去看就好了。把十篇文章的要点列成清单，那是组合化的事，AI比我做得好。

我想在最后说一段完全私人的话。

三个月前我开始写这个系列的时候，我的想法是：用SECI模型作为主题，写一组有深度的文章，建立我在知识管理领域的专业形象。

这个想法是诚实的。它是一个做知识IP的人会有的、合理的、功利性的想法。

但三个月之后，当我写到这最后一篇的此时此刻，我的感受跟三个月前不一样了。

我不再觉得这个系列是"我用来建立专业形象的内容产品"。

我觉得这个系列是——

一段旅程的记录。

这段旅程中，有一些东西真的在我身上发生了。不是我假装发生、也不是我希望发生——是我在写的过程中真实地经历了困惑、搏斗、卡壳、突破和领悟。

那个在第三篇开头崩溃了三小时写不出PPT的人是我。
那个在第五篇结尾引用面馆大叔说"差在手上"然后沉默了很久的人是我。
那个在第七篇里发现自己设计的"完美SECI系统"三周就崩了的人是我。
那个在第八篇里承认SECI模型有裂缝、承认自己前面的文章可能太理想化的人是我。
那个在第九篇里犹豫要不要写出自己拒绝了一个赚钱机会的人也是我。

这些不是"素材"。这些是我的生活。

而SECI模型给了我一种语言去描述和理解我的生活。

它让我看到了自己学习方式的盲区。
它让我理解了为什么有些知识"学了但没用"。
它让我开始有意识地去"泡"、去"掏"、去"连"、去"练"。
它让我在写这十篇文章的过程中，完成了一次真实的知识转化——从"我知道一个叫SECI的模型"，到"SECI已经成为我看世界的方式的一部分"。

这就是我在这个系列里学到的最大的一件事。

不是SECI的四个象限分别是什么。不是丰田和谷歌怎么做知识管理。不是AI时代组合化在被怎样重写。

我学到的最大的一件事是——

一个人要真正理解一样东西，没有捷径。你得花足够长的时间，用足够笨的方式，一圈一圈地转。

读一遍不够。想一遍不够。聊一遍不够。写一遍不够。

你得读了再想，想了再聊，聊了再写，写了再做，做了再回去重新读。

每一圈都觉得"好像更懂了一点"。但同时每一圈都会发现"还有更多不懂的"。

然后你接受这件事——学习不是一个有终点的旅程——然后你继续走。

不是因为终点在前方等着你。

而是因为走本身就是意义。

09

我想用一个画面结束这个系列。

想象你站在一栋螺旋形的建筑里。一条坡道从底层一直盘旋而上，看不到顶。

你从底层开始往上走。每走一圈，你会经过同一个方向的窗户。

第一圈，你透过窗户看到了一片风景。

第二圈，你又经过那扇窗户。你看到的是同一片风景——同样的山、同样的河、同样的天空。

但你看到的不一样了。

因为你高了一层。你的视角变了。

你看到了第一圈看不到的东西——山后面有另一座山。河在远处拐了一个弯。天空的颜色在边缘处跟中间不一样。

第三圈，同一扇窗户，同一片风景。但你又看到了新的东西。

风景没变。变的是你。

SECI螺旋就是这栋建筑。社会化、外化、组合化、内化——就是你每一圈经过的四扇窗户。

你看到的风景是你自己的人生——你的工作、你的关系、你的困惑、你的选择。

每转一圈，你看到的人生跟上一圈一样。

但你理解的深度不一样了。

这就够了。

我是一只阿木木。

这是"SECI模型"系列的第10篇，也是最后一篇。

谢谢你陪我走完了这一圈。

如果这个系列在你心里留下了什么，不管多小——一句话、一个画面、一个念头——那就够了。

不需要记住全部。不需要收藏。

让它在你心里待着。然后去生活。

生活会给你场景。场景会激活它。

然后在某一天，在某一个你没有预料到的瞬间，你会突然发现——

"哦。原来是这个意思。"

那就是你的螺旋又转了一圈。

获取资源包完整文件，请点击了解详情 →