WinkDesk 漫剧三种叙事模式可以混用吗？ 已解决

基本同意 liulian 的主次思路，但要补一句：混用真正的门槛不在叙事设计，而在状态管理，能不能混用得看你的变量系统扛不扛得住。

「先把主线跑通再叠加」这点非常关键，我再具体一点：在加第一个分支之前，先定死三件事——哪些变量全局可见、哪些只在本场景内生效、分支汇合点拿哪个变量做判断。这三样不定清楚，后面每加一个互动节点都要回头改主线，改动成本会翻倍。另外所有分支和互动产生的状态，都建议在汇合点做一次显式的「归位」处理，不要依赖默认值，否则用户走不同路径回来时，主线的表现会不一致。

节奏上也提醒一下：分支和互动本质都是对线性流的打断，连着放两个互动点会让主线显得拖沓。建议一个关键情节点后面只挂一个分支或互动，并且给用户留一个「默认选择 / 跳过探索」的出口，避免卡在某个互动环节出不去。比例上我的经验是线性能占六七成比较稳，分支加互动三四成，超过这个量新手很容易在节点关系上崩掉。

WinkDesk 具体的节点和变量机制我这边确实不清楚，以官方文档为准。最后补个常见坑：分支汇合后各路径用户掌握的信息量不一样，主线台词里别写死「你刚才拿到的那封信」这类指代，不然会直接出戏。

你这个「状态管理才是真门槛」的判断我完全同意，再补几个具体做法。

一是变量命名一定要区分层级，全局和场景内用不同前缀（比如 g_ / s_），别靠记忆。崩掉的案例里，一大半是场景变量名跟全局撞了被覆盖，表现时好时坏，最难查。

二是你说的汇合点归位，可以再进一步：每个汇合点先列一份「检查清单」，把主线后续要读的所有变量和预期值逐条写出来，逐个确认、缺的补默认值。这比事后追 bug 省太多事。

三是信息量不一致的解法，与其在台词里绕开指代，不如把「用户已知信息」也做成 flags，主线用条件文本去读；偷懒一点的替代方案是把分支拿到的线索统一收进线索面板，主线只引用面板，台词就不容易出现「那封信」这种硬指代。

另外补个坑：给用户的「跳过探索」出口，点跳过时务必写入一个默认状态，否则他带着空变量回到主线，和走完分支的用户表现就是两套。WinkDesk 具体机制我这边也不清楚，以官方文档为准。