作者：郝子旭（组长）
阶段时间：2026-06-07 至 2026-06-08
本阶段关键词：Figma 风格、Tailwind、桌面端重构、多智能体会话、浮窗体验、前端迁移

---

一、为什么又做了一次前端重塑

6 月 7 日到 6 月 8 日，我对桌面端前端做了一次很大的重塑。

前面几个阶段已经连续打磨过旧版界面：深色主题、拟物化风格、状态栏、聊天滚动、卡片层级都修过。但继续看下去，我还是觉得旧页面体系有一个问题：它是在功能不断增加的过程中逐步长出来的，很多页面都能用，但整体气质和信息组织还不够统一。

研途灵伴的功能很多。聊天、计划、错题、复习、小测、课堂记忆、课程上下文、学习状态、情绪、饮食、报告、设置、后台管理，全都挤在一个桌面端里。如果界面只是把模块摆出来，用户会觉得像在切很多工具，而不是在使用一个完整的学习陪伴系统。

所以 6 月 7 日先做了一次旧前端优化，主要改主布局、侧边栏、标题栏、聊天窗口和全局样式。到 6 月 8 日，我直接把方向定得更彻底：用 Figma/Tailwind 风格的新页面体系替换旧 AntD 页面外壳，重新组织整个桌面端体验。

这个决定并不轻松。旧前端虽然不好看，但它已经接了很多业务。重写页面意味着我要重新处理路由、布局、状态、API、弹窗、图表、通知和 Electron 能力。只要漏掉一个入口，就可能出现“新界面更漂亮，但功能退步”的问题。

我最后还是选择做这次重塑，是因为旧体系继续补下去的边际收益已经变低。很多样式问题不是单个页面的问题，而是整体组件语言不统一：导航、状态面板、卡片、弹窗、图表、聊天输入区各自长出来，越修越像拼接。与其继续在旧结构上打补丁，不如重新整理一套更适合桌面端的页面骨架。

这次重塑前，我也重新盘点了一遍功能范围。登录、建档、四角色聊天、今日计划、错题本、复习、小测、课堂记忆、课堂上下文、学习状态、情绪、饮食、报告、设置、管理端、悬浮窗，这些都不能丢。这个盘点决定了重构不是从视觉稿开始，而是从功能清单开始。

二、从旧 pages 迁到新的 figma/app 体系

这次提交的规模很大，删除了大量旧 desktop/src/pages 和 desktop/src/components/Layout 下的页面与布局文件，同时新增 desktop/src/figma/app 下的一套新结构。

新结构里包括登录、建档、主布局、设置、窗口框架、悬浮窗页面，以及各个业务页面：聊天、计划、错题、复习、小测、课堂、状态分析、情绪、饮食、报告、管理端等。样式层也改成 Figma 风格的主题文件和 Tailwind 相关样式，引入了 Lucide 图标、Recharts 图表和 Sonner 通知。

这个迁移不是只换皮。页面要重新接回现有 API 和 store，原来的业务能力不能丢。比如计划生成和调整、错题详情与掌握度、复习提交、小测作答、课堂记忆、情绪记录、饮食记录、学习状态分析、日报周报、后台管理都要在新页面里继续可用。

这也是这次最费心的地方。视觉重塑很容易做成“新页面很好看，但功能少了一半”。我不想这样。这个项目已经积累了不少业务能力，前端重构必须尊重这些能力，把它们重新安放到更清楚的界面里。

新的 figma/app 体系里，我把页面分成几个层次。最外层是窗口框架和主布局，它负责桌面端的整体骨架；中间是 AppShell、RightPanel、FloatingWidget 这些跨页面组件；再往下才是 PlanPage、ChatPage、MistakePage、ReviewPage 等具体业务页。

这样拆的原因，是希望把“桌面端壳子”和“业务页面”分开。以前很多页面都在自己处理间距、标题、卡片和空状态，时间一长就会不统一。现在主布局负责导航、顶部栏、右侧状态和窗口框架，页面只关注自己要表达的数据和操作。

依赖也做了调整。Tailwind 负责更灵活的样式组织，Lucide 提供统一图标，Recharts 用在图表展示，Sonner 统一通知。它们不是为了追新，而是为了减少旧页面里大量手写样式和不统一反馈。尤其是通知，原来不同地方提示方式不完全一致，切到 Sonner 后，成功、失败、刷新提醒的体验会更集中。

