多端体验:电脑整理,手机打勾

第一版待办应用已经能跑通最小闭环：新增任务、看见任务、标记完成、刷新后还在。

这一步很重要。

因为从这一刻开始，它不再只是“页面长出来了”，而是开始像一个真正的小工具。

但你只要把它放进真实生活，就会马上遇到一个新问题：

我不可能永远坐在电脑前用它。

早上坐在电脑前规划一天，可能很适合。

出门路上突然想到一件事，可能只会掏出手机记一下。

去超市时完成了一项任务，也只想在手机上点一下完成。

所以这一篇，我们开始关心多端体验。

不过先说清楚：多端体验不是一上来就做电脑端、手机 App、小程序、平板端四套东西。

对小白来说，那会迅速失控。

更稳的起点是：

先让同一个 Web 应用，在电脑和手机浏览器里都能顺手使用。

多端不是多写几套

很多人听到“多端”，第一反应是多做几个版本。

电脑一个版本。

手机一个版本。

小程序一个版本。

App 一个版本。

这当然也是多端的一种结果，但不是我们现在要追求的起点。

对一个个人待办应用来说，多端的核心其实是：

同一份任务，在不同设备上都能被合适地使用。

注意这里有两个关键词。

第一，同一份任务。

不是电脑里一份，手机里另一份。

第二，合适地使用。

不是电脑和手机长得一模一样。

电脑不是手机的放大版。

手机也不是电脑的缩小版。

它们适合的事情不一样。

电脑适合整理。屏幕大，键盘输入快，适合一次性录入多条任务，调整顺序，做搜索筛选，规划今天和本周。

手机适合行动。它随身带着，适合临时新增一条任务，快速看一下下一步要做什么，完成以后顺手打勾。

所以多端体验的重点不是“完全一样”，而是“在各自场景里都顺”。

先从响应式 Web 开始

如果你是小白，我建议第一阶段先做响应式 Web。

响应式页面的意思是：

同一套网页，在电脑宽屏和手机窄屏下，会自动调整布局。

电脑上可以显示更宽的列表、更完整的筛选区域、更舒服的编辑面板。

手机上则要把内容压缩得更清楚，按钮更好点，输入更直接。

这样做有一个明显好处：

你暂时不用维护多套客户端。

同一套功能先跑稳，再决定以后要不要做小程序或 App。

否则你会很容易陷入一个麻烦局面：

每加一个功能，都要在好几个端重复做一遍。

新增任务要改电脑端，也要改手机 App，还要改小程序。

删除确认要改电脑端，也要改手机 App，还要改小程序。

如果你还没有建立稳定的需求、测试和验收流程，这种复杂度会非常快地反噬你。

对学习 vibe coding 的小白来说，先少一点复杂度，才更容易看清问题。

电脑端和手机端的任务不同

做多端体验时，不要只问：

这个页面在手机上能不能显示？

要问：

用户在这个设备上真正想做什么？

以待办应用为例，电脑端更像“整理台”。

用户可能会做这些事：

• 批量录入今天要做的任务。
• 给任务补备注。
• 搜索以前的任务。
• 按未完成、已完成、今天、本周筛选。
• 调整任务顺序。
• 检查哪些任务需要删掉。

手机端更像“随身卡片”。

用户可能会做这些事：

• 临时新增一条很短的任务。
• 快速查看下一件事。
• 完成以后点一下打勾。
• 在路上删掉一条不需要的任务。
• 看看今天还有几件没做。

你会发现，电脑端和手机端不是功能数量的差别，而是使用姿势的差别。

电脑端可以稍微信息密一些。

手机端必须更直接。

如果你把电脑端的所有内容都硬塞到手机端，用户会觉得挤。

如果你把手机端做得太简陋，电脑端用户又会觉得整理效率太低。

所以多端体验要按场景检查。

一个具体例子：新增任务

我们拿“新增任务”这个动作来拆。

电脑端的新增任务，可以允许信息多一点。

比如：

