作者 | 付永生，阿里巴巴 / 高级技术专家

审核｜罗燕珊

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

AI 编码不是一个新话题，业界已有诸多实践，如外部的 cursor、GitHub Copilot、Bolt.new、Cline，以及内部的 Oneday、Weavefox 等等一系列的平台或工具，都提供了 AI 辅助编码的能力，但这些平台工具与现有的生产链路如何结合还存在极大的挑战：一是没办法很好的和现有研发流程进行集成，二是协作过程碎片化，有一定门槛。

本文整理自阿里巴巴高级技术专家付永生 6 月份在 AICon 2025 北京站的分享 《R2C Agent 打破 AI 辅助开发碎片化困境》。本次演讲从阿里业务研发场景出发，并结合真实的业务应用，阐述 R2C（requirement 2 code）Agent 如何从“知识库 + 钉钉文档 + 设计稿” 驱动整个研发链路，带来系统性的效率提升，并分享其中的最佳实践。

12 月 19～20 日的 AICon 北京站 将以 “探索 AI 应用边界” 为主题，聚焦企业级 Agent 落地、上下文工程、AI 产品创新等多个热门方向，围绕企业如何通过大模型提升研发与业务运营效率的实际应用案例，邀请来自头部企业、大厂以及明星创业公司的专家，带来一线的大模型实践经验和前沿洞察。一起探索 AI 应用的更多可能，发掘 AI 驱动业务增长的新路径！

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

随着人工智能技术的兴起，市面上涌现出许多面向编程的工具和平台，但这些工具的实际效果参差不齐，真假难辨。唯有亲身实践、深入其中，才能真正积累经验，获得切实的体验。在过去的一年多里，我们团队在面向客户需求的 AI 解决方案方面积累了丰富的经验。然而，针对编程这一我们自身工作的核心领域，却始终没有找到令人满意的现成方案。因此，我们决定自行探索，提出并实践了一套适合自身需求的解决方案，以更好地利用 AI 技术提升工作效率。

我希望与大家分享我们在这个过程中所积累的经验和教训。作为基础设施的使用者，我们将探讨如何更有效地使用这些工具，如何判断使用效果，以及在实践过程中遇到的挑战与反思。希望通过我们的分享，能够为大家提供一些有价值的参考和启发。

Al 编程赛道火爆背后

我想分享一下我对当前 AI 编程领域持续火爆的理解。在我看来，这个领域之所以如此火热，本质上是因为有大量资本愿意投入其中。资本的大规模投入必然有其内在逻辑，这一点从公开报道中也能得到印证。我思考了很长时间，认为这一切的源头在于大模型技术的兴起。虽然大模型提出了一种全新的可能性，但长期以来，人们并未找到理想的解决方案。直到去年 Claude 3.5 的出现，才从底层能力上带来了突破性的进展，让人们看到了新的范式就在眼前。因此，我们可以看到包括 Cursor 在内的许多工具都在那个阶段获得了全新的能力，而这些能力的提升都源于大模型的进步。

我们所做的事情应当避免那些容易被颠覆的方向。举个例子，如果你花费一年时间开发一个平台或产品，但突然出现一个突破性的大模型，那么你之前的很多努力可能会被颠覆。我并不是说这些努力没有价值，而是强调这个领域的发展速度非常快。因此，我们必须明确自身的边界和定位。在听取其他平台的分享时，我会带着这样的逻辑去理解：虽然你目前的进步可能是 1% 或 5%，看起来也很显著，但你的定位是否准确？要知道，大模型的提升可不是 1% 或 5%，而是可能达到 500%。为什么演示时看似完美无缺，实际落地却表现不佳？因为在真实场景中，没有“重来一次”的机会，也没有人能替你兜底。

在我看来，编程场景天然适合 AI 的应用。全球至少有 4000 万的高频用户，他们每天依赖编程工作。如果你能覆盖其中 10% 的用户，那就是 400 万的真实活跃用户。他们每天通过 token 消费，这个市场规模是非常可观的。因此，这些判断构成了整个行业持续投入的最大驱动力。

最近，Andrej Karpathy 分享了他对软件定义的看法，但我认为每个人的理解都不尽相同。我们可以听取他的观点，但不必完全受其影响。他的思考确实引发了行业对 AI 编程未来演进方向的深入思考，但他的判断是否准确，还需要持续观察。

我们在过去一年多时间里，一直在思考和解决这个命题。这个过程可以大致分为几个阶段：最初，代码补全是最常用的功能；随后，出现了将设计稿直接转换为前端代码的功能；我们真正想要实现的，是第三阶段：无论需求是什么，也无论想法如何变化，我都希望大模型能够按照我的设想，将完整的功能开发出来，并推动项目进展到预期阶段。这也是我们探索的起点。

工程师 AI 编程“困境”

工程师的日常工作其实是高度碎片化的。作为真正使用 AI 工具进行开发的用户，我们一线工程师实际用于编码的时间，据我估算，可能只占全部工作时间的 30% 到 40%。除了编写代码，我们还需要理解现有代码、编写单元测试、设计新功能等等，这些工作往往并不为外人所见。此外，一线开发工作并非单打独斗，任何一个项目通常都需要前端、后端、设计师、产品经理等多个角色共同参与。在这种情况下，如果只是单点地引入 AI 工具，往往难以取得理想的效果。

