最近工作里的会议越来越多。除了参加会议，还要处理聊天记录、会议纪要、邮件、在线文档和各个项目里的临时任务。信息散落在不同的平台里，整理起来很麻烦，很多待办也容易埋在一段聊天或一份会议纪要中。

飞书的产品生态给过我一些启发。在同一个平台里，聊天、会议、邮件和文档之间可以互相连接，用户可以汇总信息，整理每日待办、项目进度和日周报。

我们的办公环境没有这样的条件。IM 是自研的，会议纪要来自腾讯会议，邮件使用自己的服务器，在线文档又采购了另一套产品。多个系统彼此独立，想把一天的信息完整整理出来，需要在不同平台之间来回切换。

所以我开始研究，能不能自己把这些信息连接起来。

一段时间后，我陆续找到了公司 IM 的 CLI 接口、在线文档的 MCP、腾讯会议相关的读取方式，以及通过 Exchange 获取邮件的方法。接下来要解决的问题，是怎样把这些内容汇总、分析，再生成每天需要处理的任务。

我以前做过一个叫消灭 Todo 的应用，这次准备重新改造它。除了接入新的信息来源，也会调整原有页面。

整个改造过程中，我把 GPT 用在需求梳理、方案评审、UI 设计和设计规范整理上，再通过 Codex 修改项目代码、调试页面和完成落地。

这篇文章主要记录其中的前端设计过程。

先把自己要做的东西说清楚

刚开始时，我对这个产品的描述很简单。把不同渠道里的信息集中起来，经过分析后生成 Todo，再使用四象限和番茄时钟帮助我安排工作。

这句话能够表达大概方向，距离一份可以直接开发的产品需求还有一段距离。页面里应该有哪些模块，任务怎样进入系统，AI 在哪个环节参与，四象限和普通任务列表是什么关系，自动生成的任务要不要经过确认，这些内容都没有确定。

所以我先在 GPT 中定义一个产品经理角色，让它通过采访的方式和我沟通。

我最开始写的要求是

你是一个兼具用户思维、全栈开发经验和多年从业经验的产品经理。你需要通过用户描述梳理用户故事，编排产品流程和功能，拆解项目优先级，以最小可行版本为起点，逐步形成完整的产品文档。
沟通过程需要循序渐进，以采访的方式进行需求探索。
以上是我的初步要求。现在要定义这样一个角色，你觉得还需要补充哪些内容？

GPT 根据这段要求补充了用户画像、使用场景、产品流程、页面结构、功能优先级、最小可行版本和技术方案等部分。

接下来，它围绕我的想法继续追问。信息从哪里进入，AI 自动生成的任务需不需要人工确认，同一个任务在多个会议里被提到时如何去重，四象限由用户手动调整还是由系统判断，任务完成后是否需要回写到原始信息来源。

这些问题在最初构思时没有考虑到，放到具体使用场景里以后，产品边界才逐步清晰。

经过几轮沟通，我确认了这次改版的主要功能。它连接多个信息来源，对每天产生的信息进行分析，把其中的任务提取出来，再通过四象限管理优先级，并使用番茄时钟帮助我聚焦每一项任务。

完成第一轮沟通后，我让 GPT 输出一份 PRD。

随后，我重新打开一个对话，把整理好的文档交给它评审

我现在有一份已经梳理完成的 PRD。请站在产品评审的角度，检查其中的逻辑漏洞、缺失场景和需要继续细化的地方。

重新评审后，GPT 又找出一些此前没有覆盖的场景。我根据这些问题继续补充内容，直到 PRD 中的功能、流程和页面关系基本稳定。

不要让一个聊天窗口承担所有事情

在和 AI 长时间沟通的过程中，我遇到过一个比较明显的问题。

如果产品需求、技术方案、页面设计和代码问题都放在同一个窗口里，随着上下文越来越长，GPT 容易混淆。前面已经放弃的方案，可能在后面的回答里重新出现。已经确定的页面结构，也可能因为一次局部修改被重新改写。

后来，我主动拆分不同阶段。

一个对话负责需求访谈和 PRD，一个对话负责产品评审，一个对话负责 UI 设计，代码实现再交给 Codex。

