帕金森定律说工作会膨胀到填满所有可用时间。现在有了大语言模型,膨胀的边界消失了——模型能被说服生成多少内容,工作就能膨胀到多少。一位拥有二十年工程经验的作者在过去两年观察到一种系统性现象:团队用 AI 产出大量文档、代码、方案,但真正推动项目前进的有效产出反而变少了。这不是工具的问题,而是使用方式的问题。下面拆解这个现象,并给出可操作的对抗策略。
膨胀的三个典型模式
文档膨胀:写得多 ≠ 知道得多
最直观的表现是文档数量暴增。过去一周写一份设计文档的团队,现在一天能"产出"三份。但仔细看内容:重复的背景介绍、泛泛的"最佳实践"段落、对显而易见事物的冗长论证——信息密度反而下降。
核心判断标准不是字数,而是决策密度:一份文档里包含多少个需要人做判断的节点?如果 AI 填充的全是不需要判断的段落,那就是膨胀。
代码膨胀:生成多 ≠ 交付多
AI 生成代码的速度让"写了多少行"彻底失效作为度量。一个 PR 从 200 行变成 800 行,新增的 600 行可能是:过度泛化的抽象层、不需要的配置项、对未发生场景的防御性代码。Review 时间翻倍,但实际功能交付没变。
方案膨胀:选项多 ≠ 决策快
让 AI 列出五种技术方案,看起来信息更充分了。但如果五种方案里三种是明显不可行的填充项,决策反而更慢——你需要花时间排除噪音,而不是在有效选项间权衡。
信息密度审计:一个可运行的诊断脚本
对抗膨胀的第一步是量化它。下面这个 Python 脚本可以审计 Markdown 文档的信息密度,帮助识别哪些段落是低决策密度的填充内容。
"""
doc_density_audit.py — 审计 Markdown 文档的信息密度
用法:
python doc_density_audit.py your_doc.md
指标说明:
- decision_density: 包含"必须/需要/决定/选择/确认"等决策词的句子占比
- filler_ratio: 包含"众所周知/一般来说/通常/往往"等填充词的句子占比
- unique_ratio: 去重后句子数 / 总句子数, 衡量重复程度
高决策密度 + 低填充率 = 有效文档; 反之则可能是 AI 膨胀产物。
"""
import re
import sys
from collections import Counter
DECISION_WORDS = [
"必须", "需要", "决定", "选择", "确认", "关键", "约束",
"限制", "依赖", "风险", "权衡", "优先", "排除", "不可",
"禁止", "要求", "前提",
]
FILLER_WORDS = [
"众所周知", "一般来说", "通常", "往往", "显而易见",
"不言而喻", "毋庸置疑", "基本上", "简单来说", "总而言之",
"众所周知", "众所周知地",
]
def extract_sentences(text: str) -> list[str]:
"""按中英文句号、问号、换行拆分句子,过滤空句。"""
parts = re.split(r"[。?!\n]+", text)
return [s.strip() for s in parts if len(s.strip()) > 4]
def compute_density(sentences: list[str]) -> dict:
total = len(sentences)
if total == 0:
return {"decision_density": 0, "filler_ratio": 0, "unique_ratio": 0}
decision_count = 0
filler_count = 0
for s in sentences:
if any(w in s for w in DECISION_WORDS):
decision_count += 1
if any(w in s for w in FILLER_WORDS):
filler_count += 1
unique = len(set(sentences))
return {
"decision_density": round(decision_count / total, 3),
"filler_ratio": round(filler_count / total, 3),
"unique_ratio": round(unique / total, 3),
"total_sentences": total,
"decision_sentences": decision_count,
"filler_sentences": filler_count,
}
def read_markdown(path: str) -> str:
with open(path, encoding="utf-8") as f:
return f.read()
def strip_code_blocks(text: str) -> str:
"""移除代码块,只审计自然语言段落。"""
return re.sub(r"```.*?```", "", text, flags=re.DOTALL)
if __name__ == "__main__":
if len(sys.argv) < 2:
print("用法: python doc_density_audit.py <markdown文件路径>")
sys.exit(1)
raw = read_markdown(sys.argv[1])
clean = strip_code_blocks(raw)
sentences = extract_sentences(clean)
metrics = compute_density(sentences)
print(f"=== 文档密度审计: {sys.argv[1]} ===")
print(f"总句子数: {metrics['total_sentences']}")
print(f"决策句数: {metrics['decision_sentences']}")
print(f"填充句数: {metrics['filler_sentences']}")
print(f"决策密度: {metrics['decision_density']:.1%}")
print(f"填充率: {metrics['filler_ratio']:.1%}")
print(f"去重率: {metrics['unique_ratio']:.1%}")
# 简易诊断
if metrics["decision_density"] < 0.15:
print("⚠ 决策密度低于 15%, 文档可能包含大量无判断力的填充段落")
if metrics["filler_ratio"] > 0.10:
print("⚠ 填充率超过 10%, 存在明显的空话/套话段落")
if metrics["unique_ratio"] < 0.80:
print("⚠ 去重率低于 80%, 文档存在重复表述")
运行示例:
# 审计一份 AI 生成的架构文档
python doc_density_audit.py ai_arch_doc.md
# 输出可能如下:
# === 文档密度审计: ai_arch_doc.md ===
# 总句子数: 87
# 决策句数: 8
# 填充句数: 14
# 决策密度: 9.2%
# 填充率: 16.1%
# 去重率: 72%
# ⚠ 决策密度低于 15%, 文档可能包含大量无判断力的填充段落
# ⚠ 填充率超过 10%, 存在明显的空话/套话段落
# ⚠ 去重率低于 80%, 文档存在重复表述
你可以根据团队实际情况调整 DECISION_WORDS 和 FILLER_WORDS 列表。核心思路不变:用决策密度替代字数,作为文档有效性的度量。
对抗膨胀的四个操作规则
规则不是"少用 AI",而是让 AI 的输出经过人的决策过滤器。
1. 先写决策点,再让 AI 填充细节
反过来做——先让 AI 写全文,再从中挑决策点——几乎必然失败,因为你会在大量填充内容中迷失。正确顺序:
人 → 列出 3-5 个必须做判断的节点
AI → 为每个节点生成支撑数据/选项/论证
人 → 在节点上做决策,只保留决策相关的 AI 输出
2. 给 PR 设"膨胀上限"
在 CI 或 Review 规则中加入硬约束:
# .github/CODEOWNERS 或团队 Review 清单中的规则示例
pr_guidelines:
max_lines_changed: 400 # 单次 PR 改动行数上限
max_new_files: 8 # 新增文件数上限
require_decision_points: true # PR 描述必须列出至少 2 个设计决策
ai_generated_tag: "AI-GEN" # AI 生成的代码块必须标注此 tag
这不是限制产出,而是迫使每次提交聚焦在一个可审查的范围内。
3. 用"删除测试"验证文档价值
对文档的每个段落问一个问题:如果删掉这段,读者会做出不同的决策吗? 如果答案是"不会",这段就是膨胀。这个测试可以和上面的密度审计脚本配合使用——先脚本定位可疑段落,再人工做删除测试。
4. 区分"探索性输出"和"交付性输出"
AI 擅长快速生成大量选项用于探索,这本身是有价值的。问题在于把探索性输出直接当作交付物。操作上:
- 探索性输出:不进主分支,不入正式文档,不进 Review 流程
- 交付性输出:经过人筛选、修改、确认后才能进入正式渠道
在 Git 工作流中可以用分支命名约定区分:
# 探索性分支 — AI 辅助的广度探索,不进 main
git checkout -b explore/ai-auth-options
# 交付性分支 — 经人工筛选后的具体实现
git checkout -b deliver/sso-oauth2-impl
一份自查清单
每次你准备把 AI 输出当作正式交付物时,过一遍这五个问题:
| 问题 | 通过标准 |
|---|---|
| 我是否先列出了决策点再让 AI 生成? | 有明确的决策清单 |
| AI 输出中有多少段落经得起删除测试? | ≥ 60% 的段落删掉会影响决策 |
| 这份输出的决策密度是否超过 15%? | 用脚本审计或人工估算 |
| 探索性输出和交付性输出是否分开? | 不同分支/不同目录/不同标签 |
| Review 时间是否和功能交付成正比? | Review 1 小时对应可衡量的功能增量 |
如果三个以上回答为"否",你大概率已经掉进膨胀陷阱——产出很多,推进很少。
AI 是放大器。它放大的是你输入的意图质量。意图模糊,它放大模糊;意图精确,它放大精确。问题从来不在工具,而在人是否还在做判断。