| 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
Step 2: 选择验证策略
根据文件类型和策略矩阵，选择 2-3 种验证方式。
Step 3: Devil's Advocate 轮次
按优先级顺序质疑代码（不要跳级）：
优先级 1: 正确性 — "这段逻辑能产生正确结果吗？"
优先级 2: 错误处理 — "异常路径覆盖了吗？"
优先级 3: 安全性 — "有注入/越权/信息泄露吗？"
优先级 4: 性能 — "N 大时会爆吗？"
优先级 5: 可维护性 — "三个月后能看懂吗？"
每个优先级执行：
- 质疑：提出具体的代码问题（引用行号）
- 辩护：从作者角度为代码辩护
- 裁决：问题是否成立？成立则记录为 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-4 种
- 诚实记录：不确定的问题标记为"需人工确认"，不猜测
上下游技能
/risk → 设计阶段风险评估
↓
代码实现
↓
/verify → 本技能（验证） ← 你在这里
↓
/smoke → 冒烟测试（端到端 curl）
↓
/handoff → 交接清单
