Akka 用 65 个开源项目做实验：规格驱动的 AI 移植，57 个项目变快或变小

把一个跑了十年的老系统迁到新语言，最难的不是写代码，而是把“为什么这么写”讲清楚。Akka 最近做了一次规模不小的实验：让 AI 在结构化规格的约束下移植 65 个开源项目，看看“先写规格、再让模型动手”到底能不能替代人肉重写。

结果不算完美，但足够有信息量：首轮测试耗时 99.3 小时，消耗 94.1 亿个 token，65 个项目里有 57 个在代码规模或运行时性能上取得提升。

一分钟速览

• 实验覆盖 65 个开源项目，首轮耗时 99.3 小时，消耗 94.1 亿 token。
• 57 个项目在代码行数或运行时性能上实现提升。
• 流程分两阶段：先分析全部项目并实现最多 10% 功能，再挑 10 个项目完整移植。
• Sonnet 平均每项移植 61 分钟，Opus 需要 120 分钟，但 token 消耗少约 40%。
• 结构化规格能提升首次实现质量，跨组件决策上下文缺失是主要瓶颈。

实验到底怎么做的

Akka 把工作流拆成五个阶段：需求发现、规格定义、移植、基准测试和优化。需求发现阶段分析代码、模型、模式和运行时行为；随后由 Claude 配合 Akka Specify 完成实现、测试和审查；最后用统一的基准测试运行器比较测试通过率、代码规模和延迟。

第一阶段，团队对全部 65 个项目生成规格说明，并实现每个项目最多 10% 的功能，用来观察模型在真实代码库里的行为。第二阶段，他们根据系统特性和可量化结果，挑出 10 个项目做完整移植。这种设计避免了一上来就投入大量算力，也为后续对比留下了基线。

验证并不只靠模型自测。团队使用项目原有的单元测试和集成测试，同时由审核人员检查序列化、安全性、错误处理、个人身份信息、幂等性和架构边界。随着移植故障暴露新问题，Akka 又增加了防护措施，但也承认额外的退出条件会推高移植成本。

规格写得好，第一次就少返工

实验最重要的发现是：包含声明、证据和类型化行为的结构化规格，能显著改善首次实现的质量。换句话说，模型并不是“不会写”，而是经常不知道哪些约束不能碰。规格把这些约束显式写出来，模型就少了自由发挥的空间。

但规格也有边界。Akka 指出，上下文文件里缺少跨组件的决策信息，是当前最大的瓶颈。一个函数为什么这样拆分、一个接口为什么保留旧字段、某个异常为什么必须吞掉，这些决策往往散落在提交记录、工单和资深工程师的脑子里。规格能描述“是什么”，却很难自动补齐“为什么”。

这与 GitHub Spec Kit 的思路相近：把编码代理的工作流结构化成分规格、规划、任务、实现和收敛几个环节。区别在于，Akka 把规格放到了软件移植这个更苛刻的场景里，用 65 个真实项目而不是玩具仓库来检验。

大模型不一定更划算

模型选择的结果有点反直觉。Sonnet 平均每个项目移植耗时 61 分钟，Opus 需要 120 分钟；但 Opus 的 token 消耗少了大约 40%。这意味着更强的模型可能用更少的尝试次数完成任务，却要在单次推理上花更多时间。

Akka 还发现，提高工作量设置会增加消耗，却不能带来持续的效率增益。对工程团队来说，这是一个实用的提醒：把预算全押在“更聪明的模型”或“更多的推理步数”上，收益可能递减；先把规格和上下文补齐，往往更划算。

性能数据不能只看倍数

报告里最抓眼球的数字是 Dify 的性能提升 143333 倍，但 Akka 自己注明，所对比的工作负载存在差异。另一个方向的数据是 Netflix Metaflow 的运行速度慢了约 100 倍。把这两个数字放在一起，说明移植后的性能高度依赖具体场景，不能简单平均。

整体来看，应用程序、框架和库的性能普遍提升，而基础设施和工具的性能中位数反而下降。这也符合直觉：越靠近底层，隐含假设越多，规格越难写全；越靠近业务层，行为边界越清晰，AI 越容易接管。

趋势洞察：规格驱动开发正在成形

这次实验给出的最大启示，不是“AI 能替代程序员”，而是“AI 把软件工程的瓶颈往前推了”。过去，瓶颈在写代码；现在，瓶颈在把需求、约束和架构决策写成机器可执行的规格。

对正在做系统迁移、语言升级或遗留系统现代化的团队来说，这是一条可操作的路径：先建立规格库，再让模型在规格约束下生成和验证代码，最后用人审查关键边界。它不会让移植变成一键操作，但可能把“重写一遍”变成“重写一小部分，其余交给规格和测试”。

真正的分水岭在于上下文工程。谁能把散落在组织里的决策记录下来，谁就能让 AI 在复杂系统里少犯错。规格不是文档，而是 AI 时代的工程接口。