有赞AI研发全流程实战指南：企业级软件工程中的落地与避坑

AI 时代的研发变革

AI编程浪潮

可以说，当前是 AI 应用爆发的元年。在编程领域，从基础的代码补全到辅助编程，再到 AI 工程师乃至 AI 开发团队，新概念层出不穷。

编程工具也在快速迭代，从老牌的 Github Copilot 到现象级的 Cursor，再到 Claude Code 和最新涌现的 Codex。

对应的用户规模呈爆发式增长：Github Copilot 用户超 2000 万，Cursor 用户超 230 万，Claude Code 在短短 3 个月内用户增长了 10 倍。从商业价值看，Github Copilot 年度 ARR 超过 3 亿美元，而 Cursor 和 Claude Code 都超过了 5 亿美元。

随着编程工具的进化，编程门槛被大幅降低。氛围编程（Vide Coding）开始兴起，让更多非专业开发者能够专注于创意和结果实现。

在有赞内部，已有产品同学开始尝试用代码交付交互式的产品需求文档，这在一些创新型项目中甚至成为第一版代码的来源。

AI对企业研发的深层影响

我们开始深入思考：AI 究竟给企业研发带来了什么？

传统软件研发的生产要素由人力、技术和信息构成，其核心增长逻辑是“多招人，就能多做项目，就有更多产出”。围绕“人”这一要素，存在一系列固有难题：优秀人才难招、新人需要培养、人才会流失、个体能动性差异、以及人与人之间的协作效率瓶颈。

AI 时代，生产要素开始从“人力”向“算力”转移。增长逻辑转变为“多获取算力，就能有更多产出”。大量重复性、体力型的编码工作向算力迁移，部分模式化的脑力工作则可沉淀到算力中，算力具备快速复制和扩展的优势。

近期一些新闻也印证了这一点：硅谷大厂一边进行人员优化，一边争相采购显卡。

在这一过程中，人的角色从直接产出者，转变为对算力的设计与编排者。

这里借用电影《让子弹飞》中一张意味深长的截图。远看是火车即将超越马车，近看却是马在拉着火车前进。这与我们当前落地 AI 的处境有些相似：外界看起来“热火朝天”，但实际落地仍需投入大量人力。

但这意味着“火车”不如“马”吗？显然不是。我们都清楚，最终火车一定会超越马车。或者说，用“马拉火车”这种方式本身可能就是错误的。我们需要找到正确的驱动方式。

有赞研发的AI+实践

基于对 AI 趋势的坚定看好，在有赞研发体系内，我们开展了大量 AI 探索与实践。

这些实践横跨了软件研发的完整流程，涵盖需求、设计、编码、测试、上线的各个阶段。总体上，可以归纳为三大方向：AI Coding、AI Test，以及围绕 Agent 本身的研发与评测工作。

AI探索初期的两个故事

在 AI 探索初期，我们遇到了两个颇具启发性的小案例。

一位产品经理的氛围编程初体验

第一个故事关于一位尝试用氛围编程完成简单日常需求的产品同学。他反馈的最大感受是：严重缺乏安全感。

深入沟通后，我们发现这种不安全感主要源于三点：

• 心理上难以接受：企业级工程规模庞大、系统复杂、依赖关系深。非专业人员面对生产环境稳定性和海量线上用户时，心理负担陡增，本质上是专业判断力的缺失。
• 效率上不可持续：判断力的缺失导致效率不可持续。他需要频繁与开发者沟通确认，氛围编程变成了在 AI 和开发者之间传递信息的“传声筒”。编程耗时被极大转化成了沟通耗时，最终效率不升反降。
• 质量上不可信赖：虽然 AI 做出的功能效果正确，但实现方案可能不合理，导致后期返工。现代企业级软件工程，除了完成功能需求，还需考虑健壮性、可维护性、架构一致性等。AI 由于缺乏足够的工程上下文，在这方面往往表现不佳。

一位开发者带领的“编程团队”

第二个故事发生在五月 Claude Code 发布后。我们观察到一些开发者的编程模式发生了变化。下图是一位同学使用的 CLI 工具界面：

左侧是 4 个 AI Agent 分别处理一个项目的 4 个子需求，右侧则是他在验证和提交代码。

这种模式类似一位技术负责人带领一个小型团队做项目，由负责人进行任务拆分、方案设计、过程把控和代码审查。过去需要几个人协作完成的工作，现在一位开发者加上多个 AI Agent 就能实现。

这给了我们很大启发，开始思考如何将这种高效的人机协作模式推广到更多项目中。

企业级软件工程的四大核心挑战

经过初步观察与实践，我们总结了 AI Coding 在企业落地需要解决的关键问题，归纳为以下四点：

