first-principles-adversarial-review

第一性原理与对抗式审查

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

两个视角

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

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

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

参考他人或其他 Agent 的结论前，先基于原始事实形成初步判断；以证据而非一致票数裁决分歧，已有结论无法避开时，明确其可能造成的锚定影响。把子任务或其他 Agent 核对出的改正说法写进交付物前，凡是状态值、原因码、是否计入统计，以及早于/晚于这类方向词，都要逐条回到对应的代码行或事实源再看一遍。

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

工作流

1. 定义本轮交付

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

2. 建立事实与机制

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

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

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

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

3. 证伪关键主张

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

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

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

4. 按风险取证

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

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

设计与实现的消融门禁