AI 写代码越快,软件交付反而越难

重建一条可验证、可回退的工程闭环 · 阅读约 10 分钟

— — —

今天，一名开发者用 AI 在半小时内生成的代码，可能比过去一天手写的还多。

但许多团队同时遇到了一个反直觉现象：代码出来得更快，需求返工、评审压力、线上风险和定位成本却没有同步下降。有时，速度甚至把一个模糊决策更快地扩散到了整个系统。

问题不在于 AI 不够聪明，而在于团队只升级了代码生成面，没有同步升级工程控制面。

当代码越来越便宜，真正昂贵的东西变成了：定义正确问题、约束变更范围、独立证明结果，以及在失败时安全恢复。

传统研发容易把“完成”理解为代码写完、测试通过、PR 合并。AI 加入后，这种定义会越来越危险。

模型能够补齐缺失细节，却不知道哪些细节不应该由它补；能够同时修改几十个文件，却不知道哪条架构边界不能碰；也能够生成一套测试，为自己刚刚写出的错误假设提供“全绿证明”。

可以用一个简单的启发式关系理解交付风险：

交付风险 ∝ 变更规模 × 不确定性
          × 影响范围 ÷ 验证强度

它不是精确公式，却给出了非常实用的行动方向：任务更小、假设更显式、权限更有限、验证更独立，风险就更容易被控制。

一套完整的 AI 工程体系，可以拆成六个连续环节：

这六层不是六套互不相干的方法。它们共同构成一条证据链，运行指标、事件和事故复盘又会反向修正下一轮目标与设计。工程能力的差距，最终体现在这条链能不能连起来。

设想产品经理只说一句：“增加多模型动态加载。”

这句话足以让 AI 开始写代码，却远远不足以让团队安全交付。它没有说明：加载期间旧请求是否继续执行、内存不足时谁决定驱逐、切换失败是否回到旧版本、并发请求看到哪个模型、业务 API 能不能变化。

如果这些问题没有提前回答，AI 就会用训练数据里的常见做法，替团队作出架构决定。

下一步，才是把任务继续下沉为设计和规格。好的设计不是一张漂亮的架构图，而是让开发、测试、AI 和运维对关键问题得到同一个答案：谁拥有状态？接口怎样超时？重复请求是否幂等？部分成功怎样补偿？版本怎样兼容？资源不足时如何背压？

AI 编码工具从补全、对话，逐渐走向仓库编辑、命令执行和长程 Agent。行动权越大，效率上限越高，风险半径也越大。

一个实用的自治风险模型是：

自治风险 ≈ 行动权限 × 运行时长
          × 环境触达 × 不可逆性
          ÷ 可观测与回滚能力

真正的工程化，不是给模型一句“请谨慎修改”，而是在模型外部建立一个Agent Harness：由确定性的系统管理上下文、状态、权限、工具、验证和恢复。

Prompt、Task、Spec 和 Evidence 也不能混在一起：Prompt 只是一次交互；Task 规定本次工作的目标、范围与验收；Spec 是跨版本存在的契约；Evidence 则记录 Diff、命令、测试、环境和残余风险。

尤其要避免生成与验证完全同源。让同一个 Agent 写代码、写测试、解释失败，再宣布自己成功，等于让运动员兼任裁判。可靠验证要组合编译和静态分析、契约与属性测试、差分和故障注入、性能与安全基线，以及人类对架构边界和残余风险的判断。

质量不是“没有发现 Bug”，而是关键风险已经获得独立、可复现、可追溯的证据，剩余风险也有人明确接受。

传统测试擅长判断确定性行为，Eval 则负责评价可能存在多个合理答案的概率性输出。两者不能互相替代。

可信的 Eval 应从“这个结果要支持什么发布决策”开始，再定义能力与风险场景、样本切片、评分方法，最后设置 Release、Block 或 Canary 阈值。只报一个总体平均分，会把长尾、安全和关键用户群的问题藏起来。

调试也不是不断尝试参数，而是一连串可证伪实验：冻结环境、提出带预测的假设、一次只改变一个变量，然后观察结果是否能区分不同根因。

性能优化首先是一门实验科学。如果工作负载、硬件、软件、模型版本、输入输出长度、Batch、并发、预热和统计方法没有冻结，两次性能数字就没有可比性。

AI 推理尤其容易被一个数字误导：Tokens/s。更值得关注的是Goodput——同时满足质量、延迟和错误率约束的有效吞吐。峰值吞吐很高，但 P99 超标、答案质量下降或请求大量失败，并不代表系统拥有更高的可用能力。

Batch 是典型例子。增大 Batch 可能提高设备利用率和峰值吞吐，也可能增加凑批等待、KV 占用和长短请求干扰。真正的最优点不是图表里的最高柱，而是在真实请求分布下仍满足质量、P99、公平性和容量余量的安全工作区间。

当问题继续下沉到推理系统，工程链会更长：模型结构决定计算和状态，量化改变数值与布局，Compiler 规划全局数据流，Kernel 实现局部执行，Runtime 管理动态请求，硬件提供容量和性能上界。

一个 Token 从请求进入到返回，要经历路由和资源预留、Prefill、循环 Decode、Sampling、Streaming 和资源释放。TTFT、TPOT、P99 与 Goodput，分别暴露这条流水线的不同问题。

容量计算也远不止“参数量乘以位宽”：

权重容量 ≈ 参数量 × 位宽 / 8
          + 量化元数据 + 对齐

总内存 = 权重 + KV Cache + Workspace
       + 通信 Buffer + Runtime/Driver
       + 碎片 + 故障恢复余量

这就是为什么大模型推理必须做全栈联合设计。模型、Compiler、Kernel、Runtime 和 NPU 中任何一层的局部最优，都可能成为端到端系统的全局次优。

不需要一次引入几十套制度。选一个真实、常规风险的功能，先要求四个制品：

跑完一轮后，再看交付周期、评审等待、首次验收通过率、缺陷逃逸、P99、Goodput 和恢复时间。一次只改一个流程变量，然后复测。

真正有价值的工程改进，不是文档数量增加了，而是团队开始能够回答：为什么做、谁决定、改了什么、怎样证明、在哪运行、失败后怎么回来。

— — —

AI 不会让软件工程消失。恰恰相反，它会把软件工程从“如何生产代码”，推向“如何控制一个能高速生产代码的系统”。

未来更稀缺的工程师，不只是会写 Prompt、调 Kernel 或调用模型的人，而是能够从业务意图出发，在规格、代码、模型、编译、运行时和硬件之间追踪同一个决策的人。

他们知道什么时候可以自动化，什么时候必须停；知道什么数字可以相信，什么证据还不够；也知道系统出错时，怎样解释、止损和恢复。

代码可以由 AI 快速生成，但可信交付仍然是一门人的工程。

如果你的团队正在把 AI 引入研发流程，不妨先问一个问题：我们升级的只是生成速度，还是整条工程闭环？欢迎留言说说你们目前最难补上的一环。