我们希望从端到端的角度来理解和解决整个研发流程的问题。我们的目标是，无论使用哪个平台，都能够实现对整个研发过程的端到端支持。当涉及多个角色时，必然会形成完整的流程。下图是一位资深前端开发者在 GitHub 上分享的工作流程，这个过程就像一条流水线，非常漫长。如果 AI 只参与其中某一个环节，即使在这个环节表现出色，一旦放到整个流程中，其带来的收益也可能被大大稀释。换句话说，它可能只解决了局部问题，而无法解决全局性问题。

当然，这是一个必经的过程。目前的开发平台和 AI 工具所处的阶段，很像十多年前互联网刚刚兴起时的基础设施不完善时期。在这个阶段，必然会催生出新的基础设施。然而，就目前而言，整体效果仍然参差不齐。因此，AI 工具的用户或团队必须深入其中，才能找到最适合自身团队的问题点和解决方案。

R2C 解决方案新思路

我们提出的新思路是端到端的解决方案。无论是用户提出的需求，还是我们自己想要实现的功能，无论项目规模大小，我们都希望找到一种更高效的方式来完成。传统的辅助代码生成、一次性代码生成等工具仍然会在过程中发挥作用，但我们更关注的是如何构建一个完整的流程。

我们希望将任何需求或想法转化为一种描述性的表达，通过文档或其他载体清晰地呈现出来。我们的 AI 提案正是为了实现这种端到端的开发流程而设计的。在最终的开发阶段，AI 将在代码审核和集成过程中发挥重要的协同作用。

我们不仅提出理念，更注重将其付诸实践。因此，我们更加关注如何真正理解并落地这种端到端的解决方案。我们希望它成为一个整体性的方案，无论使用何种开发工具，都能贯穿需求分析、设计、编码、测试等整个流程。AI 能够渗透到哪个环节，最终取决于整个方案所能带来的实际效果。

在流程串联中，领域知识库的构建也至关重要。每个开发团队所面对的内容、需求和产品，都有其独特的领域积累。我们还需要实现自动化的流程衔接，并确保用户体验的一致性。事实上，一致性体验是我们最初也是最重要的追求。考虑到每位开发人员可能使用不同的 IDE，在编译过程中可能需要复制代码，以及前端、后端、测试等环节所使用的平台各不相同，我们希望通过统一的解决方案，为所有参与者提供一致且流畅的开发体验。

框架、实施和进展

在实施过程中，我们逐渐形成了一套清晰的框架，也遇到了一些值得分享的问题。我们内部称之为“R2C Agent”，它代表了我们目前对这件事的整体理解。简单来说，这个框架的核心在于将各类输入统一到一个中间层，包括 MRD、PRD、技术方案、接口测试用例、视觉稿、交互稿等。这些输入的形式，无论是标准化文档还是视觉理解，本质上都反映了我们团队或所在领域对项目的规范和理解。

我们将整个端到端的解决方案抽象为两个关键要素：提示词和上下文。中间层的构建，正是为了确保在这两个方面保持一致性和可理解性，从而让整个流程更加顺畅。我们主要关注四个方面：领域知识库、项目文档、设计稿，以及它们的结构化表达。这些文档可以是结构化的，也可以是非结构化的，但必须是 AI 易于理解的。

在最初“手搓”阶段，我们并没有完善的基础设施支持，因此我们选择在 VSCode 中开发了一个插件形式的 Agent。我们的需求文档通常存储在钉钉文档、语雀或 Word 中，Agent 通过类似 RPA 的方式调用浏览器读取这些文档内容，作为整个集成链路的起点。这种方式也解决了权限和内容可读性的问题，只要开发者有权限，Agent 就能访问相应文档。未来，当基础设施更加完善后，这一过程可以进一步简化。

目前，我们的核心输入主要包括需求文档和设计稿。设计稿可以是设计师手工完成的，也可以由 AI 生成，只要具备足够的确定性即可。沿着这个思路，我们将设计稿转化为设计元素的语义表达，这种表达方式已经相对成熟，能够被大模型较好地理解。

我们在 5 月中旬上线了 1.0 版本，按照上述思路实现了从交互稿、视觉稿到技术方案、接口文档、测试用例的完整流程。前端代码的还原度已经非常高，不仅包括视觉还原，还包括基于接口和技术文档的集成工作。前端工程师的工作几乎只剩下“填空”，整体流程已经具备较高的实用性。

在实践过程中我们也经历了一些“翻车”时刻。最初我们尝试完全依赖 AI 生成技术文档，但效果并不理想。后来我们意识到，如果由工程师自己将需求转化为 AI 友好的技术文档，整体效率和准确率会显著提升。也就是说，无论是前端、后端还是测试工程师，只要你能清晰地描述项目需求，AI 就能更准确地生成所需内容。我们验证发现，这种方式不仅适用于单个环节，也能显著提升整个流程的效果。

