AI Coding：一场被迫的「认知大扫除」
持续交付20约 5 分钟上周我让 Claude Code 帮我重构一个旧模块。它很听话，三分钟给出了完美方案，然后我盯着屏幕发了呆。
因为它用的设计模式，正是我三年前决定不再使用的。问题并不在于 AI，而在于我自己。
我没把「为什么不这么做」写下来。
1 我们最值钱的经验，都在脑子里「睡大觉」
20 世纪英国哲学家迈克尔·波兰尼（Michael Polanyi）有个著名论断：We know more than we can tell——我们知道的远比能说出来的多。
这话在软件行业特别扎心。
想想看：
- 为什么这个模块「只能这么写」？ → 「经验告诉你」
- 为什么那个接口「千万别改」？ → 「踩过坑」
- 为什么这个架构「虽然丑但稳」？ → 「别问，问就是历史」
这些「只可意会」的东西，才是你作为老工程师的真正护城河。
但问题是，它看到的只有代码，看不到你脑子里的「为什么」。
一个真实场景
我同事老张修一个 Bug，AI 给了五种方案。他选了最快的那个。
两周后，另一个功能崩了。因为那个「最快方案」破坏了某个隐式的业务约束。
老张很郁闷：「我怎么知道它不知道这个约束？」
答案很简单：因为你从没把它写下来。
2 AI 成了「最笨的读者」：它不懂你的潜台词
过去我们写文档，是为了「整理已经想清楚的事」。
现在让 AI 干活，你必须写「你从未想清楚过的事」。
为什么？
因为 AI 有个特点：它不理解潜台词，也不接受模糊指令。
# 你以为你说了「足够清楚」"优化一下这个函数"# AI 看到的"随便改，只要跑起来就行"# 你想要的是"优化这个函数，但要保证：1. 不破坏向后兼容（因为 V2 API 还在用）2. 不能增加超过 50ms 延迟（SLA 约束）3. 保留原有的错误重试逻辑（业务要求）"
看见了吗？那些你「理所当然」的假设，AI 根本看不到。
被迫「显性化」的代价
前阵子我整理项目的 project.md，列了「十不做」清单：
不做继承超过两层的抽象 不做「未来可能用到」的扩展点 不在业务代码里加 V2、V3这种命名不让 if-else嵌套超过三层...（还有五条）
写的时候我突然意识到：这些规则，我从没跟他们直接说过。
“想说”是真的“想说”，但是，真的「没说清楚」。
直到 AI 逼着我把它们写下来。
3 三种知识，三种「显性化」难度
不是所有知识都难写。根据我的经验，可以分成三类：
显性知识（最容易）
就是那些「能写进教科书的」。
比如： - Redis 是内存数据库 - Git 用 commit 提交代码 - RESTful API 用 GET/POST/PUT/DELETE
AI 已经很擅长了，不用你教。
不过有意思的是——知道「是什么」和知道「为什么选它」是两码事。
隐性知识（中等难度）
需要「做给你看」的知识。
比如： - 怎么用 gdb 调试段错误 - 怎么看日志定位性能瓶颈 - 怎么在 Code Review 里温和地拒绝一个方案
这部分，AI 现在能帮你「抄下来」。
举个例子，我让 AI 观察我怎么用 kubectl 排查 Pod 启动失败，它总结了七步排查法。现在新人直接照着做就行。
缄默知识（最难）
还是波兰尼所说的「只可意会不可言传」的部分。
比如：
- 「这个需求感觉不对劲」（但说不出为什么）
- 「这段代码看着就别扭」（但能跑）
- 「选方案 A 不选 B」（因为历史原因）
这部分，AI 会逼着你第一次「文本化」。
我的做法是写 TASTE.md（品味文档），不写硬规则，只写偏好：
# 我们的「品味」1. 我们宁可复制粘贴，也不做「可能有用的抽象」2. 我们认为「能跑的丑代码」好过「优雅的过度设计」3. 我们更信任「一眼能看懂的 50 行」而不是「精巧的 10 行」4. 我们相信「显式的错误处理」胜过「优雅的异常链」
但这称不上「规则」，最多算是偏好的影子——尽管，有影子总比没有影子好。
说到底，Harness engineering 和 AI agent Skill 的编写，本质上就是把「只可意会」的缄默知识，一步步结构化为显性知识的过程。
当我写下 TASTE.md、WHY.md、NO.md，我做的不是「写文档」——而是把那些从未被文本化的工程判断力，变成了可复用、可传承、可被 AI 理解的资产。
这就是从「我知道怎么做」到「我知道为什么这么做」的认知显性化。
4 坑：别把「品味」变成「KPI」
这里有个坑，我亲眼见过。
有个团队把「代码品味」量化成了 数十条规则，然后用 AI 自动检查。
结果呢？
代码确实「合规」了 但没人敢改任何东西了（怕触犯某条规则） 新需求来了，大家先问「规则允许吗」，而不是「用户需要吗」
这就是 Goodhart 定律：凡被度量的，都会被扭曲。
我的建议：留出「不可度量」的空间
我们在项目里故意留了四个「不写清楚」的地方：
- 战略方向感
→ 只能聊，不能写（一写就僵化） - 价值观底线
→ 规则化就会出现「规则没禁止所以可以做」 - 肌肉记忆式禁忌
→ 一旦被理性化就失效了 - 审美争论
→ 两个资深工程师为代码吵一下午，本身就是健康信号
AI 是工具，不是老板。别让它替你做价值判断。
5 从今天开始「显性化」：AI 不是缰绳，是镜子
如果你也想试试，给你一个「三步走」方案：
第一步：写一份
别写「怎么做」，写「为什么」。
# 为什么这个模块这么丑？因为 2023 年我们试过微服务化，结果：- 网络延迟增加 30ms- 调试复杂度指数级上升- 新人入职周期从 1 周变成 1 个月所以不是我们不会优雅设计，是**代价太大**。
AI 看到这个，就不会再建议「拆成微服务」了。
第二步：把「不」写下来
创建 NO.md 或 AVOID.md：
# 我们不做的事1. ❌ 不要用多于两层继承（超过两层就拆）2. ❌ 不缓存用户会话（因为一致性问题踩过坑）3. ❌ 不在周五下午发布（血的教训）4. ❌ 不用 `V2/V3` 命名（会让人觉得旧版还能用）
这些「不」，才是你真正的经验财富。
第三步：定期「复盘」你的品味
每月花半小时，和团队一起聊：
「最近哪段代码让你觉得「别扭」？」 「AI 给的方案哪里不对劲？」 「如果重新来，你会改什么？」
把聊出来的东西，补充到 TASTE.md 里。
经验的影子，比规则有温度。
那位做了八年的老工程师，花了两小时写下的《项目品味说明》，不是写给 AI 看的，是写给他自己看的。
AI 只是逼他第一次面对那些「以为自己知道，其实从未想清楚」的事。
这哪里是效率工具？这是一场被迫的认知大扫除。
而且，这场扫除，才刚刚开始。
如果你也想试试「显性化」，从写下第一份 WHY.md 开始吧。你会发现，那些「说不清」的东西，才是你最值钱的资产。