devgo.cn如果你让 AI 帮你把代码从一个语言搬到另一个语言，你会选最强的模型、开最高的推理预算，对吧？Akka 用 65 个开源项目做了一次大规模实验，结论却反直觉：在“规格驱动”的工作流下，更小、更便宜的模型（Sonnet）平均每个移植任务耗时 61 分钟，而更大的 Opus 要 120 分钟，虽然 Opus 省了约 40% 的 token，但小模型产出的代码在通过率和性能上反而更稳定。这背后不是模型能力问题，而是“约束”问题——当任务被拆成清晰的规格说明时，小模型更愿意老老实实照着做，大模型反而容易“自由发挥”。
实验分两批进行。第一批覆盖全部 65 个项目，Akka 为每个项目生成规格说明，并实现每个项目约 10% 的代码面，然后根据系统特征和可量化结果挑出 10 个做完整移植。整个流程由一个“交付流水线”驱动，循环跑四个阶段：发现（分析代码、模型、schema 和运行时行为）、规格化（用 Claude + Akka Specify 生成结构化规格）、移植（实现、测试、评审）、基准对比（用统一的 runner 比较测试、代码量和延迟）。
这个流水线的核心假设是：如果规格写得足够好，模型就能像照着图纸施工一样干活，而不是靠猜。
Akka 发现，包含“断言（claims）、证据（evidence）、类型化行为（typed behavior）”的结构化规格能显著提高首轮实现的质量，但跨组件的决策仍然容易漏进上下文文件的缝隙里。后续要补的方向包括接口枚举、测试注入、来源追踪、差分测试和对抗性测试。GitHub 的 Spec Kit 也在做类似的事，把 coding agent 的工作流组织成规格、规划、任务、实现、收敛五个阶段。
真正值得琢磨的是模型和“努力程度（effort）”的搭配。实验里，Sonnet 平均每个移植 61 分钟，Opus 要 120 分钟；Opus 省 token，但更高的 effort 设置只是增加消耗，并没有稳定提升效率。换句话说，你给大模型更多“思考时间”，它不一定干得更好，反而可能想太多。
这个结果在工程师圈子里引发了讨论。一位叫 Aaditya 的工程师在 Akka CEO Tyler Jewell 的 LinkedIn 帖子下留言，说小模型的行为和他观察到的现代化改造项目一致：小模型会严格跟随规格，大模型反而可能即兴发挥。
他还追问了一个关键问题：代码行数减少到底是因为删掉了死代码，还是因为目标语言本身的差异？
Avahi 的市场负责人 Rick Bryce 也提到，约束条件本身可能就在影响结果。这些讨论指向同一个核心疑问：移植效率的差异，到底是模型能力决定的，还是规格约束决定的，还是两者共同作用？
验证环节用的是项目原有的单元测试和集成测试，外加审计员检查序列化、安全、错误处理、PII（个人身份信息，比如邮箱、手机号）、幂等性和架构边界。Akka 在失败暴露新问题时不断加护栏，但也承认额外的退出条件会推高移植成本。性能结果因项目类型而异：应用、框架和库普遍变好，基础设施和工具类项目的中位数反而变差了。最夸张的是 Dify，快了 143,333 倍，但 Akka 自己都注明对比的工作负载不一样；Netflix 的 Metaflow 则慢了约 100 倍。
这件事对你有什么用？如果你在做代码迁移、跨语言重写或者遗留系统现代化，别默认“模型越大越好、预算越高越好”。先把任务拆成可验证的规格——明确输入输出、边界条件、性能目标——然后在小模型上试，把省下来的预算花在更细的规格打磨和更严的验证上。坑在于：规格的完整性直接决定小模型的上限，跨组件的隐式依赖很容易漏；另外，性能对比一定要用相同的工作负载，否则像 Dify 那种夸张数字只会误导你。
内容与图片版权归原作者所有 · 原文: https://www.infoq.com/news/2026/10/ai-spec-driven-delivery/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global