盲区审计编排器 (Blindspot Audit Orchestrator)

把「我想优化 X，我知道 A、B 两个维度有问题」翻译成一次补全了盲区维度、带对抗证伪、落盘可接手的多维审计。

语言约定：正文一律中文；状态词/裁定词保留英文（P0-P3、CONFIRMED / DOWNGRADED / REFUTED、live-traffic / dormant、Frozen(tripwire) 等）。

定位与流水线

用户重构意图（已知维度不全）
   ↓
【本 skill】盲区扩维 → 多维审计 → 对抗证伪 → 审计文档集落盘
   ↓  产出：{专项目录}/000-README + 00-总览与决策台账 + 01..0N 维度审计
   ↓  （用户拍板 00 文档里的 D-x 决策后）
requirements-matrix-generator → requirements/（需求矩阵）
   ↓
spec-dev → Kiro Specs 四件套
   ↓
loop-prompt-generator → 无人值守批量执行提示词

本 skill 只负责第一段。审计文档集的质量决定了整条 SSD（spec-driven development）链的质量——盲区在这一层漏掉，后面每一层都放大。

理论根基（官方《Finding your unknowns》四象限 → 本 skill 的机制映射）

Quick Reference

核心流程:

意图接收 → 盲区扩维 → 访谈确认 → 审计执行 → 对抗证伪 → 汇总落盘
  (1)        (2)         (3)        (4)        (5)        (6)

快速检查（每次执行前过一遍）:

• 维度数 = 用户给的 + 扩维补的 + 固定盲区维（最后一维必须是"盲点与横切扫描"）
• 每个维度分配了独立发现前缀（MA-x / FUL-x 式），互不撞号
• 真相源已确认：源码 HEAD sha + 运行环境实测方式（灰度 URL / DB / 日志）
• 环境探测类结论（DNS/网络/第三方服务）不允许只凭本机测量定 P0
• 用户独有知识清单已在访谈中过（资产归属/内容真实性/历史决策）
• P0/P1 全量走对抗证伪（见 references/falsification-protocol.md）
• 每个维度文档都有「健康面正向核销」章节（防过度工程 + 防后续重复怀疑）
• 00 总览的决策项写成选项集（a/b/c + 推荐），不是模糊建议

Standard Workflow

Step 1: 意图接收与语境侦察（intake）

从用户输入 + 快速侦察提取六件事，缺的主动补：

1. 目标与边界：审计什么（页面集/子系统/链路）、明确排除什么（007 排除 /docs 与登录后页面）
2. 用户已知维度：用户点名的关注点 → 直接进维度表
3. 真相源双证配置（runtime > canon 的物质基础）：
   • 源码侧：repo 路径 + 当前 HEAD sha（审计锚点固定在这个 sha）
   • 运行侧：灰度/生产 URL（curl 实测）、DB 访问方式、公开 API 端点
   • 两侧版本必须一致或标注差异（007 用「HEAD=955e3a18 =灰度部署版本，三面一致」开头）
