sdd-full 5.1.6 → 5.1.7

package/.claude/commands/mu.md

@@ -2,21 +2,55 @@
 
 当用户输入 /mu 命令时，执行以下流程：
 
+0. 默认最大讨论10分钟，根据用户需求动态调整。动态调整时间范围：5-15分钟。
+
 1. 检查当前需求是否符合触发条件：
    - 模糊/开放式的技术或产品需求
-   - 需要多角度分析、行业调研、技术选型、方案对比
-   - 需要区分 MVP/标准/顶配三套方案
-2. 加载 multi-expert-discussion 技能，执行核心流程：
-   - 阶段 1：需求解析（领域、目标、约束、指标）
-   - 阶段 2：专家规划与创建（动态子 Agent）
-   - 阶段 3：圆桌自由研讨（并行搜索 + 专家辩论）
-   - 阶段 4：方案收敛（输出三套完整方案）
+
+2. 加载 `multi-expert-discussion` 技能，执行核心流程：
+   - 阶段 1：问题定义与专家招募
+   - 阶段 2：初始立场与信息对齐
+   - 阶段 3：圆桌自由研讨（支持搜索子阶段、专家辩论）
+   - 阶段 3.5：多分支并行探索（Fork，可选）
+   - 阶段 3.6：分支结果对比与融合（Merge，可选）
+   - 阶段 4：对输出的二次研讨（迭代深化，可选）
 3. 输出结果：
-   - docs/progress/ - 中途落地文档（每轮研讨快照）
-   - docs/solutions/ - 最终方案（solution\_mvp.md、solution\_standard.md、solution\_pro.md）
+   - docs/{讨论关键字}/progressprogress/ - 中途落地文档（每轮研讨快照、阶段备忘录）
+   - docs/{讨论关键字}/solutions/ - 最终方案（solution_mvp.md、solution_standard.md、solution_pro.md，包含决策可追溯链）
 4. 支持的子命令：
-   - /continue - 接续之前的研讨
+   - /continue - 接续之前的研讨（使用状态转储恢复）
    - /new - 新建研讨
    - /check - 自检模式条件
-5. 所有输出自动保存到当前议题文件夹（最多 8 个字）
+5. 所有输出自动保存到当前议题文件夹，命名规则：
+   ```
+   {讨论关键字（3-10字）}_{YYYYMMDD_HHmmss}
+   ```
+   例如：`技术选型_20260513_143022`
+
+---
+
+## 技能文件结构说明
+
+```
+.multi-expert-discussion/
+├── SKILL.md (核心编排流程)
+├── references/
+│   ├── roles.md          # 角色体系定义
+│   ├── scoring.md        # 评分体系
+│   ├── mechanisms.md     # 流程机制详解
+│   └── schemas.md        # Schema 汇总
+└── templates/
+    └── reports.md        # 所有模板和输出规范
+```
+
+## 关键特性
+
+- ✅ 置信度评估体系（来源可靠性、逻辑一致性、数据可验证性、外部验证支持度）
+- ✅ 多分支并行探索（Fork/Merge 机制）
+- ✅ 死锁检测与熔断机制
+- ✅ 搜索子阶段（支持 Web 搜索、代码库搜索、文档查询）
+- ✅ 魔鬼代言人机制（防止回音室效应）
+- ✅ 上诉与异议裁决流程
+- ✅ 决策可追溯链（支持多层嵌套引用）
+- ✅ 完整的韧性机制（超时处理、异常恢复、健康监控）
 

package/.claude/skills/multi-expert-discussion/SKILL.md

@@ -1,152 +1,170 @@
-***
-
+---
 name: multi-expert-discussion
-model: deepseek-v4-flash
-description: Use when the user provides a vague/high-level requirement (technical, product, or design) that needs systematic analysis, multi-perspective debate, web research, and structured output across multiple solution tiers. Not for simple Q&A, single-expert tasks, or straightforward coding tasks.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-
-# 万能中枢式多专家自动研讨系统
-
-## 概述
-强制启用 Coordinator 中心化调度模式，纯对话内运行，无云端、无代码，自带断点续存、模式自动选择、前置条件自检、自动切换运行模式。
-主中枢 Agent 接收一句模糊需求，自动规划专家角色、动态创建独立子 Agent，组织圆桌自由研讨（含联网搜索），最终收敛输出 MVP/标准/顶配三套完整落地方案。
-
-## 输出目录规范
-所有输出文档统一存放在项目根目录的 `docs/` 下，按类型分目录：
-
-```
-docs/
-├── progress/          # 中途落地文档（每轮研讨快照）
-│   └── {内容提炼3-8字}_{timestamp}.md
-├── solutions/         # 最终方案
-│   ├── {内容提炼3-8字}_mvp_{timestamp}.md
-│   ├── {内容提炼3-8字}_standard_{timestamp}.md
-│   └── {内容提炼3-8字}_pro_{timestamp}.md
-└── archive/           # 历史归档（可选，用于大任务存档）
-    └── ...
-```
-
-- 任何文件输出路径必须使用 `docs/` 前缀
-- 中间产物写入 `docs/progress/`，最终方案写入 `docs/solutions/`
-- 文件名格式：按照讨论内容提炼3-8个字 + 数字时间戳（YYYYMMDDHHMMSS）
-
-## 何时使用
-
-**触发条件：**
-
-- 用户给出模糊/开放式的技术或产品需求，需要多角度分析
-- 需要行业调研 + 技术选型 + 方案对比 + 落地步骤的系统性输出
-- 方案需要区分不同投入级别（轻量/标准/顶配）
-- 需求涉及竞品分析、SOTA 调研、技术可行性评估
-
-**不要用于：**
-
-- 可直接回答的单一问题
-- 纯编码任务（可直接写代码的场景）
-- 已有明确方案的执行性任务
-
-## 核心流程
-
-### 阶段 1：需求解析
-
-解析用户输入的领域、目标、约束、硬件、性能指标、输出格式。
-
-
-### 阶段 2：专家规划与创建
-
-极简公式（定角色 = 划边界 万能公式）
-角色定义 = 锁定知识边界 + 锁定身份立场 + 锁定思考逻辑 + 锁定输出规则本质就是：把通用大模型，强行关进你划定的专业圈子里，不许出圈、不许乱聊、不许外行回答。
+description: >
+  通过模拟多学科专家团队对复杂问题进行结构化研讨。具备置信度评估、多分支并行探索、死锁检测熔断、搜索验证、决策可追溯链。当用户需要多角度分析复杂问题、方案评审、技术选型决策、风险评估时使用。用户也可直接使用 /multi-expert-discussion 触发。
+disable-model-invocation: false
+---
 
