winson-ai-output-three-tier-audit

AI 产物三层审核法。把"能看 → 能用 → 能放心用"三个指数级跃迁的标准转化为可执行的审核流程，配合"举一反三深挖"识别系统性卡点。

Use this skill when the user needs to: 审计 AI 生成的代码/产品/文档产物是否真正可交付，评估 AI 产物的成熟度，做发布前的最终验收，从"功能存在"升级到"敢放心交付"，识别 AI 产物的隐藏卡点，或对 AI 协作产物做系统性 review。

Trigger keywords: AI产物审核, 三层审核, 能看能用能放心用, 交付验收, 举一反三, 卡点排查, review, 验收标准, 成熟度评估, winson-ai-output-three-tier-audit.

一、核心哲学（必读）

1.1 唯一铁律

> AI 产物的成熟度不是线性的，是指数级跃迁的。

"能看"、"能用"、"能放心用"不是同一根标尺上的三个刻度，而是三根完全不同的标尺。从一层到下一层，所需投入的脑力、时间、洞察力都是前一层的指数倍。

1.2 三个底层认知

1.3 核心公式

能看（理想路径成立）
  → 能用（现实路径成立）
    → 能放心用（敌对路径成立）
      → 交付

每一层都是独立审核 pass，使用不同的审核工具：
  能看层  → 契约对照、编译验证、表面演示
  能用层  → 交互流程穿越、错误路径追问、边界值测试
  能放心用层 → 举一反三深挖、竞态/生命周期/原子性追问、数据一致性审计

1.4 关键概念：敌对路径

"敌对路径"不是恶意攻击，而是 "AI 默认不主动思考的运行场景"。AI 生成产物时走最短可行路径，这些场景它默认不提：

能放心用层的本质，就是假设这些场景一定会发生，追问产物在这些场景下是否仍然成立。

1.5 为什么这样设计

AI 产物有一个共同病灶：在理想路径上无懈可击，在现实路径上漏洞百出。

这是因为 AI 生成产物时默认走"最短可行路径"——它能写出编译通过的代码、能讲清楚功能演示、能让文档自洽。但 AI 默认不会主动思考：
- 用户在动画期间按快捷键会怎样？
- 异步请求进行中切换上下文会怎样？
- 删除当前活动对象后，持有引用的另一方会怎样？

这些"会怎样"不是 AI 不会处理，而是 AI 默认不主动提出。三层审核法的本质，是用结构化的追问，强迫 AI 把这些"默认不提"的隐患显性化。

二、完整执行流程

Phase 1：基线确认（Baseline）

Step 1.0：产物结构摸查

审核前先建立产物的整体心智地图。不要直接开始审细节——没有全局观的审核会漏掉跨模块的系统性卡点。

操作：
- 列出产物文件结构（目录树）
- 识别核心模块与入口点
- 找到契约文件（章程/规范/类型定义/接口声明）
- 摸清依赖关系（谁调用谁、谁持有谁）
- 标注关键状态对象的生命周期（在哪里创建、在哪里使用、在哪里销毁）

输出：产物结构图 + 模块清单 + 依赖关系图 + 关键对象生命周期表。

> 💡 为什么要先摸查：举一反三深挖（Phase 4）需要扫描"所有同类触发点"，没有全局视图就会漏扫。先建立地图，后面才能系统性追问。

Step 1.1：找到契约

任何审核的第一步都是找到"应该符合什么标准"。没有基线的审核是挑刺，有基线的审核是验收。

契约来源清单（按优先级）：
1. 项目章程 / 架构规范 / 设计文档
2. 团队硬约束 / 工程约定 / 历史教训
3. 行业默认标准（如数据隔离、原子性、向后兼容）
4. 用户口头要求的隐含期望

输出：一份"应该满足什么"的清单。

Step 1.2：列出"应该有什么"

从契约反推产物的预期结构。例如契约说"三层架构"，那产物就应该有三层落地的证据。

检验标准：能否用一句话回答"这个产物应该有什么、不应该有什么"。

输出：基线对照表（契约条款 → 预期实现位置）。

Phase 2：能看层审核（Looks Right）