4. 上游基线：有没有前一轮审计/问题清单（如 MKT-1~24）？有 → 审计任务里必须含「逐项复核今日状态：仍在 / 已修 / 部分修 / 需重新定性」，防止重复发现与误报已修项
5. 项目纪律来源：.claude/rules/*、CLAUDE.md、记忆文件——注入维度 agent 的提示词，但记忆断言必须先对抗 confirm/refute 再引用（历史双向翻车：把"设计过从未实现"当"已实现有 bug"；把"文档说未接线"当真而实际已接线）
6. 交付模式（问用户或按语境判断）：
   • 模式 A（会话内执行）：本会话 fan-out 维度 agent，直接落盘文档集。维度 ≥5 且用户已授权 workflow 时可用 Workflow 编排；否则 Agent 工具分批并行
   • 模式 B（提示词包）：不执行，生成 {专项目录}/audit-prompts/ 下的 paste-ready 提示词文件（一维一文件 + 一份编排总纲），用户拿到任何会话/机器上跑。模板见 templates/dimension-agent-prompt.template.md

Step 2: 盲区扩维（本 skill 的灵魂）

用户给的维度只是 Known Knowns。依次跑四个机制，产出候选维度：

机制 1 — 维度库比对：按目标类型查 references/dimension-library.md，列出该类型的基础维度集，找出用户没提的。

机制 2 — codebase 侦察反推：快速 Explore 目标涉及的文件面/子系统 → 反推缺失维度。判据：目标触碰了某子系统的数据或状态，但用户没提这个子系统 → 补维度。（例：用户要改支付入口，侦察发现入口写 subscription_state 表 → 补「订阅生命周期」维。）

机制 3 — 六视角轮换：每个视角问一句「这次改动我最怕什么」，怕的东西没有维度承接 → 补：

• 终端用户（被错扣钱/看到假信息/流程断链）
• 运营（关不掉/看不见/补救无杠杆）
• 客服（对账口径/退款语义说不清）
• 攻击者（滥用面/绕过面/薅羊毛面）
• 财务/审计师（账实不符/合规披露缺失）
• 三个月后接手的工程师（文档漂移/幽灵配置/无守护回归）

机制 4 — 固定追加维（无条件，两个）：

• 盲点与横切扫描维（0N，最后一维）：任务 = 审计「其他维度的任务书都没覆盖的地方」+ 横切面（跨维度共享的基建：cron 投递、锁、环境配置、CI 守护）。007 的 BS 维抓出零度量，009 的 BLD 维抓出 P0 悬挂预扣——两轮最重的发现都出自这一维
• 度量与可验证性检查（独立维或并入盲区维）：目标域有没有度量？没有 → 一切改进无法验证效果，本身就是 P0 级发现（007 BS-1 教训）

产出维度提案表给用户确认（这是本 skill 与用户唯一必需的确认门）：

| # | 维度 | 前缀 | 来源 | 审计焦点（一句话） |
|---|------|------|------|------------------|
| 01 | {用户给的} | XX- | 用户点名 | ... |
| 02 | {扩维补的} | YY- | 维度库/侦察/视角:{哪个} | ... |
| 0N | 盲点与横切扫描 | BS- | 固定追加 | 其余维度未覆盖处 + 横切基建 |

维度数经验值：6-9 个（007/009 都是 8）。少于 4 说明目标太小可能不需要本 skill；多于 10 建议合并或拆两轮专项。

Step 3: 访谈（用户独有知识确认门）

维度确认后、开审前，一次性问清两类问题（用 AskUserQuestion，架构性问题优先——答案会改变审计范围/维度划分的先问）：

A 类 — 用户独有知识（审计者不可能从代码/网络推出的事实）：

• 资产归属：域名/邮箱/账号哪些是用户真实持有？（007 教训：审计判 token101.ai 是废域要全站替换，真相是生产域；判 support 邮箱是黑洞，真相是用户自持可收信——方向整个反了）
• 内容真实性：证言/数据/案例是真实有授权还是占位？
• 历史决策：哪些「看起来是 bug」其实是拍过板的有意为之？（有决策台账/记忆的先读）
• 环境语境：生产是否真实开量（Stripe test/live？）——决定发现的暴露度定级

B 类 — 审计执行参数：

• 严重度语境：什么算这个项目的 P0？（资金错误？诚信问题?数据泄露?）
• 产出目录：专项文档放哪（如 013-新一轮优化专项/0XX-{专项名}/）

问不到答案的项：不阻塞开审，但相关发现必须标注「待用户确认（涉及用户独有知识）」，禁止直接定 P0。

Step 4: 审计执行设计

给每个维度 agent 注入统一纪律（完整提示词模板见 templates/dimension-agent-prompt.template.md），核心七条：

1. runtime > canon：每条发现锚定 file:line（HEAD={sha}）+ 实测日期；数量断言（"只有 2 处消费点"）必须实际执行 grep/读码取得，禁止引用文档数字
2. 双证：源码证据 + 运行环境实测（curl 灰度页面/API、查 DB）各一，只有单证的发现要标注
3. 暴露度标注：每条发现标 live-traffic / dormant / ops-only。dormant 高危项建议 Frozen(tripwire)（登记解冻触发器）而非立即修
4. 误报防御：环境探测类结论（DNS 解析/网络可达/第三方服务状态）必须附「本机环境可能被代理/DNS 污染」的免责标注，只能定为「待复核」不能定 P0；「本机测不到」≠「不存在」。实测证据须有效：用"必然失败的输入"测出的失败证明不了机制（假 key 得 401 ≠ session-only）
5. 健康面正向核销：单列一章写「查过且干净的面」（防过度工程 + 防止后续审计者重复怀疑同一处）
6. 交叉引用：发现与其他维度相关时显式标注（→ 0X 维），交叉实锤的问题在汇总时升权重
7. 视觉资产机扫：审计范围含截图/图片时，文本 grep 扫不到图里的东西——涉敏维度（暴露/准确性类）必须用 Read 工具逐张读图核查敏感值（key/UUID/内部数据/过期 UI）。008 实锤：全场最重的 P0（截图泄真实 API key）只有读图能抓到

执行编排（模式 A）：

• 维度 agent 并行 fan-out，各自落盘 {NN}-{维度名}.md（结构见 templates/dimension-audit.template.md）
• findings 摘要随文档落盘（防丢关键设计）：要求 agent 把结构化 findings 摘要写进文档头部 frontmatter（格式见模板），返回值只是它的副本——agent 撞限额丢返回值时，主线程从磁盘 head 提取即可，零损失（008 实锤：4/8 agent 丢返回值，报告全在磁盘）
• 大批量注意（009 实战经验）：分块执行而非单次全并行；agent 撞限额死掉时先盘磁盘再重跑（文件常已写完只丢返回值）；嵌入大上下文时用 ASCII 编码防 Unicode 解析炸

Step 5: 对抗证伪波（P0/P1 全量，不可跳过）

审计完成后，全部 P0/P1 发现交独立证伪 agent 双向验证。协议全文见 references/falsification-protocol.md，要点：

• 证伪者不信任原审计者的任何引用，独立重推 file:line
• 双向找证据：既找支持也找反驳
• 四个高频翻车点必查：设计 vs 实现混淆、锚点漂移（含幻觉锚点）、语境缺失（用户独有知识）、无效实测证据（假凭证/污染环境测出的结论）
• 裁定四值：CONFIRMED / DOWNGRADED / UPGRADED / REFUTED，产出裁定表进 00 总览
• 分批每批 ≤5 条
• 限额受阻不弃守：证伪波撞会话限额时按协议降级序执行——交叉实锤=内建证伪 / 单源 P0 主线程亲验（含读图）/ 单源 P1 标 PENDING+实施前逐条前提复核，裁定表诚实登记方式（协议文件「限额/资源受限降级协议」节）

007 实测 2/6 P0 被证伪波+用户确认拉下来；009 实测 19 条里 2 条 DOWNGRADED、0 REFUTED；008 实测抓获 1 个幻觉锚点 + 1 组无效证据（结论均经换证据后保住）——证伪波成本远低于按误报立项实施的浪费。

Step 6: 汇总落盘

产出固定文档集（模板见 templates/）：

{专项目录}/
├── 000-README-目录索引与接手说明.md   ← 阅读顺序表 + 当前状态 checkbox + 关键结论速记
├── 00-现状总览与迭代指南.md           ← 见下方结构
├── 01-{维度1}.md ... 0N-盲点与横切扫描.md
└── (可选) 专题指南                    ← 审计发现「代码就绪只差配置/操作」类问题时，
                                        写成可操作的点亮指南（007 的 09-度量点亮指南模式）

00 总览的固定结构（这是拍板与接手的主入口）：

1. 一句话总判断（含自然优先序，如「诚信止血 > 度量点亮 > 架构提速 > 增长打磨」）
2. P0 全景（跨维度聚合，标来源维度；含证伪裁定状态）
3. P1 精选（按维度，完整清单指向各维度文档）
4. 健康面（跨维度汇总不需要动的，防过度工程）
5. 迭代批次建议（A-H：按依赖关系+主题成批，不按发现顺序；标注每批前置的拍板项；给推荐执行序）
6. 待拍板决策清单（D1-Dx）：每项 = 问题 + 选项集(a/b/c) + 推荐 + 涉及的发现编号。这是与用户讨论的主菜单
7. 与既有专项/资产的衔接（口径 SSOT 来自哪个专项）
8. 讨论记录（留空章节，拍板后逐条回填裁决——文档是活的决策台账）

收尾动作：向用户报告「维度×发现数、P0/P1 清单、证伪裁定、待拍板 D-x 菜单」，并提示下一步：拍板 D-x → 调用 requirements-matrix-generator 进入需求矩阵阶段。

铁律（从 007/009 两轮实战蒸馏，违反任意一条 = 审计质量不可信）

1. 每条发现必须 file:line + 实测日期，数量断言必须实际 grep
2. 双证优先；环境探测类结论禁止只凭本机测量定 P0；实测证据须有效（假凭证测出的失败不算证据）
3. 用户独有知识确认门必须过——资产归属/内容真实性/历史决策不是代码能回答的
4. P0/P1 全量对抗证伪，裁定表落盘；限额受阻按降级协议执行并诚实登记，禁止把 PENDING 静默当 CONFIRMED
5. 暴露度先于优先级：dormant 高危 → Frozen(tripwire)，不立即修
6. 每个维度必须写健康面正向核销
7. 最后一维固定为盲点与横切扫描维
8. 有上游基线必须逐项复核今日状态（仍在/已修/部分修/需重定性）
9. 记忆/老文档断言先对抗 confirm/refute 再引用
10. 决策写成选项集交拍板，不写模糊建议；拍板结果回填 00 文档（文档即台账）
11. 产出边界到审计文档集为止；requirements 是下游 skill 的职责
12. 关键结论不留在对话里——全部落盘（findings 摘要进文档 frontmatter），000-README 保证任何新会话可接手
13. 审计范围含视觉资产（截图/图片）时必须逐张读图机扫——文本 grep 对图片盲

文件指针

版本记录

• v1.2（2026-07-08）：008 端到端实施验证（审计结论经得起实施检验）。008 docs 专项首次跑通全链（审计→矩阵→specs→loop→12 spec 全终态），实施阶段反向验证了本 skill 的审计质量——正向信号，非新增机制：
  • 4 个 P0 组在实施中全部坐实为真问题：死链域 252→0、quickstart 篇幅 7.2 倍冗余、me* 端点 401、截图泄真实 key——审计层判定的 P0 无一在实施时被推翻。印证「runtime 双证 + 对抗证伪」把误报拦在审计层的价值（对比若审计误报，实施波会白做整批 spec）。
  • 维度库类型 G（文档/知识库）经完整使用验证有效：008 的 8 维配置（准确性/覆盖度/旅程/UI交互/内部暴露/双语/SEO/盲点）一路贯穿到 12 需求零遗漏追溯，说明类型 G 的基础维度集不缺关键维、无冗余维。
  • 用户独有知识确认门二次兑现价值：D3「泄漏的 API key 用户确认已失效」——审计者不可能从代码/网络推出 key 是否仍有效，用户一句话把该 P0 从「需全站轮换止血」改写为「登记失效即可关闭」。与 007（域名归属/邮箱黑洞误报）同类，坐实此门是跨专项稳定复现的必需门，不是 007 偶发。
  • 一句话教训：blindspot-audit 主要价值在审计阶段；实施阶段的意义是「审计结论若立得住，下游每一层都省一次返工」——008 证明立得住。顶层串联指南见 _skills/SSD-全链路方法论.md。
• v1.1（2026-07-07）：008 docs 审计首跑回填 4 项——① 证伪波限额降级协议（交叉实锤=内建证伪 / 单源 P0 主线程亲验含读图 / 单源 P1 标 PENDING）② 误报防御新增"假阴性证据"与"幻觉锚点"两类（假 key 401 证明不了 session-only；auth.ts:177 不存在但结论仍真）③ 视觉资产逐张读图机扫升为纪律第 7 条+铁律 13（截图泄真实 key 靠读图抓获）④ findings-summary frontmatter 先行落盘防返回值丢失（4/8 agent 丢返回值报告全救回）；维度库新增类型 G 文档/知识库
• v1.0（2026-07-07）：初版，蒸馏 007 前端 8 维审计 + 009 支付 8 维审计 + 官方《Finding your unknowns》四象限