Request Guard

---
name: request-guard
description: 用户突然提出修改请求时先做三维度检查（冲突 / 替代方案 / 副作用）再决定是否执行，输出通过 / 存疑 / 拦截，防止被突发奇想带着跑。触发："改一下"、"改成"、"能不能这样改"等短小突然、缺上下文的修改请求；只做优化分析走 artifact-optimizer，精简文件走 content-simplifier。
---

# 请求守卫

## 概述

**目的**：在用户突然提出修改请求时，先做一次快速刹车检查，防止盲从用户的突发奇想

**功能**：对用户的修改指令进行三维度轻量检查（是否与已有约定冲突、是否有更简单的替代方案、是否会引入副作用），1 轮输出结论

**使用场景**：
- 用户突然说"改一下这个"、"把这个改成 X"、"优化一下"时
- 用户的修改请求简短、缺少上下文、看起来像是突发奇想时
- AI 准备执行修改之前，需要先验证指令的合理性

## 定位

```
用户修改指令 → request-guard（本 skill）→ 通过 → 执行修改
                     ↓
              存疑/拦截 → 输出理由 → 等用户决策
```

- **输入**：用户的修改指令 + 当前上下文（已有设计文档、代码规范、讨论历史）
- **输出**：通过 / 存疑 / 拦截 结论 + 理由
- **边界**：只做快速检查，不做深度需求分析（那是 requirement-mining 的事）

## 何时使用

### 触发条件

用户消息满足以下**任一条件**时触发：

| 信号 | 示例 |
|------|------|
| 短促修改指令 | "把这个函数改成 async"、"这里的名字改一下" |
| 解决方案式请求 | "能不能在这里加个缓存"、"加个重试机制" |
| 缺少背景的优化 | "优化一下性能"、"这里写得太复杂了" |
| 对立于已有约定 | 用户要求的方向与已有设计文档、代码规范冲突 |

### 不需要触发的情况

| 情况 | 处理 |
|------|------|
| 用户有充分上下文讨论（3+ 轮） | 说明已思考过，跳过检查 |
| 用户明确说"我确认这个方案" | 跳过检查，直接执行 |
| 微小修改（typo、格式） | 跳过检查 |

## 核心原则

1. **先刹车后执行**：接到修改指令不立即动手，先过一遍检查
2. **轻量快速**：只检查 3 个关键维度，1 轮输出结论
3. **不替代深度分析**：发现严重问题时建议用 requirement-mining 深度分析
4. **最终决定权归用户**：即使拦截，用户说"我就要这样做"也执行

## 工作流

```
拦截 → 三维度检查 → 输出结论 → 通过则执行 / 存疑则建议后确认 / 拦截则阻止并说明
```

---

## 检查维度

### 维度 1：是否与已有约定冲突

检查用户的修改请求是否和已有的设计文档、代码规范、架构约定矛盾。

**检查方法**：
- 对照已有设计文档（DESIGN.md）、API 设计（api-design.md）
- 对照项目代码规范、命名约定
- 对照上下文中已确认的讨论结论
- **决策记忆查询**：调用 `use_skill("ki-memory-lookup")` 的决策记忆策略查该模块历史决策；命中的「被否决方案」说明该方案已被考虑并否决过，**先核对原否决理由是否仍成立**，只在理由不再成立时才重新提出，避免重复讨论同一个已否决方案（查询失败或无可用记录，忽略继续）

**判断标准**：

| 情况 | 结论 |
|------|------|
| 与已有约定一致或兼容 | ✅ 通过 |
| 与已有约定有潜在冲突 | ⚠️ 存疑 |
| 与已有约定明确矛盾 | ❌ 拦截 |

### 维度 2：是否有更简单或更根本的方案

检查用户的请求是"方案"还是"需求"。如果用户提供的是方案而不是问题本身，判断是否有更简单的替代。

**检查方法**：
- 用户说的是"做什么"（加缓存）还是"解决什么"（查询太慢）？
- 如果用户提供的是方案：有没有更简单的方式达到同样效果？
- 是否有现成的功能或约定可以直接复用？

**判断标准**：

| 情况 | 结论 |
|------|------|
| 方案合理，没有明显更优替代 | ✅ 通过 |
| 有潜在的更优方案，值得讨论 | ⚠️ 存疑 |
| 方案明显过度设计或有更简单替代 | ❌ 拦截 |

### 维度 3：是否会引入明显副作用

检查修改后是否会影响其他模块、破坏现有功能、引入新的复杂度。

**检查方法**：
- 改了这个地方，有没有其他地方依赖它？
- 修改后会不会引入新的边界情况或竞态条件？
- 会不会让代码变得更复杂而不是更简单？
- **强关联关系查询**：对涉及跨模块的修改，调用 `use_skill("ki-memory-lookup")` 检索被改模块的强关联关系（跨模块契约/业务耦合），判断是否牵动其他模块（副作用检查的直接依据；查询失败或无可用记录，跳过继续）

