黑箱转向（二）：生成—验证落差，真正的拐点

Lingming — Mon, 02 Mar 2026 11:38:38 -0500

一个代码代理十分钟生成五个文件，并不意味着团队获得了十分钟的交付。有人仍要确认需求没有误解、依赖没有引入风险、边界条件得到处理、测试没有只证明理想路径，上线后也不会破坏既有数据。

代码生成把“得到一个可运行候选方案”变得很便宜，却没有同比例压缩其余工作。上一篇说明，大型软件早已依靠局部理解运行。本篇要定位 AI 带来的新增压力：不是软件第一次超出个体认知，而是实现吞吐量可能开始持续超过保证吞吐量。

代码产量不是软件生产率

软件工作的产出不是代码文本，而是被用户使用、能够维护并承担后果的系统变化。新增行数甚至未必是正向指标：更短的实现可能更好，删除不必要代码也可能比增加功能更有价值。

因此，“模型每秒生成多少行”无法直接与“工程师每小时写多少行”比较。模型可以快速制造候选实现，工程师则还在完成问题建模、取舍、集成和验证。两者不是同一种计量单位。

更合适的链条是：

需求澄清 → 候选生成 → 人工审查 → 自动验证 → 系统整合 → 渐进发布 → 运行反馈

AI 主要压缩其中一部分，有时也能帮助测试和解释，但任何未被压缩的环节都可能成为新瓶颈。候选代码越便宜，团队越容易把瓶颈从“写不出来”转移到“看不完、接不上、无法放心上线”。

现有证据不支持一个整齐的全球拐点

截至 2026 年，AI 编程的使用率和效果都在快速变化，但研究结果仍取决于任务与人群。

2025 年 Stack Overflow 开发者调查显示，很多开发者已经使用 AI 工具，但 72% 的相关受访者表示 vibe coding 不是其专业工作方式；对 AI 准确性持不信任态度的人多于信任者。高责任的部署与监控任务也最少被计划交给 AI。这说明“广泛辅助”不能直接改写成“AI 已是主要代码生产者”。

METR 在 2025 年对熟悉自己大型开源仓库的资深开发者进行随机实验，观察到允许使用当时 AI 工具的任务平均耗时反而增加。2026 年的后续说明认为较新的工具可能已经带来加速，却也指出不愿在无 AI 条件下工作的参与者造成了样本选择问题，无法给出稳定总体估计。

DORA 2025 的结论更适合这组复杂证据：AI 像一个放大器。它可以提高个人效率和交付吞吐，也可能同时增加交付不稳定性；平台质量、内部开发体验、小批量变更和清晰的组织政策会显著影响结果。

所以，本系列不把 2026 年某一天宣布为统一的“生成拐点”。拐点发生在具体团队内，而且需要用实际交付数据识别。

真正的落差发生在哪里

生成—验证落差至少有四种来源。

需求落差

模型可以忠实实现一条错误或不完整的需求。代码越快出现，团队越可能把“已有实现”误当作“问题已经被定义”。需求中的权限、失败处理、兼容性和非功能约束若没有先说清，后续审查只能在成品中反向猜测。

意图落差

人手编写也可能缺少设计理由，但 AI 会让这种情况更容易规模化。一个实现可能来自几轮对话、临时上下文和模型默认选择；仓库只保存最终 diff，没有保存哪些方案被排除、哪些假设仍不确定。

审查落差

生成工具可以一次交付大批变化，而审查者的注意力仍有限。大批量 diff 会降低逐项质疑的概率，“测试是绿的”很容易成为替代性判断。此时问题不一定是代码不可读，而是组织没有为阅读支付足够时间。

整合落差

模型擅长局部任务，不代表它掌握组织特有的部署约束、历史兼容负担和隐性业务规则。一段局部合理的实现，可能扩大依赖、破坏性能预算或绕过已有治理流程。真正昂贵的工作常发生在模块边界。

怎样判断团队是否越过了自己的拐点

不要只统计生成代码占比。更有用的是同时观察流量、质量和理解。

维度	可观察指标	危险信号
变更流量	PR 大小、并行变更数、审查等待时间	生成量上升，审查队列持续增长
返工质量	首次通过率、回退率、缺陷逃逸率	合并更快，返工与事故同步增加
系统整合	构建失败、兼容问题、依赖增长	局部测试通过，集成频繁失败
团队理解	设计理由覆盖、模块接手时间、事故定位时间	只有生成者会操作，没人能解释边界
运行结果	变更失败率、恢复时间、用户影响	吞吐增加，稳定性下降

当候选实现增长快于审查与运行保证，并且返工、恢复和接手成本持续上升，团队才真正越过了自己的生成拐点。

缩小落差，而不是限制一切生成

解决办法不是给 AI 设置一个统一代码配额，而是让生成批量与保证能力匹配。

先写成功条件、禁止行为和非功能约束，再请求实现。
把任务拆成能被独立审查的小变化，限制一次跨越的模块和权限。
要求每次生成同时提供测试主张、未覆盖边界和关键设计取舍。
对高风险代码保留更强人工审查、静态分析和独立验证。
用团队交付结果评估工具，而不是只看补全接受率或生成行数。
发现审查队列和认知债上升时，优先删除、合并和澄清，而非继续堆积实现。

AI 有时也能缩小验证成本，例如生成性质测试、解释陌生模块或帮助定位依赖。但这些输出同样需要核验。工具能够参与保证流程，不等于它可以为自己的结果签发可信证明。

结语：拐点是一条反馈曲线

生成式 AI 最重要的变化，不是把源代码变成神秘物体，而是解除实现产量原有的人力摩擦。这个变化可能释放创造力，也可能让组织更快地积累未经充分验证的系统。

真正的分水岭，不在于模型一次写了多少行，而在于团队能否让问题定义、审查证据、运行反馈和责任容量跟上。生成快于验证只是风险条件；是否滑向黑箱，要看组织怎样响应这条落差。

延伸阅读与参考资料

上一篇：《黑箱转向（一）：软件工程从来不是完全的白箱》；下一篇：《黑箱转向（三）：认知债——团队知道得越来越少吗》。

开发效率 on Lingming 灵明