北京
作者 ｜ Leela Kumili
译者 ｜ 平川
Akka 利用 65 个开源项目，对一种基于规格说明的 AI 辅助软件移植工作流进行了 测试，评估内容包括：规格说明的结构、上下文、模型和工作量选择、自动化验证、token 消耗以及运行时性能。首轮测试耗时 99.3 小时，消耗了 94.1 亿个令牌。根据 Akka 的报告，在 65 个移植项目中，有 57 个在代码行数或性能方面实现了提升。
该实验分成了两个阶段。Akka 对全部 65 个项目进行了分析，生成规格说明并实现了每个项目最多 10% 的功能。随后，他们根据系统特性和可量化的结果，从中选出 10 个项目进行了完整实现。交付管控工作流循环经历了需求发现、规格定义、移植、基准测试和优化等阶段。需求发现阶段对代码、模型、模式和运行时行为进行了分析，而 Claude 配合 Akka Specify 则负责实现、测试和审查工作，然后通过一个通用的基准测试运行器，对测试、代码规模和延迟进行了比较。
Akka 的交付管控工作流（图片来源：Akka 博客）
Akka 发现，包含声明、证据和类型化行为的结构化规格说明能够改善首次实现的效果，而上下文文件中缺少了跨组件决策的内容。后续研究领域包括接口枚举、测试数据导入、溯源追踪、差异测试和对抗性测试。GitHub Spec Kit 同样围绕规格说明、规划、任务、实现和收敛这几个环节，对编码代理的工作流进行了结构化设计。在 Akka 的实验中，Sonnet 平均每项移植耗时 61 分钟，而 Opus 则为 120 分钟；但 Opus 的 token 消耗量少了大约 40%。虽然提高工作量设置会增加消耗，却并不能获得持续的效率提升。
研究结果的发布引发了工程师们的一番讨论。在 LinkedIn 上，Aaditya 在 Akka 首席执行官 Tyler Jewell 的一篇博文下 评论 道：
规模较小的模型其行为与他观察到的现代化改造工作相符，即较小的模型会严格遵循规范，而较大的模型则可能会进行即兴调整。
Aaditya 还提出了一个 问题：
代码行数的减少主要是源于死代码的移除，还是源于目标语言的差异？
在同一场讨论中，Avahi 市场部负责人 Rick Bryce提到 了一个相关的点，并指出限制条件可能会影响结果。这些评论引发了新的疑问：移植效率的差异究竟是源于模型能力、规格限制，还是两者兼而有之。
成本更低的模型能实现更精确的移植，这一发现值得深入探究。
Akka 模型与工作量效率图（图片来源： Akka 博客）
验证工作采用了原始的单元测试和集成测试，并且同时由审核人员对序列化、安全性、错误处理、个人身份信息（PII）、幂等性以及架构边界进行了检查。随着移植故障暴露出的新问题，Akka 增加了防护措施，但同时也指出，额外的退出条件增加了移植成本。性能表现因项目而异：应用程序、框架和库的性能普遍得到提升，而基础设施和工具的性能中位数则有所下降。根据 Akka 的报告，Dify 的性能提升了 143333 倍，不过所对比的工作负载存在差异；而 Netflix Metaflow 的运行速度则慢了约 100 倍。
https://www.infoq.com/news/2026/10/ai-spec-driven-delivery/
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
