高德营销AI质量工程：研发识别风险、测试验证风险如何落地

所谓 AI 质量工程，指的是把 AI 的分析与执行能力装进软件质量保障流程：让 AI 帮忙找风险、设计测试、执行验证，同时用明确的业务规则、权限边界、人工审阅和运行记录去约束它的判断与动作。每条建议怎么验证、每次改动怎么追踪、最终依据什么决定交付，才是它真正盯住的东西。

AI 进入软件交付环节之后，团队要同时应对两个彼此相连的难题：研发这边怎么找出值得动手的风险，测试这边怎么确认这些风险已经被控住。风险依据、测试预期和实际运行结果只有相互挂上钩，"发现问题"才谈得上变成可追溯的交付依据。

落到高德营销业务上，研发侧搭了 Graph Engineering 决策图，测试侧搭了 AgentLoop 工作流。前者按代码变更组织多角色评审，给出风险、代码位置和验证条件；后者按业务规则做变更分析、用例设计、测试方案设计和自动化实现，产出测试资产与运行记录。本文就按"研发识别风险—测试验证风险—形成交付证据链"这条线，把两侧的做法讲一遍。

眼下，研发风险识别和测试验证这两块能力已经各自落地。统一任务协议、跨侧自动交接、结果回流和交付门禁还在建设中。下文分别讲已经落地的能力、案例记录，以及后续协同设计的思路。

图 1 展示的是研发决策图与测试交付图的协同设计。统一证据协议和跨侧自动回流属于后续建设方向。

研发侧从研发平台里的应用切入，把仓库、分支、扫描范围、验证命令等上下文组织起来。评审靠规则和 Agent 配合：边界清楚的问题交给规则处理，需要进一步判断的风险则由 Agent 结合代码、需求和历史信息来识别。

我们用 LangGraph StateGraph评审过程要显式组织。Generator 先形成基础 Finding；PM、QA、Developer、SRE、Security由这些角色并行审查需求边界、测试条件、稳定性和安全性；Reducer把重复出现的结论归并到一起。Judge对有效性、严重程度和处理优先级作出判断。策略允许时，Executor / Refiner接着给出修复方案，并依据验证诊断做有限次数的迭代。

这张决策图不只输出修改建议，还要讲清风险究竟是什么、判断依据在哪儿、达到什么结果才算风险处理完毕。比如「新增枚举未覆盖兜底分支」，得同时交代变更位置、可能受影响的业务条件和待验证场景，测试侧才能接着往下用。

风险判断和执行权限是分开管的。Safe Autofix修复流程被拆成下面这些动作，每个动作由策略单独控制：

proposal → dry-run → apply → verification → commit → push → optional MR

动手修之前，先核对策略白名单、风险等级、置信度和证据锚点；真正改动前执行dry-run，改完再跑仓库验证。commit、push 和 MR这几项分别受控，验证通过本身不会自动放开后续的交付权限。每次尝试都记录验证结果、失败原因和操作来源。

验证没通过时，命令输出和诊断可以回流给Refiner。一旦超出迭代次数或预算上限，就停止自动尝试，按执行状态处理本地改动并转成报告项；已经发生的远端动作则要单独处理。留出这些边界，是为了让风险识别、修复建议和实际交付各有可核查的依据。

当前 Safe Autofix流程和权限机制的建设已经完成，快照里自动修复的记录是 0。眼下重点还是风险识别、人工确认和安全边界验证，自动修改的数量并没有被当成建设目标。

能生成、能编译测试代码，不等于测试就验对了业务行为。如果 Agent 拿实现代码推出预期值，再拿这个值去检查同一段实现，代码里的错误很可能被一起写进断言。测试里的 Oracle Problem 说的就是这件事：正确的预期结果该怎么确定。

我们的做法是给预期标来源。需求文档里的业务规则，能提供独立于实现的依据；提交说明有助于理解意图，但仍要核对；只从实现代码推出来的预期，只能说明代码现在怎么跑，不能单独证明业务是对的。阶段一提取requirement_expectations[]，把规则和它的适用条件交给后续阶段。拿不到独立规则时，就该明确说验证能力受限，而不是把代码行为直接当成业务标准。

对关键风险点，我们会比对实际响应、需求规则和用例断言三者是否一致，并设计能区分目标行为与错误行为的场景。比如业务规则确实要求输出不同时，合法输入和非法输入的断言就该不一样。正反向检查能提高测试的辨别力，但有限用例通过，不等于所有实现路径都被证明正确；需求本身准不准，还得靠人判断。

AgentLoop 分四个核心阶段：变更分析、测试用例设计、测试方案设计、自动化实现，由此产出测试资产；后续验证则靠执行验证、失败诊断、覆盖率分析和报告汇总来完成。初始化只是运行前的准备。

图 3 测试工作流。①—④是四个核心阶段，⑤—⑧是执行验证、失败诊断、覆盖率分析和报告汇总。上游设计回溯须经人工确认。

相邻核心阶段之间都安排了人工审阅。阶段四可以在本阶段内做受限修订；一旦失败根源出在上游的业务理解或测试设计，就要停下来请求人工确认，不能绕过已经通过的审阅环节。这样"测什么""怎么测""代码怎样实现"能分开检查，不同层次的问题不会混在一次生成里处理。

图 4 是脱敏后的工作流界面，阶段、时间线、产物列表都列在其中。初始化这类准备节点以及人工确认环节，界面上同样能看到；这张图要说明的是工作流怎么组织。

