在2025年这个被许多人视为AI应用元年的时间节点，技术圈的喧嚣从未停歇。从Zui基础的代码补全，到如今热议的AI工程师，甚至是AI开发团队，概念层出不穷。然而当我们剥去那些光鲜亮丽的营销外衣，深入到企业级研发的肌理中时会发现真正的落地远比想象中复杂。这就好比那张经典的截图：远kan是一列火车即将超越骏马，象征着新技术的碾压之势；但拉近镜头一kan，却是马在拼命地拉着火车跑。这虽然是个玩笑，却精准地描绘了当下hen多企业落地AI的现状——朋友圈里各种炫酷，实际落地却需要大批“人马”在背后默默填坑。

有赞作为一家在SaaS领域深耕多年的公司，出于对技术趋势的敏锐嗅觉，我们在内部研发体系进行了大量的AI探索。这不仅仅是为了赶时髦，geng是为了解决传统研发模式中那些根深蒂固的痛点。今天我想抛开那些宏大的叙事，聊聊有赞是如何一步步将AI嵌入到研发全流程中的，以及我们在这一过程中踩过的坑和收获的经验。

一、 生产要素的变迁：从人力密集到算力驱动

在谈论具体技术之前，我们需要先厘清一个底层逻辑的变化。传统的软件研发，其生产要素无非是人力、技术和信息。核心逻辑非常简单粗暴：多招人，就Neng多Zuo项目，产出自然就高。但围绕“人”这个要素，问题也随之而来：好人才难招、新人培养周期长、人才流失风险大、个体情绪波动以及人与人之间低效的协作成本。

而这个逻辑正在被重写。人力开始向算力转移，增长逻辑变成了：购买geng多显卡，获取geng多算力，就Neng获得geng多产出。大部分重复性的体力工作正在向算力迁移，甚至部分脑力工作也Ke以沉淀到算力中，实现快速的规模化扩张。但这并不意味着人变得不重要了相反，人的角色发生了根本性的转变——从直接产出者，变成了对算力的设计与编排者。

随着编程工具的飞速发展，编程门槛被大幅降低，“氛围编程”开始兴起。这种模式让geng多非专业开发者Neng够专注于创意和结果，而不是纠结于语法细节。但这同时也带来了新的挑战：企业级工程规模庞大、系统复杂度极高，功Neng间的依赖关系错综复杂。当非专业人员面对生产环境的稳定性和海量线上用户的压力时心理负担会急剧增加。这种“严重缺乏安全感”的反馈，我们Zui初是从一位尝试用AI交付交互式PRD的产品经理那里听到的。这本质上是一种判断力的缺失。

二、 AI Coding：构建虚拟开发团队

在有赞的实践中，我们将AI落地划分为了三个阶段：AI增强阶段、AI驱动阶段以及AI自主阶段。目前，我们的大量实践集中在AI增强阶段，并正在向AI驱动阶段迈进。

在AI Coding的设计路线上，我们曾面临两个选择：是以人为主、Agent为辅，还是以Agent为主、人监督？经过初步的观察和尝试，我们发现以人为主的模式存在明显弊端：判断力缺失导致效率不可持续，开发者需要频繁地与AI沟通确认，编程的耗时被极大地转换成了沟通确认的耗时Zui终效率不升反降。因此，我们选择了第二条路线——以Agent为主、人监督。虽然这条路起步难，但其“天花板”geng高，且Neng系统化解决效率、质量和心理负担的问题。

1. 打造专业的Agent个体

构建一个Coding Agent，就像是从0到1搭建一个开发团队。通用AI Agent和计算机非常相似：它们dou有计算单元，dou有短期存储，dou需要获取外部信息，dou需要好用的工具，并且dou由专业的个体组成，Neng高效协同完成复杂任务。

基于此，我们选择了Claude Code作为基础Agent的底座。为什么是它？因为在子Agent调度、MCP集成、通用开发工具以及上下文压缩方面它Yi经Zuo得相当不错。我们通过其强大的 Neng力，将其连接到有赞内部的研发体系。同时我们为每个AgentZuo了差异化的基模选择，根据任务特点、LLM的优劣势以及成本来匹配Zui合适的模型。例如需求解析和仓库定位这种相对简单的任务，我们会用GPT-4o；代码审查则用Gemini 2.0，因为它拥有geng大的上下文窗口；而方案和编码则倾向于Claude 3.5 Sonnet，其中记忆功Neng用GPT-4o效果尤为出色。

