YC Startup School 的舞台上，主持人 Diana Hu 问 Jeff Dean 一个问题。在此之前，Dean 刚讲了他和搭档 Sanjay 写的一个性能优化 Skill——教模型自己做「跑 benchmark → 改代码 → 测提升 → 再迭代」的闭环。Diana 听完说：「如果谁拿到这个 Skill，就能像 Jeff Dean 一样做性能优化了。这东西肯定价值无限。有人能拿到它吗？」
Jeff Dean 的回答出乎所有人意料：「哦，我们其实把它公开了。」
他说的是他和 Sanjay 合写的一份 30 页文档，叫 《Performance Hints》。后面还有一个细节：有人把这份文档做了摘要，喂给不同的模型，发现模型在性能问题上的推理能力真的变强了。
全世界都想要的东西，他直接公开了。这一幕值得多看两眼——因为它指向一个被严重低估的变化： 组织里最值钱的知识，载体正在从「写给人读的文档」悄悄换成「写给 Agent 执行的 Skill」。
一、Jeff Dean 在 Google 内部干了什么
先看他在对谈里讲的三件事，都是 Google 内部正在跑的实践。
第一件：微基准 Skill。 Dean 和 Sanjay 维护着一个 Google 内部的微基准库，很多数据结构被上百万个进程使用，性能至关重要。过去做性能优化的流程是：人测一遍基准 → 改代码 → 重测 → 看缓存足迹 → 再改。他们把这套流程写成了一个 Skill 交给模型，模型就能自己跑完整个循环——测、改、验证、迭代，全程不用人盯。
第二件：Google 内部工具 Skill。 这是更关键的一件。Dean 说，Google 内部给 Agent 配了一整套 Skill，教它用内部专有的开发工具：写代码、做代码评审、测性能、拉日志。注意这里的问题——模型从来没有在「Google 工程师怎么从专有系统里拉日志」这件事上训练过，这是纯粹的内部知识，互联网上不存在。但 Dean 说，只要 Skill 定义得当，模型就能干。
第三件：公开 《Performance Hints》。 就是开头那一幕。几十年沉淀的性能优化经验，没有锁在内部，而是写成文档公开，而且公开的方式天然适合喂给模型。
三件事放在一起，模式很清楚：Google 没有指望模型「自己学会」内部知识，也没有指望工程师去读文档然后转述给模型——他们把专家知识直接写成了 Agent 可执行的格式。
二、文档为什么撑不住组织知识
先说清楚我不是在贬低文档。我在 继编程之后，大模型应用的下一个爆发场景是知识管理 里讲过知识管理为什么重要，也在 数字员工是下一个十年的故事 里说过知识库注定腐烂的原因。这里只把结论压缩一下：文档作为组织知识的载体，有三个结构性缺陷。
读者是人，阅读率天然低。 一份 SOP 写出来，真正读完的人可能不到一成。知识没有被消费，就等于没有被传递。
无法验证对错。 文档写得对不对、过时没有，只能靠人凭经验判断。大多数时候没人判断——于是文档安静地腐烂，直到某个人按它操作翻了车。
没有反馈信号。 文档过时的第一天，没有任何事情发生。没有报错，没有告警，组织感知不到损耗，自然也没有维护的动力。
这三个缺陷的共同根源是：文档的验证回路经过人。而人这个环节，又慢又贵又不稳定。
三、Skill 和文档的三个本质区别
有人会问：Skill 不就是「可执行的文档」吗？写文档不就够了？
不是。两者有三个本质区别，每一个都改变了知识维护的激励结构：
| 知识库文档 | Skill | |
|---|---|---|
| 读者 | 人 | Agent |
| 验证方式 | 人凭经验判断对错 | 执行结果直接判定（可度量） |
| 腐烂时的信号 | 无——没人发现 | Agent 当场失败，纠错信号立刻回流 |
| 维护激励 | 弱——写文档没产出，改文档更没产出 | 强——不改，Agent 就干不了活 |
最容易被忽略的是第三行。文档过时是无声的，Skill 失效是响亮的——Agent 会当场失败，失败会暴露出错在哪一环，纠错会回流成 Skill 的更新。我在 数字员工背后的 Agent，是五层基础设施的叠加 里讲学习层时说过：每一次人类的纠错、确认、驳回，都是学习信号。Skill 就是这些信号天然的落点。
还有一个更隐蔽的价值： 写 Skill 会逼你把隐性知识显性化成可执行的形式，这本身是最严格的知识审查。 专家做事经常「说不清怎么做的，凭手感」。文档可以容忍这种模糊——写一句「根据经验判断」就能蒙混过去。但 Agent 不接受模糊：你要把它写成 Skill，就必须回答「什么条件触发、分几步、每步的输入输出是什么、什么情况升级给人」。写不出 Skill 的地方，恰好就是组织里最珍贵也最危险的隐性知识所在地。
一个 Skill 大致长这样：
# 技能：生产配置回滚
触发条件：收到回滚请求，且目标为 prod 环境
步骤：
1. 读取当前配置版本与上一个稳定版本
2. 对比差异，列出变更项，发给审批人
3. 审批通过后执行回滚
4. 调用健康检查接口验证，失败则告警并停手
边界：数据库 schema 变更不在回滚范围，升级给人
# generated by hugo AI
九行。但每一行都是把某个老员工脑子里的「这种事我们一般这么处理」翻译成了 Agent 能执行的指令。注意第 4 步——验证环节必须写进 Skill 本身，这是下一节的关键。
也要诚实地说一个边界： Skill 的「响亮」是有条件的——只有当错误会体现在执行结果上时才响亮。 回滚没做对，健康检查会报警，这是响亮的；但一个写周报摘要的 Skill 悄悄漏掉了一个关键决策，输出看起来依然通顺——这种失效和文档腐烂一样无声。所以写 Skill 时，验证环节不是可选项：能接客观校验的（接口、测试、格式）就接上；接不上的，至少要设计一个人工确认的关卡。没有验证环节的 Skill，只是换了一种格式的文档。
四、对组织意味着什么
我在 让 AI 自己写 Skill：可进化 Agent 的设计原理与最佳实践 里讨论过个人 Agent 的 Skill 体系——把自己的写作风格提炼成 Skill，让 Agent 越用越像我。今天这篇是往上走一层：个人有个人的一套，组织也一样，而且组织这一层的 stakes 大得多。
个人的隐性知识流失了，损失的是一个人的效率；组织的隐性知识流失了——老员工离职、团队解散、流程失忆——损失的是组织能力本身。过去这些知识唯一的归宿是文档，而文档撑不住。现在第一次有了第二种载体：写给 Agent 执行的 Skill。
顺着这个方向看，数字员工是下一个十年的故事 里那个判断可以再推一步：知识库不是「被人维护的对象」，而是「数字员工工作的副产品」——而这个副产品的主要形态，不是文档，是 Skill。组织每天的协作里，每一次专家处理疑难、每一次老员工带新人、每一次事故复盘，都是把过程写成 Skill 的机会。文档会腐烂，但 Skill 每天都在被 Agent 执行、被结果验证、被纠错更新——它是活的。
五、怎么开始
不需要先建什么知识管理平台。三步就能开始：
- 挑一件专家反复在做、且很难招到第二个人会做的事。 它通常是某个老员工脑子里的「这种事我处理过一百次」。
- 让专家做一次，把过程完整录下来。 注意录的是过程，不是结果——包括他看了一眼什么、排除了什么、为什么走这一步。
- 写成 Skill，让 Agent 执行，用执行结果做验收。 第一次一定写得不对，没关系——Agent 的每次失败都在告诉你，专家的哪个判断还没被显性化。
这件事的复利在于：第一个 Skill 最贵，因为要摸索格式和边界；往后每一个都更快，因为组织的「怎么写 Skill」本身也在变成 Skill。
写在最后
Jeff Dean 在 YC 上还说了一句值得记住的话：模型只是系统的一个零件，真正要构建的是会用工具、会检索、带着历史工作的完整系统。
零件大家都能租到，系统里沉淀的东西才是自己的。而系统里最值钱的沉淀物，就是那些把你的组织「到底是怎么做事的」写下来的 Skill。
过去二十年，组织知识写给人读；接下来的十年，它会越来越多地写给 Agent 执行。你的组织里，有多少隐性知识还锁在专家的脑子里，又有多少已经变成了 Agent 能执行的 Skill？欢迎留言聊聊。