Memoflow UI 重构实践

记录使用 AI Agent (包括 Claude Code、Codex、Open Design、Google Stitch 和 Antigravity) 对 DailyUse Memoflow 项目进行 UI 重构的实战步骤与经验总结。

#type / howto #status / growing #tech / dev / project / dailyuse

[!info] related notes

Memoflow UI 重构实践

[!IMPORTANT] 提前总结 一次失败的尝试， google stitch 和 opendesign 的复现能力都不太行（open design 主要是三栏面板的交互部分不行， google stich 则是结构都没复刻对）。 后面直接尝试 antigravity，两轮对话（先复刻 chatgpt 桌面端UI，再加入 opendesign 中已经初具样子的原型）就实现 8分左右了。

目标

当前我的这个 Memoflow 项目的 UI 明显有问题，有点不一致，也比较杂乱。因为大致的功能框架已经实现了七八分，所以接下来我准备尝试进行一次重构。

前置条件

这次重置主要基于 AI 工作流完成，首先需要有 AI 工具和 AI Agent，主要用到了：

  1. Cloud Code + Cloud fable 5 模型
  2. Codex + GPT 5.6 SOUL 模型
  3. Open Design AI 设计工具

步骤

1. 先让代码 Agent 做“业务与 UI 信息审计

[!info] 补充 这一步建议用 Claude Code / Codex / Cursor / Windsurf。 目标文档可以叫：UI_REDESIGN_BRIEF.md

提示词

你现在是一个资深产品设计师 + 前端架构师 + 代码审计 Agent。

我有一个已经初步开发完成的应用，当前 UI 可以使用，但我认为信息层级、布局和视觉表达不够优雅。我计划进行一次 UI/UX 重构。

请你先不要修改任何代码，也不要生成新的 UI。你的任务是阅读当前代码库，理解业务逻辑、页面结构、路由、组件、API 数据、状态管理和用户流程，然后生成一份 UI 重构前的业务与界面分析文档。

请输出到：

docs/UI_REDESIGN_BRIEF.md

文档必须包含：

1. 当前应用定位
2. 核心用户是谁
3. 主要页面 / 路由
4. 每个页面的业务目标
5. 每个页面必须展示的信息
6. 可以弱化、折叠、延迟展示或隐藏的信息
7. 用户主要操作路径
8. 当前 UI 的问题
9. 建议的新信息架构
10. 建议的新页面布局
11. 需要保留的组件和状态
12. 改版风险点

分析要求：

- 先阅读路由配置、页面组件、核心业务组件、API 请求、TypeScript 类型、hooks、store、表单 schema 和权限逻辑。
- 不要只根据文件名猜测，要引用具体文件路径。
- 对每个页面用表格列出：
  - 必须展示的信息
  - 可以弱化的信息
  - 可以隐藏的信息
  - 可以移动到详情页的信息
  - 不能删除的交互状态
- 不要修改代码。
- 不要生成视觉稿。
- 不要引入新功能。
- 所有建议都必须基于当前代码中已经存在的业务逻辑。

2. 让 Agent 生成页面级重构方案

提示词

请基于 `docs/UI_REDESIGN_BRIEF.md`，继续输出一份页面级 UI 重构方案。

请按页面分别给出：

1. 当前页面目标
2. 用户在这个页面最重要的动作
3. 新布局结构
4. 首屏应该展示什么
5. 次要信息如何处理
6. 表单 / 卡片 / 列表 / 筛选 / 详情区域如何组织
7. 空状态、加载状态、错误状态如何设计
8. 移动端响应式如何处理
9. 哪些组件可以复用
10. 哪些组件应该拆分或重命名

请输出到 `docs/UI_PAGE_REDESIGN_PLAN.md`。

注意：
- 不要追求花哨视觉，优先考虑信息层级、业务清晰度和可维护性。
- 每个页面都要明确「主操作」和「次操作」。
- 删除或弱化信息时，需要说明原因。

3. 让 Open Design 基于分析生成页面设计

