Xb Review

---
name: xb-review
description: 调用受用户配置约束：高自动、中先确认、低须明确开启；用户指定其他技能时禁止接管。审查工作交付物或复盘已完成项目，按目标、证据、逻辑、可用性、风险和验收标准给出带位置的发现；区分真实缺陷、合理取舍和风格偏好。触发：$xb-review、帮我检查、能不能交、交付前把关、复盘一下。
---

# xb-review：交付审查与复盘

调用前先读 `../xbskill/references/interaction-settings.md`，按用户已选调用强度和保存提示执行；明确指定其他技能或拒绝 XB 时退出。未初始化时只允许配置与说明，禁止代选或先执行后确认。

直调时先读取 `../xbskill/references/contracts.md`、`../xbskill/references/resolution-standard.md` 与 `../xbskill/references/intellectual-capabilities.md`；任一文件缺失时报告精确路径并停止，不得凭记忆补造契约、完成状态或理论镜头。

审查对象跨 IT、数据、自动化、写作、演示或报告，或涉及多来源冲突、批量改动、敏感信息和重复缺陷时，读取 `../xbskill/references/task-domain-patterns.md`；单一低风险文稿的局部检查不加载。

## 任务定义

两种模式不可混写：

- **交付前审查**：用当前材料判断产物是否达到明确门槛，并找会导致错误、误解、不可用或风险失控的缺陷。
- **事后复盘**：比较预期与现实结果，识别可改变下次过程的机制；没有结果时只能做过程审计或复盘准备。

审查不是修改。除非用户同时授权修复，否则只给发现和修法；“已指出”不能写成“已修复”。清单不是审查，读取一手产物并执行必要验证后才能给状态。

## 核心判断模型：主张—门槛—反例—影响

每个发现必须形成闭环：

```text
审查对象与版本 → 它声称要达到什么 → 适用验收门槛
→ 可定位证据 → 触发条件/反例 → 现实影响 → 最小修法 → 复验
```

按八维检查，但只报告有证据的发现：

| 维度 | 核心问题 | 阻塞信号示例 |
|---|---|---|
| 目标成立性 | 产物是否解决被要求的问题 | 做了另一件漂亮的事 |
| 用户侧价值 | 结果是否可用且成本可接受 | 把工作全部退回用户 |
| 事实证据 | 关键主张能否复核、范围匹配 | 无来源、旧版本、主张过强 |
| 逻辑 | 结论是否由材料支持，替代解释是否处理 | 从相关跳因果、循环论证 |
| 可操作性 | 谁在何时如何使用，怎样验收 | 只有原则没有接口 |
| 边界权限 | 授权、隐私、角色和适用范围清楚吗 | 越权外发或责任模糊 |
| 安全恢复 | 失败是否响亮、可停止、可回滚 | 静默失败或不可逆无确认 |
| 可维护性 | 换人、重跑、更新后是否仍可解释 | 隐含知识、无版本和负责人 |

## 严重度取决于影响

| 等级 | 判定 | 输出动作 |
|---|---|---|
| 阻塞 | 在正常或关键边界条件下会造成错误决定、不可用、安全/合规风险或不可逆损失 | 修复并复验前不交付 |
| 重要 | 不一定阻塞首次使用，但会显著增加误解、返工、维护或局部失败 | 本轮修复或由有权者接受风险 |
| 可选 | 不影响目标和风险的体验、清晰或一致性改善 | 不阻塞，说明收益 |
| 非问题 | 合理取舍、超出范围或纯个人偏好 | 不列为缺陷；必要时记录取舍 |

严重度由 `触发概率/可达性、影响、可检测性、可恢复性、暴露范围`共同决定。不要用“最佳实践”四个字自动升级。

## 信号词典

| 审查信号 | 要求证 | 常见误判 |
|---|---|---|
| “看起来不专业” | 哪类受众、哪个目标和可观察影响 | 风格偏好冒充缺陷 |
| “测试通过” | 测了什么版本、样本、预期和实际 | 绿色状态等于覆盖充分 |
| “大家都这么做” | 实际规则、适用范围和反例 | 惯例等于正确/授权 |
| “只有一个小问题” | 是否位于关键路径或高影响边界 | 代码/文字行数少就低风险 |
| “用户不会这样操作” | 界面是否允许、历史是否发生、代价 | 用理想用户删除负例 |
| “先交再改” | 错误可检测、可逆、谁接受风险 | 截止自动降低安全门 |
| “没发现问题” | 一手材料与关键验证是否充分 | 没测到等于没有 |
| “复盘一下” | 是否已有预期、结果和可定位证据 | 写感想或时间流水账 |

## 模式与条件分支

### A. 标准符合性审查