在实现层面，我们采用了 MCP 服务，并发布了自己的 MCP 服务以提供整体能力。通过定义 workflow，我们将需求文档、接口文档、技术文档、业务知识库和视觉库等输入组织起来，形成可迭代的开发流程。这种方式既能利用现有工具的能力，也能随着大模型的进步持续优化。关键在于如何规范需求、接口和技术文档的描述。根据我们的经验，只要需求文档写得足够清晰，达到评审时可被团队理解的程度，大模型就能较好地处理。

在定制过程中，我们重点关注三个方面。首先是上下文窗口管理。我们不希望一次性将所有信息都输入给大模型，而是只提供项目所需的关键内容，以避免信息过载和生成无关内容。其次实现主任务、子任务独立运行。最后是主任务负责管理、子任务负责实施。我们采用类似多 Agent 的思路，但在实际项目中，一个 workflow 可能会涉及大量上下文，因此我们更倾向于将任务拆分为子任务，由一个主 Agent 统一协调执行。这样做的好处是，每个子任务都是确定性的，不需要 Agent 进行额外规划，从而避免失控。我们认为，Agent 并非万能，对于确定性任务，明确指令比自由发挥更有效。

我们在内部多个项目中验证了这一方案的有效性。在前端开发中，代码采纳率和覆盖率已经达到较高水平，甚至包括常规业务逻辑的处理也表现出色。整体开发效率和成本都有显著改善。需求一旦明确，当天晚上就能看到初步效果，大大缩短了沟通周期。虽然这还不是完整的端到端流程，但已经展现出明显的效率提升。

关于后端代码生成，很多人持怀疑态度，认为 AI 难以胜任。但实际上，问题不在于 AI 的能力，而在于我们对其缺乏信心。我们验证发现，AI 在这些场景中并不存在本质障碍。编程是一个确定性过程，AI 生成的代码虽然不是唯一解，但可以从整体角度优化系统效果，往往比局部优化更具价值。以服务端开发为例，只要明确接口定义和领域模型，AI 就能生成高质量代码。我们并不追求一步到位，而是希望 AI 生成的代码能大幅减少人工工作量，让工程师专注于“填空”和优化。

在工程实施方面，最关键的是文档管理。所有输入都依赖于文档，因此如何组织和管理文档，将直接影响整个链路的实现效果。每个团队都有自己的编程规范和需求文档格式，这些都需要文档化。如果你已经有一个运行多年的系统，也可以让 AI 理解现有代码结构，并生成相应的文档，反哺知识库。从设计信息和文档信息入手，是构建高效 AI 开发流程的关键起点。

AI DEV vs AI CODING

在完整的开发链路中，时间的分布其实是高度碎片化的，每个环节都紧密相连。AI 并不会颠覆这一流程，因为软件开发本身的流程是合理的，AI 的作用在于加快进度、提升效率，并改变某些环节的执行方式。真正的开发过程涉及多个阶段，包括系统集成和测试等。目前市面上所谓的 AI 编程工具或脚手架，只有与现有的工作流程结合，才能发挥最大效用，否则只会加剧碎片化。

碎片化带来的唯一好处，是可能让团队中的一部分人脱颖而出，使用 AI 更熟练的人表现会更出色。但这种个体的优秀并不会带来团队整体质的飞跃，团队层面的提升需要更系统的理解和方法。

系统工程的核心始终是追求效率和质量，沿着这个方向推进是没有问题的。关键在于人的协作如何发挥作用。最值得分享的是，AI 在理解和响应人类输入方面表现出色。我们围绕文档和流程所做的工作，正是基于这一点。无论处于哪个环节，只要你的工作对 AI 友好，就能在端到端的集成方案中发挥作用。人在整个过程中扮演的角色，是将现实世界的理解转化为 AI 能够更好理解的形式。

未来展望

下图展示的是我们前端开发中的一个关键环节，称为 C2C（Component to Code，组件到代码）。在前端开发中，我们会积累大量组件和能力，并将需求拆解为多个模块。最核心的优势在于，凡是曾经写过的代码和组件，都可以被高效、准确地复用。从我们目前的前端实践来看，大约 60% 到 70% 的开发工作已经能够得到高质量的保障。

虽然行业内已有不少类似的做法，但据我观察，目前还没有哪个平台能够真正做到“只需提出需求，其余全部自动化完成”。要想真正享受到 AI 带来的成果，无论是个人还是团队，都必须亲自下场实践，亲手去用、去感受。这也是我们持续推动最佳实践的原因——只有在实际使用过程中，才能不断加深理解，持续优化流程。

我们始终在推进的目标，是在端到端的交付流程中不断提升 AI 的渗透率。我们设定了 50% 的目标，但很快就会突破这个数字。目前，在 R2C 的各个环节中，无论是前端、后端还是测试，AI 生成内容的采纳率已经超过 50%。我们的思路是将开发工作逐步转化为“填空题”——AI 完成大部分内容，开发者只需补充关键部分。一旦进入这种迭代模式，整个流程会不断收敛，效率也会持续提升。