真人测试如何补足 API 监测？地区、账号与网页场景的执行方法

如果目标客户使用某个 AI 网页或手机 App，仅靠 API 结果无法确认他们在界面里会看到什么。真人测试可以补充这一层证据，但前提是问题与条件有记录、截图能对应完整回答、无法执行的情况没有被隐藏。一位测试者的一次结果是一个场景观察，不是某个国家的市场调查。

1. 先确定为什么需要界面测试

适合加入人工测试的原因包括：目标客户主要使用消费者界面；某项选择依赖地区或语言；网页出现了与 API 不同的说明；希望确认来源卡片、推荐入口或购买路径的实际显示。范围应围绕一个待解决的问题，而不是先罗列最多的平台名称。测试更多产品不一定增加可解释性。

确认表写明买家角色、平台与端、目标语言、实际地区、原题、是否需要新会话、证据形式和完成窗口。账号条件、设备可用性和平台限制应在排期前核实。某个平台在一个地区无法进入时，不能临时换成另一种服务却继续使用原平台标签。需要替代方案，可以提出，但必须保留变更记录。

2. 新会话测试与真实情境分开

新会话测试尽量减少历史上下文影响，适合比较同一原题在不同观察单元中的表现。真实情境测试则保留买家已有的上下文，例如已经谈过预算、计划迁移的平台或语言偏好；它更接近某次真实任务，却与控制测试不完全可比。两类样本都可以有价值，但应该独立呈现。

“新建聊天”也不自动意味着所有个性化关闭。Google 对 Gemini 历史聊天的说明表明，相关设置和产品能力可能让过去对话参与回答。执行者应记录可见设置和标签，不猜测隐藏状态，也不宣称已经清除了所有系统影响。平台更新后，需要重新核查可用控制项。

3. 地区是执行条件，不是用户标签

记录真实执行地、时区、界面语言、问题语言和观察时间，它们是不同字段。英文提问不等于美国用户，中文界面也不证明人在中国；API 的路由信息更不能替代消费者地理位置。若某个条件无法核实，就标为未知，并说明是否影响本次目的。

地区样本通常不能代表当地全部用户。账号类型、历史行为、设备版本和网络条件还可能不同。对外报告宜写“在某时段、某界面条件下的观察”，而不是“该国 AI 都不会推荐你”。没有必要为了收集地理证据获取测试者精确住址；保留足够支持研究范围的地区信息即可，个人资料应在共享前删除。

4. 执行前把问题与动作顺序冻结

给执行者一份编号明确的任务卡：打开指定入口，确认会话类型，复制题目，等待终态，保存回答，再检查实际展示的来源。任何补问、重新生成或更改模式都可能影响结果，需要记录为新轮次或新尝试。不能只保留第一次不理想之后重新生成的有利回答。

可使用一个模拟练习训练执行者：虚构买家问“现有客服团队应怎样比较可本地部署的知识库”。练习只检查复制、截图和命名流程，不产生真实品牌发现结论。执行者应理解自己记录界面事实，不负责给模型加产品介绍，也不应为了完成任务替模型补齐缺失引用。

5. 完整回答与截图必须互相印证

截图至少让审核者看出平台、原题、回答段落和可见条件。长答案需要连续保存，保留段落顺序；若导出文本，应核对没有漏掉警告、限制或后半段候选。只截一个品牌名称，无法判断它被推荐、被批评，还是作为不适用例子出现。

来源证据保留界面上实际显示的标题、网址或卡片，并记录能否打开。平台只给跳转链接时，应保存原链接，不猜测最终文章；当前打开后内容变化时，记录核验时间。截图不得包含其他聊天、个人邮箱、付款信息或无关账号内容。去身份处理不能改变回答正文，更不能移除不利结果。

6. 为失败和部分完成保留位置

无法登录、产品不可用、限流、页面加载失败、回答中断和平台拒绝应分别记录。已得到完整回答但没有来源，与没有完成回答也不同。对某题尝试了多少次、最终哪些可判定、哪些只保存了错误，都应在交付中列明，不让失败悄悄消失在分母外。

若事先允许恢复，说明等待条件、最大次数和是否保持原题。一次恢复不是额外的独立市场样本。已经看到回答后更改问题去获取满意结果，则是探索测试，需要另起编号。执行者不用替失败找一个听起来合理的产品原因；服务不可用通常不能说明目标品牌不适合推荐。

7. 与 API 对照时先列共同条件

同一个模型名称不意味着同一个完整产品配置。API 请求、网页系统指令、搜索工具、可用资料和用户上下文可能不同。OpenRouter 的搜索说明描述其请求路线与工具设置，不能拿来证明消费者界面采用相同路径。对照表应写清哪些条件能对齐，哪些不可见。

可以共同比较的是问题原文、是否点名品牌、语言、可见结果和来源内容；不能随意对齐的是隐藏模型版本、检索查询、账号个性化和路由。报告可展示“API 出现目标，网页样本未出现”的差异，但不能直接归因为地区屏蔽或某一页面问题。差异首先是下一轮调查的起点。

8. 证据命名让交付可以抽查

一种教学命名方式是“批次—题号—平台—端—尝试序号”，文本、截图和执行表使用同一前缀。执行表另外记录原文版本、开始结束时间、终态、截图清单和偏差。命名中无需出现测试者真实姓名；有必要的内部身份映射可以与客户交付分开保存。

审核者从任意一个结论出发，应能找到对应任务卡、完整答案和图像。再从任意截图反查执行表，确认它没有被放错题目。文件数量多并不意味着证据充分；关键是这些材料描述同一个观察单元。来源文件损坏、截图顺序不明或原题缺失时，应退回补证，而不是靠报告作者猜测。

9. 人工复核怎样形成结论

先核对执行是否符合约定，再判断实体、出现方式、描述准确性与来源支持。两位审核者出现分歧时，可保留待判断并记录原因，不必强行给每个格子一个确定标签。自动文字识别能够辅助检索截图，但最终重要片段仍需要与图像对照，避免漏字改变含义。

客户验收可以抽取一条正面观察、一条未提及和一条失败，要求完整追溯。还应检查不同地区样本是否用了不同问题，是否把多轮结果混成首轮，是否遗漏重新生成。这样验收的是执行可信度，而不是要求每位测试者都必须获得品牌推荐。

10. NiubiGEO 的人工服务如何衔接

NiubiGEO 的在线采集观察真实模型 API；指定网页或 App 的执行属于另外确认的人工范围。可以先用 API 找出重点问题，再针对目标客户的界面做验证，也可以直接从一个明确使用场景开始。系统不会自动把人工订单变成已经完成的消费者端证据，交付仍需要实际执行与复核。

最终报告列出已完成场景、完整证据、偏差、失败和下一步，不把某次界面差异写成全国排名。后续若要修改内容，应连接具体误解或信息缺口，再用相近条件复测。通过 真人测试入口提交平台、地区、语言和原题后，可先确认是否可执行，再安排次数、排期与证据要求。

11. 保留一份可复用的执行自检

开始前确认入口、原题、会话和授权范围；执行中保留所有尝试，不临场引导；结束后核对答案与截图、清理无关个人资料、检查来源和终态；交付时说明限制与不能比较的条件。每一项都应该能由另一位审核者检查，而不是只在执行者脑中成立。

如果目的从“观察首轮方案发现”改为“验证多轮购买建议”，应另开任务版本，记录新增上下文和停止条件。真实场景不必被过度简化，但复杂性必须写进报告。只有先把这些控制与未知解释清楚，人工观察才有能力补充自动采集，而不是增加另一组无法比较的截图。