• 大规模：对 LLM 的多仓库理解能力、上下文窗口长度提出了极高要求。
• 高复杂：通常涉及多个业务系统、历史兼容性等问题，需要解决 LLM 的注意力缺失、准确率与召回率低的问题。
• 多协作：一个项目往往涉及多职能、多部门的协作。不同团队对 AI 的理解和应用深浅不一，如何协同？人在哪些环节、以何种力度监督 AI？需要合理规划 AI 落地的节奏和人机协作模式。
• 私有化：企业内部有大量分散、不透明、非标准化的信息，难以被 AI 有效检索和利用，需要建设内部知识库并打通内部工具链。

AI落地的三个阶段演进

明确关键问题后，我们将 AI 落地划分为循序渐进的三个阶段：

• AI 增强阶段：人主导，AI 辅助。此阶段重点聚焦利用 AI 实现单点提效。
• AI 驱动阶段：AI 主导，人监督。此阶段 AI 有能力接管单一的研发环节。
• AI 自主阶段：AI 自主完成，人仅需少量介入。

对于不同场景，应该匹配适合的发展阶段。过度追求“全自动”往往适得其反，我们曾踩过不少坑。AI 的落地无法一蹴而就，需要循序渐进。目前，我们的实践大多处于 AI 增强阶段，少数场景达到了 AI 驱动阶段。

AI Coding：从个人助手到规模协同

核心设计路线的选择

关于 AI Coding 的设计路线，我们面临两个选择：以人为主、Agent 为辅；或以 Agent 为主、人进行监督。

我们观察了开发者的辅助编程模式，发现“以人为主”的模式存在一些局限：

• 协作仍以人为中心，沟通靠声音，工具调用靠手速，信息传递效率低。
• 个人经验内化后无法共享，Agent 配置分散，形成信息孤岛。
• 人的规模化需要时间，扩张速度受限制。

因此，我们选择了第二条路线。它能够系统化地解决以上三个问题，并且具备更高的“天花板”。

构建 Coding Agent 框架

明确了设计路线，我们开始构建 Coding Agent。这个过程类似于从零到一搭建一个开发团队：

• 都需要好用的工具（硬件、软件、技术选型）。
• 都由专业的个体（开发者/Agent）组成。
• 这些个体需要能高效协同，以完成复杂任务。

让我们先从设计一个专业的 Agent 开始。

Agent 架构的设计演进

通用 AI Agent 与计算机系统在架构上有着有趣的相似性：

• 都有计算单元（CPU / LLM）。
• 都有短期存储（内存 / 上下文）。
• 都需要获取外部信息（网络 / 搜索工具）。
• 都可以通过多节点协同完成复杂任务。

当我们将通用 AI Agent 具体化为 Coding Agent 时，各模块的选型会更加聚焦：

• LLM：需要选用垂直领域的编程专用模型。
• 上下文：需要引入企业的开发规范与特定约束。
• 长期存储：需要对接企业内部知识库。
• 搜索工具：聚焦于代码仓库的搜索与理解。
• 工具链：需要对接企业内部的研发工具和平台。
• 协同系统：拆分方式应参考企业内部的协作流程或领域分工。

技术选型与自研策略

明确了核心模块，首先要回答两个问题：技术方案如何选型？哪些部分需要自研？ 在 AI 时代，行业解决方案百花齐放，迭代速度极快，例如近期的 Gemini 3、Nano Banana Pro。 做得越多，越容易陷入疲于追赶的局面。最大程度借助行业成熟能力，并将其与企业内部资源串联，是关键所在。 我们的核心策略是：将通用能力交给行业，集中资源攻坚私有化部分，通过行业的快速迭代来持续提升底层能力。

基础 Agent 与系统提示词

明确了策略，首先是基础模型的选择。年初我们基本达成共识：LLM 应该交给大厂，我们专注于应用层。 到了 5 月份，我们发现 Agent 系统层面也有了不少优秀的行业实践。因此问题演变为：是选择基础模型，还是选择基础 Agent？ 即，选 Claude 还是 Claude Code？ 围绕这个问题进行研究后，我们发现 Claude Code 作为通用编程 Agent，在子 Agent 调度、MCP（Model Context Protocol）集成、通用开发工具、上下文压缩等方面已经做得相当不错。 因此，我们选择 Claude Code 作为基础 Agent 的底座，利用其强大的扩展能力，将其连接到我们内部的研发体系。 首先是系统提示词。这方面 Claude Code 的基础已经很好，我们仅做了少量扩展，总计不到 200 行，主要是补充内部的编程规范和特定约束。

开发工具集成

和人一样，Agent 也需要开发工具。例如，当开发者让它参考某个历史需求时，它需要能访问需求管理平台查看详情；或者，它可以通过飞书文档创建一篇技术方案供开发者审阅。 这些工具散落在内部各个系统和平台，有些则在外部。我们通过 MCP 协议将这些工具集成起来，交由 Agent 根据上下文决策使用。

