一句话结论
Akka 团队通过基于规格说明的 AI 工作流完成 65 个开源项目移植测试，57 个在代码行数或性能上实现提升，但性能收益与项目类型强相关，结论不可泛化到所有场景。
关键要点
- 首轮测试耗时 99.3 小时，累计消耗 94.1 亿个令牌（token）。
- 65 个移植项目中 57 个在代码行数或性能方面实现提升。
- 小工作量的 Sonnet 平均每个移植耗时 61 分钟，Opus 为 120 分钟，但 Opus 的 token 消耗量比 Sonnet 少约 40%。
- 提高工作量设置会增加消耗，但并不能带来持续的效率提升。
- 性能收益呈分化：应用、框架和库普遍提升，基础设施与工具类性能中位数下降。
背景与事实
Akka 利用 65 个开源项目，对一种基于规格说明（specification-driven）的 AI 辅助软件移植工作流进行了系统性测试，评估维度涵盖规格说明的结构设计、上下文组织、模型与工作量档位选择、自动化验证机制、token 消耗量以及移植后的运行时性能。首轮测试整体耗时 99.3 小时，期间累计消耗 94.1 亿个令牌。根据 Akka 报告，在 65 个移植项目中，有 57 个在代码行数或性能指标上取得了正向提升。
实验分为两个阶段。第一阶段，Akka 对全部 65 个项目进行分析，生成规格说明，并为每个项目实现最多 10% 的功能；第二阶段，团队依据系统特性和可量化结果，从中筛选出 10 个项目进行完整实现。交付管控工作流循环经历需求发现、规格定义、移植、基准测试和优化等阶段。需求发现阶段对代码、模型、模式和运行时行为进行了分析；实现、测试和审查工作由 Claude 配合 Akka Specify 完成；最后通过一个通用的基准测试运行器，对测试通过率、代码规模和延迟进行横向比较。
Akka 发现，包含声明（declarations）、证据（evidence）和类型化行为（typed behavior）的结构化规格说明能够显著改善首次实现的效果；而上下文文件中则存在跨组件决策内容缺失的问题。验证环节同时使用了原始单元测试和集成测试，并由审核人员对序列化、安全性、错误处理、个人身份信息（PII）、幂等性以及架构边界进行了人工检查。随着移植过程中暴露出的新问题，Akka 增加了防护措施，但也指出额外的退出条件（exit criteria）拉高了移植成本。后续研究方向包括接口枚举、测试数据导入、溯源追踪、差异测试（differential testing）和对抗性测试（adversarial testing）。GitHub Spec Kit 同样围绕规格说明、规划、任务、实现和收敛等环节，对编码代理（coding agent）的工作流进行了结构化设计，与本实验思路相近。
在性能结果方面，表现因项目类型而异：应用程序、框架和库的性能普遍提升，而基础设施和工具类性能的中位数有所下降。报告给出的两个极端案例分别是：Dify 的性能提升了 143333 倍，但所对比的工作负载存在差异；Netflix Metaflow 的运行速度则慢了约 100 倍。
影响分析
对中文开发者与从业者而言，这份测试提供了几点可操作的判断。其一，基于规格说明的 AI 移植并非“一次调用出结果”，而是一个需要迭代验证、人工审核和多次优化环节的工作流，团队在引入此类工具前应预留额外的退出条件与回滚机制，避免盲目追求 100% 自动化。其二，模型档位与成本之间存在非线性关系：Opus 在耗时上更长（120 分钟对 61 分钟），但 token 消耗反而比 Sonnet 少约 40%，说明“更贵的模型不一定更省钱”，选型需要结合团队对上下文管理、规格结构化程度以及验证自动化水平的综合评估。其三，性能收益高度依赖项目类型，应用、框架和库类项目容易获得正向收益，而基础设施与工具类项目的中位数性能反而下降，团队在决定是否为某类项目启动 AI 移植时，应把“项目类别”作为前置过滤条件，而非把所有移植任务视为同质化工作。其四，结构化规格说明（声明、证据、类型化行为）对首次实现质量的提升已被验证，中文团队若希望复用此类方法，应优先投资在规格模板与上下文文件的标准化建设上，而不是单纯更换更强的模型。以上判断属于基于公开事实的分析推演，实际落地效果仍取决于团队工程成熟度、验证基础设施和项目复杂度。
适用边界
该结论仅适用于已具备完整单元测试和集成测试基础设施、可执行基准测试、且愿意引入人工审核与额外退出条件的软件移植场景；对于缺乏测试覆盖、无法进行横向性能对比、或业务对安全合规（如 PII 处理、幂等性、架构边界）没有明确验收标准的项目，该结论不直接成立。此外，测试中性能提升案例（如 Dify 提升 143333 倍）伴随工作负载差异这一前提，意味着不能将倍率数据直接外推到其他项目；基础设施与工具类项目中位数性能下降的事实也表明，该结论在低层系统移植场景中可能反向成立。
孤本观察
编辑判断：本次测试的价值更多在于暴露了“基于规格说明的 AI 移植”在验证成本与性能分化上的隐性代价，而非证明 AI 能在所有场景下稳定优于人工移植；对中文团队而言，可复用的资产是规格结构化方法与验证流程设计，而非单一模型或工作流的直接搬运。
常见问题
Akka 测试中 Opus 和 Sonnet 在移植耗时与 token 消耗上有何具体差异？
Sonnet 平均每个移植耗时 61 分钟，Opus 耗时 120 分钟；但 Opus 的 token 消耗量比 Sonnet 少约 40%。
在测试的 65 个项目中，哪些类型的项目性能普遍提升，哪些类型性能中位数下降？
应用程序、框架和库的性能普遍提升；基础设施和工具类项目的性能中位数有所下降。
Akka 测试中提到的两个极端性能案例分别是什么，具体数据如何？
Dify 性能提升了 143333 倍（但工作负载存在差异），Netflix Metaflow 运行速度则慢了约 100 倍。
Akka 测试的第一阶段对 65 个项目实现了多少比例的功能？
第一阶段为每个项目实现了最多 10% 的功能。
结构化规格说明中包含哪些关键元素，它们对首次实现有什么作用？
包含声明、证据和类型化行为，这些元素能显著改善首次实现的效果。
来源：InfoQ 中文 AI