拒绝 AI 盲目生成：一套四阶段工程实践¶
当团队引进 AI 编码助手后，代码产出量激增、PR 佇列变长、测试绿灯，但维护性急剧下降。这不是 Token 不够或 Prompt 不好——而是一个系统性误区：把"AI 写得更快"误判成"AI 生成的变更更容易被组织吸收"。
目录¶
现状与盲点：高吞吐量带来的"工程反噬"¶
生产力假象与维护危机¶
团队引进 AI 编程助手后的典型现象： - 程式码产出量激增 - PR 佇列变长 - 测试全为绿灯 - 但原本一處即可修復的功能散落多處，维护性急剧下降
核心矛盾：吞吐量（Throughput）上升的同时，缺陷率（Defect Rate）、事故率（Incident Rate）、审查积压也在加速恶化。
Faros AI 2026 产业报告核心数据¶
Faros AI 观测约 22,000 名开发者、4,000 个团队、两年遥测数据，追踪同一组织从最低到最高 AI 采用率期间的指标变化 [00:48]。
报告命名为「加速鞭挞」（Acceleration Whiplash）：AI 以远超人类步调的产出灌入一个为人类节奏和人类品质而建的交付系统，该系统从未被设计来吸收这些产出。
| 指标 | 变化幅度 | 说明 |
|---|---|---|
| 每开发者完成的 Epics | +66% | 业务交付确实加速 |
| 每开发者任务吞吐量 | +33.7% | 更多功能被产出 |
| PR 体积（Size） | +51.3% | 每个 PR 更大 |
| 代码流失率（Code Churn） | +861% | 删除/新增行比近 10 倍 |
| 每开发者 Bug 数 | +54%（2025 年仅 +9%） | 缺陷率加速而非趋稳 |
| 生产事故/PR 比 | +242.7% | 事故率超 3 倍 |
| 首次 PR 审查中位时间 | +156.6% | 审查积压 |
| 平均审查耗时 | +199.6% | |
| 审查中位总时间 | +441.5% | 资深工程师被"活埋" |
| 无审查直接合并的 PR | +31.3% | 审查产能跟不上产出 |
[!warning] AI 放大了既有交付系统的优点和缺陷 高 AI 采用率与更大 PR、更长审查时间、更多 Bug 及生产事故呈正相关。AI 不是一个中性的加速器，而是一个放大器——它会让好的工程实践更快产出价值，也会让脆弱的交付管道更快崩溃。
评测盲区：Benchmark 测不出可维护性¶
SWE-bench 等评测主要检查功能正确性（Pass-to-pass / Fail-to-pass），能自动化验证结果，但完全无法测量：
- 程式码是否容易维护
- 抽象是否合理
- 维护者是否愿意合并
METR（Model Evaluation & Threat Research）的研究指出：自动化测试通过率平均比维护者实际愿意合并的比例高出 24.2 个百分点。约半数通过 SWE-bench 自动评分的 AI PR，真实维护者不会合并 [02:30]。
┌─────────────────────────────────────────────────────┐
│ Benchmark vs. 现实鸿沟 │
│ │
│ SWE-bench 自动评分通过率 │
│ ████████████████████████████████████ ~75% │
│ │
│ 维护者实际愿意合并率 │
│ ██████████████████████ ~51% │
│ │
│ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ← 24.2% 的"虚假信心"地带 │
│ │
│ 绿灯 ≠ 可维护 │
│ 绿灯 ≠ 架构合理 │
│ 绿灯 ≠ 团队愿意合并 │
└─────────────────────────────────────────────────────┘
核心工程痛点拆解¶
绿地（Greenfield）与棕地（Brownfield）的现实鸿沟¶
| 维度 | 绿地专案（Greenfield） | 棕地专案（Brownfield） |
|---|---|---|
| 代码库状态 | 空无一物 | 累积多年历史 |
| 隐式约束 | 几乎没有 | 充满业务逻辑、架构约定 |
| AI 表现 | 可快速生成完整应用 | 现有证据不足以证明人工审查能长期维持复杂系统 |
| 典型场景 | 新项目原型、Hackathon | 生产环境迭代、遗留系统改造 |
| 风险等级 | 低（大不了重写） | 高（改错一处影响全局） |
Stanford 研究（100k 开发者提交分析）证实：AI 工具在绿地项目中表现优异，但在大型既有代码库中往往使开发者更不高效 [03:03]。
工具链无法替代"人"的判断¶
新增 Linter 或结构化测试能检查既有明确规则，但无法发现深植于资深工程师脑中的隐式意图（Implicit Intent）：
┌───────────────────────────────────────────────────┐
│ 能被工具自动化的 vs. 需要人类判断的 │
├───────────────────────────────────────────────────┤
│ │
│ ✅ 工具可检测： │
│ · 代码风格违反 Linter 规则 │
│ · 测试覆盖率不足 │
│ · 类型错误 / 编译错误 │
│ · 已知安全漏洞模式 │
│ │
│ ❌ 工具测不出（需要人类）： │
│ · 这个抽象层次是否合理？ │
│ · 改动是否符合业务意图？ │
│ · 架构边界划在哪里最优？ │
│ · 这段代码 6 个月后还有人看得懂吗？ │
│ · 这是在解决真问题还是在制造复杂度？ │
│ │
└───────────────────────────────────────────────────┘
审查成本与 PR 佇列堆积¶
HumanLayer 创始人 Dex Horthy 的亲身经历：团队成员每几天产出 2,000 行复杂 Go 代码 PR（JSON RPC over Unix sockets + 流式 stdio 管理 fork 进程）。仔细审查 2,000 行复杂系统代码每几天来一轮，完全不可持续。
"我刚开始感觉像 Mitchell Hashimoto 在 Ghostty 项目中要求'AI 贡献必须披露'时的那种不安。" —— Dex Horthy
审查积压的恶性循环：
AI 产出激增
│
▼
PR 佇列堆积 ──────▶ 审查者疲劳
│ │
▼ ▼
审查时间拉长 ◀── 无审查直接合并比例上升
│ │
▼ ▼
资深工程师被"活埋" ──▶ 生产事故激增
│ │
▼ ▼
技术债累积 ◀───── 代码品质持续下降
解决方案：HumanLayer 四阶段工程实践¶
Dex Horthy 在 HumanLayer 团队归纳出一套防範 AI 盲目生成的高杠杆流程 [04:32]。
核心理念：把审查成本前移到程式码尚未生成之前，先把坏 PR 的机率降低，再去追求生成速度。
┌─────────────────────────────────────────────────────────┐
│ 四阶段工程实践流程 │
│ │
│ ┌──────────────┐ │
│ │ 阶段一 │ 产品需求与设计 │
│ │ Product │ 用简单文档/HTML 草图对齐痛点 │
│ │ Requirements │ → 把需求搞清楚 │
│ └──────┬───────┘ │
│ ▼ │
│ ┌──────────────┐ │
│ │ 阶段二 │ 系统架构 │
│ │ System │ 画序列图，定义 API 介面与数据模型 │
│ │ Architecture │ → 提前杜绝架构错误 │
│ └──────┬───────┘ │
│ ▼ │
│ ┌──────────────┐ │
│ │ 阶段三 ★ │ 程序设计（最易被忽略、最关键） │
│ │ Program │ 定义类别、方法签名、调用栈 │
│ │ Design │ 用伪代码/文件树差异与 AI 对齐 │
│ └──────┬───────┘ → 在 AI 写码前规定好"程式形状" │
│ ▼ │
│ ┌──────────────┐ │
│ │ 阶段四 │ 垂直切片叠代 │
│ │ Vertical │ 切出最小可运行完整功能切片 │
│ │ Slice │ 跑通→测试→审查→再叠代 │
│ └──────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘
阶段一：产品需求与设计（Product Requirements & Design）¶
做法：先不写程式码。使用简单文档或 HTML 草图对齐要解决的痛点 [04:39]。
目的：把需求搞清楚，效益远高于盲目生成上万行无用程式码。
实践要点： - 用最简方式（文档、草图、wireframe）描述要解决的用户痛点 - 确保所有利益相关者对"要解决什么问题"达成一致 - 这一步的 ROI 远高于后面生成上万行无用代码再删除的成本
"一堆无用的代码行数是最昂贵的浪费——不是因为 token 成本，而是因为审查者要花大量认知资源去理解、评估、最终拒绝它们。" —— 核心理念
阶段二：系统架构（System Architecture）¶
做法：画出序列图（Sequence Diagram），定义 API 介面与数据模型 [04:53]。
目的：提前杜绝 AI 可能犯下的架构错误，明确服务边界与数据流向。
实践要点： - 定义清晰的 API 接口契约 - 确定数据模型与数据流向 - 划分服务边界（哪些逻辑在哪一层） - 这一步决定了 AI 生成代码时的"护栏"边界
阶段三：程序设计（Program Design）★最关键¶
做法：向下深入一层，定义类别、方法签名、调用栈（Call Stack），并用伪代码或文件树差异与 AI 对齐 [05:05]。
目的：展现工程师的核心价值——在 AI 写码前规定好"程式形状"。
这是四个阶段中最容易被跳过、但杠杆最高的一步。原因：
| 不做程序设计的后果 | 做程序设计的收益 |
|---|---|
| AI 自行决定抽象层次，经常不合理 | 工程师掌控代码结构 |
| 方法签名混乱，后期返工成本高 | AI 只需"填肉"，错误范围可控 |
| 调用关系不清晰，审查者难以理解 | 审查者可直接审查设计而非逐行读码 |
| 一处错误扩散到数百行代码 | 设计层面的错误在代码生成前就被拦截 |
Dex Horthy 的杠杆公式：
错误的层级 影响范围
─────────────────────────────────
一行坏代码 → 一行坏代码
一行坏计划 → 数百行坏代码
一行坏研究 → 数千行坏代码
─────────────────────────────────
→ 人类精力应集中在流程最高杠杆的环节：
Research > Plan > Code (审查)
实际对齐方式示例（伪代码 + 文件树）：
# 文件树差异
src/
├── payment/
│ ├── processor.py # 新增 PaymentProcessor 类
│ │ ├── process() # 主入口，签名: (order: Order) -> Result
│ │ └── refund() # 签名: (txn_id: str, amount: Decimal) -> Result
│ ├── gateway/
│ │ ├── stripe.py # StripeGateway 实现 Gateway 接口
│ │ └── paypal.py # PayPalGateway 实现 Gateway 接口
│ └── models.py # 新增 TransactionRecord 数据模型
# 调用栈
OrderController.create()
→ PaymentProcessor.process(order)
→ Gateway.charge(card_token, amount)
→ TransactionRecord.save()
→ OrderConfirmation.send()
阶段四：垂直切片叠代（Vertical Slice Iteration）¶
做法：避免让 AI 横向切分，而是切出最小可运行的完整功能切片，跑通、测试、审查后再叠代 [05:23]。
❌ 横向切分（Horizontal）—— AI 的默认倾向
┌──────────────────────────────────────────┐
│ DB 迁移层 │ API 层 │ 前端层 │ 测试层 │
│ (全部写完) │(全部写完)│(全部写完)│(全部写完) │
└──────────────────────────────────────────┘
问题：无法跑通、无法验证、审查者面对巨大 PR
✅ 垂直切片（Vertical）—— 正确做法
┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐
│切片1│→ │切片2│→ │切片3│→ │切片4│
│DB+API│ │DB+API│ │DB+API│ │DB+API│
│+前端 │ │+前端 │ │+前端 │ │+前端 │
│+测试 │ │+测试 │ │+测试 │ │+测试 │
└─────┘ └─────┘ └─────┘ └─────┘
每个切片：可运行 → 测试通过 → 审查 → 合并 → 下一个
每个垂直切片应满足： - 端到端可运行（从 DB 到 UI） - 有测试覆盖 - 可独立审查（审查者能在合理时间内完成） - 可独立部署/合并
人机协同的新范式与工作流分配¶
任务分级机制¶
并非所有任务都需要走完整四阶段流程 [05:37]：
┌─────────────────────────────────────────────────────┐
│ 任务分级决策树 │
│ │
│ 任务复杂度？ │
│ ├── 轻量（~40%） │
│ │ ├── 改 typo / 小 bugfix │
│ │ ├── 添加简单配置 │
│ │ └── 样式微调 │
│ │ → Zero-shot 生成或 1-2 轮轻量反馈即可 │
│ │ │
│ └── 重型改动 │
│ ├── 意图误解代价高？ │
│ │ ├── 是 → 必须走完四阶段 │
│ │ │ 产品需求 → 架构 → 程序设计 → 垂直切片 │
│ │ │ │
│ │ └── 否 → 可适当简化，但至少做程序设计 │
│ │ │
│ ├── 架构边界涉及？ │
│ │ └── 是 → 阶段二（架构）不可跳过 │
│ │ │
│ └── 多服务/多层改动？ │
│ └── 是 → 阶段四（垂直切片）必须严格执行 │
│ │
└─────────────────────────────────────────────────────┘
"审查前移"的核心哲学¶
AI 的发展方向不是淘汰工程师，而是重新分工 [05:48]：
| AI 负责 | 人类工程师负责 |
|---|---|
| 高吞吐量的实现（Implementation） | 高层对齐（Alignment） |
| 代码生成（Code Generation） | 架构边界定义 |
| 测试编写（Test Writing） | 设计规范对齐 |
| 文档草稿（Documentation Draft） | 高层审美判断（Aesthetic Judgment） |
| 重构执行（Refactoring Execution） | 隐式意图传达 |
"把审查成本前移至程式码尚未生成之前，先把坏 PR 的机率降低，再去追求生成速度。" [05:59]
核心价值总结¶
"别把 AI 写得更快，误判成 AI 生成的变更更容易被组织吸收。" [06:13]
AI 时代下工程师的核心价值，已从单纯编写语法转变为： 1. 架构边界定义 2. 设计规范对齐 3. 高层审美判断
关键数据来源交叉验证¶
Faros AI 2026 报告¶
- 来源：22,000 名开发者、4,000 个团队、两年遥测数据
- 追踪方式：同一组织从最低到最高 AI 采用率期间的指标变化（非问卷调查，而是实际系统遥测）
- 关键发现：DORA 2025 报告认为"强工程基础能保护团队免受 AI 副作用"，但 Faros 遥测数据显示高绩效工程组织同样经历下游品质恶化
- 代码流失率 861% 的三种可能解释：(1) 开发者快速接受 AI 代码后又返工替换；(2) AI 终于让团队有余力做大规模重构；(3) 工程师快速交付不满意的代码后持续改进
METR SWE-bench 研究¶
- 审查了 296 个 AI 生成的 PR，与真实维护者核对
- 维护者合并率平均比 SWE-bench 自动评分低 24 个百分点
- 统计显著性确认：测试通过 ≠ 可维护 ≠ 团队愿意合并
HumanLayer 实践验证¶
- Dex Horthy 团队在 300k LOC Rust 代码库（BAML）验证
- 业余 Rust 开发者 + AI = 一小时内修好 bug，次日维护者批准合并
- 7 小时内产出 35k LOC（取消支持 + WASM 编译），维护者估计每项需资深工程师 3-5 天
- 方法论核心：Frequent Intentional Compaction（频繁刻意压缩），通过 Research → Plan → Implement 工作流管理 context window
行动建议¶
✅ 实施审查前移 在交付 AI 撰写代码前，先落实需求草图与程序设计（方法签名 + 调用栈）的对齐
✅ 采取垂直切片交付 要求 AI 每次仅实现并跑通最小可用的完整垂直切片，防止一次送出庞大的横向 PR
✅ 建立任务分级审查 区分低风险单次任务与高风险架构变更，高风险任务必须严格走完四阶段设计流程
✅ 监控代码流失率 如果 Code Churn 异常升高，调查是 AI 代码返工还是真重构
❌ 不要仅以测试绿灯作为合并标准 测试通过率比维护者意愿平均高 24.2%
❌ 不要以减少工程师编制来对冲 AI 产出增长 维护 AI 输出安全、正确、可维护的工作量并未减少，反而增加了
参考资料¶
- 拒绝 AI 盲目生成：一套四阶段工程实践（YouTube） — Why QQ 频道
- Ten takeaways from the AI Engineering Report 2026: The Acceleration Whiplash — Faros AI
- Getting AI to Work in Complex Codebases — Dex Horthy / HumanLayer
- Many SWE-bench-Passing PRs Would Not Be Merged into Main — METR
- AI Code Quality: The Hidden Cost Senior Engineers Pay — Faros AI
相关笔记¶
- [[AI 编码代理]]
- [[代码审查最佳实践]]
- [[Context Engineering]]