sdd-full 5.2.0 → 5.2.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -8,15 +8,17 @@
8
8
  - 模糊/开放式的技术或产品需求
9
9
 
10
10
  2. 加载 `multi-expert-discussion` 技能,执行核心流程:
11
- - 阶段 1:问题定义与专家招募
12
- - 阶段 2:初始立场与信息对齐
13
- - 阶段 3:圆桌自由研讨(支持搜索子阶段、专家辩论)
14
- - 阶段 3.5:多分支并行探索(Fork,可选)
15
- - 阶段 3.6:分支结果对比与融合(Merge,可选)
16
- - 阶段 4:对输出的二次研讨(迭代深化,可选)
11
+ - 阶段 0:问题类型路由 → 加载对应 YAML 工作流(收敛型含分层前置文档调研)
12
+ - 阶段 1:问题定义与专家招募(含偏见声明)
13
+ - 阶段 2:初始立场与信息对齐(含置信度评分、分叉点识别)
14
+ - 阶段 3:圆桌自由研讨(含搜索子阶段、回音室检测、死锁检测)
15
+ - 阶段 4:多分支并行探索(Fork,可选)
16
+ - 阶段 5:分支结果对比与融合(Merge,可选)
17
+ - 阶段 6:对输出的二次研讨(迭代深化,可选)
17
18
  3. 输出结果:
18
- - docs/{讨论关键字}/progressprogress/ - 中途落地文档(每轮研讨快照、阶段备忘录)
19
+ - docs/{讨论关键字}/progress/ - 中途落地文档(每轮研讨快照、阶段备忘录)
19
20
  - docs/{讨论关键字}/solutions/ - 最终方案(solution_mvp.md、solution_standard.md、solution_pro.md,包含决策可追溯链)
21
+ - 静默模式(用户声名):仅输出最终方案,无 progress 中间过程
20
22
  4. 支持的子命令:
21
23
  - /continue - 接续之前的研讨(使用状态转储恢复)
22
24
  - /new - 新建研讨
@@ -35,22 +37,30 @@
35
37
  .multi-expert-discussion/
36
38
  ├── SKILL.md (核心编排流程)
37
39
  ├── references/
38
- │ ├── roles.md # 角色体系定义
39
- │ ├── scoring.md # 评分体系
40
- │ ├── mechanisms.md # 流程机制详解
41
- └── schemas.md # Schema 汇总
40
+ │ ├── roles.md # 角色体系定义
41
+ │ ├── scoring.md # 评分体系(4维20分制+权重衰减)
42
+ │ ├── mechanisms.md # 流程机制详解(原子原语库+强制快照+用户干预+共识修订)
43
+ ├── workflow-engine.md # 流程引擎(YAML编排、预设模板、自定义流程)
44
+ │ ├── problem-routing.md # 问题类型路由(收敛/发散/探索/混合)
45
+ │ └── schemas.md # Schema 汇总
42
46
  └── templates/
