在狼人杀项目的前端重构中，我选择了现代前端技术栈来构建一个响应式、可维护的游戏界面。本周的主要工作包括技术选型、项目初始化和基础架构搭建。

第二周最大的收获是把“状态机 + SSE 流”真正映射到 Vue 的响应式 UI 上：后端每吐一个 token，前端就能即时更新消息气泡；：流式 UI 的关键是“让用户知道系统在工作”。第 1 周我已经把“大厅 → 创建会话 → 启动游戏 → 进入游戏页”的闭环跑通了，但游戏页当时更偏“展示”。这种“数据驱动 UI”的感觉很强，也让我更理解 Vue3 组合式 API 在复杂交互里的优势。为了让用户

第一周偏“把路修通”：工程化、路由、store、接口先打通，保证最小闭环能跑。第二周偏“把车跑起来”：核心交互（推进/行动）+ SSE 流式体验，让玩法成立。第三周偏“让车更可靠”：抽重复逻辑、做可配置化、补错误提示与防呆，让演示更稳、代码更能继续迭代。我最大的体会是：课程项目看起来是“功能越多越好”，但真实开发往往是“能不能稳定跑、能不能让别人看懂、能不能持续改”。把 baseURL 抽出来、把

若课程采用敏捷叙事，也可以把每一周看成一轮短迭代，每轮都覆盖表中若干列，而不是「前几周只做实现、最后一周只做测试」。预言家等阶段由状态机与「继续推进」驱动即可，前端不必臆造未提供的接口——这在需求边界上是清楚的，也便于和后端同学对口径。这类记录不必正式写到测试用例编号粒度，但养成习惯后，和「软件工程要可追溯」的要求是一致的。：中期开会时可以指着 M3 问「这周有没有往 M3 挪」，而不是只讨论「界