代码库搜索与理解

有了工具，接下来是代码理解能力，这是 Coding Agent 的关键能力之一。 我们将其分为三层：目标仓库定位、跨仓库依赖代码召回、工作区代码理解。目标仓库定位相对简单，我们采用了基于知识库的 RAG 方案。 在代码理解技术上，业内常见方案有：向量索引检索（RAG）、抽象语法树（AST）分析、文本搜索（grep）、预生成文档（如 deepWiki），实际应用中常有组合方案。 Cursor 主要采用 RAG 方案，优点是速度快，适合大型单体仓库，缺点是存在精度丢失（向量化）和实时性不高的问题。 Claude Code 则选择了更纯粹的文本搜索方案，与人脑的搜索方式相似，优点是精度高、实时性强，但性能开销相对较大。 在有赞，对于跨仓库的依赖代码，由于仓库数量庞大，我们采用 RAG 方案，并基于 Git 提交记录进行增量更新来保障一定实时性。对于工作区代码理解，由于基础 Agent 是 Claude Code，我们直接沿用其文本搜索能力。 另外，代码安全至关重要。无论是发送给向量嵌入模型还是大模型的代码片段，都会经过安全扫描进行脱敏处理。

知识库建设

理解了代码，还需要理解内部的业务与工程知识。和开发者一样，Agent 需要理解业务知识（如产品模块、业务术语）和专业知识（如技术选型、编程规范、工程现状）。 这些额外的上下文能让 Agent 编写的代码更符合预期，避免写出“另类”的代码。 过去，企业知识库建设有两大痛点：一是信息孤岛（无法统一检索，重复建设严重），二是内容老旧（因缺乏审核和运营机制，存在大量过期或错误信息）。 为此，我们内部成立了专门的知识工程团队，负责推动知识的透明化和持续更新。他们围绕知识增长、内容质量、知识使用三个维度进行建设，为上层应用提供高质量的知识供给。

至此，一个 MVP 版本的 Coding Agent 完成了。但我们拿它去尝试实际需求时，发现效果并不理想。原因在于，还有大量隐性的、个性化的经验存在于开发者的头脑中，没有被 Agent 掌握。

长期记忆学习系统

为此，我们为 Agent 打造了基于长期记忆的学习系统。简单来说，就是将开发者与 Agent 在监督对话中产生的有效经验提取出来，作为长期记忆存储。当后续遇到类似场景时，可以召回这些记忆进行参考，实现跨会话的经验复用。 这就好比一位经验丰富的老员工手把手带教实习生。整个过程分为几个环节：

• 记忆提取：重点关注符合事实、保留细节、避免过度归纳泛化。
• 记忆储存：采用自然语言加标签的形式储存，而非结构化数据，并保留原文引用。
• 记忆合并：定期对相似的记忆进行归纳合并。
• 记忆检索：业内根据场景不同，常用方案有向量数据库、知识图谱、分层存储等，我们目前采用向量数据库。
• 记忆遗忘：随着记忆数量增长，根据时间远近和使用频次进行遗忘。对于高频使用的记忆，经过泛化后可转化为通用知识入库。 虽然我们设定了很多提取规则和后处理逻辑，但在实际应用中，通过人工标注及修正的方式，可以较快地加速记忆的可用性。我们在 AI Coding 场景测试，同类任务在未接入记忆时需 5-10 轮对话修正，接入记忆后仅需 1-3 轮，效果提升显著。

云端沙箱环境

Agent 构建完成后，其运行、调用工具、拉取代码等操作都需要一个执行环境，如同为开发者配备一台电脑。 通过对本地辅助编程模式的观察，我们发现本地运行存在一些问题：复杂环境配置带来额外上下文负担、工程化适配困难、安全与监管难以保障。 因此，我们选择了云端部署方案。为每个 Agent 的每次会话分配一个独立且标准化的沙箱环境，其中包含了必要的开发环境，以便对交付结果进行预览。 同时，我们对会话及沙箱做了无状态化处理，以实现水平扩容能力。我们将会话内容存储在共享存储中，当开发者开启或继续一个会话时，系统会动态分配一个随机沙箱，并从共享存储中恢复之前的会话状态。 这一切操作都需要通过统一的网关进行，以解决安全和监管问题。

多智能体系统

随着接入的研发环节增多，我们发现单一 Agent 在面对多个环节时，由于 LLM 上下文长度限制，会出现遗忘、性能下降等问题。 为此，我们引入了多智能体系统，将复杂度进行分而治之。