43
- └── reports.md # 所有模板和输出规范
47
+ └── reports.md # 所有模板和输出规范
44
48
  ```
45
49
 
46
50
  ## 关键特性
47
51
 
48
- - ✅ 置信度评估体系(来源可靠性、逻辑一致性、数据可验证性、外部验证支持度)
49
- - ✅ 多分支并行探索(Fork/Merge 机制)
50
- - ✅ 死锁检测与熔断机制
52
+ - ✅ 置信度评估体系(4维20分制:来源可靠性、逻辑一致性、数据可验证性、外部验证支持度)
53
+ - ✅ 多分支并行探索(Fork/Merge 机制,含收敛vs死锁边界判定)
54
+ - ✅ 死锁检测与熔断机制(连续3轮无进展+魔鬼代言人介入)
55
+ - ✅ 回音室假收敛检测与升级处理
51
56
  - ✅ 搜索子阶段(支持 Web 搜索、代码库搜索、文档查询)
52
57
  - ✅ 魔鬼代言人机制(防止回音室效应)
53
- - ✅ 上诉与异议裁决流程
58
+ - ✅ 上诉与异议裁决流程(含元审查最终裁定)
54
59
  - ✅ 决策可追溯链(支持多层嵌套引用)
55
- - ✅ 完整的韧性机制(超时处理、异常恢复、健康监控)
60
+ - ✅ 完整的韧性机制(超时处理、异常恢复、健康监控、断点续存)
61
+ - ✅ 原子原语库(8个可复用原语:ask_experts/audit_round/audit_documentation/generate_memo/generate_micro_memo/fork_branch/merge_branches/output_template)
62
+ - ✅ 用户干预机制(强制介入/优雅暂停/状态保持)
63
+ - ✅ 强制快照(共识达成/重大决策时自动生成微型备忘录)
64
+ - ✅ 静默模式(无中间过程输出,仅最终完整报告)
65
+ - ✅ 流程引擎(YAML 工作流编排,支持收敛/发散/探索/混合四类预设流程+自定义流程)
56
66
 
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  name: multi-expert-discussion
3
3
  description: >
4
- 通过模拟多学科专家团队对复杂问题进行结构化研讨。具备置信度评估、多分支并行探索、死锁检测熔断、搜索验证、决策可追溯链。当用户需要多角度分析复杂问题、方案评审、技术选型决策、风险评估时使用。用户也可直接使用 /multi-expert-discussion 触发。
4
+ Use when users need multi-perspective analysis of complex problems, technical solution reviews, technology selection decisions, or risk assessments that benefit from structured multi-expert discussion. Also use when users directly invoke /multi-expert-discussion. Triggers include: 360-degree evaluation needed, multiple viable approaches with trade-offs, or systematic exploration of unfamiliar domains.
5
5
  disable-model-invocation: false
6
6
  ---
7
7
 
@@ -147,7 +147,7 @@ disable-model-invocation: false
147
147
 
148
148
  - **超时策略**:专家发言60秒、审查AI审核30秒、备忘录生成20秒(详见 references/mechanisms.md)
149
149
  - **死锁检测与熔断**:连续3轮无进展触发,强制引入魔鬼代言人或随机调入新专家(详见 references/mechanisms.md)
150
- - **异常分类与处理矩阵**:9种异常类型的自动化处理策略(详见 references/mechanisms.md)
150
+ - **异常分类与处理矩阵**:10种异常类型的自动化处理策略(详见 references/mechanisms.md)
151
151
  - **实例健康监控**:心跳检测、内存/Token检测、响应质量检测(详见 references/mechanisms.md)
152
152
  - **分支内死锁处理**:与主线程略有差异(详见 references/mechanisms.md)
153
153
  - **断点续存**:上下文快照和状态转储(详见 references/mechanisms.md)
@@ -217,6 +217,7 @@ disable-model-invocation: false
217
217
  | 路由准确性-探索 | 提探索型问题("什么是量子计算") | 自动加载探索型流程,构建知识图谱 |
218
218
  | 交叉污染 | 用收敛型流程处理发散型问题 | 流程表现出不适配症状或自适应调整 |
219
219
  | 末位淘汰 | 修改某类型流程的产出模板,在另一类型任务上跑 | 修改不传染到其他类型 |
220
+ | 路由准确性-混合型 | 提混合型诉求("评估Flutter可行性并学习其架构") | 自动加载先探索后收敛的两阶段流程 |
220
221
 
221
222
  ### 3. 交互与边界压力测试
222
223
 
@@ -14,8 +14,6 @@
14
14
  - 执行上诉与异议裁决,生成阶段备忘录
15
15
  - 在多分支合并时,升级为元审查AI,横向比对分支结果
16
16
  - 可指定魔鬼代言人,检测回音室效应
17
- - 魔鬼代言人指派:共识度过高时指定专家提出反面论点
18
- - 落地完整性审计:检查阶段输出物是否生成、决策是否写入文档、决策链是否可追溯
19
17
  - 辅助主持人检测死锁(提供连续轮次僵持度评分)
20
18
  - **AI实例**:1 个,与主持人常驻。分支内部有各自的审查AI副本
21
19
 
@@ -34,7 +32,7 @@
34
32
  ### 魔鬼代言人(Devil's Advocate)
35
33
  - **来源**:由现有专家临时担任(审查AI指定),非独立实例
36
34
  - **触发条件**:
37
- 1. 回音室效应检测触发
35
+ 1. 回音室效应检测触发(或审查AI主动指派,当共识度过高时)
38
36
  2. 死锁熔断策略要求
39
37
  3. 审查AI主动指定(预防性介入)
40
38
  - **职责**:
@@ -52,7 +50,7 @@
52
50
  - 每位专家需在首次发言时进行**初始偏见声明**,声明自己的核心预设与潜在认知偏差
53
51
  - 每轮发言必须附带:
54
52
  - 观点陈述
55
- - 各维度量化评分(来源可靠性1-5,逻辑一致性1-5,数据可验证性1-5)
53
+ - 各维度量化评分(来源可靠性1-5,逻辑一致性1-5,数据可验证性1-5,外部验证支持度1-5
56
54
  - 综合置信度标签(高/中/低/存疑)
57
55
  - 潜在偏见影响自评(0-5)
58
56
 
@@ -32,7 +32,7 @@
32
32
  - **权重调整因素**:
33
33
  | 因素 | 调整幅度 | 触发条件 |
34
34
  |------|---------|---------|
35
- | 高持续置信度 | +0.1/轮 | 连续3轮综合置信度 ≥ 13 |
35
+ | 高持续置信度 | +0.1/轮 | 连续3轮综合置信度 ≥ 17 |
36
36
  | 外部验证贡献 | +0.05/次 | 提出观点被搜索验证为正确 |
37
37
  | 连续超时 | -0.2/次 | 连续2轮超时弃权 |
38
38
  | 事实错误 | -0.3/次 | 审查AI裁定发言存在事实错误 |
@@ -42,6 +42,19 @@
42
42
  - 最终推荐排序时,高权重专家的方案获得更高优先级
43
43
  - **权重上限**:2.0,下限:0.1(保留最低发言权)
44
44
 
45
+ ### 权重增长控制与衰减机制
46
+
47
+ 为防止少数高权重专家形成寡头垄断,实施以下控制策略:
48
+
49
+ - **对数增长**:接近上限时权重增长幅度递减
50
+ - 当权重 ≥ 1.5 时,增长因子为原值的 50%(如 +0.1 → +0.05)
51
+ - 当权重 ≥ 1.8 时,增长因子为原值的 25%(如 +0.1 → +0.025)
52
+ - **硬封顶**:权重上限严格限制为 2.0,不可突破
53
+ - **衰减机制**:专家连续无贡献时权重缓慢衰减
54
+ - 连续 3 轮无显著贡献(未提出新观点、未参与有效辩论),权重 -0.1/轮
55
+ - 连续 5 轮无贡献,权重降至 1.0 基准线
56
+ - **重置下限**:衰减至 0.1 后,若该专家恢复活跃贡献,权重按 0.5/轮恢复,最多恢复至 1.0
57
+
45
58
  ## 共识度/分歧强度/死锁指标计算公式
46
59
 
47
60
  ### 进展指标精确定义
@@ -55,7 +68,8 @@
55
68
  其中议题权重由审查AI根据其对最终决策的影响程度评定(1-3)
56
69
 
57
70
  3. **总置信度均值(C_avg)**:
58
- C_avg = Σ(每位专家综合置信度分值) / 专家数
71
+ C_avg = Σ(每位专家综合置信度分值 × 专家权重) / Σ(专家权重)
72
+ 注:使用加权均值而非简单平均,确保高权重专家对判定结果有更大影响
59
73
 
60
74
  ### 死锁判定(修订版)
61
75
 
@@ -63,3 +77,5 @@
63
77
  - 新共识项数 = 0
64
78
  - 分歧强度 D 未下降(D_n ≥ D_{n-1} × 0.95)
65
79
  - |C_avg_n - C_avg_{n-1}| ≤ 0.3
80
+
81
+ **权重参与说明**:上述判定中的「分歧强度 D」计算已隐含专家权重影响(权重加权标准差),「总置信度均值 C_avg」使用加权均值(按专家权重加权),确保高权重专家对判定结果有更大影响。
@@ -116,7 +116,7 @@
116
116
  "recommended_solution": "方案描述(≤200字)",
117
117
  "confidence": {
118
118
  "overall_score": 14.2,
119
- "label": "",
119
+ "label": "",
120
120
  "dimensions": {
121
121
  "source_reliability": 4.5,
122
122
  "logic_consistency": 4.8,
@@ -134,54 +134,11 @@
134
134
  "alternative_options": [
135
135
  {"rank": 2, "description": "备选方案", "confidence_score": 11.8, "reason_for_lower_rank": "原因"}
136
136
  ],
137
- "evidence_chain": {}
138
- }
139
- ```
140
-
141
- ## 单分支最终方案报告 JSON 模板(无分叉场景)
142
-
143
- 当研讨未触发分叉操作时(仅单分支运行),使用以下模板替代多分支方案报告:
144
-
145
- ```json
146
- {
147
- "report_type": "单分支最终方案报告",
148
- "branch_id": "main",
149
- "generated_at": "ISO 8601",
150
- "total_rounds": 5,
151
- "session_type": "single_branch",
152
- "final_conclusion": {
153
- "recommended_solution": "方案描述(≤200字)",
154
- "confidence": {
155
- "overall_score": 14.2,
156
- "label": "高",
157
- "dimensions": {
158
- "source_reliability": 4.5,
159
- "logic_consistency": 4.8,
160
- "data_verifiability": 4.1,
161
- "external_validation": 4.0
162
- }
163
- },
164
- "key_strengths": ["优势1", "优势2"],
165
- "fatal_weaknesses": ["致命弱点(如有)"],
166
- "resolution_path": "收敛型结束 / 轮次结束 / 死锁熔断(见分歧终止报告)",
167
- "resource_feasibility": "高/中/低",
168
- "implementation_risks": [
169
- {"risk": "风险描述", "probability": "高/中/低", "impact": "高/中/低", "mitigation": "缓解措施"}
170
- ]
171
- },
172
- "alternative_options": [
173
- {"rank": 2, "description": "备选方案", "confidence_score": 11.8, "reason_for_lower_rank": "原因"}
174
- ],
175
137
  "decision_chain": {}
176
138
  }
177
139
  ```