提示词

你现在是一个产品型 UI 设计师和 design system designer。

请基于以下文档进行 UI 重构方向探索：

- docs/UI_REDESIGN_BRIEF.md
- docs/UI_PAGE_REDESIGN_PLAN.md

目标不是重新发明产品，而是在保留现有业务逻辑和必要信息的基础上，让界面更简洁、更优雅、更清晰。

请完成以下任务：

1. 提炼当前应用的设计目标。
2. 生成一个 design.md，定义新的视觉语言：
   - 设计原则
   - 色彩系统
   - 字体层级
   - 间距规则
   - 卡片规则
   - 表格规则
   - 表单规则
   - 按钮规则
   - 标签 / 状态样式
   - loading / empty / error / success 状态
3. 基于文档生成 2～3 个 UI 方向：
   - 方向 A：极简工具型
   - 方向 B：现代 SaaS Dashboard
   - 方向 C：更有品牌感但不花哨
4. 每个方向都要说明：
   - 适合什么业务气质
   - 信息层级如何组织
   - 哪些信息被弱化
   - 哪些操作被突出
   - 有什么风险
5. 生成关键页面的 HTML 原型或视觉草案。

约束：

- 不要删除 UI_REDESIGN_BRIEF.md 中标记为“必须展示”的业务信息。
- 不要增加不存在的业务功能。
- 不要为了视觉效果牺牲业务可读性。
- 优先清晰、克制、可维护。
- 所有设计建议都要服务于用户完成核心任务。

[!warning] 注意事项 一开始直接给上面的提示词，让 Open Design 开始进行设计，但是出现了一个问题：Open Design 直接返回了一系列的问题，比如当前的设计是网页原型还是别的什么，还有产品定位等。 这说明 Open Design 并没有真的读取到我上面那两个和 UI 重构相关的 markdown 文档。所以后面又进行了下一步，也就是让强制 AI 去阅读文档的操作。

请先暂停 Quick Brief 流程，不要继续问我“目标用户、目标平台、关键页面范围”等基础问题。

当前项目已经有两份完整文档：

1. docs/UI_REDESIGN_BRIEF.md
2. docs/UI_PAGE_REDESIGN_PLAN.md

在继续生成任何 UI、原型、视觉方案之前，请先证明你已经完整读取并理解了这两份文档。

请严格按下面格式回答，不要生成设计稿，不要给泛泛而谈的建议。

---

## 1. 文档读取确认

请分别说明你是否成功读取了：

- docs/UI_REDESIGN_BRIEF.md
- docs/UI_PAGE_REDESIGN_PLAN.md

如果你没有读取到其中任何一个文件，请明确说：
“我无法读取该文件”
不要根据文件名或上下文猜测内容。

---

## 2. 请总结 UI_REDESIGN_BRIEF.md 中的 12 个关键事实

要求：
- 必须包含应用定位、目标用户、技术平台、主要页面、核心业务路径、当前 UI 问题、新信息架构、必须保留的状态和风险点。
- 每条都要尽量具体，不要写成“这是一个生产力应用”这种泛泛描述。
- 每条后面标注来自哪个章节，例如：Brief §1、Brief §8、Brief §11。

我希望你至少能提到这些事实中的大部分：

- 应用名是知行 Memoflow。
- 它是 AI-first personal productivity operating system，不是普通待办清单。
- Web 和 Desktop 共用 packages/app-vue。
- `/` 和 `/ai/chat` 都渲染 AIChatView，属于重复入口。
- AI 工作台是首页。
- 核心模块包括 Goal、Task、Schedule、Reminder、Repository、Editor、AI、Governance。
- 当前导航有 10 个一级入口 + 2 个底部入口，缺少分组。
- 新信息架构建议按 工作台 / 计划 / 执行 / 知识 / 系统 分区。
- 通知要从一级导航降级为铃铛入口。
- repository 要从“仓库”更名为“笔记”。
- 必须保留 `?dialog=goal&goalId=`、`/note/:id`、`/goals/:id` 等深链契约。
- 必须保留 data-testid、DI 端口、Pinia/composable 门面、AI goal-agent 状态机、编辑器未保存守卫。

