通用两轮并行
提案评审决策流程

如何用 Swarm Decision群体并行决策：多角色独立提案 + 独立评审 + 最终裁决 Skill
把复杂问题变成可裁决对象

胥克谦 · 2026-04-21

背景

核心概念

什么是 Swarm Decision？

第一轮

提案发散

多个角色在同一 Profile配置档案：按内容类型装配角色、评审标准与门禁强度下独立产出差异化方案，强调独立性与多样性，避免群体极化。

汇总

观点变选项

主进程将候选方案整理为可比较的 Option Cards选项卡片：每个候选方案的清晰结构化描述 + 对比矩阵 + 阻塞问题清单。

第二轮

独立裁决

全新角色组对候选方案独立给出 verdict（含 trade-offs、风险与签字条件），确保评审者与提案者完全解耦。

把「多解、强约束、跨角色博弈」变成可交付结论

背景

痛点驱动

为什么需要它？

Evidence Root证据根目录：统一落盘、可回放、可审计的过程证据散落在 root，门禁范围不一致
docLinks文档链接：跨文档引用关系与断链检测断链治理缺失，commit-path 不一致
讨论阶段误触发写入，仓库被污染
多解方案无独立评审，结论难以回放审计

Swarm Decision群体并行决策：多角色独立提案 + 独立评审 + 最终裁决把「讨论」变成「决策」，把「方案」变成「交付」

背景

实证基础

30 个案例横跨 3 大领域

30

完整闭环案例

每个案例都跑完整两轮闭环并落盘全过程证据

研发 / 产品

Doc Root PolicydocLinks 治理Write-Intent Gate 并行边界MSW Mock 口径ToolInventory 契约包管理器冲突Docker 探测稳健性LLM 路由治理

架构决策

EvidenceRoot 统一配置协议Resumable Task 状态机

写作创意

一页纸入口决策型模板指令型防误触发

结构

本教程

内容结构

01

流程骨架

两轮发散 → 收敛 → 裁决的完整状态机

02

角色体系

谁提案、谁评审、谁裁决

03

10 类内容类型

如何按类型装配不同 Profile配置档案：按内容类型装配角色、评审标准与门禁强度

04

安全门禁

防误写、防泄密、防越权（Fail-Closed阻断式门禁：不满足条件直接停止，不允许降级为警告）

05

Skill 生成

从研究文档到可复用能力的完整路径

总览

架构总览

系统架构 — 一张图理解 Swarm Decision （点击放大）

Part 1 · 流程骨架

核心流程

两轮并行流程骨架

INIT→ FREEZE_INPUT→ DISPATCH_R1→ SYNTHESIS→ DISPATCH_R2→ JUDGING→ FINAL→ META

各阶段职责

FREEZE_INPUT：冻结输入合同（Problem / Evidence / Constraints / Success / Non-Goals / Rubric）
DISPATCH_R1：多角色独立提案（至少 3–5 个角色）
SYNTHESIS：Option Cards + 对比矩阵 + 阻塞问题
DISPATCH_R2：仅回答阻塞问题（禁止二次发散）

裁决与交付

JUDGING：全新角色独立 verdict（pick + confidence + trade-offs + sign-off）
FINAL：最终裁决，冻结 Profile配置档案：按内容类型装配角色、评审标准与门禁强度 v1
META：trace + requirements（可回放合同）

禁止跳过任何阶段，确保决策链路完整可追溯

Part 1 · 流程骨架

提案轮

Round 1：独立发散

Product

产品视角

可落地性、用户体验

Architect

架构视角

可扩展性、长期成本

Implementation

实现视角

工期、依赖、风险

QA

质量视角

可验证性、回归覆盖

Risk Security

风险视角

合规、安全、泄密风险

核心规则：每个角色先独立成稿，禁止互相引用后再写——防止观点趋同，保留多视角优势

Part 1 · 流程骨架

汇总

汇总阶段：观点变选项

Option Cards

每个候选方案的清晰描述，包含：方案名称、核心做法、关键假设、预期收益、已知局限

对比矩阵

多维度评分对比：
可落地性 / 可验证性 / 风险 / 成本 / 采用率

阻塞问题清单

必须回答的关键问题，决定 R2 的方向：悬空假设 / 跨方案冲突 / High 风险未决项

允许 Composite（组合方案），但必须写成明确 option，禁止把多个方案揉成一团变成模糊折中

Part 1 · 流程骨架

评审轮

Judging：全新角色独立裁决

技术

Judge Tech

技术可行性、架构合理性

产品

Judge Product