Kbase用于补充代码差异中缺少的环境知识，例如缓存规则、Mock 方式和 TestBase差异体现在：相关知识以结构化条目的形式，被带入用例设计、方案设计和实现阶段，并跟着知识库与仓库的更新一起同步。它给环境适配提供的是上下文，需求规则对测试预期的约束，它替代不了。

用例执行失败后，先分清是环境瞬时问题、数据残留、用例自身问题、预期错误，还是服务实现缺陷。归因要看请求、响应、环境状态和独立需求依据；证据不够就保留"待判定"，不能为了把测试弄通过就反过来改判断标准。

自愈守三条约束：预期修订必须有独立依据，不能照抄实际响应；不许靠删断言或降精度把失败盖过去；所有修订都要留记录。目前工作流会把修订达到三次的用例标为弱验证，作为人工复核的管理提示。修订次数本身不决定断言对不对，验证结论仍看独立预期、执行结果和覆盖范围。碰上上游规则或设计变更，必须回到人工确认。

研发侧和测试侧现在主要靠人工确认来衔接产物，统一协议、自动交接和结果回流都还在建设中。

拿营销业务里一次涉及行业类型与静态券面额的变更来说，研发侧关心新增行业类型有没有漏掉兜底处理，测试侧把这个风险转成了可执行的用例。下面按该任务的案例记录，讲风险怎么发现、七条用例怎么设计、TC-03 返回差异、开发补充分支和复测的处理过程。应用和仓库名称用代称。

这条 Finding后续测试的关注点因此收窄成一个具体问题：行业参数一旦变化，静态券面额会不会偏离业务规则。研发侧负责讲清代码里哪些处理路径可疑，测试侧要定下合法输入与非法输入各自应得的返回结果，再跑实际执行核对两者是否对得上。

具体推进分四个核心阶段。阶段一对着需求，梳理行业参数与券面额的预期；阶段二把预期展开成七条用例，其中包括TC-03比对合法与非法行业输入下的返回差异；阶段三把用例对应到数据准备、接口调用和执行条件上；阶段四做完自动化实现并运行。研发侧提出的兜底风险，就这样落到了具体输入与断言上。

那一次测试设计把断言约定为“合法行业参数返回配置面额、非法行业参数返回兜底值”，TC-03验证就围绕这一区别展开。这里给出的是该次测试采用的预期；需求对规则适用范围的表述并不一致，所以本案例只用于说明返回差异及其处理过程，不据此认定全部业务约定都已验证过。

首次执行TC-03执行时，非法行业参数返回的是配置面额，与用例设定的兜底值预期不符。这一失败把前面的代码风险变成了一组具体的输入、预期与实际结果，排查也集中到非法行业输入对应的处理路径上。

案例记录显示，开发随后定位到缺少兜底分支并补上了处理；之后TC-03 复测通过，Finding被记为“已验证修复”。研发识别的风险、用例执行暴露的差异、代码修改与复测结果，由此串在了一起。这里报告的验证结果只限于TC-03的处理记录。

本次记录写的是TC-03只记录了这条风险首次执行以及后续处理的过程，另外六条用例跑出来什么结果并未纳入，全部请求、响应和断言同样没有展示。换句话说，它呈现的是一条风险如何被定位、如何被复测，至于整条业务链路验证得全不全，靠它判断不了。要拿到完整的交付证据，还得把独立业务规则、修复前后版本和对应的执行结果一并关联起来。

案例中需要对应的内容很具体：新增行业类型的变更、兜底路径Finding、TC-03的输入与预期、首次执行出现的返回差异、开发对分支的修复，以及复测结果和Finding只有把这些信息收进同一条记录，读者才能顺着线索看清：发现了哪类风险、后来改了什么、又凭什么判断改动生效了。

为了让这种关联逐步统一起来，拟定的证据模型只保留几个核心字段：用来标识变更和版本的信息，change_id 与 source_revisionclaim /locator以及说明风险或验证结论、并交代其依据的内容；状态上则区分待验证、人工确认和执行验证三种。需求依据、代码改动和运行结果靠同一套标识串起来，交付判断才有被复查的可能。verification_status

这个案例呈现的，是风险、用例、代码处理与结果记录彼此如何对应。统一协议、跨侧自动交接和自动回流目前还属于建设目标；图里的箭头只表示处理的先后顺序。

案例里这种协同方式的做法是：研发发现的风险被带进具体测试场景，执行结果再被记入问题处置记录。任何一项交付判断，都得讲清依据、版本和验证范围，出现分歧时才能回溯到具体的输入和结果。

看板上标记为可信修复的是 50/94，也就是 53.2%；上报修复 60 项，其中有 10 项属于行号漂移造成的误判。Autofix这项记录为 0——两种修复记录的口径并不一样。

图中 6、7、8 月标签下分别列出 13、19、14 个工作项，合计 46 个；完成比例反映的是这些工作项的流程状态。图中所说的“全链路交付”指的是这条测试工作流，并不意味着研发与测试之间的自动交付已经打通。

第一组数据反映单仓库看板里的问题处置状态，其中记录为 0；第二组数据反映的是图中工作项的流程完成状态。流程走完和业务验证通过是两回事，仅凭一次快照也看不出整体质量或效率有何变化。Autofix

这套做法更适合业务规则清楚、环境可控、结果能观测的场景。碰上需求规则不全、并发时序复杂或者结果带概率性的情况，还是得靠人工判断，配合其他验证手段。眼下两侧能力已各自落地，统一协议、自动交接和交付门禁还在建设中。