JevCode架构模式
用 TypeSafe 构建系统的架构模式。学会以「离散的原子决策」来思考，是发挥它全部价值的关键。
核心理念
TypeSafe 被设计为嵌入到更大的系统之中，用它来做决策。关键技能是：以离散的、原子的决策来思考，再让这些决策组合出复杂的系统行为。
这意味着不要试图让一次调用解决一个复杂业务问题，而应该把它拆成若干个独立判断，再用你自己的代码把它们组合起来。代码里的组合逻辑是确定性的、可测试的、可调的——这正是可靠性的来源。
四个模式
| 模式 | 做什么 | 收益 |
|---|---|---|
| 扇出并行 | 单次调用发送大量问题（包括推测性的），由代码决定哪些是相关的 | 成本、速度 |
| 置信度路由 | 把置信度作为第二决策轴，构建更安全的系统 | 可靠性、安全性 |
| 组合评分 | 把多个分析维度合并成单一分数 | 成本、可靠性、速度 |
| 意图路由 | 分类用户意图并路由到合适的处理器 | 成本、速度 |
它们如何配合
这四个模式不是互斥选项，而是可以叠加的构件。一个典型的生产系统会同时使用多个：
用户请求
│
├─ [意图路由] 先判定这是什么类型的请求 ──────────┐
│ │
├─ [扇出并行] 一次性问出所有可能需要的判断 ──────┤
│ │
├─ [组合评分] 对候选结果按多维度打分排序 ────────┤
│ │
└─ [置信度路由] 高置信度自动执行 / 低置信度转人工 ┘意图路由通常在最前面，因为它决定了后续需要哪些处理链路。扇出并行贯穿始终，因为把问题打包进一次调用几乎没有额外延迟成本。组合评分在需要排序时使用。置信度路由是最后一道闸门，决定结果是自动执行还是升级给人。
设计原则
原子化拆分。 每个问题只问一件事。看起来「一次问完更省事」的复合问题，会让你无法判断模型在哪个部分出错，也无法单独调整。
代码负责组合，模型负责判断。 加权、阈值、分支逻辑都放在你的代码里。这些是你需要能读懂、能测试、能调参的部分。
让不确定性可见。 与其让模型强行给出一个答案，不如用置信度把「不确定」暴露到系统层面，由你的代码决定怎么处理。