一个模块的设计文档半年内被三个人用助手"润色"过。每次改动都不大：补一句说明、调一次结构、扩写一段背景。半年后新同事读这份文档，得到的印象与代码实际情况有三处不一致——而每一处都能追溯到某次"润色"里一个小小的概括。
AI 辅助写文档的风险不在"写错"，而在平滑的失真：它把不确切的地方写得更像确定的，把有争议的地方写得更像共识。单次改动看不出来，累积起来就把一份"记录决策"的文档变成了一份"看起来完整的说明文"。
1. 失真的四种形态
| 形态 | 机制 |
|---|---|
| 确定性升级 | "我们倾向于 A" → "我们采用 A" |
| 范围扩大 | "这个模块的接口" → "本系统的接口" |
| 因果简化 | 省略前提，只留结论 |
| 细节补全 | 原文没写的数字被"合理"补齐 |
四种形态还能叠加：先扩大范围，再把"倾向"升级为"采用"，最后删掉前提——一次改写就能把一条有条件的经验变成一条无条件的规范，而读者看不出它曾经有条件。
第二项最隐蔽：范围词是模型的常见放大器，"本模块"变成"本系统"只差两个字，但责任范围扩大了一个量级。
第三项是"读起来更顺"的代价：因果链里的前提被删掉后，结论变成了无条件断言。
2. 为什么助手会做这种升级
| 原因 | 说明 |
|---|---|
| 训练目标偏好连贯 | 转折与限定会让文本"不顺" |
| 缺少系统上下文 | 不知道哪些词是精确的 |
| 倾向于补全模式 | 见到"设计文档"就按模板补 |
| 无责任约束 | 它不承担后果 |
还有一个更隐蔽的机制：助手会补齐"应该有"的章节。设计文档"通常有"风险与备选方案，于是它补上一段——内容合理但与实际不符，而读者会以为这些是当初真的考虑过的。
第三项最实际：你让它"润色"，它就会把一段话改得更像这类文档通常的样子，而"通常的样子"里包含大量它不知道真假的填充。
// 同一段话的两种改写
原文：目前只在订单模块使用该机制，其它模块暂未接入。
改写后（失真）：该机制已在系统中广泛使用。
// 差别：范围词从"订单模块"变成"系统"，"暂未"变成"已"
3. 三类内容不该交给助手改写
| 内容 | 为什么 |
|---|---|
| 决策与取舍 | 措辞就是决策本身 |
| 数字与指标 | 补全与取整都会改事实 |
| 边界与例外 | 限定词被删就成了绝对断言 |
第一项最要紧："我们决定不做 X，因为 Y"这句话里，去掉 Y 就不是同一个决策了。助手很可能把 Y 精简掉，因为它读起来像铺垫。
可以给这类句子加一个固定句式，让限定词不容易被删：
// 三种不允许被改写的句式
"仅支持 X，不支持 Y" → 不允许合并成"支持 X/Y"
"在 A 条件下成立，否则……" → 不允许删掉后半句
"当前只用于 Z 模块" → 不允许换成"系统内"
// 复核时先搜这三类句式，比通读有效
第三项是事故来源：文档写"该接口不支持并发调用"，被改成"该接口对并发有一定要求"，下游就可能按错误理解去用。
4. 可用的分工
| 任务 | 交给助手 | 人负责 |
|---|---|---|
| 结构梳理 | 是 | 确认取舍 |
| 语言润色（不改变事实） | 是 | 复核范围词 |
| 补示例 | 视情况 | 验证示例正确 |
| 写决策与数字 | 否 | 全部 |
第二项与第四项的分工也值得说清："补示例"看起来无害，实际上示例会成为下游的参照。一个编造的示例比一段模糊的描述更危险，因为它看起来是可执行的。
第二项的关键是"不改变事实"这个限定：润色应当只动语序与措辞，不动断言强度。判断方法是改写前后对比"断言的范围与确定性有没有变"。
// 改写前后的三项核对
1. 范围词：模块/系统/全局 有没有被放大
2. 确定性：倾向/采用/必须 有没有被升级
3. 前提：因为/在…条件下 有没有被删
三项任一变化 → 不是润色，是改事实，须人工确认
失真还有一层时间维度：越旧的段落越危险。因为它经过更多次改写，累积的偏差更多，而它在文档里位置更靠前、看起来更权威。所以"老文档更可信"这个直觉在这里恰好是反的。
5. 让失真可见的三种做法
| 做法 | 效果 |
|---|---|
| 保留原文（diff 可查） | 改动可见 |
| 标注"AI 辅助"与复核人 | 责任可见 |
| 定期与代码对照 | 事实可验证 |
第二项不是形式主义："这段是助手改的、我复核过范围词" 这句话会让复核真的发生。没有它，复核往往退化成"通读一遍觉得没问题"。
// 文档头部元信息：三行，成本低
doc: order-module-design
assisted: true # 是否经 AI 改写
reviewed_by: 张三 # 复核范围词与数字的人
last_fact_check: 2026-11-10 # 最近一次与代码对照的日期
核对也可以半自动化：把文档里的接口签名、配置键、表名抽出来，与代码对一遍。这类"命名级"断言最容易失配，也最容易用脚本检查。
// 抽出文档中的配置键，与代码中的实际键对比
grep -oE '[a-z]+(\.[a-z_]+)+' docs/*.md | sort -u > doc_keys.txt
grep -rhoE '"[a-z]+(\.[a-z_]+)+"' src/ | tr -d '"' | sort -u > code_keys.txt
comm -23 doc_keys.txt code_keys.txt # 文档有、代码没有 → 失配候选
第三项是最硬的手段：每季度挑三处关键断言，去代码里核对。核不上就修文档，核得上就把日期往后推。
6. 排错：五种"文档与代码不符"
| 现象 | 成因 | 处理方向 |
|---|---|---|
| 文档说支持，代码不支持 | 范围词被放大 | 对照代码，收紧措辞 |
| 数字对不上 | 被补全或取整 | 数字必须来自可查来源 |
| 前提消失只剩结论 | 因果被简化 | 补回前提 |
| 多份文档互相矛盾 | 各自被独立润色 | 建立单一来源 |
| 新同事按文档做错 | 缺少"不适用"说明 | 补边界段落 |
第五项是最终代价：文档的读者会照它做事。所以"文档失真"不是文风问题，它是会转化成事故的输入。
7. 边界：什么情况可以放手
| 场景 | 为什么 | 做法 |
|---|---|---|
| 会议纪要（原始记录在） | 可回溯 | 放手改写 |
| 内部草稿 | 不对外 | 放手 |
| 纯操作手册（有测试验证） | 可被验证 | 放手，但保留验证 |
| 对外文档 | 责任重大 | 逐句复核 |
还有一条与协作有关的边界：不要让两个人分别润色同一份文档的两半。各自独立改写会让措辞与范围词产生分歧，而全文读起来仍然通顺——这种矛盾比明显的错误更难发现。
最后一条与版本管理有关：把文档放进仓库并保留 diff，是唯一能让失真可追溯的手段。放在共享文档里的文件，每次改写覆盖前一次，"这句话是谁改的、改之前是什么"就永远查不到了。
判断口径一句话：这段文字会不会被当成事实依据去执行。会，范围词与数字必须人工核对；不会，改写只是效率工具。
文档失真的校正成本也有一个规律：越晚发现越贵。一周内发现，只需改一句话；半年后发现，已经有人按它做过设计，改动会牵出讨论与返工。所以"定期核对"的频率应当与文档被引用的频率挂钩。
8. 自测
- 失真的四种形态中，哪一种只差两个字却扩大了责任范围？
- 为什么"读起来更顺"常常意味着前提被删掉？
- 三类不该交给助手改写的内容里，哪一类是事故的直接来源？举一个例子。
- "润色"的界限是什么？改写前后该核对哪三项？
- 为什么"标注 AI 辅助与复核人"能让复核真的发生？
- 判断"能否放手改写"的那个问题是什么？