178
140
 
179
- **使用说明**:
180
- - 当研讨无分叉时,使用此模板替换多分支报告
181
- - `session_type` 字段标记为 "single_branch",与多分支场景区分
182
- - 输出目录中的 "多分支决策对比" 替换为 "方案演进过程"
183
-
184
- ## 证据链 JSON 模板
141
+ ## 决策链 JSON 模板
185
142
 
186
143
  ```json
187
144
  {
@@ -217,7 +174,7 @@
217
174
  }
218
175
  ```
219
176
 
220
- 二次研讨时,可引用上一轮证据链,形成多级引用。
177
+ 二次研讨时,可引用上一轮决策链,形成多级引用。
221
178
 
222
179
  ## 二级决策链 JSON 模板
223
180
 
@@ -270,6 +227,8 @@
270
227
 
271
228
  **使用说明**:按此顺序输出内容,并为每个标题设置对应的锚点ID。同时,在每节末尾嵌入"[↑ 返回目录](#-目录)"链接。
272
229
 
230
+ **单分支场景说明**:当研讨未触发分叉时,目录第5节「5. 多分支决策对比」替换为「5. 方案演进过程」,其余章节保持不变。
231
+
273
232
  ## 消息传递 JSON 格式
274
233
 
275
234
  ```json
@@ -308,7 +267,7 @@ fork(options: {
308
267
 
309
268
  merge(options: {
310
269
  branch_ids: ["alpha", "beta"], // 参与合并的分支
311
- strategy: "best_confidence" | "complementary" | "user_choice"
270
+ strategy: "best_confidence" | "user_choice"
312
271
  }) -> { final_report }
313
272
 
314
273
  destroy_branch(branch_id: "alpha") // 仅分支管理AI可调用
package/bin.js CHANGED
@@ -6,7 +6,7 @@ const fs = require('fs');
6
6
  const path = require('path');
7
7
 
8
8
  const SDD = {
9
- version: '5.2.0',
9
+ version: '5.2.2',
10
10
  name: 'sdd-full',
11
11
  description: '完整的软件设计开发技能包'
12
12
  };
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "sdd-full",
3
- "version": "5.2.0",
3
+ "version": "5.2.2",
4
4
  "description": "SDD Full - 完整的软件设计开发技能包",
5
5
  "main": "index.js",
6
6
  "bin": "./bin.js",