> 目标：产物在理想路径上成立。

Step 2.1：契约落地对照

逐条对照基线表，确认每条契约都有对应的实现位置。

检验问题：
- 章程/规范要求的每一项，在代码/产物中能找到对应位置吗？
- 文档描述的功能，实际实现了吗？
- 数据结构是否与设计一致？

输出：契约落地表（条款 → 位置 → 状态：✅/⚠️/❌）。

Step 2.2：编译/构建验证

检验问题：
- 产物能否通过编译/构建？
- 类型检查是否通过？
- 静态分析有无致命错误？

输出：构建结果（pass/fail + 错误清单）。

Step 2.3：表面功能演示

检验问题：
- 主流程能跑通吗？
- 关键功能在"理想输入"下能工作吗？
- 文档与实现是否自洽（文档说有，实际也有；文档没说，实际也没有）？

输出：演示结果。

Step 2.4：文档同步检查

检验问题：
- 文档描述的实现细节是否与代码一致？
- 是否有过时的条款（如文档说"用方案 A"，代码已升级为"方案 B"）？
- 版本号/日期是否更新？

输出：文档偏差清单。

能看层的退出标准

• [ ] 所有契约条款都有落地位置
• [ ] 编译/构建通过
• [ ] 主流程能演示
• [ ] 文档与实现无重大偏差

> ⚠️ 重要警告：能看层通过 绝不代表 产物能用。这只是"看起来像那么回事"。

Phase 3：能用层审核（Works in Reality）

> 目标：产物在现实路径上成立。

Step 3.1：交互流程穿越

不再用"理想输入"，而是模拟真实用户的操作序列。

检验问题：
- 用户在"非预期时刻"操作会怎样？（如加载中、切换中、动画中）
- 用户重复操作会怎样？（如双击、连点、快速切换）
- 用户走"非主流程"路径会怎样？（如取消、返回、中断）

典型卡点：
- 加载中按快捷键 → 触发了不该触发的动作
- 动画中点击 → 状态错乱
- 快速切换 → 旧请求污染新状态
- 边界值（空输入、超长输入、负数）→ 崩溃或静默失败

输出：交互断裂清单。

Step 3.2：错误路径追问

对每个能想到的失败点追问"失败后会怎样"。

检验问题：
- 网络/IO 失败后，UI 是否有反馈？还是会无限 loading？
- 失败后状态是否回滚？还是停留在半成品状态？
- 失败是否被静默吞掉？日志是否记录？
- 用户能否从失败状态恢复？还是必须重启？

输出：错误路径缺陷清单。

Step 3.3：视觉/数据一致性

检验问题：
- UI 显示的数据与底层状态是否一致？
- 多个视图（如列表 + 详情）是否同步？
- 操作后的反馈是否对应实际发生的事？

输出：一致性缺陷清单。

Step 3.4：边界与默认值

检验问题：
- 空值/零值/负值是否处理？
- 默认值是否合理？
- 上限是否定义（如输入长度、列表容量）？

输出：边界缺陷清单。

能用层的退出标准

• [ ] 所有交互流程闭环（含非预期时刻、重复操作、非主流程）
• [ ] 错误路径有反馈、有回滚、可恢复
• [ ] 视觉与数据一致
• [ ] 边界值不崩

> ⚠️ 重要警告：能用层通过 绝不代表 产物能放心用。这只是"日常使用不崩"。

Phase 4：能放心用层审核（Trustworthy Under Adversity）

> 目标：产物在敌对路径上仍成立。

这是最难的一层，也是大多数 AI 产物翻车的地方。核心工具是 举一反三深挖。

Step 4.1：举一反三深挖（核心方法）

方法论：把 Phase 3 发现的每个卡点当作"模板"，沿同一主线继续深挖同类隐患。

操作步骤：

1. 列出已发现的所有卡点（来自 Phase 2-3）
2. 为每个卡点抽象出"主线"（详见下方"主线抽象法"）
3. 沿每条主线追问："还有没有其他地方犯同类错误？"
4. 扫描所有同类触发点（依赖 Phase 1.0 的产物结构图）

主线抽象法（如何从已修复问题抽象主线）

