首页科技快讯存量代码库难适配、人机边界模糊？百度拆解Coding Agent企业级落地的硬核解法

存量代码库难适配、人机边界模糊？百度拆解Coding Agent企业级落地的硬核解法

来源：晰数塔互联网快讯时间：2026年04月16日 10:52

作者｜颜志杰，百度资深研发工程师

策划｜AICon 全球人工智能开发与应用大会

审核｜Kimmy

在生成式 AI 狂飙突进的当下，软件研发被公认为大模型落地最成熟的“试验田”。然而，当开发者试图将 AI Coding 从简单的代码补全推向深度的 Agent 协作时，现实的“海水”却比预想中冷峻：面对动辄几十万行、运行超过十年的存量复杂代码库，以及对稳定性要求极苛刻的生产环境，AI 往往显得力不从心。

作为 AI 落地浪潮中的先行者，百度如何看待当前 AI 编程“一半是火焰、一半是海水”的矛盾现状？当代码生成占比突破 70% 的临界点，研发团队的协作范式将发生怎样的质变？

本文基于百度资深研发工程师颜志杰在 2025 AICon 全球人工智能开发与应用大会·北京站上的演讲实录整理。他深度剖析了 Coding Agent 在企业级落地面临的三大硬核挑战——稳定性控制、人机协作边界、以及软件工程复杂度的转移。通过分享百度内部沉淀的“知识体系 + Rules 建设”、从“增强”到“重塑”的 DevOps 演进路径，以及以“Spec 驱动”为核心的 AI 原生研发模式，揭示了在 AI 时代，开发者应如何通过构建确定性的工程配套，跨越从工具到“研发数字员工”的代际鸿沟。

当然，需要看到的是，AI Coding 仍处于高速演化期。尤其在过去半年，以 harness、skill 为代表的一系列新实践不断涌现，部分问题已经出现新的解法路径。因此，本文更希望提供一个“问题框架”与“思考坐标”，建议结合具体业务场景进行批判性理解与实践落地。

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）

AI 编程的“冰火现状”

关于 AI Coding 在整个软件研发领域的现状，可用一句话概括：一半是火焰，一半是海水。行业内不乏令人振奋的消息——开发者借助大模型快速搭建应用并实现盈利，行业领袖也宣称模型能力已超越博士水平，整体呈现出对大模型的亢奋态势。

但实际落地中，若让 AI 对接已有 10 年历史的代码库，或是处理线上正在运行的存量代码，效果远未达到宣传中的理想状态。业界普遍倡导，只要掌握自然语言，就能具备与大模型交互的能力。但自然语言本身存在多义性，与模型交互实则需要一定技巧，尤其在线上严肃业务环境中落地，仍面临不小挑战。

在此，我引用斯坦福大学此前发布的一份研究报告，其中提出了一个二维分析框架：横轴区分 Greenfield（从 0 到 1 的新建场景）与 Brownfield（基于存量代码库的演进场景），纵轴则代表任务复杂度，由低至高梯度分布。从该框架不难看出，在存量代码库中处理高复杂度任务时，AI 的落地难度依旧较高。

我并非不看好 AI 在存量代码库或复杂任务场景中的应用。恰恰相反，AI 仍是一款极具潜力与能力的工具。只要方法得当，AI 在复杂工程环境中的应用前景依然值得期待。

结合百度在 AI 领域的落地实践，我们可观察到一些变化：

首先 AI 代码生成占比及其构成正经历深刻变革。2024 年，AI 代码生成占比约在 20% 至 30% 之间，且核心贡献来自基础的 “代码续写”。当时行业普遍预期，当采纳率攀升至 40% 左右，该指标将进入增长瓶颈，难以实现进一步突破。然而，随着 AI Agent 的快速落地，这一指标不仅持续攀升，增长斜率也显著提升。核心驱动力在于，由 Agent 主导的编程模式在整体代码构成中的占比稳步提升。

其次，具备行业影响力的 Coding Agent 产品正持续涌现。

从落地路径来看，Coding Agent 的应用场景已突破 IDE 的局限。尽管 IDE 仍是其最核心、最直接的应用载体，但市场实践已呈现出更为丰富的落地形态。用户已形成明确的付费意愿，愿意为 IDE 及各类编码助手产品直接付费。相关数据显示，在年度经常性收入突破 10 亿美元的企业中，有相当一部分来自编码助手赛道。