• 编排方式：有 Workflow（工作流）和 Agentic（智能体自主）两种。由于企业级工程对稳定性、可观测性要求高，我们采用 Workflow 串联多个 Agent，在部分 Agent 内部则通过 ReAct 模式发挥 LLM 的自主规划能力。
• 拆分方式：有按流程拆分和按领域拆分两种。我们都进行了尝试，从落地情况看，按流程拆分基本可以解决大部分问题。 同时，我们为不同的 Agent 选择了差异化的基座模型，主要依据 Agent 的任务特点、不同 LLM 的优劣势以及成本考量：
• 需求解析和仓库定位较为简单，使用 GPT-4o。
• 代码定位使用向量嵌入模型 voyage-code-3，并配合 deepseek-v3 做后处理。
• 方案设计和编码使用 Claude-sonnet-4.5，其中记忆召回部分使用 GPT-4 效果出色。
• 代码审查则使用 Gemini 2.5，其巨大的上下文窗口允许我们将更多代码片段一次性给到模型。

人工监督回路

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

• 面向开发者的监督系统：主要基于飞书 IM，它本身就是一个天然的对话流，同时结合飞书文档、GitLab 等工具。开发者可以在 Agent 的每个产出阶段（如需求清单、技术方案、改动代码、实际效果预览）进行审核，并通过多轮对话进行修正。
• 面向管理者的监督系统：主要基于多维表格及其仪表盘，管理者可以一目了然地看到每个需求的情况，包括交付率、对话轮次、Token 消耗、对话明细等。 其中，对话明细可以转化为评测数据集，用于后续 Agent 的迭代优化。

对接发布系统

最后，我们通过部署发布 Agent，打通了发布系统。如图所示，开发者只需通过对话，即可方便地将代码部署到预发环境，或发布至生产环境：

最终产品形态与交互

以上便是我们最终的产品形态，并已成功交付了不少需求。当然，当前这种基于 IM 对话的人机交互模式也有其局限性。因此，我们正在开发更直观的 Web 端界面，类似 Manus 那样的效果。

需求选择与落地节奏

在 AI Coding 的落地需求选择上，我们从三个维度考量：多职能、多仓库、需求规模。和培养新人一样，在 Agent 能力尚不完善时，先从单职能、单仓库的日常小需求开始。通过完成小需求来验证 Agent 能力并积累数据，同时，这类需求因优先级不高容易积压，用 AI 来处理具有明显的提效价值。 在向兄弟团队推广时，我们发现大家对 AI 的期望往往过高，会分配给它非常有挑战性的任务。我们需要理解并传递一个观念：AI 不是万能的，人做不了的事情，AI 通常也做不了。 目前，我们的 AI Coding 已能够处理单职能、跨多仓库的日常需求，累计交付近百个需求。综合提效约 30%（包含人工监督耗时），单个需求的 Token 费用不到 100 元人民币。 接下来，我们会重点向“多职能多仓库”协作和“项目级”复杂需求两个方向进行迭代探索。

典型实践案例

在落地过程中，我们也发现了一些特别适合 AI 处理的共性需求类型。

翻译型任务

第一类我们称之为“翻译型任务”：已有明确、成熟方案且逻辑相对简单的任务，AI 可以快速完成，且质量不错。例如：技术债务治理。 我们有一个基础库升级的案例，涉及基础库、业务库和 23 个业务应用的联动升级。传统模式下需要超过 50 人日的工作量，通过 AI Coding 在几十分钟内就完成了代码改动。

降低开发门槛：跨域编程

第二类是跨域编程。工作中经常需要跨团队、跨领域进行技术支援，以往人员的学习和熟悉过程会产生额外时间成本。通过 AI Coding，我们的开发者进行了不少跨域编程尝试，这部分熟悉时间几乎被抹平。例如，一位后端工程师利用 AI 辅助高效完成了涉及复杂前端交互的任务。

小插曲：移动端应急编程

另外还有一个有趣的小插曲： 相信程序员都有共鸣：随身携带电脑是个痛点。在我们落地 AI Coding 的过程中，发生了一个小案例：一位开发同学外出聚餐未带电脑，此时线上出现一个 Bug：

• 他掏出手机，打开飞书，通过聊天唤起了一个 Coding Agent。
• 将 Jira Bug 链接和描述丢给 Agent。
• 让 Agent 先开始修改，自己继续吃饭。
• 几分钟后，Agent 修改完成。
• 他查看改动确认无误，便让 Agent 执行了发布操作。 这虽然只是一个非常小的案例，但让我们真切地看到，AI 正在潜移默化地改变着我们的编程方式和工作流。

完整架构全景

以上，就是我们在 AI Coding 方向的完整实践：

• 工具层：我们构建了稳定好用的云端沙箱环境。
• 个体智能层：基于上下文工程（Context Engineering），打造了具备专业能力的 Agent 个体。
• 协同智能层：通过多智能体系统（MAS）让它们高效协同工作。
• 交互层：设计了人机交互界面，让人能够有效监督和引导 Agent。

AI Test：从自动化到智能化

传统自动化测试的局限

