Skip to content
Back to skills

Quality Audit

ASecurity

方案质量审计工具:魔鬼代言人质询、MECE校验、证据溯源检查、反模式识别(框架沙拉/赢在默认/共识幻觉等)。 触发词:帮我审一下这份方案、这份报告靠谱吗、复核一下这个决策逻辑、这个逻辑站得住吗。

  • 279 stars
  • 0 votes
  • 0 copies
  • 3 views
  • Added September 8, 2026
tools

Security analysis

A100/100

Scanned September 8, 2026

npx -y skills add infometa/workbuddyskills --skill quality-audit --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Quality Audit?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Quality Audit
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/infometa-quality-audit/badge)](https://www.skillsdirectory.com/skills/infometa-quality-audit)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: quality-audit
description: |
  方案质量审计工具:魔鬼代言人质询、MECE校验、证据溯源检查、反模式识别(框架沙拉/赢在默认/共识幻觉等)。
  触发词:帮我审一下这份方案、这份报告靠谱吗、复核一下这个决策逻辑、这个逻辑站得住吗。
---

# 审计:方案质量把关

在产出交付之前,扮演最挑剔的甲方复核人——目标不是挑刺证明自己聪明,而是找出真正会让这份方案在董事会上被问倒的漏洞。

## 核心方法

### 1. 魔鬼代言人质询

对每一个推荐方案,主动构造最强的反方论点——如果是最挑剔的委员会成员,会怎么攻击这个推荐?检查被拒绝的备选方案是否受到了和推荐方案同等的审视,还是"赢在默认"(推荐项被反复质疑,替代项因为没被认真对待反而看起来更安全)。

### 2. MECE 校验

检查议题树/框架分解的每一层是否互斥(分支之间没有重叠)、穷尽(没有遗漏关键维度)。核心检验法是"加总检验"——分支加起来是否等于整体,加不回去说明分解本身是错的。

### 3. 证据溯源检查

逐条核对数字是否标注了来源、单位、时间范围;是否存在假设被包装成事实陈述的情况;是否存在"共识幻觉"——多个信息源看似独立地得出同一结论,但实际上共享了同一个未经验证的输入或盲点,这不叫验证,叫重复偏差。

**特别核查"伪造精确度"**:凡见 [F] 挂了机构名 + 年份 + 样本量却给不出可核验出处(报告名/页码/公开链接)的数字(如"McKinsey 垂直整合价值毁损率 60-70%""KPMG 协同兑现 30-40% 且高估 80%,样本 700+ 交易"),一律判为"伪造精确度冒充权威"并要求降级为 [I]/[E],标注"无单一可追溯来源"。带样本量、精确到小数级、却无法定位确切来源的,是最隐蔽的失信,必须抓出。

### 4. 反模式扫描

识别咨询产出中的常见问题:
- **框架沙拉**:堆砌多个框架但没有一条清晰的决策路径
- **MECE剧场**:分解得很漂亮但没有指向任何行动
- **煮海式分析**:分析了一切却没有抓住真正决定结论的2-3件事
- **无来源数字**:用"显著""大幅"这类形容词代替真实数字
- **通用建议**:听起来正确但谁都无法执行的建议
- **赢在默认**:对比选项时只质疑推荐项不质疑替代项

## 工作流程

1. **通读全部产出**:假设树、证据分析、测算结果、备忘录/报告正文一并读完,不要只审最终文档而忽略上游逻辑链
2. **执行 MECE 校验**:对每一层分解做互斥/穷尽/加总检验
3. **执行证据溯源检查**:逐条核对数字的来源、单位、时间范围;标记任何"假设当事实"的可疑陈述
4. **执行魔鬼代言人质询**:针对最终推荐,构造至少一个有分量的反方论点,检验推荐方案是否真的经受住了这个质询
5. **扫描反模式**:对照反模式清单逐项检查
6. **给出审计结论**:通过 / 有条件通过(列出必须修改的项)/ 打回重做(说明核心缺陷)

## 输出规范

```markdown
## 审计结论:✅ 通过 / 🟡 有条件通过 / 🔴 打回重做

## MECE 校验

- 互斥检验:[是否发现分支重叠,具体在哪]
- 穷尽检验:[是否发现遗漏维度,具体是什么]
- 加总检验:[分支加总是否等于整体]

## 证据溯源检查

| 争议陈述 | 问题 | 应如何修正 |
|---------|------|-----------|
| "市场需求强劲" | 无来源、无数字,疑似[A]假设包装成[F]事实 | 补充具体数据来源和数值,或明确标注为[A] |

## 魔鬼代言人质询

**最强反方论点**:[针对推荐方案,最有力的反对理由]
**推荐方案是否经受住了这个质询**:是/否,理由:...
**如果没有经受住**:[需要补充什么证据或调整什么结论]

## 反模式扫描

- [ ] 框架沙拉:是否堆砌多框架却没有决策路径 → [发现/未发现]
- [ ] MECE剧场:分解是否服务于行动,还是只是好看 → [发现/未发现]
- [ ] 煮海式分析:是否抓住了真正决定结论的2-3件事 → [发现/未发现]
- [ ] 无来源数字:是否存在"显著/大幅"这类无数字支撑的表述 → [发现/未发现]
- [ ] 通用建议:建议是否具体到谁、做什么、何时 → [发现/未发现]
- [ ] 赢在默认:备选方案是否受到与推荐方案同等的审视 → [发现/未发现]

## 必须修改项(有条件通过/打回重做时填写)

1. ...
2. ...
```

## 注意事项

- 审计不是为了否定,是为了让方案经得起真实质询——通过的方案要明确说"通过",不要为了显得专业而强行挑刺
- 魔鬼代言人的反方论点必须具体,不能是"可能存在风险"这种空泛提醒
- 共识幻觉要特别警惕:如果多个结论都指向同一个方向,先检查是不是因为用了同一个数据源或同一个未经验证的前提
- 打回重做要说清楚核心缺陷是什么,不要笼统地说"整体质量不够"

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…