代码测试核查技能
# 当 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 拉满的时候，测试需要的不是更努力地加班，而是更聪明的工具。