开始之前，先简要回顾传统测试面临的挑战：技术栈多样化、设备终端碎片化、工程规模持续增大，这些都对测试效率提出了更高要求。 自动化测试的引入部分提升了效率，但其本身也存在局限：用例编写有门槛、维护成本高、难扩展和复用、失败排查困难。

AI时代测试的新挑战与新机遇

在 AI 时代，随着编码效率的极大提升，对测试效率的要求也水涨船高。同时，由于 AI 生成代码的不确定性增加，变更的影响面和潜在风险更大，给测试带来了新的挑战。 当然，AI 也为测试领域带来了新的可能性：

• 测试设计阶段：可实现 AI 用例生成、用例优化、用例选择（精准测试）等。
• 测试执行阶段：可实现 AI 数据构造、AI 驱动执行、AI 增强录制、AI 无参考测试等。
• 评估优化阶段：可实现 AI 失败归因、AI 用例修复、AI 分析报告等。 我们在这方面进行了诸多探索，踩过不少坑，也有些能力在部分场景成功落地。

基石：AI用例标准化

当我们开始尝试结合 AI 与测试时，遇到的第一个拦路虎就是：测试用例本身的质量。 过往积累的历史用例缺乏有效维护，质量参差不齐，例如左图中存在大量隐式步骤、断言缺失等问题。此外，用例还分散在不同平台（如文本用例和自动化用例），互不相通。 这就导致了 GIGO（垃圾进，垃圾出）的现象：输入给 LLM 的用例质量低下，其生成的输出质量也难以保证，且容易产生“幻觉”。

于是，我们开始思考如何从根本上解决用例问题。我们发现，LLM 具备强大的自然语言理解能力，这让传统文本用例与自动化用例的融合成为可能，即自然语言用例——让用例兼具语义可读性和机器可执行性。 我们探索了两个方向：AI 存量用例优化、AI 增量用例生成。

• 存量优化：基于已有的测试目标和粗略步骤，由 LLM 生成更规范的用例名称、标签，并逐步优化步骤描述、补充断言。
• 增量生成：结合业务知识库，并参考历史优质用例进行新用例生成。 所有这些自然语言用例集合在一起，本身就构成了一个高质量的测试知识库。

一个新的用例生成过程分为三步：

1. 填写基本信息：输入测试目标，并开启“AI规划”选项。
2. 选择参考用例：从历史用例库中选择相关的用例供 LLM 参考。
3. 用例生成：LLM 会生成用例的基础信息，以及完整的自然语言测试步骤。这些步骤一目了然，且可被测试引擎直接执行。 目前，用例生成的准确度和场景覆盖度仍有较大提升空间，处于持续探索阶段。

AI增强录制：让录制更智能

我们仍有大量用例是通过录制方式产生的，因此我们研发了 AI 增强录制能力。 （编者注：此处原始内容包含一段视频描述，因格式限制保留文字说明） 在录制视频中，当人工进行操作时，系统会并行录制屏幕截图及坐标信息，并实时交给多模态 LLM 进行分析，生成自然语言描述的测试步骤。这个过程是并行的，不影响人工操作，单次生成耗时约 5 秒。录制完成后，回放执行也非常流畅，AI 能够以接近人工操作的速度和方式执行用例。

我们是如何实现的？ 首先回顾传统录制的局限：定位不精确、录制步骤冗余、需要大量人工校准、维护成本高。如下图：

通过 AI 增强后，测试步骤能更精确地识别用户意图，例如“输入价格1”、“输入划线价2”，且描述更为精炼：

整个增强过程大致分为几个关键步骤：

1. 原始输入（DOM+截图）：捕捉用户操作时的完整 DOM 和屏幕截图，输入给多模态 LLM。当前通用多模态模型已足够强大，我们第一版就达到了约 70% 的准确率。即使不提供 DOM，仅凭截图 LLM 也能识别，这为跨平台录制提供了可能。但此方案 Token 消耗巨大，且过长上下文会带来不稳定和幻觉。
2. DOM 预处理：对 DOM 进行智能裁切，去除噪音以降低 Token 消耗，同时标注重要内容以提升模型注意力。此外，敏感信息和代码也会被过滤。经过处理后，上下文长度可减少约 99%。
3. 交互区域标注：为了将准确率从 70% 进一步提升，我们遇到一个问题：当用户操作没有明显的界面交互状态变化时（如左图，点击“…”按钮），LLM 难以准确理解，可能仅识别为“点击空白区域”。我们通过增加交互区域标注来解决，让 LLM 能准确识别用户交互的UI元素，效果如右图，LLM 能正确理解为“点击更多按钮”。
4. 父级元素上下文标注：虽然增加了交互标注，但在复杂业务场景中，元素之间常有关联。如左图，“？”图标，LLM 能识别为“帮助”，但不清楚是“退款资金状态的帮助”。如果一个页面有多个类似图标，识别就不准确了。为此，我们增加了父级元素标注，将交互区域前后的父级 DOM 元素一同提供给 LLM，使其理解更丰富的上下文关系。如右图，增加后 LLM 能准确理解为“点击退款资金状态的帮助”。 经过上述优化，我们的增强准确率达到了 89%，单次增强耗时在 5-10 秒之间。这很大程度上得益于底层多模态模型能力的快速提升，从早期使用 Qwen2.5-VL 的约 20 秒，提升到使用 GPT-4o 的 10 秒以内。 目前这套方案支持跨全平台，包括 Web、Pad、桌面端，覆盖 Android、iOS、鸿蒙等系统，以及各类小程序。

