上一篇 44岁被裁后用AI写鸿蒙App(4)：UIDesignKit UI------光感玻璃 + 流光交互实战44岁被裁后用AI写鸿 - 掘金
我把 App 改成了"聊天即操作"模式。然后发现了很多问题。 有些是预期内的，有些让我重新思考"对话式 UI"的边界。
一、一个大胆的想法
如果你用过 Cursor、Claude Code、或者我前面几篇写的 Hermes Agent，会发现它们的共同特点：
它们没有传统 UI。 没有菜单栏、没有工具栏、没有向导弹窗。你打开它，就是一个输入框 + 一个对话界面。你说"帮我查一下今天的天气"，它就去做。
我一开始做 my-parents-helper 时就在想这个问题：
老人学不会复杂的 App 操作。但如果 App 根本没有"操作步骤"呢？
所以我把 App 设计成了 Agent CLI 模式------就一个页面，一个对话输入框。打开 App，说话就行：
- "明天早上八点提醒我吃药"
- "今天天气冷不冷"
- "帮我给女儿发条消息说我挺好的"
不需要导航栏，不需要按钮层级，不需要学任何操作步骤。
在 feat/agent-native 分支上，我甚至做了一次更彻底的尝试：把几乎所有功能入口都收进了对话。 设置页面、家庭成员管理、提醒创建------全走对话。
这个想法很吸引人。但当我真的用了一段时间之后，我开始发现事情没那么简单。
二、先说说 Agent CLI 到底好在哪里
不是来泼冷水的。在做这个重构之前，我需要先承认它的优点------否则我一开始就不会选择这个方向。
好处 1：零学习成本
老人不用学"点哪里"。"想起要做什么 → 打开 App → 说出来"------这就是全部操作。不需要记忆。
好处 2：全场景覆盖
对话可以处理任何问题。传统 App 每个功能对应一个入口，但老人的需求是随机的、不可预测的。对话没有这个限制------只要 AI 够聪明，什么都能答。
好处 3：自然语言 > 复杂的菜单路径
一个用药提醒，传统 App 可能要你：
- 打开"提醒"模块
- 点"新增提醒"
- 选择"用药"
- 填入药品名 -> 选择时间 -> 选择"重复"
- 确认
对话式："明天开始，每天早中晚三次提醒我吃降压药"------一步到位。
三、但也遇到了三个实打实的问题
问题 1：有些操作，对话比点按钮慢
这是最反直觉的发现。
如果我问你"把 Wi-Fi 开着"，你更倾向于：
A. 说一句"请帮我打开 Wi-Fi"（等 AI 理解 → 等执行 → 等确认） B. 直接按一下那个开关按钮
答案显然是 B。对于简单、确定性的操作，物理交互永远比对话快。
老人其实也一样。如果你的 App 能把"吃药提醒"以一个大按钮的形式放在首页，她点一下比说话更省事。不是因为按钮比对话先进，而是因为某些操作的交互成本，对话 > 点击。
问题 2：对话没有"可见性"
传统 App 的 UI 天生告诉你一件事：这里能做什么。
你打开一个 App，看到菜单栏，你就知道"哦，有这些功能"。
但对话式 UI 没有这个"可见性"。老人打开 App，只看到一个输入框。她可能想不起来"还能设提醒"，可能不知道"还能查天气"。如果她不说，AI 再聪明也帮不了她。
OpenAI 在发布 GPT-4o 时展示的"对话手机"概念很酷，但你注意它的演示场景：都是用户主动提出请求。问题是，用户不知道自己能请求什么的时候怎么办？
问题 3：AI 的"不确定感"在关键场景是致命的
试想一下：如果老人含糊地说了一句"帮我弄一下那个药的事情"------AI 猜错了，设了一个错误的提醒。后果可能是没吃药、多吃了一次，这都是有实际风险的。
传统 UI 在这方面的优势是：它是确定性的。你点"新建提醒"，系统打开一个表单，每个字段清清楚楚。填错了也要怪你自己没看清。
AI 的"推测"会带来结果的不确定性。在"提醒吃药"这类场景中，不确定性可能是不可接受的。
四、所以我最终的结论是：混合模式
经过一段时间的使用和反思，我现在的做法是：
用对话覆盖 70% 的场景，用 UI 覆盖剩下 30%。
| 场景 | 最佳方式 | 原因 |
|---|---|---|
| 查天气、问问题、闲聊 | ✅ 对话 | 速度快，交互自然 |
| 创建提醒、发送消息 | ✅ 对话 | 复杂参数用自然语言一步到位 |
| 开关设置（开启 Wi-Fi） | ❌ 直接按钮 | 点击比说话快 |
| 查看闹钟列表、任务清单 | ❌ 列表 UI | 可视化比对话逐条读更高效 |
| 高风险操作（删除、修改） | ⚠️ 对话 + UI 确认 | AI 理解 + 用户二次确认 |
具体到 my-parents-helper 中：
- 首页是对话界面，覆盖"问、聊、提醒"等高频需求
- 侧边或快捷入口放置高频操作按钮------吃药提醒、天气、家人联系
- 设置页保留传统表单，不强行用对话替代
这不是"倒退"，而是"务实"。Agent CLI 是一种新的交互范式，但不是万能的。知道什么场景该用对话、什么场景不该用，比"所有功能都用对话"更难。
五、对"Agent 手机"的一些看法
OpenAI 和 Anthropic 一直在推动 Agent 概念。不少科技媒体预测未来的手机可能没有传统 UI，全是对话式 Agent。
我的看法是：对话会是未来 App 的重要组成部分，但不会替代 UI。它替代的是那些"自然语言比点击更高效"的操作，而不是全部。
如果一个 App 的设计目标是"老人 10 秒内能完成一次提醒------它应该优先考虑对话。但如果它的目标是"让用户以最高效率完成一个确定操作"------那还是按钮更合适。
最好的方案不是二选一，而是让两者共存。 我称之为 TAP（Text + Action Pattern）模式：文本对话作为主入口，UI 组件作为补充和确认手段。
六、技术实现上的取舍
在重构到 feat/agent-native 分支的过程中，我做了几个关键决策：
1. Agent 与 UI 状态共享
对话产生的数据直接写进 @ObservedV2 Model。UI 组件通过 @Trace 自动响应------不需要额外的"同步"代码。
typescript
// 对话中"创建一个提醒" → AgentSkill 调用 model.addReminder()
// UI 组件（提醒列表）自动刷新，不需要额外的通知机制2. 关键操作走 UI 确认
对话中发起的"删除"、"修改"操作，先在对话界面展示摘要卡片（ContentCard），然后等待用户点击"确认"或说"确认"才执行。这个确认逻辑是双通道的------点击和语音都可以。
3. Agent 错误兜底
如果 AI 理解错了，提供一个"撤销"按钮。这个按钮通过 @Monitor 监听状态变化触发回滚。
小结
| 观点 | 总结 |
|---|---|
| 对话不是万能的 | 对于确定性的操作，按钮比对话高效 |
| UI 提供可见性 | 用户需要知道"这个 App 能做什么" |
| 混合模式才是答案 | 对话做 70% 的交互，UI 做剩下的 30% |
| 落地比概念重要 | 我在真实项目中验证了两者共存的方案 |
| 技术实现不难 | @ObservedV2 + @Trace 天然支持对话与 UI 状态共享 |
最后想说一句：不要因为"AI 很酷"就强行把所有交互改成交互式 UI。好的设计是知道什么时候不用 AI。
下篇预告
篇 6：踩坑合集------@ObservedV2 + Repeat、编译报错、组件化重构
整个开发过程中遇到最头疼的 10 个 bug 和他们的解决方案。纯干货，适合收藏。
关注我 seal_jing，一个在鸿蒙生态里写 App 的独立开发者。
发布时间：2026年6月 作者：seal_jing，44岁、被裁、血压已恢复正常、正在写代码