价值、用户体验

必须

Judge Risk

安全、合规、泄密风险

Verdict 格式（每个 Judge 必须输出）

pick

选哪个方案

confidence

置信度 0-1

trade-offs

权衡点

sign-off

验收条件

Part 1 · 流程骨架

最终交付

Decision Report：可交付报告

必须包含的 8 个章节

Executive Summary：执行摘要
Final Decision：最终决定
Option Cards：选项卡片
Comparison Matrix：对比矩阵
Verdict Summary：评审汇总
Risks & Sign-off：风险与签字
Acceptance Checklist：验收清单
Revisit Triggers：复盘触发条件

核心原则

可回放：每个结论都有证据支撑

可验收：Acceptance Checklist 量化验收条件

可审计：决策链路完整存档，随时可回放

Revisit Triggers 将一次性决策升级为可演化的决策协议

Part 2 · 内容类型

内容类型

为什么需要 10 类 Content Type？

痛点
研发流程、创意流程、企业传播流程——对内容类型的要求截然不同：谁来决策？门禁是什么？最终产出什么？用同一套逻辑，必然导致过松或过严。

解法：Profile 装配
按 contentType × riskClass内容类型 × 风险等级：决定角色、门禁与产物合同装配：角色、Rubric、Gate门禁规则：决定何时阻断、何时警告、产物格式——同一骨架，因地制宜。

三域覆盖

研发

Spec · ADR · Plan · QA · Ops · Security · Analytics

创意

Creative Brief · Enablement

企业市场

External Comms · Analytics · Security

Part 2 · 内容类型

内容类型

10 类 Content Type 总览

类型	核心门禁	分组
Spec	schema + examples 合同，breaking change 迁移窗口	技术
ADR	trade-offs + revisit triggers + 拒绝理由	技术
Plan	阶段门禁 + 并行资格机读裁决	技术
QA/Audit	evidence manifest + 默认脱敏	运维
Ops	Execution Intent + Danger Zone token	运维
Security	controls→gate + restricted 指针	运维
Analytics	metricVersion + query pointers (restricted)	业务
Comms	claim→evidence + 审批块（Approvers/Expiry/Scope）	业务
Creative	Brief 必填 + Do-Not 清单	业务
Enablement	双轨结构 + 命令标签（SAFE/DANGEROUS）	业务

Part 2 · 内容类型

对外材料

External Comms：审批链路

⚠ 为什么关键？
对外发布的声明、数据、承诺——任何失误都将影响客户信任与法律责任。

必备字段

claim→evidence 映射表：每个声明必须有对应证据指针，不可空口无凭
Approvers / Date / Expiry / Scope：审批块（必填）
Migration / Rollback：承诺变更时的迁移与回滚策略

Fail-Closed 规则

✕ 缺 Approvers / Expiry / Scope → BLOCK

✕ 未批准承诺 → 直接阻断

核心原则：未经审批的日期、价格、合规承诺，一律不得出现在对外材料中

Part 2 · 内容类型

运维安全

Ops/Incident：危险操作门禁

Execution Intent：三级水位线

NONE

仅读取，不执行

安全

READ-ONLY

仅查询操作

需审核

WRITE

写操作 — 必须带 token

高风险

Danger Zone — 写操作必须包含

☠ 影响面分析

↩ 回滚策略

✓ 前置检查清单

✓ 验证步骤

Part 2 · 内容类型

技术规格

Spec：合同化治理

schema + examples = 可回归合同

Spec（规范） = schema 定义 + examples 示例 + strict/compat 分级

可回归合同 = 接口契约 + 测试用例 + 破坏性变更追踪

strict：高风险类规格，强制严格模式

compat：向后兼容，允许渐进迁移

Fail-Closed 规则

✕ 缺 schema / examples → BLOCK

✕ breaking change 无迁移策略 → BLOCK

✕ 示例命中敏感模式（token / key / 绝对路径）→ BLOCK

Profile 装配：高风险类技术规格（支付、认证、数据格式）→ strict 模式强制，不允许 compat 回退

Part 3 · 安全治理

安全治理

6 大安全威胁模型

01

过早写入

用户只是讨论/要方案，系统却已生成文件、修改仓库

02

误把示例当执行

文档命令块Code Block：文档中的代码/操作示例被误判为可执行脚本

03

证据二次泄漏

敏感日志或配置信息被粘贴进正文或对外材料

04

越权承诺

对外材料出现未经审批的日期、价格或合规承诺

05

权限不可追责

谁批准、何时批准、范围是什么——全部不可审计