2. 赋予Agent“记忆”与“知识”

仅仅有底座是不够的，Agent还需要理解业务知识和技术规范。我们发现，过往企业知识库建设存在两大痛点：信息孤岛和内容老旧。

为此，我们为Agent打造了基于长期记忆的学习系统。记忆的存储采用自然语言加标签的形式，而非结构化存储，并保留了原文引用。记忆提取阶段重点关注符合事实、保留细节、不归纳泛化；记忆检索则采用向量数据库；随着记忆数量增加，还会根据时间和频次进行遗忘，高频使用的记忆在泛化后会转化为知识。

此外算法团队也Zuo了大量建设，让业务团队Neng聚焦在微调数据集上。一条微调数据包括Instruction、Input、Output。我们通过脚本抓取线上原始样本作为正样本，再通过程序合成多个负样本，结合特定的Prompt来生成Output。通过指令微调和思维链微调，我们让LLM具备了geng细化的任务定义、明确的输出格式以及内部评判标准。

3. 解决代码理解与工具集成

代码理解是Coding Agent的关键Neng力。业内常见的方案有向量索引检索、抽象语法树、文本搜索以及预生成文档。Cursor选择RAG方案，速度快但精度有丢失且实时性不高；Claude Code则选择纯粹的文本搜索，像人一样阅读代码，精度高、实时性强，但性Neng稍差。

在有赞，我们将代码理解分为三层：目标仓库定位、跨仓库依赖代码召回和工作区代码理解。目标仓库定位使用知识库RAG；跨仓库依赖代码由于仓库数量庞大，采用RAG方案并基于Git提交记录进行增量geng新；工作区代码理解则直接利用Claude Code的文本搜索Neng力。同时代码安全至关重要，所有发送给模型的代码片段dou经过安全扫描脱敏。

在工具集成方面我们通过MCP将散落在内部各系统、平台的工具集成起来交由Agent决策使用。比如访问需求管理平台、创建飞书文档技术方案等。

4. 云端Sandbox与部署发布

Agent构建完成后需要一个运行环境。我们选择了云端部署方案，为每次会话分配独立且标准化的沙箱，其中包含完整的开发环境，以实现交付结果预览。同时我们对会话及沙箱Zuo了无状态化，实现水平扩容。会话存储在共享存储中，当开发者开启或继续会话时动态分配随机沙箱并恢复状态。

Zui后通过部署发布Agent，我们打通了发布系统。现在通过对话就Ke以hen方便地将代码部署到预发环境，甚至直接发布至生产环境。有个比较有意思的小插曲：一位开发同学出去聚餐没带电脑，这时来了个紧急Bug。他掏出手机，打开飞书唤起Agent，把Jira链接和说明丢过去，然后就让Agent先改着，自己先吃饭了。过了几分钟，Agent改完了他kan没问题就直接发布了。这虽然是个小案例，但确实让我们kan到了AI正在慢慢改变编程方式。

三、 AI Test：重塑质量保障体系

编码效率的提升对测试效率提出了geng高的要求。同时由于AI生成代码的不确定性，影响面和风险geng大，给测试带来了新挑战。传统测试面临技术栈多样化、设备终端碎片化、工程规模增大等问题，而自动化测试虽然引入了一段时间，但也存在编写门槛高、维护成本高、难 复用、失败排查困难等局限。

1. 自然语言用例：打破隔阂

过往历史用例缺乏维护，质量参差不齐，存在各种隐式步骤和断言缺失，且文本用例和自动化用例互不相通。我们开始思考如何解决这个问题，发现LLM强大的自然语言理解Neng力让传统文本用例和自动化用例的融合成为可Neng，也就是“自然语言用例”。这种用例兼具语意性和可执行性，所有自然语言用例放在一起，本身就是一个高质量的测试知识库。

我们探索了两个方向：AI存量用例优化和AI增量用例生成。对于存量用例，由LLM根据测试目标和步骤生成geng规范的用例名、标签，优化步骤并补充断言。对于增量用例，则结合业务知识库并参考现有用例进行生成。一个新的用例生成过程分为三步：填写基本信息、选择参考用例、LLM生成基础信息及完整的自然语言测试步骤。

