界面也是一种承诺

按钮上写着"保存"，就是在承诺：你输入的内容不会悄悄消失。

进度条开始移动，就是在承诺：系统知道任务走到了哪一步。

弹出确认框，就是在承诺：最终决定权还在你手里。

界面里的每一个状态，都是一句承诺。写界面的人往往只把它们当作视觉元素，但用户是把它们当作契约在读的。

每个状态都在建立预期

承诺不一定非要说出口。它藏在细节里：

• 禁用态承诺"现在不能点，并且系统知道为什么不能"
• 加载态承诺"已经在处理，不是卡住了"
• 成功提示承诺"结果已经落定，可以放心离开"
• 可撤销承诺"就算你改主意，也能回到刚才"

反过来，缺少某个状态，也是一种承诺——只是承诺的内容是"我不打算告诉你"。一个点了之后没有任何反馈的按钮，承诺的是"你的操作是否被接收，取决于你自己猜"。

这也是为什么"先做交互再做状态"通常会出问题：如果不知道系统此刻处在什么状态，就不知道该呈现什么，也不知道该承诺什么。

失败不是承诺的终点

真正可靠的界面不只展示成功。它必须回答四个问题：

1. 哪里失败了——不是"出错了"，而是哪个步骤、哪个字段
2. 已经发生了什么——有没有副作用，有没有写进去一半的数据
3. 能不能重试——重试是否安全，会不会重复执行
4. 下一步由谁决定——是系统自动兜底，还是交给用户选

一个只说"操作失败"的提示，等于把这四个问题全部退给了用户。看起来是省事，实际上是把成本转嫁给了最没有信息的一方。

写 Agent 产品时这一点尤其明显：模型调用可能超时、工具可能返回意外结构、上下文可能超限。如果界面只负责显示"正在思考"，用户既不知道该等还是该中断，也不知道中断之后会发生什么。状态机先画清楚，界面才有东西可承诺。

承诺要能被验证

承诺的价值在于可验证。几个容易被忽略的检查项：

• 按钮文案和它实际做的事是否一致（"保存"是否真的持久化了）
• 进度是否真实反映进度，而不是一段无意义的动画
• 撤销是否真的回到原状，包括那些界面上看不到的副作用
• 错误提示里是否包含了用户下一步真正需要的信息

这些都可以逐条过一遍。它们不难改，难的是承认：一个好看但不能兑现的界面，比一个朴素但准确的界面更贵。

少承诺，承诺了就做到

界面设计里有一种常见的过度承诺：为了显得流畅，把状态做得比实际更乐观——进度条走得比真实进度快，成功提示在写入完成前就弹出，失败时用"稍后自动重试"掩盖问题。

短期看体验更好，长期看是在透支信任。用户迟早会发现那个进度条是假的，而一旦发现，他会对界面上所有其他承诺都打上问号。

更稳妥的做法是：承诺少一点，但每一条都做到。不确定就不说进度，做不到就不给"自动重试"的暗示，失败就把失败说清楚。