主线模板库（用于启发，不穷尽）：

输出：举一反三隐患清单（主线 → 已修复 → 新发现 → 优先级）。

Step 4.2：竞态与并发审计

检验问题：
- 哪些操作是异步的？它们之间有竞态吗？
- 共享状态的读写是否同步？
- "先读后写"中间是否有窗口期？
- 多个定时器/回调是否会互相踩踏？

典型卡点：
- 请求 A 开始 → 请求 B 开始 → 请求 B 先返回 → 请求 A 返回覆盖 B 的结果
- 切换开始 → 旧请求还在写 → 旧请求写入污染新状态
- 计时器在对象销毁后仍触发

输出：竞态缺陷清单。

Step 4.3：生命周期审计

检验问题：
- 每个对象的创建/使用/销毁是否闭环？
- 销毁后是否还有引用持有？（孤儿引用、悬挂指针）
- 销毁后是否还有回调会触发？
- 创建时的初始状态是否完整？（避免继承上一对象的脏状态）

输出：生命周期缺陷清单。

Step 4.4：原子性与一致性审计

检验问题：
- 多步操作是否原子？中途失败会怎样？
- 回滚是否真的能回滚？回滚本身失败呢？
- 持久化与内存状态是否一致？
- 跨进程/跨模块的引用是否同步更新？

输出：原子性缺陷清单。

Step 4.5：契约边界审计

检验问题：
- 每个模块/函数是否遵守自己的词汇表/契约？
- 默认值、回退值、硬编码值是否都符合契约？
- 文档声明的边界（如"至少保留一个"）是否在所有路径上都被强制？

输出：契约违反清单。

能放心用层的退出标准

• [ ] 举一反三深挖完成（每条主线至少追问 3 个同类场景）
• [ ] 所有竞态有守卫或消解
• [ ] 所有生命周期闭环（无孤儿引用、无悬挂回调）
• [ ] 所有原子操作有回滚且回滚可靠
• [ ] 所有契约边界在所有路径上被强制

> ✅ 通过此层 = 可以放心交付。

Phase 5：修复与回归（Fix & Regression）

Step 5.1：优先级排序

把所有发现的卡点按以下标准排序：

输出：优先级清单。

Step 5.2：修复执行

执行原则：
- 同一文件的修改合并到一次提交
- 每个修复点在代码中标注（如 [修复 X] 注释）
- 修复前备份原文件
- 每完成一个修复点立即编译验证（见下方硬性纪律）

硬性纪律：编译验证节奏

> 不要批量修改后一次性验证——失败时无法定位是哪个修复引入的问题。

• 每完成一个修复点 → 立即编译验证
• 编译失败 → 回滚该修复点 → 重新设计
• 编译通过 → 进入下一个修复点
• 全部修复完成 → 最终整体验证 + 构建产物

输出：修复清单（卡点 → 修复位置 → 验证结果）。

Step 5.3：回归审核

修复可能引入新卡点。修复完成后回到 Phase 2-4 重新审核。

重点回归：
- 修复点附近的代码是否被破坏？
- 修复引入的新接口/参数是否被所有调用方正确使用？
- 修复是否触发了新的举一反三主线？

输出：回归结果。

Phase 6：文档同步与版本控制（Doc & Version）

Step 6.1：文档同步

检验问题：
- 设计文档是否与修复后的实现一致？
- 变更日志是否记录了本轮所有修复？
- 过时条款是否被更新？

输出：更新后的文档。

Step 6.2：版本控制

• 原文件备份（如 .v1.0.bak、.v2.0.bak）
• 变更日志追加（按版本号记录修复列表）
• 编译验证 + 构建产物更新

输出：版本控制产物。

Phase 7：审核报告输出（Report）

审核的最终交付物是一份结构化报告，让审核结果可追溯、可执行、可交接。

Step 7.1：报告结构

# [产物名] 审核报告

## 一、总体结论
- 是否符合契约（能看）：✅/⚠️/❌
- 是否交互闭环（能用）：✅/⚠️/❌
- 是否敌对路径成立（能放心用）：✅/⚠️/❌

## 二、契约落地表（来自 Step 2.1）
[表格]