AI驱动用例执行

有了高质量的用例，接下来是执行环节。目前我们所有用例执行都会注册到统一的任务中心，由其下发到两大执行集群：浏览器任务集群和 App（含小程序）任务集群。 AI 在执行方面具有天然优势：具备跨平台支持能力，以及一定的自适应能力。例如，面对某些设备上的像素抖动或UI微调，LLM 能够识别并适应，从而提升用例的稳定性。 目前，我们每天的 AI 用例执行量超过 10 万次，任务成功率达 96%。

当然，这个过程也遇到了一些问题：模型执行速度慢、模型幻觉、模型识别精度不足。

• 解决“执行速度慢”：我们首先建立了基于图像和 Prompt 的识别缓存。但对于缓存未命中的情况，AI 指令的秒级响应与程序指令的百毫秒级响应仍有差距。因此我们做了“AI提速”优化：用例解析后，优先尝试用程序化脚本执行；若执行失败，则切换至 AI 兜底执行；AI 执行成功后，会进行“自愈”——提取成功定位的信息，反哺并更新程序化脚本，使得下次同类操作能直接走程序。
• 解决“模型幻觉”：幻觉问题相对可控，通过对 LLM 生成的步骤进行二次 Prompt 优化，并采用更精确的 AI 指令（如在某些场景用 AI Input 替代宽泛的 AI Action），基本可以解决。
• 解决“识别精度问题”：如下图右上角所示，红框是 Qwen-vl-max 的识别区域，绿框是 UI-TARS-1.5 的识别区域，两者对于小元素的识别精度差异明显。根据我们的测试，Qwen-vl-max 对小图标识别能力较弱，开启深度思考（deepThink）后有所改善。UI-TARS-1.5 在探索性任务上表现较强。但在断言准确性上，两者均不如 GPT-4o。我们从元素定位、元素断言、内容提取、任务规划四个维度测试了5款主流多模态模型，最终选择 UI-TARS-1.5 作为当前主力，因其在元素定位精度和移动端适应性上综合表现更佳。

探索：AI无参考测试

实现了 AI 执行后，我们开始思考：LLM 本身具备通用常识，如果注入企业内部知识，是否可以直接进行“无参考测试”（即无需预先编写用例）？ 我们对此进行了探索。首先，无参考测试对模型的精度和理解深度要求极高，通用多模态 LLM 难以满足。 因此，我们引入了监督微调。通过 SFT（LoRA）方式，主要让模型获得以下能力：更细粒度的任务定义理解、明确的输出格式以方便工程化对接、以及注入内部业务知识和评判标准。 我们的算法团队提供了基础框架，让业务测试团队可以聚焦于构建微调数据集。一条微调数据通常包括：Instruction（指令）、Input（输入）、Output（期望输出）。下图是一个简单示例：

当然，这条示例数据质量并不高，其 Output 缺少了很多必要信息，例如：作答风格、结构化输出、内部知识引用、分析过程和原因。我们从指令微调和思维链微调两个角度对这类数据进行优化，如下图：

定义了数据结构后，下一个挑战是如何生成大量的微调数据。通常需要训练集、验证集和测试集，前两者用于训练和调参，后者用于最终评估。 数据集需要包含正样本（正确操作）、负样本（错误或有问题的操作）和混合样本，比例通常约为 1:3，以避免模型过度偏向“总是发现问题”的倾向。 数据集的生成主要依赖 LLM 合成：首先通过脚本抓取线上实际的正样本；然后通过程序规则生成多种负样本；最后，结合样本图片和特定 Prompt（内含内部知识、预期输出结构、作答风格要求），用大语言模型生成最终的 Output。 目前，我们的垂直领域测试模型正在微调过程中。

AI失败归因与归类

当用例执行完成后，我们需要对失败用例进行分析。传统人工分析效率较低，100条失败用例可能需要15分钟。 我们利用 AI 来加速这一过程。首先由 LLM 总结单个失败用例的核心原因，然后将原因相似的用例进行分组归类。 如右下圖所示，85条失败用例被快速归为3组，并标明了每组的主要失败原因。这使得人工分析效率大幅提升，100条用例分析时间缩短至约1分钟。