每个窗口只处理一类问题。重新开始时，就把已经确认的文档作为新的上下文交给它。

这种方式也方便管理每个阶段的结果。产品需求记录在 PRD.md 中，最终设计规则记录在 DESIGN.md 中，UI 设计图作为开发过程中的视觉参考。即使对话窗口发生变化，也不会完全依赖聊天记录继续工作。

PRD 完成后，先寻找设计参考

PRD 确定以后，我没有马上让 Codex 写页面，也没有直接让 GPT 输出 DESIGN.md。

我先去寻找喜欢的产品页面和设计案例。参考内容没有固定限制，可以是一张截图，可以是一个完整网站，也可以是某个页面里的局部组件。有时关注整体配色，有时关注导航结构，也可能只关注卡片排版和信息层级。

已经整理好的风格参考

Refero Styles 提供了不同的网站设计风格，也可以查看对应的颜色、字体、组件和设计规则。这类参考适合已经有大概审美方向的情况。

https://styles.refero.design/

找到接近的风格后，可以把它的 DESIGN.md 交给 Codex，让它参考其中的设计语言，再替换成自己的内容。

请读取这份 DESIGN.md。
接下来制作我的个人站时，参考这份设计语言。
只借鉴风格，不复制原网站的品牌、文案和素材。

从真实网站提取设计规则

如果看到某个真实网站喜欢的页面，可以保留网站地址或页面截图。web-to-design-md 这类工具可以从网页中提取字体、颜色、CSS 变量和组件信息，方便 GPT 理解页面使用了哪些设计规则。

https://github.com/Paidax01/web-to-design-md

它会把网页里的颜色、字体、按钮、间距和卡片样式整理出来，变成 Codex 可以读取的设计说明。

适合这几种情况

• 看到一个喜欢的官网
• 想借鉴它的视觉气质
• 不希望 Codex 只看截图猜测样式

基本流程是

1. 找到参考网站链接
2. 使用 web-to-design-md 生成 DESIGN.md
3. 删除对方的 Logo、文案、图片和品牌元素
4. 把剩下的风格规则交给 Codex
5. 让 Codex 使用自己的内容重新设计

参考网站只能用于借鉴风格，不要复制别人的品牌、图片、文案和完整结构。

没有明确方向时，先去参考库浏览

当自己还说不清楚想要什么时，可以先去 Pinterest 和 Page Flows 浏览案例。

Pinterest 适合寻找整体气质、颜色和版式。Page Flows 里有很多真实产品页面和用户流程，可以查看登录、设置、订阅、任务管理、仪表盘和移动端引导等场景。

https://www.pinterest.com/

寻找参考时，不需要某一张图完整符合自己的产品。可以分别关注暗色背景、卡片层级、导航方式和页面留白，再把这些参考一起交给 GPT。

具体怎样组合，由 GPT 根据 PRD 和参考图片重新设计。

让 GPT 根据 PRD 和参考图生成 UI 设计

参考图准备好后，我把 PRD.md 和这些图片一起交给 GPT，让它生成完整的产品 UI 设计图。

这里需要的是接近真实产品页面的高保真 UI 图片。导航、任务列表、四象限、AI 助手、番茄时钟和页面操作区域都要呈现出来，页面里的功能关系也要符合 PRD。

我一般这样描述

请读取这份 PRD.md，并结合我提供的页面参考，为这个产品生成一套完整的桌面端 UI 设计图。
设计图需要真实呈现产品界面，包含导航、任务区域、四象限、AI 助手和番茄时钟等主要模块。页面中的功能关系需要符合 PRD，不能只生成用于表达氛围的概念图。
参考图片用于说明我喜欢的颜色、排版和组件风格。请结合我的产品内容重新设计，不要直接复制参考网站的品牌、文案和素材。
请先生成首页设计图，等我确认后再继续其他页面。

第一版设计图出来后，直接围绕图片判断。哪些区域太拥挤，哪个模块不够突出，导航是否占用了太多空间，四象限是否方便操作，右侧区域有没有浪费页面宽度，这些问题看图比看文字直观。

