近几年 AI 工具快速融入研发流程。各类产品不断涌现,百家争鸣,而开发者的工作方式也在悄然发生变化。效率的提升已经成为共识,但与此同时,质量与可信性也被推到前台:在提速的同时,研发该如何守住质量底线?
近日 InfoQ《极客有约》X AICon 直播栏目特别邀请了众安银行技术委员会主席沈斌、华为云 PaaS 首席前端架构师侯凡、字节跳动 TRAE 架构师宁啸威一起,从前端、后端、架构等多视角探讨 AI 提效研发现状。
部分精彩观点如下:
在思考如何打造下一代 AI Native 产品时,重点是如何在人与 AI 之间找到平衡点。在 AI 能力尚未足够强大、无法完全放手的阶段,这个交互平衡点显得尤为重要。
无论是 RAG,还是上下文增强,或者 MCP,这些都只是手段,而不是目的。目标是搭建开放生态,让业务团队能够把 AI 当作大脑接入。
未来大量 Web 应用可能会消亡,包括网站和 APP,因为交互方式将转向自然语言。前端界面会极度简化,像谷歌最初的搜索框那样,而企业则主要提供后端的服务能力。
以下内容基于直播速记整理,经 InfoQ 删减。
AI 在研发中的角色演变
沈斌:很多团队最初接触 AI 时,是用它做一些具体的小任务,比如写测试、生成代码。但现在,我们看到 AI 介入了更多研发环节,甚至影响到架构设计和组织协作。我们常说的 AI 时代,是从 2022 年底 ChatGPT 推出后开始的。当时业界普遍称之为 AI 的“iPhone 时刻”。从那时起,AI 提效的话题迅速涌现。回顾近三年,我清晰地看到 AI 应用经历了三个阶段。
第一阶段是 AI 辅助编程。在这一阶段,AI 更多地作为工具存在,最常见的形式是 IDE 插件。这个阶段的模式很典型:左边是编辑器,右边是聊天框,遇到需要写小算法或简单任务时,就在聊天窗口中获得 AI 的提示,再应用到编辑器中。
这一模式持续了大约一年,后来出现了以 Cursor 为代表的 IDE 工具,我称之为“氛围编程 1.0 时代”。它在 Chat 模式的基础上引入了 Agent,可以自主完成一些简单任务,不再局限于局部方法,而是能应对简单的需求,研发效率因此明显提升。
第三阶段是今年 2 月份 OpenAI 联合创始人 Andrej Karpathy 提出的 Vibe Coding 概念,催生了当前火热的 Claude Code。这种形态从 IDE 升级为 CLI(命令行)模式,我称之为“氛围编程 2.0 时代”。相比 IDE,CLI 模式虽然门槛更高,但用户群体更广泛,玩法更多样,定制自由度也更高。
侯凡:当前网上对 AI 的看法往往有两个极端。第一个认为,AI 是下一代生产力革命,能带来颠覆性的效率提升。尤其是在 ToB 业务场景中,我们每天都能看到很好的实践案例。这种声音信心十足,认为 AI 会像当年云服务改造那样,重塑研发工具并显著提升效能。第二个则是在真实研发过程中感觉好像“没什么用”。他们并不像爱好者那样兴奋,而是认为当前 AI 的产出很难直接进入生产系统。
我相信各大公司也有类似经历。一方面,管理层寄予厚望,希望借助 AI 工具让效率提升数倍以上。但实际情况是,生成的大量代码很难放心直接入库。比如 Agent 模式一次生成一万行、两万行代码,但我们敢不敢真的直接把这些代码提交到生产库?当然,AI 在个人开发场景中很有价值,比如写小游戏、小 Demo,甚至家庭小应用,我自己也受益颇多。但换到 ToB 场景,要考虑的事情和因素就要复杂得多。
在我们团队内部,AI 编程的渗透率几乎已达到 100%。在使用 AI 工具的过程中,我们不断获得新的思路和启发,也对产品提出更多改进。在公司层面,AI 编程也受到高度重视,AI 工具被强力推广应用到各业务团队。以核心团队为例,头条和抖音的前端团队对 TRAE 的使用率已经很高。过去 iOS 或安卓开发同事将 Figma 设计稿还原为代码可能需要一两天,现在通过接入 Figma MCP 生态,借助 TRAE 或其他工具,“design to code”仅需几分钟。
市面上涌现了许多 AI 编程产品,在真实的编码场景中,决定用户口碑的一大因素是如何处理好“人与 AI 的交互”。以 Cursor 为例,它会在生成代码时要求开发者参与 review,在每个环节设置 checkpoint,允许纠偏或回滚,确保开发者对结果保持掌控,这种协作方式正是其核心竞争力所在。我们最近也在思考如何打造下一代 AI Native 产品,重点就是如何在人与 AI 之间找到平衡点。在 AI 能力尚未足够强大、无法完全放手的阶段,这个交互平衡点显得尤为重要。
侯凡:两年前,很多人担心 AI 会让工具团队失去价值。但结合实践来看,答案显然是否定的。代码能不能入库,取决于后续研发流程。即使是人工编写的代码,也必须经过严格的扫描和校验,AI 生成的代码当然也一样。
从我们的经验来看,研发流程并没有因为 AI 出现而被打破,而是加速了各个角色的效率。无论是开发者、测试人员还是架构师,最终都需要有人对结果负责。这意味着,AI 并没有减少“人”的必要性,而是让人承担更高层次的决策和责任。
我的总结是:一方面,AI 的确显著提升了研发效能,但它并没有完全颠覆现有模式,至少目前还没到那一步;另一方面,AI 的使用门槛不低,对开发者的工程能力和工具使用能力要求更高。我们需要保持理性和平和的心态,把 AI 看作是技术创新带来的重大提升,而不是一劳永逸的替代。未来或许会出现颠覆性的一天,但眼下更关键的是结合好的工具、模型和工程实践,把 AI 真正用好。
提效的“质”和“量”
沈斌:提效一般会想到速度加快,但其实在质量、稳定性、安全性上 AI 也会带来变化。大家自身或者团队方面有没有这些方面的变化?在质和量上,AI 分别带来了哪些提升?
因此我认为,随着 AI 的发展,反而会带来更多对确定性工具的需求。谁来守住底线?谁来约束和判断 AI 生成的代码?这就需要借助传统工具。很多传统的理念,如 TDD 等,其实在过去因为开发者没有时间而难以真正落地。而现在 AI 提升了效率,把时间还给了开发者,很多理念和方法都有可能重新得到实践。开发者可以更多地专注于工具开发,让 AI 生成的代码在规则范围内运行,从而做到可控和可信。只要经过既有的代码检查、安全扫描等工具的验证,我们就可以在新的语境下更好地应用这些规则。
我还观察到一个现象:提效效果不仅与岗位相关,也与使用者的经验水平有关。从“下限”来看,AI 编写的代码往往比大多数开发者更规范,因而下限更高。但从“上限”来看,人类开发者的能力仍然更强。因此在高阶开发者手中,AI 的提效更为显著;而在初级开发者手中,虽然 AI 能帮他们写代码,但他们常常无法完全理解这些代码。当出现问题时,他们不得不依赖 AI 修复 Bug,这实际上会带来 AI 应用上的反噬。
除了成本,另一个问题是效果难以量化和提升。不同用户在使用时感受差异明显,比如有人觉得 Claude Code 在某些场景表现更好,有人则更喜欢其他 Copilot 工具的简洁。这种差异底层上受制于模型能力,而能否真正理解用户复杂需求、掌握整体代码上下文,取决于 Agent 的设计理念。如何在成本与效果之间取得平衡,是目前相关产品面临的深水区挑战。
沈斌:我认为最大的难点在于公司管理层的认知是否对齐,尤其是一把手。企业大致存在两种情况:一种是认知落后,仍以传统方式推动研发,对 AI 提效不重视;另一种则是过于乐观,甚至认为 AI 能取代大部分研发人员,从而产生不切实际的幻想。这两种极端认知都会削弱企业的竞争力。
回到成本问题,虽然表面上 AI 的使用成本不低,但如果将 AI 视为“员工”,能带来 20%-30% 的研发效率提升,那么其投入是值得的。真正的挑战在于如何科学地量化这种提效。这涉及质与量的度量方法,本质上也是一个管理问题。
AI 重塑研发协作与架构
沈斌:AI 进入团队之后,在分工模式、协作方式,或者系统架构上,有没有发生明显变化?
我的观点可以概括为八个字:岗位左移,职级上移。所谓岗位左移,是指在 AI 提效的背景下,研发流程中的岗位会发生转移。测试向开发靠拢,开发向产品靠拢。同时,AI 会催生新的岗位,如 AI 产品经理、AI 架构师、提示工程师等,这些岗位已成为泛开发领域的重要组成部分。
职级上移更容易理解。由于 AI 对高级岗位的提效作用不如对初级岗位明显,因此未来团队中高级岗位的比例会提高,平均职级会整体上移。我们的内部尝试发现,在 AI 的辅助下,一个以高职级为主的团队,在同样成本下能交付更高的价值。
侯凡:我是前端出身,一直关注 AI 对前端的冲击。相比代码生成,我更关注它对用户体验和交互方式的影响。传统 UI 是基于图形化的信息架构,如层级菜单,这是一种有边界的体验。而 AI 出现后,语言交互逐渐兴起,我们称之为 LUI(Language User Interface)。它打破了原有边界,从文本输入到多样化的卡片排版,都集中在对话框中。
未来可能会发展为“无边界体验”。就像抖音的推荐流替代了传统的列表浏览,AI 的生成和理解能力也可能推动交互模式发生根本变化。大家常提到钢铁侠的“贾维斯”,就是这种 AI 导向的信息系统,通过自然语言或感知触发完成交互。
AI 的出现会深刻改变前端架构,因为前端始终围绕交互模式演进。随着 AI 学习能力和理解能力的提升,它不仅能学习代码和知识库,还能理解产品结构和业务逻辑,这将带来新的框架、工具和创新。我认为 AI 不会取代程序员,而是会催生新的产品、新的技术领域和新的方法论。
宁啸威:从后端和架构的角度看,过去流行的 SOA(Service Oriented Architecture)通过标准化接口拆分服务,以支持集成与复用。而 AI 的出现,特别是开放生态的建立,使研发和组织架构逐渐向 AI 中心化转变。比如 MCP 协议的应用,许多业务团队会在内部搭建 MCP Server,让公司内部的 Agent 能发现并使用他们的服务。这种模式可以称作 AOA(AI Oriented Architecture),或许会成为新的架构范式。
沈斌:其实已经有一个类似的概念,叫 A2A(Agent to Agent)。
宁啸威:未来研发组织可能会更加扁平化和网络化,由 AI 作为智能中介实现动态协作,快速匹配需求和能力,从而提高资源配置效率。
沈斌:未来大量 Web 应用可能会消亡,包括网站和 APP,因为交互方式将转向自然语言。前端界面会极度简化,像谷歌最初的搜索框那样,而企业则主要提供后端的服务能力。
展望未来
沈斌:放眼 3~5 年,如果只能选一个方向,你最期待 AI 在研发中实现的突破是什么?
宁啸威:我希望未来的 AI 能够从当前更像“高级工程师”的形态,逐渐向“架构师”的方向演进。这意味着 AI 不仅要具备更强的整体系统理解能力,还需要具备自我进化的能力。它能够不止停留在代码实现层面,而是参与到顶层架构的设计中。例如,当我们需要在不同技术方案或架构模式之间做出选择时,AI 可以基于现有项目特点、团队能力以及业务需求,提供更有针对性的架构建议。
未来,我希望 AI 能进一步介入顶层设计和技术决策,从而推动研发组织更加扁平化。那时,个人价值可能更多体现在战略规划和技术愿景上,而不是被琐碎的执行工作占据。
侯凡:我认为目前所有大模型在落地过程中,最大的问题是如何更好地理解具体的项目、团队和业务。为此,我们往往需要做大量前处理,包括语料准备和知识库构建。我希望 AI 自身能够具备一定的调优能力。通用大模型的能力已经多次被验证,真正的瓶颈在于准确性和上下文感知。如果能在工具化、平台化上降低准备成本,提高效率,我相信会极大促进大模型在企业中的落地。
沈斌:我最期待的未来是可穿戴设备的落地和普及。原因在于,当前 AI 之所以无法闭环整个研发流程,一个关键问题是缺乏感知能力,也就是所谓的“具身智能”。举例来说,AI 可以沿着研发流程完成需求分析、文档设计、代码编写、单元测试,甚至部署。但在最后的业务验收环节,它无法像人一样在真实环境中验证需求是否达标。AI 只能在模拟环境中进行验证,缺乏与真实世界交互的能力。
沈斌:“全栈”这个概念其实提出已久,但由于技术门槛高,真正能完全胜任全栈的人并不多。在 AI 时代,人机协同让这一点变得更可能实现。对于前端或后端出身的程序员,通过 AI 的辅助,完全可以较快地掌握另一端的平均水平。AI 已经能达到中级开发水平,对于大多数非复杂需求,它生成的代码具备较高可用性。程序员可以在此基础上进行理解和反向学习,从而提升自己的能力。
例如,Claude 在 8 月 15 日的更新中推出了三种模式:一种是“默认模式”,由 AI 一条龙完成代码编写;第二种是“解释模式”,AI 在编写过程中同步解释代码逻辑;第三种模式则会刻意留下一些 TODO 项让人类开发者完成。这种模式非常适合想要向全栈方向发展的人,通过与 AI 协同,可以更快补齐短板。