AI 正在把人变成输出管道——如何识别和对抗"虚假生产力"

2026-05-19 15 预计阅读时间:1 分钟
来源:oschina.net AI 摘要 原文链接

免责声明:本文为 AI 摘要整理,建议结合原文阅读。摘要可能省略上下文、版本差异或边界条件,不作为官方说明。

预计阅读时间:11 分钟

帕金森定律说工作会膨胀到填满所有可用时间。现在有了大语言模型,膨胀的边界消失了——模型能被说服生成多少内容,工作就能膨胀到多少。一位拥有二十年工程经验的作者在过去两年观察到一种系统性现象:团队用 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_WORDSFILLER_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 是放大器。它放大的是你输入的意图质量。意图模糊,它放大模糊;意图精确,它放大精确。问题从来不在工具,而在人是否还在做判断。


相关推荐