sdd-full 5.2.1 → 5.2.3

package/.claude/skills/multi-expert-discussion/references/red-team.md

@@ -0,0 +1,279 @@
+# 红队攻击协议
+
+## 红队攻击者角色定义
+
+### 角色定位
+
+红队攻击者（Red Team Attacker）是一个独立于魔鬼代言人的对抗性审查角色，其核心职责是对专家组已产出的初步方案进行系统性的攻击测试，而非参与讨论过程本身。
+
+### 与魔鬼代言人的关键区别
+
+| 维度 | 魔鬼代言人 | 红队攻击者 |
+|------|-----------|-----------|
+| 介入时机 | 讨论进行中（过程内） | 方案产出后（事后） |
+| 作用性质 | 预防性——在讨论中防止回音室效应 | 攻击性——对已产出方案进行破坏性测试 |
+| 触发条件 | 共识度过高、回音室检测、死锁熔断 | 灰度导航类问题产出初步方案后自动触发，或用户显式指令 |
+| 输出目标 | 打破当前轮次的高共识，引入反方论证 | 暴露方案的系统性缺陷、边界崩溃点和未覆盖场景 |
+| 参与方式 | 由现有专家临时担任，仍参与讨论 | 完全独立的外部攻击角色，不参与方案构建 |
+| 作用域 | 单轮或多轮讨论的局部议题 | 方案全局，覆盖所有已产出的结论和共识 |
+| 解除条件 | 任期结束 / 回音室风险解除 | 至少3轮攻击完成 / 用户确认终止 |
+
+### 职责范围
+
+- 不接受专家组的"合理范围"预设，不认可"假设一切正常"的前提
+- 以"方案已经失败"为起点，倒推失败路径和关键断裂点
+- 每轮攻击覆盖不同攻击维度的组合，确保全面覆盖
+- 攻击结论附带严重度评级，区分致命缺陷与可容忍风险
+- 最终输出残余风险清单，标注专家组未能充分回应的攻击点
+
+## 六大攻击维度
+
+### 1. 假设挑战（Assumption Challenge）
+
+**定义**：系统性地质疑方案所依赖的核心假设是否成立。不承认任何"不言自明"的前提，所有假设均需经受压力测试。
+
+**攻击策略**：
+- 逐条列出方案依赖的显性和隐性假设
+- 对每条假设进行反向论证："如果这条假设不成立，方案会怎样？"
+- 检查假设之间的依赖链——是否有假设依赖于另一条未经验证的假设
+
+**示例**：
+> 方案假设"用户有稳定的网络连接"。攻击：如果用户在偏远地区、地下室、或网络管制环境中，该方案是否仍然有效？离线降级策略是什么？数据同步冲突如何处理？
+
+### 2. 边界压力（Boundary Stress）
+
+**定义**：将方案推至极端条件，测试其在不理想甚至恶劣环境下的表现。不满足于"正常情况可行"，必须找到方案的断裂边界。
+
+**攻击策略**：
+- 参数极值测试：将方案中的关键变量推向最小值和最大值
+- 并发/容量极限：将负载推向设计上限的10倍以上
+- 退化条件：模拟关键组件逐一失效的级联场景
+- 时间极端：极短时间窗口、极端延迟、超长时间运行
+
+**示例**：
+> 方案设计了消息队列处理峰值1000 TPS。攻击：当突发流量达到10000 TPS并持续30分钟时，队列积压策略是什么？是否会触发连锁超时导致整个系统不可用？
+
+### 3. 替代解释（Alternative Explanation）
+
+**定义**：用不同的理论框架、分析视角或认知模型重新解读同一现象，暴露方案可能存在的认知盲区。一个现象可能有多种解释，方案选择其中一种不代表其他解释不成立。
+
+**攻击策略**：
+- 切换分析框架：用不同的学科或理论重新审视问题
+- 角色代入：从不同利益相关者的视角重新理解问题
+- 因果逆转：检查是否存在反向因果关系
+- 第三变量：是否存在未被考虑的混淆变量
+
+**示例**：
+> 方案认为"用户留存率下降是因为功能不够丰富"，因此建议增加新功能。攻击：用行为经济学视角重新审视——用户留存下降是否因为选择过载（choice overload）？增加功能是否反而会加剧问题？
+
+### 4. 最坏情况（Worst Case）
+
+**定义**：以方案完全失败为终局，系统推演从当前状态到该终局的所有可能路径。不讨论概率，只讨论一旦发生则后果不可接受的场景。
+
+**攻击策略**：
+- 构建失败树：从终局反推，找出所有可能导致该终局的事件链
+- 单点故障分析：方案中是否存在单一故障点，一旦失效则全局崩溃
+- 级联效应：一个组件的失败如何传播并放大
+- 不可逆后果：方案失败后是否会造成不可逆的损害
+
+**示例**：
+> 方案建议将旧的单体数据库中的数据逐步迁移到新的微服务数据库。最坏情况推演：迁移脚本存在边界bug，导致30%的用户数据被静默损坏，且该bug在迁移完成2周后才被发现，此时旧数据库已被清理。不可逆后果：永久性用户数据丢失，无回滚路径。
+
+### 5. 逆向思维（Reverse Thinking）
+
+**定义**：从方案的目标终点出发，反向验证到达该终点的每条路径是否必然可行。不满足于"从起点到终点好像能走通"，要求每条路径都经得起反向推演。
+
+**攻击策略**：
+- 终态分解：将方案目标分解为若干必经中间状态
+- 必要条件分析：到达每个中间状态必须具备什么条件
+- 缺失环节检测：是否存在"跳跃式"推理，即缺乏对关键转换步骤的说明
+- 阻塞点识别：路径中是否存在一旦阻塞则无法绕行的节点
+
+**示例**：
+> 方案目标是"6个月内将系统可用性从99.9%提升到99.99%"。逆向：要达到99.99%，必须具备自动故障转移（< 1分钟）、无单点故障、蓝绿部署能力。检查当前方案是否明确说明了如何获得这些能力，以及每条路径的时间可行性。
+
+### 6. 历史类比失败（Historical Analogy Failure）
+
+**定义**：寻找历史上或公开案例中与当前方案结构相似的失败案例，分析其失败原因并检查当前方案是否复现了同样的脆弱模式。
+
+**攻击策略**：
+- 模式匹配：识别当前方案中的架构模式、组织模式或决策模式
+- 失败库检索：检索每种模式在历史上的典型失败案例
+- 模式复现检测：检查当前方案是否重现了已知的失败模式
+- 避免措施验证：如果方案声称避免了历史失败，验证该避免措施是否充分
+
+**示例**：
+> 方案采用"大爆炸式"重写策略，计划用新系统一次性替换运行6年的遗留系统。历史类比：Netscape用3年重写浏览器，期间市场份额从90%跌至不足5%。攻击：当前方案的重写策略与Netscape的模式高度相似——长期脱离用户需求迭代、测试覆盖不足、新旧系统切换无灰度方案。该方案是否实质上忽略了这一历史教训？
+
+## 红队攻击流程
+
+### 触发条件
+
+红队攻击在以下任一条件满足时触发：
+
+**条件A：自动触发（灰度导航类问题）**
+
+当问题被路由判定系统识别为灰度导航类问题——即同时满足以下至少两项特征的问题——在专家组完成阶段3（深度研讨）并产出初步方案后，自动触发红队攻击：
+
+- **价值冲突**：方案涉及不同利益相关者的价值取舍（如安全 vs 便利、性能 vs 成本）
+- **信息不完备**：关键数据缺失或无法验证，决策依赖推定而非事实
+- **后果重大**：方案失败可能导致不可逆损失、安全风险或重大资源浪费
+- **高不确定性**：方案涉及新技术、新领域或未曾验证的假设
+
+**触发时机**：阶段3备忘录产出后、阶段4（方案输出与交付）开始前的间隙。
+
+**条件B：用户显式指令**
+
+用户发出以下任一指令时，立即在下一轮启动红队攻击：
+- "红队攻击"
+- "对这个方案进行对抗性审查"
+- "让红队来攻击一下"
+- "启动红队测试"
+
+### 攻击执行规范
+
+#### 轮次要求
+
+- **最低攻击轮次**：3轮，每轮覆盖不同的攻击维度组合
+- **每轮维度分配**：每轮至少使用2个、最多3个攻击维度
+- **维度覆盖要求**：3轮攻击结束后，6个攻击维度必须全部被覆盖至少一次
+- **追加轮次**：如果专家组答辩后仍有未解决的致命/严重缺陷，自动追加1轮专项攻击聚焦该缺陷
+
+#### 维度分配规则
+
+| 攻击轮次 | 必选维度 | 可选维度（选1-2个） |
+|---------|---------|-------------------|
+| 第1轮 | 假设挑战 | 边界压力、替代解释 |
+| 第2轮 | 最坏情况 | 逆向思维、历史类比失败 |
+| 第3轮 | 逆向思维 | 边界压力、历史类比失败 |
+
+#### 攻击输出格式
+
+每轮攻击输出必须包含以下要素：
+
+1. **攻击维度声明**：明确本轮使用的攻击维度
+2. **攻击发现列表**：每个发现包含：
+   - 发现编号（格式：RT-轮次-序号，如 RT-1-001）
+   - 攻击维度
+   - 攻击描述（≤150字）
+   - 严重度评级（致命/严重/中等/轻微）
+   - 被攻击的具体方案组件或结论
+3. **发现汇总**：本轮发现数量及严重度分布
+
+### 答辩规范
+
+#### 答辩方
+
+被攻击方为参与阶段3的全体专家组成员，由主持人协调答辩顺序和发言权。
+
+#### 答辩要求
+
+- **逐条回应**：每条攻击发现必须被逐一回应，不可跳过、不可合并
+- **不可回避**：不得以"超出讨论范围""概率很低""业界惯例"等理由拒绝回应
+- **回应分类**：
+  - **接受并修正**：承认攻击有效，给出修正方案
+  - **接受但容忍**：承认攻击有效，但论证其严重度不足以推翻方案，给出风险接受的理由
+  - **反驳**：论证攻击不成立，必须给出具体依据和逻辑链
+- **计时**：每条发现的答辩限时 90 秒，超时标记为"答辩未完成"
+
+#### 答辩评分
+
+审查AI对每条答辩进行评分：
+
+| 评分 | 标准 |
+|-----|------|
+| 充分回应 | 答辩逻辑完整、依据充分、推翻了攻击或给出了可验证的修正方案 |
+| 部分回应 | 答辩部分回应了攻击，但存在逻辑缺口或依据薄弱 |
+| 回应不足 | 答辩回避了核心问题，或以模糊理由拒绝回应 |
+| 未回应 | 超时或跳过该条攻击发现 |
+
+### 残余风险输出
+
+攻击结束后，红队攻击者汇总所有攻击发现中"答辩评分 ≠ 充分回应"的条目，生成《残余风险清单》。
+
+#### 残余风险分级
+
+| 残余风险等级 | 判定条件 | 处理建议 |
+|-------------|---------|---------|
+| **P0 - 未解决致命风险** | 致命级发现且答辩评分 = 回应不足或未回应 | 方案不可交付，必须重新设计 |
+| **P1 - 未解决严重风险** | 严重级发现且答辩评分 = 回应不足或未回应 | 必须补充风险缓解措施后方可交付 |
+| **P2 - 部分回应的中等风险** | 中等发现且答辩评分 = 部分回应 | 交付时附带风险声明和监控建议 |
+| **P3 - 需关注的轻微风险** | 轻微发现且答辩评分 = 部分回应或回应不足 | 标记为观察项，纳入后续迭代计划 |
+
+#### 残余风险清单格式
+
+| 风险编号 | 原始发现编号 | 攻击维度 | 残余风险描述 | 风险等级 | 专家组回应摘要 | 为何未充分解决 |
+|---------|------------|---------|-------------|---------|--------------|--------------|
+| RR-001  | RT-2-003   | 最坏情况 | 迁移失败无回滚路径 | P0 | "已规划备份，但未验证回滚时间" | 回滚时间未量化，实际可行性存疑 |
+
+### 终止条件
+
+红队攻击在满足以下任一条件时终止：
+
+1. 3轮攻击完成，且残余风险清单中无 P0 级风险
+2. 用户显式指令"终止红队攻击"
+3. 专家组主动承认方案存在致命缺陷，请求终止攻击以重新设计
+
+若3轮后仍存在 P0 级风险，自动追加第4轮专项攻击。第4轮后仍存在 P0 级风险，标记为"方案未通过红队检验"，将完整攻击记录和残余风险清单交付用户决策。
+
+## 红队攻击报告模板
+
+```json
+{
+  "report_type": "红队攻击报告",
+  "generated_at": "ISO 8601",
+  "target_solution": "被攻击的方案摘要",
+  "attack_rounds": [
+    {
+      "round": 1,
+      "dimensions_used": ["假设挑战", "边界压力"],
+      "findings": [
+        {
+          "finding_id": "RT-001",
+          "dimension": "假设挑战",
+          "description": "攻击描述",
+          "severity": "致命/严重/中等/轻微",
+          "target_response": "专家组回应",
+          "residual_risk": "未充分回应的残留风险"
+        }
+      ]
+    }
+  ],
+  "summary": {
+    "total_findings": 0,
+    "fatal_findings": 0,
+    "unresolved_risks": [],
+    "overall_assessment": "方案通过红队检验 / 方案存在重大缺陷需重新设计 / 方案部分通过但存在残余风险",
+    "recommendation": "建议"
+  }
+}
+```
+
+### 报告字段说明
+
+| 字段 | 说明 |
+|------|------|
+| `report_type` | 固定值："红队攻击报告" |
+| `generated_at` | 报告生成时间，ISO 8601 格式 |
+| `target_solution` | 被攻击方案的简要摘要（≤200字），标注方案来源（阶段3备忘录编号） |
+| `attack_rounds` | 攻击轮次数组，每轮包含维度组合和发现列表 |
+| `attack_rounds[].round` | 轮次编号，从1开始递增 |
+| `attack_rounds[].dimensions_used` | 本轮使用的攻击维度名称列表 |
+| `findings[].finding_id` | 全局唯一发现编号，格式：RT-轮次-序号 |
+| `findings[].severity` | 严重度：致命（方案无法成立）、严重（核心组件需重构）、中等（可修复但影响较大）、轻微（边界场景可忽略） |
+| `findings[].target_response` | 专家组对该发现的答辩内容摘要（≤100字） |
+| `findings[].residual_risk` | 若答辩未充分解决该发现，填写残留风险描述；若已完全解决，填写"已解决" |
+| `summary.total_findings` | 3轮攻击的总发现数量 |
+| `summary.fatal_findings` | 严重度为"致命"的发现数量 |
+| `summary.unresolved_risks` | 未被充分回应的攻击发现ID列表 |
+| `summary.overall_assessment` | 三选一：方案通过 / 存在重大缺陷需重新设计 / 部分通过但存在残余风险 |
+| `summary.recommendation` | 针对方案的改进建议或风险接受建议（≤300字） |
+
+### 严重度判定标准
+
+| 严重度 | 判定标准 | 方案后果 |
+|--------|---------|---------|
+| 致命 | 方案核心假设被证伪，或最坏情况推演导致不可逆的灾难性后果 | 方案不可成立，需推翻重来 |
+| 严重 | 方案关键组件存在设计缺陷，在可预见的条件下会失效 | 核心组件需重新设计，其余部分可保留 |
+| 中等 | 方案存在可修复的逻辑漏洞或覆盖不足，但不影响整体可行性 | 需补充修正方案，不改变方案主体 |
+| 轻微 | 方案在极端边界条件下可能出现非关键性问题 | 可以接受该风险，标记为后续优化项 |

