夜雨聆风
如果让你做一个 AI 应用的"插件系统"——你会怎么设计？
我们当时的设计是——
用户写一段 JavaScript 代码 注册到一个"插件管理器" 插件管理器在某些事件触发时调用这段代码 代码里可以调 AI 模型
听起来很正经对吧？
最后没人写插件。
为啥？
门槛太高了。
要会 JavaScript 要会异步编程 要懂我们的 SDK 要写测试 要 debug
我们的用户——很多是产品经理、运营、设计师—— 他们不会编程。
他们能想到很多有价值的"AI 工作流"——但写不出代码。
跟着这本书读到第 22 章——讲技能系统那一章——我才看清：
Anthropic 把这件事做对了。
"技能"是什么——可调用的提示词模板
Claude Code 里有一种东西叫"技能"（skill）。
听起来像 RPG 游戏里的概念。
实际上它就是一份 Markdown 文件。
整本书里这一章给了一个最让我醍醐灌顶的定义——
"技能系统的本质是可调用的提示词模板。"
什么意思？
你想让 Claude Code 学会"重构整个代码库"这件事—— 传统做法——你得写一段代码——挂到 Claude Code 上。
技能做法——你写一份 Markdown 文档：
---
description: 5-30 个 worktree 并行重构代码库
when_to_use: 用户输入 /batch 时触发
allowed-tools: Bash, Read, Edit, Glob, Grep
context: fork
---
# Batch 重构技能
执行步骤：
1. 分析用户需求，把任务拆成 5-30 个独立工作单元
2. 为每个工作单元启动一个隔离的 worktree
3. 每个 worktree 由一个独立 Agent 处理
4. 维护状态表——记录所有 worktree 的进度
...
就这。
纯文本。Markdown 格式。前面带一段 YAML frontmatter 配置。
用户输入 /batch 把所有 React 组件迁移到 Vue—— Claude Code 加载这份 SKILL.md—— 注入到对话上下文——
模型按这份文档的指令去执行。
执行者不是你的代码——是 LLM。
LLM 按 Markdown 文档的步骤一步步做。
这套设计为啥牛——三个层级的差异
最关键的——"谁可写"那一行。
这意味着——产品经理可以写技能、运营可以写技能、设计师可以写技能。 他们最懂业务流程——他们不会编程也没关系——
他们写一份 Markdown 文档，就能让 AI 学会一个新流程。
我读完这一段后悔了两年。
两年前如果我把插件系统做成"写 Markdown 就行"——我那家初创公司可能不会挂。
skillify：用 AI 把 AI 自己变聪明
这一章最让我惊呆的是——Claude Code 有一个内置技能叫 skillify。
它是干啥的？
把当前会话蒸馏成一个可复用的新技能。
具体流程——
你跟 Claude Code 在某个会话里慢慢摸索——做完了一件复杂的事情 你跑 /skillify Claude Code 回顾整个会话—— 你问了啥 它做了啥 哪些地方你纠正了它 最终怎么完成的 它生成一份新的 SKILL.md——下次你直接用这个技能就行
整个流程是个"四轮访谈"：
Round 1：技能名称、描述、目标、成功标准
Round 2：步骤列表、参数定义、执行模式（inline 还是 fork）
Round 3：每步的成功标准、产出物、人工检查点、并行机会
Round 4：触发条件、边界情况
四轮访谈结束——一份完整、可复用的 SKILL.md 出现在你的 .claude/skills/ 目录下。
这套机制的妙处——
"AI 用 AI 的能力，把 AI 的能力拓展。"
正常情况下——你想让 AI 做某件事更好——你得手写提示词、调试、迭代。
skillify 让 AI 自己写这份提示词——把刚才会话中"行得通"的部分蒸馏出来。
这就是工程上一个自指（self-referential）的设计——
系统能扩展自己。
"关注用户纠正过你的地方"——核心洞见
skillify 这一章里有一句话让我抄下来贴在了办公桌上——
"关注用户纠正过你的地方——这些纠正往往包含最有价值的隐性知识。"
什么意思？
你跟 AI 干活——
90% 的时候 AI 直接做对——这些是"已知好做法"——技能里写不写都行 10% 的时候 AI 做错——你纠正它"应该这样做"——这 10% 是金子
为啥？
因为这 10% 是 AI 自己想不到的——只有你（人类）才知道。
你的项目有个特殊的代码规范——AI 不知道——你纠正它。 你的团队有个特殊的工作流——AI 不知道——你纠正它。 你的业务有一个特殊的边界——AI 不知道——你纠正它。
这些"纠正"是隐性知识——藏在你脑子里——AI 想不到、不知道。
skillify 的设计就是——专门挖掘这些纠正—— 把它们写进 SKILL.md——下次 AI 就不会再犯。
我把这套思路用到了我自己的工作上——
每次跟 AI 干活——遇到我纠正它的地方——我专门记下来。 积累一段时间——我有了一份"AI 容易做错的清单"—— 我把这份清单写成系统提示词——AI 出错率降低 60%。
纠正是金子——不是负担。
batch 技能：5-30 个 worktree 并行
最后讲一个让我看完叫绝的内置技能——batch。
它是干啥的？
用 5-30 个独立 worktree 并行重构代码库。
具体流程——
你说"把所有 React 组件迁移到 Vue" batch 技能启动——
研究阶段：前台 Agent 分析项目，把任务拆成 5-30 个独立工作单元（每个组件一个） 并行阶段：每个工作单元启动一个独立的 git worktree——派一个独立 Agent 处理 追踪阶段：维护状态表——记录每个 worktree 的进度、PR 链接
几十个 AI 同时干活——互不打架。
为啥要 5-30 个？
太少——并行度不够，速度慢 太多——超过你机器的并发能力，反而慢
源码里直接写：
MIN_AGENTS = 5
MAX_AGENTS = 30
有数字，没争论。
更妙的是——batch 技能配置了 disableModelInvocation: true：
disableModelInvocation: true什么意思？
模型不能自己调用 batch 技能——
只有用户显式输入 /batch 才能触发。
为啥？
因为大规模重构是危险的事——
一次改 30 个 worktree 每个 worktree 跑一个独立 Agent 烧的 token 是平时的 30 倍 出错的代价巨大
这种事不能让 AI 自主决定——必须人类显式触发。
这一条配置——保护用户钱包 + 保护项目质量。 朴素但关键。
1% 上下文窗口预算——技能系统的内存约束
讲到技能——这一章还讲了一个我在第 8 章就埋下钩子的细节。
技能列表本身要占上下文空间——
Claude Code 给它的预算是 1% 的上下文窗口：
SKILL_BUDGET_CONTEXT_PERCENT = 0.01
DEFAULT_CHAR_BUDGET = 8000 // 200K × 4 × 0.01
MAX_LISTING_DESC_CHARS = 250
什么意思？ 所有技能加起来——最多占 8000 字符——大概几十个技能的简短描述。
超了怎么办？三级降级——
Level 1：完整描述（如果不超 8K 字符）
Level 2：超了——非内置技能描述截短
Level 3：还超——非内置技能只显示名字
注意——内置技能永远保留完整描述。 为啥？因为内置技能是 Anthropic 精心设计的——它的"何时调用"对模型决策至关重要。
这套设计透着一个工程哲学——
有限资源下的智能分配：
重要的（内置）保留完整 次要的（用户自定义）允许截断 实在装不下——只留名字——用户调用时再加载完整内容
这一章给我的最大启发
读完这一章我有一个反思——
做 AI 应用，最关键的扩展性不是"能写多少代码"——是"能写多少提示词模板"。
代码扩展——
门槛高（要会编程） 演进慢（改代码 + 发版） 谁可写：工程师
提示词扩展——
门槛低（写文档就行） 演进快（改 Markdown 立即生效） 谁可写：任何会写文档的人
降低创造的门槛——是产品的核心壁垒。
我现在做任何 AI 工具——优先做"提示词模板"扩展——后做"代码"扩展。 让 AI 时代的"产品经理"也能直接拓展产品功能——这是 AI 时代的'低代码'。
Part 6 进度更新
这是系列第 25 篇。 Part 6 还剩 Ch22b 插件系统、Ch23 Feature Flag 路线图、Ch24 跨会话记忆。
下一批拆这三章——会讲：
插件系统从打包到市场——技能系统的扩展生态 89 个 Feature Flag 背后的产品路线图——Anthropic 在 AI 时代的下一步 跨会话记忆——AI 怎么"记住"你的偏好