## 三、卡点清单（按 P0/P1/P2 排序）
[表格]

## 四、举一反三深挖表（来自 Step 4.1）
[表格]

## 五、修复清单（来自 Step 5.2）
[表格]

## 六、仍存在的卡点（P2 未修）
[列表]

## 七、优先执行建议（按修复成本/收益比排序）
[列表]

Step 7.2：报告输出原则

• 可执行：每个卡点都有具体位置（文件+行号）和修复建议
• 可追溯：标注每个卡点来自哪个 Phase、哪条主线
• 可交接：其他人拿到报告能直接按优先级执行修复

输出：Markdown 审核报告。

三、审核工具箱

3.1 契约对照表模板

3.2 举一反三深挖表模板

3.3 错误路径追问模板

对每个失败点填表：

3.4 优先级清单模板

3.5 关键对象生命周期表模板（来自 Step 1.0）

四、常见陷阱与避坑指南

五、场景适配指南

六、质量检验清单

完成审核后逐项检查：

流程完整性

• [ ] Phase 1.0 产物结构摸查完成？关键对象生命周期表已列？
• [ ] Phase 1 基线确认完成？契约清单已列？
• [ ] Phase 2 能看层独立通过？退出标准全勾？
• [ ] Phase 3 能用层独立通过？退出标准全勾？
• [ ] Phase 4 能放心用层独立通过？举一反三至少 3 条主线？
• [ ] Phase 5 修复后有回归审核？每个修复点都即时编译验证？
• [ ] Phase 6 文档与版本控制同步？
• [ ] Phase 7 审核报告已输出？

审核深度

• [ ] 每个卡点都抽象了主线？
• [ ] 每条主线都追问了至少 3 个同类场景？
• [ ] 竞态、生命周期、原子性、契约边界四类审计都做过？
• [ ] 优先级清单完整（P0/P1/P2）？

交付质量

• [ ] P0 全部修复？
• [ ] P1 全部修复或明确排期？
• [ ] P2 全部记录？
• [ ] 文档与实现一致？
• [ ] 变更日志已更新？
• [ ] 审核报告可执行、可追溯、可交接？

七、执行原则

1. 三层独立 pass，不可合并：能看层通过不等于能用层通过；能用层通过不等于能放心用层通过。每层有独立的退出标准。
2. 先全局后细节：Phase 1.0 的产物结构摸查是后续举一反三扫描的基础，不可跳过。
3. 举一反三是能放心用层的灵魂：单点修复追不上系统性缺陷。沿主线深挖是唯一可靠方法。
4. 主线抽象是举一反三的关键技能：去掉业务词汇、只留结构、归类命名，才能扫描所有同类触发点。
5. 契约是审核的基线：没有契约的审核是挑刺。先找契约，再开始审。
6. 修复必须回归：修复引入的新卡点往往比原卡点更隐蔽。
7. 编译验证逐个进行：每个修复点立即编译，不要批量修改后一次性验证。
8. 文档与代码同等重要：文档过时是 P1，不是 P2。
9. P2 必须记录：不修可以，但不能遗忘。已知卡点清单是下一轮审核的输入。
10. 审核必须输出报告：没有报告的审核等于没审——结果无法追溯、无法交接。
11. AI 产物的默认盲区是"敌对路径"：AI 默认走最短可行路径，不会主动思考用户在动画期间按快捷键、在请求进行中切换上下文。三层审核法的本质是用结构化追问强迫把这些盲区显性化。
12. 审核的终点是"敢不敢交付"：不是"有没有问题"，是"敢不敢在敌对路径上仍然交付"。能放心用层通过 = 敢交付。

八、局限与边界

三层审核法是 静态推演，不是动态测试。它能识别"想得到的卡点"，但识别不了"想不到的卡点"。

局限

边界

与其他能力的关系

• 三层审核法 = 静态推演（"想得到"的卡点）
• 单元/集成测试 = 动态验证（"跑得到"的卡点）
• 真实用户反馈 = 未知发现（"想不到"的卡点）

三者互补，不可相互替代。三层审核法是 发布前的第一道关，但不是唯一一道关。

关于作者