---

## 3. 请总结 UI_PAGE_REDESIGN_PLAN.md 中的 12 个关键执行方案

要求：
- 必须覆盖全局页面壳、导航、状态设计、响应式、共享组件、页面级重构和实施顺序。
- 每条后面标注来源章节，例如：Plan §0.1、Plan §1、Plan §15。

我希望你至少能提到这些事实中的大部分：

- 页面壳要统一成 ListPageShell、DetailPageShell、WorkspaceShell。
- 主导航要按 工作台 / 计划 / 执行 / 知识 分组。
- `/ai/chat` 要保留路由 redirect 到 `/`，但从导航删除。
- AI 工作台要把 workflow 生命周期按钮从 composer 迁移到右侧 context panel。
- AI composer 只保留发送、停止、模式切换、模型设置等核心输入功能。
- Dashboard 要从“第二首页”降级为统计与回顾页。
- Dashboard 的 6 张统计卡要压缩成 StatStrip。
- 任务页要从“任务模板管理”改为“任务库”。
- 任务依赖图要从 1400px Dialog 升级为页面视图模式。
- 日程页保留为执行分组默认入口，并新增 EventDetailSheet 留位。
- Repository / 笔记工作区要做阶段 0 UI 收缩，退役多标签、分屏、自包含导出、批量导入。
- 实施顺序是 P0 基建、P1 招牌路径、P2 对齐批、P3 笔记收缩。

---

## 4. 请做一次交叉验证

请列出：

1. Brief 中提出的问题，Plan 中对应如何解决。
2. Brief 中要求保留的契约，Plan 中是否有对应保护。
3. Brief 中的风险点，Plan 中是否有对应的实施策略。
4. 两份文档之间是否存在冲突。
5. 如果存在冲突，请指出冲突点，并说明你会以哪份文档为准。

特别需要检查这些点：

- Brief 说 RepositoryWorkspaceView 的标签页是不可删除交互状态，但 Plan 又根据 Obsidian vault 方向决定阶段 0 退役 TabManager。请解释这个冲突如何处理。
- Brief 说本次移动端不在范围内，Plan 也只处理 Web 窄视口和 Desktop 窄窗口。请确认不要设计原生移动端。
- Brief 说不要新增业务功能，Plan 里唯一允许的加法是日程 EventDetailSheet 留位。请确认不要擅自新增其他功能。

---

## 5. 请输出你接下来会采用的设计约束

请列出至少 15 条约束，必须包括：

- 不新增不存在的业务功能。
- 不删除必须展示的信息。
- 不破坏现有路由深链。
- 不破坏 `?dialog=goal&goalId=`。
- 不破坏 `/note/:id`。
- 不破坏 AI goal-agent 状态机。
- 不把 workflow 状态机重写成新的状态机。
- 不绕过 DI 端口直接请求 HTTP / IPC。
- 不删除 data-testid。
- 不改动业务数据模型。
- 不把 Web/Desktop 共用前端拆开设计。
- 不把移动端 React Native 纳入本次设计范围。
- 不引入新的 UI 框架。
- 不让视觉效果优先于信息层级。
- 不把调试/演示入口暴露到生产导航。

---

## 6. 请把 Quick Brief 表单自动补全

基于这两份文档，请自动补全下面这些字段，不要再问我：

### 我们要做什么？
请你从 Prototype / Live artifact / Slide deck / Image / Video / HyperFrames / Audio / Other 中选择合适项，并说明理由。

### 目标平台
请你从响应式网页、桌面网页、iOS 应用、Android 应用、平板应用、桌面应用中选择合适项，并说明理由。

### 目标用户
请基于文档直接填写。

### 品牌背景
请基于文档直接填写。

### 关键页面范围
请基于文档直接填写。

