AI修改祖传代码，评审难题浮现与Arm解决方案

近年来，人工智能技术在软件开发领域的应用日益深入，从代码生成到自动化测试，AI正在重塑传统的开发流程。然而，当AI开始介入那些历经多年迭代、结构复杂且文档缺失的「祖传代码」时，一个意想不到的问题出现了：代码评审变得异常棘手。

根据某技术社区的观察，AI能够在几分钟内完成组件重构、补齐测试用例并整理目录结构。但真正让开发者感到困扰的，是这些经过AI改造后的代码在提交评审时引发的思考：我们究竟在评审什么？对于那些维护多年的前端模块，评审过程往往演变成一场关于「这是不是你想要的样子」的无休止争论。

这种现象背后，反映了AI生成代码与传统评审机制之间的深刻矛盾。一方面，AI能够快速产出功能完备的代码；另一方面，评审者需要验证的不仅是代码的功能性，还包括其可读性、架构合理性以及与现有系统的一致性。而当这些代码是由AI自主生成时，评审者往往难以判断哪些是必要的改进，哪些可能是过度优化，甚至可能引入新的潜在问题。

以近期Arm推出的AI Portal为例，该公司正试图通过提供全面的工具链支持来缓解这一困境。Arm AI Portal不仅为开发者提供了模型性能数据和部署资源，还允许编程智能体通过MCP（Multi-Container Protocol）调用相关资料。不过，面向智能体的资源目前仍处于预先体验阶段，这意味着开发者仍需在选择技术栈和运行环境时做出最终决策。

值得注意的是，代码交给AI之后，应用选用哪套技术、最后运行在哪里，依然需要作决定。编程智能体正开始参与这些选择。对Arm来说，争取开发者的工作也随之延伸到了AI查阅什么资料、调用哪些工具的环节。

Arm主要向芯片公司授权技术，却需要提前接近应用团队。等一款软件已经写完，它能选用哪些硬件，往往也受到了代码和依赖的约束。Arm AI Portal提供模型性能数据与部署资源，帮助软件先替硬件做了一轮筛选。

今年4月，Docker公布过一次颇有代表性的失败案例。团队想在Arm64 MacBook上运行音乐生成模型ACE-Step v1.5，结果连容器都没构建出来。Docker披露的原因藏在一条下载链接里：依赖文件把flash-attn安装包的地址写死为x86版本。机器已经换了架构，安装程序还在下载不兼容的文件。模型有35亿参数，卡住它的却是安装环节。失败发生在性能比较之前。

开发者很少直接找Arm购买CPU设计，但会决定项目采用什么模型、调用什么框架、装哪些依赖。如果这些软件只在一种架构上验证过，其他硬件就要先补一笔适配费用，才有资格参加接下来的比较。比如，一款应用决定把语音识别放在设备上，团队就得评估本地模型、运行库与内存；如果改用云端API，这些工作会转交给服务提供方，硬件选择也随之转移。算力需求并不会消失，只是在不同的产品选择之后，落到了不同的设备和企业账上。

对急着交付的团队来说，这笔费用往往比参数表更有分量。一个方案今天就能运行，另一个方案得先查清楚为什么装不上，后者再便宜、能效再高，也可能被暂时搁置。软件里的默认设置，有时就这样替团队完成了一次硬件筛选。

当然，使用某个框架，并不意味着从此只能选择一种芯片。开放框架本来就在努力跨越架构差异。问题是，理论上可移植，与一个普通团队能否在交付期限内完成迁移，距离不小。

Arm争取开发者，要改变的正是这段距离。它得让应用团队知道，Arm平台上有可用的方案，而且值得花时间验证。等基础设施团队开始比较服务器时，如果应用已围绕另一种架构完成部署，迁移和重新验证的成本就会进入采购账本。越早降低这些成本，Arm越容易参与后续的生态系统建设。