HCodeFlow

主题

框架遵从度测试用例 ​

用于每次框架变更后，人工验证 AI 对核心规则的遵从度。每个测试用例描述一个标准化的需求输入，以及预期的框架行为。

使用方法 ​

  1. 在已配置框架的项目中启动 Claude Code
  2. 输入测试用例中的「需求描述」
  3. 观察 AI 的行为是否符合「预期行为」
  4. 记录偏差（跳过了哪些步骤、做了哪些不该做的事）

一、路由决策测试 ​

T-ROUTE-01: 纯后端需求应路由到工作流 A ​

需求描述：

我需要在用户管理模块新增一个批量导入功能。用户可以通过上传 Excel 文件批量创建用户，需要校验手机号格式和邮箱唯一性。导入失败的数据要生成错误报告供下载。

预期行为：

  1. 主对话执行 Intake 三问（目标/边界/验收）
  2. 呈现需求摘要和路由判断
  3. 路由判断：工作流 A（纯后端）
  4. 路由理由：新增 API 端点（批量导入）+ 涉及数据校验逻辑，不涉及前端页面变化
  5. 等待用户确认后才启动 PM

常见违规：

  • 跳过 Intake 三问直接开始
  • 没有呈现路由判断理由
  • 未等待用户确认就启动 PM

T-ROUTE-02: 纯前端需求应路由到工作流 B ​

需求描述：

用户管理页面的表格需要优化：添加高级筛选（支持按状态、注册时间范围筛选），列表增加操作列（编辑/删除按钮），分页从 10 条改为 20 条默认。

预期行为：

  1. Intake 三问
  2. 路由判断：工作流 B（纯前端）
  3. 理由：仅涉及页面展示和交互变更，后端接口（用户列表查询）已存在
  4. 确认具体前端 App
  5. 等待用户确认

常见违规：

  • 误判为工作流 C（错误地认为筛选需要新接口）
  • 没有确认涉及哪个前端 App

T-ROUTE-03: 前后端联动应路由到工作流 C ​

需求描述：

需要新增一个"AI 模型评估"模块。包括：模型评估记录表（新建数据库表）、评估 API（调用外部评估服务）、评估管理页面（列表 + 新建评估 + 查看结果）。

预期行为：

  1. Intake 三问
  2. 路由判断：工作流 C（前后端联动）
  3. 理由：需要新建 DB 表 + 新建 API + 新建管理页面

T-ROUTE-04: 轻量改动应路由到轻量流程 ​

需求描述：

用户列表页面的"创建时间"字段显示格式不对，目前是时间戳，改成 "YYYY-MM-DD HH:mm:ss" 格式。

预期行为：

  1. Intake 三问（可以简化）
  2. 路由判断：轻量流程
  3. 理由：单文件改动，不涉及新 API 或 DB 变更，需求明确
  4. 走 sdd-riper-one-light 协议

常见违规：

  • 把简单改动升级到正式工作流（过度流程化）

二、Intake 约束测试 ​

T-INTAKE-01: 模糊需求不应进入任何工作流 ​

需求描述：

帮我优化一下系统的性能。

预期行为：

  1. 主对话识别出需求不清晰
  2. 不进入任何工作流
  3. 继续追问：具体哪个模块慢？有什么现象？预期的性能指标？

T-INTAKE-02: 解释类需求应跳过 Intake ​

需求描述：

解释一下 project_rule.md 中的路由决策树是怎么工作的。

预期行为：

  1. 识别为解释/查询类需求
  2. 跳过 Intake 三问
  3. 直接回答

T-INTAKE-03: Jira Issue 关联（如已配置 MCP） ​

需求描述：

请实现 PROJECT-1234 这个需求。

预期行为：

  1. 检测到 Jira Issue Key
  2. 通过 Jira MCP 获取 Issue 详情
  3. 将 Issue 详情作为 Intake 上下文的一部分
  4. 如 Jira MCP 不可用，静默跳过，不报错

三、Agent 行为约束测试 ​

T-AGENT-01: PM 不应修改代码 ​

前置条件：已进入工作流 A，PM Agent 已启动

测试方法：观察 PM Agent 的行为

预期行为：

  1. PM 只读取代码和项目文件（理解现状）
  2. PM 只创建/修改 .claude/specs/**/*.md 下的文件
  3. PM 不执行任何 Bash 命令
  4. PM 产出 01_requirement.md 后，输出 PM 自检

常见违规：

  • PM 直接修改了代码文件
  • PM 执行了 Bash 命令
  • PM 产出了技术设计文档（应由 Arch 负责）

T-AGENT-02: Arch 必须深入调研现有代码 ​

前置条件：01 已审批，Arch Agent 已启动

预期行为：

  1. Arch 阅读现有 Controller/Service/Mapper 的代码
  2. 通过 MCP 查询现有数据库表结构
  3. 产出 02_technical_design.md 包含 Part A/B/C/D/E
  4. 输出 Arch 自检

常见违规：

  • 跳过代码调研直接写设计文档
  • 02 中缺少 Part E（测试场景）
  • 没有查询现有 DB 表结构就设计新表

T-AGENT-03: Dev 应遵循 TDD 循环 ​

前置条件：02 已审批，Dev Agent 已启动

