心智模型：用户拿错了说明书
把 AI 当搜索引擎、当数据库、当会学习的学徒、当计算器，四种错配四类差评。四段对话找茬，再给空状态示例、边界前置、记忆外显三个纠正手段
本页解决的问题
先给结论「心智模型：用户拿错了说明书」要解决的关键问题是什么？
把 AI 当搜索引擎、当数据库、当会学习的学徒、当计算器，四种错配四类差评。四段对话找茬，再给空状态示例、边界前置、记忆外显三个纠正手段
把品味变成产品可重复的行为。 有用的结果不是一句“我觉得更好”。它应该是一条看得见的规则、一个小例子，以及判断体验何时低于标准的方法。
记录一个前后对比，让别人不用听解释也能看懂质量线。
表面更精致了，却没有减少用户的不确定感。
聊天框长得像搜索框，回答长得像百科，界面像个耐心的客服。用户按外观匹配了四本旧说明书，每一本都会精准地制造一类差评。
当搜索引擎用
当数据库用
当会学习的学徒用
当计算器用
四段对话，事故都已经发生。先判断用户拿的是哪本说明书，判完看解析：解析里带产品对策，诊断只是开始。
心智模型没法靠说明文档纠正，没人读。只能在使用路径上见缝插针地教，而第一个现场就是新会话的空白首屏：用户还没打出第一个字，说明书还没翻开，这一屏写什么，决定他拿起哪本。三种首屏方案，亲手切换，看右边的界面和下面的首问质量怎么变。
学徒说明书的差评词是「说了也不听」。下面两个产品都答应了用户的要求，差别在答应的方式。点你判断能终结这句差评的那一版。
| 型号 | 亮度 | 价格 |
|---|---|---|
| X1 | 800 流明 | 2299 |
| X2 | 1200 流明 | 3499 |
时效类问题是搜索引擎说明书的高发区，找茬第一段对话就是这么翻车的。两版 AI 说的边界内容一字不差，差别只在什么时候说。选更能保住心智的那版。
从「四本错误说明书 · 差评的批发源头」把感觉变成判断
「聊天框长得像搜索框，回答长得像百科，界面像个耐心的客服。用户按外观匹配了四本旧说明书，每一本都会精准地制造一类差评」指出，AI 降低了做出“能用”成品的门槛，读者真正需要练的是看出哪里不对，并把感觉说成可以执行的要求。
观察用户的下一步，而不是只看表面
「四段对话，事故都已经发生。先判断用户拿的是哪本说明书，判完看解析：解析里带产品对策，诊断只是开始」可以转成几个可观察的问题：用户是否知道现在发生了什么，是否知道下一步做什么，出错或空白时能否恢复，以及信息层级是否让重要内容先被看见。
- 差评先查心智 ：用户按旧产品的说明书用 AI，先认出他手里那本，再谈修复
- 空状态别写欢迎语 ：放三条示范正确问法的示例，加一句边界声明
- 记忆要外显 ：「已记住」做成能看、能删的界面实物，口头答应治不了学徒错配
漂亮不等于容易用
把「时效类问题是搜索引擎说明书的高发区，找茬第一段对话就是这么翻车的。两版 AI 说的边界内容一字不差，差别只在 什么时候说 。选更能保住心智的那版」用在第二个页面或流程上，记录一个具体犹豫点和一个改动后的用户动作；能被观察到的变化，才是体验改善。
从「四本错误说明书 · 差评的批发源头」走到「找茬练习 · 认出用户手里那本说明书」
「四本错误说明书 · 差评的批发源头」先把问题落在「聊天框长得像搜索框，回答长得像百科，界面像个耐心的客服。用户按外观匹配了四本旧说明书，每一本都会精准地制造一类差评」上；到了「找茬练习 · 认出用户手里那本说明书」，讨论继续推进到「四段对话，事故都已经发生。先判断用户拿的是哪本说明书，判完看解析：解析里带产品对策，诊断只是开始」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
评估体验时，把抽象的“好看”或“顺手”换成用户动作：他是否看懂状态、找到了下一步、能从错误中恢复，并且愿意继续使用。
- 「四本错误说明书 · 差评的批发源头」：聊天框长得像搜索框，回答长得像百科，界面像个耐心的客服。用户按外观匹配了四本旧说明书，每一本都会精准地制造一类差评
- 「找茬练习 · 认出用户手里那本说明书」：四段对话，事故都已经发生。先判断用户拿的是哪本说明书，判完看解析：解析里带产品对策，诊断只是开始
- 「最后的要点」：边界声明抢在出错前面 ：时效、算数这类短板提前亮出来，并给工具开关当出路
最后的「最后的要点」把讨论落到「边界声明抢在出错前面 ：时效、算数这类短板提前亮出来，并给工具开关当出路」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
✅ 这一课想和你分享的
- 差评先查心智：用户按旧产品的说明书用 AI，先认出他手里那本，再谈修复
- 空状态别写欢迎语：放三条示范正确问法的示例，加一句边界声明
- 记忆要外显：「已记住」做成能看、能删的界面实物，口头答应治不了学徒错配
- 边界声明抢在出错前面：时效、算数这类短板提前亮出来，并给工具开关当出路
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。