以 Cursor 为例，其 2024 年公开数据显示，用户规模已达约 30 万，年度经常性收入达 5 亿美元；与此同时，同类产品持续涌现并实现高速增长。除商业化收入的验证外，资本市场同样对该赛道表现出积极态度。以 Cursor 为代表的企业，当前估值已达约 300 亿美元。资本的持续投入与高估值认可，充分彰显了市场对 Coding Agent 领域长期价值与发展潜力的坚定信心。

此外，我近期更为关注的另一行业趋势是，多款具备行业影响力的 Web 形态 Coding Agent 产品正大量涌现。以 2024 年率先提出 “首个 AI 软件工程师” 概念的 Devin 为例，其创新的产品形态给行业留下了深刻印象。与此同时，GitHub 平台也呈现出明显的能力升级态势，其 DevOps 体系已逐步上线 AI 相关功能，针对简单 Bug 修复、Issue 处理等基础研发任务，可直接交由 AI 完成。这一突破打破了 AI 仅能在 IDE 内部使用的局限，让开发者得以在更广泛的研发流程中无缝调用 Agent 能力，使其直接参与研发任务的全流程执行。

近期，CodeX、Claude Code 等产品也迅速走红。不仅如此，在代码评审等研发高频场景中，一批深耕垂直领域的 Coding Agent 企业相继崛起。

第三个变化，当我们进一步将 Agent “拟人化”，赋予其类人身份，并允许其操作各类工具与平台时，会发现其可完成的任务范围大幅拓展。在我们内部，这种 Agent 形态被定义为 “研发数字员工”。

若进一步延伸，当 Agent 不再局限于个人助手、对话工具的定位，而是深度融入整个软件研发全流程，所带来的变革将更为显著。一套完整的研发流程，以用户需求为起点，需经历需求澄清、编码开发、测试验证等多个核心环节，构成一条完整的工作流。在这条工作流中，不同节点可由不同角色分工承接。

AI 能够从 DevOps 系统中获取需求卡片，从代码仓库拉取代码，触发并执行流水线作业，还可通过通信工具与人类工作人员实现高效交互，深度参与研发各环节。

在现有的工作模式中，各岗位角色分工极为精细，其核心前提是默认人类专业技能的门槛极高。因此，一项需求产生后，尤其是在大厂团队中，往往需要经过产品经理（PM）、用户体验设计师（UE）、前端开发（FE）、后端开发（RD）、运维（OP）及测试（QA）等多个角色流转推进。团队大量的时间与精力，并非消耗在核心的编码工作上，而是投入到沟通协作环节 —— 即信息传递与需求澄清的过程中。

但当 AI 深度介入后，各类研发工作的门槛将逐步降低。例如，在 AI 的辅助下，产品经理是否可直接输出设计稿，甚至完成部分简单的前端开发工作？或是前端团队无需维护庞大的代码库，仅依托 Node.js 实现前后端一体化，在完成前端开发的同时，同步完成后端开发与自我测试？实际上，小团队也能高效完成大规模的研发工作。

深水区的硬核挑战：稳定性、预期落差与复杂度转移

将 Coding Agent 落地到企业级场景，面临着诸多现实挑战。我们常提及的这片“海水”，其深度体现在多个层面。以百度的实践经验为例，我们将这些挑战总结为三个核心方面。

首先，是如何让 AI 输出稳定可控的效果。大模型本质上属于概率模型，其输出难以完全掌控。当 AI 进入生产环境，要求工程师在日常工作中持续使用时，若稳定性问题无法解决，用户极易对其产生不信任感，甚至觉得不如直接手动编写代码更为可靠。此外，AI 代码生成并非一次性任务，代码产出后仍需在真实业务环境中运行，并进行长期维护迭代。

因此，即便 AI 准确实现了某个功能点，在实际工程场景中，仍可能出现不符合原有代码规范、与工程整体调性不符的情况。例如，在既有 LIB 库已定义相关函数的前提下，AI 可能会自行新建函数，甚至新增额外文件来实现完全相同的功能。这种“过度发挥”的实现方式，虽然从功能层面来看可行，但从代码结构规整性与工程一致性角度而言并不合理，会大幅增加后续代码的理解与维护成本。