06

治理退化

从"严"逐步变成"随便"，warn-only仅警告模式：违规仅提示，不阻断长期存在

每一种威胁都可能独立触发，也可能在多个环节级联放大——防御体系必须同时覆盖

Part 3 · 安全治理

安全治理

Write-Intent Gate写入意图门禁：防止误写机制，强制显式授权

两阶段原则

Phase 1

DISCUSSION / RESEARCH讨论 / 研究态

只读 / 分析 / 生成提案 → 禁止写入仓库

↓

Phase 2

APPLY / EXECUTION执行态

满足写入意图协议后才允许写操作

写入意图协议（4 要素）

1

dry-runDry-Run：仅输出计划，不实际写入默认

先输出 plan + diff-scope

2

--apply显式确认标记

显式标记才能触发真实写入

3

nonce / token一次性令牌：防跨对话误触发

防止会话误触发写入

4

scope范围化授权：限定允许写入的目录/文件类型约束

范围化授权：允许写哪些目录

Fail-Closed：缺少 apply应用标记 / nonce一次性令牌 / scope范围化授权任一项 → 直接阻断

Part 3 · 安全治理

安全治理

SSOTSingle Source of Truth · 单一事实来源单写者 + 并行边界

单一事实来源

主进程

options.md选项说明文件
decision-report.md决策报告
最终汇总

子进程

各自 round*.md轮次记录文件
各自 verdict-*.md裁决结果文件

子进程不得越权写入主进程产物

三态裁决 — 并行资格

PARALLEL_OK

写集合互斥，可安全并行执行

SERIAL_ONLY

不确定是否有冲突 → 降级为串行

BLOCKED

发现写集合冲突或 scope授权范围不清晰 → 直接阻断

Part 3 · 安全治理

安全治理

扫描门禁：自动拦截风险

模式	命中内容	动作
secrets密钥/凭证/令牌	token / key / password / 私钥 / 连接串	FAIL
绝对路径Absolute Path	/Users/... , /home/... , C:\...	FAIL
越权承诺Unauthorized Commitment	未经审批的日期 / 价格 / 合规承诺	FAIL
危险命令块Dangerous Command Block	无 Execution Intent执行意图标签标签的写操作命令	FAIL

默认安全策略：证据采集默认脱敏 / 摘要处理，不保留原始敏感信息

高风险模式：必须显式启用，任何隐式跳过视为配置违规

Part 3 · 安全治理

安全治理

负例 Fixtures：最强防退化手段

为何需要负例？
内容风险（泄密/越权/误触发）很容易在迭代中悄悄退化——人的判断会疲劳，规则会松动，负例 fixtures 是唯一能持续捕获退化的机制。

PASS

pass fixtures

最小合规样例
每种 contentType内容类型保留 1 份

定义合规基线

FAIL

fail fixtures

每条 fail-closed gate失败即阻断的检查门对应 1 个故意失败样例

验证门禁有效性

EXPECTED

expected fixtures

预期 gate检查门结果
PASS / FAIL + reason codes原因码

锁定预期行为

核心洞察：负例 fixturesNegative Fixtures：故意设计的失败样例，用于验证门禁有效性的治理优先级 = 代码测试Code Tests：单元测试/集成测试

Part 4 · 集成与配置

配置体系

Profile 体系：可配置装配

四层叠加，可收紧不可放松

1

Risk Overlay（风险叠加层）

riskClass 决定门禁强度、restricted 标签与审批流程

2

ContentType Overlay（内容类型层）

typeSpecific 规则 + 角色增删 + 必交付机读合同

3

Org/Repo Policy Overlay（组织政策层）

组织级或仓库级安全与合规政策覆盖

4

Task Override（任务级覆盖）

仅允许收紧；放宽必须走正式 waiver 申请

核心原则：任何层级只允许收紧，禁止放松 —— 这是防止配置漂移的关键约束

Part 4 · 集成与配置

配置体系

Task Dials：任务旋钮

同一骨架，按次调参——从轻量速推到深度评审，一套体系覆盖全频谱

旋钮	选项	影响
creativity	low / medium / high	是否要求 moonshot option
riskTolerance	low / medium / high / critical	评审侧风险权重与决策阈值
generality	narrow / medium / broad	option 适用范围与可复用性要求
speed	fast / normal / thorough	角色数量与阻塞问题上限
reuseFirst	true / false	是否强制复用已有组件
safety.strictness	low / medium / high	扫描门禁覆盖范围与深度

Part 4 · 集成与配置

配置体系

