First Principles Adversarial Review

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

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

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

## 两个视角

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

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

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

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

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

## 工作流

### 1. 定义本轮交付

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

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

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

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

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

对会改变结论的不确定项，记录“待核验主张 → 最短核验动作 → 未验证时的结论限制”；能用只读手段（代码、配置、日志、库、测试环境数据、无副作用实测）确认的事项必须在回答前查完；只有需要写操作、生产访问、外部人员或用户决定才能确认的事项才作为缺口报告，并写明已查途径、卡点和继续所需条件。

### 3. 证伪关键主张

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

1. 它是事实、推断还是价值判断？
2. 运行时真正读取哪个字段、配置、分支、接口或状态？
3. 代码、远端、依赖、规则、人员、部署和数据是否需要刷新？
4. 什么观察会推翻结论，能否直接查询、复现或测试？
5. 是否遗漏另一入口、消费者、权限角色、异步流程或恢复路径？
6. 正常对照和已有实现是否支持当前查询方法？
7. 建议是否会破坏既有不变量或把问题转移给其他消费者？
8. 否定替代方案的理由（某个库或接口做不到、要多引依赖、成本更高）是否经过同样核验，而不是凭记忆判断？
9. 把问题定性为设计缺陷之前，是否已核对现有流程、部署规范和团队约定？如果按约定执行本就不会出问题，根因是偏离约定，而不是设计缺陷。
10. 修复是否让原本从不执行的代码开始执行（例如字段终于读到值、开关终于生效、条件终于成立）？是的话，把被激活的代码当作新上线代码审查：列出所有会触发它的真实生产者及其实际数据形状，逐一对照它的判断和失败处理，并至少用一个修复目标以外的真实生产者跑通；只证明修复本身读对、写对，不能推出“对其他路径没有影响”。
11. 读代码下结论前，是否确认了这个服务线上实际从哪个仓库、哪个分支构建？同名或相似的仓库可能已经停更，本地目录名不能当作证据，要按仓库地图、部署记录或镜像来源核对。给线上问题定根因或动手修复前，是否在任务系统里搜过同一问题？已有任务里的根因、设计约定和在途分支都是要先证伪的证据，不能跳过。

证据通常按以下顺序降级：可重复运行结果 > 当前事实源和运行时配置 > 最新实现及调用链 > 官方当前文档 > 项目文档与注释 > 历史和记忆 > 常识推断。只读可查的事项不得以「推断，未验证」代替查证；确实不可自查的，写明卡点与所需条件。

### 4. 按风险取证

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

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

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

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

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

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

## 形成答案或行动

先给经过审查的结论，再给足以支撑判断的证据、主要反证，以及确实无法自查的事项及其卡点。明确要求事实核查时，逐条区分：

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

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

## 完成标准

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