迁移过程中我也保留了一个底线：新页面可以重写视觉，但不能绕开原来的 store 和 API 体系。比如计划页仍然要调用计划服务，错题页仍然要走错题 API，学习状态页仍然要读 state 和 advice，课堂页仍然要连接 course memory 和 course context。这样后续联调时，如果出现问题，也能沿着原有业务链路排查，而不是新旧两套逻辑混在一起。

三、聊天中心改成真正的多智能体会话体验

这次我特别重构了聊天中心。

项目里本来就有四个前台角色：主助手、学习助手、生活助手、心理助手。旧版聊天也支持 persona，但会话体验还不够像真实的多角色系统。6 月 8 日这次改动里，我把聊天中心调整为按智能体隔离的多会话模式。每个智能体都可以维护自己的历史会话，也可以新建独立上下文。

这个改动需要后端配合。原来后端对同一 persona 只有一个会话的限制被放开，conversation service 同步调整，前端 mock、API 和 store 的排序逻辑也改为最近会话优先。这样用户和学习助手讨论一道题，不会影响他在心理助手里的情绪记录；主助手的总入口会话，也不再和专项角色混成一个上下文。

图片上传和截图答疑也被保留下来，流式回复、消息动作、会话历史、角色切换都重新接到新页面里。结合前一阶段做的上下文追问，这个聊天中心更接近项目最初想要的形态：不是一个大聊天框里塞所有内容，而是不同陪伴角色各自承担清楚的任务。

这个改动背后有一个产品判断：四个智能体不应该只是四个 tab。主助手、学习助手、生活助手、心理助手面对的内容不同，用户和它们建立的上下文也不同。学习助手里可能连续追问一道题，心理助手里可能记录一次情绪波动，生活助手里可能讨论饮食和休息。如果它们共享同一个会话结构，用户会很难知道当前对话到底属于哪条线。

所以这次把“多角色”推进到“多会话”。用户可以在每个角色下保留不同历史，也可以新建上下文。这会让会话管理稍微复杂一些，但它更符合真实使用：不同主题不互相污染，后续查找记录也更自然。

后端放开同一 persona 只有一个会话的限制，是这个体验能成立的前提。否则前端再怎么设计，最终仍然只能把所有学习助手消息塞进一个会话里。这个地方也说明，前端重构经常不只是前端的事。一个体验变化，背后可能要改服务端约束、API 排序、store 合并逻辑和 mock 数据。

聊天页面里还有一些小取舍。图片上传和截图答疑必须保留，因为它们是学习助手的重要入口；流式回复也要保留，因为等待模型完整返回会让用户感觉卡住；消息动作按钮不能丢，因为加入错题本、安排复习、保存笔记这些动作是学习闭环的一部分。新界面要更轻，但不能把这些业务按钮省掉。

四、浮窗和桌面感继续往前走

除了主窗口，这次也继续优化了 Electron 浮窗。

悬浮窗是研途灵伴和普通网页应用差别很大的地方。用户学习时不一定一直盯着主窗口，更多时候可能在看课程、刷题或写笔记。浮窗要能常驻桌面，快速开始学习、截图答疑、记录笔记、查看小状态，并且不要打扰。

这次主要处理了透明层、收起展开卡顿、最小化圆圈拖动和窗口尺寸切换动画。新增 collapsed 浮窗移动 IPC 后，收起状态的小圆圈也能更自然地拖动。窗口尺寸切换动画也做了取舍：有些动画看起来精致，但在浮窗这种高频开合的小工具里，卡顿比动画缺失更影响体验，所以我选择禁用尺寸切换动画，让响应更直接。

这个阶段我对浮窗的理解也更清楚了。它不是主窗口的缩小版，而是一个学习现场的快捷入口。它应该轻、稳、少干扰，能把用户从当前学习场景快速带到截图、跟课、笔记和主窗口，而不是抢走注意力。

浮窗还有一个很现实的问题：它会盖在别的软件上。用户可能正在看网课、刷题、写文档，如果浮窗展开收起卡顿，或者透明层挡住点击，就会直接影响学习现场。网页里的一个弹窗卡一下可能还能忍，桌面浮窗卡一下就会变成持续干扰。

所以我对浮窗做了更偏工程化的处理。收起状态的小圆圈需要能拖动，主窗口和浮窗之间要能互相唤起，尺寸变化不能让用户感觉窗口在乱跳。这里的很多工作不体现在页面截图里，但它决定了这个功能能不能长期挂在桌面上。