- 1：给 AI 定义细分角色，是不是就是划定大模型搜索边界？
-是，完全就是大模型原本知识库是全开放的，什么都能检索、什么都能联想。你给细分角色，就是人为缩小它的知识检索范围：只允许调取这个行业、这个岗位、这个专业的内容，自动屏蔽无关领域的知识、废话、跨界瞎扯。角色 = 人工圈定搜索边界。
+# Multi-Expert Discussion
 
- 2：边界越细分，AI 越专业？
-对，成正比
-边界越宽（角色笼统：你是全能顾问）→ 回答泛、水、不落地、像闲聊
-边界越窄（角色细分：你是实体店餐饮运营、只做门店拓客）→ 知识聚焦、思维专一、话术专业、不跑题
-越收敛，越专业；越宽泛，越业余。
+## 技能目标
 
- 3：角色定义除了搜索边界，还限制了什么？
-不止是知识搜索边界，还有 3 层隐形边界：
-思维边界：强制用这个行业的专业逻辑思考，不用普通人闲聊逻辑
-立场边界：站在从业者 / 老板 / 律师 / 文案的立场说话，不中立瞎扯
-输出边界：限定语气、格式、篇幅、不许废话、不许模板套话
+通过模拟多学科专家团队，对复杂问题进行结构化、可追溯、高韧性的研讨，产出附带置信度评估、决策链记录、支持并行探索与迭代深化的稳健方案。输出自带结构化导航目录。
 
+## 快速启动
 
-1. 根据需求规划所需专家角色（需求拆解、AI搜索、竞品分析、技术架构、工程落地、收敛等）
-2. 为每个专家分配独立模型、工具权限、专属系统提示词
-3. 使用 create_agent() 批量创建独立子 Agent
-4. 广播统一任务背景给所有专家
+1. 主持人确认问题边界
+2. 自动招募专家团队
+3. 启动圆桌研讨
+4. 产出最终报告
 
-### 阶段 3：圆桌自由研讨
+## 核心流程总览
 
-1. **搜索优化（并行 + 缓存 + 超时）**：
-   - **多路并行搜索**：按需求维度拆分为 2-3 路独立搜索（如：技术方案、竞品市场、学术SOTA），使用 create_agent() 同时启动并行搜索子 Agent，互不等待
-   - **搜索缓存**：每轮搜索前先检查缓存（ContextManager 搜索层），相同 query 直接返回缓存结果，避免重复搜索
-   - **搜索策略分层**：先执行轻量快速搜索（30秒获取概要），若时间充裕再执行深度搜索（60秒获取细节）
-   - **严格超时**：单路搜索 **最大 60 秒**，超时立即返回已有部分结果，多路并行总体等待 ≤90 秒
-   - **搜索结果精简**：仅保留结论 + 关键数据（含来源）+ 1 个最相关链接，删除冗余描述，每路 ≤1000 token
-2. 专家轮流发言，互相引用、质疑、反驳、补充（双向通信，非流水线串行）
-3. 主中枢做消息路由
-4. **讨论轮数自适应**：主中枢根据问题复杂度动态设定 2-5 轮讨论。简单问题 2 轮收敛，中等复杂度 3-4 轮，复杂问题最多 5 轮。达成共识可提前终止
-5. 每 4 轮自动执行上下文压缩
-6. 每路搜索输出 ≤1000 token，专家发言 ≤800 token
-7. **专家思考时限**：每轮每位专家单次思考最长 5 分钟，超时立即输出已有结论，禁止无限思考或反复自我修正
-
-### 阶段 4：方案收敛
-
-调度收敛专家整合全部观点，输出：
-
-- **MVP 轻量版**：最小可用，快速落地
-- **标准版**：平衡性能与成本
-- **顶配专业版**：不计成本，对标行业顶级效果
-
-每版包含：技术选型、模型、参数、Prompt、配置、风险点、部署步骤。
-
-## 一、全自动记忆 & 断点续存（强制执行）
-1. 每轮圆桌结束，自动生成精简【会话快照】，仅保留：需求、约束、专家、当前轮次、核心结论，禁止携带冗余历史。
-2. 后续调用只传入【快照+最新发言】，严格压缩上下文。
-3. 指令：/continue=接续；/new=新建；/check=自检模式条件
-4. **文件夹规范**：所有输出必须保存到**当前议题文件夹**下，文件夹名根据需求自动生成，**最多 8 个字**。
-5. **中途落地文档**：每轮研讨后在议题文件夹下自动输出 `{内容提炼3-8字}_{timestamp}.md`，包含当前讨论进度、阶段性结论、待确定问题，便于随时查看和追溯。
-
-## 二、模型绑定
-模型在技能 frontmatter 的 `model` 字段中固定指定（当前为 `deepseek-v4-flash`），加载技能时自动生效。
-如需临时切换，使用 `/model <模型名>` 命令手动覆盖。
-
-## 三、调度模式（适配 Deepseek 速度，禁止串行）
-1. 【并行中心化圆桌（默认强制）】主中枢控收敛，所有专家并行调用，禁止串行排队。
-2. 【蜂群模式】：仅用于纯头脑风暴。
-&gt; 永久禁用串行圆桌模式，Deepseek 串行会极度卡顿。
-
-## 四、Deepseek 输出强制提速规则
-1. 思考极简：禁止深度啰嗦推理、禁止自我反问、禁止客套铺垫，直接输出核心内容。
-2. 输出精简：严格控制单次输出长度，拒绝大段解释。
-3. 禁止流式啰嗦输出，一口气给出完整结果。
-
-## 五、自动前置条件检查 &amp; 执行流程
-接收需求 → 判断任务类型 → 加载 skill 自动绑定 frontmatter 模型 → 自检条件 → 并行专家调用 → 精简快照保存 → 收敛输出方案
+```
+问题定义 → 专家招募 → 初始立场对齐 → 圆桌研讨（搜索子阶段可选）
+→ （分叉条件触发？）→ 多分支并行探索 → 分支结果对比融合
+→ 最终报告 → （二次研讨？）→ 迭代深化
+```
 