修改时，不重新描述整个页面，直接指出当前设计图中的具体位置

保留当前左侧导航和整体配色，中间四象限区域需要扩大。右侧 AI 助手缩窄，并增加今日任务进度。顶部信息较多，请降低标题区域的高度。

不同版本可以分别保留有价值的部分。第一版的整体结构、第二版的卡片样式、第三版的右侧区域处理，都可以作为下一版设计的输入。

这个过程可能持续几轮。首页确定后，再继续生成任务管理、四象限、AI 助手、番茄时钟、设置页和移动端页面。逐页确认比一开始生成一张包含十几个缩略图的合集更方便，页面里的文字和细节也更容易看清。

经过几轮生成和修改，最终得到一组相对完整的 UI 设计图。这些图片确定了产品的主要布局、配色、信息密度、组件样式和页面之间的关系。即使图片中还有少量文字错误，也已经足够用于后续设计决策和代码实现。

只看 PRD 时，很难想象页面开发完成后的实际效果。先生成 UI 设计图，可以在写代码之前看到产品的大致形态，也可以提前修改不符合使用习惯的布局。

UI 设计确定后，再生成 DESIGN.md

UI 设计图确认后，再开始生成 DESIGN.md。

这份文档需要分析已经确认的 UI 图片，从中提取颜色、字体层级、布局比例、卡片样式、按钮、图标、间距和响应式处理，再把这些内容整理成 Codex 可以执行的设计规范。

我把最终版本的 UI 图片、PRD.md 和之前使用的参考一起交给 GPT，并说明最终 UI 图片的优先级最高

请根据已经确认的 UI 设计图整理一份 DESIGN.md。
最终 UI 设计图是主要依据，PRD.md 用于核对产品功能和页面关系，其他参考图片只用于补充设计细节。
DESIGN.md 需要写清楚页面布局、颜色、字体、间距、圆角、按钮、卡片、导航、图标、图片使用方式、动效和响应式规则。
请尽量从设计图中提取可以执行的规则，不要只使用简洁、高级、有科技感这类概括。
同时列出开发时需要避免的样式，例如随意增加颜色、使用 Emoji 代替图标、过度使用渐变和阴影。
完成后先停下来，等我确认。

GPT 输出 DESIGN.md 后，需要检查文档和设计图是否一致。

图片里只在局部使用强调色时，文档不应该把它总结成全局主色。桌面端采用比较宽松的布局时，文档需要说明移动端怎样收缩。设计图中的卡片只有轻微边框时，也不应该被写成带有明显阴影的悬浮卡片。

重点检查以下内容

• 页面结构是否符合 PRD
• 主色和辅助色有没有超出设计图
• 字体层级是否清楚
• 桌面端的信息密度是否合适
• 移动端如何调整
• 文档有没有写明需要避开的元素

不要做什么这一部分同样需要写清楚。比如不要随意新增主色，不要使用 Emoji 代替图标，不要使用过量的玻璃拟态，不要给每张卡片都增加阴影，不要为了填满页面添加没有功能的装饰模块。

经过几轮修改，DESIGN.md 会变成一份具体的执行说明。它记录最终设计图背后的规则，方便 Codex 在实现不同页面时维持一致的颜色、间距和组件样式。

把 PRD、DESIGN.md 和 UI 设计图一起交给 Codex

准备好 PRD.md、DESIGN.md 和最终 UI 图片后，再让 Codex 开始修改项目。

第一次指令不需要太复杂，通常说明几个基本要求

请读取项目中的 PRD.md 和 DESIGN.md，并参考最终确认的 UI 设计图重新实现页面。
保留现有业务功能和数据逻辑，先完成前端结构和样式调整。
页面需要适配桌面端和移动端。不要增加 DESIGN.md 之外的主色，不要使用 Emoji 或临时占位图标。
UI 设计图用于对照页面效果，DESIGN.md 用于约束具体设计规则。
完成后启动本地服务，并在浏览器中检查页面。

第一版页面出来后，反馈需要指向具体区域和问题。比如左侧导航占用空间太大，任务卡片的信息层级不清楚，四象限区域在桌面端显得局促，移动端保留了过多辅助信息，或者首页首屏和 UI 设计图差异较大。

