2026年9月16日週三
先说清楚为什么会有这两次重构——不然下面的失败清单，看起来就像无缘无故的折腾。
一切从一个念头开始：做一个会聊天、会记得人的 AI（类似 Neuro Sama）。 不是客服式问答机，不是复读机，而是一个有人格、有记忆、有情绪、能跟我拌嘴唠嗑、下了播也愿意陪观众聊天的存在。参考的是全世界的 AIVtuber 们——但不想抄作业，想自己养一个。
于是有了三次命名，同一个执念：
方向从头到尾没变过：人格延续、记忆沉淀、长期观众关系——像人一样记得你。 这个执念本身没有错；错的是框架搭了两次，两次都倒在同一类问题上。下面进入正题。
写这篇之前，先承认一件事：翻完两次重构的失败记录，我发现大部分问题最后都能收敛成同一个道理——我们一直在补“这一处”，却很少问“为什么每次都断在这一类”。
第二次看起来纪律严明多了，对吧？但结果是：两次都没有一场真直播。第二次最长的“直播” 100 秒，真实弹幕 9 条，记忆 / 梗 / 总结全部 0 行。
1. 真正重复的不是“错”，是“配置分层没有唯一权威规则”。 第一次：运行期值、真凭据、真实房间号被写进了模板 config.json（放错边）。 第二次：provider 端点被从模板抹掉 → 回退官方端点 → 401，AI 完全不回复（放没边）。 同一个根因，两个相反方向，两次都栽。第二次还只修了一半（本机路径迁走了，端点没迁）——修一半的分层规则，等于没修。
2. 两次都拿“测试全绿 + 审阅包齐”当完工定义，结果都没有“能播且体感达标”。 第一次 92 条；第二次 657 条。都没有真直播。测试绿 ≠ 能播。
3. 同一个结构病（单线程 + 长任务）两次都没在架构层解决。 第一次：AI 唱歌同步跑在单线程里 → 点歌全暂停。 第二次：worker 单线程 + 内联 sleep → 弹幕摄入阻塞、主动引擎饿死；音色冷启动十几秒被焊在每一次说话上。 第一次是“调度问题”，第二次是“架构问题”，本质同一条。只换模块不换并发模型，会第三次栽。
三个机制层面的解释：
每张卡开工前抄一遍防复发检查表：配置归属 / 交付面 / 端到端用例 / 降级可观测 / 长任务位置 / 原子性 / 行为判据 / 开关与实测 / 数字断言（9 项）；完工后按 8 项验收（含 golden 对拍、回滚实测）。
第三条路，不再补丁式填坑，先立规则再动刀。