package/.claude/skills/multi-expert-discussion/references/roles.md

@@ -44,6 +44,40 @@
 - **输出规范**：发言前标注"[魔鬼代言人模式]"，与原专家身份明确区分
 - **评分要求**：反方论证的评分独立进行，不与原专家评分混合
 
+### 红队攻击者（Red Team Attacker）
+- **来源**：独立角色，由审查AI在红队攻击阶段临时创建，非专家组常驻成员
+- **触发条件**：灰度导航类问题（价值冲突、信息不完备、后果重大）在专家组产出初步方案后自动触发
+- **职责**：
+  - 对专家组已产出的方案进行系统性攻击测试
+  - 覆盖六大攻击维度：假设挑战、边界压力、替代解释、最坏情况、逆向思维、历史类比失败
+  - 每轮攻击选择2-3个维度组合，确保3轮内覆盖所有维度至少一次
+  - 攻击必须附带置信度评分和严重度评级（致命/严重/中等/轻微）
+- **与魔鬼代言人的区别**：
+  | 维度 | 魔鬼代言人 | 红队攻击者 |
+  |------|-----------|-----------|
+  | 介入时机 | 研讨过程中预防性介入 | 方案产出后事后攻击 |
+  | 作用性质 | 防止回音室，制造必要分歧 | 压力测试，验证方案韧性 |
+  | 攻击对象 | 当前轮次的共识议题 | 已产出的完整方案 |
+  | 参与方式 | 由现有专家临时担任 | 独立创建的新角色 |
+  | 作用域 | 单轮/单议题 | 全方案系统性审查 |
+- **输出规范**：发言前标注"[红队攻击模式 - 第N轮]"，每轮输出攻击发现列表，附严重度评级
+
+### 认知监察官（Cognitive Inspector）
+- **来源**：独立角色，与审查AI并行但职能不同
+- **触发条件**：研讨进入元认知层（偏见声明完成后）自动激活，全程并行运行
+- **职责**：
+  - 偏见扫描：追踪各专家是否持续受初始偏见影响而未被纠正
+  - 可信度审计：二次审核审查AI的置信度标注，检查是否有系统性高估或低估
+  - 盲点检测：识别专家组集体忽略的视角或维度
+  - 熵增预警：对研讨过程本身的熵增（讨论内卷、脱离现实、语言游戏化）发出预警
+- **四项固定检查（每轮结束后执行）**：
+  1. 人类中心主义预警：是否在用纯政治/关系的框架解释主要由自然或技术驱动的问题？
+  2. 利害计算万能论预警：是否把所有行为者的动机都还原为趋利避害，忽略超越性召唤？
+  3. 「安逸的熵增」预警：当前分析框架本身是否因过于复杂而脱离了现实？
+  4. 「虚无的熵增」预警：是否因看到"一切都终将熵增"而滑向了悲观宿命论？
+- **输出规范**：每轮结束后输出「认知监察官审校备注」，简短的3-5条审校意见，不阻塞主流程
+- **与审查AI的区别**：审查AI关注"结论是否正确"，监察官关注"思考过程是否有偏"
+
 ## 动态专家角色
 
 - 根据问题领域动态定义（例如：战略顾问、技术架构师、风险分析师、用户研究员、伦理学家等）
