阿里许晓斌：我团队里 AI 替代程序员还不现实， AI 编程工具没产生质变

软件编程是最先被生成式 AI 冲击的领域之一。而对于原来的技术团队管理者来说，他们对生成式 AI，尤其是 AI 编程工具的态度，会很大程度上决定整个团队的 AI 使用效率。

许晓斌 作为阿里巴巴技术风险和效能部技术总监，已经有五年以上的管理经验。那么，团队成员使用 AI 编程工具会给以他为代表的管理者带来什么影响吗？AI 编程工具是否会给企业带来代码质量等问题？

许晓斌： 据我了解，目前大家主要使用的工具就是代码补全和代码会话，前者就是集成在 IDE 中，后者可以在 IDE 中，也可以是单独的交互界面。此外就是嵌入到研发流程中的 AI 增强，比如 Code Review，Agent 自动升级 JDK，诊断各类错误等等。它们都能在一定程度上帮助开发者提高日常研发工作的效率。至于缺点，有些产品比较成熟，如补全和会话，而其他的就相对都还在比较初步的阶段。

许晓斌：Cursor 相比 Github Copilot 之类的主流编程助手工具，由于抛开了 IDE 设计的思维历史，显然其产品思维更底层，即它在尝试重新思考 IDE 应该怎么做，例如它可以在任意文件夹 / 文件 /Codebase 呼出会话上下文，这个是其他 IDE 无法做到的，因此它给人“惊艳”的感觉。至于多大痛点，我倒不觉得已经形成了突破，这个还需要再看看。

至于为什么 AI 编程工具发展这么快，第一是因为程序员群体薪资高，因此给他们提高效率的商业价值非常显著；第二是这个群体对新技术充满热情，更积极拥抱新的技术，因此也促进了这个领域的发展迭代。

许晓斌： 目前的 AI 编程工具都是基于之前的研发流程范式在改进，从各种产品不断涌现来看，还处于初步的阶段，而且模型的演进给这类产品的想象空间带来了巨大的不确定性。对开发者来说，肯定是需要去主动拥抱和使用才是正确的，因为未来 AI 必定能够替代开发者的一部分工作。

AI 编程工具的优化方向，我觉得是两方面：一部分是模型自身的突破，这个我不专业；另一部分是企业需要重新思考自己的数据，能够让编程工具充分用起来。

许晓斌： 肯定支持，不支持才需要问为什么，更何况我们自己团队也在建设 AI 工具，如 Aone Copilot，自己肯定得吃狗粮。我也看到团队很多成员在部分用 GPT 或者千问替代搜索引擎来查阅各种资料。包括我自己，当我做一些新的技术领域的 research 的时候，就会找 GPT 给我推荐一些论文，当我学习一些新的编程语言和框架的时候，我也比较依赖代码会话工具给我许多建议（大多数时候这些建议都非常准确）。在当下的阶段，生成式 AI 会对软件工程产生怎样的影响，我现在还没有比较清晰的判断，我不太信任各种动辄颠覆的断言，但也不持保守的态度，因此积极去使用、去理解、去学习，我认为是较为正确的方法。

许晓斌： 我们团队的日常开发工作有严格的 code review 和单元测试覆盖的流程，无论是否是 AI 生成的代码，都需要经过 code review 和 CI，所以并不担心质量问题，实践中也还没遇到过 AI 生成的代码引入的严重生产问题。更何况，很多时候人写的代码质量，并不见得比 AI 生成的代码质量高，我们还在内部研发基于 AI 做 code review 的工具，虽然还仅仅处于比较起步的阶段，但随着时间的积累，这方面的工具肯定能帮助改进代码质量的。

还有一些代码质量的问题是需要在运维阶段才容易被发现的，传统的做法会在发布的工具建设、监控能力的改进上下功夫，长期来看这部分应该也能充分使用 AI 的能力，也就是说大家说的 SRE Copilot，但是这个会更难一些，因为它要结合大量实时的数据分析。