-## 上下文治理规则（强制）
+## 阶段 1：问题定义与专家招募
+
+- **主持人职责**：与用户明确问题边界、输出格式、时间/成本约束
+- **专家创建**：根据问题领域动态创建专家角色
+- **偏见声明**：每位专家首次发言时完成偏见声明（模板见 templates/reports.md）
+- **角色定义**：详见 references/roles.md
+
+## 阶段 2：初始立场与信息对齐
+
+- **专家发言**：每位专家发表初始观点
+- **评分体系**：使用置信度评分体系（详见 references/scoring.md）
+- **审查AI预标注**：首轮事实核查和置信度预标注
+- **分叉点识别**：标记潜在的高置信度互斥方向
+
+## 阶段 3：圆桌自由研讨
+
+此阶段可在单分支或多分支中运行。每个分支内部拥有一套完整的专家实例和本地审查AI。
+
+### 每轮内部流程
+
+1. **专家发言**（超时控制生效），包含量化评分、置信度标签、偏见自评
+2. **其他专家响应/反驳**，同样附带评分
+3. **搜索子阶段**（可选，条件触发）：
+   - 触发条件：专家标注"需要外部验证"、审查AI标记信息缺口、用户显式触发
+   - 搜索专家执行信息检索并注入结果
+   - 详见 references/roles.md 中的搜索/研究专家定义
+4. **本地审查AI执行**：
+   - 置信度审核与处理（低分内容处理详见 references/scoring.md）
+   - 回音室效应检测（详见 references/mechanisms.md）
+   - 上诉与异议裁决（详见 references/mechanisms.md）
+5. **生成阶段备忘录**（模板见 templates/reports.md），发送至各专家进行事实性确认
+6. **确认后的备忘录存入上下文**，作为决策链记录
+7. **主持人检测死锁指标**（公式详见 references/scoring.md），触发则执行熔断策略（详见 references/mechanisms.md）
+8. **检查分叉/合并条件**（详见下文阶段3.5和3.6）
+
+### 本轮结束前，分支管理AI判断
+
+- 若存在≥2个互斥高置信度方向（或用户要求），触发 **Fork** 操作（见阶段3.5）
+- 否则，继续下一轮，直到达到预设轮次、收敛或死锁熔断
+
+## 阶段 3.5：多分支并行探索（Fork）
+
+- **触发条件**：在任意轮次后，满足以下之一：
+  - 专家组裁决：存在≥2个高置信度但互斥方向
+  - 审查AI建议：继续单线程无法消除不确定性
+  - 用户显式指令
+- **操作**：
+  - 分支管理AI记录当前分叉点上下文快照（详见 references/mechanisms.md）
+  - 创建新分支，每个分支复制相同专家团队和规则，但指定探索方向
+  - 每个分支独立运行**阶段3完整内循环**
+- **分叉管理API**：详见 templates/reports.md
+- **资源隔离**：分支间不直接共享后续生成内容，只通过分叉点继承公共知识
+
+## 阶段 3.6：分支结果对比与融合（Merge）
+
+### 分支合并条件
+
+满足以下任一条件时，分支结束并进入Merge阶段：
+1. 所有分支均达到预设最大轮次（默认5轮）
+2. 所有分支均达成"收敛"（连续2轮无新分歧项产生）
+3. 某分支触发死锁熔断且魔鬼代言人介入无效
+4. 用户显式指令"合并讨论"
+5. 全局时间预算耗尽
+
+**特殊规则**：
+- 若仅1个分支达到收敛而其他分支仍在讨论，收敛分支提前冻结，等待其他分支
+- 若某分支的资源（token/时间）耗尽，生成部分结论并标记"未完成"
+
+### Merge流程
+
+- **总审查AI升级为元审查AI**（详见 references/mechanisms.md）
+- 收集各分支《最终方案报告》和全量阶段备忘录
+- 生成《多分支决策对比表》：
+  | 维度 | 分支A方案 | 分支B方案 |
+  |------|-----------|-----------|
+  | 核心逻辑 | ... | ... |
+  | 综合置信度 | 14.2 (高) | 11.8 (中) |
+  | 优势 | ... | ... |
+  | 致命弱点 | ... | ... |
+  | 资源可行性 | 高 | 中 |
+- **融合方案冲突检测**（详见 references/mechanisms.md）
+- 若存在互补可能性，元审查AI可提议融合方案
+- 输出最终推荐排序，附完整决策追溯链（模板见 templates/reports.md）
+
+## 阶段 4：对输出的二次研讨（迭代深化）
+
+支持用户对已生成的任何结论、风险项或子议题发起新一轮研讨，实现递归深入研究。
+
+- **触发方式**：用户在收到最终输出后，发送指令如"针对结论X再次讨论"或"对风险Y深入分析"
+- **流程**：
+  1. 主持人提取被指定议题，并将其作为新的核心问题
+  2. 继承上一轮的所有阶段备忘录、分支对比表、决策链作为背景知识
+  3. 沿用原专家团队，或根据新问题增补专家。每位专家的初始偏见声明可更新
+  4. 完全复用阶段1至阶段3.6的机制
+  5. 新一轮产生独立的决策链和备忘录，并与上一轮建立关联（生成二级决策链，模板见 templates/reports.md）
+- **嵌套支持**：理论上可多次迭代，每次生成新的研讨层，直至用户满意
+
+## 韧性机制速查
+
+- **超时策略**：专家发言60秒、审查AI审核30秒、备忘录生成20秒（详见 references/mechanisms.md）
+- **死锁检测与熔断**：连续3轮无进展触发，强制引入魔鬼代言人或随机调入新专家（详见 references/mechanisms.md）
+- **异常分类与处理矩阵**：9种异常类型的自动化处理策略（详见 references/mechanisms.md）
+- **实例健康监控**：心跳检测、内存/Token检测、响应质量检测（详见 references/mechanisms.md）
+- **分支内死锁处理**：与主线程略有差异（详见 references/mechanisms.md）
+- **断点续存**：上下文快照和状态转储（详见 references/mechanisms.md）
 
