第 21 章　让一个受控原型接受真实反馈

能运行、做对了和适合真实使用，是三件事

项目做到这里，至少要区分三种检查。

内部验证问：系统是否按设计运行？链接、检索、权限和日志是否符合预先写下的要求？

结果确认问：这个原型是否真的帮助目标使用者完成了那个有限任务？它有没有把人带向错误材料，或者让边界更难理解？

受控试用则把系统放进一个很小的真实情境：少量自愿参与者、有限时间、有限功能、最少数据，并且能够随时停止和退回原来的方法。

三者不能互相替代。开发者自己完成十次内部测试，不等于另一位使用者会理解入口；一次试用顺利，也不等于系统已经适合公开发布。

试用不是把链接发到群里

受控试用已经涉及真实的人。邀请之前，至少要让参与者看懂这些内容：

• 谁在做这个原型，它不是哪一种官方或专业服务；
• 本轮只测试什么，明确不处理什么；
• 会接触哪些数据，谁能看到，保存多久，怎样删除；
• AI参与哪一步，哪一步由人确认；
• 可能出现哪些已知问题；
• 怎样退出，退出后是否仍有原来的非AI路径；
• 出现问题联系谁，什么情况下试用会立即停止。

这些说明不能藏在很长的条款末尾。对课程概念导航来说，“不要上传成绩、身份信息或未公开材料”应出现在输入区附近；查阅教师原始材料的入口也应始终可用。参与者不应因为拒绝使用AI而失去本来能够获得的课程资源。

真正的知情也不只是点一下“同意”。当功能、数据或用途发生变化，原来的说明可能已经不够，需要重新评估，而不是默认一次同意覆盖以后所有版本。

少收数据，往往比更复杂的保护更可靠

试用者完成“找到某个概念的前置内容和原文位置”时，制作者真正需要知道的，可能只是：是否找到、在哪里卡住、哪句话造成误解。

如果一张简单观察表和参与者主动反馈已经够用，就不默认录音、录屏、保存完整输入或采集身份信息。增加数据必须重新回答：这项数据怎样帮助当前目的？谁能接触？保存多久？能否用更少的信息达到同样目的？

这既减少隐私风险，也减少团队日后解释、保管和删除数据的负担。

反馈要贴着任务，不只收“满意度”

“感觉挺好”“界面不错”可以说明情绪，却很难指导下一版。更有用的试用，会给参与者一个有限任务：

请找出“相关性不等于因果关系”的前置概念和课程原文入口。如果证据不足，请说明你下一步准备去哪里查。

制作者要观察参与者能否完成任务：有没有找到正确入口，是否看见证据状态，是否误把系统当作官方答案，失败后是否知道回到哪里。“喜不喜欢AI”只能作为补充感受。

反馈也要区分证据强度。一位参与者问能否上传成绩单，只能说明这一次入口可能没有挡住越界，不证明“所有学生都会误解”。修订后还要再看：把警示放到输入框旁边，是否真的减少了误解；如果没有，可能需要直接取消这一输入方式，而不是继续润色说明。

一个受控试用应留下怎样的记录

记录不必厚，却应能回答：

1. 本轮测试的任务、参与范围和时间；
2. 使用的版本、资料范围和关闭条件；
3. 参与者看见了什么说明与替代路径；
4. 哪些问题实际发生，依据是什么；
5. 团队改了什么，什么没有改，为什么；
6. 是否出现了停止条件，数据怎样处理。

如果发生意外数据上传、明显误导、无法执行退出或其他超出边界的情况，应先停止相应功能，保护参与者，再调查原因。不要为了凑齐反馈数量继续运行。

先写一份不发送的邀请

如果项目确实准备邀请别人试用，先写一份不超过一屏的邀请，但暂时不要发。请一位不参与制作、了解场景规则的人阅读，然后只回答三个问题：

• 我知道这次要完成什么吗？
• 我知道不能交出什么、怎样退出吗？
• 出现问题时，我知道替代路径和联系人吗？

只要其中一个答案含糊，就继续留在内部验证。

受控试用的价值，不是给项目盖上“真实用户验证”的印章。它让系统在很小、可停止、可恢复的范围内遇见真实的人，并让制作者有机会看见自己原先没有想到的误解和代价。完成这一步，仍然不自动取得公开发布的许可。