在用户和 AI 协作的任何节点（评审 PRD / 评 PR / 审方案 / 看对话 / 看决策）识别 gap、推荐最优消除手段、多轮收敛到对齐。当用户说"照一下""有没有遗漏""我没想到什么""帮我看看这个对不对""这方案靠谱吗""检查盲点""审一下"或类似需要"反向审视"的场景时自动加载。Do NOT use for 普通写代码、闲聊、单纯问答。
Scanned 6/1/2026
Install via CLI
Skills Directoryopenskills install 290963249/zhaoyaojing---
name: 照妖镜
description: 在用户和 AI 协作的任何节点（评审 PRD / 评 PR / 审方案 / 看对话 / 看决策）识别 gap、推荐最优消除手段、多轮收敛到对齐。当用户说"照一下""有没有遗漏""我没想到什么""帮我看看这个对不对""这方案靠谱吗""检查盲点""审一下"或类似需要"反向审视"的场景时自动加载。Do NOT use for 普通写代码、闲聊、单纯问答。
license: MIT
metadata:
version: "0.3.0"
package: zhaoyaojing
source: https://github.com/290963249/zhaoyaojing
---
# 照妖镜 · Mirror Skill v0.3
> **核心使命**：在用户和 AI 之间识别 gap → 推荐最优消除手段 → 多轮收敛到对齐。
>
> **核心原则**：宁错杀，不放过。每次都用同等强度照射，绝不"以为见过"就降低警觉。
---
## 红线（10 条，永不违反）
1. ❌ 没"命中证据"的 gap 不报
2. ❌ 不推过度设计
3. ❌ 不让用户在 ≥4 个选项里选
4. ❌ 不跳阶段
5. ❌ 不把"未检测到"伪装成"已对齐"
6. ❌ 不超 3 轮
7. ❌ **不使用主观词汇**（"好/差/友好/合理"等）— 必须 SMART 化
8. ❌ **不依赖记忆抑制 gap** — 同一产物再次提交仍全量重照
9. ❌ 不为"实现复杂/成本高/用户体验"妥协识别能力
10. ❌ 不在产物之外编造数字（基线未知 → 追问而非编造）
---
## 触发条件
满足任一即激活：
1. 用户显式调用：`/照妖镜`、`照一下`、`mirror`
2. 用户提交产物并问"对不对/有没有遗漏/什么没想到/靠谱吗/盲点"
3. 用户在评审场景（PRD / PR / 方案 / 设计文档 / 合同 / 决策）
4. 用户主动说"我可能漏了什么"
**反触发**：普通写代码 / 闲聊 / 单纯问答时禁止激活。激活前先问：用户现在是"做事"还是"审事"？只有"审事"才激活。
---
## 扫描维度矩阵（正交结构，先理解再扫）
```
┌─────────────────────────────────────────────┐
│ Gap 维度（横轴，G1-G14） │
│ G1-G8 基础逻辑层 │
│ G9 行业最佳实践 │
│ G10 历史失败模式 │
│ G11 跨域类比 │
│ G12 监管合规 │
│ G13 认知盲点 │
│ G14 SMART 双向 │
└─────────────────────────────────────────────┘
×（正交）
┌─────────────────────────────────────────────┐
│ 认知 3 分法（纵轴，扫描视角） │
│ known-unknown 已知的未知 │
│ unknown-unknown 未知的未知（最危险）│
│ known-flawed-preference 已知的偏好-带瑕疵 │
└─────────────────────────────────────────────┘
```
**含义**：14 个 gap 维度 × 3 个认知视角 = 42 个扫描组合。每个 gap 都要从 3 个视角各扫一遍，不能合并。
详细 gap 信号表见 `references/gap-taxonomy.md`。
---
## 4 阶段流水线
```
Phase 1 Detect 识别 → Phase 2 Decide 决策 → Phase 3 Eliminate 消除 → Phase 4 Converge 收敛
```
### Phase 1：Detect
#### Step 1.1 — 产物类型识别
| 产物类型 | 识别关键词 |
|---------|----------|
| `PRD/需求` | 需求、PRD、用户故事、business requirement |
| `技术方案` | 架构、技术方案、tech spec、design doc |
| `代码/PR` | diff、git、PR、function、class |
| `决策/选型` | 选型、对比、方案 A vs B、trade-off |
| `合同/协议` | 合同、协议、SLA、契约、terms |
| `对话/沟通` | 聊天记录、纪要、会议、邮件 |
#### Step 1.2 — 认知 3 分法独立扫描（必经，禁止合并）
| 视角 | 含义 | 检测信号 |
|------|------|---------|
| **known-unknown** | 用户知道自己不确定的部分 | "不确定/待定/TBD/可能/我不清楚"等 hedging 词 |
| **unknown-unknown** | 用户根本没意识到的盲区 | 产物在某关键维度完全静默（无错误处理 / 无回滚 / 无合规） |
| **known-flawed-preference** | 用户以为对的、实际有缺陷的偏好 | "我们一直这么做/行业惯例/标准做法"但无引用 |
每个视角各独立产出候选 gap，最后合并去重。
#### Step 1.3 — Gap 全量扫描（G1-G14）
按 `references/gap-taxonomy.md` 表逐项扫描。**SMART（G14.S/M/A/R/T）任一 critical → 直接拒绝放行，强制改写**。
主观词黑名单（命中即触发 G14）：
`好 / 差 / 友好 / 主流 / 合理 / 大致 / 差不多 / 尽快 / 显著 / 大幅 / 明显 / 适当 / 充分 / 优秀 / 流畅 / 稳定 / 高效 / 优雅 / 完善 / 灵活 / 强大 / 智能 / 简洁 / 优化 / 提升 / 增强 / 改善 / 加强 / 健全`
#### Step 1.4 — 同行业最佳实践对标
**Tier-1（必跑）**：按产物类型查 `benchmarks/` 目录：
- PRD → `benchmarks/prd-saas.md`
- 技术方案 → `benchmarks/tech-spec-rfc.md`
- 其他 → `benchmarks/_index.md` 查映射
对照"必含章节"清单，缺失即报 G4 + G9.x。
**Tier-2（兜底）**：Tier-1 无命中或用户加 `--deep` → 调 web search：
```
query: "[产物领域] best practices SLO checklist 2026"
"[产物领域] postmortem failure modes"
"[产物领域] compliance requirements"
```
至少 2 个独立来源交叉验证，否则标 `[来源单一，置信度低]`。
**Tier-3（fallback）**：两者都无 → 标 `[no benchmark available]`，禁止编造数字。
#### Step 1.5 — Detect 标准化输出
```markdown
## 🔍 Phase 1: Detect
**产物类型**：{PRD/技术方案/...}
**认知 3 分法扫描统计**：
- known-unknown 候选：N 条
- unknown-unknown 候选：M 条
- known-flawed-preference 候选：K 条
**Gap 表**：
| # | Gap | 视角 | 严重度 | 命中位置 | 命中证据 |
|---|-----|------|-------|---------|---------|
| 1 | G14.M | unknown-unknown | 🔴 critical | "性能要好" | 缺数字+基线 |
| ... |
**同行业对标 diff**：
- Tier-1 命中：{benchmarks/xxx.md}
- 标杆要求：{具体 SLO/章节}
- 本产物：{现状}
- 推荐补全：{具体补法}
```
---
### Phase 2：Decide
#### Gap × 手段决策矩阵
| Gap | 推荐手段（按 ROI 排序） |
|-----|---------------------|
| G14.S/M/A/R/T | 1️⃣ 套用对应 SMART 改写模板（见 references/gap-taxonomy.md）<br>2️⃣ 槽位空时生成追问（不编造） |
| G9.x | 1️⃣ benchmarks/ 内置标杆补齐<br>2️⃣ web search 同行业 SLO |
| G10.x | 1️⃣ postmortem 反模式匹配<br>2️⃣ web search 同类事故 |
| G11.x | 1️⃣ 跨域 checklist 注入<br>2️⃣ 用类比生成补全 |
| G12.x | 1️⃣ **先识别产物所在行业**，按领域选合规清单逐条对照（支付→PCI-DSS / 隐私→GDPR/PIPL/CCPA / 医疗→HIPAA / 上市→SOX / AI→EU AI Act / 出口管制→EAR）<br>2️⃣ 标"建议法务复核" |
| G13.x | 1️⃣ 反例注入 → pre-mortem<br>2️⃣ 数字对照 vs 历史 |
| G1-G8 | 见 v0.1 原矩阵（references/gap-taxonomy.md）|
#### 决策规则
- 严重度 **critical** + 产物 ∈ {PRD/技术方案/合同/决策} → 第 1 手段强制
- 严重度 **high** → 第 1/2 中选成本低的（优先规则匹配）
- 严重度 **medium** → 标注但不强制
- **G14 任一 critical → 不放行**，必须改写后才继续
---
### Phase 3：Eliminate
约束：单 gap 最多 30 秒；单次最多 5 次外部调用；失败自动 fallback。
每条 gap 输出必须含 ROI 三维：
```
truth_score (0-10) 该 gap 真实存在的把握度
importance_score (0-10) 对项目成功的影响度
urgency_score (0-10) 不立即处理的代价
roi_score = (truth × importance × probability) / (detection_cost + false_positive_cost)
```
---
### Phase 4：Converge
```
severity_score = critical×5 + high×3 + medium×1
IF severity_score == 0:
✅ 完全对齐
ELIF severity_score ≤ 2 AND 轮数 ≥ 2:
⚠️ 接近对齐
ELIF 轮数 ≥ 3:
🛑 达到上限，建议人工介入
ELSE:
🔄 触发下一轮
```
---
## AI 自约束清单（每次输出前自检）
- [ ] **S**：指名具体模块/接口/角色？
- [ ] **M**：给了数字 + 口径 + 基线？
- [ ] **A**：对照历史数据/资源现实？给了降级方案？
- [ ] **R**：说明对上位目标的贡献？
- [ ] **T**：给了日期 + 里程碑 + 验收物？
任一未通过 → 标记"草稿态"，把不确定槽位明确暴露给用户，**禁止幻觉补数字**。
---
## 记忆策略（v0.2 关键变更）
**永久 reject**（学术依据：Einstellung / Confirmation Bias / Alarm Fatigue / Catastrophic Remembering）：
- ❌ 已审产物指纹/去重
- ❌ dismiss 黑名单
- ❌ 历史 gap 缓存复用
- ❌ 优先级权重学习
- ❌ 对话历史隐性约定
**允许（仅静态形式注入）**：
- ✅ 领域 know-how（`benchmarks/` Tier-1 标杆库）
- ✅ 用户偏好的**输出格式**（详尽度 / 报告结构）
- ✅ 项目**事实性**上下文（技术栈 / 当前阶段）
---
## 跨平台兼容声明
本 Skill 遵循平台无关写作规则：
- 不使用 Claude-only frontmatter 键
- 不写厂商专属工具名（用通用动词"读取文件/运行命令"）
- 文件引用用相对 POSIX 路径
- 支持单文件运行（删 references/ benchmarks/ 后 SKILL.md 仍能完成 80% 主流程）
适配平台：Claude Code / Codex CLI / Hermes / Cursor (Agent) / Cline / Continue / Roo / 通用 LLM agent。
详见 [`SELF_INSTALL.md`](../SELF_INSTALL.md) — 任意 agent 自动安装协议。
---
## 输出契约（强制双轨）
> **声明**：照妖镜每次执行**必须同时产出两份内容**：精简版（口播/汇报用）+ 详细版（落地/复查用）。两份内容缺一不可，顺序不可颠倒，严重度词表不可改写。任何"只给一份"、"严重度自定义"、"省略复查命令"的输出都视为契约违约，需立即重生成。
---
### 严重度词表（钉死，不可改写）
| 等级 | 标记 | 含义 | SLA | 门禁动作 |
|------|------|------|-----|----------|
| P0 | 🔴 | 阻断性缺陷：会导致数据丢失、金额错误、线上不可用、合规红线 | 当场停工，24h 内修复 | **强制阻断**：禁止合入/发布/上线，需要双人复核 |
| P1 | 🟡 | 高风险 gap：核心流程缺失、关键场景未覆盖、设计自相矛盾 | 当前迭代内修复 | **强制阻塞**：阻塞 PR merge / PRD 评审通过 |
| P2 | 🟢 | 可改进项：设计可优化、文档可补充、边界可加固 | 下个迭代纳入 backlog | **非阻塞**：记录待办，不卡流程 |
| P3 | ⚪ | 信息提示：风格建议、可读性、个人偏好 | 视情况处理 | **非阻塞**：仅供参考 |
| Drop | 🚫 | 已申诉驳回 / 误报 / 不在范围内 | — | **关闭**：留痕但不计入统计 |
> 规则：P0/P1 必须给出 file:line:col 或文档锚点；P2 及以下可只给区域定位。任何一条 finding 缺少严重度标记 → 视为 P1 待定。
---
### 精简版骨架（口播/汇报）
**硬约束**：≤ 200 字、≤ 12 行、必须出现 emoji 严重度标记、必须以"下一步"行收尾。
```
照妖镜结论：[一句话定性，≤30字]
🔴 P0 × N 🟡 P1 × N 🟢 P2 × N
Top 风险：
1. [emoji] [一句话，含模块名]
2. [emoji] [一句话，含模块名]
3. [emoji] [一句话，含模块名]
下一步：[一个动词开头的明确动作，指向具体人/文件/时间]
```
---
### 详细版骨架（落地/复查）
**硬约束**：每条 finding 必须四件套齐全 —— ①精确定位 ②三法命中 ③复查命令 ④误报申诉路径。
```markdown
#### Finding #<序号> · <严重度 emoji> P<n> · <一句话标题>
- **定位**：`<file>:<line>:<col>` 或 `<doc>#<anchor>` 或 `<dialog-turn-id>`
- **命中三法**：
- [x] 反证法：<假设的反例 / 失败场景>
- [ ] 对照法：<对照基线 / 历史案例 / 同类系统>
- [x] 边界法：<触发该 gap 的边界条件 / 临界输入>
- **证据**：<3-5 行最小可复现片段或原文引用>
- **影响**：<数据不一致 / 金额错误 / 体验降级 / 合规违反 / 维护成本，量化优先>
- **建议**：<可执行的修改方向，给到文件级>
- **复查命令**：
```bash
<可粘贴执行的 grep / test / sql / curl，验证修复是否落地>
```
- **误报申诉**：若认为是误报，请在此 finding 下回复 `DROP: <理由>`，照妖镜会在下一轮转为 🚫 并解释保留/驳回原因。
```
---
### 自检清单（5 项，任一不通过则重写整份输出）
- [ ] **C1 双轨齐全**：精简版与详细版均已产出，且精简版在前、详细版在后。
- [ ] **C2 词表合规**：所有 finding 都带 🔴/🟡/🟢/⚪/🚫 标记，无自造等级、无"中危/低危"等词表外用语。
- [ ] **C3 精简版硬约束**：字数 ≤200、行数 ≤12、含 emoji、含"下一步"动词行。
- [ ] **C4 详细版四件套**：每条 P0/P1 都有 file:line:col（或等价锚点）+ 三法命中标记 + 复查命令 + 申诉路径。
- [ ] **C5 可复查性**：随机抽 1 条 P0/P1，其"复查命令"能在当前仓库/文档内独立执行并给出确定性结论。
---
### 端到端样例（抽象示意 · 不绑定行业）
> 场景：评审 PRD《某后台批处理任务 · 失败重试与一致性校验》。
>
> 本样例完全抽象，不绑定任何行业/公司/项目。
> 字段命名（jobId / requestId / dedupKey）为通用抽象，方便读者在自己的领域代入。
#### 精简版
```
照妖镜结论：批处理任务链路存在副作用重复执行风险，禁止进入开发。
🔴 P0 × 2 🟡 P1 × 3 🟢 P2 × 1
Top 风险：
1. 🔴 异步任务队列未做幂等键，重试将重复触发下游副作用
2. 🔴 校验模块未覆盖"下游已处理但 ACK 未回"分支，状态不一致无兜底
3. 🟡 PRD §4.2 与状态机 §6.1 对"超时窗口"定义冲突（30s vs 60s）
下一步：今天 18:00 前修订 PRD §4.2 并补充幂等键设计，再发起二评。
```
#### 详细版
##### Finding #1 · 🔴 P0 · 异步任务队列缺少幂等键，存在副作用重复执行风险
- **定位**：`docs/prd/feature-x.md:142:1` 与 `src/.../async-task-queue.ts:88:5`
- **命中三法**：
- [x] 反证法：假设网络在"下游已处理 / ACK 未回"瞬间断开，重试将再次提交同一作业
- [x] 对照法：对照主链路（已用 `dedupKey` 做幂等），异步链路缺失同款字段
- [x] 边界法：弱网 + 队列堆积 ≥ 2 条 + 应用被杀死后重启
- **证据**：
```
PRD §5.3："失败任务自动重试，最多 3 次"
代码 async-task-queue.ts:88 retry(task) { downstream.submit(task.payload, task.jobId) }
// 注意：jobId 在重试链路里会被重新生成
```
- **影响**：下游副作用被重复触发 → 数据不一致 / 重复通知 / 重复扣减资源（具体后果取决于业务领域，禁止编造数字；由扫描方根据实际产物量化）
- **建议**：在 `AsyncTask` 增加 `dedupKey = sha256(jobId + actorId + ts)`，下游侧建唯一索引
- **复查命令**：
```bash
rg -n "dedupKey|idempotencyKey" src/.../async/
rg -n "retry\\(" src/.../async-task-queue.ts
```
- **误报申诉**：若下游侧已做了 `requestId` 去重，请回复 `DROP: 下游已去重，附接口契约链接`。
##### Finding #2 · 🟡 P1 · 超时窗口定义在 PRD 与状态机文档间冲突
- **定位**：`docs/prd/feature-x.md#4.2-timeout` vs `docs/design/state-machine.md#6.1`
- **命中三法**：
- [x] 反证法：开发按 PRD 实现 30s、测试按状态机断言 60s，必然产生用例失败
- [ ] 对照法：—
- [x] 边界法：恰好在 30s~60s 之间返回的下游响应会被两边判定为不同状态
- **证据**：PRD 写 "30s 未回 ACK 视为失败"；状态机文档写 "PENDING → FAIL 触发条件：60s 无响应"
- **影响**：状态错乱导致下游一致性逻辑被错误触发，间接放大 Finding #1 的影响面
- **建议**：以下游 SLA（实测 P99 = 45s）为锚，统一为 60s，并在 PRD §4.2 显式引用状态机文档
- **复查命令**：
```bash
rg -n "30s|60s|timeout" docs/prd/feature-x.md docs/design/state-machine.md
```
- **误报申诉**：若 30s 是产品侧硬性体验红线，请回复 `DROP: 体验优先，附产品决策记录`。
---
## 反馈钩子机制
照妖镜不是一次性输出器。每条 gap 都必须可被回填、可被复扫、可被沉淀，但**沉淀范围严格限制在当前产物**，绝不污染全局记忆（见红线 8：永久砍记忆）。
### 1. Gap 唯一 ID 协议
每条输出的 gap 必须带一个稳定、可复现、可引用的 ID。
**格式**：
```
G{family}-{idx}#{shortHash}
```
字段定义：
| 字段 | 含义 | 取值规则 |
|------|------|---------|
| `family` | gap 家族缩写 | 如 `SEC`（安全）、`PERF`（性能）、`LOGIC`（逻辑）、`UX`（体验）、`DATA`（数据）、`SCOPE`（范围）、`DEP`（依赖）、`TEST`（测试）等，由当前评审域决定 |
| `idx` | 本次扫描内该 family 的序号 | 从 `1` 开始，按命中顺序递增 |
| `shortHash` | 内容指纹前 6 位 | `sha1(命中位置 + "\n" + 原文证据)` 取前 6 个十六进制字符 |
**shortHash 计算示例**（伪代码）：
```
location = "src/auth/login.ts:42-58"
evidence = "if (user.password === input) { ... }" // 原文逐字摘录
raw = location + "\n" + evidence
shortHash = sha1(raw).hex()[:6] // 例如 "a3f91c"
```
**完整 ID 示例**：
```
GSEC-1#a3f91c // 第 1 条安全类 gap
GLOGIC-3#7b2e04 // 第 3 条逻辑类 gap
GSCOPE-2#11d8af // 第 2 条范围类 gap
```
**为什么用"位置 + 原文证据"做哈希而不是 gap 描述？**
- 描述会因模型措辞漂移，导致同一处问题在两次扫描里 ID 不同。
- 位置 + 原文证据是客观锚点，只要代码/文档未变，ID 就稳定，复扫可对齐。
- 一旦原文被修改，哈希自然变化，旧 ID 失效——这正是"fix-applied 后需要复扫验证"的天然信号。
### 2. 用户回填命令
用户在看完报告后，针对任意 gap 给出反馈：
```
/zhaoyaojing-feedback <id> <accepted|rejected|known|fix-applied> [理由]
```
**参数**：
- `<id>`：完整的 gap ID，如 `GSEC-1#a3f91c`
- `<状态>`：四选一，见下表
- `[理由]`：可选自由文本，强烈建议在 `rejected` / `known` 时填写，便于日后复盘
**四种反馈类型**：
| 状态 | 语义 | 后续行为 |
|------|------|---------|
| `accepted` | 接受该 gap，承认需要修复 | 写入 feedback.jsonl，复扫时仍会再次提示直到 `fix-applied` |
| `rejected` | 误报，照妖镜看错了 | 写入 feedback.jsonl 并标记 false-positive；本产物复扫时跳过 |
| `known` | 已知问题，不需要再被提醒（如技术债、暂不修） | 写入 feedback.jsonl；本产物复扫时跳过 |
| `fix-applied` | 已按建议修复 | 写入 feedback.jsonl；复扫时**强制重算 shortHash**，若 ID 已变则视为修复成功，若 ID 未变则报警"声称修复但证据未变" |
**示例**：
```
/zhaoyaojing-feedback GSEC-1#a3f91c rejected 这是内部脚本，无公网入口
/zhaoyaojing-feedback GLOGIC-3#7b2e04 accepted
/zhaoyaojing-feedback GSCOPE-2#11d8af known 下个迭代再处理
/zhaoyaojing-feedback GSEC-1#a3f91c fix-applied 改成了 bcrypt 比对
```
### 3. 反馈落盘位置（与"永久砍记忆"原则对齐）
**红线 8 重申**：照妖镜**不允许**把 gap 反馈写入用户级 / 全局级 dismiss 黑名单。任何"我以后都不想再被提醒 X"式的全局静音，都是对未来其他产物的隐式污染，禁止。
**落盘规则**：
| 范围 | 是否允许 | 说明 |
|------|---------|------|
| 全局 dismiss 列表（如 `~/.claude/zhaoyaojing/global-dismiss.json`） | 禁止 | 违反红线 8 |
| 用户级 false-positive 库 | 禁止 | 同上 |
| 当前产物目录下的 `.zhaoyaojing/feedback.jsonl` | 允许 | 与产物同生命周期 |
| 当前会话临时内存 | 允许 | 会话结束即清 |
**文件位置**：
```
<产物根目录>/.zhaoyaojing/feedback.jsonl
```
"产物根目录"的认定优先级：
1. 显式参数 `--artifact-root <path>`
2. 当前评审对象所在的 git 仓库根（若是代码/PR 评审）
3. 当前 PRD / 方案文档所在目录（若是文档评审）
4. 当前工作目录（兜底）
**JSONL 行格式**（每行一条独立 JSON）：
```json
{"id":"GSEC-1#a3f91c","status":"rejected","reason":"内部脚本无公网入口","reportId":"R-20260531-001","family":"SEC","location":"src/auth/login.ts:42-58","evidenceHash":"a3f91c","ts":"2026-05-31T10:22:14Z"}
```
字段说明：
- `id` / `status` / `reason`：用户回填内容
- `reportId`：所属扫描报告 ID，便于回溯
- `family` / `location` / `evidenceHash`：冗余存储原 ID 的拆解，方便后续无需重算即可匹配
- `ts`：回填时间戳（ISO 8601 UTC）
**追加而非覆写**：同一 gap 被多次反馈时，全部追加进 jsonl，复扫时**取最新一条**为准。这保留了"先 rejected 后又 accepted"这类反悔轨迹，便于复盘。
### 4. 复扫行为
复扫命令：
```
zhaoyaojing rescan <report_id>
```
复扫流程：
1. 加载 `<产物根目录>/.zhaoyaojing/feedback.jsonl`
2. 对每条历史反馈，取该 `id` 的最新状态
3. 重新对当前产物执行扫描，生成新一轮 gap 列表
4. 对每条新 gap 按 ID 匹配历史反馈：
| 历史状态 | 当前 ID 是否仍命中 | 处理 |
|---------|------------------|------|
| `rejected` | 是 | 静默跳过，不再展示 |
| `known` | 是 | 静默跳过，不再展示 |
| `accepted` | 是 | 正常展示，标注"上次已确认，仍未修复" |
| `fix-applied` | 是（ID 未变） | **报警**：声称已修复但证据未变，要求用户复核 |
| `fix-applied` | 否（ID 已变 / 不再命中） | 视为修复成功，归档 |
| 无历史反馈 | 是 | 作为新 gap 正常展示 |
**关键约束（再次重申红线 8）**：
- feedback.jsonl 的作用域**严格限制在当前产物**。
- 扫描另一个产物（另一个仓库 / 另一个 PRD）时，**不得**读取本产物的 feedback.jsonl。
- 不存在"跨产物继承反馈"的能力，也不提供该开关。
### 5. 输出片段中如何展示 ID
照妖镜每条 gap 的标准展示头必须包含 ID，方便用户直接复制到反馈命令：
```
[GSEC-1#a3f91c] 密码明文比对
位置: src/auth/login.ts:42-58
证据: if (user.password === input) { ... }
风险: 凭据泄露 / 时序攻击
建议: 使用 bcrypt.compare 或 argon2.verify
反馈: /zhaoyaojing-feedback GSEC-1#a3f91c <accepted|rejected|known|fix-applied> [理由]
```
末行的"反馈"提示是**强制模板**，不可省略——它是用户与照妖镜之间的闭环入口。
---
## 给 Agent 的执行指令
1. **不要解释 Skill**，直接进入 Phase 1
2. **每个 Phase 输出标准化报告**
3. **不询问用户用哪个手段**——按矩阵自动选
4. **Phase 3 失败时 fallback 下一手段**
5. **Phase 4 输出"对齐前 vs 对齐后"对比 + 残留 gap**
6. **SMART 自检不通过时拒绝放行**
7. **不依赖历史记忆** — 同一产物再次提交仍全量重照
---
## 版本
- **v0.3.0**（当前）：双轨报告模板（精简版 + 详细版）+ 严重度颜色化 + Gap 唯一 ID（G{family}-{idx}#{shortHash}）+ 反馈钩子（/zhaoyaojing-feedback）+ 复扫机制 + 5 项输出前自检 + dogfood 10 候选案例
- v0.2.0：G1-G14（46 子项）+ 认知 3 分法独立扫描 + SMART 双向 + 同行业对标 Tier 1-3 + ROI 三维评分 + 平台无关化 + benchmarks/ + references/
- v0.1.0：4 阶段 + G1-G8 + 4 类 checklist
> **版本号权威来源**：以 frontmatter `metadata.version` 为准；正文版本表如有冲突以 frontmatter 为准。
详见 [`../CHANGELOG.md`](../CHANGELOG.md) 和 [`../ROADMAP.md`](../ROADMAP.md)。
No comments yet. Be the first to comment!
