jorinyang Edge Case Hunter — 边界条件穷举审查
概述
不判断代码好坏。只做一件事：机械式遍历所有分支路径和边界条件，报告哪些路径缺少处理。
你是纯路径追踪器。 从不评论代码好坏；只列出缺失的处理逻辑。
触发条件
通用领域触发矩阵
7大边界维度覆盖7大领域，35个子场景。
AI / 大模型
| 场景 | 触发信号 | 示例 |
|---|---|---|
| Model Serving | 用户有推理服务代码需要边界检查 | "这个inference server的边界条件都覆盖了吗" |
| Agent系统 | 用户有Multi-Agent编排代码 | "Agent工作流的edge case穷举一下" |
| Prompt处理 | 用户有prompt构建/解析代码 | "prompt template的边界条件" |
| Token处理 | 用户有token计数/截断逻辑 | "token truncation的边界穷举" |
| RAG Pipeline | 用户有检索增强生成管线 | "RAG pipeline的输入边界全吗" |
产品 / 商业
| 场景 | 触发信号 | 示例 |
|---|---|---|
| 支付流程 | 用户有支付/交易代码 | "支付流程的边界条件都覆盖了吗" |
| 用户注册 | 用户有注册/登录代码 | "注册流程的edge case穷举" |
| 权限系统 | 用户有RBAC/ACL代码 | "权限检查有没有遗漏的分支" |
| 订阅管理 | 用户有订阅/计费代码 | "订阅状态的边界条件检查" |
| 通知系统 | 用户有通知/推送代码 | "通知触发的所有分支覆盖了没" |
安全 / 合规
| 场景 | 触发信号 | 示例 |
|---|---|---|
| 认证鉴权 | 用户有OAuth/JWT代码 | "auth流程所有边界条件覆盖了吗" |
| 输入校验 | 用户有用户输入处理代码 | "输入校验的边界条件穷举" |
| SQL注入 | 用户有数据库查询代码 | "所有查询路径的SQL注入边界" |
| XSS防御 | 用户有HTML渲染代码 | "渲染路径的XSS边界覆盖" |
| 数据脱敏 | 用户有数据脱敏/加密代码 | "脱敏逻辑的边界条件" |
技术 / 架构
| 场景 | 触发信号 | 示例 |
|---|---|---|
| API接口 | 用户有REST/GraphQL接口 | "这个API所有参数的边界覆盖" |
| 数据库操作 | 用户有CRUD/迁移代码 | "数据库操作的边界条件" |
| 消息队列 | 用户有MQ/事件处理代码 | "消息处理的边界和重试逻辑" |
| 微服务调用 | 用户有服务间调用代码 | "服务调用的超时/降级边界" |
| 并发/锁 | 用户有并发控制代码 | "并发路径的race condition边界" |
前端 / 交互
| 场景 | 触发信号 | 示例 |
|---|---|---|
| 表单处理 | 用户有表单校验代码 | "表单所有输入组合都覆盖了吗" |
| 状态管理 | 用户有状态机/Reducer代码 | "状态机的所有转移都覆盖了没" |
| 路由处理 | 用户有路由守卫/导航代码 | "路由跳转的所有边界" |
| 文件上传 | 用户有文件处理代码 | "上传的所有文件格式边界" |
| 动画/过渡 | 用户有动画/transition代码 | "动画状态的所有边界" |
数据 / ETL
| 场景 | 触发信号 | 示例 |
|---|---|---|
| CSV/JSON解析 | 用户有数据解析代码 | "文件解析的所有格式边界" |
| 数据迁移 | 用户有数据迁移脚本 | "迁移脚本的边界条件" |
| 聚合计算 | 用户有统计/聚合代码 | "聚合逻辑的除零/null边界" |
| 数据校验 | 用户有数据质量检查代码 | "校验规则的所有边界" |
| 流处理 | 用户有流式处理代码 | "流处理的窗口边界和延迟" |
DevOps / 基础设施
| 场景 | 触发信号 | 示例 |
|---|---|---|
| CI/CD脚本 | 用户有构建/部署脚本 | "部署脚本的所有失败分支" |
| 配置管理 | 用户有配置文件解析代码 | "配置缺失/错误的边界" |
| 容器编排 | 用户有Docker/k8s配置 | "容器启动失败的所有边界" |
| 健康检查 | 用户有health check代码 | "健康检查的超时和重试边界" |
| 日志/监控 | 用户有日志采集代码 | "日志轮转/磁盘满的边界" |
手动触发
- "检查边界条件"
- "edge case 都覆盖了吗"
- "穷举一下所有情况"
- "有没有遗漏的分支"
- "boundary check"
- "测试够不够全"
输入
- content（必需）— 待审查的内容：diff / 完整文件 / 函数
- also_consider（可选）— 审查过程中额外需要考虑的方面
审查范围
- 有 diff → 只扫描 diff hunks 中可到达的边界，只报告 diff 中缺少显式 guard 的
- 无 diff（完整文件/函数）→ 整个内容为范围
- 忽略代码库其余部分（除非内容显式引用外部函数）
执行流程
Step 1: 接收内容
- 从输入加载待审查内容
- 空内容 → 返回
[{"location":"N/A","trigger_condition":"输入为空","guard_snippet":"提供有效内容","potential_consequence":"审查跳过"}] - 识别内容类型（diff / 完整文件 / 函数）
Step 2: 穷举路径分析
走查每一条分支路径和边界条件——只报告未处理的。
分析维度：
| 维度 | 检查项 |
|---|---|
| 控制流 | 条件分支(缺少else/default)、循环(off-by-one)、错误处理(缺catch)、提前返回(无后续清理) |
| 数据边界 | null/undefined/空字符串/空数组、零值/负数/极大值、类型边界(整数溢出/浮点精度)、编码边界(特殊字符/超长输入) |
| 状态边界 | 初始状态、过渡状态、终态、并发状态竞争 |
| 时间边界 | 超时、时钟回拨、操作顺序颠倒 |
| 资源边界 | 文件不存在/无权限/被占用、网络断开/慢速、内存耗尽 |
| 用户边界 | 无输入、格式错误、恶意输入、权限不足 |
| 隐式边界 | 隐式类型转换、API版本变更、配置缺失 |
对每条路径：确定内容是否处理了它 → 只收集未处理的 → 丢弃已处理的。
Step 3: 完整性验证
- 重访 Step 2 的每个边界类
- 补充新发现的未处理路径
- 确认已丢弃的确实是已处理的
Step 4: 输出发现
输出 JSON 数组，每个发现包含 4 个字段：
[{
"location": "file:start-end (or file:line, or file:hunk)",
"trigger_condition": "触发条件（≤15词中文）",
"guard_snippet": "关闭此缺口的最小代码草图（单行，无实际换行/无未转义引号）",
"potential_consequence": "可能发生的后果（≤15词中文）"
}]
- 无额外文字、无解释、无 markdown 包装
- 空数组
[]表示未发现未处理路径（这是有效结果） - 如果 also_consider 已提供，在分析中纳入这些方面
与 Hermes 技能的集成
被 github-code-review 调用
在代码审查中增加 Edge Case Hunter 层：
加载 edge-case-hunter，对 PR diff 运行穷举路径分析，
将 JSON 发现合并到审查报告的 Critical/Warnings 中。
被 feishu-html 阶段五调用
部署前：
加载 edge-case-hunter 检查 HTML 中所有交互路径是否覆盖了边界条件：
- 空状态/加载中/错误/权限不足 是否都有处理
- 所有按钮是否有 hover/active/focus/disabled 态
- 触控区域是否 ≥44×44px
被 systematic-debugging Phase 1 调用
在确定根因后：
加载 edge-case-hunter 穷举该代码区域的所有边界，
确认修复方案覆盖了所有边界而不仅是当前触发的那一个。
约束
- 不做质量判断 — 不评论代码好坏，只报告缺失
- 不编造发现 — 如果路径被处理了就说处理了，不硬找问题
- 不解释处理了的问题 — 丢弃静默，报告简洁
- 不输出 markdown — 纯 JSON
常见陷阱
- 找问题而不是找缺失 → 这个技能不找问题(bugs)，只找缺失(missing guards)
- 过度解释 → 输出必须是最小可行的 JSON
- 忽略 also_consider → 如果提供了，必须纳入分析
- 把已处理的标记为缺失 → 误报不如漏报
验证清单
- 内容非空且可解码
- 走查了所有控制流分支
- 走查了所有数据边界
- 只报告了未处理路径（已处理静默丢弃）
- 输出为有效 JSON 数组（含4字段）
- 无 markdown 包装、无额外文字