• 标题。
• 备注。
• 截止时间。
• 优先级。
• 所属清单。

因为电脑端键盘输入方便，用户可能正在认真规划。

但手机端如果一打开新增，就让用户填五六项，体验可能会很糟。

手机端更适合：

• 先只露出标题输入框。
• 用户输入标题后就能保存。
• 备注、截止时间、优先级作为可展开的高级选项。
• 保存按钮足够大。
• 输入完成后键盘行为正常。

这就是多端体验的典型判断：

同一个功能，在不同设备上不一定用同一种展开方式。

你不需要一开始讲出专业术语。

你只要能描述场景：

手机上新增任务要快，电脑上整理任务要全。

Codex 就能据此帮你调整布局和交互。

一个具体例子：完成任务

再看“完成任务”。

电脑端可以在每条任务前放一个复选框。

鼠标点击很精确，问题不大。

手机端就不一样了。

手指比鼠标粗。

走路、坐车、排队时操作也不稳定。

所以手机端的完成按钮不能太小，不能离删除按钮太近。

否则用户本来想完成任务，结果误删了。

你可以让 Codex 专门检查这个场景：

请只检查手机端“完成任务”的交互。

场景：
用户在路上打开待办应用，只想把“买牛奶”标记完成。

请检查：
1. 完成按钮是否足够大。
2. 完成按钮和删除按钮是否离得太近。
3. 点完成以后反馈是否明显。
4. 如果误点，是否容易恢复。
5. 任务标题很长时，完成按钮是否仍然容易点击。

先输出问题清单，不要直接改代码。

这类提示词，比“优化手机端体验”更有效。

因为它把 Codex 拉回到一个真实动作里。

同一份数据比同一张脸更重要

多端体验里最重要的不是界面长得一模一样，而是数据不能分裂。

如果你在电脑上新增了“周五交报告”，手机上看不到，那多端就是假的。

如果你在手机上把“买牛奶”打勾完成，电脑刷新后还是未完成，那体验就会让人不信任。

任务不应该分成“电脑里的任务”和“手机里的任务”。

它们应该是同一份数据，只是在不同设备上被展示出来。

这件事会牵涉到登录、同步和数据安全。我们下一篇会专门讲。

这一篇先记住一个简单判断：

多端体验的底线，是同一件事在不同设备上不要互相打架。

哪怕第一阶段还没有真正做登录，你也要开始这样验收：

电脑端新增任务，刷新以后还在。

手机宽度下打开，同样能看到。

手机宽度下标记完成，回到电脑宽度后状态一致。

这些检查会逼着你早点发现数据设计和交互设计的问题。

让 Codex 先做多端体检

多端体验很适合让 Codex 先做检查，而不是一上来就改代码。

你可以这样提示：

请检查当前个人待办应用的多端体验。

请基于两个真实场景检查：

场景 A：电脑端整理
- 用户在电脑上新增 3 条任务。
- 给其中 1 条补充备注。
- 按未完成任务筛选。
- 搜索其中一条任务。

场景 B：手机端行动
- 用户在手机宽度下快速新增一条任务。
- 把一条任务标记完成。
- 删除一条测试任务。
- 查看任务很多时页面是否容易滚动。

请输出：
1. 通过的地方。
2. 有问题的地方。
3. 每个问题影响哪个场景。
4. 修改优先级。
5. 建议先改哪些，不要一次性大改。

先不要改代码。

这里我建议你先让 Codex 列问题清单。

原因很简单：

如果直接说“优化多端体验”，它可能会大改样式，甚至顺手重构结构。

先列问题，后做修改，你才知道每次改动是为了解决什么。

再让 Codex 分批修改

问题清单确认以后，不要一口气全改。

多端体验最容易发生一种情况：

手机端改好了，电脑端坏了。

电脑端舒服了，手机端又挤了。

所以建议分批修改。

比如第一批只改手机端新增任务：

请只修改手机端新增任务体验，不要改电脑端布局。

目标：
用户在手机宽度下，可以 5 秒内新增一条只有标题的任务。

