AI SDD 开发规范-21-隐性知识（Tacit Knowledge）
2025/11/20大约 4 分钟
隐性知识（Tacit Knowledge）
AI 编程的核心瓶颈不是“不会写代码”，而是“无法自动获得、理解和持续维护隐性知识（Tacit Knowledge）”。
下面我从**什么是隐性知识 → 它为什么对 AI 特别致命 → 现有方案为什么都不够 → 可落地的系统性解决路径（工程级）**四个层次展开。
一、什么是“隐性知识”（在工程语境下）
在真实工程中，隐性知识不是“经验主义”，而是大量未被显式表达、却真实约束系统行为的事实。
在代码层面，它通常表现为：
- “这个接口不能随便改，下游有老系统”
- “这里必须先查 DB 再查缓存，否则会打爆 ES”
- “这个字段名历史原因不能动”
- “这里 catch 了异常是为了兼容老客户端”
- “这段代码很丑，但千万别重构”
这些知识：
- 不在代码里
- 不在 README
- 甚至不在设计文档
- 只存在于：
👉 人的脑子里 + 历史事故里
二、为什么“隐性知识”对 AI 编程是致命的？
1️⃣ LLM 的世界是“显性文本宇宙”
LLM 能理解的前提是：
信息必须被“说出来”
而隐性知识的本质是：
- 默认共识
- 历史妥协
- 反复踩坑后的“禁区”
👉 没人写，它就不存在
2️⃣ AI 极容易做“局部最优、全局灾难”的修改
典型场景：
“我只是让 AI 优化一个方法”
但这个方法：
- 被某个定时任务假定是幂等的
- 被某个 MQ 重试逻辑依赖副作用
- 被某个灰度逻辑隐式调用
AI 不知道这些“非显性契约”。
3️⃣ 隐性知识往往是“负向知识”
最危险的隐性知识是：
- ❌ 不能做什么
- ❌ 哪些地方不要碰
- ❌ 哪些 bug 是“已接受的坏味道”
而 LLM 的训练目标是：
生成“看起来更好”的代码
这与“历史妥协”天然冲突。
三、为什么常见方案解决不了这个问题？
❌ “多写点文档”
- 人不会主动写“不要改这里”
- 文档很快过期
- 无法覆盖真实运行约束
❌ “多喂上下文”
- 隐性知识本来就不在上下文中
- Prompt 不是魔法
❌ “RAG + 知识库”
- RAG 只能检索已存在的知识
- 对“没人写的坑”无能为力
四、真正可行的解决方向（工程级）
下面是重点：不是一个方案，而是一组协同机制。
1️⃣ 把“隐性知识”强制转化为“显性约束”
不是写说明，而是变成 AI 必须遵守的规则。
你的 GEMINI.md 本质已经在做这件事
可以进一步升级为：
📌 《AI 行为约束清单》
示例：
## 不可修改区域（Hard Constraints）
- 不允许重构 auth 模块
- 不允许修改 public DTO 字段名
- 不允许引入新依赖
- 不允许改变接口返回结构👉 禁止比建议更重要
2️⃣ 用“失败史”作为一等知识源
隐性知识最密集的地方是哪里？
事故、Bug、回滚、线上问题
工程化做法：
每个严重 Bug：
- 根因
- 为什么当初这样设计
- 如果 AI 来改，哪里会踩雷
沉淀为：
## Known Traps / Historical Landmines
- 2021-05: 修改缓存 key 导致全量失效
- 2022-11: 改动超时策略引发雪崩👉 这是 AI 最有价值的训练语料
3️⃣ 设计“澄清优先”的 AI 执行模式
你之前提到的：
spec-kit 的澄清阶段
这是极其正确的方向。
原则：
凡是涉及行为变化，AI 必须先提问
示例规则：
- 改接口语义 → 必须列风险
- 改数据结构 → 必须询问历史兼容性
- 改并发逻辑 → 必须假设存在隐性依赖
这是在模拟资深工程师的谨慎。
4️⃣ 用“负例驱动”的提示词设计
普通 Prompt：
“请帮我优化这段代码”
工程级 Prompt：
“请在不破坏以下隐性约束的前提下修改，否则拒绝执行”
如果你无法确认以下隐性约束是否成立，请先提出澄清问题，不要直接改代码。👉 允许 AI 拒绝执行，是成熟系统的标志
5️⃣ 把“不能改”固化为结构，而不是靠记忆
例如：
- 黑盒模块（只暴露接口）
- Legacy Zone（只允许 bugfix）
- 冻结包 / 冻结目录
- 编译期校验（字段、接口 hash）
这本质是：
用工程手段封装隐性知识
六、一个非常重要的认知升级
隐性知识不是“AI 的缺陷”，而是“工程长期不规范的成本”。
AI 只是：
- 把这些问题提前暴露
- 把“靠人兜底”的系统，变成“必须显性化”的系统
七、最终结论（工程视角）
如果我帮你总结成一句工程原则：
不要试图让 AI“理解隐性知识”，而是要让系统“不允许隐性知识存在”。