写文档的人知道没人看，看文档的人知道写的也未必准，于是文档逐渐腐烂，变成一种"合规性存在"——写了，但没人信。

1. 成本结构彻底反转（最核心原因）

大模型出现前：写文档成本很高。
需要梳理逻辑、整理案例、逐字推敲，没人会耗费精力去写一份毫无价值的空话文档。能动笔写的，大多是确实有信息要沉淀。

大模型时代：生成文档边际成本趋近于0，核验、持续维护成本依旧很高。
团队任务来了：需要交付一份设计文档、接口说明、方案文档用于评审/审计。
利用大模型几十分钟产出完整篇幅，轻松完成指标；
但要持续跟进版本迭代、验证每一段描述、持续修正偏差，依然需要大量人力。

人天然选择低成本方案：完成“有文档”这个结果，而不是完成“文档可信”这个目标。

2. 责任机制天然缺位

文档的错误几乎没有惩罚：

• 文档写错、信息滞后，很难追溯是谁没有更新；
• 很少有团队规则要求：代码变更必须同步更新文档；
• 没人会因为“文档和代码不一致”承担故障、线上问题责任。

反过来，没有文档会被流程卡点、合规检查打回。
于是最优生存策略：先把文档造出来应付检查。至于准不准确，属于次要目标。

3. 供需两端双向预期崩塌，形成自我强化闭环

• 写作者视角：业务迭代太快，今天写对，下周功能就改了，反正迟早过时，认真仔细是无用功；读者最后还是要去读代码、找人问。
• 阅读者视角：吃过无数次文档和实现对不上的亏，预先默认文档存疑，不会完全信任文档做开发。

两边达成隐性共识：文档不必保真，只要存在即可。
信任一旦消失，文档就失去知识载体的本质功能。

4. 大模型会放大“模糊、未经实证的文本”

大模型擅长拼凑通顺文本，但不擅长区分信息真假、版本新旧。
很多文档直接基于旧版本代码、过时需求生成，模型还能把矛盾的内容平滑缝合。
大量“看似通顺实则错误”的内容涌入知识库。
错误信息不断堆积，进一步降低所有人对文档的信任度，加速腐烂。

5. 组织目标错配：流程目标 > 工程目标

很多团队引入文档的初衷：沉淀知识、降低协作沟通成本（工程目标）。
但落地之后慢慢异化：
文档首要作用变成流程凭证、审计材料、交付物清单上的一项勾选框（流程目标）。

当一件事物的首要价值变成“证明自己存在”，而非“提供有效信息”，腐烂就是必然结局。

一句话总结根本原因
维持文档准确的成本 > 不准确带来的损失；拥有文档带来的流程收益 > 文档真实有用带来的工程收益，叠加大模型降低“应付式文档”的生产门槛，最终文档沦为合规摆设。