开发日志 004：从修补问题转向 v4.0 架构重构

为什么不继续打补丁

原型运行后，问题并不集中在某一个页面或接口：部分人数和阈值被硬编码，个别非法操作没有在规则层阻断；AI 每次行动重新创建实例，跨轮记忆与信念无法持续；轮末反思没有真正接入写入链路；玩家接口会暴露不应公开的身份或任务信息；前端轮询和流式发言也存在状态更新缺口。

这些问题互相影响。只修一个显示问题，无法让 AI 的判断更连贯；只补一条规则，又会在其他硬编码位置产生不一致。因此本次选择从领域边界开始重构，而不是继续维持旧结构。

重构原则

第一，规则引擎必须独立于框架和模型调用，所有状态推进与非法动作拒绝由领域层负责。第二，AI 必须在一局内持久存在，让工作记忆、情节记忆和信念追踪真正跨轮累积。第三，玩家视角的隐藏信息只能在服务端过滤，不能依赖浏览器“看不见”。第四，讨论调度保持串行，避免并发写入投票和上下文继承产生竞态。

在此基础上，后端被规划为 core、agent、llm、api 四个主要层次；前端改用 Zustand 管理对局与界面状态，并将圆桌、议事录、控制面板、上帝视角和复盘拆分为独立组件。

在正式重构前，simplify 分支先清理了旧的重复 Agent 实现与失效代码，并收敛前端共享常量和上下文处理。这个步骤并不直接增加玩法，但降低了旧代码干扰新架构的程度，也让后续模块替换更清晰。

阶段结果

架构审计把“功能清单”转化为可验证的模块职责与测试目标：规则可单测，AI 调用可降级，接口可验证脱敏，前端可通过构建与完整对局验收。这使后续重构不再是一次无边界的大改，而是沿着领域、智能体、API 与界面的顺序逐层落地。