动态采样：按需扩容

固定基线矩阵（risk × budget）

Risk \ Budget	fast	normal	thorough
Low	R1=3, J=3	R1=5, J=3	R1=7, J=5
Med	R1=5, J=3	R1=7, J=5	R1=11, J=7
High	R1=7, J=5	R1=9, J=7	R1=15, J=9

扩容触发信号

!

多样性不足

options 缺方向性不同的候选

!

证据不足

关键 claim 无证据指针

!

分歧过大

judge pick 分散，无法靠证据裁决

停止条件：边际增益变小 / 覆盖达标 / 预算触顶

Part 4 · 集成与配置

生态集成

生态集成：被其它 Skill 调用

触发模式

手动

用户显式表达"要决策闭环"

自动

上游 Skill 遇到阻塞问题或门禁 FAIL

集成点

PRD 文档生成器 → 关键争议需多角色裁决
架构文档生成器 → 技术选型存在多解
开发计划生成器 → 并行边界不清
文档质量门禁 → FAIL 需要方案裁决

输出物

decision-report.md

决策过程与结论报告

requirements.md

从决策中提炼的需求

decision.json

机读决策记录（可选）

关键接口：decision.json 是机读格式，供下游 Skill 直接消费

总结

下一步

从研究到 Skill：Spec Pack 概览

已产出

30 个案例全流程闭环证据
通用流程骨架（7 状态机）
10 类内容类型 Profile配置档案：按内容类型装配角色、评审标准与门禁强度 v1
安全门禁 + 扫描规则 + 负例 fixtures
机读 Schema数据结构定义：规范文件中字段、类型、约束 v0.1

下一步

1

生成目录结构

.claude/skills/swarm-decision/

2

编写 skill.md + templates/

Prompt Contract / Proposal / Verdict / Decision Report

3

制作 examples/ + schemas/

工程决策 × 1 + Creative × 1（含负例说明）

从"两轮并行提案评审"到"可复用的决策能力"，一步之遥

通用两轮并行提案评审决策流程

什么是 Swarm Decision？

提案发散

观点变选项

独立裁决

为什么需要它？

30 个案例横跨 3 大领域

研发 / 产品

架构决策

写作创意

内容结构

流程骨架

角色体系

10 类内容类型

安全门禁

Skill 生成

系统架构 — 一张图理解 Swarm Decision （点击放大）

两轮并行流程骨架

各阶段职责

裁决与交付

Round 1：独立发散

汇总阶段：观点变选项

Option Cards

对比矩阵

阻塞问题清单

Judging：全新角色独立裁决

Judge Tech

Judge Product

Judge Risk

Verdict 格式（每个 Judge 必须输出）

Decision Report：可交付报告

必须包含的 8 个章节

核心原则

为什么需要 10 类 Content Type？

三域覆盖

10 类 Content Type 总览

External Comms：审批链路

必备字段

Fail-Closed 规则

Ops/Incident：危险操作门禁

Execution Intent：三级水位线

Danger Zone — 写操作必须包含

Spec：合同化治理

schema + examples = 可回归合同

Fail-Closed 规则

6 大安全威胁模型

过早写入

误把示例当执行

证据二次泄漏

越权承诺

权限不可追责

治理退化

Write-Intent Gate写入意图门禁：防止误写机制，强制显式授权

两阶段原则

DISCUSSION / RESEARCH讨论 / 研究态

APPLY / EXECUTION执行态

写入意图协议（4 要素）

dry-runDry-Run：仅输出计划，不实际写入 默认

--apply显式确认标记

nonce / token一次性令牌：防跨对话误触发

scope范围化授权：限定允许写入的目录/文件类型 约束

SSOTSingle Source of Truth · 单一事实来源 单写者 + 并行边界

单一事实来源

三态裁决 — 并行资格

扫描门禁：自动拦截风险

负例 Fixtures：最强防退化手段

pass fixtures

fail fixtures

expected fixtures

Profile 体系：可配置装配

四层叠加，可收紧不可放松

Risk Overlay（风险叠加层）

ContentType Overlay（内容类型层）

Org/Repo Policy Overlay（组织政策层）

Task Override（任务级覆盖）

Task Dials：任务旋钮

动态采样：按需扩容

固定基线矩阵（risk × budget）

扩容触发信号

多样性不足

通用两轮并行
提案评审决策流程

dry-runDry-Run：仅输出计划，不实际写入默认

scope范围化授权：限定允许写入的目录/文件类型约束

SSOTSingle Source of Truth · 单一事实来源单写者 + 并行边界