AI Coding 已经能够完成代码生成、项目修改、测试执行，甚至参与线上问题排查。
但一个值得思考的现象是：AI 写代码越来越快，软件从需求提出到最终上线，为什么没有同步提速？
阿里巴巴在《AI Native 研发范式实践手册》中，专门复盘了这个问题。
这份手册由阿里巴巴技术团队发布，围绕内部三个真实业务实践案例，系统梳理了 AI Native 研发转型过程中遇到的五大共性挑战，以及企业级 Agent 基础设施的建设方向。
手册提出了一个很重要的判断：研发效率并不等于代码生成速度。
按照手册披露的数据，在阿里巴巴，编码投入约占研发活动的 20%～30%。代码生成效率提升之后，需求理解、环境准备、测试验证、发布和运维等环节，反而会成为新的效率瓶颈。
这意味着，AI 研发正在从 Copilot（辅助编码）走向 Agentic（智能体自主执行），企业需要改变的已经不只是开发工具，而是整个软件研发和交付体系。
下面结合这份手册，看看阿里巴巴三个团队究竟做了哪些尝试。
一、阿里巴巴三个真实案例：AI 如何进入软件研发？
- AIDC 数字投手：从一个人指挥多个 Agent，到数字员工协作
AIDC 数字投手是阿里巴巴面向 Alibaba.com 商家的智能营销助手，主要负责广告效果诊断、投放策略分析和广告运营优化。
为了让 Agent 真正承担业务工作，团队经历了三个阶段。
第一阶段：超级个体。
工程师开始使用 Coding Agent，一个人同时管理 3～5 个 Agent 会话，让 AI 分别承担策略生产、数据分析、知识整理等任务。
初期效果非常明显，一个人能够完成原来两三个人的部分工作。
但问题也随之出现：
AI 生成了大量内容，团队成员却很难快速理解和消化。
每个会话都沉淀了大量业务知识，却难以在团队之间复用。
任务完成后，其他人很难直接接手原来的工作。
第二阶段：数字员工。
团队将本地 Agent 会话迁移到云端，让数字员工分别承担产品、研发、评测和数据分析等工作。
个人产能开始转变为团队产能，但不同数字员工之间缺乏协作机制，任务分配、优先级和结果验收仍然需要人工协调。
第三阶段：云上 Scrum。
团队进一步建设 Agent 之间的通信机制，让不同数字员工可以按照业务领域分工协作。
这套模式类似敏捷开发，每个数字员工承担明确职责，任务完成后通过结构化结果交接，减少人工传递信息的成本。
团队还将数字投手拆分为三个核心部分：
组成
主要职责
经验
沉淀专家策略、业务规则和历史经验
手脚
负责工具调用、参数约束和实际操作
头脑
理解问题、分析策略、做出决策
这套架构强调一个原则：确定性的计算和操作交给工程系统，AI 只在明确的业务边界内进行推理。
项目后续还建立了线上数据反馈机制，将策略挖掘、策略生产和能力修复交给不同数字员工协作完成。
手册披露的阶段性成果包括：
策略交付周期从约 10 天缩短至 2 天。
约 80% 的核心能力实现 Skill 化。
这个案例关注的是团队开始解决数字员工之间的协作、知识复用和结果验收问题。
- 千问用户增长 Agent：从 AI Coding 到完整研发流程
阿里巴巴手册中的第二个案例，原名为「千问用增 Agent」。
该项目由千问研发团队负责，目标是利用 Agent 重构用户增长体系，打造工业化智能运营系统。
它涉及投放执行、投放策略、数据分析、预算规划和素材生产等多个模块。
这个项目有一个很值得软件测试从业者关注的地方：团队明确设置了质量工程师角色，负责系统功能测试、自动化验证和质量准入门禁。
项目推进 AI Coding 的过程，大致分为三个阶段。
第一阶段：探索 AI Coding 的效率边界。
项目初期，约 15 名服务端工程师分别探索 AI Coding，通过定期分享沉淀有效经验。
研发人员不再局限于原来的服务端岗位，也开始借助 AI 承担前端、Agent 开发和算法策略等工作。
部分场景下，代码生成速度达到传统开发方式的数倍，甚至约 10 倍。
第二阶段：解决存量工程适配问题。
当代码生成能力得到验证后，新的问题出现了。
AI 能够生成代码，但不一定理解企业原有项目的架构、模块关系、业务规则和技术约束。
团队开始建设项目文档、代码知识图谱和工程规则：
Code Docs：解释模块职责、设计背景和使用方式。
Code Graph：查询代码定义、调用关系和影响范围。
Rules：将团队经验沉淀为可执行的工程约束。
让 Agent 不再每次都从零开始理解项目。
第三阶段：让 AI 参与完整软件研发流程。
团队逐渐把 AI Coding 扩展到需求理解、技术方案、任务拆解、编码实现、联调自测、问题排查和文档沉淀。
其中有四项工程能力特别值得关注：
核心能力
具体实践
项目理解
Code Docs、Code Graph、Rules
需求理解
AI 主动追问需求中的隐含条件，形成 Spec 和 Tasks
可靠编码
引入 TDD，通过测试反馈约束代码实现
线上排障
使用 TraceId 打通日志、调用链和代码位置
其中，TDD（测试驱动开发）是一个非常值得测试开发人员关注的实践。
团队先通过失败测试固定需求边界，再完成最小实现，让测试通过，最后在测试保护下进行重构。
测试不再只是开发完成后的验收工作，而是直接进入 AI 的编码过程，为 Agent 提供持续、客观的反馈。
例如，并发场景下，即使接口层实现了幂等，也不代表整个业务链路没有问题。请求入口、数据库事务、消息发布和消费执行，都可能存在幂等性缺陷。
因此，测试需要覆盖真实业务链路、关键分支和已知故障模式，而不是单纯追求代码覆盖率。
手册披露了该团队 2026 年 5 月至 8 月的阶段性数据：
平均交付周期缩短 50%。
千行代码缺陷率下降 70%。
变更失败率下降 90% 以上。
这些是该团队特定实践周期内的结果，并不代表所有企业采用 AI Coding 都能获得相同收益。
但它至少说明了一件事：AI Coding 的价值不只在于生成代码，更在于通过项目上下文、测试反馈和工程规范，让代码能够可靠交付。
- 万有无界平台：让需求、开发、测试和缺陷修复形成闭环
万有无界是阿里巴巴的一款企业级人与 Agent 协作平台。
这个案例覆盖了产品、设计、研发、测试和运维等多个角色，重点解决研发过程中信息交接不完整的问题。
过去，一个需求通常需要经过产品评审、设计交付、研发实现、测试验收等多个环节。
每次交接都可能丢失上下文。
例如，产品描述了一个页面功能，但没有说明空状态、异常状态、权限限制和数据依赖。等开发完成后，测试才发现部分场景没有考虑。
团队开始将整个研发过程拆分为三个相互关联的部分：
上下文资产 + 工程执行环境 + 验证证据。
这三个部分分别解决：
上下文资产：本次需求到底要解决什么问题？
工程执行环境：代码应该在哪里修改，依赖是否真实可用？
验证证据：修改后的结果是否符合预期？
其中有两项实践非常值得测试人员关注。
第一，基于真实工程构建可交互原型。
产品经理在需求评审之前，就可以基于真实项目代码制作可操作的原型。
评审人员直接检查页面正常状态、空状态、异常状态、权限和数据依赖，不再只对着静态文档讨论。
手册披露，近四个版本中，约 80% 的交互体验类需求可以通过这种方式承接。
第二，基于现场证据实现 AI 自动修复缺陷。
当自动化测试发现问题时，系统不再只把一句 Bug 描述交给 AI，而是同步采集：
当前页面版本和运行环境。
页面入口和复现步骤。
接口请求和关键日志。
测试数据和受影响范围。
页面截图、样式和节点信息。
AI 在相同版本和环境中复现问题、修改代码，再回到相同页面状态进行回归验证。
在上下文充分的视觉类缺陷样本中，自动修复一次成功率约为 89%。
不过，这个案例还有一个特别有意思的数据：
虽然 Auto Bug Fix 的比例已经达到 60% 以上，但 Bug 日清率只是从 53% 提升到最高 63%。
原因在于，自动修复的触发和最终结果校验，仍然依赖人工或其他确定性流程。
这说明，单个环节自动化程度很高，并不代表整个交付流程就实现了自动化。
自动化测试不仅要解决执行问题，还要解决任务触发、失败诊断、修复验证和结果闭环。
二、AI Native 研发转型，企业必须解决五大挑战
三个案例虽然业务不同，但阿里巴巴从中归纳出了五类共性挑战。
- 环境与验证：Agent 能不能在真实环境中完成任务？
Agent 可以修改代码，却不一定知道项目需要什么依赖、数据库如何初始化、测试数据从哪里获取，以及外部接口应该如何调用。
企业必须提供可复现、可调用的研发环境。
手册提出了分层验证思路：
验证层级
主要内容
秒级反馈
编译、类型检查、Lint、单元测试
分钟级反馈
集成测试、契约测试、浏览器自动化
人工判断
业务价值、用户体验和复杂风险
前两层为 Agent 提供高频、客观的执行反馈，人工判断则保留给机器无法可靠裁决的问题。
这对自动化测试体系提出了更高要求：测试环境必须稳定，测试数据必须可信，执行结果必须可复现。
- 平台能力：从面向人操作，转向面向 Agent 执行
过去的研发平台主要服务工程师，通过 Web UI 完成代码管理、流水线执行、测试和发布。
Agent 进入之后，原有操作方式开始暴露问题。
MCP 可以解决模型如何调用工具，却不能天然解决模型是否知道自己应该操作哪个项目、哪个仓库、哪条流水线。
因此，企业需要建设统一、稳定、可编程的研发入口，并通过 CLI、MCP 和 API 提供明确的任务执行能力。
平台不能只告诉 Agent「流水线失败了」，还应该提供失败发生的位置、相关日志和下一步可执行操作。
- 效能度量：AI 到底有没有真正提高效率？
统计 AI 使用人数、Token 消耗量、代码生成量，只能说明工具使用情况。
不能证明研发效率真的提升了。
阿里手册提出三层度量体系：
层级
核心指标
L1：AI 效能
使用率、Session、Token、Skill、MCP
L2：工程质量
缺陷率、回滚率、返工率、变更失败率
L3：价值交付
需求交付周期、发布频率、业务收益
同时，需要打通一条完整的数据关联链：
Session → Commit → Change → Workitem
也就是从 AI 会话，关联到代码提交、变更记录，再关联到实际需求。
这样才能判断 AI 生成的内容是否真正进入了交付流程，以及最终有没有改善交付质量。
- 数字员工：Agent 的身份、权限和责任如何管理？
当 Agent 能够独立执行代码修改、测试和发布任务时，企业原有的权限体系也需要调整。
Agent 可以读取代码，不代表它可以直接修改主分支；可以执行测试，也不代表它可以直接发布生产环境。
企业需要逐步建立：
独立的 Agent 身份。
明确的任务授权范围。
最小权限原则。
高风险操作人工审批。
完整的操作记录和审计机制。
AI 可以承担执行工作，但不能绕过企业现有的安全和质量门禁。
- 组织配套：产品、开发、测试之间的协作方式正在变化
AI 能够跨技术栈完成越来越多的工作，传统岗位之间的部分技术壁垒正在降低。
未来研发团队可能更多采用小型跨职能团队，围绕具体业务目标组织人员与 Agent 协作。
但还有一个问题值得管理者重视：员工是否愿意把自己的经验和知识沉淀给 AI？
如果员工担心自己整理的 SOP、业务规则和工作经验最终成为替代自己的工具，知识沉淀就可能受到影响。
因此，AI Native 转型不仅涉及工具和技术，还涉及岗位发展、人才培养、绩效评价和激励机制。
这五项挑战说明，企业要实现 AI Native 研发，必须同时改造技术基础设施、工作流程和组织协作方式。
三、企业级 Agent 基础设施，需要建设哪些能力？
阿里巴巴在手册第三部分，进一步展开了企业级 AI 研发基础设施的整体架构。
这部分技术内容对测试开发人员也有很强的参考价值。
基础设施
主要解决的问题
Agent Harness
管理上下文、任务规划、执行状态和失败恢复
企业知识库
提供业务规则、研发规范和历史经验
MCP / CLI
连接研发平台、代码仓库、测试系统等工具
Skill
沉淀可复用的任务方法和操作流程
Sandbox
为 Agent 提供隔离、安全的执行环境
Coding 环境
提供代码、依赖、配置、数据和运行条件
Identity & Policy
管理 Agent 身份和资源访问权限
Guardrail
对生产变更和高风险操作设置独立门禁
Observability
记录 Agent 执行轨迹、工具调用和最终结果
其中，我认为有五项技术值得重点关注。
- Agent Harness：让 Agent 能够持续完成长任务
Harness 可以理解为 Agent 的执行管理框架。
它负责管理上下文、任务计划、工具调用、状态恢复、验证反馈和人工接管。
例如，让 Agent 修复一个构建失败的问题：
读取日志 → 定位代码 → 修改代码 → 执行构建 → 分析失败 → 再次修复。
这个过程不是一次性生成答案，而是持续行动、验证和纠错。
- 企业知识库：让业务经验成为可复用资产
企业需要将分散的技术文档、业务规则、代码规范、历史缺陷和排障经验整理成 Agent 能够检索和理解的知识。
知识库提供事实，Skill 提供任务方法，MCP 和 CLI 提供执行入口。
三者配合，Agent 才能真正进入企业研发流程。
- Sandbox：给 Agent 提供可复现的执行环境
Sandbox 不只是一个容器。
它还需要考虑依赖、配置、数据、网络策略和资源隔离。
对测试开发来说，这意味着 Agent 执行自动化测试时，需要有独立的环境、可靠的测试数据和可重复的验证条件。
- Guardrail：不能让 Agent 自己给自己判定通过
这是企业级 Agent 安全体系中非常重要的一环。
Agent 可以提交修改方案和测试报告，但不能自行决定生产发布通过。
高风险操作必须经过独立规则校验、证据核验和人工审批。
如果验证超时、证据缺失或状态不明确，就不能默认放行。
- Agent Observability：从监控系统运行，扩展到分析 Agent 行为
传统 APM 主要关注接口耗时、错误率、吞吐量和资源利用率。
Agent 还需要记录完整的执行轨迹（Trajectory），包括：
模型调用记录。
工具调用记录。
Skill 执行情况。
任务状态变化。
执行失败和重试过程。
最终验证结果。
这样才能分析 Agent 为什么调用某个工具、为什么反复重试，以及任务失败究竟发生在哪个环节。
可观测的目的不只是记录日志，而是让 Agent 的问题能够被定位、评测和持续改进。
四、AI Native 时代，软件测试工程师需要提升哪些能力？
看完阿里巴巴这三个实践案例，我认为软件测试行业有一个非常明确的变化：
测试正在从研发流程末端的质量检查，逐渐变成 Agent 整个执行过程中的验证基础设施。
过去，测试人员主要负责设计测试用例、准备测试数据、编写自动化脚本、执行测试和跟踪缺陷。
现在，Agent 可以参与这些工作的多个环节，但它需要测试体系提供可靠的反馈。
结合手册中的实践，我认为测试开发人员未来应该重点提升三个方向。
- 自动化测试与 Agent 协同
掌握 Playwright、Selenium 等自动化测试技术，进一步结合 LLM、MCP、CLI 和 Skills，让 Agent 能够参与：
测试场景分析和用例生成。
自动化脚本生成与维护。
浏览器自动化执行。
失败用例分析。
缺陷定位与自动修复。
修复后的自动回归验证。
未来测试人员不仅要会写自动化脚本，还要知道如何让 Agent 正确调用测试能力。
- 测试环境与测试数据工程
Agent 要完成测试，不能只给它一份测试用例。
还需要提供符合业务场景的数据、稳定的运行环境、真实的接口依赖，以及必要的 Mock 和数据清理机制。
测试环境能否快速创建、测试数据能否重复构造、执行结果能否复现，会直接影响 Agent 的测试可靠性。
这也是测试工程师从自动化脚本开发走向测试基础设施建设的重要方向。
- AI Agent 质量评测与安全测试
传统自动化测试主要验证软件功能是否符合预期。
AI Agent 测试还需要关注：
Agent 是否正确理解用户意图？
工具调用是否正确？
是否存在无效重试和错误决策？
多步骤任务能否稳定完成？
是否出现越权访问和敏感数据泄露？
任务完成后是否留下完整的验证证据？
这要求测试人员进一步掌握 Agent 评测集建设、执行轨迹分析、工具调用评测、安全测试和质量门禁设计。
未来，测试开发工程师的价值不仅在于发现 Bug，还在于建立一套能够持续验证 AI 行为的工程体系。
写在最后
AI 写代码只是开始，让 AI 能够在真实工程环境中完成任务、通过测试验证，并且安全地交付结果，才是 AI Native 研发真正需要解决的问题。
对于软件测试行业而言，AI 带来的这场变化，并不意味着测试工作会消失，更不意味着测试工程师将失去价值。
相反，随着 Agent 开始参与需求分析、代码开发、自动化执行和线上排障，企业对测试环境、测试数据、质量评测和安全验证的要求只会越来越高。
未来真正有竞争力的测试开发工程师，需要同时理解软件工程、自动化测试和 AI Agent 的运行机制。
代码可以让 AI 来写，但软件是否真正可靠，仍然需要一套经得起验证的工程体系。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