其次，源于当前行业对 AI 的整体预期处于高位亢奋状态。相关统计显示，在约 100 万亿 Token 的使用规模中，超过 50% 来自 AI 的生成或消耗，这一高占比在一定程度上放大了行业对 AI 能力的过度期待。在产品宣传与市场运营过程中，“AI 无所不能”的认知被普遍强化，导致用户初次尝试时往往抱有极高期待，试图通过一句自然语言指令，就让 AI 完成复杂的工程化实现。但在实际体验中，AI 很难稳定完成这类工程化要求极高的任务，这种预期与实际体验的落差，极易让用户产生 AI“能力不足”的认知，进而选择放弃使用。

此外，尽管业界长期倡导通过自然语言与模型交互，但在严肃的软件工程场景中，仅依赖自然语言远远不够，仍需掌握提示词设计、上下文组织、任务拆解及流程化协作等方法与技巧。这意味着，人机协同所需的工程能力建设，在 AI 实际落地过程中同样至关重要。

最后，是软件系统本身的复杂度，并不会因 AI 的引入而消失，而是发生了转移。随着 AI 参与代码生成的比例不断提升，人类在“编写代码”这一环节的投入或许会减少，但当系统中大量代码由 AI 生成时，新的关键课题随之出现：如何保障系统整体质量，如何在出现问题时快速定位并修复，这些都将成为企业需要重点攻克的核心难题。

构建确定性工程体系，跨越 80 分危机

在实际应用中，确保 AI 输出结果的稳定与可预期至关重要，以此避免其在不同场景下出现大幅波动。

百度的核心实践是，在组织层面大规模引入规则。这些规则本质上是工程规范与约束，相当于研发过程中的指导手册，明确了代码库应遵循的原则、约定及需规避的反模式。通过体系化沉淀与推广这些规则，可在一定程度上降低 AI 输出的不确定性，提升整体产出的一致性，进而缓解 AI 产出“不可控”的痛点。

鉴于规则编写存在较高专业门槛，难以要求所有参与者都能高质量制定规则，因此需通过合理分工协作解决这一问题：由具备丰富经验与科学方法论的少数专家，负责规则的设计、提炼与沉淀，让更多开发者无需投入额外精力，即可基于这些成熟规则，直接获取实际收益。

规则的构建可拆解为三个核心维度：一是 What，明确代码库的功能定义；二是 Where，指明核心模块与常见路径的分布；三是 How，规范具体的实现方式。例如，新增日志功能时，明确规定应使用的库、import 引入方式及记录规范；操作数据库时，约定必须通过特定数据访问层，禁止直接编写查询语句。

此外，规则建设应立足场景，而非一开始就构建覆盖所有场景的冗余体系。考虑到模型上下文空间有限，更合理的方式是按研发阶段拆分，例如在 Plan、Code 及 Review 阶段，分别加载对应的规则集。这种按需加载的机制，既能避免占用过多上下文资源，也能在各研发阶段发挥精准约束作用。在生产落地层面，我们借助智能化工具降低规则编写门槛，核心路径是“以 AI 生产规则”。

实践证明，通过与 AI 深度对话，引导其自主提炼、转化规则，效率远高于传统静态工具生成。为实现“专家定义、全员受益”的目标，我们将规则与代码库进行同源管理，并集成至 CI 流程，使规则正式成为工程资产的重要组成部分。

当代码库规模达到几十万行、包含数千个文件时，将全部代码一次性加载给 AI 并不现实。AI 本质上属于无状态服务，本次对话的上下文信息，在后续交互中很可能无法被有效保留。因此，推进记忆工程与知识工程建设显得尤为关键。

文件系统存储是当前最具落地性的方案之一：通过将知识库与代码库同源管理，借助规则明确告知 AI 在 Cursor 编写、Commit 提交等环节所需文档的具体位置与核心内容。由于 Agent 本身具备出色的文件系统检索能力，这一协同模式具备极高的实践可行性。

其次，也可引入图数据库作为补充方案。在图数据库的落地实践中，可按项目维度进行划分，即以单个项目为单位搭建独立的图数据库实例，在实例中沉淀该项目对应的前端、后端相关内容，以及基础规则与研发规范。其核心目标，是对项目相关知识进行统一归集管理，避免信息分散，使其在图数据库中形成完整的结构化体系。