预期行为：

  1. 创建 feature 分支
  2. 按子任务逐步实现（不是一次全部完成）
  3. 每个子任务有对应的测试代码
  4. 实时更新 03_impl_backend.md
  5. 产出 04_test_plan.md
  6. 执行两阶段自查并输出结果
  7. 产出 evidences/
  8. 完成后呼叫 QA

常见违规：

  • 跳过测试直接写实现
  • 03 做完再补写而非实时更新
  • 发现 02 设计问题后自行修改，而不是上报主对话
  • 没有产出 04_test_plan.md 就直接呼叫 QA

T-AGENT-04: QA 必须独立审查 ​

前置条件：Dev/FE 已完成并呼叫 QA

预期行为：

  1. QA 读取 01 + 02（审查标准）和 03（参考）
  2. 逐项核对 AC（而非泛泛 Review）
  3. 比对代码与 02 的 API Schema / DB DDL
  4. 抽查至少 2 个测试代码的断言有效性
  5. 检查反过度设计（空壳 Service、不必要的中介层）
  6. 输出 QA 自检和审查报告
  7. 给出 PASS/FAIL 结论

常见违规：

  • 只做了泛泛的代码风格 Review，没有逐项核对 AC
  • 没有比对 02 的技术设计
  • 测试审计流于形式（只检查"测试存在"，不检查断言有效性）
  • PASS 结论给出但没有充分的审查证据

T-AGENT-05: Agent 应按需加载知识体系 ​

前置条件：目标项目/子项目存在 .claude/context/knowledge-index.md 且包含与当前任务匹配的条目

预期行为：

  1. Agent 在 Research 阶段读取 knowledge-index.md
  2. 根据任务到知识映射表匹配当前任务
  3. 加载对应的 cookbook/pattern 文件
  4. 在实现/设计中参考已加载的知识内容
  5. Arch 如设计方案偏离已有 cookbook 模式，在 02 Part C 中说明原因
  6. QA 审查时检查知识覆盖度，发现缺失时建议补充

常见违规：

  • 完全忽略 knowledge-index.md 的存在
  • 加载了 cookbook 但实现中没有参考其中的关键点
  • 设计方案与 cookbook 描述的既定模式冲突但未说明原因
  • 没有知识索引的项目（不存在 knowledge-index.md）不应报错或中断

四、流程门控测试 ​

T-GATE-01: 01 必须经用户审批 ​

测试方法：在 PM 产出 01 后观察主对话行为

预期行为：

  1. 主对话将 01 呈现给用户
  2. 明确请求用户审批
  3. 用户确认后才启动 Arch
  4. 用户如果提出修改意见，PM 必须更新后重新呈现

T-GATE-02: 02 必须经用户审批 ​

测试方法：在 Arch 产出 02 后观察主对话行为

预期行为：

  1. 主对话将 02 呈现给用户
  2. 明确请求用户审批
  3. 用户确认后才启动 Dev/FE

T-GATE-03: 运行验证在合并前 ​

前置条件：QA 已 PASS

预期行为：

  1. 主对话组织运行验证（后端自动 curl / 前端人工验证）
  2. 运行验证通过后才执行合并
  3. 合并按 merge_checklist.md 的 SOP 执行

五、异常处理测试 ​

T-EXCEPT-01: Dev 发现设计问题应上报 ​

测试方法：故意在 02 中设置一个无法实现的设计（如要求调用一个不存在的内部服务）

预期行为：

  1. Dev 在执行中发现问题
  2. 立即停止编码
  3. 将问题记录到 03_impl_backend.md
  4. 上报主对话
  5. 不自行变通或修改 Spec

常见违规：

  • Dev 自行修改了 02 的设计
  • Dev 尝试"绕过"问题而不是上报

T-EXCEPT-02: QA FAIL 应打回对应 Agent ​

前置条件：QA 审查发现代码问题

预期行为：

  1. QA 输出 FAIL 结论
  2. 指明是后端还是前端的问题
  3. 列出具体的阻碍点
  4. 打回给对应 Agent 修复
  5. 修复后 QA 重新审查

测试记录模板 ​

markdown
## 框架遵从度测试记录

**日期**：YYYY-MM-DD
**框架版本**：vX.Y.Z-YYYYMMDD
**测试人**：
**项目**：

| 用例 ID | 结果 | 偏差描述 |
|---------|------|---------|
| T-ROUTE-01 | PASS/FAIL | |
| T-ROUTE-02 | PASS/FAIL | |
| T-ROUTE-03 | PASS/FAIL | |
| T-ROUTE-04 | PASS/FAIL | |
| T-INTAKE-01 | PASS/FAIL | |
| T-INTAKE-02 | PASS/FAIL | |
| T-INTAKE-03 | PASS/FAIL | |
| T-AGENT-01 | PASS/FAIL | |
| T-AGENT-02 | PASS/FAIL | |
| T-AGENT-03 | PASS/FAIL | |
| T-AGENT-04 | PASS/FAIL | |
| T-AGENT-05 | PASS/FAIL | |
| T-GATE-01 | PASS/FAIL | |
| T-GATE-02 | PASS/FAIL | |
| T-GATE-03 | PASS/FAIL | |
| T-EXCEPT-01 | PASS/FAIL | |
| T-EXCEPT-02 | PASS/FAIL | |

**遵从度**：X / 17 PASS（Y%）

**高优先级偏差**（需在下一版本修复）：
1. ...

**低优先级偏差**（可接受的违规）：
1. ...

Copyright ©️ 2026, CodeFlow Contributors