AI编程助手是帮手还是陷阱？

你有没有发现，用了AI写代码之后，反而更累了？

GitHub Copilot最近推出了一个叫Squad的功能，让多个AI代理（智能体）协作完成复杂任务。这听起来很酷，但一个更根本的问题摆在面前：当AI能生成代码，程序员的工作到底是什么？

为什么AI编程让人更累

Copilot Squad的作者提出了一个尖锐的观察。用AI生成代码确实变快了，但"如果你不在乎质量，感觉生产力爆棚；如果你经验丰富，知道维护高质量软件是什么滋味，就会明白这种感觉是骗人的。"

这里有个关键概念：阿姆达尔定律（Amdahl's Law）。它指出，优化系统的某一部分所带来的整体性能提升，受限于该部分实际被使用的时间占比。

翻译成人话：如果AI只帮你写代码，而写代码只占你工作的20%，那整体效率提升天花板就很低。剩下的80%——设计、测试、调试、维护、沟通——AI帮不上忙，甚至可能添乱。

更麻烦的是，AI代理不在乎代码质量。"它们不学习，不需要代码对未来自己友好，不会因为引发重大事故而恐惧，也不会在事后复盘时感到羞耻。"

在职场上，"把烂摊子推给AI"是快速失去所有人信任的方式。

两种极端路线之争

面对AI编程，行业正在分裂成两个阵营。

正方观点：人机协作，保持控制

以Jeremy Howard的SolveIt方法为代表。核心思路是用工具让AI辅助写代码，但主要由人编写，重点关注良好架构，保持代码简洁可理解。

这种方法的问题在于：工具链还没成熟，而且与"token最大化"（让AI生成尽可能多的代码）的行业趋势相悖。

反方观点：放手让AI swarm（蜂群）

以Steve Yegge提出的Gas Town为代表。基本不读代码，让一群AI代理自由发挥，只关注如何让这个配置产生预期结果。

这种方法的吸引力显而易见：如果AI能自己搞定，为什么还要看代码？

作者的判断：两种都是"天才"

原文在这里戛然而止，但倾向性很明显。作者花了大量篇幅论证"质量不可妥协"，引用阿姆达尔定律说明单纯加速编码的局限性，强调"在职场上不能vibe coding（凭感觉写代码）然后YOLO（不管不顾）"。

这些都在为SolveIt路线背书。Gas Town被一笔带过，更像是对行业极端现象的点名，而非推荐。

Squad功能到底是什么

回到Copilot Squad本身。这是一个让多个AI代理协作的功能，比如一个负责写代码，一个负责测试，一个负责文档。

作者的建议配置很有讲究：

不要完全放手。设置明确的检查点，让代理在关键节点停下来等你确认。

保持上下文精简。给AI的上下文越多，它越容易迷失。只给必要信息。

把重复决策自动化。如果某个判断你每次都会做同样的选择，写成规则让AI执行。

这些建议的底层逻辑是一致的：AI是工具，不是同事。工具需要被管理，而不是被信任。

程序员的新角色

一个令人不安的可能性被提了出来：我们的工作会变成写详细的需求文档，然后审查海量AI输出并对其负责？

这比写代码"糟多了"。写代码至少有创造性反馈，有"这段代码写得漂亮"的满足感。写文档和审查是纯粹的成本中心。

但作者没有停留在抱怨。他指出，几乎所有人都在用编程代理，"AI的实用性和需求不像加密货币"，不会消失。明智的做法是学会使用它，而非忽视它希望它消失。

关键是找到平衡点：利用AI的速度，但不放弃对质量的责任。

行动建议

如果你已经在用Copilot或其他AI编程工具，试试这个检验：最近一次代码审查，你有没有因为"这是AI写的"而放松标准？

如果有，这就是危险信号。AI不会为你的技术债务买单，不会替你参加凌晨的故障排查，不会在简历上为你的烂代码背锅。

Squad这类功能的价值，不在于让AI替你做更多，而在于让你更清晰地划分边界——哪些决策值得人类注意力，哪些可以委托给机器。划清这条线，可能是AI时代程序员最重要的新技能。