我也重新看了悬浮窗里的信息密度。它不适合塞太多内容，只需要学习计时、快捷操作、当前状态和返回主窗口入口。更复杂的计划、错题、报告应该回到主窗口。这个边界如果不清楚，浮窗会慢慢变成另一个小主窗口，最后既不轻，也不好用。

五、Figma Make 文案和设计方向沉淀

这一阶段前半段还有一条比较特殊的提交，里面包含了 Playwright 页面记录、Figma Make 前端功能说明文案和一张 UI 截图。这不是业务代码，但它记录了当时前端重塑前后的设计沟通材料。

我把页面模块、功能范围、设计方向和审美约束整理成一份给生成工具看的说明。这个过程也反过来帮我重新盘了一遍前端功能：哪些页面必须保留，哪些状态不能漏，哪些地方是桌面端特有能力，哪些只是普通网页式布局。

这一步对后面的重构有帮助。因为当我明确写出“AI 看不到后端逻辑，所以文案要描述页面、模块、状态和交互”时，我也在强迫自己从用户能看到的角度重新理解系统。前端不是后端能力的附属品，它要把那些复杂链路变成用户能理解、能操作的界面。

我在写这份说明时，特别强调了功能完整性。因为生成工具看到的是描述，不知道后端真实有哪些能力。如果文案只说“做一个学习助手界面”，它很容易生成一个漂亮但空泛的壳子；如果把计划、错题、复习、课堂、情绪、饮食、报告、后台和浮窗入口都说清楚，生成出来的方向才更接近项目真实需求。

视觉方向也在这份材料里一起沉淀。前面我已经试过深色、拟物化、柔化等几轮样式，最后更想要的是一个安静、清楚、有桌面应用质感的界面，而不是普通 SaaS 仪表盘。考研学习软件不适合过度营销化，也不适合把每个页面都做成大卡片展示。它需要能被反复打开、长时间使用。

这份材料虽然不是代码，但它帮助我把“好看”拆成了可执行的约束：导航怎样组织，状态面板放什么，图表如何呈现，聊天中心如何区分角色，浮窗怎样保持轻量，后台如何和学生端区分。这比单纯说“界面要更高级”有用得多。

六、这次重构的风险和取舍

这次重构最大的风险，是范围太大。

一次提交里删除旧页面体系、加入新页面体系、替换样式方案、调整依赖、修改路由、改聊天 store、改浮窗 IPC，还顺手放开后端会话限制。任何一个点出问题，都可能影响启动、构建或业务页面。所以我在写的时候一直尽量保守：能复用已有 API 的地方不另起接口，能沿用已有 store 的地方不重新设计状态层，能保留原业务流程的地方不改后端语义。

另一个取舍是富文本组件。6 月 3 日刚新增过公共 RichTextRenderer，但 6 月 8 日前端体系重塑时，旧 Common 目录被删除，新的 ChatPage 需要在新结构里重新处理 AI 内容展示。这说明重构时很容易把前面刚做过的基础设施推翻。后面继续整理时，需要把新体系里的富文本能力再统一好，避免回到每个页面各自渲染的状态。

构建验证是这次的基础检查。提交里记录了 npm run build 和 git diff --check。它们不能证明所有业务流程都已经联调通过，但至少说明新前端体系在编译层面站住了，补丁格式也没有明显问题。对于这种大范围迁移来说，这是第一道门槛。

真实联调还要继续。尤其是后台页、课堂页、小测、错题详情、复习提交、截图答疑、悬浮窗和右侧状态面板，这些页面都牵着后端数据。新界面写完以后，下一步不是继续加视觉效果，而是拿真实数据一条条走流程。

七、阶段小结

6 月 7 日到 8 日这一段，是一次比较大的前端方向调整。旧版 AntD 页面体系被新的 Figma/Tailwind 风格替换，所有主要业务页面重新组织；聊天中心从普通 persona 切换，变成按智能体隔离的多会话体验；浮窗也继续朝更稳定、更像桌面工具的方向修。

这次改动的风险也很清楚：重构越大，越容易遗漏旧功能。所以我在写新页面时一直对照现有 API、store 和业务入口，尽量让视觉改变不以功能缺失为代价。提交里记录的验证是 npm run build 和 git diff --check，说明这次至少完成了构建和补丁格式层面的检查；后面还需要继续做真实联调，尤其是每个页面的细小交互和后端数据兼容。

做完这次之后，研途灵伴的桌面端更接近我希望的样子：它不是很多页面拼起来的工具箱，而是一个围绕学习、状态、问答和陪伴组织起来的桌面应用。接下来要继续看的，是新界面在真实数据和真实使用流程里是否足够稳。