第 6 章 · 第 36 讲 · 15:44
模块：M6 产品手感 ｜ 篇章：审美工程收官 + 交互工程开篇
本集解决「好看之后，好用怎么办」：15 项验收清单、三条有出处的判据、体贴清单、三遍验收法、状态三件套。
来源：xueai.miyang.cn（小山学堂 · 洛小山《学 AI 产品，从入门到精通》）
这一集是审美工程的收官，也是交互工程的开篇。
难点从来不是稿子一眼就很差——那反而好办。难缠的是「差不多就行」：稿子第一眼过得去，手就想点通过，糙的地方要到上线之后才扎眼。本集给你一份清单，管住那只手。
三分钟验收，怎么算都不亏：AI 十分钟能出一版稿，你花三分钟验收，这笔账怎么算都划算。
| 篇章 | 管什么 | 验收方式 |
|---|---|---|
| 审美工程 | 好看 | 看：截图就能评审 |
| 交互工程（本集起） | 好用 | 用：把流程走一遍，把坏情况都试一遍 |
| 心理学篇 | 用户的感受 | 走：代入真实用户状态 |
三章各出一张验收清单，配齐了就是上线前的三张清单。
| 组别 | 项数 | 检查什么 |
|---|---|---|
| 层级 | 3 | 一屏只有一个主角，主角三秒内找得到，其余按重要程度递减 |
| 间距 | 3 | 间距是否落在同一套档位，块与块之间有没有呼吸感 |
| 克制 | 4 | 元素数量与颜色数量有没有超出必要 |
| 一致性 | 2 | 差不多一样的元素有没有做成一样 |
| 细节 | 3 | 对齐、对比度、响应时间 |
《About Face 4》第 17 章的判据：每个元素的存在要有理由，每处差异的存在也要有理由。 给不出理由，就删掉元素、抹平差异。
配套手法叫删减测试：把可疑元素去掉，看信息受没受损。书里把话说得更狠：删减东西，直到破坏了设计为止，再把最后去掉的那件加回来。
素材例题：AI 交来的落地页，标题底下压了一条渐变装饰线，怎么办？
答案是 B。 其余三项都是在给一个说不出理由的元素找借口。
《About Face 4》第 17 章引尼尔森的划分：
| 时长 | 用户感受 | 该给什么 |
|---|---|---|
| 0.1 秒内 | 感觉是即时的 | 不需要反馈 |
| 1 秒内 | 思路不断 | 给个细微线索就够 |
| 接近 10 秒 | 开始怀疑 | 必须给出正在运行的信号（转圈加预估） |
| 超过 10 秒 | 焦虑 | 解释慢在哪、给进度更新，做完还要提示一声 |
你手上的操作落在哪一档，决定了要不要给反馈、给什么反馈。
Tufte 的原则：可量化的数据就要量化。 图表把趋势画出来，数字本身也要在场。
《About Face 4》举了 Windows 磁盘属性的例子：饼图给大概印象，已用和可用的字节数照样列出来。
AI 生成的报表页尤其爱犯这个错：曲线画得漂亮，凑近一看一个数都没有，汇报时还得回去翻原始数据。所以只有趋势的周报卡不合格，趋势带数字的才叫交付。
这三条判据（存在要有理由、响应过三道门槛、可量化就要量化）都出自公开的设计经典，你答得出出处，意见才站得住。这在跨职能协作里尤其重要：说「我觉得这个装饰线多余」，对方可以反驳；说「这个元素说不出存在的理由，按删减测试应该先去掉试试」，讨论就变成了可验证的流程。把审美意见翻译成有出处的判据，是让评审从争吵变成流程的关键一步。
能看出、能说清、能验收。
| 类型 | 推荐 | 重点 |
|---|---|---|
| 书 | 《Refactoring UI》 | 把设计规则写成开发者能照做的操作，重点读改稿前后对比图 |
| 书 | 《写给大家看的设计书》 | 亲密性、对齐、重复、对比四条原则，读案例改稿部分 |
| 书 | 《About Face 4》第 17 章 | 本页多条判据出处；只读这一章也够本 |
| 原则 | Dieter Rams 设计十诫 | 「少，但更好」的原始出处 |
| 原则 | Laws of UX | 读 Hick's Law 与 Aesthetic-Usability Effect |
| 规范 | Apple HIG / Material Design 3 | 读 Layout、Typography、Color roles |
| 实践 | Linear.app / Stripe.com | 当阅读材料，用四步法现场拆 |
| 维度 | 审美的病 | 交互的病 |
|---|---|---|
| 暴露时机 | 页面打开的前三秒 | 用起来之后：删错数据、断网、第一次打开 |
| 谁先发现 | 你自己扫一眼就能发现 | 往往是用户替你发现，代价是流失 |
| AI 犯错的样子 | 五颜六色、字号打架，看着就不对 | demo 里一切正常，边界情况全是坑 |
| 验收方式 | 看：截图就能评审 | 用：把流程走一遍，把坏情况都试一遍 |
好不好看一眼能看出来，好不好用要用起来才知道。
AI 把「做出来」变得很容易，它默认交付的交互停在「能跑通」级别：
你验收时点两下觉得没问题，用户用一周就想卸载。
Alan Cooper 在《About Face 4》第 8 章「数字产品的礼仪」里借纳斯和里夫斯的研究，把结论落成一条设计原则：「软件应该像人一样体贴。」
Cooper 的观察很扎心：交互产品惹怒我们的原因通常不在缺功能，在不体贴。
| 体贴的软件… | AI 默认产出的反面 |
|---|---|
| 有预见（预判下一步，提前备好） | 第一次打开一片空白，下一步全靠猜 |
| 会及时通知（进展主动告诉你） | 点了保存没动静，转了圈也没个说法 |
| 不因自己的问题烦你（故障自己消化） | 一断网就把 Error: code 500 端到你脸上 |
| 是自信的，但备好退路（帮你恢复） | 要么删前问三遍，要么删了就真没了 |
| 不问多余的问题（记住选择、给默认值） | 每次打开都把同一个问题再问一遍 |
| 帮你避免低级错误（悄悄拉一把） | 眼睁睁看你误删，然后弹窗说操作失败 |
一个能跑通的待办应用「今日清单」，功能齐全，五处不体贴全藏在一屏里：顶部横幅每次打开都问「要开启夜间模式吗」、工具栏弹一串代码味报错、删除没有确认、归档区点了没反馈。
没有一处是功能缺失，应用照样能跑通，病全出在礼数上。 这正是 Cooper 那句话的意思。
没反馈是病，反馈过度也是病。 Cooper 在第 8 章专门点过名：交互产品爱用不必要的通知向我们炫耀，「文档保存成功！」这种弹窗等着被点掉，除了打断你没有别的作用。
| 方案 | 做法 | 判词 |
|---|---|---|
| A | 每次保存都弹窗庆祝，必须点「确定」才能继续写 | 打断工作流 |
| B | 按钮原地变成「已保存」，角落留一行时间戳 | 手不用停 |
答案是 B。
素材让你回想天天在用的软件，六种不体贴里选一个被折磨得最狠的：空白空态、报错全是代码味黑话、手一滑删了找不回来、点了没反应、同一个问题每次都问、一崩溃写了半天的东西全没了。
这六条你几乎一定中过招。 它们最有价值的地方在于：任何一条，都是你手上这个产品可以立刻改的地方。不要把它当别人的问题——把自己产品逐条对照一遍，通常能找到三处以上可以马上动手的改进。
审美验收看截图就行，交互验收要动手走流程，而且要走三遍，每遍换一个身份。
| 第几遍 | 扮演谁 | 怎么走 | 抓什么病 |
|---|---|---|---|
| 第一遍 | 老用户 | 顺着理想路径把主流程走完 | 存了没动静、问个没完这类日常摩擦 |
| 第二遍 | 倒霉用户 | 故意犯错：删一条、断个网、输错格式、连点两次提交 | 报错像甩锅、删了就没、一崩全丢 |
| 第三遍 | 新用户 | 清掉数据从零开始，第一次打开的每一屏都停下来看 | 空白空态、下一步全靠猜 |
第二遍和第三遍最容易被省略，而 AI 的病恰恰全堆在那里。 demo 给你演示的永远是第一遍：网络流畅、数据现成、路径笔直。你替用户把另外两遍走了，病就在上线前被抓住。
每停一屏问六个问号：这一屏有预见吗？会通知吗？在甩锅吗？备好退路了吗？在问多余的问题吗？会帮我兜住低级错误吗？
AI 生成的界面默认只有一种状态：数据齐全、网络流畅、一切正常。可用户遇到的头一屏常常是另外三种：没数据、在等待、出错了。
这三种非正常时刻恰恰是体验分水岭。
| 状态 | AI 默认的敷衍版 | 该有的样子 |
|---|---|---|
| 空态 | 一片空白，或一行灰字「暂无数据」 | 教下一步：说明这里是干嘛的，给动作入口，最好带示例 |
| loading | 一个干转的圈，转多久都是那个样 | 说进行到哪：内容形状先出来，进度看得见 |
| 错误态 | alert 弹一串代码，或者干脆没反应 | 说人话给出路：发生了什么、为什么、怎么办 |
Cooper 打过一个比方：向店员问路，好店员除了指路还会顺手告诉你更划算的选择。空态就是用户在问路：我到了，然后呢？ 一片空白等于店员耸了耸肩。
好空态回答三个问题：这里是干嘛的、我现在能做什么、做出来大概长什么样。 前两个用一句话加一个按钮解决，第三个给示例数据或模板。
| 方案 | 做法 | 判词 |
|---|---|---|
| A | 列表区一片空白，新建按钮藏在右上角菜单里 | 让人自己找路 |
| B | 「还没有笔记，写下第一条，或者从模板开始」+ 主按钮 + 示例入口 | 说明用途、给入口、备示例 |
答案是 B。
一个干转的圈只传达了一个信息「在忙」，转到第五秒，用户开始怀疑是卡死了。骨架屏先把内容的形状画出来，等于告诉用户马上到了、到了以后长这样；再配一条进度说明，焦虑就压下去大半。
同样等 3 秒：「加载中…」对比「正在拉取最近 30 天的消息…」——后者体贴得多。
Cooper 在《About Face 4》第 15 章对错误信息的立场很硬：老式错误对话框要么责备用户，要么拿技术故障甩锅，多数根本不该出现。 真到了必须说的时候，交代清楚三件事：
三样齐了才算说人话，缺了「怎么办」的错误信息等于把用户堵在死胡同里。
还有一条底线：措辞不能责备用户。 第 15 章的原则是用户视角里没有过错——把「您输入了非法字符」换成「这里只支持字母和数字」，信息一样，态度天差地别。
| 原文 | 病灶 | 三要素改写 |
|---|---|---|
| 「操作失败，请重试。」 | 没说哪个操作；「请重试」是句空话，重试十次照样失败，因为病根在附件大小 | 发生了什么：报销单没提交出去，草稿已经保留。为什么：附件超过了 10MB 的上限。怎么办：压缩一下附件，或者拆成两张单子提交 |
Error 422: Unprocessable Entity | HTTP 状态码是给开发者看的日志，端给用户等于甩锅 | 发生了什么：收货信息没保存上。为什么：手机号少了一位。怎么办：补上缺的那位就能提交，光标已经帮你定位过去 |
| 「您输入了非法字符！」 | 「非法」加感叹号，输个空格就成了嫌疑人 | 发生了什么：用户名还没通过检查。为什么：只支持字母、数字和下划线。怎么办：把空格换成下划线就行 |
| 状态 | 判定标准 | 得分 |
|---|---|---|
| 默认态 | 数据齐全时的正常展示 | AI 一定会做，白送一分 |
| loading 态 | 骨架屏或进度说明 | 干转圈算半分 |
| 空态 | 说明用途、给动作入口、有示例更好 | 齐全才给分 |
| 错误态 | 发生了什么、为什么、怎么办 | 三要素齐全才给分 |
| 成功态 | 操作成了要让人看见，但别用弹窗邀功 | 弹窗邀功扣分 |
这张表同时就是给 AI 提需求的模板——整张写进提示词就行。
AI 不会主动想空态、loading、错误态。你不提要求，它就一律敷衍——这是它的默认行为模式，不是疏忽。所以正确做法不是事后挑错，而是事前把这三种状态写进需求。 状态覆盖率自查表可以直接当需求模板用：把五种状态逐条列出来，要求 AI 逐条实现，验收时再逐条对照。这一步几乎不增加沟通成本，却能把交互上最容易漏掉的那一类问题，从「上线后被用户发现」提前到「交付前被自己发现」。
审美验收（15 项）
判据溯源
交互验收
状态三件套
清单用法：不要一次性全勾。先挑当前项目里最容易出事的那一类，只把那一类勾完，改动一次、验证一次。清单的价值在于暴露盲区，不在于制造「全部通过」的成就感。
本集内容严格取材于 content-slices/pm36-m6.md 所聚合的三节课节素材，不跨集取材、不虚构源文档没有的数据、案例与引文。
几处需要说明的约束：
本集素材来源：xueai.miyang.cn（小山学堂 · 洛小山《学 AI 产品，从入门到精通》）
小山学堂「审美工程」与「交互工程」专题原创；部分设计原则整理自《About Face 4：交互设计精髓》第 8、15、17 章（Alan Cooper 等著），响应时间门槛为该章转引尼尔森，量化原则出自 Tufte。
二次演绎配音版，仅供学习交流使用。