有正式需求、验收标准、政策或接口时，先锁定版本与适用范围，建立“要求—证据—结果”矩阵。不得用个人偏好改写硬标准，也不得用标准清单跳过真实使用。

### B. 风险优先审查

标准不完整但产物有外部影响时，从资产、用户、错误路径和不可逆动作建立风险门；明确这是“本轮暂定标准”，列制定依据和有权确认者。

### C. 可用性审查

让目标使用者或等价陌生接收方按字面完成关键任务；记录卡住位置、前置知识、静默失败和恢复。作者自测只能算补充，不能替代陌生使用。

### D. 变更/差异审查

确定基线、变更范围和声明目的；检查范围外差异、兼容性、迁移、回滚和用户锁定内容。工作区已有改动默认属于用户，不因“清理”覆盖。

### E. 事后复盘

对照 `预期、实际、差异、机制、动作、验证窗口`。单次异常与重复系统模式分开；纠正个人行为不能替代流程原因，系统原因也不抹去可证实责任。

## 理论镜头

每题最多使用 1–2 个镜头，先读产物再选。常用两种：

- **波普尔**：为关键主张预写最强反例和翻转门；适合单次交付判定。
- **戴明**：用同口径多次样本区分共同原因和特殊原因；适合重复缺陷复盘。

使用时必须落实 `触发证据、观察、动作、产物字段、推翻条件`。没有改变审查动作就删除人物名。不能以理论概念替代文件、数据、日志、用户操作或公司授权。

## 执行流程

1. 锁定对象、当前版本、受众、目标、审查范围、明确排除项和截止。
2. 收集标准及来源；缺标准时建立最小门槛并标暂定、依据和确认人。
3. 先读一手产物，画关键主张、使用路径、权限和外部副作用；不从作者摘要下结论。
4. 选择最能暴露高影响缺陷的验证：正常、边界、错误、重复、负例、恢复或陌生接收方。
5. 主动找反证，也找看似问题但实际合理的取舍，防止只收集批评。
6. 对每个发现写证据位置、触发、影响、严重度理由、最小修法和复验方式；合并同根因重复项。
7. 分开报告阻塞、重要、可选、已验证优点和非问题；没有实质缺陷就明确通过。
8. 若用户授权修复，修后重新读取当前版本并复验；原发现不因“改过了”自动关闭。
9. 给状态、覆盖边界、未测部分、现实反馈和用户复核点。

## 发现字段

```text
标题：用可观察故障描述
严重度：阻塞 / 重要 / 可选
对象版本与位置：文件+行 / 页 / 单元格 / 步骤 / 条件
适用标准及来源：
触发条件或反例：
实际结果：
预期结果：
用户/业务影响：
为什么是此严重度：
最小修法：
复验方法与通过阈值：
会翻转本发现的证据：
```

## 最终产物

```text
审查类型与状态：未审 / 部分审 / 已审
对象、版本、目标、范围与排除项：
标准来源与暂定项：
执行过的验证及证据：
阻塞项：
重要项：
可选项：
已验证优点：
合理取舍/非问题：
未覆盖与无法验证：
整体结论：通过 / 有条件通过 / 不通过 / 无法判定
现实反馈点：
用户复核点：
```

## 案例校准

**正例**：审查月报时，将“数据可用于预算决定”设为关键主张，抽查总量与明细、跨月口径和一个边界月份。边界月份仍沿用旧口径，可能改变预算排序，于是判阻塞，给出具体单元格、触发范围和按统一口径复算的复验门。

**反例**：没有打开交付物，只根据作者描述生成通用检查清单，就写“整体质量较高，建议优化标题配色”。前者没有审查证据，后者没有目标影响。

**边界例**：方案没有风险章节，但正文已在每个选项下清楚写出风险、承担者和控制。若受众能完成决定且标准未要求独立章节，这属于结构取舍，不应为模板一致性制造缺陷。

## 验证、失败与翻转

- 一手对象缺失或版本不明：状态为未审/无法验证，不能“基于描述通过”。
- 只跑顺利路径或只做静态阅读：状态为部分审，明确未覆盖的失败面。
- 发现无法写出触发条件和影响：降为问题线索或个人偏好，不进入正式缺陷。
- 修复后原样本通过但负例、恢复或相邻路径失败：发现未关闭。
- 新证据证明标准不适用、触发不可达或影响不存在：撤回或降级发现并说明原因。
- 复盘没有现实结果或重复样本：只给暂定机制，不称防复发已验证。

## 结果回流

记录 `发现类型、首次遗漏环节、真实是否发生、修复成本、复验结果、复发情况、误报原因`。重复缺陷进入不可绕过的检查或自动验证；误报进入边界和非问题库。评估审查净收益时同时计算降低的风险与增加的等待、流程和维护成本，防错不能演变成无差别阻塞用户。