01
状态与控制
用户点击后，知道系统收到什么、正在做什么、是否可以取消。系统应说清等待、成功和失败之间的区别。
检查问题：操作到底有没有生效？
01 / 把原文的启发
变成可检验的问题
“高级感”在本文中只指用户对产品质量、可靠性和被认真对待的主观判断。它不是统一分数，也不是定价权的同义词。在第 02 节的框架中，它对应第三层“感知质量”。
- 来源证据 可追溯的研究或官方资料
- 本报告提议 本报告给出的方法，未经来源证明
- 假设练习 虚构情境，无真实数据
02
跨页面一致性
同一个对象使用同一个名称。额度、按钮、日期和保存状态在整条任务路径中保持一致，而非只在单张页面上好看。
检查问题：上一步学会的规则，下步还能用吗？
03
失败后的恢复
系统解释发生了什么、数据保留到哪里、用户下一步做什么。恢复应尽量延续原任务，减少重新输入。
检查问题：出了错，用户能否继续完成任务？
以上三个方向来自原文作者 Tim 的观点（经深思圈转述）[02]；检查问题由本报告提出。
本报告的判断：先把核心任务做对，再减少关键流程中的不确定性。不要因为页面更精致，就默认用户愿意付更高价格。准确性、响应速度、隐私、可靠性、工作流整合与真实任务成果同样影响选择。
从界面到利润，中间有四段证据
- ① 任务表现成功率、时间、错误恢复率
观察真实操作 - ② 后续使用再次完成核心任务、留存
跟踪同一批用户 - ③ 支付行为付款、续订、退款
核对交易与分母 - ④ 经营结果增量收入减增量成本
计算贡献利润
箭头代表待验证的假设关系，不代表必然因果。更满意可能不再回来；用得更多可能不付费；收入提高也可能被推理与客服成本抵消。第 10 节给出每一段的指标与观察期。
02 / 设计能改善哪一层，
改不了哪一层
本报告提议
这是本报告提出的分析框架，不来自原文或所引研究。层与层之间的三条连接都是待验证的假设，用虚线标出。框架的用途是先判断问题在哪一层，再决定是否值得改界面。
- 第一层
基础任务价值
要回答：用户是否经常需要完成这个任务？AI 结果是否准确到可以直接使用或少量修改？
观察：任务频率、现有替代方案、结果被采用或大幅改写的比例。
设计能做：帮助用户发现错误结果，例如显示出处、标出不确定部分。交互设计还可以改善提供给模型的上下文，例如引导补全输入、绑定资料来源、在输出前做校验；这些改动可能影响端到端准确性，需要用固定评测样本单独测量。
设计不能做：只改视觉外观，不会让模型结果更准确；也不能让低频或不重要的任务变得重要。
H1 · 假设：只有第一层成立，第二层的改进才会转化为持续使用。
探索性检查：按“结果被采用”与“结果被丢弃”分组，看改版后的回访变化是否集中在采用组。这种分组发生在结果之后，只能提供线索，不能证明改版的因果效应。条件允许时，按用户随机分配新旧版本，并在实验前按基线特征（例如改版前的结果采用率）预先划定子组，再估计效应。- 第二层
可靠与可用
要回答：用户能否稳定完成任务？等待、失败、取消时，用户是否知道发生了什么？
观察：任务成功率、恢复率、求助次数、重复提交次数。
设计能做：这是界面与交互最直接起作用的一层，见第 05 节矩阵。
设计不能做：单靠前端文案。状态查询、去重与持久化需要服务端实现。
H2 · 假设：第二层改善与跨页一致，会提高用户对产品质量的判断。
检验：同一任务改版前后，用户对可靠性的描述和交付行为是否变化。前后对比会混入同期变化，只作线索；有条件时用随机分组。- 第三层
感知质量（本文的“高级感”）
要回答：用户是否认为产品可靠、认真，可以放心把结果交给同事或客户？
观察：访谈中的描述；是否直接分享或交付结果；导出后是否需要重新整理。
设计能做：跨页一致、细节准确、导出完整会影响这一判断。
设计不能做：抵消反复失败。第二层经常出错时，精致外观可能让落差更明显。
H3 · 假设：感知质量只有在任务价值足够、价格与替代品允许时，才可能体现为付款。
检验：完整计费周期内的同期群付款与续订，见第 10 节。- 第四层
付费意愿与付款行为
要回答：用户是否在当前价格下付款、续订，且没有退款？
观察：实际付款、续订与退款；口头表示“愿意付”只作线索。
设计能做：减少价格页与付款流程中的摩擦和误解。
设计不能做：决定预算、替代品价格和由谁拍板购买。
| 症状 | 更可能的层 | 先做什么 | 改设计能否解决 |
|---|---|---|---|
| 首次顺利完成，之后很少回来 | 第一层：需求频率或价值 | 访谈任务频率和替代方案；确认任务是否本来就低频。 | 通常不能。 |
| 用户大量改写或丢弃 AI 结果 | 第一层：结果准确性 | 建立固定评测样本，统计可直接使用的结果比例。 | 只改外观不能让结果变准；改进上下文收集、依据绑定和校验可能提高端到端准确性，需单独测量。 |
| 中途放弃、重复提交、频繁求助 | 第二层：可靠与可用 | 按第 05 节矩阵逐行注入故障并观察。 | 能，但需要服务端配合。 |
| 结果可用，但用户不敢直接交给别人 | 第三层：感知质量 | 检查导出格式、出处和跨页一致性。 | 可能，需要访谈和交付行为确认。 |
| 常用且满意，但不升级 | 第四层：价格、预算、替代品 | 访谈实际付款决策者；小范围价格测试。 | 通常不能，只能减少付款摩擦。 |
使用边界：这张表是诊断起点，不是结论。同一症状可能有多个原因，需要访谈和日志共同确认。
03 / 原文哪些话
可以信到哪一步
标签说明：限定保留＝核到依据但要限制范围；部分核实＝只核到一部分；改写结论／口径＝修正推论或统计含义；待核实＝未取得足够原始证据；作者观点＝可讨论的判断。
限定保留
AI 做的界面约四分之一“说了没做”
原论文确实报告约 25% 的设计理由未实现；功能要求约 34%。这是所测任务上的理由—实现差距，不是所有 AI 产品的通用故障率。[03]
部分核实
导航换位置，使用户后续操作持续变慢
改写结论
服务补救可能让用户更满意
元分析对满意度支持正向效果，但对复购意向、口碑、企业形象未发现显著正效应。不能据此故意制造故障，也不能保证复购。[05]
限定保留
小恐龙每月被玩 2.7 亿次
Google 2018 年官方访谈支持这个历史次数。不能换算成用户人数，也没有提供由该设计带来的收入或留存增量。[06]
改写口径
一次糟糕体验会让三分之一用户流失
待核实
匿名加密卡：新增账户 +60%，充值 +79%
待核实
2010 与 2021 包装研究解释高级感
原文未给论文题目；本次未完成唯一匹配。补充 2019 年巧克力实验，只说明包装与产品体验可分别研究，不能证明软件“好看零溢价”。[13]
作者观点
三处体验是 AI 时代的溢价来源
Tim（经深思圈转述）提出三处体验；深思圈进一步解读为“好看零溢价”。三处体验值得检查，但零溢价判断过于绝对。功能准确性、可靠性、任务价值、品牌和分发仍可能影响价格。[02]
限定保留
系统状态、撤销、恢复是共同弱项吗？
论文讨论了状态可见、用户控制与错误预防恢复等交互弱项；其统计表显示“功能类原则”整体最难实现。不能把功能类总结果改写为“错误恢复单项排名最差”。[03]
待核实
容易理解，就一定评价更好吗？
原文提到“几十年研究”，但未给具体出处；本次未完成匹配。将理解成本作为待测机制保留，评价更好也不等于愿意付钱。[02]
为什么保留一些“待核实”，而不是补一个听起来合理的出处？
Tim 的身份、Undertone 改版与匿名客户数据，当前只有中文文章转述。搜索没有完成一一对应，就不猜公司、视频或实验。包装研究也不能只因年份相同就认作原文所引论文。
补充的 2019 年包装实验研究 75 人对同一巧克力在不同呈现条件下的反应；它提醒我们分开研究外观与产品体验，但食品实验不能直接给软件定价结论。[13]
04 / 七个案例，
各自解决什么问题
五个通用产品案例和一个 AI 产品案例可核对官方资料；Undertone 保留为原文情境。它们展示设计方法；没有提供可迁移的收入增长保证。
显示 7 个案例
CASE 01
Gmail
让误操作有一个有限的反悔窗口官方文档 / 官方自述
发送后提供撤销入口，窗口可设置为 5、10、20 或 30 秒。[08]
可迁移：把不可逆操作拆成准备、确认、提交；明确何时仍能撤销。
边界：超过设定的撤销窗口后，不能再使用此功能撤回；文档没有证明它提高订阅转化。
复测：倒计时内撤销后内容仍在；到期后清楚说明状态。
CASE 02
Stripe
同一句“付款失败”需要不同下一步官方文档 / 官方自述
余额不足建议换支付方式；需要认证时走认证；重复交易先查已有付款；疑似欺诈不暴露详细原因。[09]
可迁移：让恢复动作由真实错误类别决定；状态未知先查单。
边界：一味重试可能增加重复操作风险；官方错误指南不等于转化实验。
复测：模拟拒付、认证、网络中断；核对提示和后台订单一致。
CASE 03
GOV.UK
全局摘要与字段错误使用同一表述CASE 04
Figma
允许带走副本，也解释副本失去了什么官方文档 / 官方自述
官方支持保存本地副本用于备份；副本不含评论和版本历史，重新导入视为新文件。[12]
可迁移：提供导出与恢复入口，同时列清内容、关系和历史的保留范围。
边界：本地副本、云同步、版本历史是不同能力；本例不证明离线自动恢复。
复测：导出后重新导入，逐项核对内容和不可恢复部分。
CASE 05
Chrome Dino
减轻等待时的挫败感官方文档 / 官方自述
Google 介绍了断网游戏的设计与 2018 年每月 2.7 亿次游玩。它让错误时刻有可做的事。[06]
可迁移：非紧急等待可提供轻量辅助；先解释断网和恢复入口。
边界：游戏不能修好网络；付款、急救等高焦虑场景不应靠趣味分散注意。
复测：用户能否快速区分连接故障与数据丢失，能否返回原任务。
CASE 06
Undertone（原文案例）
录音太短与额度用完都要给具体解释二手转述 · 未独立核实
原文转述：短录音没有结果；不同页面给出模糊额度提示。改法是明确已用次数和刷新日期。[02]
可迁移：短录音也回报已识别时长、是否计费、下一步；额度显示统一。
边界：未独立确认 Tim 原视频、产品身份和改版效果；只作问题情境。
复测：短录音、麦克风拒绝、额度归零分别测试，不把一个案例当增长证明。
CASE 07NotebookLM
让 AI 回答回到具体出处
NotebookLM
（历史功能案例）
让 AI 回答回到具体出处Google 官方公告 · 2024
Google 在 2024 年 6 月介绍：回答中的行内引用能跳到来源中的支持段落，便于检查生成内容。此处使用发布时的产品名称与功能说明。[14]
可迁移：在 AI 结论旁保留可打开的证据位置，区分原文、概括和推断，让用户能核查重要结论。
边界：有引用不保证引用支持结论；资料本身可能错误。官方功能公告没有提供留存或付款增量。
复测：抽取关键结论，逐条打开引用，检查是否支持该结论，并记录不支持的比例。
七个案例都是设计模式的示例。官方文档说明功能存在，不说明这些功能带来了多少留存或收入。
05 / AI 产品的十类状态：
用户问什么，产品承诺什么
本报告提议
每一行回答三件事：用户此刻最想知道什么；产品明确承诺什么；用什么可观察的操作来验收。验收要核对服务端或账单记录，不能只看界面文案。
四件事要分别确认：本页停止显示；服务端停止任务；本次未计费；已退款。前端点了“取消”，只证明第一件事。
| 状态 | 用户问题 | 产品承诺 | 可观察的验收 |
|---|---|---|---|
| 输入校验 | 我的输入能用吗？要改哪里？ | 提交前指出具体字段和限制，例如格式、时长、大小。保留已填内容。校验未通过时不发起生成，也不计费。 | 提交空字段和超限文件：错误指向具体字段，焦点移到错误摘要；原输入仍在；服务端没有新任务，账单没有新记录。 |
| 权限 | 为什么不能继续？要去哪里打开？ | 说明缺少哪项权限，例如麦克风、文件或团队角色。说明授予后会发生什么。拒绝后提供替代路径。 | 在浏览器中拒绝麦克风：页面显示原因和开启步骤，不停留在加载状态；改用上传文件仍能完成任务。 |
| 上传 | 传了多少？断了要从头传吗？ | 显示上传进度。只有服务端确认接收后，才显示“已上传”。说明中断后能否续传。 | 上传中途断网再恢复：界面状态与服务端文件记录一致；不出现界面显示“已上传”而服务端没有文件的情况。 |
| 生成与流式输出 | 它还在工作吗？已出现的内容算数吗？ | 区分排队、生成中、已完成。流式内容在完成前标为“未完成”。完成标记以服务端完成状态为准。 | 生成中断开连接：已显示部分仍标为未完成，并提供继续或重新生成；未完成内容不能作为最终结果导出，只能作为明确标注的草稿导出，并保留“未完成”标记（见“导出”行）。 |
| 取消 | 停下了吗？还会扣费吗？ | 分开说明“本页已停止显示”和“服务端已确认停止”。按事先公布的规则说明计费；确认取消后仍可能按规则产生费用。计费系统确认前，不承诺未计费或退款。 | 点击取消后核对三项记录：取消请求时间、服务端任务最终状态、账单记录。服务端确认停止后，界面才显示“已停止”；只有计费系统明确确认本次无费用时，才显示“未计费”。按已公布规则仍产生费用的，显示实际费用，不写“未计费”。 |
| 超时服务端状态未知 | 到底成功没有？再点一次会重复吗？ | 显示“结果未知，正在确认”。按任务编号查询。重试复用同一个幂等键，避免生成第二个任务。 | 注入超时，且后台实际已完成：用户能找回结果；连续点击重试后，服务端只有一个任务、一笔费用。 |
| 无依据结果俗称“幻觉” | 这个结论有根据吗？ | 关键结论附可打开的出处。找不到依据时明确说“未找到依据”。推断与原文分开标注。 | 抽样关键结论，逐条打开出处，记录不被支持的比例；提问来源中没有答案的问题，检查是否说明无依据，而不是编造。 |
| 额度与费用 | 还剩多少？这次花多少？何时刷新？ | 所有页面使用同一额度数字和刷新日期。高消耗操作前显示预计消耗。写明失败、取消、超时任务是否计费。 | 在全部入口对照额度显示；分别触发失败、取消、超时，核对账单记录与界面说明一致。 |
| 导出 | 导出了什么？少了什么？ | 说明导出格式包含和不包含的内容，例如出处、时间戳、编辑历史。未完成内容不提供“最终结果”导出；用户选择导出草稿时，文件标为草稿并保留“未完成”标记。标为“无依据”的内容，导出时保留标记。 | 导出后重新打开或导入，逐项核对内容；未完成内容无法以最终结果导出；草稿文件中的草稿标识、未完成标记和出处仍可见。 |
| 再次打开回访 | 上次的内容还在吗？做到哪一步了？ | 说明哪些内容保存在服务器，哪些只在本设备。回访时显示任务的服务端当前状态。 | 关闭页面、换设备后重新打开：服务器已保存的内容可找回；仅存本地的内容有明确提示；进行中的任务显示服务端最新状态，而不是旧的本地状态。 |
矩阵中的“承诺”是对产品团队的要求，不是对任何现有产品的描述。Stripe 的“状态未知先查单”[09]、GOV.UK 的错误摘要[10]、Figma 的导出范围说明[12]、NotebookLM 的行内引用[14]是对应行的参考模式。第 07 节的演示对应“取消”和“超时”两行。
06 / 三个改写练习：
从“出错了”到可继续的下一步
假设练习
以下三个产品与情境都是虚构的设计练习。没有真实用户、日志、保存记录或增长数据。〈〉内是需要按真实系统填写的内容。状态无法确认时，文案写“未知”，不写成功。
AI 录音摘要：生成请求超时
失败时刻：用户上传一段较长的会议录音。练习设定：服务端已确认收到文件。生成摘要的请求在客户端超时，界面没有收到结果。
不足的提示
出错了，请重试。
问题：没有说明哪一步出错；“重试”可能导致重新上传并再次消耗额度；后台可能已经生成完成。
改写后的反馈
摘要结果暂时未知
录音已上传成功。摘要生成的响应超时，我们还不确定它是否完成。
正在按任务编号〈任务编号〉查询状态。确认前请不要重新生成，以免重复消耗额度。
［查询状态］
- 保留的数据
- 服务端已确认接收的录音文件；任务编号。摘要状态为“未知”，不显示为“已保存”。
- 下一步
- 查询结果：已完成，显示摘要；已失败，说明原因，并允许不重新上传就重试，是否计费以实际记录为准；仍未知，告诉用户何时再查。
- 要测什么
- 注入超时的任务中，用户最终拿到摘要或得到明确失败结论的比例；同一录音产生的重复任务数；重复扣费数，应为 0；相关求助次数。
- 尚未证明
- 这次改写是否提高续订或减少退款。第一步只能证明恢复路径可用。
内容发布草稿：发布到外部平台失败
不足的提示（两种情境相同）
发布失败。
问题：情境一确实未发布；情境二可能已经发布。同一句话会让用户在情境二再次发布，产生重复内容。
改写后的反馈
情境一：未发布
〈平台〉授权已过期。草稿仍在草稿箱，内容没有改动。重新授权后可以从这一步继续发布，不需要重新生成。
［重新授权并继续］
情境二：发布状态未知
我们没有收到〈平台〉的确认。内容可能已经发布，也可能没有。确认前请不要再次发布。
［查询发布状态］［去〈平台〉查看］
- 保留的数据
- 草稿正文、所选图片、发布设置。前提是产品在调用发布前，已把草稿写入服务器并确认成功。这是设计要求，不是已知事实。
- 下一步
- 情境一：重新授权，回到发布确认页。情境二：查询结果；已发布则显示链接，未发布则允许发布一次。
- 要测什么
- 遇到授权错误的发布尝试中，同一会话内完成发布的比例；超时后的重复发布次数；因发布失败而重新生成草稿的次数。
- 尚未证明
- 是否提高付费套餐的升级或续订。减少重复发布能降低风险，但不直接说明收入变化。
客服助手：知识库没有答案
失败时刻：用户问“我买的年度套餐能退款吗？”帮助文档中没有年度套餐的退款条款。
不足的回答
可以，30 天内无理由退款。
问题：这是练习中故意编造的错误回答，用于说明风险。结论没有出处；用户可能据此行动；错误承诺会转成客服成本和信任损失。
改写后的回答
我在当前帮助文档中没有找到年度套餐的退款条款，所以不能告诉你能否退款，也不能给出期限。
［转人工客服］［查看已找到的相关条款］
- 保留的数据
- 下一步
- 转人工；或查看相关条款，并标明“该条款不涉及年度套餐”。
- 要测什么
- 抽样审核涉及政策的对话中，无出处结论的比例；转人工后用户重复提供信息的比例；从转交到首次人工回复的时间。
- 尚未证明
- 是否降低客服成本或提高续费。转人工比例上升，可能在短期内增加成本。
07 / 亲手试一次
失败后的体验
下面是本报告制作的教学模拟，不连接服务器、不调用模型、不收费，也不访问麦克风。目的是比较反馈是否足以支持下一步行动。它对应第 05 节的“取消”和“超时”两行。
场景：生成一份内容摘要
先选择故障，再点击开始。运行中可以取消。发生失败或超时时，观察输入是否保留，以及系统有没有错误承诺。
- 正常：展示明确结果。
- 失败：保留输入，提供修正后重试。
- 超时：状态待确认，先查询，再决定是否重试。
- 取消：说明已取消什么，以及数据是否仍在。
真实系统还需要服务端状态查询、任务标识、去重与持久化。这里的客户端模拟不证明这些能力已经实现。
尚未开始
输入保留在当前页面。请选择场景后开始。
数据：仅当前页面内存；关闭后不保留。
08 / 检查自己的
一条核心流程
选择一个真实流程，例如“上传录音 → 生成 → 导出”。每项标明现状，先处理可能造成数据损失、重复操作或无法继续任务的问题。需要更细的检查项时，使用第 05 节矩阵。
尚未检查 6 项。未检查不等于通过。
仅在点击保存后尝试写入本浏览器；不上传。文件模式下存储支持因浏览器而异。
09 / 小团队先修哪一个：
一张可编辑的排序表
本报告提议 · 启发式
把第 05 节或第 08 节发现的问题填进来。表格给出讨论用的排序，不给“高级感分数”。数值只在同一张表内比较，不能跨产品或跨团队比较。
排序参考值 = 严重度 × 频率 × 把握 ÷ 修复工作量
- 这是启发式，不是测量结果。把四项相乘只是为了便于讨论，它们之间并没有经过验证的数量关系。
- 修复工作量最小为 1，计算不会出现除以零。
- 严重度为 4 的问题列为红线，先止损，不参与排序。止损可以是临时禁用重复提交或暂停相关扣费。
- 把握为 1 的问题标为“先补证据”：先复现或查日志，再决定是否修。
- 两项参考值接近时，回到用户影响讨论，不要只看数字。
严重度
- 轻微：文字或外观不一致，任务不受影响
- 受阻：用户迟疑或需要求助，但能完成
- 中断：任务无法完成，需要重来
- 红线：数据丢失、重复扣费，或无依据结果被当作事实使用
频率
- 罕见：只在特殊条件下出现
- 偶尔：部分用户在部分任务中遇到
- 常见：多数用户在早期使用中会遇到
- 每次：每次执行该任务都会遇到
把握
- 猜测：团队推测或单条反馈
- 有反馈：能复现，或有多条独立反馈
- 有记录：日志或观察有明确分母
修复工作量
- 半天内
- 一到两天
- 一周内
- 超过一周，或需要改服务端
工作量含义按团队实际人力改写，但同一张表内保持一致。
前四行是示例假设，不是任何产品的真实数据。直接改写或清空即可。
参与排序 4 项；1 行未填写问题名称，未参与。
红线项：先止损，不参与排序
- 超时后可再次点击生成，可能重复扣费 · 参考值 8（严重度 4 × 频率 2 × 把握 2 ÷ 工作量 2）
其余问题按参考值从高到低
- 三个页面的剩余额度说法不一致 · 参考值 18（严重度 2 × 频率 3 × 把握 3 ÷ 工作量 1）
- 短录音返回空白且没有解释 · 参考值 12（严重度 3 × 频率 2 × 把握 2 ÷ 工作量 1）
- 导出的摘要不含出处 · 参考值 3（严重度 3 × 频率 3 × 把握 1 ÷ 工作量 3） · 把握低：先补证据
修改后自动重新排序。仅在点击保存后尝试写入本浏览器；不上传。排序表与第 08 节检查表分开保存。
示例说明：如果只看参考值，“重复扣费”只排第三。红线规则把它提到最前。这说明公式只是讨论工具，不能替代对后果的判断。
10 / 用两周发现问题，
用完整周期验证付款
这是建议实验安排。两周可验证局部可用性，通常不足以判断长期留存或续订。低流量产品优先观察真实任务，不用少量数据宣布显著增长。
确定一条任务与基线
选近期真实用户反复执行的任务。记录起点、完成标准、失败分母和人工协助。观察 5–8 名目标用户可用于发现问题，不能估计总体流失率。
产物：可复现问题、录屏或事件记录、改版前数据。
只改一个关键机制
例如只增加明确保存状态与恢复入口。提前写清预期改善和反证，避免同时换价格、渠道与核心功能后归因给界面。
产物：明确改动、失败注入步骤、回滚版本。
复测，再追踪后续行为
比较成功率、恢复时间与求助次数。有足够流量再设计随机对照；样本量由基线和最小有意义变化决定。留存、付款和续订按真实周期继续观察。
产物：分组、分母、观察期、不确定性和停止规则。
示例：AI 录音摘要的一套指标
假设练习 沿用第 06 节练习 A。〈〉内的时限与阈值由团队在实验前写定，本报告不提供数值。
| 类型 | 指标 | 分子 ÷ 分母 | 说明 |
|---|---|---|---|
| 主要指标 | 核心任务完成率 | 在〈时限〉内得到可导出摘要、且没有联系客服的任务数 ÷ 合格上传任务数 | 只用这一个指标判断改动是否有效，但它只说明流程走通，不说明摘要质量；能导出不等于内容可用。必须同时通过下面两项发布门槛，才能宣布改动有效。合格任务：格式与时长在支持范围内；排除内部账号；同一任务编号的重复提交只计一次。 |
| 发布门槛 | 摘要可用率 | 抽样中被审核判为“可直接使用或少量修改即可使用”的摘要数 ÷ 抽样审核的已完成摘要数 | 实验前写定抽样规则（例如每组按任务编号随机抽取〈数量〉份）、评审标准（遗漏关键行动项、事实错误、错误归属发言人即判为不可用）和最低阈值〈阈值〉。评审人不知道摘要来自哪一组。低于阈值时不发布，不论主要指标如何。 |
| 护栏 | 重复扣费率 | 同一任务被扣费两次及以上的任务数 ÷ 已扣费任务数 | 由改动引起的新增应为 0。数据来自支付记录，不来自界面。 |
| 护栏 | 每个成功任务的变动成本 | 期间模型与基础设施费用 ÷ 成功任务数 | 自动重试和状态轮询可能增加成本。 |
| 护栏 | 求助率 | 关联到任务的客服工单数 ÷ 合格上传任务数 | 工单需要记录任务编号，否则无法关联。 |
| 发布门槛 | 无依据结论比例 | 抽样中不被出处支持的关键结论数 ÷ 抽样关键结论数 | 人工抽样审核；抽样规则与上限〈上限〉在实验前写定，且不得高于改版前基线。超过上限时不发布，不论主要指标如何。 |
| 护栏 | 退款率 | 退款笔数 ÷ 同一同期群的付款笔数 | 退款窗口结束后再结算。 |
需要记录的事件（事件名为示例，按自己的系统命名）
| 事件 | 何时记录 | 关键字段 |
|---|---|---|
task_submitted | 用户提交任务 | 任务编号、匿名用户编号、实验分组、输入时长区间 |
upload_confirmed | 服务端确认收到文件 | 任务编号、文件大小区间 |
task_completed / task_failed | 服务端任务结束 | 任务编号、错误类别、耗时 |
timeout_shown | 界面显示“结果未知” | 任务编号、当时的服务端状态 |
status_queried | 用户或系统查询任务状态 | 任务编号、查询结果：完成、失败、进行中、未知 |
cancel_requested / cancel_confirmed | 客户端发出取消；服务端确认停止 | 任务编号、两者时间差、是否计费 |
retry_submitted | 用户重试 | 任务编号、幂等键、是否生成了新任务 |
result_exported | 导出完成 | 任务编号、格式、是否含未完成标记 |
charge_recorded / refund_recorded | 支付系统记账 | 任务编号或订单号、金额、同期群 |
support_ticket_linked | 工单关联到任务 | 任务编号、问题类别 |
客户端事件可能因用户关闭页面而丢失。作为分母的事件，应在服务端记录。
发现测试
目的：找出用户在哪里卡住、为什么卡住。
方法：每轮 5–8 名目标用户，执行真实任务，并注入第 05 节中的故障。
产出：问题清单、复现步骤、可填入第 09 节的条目。
不能用来估计比率，也不能证明付款变化。
A/B 测试
目的：估计改动对主要指标的影响大小。
前提：流量足以在预定时间内检测到最小有意义的变化。按用户随机分组，不按会话分组。
事先写定：主要指标、护栏、样本量、观察期。看到好结果也不提前结束。
分组比例明显偏离设定时，先查数据问题。流量不足时，可改用前后对比，但它是观察性证据，不等同于随机 A/B 证据：季节、用户构成、渠道、模型版本和同期其他改动都可能造成差异。写明这些同期变化，只把结果当作方向性线索，谨慎推断，不据此宣布因果效果。
观察期要跟着要回答的问题走
- 任务完成率：达到事先计算的样本量后即可评估。
- 回访与留存：先确定用户的自然使用周期（每天、每周或每月）。观察期覆盖多个完整周期，长度在实验前写定。按首次接触改动的日期分成同期群。
- 续订：只有同期群到达续订日后才有数据。月付产品至少要等第一个续订日及扣款重试期结束；年付产品在几周内无法评估续订。
- 净收入：退款窗口结束后再结算。
停止与回滚条件（实验前写定）
- 出现由改动引起的重复扣费或数据丢失：立即回滚，不等统计结果。
- 护栏指标超过事先设定的阈值，例如每个成功任务的成本超过上限：暂停并复查。
- 分组比例偏离设定，或关键事件缺失：停止解读结果，先修复数据。
- 主要指标改善，但护栏恶化：不宣布成功，先权衡。
- 摘要可用率低于阈值，或无依据结论比例超过上限：不发布。导出数量增加本身不证明结果质量。
- 到预定观察期仍无可检测差异：记录为“未证明有效”，不延长观察期去等待好结果。
| 证据类型 | 例子 | 能说明 | 不能说明 |
|---|---|---|---|
| 实际付款与续订 | 交易记录中的首次付款、续订、扣除退款后的净额 | 在当前价格和人群下，有人实际付了钱 | 付款是否由体验改动引起，需要对照组 |
| 购买前行为 | 打开价格页、开始结账、试用到期前的操作 | 购买兴趣和流程中的摩擦点 | 最终是否付款 |
| 陈述的付费意愿 | 问卷“你愿意为此付多少钱” | 价格区间的初步线索 | 实际付款；说法与行为可能不一致 |
| 满意度与评价 | 评分、访谈中的好评 | 对体验的感受 | 付款、续订、利润 |
每个指标都要写清分母
任务成功率 = 无人工帮助完成任务的次数 ÷ 合格尝试次数。恢复率 = 从目标故障恢复并完成任务的次数 ÷ 注入该故障的次数。付费率 = 实际付款人数 ÷ 具备同等购买条件的人数。
利润单独算：增量实收收入 − 增量退款 − 模型、支付、客服等变动成本 − 本次新增开发维护成本。时间范围和成本摊分必须一致。
三种应当接受的“没有赢”
可能是需求不强、替代品便宜或目标人群不对。继续美化不一定解决问题。
自动重试和更长交互可能增加模型成本。先看每次成功任务的总成本。
统一样式若破坏熟练用户的操作习惯，可能带来迁移成本。保留可测例外。
给 AI 的实现任务应当怎么写？
先指定任务和用户，再列状态：空白、处理中、成功、失败、取消、超时、权限不足、额度耗尽。对每个状态说明触发条件、可见反馈、允许操作、数据保留与验收步骤。第 05 节矩阵可以直接作为清单。
要求 AI 提供“承诺—界面位置—可运行检查”的对应表。实际点击验证后再确认完成。不要把它生成的解释本身当作检查结果。
11 / 局限、反例，
以及仍然值得做的事
本报告引用的来源，没有一条直接证明“改善体验会提高 AI 产品的付费意愿或付款”。下面逐类说明边界。
| 来源 | 能说明 | 不能说明 |
|---|---|---|
| York 导航研究 [04] | 导航不一致会增加耗时，并影响后续页面 | 留存或付费；它是 2009 年的网站研究 |
| 服务补救元分析 [05] | 补救对满意度的正向效果 | 复购意向的正向效果（未发现显著效应） |
| PwC 调查 [07] | 受访者表达的离开意向 | 真实流失率 |
| 官方产品文档 [06][08]–[12][14] | 某种设计模式存在，以及它如何工作 | 该模式带来的留存、收入或利润；这些是模式，不是因果商业结果 |
| 原文与总结 [01][02] | 作者的观点与转述的案例 | 匿名增长数据和原视频内容，二者仍待核实 |
| 巧克力包装实验 [13] | 外观与产品体验可以分开研究 | 软件定价；它不是原文所引的 2010/2021 论文 |
需要考虑的反例情形
以下是推理出的可能情形，用于提醒检查方向，没有引用数据，也不指向具体产品。
替代品少、任务价值高时，用户可能忍受较差的体验。含义：不要因为界面差，就认定付费问题来自界面。
恢复率提高了，失败本身可能并未减少。含义：同时统计失败发生率和恢复率。
用户看清消耗后，可能更谨慎。含义：这是诚实展示的成本；同时观察使用量和投诉。
每一步都确认，会增加操作时间。含义：只在不可逆或高成本操作前确认。
有链接不等于链接支持结论。含义：定期抽查出处是否支持结论。
已经离开的用户不会出现在访谈和反馈里。含义：查看流失前最后几次任务记录，并尝试联系流失用户。
另一个常见偏差是新版本的短期新鲜感。按同期群持续观察，可以减少误判。
即使不能证明溢价，仍值得先做的事
修复数据丢失和重复扣费。这类问题直接伤害用户，与能否提价无关。
统一额度与费用的说法。用户需要准确信息来决定是否继续使用。
状态未知时说“未知”，并提供查询。错误地报告成功，比承认未知代价更高。
这些建议的理由是减少损害，不是“会带来更高收入”。