@@ -54,6 +88,17 @@
   - 综合置信度标签（高/中/低/存疑）
   - 潜在偏见影响自评（0-5）
 
+### 权力意志分析专家（Power Will Analyst）
+- **来源**：动态专家角色，当问题涉及组织决策、权力结构重组或利益博弈时自动招募
+- **职责**：
+  - 从权力动力学角度分析各方的利益格局和行动逻辑
+  - 识别隐性权力结构（非正式权威、信息垄断者、议程设置者）
+  - 分析决策过程中各方的话语权和否决权
+  - 评估方案实施的权力可行性（谁会支持？谁会抵制？抵制的筹码是什么？）
+- **触发条件**：问题涉及组织内部决策/跨部门协作/资源分配/战略转型
+- **初始偏见声明**：必须声明自身的权力分析框架偏好（如倾向于冲突论还是合作论）
+- **输出规范**：在发言中标注"[权力意志分析视角]"
+
 ## 搜索/研究专家（Research Agent）
 - **职责**：
   - 在研讨过程中，根据专家的信息需求或审查AI的核查指令，执行外部信息检索
@@ -69,3 +114,36 @@
   - 引用来源列表（URL + 标题 + 摘要）
   - 时效性标注（发布时间 vs 当前日期）
   - 可信度预标注（高/中/低/存疑）