要求：
1. 标题输入框在手机端足够明显。
2. 保存按钮容易点击。
3. 备注、截止时间等非必填项不要一开始占太多空间。
4. 保存成功后任务出现在列表顶部。
5. 手机端不能出现横向滚动。

修改完成后，请说明改动文件，并给出电脑端和手机端分别怎么验证。

第二批再改手机端列表：

请只修改手机端任务列表体验。

目标：
用户单手操作时，能清楚完成任务，不容易误删。

要求：
1. 完成按钮点击区域更舒服。
2. 删除按钮不要和完成按钮过近。
3. 长标题可以换行，但不能遮挡按钮。
4. 已完成任务要有明确但不过度刺眼的状态。
5. 保持电脑端列表不受影响。

改完后请运行自动化检查或截图，让我确认手机宽度效果。

第三批再回到电脑端整理效率：

请检查并优化电脑端整理任务的效率。

目标：
用户在电脑上能快速浏览、筛选和搜索任务。

要求：
1. 列表信息密度可以比手机端高。
2. 搜索和筛选入口容易找到。
3. 新增任务后不打断当前筛选状态，除非有明确提示。
4. 编辑入口清楚，但不要让列表变得拥挤。
5. 请保留手机端已经验证通过的交互。

这就是和 Codex 配合的节奏：

先定场景，再定范围，再修改，再验收。

手动验收比截图更重要

检查多端体验，不需要一开始就买很多设备。

你可以先用浏览器的窄屏模式模拟手机。

但不要只看截图。

多端体验是用出来的。

你可以按下面流程手动验收：

电脑端：

• 打开应用。
• 新增三条任务。
• 搜索其中一条。
• 标记一条完成。
• 删除一条测试任务。
• 刷新页面，确认状态仍然正确。

手机端：

• 切到手机宽度。
• 新增一条短任务。
• 新增一条很长标题的任务。
• 标记完成。
• 尝试删除。
• 滚动列表。
• 刷新页面。

重点观察这些地方：

• 手机宽度下有没有横向滚动。
• 新增按钮是否容易点。
• 任务标题很长时会不会盖住完成按钮。
• 列表项之间会不会太挤。
• 电脑宽屏下能不能快速浏览任务。
• 刷新后数据是否还一致。

如果你使用 Codex 的内置浏览器或 Playwright 自动化验收，也可以让它帮你截图。

比如：

请用浏览器分别在桌面宽度和手机宽度验收当前页面。

验收动作：
1. 桌面宽度新增任务、筛选、搜索、完成。
2. 手机宽度新增任务、完成任务、删除测试任务。
3. 分别截图保存。
4. 检查是否有横向滚动、文字遮挡、按钮过小、状态不同步。

请把发现的问题按严重程度排序。

截图不是为了好看。

它是帮助你发现肉眼容易忽略的问题。

多端体验的完成标准

这一篇的目标不是把所有端都做完。

而是让你知道，多端体验至少要达到这些标准：

• 同一套 Web 应用在电脑和手机浏览器里都能打开。
• 手机端没有明显横向滚动。
• 手机端可以快速新增和完成任务。
• 电脑端可以舒服地整理、搜索和筛选任务。
• 长标题、空状态、错误提示在不同宽度下都不崩。
• 同一份数据在不同宽度和刷新后表现一致。

如果这些做到了，你的应用就已经比“只能在开发电脑上看一眼”的 demo 更进一步。

它开始进入真实使用环境。

多端体验的本质是场景

做到这里，你会发现一个变化。

我们已经不只是在问“这个功能有没有”，而是在问“这个功能在什么场景下是否顺手”。

这就是从写功能走向做产品的一小步。

对个人待办应用来说，电脑端适合整理，手机端适合行动。

同一份数据在两个场景里自然流动，用户才会愿意真的用下去。

下一篇，我们就要进入更关键的问题：

如果电脑和手机都能看到同一份任务，那系统怎么知道“这是谁的任务”？