# 当 AI 写代码比测试还快时我们造了一个「代码测试核查器」Code Test Check — ClawHub 开发越来越快测试却还在原地踏步。与其让 QA 拿着 PRD 一行行去对代码不如让 AI 先帮你把实现度查清楚。## 一、背景AI 加速下的质量左移困境过去一年团队的交付节奏被 AI 编码助手显著拉快。一个功能从需求评审到提测的周期被压缩到了原来的几分之一——一个上午就能产出几百行 Controller Model Vue 页面。开发侧的**交付速率Delivery Velocity**上去了但测试侧的**验证吞吐Verification Throughput** 并没有同步提升两者之间出现了一条越来越宽的速度差。这条差值直接反映在了几个关键的**质量度量指标**上- **缺陷发现阶段Defect Detection Stage后移**越来越多的问题被推迟到系统测试、甚至验收测试阶段才暴露——功能没实现实现与需求偏离改 A 坏了 B。- **缺陷泄漏率Defect Leakage Rate上升**本应在编码阶段拦截的缺陷泄漏到了下游甚至流到生产。- **回归测试Regression Testing成本攀升**AI 生成的改动面更广、触及的共享代码资产更多传统基于经验的**影响范围评估Impact Analysis** 越来越难覆盖全。这背后是一个被反复验证的工程常识——**缺陷修复成本曲线Cost of Defect Curve**缺陷发现得越晚修复代价呈指数级上升。同一个漏实现在编码当天发现和到系统测试阶段发现修复成本可能差上一个数量级。修复成本▲│ ╱ 生产/验收阶段发现│ ╱│ ╱ 系统测试阶段发现│ ╱│ ╱ 单元/编码阶段发现│ ╱│ ╱ 需求/设计阶段发现└──────────────────────────────────→ 时间轴左移的目标把缺陷拦截在这里 ↑这正是业界倡导多年的 **「测试左移」Shift-Left Testing** 想要解决的核心命题。 **测试左移**将质量验证活动从 SDLC 的右端系统测试、验收测试尽量向左端需求分析、设计评审、编码、静态检查推移**在缺陷最便宜的阶段把它拦截**。它依赖三块能力需求可测性分析Testability Analysis、静态测试Static Testing如评审/走查/静态分析、以及需求-代码可追溯性Traceability。理想中真正落地的左移要求 QA 在开发**提测的当下**而非等系统测试就能回答这三个问题1. **需求覆盖率Requirements Coverage**PRD 里的 N 个验收点源码到底实现了多少——这是**需求-代码可追溯性**问题。2. **实现符合度Implementation Conformance**实现方式与需求规约一致吗有没有偏离规约Deviation——这是**静态测试**要回答的。3. **变更影响范围Change Impact Analysis**本次改动触及的共享资产Model/字段/接口/常量波及了哪些既有模块是否引入**回归风险**——这是**回归测试范围界定**问题。但现实是要回答这三个问题QA 传统上必须执行**人工代码走查Code Walkthrough**——逐个打开后端路由、Controller、Model、前端视图文件去比对。这是一项**高度依赖人力、易疲劳、易遗漏**的活动。左移理念喊了很多年之所以难规模化落地根因就在于**它要求 QA 具备在编码阶段低成本读懂代码的能力而这恰恰是大多数团队缺失的一环。**于是我们想**既然 AI 能写代码那它同样能做静态代码分析——为什么不让 AI 把需求 ↔ 代码的可追溯性核查在编码阶段就先跑一遍**这就是 code-test-check代码测试核查器诞生的原因。本质上它是**测试左移的一次工程化落地**把需求落地核查这项原本属于静态测试的活动用 AI 自动化执行在代码提交当下就建立**需求-代码追溯矩阵**、识别**偏离规约**、圈定**回归影响范围**让缺陷在它修复成本最低的阶段被暴露。## 二、它是什么一个证据驱动的需求落地核查器先说清楚它的定位避免误解。code-test-check **不是**- ❌ 自动生成测试用例的工具那是 test-case-generator 的活- ❌ 自动生成自动化测试脚本的工具那是 auto-test-writer 的活- ❌ 代码质量/规范审查工具那是 domain-code-reviewer 的活code-test-check **是** 给它一份 **PRD 需求文档** 或 **功能测试用例**Excel/JSON它会在前后端源码里**逐条核查**这些功能点到底有没有被实现最后输出一份**带代码证据的 Markdown 验证报告**。一句话概括**它解决的是需求有没有落地到代码这个测试前置环节帮你在动手测之前先知道哪里没做、哪里做歪了、哪里有回归风险。**## 三、核心设计四条不可违背的原则这个技能最关键的地方不在于能搜索代码而在于它对自己提出了几条**克制**的约束。我认为这正是它可靠性的来源。### 原则 1证据驱动 —— 没有代码位置就不许说已实现每一个实现状态的判定都必须附上**代码位置文件路径:行号**和**关键代码片段**。报告里每一条结论都是可点击跳转的。这意味着它不会给你一句空洞的该功能已实现而是直接告诉你去 app/admin/controllers/AbnormalReport.php:128 看这个方法。### 原则 2禁止臆测 —— 找不到就是找不到这是我觉得最关键的一条。AI 最容易犯的错就是脑补——因为这个功能很常见所以应该实现了。这个技能明确禁止这种行为**找不到对应代码就标记为未找到/未实现**严禁因为功能常见或AI 一般会写而假设其存在。测试核查最怕的就是假阳性——你以为实现了其实没有。宁可多报一个未实现让人去确认也不能漏报。### 原则 3只读分析 —— 不改代码、不连库、不调接口它只读取和分析源码绝不修改源码、不连数据库、不调用真实接口。这保证了核查过程**零副作用**可以随时跑、反复跑不会污染环境。### 原则 4必须分析关联影响 —— 防漏测的灵魂步骤只验证需求点本身会漏掉最大的风险**回归**。所以这个技能强制要求在验证完需求点之后追加一步**关联模块影响分析**- 识别本次改动触及了哪些共享代码资产模型/字段/接口/常量/公共方法- 反向追溯谁还在用这些资产- 评估每个调用方受波及的风险等级高风险/低风险/无影响这一步直接把回归测试范围给你圈出来了——这是手工核查最容易忽略、却最值钱的部分。## 四、它是怎么工作的六步工作流整个核查过程被拆解成清晰的六个步骤① 读输入材料 → ② 拆原子功能点 → ③ 逐条验证 → ④ 关联影响分析 → ⑤ 生成报告 → ⑥ 输出总结### 第一步读取并理解输入材料支持两种输入- **PRD 需求文档**Word/PDF/Markdown/纯文本提取功能模块、业务规则、字段要求、接口定义、约束条件。- **功能测试用例**Excel/JSON直接取每条用例的 expected预期结果作为验证标准——因为用例的颗粒度更细、可验证性更强。 当同时提供两者时以测试用例为验证主轴PRD 作为补充上下文。### 第二步构建原子化功能点清单把需求拆成**可独立验证的原子功能点**。好的拆解长这样- ✅ 移动端审批列表支持按状态筛选- ✅ 审批通过时必填审批意见- ✅ 驳回后状态回写为待处理- ❌ 实现移动端审批功能太大无法定位每个功能点都会标注归属是后端实现、前端实现、还是前后端协同。拆完会**先和你确认清单**再开始验证。### 第三步逐条验证核心对每个功能点用由广到窄的三段式搜索策略1. **语义搜索定位**用 SearchCodebase 按功能意图找代码不依赖精确关键词2. **精确匹配确认**用 Grep 按方法名/路由/字段/文案精确锁定3. **阅读代码验证逻辑**用 Read 读取命中代码核对逻辑是否真的满足需求最终给出四种状态之一| 状态 | 含义 ||------|------|| ✅ 已实现 | 找到代码且逻辑符合需求 || ⚠️ 部分实现 | 有相关代码但缺失分支/场景不完整 || ❌ 未实现 | 前后端都没找到 || 偏离需求 | 有代码但实现方式和需求不一致 |这里有个很实在的设计**关键词命中 ≠ 功能实现**。它会专门防空实现注释代码旧版残留这些假阳性——这正是手工核查和朴素 AI 搜索最容易踩的坑。### 第四步关联模块影响分析防漏测这是整个技能的灵魂。它会把第三步定位到的代码里被改动/新增的共享资产提取出来然后反向追溯调用方- 后端某个 Model 字段变了 → 搜索整个后端还有谁在读写这个字段- 某个常量/枚举变了 → 搜索所有引用它的条件分支极易遗漏- 某个接口入参/出参变了 → 前端所有调用方 后端所有内部调用最后输出一张关联调用方影响评估表把回归点按风险等级标出来。### 第五步 第六步生成报告 输出总结按固定模板生成 Markdown 报告包含实现情况总览统计摘要 实现矩阵、详细验证每个功能点的前后端证据、风险与遗漏、关联模块影响分析、回归测试建议清单。最后给你一句话总结**已实现 X / 部分 Y / 未实现 Z / 偏离 W高风险回归点 N 个。**## 五、它的价值把测试的起跑线往前挪回到最初的痛点。有了这个技能后测试流程变成了这样PRD 定稿 → 开发编码↓【code-test-check】需求落地核查 ← 新增的前置环节↓得到哪些没实现 / 哪些做歪了 / 哪里有回归风险↓QA 带着这份地图精准测试 → 提缺陷它带来的实际收益1. **测试前置缺陷左移**不用等手工测到才发现这个功能根本没写报告阶段就暴露了。2. **聚焦高风险区域**QA 可以把精力优先投到未实现偏离需求高风险回归点上而不是平均用力。3. **降低核查门槛**QA 不用硬啃源码AI 把证据链直接铺好点链接就能看代码。4. **防漏测**关联影响分析把人脑容易忽略的回归范围系统性地圈了出来。## 六、诚实地谈它的局限任何一个工具都应该坦诚它的边界这个技能也不例外。它在设计时就明确声明了**静态分析的局限**- **无法覆盖运行时行为**基于数据库配置/开关的动态逻辑、权限/角色控制的可见性、异步队列和定时任务的执行、第三方服务调用的实际响应——这些静态分析都判不了。- **报告是测试设计的参考输入不能替代实际运行时测试。**换句话说它能帮你回答代码里到底有没有实现、实现得对不对但回答不了跑起来到底正不正常。**它把测试的范围和重点告诉你剩下的验证还得靠真实运行。**## 七、写在最后AI 让代码产出变快本质上是把工程效率的瓶颈从写转移到了验。谁能更快、更全地把做没做对这件事查清楚谁就能接住 AI 带来的速度红利。code-test-check 的思路其实很简单**让 AI 干 AI 擅长的事大规模读代码、搜索、追溯调用链让人干人擅长的事判断业务正确性、设计测试策略、做运行时验证。** 它不替代测试而是给测试装上一张需求落地地图。当开发速度被 AI 拉满的时候测试需要的不是更努力地加班而是更聪明的工具。