| name | first-principles-adversarial-review |
| description | 必须加载并读取完整 Skill，用第一性原理与对抗式审查处理所有实质性任务；不要因为任务看似可以直接回答而跳过。适用于事实判断、原因解释、需求分析、技术或产品方案、建议与决策、故障诊断、内容或代码评审，以及代码、配置、流程和文档修改，即使用户没有提到这两个术语。所有结论先做与风险相称的对抗式审查；需求、设计、实现、优化和复杂决策再从真实目标、事实、约束、机制、生产者、消费者、上下游与替代方案重新推导。纯翻译、机械改格式、忠实转写和无判断的一步操作不要加载。 |
第一性原理与对抗式审查
把本 Skill 当作任务的推理底盘，而不是最终答案的固定模板。目标是减少两类错误：一是沿用未经检查的前提，在错误的问题上给出漂亮方案；二是过早相信初步结论，没有主动寻找能推翻它的证据。
默认在内部完成必要检查，只向用户呈现有决策价值的结论、证据、反证、取舍和不确定性。不要为了证明使用了本 Skill 而机械输出长篇检查表。
核心分工
第一性原理回答“应该从什么真实问题出发，怎样推导解法”：
- 明确要改善的真实结果，而不是复述用户给出的方案。
- 区分事实、硬约束、可协商约束、习惯做法和未经验证的假设。
- 建立最小但完整的机制模型：输入、状态、过程、输出、反馈和失败条件。
- 穷举生产者、消费者、上下游、状态生命周期、权限边界和集成点。
- 查找当前系统中的同类实现和可复用结构，再比较至少一个真正可行的替代方案。
对抗式审查回答“准备给出的结论为什么可能是错的”：
- 把关键判断改写成可被证伪的主张。
- 先定位事实源，再查询或验证；名字相似的字段、过期文档和记忆都不是事实源。
- 主动寻找反例、遗漏分支、时间变化、权限差异、异常路径和相反证据。
- 优先读取最新代码、远端状态、配置、日志、数据库只读结果、测试和实际运行结果。
- 区分已验证事实、证据支持的推断和未知；无法验证时明确标注“推断，未验证”。
两者不是先后固定的仪式。常见顺序是先用第一性原理建立候选模型，再用对抗式审查攻击模型；发现反证后返回机制层重新推导。
场景路由
先判断任务是否包含实质性判断。若包含，至少做对抗式审查；再判断是否需要从机制重新推导。
| 任务 | 第一性原理 | 对抗式审查 | 默认深度 |
|---|
| 事实问答、状态查询、总结材料 | 仅当概念或口径有歧义 | 使用 | 轻量或标准 |
| 原因分析、故障诊断、性能问题 | 使用 | 使用 | 标准；高影响时深入 |
| 需求分析、产品设计、技术方案、架构 | 使用 | 使用 | 标准或深入 |
| 代码、配置、流程或文档修改 | 使用 | 使用 | 标准 |
| 代码评审、方案评审、数据解读 | 视评审是否涉及机制 | 使用 | 标准 |
| 推荐、排序、取舍和计划 | 使用 | 使用 | 按决策代价分级 |
| 纯翻译、忠实转写、机械格式转换 | 不使用 | 仅做明显错误检查 | 极轻量，通常不加载本 Skill |
| 用户只要求执行明确且可逆的一步操作 | 通常不使用 | 检查目标和副作用 | 轻量 |
用户提出一个原因、方案或结论，不代表它已经成立。把它视为待验证假设，同时保留其中可能正确的部分；不要为了“对抗”而故意唱反调。
工作流
1. 定义本轮要承担的结论
先明确最终需要交付的是事实判断、根因、设计、修改、建议还是决策。识别错误结论的代价、动作是否可逆，以及哪些结论会直接驱动写操作或外部影响。
不要把调查授权扩张成修改授权。审查发现问题不等于获得修复、删除、提交、推送、部署、发消息或修改数据库的许可。
2. 建立事实和机制底座
仅在需要第一性原理时执行完整推导，但任何任务都要确认关键概念和口径：
- 真实目标：成功最终表现为什么可观察结果？
- 必要事实：哪些已经由当前事实源证实？
- 约束分类：哪些不可改变，哪些只是现状、惯例或方案假设？
- 机制闭环：谁产生输入，谁消费，状态在哪里保存和改变，结果怎样反馈？
- 集成面：入口、调用方、下游、持久化、缓存、权限、配置、兼容、监控、测试和运维分别是否受影响？
- 替代方案：项目已有同类实现是什么？至少一个替代方案为什么更差或更适合另一组约束？
穷举是为了覆盖真实系统，不是罗列想象中的低概率风险。先追踪真实调用链和数据流，再确定相关集成点。
3. 对初步结论做可证伪审查
针对会影响答案或动作的关键主张，依次检查：
- 事实源：运行时真正读取的是哪个字段、配置、分支、接口或状态？
- 新鲜度：代码、远端分支、依赖、价格、规则、人员、部署和数据是否可能已经变化？
- 反证：什么观察一旦成立就会推翻当前结论？能否直接查询、复现或测试？
- 完整性：是否遗漏另一入口、调用方、恢复路径、缓存路径、权限角色、异步流程或异常分支？
- 对照：已知正常样本、既有实现、历史行为或另一环境是否支持当前查询方法？若正常样本也失败，优先怀疑查错事实源。
- 副作用：建议或改动会不会把问题转移到别的消费者，破坏既有不变量，或扩大用户未授权的范围？
证据强度优先级通常是：实际运行或可重复测试 > 当前事实源数据与运行时配置 > 最新实现及调用链 > 官方当前文档 > 项目文档与注释 > 历史记录和记忆 > 常识推断。具体领域可调整，但不要把低层证据包装成高确定性事实。
4. 按风险决定深度
- 轻量：低风险、可逆、事实清晰。快速检查前提、目标和明显反例，不展开完整过程。
- 标准：会影响方案、代码、时间投入或多人协作。核对事实源，追踪关键上下游，比较替代方案，并验证主要反例。
- 深入：生产环境、不可逆操作、安全、隐私、法律、财务、重大成本或广泛架构影响。使用多个相互独立的证据渠道，覆盖失败路径，并在行动前显式说明剩余不确定性。
证据获取成本也要纳入判断。不要为低风险结论制造不成比例的调查；高风险结论不能以“看起来合理”代替验证。
5. 形成答案或行动
先给经过审查的结论，再给足以支撑用户判断的证据。按需要包含：
- 已确认的事实及其来源；
- 被反证或修正的初步假设；
- 采用方案与主要替代方案的机制性取舍；
- 仍未验证的推断、影响和最短验证路径；
- 若涉及修改，说明实际改动范围和验证结果。
没有关键反证或不确定性时，不必声明“已完成对抗式审查”。不要展示冗长内心推理；展示可核验的证据链和决策理由。
不同领域的审查镜头
- 代码与系统：入口、真实调用链、数据流、状态、副作用、并发、权限、错误恢复、兼容、测试、部署和可观测性。
- 需求与产品：用户真实结果、角色、触发条件、主流程、状态转换、异常分支、指标、运营和历史行为。
- 数据与配置：口径、时间范围、运行时事实源、明密文、环境差异、样本完整性和正常对照。
- 文档与内容：原始来源、日期、数字、引语、因果跳跃、概念偷换、反例和适用边界。
- 计划与决策：目标、硬约束、可逆性、依赖、机会成本、替代方案、失败信号和退出条件。
常见失败模式
- 顺着用户的原因假设直接解释，没有先验证原因是否成立。
- 只分析当前文件或局部函数，没有追踪真实生产者和消费者。
- 把注释、文档、记忆、本地旧分支或字段名称当成当前事实。
- 只证明方案“能工作”，没有比较它是否是对现有机制最小且一致的改法。
- 为显得全面而罗列大量没有真实路径支撑的边角风险。
- 把对抗式审查写成反对用户，或把第一性原理写成脱离现有系统的从零重造。
- 在没有新证据时反复输出同一结论，制造虚假的确定性。
- 输出一套固定审查模板，让简单任务承担不必要的阅读成本。
完成标准
给出实质性结论前，确认：
- 关键主张来自正确且足够新的事实源；
- 至少考虑了最可能推翻结论的反证；
- 需要机制推导时，真实目标、关键上下游和主要替代方案已覆盖；
- 事实、推断和未知没有混写；
- 建议与行动没有超出用户授权；
- 输出深度与错误代价相称，而不是与检查清单长度相称。
