Ludus 沙盘引擎：因果推演与敏感性分析

沙盘应该回答什么问题

大多数”AI 预测”类产品试图告诉你”未来会怎样”。Ludus 的沙盘不干这个。

它回答的是另一个问题：“如果某个关键变量变了，我的推荐会翻吗？”

这两个问题的区别很大。前一个要求精确预测——没有人能做到。后一个要求系统告诉你建议的边界和脆弱点——这是可以做到的。

输入：从报告到因果图

沙盘不从空白开始。它的初始图由深度报告自动生成：

# 报告中的结构化建议
{
  "recommended": "优先进入救援市场",
  "conditions": [
    "3 个月内确认 2 个以上采购意向",
    "采购周期不超过 12 个月",
    "复杂地形能力在试点中达标"
  ],
  "keyFactors": [
    { "factor": "救援需求强度", "impact": "high", "direction": "positive" },
    { "factor": "采购周期", "impact": "high", "direction": "negative" },
    { "factor": "安全责任风险", "impact": "medium", "direction": "negative" },
    { "factor": "地形适应能力", "impact": "medium", "direction": "positive" }
  ]
}

# 系统自动生成初始因果图
# 节点：救援需求强度、采购周期、安全责任风险、地形适应能力、...
# 边：正向/负向 + 强度 + 延迟 + 关系质量

自动生成的节点和边都标记为 draft 状态，带来源理由，用户可以逐条确认、修改或否决——在正式图确认之前，不能运行正式 SimulationRun。

节点与边模型

每个节点携带完整的元数据：

属性	说明	示例
type	八类之一	`external`（外部因素，不可控）
baseline	当前基线值	9 个月
unit	业务单位	`months`
normalization	归一化方向	`inverse_linear`（越大越差）
controllability	可控性	`uncontrollable`
evidenceStatus	证据状态	`conditional`（有证据但不充分）

关键设计：节点使用业务单位（月、百分比、金额），在引擎入口统一转换到 [0, 1] 归一化空间，输出时再转换回业务单位。inverse_linear 用于”值越大越差”的指标——采购周期越长，得分越低。

每条边额外记录 delaySteps（延迟步数）和 relationshipQualityScore（关系质量）——系统优先展示高影响低质量的关系，提示用户这些边最值得验证。

推演引擎

引擎设计遵循三个原则：

确定性可复现

每个 SimulationRun 绑定精确的输入快照——图版本、情景参数、引擎版本、数据源版本。相同输入 = 相同输出。inputHash 由这些绑定字段精确计算：

{
  "graphVersionId": "gv_007",
  "scenarioVersionId": "scv_003",
  "engineVersion": "1.0.0",
  "seed": null,  // 确定性引擎不需要 seed
  "calculationTimestamp": "2026-07-23T10:00:00Z"
}

三情景推演

引擎支持三种预设情景切换：

情景	说明	调整方式
乐观	关键外部因素向好	上行 20%
基准	保持当前基线	不动
悲观	关键外部因素恶化	下行 20%

用户也可以手动拖拽每个变量的滑杆，在三情景之间做精细的敏感性分析。

翻转条件识别

这是沙盘最有价值的功能。对每个条件化建议，引擎计算”翻转阈值”——变量到达什么值时建议会改变：

# 引擎输出
{
  "recommendation": "优先进入救援市场",
  "flipConditions": [
    {
      "variable": "采购周期",
      "currentValue": 9,
      "flipThreshold": 14.5,
      "distance": 5.5,
      "unit": "months",
      "direction": "如果在基准情景下采购周期 > 14.5 个月，建议将翻转为家庭服务"
    },
    {
      "variable": "安全责任风险",
      "currentValue": 0.4,
      "flipThreshold": 0.72,
      "distance": 0.32,
      "unit": "normalized",
      "direction": "如果安全责任风险评估 > 0.72，建议将翻转为继续研究"
    }
  ]
}

翻转条件会被映射回业务单位，不是抽象分数。用户看到的是”如果采购周期超过 14.5 个月就得改主意”，而不是”风险因子达到 0.72”。

图版本管理

沙盘支持实验性工作流：

confirmed graph v1 (基线)
    ↓
创建实验分支 branch-optimistic
    ↓
在分支上编辑节点和边 → 保存 branch-optimistic v2
    ↓
运行 SimulationRun 对比 v1 vs branch-optimistic
    ↓
如果满意 → 把 branch-optimistic 提升为当前 confirmed graph
如果不满 → 保留实验分支或删除

回滚是非破坏性的——从历史快照创建新当前版本，不覆盖也不删除历史版本。undo/redo 和版本比较在 confirmed graph 工作副本上操作，不影响已发布的图版本。

不可降级约束

沙盘引擎有三条硬约束：

未确认图不能正式推演：只有所有节点和边都经过人类确认的图版本，才能运行正式 SimulationRun。draft 图只能跑 experimental 模式。
不可复现的推演不成立：如果两次相同输入产生不同输出，SimulationRun 状态进入 error，不能用于正式建议。
结果必须带免责声明：每个推演结果必须标注”用于因果推演和敏感性分析，不是精确预测”。这是 UI 层面的强制约束，不是软建议。

Scrum 与 Review 闭环

沙盘推演结束后，用户可以：

把推演结论转化为 CandidateRevision——提交到决策档案的候选变更
把翻转条件转化为验证行动——“在 3 个月内确认采购周期是否 < 12 个月”
在决定签署后保存 Review——复盘时区分”沙盘推演对了但执行错了”和”沙盘推演本身有问题”

注意 Review 不做”事后诸葛亮”——它不拿实际结果去和沙盘推演的”预测”对比，因为沙盘明确说自己不是预测工具。Review 关注的是：当时的决策过程是否充分、假设验证是否完成、退出条件是否被触发。

最后

沙盘引擎是 Ludus 里代码量最小的模块，但思考时间可能最长。

核心设计就两个判断：不声称预测未来。把”什么条件下你会改变主意”作为核心输出。这两个判断决定了整个模块的方向——不是做一个更强大的预测引擎，而是做一个让用户更清楚自己判断边界的工具。

说到底，Ludus 想做的也不是帮你做更好的决定，而是让你更清楚自己正在做什么样的决定。

丽·芙