AI 给编程工作带来根本性转变了吗？

在目前的研发工作中，就算有 AI 加持，产研团队依旧面对很多问题。那么，企业应该如何通过 AI 重塑工作方式？研发团队能够采用智能化手段，在提升工作效率的同时，也推动创新和业务增长吗？

日前 InfoQ《极客有约》X QCon 直播栏目特别邀请了腾讯技术总监黄闻欣担任主持人，与百度前端架构师、百度技术组织委员会 Web 方向负责人张立理，字节跳动质量效能专家赵亮、盛派网络创始人兼首席架构师苏震巍，共同探讨利用 AI 技术重塑产品研发核心流程的最佳实践。

部分精彩观点如下：

• 在需求分析和产品原型快速生成方面，AI 有潜力帮助产品经理节省大量时间。

• 实现大规模端到端的自动生成目前看来并不现实。

• AI 应该从根本上消除所谓的幻觉，而不是依赖于算法的不断修补。

• 我更期待 AI 会提问，而不是只是帮我做做总结。

• 低代码、零代码平台以及自然语言编程技术的发展，正在降低编程的门槛。

• 智能家居可能是零代码 AI 编程最容易进入的领域。

在 10 月 18-19 日将于上海举办的 QCon 全球软件开发大会上，我们特别设置了【AI 重塑技术工作流程】专题，关注实际案例和解决问题的策略，旨在解决当前研发团队面临的困境，让智能能真正赋能业务，创造价值。

 

在该专题论坛中，百度的张立理老师将分享《大模型技术重塑智能研发新范式》；字节跳动的赵亮老师将分享《基于 LLM 的单元测试用例自动生成》；盛派网络的苏震巍老师将分享《协同研发的流程重塑：使用 AgentManager 打造多智能体 Copilot》。查看大会日程解锁更多精彩内容： https://qcon.infoq.cn/2024/shanghai/schedule

以下内容基于直播速记整理，经过不改变原意的编辑。完整视频参看：https://www.infoq.cn/video/97wLJ4mDdPdDxqiiz7V8

AI 给编程工作带来根本性转变了吗？

黄闻欣：AI 技术在工作流程中带来的最显著变化是什么？这些变化是否仅限于效率提升，还是涉及到了工作方式的根本性转变？

苏震巍： 我工作中主要涉及商业项目管理和开源社区管理两个方面。在商业项目管理层面，我们已经将 AI 应用于公司的日常决策中。AI 代理结合知识库和其他技术，帮助我们理解岗位背景能力，并辅助从运维到公司内部决策的各个方面。在项目开发和交付过程中，使用 Copilot 等工具辅助开发，以及在测试和运维阶段利用 AI 机器人进行监控和问题处理。AI 在预测和处理问题方面的能力远超传统算法，使我们能够以更低的成本实现更高的效能。

在开源社区管理方面，我们利用 AI 分析社区数据，如 GitHub 上的活跃度，以辅助决策。AI 帮助我们分类问题、确定优先级，尤其是在资源有限的情况下，AI 的筛选能力极大地缩短了处理时间。以前需要半小时完成的数据采集和分析，现在几秒钟就能完成。此外，我们还有一个对话窗口，社区成员可以直接向 AI 提问，获取历史数据并得到操作建议。

赵亮： 在研发流程尤其是 DevOps 流程中，AI 已经开始改变我们的工作方式。在研发的上工程阶段，可以通过结合历史需求、研发等数据对大模型的针对性训练来辅助研发进行需求分析、架构设计和风险识别。而在下工程阶段，AI 工具如 Copilot 已经在编码和运维中发挥作用，提高了我们的工作效率。此外，传统的代码扫描工具在 AI 模型的协助下，也进一步提升了在代码理解和风险识别场景的效果，帮助我们在代码上线前进行风险规避。

不过目前 AI 模型尚未成熟到可以完全替代人类。在模型不能完全守好最后一道风险门槛的情况下，我们仍然需要人为地进行最终的审查和决策。

张立理： 代码生成分为两种形式：一种是在编写代码过程中的续写，另一种是非续写，即在非编码过程中生成的代码。我注意到，非续写的代码在所有模型生成的代码中的占比从最初的 5% 到 10%，已经增长到现在的 30% 多，并且这个比例还在向 40% 增长。这表明，随着大模型的应用，开发者在一定程度上已经从编写代码的工作中解放出来。他们越来越多地使用自然语言或者介于人与程序之间的某种语言来生成应用，这是一种工作方式的重大转变。

