从风险识别到验证闭环：高德营销AI质量工程实践
阿里云开发者 · 软件开发
高德技术 2026-11-05 10:15 浙江 阿里妹导读 文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。 一、问题背景 本文所说的 AI 质量工程，是将 AI 的分析与执行能力纳入软件质量保障过程的一种工程实践：由 AI 辅助识别风险、设计测试和执行验证，通过明确的业务规则、权限边界、人工审阅与运行记录，约束其判断和动作。它关注的是每一条建议如何被验证、每一次修改如何被追踪，以及最终凭什么作出交付决定。 AI 参与软件交付后，团队需要解决两个相连的问题：研发侧如何识别值得处理的风险，测试侧如何验证这些风险是否已经得到控制。只有把风险依据、测试预期和实际运行结果关联起来，"发现问题"才能进一步转化为可追溯的交付依据。 在高德营销业务中，我们分别建设了研发侧的 Graph Engineering 决策图和测试侧的 AgentLoop 工作流。前者围绕代码变更组织多角色评审，输出风险、代码位置及验证条件；后者围绕业务规则完成变更分析、用例设计、测试方案设计和自动化实现，产出测试资产与运行记录。本文沿着"研发识别风险—测试验证风险—形成交付证据链"介绍这两侧实践。 目前，研发风险识别与测试验证能力已分别落地。统一任务协议、跨侧自动交接、结果回流和交付门禁仍在建设。本文分别介绍已落地的能力、案例记录及后续协同设计。 图 1 研发决策图与测试交付图的协同设计。统一证据协议与跨侧自动回流为后续建设方向。 二、研发侧风险识别 决策图如何形成可验证的风险结论 研发侧以研发平台中的应用为入口，组织仓库、分支、扫描范围和验证命令等上下文。评审由规则与 Agent 配合完成：规则处理边界明确的问题，Agent 结合代码、需求和历史信息识别需要进一步判断的风险。 我们用 LangGraph StateGraph 显式组织评审过程。 Generator 先形成基础 Finding ； PM 、 QA 、 Developer 、 SRE 、 Security 等角色并行审查需求边界、测试条件、稳定性和安全性； Reducer 合并重复结论； Judge 判断有效性、严重度和处理优先级。在策略允许时， Executor / Refiner 再生成修复方案，并根据验证诊断进行有限次数的迭代。 图 2 多角色评审决策图，包括角色分工、结论合并与诊断回路。 这张决策图的输出不仅是修改建议，还要说明风险是什么、判断依据位于哪里，以及需要什么结果才能确认风险得到处理。例如，"新增枚举未覆盖兜底分支"需要同时给出变更位置、可能受影响的业务条件和待验证场景，才能成为测试侧可继续使用的输入。 安全修复权限阶梯 风险判断与执行权限分开管理。 Safe Autofix 将修复流程拆分为以下动作，各动作由策略分别控制： proposal → dry-run → apply → verification → commit → push → optional MR 进入修复前，先检查策略白名单、风险等级、置信度和证据锚点；实际修改前执行 dry-run ，修改后运行仓库验证。 commit 、 push 和 MR 分别受控，验证通过本身不会自动开启后续交付权限。每次尝试均记录验证结果、失败原因及操作来源。 验证失败时，命令输出与诊断可以回流给 Refiner 。超过迭代或预算上限后，停止自动尝试，按执行状态处理本地改动并转为报告项；已经发生的远端动作需要单独处理。保留这些边界，是为了让风险识别、修复建议和实际交付各自具有可核查的依据。 当前 Safe Autofix 主要完成了流程和权限机制建设，相关快照中自动修复记录为 0，现阶段仍以风险识别、人工确认和安全边界验证为主，尚未将自动修改数量作为建设目标。 三、测试侧验证闭环 Oracle Problem：预期结果从哪里来 能够生成和编译测试代码，并不意味着测试验证了正确的业务行为。假如 Agent 从实现代码推导出预期值，再用这个值检查同一段实现，代码中的错误可能被一并写进断言。这就是测试中的 Oracle Problem：如何确定正确的预期结果。 我们的处理方式是标注预期来源。需求文档中的业务规则可以提供独立于实现的依据；提交说明可辅助理解意图，但仍需核对；仅从实现代码推导的预期只能说明代码行为，不能单独证明业务正确。阶段一提取 requirement_expectations[] ，把规则及其适用条件传递给后续阶段。缺少独立规则时，应明确验证能力受限，而不是把代码行为直接提升为业务标准。 对关键风险点，我们比较实际响应、需求规则和用例断言是否一致，并设计能够区分目标行为与错误行为的场景。例如，在业务规则确实要求不同输出时，合法与非法输入应有不同断言。正反向检查能提高测试的辨别能力，但有限用例通过不等于