请求守卫

概述

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

功能：对用户的修改指令进行三维度轻量检查（是否与已有约定冲突、是否有更简单的替代方案、是否会引入副作用），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") 检索被改模块的强关联关系（跨模块契约/业务耦合），判断是否牵动其他模块（副作用检查的直接依据；查询失败或无可用记录，跳过继续）

判断标准：

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

---

输出格式

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

请求：[用户原话摘要]

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

━━━ 综合结论 ━━━

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

[结论说明]

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

结论处理

结论	处理
✅ 通过	继续执行用户的修改请求
⚠️ 存疑	输出疑虑和建议，等用户确认后执行
❌ 拦截	输出拦截理由，建议用户重新考虑或用 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
• ❌ 强制拦截：用户坚持时应当遵从，不反复拦截
• ❌ 只拦不改：拦截时必须给出具体理由和替代建议