在此基础上，AI 的实际应用效果将持续提升，呈现出更强的“智能性”。这一提升的核心驱动力，正是记忆工程体系的价值。当然，AI 效果的优化并非仅依赖模型本身，模型能力固然重要，但只要将知识工程与记忆工程搭建得足够完善，即便采用性能相对普通的模型，同样能够实现理想的应用效果。

尽管我们此前一直在探讨规则构建与记忆工程的高质量输入输出，但必须清醒认识到：模型本质是概率模型，要求其在所有场景下都输出 100% 确定的结果并不现实。因此，我们不应回避这一特性，反而需要更加重视以确定性为导向的工程化方法。

行业常见的典型 Agent 框架，是将任务直接交由模型自主决策，由其调用工具、结合记忆进行多轮循环直至完成任务。但这种模式更接近 Copilot 形态，本质属于推荐式机制，效果稳定性不足，整体成功率大致处于五五开的水平。因此在当前自动化落地场景中，我们更倾向于采用 Micro-Agent 方案：将确定性逻辑尽可能通过代码固化实现，仅在传统方式难以自动化的环节引入 AI，做小粒度、局部化的能力补强。

此外，部分场景容易陷入认知误区，认为必须采用大模型驱动的 Agent，依靠模型自主推理与任务规划才能体现 Agentic 能力。但事实上，对于流程明确、具备标准 SOP、重复性高且复杂度较低的任务，Workflow 编排模式并不过时。在这类场景下，App Builder、扣子、N8N、Rost 等工具，仍是更直接、高效且确定性更高的解决方案。

第三，在 IDE 编程场景中，必须强化对 AI 生成代码的测试与验证能力。模型的概率属性决定了，代码生成后即便经过 lint 检查、规则约束、代码评审与编译等多轮校验，最终效果也会远优于一次性生成结果。但即便使用顶尖模型搭配完备的规则体系，也难以实现 100% 确定性，往往十次执行中九次成功，仍可能出现一次异常。

因此在工程实践中，不能仅依赖模型本身，必须配套引入确定性工程方法，通过测试、校验、反馈闭环等机制，持续提升系统整体的可靠性与稳定性。

在现有模型能力下，哪些任务适合交由 AI 处理、哪些必须由人主导，行业内尚未形成一套标准化的“能力地图”作为参考。

但从实践中可以总结出一个普遍共识：应从小颗粒度、重复性任务入手，通过稳定的结果交付逐步建立信任。

结合百度内部的实践经验，我们可以从开发者视角，分享几个关于人机边界的核心认知。

首先，单文件级别的任务，现有模型基本可以胜任。若效果不佳，大概率是需求本身未梳理清晰。无论是生成函数、编写单元测试、添加注释，还是代码拆分，模型都能实现较为出色的效果；

其次，对于逻辑简单、与业务耦合度较低的任务，AI 同样具备较高的完成度。例如新增 API 接口、添加日志与监控等高频标准化工作，模型均可稳定执行

以 Comate 为例，该产品包含中英文两个版本。此前前端开发需要同步维护两套代码并手动翻译，流程琐碎且重复。我们通过规则体系搭建了类 Agent 自动化工具，实现了中英文代码的自动转换。如今开发者只需完成中文版本开发，运行 Agent 即可自动生成英文版本，这类任务已完全交由 AI 处理。

但在需求实现层面，尽管外界普遍认为 AI 可胜任从 0 到 1 的生成工作（如 Figma 转代码已有不错表现），可一旦涉及复杂需求，尤其是仅靠自然语言描述、缺乏详细 Spec 支撑或完整方法论的场景，AI 效果往往不尽如人意。任务层级越高、复杂度越深，AI 的处理能力反而会随之下降；

此外，开发者对人机边界的大量探索，仍依托于 DevOps 平台展开。DevOps 平台本身已定义了清晰的人机交互流程，且不少平台已集成 AI 能力。若 DevOps 平台持续迭代升级，人机协同的边界是否也会随之动态演进？基于此，我们提出一个核心问题：AI 在 DevOps 产品中应当如何落地？

我们的核心观点是：先做增强，再做重塑。