-| 层级    | 内容         | 策略                         |
-| ----- | ---------- | -------------------------- |
-| 永久层   | 用户需求、约束、目标 | 永久保留，不压缩                   |
-| 活跃层   | 最近 4-6 轮讨论 | 滚动保留                       |
-| 历史摘要层 | 更早讨论       | 压缩为要点，删除原始长文本              |
-| 搜索层   | 搜索结果       | 单轮 ≤2000 token，仅结论+关键数据+链接 |
-| 专家发言  | 单轮观点       | 单轮 ≤800 token              |
+## 输出规范
 
-所有子 Agent 中间推理隔离在自身上下文，主上下文仅存摘要与最终结果。
+### 文件夹命名规则
+```
+{讨论关键字（3-10字）}_{YYYYMMDD_HHmmss}
+```
+例如：`技术选型_20260513_143022`
 
-## 角色体系
+### 输出目录结构
+```
+{讨论关键字}_{时间}/
+├── docs/
+│   ├── progress/      # 中途落地文档（每轮研讨快照、阶段备忘录）
+│   └── solutions/     # 最终方案（solution_mvp.md、solution_standard.md、solution_pro.md）
+└── context/           # 上下文快照和状态转储文件
+```
 
-- **主中枢 Agent**（永久存在）：需求解析、专家规划、创建子 Agent、圆桌控场、消息路由、上下文治理、结果收敛
-- **动态子专家**（按需创建）：需求拆解、AI搜索、行业竞品、技术架构、工程落地、收敛等角色，不固定数量
+### 其他规范
+- **最终输出目录**：使用 templates/reports.md 中的目录模板，确保可点击跳转
+- **报告模板**：所有报告模板见 templates/reports.md
+- **消息传递格式**：实例间消息格式见 templates/reports.md
+- **Schema 索引**：所有 Schema 汇总见 references/schemas.md
 
-## 输出规范
+## 文件结构参考
 
-1. **文件夹规范**：所有输出必须保存到**当前议题文件夹**下，文件夹名根据需求自动生成，**最多 8 个字**
-2. 最终输出必须包含三套完整方案，每套方案独立成章，包含完整的技术选型、架构、配置、Prompt、部署步骤和风险说明
-3. **方案必须输出为 **`{内容提炼3-8字}_mvp_{timestamp}.md`、`{内容提炼3-8字}_standard_{timestamp}.md`、`{内容提炼3-8字}_pro_{timestamp}.md` 三个独立的 Markdown 文件，均放在议题文件夹下
-4. 主上下文不堆积中间讨论与冗余信息
+```
+.multi-expert-discussion/
+├── SKILL.md (本文件)
+├── references/
+│   ├── roles.md          # 角色体系定义
+│   ├── scoring.md        # 评分体系
+│   ├── mechanisms.md     # 流程机制详解
+│   └── schemas.md        # Schema 汇总
+└── templates/
+    └── reports.md        # 所有模板和输出规范
+```

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

