sdd-full 5.2.1 → 5.2.3
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.
- package/.claude/commands/mu.md +27 -17
- package/.claude/settings.json +84 -0
- package/.claude/skills/multi-expert-discussion/SKILL.md +87 -3
- package/.claude/skills/multi-expert-discussion/references/action-prioritization.md +359 -0
- package/.claude/skills/multi-expert-discussion/references/attribution-analysis.md +568 -0
- package/.claude/skills/multi-expert-discussion/references/cross-examination.md +252 -0
- package/.claude/skills/multi-expert-discussion/references/entropy-framework.md +167 -0
- package/.claude/skills/multi-expert-discussion/references/mechanisms.md +84 -0
- package/.claude/skills/multi-expert-discussion/references/problem-routing.md +41 -1
- package/.claude/skills/multi-expert-discussion/references/red-team.md +279 -0
- package/.claude/skills/multi-expert-discussion/references/roles.md +78 -0
- package/.claude/skills/multi-expert-discussion/references/scoring.md +49 -0
- package/.claude/skills/multi-expert-discussion/references/second-order-effects.md +343 -0
- package/.claude/skills/multi-expert-discussion/templates/reports.md +156 -0
- package/.claude/skills/multi-expert-discussion//344/270/207/350/203/275/346/236/266/346/236/204/345/233/276/346/217/220/347/244/272/350/257/215/346/250/241/346/235/277.md +203 -0
- package/.claude/skills/multi-expert-discussion//345/256/214/346/225/264/346/236/266/346/236/204/345/233/276.md +615 -0
- package/bin.js +1 -1
- package/package.json +1 -1
|
@@ -0,0 +1,252 @@
|
|
|
1
|
+
# 交叉质询协议
|
|
2
|
+
|
|
3
|
+
## 交叉质询概述
|
|
4
|
+
|
|
5
|
+
交叉质询(Cross-Examination)是 V5.1 第七层(领域模拟层)的核心对抗机制。当两位专家对同一议题给出互斥的高置信度观点时,自动触发结构化的质疑程序,通过多轮攻防交锋验证双方观点的坚固程度。
|
|
6
|
+
|
|
7
|
+
交叉质询区别于圆桌自由研讨(Roundtable Free Discussion)的关键特征:
|
|
8
|
+
|
|
9
|
+
| 维度 | 圆桌自由研讨 | 交叉质询 |
|
|
10
|
+
|------|-------------|---------|
|
|
11
|
+
| 性质 | 协作探索 | 对抗验证 |
|
|
12
|
+
| 形式 | 多位专家轮流发言,自由交锋 | 一对一质询,结构化攻防 |
|
|
13
|
+
| 规则约束 | 发言限时,无强制回应义务 | 答辩方必须逐条回应,不可回避 |
|
|
14
|
+
| 质询维度 | 无固定分类 | 四维分类(事实/逻辑/预设/数据) |
|
|
15
|
+
| 轮次控制 | 由主持人灵活调度 | 硬性限制默认 3 轮 |
|
|
16
|
+
| 输出 | 阶段备忘录 | 交叉质询备忘录 + 裁决书 |
|
|
17
|
+
| 终止条件 | 共识达成或死锁熔断 | 轮次耗尽或一方弃权 |
|
|
18
|
+
|
|
19
|
+
## 触发条件
|
|
20
|
+
|
|
21
|
+
### 自动触发
|
|
22
|
+
|
|
23
|
+
同时满足以下两个条件时,审查AI自动启动交叉质询程序:
|
|
24
|
+
|
|
25
|
+
1. 两位专家对同一议题给出互斥观点(观点不可共存,且非语义等价变体)
|
|
26
|
+
2. 双方置信度标签均为「高」(综合分 ≥ 17)
|
|
27
|
+
|
|
28
|
+
审查AI在启动前需确认互斥性,排除以下伪互斥情形:
|
|
29
|
+
- 术语差异导致的对立(双方用不同术语描述同一实质内容)
|
|
30
|
+
- 适用范围不同导致的对立(双方在不同预设条件下给出不同答案,本质不矛盾)
|
|
31
|
+
- 粒度差异导致的对立(一方为另一方观点的子集或细化)
|
|
32
|
+
|
|
33
|
+
### 审查AI建议触发
|
|
34
|
+
|
|
35
|
+
审查AI在以下情况下可主动建议启动交叉质询:
|
|
36
|
+
|
|
37
|
+
- 发现某专家观点存在逻辑漏洞,但该漏洞在自由研讨中未被充分挑战
|
|
38
|
+
- 某专家的观点依赖未经验证的预设,而该预设可能不成立
|
|
39
|
+
- 两位专家虽非严格互斥,但其分歧对最终决策至关重要
|
|
40
|
+
|
|
41
|
+
审查AI建议格式:
|
|
42
|
+
|
|
43
|
+
> 「审查AI建议:对 Expert_A 与 Expert_B 在议题『XXX』上的分歧启动交叉质询。理由:Expert_A 的推理链在第N步存在跳跃,未在自由研讨中被质疑。是否启动?」
|
|
44
|
+
|
|
45
|
+
### 用户显式指令
|
|
46
|
+
|
|
47
|
+
用户可在任意时刻发出指令:
|
|
48
|
+
|
|
49
|
+
> 「交叉质询 Expert_A 和 Expert_B」
|
|
50
|
+
|
|
51
|
+
或指定议题范围:
|
|
52
|
+
|
|
53
|
+
> 「交叉质询 Expert_A 和 Expert_B,仅针对议题『XXX』」
|
|
54
|
+
|
|
55
|
+
用户指令优先于自动触发规则——即使用户指令不满足自动触发条件,系统仍需执行。
|
|
56
|
+
|
|
57
|
+
## 质询格式规范
|
|
58
|
+
|
|
59
|
+
### 质询维度四分类
|
|
60
|
+
|
|
61
|
+
每条质询必须明确标注所属维度。一个质询方可在同一轮中发起多条质询,每条可归属于不同维度。
|
|
62
|
+
|
|
63
|
+
| 维度 | 定义 | 质询要点 | 示例 |
|
|
64
|
+
|------|------|---------|------|
|
|
65
|
+
| 事实质疑 | 质疑对方引用的数据、事实或引用的准确性 | 检查引用来源、数据时效、数字准确性 | "你引用的『2023年Statista报告』显示Java开发者占31%,该报告的实际发布日期为2022年Q4,数据采集时间为2021年。请提供2024年后的等效数据。" |
|
|
66
|
+
| 逻辑质疑 | 质疑对方推理链的完整性或推理步骤的跳跃 | 检查推理是否包含隐藏步骤、是否存在非必然推论 | "你断言『A导致B,B导致C,因此A导致C』,但A到B依赖假设X成立。请论证假设X在当前场景下必定成立。" |
|
|
67
|
+
| 预设质疑 | 质疑对方论证所依赖的隐含前提或边界条件 | 检查是否存在未经声明或未经论证的假设 | "你的论证预设『用户总是有稳定的网络连接』。请在离线场景下重新检验你的结论是否仍然成立。" |
|
|
68
|
+
| 数据质疑 | 质疑对方所用数据的代表性、样本量、采集方法或适用范围 | 检查样本偏差、数据采集条件、统计显著性 | "你引用的用户调研N=50且仅覆盖一线城市。请论证该样本对三线城市用户群体的代表性。" |
|
|
69
|
+
|
|
70
|
+
### 每轮质询格式
|
|
71
|
+
|
|
72
|
+
质询方发言必须包含以下结构要素:
|
|
73
|
+
|
|
74
|
+
```
|
|
75
|
+
---
|
|
76
|
+
[质询轮次]: 第 N 轮
|
|
77
|
+
[质询方]: Expert_A
|
|
78
|
+
[答辩方]: Expert_B
|
|
79
|
+
[议题]: 明确的议题描述
|
|
80
|
+
|
|
81
|
+
[质询 1]
|
|
82
|
+
维度:事实质疑 / 逻辑质疑 / 预设质疑 / 数据质疑
|
|
83
|
+
内容:(具体质询内容,明确指出被质疑的具体言论或推理步骤)
|
|
84
|
+
要求回应:(要求答辩方回答的具体问题,一问一行,可多个子问题)
|
|
85
|
+
|
|
86
|
+
[质询 2]
|
|
87
|
+
维度:事实质疑 / 逻辑质疑 / 预设质疑 / 数据质疑
|
|
88
|
+
内容:(具体质询内容)
|
|
89
|
+
要求回应:(具体问题)
|
|
90
|
+
|
|
91
|
+
(可继续追加质询 3、4...,单轮质询数上限 5 条)
|
|
92
|
+
---
|
|
93
|
+
```
|
|
94
|
+
|
|
95
|
+
答辩方格式:
|
|
96
|
+
|
|
97
|
+
```
|
|
98
|
+
---
|
|
99
|
+
[答辩轮次]: 第 N 轮
|
|
100
|
+
[答辩方]: Expert_B
|
|
101
|
+
[质询方]: Expert_A
|
|
102
|
+
|
|
103
|
+
[回应 1]
|
|
104
|
+
针对质询:[质询 1 的内容摘要]
|
|
105
|
+
判定:接受并修正 / 部分接受 / 驳回
|
|
106
|
+
理由:(若接受并修正:说明修正后的观点;若部分接受:说明接受哪些、不接受哪些及理由;若驳回:说明驳回的理据)
|
|
107
|
+
|
|
108
|
+
[回应 2]
|
|
109
|
+
针对质询:[质询 2 的内容摘要]
|
|
110
|
+
判定:接受并修正 / 部分接受 / 驳回
|
|
111
|
+
理由:(同上)
|
|
112
|
+
|
|
113
|
+
---
|
|
114
|
+
```
|
|
115
|
+
|
|
116
|
+
## 答辩规则
|
|
117
|
+
|
|
118
|
+
### 轮次限制
|
|
119
|
+
|
|
120
|
+
交叉质询默认 3 轮,不可延长:
|
|
121
|
+
|
|
122
|
+
| 轮次 | 内容 | 执行者 |
|
|
123
|
+
|------|------|--------|
|
|
124
|
+
| 第 1 轮 | 质询 → 答辩 | Expert_A 质询 Expert_B |
|
|
125
|
+
| 第 2 轮 | 再质询 → 再答辩 | Expert_A 针对第 1 轮答辩内容发起追问 |
|
|
126
|
+
| 第 3 轮 | 最终质询 → 最终答辩 | Expert_A 发起最终质询,Expert_B 最终答辩 |
|
|
127
|
+
|
|
128
|
+
质询方在第 2 轮和第 3 轮的质询必须基于上一轮答辩内容,不可重复首轮已提出的质询,不可引入全新的、与之前质询无关的攻击维度。
|
|
129
|
+
|
|
130
|
+
### 超时处理
|
|
131
|
+
|
|
132
|
+
- 每轮质询限时 60 秒,每轮答辩限时 60 秒
|
|
133
|
+
- 超时未返回有效发言,视为弃权
|
|
134
|
+
- 质询方弃权:交叉质询提前终止,审查AI直接裁定——维持双方原观点不变,备忘录标注"质询方弃权"
|
|
135
|
+
- 答辩方弃权:该轮答辩视为完全未回应,审查AI裁定时将该轮所有质询视为"答辩方默认接受"
|
|
136
|
+
- 双方均弃权:交叉质询终止,双方观点均降级至置信度「中」
|
|
137
|
+
|
|
138
|
+
### 答辩不可回避
|
|
139
|
+
|
|
140
|
+
答辩方必须对每条质询给出实质性回应,禁止以下行为:
|
|
141
|
+
|
|
142
|
+
- 仅回复"不适用"而无进一步说明
|
|
143
|
+
- 仅回复"已在之前讨论中说明"而无具体引用
|
|
144
|
+
- 用反问替代回答
|
|
145
|
+
- 以非实质性内容填充(如重新陈述立场而不回应质询点)
|
|
146
|
+
|
|
147
|
+
审查AI在每轮答辩后进行合规性检查,判定以下情形视为"回避":
|
|
148
|
+
|
|
149
|
+
| 回避类型 | 判定标准 | 处理 |
|
|
150
|
+
|---------|---------|------|
|
|
151
|
+
| 空回应 | 答辩文本未涉及质询的具体内容 | 该条质询视为答辩方默认接受 |
|
|
152
|
+
| 循环论证 | 答辩内容为被质询观点的重述,未提供新的论证 | 该条质询视为答辩方默认接受 |
|
|
153
|
+
| 转移话题 | 答辩内容指向另一个不相关的议题 | 该条质询视为答辩方默认接受 |
|
|
154
|
+
|
|
155
|
+
## 交叉质询裁决
|
|
156
|
+
|
|
157
|
+
### 裁决流程
|
|
158
|
+
|
|
159
|
+
交叉质询 3 轮结束后(或提前终止后),审查AI进入裁决阶段:
|
|
160
|
+
|
|
161
|
+
1. **逐条评估**:审查AI逐条评估每轮质询和答辩的质量
|
|
162
|
+
- 质询是否切中要害(有效质询 vs 无效质询)
|
|
163
|
+
- 答辩是否充分回应(有效回应 vs 回避 vs 默认接受)
|
|
164
|
+
|
|
165
|
+
2. **置信度重算**:根据质询结果重新计算双方置信度
|
|
166
|
+
- 答辩方每有一条"接受并修正":该议题综合分 -1
|
|
167
|
+
- 答辩方每有一条"默认接受"(含回避判定):该议题综合分 -2
|
|
168
|
+
- 答辩方每有一条"驳回(附充分理由且审查AI认可)":该议题综合分不变
|
|
169
|
+
- 质询方每有一条无效质询(审查AI判定为不成立):该议题综合分 -0.5
|
|
170
|
+
|
|
171
|
+
3. **裁决输出**:审查AI裁定哪一方观点在质询后置信度更高
|
|
172
|
+
|
|
173
|
+
### 裁决原则
|
|
174
|
+
|
|
175
|
+
- 交叉质询不追求"谁赢",而是验证哪一方的观点更经得起对抗性检验
|
|
176
|
+
- 裁决结果有三种可能:维持 A 方优势、维持 B 方优势、双方均降级(质询暴露双方均存在漏洞)
|
|
177
|
+
- 若双方在质询后综合分均降至 < 17,则该议题从"高置信度分歧"降级为"待进一步研究",不产生裁决
|
|
178
|
+
|
|
179
|
+
### 交叉质询备忘录
|
|
180
|
+
|
|
181
|
+
审查AI在裁决完成后输出交叉质询备忘录,记录质询过程、关键转折点、最终裁定。
|
|
182
|
+
|
|
183
|
+
备忘录模板:
|
|
184
|
+
|
|
185
|
+
```json
|
|
186
|
+
{
|
|
187
|
+
"type": "cross_examination_memo",
|
|
188
|
+
"meta": {
|
|
189
|
+
"initiated_by": "auto | auditor_suggestion | user_command",
|
|
190
|
+
"topic": "议题描述",
|
|
191
|
+
"examiner": "Expert_A",
|
|
192
|
+
"respondent": "Expert_B",
|
|
193
|
+
"total_rounds": 3,
|
|
194
|
+
"rounds_completed": 3,
|
|
195
|
+
"termination_reason": "轮次耗尽 | 质询方弃权 | 答辩方弃权 | 用户终止"
|
|
196
|
+
},
|
|
197
|
+
"rounds": [
|
|
198
|
+
{
|
|
199
|
+
"round": 1,
|
|
200
|
+
"examination": [
|
|
201
|
+
{
|
|
202
|
+
"id": "Q1",
|
|
203
|
+
"dimension": "事实质疑 | 逻辑质疑 | 预设质疑 | 数据质疑",
|
|
204
|
+
"summary": "质询内容摘要",
|
|
205
|
+
"effectiveness": "有效 | 无效",
|
|
206
|
+
"effectiveness_reason": "审查AI判定理由"
|
|
207
|
+
}
|
|
208
|
+
],
|
|
209
|
+
"response": [
|
|
210
|
+
{
|
|
211
|
+
"id": "R1",
|
|
212
|
+
"refers_to": "Q1",
|
|
213
|
+
"judgment": "接受并修正 | 部分接受 | 驳回",
|
|
214
|
+
"compliance": "合规 | 回避",
|
|
215
|
+
"compliance_reason": "审查AI合规性判定理由",
|
|
216
|
+
"summary": "答辩内容摘要"
|
|
217
|
+
}
|
|
218
|
+
]
|
|
219
|
+
}
|
|
220
|
+
],
|
|
221
|
+
"critical_turning_points": [
|
|
222
|
+
{
|
|
223
|
+
"round": 2,
|
|
224
|
+
"description": "关键转折点描述,说明为何该节点改变了对抗态势"
|
|
225
|
+
}
|
|
226
|
+
],
|
|
227
|
+
"confidence_recalculation": {
|
|
228
|
+
"examiner": {
|
|
229
|
+
"original_score": 18,
|
|
230
|
+
"adjustments": [
|
|
231
|
+
{ "reason": "第2轮 Q3 被判定为无效质询", "delta": -0.5 }
|
|
232
|
+
],
|
|
233
|
+
"final_score": 17.5,
|
|
234
|
+
"final_label": "高"
|
|
235
|
+
},
|
|
236
|
+
"respondent": {
|
|
237
|
+
"original_score": 17,
|
|
238
|
+
"adjustments": [
|
|
239
|
+
{ "reason": "第1轮 R2 被判定为回避,默认接受", "delta": -2 },
|
|
240
|
+
{ "reason": "第3轮 R1 接受并修正", "delta": -1 }
|
|
241
|
+
],
|
|
242
|
+
"final_score": 14,
|
|
243
|
+
"final_label": "中"
|
|
244
|
+
}
|
|
245
|
+
},
|
|
246
|
+
"verdict": {
|
|
247
|
+
"outcome": "examiner_advantage | respondent_advantage | both_degraded | no_verdict",
|
|
248
|
+
"ruling": "最终裁定说明",
|
|
249
|
+
"degraded_topic": "若双方均降级,该议题的新处理方式"
|
|
250
|
+
}
|
|
251
|
+
}
|
|
252
|
+
```
|
|
@@ -0,0 +1,167 @@
|
|
|
1
|
+
# 熵增/熵减元公理框架
|
|
2
|
+
|
|
3
|
+
## 1. 简介
|
|
4
|
+
|
|
5
|
+
熵增/熵减元公理是多专家研讨系统的根本分析视角,位于 V5.1 架构第负一层(元公理层)。它不直接参与具体议题的辩论,而是为所有讨论提供一个底层的、不可绕过的分析透镜。任何问题、方案、分歧,最终都可以——也必须可以——从熵增与熵减的角度被审视。
|
|
6
|
+
|
|
7
|
+
本框架包含两类元公理:
|
|
8
|
+
|
|
9
|
+
- **元公理一(熵增公理)**:在没有能量/信息注入的情况下,任何系统的默认趋势都是走向混乱、模糊和解体。混乱不需要解释,秩序才需要。
|
|
10
|
+
- **元公理二(熵减公理)**:一切生命、思维、组织、文明存在的意义,就是在局部范围内,通过消耗能量,暂时性地对抗熵增。所有"问题",本质上都是需要被处理的熵增;所有"方案",本质上都是计划实施的熵减。
|
|
11
|
+
|
|
12
|
+
用日常语言说:事情天然会变糟,不需要理由;让事情变好,才需要付出努力和理由。
|
|
13
|
+
|
|
14
|
+
---
|
|
15
|
+
|
|
16
|
+
## 2. 元公理一:熵增公理
|
|
17
|
+
|
|
18
|
+
### 2.1 正式定义
|
|
19
|
+
|
|
20
|
+
设系统 S 在时间 t 的状态为 S(t),在没有外部能量/信息注入 ΔE 的情况下:
|
|
21
|
+
|
|
22
|
+
```
|
|
23
|
+
S(t + Δt) 的信息熵 H(S) 单调不减,即 H(S(t + Δt)) ≥ H(S(t))
|
|
24
|
+
```
|
|
25
|
+
|
|
26
|
+
当且仅当 ΔE > 0 且 ΔE 被有效导向结构化用途时,H(S) 才可能下降。
|
|
27
|
+
|
|
28
|
+
### 2.2 日常语言表述
|
|
29
|
+
|
|
30
|
+
事情放着不管,一定会越来越乱。代码不维护会腐烂,团队不沟通会猜疑,知识不整理会遗忘,流程不审计会腐化。这不是谁的错,这是世界的默认设置。
|
|
31
|
+
|
|
32
|
+
### 2.3 在研讨中的应用
|
|
33
|
+
|
|
34
|
+
分析问题现状时,从"这个系统正在遭遇哪类熵增"入手。不要先问"谁的责任",先问"哪种混乱正在发生"。
|
|
35
|
+
|
|
36
|
+
### 2.4 熵增的四种形态
|
|
37
|
+
|
|
38
|
+
| 形态 | 定义 | 典型表现 | 研讨中如何识别 |
|
|
39
|
+
|------|------|---------|--------------|
|
|
40
|
+
| 信息熵增 | 知识混乱、信息过载、信号被噪声淹没 | 文档过期、需求矛盾、数据口径不统一、关键信息找不到 | 专家引用相互矛盾的事实依据时 |
|
|
41
|
+
| 结构熵增 | 组织松散、流程腐化、权责模糊 | 审批链路冗长、职责边界模糊、资源重复配置、流程形同虚设 | 讨论中反复出现"这个该谁负责"时 |
|
|
42
|
+
| 关系熵增 | 信任瓦解、沟通断裂、协作成本上升 | 跨团队推诿、会议变成辩护、信息有意隐瞒、历史积怨影响决策 | 专家之间出现非理性对立时 |
|
|
43
|
+
| 认知熵增 | 偏见固化、思维僵化、路径依赖 | "我们一直都是这么做的"、对新方案的条件反射式否定、框架锁定 | 专家组反复回到同一个死胡同时 |
|
|
44
|
+
|
|
45
|
+
---
|
|
46
|
+
|
|
47
|
+
## 3. 元公理二:熵减公理
|
|
48
|
+
|
|
49
|
+
### 3.1 正式定义
|
|
50
|
+
|
|
51
|
+
熵减是一个需要消耗能量的非自发过程。对于系统 S,实现局部熵减 ΔH < 0 的必要条件是:
|
|
52
|
+
|
|
53
|
+
```
|
|
54
|
+
ΔH < 0 ⇒ ΔE > 0 且 η · ΔE > |ΔH|
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
其中 η 为能量利用效率(0 < η ≤ 1),η · ΔE 为实际用于结构化用途的有效能量。未被有效利用的能量转化为废热(副作用、次生问题)。
|
|
58
|
+
|
|
59
|
+
### 3.2 日常语言表述
|
|
60
|
+
|
|
61
|
+
把乱的东西整理好,是需要花力气的。写文档要时间,对齐认知要开会,重构代码要人力,重建信任要诚意。而且花出去的力气不可能 100% 变成好结果——总有一部分会被浪费掉,甚至带来新麻烦。
|
|
62
|
+
|
|
63
|
+
### 3.3 在研讨中的应用
|
|
64
|
+
|
|
65
|
+
评估方案时,从"这个方案能在多大程度上、以多大代价实现局部熵减"入手。不要先问"这个方案好不好",先问"它能让哪种混乱减轻多少,代价是什么"。
|
|
66
|
+
|
|
67
|
+
### 3.4 熵减的代价
|
|
68
|
+
|
|
69
|
+
| 代价类型 | 说明 | 研讨中需评估的问题 |
|
|
70
|
+
|---------|------|------------------|
|
|
71
|
+
| 能量消耗 | 时间、金钱、注意力、认知负荷的直接投入 | 这个方案需要投入多少资源?团队当前是否承担得起? |
|
|
72
|
+
| 机会成本 | 选择此熵减路径而放弃的其他路径 | 同样的资源如果投向另一个问题,能获得更大的熵减吗? |
|
|
73
|
+
| 副作用(废热) | 熵减过程中不可避免的次生混乱 | 方案执行过程中会产生什么新问题?是否有预案? |
|
|
74
|
+
|
|
75
|
+
---
|
|
76
|
+
|
|
77
|
+
## 4. 四条戒律(内置约束)
|
|
78
|
+
|
|
79
|
+
### 4.1 戒律一:反过度简化
|
|
80
|
+
|
|
81
|
+
**内容**:用熵增熵减解释一切之前,先问——这件事是否还需要从意义、信仰、美学的维度去理解?如果是,不要强行还原。
|
|
82
|
+
|
|
83
|
+
**适用范围**:涉及人类情感、文化价值、艺术判断、伦理选择等不可量化的领域时,熵框架只作为辅助视角,不可取代人文维度的讨论。
|
|
84
|
+
|
|
85
|
+
**日常语言表述**:不是所有事情都能用"变乱"和"整理"来解释。一首诗好不好、一个信仰值不值得坚守、一个设计美不美——这些问题有它们自己的语言,别硬套。
|
|
86
|
+
|
|
87
|
+
### 4.2 戒律二:反分析瘫痪
|
|
88
|
+
|
|
89
|
+
**内容**:当分析超过三层深度时,强制收束。问自己:我需要的是一个足够好的行动方案,还是一个完美的认知模型?如果是前者,停止分析,开始行动。
|
|
90
|
+
|
|
91
|
+
**触发条件**:熵增/熵减因果链追溯超过三层(问题 → 原因 → 原因的原因 → 原因的原因的原因)。
|
|
92
|
+
|
|
93
|
+
**收束话术**:
|
|
94
|
+
> 分析已到达第三层深度。当前面临的选择是:继续深化认知模型,还是基于现有分析输出行动方案。若选择后者,将以当前最深一层的结论作为行动依据。
|
|
95
|
+
|
|
96
|
+
**日常语言表述**:分析问题像剥洋葱,剥到第三层就够了。再剥下去,你会忘了自己本来是要炒菜,不是研究洋葱。
|
|
97
|
+
|
|
98
|
+
### 4.3 戒律三:反宿命论
|
|
99
|
+
|
|
100
|
+
**内容**:每次启动熵增熵减分析后,必须在结尾输出「因此,我接下来的熵减行动是——」。不许只分析、不行动。熵增是默认趋势,意味着什么都不做就等同于放任混乱加剧。承认熵增的必然性,不是接受混乱的借口。
|
|
101
|
+
|
|
102
|
+
**日常语言表述**:知道事情会变乱,不等于你可以袖手旁观。"反正都会乱"不是不做事的理由——恰恰相反,正因为会乱,才更需要做事。
|
|
103
|
+
|
|
104
|
+
### 4.4 戒律四:反语言腐败
|
|
105
|
+
|
|
106
|
+
**内容**:每次使用"熵增"或"熵减"术语时,必须同时用日常语言重新表述一遍。禁止用专业术语包装常识、制造理解壁垒。
|
|
107
|
+
|
|
108
|
+
**执行标准**:
|
|
109
|
+
- 首次引入术语时:给出术语 + 日常表述
|
|
110
|
+
- 后续使用术语时:在同一段落内附带日常表述,或在前文已有明确日常定义的前提下可简用术语
|
|
111
|
+
- 面对非技术背景用户时:优先使用日常表述,术语仅作为括号补充
|
|
112
|
+
|
|
113
|
+
**日常语言表述**:说人话。能说"事情变乱了"就不要说"系统熵增";能说"整理清楚"就不要说"实施熵减"。术语是工具,不是武器。
|
|
114
|
+
|
|
115
|
+
---
|
|
116
|
+
|
|
117
|
+
## 5. 熵减行动收束模板
|
|
118
|
+
|
|
119
|
+
### 5.1 格式
|
|
120
|
+
|
|
121
|
+
```
|
|
122
|
+
因此,我接下来的熵减行动是——[具体行动描述]
|
|
123
|
+
```
|
|
124
|
+
|
|
125
|
+
用日常语言说:所以,我接下来要做的事情是——[具体行动描述]。
|
|
126
|
+
|
|
127
|
+
### 5.2 收束时机
|
|
128
|
+
|
|
129
|
+
| 问题类型 | 是否强制 | 收束位置 |
|
|
130
|
+
|---------|---------|---------|
|
|
131
|
+
| 灰度导航类问题(价值冲突、信息不完备、后果重大) | 强制 | 最终结论前必须执行 |
|
|
132
|
+
| 收敛型问题 | 建议 | 方案输出前建议执行 |
|
|
133
|
+
| 发散型问题 | 建议 | 创意收拢阶段建议执行 |
|
|
134
|
+
| 探索型问题 | 建议 | 认知框架建立后建议执行 |
|
|
135
|
+
|
|
136
|
+
### 5.3 行动描述要求
|
|
137
|
+
|
|
138
|
+
行动描述必须满足以下标准:
|
|
139
|
+
- **具体**:有明确的执行主体、动作、对象,不可抽象模糊
|
|
140
|
+
- **可验证**:完成后可以判断"是否做到了"
|
|
141
|
+
- **有边界**:明确行动的范围,不无限扩大
|
|
142
|
+
|
|
143
|
+
---
|
|
144
|
+
|
|
145
|
+
## 6. 熵增/熵减快速诊断表
|
|
146
|
+
|
|
147
|
+
主持人在问题定义阶段使用本表进行初步诊断,为后续专家讨论建立共同的熵视角。
|
|
148
|
+
|
|
149
|
+
| 观察现象 | 熵增类型 | 熵减方向 |
|
|
150
|
+
|---------|---------|---------|
|
|
151
|
+
| 多方引用的数据/事实相互矛盾 | 信息熵增 | 建立单一事实源,统一数据口径 |
|
|
152
|
+
| 决策链路冗长,无人能说清谁拍板 | 结构熵增 | 明确决策权责,压缩审批节点 |
|
|
153
|
+
| 会议时间一半用于解释背景而非讨论方案 | 信息熵增 + 关系熵增 | 前置文档对齐 + 恢复信任机制 |
|
|
154
|
+
| 跨团队协作时对方第一反应是自我保护 | 关系熵增 | 建立共同目标,短期联合攻坚破冰 |
|
|
155
|
+
| 对新方案的反对意见全部基于"历史经验" | 认知熵增 | 引入外部案例、数据实验、小范围试点 |
|
|
156
|
+
| 同一问题反复出现,每次用临时方案掩盖 | 结构熵增 | 根治流程缺陷,而非追加补丁 |
|
|
157
|
+
| 关键人离职后相关工作完全停滞 | 信息熵增 + 结构熵增 | 知识沉淀制度化 + 备份机制 |
|
|
158
|
+
| 团队内有两种完全不同的"现实"认知 | 认知熵增 + 关系熵增 | 事实对齐会议 + 共同外部数据源 |
|
|
159
|
+
| 资源在多条线上重复投入,互相不知情 | 结构熵增 | 资源可视化管理 + 协调节点 |
|
|
160
|
+
| 文档齐全但无人参考,实际做法靠口头传承 | 信息熵增 | 文档瘦身 + 将文档纳入流程强制节点 |
|
|
161
|
+
|
|
162
|
+
### 使用说明
|
|
163
|
+
|
|
164
|
+
1. 主持人在阶段0(问题定义)中对照上表进行初步诊断
|
|
165
|
+
2. 将诊断结果作为问题背景的一部分注入专家招募和初始立场对齐阶段
|
|
166
|
+
3. 诊断结果不作为结论,仅作为讨论的起点——专家可以修正、补充或推翻
|
|
167
|
+
4. 最终研讨会输出中应包含"熵视角总结"章节
|
|
@@ -305,3 +305,87 @@
|
|
|
305
305
|
1. 审查AI建议暂停当前讨论方向
|
|
306
306
|
2. 引导聚焦新议题或切换讨论角度
|
|
307
307
|
3. 若暂停后仍无进展,则持续触发死锁熔断流程
|
|
308
|
+
|
|
309
|
+
## 红队攻击触发与调度
|
|
310
|
+
|
|
311
|
+
- **触发条件**:灰度导航类问题在专家组产出初步方案(即阶段3退出后)自动触发;或用户显式指令"红队攻击"
|
|
312
|
+
- **调度逻辑**:
|
|
313
|
+
1. 审查AI确认触发条件满足 → 通知主持人暂停正常流程
|
|
314
|
+
2. 主持人创建红队攻击者角色实例
|
|
315
|
+
3. 红队攻击者接收当前上下文快照(初步方案 + 全程备忘录 + 共识仓库)
|
|
316
|
+
4. 红队攻击者执行3轮攻击(详见 references/red-team.md)
|
|
317
|
+
5. 每轮攻击后,专家组进行答辩
|
|
318
|
+
6. 3轮攻击结束后生成《红队攻击报告》
|
|
319
|
+
7. 将报告注入后续流程,专家组基于红队发现修订方案
|
|
320
|
+
|
|
321
|
+
## 交叉质询触发与调度
|
|
322
|
+
|
|
323
|
+
- **触发条件**:
|
|
324
|
+
1. 自动触发:两位专家对同一议题给出互斥观点且双方置信度标签均为「高」
|
|
325
|
+
2. 审查AI建议触发
|
|
326
|
+
3. 用户显式指令
|
|
327
|
+
- **调度逻辑**:
|
|
328
|
+
1. 审查AI检测到满足触发条件 → 通知主持人
|
|
329
|
+
2. 主持人暂停当前讨论,宣布进入交叉质询阶段
|
|
330
|
+
3. 明确质询方和答辩方,设定3轮质询/答辩交替规则
|
|
331
|
+
4. 每轮限时60秒,超时视为弃权
|
|
332
|
+
5. 3轮结束后审查AI作出裁决
|
|
333
|
+
6. 生成《交叉质询备忘录》,存入上下文
|
|
334
|
+
|
|
335
|
+
## 二阶效应推演触发节点
|
|
336
|
+
|
|
337
|
+
- **触发条件**:灰度导航类问题在红队攻击完成后(或方案修订完成后)自动触发
|
|
338
|
+
- **推演流程**:
|
|
339
|
+
1. 审查AI提取最终推荐方案的每个关键决策点
|
|
340
|
+
2. 对每个决策点执行三步推演:因果链延长 → 影响域扩展 → 时间维度拉伸
|
|
341
|
+
3. 生成《二阶效应分析表》
|
|
342
|
+
4. 将二阶效应发现反馈给专家组,评估是否需要修订方案
|
|
343
|
+
- **调度时机**:在红队攻击之后、行动排序之前
|
|
344
|
+
|
|
345
|
+
## 归因分析调度逻辑
|
|
346
|
+
|
|
347
|
+
- **触发条件**:深度分析类问题("为什么"类)在深度优先层之后自动触发
|
|
348
|
+
- **调度流程**:
|
|
349
|
+
1. 主持人将问题现象传递给归因分析引擎
|
|
350
|
+
2. 按五步链路执行:第一性拆解 → 横向校验 → 纵向溯源 → 空间归因 → 时间归因
|
|
351
|
+
3. 生成《归因分析报告》
|
|
352
|
+
4. 将报告注入后续讨论,作为深度分析的补充输入
|
|
353
|
+
|
|
354
|
+
## 认知监察官并行运行机制
|
|
355
|
+
|
|
356
|
+
- **激活时机**:研讨完成偏见声明阶段后自动激活
|
|
357
|
+
- **运行模式**:并行运行,不阻塞主流程
|
|
358
|
+
- **每轮输出**:在审查AI完成审核后,监察官追加「认知监察官审校备注」
|
|
359
|
+
- **审校备注内容**(3-5条):
|
|
360
|
+
- 偏见追踪:是否有专家持续受初始偏见影响
|
|
361
|
+
- 盲点扫描:是否有被集体忽略的视角
|
|
362
|
+
- 熵增预警:讨论本身是否出现内卷或脱离现实
|
|
363
|
+
- 四项固定检查结论(人类中心主义/利害计算万能论/安逸的熵增/虚无的熵增)
|
|
364
|
+
- **与审查AI的协作**:审查AI关注结论正确性,监察官关注思考过程偏差,两者并行互补
|
|
365
|
+
|
|
366
|
+
## 行动排序触发机制
|
|
367
|
+
|
|
368
|
+
- **触发条件**:灰度导航或步骤流程类问题在二阶效应推演完成后自动触发
|
|
369
|
+
- **排序流程**:
|
|
370
|
+
1. 主持人提取所有候选行动项
|
|
371
|
+
2. 先执行叙事先行评估(叙事不通的行动直接降级)
|
|
372
|
+
3. 再执行量化排序:优先级 = 效果 × 紧迫度 × (6 - 实施难度)
|
|
373
|
+
4. 按优先级得分分类:P0(>80) / P1(50-80) / P2(20-49) / P3(<20)
|
|
374
|
+
5. 生成《行动排序矩阵》
|
|
375
|
+
- **调度时机**:在二阶效应推演之后、熵减收束之前
|
|
376
|
+
|
|
377
|
+
## 熵增/熵减元公理注入节点
|
|
378
|
+
|
|
379
|
+
- **注入时机**:问题定义阶段(阶段1),主持人在确认问题边界时注入
|
|
380
|
+
- **注入方式**:主持人在问题定义声明中阐述:
|
|
381
|
+
1. "从熵增视角看,当前问题属于哪类熵增(信息/结构/关系/认知)?"
|
|
382
|
+
2. "从熵减视角看,我们期望的方案应该实现什么样的局部熵减?"
|
|
383
|
+
- **持续作用**:元公理框架作为所有后续分析的背景视角,各专家在论证时可选引
|
|
384
|
+
|
|
385
|
+
## 熵减行动收束节点
|
|
386
|
+
|
|
387
|
+
- **触发条件**:所有问题类型在最终结论前执行;灰度导航类问题强制不可跳过
|
|
388
|
+
- **收束格式**:「因此,我接下来的熵减行动是——[具体行动描述]」
|
|
389
|
+
- **反语言腐败要求**:必须附带日常语言重新表述(不可仅用"熵减"术语)
|
|
390
|
+
- **调度时机**:在所有分析和排序完成之后、最终结论输出之前
|
|
391
|
+
- **执行者**:主持人汇总专家组结论,提炼为一个明确的、可执行的熵减行动声明
|
|
@@ -30,4 +30,44 @@
|
|
|
30
30
|
|
|
31
31
|
用户选择后,路由到对应流程。
|
|
32
32
|
|
|
33
|
-
**兜底策略**:若用户在询问后仍未做出选择,或在限定时间内未回复,系统默认按收敛型处理(加载收敛型流程 + 阶段0分层前置),并在流程开始时标注"已按默认收敛模式启动,可在任何轮次重选类型"。
|
|
33
|
+
**兜底策略**:若用户在询问后仍未做出选择,或在限定时间内未回复,系统默认按收敛型处理(加载收敛型流程 + 阶段0分层前置),并在流程开始时标注"已按默认收敛模式启动,可在任何轮次重选类型"。
|
|
34
|
+
|
|
35
|
+
## V5.1 问题类型扩展
|
|
36
|
+
|
|
37
|
+
### 五种问题类型判定规则
|
|
38
|
+
|
|
39
|
+
在原有收敛型/发散型/探索型基础上,增加 V5.1 的五种类型映射:
|
|
40
|
+
|
|
41
|
+
| V5.1 类型 | 原有类型映射 | 识别特征 | 触发策略 |
|
|
42
|
+
|:---|:---|:---|:---|
|
|
43
|
+
| 1. 事实查询 | 不触发多专家(轻量探索) | 有明确答案、边界清晰 | 单专家快速响应或直接搜索 |
|
|
44
|
+
| 2. 步骤流程 | 收敛型 | "怎么做"、有成熟路径 | 收敛型流程 + 强制开源自检 |
|
|
45
|
+
| 3. 深度分析 | 收敛型(增强) | "为什么"、多变量互动 | 收敛型流程 + 归因分析中心 |
|
|
46
|
+
| 4. 灰度导航 | 收敛型(全层级) | 价值冲突、信息不完备、后果重大、涉及关系结构重组 | 全层级开启:红队攻击 + 二阶效应 + 五维校准 + 交叉质询 |
|
|
47
|
+
| 5. 创新探索 | 发散型(增强) | "还能怎样"、需突破框架 | 发散型流程 + 可能性探索层,早期严禁过度批判 |
|
|
48
|
+
|
|
49
|
+
### 灰度导航触发规则
|
|
50
|
+
|
|
51
|
+
当判定为灰度导航类型时,自动触发以下全套机制:
|
|
52
|
+
- **红队攻击**(阶段5A):专家组产出初步方案后自动触发
|
|
53
|
+
- **二阶效应推演**(阶段5B):对每个关键决策点进行连锁反应推演
|
|
54
|
+
- **交叉质询**(阶段3A):当出现高置信度互斥观点时触发
|
|
55
|
+
- **五维价值校准**:以事实、价值、时空、系统(含权力意志分析)、实践五个维度校验中间结论
|
|
56
|
+
- **熵减行动收束**(阶段7):强制输出「因此,我接下来的熵减行动是——」
|
|
57
|
+
|
|
58
|
+
### 各类型的层级调度策略
|
|
59
|
+
|
|
60
|
+
| V5.1 类型 | 调用层级 | 强制动作 | 双螺旋引擎 |
|
|
61
|
+
|:---|:---|:---|:---|
|
|
62
|
+
| 事实查询 | 广度优先→可信度标注 | 无 | 仅理性引擎 |
|
|
63
|
+
| 步骤流程 | 深度优先→行动排序;强制开源自检 | 自信源自检 | 仅理性引擎 |
|
|
64
|
+
| 深度分析 | 场景→元认知→广度→深度→归因 | 归因分析中心 | 理性为主,感性为辅 |
|
|
65
|
+
| 创新探索 | 可能性探索→验证迭代 | 早期严禁过度批判 | 理性为主,允许混沌 |
|
|
66
|
+
| 灰度导航 | 15层全开(含元公理层) | 红队攻击+二阶效应+五维校准+熵减收束 | 双螺旋全开 |
|
|
67
|
+
|
|
68
|
+
### 混合型处理增强
|
|
69
|
+
|
|
70
|
+
当用户输入同时包含多种特征时:
|
|
71
|
+
1. 若含灰度导航特征,优先按灰度导航处理(最高优先级)
|
|
72
|
+
2. 若同时含深度分析+步骤流程,先归因分析→再行动排序
|
|
73
|
+
3. 若同时含创新探索+步骤流程,先发散探索→收敛到行动序列
|