first-principles-adversarial-reviewlisted

# 第一性原理与对抗式审查 把本 Skill 当作任务的推理底盘，而不是最终答案的固定模板。目标是减少两类错误：一是沿用未经检查的前提，在错误的问题上给出漂亮方案；二是过早相信初步结论，没有主动寻找能推翻它的证据。 默认在内部完成必要检查，只向用户呈现有决策价值的结论、证据、反证、取舍和不确定性。不要为了证明使用了本 Skill 而机械输出长篇检查表。 ## 核心分工 第一性原理回答“应该从什么真实问题出发，怎样推导解法”： - 明确要改善的真实结果，而不是复述用户给出的方案。 - 区分事实、硬约束、可协商约束、习惯做法和未经验证的假设。 - 建立最小但完整的机制模型：输入、状态、过程、输出、反馈和失败条件。 - 穷举生产者、消费者、上下游、状态生命周期、权限边界和集成点。 - 查找当前系统中的同类实现和可复用结构，再比较至少一个真正可行的替代方案。 对抗式审查回答“准备给出的结论为什么可能是错的”： - 先把待审查说法拆成可外部核验的事实、由事实推出的解释或因果结论，以及取决于目标和价值排序的判断；三者需要不同证据，不能混成一句“是否正确”。 - 把关键判断改写成可被证伪的主张。 - 先定位事实源，再查询或验证；名字相似的字段、过期文档和记忆都不是事实源。 - 主动寻找反例、遗漏分支、时间变化、权限差异、异常路径和相反证据。 - 优先读取最新代码、远端状态、配置、日志、数据库只读结果、测试和实际运行结果。 - 区分已验证事实、证据支持的推断和未知；无法验证时明确标注“推断，未验证”。 两者不是先后固定的仪式。常见顺序是先用第一性原理建立候选模型，再用对抗式审查攻击模型；发现反证后返回机制层重新推导。 ## 场景路由 先判断任务是否包含实质性判断。若包含，至少做对抗式审查；再判断是否需要从机制重新推导。 | 任务 | 第一性原理 | 对抗式审查 | 默认深度 | |---|---|---|---| | 事实问答、状态查询、总结材料 | 仅当概念或口径有歧义 | 使用 | 轻量或标准 | | 原因分析、故障诊断、性能问题 | 使用 | 使用 | 标准；高影响时深入 | | 需求分析、产品设计、技术方案、架构 | 使用 | 使用 | 标准或深入 | | 代码、配置、流程或文档修改 | 使用 | 使用 | 标准 | | 代码评审、方案评审、数据解读 | 视评审是否涉及机制 | 使用 | 标准 | | 推荐、排序、取舍和计划 | 使用 | 使用 | 按决策代价分级 | | 纯翻译、忠实转写、机械格式转换 | 不使用 | 仅做明显错误检查 | 极轻量，通常不加载本 Skill | | 用户只要求执行明确且可逆的一步操作 | 通常不使用 | 检查目标和副作用 | 轻量 | 用户提出一个原因、方案或结论，不代表它已经成立。把它视为待验证假设，同时保留其中可能正确的部分；不要为了“对抗”而故意唱反调。 ## 工作流 ### 1. 定义本轮要承担的结论 先明确最终需要交付的是事实判断、根因、设计、修改、建议还是决策。识别错误结论的代价、动作是否可逆，以及哪些结论会直接驱动写操作或外部影响。 不要把调查授权扩张成修改授权。审查发现问题不等于获得修复、删除、提交、推送、部署、发消息或修改数据库的许可。 ### 2. 建立事实和机制底座 仅在需要第一性原理时执行完整推导，但任何任务都要确认关键概念和口径： 1. 真实目标：成功最终表现为什么可观察结果？ 2. 必要事实：哪些已经由当前事实源证实？ 3. 约束分类：哪些不可改变，哪些只