整个归因归类流程如下：首先对用例执行报告进行程序化预处理。 程序主要完成两件事：将失败截图进行智能切片，将冗长的测试步骤拆分为独立段落。前者解决了多模态 LLM 处理大图时的幻觉和不稳定问题，后者提升了处理性能。 接着，将切片和步骤分别交给“图片归因 Agent”和“步骤归因 Agent”进行并发分析。 然后由“总结 Agent”对分析出的原因进行合并提炼，最后由“归类 Agent”将原因相似的失败用例进行分组。 目前，线上所有失败用例已 100% 覆盖 AI 归因归类，归因准确率达到 85%。

探索：AI用例自修复

实现了 AI 归因后，我们进一步思考：既然已经知道失败原因，是否可以让 LLM 尝试自行修复？ 因此，我们正在探索 AI 用例修复能力。目前主要针对“像素差异率波动”和“非核心元素变化”这两类场景实现了自动化修复建议。 如下图，AI 会对判定为可自动修复的场景给出修改建议，人工确认无误后，可一键完成修复。目前修复准确率约为60%，仍在优化中。

与 AI Coding 的闭环串联

以上是我们在 AI Test 方向的实践。未来，我们计划将 AI Coding 与 AI Test 进行深度串联：由 Coding Agent 在完成代码后，生成对应的测试目标或场景描述，交由 Test Agent。Test Agent 根据描述，从用例库中召回相关用例或生成新用例，并驱动后续的自动化测试执行，形成研发闭环。

Agent 评测：从炫酷演示到生产落地

在构建大量 AI Coding 和 AI Test Agent 的过程中，我们认识到需要一套科学的 Agent 评测体系，来客观评估其效果并指导迭代。

为什么需要独立的 Agent 评测

先看一张熟悉的图：我们看到别人展示的 Agent 时，常觉得炫酷而跃跃欲试，然后自己动手构建。在开发环境或小范围测试中，它表现似乎不错。 但一旦发布到生产环境，面对用户千奇百怪的提问和真实场景，各种问题涌现，最终往往仍需转人工处理。 我们需要认识到，Agent 与传统软件有本质不同，无法通过穷举所有用例的方式来保障效果。 软件测试的目标是固定的、标准化的、可复现的；而 Agent 评测则面对不确定性、开放性（用户自由提问）和多样化（模型非确定性回答）。 发布标准上，传统软件主要看功能点完成度和测试通过率；Agent 则需要使用评测集，进行多维度的指标评估。 Agent 开发完成，绝不等于达到了生产发布标准。评测指标应该成为是否上线的核心依据。

评测集的构建

开始 Agent 评测，首先需要准备评测集。评测集类型主要有：有参考（提供标准答案）、无参考、参考资料型三种。 评测集的构造方法常见有：人工标注、LLM 泛化、线上真实数据采样。 对于一个全新的 Agent，没有线上数据，我们可以通过人工标注 50-100 条高质量的“种子集”，然后利用 LLM 进行泛化扩充，生成更多样化的评测问题。 根据用途和来源，评测集可以划分为：种子集、Badcase集（通常来自用户反馈）、扩展集、对抗集、场景集（由特定业务场景决定）。

评测器的设计

有了评测集，接下来是评测器。评测分为人工评测和自动化评测。新 Agent 初期，评测标准可能不明确，可结合人工评测。随着调用量增加，应逐步将人工评测的维度和标准沉淀为自动化评测。自动化评测具有评判尺度统一、主观偏差少的优点。 自动化评测器包括：托管评测器（平台自带，可快速启动）、自定义评测器（根据业务编写 Prompt 的“裁判模型”）、外部评测器（由第三方服务提供）。裁判可以是另一个 LLM，也可以是特定的算法（如 BLEU、CLIPScore 等），或是业务逻辑验证程序。 评测器设计一般包含：评估步骤、打分标准、推理指令、少样本示例（正例/反例）、边界案例、基于业务的特殊判断要点（如合规、医疗等场景）。评测打分建议采用 0-5 分制进行归一化，兼顾可解释性和区分度，便于不同维度横向对比。此外，为裁判模型添加思维链要求可以提升其判断的可解释性和一致性，便于后续人工分析优化。

评测指标设定

接着是设定评测指标。首先要明确评测的主体是什么，可以是：基础模型版本、提示词版本、工具链版本、召回的记忆版本等。 围绕评测主体，设定多维度指标，通常包括四类：效果指标（如准确率、相关性）、技术指标（如响应延迟、Token消耗）、用户指标（如满意度、留存率）、业务指标（如转化率、问题解决率）。 另外，裁判模型本身也需要被评测，以确保其可靠性：

