前因：这不是“一个项目”，是一个想活着的角色

先说清楚为什么会有这两次重构——不然下面的失败清单，看起来就像无缘无故的折腾。

一切从一个念头开始：做一个会聊天、会记得人的 AI（类似 Neuro Sama）。 不是客服式问答机，不是复读机，而是一个有人格、有记忆、有情绪、能跟我拌嘴唠嗑、下了播也愿意陪观众聊天的存在。参考的是全世界的 AIVtuber 们——但不想抄作业，想自己养一个。

于是有了三次命名，同一个执念：

• dango-live（最初的白纸）：单主播应用，先做一个“会聊天的 AI 角色”——人设、红线、音色、记忆写死在代码里。简单，但动一下就改代码。
• miststar-live（第一次认真搭框架，2026-08）：升级成“平台”。角色系统化，一个 AI 变成一窝角色，换角色即换人设、换音色、换专属记忆；观众画像、世界观梗库平台级共享。这是第一次认真搭框架。
• shiogiri-paw / shiogiri-live（第二次认真搭框架，2026-09）：把“过日子”和“上台表演”拆成两个系统——魂侧管聊天、记忆、串门（像在 Discord 里唠嗑），体侧管直播、弹幕、唱歌（像上台表演）；开播前注入人设、直播中上报事件、下播后沉淀记忆。这是第二次认真搭框架。

方向从头到尾没变过：人格延续、记忆沉淀、长期观众关系——像人一样记得你。 这个执念本身没有错；错的是框架搭了两次，两次都倒在同一类问题上。下面进入正题。

写这篇之前，先承认一件事：翻完两次重构的失败记录，我发现大部分问题最后都能收敛成同一个道理——我们一直在补“这一处”，却很少问“为什么每次都断在这一类”。

背景

• 第一次：miststar-live（2026-08），35 个模块 / 92 条测试 / 没有 git；
• 第二次：shiogiri-paw / shiogiri-live（2026-09），54 个模块 / 16,283 行 / 657 条测试全绿 / 15 张卡审阅包 / 哈希自校验。

第二次看起来纪律严明多了，对吧？但结果是：两次都没有一场真直播。第二次最长的“直播” 100 秒，真实弹幕 9 条，记忆 / 梗 / 总结全部 0 行。

三个最该记住的结论

1. 真正重复的不是“错”，是“配置分层没有唯一权威规则”。 第一次：运行期值、真凭据、真实房间号被写进了模板 config.json（放错边）。 第二次：provider 端点被从模板抹掉 → 回退官方端点 → 401，AI 完全不回复（放没边）。 同一个根因，两个相反方向，两次都栽。第二次还只修了一半（本机路径迁走了，端点没迁）——修一半的分层规则，等于没修。

2. 两次都拿“测试全绿 + 审阅包齐”当完工定义，结果都没有“能播且体感达标”。 第一次 92 条；第二次 657 条。都没有真直播。测试绿 ≠ 能播。

3. 同一个结构病（单线程 + 长任务）两次都没在架构层解决。 第一次：AI 唱歌同步跑在单线程里 → 点歌全暂停。 第二次：worker 单线程 + 内联 sleep → 弹幕摄入阻塞、主动引擎饿死；音色冷启动十几秒被焊在每一次说话上。 第一次是“调度问题”，第二次是“架构问题”，本质同一条。只换模块不换并发模型，会第三次栽。

跨两次的 8 条重复模式

1. 配置分层没有唯一权威规则 —— ⭐ 最该记住
2. 完工定义错位：测试绿 ≠ 能播（两次都缺“行为判据”）
3. 单线程 + 长任务（把“等待”放在关键路径上）
4. “链路断一节，却没有任何测试能发现”——例如说话绑错了模型类型，静默降级直通，角色音色从未生效
5. 文档写的是意图不是实测（第一次测数 70 vs 实际 92；第二次 181 vs 657）
6. 验证环境与交付环境不分（临时路径、调试开关混进交付物）
7. 配置落盘 / 多步写入不原子（靠调用方自觉，漏调即丢）
8. “默认关”纪律保护了回滚，也冻结了能力（10 个能力默认关，全部落卡、全部有测试、全程没跑过）

为什么会重复？

三个机制层面的解释：

1. 制度覆盖了“改代码”，没覆盖“交付后的运行”——没有“跑一段”的验收；
2. 每个失败点都被当成“这一处的问题”来修——没人抽象出“长任务不得占用关键线程”这类原则；
3. 知识留痕的载体太脆——第一次的决策活在一个备忘文件里，第二次的结论分散在十五张卡里。第三次要留下的是“规则”，不是“记录”。

第三次怎么防？

每张卡开工前抄一遍防复发检查表：配置归属 / 交付面 / 端到端用例 / 降级可观测 / 长任务位置 / 原子性 / 行为判据 / 开关与实测 / 数字断言（9 项）；完工后按 8 项验收（含 golden 对拍、回滚实测）。

第三条路，不再补丁式填坑，先立规则再动刀。