初期阶段，DevOps 平台应保留原有形态，尊重现有研发流程，优先聚焦高频通用场景进行能力补强。例如将 Code Review 环节独立出来，原先需要人工参与评审，现在可由 AI 先行辅助检查并给出评论，完成基础性赋能。对于单元测试、Debug 调试、API 管理等高频场景，同样先在现有流程中实现局部 AI 增强。

在此基础上，再针对垂直场景进行流程重塑。例如不少研发人员需耗费大量时间制作 BI 数据报表，在数据库基建完善后，便可通过 Web Coding 模式，让 AI 辅助用户根据需求自主高效生成报表。因此对于 DevOps 产品，我们的判断高度一致：先增强、后重塑，这是现阶段最稳妥、最具可行性的落地方法论，也是我们对人机协同边界的深度思考。

当前行业对 Agent 在研发领域的落地态度过于亢奋。大量宣传都在强调 AI 的能力与惊艳效果，却普遍忽略了底层工程体系建设。我们认为行业叙事逻辑需要转变：不应只强调“AI 能完成某项任务”，而应转变为“AI 能完成这项任务，但需要配套相应方法才能达成预期效果”。换言之，不仅要会使用工具，更要掌握用好工具的方法，在部分场景下为工具提供更充分的输入支撑，才能获得理想产出。

软件的复杂度不会消失，只会发生转移。随着 AI 生成代码的成本不断降低，若原有研发流程保持不变，代码验证的成本反而会同步攀升。例如，生成一百行代码或许仅需片刻，但要从其中定位并修复三行存在隐患的代码，往往需要耗费大量时间。因此，我们开始思考：现有敏捷开发流程是否还能最大化发挥 AI 的价值？并由此提出核心观点：在 AI 时代，工程能力不仅没有弱化，反而变得愈发重要。

在此，我推荐一种经过实践验证的最佳路径 ——Spec 模式。它并非某款工具的专属功能，而是一套能让 AI 最大化发挥效能的标准化流程。其核心要求是，开发者将原本用于编写代码的部分时间，专门用于与 AI 澄清需求 —— 这就像带新人一样，需先通过 Plan 明确逻辑、界定需求，再让其开展编码工作，并明确测试标准与方法。

这一流程的落地，依赖两大核心能力：一是知识工程的搭建与提示词技巧的掌握；二是代码与文档的同步更新。过去，让开发者主动更新文档、编写单元测试往往难度较大，但在 AI 驱动的流程中，AI 可自动完成文档更新与单测编写，实现流程化落地 —— 这种知识工程的顺畅流转，是 Spec 模式跑通的核心关键。与此同时，测试能力更是重中之重。大模型的概率属性决定了其存在 “80 分危机”—— 生成的内容看似合格，却始终存在细微偏差，难以达到工业级标准。

我们不能单纯依赖模型能力的提升，而应在 Spec 中明确固定的测试用例，让 AI 完成代码编写后自动执行测试，根据测试结果自我反思、迭代修正。只有经过测试 “守门” 的代码，在后续评审环节才能真正让人放心。

此外，软件工程能力的提升并非仅局限于研发领域，还可延伸至产品经理的 AI 原型搭建、运营等场景。要让 Code Agent 真正实现企业级落地，组织层面的宣导与氛围建设至关重要。在百度，我们通过技术学院将 AI 原生相关内容设为必修课，并借助 1024 工程师大会等平台展示实践成果，引导全员形成 “用好 AI 是专业能力、更是潮流” 的认知，让运用 AI 提效成为一种行业新风尚。

总结与展望

比尔·盖茨指出，人们常高估未来两年的变化，却低估未来十年的变革。当前，非专业场景的范式转型已然发生，而专业编码领域正在迎来拐点。Code Agent 的大规模落地并非简单的工具更迭，其背后需要极具深度的工程配套建设，以跨越稳定性保障、人机协同边界界定及工程能力重构等关键阻碍。

正如 19 世纪末伦敦街头的景象：初生的汽车冒着浓烟、步履蹒跚，甚至不及传统的马车迅捷。马车夫或许会嘲笑这一新兴物种的拙劣，但他并未意识到，全世界最聪明的头脑正致力于内燃机与流水线的技术攻关。当这些底层技术完成突破，时代的改写便成定局。百度始终秉持坚定的技术乐观主义。我们正致力于通过体系化的工程手段加速这一进程的到来，并已做好全面准备迎接这一时代。

发布于：北京