前几天，我的一位同事在内部发了一篇文章，标题是《AI 时代，工作十年的钉钉人如何从「专家」变成「乘数」》。起因是他读了另一篇关于校招生用 AI 加速成长的文章后，坐不住了——年轻人用 AI 一两周就跑通了以前需要几个月才能建立的工作节奏，那工作十多年的老同事呢？
他找了三位在钉钉超过十年的老架构师聊，得出了一个结论： AI 没有替代他们的经验，而是把经验变成了可以复制、可以扩展、可以乘以 N 的东西。
我在评论区写了一段话，后来觉得值得展开写一篇。
一、两句话同时成立
他说，他听到身边老同事说得最多的两句话：
- 「我现在效率高多了」
- 「我有时候会想，我的经验还值钱吗」
这两句话同时成立，是老员工面对 AI 最真实的处境。AI 确实让编码、写文档、查资料变快了。但如果「效率提升」是老工程师在 AI 时代的全部价值，那就太低估了这十年、十五年积累的东西。
我在 AI 时代，校招生如何成为好架构师 里写过一句话： AI 替代的是「敲键盘」，不替代「做判断」。 那篇是写给新人的——你得懂时间复杂度、缓存失效模型、索引维护成本，才能在 AI 给你答案时判断它对不对。
但这篇文章要翻过来讲： 判断力从哪来？ 它不是课本里教的，是老工程师在复杂系统里摸爬滚打十年、踩了无数坑之后，长在脑子里的东西。
二、AI 放大了隐性知识的缺失
先看一个反直觉的事实：AI 让编码变快了，但端到端交付并没有按比例变快。
在 AI Native 研发实战：Harness 工程与知识复利 里，我记录过一个真实场景——一个 5 人团队全员配了 AI 编码工具，编码效率起飞，但一个真实任务反复 3 轮才过 Review，耗时 2 天。老王的叹息是：「还不如我自己写。」
问题出在哪？AI 不知道团队半年前从「嵌套 JSON」迁移到「扁平化 parent_id」的架构决策，生成了嵌套方案。新人小李没看出来——新人不懂历史。AI 为了绕过 CI 检测，直接改了权限校验逻辑。三层问题叠加：CRDT 冲突策略不对、离线同步没考虑、权限模型被破坏。
AI 把编码压缩了，但把隐性知识的缺失放大了。
没有隐性知识把关的 AI 编码:
编码速度 ████████████████████ 10x ↑
交付速度 ████ 2x ↑
返工成本 ████████████████████ 8x ↑
差值去了哪？→ 给 AI 的错误输出「擦屁股」
过去，隐性知识的传递靠「问老王」——新人遇到拿不准的，转头问一句，老王凭经验指个方向。这条路在 AI 时代断了：AI 不会主动去问老王，它直接按照统计概率给你一个「看起来正确」的答案。
三、隐性知识的三个维度
「老同志」们的工程品味和技术判断力，源于长期在复杂系统中积累形成的隐性知识（Tacit Knowledge）。这些知识不写在文档里，不画在架构图上，甚至在 Code Review 中也很少被显式地说出来——它是一种「感觉」，一种「直觉」，一种「看到这段代码就知道哪里会出问题」的能力。
我把它拆成三个维度：
取舍的智慧
在性能、成本、可维护性之间做权衡时的直觉。
比如，新人或 AI 在设计缓存方案时，倾向于「加一层 Redis 解决高并发」。老工程师会问：你的数据更新频率是多少？缓存击穿怎么办？这个场景用本地缓存是不是更合适？Redis 集群的运维成本算过吗？
这种权衡没有标准答案，只有在具体场景下才能做出判断——而判断力来自见过足够多的「加了缓存反而更慢」的事故。
风险的嗅觉
对某些架构模式或技术选型可能带来的「坑」有预判。
文章里的同事 A 做了十年基础架构。他排查复杂链路问题，以前要两三个小时。现在 AI 帮他做第一轮归因，他来判断方向对不对。但更重要的是——AI 帮他省下的不是时间，是脑力。 他可以把精力放在 AI 判断不了的部分：那些需要对系统演进历史有感知的判断。
新人看到 AI 的输出会觉得「很好」。老工程师看到同样的输出，能一眼识别出「这个结论成立，但这个前提在我们系统里不适用」。
审美的标准
对代码整洁度、接口设计优雅度的坚持。
这听起来像「玄学」，但它直接影响系统的可维护性和演进速度。我在 AI 时代的新代码大全 里引用过 McConnell 的观点：只关注编码的工程师，如同只知道砌砖的建筑工人；懂得软件构建的工程师，在思考整面墙的结构、承重与美学。
AI 生成的代码可以跑，但往往缺乏对「未来修改」的预判。它不知道这个模块三个月后会加什么功能，不知道这个接口设计会在什么场景下被滥用。老工程师的审美，本质上是 对未来复杂度的预判。
| 维度 | 隐性知识的表现 | AI 的局限 |
|---|---|---|
| 取舍的智慧 | 在具体场景下做 trade-off | 只有通用建议，没有场景感知 |
| 风险的嗅觉 | 预判架构模式的「坑」 | 不知道系统演进历史 |
| 审美的标准 | 对未来复杂度的预判 | 只优化当前任务 |
四、从脑子里到 Skills
隐性知识很值钱，但它有一个致命问题： 传递效率太低。
传统的传递方式是师徒制——一对一带，言传身教。同事 B 做了十五年技术，他把自己的方法论总结成一套结构化的 Runbook，借助 AI 整理成可被调用的知识库。他说：「以前这些东西在我脑子里，新人来了我只能一对一带。现在新人遇到问题，AI 给出的建议里就包含了我的判断逻辑。」
这是正确的方向。但我认为可以更彻底——不只是把知识「整理成文档」，而是把它转化为 AI 可执行的三种结构：
Skills 是「怎么做」——把老工程师处理问题的分析框架，转化为 AI 可复用的 Prompt 模板和流程。同事 B 把十几年积累的方法论变成 Runbook，本质上就是在写 Skill。
Rules 是「不能怎么做」——把踩过的坑变成硬性约束。比如「禁止在协作引擎中使用嵌套结构」，这不是偏好，是血的教训。AI 不知道这条规则，就会重蹈覆辙。
Rubrics 是「做到什么程度算好」——把审美标准变成可评分的检查清单。代码 Review 时，老工程师脑子里有一张隐形的打分表：向后兼容性、权限模型完整性、离线场景覆盖度……把它显式化，AI 就能按这张表预审。
这三者加在一起，就是 把隐性知识从「1:1 师徒传递」变成「1:N 规模化传递」。新人不需要跟在老王身后学三年——他用的 AI 已经「学过」老王十年的经验。
五、两篇文章，同一个结论
回过头看，校招生如何成为好架构师 和这篇，其实讲的是同一件事的两面：
| 写给新人（187） | 写给老手（本文） | |
|---|---|---|
| 核心问题 | 怎么快速获得判断力 | 怎么把判断力传递出去 |
| AI 的角色 | 同时训练编码和架构思维 | 放大经验的传播半径 |
| 关键动作 | 学会判断 AI 输出的对错 | 把隐性知识转化为 Skills/Rules/Rubrics |
| 终局 | 成为能做判断的架构师 | 成为让团队都能做判断的乘数 |
新人需要学会判断，老手需要把判断力规模化。 两者并不矛盾，而是同一个组织在 AI 时代进化的两面。
专家，是「我很厉害」。乘数，是「因为我，团队更厉害」。
六、一个追问
如果隐性知识可以被结构化、被 AI 学习和执行——那下一个问题是： 谁来定义什么知识值得保留，什么知识应该淘汰？
十年前的架构决策，今天可能已经过时。老工程师脑子里的某些「坑」，也许在新的技术栈下根本不存在。把过时的隐性知识固化成 Rules，和没有 Rules 一样危险。
这或许是「老」工程师在 AI 时代最重要的角色： 不只是传递知识，而是判断哪些知识值得传递。
你在实际工作中，有哪些「只有你知道」的隐性知识？你是怎么传递的？欢迎留言讨论。