沿着证据链判断AI陪伴功能的测试程度
仅看产品页面，无法证明一项AI陪伴功能经过充分测试，但可以判断公开证据是否足以支持眼前的使用决定。先问六个问题：测试的是哪个准确版本？预期用途与排除范围是什么？覆盖了哪些真实场景？记录了什么失败与恢复路径？是否有与开发团队分开的审查？发布后行为变化时如何监测？缺少答案不自动证明功能有问题，却会降低可信范围，因此使用也应收窄。首次试用保持可撤回，不提供较敏感资料，先关闭可选工具，也不要为只有精美演示支持的宽泛承诺付费。
第一阶：确认被测系统是谁
只有模型名称远远不够。应寻找应用版本、模型或服务版本、已开启工具、历史设置、语言、平台、日期和付费档位。运营方更新模型、提示、检索来源、内容控制、语音链路或工具权限后，营销名称可能不变，功能行为却已经不同。没有标明这些条件的证据，无法可靠对应今天看到的产品。把版本说明、帮助页、应用内标签和评估日期并排比较。若配置不清楚，就记录“无法确认版本”，不要假设新画面自动继承旧测试结果。这一步能防止后续所有分数脱离具体产品而漂浮。
第二阶：让预期用途与宣传承诺对齐
有效文档会解释功能要完成什么，也会说明不适用范围。把宣传改写成任务：日常文字交流、活动建议、图片回应、语音输入、网页检索、提醒或在相连服务中执行动作，再看评估是否测试同样任务。仅文字评估不能说明语音、图片、长历史、外部工具或公开互动。FTC 针对一款AI检测工具的投诉描述了宣传准确率却未覆盖不同实际使用条件的情况；可迁移的判断原则是，宽承诺必须由同宽度证据支持，不能借用窄测试的可信度。范围不一致时，只认可已经证明的任务。
第三阶：查看场景与失败样例
没有场景定义的百分比很难解释。可用证据会描述普通、边缘与对抗输入，账号状态、语言、媒介、相关使用群体和评分规则，也会给出哪些情况算失败、分歧、拒绝或未解决。按功能需要寻找网络中断、陈旧历史、共用设备、含糊指令、长对话、拒绝权限和工具错误。精心挑选的演示与平均分可能遮住低频却重要的问题。NIST 的AI资源强调在使用情境中完成测试、评估、验证与确认。要问的不只是“分数多高”，而是场景是否像自己的用法，以及理想路径失效时是否测试过恢复。
第四、五阶：寻找限制说明与独立性
可信证据会把限制放在结果附近，区分已知缺口和根本未测试的项目，并说明缓解措施，却不暗示所有风险已经消失。再看是否有功能开发团队之外的人员做复核评估、外部专业人员参与，或至少使用没有参与调优的保留数据。独立性不是完美徽章，而是减少同一团队既出题又给自己作最有利解释的机会。OpenAI 的系统卡展示了外部读者可以检查的证据痕迹：模型范围、评估阶段、红队工作、观察到的风险和产品层措施。小型产品资料可以更简洁，但仍应回答方法与边界的具体问题。
第六阶：核对监测与变更控制
测试不会在发布当天真正结束。版本、政策、语言、工具和使用方式改变后，行为也可能变化。寻找带日期的版本说明、可提交可复现问题的渠道、状态或事件入口、明确的功能变更，以及重要场景是否复测。特别核对重大更新是否改变权限、历史、分享、付款或删除。发布时证据很丰富却没有维护路径的功能，会随时间越来越难评估；相反，一份写明改了哪个入口、已知限制和复测范围的简短变更记录，可能比永久“已测试”徽章更有用。记录三个日期：当前功能版本、最近相关评估、自己的最近一次低披露检查。
按证据阶梯选择使用级别
把每一级标为清楚、部分或缺失，再选择可逆的使用级别。版本和范围证据很弱时，只做中性文字试用，不开可选工具；场景与恢复证据较可信时，可测试已经覆盖的任务，同时关闭无关权限。若涉及付款、公开发布、外部动作或持久历史，应在启用前要求更强说明。不要把阶梯用于公开比较，它只支持一个配置下的一次个人决定。保存链接和日期，不保存含有他人内容的截图，并在更新后复核。真正有用的问题不是“功能是否普遍安全”，而是“当前证据支持哪项具体用法，哪些仍在范围外”。
常见问题
没有公开文档就证明没测试吗？
不能。它说明外部读者无法核对范围、方法和结果，因此在问题得到回答前应收窄使用。
一个很高的基准分数够吗？
不够。还需要配置、任务对应、场景分布、评分规则、失败样例与产品恢复。
最快的第一步是什么？
先确认准确版本和日期，再核对公开场景是否匹配计划使用的功能与语言。