2. AI执行与归因：从“人找原因”到“AI找原因”

有了用例，接下来是执行。目前我们的用例执行统一注册到任务中心，由其下发到两大集群，分别执行浏览器任务和App任务。日执行量超过每天10万次任务成功率达到98%。

当用例执行失败后过往需要人工分析，效率极低。我们通过AI来提速这个过程： 由LLM将单个失败核心原因，然后将类似原因分组归类。具体流程是：程序预处理，然后切片交给图片归因Agent、步骤归因Agent进行并发分析，再由Agent合并原因，Zui后由归类Agent对类似用例分组。目前线上用例Yi100%覆盖AI归因归类，归因准确率85%。人工分析100条失败用例需要15分钟，AI仅需1分钟。

3. 挑战与突破：精度、速度与幻觉

在AI测试落地中，我们也遇到了模型执行速度慢、幻觉和识别精度问题。

为了解决“模型识别精确问题”，我们测试了多个主流端。发现Qwen-vl-max对小图标识别Neng力较差，UI-TARS在元素定位精度和移动端表现较好，因此成为我们的选型。

为了解决“模型执行速度慢”，我们Zuo了基于图像和Prompt的识别缓存。未命中缓存时AI指令的秒级与程序指令的百毫秒级差距依然hen大。因此我们Zuo了AI提速：用例解析后 程序执行，失败时AI兜底执行，成功后由AI自愈并提取信息geng新程序脚本。

为了解决“模型幻觉问题”，通过LLM二次优化步骤Prompt，并采用geng准确的AI指令基本Ke以解决。

此外我们还在探索AI无参考测试和AI用例修复。既然归因dou知道了原因，何不让LLM自己修复？目前主要针对像素差异率波动、非核心元素变化的场景实现了修复，准确率90%。

四、 人机协作：监督与信任的建立

整个Agent系统的运行离不开“人工监督”。我们面向开发者和管理者分别设计了两套监督系统。

面向开发者的监督系统基于飞书IM，利用其天然的对话流特性，结合飞书文档和GitLab。开发者Ke以在Agent的每个阶段对产物进行审核，包括需求清单、技术方案、改动代码、实际效果等，并通过多轮对话进行修正。对话明细Ke以转化为评测集，用于后续Agent的评测。

面向管理者的监督系统则基于多维表格及其仪表盘。管理者对每个需求的情况一目了然包括交付率、对话轮次、Token消耗、对话明细等。

五、 ：循序渐进，拥抱未来

回顾这一路走来我们深刻体会到，AI的落地无法一蹴而就，需要循序渐进。对于不同的场景，应该匹配适合的阶段，过度追求AI反而会适得其反。我们踩过不少坑，也积累了一些经验。

比如我们发现有两类需求特别适合AIZuo：一是“翻译型任务”，Yi有明确方案且较为简单，如技术债务治理；二是“跨域编程”，过往跨团队支援的学习时间被AI抹平。有一个基础库升级的案例，涉及基础库、业务库和23个业务应用，原本需要超过50人日通过AI几十分钟就完成了。

当然我们也必须清醒地认识到，AI不是万Neng的，人Zuo不了的它也Zuo不了。在推广到兄弟团队时我们发现大家对AI期望过高，给了它hen多非常有挑战的需求，结果往往不尽如人意。

目前，我们的AI CodingYi经Ke以实现单职Neng多仓库的日常需求，Yi交付近百个需求，综合提效30%，包括人工监督的耗时单个需求Token费用不到0.5元人民币。接下来我们会重点向多职Neng多仓库、项目级需求两个方向迭代。

硅谷的大厂一边裁员，一边争相购买显卡，这或许就是未来的缩影。虽然现在kan起来像是“马拉火车”，但我们坚信，Zui终火车一定会超越马，亦或，马拉火车的方式本身就错了。在这个过程中，Zuo的越多越容易陷入追赶的局面Zui大程度地借助行业Neng力，并将其与企业内部资源串联，才是关键。这就是有赞在AI研发全流程落地实践中的一点思考与。

---