页面调整通常分几轮完成。第一轮处理整体布局，第二轮处理组件和间距，第三轮再检查字体、图标、状态反馈和移动端细节。每轮只集中处理几个问题，修改范围更容易控制。

Codex 有时会在修复一个区域时影响其他页面。例如，为了让首页内容更紧凑，它修改了全局卡片样式，设置页和项目页也跟着变化。遇到这种情况，需要先检查样式的影响范围，再决定修改全局组件，还是只覆盖当前页面。

这一阶段和普通的前端走查接近，只是沟通对象换成了 Codex。反馈里带上具体页面、具体区域、当前问题和期望效果，修改结果会稳定很多。

页面观感不一致时，先检查素材

页面结构调整完成后，布局、颜色和组件都接近设计图，整体观感仍可能有差异。继续修改 CSS 没有明显改善时，可以先检查配图和图标。

默认 SVG、风格不统一的插画、临时头像和随手找来的背景图，都会影响页面的一致性。

这时可以继续使用 GPT 或 Codex 的生图能力，根据 DESIGN.md 生成对应素材。例如首页右侧的主视觉、项目卡片封面、空状态插画、背景纹理和产品展示图。

生成素材时，先说明图片在页面里的用途和比例

请根据 DESIGN.md 生成一张用于首页右侧的主视觉图。
画面需要适合横向裁切，主体放在中间偏右区域，左侧保留一定留白。不要出现文字、品牌 Logo 和复杂背景，颜色需要和当前页面主色保持一致。

图片生成后，再让 Codex 放入项目中，调整尺寸、裁切方式和响应式显示。卡片配图也需要统一生成，避免每张图像来自不同的网站。

图标尽量使用同一套图标库。需要定制图形时，统一线条粗细、圆角和视觉尺寸。

这次改版留下的一套流程

这次消灭 Todo 的改版，从需求到页面完成，大致经历了以下阶段。

下面这张图概括了整篇文章的主线。先把需求说清楚，再整理设计参考和设计规则，最后交给 Codex 完成代码实现。

1. 使用 GPT 进行产品访谈，把最初的想法整理成 PRD.md
2. 重新开启对话，对 PRD 做产品评审并补充缺失场景
3. 在 Refero Styles、Pinterest、Page Flows 和其他网站中寻找设计参考
4. 把 PRD.md 和参考图片交给 GPT，生成接近真实产品的高保真 UI 设计图
5. 围绕 UI 图片逐页评审，修改页面结构、布局和视觉细节
6. 确认桌面端和移动端的主要设计方案
7. 让 GPT 根据最终 UI 设计图整理 DESIGN.md
8. 检查 DESIGN.md 与设计图是否一致，补充开发边界和响应式规则
9. 将 PRD.md、DESIGN.md 和最终 UI 图片一起交给 Codex
10. 由 Codex 完成代码实现，并在浏览器里逐页对照设计图检查
11. 继续处理图标、配图、交互状态以及桌面端和移动端细节

这套流程里，我没有承担前端开发和设计规范整理的具体工作。我的主要任务是把需求说清楚，提供参考，挑选合适的版本，判断输出是否符合预期，并指出需要修改的地方。

GPT 负责整理需求、评审方案、生成 UI 设计图、分析最终设计和编写 DESIGN.md。Codex 负责读取这些文档和图片，修改项目代码并完成开发。

PRD.md、UI 设计图和 DESIGN.md 把几个阶段连接起来。PRD.md 说明产品需要实现哪些功能，UI 设计图用于确认页面最终形态，DESIGN.md 则把设计图片转换成可以反复使用的设计规则。

整个过程中耗费时间较多的部分仍然是选择和判断。需要挑选参考图，决定哪一套视觉方向更适合产品，判断 GPT 是否理解自己的审美，也需要在 Codex 完成页面后逐个检查细节。

工具可以快速生成方案，最后保留哪一版、哪里需要删掉、哪些功能应该突出，仍然需要自己作出决定。

经过这次改版，我对 GPT 和 Codex 的使用方式清楚了很多。以后再做新的个人项目，大概还会沿用这套流程。