@@ -0,0 +1,191 @@
+# 流程机制详解
+
+## 超时策略
+
+- **专家发言限时**：默认 60 秒，可配置。超时未返回有效发言，视为该专家本轮弃权，主持人记录"状态：无响应，维持上次有效立场"，并跳过该专家
+- **审查AI审核限时**：30 秒。超时则该轮审核不通过，标记为"审查未完成"，该轮置信度整体降级，并触发告警供人工检查
+- **阶段备忘录生成限时**：20 秒。超时由主持人接管生成简易版备忘
+
+## 死锁检测与熔断
+
+- **判定条件**：连续 3 轮同时满足（详见 references/scoring.md）
+- **执行熔断**：
+  - 强制引入"魔鬼代言人"（若尚未在场）或随机调入新专家视角
+  - 若仍无法打破，则终止该分支或整场研讨，生成《分歧终止报告》，将当前状态完整交付用户决策，避免无限循环
+
+## 回音室效应检测算法
+
+- **触发阈值**：连续2轮满足「共识度 ≥ 4.8」且「分歧强度 < 0.5」
+- **检测算法**：
+  1. 计算本轮所有议题的共识度均值
+  2. 若均值 ≥ 4.8，检查是否有议题存在事实上的多元答案
+  3. 审查AI随机选取1个"高共识"议题，尝试构造反方论证
+  4. 若反方论证存在合理性（置信度 ≥ 中），判定为回音室效应
+- **处理**：指定一名置信度最高的专家临时担任魔鬼代言人（任期：1轮）
+
+## 上诉与异议裁决流程
+
+1. 专家在审查AI发布备忘录后1轮内（窗口期），可对以下事项提起上诉：
+   - 审查AI对其观点的置信度降级
+   - 审查AI对其发言的事实性否决
+   - 审查AI的偏见指控
+2. 上诉格式：
+   ```json
+   {
+     "type": "appeal",
+     "expert": "Expert_A",
+     "target_memo_round": 3,
+     "disputed_item": "置信度降级",
+     "reason": "审查AI忽略了我引用的官方文档数据",
+     "evidence": ["引用来源URL"]
+   }
+   ```
+3. 审查AI进入元审查流程：
+   a. 自我审视：重新评估原始裁定，检查是否有遗漏或误判
+   b. 交叉验证：若涉及事实性争议，触发搜索子阶段获取外部证据
+   c. 裁定：维持原判 / 修正裁定 / 提请其他专家评议
+4. 元审查裁定为最终裁定，不可再次上诉（防止无限递归）
+5. 所有上诉记录记入阶段备忘录
+
+## 元审查流程（对内 + 对外）
+
+### 对内元审查（处理上诉）
+- **触发**：专家提起上诉
+- **执行者**：当前分支的审查AI
+- **流程**：自我审视 → 交叉验证 → 裁定
+- **输出**：上诉裁定书（合并入备忘录）
+
+### 对外元审查（Merge阶段）
+- **触发**：所有分支结束或终止
+- **执行者**：总审查AI（Meta-Auditor），独立于各分支审查AI
+- **升级判断**：当分支数 ≥ 2 时，主审查AI自动升级为元审查AI
+- **流程**：收集各分支最终报告 → 生成对比表 → 检测融合可行性 → 输出推荐排序
+
+**注意**：元审查AI可与审查AI复用同一实例，但Merge阶段必须以"元审查模式"运行
+
+## 异常分类与处理矩阵
+
+| 异常类型 | 检测方式 | 严重度 | 自动处理策略 | 人工介入条件 |
+|---------|---------|--------|-------------|-------------|
+| 专家实例超时 | 发言限时到期 | 低 | 标记弃权，维持上次立场 | 连续3轮超时 |
+| 审查AI超时 | 审核限时到期 | 中 | 该轮置信度整体降1级 | 连续2轮超时 |
+| 专家实例崩溃 | 连接丢失/异常退出 | 高 | 重启实例+注入最近快照 | 重启失败 |
+| 分支管理器崩溃 | 分叉/合并操作失败 | 致命 | 终止分叉，回退到线性模式 | 任何情况 |
+| 死锁 | 连续3轮无进展 | 高 | 执行熔断策略 | 熔断后仍需决策 |
+| 回音室效应 | 共识度过高且持续2轮 | 中 | 强制引入魔鬼代言人 | 无 |
+| 搜索超时 | 研究专家30秒无响应 | 低 | 记录"搜索未完成"，继续流程 | 连续3次超时 |
+| 上下文溢出 | token使用超过80%阈值 | 高 | 压缩历史备忘录，摘要化旧轮次 | 无法压缩至安全线 |
+| JSON解析错误 | 消息格式不合法 | 中 | 请求重发，最多3次重试 | 3次重试后仍失败 |
+
+## 实例健康监控
+
+主持人每轮开始前执行健康检查：
+1. **心跳检测**：向所有活跃实例发送 ping，2秒内未响应标记为"疑似异常"
+2. **内存/Token 检测**：查询各实例上下文使用率，超过80%触发上下文压缩
+3. **响应质量检测**：若某专家连续2轮仅返回模板化/无实质内容，标记为"低参与度"
+4. **健康报告**：主持人维护一个健康状态表，记录每个实例的状态和异常次数
+
+**健康状态表结构**：
+
+| 实例ID | 角色 | 状态 | 异常次数 | 上次活跃时间 | Token使用率 |
+|--------|------|------|---------|-------------|------------|
+| inst_01 | 主持人 | 正常 | 0 | 2026-05-13 10:30 | 45% |
+| inst_02 | 审查AI | 正常 | 0 | 2026-05-13 10:30 | 52% |
+| ...    | ...  | ...  | ...     | ...         | ...        |
+
+## 随机新专家调入流程
+
+1. 候选人池来源：预定义的"备用专家角色列表"（在阶段1与用户共同确定）
+2. 调入步骤：
+   a. 从候选人池中随机抽取1-2名未参与当前研讨的专家角色
+   b. 注入当前上下文快照（问题陈述 + 最近3轮备忘录 + 当前共识仓库）
+   c. 新专家在首轮发言中完成偏见声明和初始立场（跳过阶段2对齐）
+   d. 新专家首轮发言不参与该轮的置信度均值计算（视为"预热轮"）
+3. 若候选人池已耗尽，则触发"研讨终止"并向用户报告
+
+## 分支内死锁处理与主线程差异
+
+- 分支内的死锁熔断首先执行魔鬼代言人介入（同主线程）
+- 若魔鬼代言人介入无效（再1轮后仍死锁），该分支标记为"死锁终止"
+- 死锁终止的分支不丢弃，生成《分歧终止报告》后冻结，等待Merge阶段与其他分支对比
+- 分支内的备忘录独立存储，Merge时作为该分支的审计追踪一并提交
+
+## 断点续存（上下文快照、状态转储）
+
+### 上下文快照
+
+```json
+{
+  "snapshot_id": "uuid",
+  "created_at": "ISO 8601",
+  "branch_id": "main",
+  "round": 3,
+  "question": "原始问题陈述",
+  "consensus_warehouse": [
+    {"issue": "已达成的共识议题", "score": 4.8, "supporters": ["A", "B", "C"]}
+  ],
+  "expert_states": [
+    {
+      "expert_id": "Expert_A",
+      "last_stance": "最近立场摘要",
+      "confidence_history": [13.2, 14.1, 13.8],
+      "bias_self_history": [3, 3, 2],
+      "status": "active"
+    }
+  ],
+  "recent_memos": ["备忘录#1", "备忘录#2", "备忘录#3"],
+  "fork_context": {
+    "fork_point_round": 3,
+    "direction_a": "方向A描述",
+    "direction_b": "方向B描述"
+  },
+  "health_status": {
+    "deadlock_risk": 3,
+    "echo_chamber_risk": 1,
+    "total_exceptions": 0
+  }
+}
+```
+
+### 状态转储命令定义
+
+- **命令格式**：`主持人::dump_state(target: "all" | "round" | "experts")`
+- **输出**：当前全量记忆的 JSON 块（等同于上下文快照 + 所有历史备忘录）
+- **用途**：实例崩溃恢复、人工审计、跨会话继承
+- **与上下文快照的关系**：状态转储是完整导出，上下文快照是分叉/熔断时的精简切片
+
+### 共识仓库定义
+
+```json
+{
+  "consensus_items": [
+    {
+      "id": "C-001",
+      "issue": "议题描述",
+      "achieved_in_round": 2,
+      "consensus_score": 4.8,
+      "agreed_by": ["Expert_A", "Expert_B", "Expert_C"],
+      "content": "具体共识内容（≤100字）",
+      "immutable": true
+    }
+  ]
+}
+```
+
+- **特性**：一旦进入共识仓库，后续轮次不可推翻（immutable=true）
+- **例外**：审查AI发现共识基于错误事实，可标记为"存疑"并重新开放讨论
+
+## 融合方案冲突检测
+
+1. 元审查AI提取各分支的"最高置信度组件"（每个分支置信度最高的子结论）
+2. 逐对检测：
+   - 语义冲突：两个组件在语义上互斥（如"采用微服务" vs "采用单体"）
+   - 依赖冲突：组件A依赖的技术栈与组件B不兼容
+   - 资源冲突：两个组件合并后所需资源超过约束
+3. 冲突裁决规则：
+   | 冲突类型 | 裁决规则 |
+   |---------|---------|
+   | 互斥语义 | 取置信度更高者，放弃低者 |
+   | 技术依赖冲突 | 搜索子阶段评估兼容性，产出适配方案 |
+   | 资源冲突 | 降级低置信度组件为"可选"，优先保证高置信度 |
+4. 若冲突无法裁决，标记为"待用户决策"并附冲突说明

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

