先解决最大的坑：用户不知道能问什么
GUI 时代，菜单和按钮就是产品说明书，用户扫一眼就知道这东西能干嘛。CUI 把这个安全感拿走了——一个空输入框，能力是隐形的，新用户面对它的第一反应是懵。ChatGPT 首页那几个示例问题、Kimi 的推荐问题、Perplexity 的首页热门话题，干的都是同一件事：用示例代替说明书。
所以第一条原则是引导前置。示例问题不是装饰，是转化率工具。经验上，首屏给了示例的对话产品，首次发送率比纯空框明显高一截。示例怎么选也有讲究：选高频真实需求、选模型答得漂亮的、选能代表能力边界的。把模型答不好的问题放上去，等于花钱请用户来看自曝其短。
管理预期：先说不能做什么
对话的自由度是双刃剑，用户会以为它什么都能干，然后期望落空骂产品智障。聪明的做法是主动暴露边界：Copilot 类的场景里，能力跟着光标上下文走，用户大概知道它只管当前文件；通用助手里，开场白、能力标签、甚至拒答话术都在传递「我擅长什么」。这里有个反直觉的判断：拒答不是失败，含含糊糊编一个错答案才是。用户被明确地拒绝一次，损失的是一条答案；被一本正经地骗一次，损失的是对整个产品的信任。
把纠错成本降到最低
多轮对话里，模型理解偏了是家常便饭，设计要点是让用户纠正起来不费劲：支持追问澄清而不是重开一轮、提供「重新生成」、对关键操作给确认环节。还有个容易被忽略的——上下文要有节制。对话拉得太长，模型开始「忘事」，体验反而崩，该提醒用户开新会话就提醒，Claude 在长对话时提示上下文将满就是这个思路，丑话说在前面比默默变笨强。
该用按钮的地方别硬用对话
我的判断是：纯 CUI 是个过渡形态，成熟产品最后都长成混合式。高频、结构化的操作，按钮永远比打字快——豆包把语音、拍照做成显眼入口，Copilot 在编辑器里给「接受/拒绝」快捷键，Cursor 把改动渲染成 diff 让你一键 apply。对话负责表达意图，GUI 负责确认和高效操作，各干各的强项。见过最蠢的设计，是把「确认/取消」都做成要用户打字回复「是」的对话流程——为了显得 AI，把效率倒退回了命令行时代。
上下文要让用户看得见
多轮对话的另一个坑是「模型记得什么」对用户是黑盒。用户聊了五轮，以为模型全记得，其实关键信息早被截断或带偏了。好的设计是把上下文显性化：ChatGPT 支持编辑历史问题、从某个节点重新分叉，等于告诉用户「上下文从这里改写」；不少产品会把本轮用到的背景（当前文档、选中的文本）以小卡片形式挂在输入框上，用户一眼知道这轮对话基于什么。上下文黑盒是误会之源，显性化之后，「它怎么又忘了」这类投诉会少很多。