同一个模型，产出差一倍：编码智能体的“脚手架税”

模型一样，结果却差很多

同一个基础模型，接进不同的编码智能体框架，任务成功率、返工次数、代码可维护性可能相差明显。最近一份针对编码智能体的评测把这件事讲得更直白：真正拉开差距的往往不是模型权重，而是模型外面那层脚手架——上下文怎么拼、工具怎么给、验证怎么做、失败怎么回退。有人把这部分成本叫作“脚手架税”。

脚手架由什么构成

上下文供给。把哪些文件、哪些历史、哪些约束喂给模型，决定了它是在猜还是在读。给错的上下文，比不给更糟。

工具与权限边界。能不能跑测试、能不能改配置、能不能执行命令，以及这些动作发生在多窄的沙箱里。边界越清晰，模型越敢动手。

验证回路。有没有自动化的“做完自检”，决定产出是一次成型还是反复返工。这一步最费工程投入，也最容易被跳过。

为什么投工程比换模型更划算

换模型是一笔按调用量持续计费的开销，而且模型每半年就会被替换一轮；脚手架是一次性投入，能跨模型复用。把预算压在脚手架上的团队，模型升级时是平滑过渡；把预算压在提示词和模型选择上的团队，每次换模型都要重来一遍。更实际的一点是，脚手架里沉淀的是自己团队的工程规范与测试资产，这些不会因为供应商调价而蒸发。

落地时的三个判断

一看返工率，而不是首次生成速度；二看它敢不敢自己跑测试并读回结果；三看失败时留下的是可复现的记录，还是“我认为已经修好了”。把这三条写进验收标准，AI 编程才从演示走进生产。对产业客户而言，能不能稳定交付，比单次演示惊艳与否重要得多。