+
+## 偏见声明 JSON 模板
+
+```json
+{
+  "expert_id": "Expert_A",
+  "role": "技术架构师",
+  "declaration": {
+    "core_assumptions": ["预设1：微服务架构优于单体", "预设2：..."],
+    "cognitive_biases": [
+      {
+        "type": "确认偏误",
+        "description": "倾向于寻找支持微服务架构的证据",
+        "self_rating": 3
+      }
+    ],
+    "experience_domain": "后端架构设计，10年经验",
+    "limitations": ["缺乏前端架构经验", "无特定行业领域知识"],
+    "conflict_of_interest": "无",
+    "interest_declaration": {
+      "stakes": "在该议题中的利害关系描述",
+      "beneficiary": "谁将从我的建议中获益",
+      "cost_bearer": "谁将承担我的建议的成本"
+    },
+    "presupposition_anatomy": {
+      "core_presuppositions": ["我不自觉的预设1", "预设2"],
+      "untested_beliefs": ["未经检验的信念"],
+      "disciplinary_blinders": "我的学科/专业背景可能带来的盲区"
+    },
+    "last_updated": "ISO 8601"
+  }
+}
+```

package/.claude/skills/multi-expert-discussion/references/scoring.md

@@ -18,6 +18,54 @@
 - 7-11 → 低
 - <7 → 存疑
 
