当前框架的缺点、风险和补强方向

FishDice 的核心设计很干净，但它的能力边界也很明显：目前完成的是玩法决策闭环，不是资源、UI、场景、服务和目标玩法全链路框架。

主要缺点

问题	风险	建议
配置仍内建在代码中	策划无法独立调规则、权重、候选、模式映射；发版成本高。	把 definition 层迁移到 JSON/ScriptableObject/远端表，但保留现有 validator。
没有生产级资源映射	result key 到图标、动画、prefab、音效的关系尚未定义。	增加 Unity Integration 层，保持 Runtime 只认 key。
UI 只是 Demo	没有 panel 生命周期、导航、层级、动画完成回调、数据绑定约定。	建立 LuckyDicePresentation 或 Presenter/ViewModel，再接项目 UI 框架。
TargetMode 只解析，不启动	核心能产出 `slap_down_normal`，但没有真实玩法启动器。	补 `TargetModeLauncher` 接口和 Unity 层实现。
Lucky Dice 筛选策略写死在 service 中	后续 cooldown、tutorial、活动来源、权重策略复杂后，service 会膨胀。	把 filter 抽成可注册 pipeline，并让 Trace 记录每个 filter 的前后数量。
Trace 目前是内存结果，不是日志系统	线上复盘还缺持久化、埋点、采样和导出协议。	新增 Trace sink 或 adapter，把核心 trace 转接到日志/埋点系统。
异常和失败策略还偏工程化	部分错误通过 exception 抛出，生产玩法可能需要降级而不是中断。	区分配置启动期错误、请求错误、运行期可恢复错误。

先让规则、候选、target mode 从外部数据创建，并保留现有校验链。

定义 TargetModeEntry 到真实玩法模块的启动、完成、失败回调。

补齐 ResultKey 对应 icon/slot/prefab/动画资源的统一表。

不要为了快速接 UI，把 Sprite、Prefab、Canvas、Coroutine 或场景跳转塞回 Runtime。那会破坏当前最有价值的纯核心边界。

不要把新组合直接写成 if normalizedKey == ... 的业务方法。组合增长应优先走规则配置和 matcher/action 扩展。