许晓斌： 首先，我认为今天各类主流 Copilot 生成的代码质量还是不错的，没很多人想象的那么糟糕；其次，我也认为今天许多开发者写的代码质量是很差的，没很多人想象的那么好，因此我不认为用 AI 工具会带来更多技术债。更何况技术债更多时候不仅仅体现在编码那一时刻，组织架构是否合理、系统架构是否合理、技术 Leader 是否重视长期的技术健康度，都远发挥了更重要的作用。

许晓斌： 对我来说好像没有什么太大的挑战，很多人说 AI 要替代程序员，至少在我团队（负责阿里巴巴研发运维基础设施）这个事好像还不太现实，我会鼓励大家积极使用各种工具提高自身的效率，团队多数人也确实每天都在使用。这个问题的回答也从侧面说明了，今天 AI 编程工具的引入，其实还没产生质变，所谓质变即它真的替代掉了一些岗位，让一些岗位消失了，那个时候管理者就需要重新思考组织结构设计。

许晓斌： 他们积极去用就可以了，鼓励为主，不会提什么严格的要求。使用 AI 工具不像训练模型，没啥门槛，我粗略估计我团队的成员，有八成的人每天都在用相关的工具。

许晓斌： 这个问题比较大，也和 AI 不是强相关了。我觉得提高团队效率的核心还是提升开发者的体验。首先，给他们设置有挑战有意思的目标，激发团队；其次，在组织结构和系统架构上设计比较合理的高内聚低耦合的边界，让团队同学可以用更多的时间去思考如何解决技术 / 用户问题，而不是浪费在沟通和消耗上；还有，就是建立比较好的工程师文化和氛围，关注工程质量，而不是整天在所谓的“代码屎山”上工作；最后，就是给他们提供最好的工具，无论是 AI 的也好，还是我们称之为平台工程也要，这也是我团队为阿里巴巴整体在做的事情。

以上四点，其中前三点都是需要管理者去有意识的建设的，那管理者对人的沟通和共情能力、组织的设计能力、系统的设计能力，以及对软件工程的理解，都是需要长期提升和学习的。

许晓斌： 从商业角度就是个简单的成本逻辑，提升效率 = 降低成本，下一步就推导到优化岗位了，这个我也理解。我认为很多人短期内高估了 AI 的能力，因此急急忙忙就要拿到效果。今天 AI 编程工具的能力还比较初步，如果能替代一些岗位的话，只能是一些比较简单的岗位，比如不涉及复杂业务逻辑的前端，或者一些有了测试用例的文档后编写测试用例代码的测试岗。但实际上我们看到 AI 出现以前，这些岗位在很多公司都被逐渐用外包（编程能力较弱）来取代正式员工了，背后的成本逻辑其实是一致的。

无法被 AI 取代的部分，主要有几方面：

1. 需要大量沟通理解的领域模型和业务逻辑，我们不能指望 AI 和人聊后，把业务逻辑梳理清楚。

2. 对可用性质量要求比较高的部分，例如调度系统、中间件、存储核心系统。

3. 其实也就是暗含在 2 中的，就是逻辑极度复杂的场景，短期模型能力好像还不够。

许晓斌： 这个问题是错误的，技术管理者需要同时兼顾技术和管理，二者缺一不可。在实际的工作中我看到的优秀管理者，都是两者同时成长的。如果只做管理，缺乏对技术深度的理解，就会在风险的识别，人员的任用，系统的合理架构设计上出现许多问题。反之，如果只关注技术，缺乏对人的理解和关心，那随着团队变大，各种冲突、矛盾就会被方法（是的，有人的地方就有观念差异和冲突），管理者很多时候是在基于对每个人的理解和认同的基础上，去建立团队的共识和积极的氛围，是一件解决工程师团队规模 Scalability 的事，即随着人员的增多怎么保障平均每个人的贡献不下降。

对技术管理者的建议，核心是两条：

1. 不要轻视技术，要持续关注和学习。

2. 你是否从成就他人的过程中获得成就感？如果答案是 YES，那你肯定可以做好一个管理者。