在当今软件开发领域，人工智能代码助理成为许多开发者关注的焦点。它们宣称能够帮助程序员提高生产力，减少重复且枯燥的工作。但当实际任务交付到AI手中时，结果往往令人既期待又失望。本文聚焦一项由技术负责人亲自尝试的现实案例——将企业级仪表盘的状态管理系统从传统的NgRx迁移为全新的信号（signals）服务架构。任务表面上简单，是典型的重复重构工作，理论上正是人工智能的擅长领域。然而，结果是否如愿？本文将全方位还原这次“AI助理”的真实表现。
整个实验围绕四个主要轮次展开。起初，使用了微软的Copilot。令人失望的是，Copilot几乎没有任何实质贡献，它只查看了部分文件内容便选择清空代码。这样的行动令开发人员立即关闭工具，完全无法继续依赖。接着是Cursor.ai的两次尝试。第一次尝试虽然做了一些代码移植工作，但很快陷入了错误修复的死循环中，错误越改越多，最终不得不中断。
第二次尝试尝试缩小范围，单独处理一个store的全部组成部分，结果却让人哭笑不得：AI竟开始自动重写CSS，这与任务完全不符，彻底打乱了进度。之后的回合转向了基于网页版的GPT-4o。尽管返回了一个压缩包文件，但文件中的服务代码基本是空壳，只有“移植特效效果”等TODO注释，没有实际代码。另一版本的GPT-4o-mini-high号称擅长代码，结果却输出了一篇如何手动迁移的博客文章，虽然有参考意义，却毫无自动生成代码的实质价值。Gemini 2.5 Pro稍有起色，输出了部分代码，但大多数是需要开发者进一步填充的占位符，甚至还夹杂着“懒人请自行完成”之类的戏谑留言，明显还是缺乏实用性。终于，第四轮的Claude 3.7展现了一些诚意。
它按照指示成功移植了两个小型store（UI状态和选择状态），代码较为完整且未出现崩溃。但到处理第三个大型store时崩溃频发，出现“输出消息太长”等内存错误。通过将任务拆分为更小服务逐一输入，虽然仍时常崩溃，但最终产出了一些可以用的代码片段。核心数据store迁移成为了最大难点，人工智能先后生成了大量带有未定义变量和无调用函数的代码，根本无法直接使用。技术负责人不得不耗费数小时不断点击“继续”，仿佛被实验室的多巴胺循环所困扰，最终产出代码“勉强能编译”，但在实际应用后，大量功能缺失，真实开发需求难以满足。时间成本极高，整整一天几乎被浪费，只有约两百行代码稍具实用价值，虽算不上成功，但仍优于其他工具的表现。
几周后，受限于网络视频的演讲启发，实验者决定借助Claude的全新“Claude Code”体验再度尝试，同样的任务，换了体验后依然失败，甚至等待令牌重置长达三小时。最终Claude生成了80行代码，耗时45分钟，且完成了引用更新。运行仪表盘后体验依然不尽人意：代码量过少，遗留大批功能缺失，花费大型项目一个周末的时间却换来平平无奇的成果，令人极为失望。这次真实实验表明，当下人工智能代码助理虽在某些简单任务中提供有限帮助，但仍难以胜任复杂的代码迁移和重构项目，稳定性不足且易出错的现象普遍。AI无法完全理解项目背景与业务逻辑，导致生成代码需要大量人工校对和修正。加之工具多次崩溃、内存限制、超长输出无法处理等问题，当前阶段的AI编程辅助更多依赖人类开发者的监控和介入。
尽管如此，AI代码助理的发展潜力不可小觑。短期内它们或许不是能独当一面的替代品，但可以通过拆分任务、精细指令和合理期望为程序员缓解部分重复劳动压力。未来若算法、模型及计算资源得到优化，结合人机协作模式，工具的表现必将提升，为软件开发者提供更实质的价值。从这次体验中，我们取得的最大教训是：技术不能盲目追求创新，而应平衡效率与准确性，合理规划人机分工。程序员依然不可或缺，需要深刻理解业务需求，熟悉技术栈，掌控项目全局，才能将AI赋能转化为实际生产力。同时也提醒开发者理性评估当前人工智能工具的能力，避免因过高预期而浪费时间。
总而言之，现阶段AI代码助理适合辅助简单重复、代码片段生成和提示优化工作，而对于复杂、细致且关系紧密的系统重构，依赖人工智能仍有巨大风险。未来期待这些工具能够在实际应用中不断磨砺进步，助力行业迈向更高效、智能的软件开发新时代。
