human-verify

name	human-verify
description	Multi-perspective code verification that simulates human review. Combines adversarial debate (Devil's Advocate), reverse verification, boundary testing, and user scenario simulation to catch issues that compilers and linters miss. Trigger words: "/verify", "验证一下", "帮我检查".

多角度模拟验证

版本：v1.0.0 | 状态：已落地 | 触发：/verify、"验证一下"、"帮我检查"

完成代码后，用完全不同的视角交叉验证——不是"能不能跑"，而是"对不对、全不全、稳不稳"。

目录

• 核心理念
• 验证策略矩阵
• 执行流程
• 输出模板
• 端到端示例
• 安全规则

核心理念

三层验证架构（灵感来源：对抗式多 agent review + 人类审查思维）

Layer 1: 对抗式辩论    — "如果我是 Reviewer，我会质疑什么？"
Layer 2: 多角度交叉    — 逆向追踪 / 边界探测 / 场景模拟 / 数据流追踪
Layer 3: 需求-代码对齐  — 双向推导，需求说了什么 vs 代码做了什么

验证策略矩阵

根据变更类型选择 2-3 种组合：

变更类型	必选验证	推荐补充
API 端点	逆向验证 + API 契约	Devil's Advocate
UI 组件	用户场景模拟 + 状态机	边界测试
数据处理	数据流追踪 + 边界测试	逆向验证
业务逻辑	双向推导 + Devil's Advocate	用户场景模拟
重构代码	行为对比 + 回归场景	数据流追踪
配置变更	环境矩阵 + 边界测试	—

执行流程

验证进度：
- [ ] Step 1: 扫描变更范围 (git diff)
- [ ] Step 2: 按策略矩阵选择 2-3 种验证方式
- [ ] Step 3: Devil's Advocate 轮次（优先级排序）
- [ ] Step 4: 执行选中的交叉验证方法
- [ ] Step 5: 发现问题 → 修复 → 再验证（反馈循环）
- [ ] Step 6: 输出验证报告

Step 1: 扫描变更范围

git diff --name-only HEAD~1    # 或 git diff --name-only

Step 2: 选择验证策略

根据文件类型和策略矩阵，选择 2-3 种验证方式。

Step 3: Devil's Advocate 轮次

按优先级顺序质疑代码（不要跳级）：

优先级 1: 正确性    — "这段逻辑能产生正确结果吗？"
优先级 2: 错误处理  — "异常路径覆盖了吗？"
优先级 3: 安全性    — "有注入/越权/信息泄露吗？"
优先级 4: 性能     — "N 大时会爆吗？"
优先级 5: 可维护性  — "三个月后能看懂吗？"

每个优先级执行：

1. 质疑：提出具体的代码问题（引用行号）
2. 辩护：从作者角度为代码辩护
3. 裁决：问题是否成立？成立则记录为 finding

当某个优先级无实质问题时，跳到下一级。

Step 4: 交叉验证方法

9 种方法的详细步骤 → 见 reference/methods.md

方法速查：

#	方法	一句话	适用
1	逆向验证	从期望输出反推代码是否能到达	核心流程
2	边界测试	null/空/超长/并发等刁难数据	输入处理
3	用户场景模拟	假装用户逐步操作	UI/流程
4	数据流追踪	追踪关键字段从入口到出口	数据处理
5	双向推导	代码做了什么 vs 需求要什么	业务逻辑
6	API 契约验证	参数/响应/错误码是否符合约定	API
7	状态机验证	状态转换是否完整、非法转换是否阻止	状态流转
8	行为对比	重构前后行为是否一致	重构
9	Devil's Advocate	按优先级对抗式质疑	所有

Step 5: 反馈循环

发现问题 → 评估严重度 → 修复代码 → 针对修复点再验证 → 确认修复
    ↑                                                    │
    └──── 如发现新问题 ────────────────────────────────────┘

• 高严重度问题：立即修复，再验证
• 中严重度问题：记录到报告，建议修复
• 低严重度问题：记录到报告，标记为建议

Step 6: 输出验证报告

输出模板

# 验证报告

> **变更**: [文件列表] | **类型**: [API/UI/逻辑/重构]

## Devil's Advocate 轮次

| 优先级 | 质疑 | 辩护 | 裁决 |
|--------|------|------|------|
| 正确性 | {具体问题} | {辩护理由} | 通过 / 需修复 |
| 错误处理 | ... | ... | ... |

## 交叉验证

### [验证方法名称]
- 过程: ...
- 发现: ...

## 发现汇总

| # | 问题 | 严重度 | 状态 |
|---|------|--------|------|
| 1 | {问题描述 + 文件:行号} | 高/中/低 | 已修复 / 待修复 |

## 结论
- 验证通过
- 验证通过，有建议: ...
- 验证未通过，需修复: ...

端到端示例

场景：验证新增的 POST /api/defect-agent/reports 端点

# 验证报告

> **变更**: DefectAgentController.cs, DefectReportService.cs | **类型**: API

## Devil's Advocate 轮次

| 优先级 | 质疑 | 辩护 | 裁决 |
|--------|------|------|------|
| 正确性 | CreateReport 未校验 templateId 是否存在 | 服务层 GetTemplateAsync 返回 null 时抛 NotFoundException | 通过 |
| 错误处理 | 并发提交同名缺陷会怎样？ | 缺陷名不要求唯一，各自创建独立记录 | 通过 |
| 安全性 | 用户能访问其他项目的模板吗？ | 服务层按 projectId 过滤 | 通过 |

## 交叉验证

### 边界测试
- 空 title → 返回 400（通过）
- title 超 500 字 → 无长度限制（注意：应加 MaxLength）
- fields 空数组 → 允许提交（符合设计，模板可选）（通过）

### 逆向验证
- 期望：创建报告 → 写入 DB → 返回 reportId
- 追踪：Controller → Service.CreateAsync → Repository.Insert（通过）
- 审计日志：未记录创建操作（未通过）

## 发现汇总

| # | 问题 | 严重度 | 状态 |
|---|------|--------|------|
| 1 | title 无长度限制 | 中 | 待修复 |
| 2 | 缺少创建操作审计日志 | 低 | 建议 |

## 结论
验证通过，建议添加 title 长度限制

安全规则

1. 不修改代码：验证技能只读不写，发现问题记录到报告，不自动修复
2. 不重复已有测试：已有单元测试覆盖的点不重复验证
3. 适度验证：简单改动用 1-2 种方法，复杂改动用 3-4 种
4. 诚实记录：不确定的问题标记为"需人工确认"，不猜测

上下游技能

/risk → 设计阶段风险评估
          ↓
      代码实现
          ↓
/verify → 本技能（验证）  ← 你在这里
          ↓
/smoke → 冒烟测试（端到端 curl）
          ↓
/handoff → 交接清单