我们的数据还显示，社区版的非续写代码使用率高于公司内部版，这可能意味着更专业的开发者可能更倾向于使用自己的专业知识来编写代码，而社区中的开发者则更快地接受了这种变化，以提高他们的工作效率。

黄闻欣：生成式 AI 在哪些场景适用，哪些场景不适用？

苏震巍： 我认为 AI 在编程领域的应用场景存在一定的割裂。一方面，AI 在帮助解决编码问题方面确实有很大的潜力，但另一方面，尽管 AI 在生成代码块和单个代码文件方面表现出色，但它并没有真正解决程序员想要解决的问题。程序员不仅仅需要 AI 来续写代码，他们更希望 AI 能够理解整个项目的意图，并协助完成整个项目的开发。

赵亮： 我认同苏老师的观点。我们之前也考虑过开发基于模型完成需求交付生成的项目，让模型从头到尾帮助我们完成。然而，如何让模型理解需求背后的真正业务含义，以及需求与代码之间的关联关系，这很困难。

我认为 AI 在许多民生或业务场景中并不适用，特别是在数据质量不高或数据缺失的情况下，模型的泛化能力不足，难以实现预期的意图。对于高风险或高责任的场景，如辅助驾驶或医疗决策，模型的准确率还不能完全达到 100%，需要人为介入。AI 目前仍处于狭义智能体的阶段，距离广义智能（AGI）还有很长的路要走。如果能够达到 AGI 阶段，大模型可能会彻底改变社会和人们的工作行为。

张立理： 在软件领域，实现大规模端到端的自动生成目前看来并不现实。我将这种情况归因于两种复杂度的影响：需求复杂度和背景复杂度。需求复杂度可以通过产品或技术人员的拆分来管理，理论上是可干预的。然而，背景复杂度则更加难以处理。例如，一个 8 岁小孩可以从头开始创建一个聊天应用，因为它没有背景复杂度。但在现实世界中，尤其是在有大量历史数据和复杂业务逻辑的情况下，背景复杂度变得非常高，即使是经验丰富的开发者也可能需要很长时间才能完全理解并处理。

黄闻欣：AI 作为检查者的角色，它在推理方面的要求相对较低，这使得它在检查代码时能够发挥出不错的效果。此外，尽管我认为从头开始完全构建一个端到端的应用是不太可能的，但我认为，如果能够通过 AI 快速生成产品原型，并且不担心这些原型在初期存在 bug，那么 AI 在这一领域的应用将是非常有价值的。

挑战和机遇

黄闻欣：AI 如何帮助你们更高效地识别和分析需求？是否有具体的工具或方法可以分享？

张立理： 我们在需求分析阶段面临的挑战往往是需求文档本身的不完善，特别是在互联网公司，我经常发现需求描述过于简略，这使得开发团队难以准确把握需求的实质。因此，我对于 AI 在需求分析环节的期望是，它能够通过提问来引导和澄清需求，而不仅仅是做总结。我希望 AI 能够与产品经理进行深入的对话，提出关键问题，以确保需求的详细程度足以指导开发工作。

赵亮： 需求分析的过程其实类似于多智能体的协作，智能体需要规划、分类和考虑后续步骤。在需求产生后，我们需要考虑它背后需要对接的系统，以及这些系统对应的服务或链路。这是一个逐步完善需求和技术实现的过程。在模型能力尚未足够强大的情况下，我们可能需要依赖于智能体或小模型来引导产品团队逐步完善需求。

苏震巍： 在代码开发过程中，不同的行业都有许多所谓的“行业规则”或内部商业秘密，这些信息不会出现在互联网上，也不可能被训练到公共开源模型中，这就导致了 AI 可能无法理解某些特定领域的缩写或术语。为了让 AI 理解这些术语，我们需要花费大量时间进行解释，这在实际操作中并不现实。

让 AI 从需求端一直走到产出端，会面临许多额外的问题。尽管如此，我们也取得了一些成功的尝试。其中一个关键点是小模型的优势，它们容易进行微调和增量训练。当 AI 对特定领域的名词和背景知识有了更深的理解后，它就能更好地与我们进行互动，通过多轮对话来生成更完善的文档。这种互动过程比直接让 AI 写代码要靠谱得多，因为它能不断提醒我们可能需要考虑的设计方面。

