功能已经跑通，怎样把它变成别人能顺利用的产品？
沿着真实任务检查输入、等待、结果和失败，让用户无需开发者讲解也能完成一次使用。
本页目录
直接回答
能调用 API 只是其中一步。用户还要知道产品能做什么、该输入什么、正在发生什么、结果能否使用以及失败后怎么办。把可用预览交给别人，观察反馈再修改，才能逐渐补齐这些环节。围绕完整任务检查界面状态，比单独增加动画更有价值。定义结果时既要有功能检查，也要有使用判断；“让人想分享”可以作为观察目标，但不能替代输入输出正确、错误可恢复等验收。
适用场景
- 自己演示没有问题，别人一用就卡住
- 页面看起来完整，但不知道怎样验证体验
- 模型调用较慢，用户容易重复点击或离开
一步一步做
写一条不需要解释的任务
选择目标用户真实会做的事，例如“把一段会议套话转成待办”“比较某件衣服的试穿预览”。记录用户来到这里之前有什么信息，结束时应该获得什么。让入口、按钮文案和结果说明围绕这件事组织。
补齐输入与结果说明
提供一份可尝试的示例，说明允许的格式、长度或图片要求。结果页告诉用户哪些是已得到的内容，哪些仍不确定，下一步能复制、下载还是继续修改。不要把内部模型名、参数和日志当成主要产品说明。
列出每个阶段的状态
整理建议：至少覆盖初始、输入中、处理中、成功、失败和无结果；上传类产品再考虑取消与重新选择。处理中给予真实反馈，避免没有依据的倒计时。重复提交要有合理处理，不让一次操作意外触发多次付费调用。
用明确规则处理边界
游戏要写清轮次、分数上下限、终止顺序；工具要写清空输入、无效文件、外部服务失败后如何继续。先在文字规则中消除矛盾，再交给 AI 实现，不要把相互冲突的要求留给模型猜。
观察一次独立使用并修正
请用户照任务操作，先不提示。记录他停在哪、误解了什么、是否认为任务完成。修正最影响结果的问题，再在手机窄屏、键盘操作和失败情形下检查。反馈应进入具体改动，而不是只收集“挺好用”。
案例拆解
假设练习：检查游戏的规则冲突
假设某游戏同时写“最低 −50 分”和“低于 −50 分失败”。若实现把分数限制在 −50，后一个失败条件就永远触发不了。应在实现前选择一种一致规则，例如到达下限即失败，或保留越界判断但不提前截断。另一个要求是动态生成且“无加载等待”；应改为有明确加载反馈并以实测速度验收，不能承诺外部 API 零等待。
行动检查
可复制模板
关键流程验收卡
工作模板
用户任务：［要达成的结果］
起点与输入：［已有信息、允许格式］
主要步骤：［操作与预期反馈］
成功证据：［具体结果，不只看页面打开］
失败情形：［空输入／超时／权限不足／结果不可用］
恢复方式：［重试、修改、返回、保留已完成内容］
观察记录：［用户卡点、原话、实际行为］
本轮只修：［最影响任务的一个问题］
易错点
- 先用动画掩盖流程问题：如果用户不知道下一步，动效通常解决不了。
- 把网络失败兜底文本当成 AI 正常回复：界面应诚实告诉用户任务未完成。
- 只在开发者熟悉的理想输入下测试：新人往往不会按预期方式使用。