@@ -0,0 +1,71 @@
+# 角色体系
+
+## 固定角色
+
+### 主持人（Facilitator）
+- **职责**：
+  - 控制流程节奏，宣布进入新阶段，传递发言权，调用分支管理器
+  - 流程健康监控：超时控制、死锁检测、异常实例重启调度
+  - 响应用户"对输出再讨论"等指令，触发二次研讨
+
+### 审查/元审查 AI（Auditor / Meta-Auditor）
+- **职责**：
+  - 每轮发言后进行置信度审核、事实核查、逻辑校验
+  - 执行上诉与异议裁决，生成阶段备忘录
+  - 在多分支合并时，升级为元审查AI，横向比对分支结果
+  - 可指定魔鬼代言人，检测回音室效应
+  - 辅助主持人检测死锁（提供连续轮次僵持度评分）
+- **AI实例**：1 个，与主持人常驻。分支内部有各自的审查AI副本
+
+### 分支管理 AI（Fork Manager）
+- **职责**：监控分叉条件，创建/销毁分支，打包分叉上下文，调度分支并行运行
+- **AI实例**：可与审查AI复用同一实例，但需明确角色切换
+
+### 分支审查AI副本与主审查AI差异
+- **创建方式**：分叉时克隆主审查AI的判定规则和当前状态
+- **权限范围**：仅能审核本分支内的专家发言，不能跨分支引用
+- **与主审查AI的关系**：
+  - 分叉期间：完全独立，各自生成本分支备忘录
+  - Merge阶段：主审查AI升级为元审查AI，收集各分支审查AI的最终备忘录
+  - 冲突场景：若分支审查AI的裁定与元审查AI的比对结果矛盾，以元审查AI为准
+
+### 魔鬼代言人（Devil's Advocate）
+- **来源**：由现有专家临时担任（审查AI指定），非独立实例
+- **触发条件**：
+  1. 回音室效应检测触发
+  2. 死锁熔断策略要求
+  3. 审查AI主动指定（预防性介入）
+- **职责**：
+  - 对本轮达成的高共识议题提出系统性反驳（至少1个反方论证）
+  - 反方论证必须附带置信度评分和外部验证（如可搜索）
+  - 不可反驳自己的原始立场（避免角色混淆）
+- **任期**：默认1轮，可经审查AI评估后延长1轮
+- **解除条件**：任期结束 / 审查AI判定回音室风险解除 / 分歧强度回升至>1.0
+- **输出规范**：发言前标注"[魔鬼代言人模式]"，与原专家身份明确区分
+- **评分要求**：反方论证的评分独立进行，不与原专家评分混合
+
+## 动态专家角色
+
+- 根据问题领域动态定义（例如：战略顾问、技术架构师、风险分析师、用户研究员、伦理学家等）
+- 每位专家需在首次发言时进行**初始偏见声明**，声明自己的核心预设与潜在认知偏差
+- 每轮发言必须附带：
+  - 观点陈述
+  - 各维度量化评分（来源可靠性1-5，逻辑一致性1-5，数据可验证性1-5）
+  - 综合置信度标签（高/中/低/存疑）
+  - 潜在偏见影响自评（0-5）
+
+## 搜索/研究专家（Research Agent）
+- **职责**：
+  - 在研讨过程中，根据专家的信息需求或审查AI的核查指令，执行外部信息检索
+  - 支持检索范围：Web搜索、代码库搜索、文档查询、Context7库文档查询
+  - 每次检索返回结构化结果，附带来源URL、提取时间、可信度预标注
+- **触发条件**：
+  1. 专家发言中标注"需要事实核查"且审查AI确认需要外部验证
+  2. 专家置信度评分中出现"来源可靠性 ≤ 2"时，自动触发补充检索
+  3. 用户显式指令"搜索一下XX"
+  4. 审查AI发现专家间存在事实性分歧且无法通过内部推理解决
+- **输出规范**：
+  - 搜索结果摘要（≤200字）
+  - 引用来源列表（URL + 标题 + 摘要）
+  - 时效性标注（发布时间 vs 当前日期）
+  - 可信度预标注（高/中/低/存疑）

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

@@ -0,0 +1,31 @@
+# Schema 汇总清单
+
+## Schema 索引表
+
+| Schema | 名称 | 定义位置 | 用途简介 |
+|--------|------|---------|---------|
+| S1 | 阶段备忘录 | templates/reports.md | 记录每轮研讨的摘要、专家立场、共识、分歧、健康指标等 |
+| S2 | 证据链 | templates/reports.md | 记录决策过程的完整追溯链，支持多层嵌套引用 |
+| S3 | 上下文快照 | references/mechanisms.md | 分叉或熔断时保存的精简状态，用于断点续存 |
+| S4 | 状态转储 | references/mechanisms.md | 完整导出当前全量记忆，用于崩溃恢复、审计、跨会话继承 |
+| S5 | 专家状态 | references/mechanisms.md (包含于S3) | 记录专家的历史立场、置信度、偏见自评等 |
+| S6 | 偏见声明 | templates/reports.md | 专家首次发言时声明的核心假设、认知偏差、领域经验等 |
+| S7 | 共识仓库 | references/mechanisms.md | 存储已达成共识的议题集合，支持不可变性保证 |
+| S8 | 最终方案报告 | templates/reports.md | 分支结束时生成的完整方案报告，包含置信度、风险、备选方案等 |
+| S9 | 分歧终止报告 | templates/reports.md | 研讨因死锁、超时、用户终止等原因结束时的报告 |
+| S10 | 分叉包 | templates/reports.md (见分叉管理API) | 用于创建新分支的上下文打包格式 |
+| S11 | 二级决策链 | templates/reports.md | 二次研讨时生成的嵌套决策链，支持跨层引用 |
+
+## 快速查找指南
+
+### 需要生成报告模板？
+→ 查看 templates/reports.md，包含所有报告模板
+
+### 需要了解角色和流程机制？
+→ 查看 references/roles.md 和 references/mechanisms.md
+
+### 需要评分公式和置信度计算？
+→ 查看 references/scoring.md
+
+### 需要查看所有 JSON 格式定义？
+→ 所有 JSON Schema 已在 templates/reports.md 中完整定义

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

