challenge

# 红蓝对抗（Red-Blue Adversarial） 对方案进行结构化的多轮攻防审查，通过蓝军（攻击方）挑战假设和红军（防御方）用数据回应的交替迭代，暴露盲点、消除过度工程、收敛到最小可行方案。 ## 参数 - `/challenge` — 对当前对话上下文中的方案发起对抗 - `/challenge [方案描述或文件路径]` — 对指定方案发起对抗 - `/challenge --light` — 轻量模式，快速压力测试 - `/challenge --deep` — 深度模式，含隐性假设专项攻击和前瞻分析 ## 输入 对抗目标：$ARGUMENTS 如果 $ARGUMENTS 为空，从当前对话上下文中识别最近讨论的方案/设计/决策作为对抗目标。如果上下文中也没有，使用 AskUserQuestion 询问用户要对什么进行对抗。 ## 核心原则 1. **蓝军必须提"最小实验"**：每条批评必须附带一个可在 10 分钟内执行的验证动作，空谈无效 2. **红军必须"用数据回应"**：引用实际数据（grep 结果、API 响应、日志条目、配置文件内容），禁止纯理论反驳。数据有可信度层级（见证据分级），致命/严重问题的回应必须用高可信度证据 3. **对抗是双向的**：红军不是来认错的，而是用证据守住合理设计。轻易全盘投降和顽固不化一样有害——如果方案的某个决策有充分理由，红军有义务据理力争。好的对抗让方案的合理部分更坚固，不合理部分被替换 4. **对抗目标是收敛**：每轮对抗应减少方案的复杂度或不确定性，不是增加 5. **采纳有成本**：每次"采纳"意味着修改方案，修改本身引入复杂度和风险。红军在采纳时必须评估修改成本，避免"攻击什么就改什么"的条件反射 ## 证据可信度分级 对抗中引用的"数据"并非同等可靠。按可信度从高到低： | 层级 | 证据类型 | 示例 | |------|---------|------| | **L1 实验** | 实际运行的实验结果 | 写脚本测量延迟、部署测试环境验证 | | **L2 探测** | API/curl/命令行实时测试 | `curl -I https://...`、`netstat -ano` | | **L3 检索** | 读取当前代码/配置/日志 | `grep`、`cat`、读文件内容 | | **L4 引用** | 文档、记忆、历史记录 | MEMORY.md 记录、官方文档 | | **L5 推理** | 逻辑推断（无直接证据） | "根据 X 原理，Y 应该成立" | **硬性要求**： - 蓝军标记为"致命"的攻击，最小实验执行后必须产出 L1-L3 级证据 - 红军驳回"致命/严重"攻击时，数据支撑必须达到 L1-L3 级 - L5 推理不能单独作为驳回依据，必须搭配更高层级证据 ## 对抗流程 ### Phase 0：锚定对抗目标 1. 明确对抗对象：方案文档、架构设计、技术选型、故障假设等 2. 用 1-3 句话概括方案的核心主张 3. 识别方案依赖的**显性假设**（通常 3-5 个） 4. **挖掘隐性假设**：列出方案中没有明确说出但必须为真的前提条件——这些是最危险的，因为从未被质疑过。重点关注： - 运行环境假设（OS、网络、权限、依赖服务可用性） - 规模假设（数据量、并发量、增长速率） - 用户行为假设（使用方式、操作顺序、容错预期） - 时间假设（执行频率、延迟容忍、生命周期） 5. **评估对抗深度**（如果用户未通过 `--light` / `--deep` 指定）： | 模式 | 适用场景 | 流程 | 预期规模 | |------|---------|------|---------| | **轻量** | 局部决策、2-3 个假设、影响范围小 | Phase 0 → 单轮精简攻防 → 结论 | 3-4 个攻击点 | | **标准** | 功能设计、技术选型、中等复杂度 | 完整 Phase 0-4 | 5-7 个攻击点 | | **深度** | 架构设计、高风险决策、生产环境变更 | 完整流程 + 隐性假设专项攻击 + 前瞻分析 | 7+ 个攻击点 | 不确定时默认标准模式。 输出格式： ``` ## 对抗目标 **方案**：[方案名称/概述] **核心主张**：[1-3 句话] **显性假设**： 1. [假设 1] 2. [假设 2] 3. [假设 3] **隐性假设**（未被明确说出但必须成立）： - [隐性假设 1]：风险等级 [高/中/低] - [隐性假设 2]：风险等级 [高/中/低] **对抗模式**：[轻量/标准/深度]，理由：[为什么选这个级别] ``` ### Phase 1：蓝军攻击 蓝军的目标不是"找茬"，而是帮方案找到自己看不见的风险。好的蓝军攻击让方案制定者感到"幸好在实施前发现了这个"。 **必做：先钢铁人（Steelman）再攻击** 每轮攻击开始前，蓝军必须用 2-3 句话展示对方案优势的真正理解——这不是客套。如果蓝军不理解方案为什么这样设计，攻击容易打偏。钢铁人描述应包含：方案试图解决的核心问题、当前设计的合理性来源、相比显而易见的替代方案的独特优势。 **蓝军攻击技巧（按优先级）**： 1. **"没确诊就开药"**：方案是否基于未验证的假设？是否先设计了方案再找问题？ → 要求：提出验证假设的最小实验 2. **过度工程化检测**：最简方案试过了吗？能用 3 行代码解决的问题是否用了 3 层抽象？ → 要求：给出更简单的替代方案 3. **逻辑悖论识别**：方案是否自相矛盾？如"用规则解决忘记规则的问题" → 要求：指出具体的逻辑环 4. **房间里的大象**：是否忽略了已有的现成方案/工具/框架？ → 要求：列出被忽视的已有方案 5. **成本盲区**：隐含的运维成本、token 消耗、注意力代价、技术债是否被低估？ → 要求：给出粗略的成本估算 6. **钢铁人攻击（Steelmanning Attack）**：在理解方案优势的基础上，指出在某个特定条件下优势不成立 → 要求：明确指出使优势失效的具体条件 7. **反转测试**：把方案的核心决策反转（如从微服务改为单体），结果会更差吗？ → 要求：给出反转后的具体对比 8. **前瞻性失败**（深度模式）：假设方案已上线 6 个月，它最可能因为什么原因失败？ → 要求：给出具体的失败场景和触发条件 **严重度定义**（严格校准）： | 严重度 | 定义 | 判断标准 | 每轮上限 | |--------|------|---------|---------| | **致命** | 方案上线后会导致**不可逆损失**或**完全无法工作** | 数据丢失、安全漏洞、核心功能失效 | 最多 2 个 | | **严重** | 方案能工作但会产生**显著的持续性问题** | 性能瓶颈、维护负担、成本超预期 | 不限 | | **中等** | 方案可以工作但有改进空间 | 代码冗余、缺少监控、扩展性不足 | 不限 | 致命上限的意义：如果超过 2 个问题都符合致命定义，说明方案需要从头审视而非逐条修补——此时蓝军应直接建议用户重新评估方案可行性，而不是继续攻击细节。 **输出格式**： ``` ## 蓝军攻击 Round N **钢铁人理解**：[2-3 句话展示对方案优势的理解] | # | 严重度 | 攻击类型 | 问题 | 最小实验（<10min） | |---|--------|----------|------|-------------------| | B1 | 致命 | [类型] | [问题描述] | [验证动作] | | B2 | 严重 | [类型] | [问题描述] | [验证动作] | | B3 | 中等 | [类型] | [问题描述] | [验证动作] | ``` 蓝军攻击完成后，**立即执行**所有标记为"致命"和"严重"的最小实验，将实验结果（含证据层级标注）记录在攻击表下方。这些实验结果将作为红军回应的证据基础。 ### Phase 2：红军回应 红军的使命是双重的：修正方案中真正有问题的部分，同时守住合理的设计决策。好的红军回应让方案变得更好，而不是被蓝军牵着鼻子走。 **红军的平衡约束**： 红军不应全盘接受蓝军攻击。当蓝军提出 5 个以上攻击时，如果红军全部采纳，往往说明红军没有认真评估每个攻击的真实成本。对于 5+ 个攻击，红军必须对至少 30% 做出实质性抗辩（驳回、或部分采纳中附带对不合理部分的反驳），除非每个攻击都附带了 L1-L3 级铁证且修改成本可忽略。 "实质性抗辩"不是简单说"不同意"——是提供反面证据，或证明蓝军攻击的前提不成立，或证明修改成本大于风险。 **红军回应模式**： | 类型 | 含义 | 要求 | |------|------|------| | **采纳** | 攻击有效，修改方案 | 给出具体修改 **+ 修改成本**（新增复杂度、影响范围、额外工作量） | | **部分采纳** | 攻击方向对但结论过头 | 说明接受/拒绝各部分，拒绝理由附 L1-L3 数据 | | **驳回** | 攻击无效或修改成本不合理 | 给出驳回理由 + L1-L3 级数据支撑 | | **降级** | 攻击有效但当前阶段不处理 | 说明何时处理、临时缓解措施、降级的风险敞口 | | **超出范围** | 超出当前评审范围 | 说明归属范围，是否需要单独跟踪 | **回应技巧**： 1. **认同 + 修正**：认可批评方向，但修正具体推论或解决方案 2. **降级而非放弃**：将"立即引入"降级为"Phase 2 观察"，而非完全移除 3. **用数据反转**：用 grep/curl/实验的实际结果推翻蓝军的假设 4. **区分"方向对"和"结论过头"**：承认问题存在但质疑蓝军建议的解决方案 5. **约束声明**：明确方案的适用边界，"这个方案不处理 X 场景，因为..." 6. **成本对比**：攻击指出的风险确实存在，但缓解成本 > 风险期望损失 7. **检验攻击前提**：蓝军的攻击是否基于正确的前提？前提本身是否需要验证？ **输出格式**： ``` ## 红军回应 Round N **防守立场**：[1-2 句话——哪些设计决策值得坚守，为什么] | # | 蓝军编号 | 回应类型 | 回应内容 | 数据支撑 [证据层级] | |---|---------|---------|---------|-------------------| | R1 | B1 | 采纳 | [回应] **修改成本**：[评估] | [数据] [L3] | | R2 | B2 | 驳回 | [回应] | [数据] [L2] | | R3 | B3 | 部分采纳 | [接受部分] / [拒绝部分及理由] | [数据] [L1] | ### 方案修正 Diff **变更 1**：[原设计] → [修正后设计] 理由：采纳 B1，[具体原因] 修改成本：[引入的新复杂度/工作量] **坚守的设计决策**： 1. [决策 1]：驳回 B2，理由 [摘要] 2. [决策 2]：未被攻击，仍然合理因为 [摘要] ``` ### Phase 3：蓝军第二轮攻击（收敛轮） 针对红军修正后的方案，进行第二轮审查。此轮重点关注： 1. **修正是否引入新问题**：改 A 是否破坏了 B？ 2. **降级处理是否合理**：被降级的项目是否真的可以推迟？ 3. **整体一致性**：修正后的方案各部分是否仍然自洽？ 4. **驳回质量审查**：红军的驳回证据是否足够？如果驳回仅靠 L4-L5 证据，重新挑战 此轮只关注"致命"和"严重"问题，中等及以下问题不再提出。 ### Phase 4：红军第二轮回应（终结轮） 回应蓝军第二轮攻击，产出最终方案。 ## 收敛判断 满足以下**任一**条件即可结束对抗： 1. **蓝军无致命/严重问题**：第二轮蓝军攻击未发现致命或严重问题 2. **红蓝共识**：双方对所有致命/严重问题的处理达成一致 3. **最大轮次**：已完成 3 轮完整对抗（极少需要第 3 轮） 如果 2 轮后仍有致命问题未解决，使用 AskUserQuestion 询问用户： - 继续第 3 轮对抗 - 将未解决问题标记为已知风险，接受当前方案 - 暂停对抗，先执行实验收集更多数据 ## 最终输出 对抗收敛后，输出结构化的攻防报告： ``` ## 红蓝对抗报告 ### 对抗目标 [方案名称/概述] ### 对抗强度 [轻量/标准/深度] | [N] 轮 | 蓝军 [M] 个攻击 | 红军驳回率 [X%] ### 攻防摘要 - **蓝军提出问题**：[M] 个（致命 X / 严重 Y / 中等 Z） - **采纳**：[A] 个 | **部分采纳**：[B] 个 | **驳回**：[C] 个 | **降级**：[D] 个 - **方案修改总成本**：[总体评估——修改引入的复杂度是否可控] ### 关键变更 1. [变更 1]：[原方案] → [修正方案]（来源：B[n]） 2. [变更 2]：[原方案] → [修正方案]（来源：B[n]） ### 坚守的设计决策 1. [决策 1]：经受了 B[n] 攻击，驳回理由 [摘要] 2. [决策 2]：经受了 B[n] 攻击，驳回理由 [摘要] ### 已知风险与降级项 1. [风险 1]：降级计划 / 风险敞口 / 触发条件 2. [风险 2]：驳回理由 / 残余风险 ### 隐性假设状态 - 已验证：[列表] - 未验证但风险可接受：[列表] - 需要持续监控：[列表及监控方式] ### 收敛后方案 [最终方案的完整描述，已整合所有采纳的变更] ### 下一步行动 1. **立即执行**：[最高优先级的具体动作，精确到命令或操作步骤] 2. **本周完成**：[短期跟进项] 3. **持续监控**：[降级项的观察指标和触发阈值] ``` ## 轻量模式输出格式 轻量模式跳过多轮迭代，用更紧凑的格式快速产出： ``` ## 快速对抗：[方案名称] **钢铁人理解**：[方案的核心优势] **隐性假设**：[1-2 个最高风险的未验证前提] ### 压力测试 | # | 风险点 | 验证结果 | 建议 | |---|--------|---------|------| | 1 | [问题] | [实验结果 + 证据层级] | [采纳/驳回 + 理由] | | 2 | [问题] | [实验结果 + 证据层级] | [采纳/驳回 + 理由] | ### 结论 [方案是否可行] + [最大的单点风险] + [建议的下一步] ``` ## 使用场景适配 ### 架构设计评审 - 蓝军重点：过度工程化、未验证假设、忽略已有方案 - 红军重点：用代码实验和 grep 结果回应 - 默认深度模式 ### 方案选型决策 - 蓝军重点：对每个候选方案分别攻击，暴露各自弱点 - 红军重点：用对比数据（benchmark、成本、复杂度）回应 - 特殊规则：不偏袒任何方案，最终推荐基于攻防后的综合评分 - 默认标准模式 ### 故障根因分析 - 蓝军重点：挑战"确认偏误"——当前假设的根因是否有其他解释？ - 红军重点：用日志、监控数据、复现实验回应 - 特殊规则：蓝军必须提出至少 2 个替代假设 - 默认标准模式 ### 快速决策压力测试 - 蓝军重点：最大的单点风险是什么？ - 红军重点：用已有数据快速验证 - 默认轻量模式 ## 注意事项 - **对抗是工具，不是目标**：如果方案本身足够简单且经过验证，不需要强行对抗。快速判断后告知用户"此方案无需对抗"也是有效输出 - **避免对抗膨胀**：蓝军每轮最多提 7 个问题，超出时按严重度裁剪 - **实验优于辩论**：能用 10 分钟实验解决的分歧，不用 3 轮辩论 - **用户是最终裁判**：当红蓝双方僵持时，使用 AskUserQuestion 呈现双方论据让用户裁决 - **警惕全盘采纳**：如果红军对所有攻击都说"采纳"，暂停反思——是方案真的全盘有问题（则建议用户重新评估），还是红军偷懒没做防守（则重新执行红军回应）