### 还有什么需要知道的吗？
请基于文档直接填写设计约束、保留状态、风险点和禁止事项。

---

## 7. 最后给出判断

请最后明确回答：

“我是否已经读取并理解了这两份文档，可以进入 UI 设计阶段？”

只允许回答以下三种之一：

A. 已完整读取，可以进入设计阶段。
B. 只读取到部分文档，需要用户重新提供缺失文档。
C. 没有读取到文档，不能进入设计阶段。

如果选择 A，请不要立即生成 UI，等待我的下一步指令。

[!note] 备注 剩余还有很多对话，不过可以使用 gpt 网页版来生成提示词，就省略了。 主要就是让 open design 按顺序 规范 -> 风格 -> 重要页面 -> 全部

验证

为了确保重构后的 UI 不仅视觉合格，且不破坏现有的业务逻辑，可以从以下三个维度进行验证：

  1. 视觉与布局还原度:

    • 对比 ChatGPT 桌面端与 Open Design 原型，检查三栏式布局的间距、配色方案及毛玻璃特效。
    • 拖拽窗口测试：在 1080p 到 4K 宽屏下，核心内容区应自适应拉伸，两侧面板应保持合理比例或固定宽度。
    • 窄屏回退：将视口收缩至 1024px 以下时，主导航和右侧面板应自动折叠为抽屉式收起状态。

  2. 交互契约与逻辑完整性:

    • 验证深层链接契约：直接访问 ?dialog=goal&goalId=xxx、/note/xxx 等路由，验证弹窗或编辑器页面是否能正常唤起并加载对应数据。
    • 状态保留测试：编辑文档时触发路由切换，应正确触发“未保存守卫”弹窗；AI goal-agent 状态机状态在 UI 刷新或重绘时应能维持原有状态。
    • 自动化测试检查：运行 npm run test:unit（或 vitest），确认所有含有 data-testid 的测试用例依然可以通过，证明 AI 重构没有误删测试锚点。

  3. 接口与通信规范:

    • 确认所有组件数据依然通过 Pinia store 或 Composable 门面流转，没有绕过 DI 端口直接向 HTTP 或 Electron IPC 发起请求。

常见问题

Q: 为什么 Google Stitch 和 Open Design 生成的原型难以直接用于复杂三栏布局的复现？

A: Stitch 与 Open Design 更侧重于静态页面的草图渲染或简单的两栏交互。对于知行 Memoflow 这种涉及 Pinia 业务状态机、右侧 context panel 以及未保存拦截器等动态行为的复杂三栏结构，设计工具缺乏状态描述契约，因而无法自动复刻复杂的逻辑交互。在此类场景下，推荐使用 Open Design 快速探索视觉和色彩系统，然后将其交由 Antigravity 这种具备上下文理解与多轮微调能力的 Agent 进行还原。

Q: 如何保护已有开发契约（如 Pinia 状态、data-testid 等）不被 AI 在重构时误删或覆盖？

A: 必须在前置步骤中让 AI 执行“业务与 UI 信息审计”并生成 docs/UI_REDESIGN_BRIEF.md。在该文档中，明确定义需要保留的交互状态、路由参数和 data-testid 锚点。在将重构任务指派给编写 Agent 时，将这份 Brief 作为最高约束输入，并强调“三不原则”（不修改数据模型、不删除 data-testid、不绕过 DI 直接请求端口），以此确保重构安全。

Q: Electron 桌面端和 Web 共享前端包（packages/app-vue）的重构如何进行响应式调试？

A: 统一使用 Web 的窄视口（通过 Chrome/Edge 开发者工具模拟不同宽度，如 375px、1024px、1400px）来验证布局折叠。由于 app-vue 在 Web 和 Electron 中共享同一套样式系统，只要 Web 端的窄视口自适应逻辑运转正常，Electron 窗口大小调整时的表现就会保持一致，无需频繁在 Electron 原生窗口中进行打包和热更新测试。

创建于 2026/7/12 更新于 2026/7/16