黄闻欣：RAG 技术会长期存在用于降低大模型幻觉吗？技术难点是在文档解析上吗？

苏震巍： 我非常不希望 RAG 长期存在，我认为它是一个过渡性技术。就像我之前提到的，RAG 的产生是为了解决特定问题，但它并没有从根本上解决，而是采用了一种打补丁的方式。例如，在 Transformer 模型中，我们利用了 Embedding 技术来处理 Token，而 RAG 的检索阶段也是用到了 Embedding，相近的技术栈使工程化变得更加容易，并且已经被模型验证过有效性，这可以看作是一种巧妙的利用，但并非从根源解决了问题。

尽管 RAG 在知识库检索方面表现良好，但我认为它仍然需要更多的补丁来完善。微软最近推出的 GRAPH RAG 产品将知识图谱的概念引入其中，这是一大进步，但也可能只是对 RAG 的又一次修补。我们可能需要不断地为 RAG 打补丁，以弥补其能力的不足。我更希望看到的是，AI 能够从根本上消除所谓的幻觉，而不是依赖于算法的不断修补。

张立理： 除了苏老师提到的，我认为 RAG 技术还解决了模型处理大规模数据的窗口大小问题，但同时也带来了召回量过大的新挑战。在代码处理方面，难点在于代码与自然语言的巨大差异，而非格式化和解析。尽管尝试了多种方法，如模型解释和注释，以及使用专门的代码 Embedding 模型，但效果都不尽如人意。理想的解决方案应该是让模型能够像人类一样使用工具，通过关键词搜索、查找定义和引用等，而不是单纯依赖向量距离，因为这种方法在代码领域并不实用。

黄闻欣：AI 应用上线之后，对服务器架构、服务器配置、网络配置要求有什么方向的变化？

苏震巍： 首先，当我们通过远程 API 调用如文心一言或其他服务时，硬件资源如 CPU 和内存的需求实际上并不高，可以忽略。但是，对于网络稳定性的要求却显著增加，因为大多数应用仍然依赖于流式输出来提供更好的用户体验。这意味着连接的持续时间变长了，无论是使用 Websocket 还是其他缓冲技术，连接都不能中断，否则可能会导致数据丢失或对话中断。

其次，我们发现私有化模型部署的需求越来越多，这直接关联到 GPU 的需求。随着 GPU 的使用，可能还需要升级电源、内存，甚至机箱大小。这些变化对机房的要求也提出了新的挑战，包括空调、机架空间和带宽等，机房托管相关的成本可能从几万元上升到几十万。尽管如此，这些硬件升级带来的收益也是显著的，比如提高了信息安全性，并且为模型的微调和其他操作提供了更大的空间。

我还想补充的是，训练机器和实际运行机器的需求有很大的不同。如果是为了训练模型，那么对算力的要求会更高。但如果只是运行已经训练好的模型进行推理，那么所需的算力可能会减少到原来的几分之一。在这种情况下，一些高端的显卡，如 4090 或者类似的型号，就足以支持一些较小模型的运行。

黄闻欣：对于现有的历史业务代码，如何利用 AI 做好对下游仓库的可维护性，更好地做好架构治理？

赵亮： 许多互联网公司，尤其是一些成立时间较长的中大型企业中，他们的代码库往往非常庞大且复杂，有的应用可能已经有十几年的历史。这样的代码库不仅逻辑复杂，而且如果之前对历史需求文档的维护不够完善，还可能存在许多断档问题。因此，当业务人员接手这样的仓库时，他们需要投入大量的精力去理解和维护，这无疑增加了成本。

在这种情况下，如果能够利用模型在前期帮助我们进行梳理和结构化调整，我认为这将在历史存量代码的治理以及后续的常态化保鲜中发挥出价值。然而，这也带来了一个问题，即如果使用一些开源的或者未经训练的模型，它们对于大厂或特定行业内的标准规范框架和组件的理解可能并不深入。因此，如果能够结合公司内部的特点，训练出一些专有的小模型，然后利用这些模型来处理知识数据或文档的保鲜和整理工作，这将为我们带来巨大的价值。

黄闻欣：AI 在代码维护、代码审查、错误检测和安全漏洞预防中的表现如何？大家是否使用过特定的 AI 工具来提高代码质量？

