本文来自花椒技术部真实工程实践。如果你也研究 AI 工程化、Agent 落地，没同行交流、没人拆解实战？可以关注公众号「花椒技术」，回复「AI」加入交流群。每日帮你从海量信息中捞干货，每天几分钟，快人一步看懂 AI 趋势。
过去，一个项目进入测试前，我们需要根据需求、测试用例和服务端代码冒烟测试一遍。中型项目完成同等范围的人工审查，通常需要一天；大型项目通常需要两天。
现在，我们把这套工作沉淀成服务端冒烟前置审查 Skill。一次真实调用里，520 活动这种大型新项目从发起审查到生成结构化报告，只用了 3 分半。
这里的审查，指正式功能冒烟前的一轮服务端代码侧检查：我们把需求、技术方案、测试用例和真实代码放进同一条链路，提前整理出需要 QA 与研发继续确认的问题。
这是《QA Skills 质量交付实践》的第三篇。第一篇讲六类 QA Skills 怎样进入质量交付流程；第二篇聚焦测试用例，聊了聊怎样用 AI 协同完成测试用例编写，感兴趣可以先看《我们自研了一个AI辅助生成测试用例平台》。这一篇只回答一个问题：过去按天计算的服务端冒烟前置审查，我们为什么能把它压缩到几分钟，以及这几分钟为什么不是以牺牲可信度换来的。
一、人工审查慢在上下文对齐，不是慢在看代码
如果只是看一段代码有没有语法问题、变量命名是否规范，花不了一天。
真正耗时的，是把分散在不同材料里的信息重新接起来：需求说了什么，技术方案怎样落，测试用例覆盖了哪些场景，入口代码在哪里，状态最后写到了哪里，异步任务执行时还保不保留触发时的上下文，结束后有没有回收，展示和真实执行的口径是不是同一套。
一个测试场景，往往要沿着多文件、多层调用继续往下追。看到接口返回成功还不够，看到日志已经记录也不够，中间事件已经投递同样不等于最终结果正确。QA 需要一直追到最终状态、最终副作用或真正生效的落点，才能判断这条用例在代码里有没有闭合。
老项目还多一层麻烦：代码里可能本来就有历史问题。如果不先锁定本次变更范围，审查很容易把旧问题、本次回归和普通优化建议混在一起，最后报告看起来很多，研发却很难据此行动。
这也是它和普通 Code Review 的区别。普通 Review 更容易从 diff 和局部实现出发，关注函数、变量、异常处理和工程规范；我们的服务端冒烟前置审查从测试用例里的业务条件出发，沿调用链追到最终状态、副作用和回收条件。它不替代 Code Review，而是补上"需求和测试场景是否真正进入代码"这一层检查。
如果这些上下文每次都由人从零整理、搜索和串联，审查时间自然会按天计算。要把它压缩到几分钟，第一步就是把这条重复发生的对齐路径固定下来。
二、第一步不是扫描代码，而是先把新项目和老项目分开
我们最初需要解决的一个问题是：能不能把所有服务端项目都交给同一个通用 Skill？
实际做下来，这条路很难成立。新项目和老项目表面上都在看需求、用例和代码，真正要回答的问题却不同。
新项目审查要回答的是：整份需求有没有做对、做全。它从完整需求和测试用例出发，把每个核心功能点映射到入口代码、核心判断、最终写入、展示通知和回收条件，再沿真实调用链逐项核对。
老项目审查先回答另一个问题：这次到底改了什么，这个问题是不是本次改动引入的。它从 diff、PR、分支或 commit 开始，向上寻找调用方，向下追到结果落点，同时检查旧字段、旧状态、旧配置和相邻链路是否仍然兼容。
两条路径可以这样理解：
| 维度 | 新项目审查 | 老项目审查 |
|---|---|---|
| 核心问题 | 整份需求是否做对、做全 | 本次改动是否引入真实问题 |
| 审查起点 | 完整需求与测试用例 | diff、PR、分支或 commit |
| 代码范围 | 从功能点追到最终结果 | 从变更点向上下游扩展 |
| 重点 | 功能遗漏、规则偏差、状态和副作用 | 回归、兼容性、变更遗漏 |
| 问题归属 | 判断是否属于当前需求 | 区分本次引入与历史存量 |
复杂迭代不一定只能二选一。大活动二期、老玩法重构这类需求，可以先用 old-project-smoke-review 锁定本次变更与回归风险，再按需要用 new-project-smoke-review 核对完整功能闭环。
先确定审查边界，再进入代码，是我们压缩审查时间的第一个取舍。它让 Agent 不必无边界扫描整个代码库，也减少了历史问题和本次变更混在一起造成的反复确认。
三、一次审查，实际要走完九个步骤
路径选好之后，Agent 才开始真正读取材料和搜索代码。
整条主链路可以概括成九步：
text
读取需求、技术方案和测试用例
→ 选择新项目或老项目路径
→ 建立完整功能映射，或先锁定本次 diff
→ 沿真实调用链追到最终状态与副作用
→ 形成候选问题池
→ 为每条候选项建立证据裁决卡
→ 排除推测、历史问题和普通优化建议
→ 只把证据成立的问题写入 HTML 报告
→ QA 与研发完成最终确认这九步是一次审查的全局主链路。新项目里的"功能点映射"，不是另一套并行流程，而是第三步"建立完整功能映射"的展开：我们会把一个功能点和需求、用例口径接起来，再依次核对入口代码、核心判断、最终写入或副作用、展示通知，以及回收和结束条件。
老项目则会先把范围收紧到本次改动，再检查修改点影响的上游入口和下游落点。写路径改了，读路径是否同步；状态变了，旧数据是否还能兼容；主链路改了，补偿、回滚、重试和通知是否遗漏。这些都要放回本次需求和 diff 中判断，不能因为代码里存在一个旧问题，就把它算成本次迭代的问题。
这里，测试用例不再只是审查前的一份附件。它提供了代码搜索的索引，也提供了边界条件和预期结果。Agent 沿着用例往代码里追，QA 和研发最后也能沿着同一条证据链回来复核。
当这条主链路和映射关系被固定下来，下一次审查就不再从"材料在哪里、代码从哪里看"开始。过去最耗时的上下文重建被复用，分钟级审查才有了稳定的执行路径。
四、候选问题进入报告前，先过证据门槛
AI 做代码审查最容易出现的一个假象，是"说得很像问题"。
看到一个校验没写在当前函数里，就推测系统没有校验；看到一个异步链路，就给出理论并发风险；看到一段代码可以重构，就把它包装成功能缺陷。这样的建议并不一定完全没价值，但它们不能直接进入一份用于测试前复核的正式报告。
因此，我们把"发现候选项"和"形成报告结论"拆成了两个阶段。每条候选项都要回答：
- 文档或测试用例到底要求什么；
- 真实代码现在怎样执行；
- 上游是否已经兜底；
- 调用链最后作用在哪里；
- 能被代码支持的最小实际影响是什么；
- 它属于当前需求、本次变更，还是历史存量；
- 这几类证据是否足以支撑正式输出。
拿一条已经脱敏的真实候选项来看：延迟执行任务在触发时没有固化完整上下文，真正执行时又读取当前状态。当排队期间状态发生变化，任务可能落到新的上下文，与触发时的场景出现偏差。
它能够进入结构化报告，不是因为"异步任务听起来有风险"，而是因为三类证据能够接上：需求和用例明确要求保留原始触发上下文；真实代码行为可以追到"触发时没有完整固化、执行时重新读取"；最小影响也能收敛到上下文偏移。
在这套规则里，以下内容默认不进入报告：
- 理论上可能发生，但当前代码链路无法证明的问题；
- 只有优化价值，没有实际功能影响的建议；
- 与本次变更无关的历史存量问题；
- 依赖假设场景、没有追到最终落点的推测；
- 证据只能证明"部分成立"的候选项。
同一根因造成的多个表象也要合并。比如目标功能没有接入某条限制，而相邻功能误接了同一条逻辑，这通常是同一个问题的正反两面，不应该拆成两条来增加报告数量。
还有一个看起来保守、实际很重要的规则：如果最终没有形成正式问题，也不能写"代码没有问题"。准确的说法只能是：当前输入材料和代码证据范围内，没有形成可输出的结论。
这两句话的差别，决定了报告是在表达证据，还是在替代码做超出证据范围的担保。
这些门槛并不是在分钟级审查之后再加一轮人工筛选，而是在 Agent 追踪代码时就尽早排除无证据推测、历史存量和普通优化建议。候选项更少、返查路径更短，QA 和研发也不用在一堆"可能风险"里反复辨真假。所以，我们得到的不只是更快的输出，而是一份可以继续复核和行动的分钟级报告。
五、为什么能快：把语义判断和确定性工作拆开
这套能力并不是把所有规则塞进一段长提示词里，也不是一个已经拥有统一任务调度器、规则引擎和主程序的平台。
真正的运行时是 Agent。它读取项目材料、搜索真实代码、追踪调用链、判断问题归属，再完成证据裁决。Skill 则把执行所需的导航、规则和确定性工具组织起来。
四层各自承担不同职责：
SKILL.md是导航入口，告诉 Agent 这次应加载哪些规则模块；references/保存功能映射、证据门槛、问题归属、排除条件和专项场景规则；scripts/负责测试用例读取、XMind 提取、HTML 报告渲染等适合程序化完成的稳定工作；agents/保存默认展示和调用配置，帮助运行时以一致方式识别对应 Skill。
这类分工把原来按天消耗的工作拆成了几类可以直接复用的动作：
| 原来的人工耗时 | 现在由谁处理 | 节省在哪里 |
|---|---|---|
| 每次重新整理需求和测试用例 | scripts/ 读取和提取 |
少做重复转换 |
| 每次重新回忆审查标准 | SKILL.md 与 references/ 按需加载 |
不再从零建立规则 |
| 人工来回搜索入口和调用链 | Agent 沿用例追踪真实代码 | 减少上下文切换 |
| 人工整理结论和报告格式 | scripts/ 渲染结构化 HTML |
减少重复归纳 |
Agent 因此可以把主要精力放在真正需要语义判断的部分：文档、用例与代码之间是否一致，调用链最终落在哪里，候选问题是否达到进入报告的证据门槛。
也正是在这个过程中，我们把测试用例从一份测试文档，变成了连接需求、代码审查、冒烟重点和人工复核的质量资产。
它在代码审查时成为功能映射的入口，在正式冒烟前帮助定位高风险路径，最后又作为 QA 与研发复核问题的共同依据。一份用例开始贯穿多个质量环节，而不是写完、执行完就留在文档里。
这也是从一天、两天缩短到几分钟的核心：我们没有要求 Agent 在每次任务里重新发明审查方法，而是把可重复的规则、材料处理和报告生成固化下来，只把需要理解业务语义的判断留给运行时。 skill目录：
六、规则复用，让"几分钟"不只发生一次
一套审查规则不会因为第一次写完就稳定。
真实项目会不断暴露新的漏审类型和误判方式。我们现在采用的维护方式是：先由 QA 和研发复核候选问题，确认问题根因；再判断需要补的是场景规则、证据条件还是排除条件；最后把经验放回对应的规则模块，同时保留原有规则和变更原因。
text
真实项目出现新的漏审或误判
→ QA 与研发复核根因
→ 补充场景规则、证据条件或排除条件
→ 保留规则变化与原因
→ 后续需求按需加载新规则这套方法已经在多个真实服务端需求中使用，能够稳定产出结构化审查结果，整体效果与人工审查基本一致。
更重要的是，真实需求里出现的新漏审类型和误判方式，会继续回到规则模块。下一次遇到相似场景，Agent 不需要从零摸索，团队也不必重复解释同一套判断。这样，"几分钟"就不再是某一次演示碰巧跑得快，而是规则不断复用之后可以重复获得的工程结果。
七、520 大型新项目：从两天到 3 分半
520 是一个使用 new-project-smoke-review 的大型新项目。同等范围的人工服务端代码侧审查通常需要两天；在一次真实调用中，Skill 从发起审查到生成报告只用了 3 分半。
再看报告是否只有速度。当前归档的另一份 520 报告列出了 10+ 条证据较完整、需要 QA 与研发继续确认的问题。它和上面的耗时记录不是同一份报告产物，因此我们不会把两份记录合并成"3 分半发现了 10+ 个问题"。
因此，这套方法缩短的是可以复用的材料处理、上下文对齐、代码追踪和证据整理；业务判断、风险取舍和最终质量结论，仍由 QA 与研发负责。只有把快的部分和必须由人负责的部分拆清楚，"两天到 3 分半"才是一个能够持续复用、也经得住复核的结果。
一句自然语言，怎样变成一次可追踪的接口验证
服务端冒烟前置审查解决的是：代码进入正式测试前，先把需求、用例和真实实现对一遍。进入正式测试后，下一步要解决的是，一句自然语言测试要求，怎样变成参数完整、过程可检查、结果可追踪的真实接口请求。
下一篇，我们会继续拆解花椒 QA 接口自动化 Skill 的工程实践。
以上是本期分享。我们技术群每天早晨推送一份**「AI 前线日报」**------聚焦 AI Coding 与具身智能，帮你从海量信息中捞干货，每天几分钟，快人一步看懂 AI 趋势。
扫码关注公众号「花椒技术 」，回复「交流群 」，和一群爱折腾的技术人一起，先人一步抓住 AI 红利。