决策路由：Cynefin 框架与 Method Pack 设计

不是模板，是路由

大多数”决策辅助系统”的做法是：给用户一个模板列表——SWOT、PESTEL、五力模型——让他们自己选。

Ludus 不这样做。用户不需要知道什么是 Cynefin、什么是指标驱动决策、什么是情景规划。他们只需要说”我想判断球形机器人优先进入救援市场还是家庭服务市场”，系统从对话中归纳决策类型，自动推荐匹配的方法包。

这个设计基于一个简单的认知：先选方法论的用户，往往会选自己听说过的那个，而不是最适合的那个。

Cynefin：让系统理解”这是什么类型的决策”

Cynefin 框架把决策问题分为五个域：

域	特征	例子	分析策略
Clear	因果关系明确，有标准做法	”选哪个云服务商”	分类 → 响应，快速分析足够
Complicated	需要专家分析，但存在正确答案	”这个技术方案是否可行”	感知 → 分析 → 响应，适合聚焦研究
Complex	因果关系只能事后解释，需要探索	”进入新市场的时机”	探测 → 感知 → 响应，需要完整分析 + safe-to-fail probes
Chaotic	系统不稳定，先稳定再分析	”突发的供应链断裂”	行动 → 感知 → 响应，默认阻断长分析
Disorder	边界不清，无法确定域	”我们到底面临什么问题”	阻断，要求澄清边界

球形机器人市场方向是一个典型的 Complex 问题——变量多、因果链长、只能在事后验证、需要 safe-to-fail 的验证路径。系统据此推荐完整战略分析（full），并强制要求反方审查和脆弱假设检测。

Cynefin gate 在创建正式 AnalysisRun 之前执行，结果冻结到 RunManifest 中：

用户确认 Charter
    ↓
Cynefin Gate 分析
    ├── Clear → 默认只允许 quick
    ├── Complicated → 默认 focused，允许 quick
    ├── Complex → 默认 full，允许 focused
    ├── Chaotic → 阻断，要求先稳定
    └── Disorder → 阻断，要求补充边界
    ↓
冻结到 RunManifest，不可更改

任何 override 必须由人类提交理由并产生 append-only 事件。系统不自动把自己的判断覆盖到人类的决定上。

Method Pack：从方法论到可运行的软件包

Method Pack 是 Ludus 最独特的概念之一。它不是一份文档，而是一个经过编译、验证、有版本号、有内容哈希的不可变软件包。

结构

ways/hardtech-market-direction/1.1.0/    # 方法源，开发阶段可修改
    ├── manifest.yaml                     # 声明版本、适用域、所需输入
    ├── SOURCES.md                        # 上游引用和溯源
    ├── SKILL.md                          # 核心能力描述
    └── ...                               # Prompt、schema、质量门定义

method-packs/hardtech-market-direction/1.1.0/  # 编译产物，运行时只读
    ├── manifest.yaml
    ├── content.json                      # 合并后的完整包体
    └── .hash                             # 内容哈希

方法源在 ways/ 下开发和版本控制。发布前必须通过 Installer 的验证——manifest 完整性、Prompt 诊断、工具权限白名单、路径边界——验证通过后生成带内容哈希的不可变 method-packs/。Worker 和 Router 运行时只读取后者。

六项不变量

第一版方法包定义了六条铁律，不能被任何 Worker 或分析结果推翻：

决策视角先于框架：先确认谁在决策、目标是什么、责任边界在哪，再选择分析框架
致命短板不可补偿：安全、合规、现金断裂等问题不能用 TAM 或其他指标”平均”掉
资源尺度改变策略性质：种子期的结论不能线性外推到天使期
证据分级硬约束：有条件证据只能支撑有条件判断，被驳回的证据不能支撑核心结论
反方发现必须改变产物：魔鬼审查的发现不能只写进附录、不改变建议
决策质量与结果质量分离：保存当时的证据和假设，让复盘能区分坏运气和坏决策

方法路由

Method Router 在 Charter 创建前执行，输入已确认的 Case 档案，输出匹配的方法包和理由：

# Router 输入
{
  "decisionCase": { "question": "...", "facts": [...], "assumptions": [...] },
  "preferredLevel": "full"
}

# Router 输出
{
  "methodId": "hardtech-market-direction",
  "version": "1.1.0",
  "match": "exact",
  "reason": "Hard tech market entry decision with resource constraint and multi-market comparison",
  "bounds": ["Rescue market", "Home service market"],
  "missingInputs": ["Procurement cycle data for rescue agencies"],
  "recommendedLevel": "full"
}

如果匹配结果是 partial 或 unsupported，Router 会返回缺什么、为什么不行，用户可以补充材料后重试，或者选择快速分析（非正式、不生成正式报告）。

做方法包的一点体会

设计 Method Pack 的过程中，我最大的体会是：把方法论变成软件包比写代码更难。

写代码是在实现一个明确的需求。写方法论是在把模糊的人类决策经验翻译成可执行的约束。后者需要你真的理解那个创始人坐在办公室里看着两个方向、手里只有有限信息的处境。

Cynefin 框架帮了大忙，因为它不告诉你”该怎么分析”，而是先帮你判断”你面对的是哪类问题”。这个前置分类的思路，是我在整个项目里觉得最有复用价值的设计。

丽·芙