赵亮： 模型在代码评审方面能够帮助我们发现许多规范性问题，甚至可能引发空指针及越界等潜在问题。然而，模型的能力确实存在局限，尤其是在处理大量代码内容时，可能会出现“幻觉”，导致无法准确定位问题或者找出过多不相关的问题。为了解决这个问题，我们采取了一些策略。我们会结合程序分析来精简代码内容，缩小范围，比如从 1000 行代码中分析出 550 行可能是增量或上下文相关的代码，然后再让模型进行评审。

另外在单元测试生成上，虽然传统的工程方法也能生成单元测试，但数据构造往往难以符合业务语义，导致数据的真实性差。而结合模型，我们可以利用模型对代码链路级甚至全仓库级的理解，使得数据构造更贴近业务语义。但是，模型在生成单元测试时也可能会引入编译问题或未引入变量等的问题，导致生成的测试用例无法运行。因此，我们不仅依赖模型，还结合了大量的工程分析和检测手段，以确保生成的数据的真实性、代码的编译性和运行可靠性，以及断言的准确性。

张立理： 百度内部主要在 App 开发方面应用了一些 SFT 的模型。这种模型能够帮助我们完成那些日常开发中我们不太关注或不愿意花时间处理的任务。例如，当我编写代码时，我并不会每天都去检查 CVE 漏洞列表，看看我的代码中是否存在潜在的安全问题。而模型能够帮助我检测这些漏洞，这本身是一件纯收益的事情。

苏震巍： 我们公司利用 AI 模型进行态势感知，通过分析行为模式来识别高风险活动，这些模型能够提供从 0 到 1 的风险评分，帮助我们决定是否需要进一步调查或采取行动。其次，AI 对我们最大的贡献在于单元测试的生成。我们采用基于领域驱动设计（DDD）的方法，强调单元测试驱动开发（TDD）。通过详细的需求描述和明确的范围界定，我们能够先编写单元测试，然后根据测试来完善代码。这样的流程确保了代码质量，无论最终是由人工还是机器来完成代码编写。AI 还帮助我们进行风险控制，并且我们正在探索使用迁移算法来分析项目进度。例如，在医疗项目中，我们使用 AI 技术来分析 X 光片数据，通过 3D 可视化展示项目中的关键节点和进度，这使得我们能够更高效地复盘和预测潜在问题。此外，AI 还协助我们审查开源项目的使用，确保我们不会因商业侵权问题而面临风险。

黄闻欣：在测试领域，例如自动化测试以及功能测试，AI 如何在这些方面发挥作用？

赵亮： 大模型在文档撰写和自动化能力构建方面具有显著的优势。特别是在单元测试方面，我们已经探讨了其潜力，但我认为大模型的泛化能力还能在更广泛的领域发挥作用，尤其是在功能测试的生成上。功能测试通常需要测试人员基于需求原始功能来编写主流程的测试用例，但往往很多测试场景需要测试人员发挥创造性思维，想象出更多的异常情况。

大模型在这方面能够提供帮助，因为它能够基于对需求的深入理解，生成包括异常场景在内的各种测试用例。虽然这些用例中可能会包含一些不切实际的情况，但它们可以作为初次筛选的结果，之后可以通过人工进行二次过滤和筛选。这样的过程不仅能够帮助我们补充和增加测试用例，还能发现那些可能连经验丰富的测试人员都未曾想到的场景。

张立理： 在我们团队的探索中，手工测试用例的生成被视为一种中间语言，它不仅规范了测试流程，还能转化为自动化脚本，尤其是驱动浏览器的自动脚本，我们正在尝试将这一过程自动化。此外，我们之前尝试让 AI 直接处理 Web 页面的源码来进行自动化测试，但效果并不理想，因为 HTML 中的噪声太多，AI 很难准确选择元素。

为了解决这个问题，我们开始尝试使用视觉模型来识别页面上的元素。我们不再要求 AI 在特定的 DOM 路径下选择元素，而是让它识别出看起来像按钮的元素，并且识别出按钮上的文字，比如“确定”。这样，我们就可以利用这些信息生成用于自动化测试的选择器脚本，从而继续进行自动化测试。