**判断标准**：

| 情况 | 结论 |
|------|------|
| 修改范围清晰，无可见副作用 | ✅ 通过 |
| 有潜在影响但可控 | ⚠️ 存疑 |
| 明确会破坏现有功能或引入不可控风险 | ❌ 拦截 |

---

## 输出格式

```text
🛡️ 请求守卫检查
━━━━━━━━━━━━━━━━

请求：[用户原话摘要]

| 维度 | 结论 | 说明 |
|------|:----:|------|
| 约定冲突 | ✅ / ⚠️ / ❌ | [简要说明] |
| 更优方案 | ✅ / ⚠️ / ❌ | [简要说明] |
| 副作用 | ✅ / ⚠️ / ❌ | [简要说明] |

━━━ 综合结论 ━━━

[✅ 通过 / ⚠️ 存疑 / ❌ 拦截]

[结论说明]

[如存疑或拦截：给出具体建议]
```

### 结论处理

| 结论 | 处理 |
|------|------|
| ✅ 通过 | 继续执行用户的修改请求 |
| ⚠️ 存疑 | 输出疑虑和建议，等用户确认后执行 |
| ❌ 拦截 | 输出拦截理由，建议用户重新考虑或用 requirement-mining 深度分析 |

---

## 示例

### 示例 1：✅ 通过

```
用户："给这个查询接口加个分页参数"

🛡️ 请求守卫检查
━━━━━━━━━━━━━━━━

请求：给查询接口加分页参数

| 维度 | 结论 | 说明 |
|------|:----:|------|
| 约定冲突 | ✅ | 设计文档已预留分页字段 |
| 更优方案 | ✅ | 分页是标准做法 |
| 副作用 | ✅ | 向后兼容，不影响已有调用 |

━━━ 综合结论 ━━━

✅ 通过 — 继续执行修改
```

### 示例 2：⚠️ 存疑

```
用户："能不能在这里加个 Redis 缓存"

🛡️ 请求守卫检查
━━━━━━━━━━━━━━━━

请求：增加 Redis 缓存

| 维度 | 结论 | 说明 |
|------|:----:|------|
| 约定冲突 | ⚠️ | 项目当前无 Redis 依赖，引入新组件 |
| 更优方案 | ⚠️ | 是否可以先加应用层内存缓存？ |
| 副作用 | ⚠️ | 引入缓存一致性维护成本 |

━━━ 综合结论 ━━━

⚠️ 存疑 — 增加 Redis 是有效的优化手段，但会引入新的基础设施依赖。
建议：1) 先确认当前性能瓶颈是否确实在查询层 2) 可考虑先用应用层缓存作为轻量方案。

是否继续引入 Redis？
```

### 示例 3：❌ 拦截

```
用户："把所有同步请求改成异步的"

🛡️ 请求守卫检查
━━━━━━━━━━━━━━━━

请求：把所有同步请求改成异步

| 维度 | 结论 | 说明 |
|------|:----:|------|
| 约定冲突 | ❌ | 设计文档明确部分接口需同步返回结果 |
| 更优方案 | ❌ | "所有"范围过大，应按场景选择性异步 |
| 副作用 | ❌ | 大规模改动可能破坏调用链的一致性 |

━━━ 综合结论 ━━━

❌ 拦截 — "全部异步化"是过度设计。
建议：1) 识别哪些场景确实需要异步 2) 逐个场景评估 3) 推荐使用 requirement-mining 深层分析。

是否仍然坚持全部异步化？[是/否]
```

---

## 与 challenger 的区别

| 维度 | challenger | request-guard |
|------|-----------|--------------|
| 质疑对象 | AI 产出的代码/设计 | 用户的修改指令 |
| 触发时机 | code-review 完成后 | 用户提出修改请求时 |
| 深度 | 深度二次审查 | 轻量快速检查 |
| 输出 | 分级问题报告 | 通过/存疑/拦截 |

## 与 requirement-mining 的关系

request-guard 是"快速版的需求检查"，requirement-mining 是"深度版的需求分析"：

- request-guard 发现问题 → 建议用户用 requirement-mining 深度分析
- requirement-mining 分析完毕 → 用户给出新指令 → request-guard 再次检查

---

## 反模式

- ❌ **过度检查**：微小修改（typo、格式调整）不需要触发检查
- ❌ **替代深度分析**：发现严重问题时不要自己深入，推荐 requirement-mining
- ❌ **强制拦截**：用户坚持时应当遵从，不反复拦截
- ❌ **只拦不改**：拦截时必须给出具体理由和替代建议