@@ -0,0 +1,65 @@
+# 置信度与量化评分体系
+
+## 评分维度表
+
+| 维度 | 说明 | 评分范围 |
+|------|------|----------|
+| 来源可靠性 | 信息出处权威性、可复现性 | 1（匿名不可验证）- 5（权威期刊/官方数据） |
+| 逻辑一致性 | 论证内部无自相矛盾，推理链完整 | 1-5 |
+| 数据可验证性 | 是否提供可检查的证据、引用或复现路径 | 1-5 |
+| 外部验证支持度 | 是否有搜索结果佐证或反驳该观点 | 1-5 |
+| 共识度 | （仅审查AI使用）多位专家观点的趋同程度 | 1-5 |
+
+## 置信度标签判定规则
+
+**最终置信度标签**由审查AI根据加权总分自动判定：
+- 综合分≥13 → 高
+- 9-12 → 中
+- 5-8 → 低
+- <5 → 存疑
+
+## 低置信度处理图谱
+
+- **存疑内容**：标记为"假设性参考"，仅供灵感，不做决策依据
+- **过时信息**：标记"时效性存疑"，触发联网搜索或知识更新建议
+- **事实错误**：审查AI直接删除，并要求专家修正论述
+- **推理漏洞**：打回专家，附审查AI质询，要求重新推理
+- **无外部验证内容**：标记"孤证待验证"，建议触发搜索子阶段补充证据
+
+## 专家权重分配机制
+
+- **初始权重**：所有专家默认权重 = 1.0
+- **权重调整因素**：
+  | 因素 | 调整幅度 | 触发条件 |
+  |------|---------|---------|
+  | 高持续置信度 | +0.1/轮 | 连续3轮综合置信度 ≥ 13 |
+  | 外部验证贡献 | +0.05/次 | 提出观点被搜索验证为正确 |
+  | 连续超时 | -0.2/次 | 连续2轮超时弃权 |
+  | 事实错误 | -0.3/次 | 审查AI裁定发言存在事实错误 |
+  | 低参与度 | -0.1/次 | 连续2轮标记为低参与度 |
+- **权重用途**：
+  - 共识度计算时，高权重专家的评分加权
+  - 最终推荐排序时，高权重专家的方案获得更高优先级
+- **权重上限**：2.0，下限：0.1（保留最低发言权）
+
+## 共识度/分歧强度/死锁指标计算公式
+
+### 进展指标精确定义
+
+1. **新共识项数**：本轮结束后，满足以下条件的议题数：
+   - 所有专家在该议题上的评分标准差 ≤ 1.0，且
+   - 该议题在本轮前未被标记为共识项
+
+2. **分歧强度（D）**：
+   D = Σ(所有议题 × 该议题专家评分的标准差 × 该议题的权重)
+   其中议题权重由审查AI根据其对最终决策的影响程度评定（1-3）
+
+3. **总置信度均值（C_avg）**：
+   C_avg = Σ(每位专家综合置信度分值) / 专家数
+
+### 死锁判定（修订版）
+
+连续 3 轮同时满足：
+- 新共识项数 = 0
+- 分歧强度 D 未下降（D_n ≥ D_{n-1} × 0.95）
+- |C_avg_n - C_avg_{n-1}| ≤ 0.3

package/.claude/skills/multi-expert-discussion/templates/reports.md