• 人工一致性：衡量模型评分与人工标注结果的一致程度。
• 评分方差：衡量模型打分结果的稳定性。
• 异常打分率。

用户反馈系统

除了离线评测和自动化评测，生产环境中用户真实的使用反馈至关重要，能帮助我们发现 Agent 在实际应用中遇到的各种边界场景和潜在问题。 反馈收集通常有两种方式：

• 显式反馈：需要用户明确操作（如点赞/点踩），意图明确但反馈率通常较低。
• 隐式反馈：采集用户在自然使用流程中的行为数据（如在 AIGC 生成多张图片时，用户选择了其中一张），并解释为偏好信号，可获得较高的反馈覆盖率。 对于反馈率低的问题，可以通过预设标签（让用户点选而非输入）来降低行动成本，通过预设高评分（如默认五星）来增加正面反馈的意愿（因为人们通常更倾向于吐槽而非夸赞）。

完整的评测体系

以上各部分组合在一起，构成了我们完整的 Agent 评测体系。

• 项目启动阶段：由专职评测人员与项目组共同设定评测维度、创建评测器、建立种子集、并通过 LLM 泛化扩充评测集。基于评测结果不断迭代和验证 Agent。
• 开发迭代过程：在 Agent 持续迭代中，使用评测集和评测器进行线下实验和 A/B 测试。
• 生产环境运行：Agent 产生的运行日志会通过评测器进行线上实时或准实时评测。Trace 日志可采样后沉淀为新的评测集。此外，从用户反馈中收集的 Badcase 也会沉淀到评测集，用于驱动优化。 我们要求，所有 Agent 在正式发布前，都必须经过严格的评测验证并达到预设标准。

AI落地过程中的关键经验

AI与程序化逻辑的结合艺术

在构建 Agent 时，常见的模块包括：纯程序计算节点、单一 LLM 调用节点、固定工作流编排、以及具备自主规划的 Agentic 节点。 可能存在一种误解，认为 Agentic 优于 Workflow，Workflow 优于单一LLM节点，单一LLM节点又优于纯程序。但从我们的实践来看，这四者并无绝对的优劣之分，通常需要根据具体的业务场景进行多选和组合。选择取决于场景对确定性、稳定性、创造性、自主性等不同维度的侧重。 此外，程序化逻辑与 LLM 也非简单的替代关系。LLM 更擅长理解、规划、生成类任务；而程序化逻辑在确定性、稳定性、高性能任务上具有不可替代的优势。通过程序化逻辑来规避 LLM 的弱项（如计算精度、稳定性）是非常必要且有效的工程手段，应避免陷入“为 AI 而 AI”的过度追求。

警惕人机协作中的陷阱

在人机协作过程中，需要警惕两个常见陷阱：

• 过度依赖陷阱：在落地 AI Coding 时，曾出现开发者对 LLM 生成代码不加判断直接采纳提交的情况。保持开发团队的主观判断力和代码所有权意识至关重要。建议分场景追求 AI 辅助程度，例如核心业务逻辑由人主导编写，非核心或模板化代码交由 AI 生成。
• 监督成本陷阱：在落地 AI Agent 时，需要人工监督。但需警惕“人工监督成本大于 Agent 自身价值”的情况。应将监督过程中产生的高价值数据（如修正对话）有效回收，用于 Agent 的迭代训练，从而降低远期监督成本，形成正向循环。

AI落地核心经验总结

最后，总结一下我们在企业内落地 AI 的关键经验：

• 区分工作性质：现阶段，LLM 更擅长执行性、模式化的工作，创造性工作仍需人类深度参与。选择合适场景切入。
• 从流程单点突破：从传统研发流程中的某个痛点环节切入，快速构建 MVP，验证价值并获取早期反馈。
• 设计好人机协作：现阶段 AI 仍需大量人参与，需充分考虑人机协作界面（让人好用）、知识外化机制（让人能高效传授经验）、明确责任归属（让人敢于使用）。
• 建设私有化基建：同步构建连接行业能力与内部能力的私有化 AI 基建平台，如上下文工程、知识库、评测体系等。
• 基于数据快速迭代：Agent 的迭代不应是“先设计完美方案再开发”，而应基于测试集和上下文工程，采用数据驱动的快速试错方式。
• 分阶段渐进落地：根据场景复杂度和 AI 成熟度，划分清晰的落地阶段，避免一开始就追求“全自动”，循序渐进是关键。

有赞AI研发实践全景

以上，就是我们在研发全流程落地 AI 的完整实践全景：

• 我们通过软件工程与上下文工程的结合，将确定性程序与创造性 LLM 的能力融合。
• 围绕研发的设计、编码、测试等核心阶段，系统化落地 AI 能力。
• 在整个过程中，同步构建了Agent 评测体系，通过持续的数据反馈，驱动 Agent 能力迭代进化。