# First Principles Adversarial Review

> 需求设计、根因诊断、复杂实现或关键事实争议需要机制推导与反证时使用；简单查询、忠实摘要和不改变行为的局部修订不加载。

- Skill: `zhangs-11/first-principles-adversarial-review` (Agent Skill, multi-file: 8 files)
- Install (CLI): `npx skillmds@latest add zhangs-11/first-principles-adversarial-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zhangs-11/first-principles-adversarial-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Zhangs-11 (https://skillmd.com/u/zhangs-11)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/zhangs-11/first-principles-adversarial-review

---


# 第一性原理与对抗式审查

把本 Skill 当作推理和交付门禁，不作为固定回答模板。目标是避免沿用错误前提、过早相信初步结论，以及为未来可能性堆叠当前并不需要的设计。

## 两个视角

**第一性原理**从真实结果重新推导解法：区分事实、硬约束、可协商约束、惯例和假设；建立输入、状态、过程、输出、反馈和失败条件的最小闭环；追踪真实生产者、消费者、上下游、权限和集成点；再与项目已有同类实现及至少一个不推翻有效硬约束的替代方案比较。

**对抗式审查**假设初步结论可能是错的：把主张拆成可核验事实、由事实推出的解释或因果推断，以及取决于目标的价值判断；定位真正的事实源，主动寻找反例、遗漏路径、环境差异、异常恢复和相反证据。

对抗的目标是寻找最强反证，不是为了反对而制造分歧。

参考他人或其他 Agent 的结论前，先基于原始事实形成初步判断；以证据而非一致票数裁决分歧，已有结论无法避开时，明确其可能造成的锚定影响。

两者可以往返：先建立候选机制，再用反证攻击；发现反证后返回机制层重推，而不是替旧结论打补丁。

## 工作流

### 1. 定义本轮交付

明确要交付的是事实判断、根因、设计、修改、建议还是决策，并判断错误代价和动作可逆性。调查和评审不授权修改；发现问题也不自动授权删除、提交、推送、部署、外部通知或数据库写入。

### 2. 建立事实与机制

先定位会改变结论的事实源。涉及原因、需求、设计、实现、优化或复杂决策时，再追踪：

- 成功最终表现为什么可观察结果？
- 哪些事实已由当前事实源证实，哪些仍是假设？
- 谁产生和消费输入，状态在哪里变化，结果如何反馈？
- 入口、调用方、下游、持久化、缓存、权限、配置、兼容、监控、测试和运维中哪些确实受影响？
- 项目已有同类实现和最小替代方案分别是什么？

穷举真实链路，不罗列没有路径支撑的低概率风险。

对会改变结论的不确定项，记录“待核验主张 → 最短核验动作 → 未验证时的结论限制”；能自查的先查，只向用户报告剩余关键缺口。

### 3. 证伪关键主张

对会驱动答案或动作的主张检查：

1. 它是事实、推断还是价值判断？
2. 运行时真正读取哪个字段、配置、分支、接口或状态？
3. 代码、远端、依赖、规则、人员、部署和数据是否需要刷新？
4. 什么观察会推翻结论，能否直接查询、复现或测试？
5. 是否遗漏另一入口、消费者、权限角色、异步流程或恢复路径？
6. 正常对照和已有实现是否支持当前查询方法？
7. 建议是否会破坏既有不变量或把问题转移给其他消费者？

证据通常按以下顺序降级：可重复运行结果 > 当前事实源和运行时配置 > 最新实现及调用链 > 官方当前文档 > 项目文档与注释 > 历史和记忆 > 常识推断。无法验证时标注“推断，未验证”。

### 4. 按风险取证

- **轻量**：低风险且可逆，检查前提、事实源和最可能的反例。
- **标准**：影响方案、代码、时间或协作，追踪关键上下游、比较替代方案并验证主要反例。
- **深入**：生产、不可逆、安全、隐私、法律、财务或重大成本，使用独立证据覆盖失败路径，并在行动前说明剩余不确定性。

证据成本应与错误代价相称；低风险任务不做仪式化调查，高风险结论不以“看起来合理”代替验证。

## 设计与实现的消融门禁

每次完成设计或实现后、交付前，对**本次新增内容**自动做一次消融实验：

1. 在内部列出新增的抽象层、接口、wrapper、helper、配置、扩展点、状态、兜底和分支，以及各自声称解决的问题。
2. 每次移除或合并一项，形成更简单的候选；不要一次删多项，否则无法判断是哪一项产生影响。
3. 设计任务用代表性 Case 重走目标、约束、生产者、消费者、状态和失败路径；实现任务比较公开行为、契约、相关测试和真实调用链，必要时再比较性能或复杂度指标。
4. 按奥卡姆剃刀选择：同样满足必需行为和保护性约束时，采用未经验证的假设更少、机制更简单的候选，而非单纯代码更短的方案；只有能指出当前需求、契约、测试或实测收益的抽象才保留。

没有新增抽象时，确认无可消融项即可，不为完成流程制造候选。消融不是顺手重构：默认只处理本批新增或改动中的设计，不能借此删除既有函数、文件、注释或改变既有接口、数据和用户行为。涉及这些对象时，先列明目标和理由并取得授权。无法安全构造或验证候选时，保留基线并明确“必要性未验证”，不把猜测包装成简化结论。

## 形成答案或行动

先给经过审查的结论，再给足以支撑判断的证据、主要反证和仍未验证项。明确要求事实核查时，逐条区分：

- **事实**：已证实、基本成立但需收窄、存在争议、证据不足或明显错误。
- **解释或因果推断**：链路成立、部分成立或不成立，并指出缺口。
- **价值判断**：说明服务的目标、受益者、代价和结论反转条件。

实现任务说明实际范围和验证结果；消融改变方案或留下关键未知时再报告其结果。内部检查不作为固定汇报项。

## 完成标准

按任务风险完成上述适用步骤后交付：结论有证据，关键未知有边界，保留的设计有必要性依据，行动未超出授权。