@@ -0,0 +1,272 @@
+# 模板与输出规范
+
+## 偏见声明 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": "无",
+    "last_updated": "ISO 8601"
+  }
+}
+```
+
+## 阶段备忘录标准模板
+
+---
+**阶段备忘录 #N** | 分支：[分支ID] | 轮次：[N] | 时间戳：[ISO 8601]
+
+### 1. 本轮摘要
+- 参与专家：[名单]
+- 弃权/超时专家：[名单]
+- 新增搜索执行情况：[检索次数/完成数/超时数]
+- 审查AI审核状态：[完成/超时/未完成]
+
+### 2. 各专家立场总结
+
+| 专家 | 核心观点（≤50字） | 综合置信度 | 偏见自评 | 状态 |
+|------|-------------------|-----------|---------|------|
+| ...  | ...               | ...       | ...     | 正常/弃权/超时 |
+
+### 3. 共识项（本轮新增）
+| # | 议题描述 | 共识度 | 支撑专家 |
+|---|---------|--------|---------|
+| 1 | ...     | 4.8    | A, B, C |
+
+### 4. 分歧项（持续未解决）
+| # | 议题描述 | 分歧强度 | 正反方 | 僵持轮次 |
+|---|---------|---------|--------|---------|
+| 1 | ...     | 2.3     | A vs B | 3        |
+
+### 5. 审查AI裁定与质询
+- 低置信度内容处理：[条数 / 处理方式]
+- 回音室效应检测：[是/否触发] [触发时：魔鬼代言人指定情况]
+- 上诉记录：[条数] [裁定结果摘要]
+- 待下一轮解决的信息缺口：[列表]
+
+### 6. 流程健康指标
+| 指标 | 本轮值 | 变化趋势 |
+|------|--------|---------|
+| 新共识项数 | X | - |
+| 分歧强度 | Y.Y | ↑/↓/- |
+| 总置信度均值 | Z.Z | ↑/↓/- |
+| 死锁风险评分 | 0-10 | - |
+
+### 7. 下一轮建议
+- 建议聚焦议题：[列表]
+- 建议触发搜索：[是/否] [主题列表]
+- 建议分叉方向：[如有]
+---
+
+## 分歧终止报告 JSON 模板
+
+```json
+{
+  "report_type": "分歧终止报告",
+  "generated_at": "ISO 8601",
+  "termination_reason": "死锁熔断 / 用户终止 / 资源耗尽",
+  "total_rounds_executed": 7,
+  "deadlock_indicators": {
+    "consecutive_no_consensus_rounds": 3,
+    "final_divergence_intensity": 2.8,
+    "final_confidence_mean": 10.3,
+    "confidence_mean_variance_last_3": 0.2
+  },
+  "irreconcilable_positions": [
+    {
+      "issue": "不可调和议题描述",
+      "position_a": {"expert": "A", "stance": "立场", "confidence": 13.2},
+      "position_b": {"expert": "B", "stance": "立场", "confidence": 13.5},
+      "deadlock_rounds": 4
+    }
+  ],
+  "interventions_attempted": [
+    {"type": "魔鬼代言人引入", "round": 5, "effect": "无显著变化"},
+    {"type": "随机专家调入", "round": 6, "effect": "无显著变化"}
+  ],
+  "deliverables": {
+    "partial_consensus": ["已达成共识项列表"],
+    "decision_tree_for_user": "需要用户决策的事项清单"
+  },
+  "recommendation": "建议用户基于以上分歧点做出决策，或重新定义问题边界后重启研讨"
+}
+```
+
+## 最终方案报告 JSON 模板
+
+```json
+{
+  "branch_id": "Alpha",
+  "report_title": "分支 Alpha 最终方案报告",
+  "generated_at": "ISO 8601",
+  "total_rounds": 5,
+  "final_conclusion": {
+    "recommended_solution": "方案描述（≤200字）",
+    "confidence": {
+      "overall_score": 14.2,
+      "label": "高",
+      "dimensions": {
+        "source_reliability": 4.5,
+        "logic_consistency": 4.8,
+        "data_verifiability": 4.1,
+        "external_validation": 4.0
+      }
+    },
+    "key_strengths": ["优势1", "优势2"],
+    "fatal_weaknesses": ["致命弱点（如有）"],
+    "resource_feasibility": "高/中/低",
+    "implementation_risks": [
+      {"risk": "风险描述", "probability": "高/中/低", "impact": "高/中/低", "mitigation": "缓解措施"}
+    ]
+  },
+  "alternative_options": [
+    {"rank": 2, "description": "备选方案", "confidence_score": 11.8, "reason_for_lower_rank": "原因"}
+  ],
+  "evidence_chain": {}
+}
+```
+
+## 证据链 JSON 模板
+
+```json
+{
+  "decision_chain": {
+    "root_question": "原始问题陈述",
+    "version": "1.0",
+    "created_at": "ISO 8601",
+    "layers": [
+      {
+        "layer": 1,
+        "phase": "初始研讨",
+        "memos": ["备忘录#1", "备忘录#2", "..."],
+        "consensus_items": ["共识项1", "共识项2"],
+        "fork_points": [
+          {
+            "fork_id": "F1",
+            "reason": "高置信度互斥方向",
+            "branches": ["Alpha", "Beta"]
+          }
+        ],
+        "final_conclusion": "该层结论摘要"
+      },
+      {
+        "layer": 2,
+        "phase": "二次研讨（针对结论X）",
+        "parent_chain_ref": "layer_1.conclusion_X",
+        "memos": ["二级备忘录#1", "..."],
+        "consensus_items": ["二级共识项1"],
+        "final_conclusion": "二级结论摘要"
+      }
+    ]
+  }
+}
+```
+
+二次研讨时，可引用上一轮证据链，形成多级引用。
+
+## 二级决策链 JSON 模板
+
+```json
+{
+  "decision_chain": {
+    "layers": [
+      {
+        "layer": 1,
+        "chain_id": "primary-uuid",
+        "...": "..."
+      },
+      {
+        "layer": 2,
+        "chain_id": "secondary-uuid",
+        "parent_layer": 1,
+        "parent_conclusion_ref": "layer_1.conclusion_risk_Y",
+        "trigger": "用户指令：对风险Y深入分析",
+        "...": "..."
+      }
+    ]
+  }
+}
+```
+
+**引用格式**：`{chain_id}::{node_path}`，例如 `primary-uuid::layer_1.consensus_items[0]`
+
+## 输出目录模板
+
+```markdown
+# [研讨主题] —— 多专家研讨最终报告
+
+## 📑 目录
+1. [执行摘要](#1-执行摘要)
+2. [问题定义与研讨范围](#2-问题定义与研讨范围)
+3. [专家团队与偏见声明](#3-专家团队与偏见声明)
+4. [研讨过程总览](#4-研讨过程总览)
+   - 4.1 [研讨轮次与分支概览](#41-研讨轮次与分支概览)
+   - 4.2 [搜索执行统计](#42-搜索执行统计)
+   - 4.3 [流程健康报告](#43-流程健康报告)
+5. [多分支决策对比](#5-多分支决策对比)
+6. [最终推荐方案](#6-最终推荐方案)
+7. [风险评估与缓解](#7-风险评估与缓解)
+8. [共识项与分歧项](#8-共识项与分歧项)
+9. [决策可追溯链](#9-决策可追溯链)
+10. [附录：全量阶段备忘录](#10-附录全量阶段备忘录)
+
+---
+```
+
+**使用说明**：按此顺序输出内容，并为每个标题设置对应的锚点ID。同时，在每节末尾嵌入"[↑ 返回目录](#-目录)"链接。
+
+## 消息传递 JSON 格式
+
+```json
+{
+  "message_id": "uuid",
+  "timestamp": "ISO 8601",
+  "from": "Expert_A",
+  "from_instance": "inst_01",
+  "to": "Auditor",
+  "branch_id": "main",
+  "round": 2,
+  "reply_to": "message_id_of_previous",
+  "content": "发言正文...",
+  "confidence": {
+    "source": 4,
+    "logic": 4,
+    "verif": 3,
+    "external_validation": 2,
+    "label": "中"
+  },
+  "bias_self": 3,
+  "flags": ["需要外部验证", "需要魔鬼代言人审视"],
+  "search_citations": ["url1", "url2"]
+}
+```
+
+## 分叉管理 API
+
+```
+fork(options: {
+  branch_count: 2,           // 分支数量
+  directions: ["方向A", "方向B"],  // 各分支探索方向描述
+  inherit_rounds: 3,         // 继承前N轮上下文
+  max_rounds_per_branch: 5   // 每分支最大轮次
+}) -> { branch_ids: ["alpha", "beta"] }
+
+merge(options: {
+  branch_ids: ["alpha", "beta"],  // 参与合并的分支
+  strategy: "best_confidence" | "complementary" | "user_choice"
+}) -> { final_report }
+
+destroy_branch(branch_id: "alpha")  // 仅分支管理AI可调用
+```

package/bin.js

@@ -6,7 +6,7 @@ const fs = require('fs');
 const path = require('path');
 
 const SDD = {
-  version: '5.1.6',
+  version: '5.1.7',
   name: 'sdd-full',
   description: '完整的软件设计开发技能包'
 };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "sdd-full",
-  "version": "5.1.6",
+  "version": "5.1.7",
   "description": "SDD Full - 完整的软件设计开发技能包",
   "main": "index.js",
   "bin": "./bin.js",