苏震巍：CI/CD 流程以及测试开发和运维的整个过程中，存在许多耗时的环节，比如反复的交互、编写测试用例、撰写 bug 修复报告等。这些工作虽然必要，但对于工程师来说，往往是一种时间上的浪费。我们团队已经开始利用 AI 来优化这些流程。例如，我们有一个机器人负责监控项目进度，它会在群里提醒团队成员完成各自的任务，确保每个环节都能按时推进。这个机器人充当了团队的“胶水”，帮助我们缩短了业务对接的时间，并在交互过程中完成了一些繁琐的工作。

黄闻欣：我总结一下，在 AI 的应用中，我们可以将其作用简化为，将数据转化为信息、再提炼为知识的过程。在处理 ToB 业务的工单时，AI 能够从大量的聊天记录中提取关键信息，并帮助我们将专家工程师在讨论中的知识点转化为可沉淀的知识。

未来展望

黄闻欣：AI 辅助编程开发是走 Workflow 还是 Agent 路线 ？如果 8 岁小女孩也可以编程的话，我们如何看编程技术的普惠性？

张立理： 我期望 AI 能够在没有任何背景复杂度的情况下，无需使用者专业性实现规模不大的应用的开发。我认为这是可行的，尤其是与处理几十万行代码的迭代相比，这种小规模应用的开发要简单得多。其次，我相信 AI 的普及将使得非专业开发人员也能受益，他们的需求通常不会像软件研发人员那样复杂。在许多场合，AI 可以作为生活辅助工具或创意实现的平台。

我认为智能家居是最有可能首先采用零代码 AI 编程的领域，因为每个人都可能需要对家居设备进行编排，但目前因为编程技能的门槛，这些需求往往无法实现。未来，通过自然语言描述转化为脚本，再由脚本控制家居设备，这是完全可能的。我也相信，类似的应用可以快速扩展到个人信息管理和财务管理等领域。

然而，我有一个疑问，这种零代码 AI 编程会不会改变软件的生命周期？传统上，我们认为软件开发完成后应该具有较长的使用寿命。但如果通过零代码方式快速生成的软件能够满足需求，并且使用后可以丢弃，那么软件的生命周期可能会变得非常短暂。这就像我们写脚本一样，用完即丢，当再次有需求时，再次编写。这种可能性让我思考，未来的软件是否也会呈现出这种即用即丢的特性。

苏震巍： 我的观点与张老师基本相似。首先，关于软件生命周期的问题，我们一直在思考未来软件将服务于谁，以及它的载体是什么。这是一个重要的问题。将来我们可能需要控制实体机器人，这可能需要一些编程基础而不仅仅是简单的指令。在这种情况下，我们可能需要进行一些手工编程，以便更好地服务于家庭机器人。

其次，我认为在 ToB 业务中，编程主要还是面向非常特定的场景。对于这样的场景，有两种可能性：一是像张老师提到的，未来某些软件可能根本不需要存在，因为 AI 可以直接提供答案。例如，如果 AI 可以直接解决计算问题，那么编写计算器 APP 可能就不再必要了。二是对于那些需要特定知识和安全要求的封闭场景，这将是一个巨大的市场和就业机会。

赵亮： 我曾读到一篇有趣的文章，它提出了 AI 可能发展到的一种形态，即所有的应用程序可能最终都会面向用户呈现为一个聊天界面，没有其他按钮或入口，而是可以根据人的任何意图去实现、生成或展示用户想要的内容。这种形态下，一个需要解决的问题是如何统一现有的各种模型标准和规范，因为这些标准和规范的多样性可能会成为非技术人员进入这一领域的瓶颈。

我认为，未来需要推动形成一个统一的模型标准，这不仅包括模型的使用和服务标准，还涉及到模型评测的标准。目前，即使是在业内，对于模型的评测也缺乏统一的标准。为了实现 AI 的普惠，无论是企业之间还是学术界之间，都需要建立对模型的统一认知和规范。

这样的统一标准将极大地降低非科班或非技术背景人群的进入门槛，这些人他们可能有很多创意和想法，但受限于传统的编程技术门槛而难以实现。如果有一套统一的规范来实现多种语言和技术栈的功能，未来将会有更多的人受益于模型。

会议推荐：

10 月 18 日 -19 日，QCon 全球软件开发大会将在上海举办。从云原生工程、架构、线上可靠性、大前端、技术管理等经典内容，到 AI Agent、AI Infra、RAG 等大热的 AI 话题，60+ 资深专家共聚一堂，深度剖析相关落地实践案例，共话前沿技术趋势。大会火热报名中，详情可联系票务经理  17310043226 咨询。