乐于分享
好东西不私藏

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

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

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

这一步很重要。

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

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

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

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

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

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

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

不过先说清楚:多端体验不是一上来就做电脑端、手机 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 更进一步。

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

多端体验的本质是场景

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

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

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

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

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

下一篇,我们就要进入更关键的问题:

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

登录、同步和数据安全,就不能再绕开了。