+## 随机性折扣因子
+
+任何确定性断言在标注可信度时，强制包含随机性折扣因子（Randomness Discount Factor, RDF），对确定性进行概率衰减。
+
+### 折扣因子计算
+
+RDF 取值范围 0.0-1.0，取值越小表示随机性/不确定性越高：
+
+| RDF | 含义 | 触发条件 |
+|-----|------|---------|
+| 1.0 | 无折扣（确定性极高） | 基于数学定理、物理定律、官方权威数据 |
+| 0.9 | 轻微折扣 | 基于广泛验证的工程实践、行业共识 |
+| 0.8 | 中度折扣 | 基于有限样本的经验判断、专家共识 |
+| 0.7 | 显著折扣 | 基于个人经验、未经验证的假设 |
+| 0.6 | 较大折扣 | 基于类比推理、跨界推断 |
+| 0.5 | 半数折扣 | 基于直觉、启发式判断、信息明显不完整 |
+| <0.5 | 高折扣 | 纯推测、无数据支持、高度不确定性环境 |
+
+### 折扣后置信度计算
+
+- 折扣后综合分 = 原始综合分 × RDF
+- 折扣后标签按以下阈值重新判定：
+  - ≥17 → 高
+  - 12-16 → 中
+  - 7-11 → 低
+  - <7 → 存疑
+
+### 标注格式
+
+可信度标注必须包含以下信息：
+- 原始等级（高/中/低/存疑）
+- 随机性折扣因子（RDF）
+- 折扣后等级（高/中/低/存疑）
+- 不确定性来源分类
+
+标注格式示例：「高(RDF 0.8)→中 | 不确定性来源：样本量有限」
+
+## 不确定性来源分类
+
+每项可信度标注必须明确不确定性来源，分为四类：
+
+| 来源类型 | 说明 | 示例 |
+|---------|------|------|
+| 随机性 (Aleatory) | 源于系统固有的随机性，不可消除 | 市场波动、用户行为的随机成分 |
+| 认知局限 (Epistemic) | 源于我们当前知识的不足，可通过研究消除 | 未知的技术细节、未查阅的文献 |
+| 信息缺口 (Information Gap) | 源于信息不完整或不可获取 | 竞争对手的非公开数据、未来事件 |
+| 模型局限 (Model Limitation) | 源于分析框架或模型的简化/假设 | 用线性模型近似非线性现象 |
+
 ## 低置信度处理图谱
 
 - **存疑内容**：标记为"假设性参考"，仅供灵感，不做决策依据
@@ -25,6 +73,7 @@
 - **事实错误**：审查AI直接删除，并要求专家修正论述
 - **推理漏洞**：打回专家，附审查AI质询，要求重新推理
 - **无外部验证内容**：标记"孤证待验证"，建议触发搜索子阶段补充证据
+- **经随机性折扣降级内容**：标记原始等级和折扣后等级，说明降级原因（RDF值和不确定性来源），若折扣后等级仍为「高」，保留为决策依据；若降级至「中」及以下，按对应等级的处理规则执行
 
 ## 专家权重分配机制