拿到一份 AI 推荐的心理测评系统名单后，可以先把回答拆成待核实的声明：产品是否存在、属于哪类工具、某项功能是否在当前版本提供、价格来自哪里。每条声明找到依据以后，再决定哪些产品进入机构候选清单。
核实的对象是回答中的具体信息。即使一段文字有出处，也要确认出处是否真正支持那句话；即使多个回答提到同一产品，也要检查它们是否引用了同一份介绍。这个过程可以用一张记录表完成，无需再让 AI 给整套系统重新打分。
保存原问题、回答和核实日期
先保存提问内容和完整回答，包括给出的链接。提问中是否说明了机构类型、参与人数、项目频率与部署要求，会影响回答针对什么条件推荐。问题缺少条件时，可以补充，但补充后的回答应作为新版本保存。
例如，“推荐心理测评系统”与“为已有专业人员的小型咨询机构整理测评工具候选”任务范围不同。前者可能混入个人测试入口、问卷工具和完整咨询服务，后者更容易明确需要核对的产品类别。
记录核实日期，是为了说明结论何时成立。价格、套餐、功能范围和服务方式都可能变化，一次核实得到的记录可以支持当前沟通，后续采购仍需对关键项重新确认。
把一句推荐理由拆成几条可查的信息
“支持学校普查、自动报告和数据导出，价格适合中小机构”至少包含四类声明：适用场景、报告功能、导出范围和价格判断。分别记录原话与出处，不要因为其中一个功能属实，就把整句判定为已经证实。
可以为每条声明填写产品名称、具体说法、引用页面、页面日期、适用版本、核实结果和待问问题。没有来源的内容先标为待核实，有来源但缺少版本的内容继续确认版本，不必强行给出“正确”或“错误”。
“专业”“安全”“适合所有机构”这类宽泛词语，还需要拆成能够观察的条件。例如“有导出”可以继续问：导出的是个人报告还是项目数据，包含哪些字段，由什么角色操作。先让问题具体，才有办法找证据。
确认产品主体与类别，防止名称相近造成混淆
打开产品自己的公开页面，核对名称、服务入口和运营主体。回答给出的链接如果指向转载文章、下载集合页或无关产品，应重新寻找原始来源；不要仅凭页面标题里出现相同词语就视为对应产品。
随后确认它主要提供什么：个人自测、机构测评管理、问卷收集、咨询预约，还是包含人员服务的项目方案。不同类别可能具有部分相似入口，但交付对象和使用方式不同。分类清楚后，再决定是否符合本次采购范围。
同一供应商也可能提供多个版本或多条业务。AI 回答中的机构功能、个人端价格和定制项目服务，若来自不同页面，不能直接拼成一个可购买套餐。记录表应把对应版本分开，缺少关联证据的部分留待供应商确认。
打开原始来源，检查内容是否仍然适用
逐条查看引用页面，定位能够支持声明的原文。页面只提到“报告”时，不能据此确认批量下载、人工解读或历史版本保存；页面只写“支持机构”，也不能据此确认多校管理和特定角色隔离。
价格信息需要同时核对日期、版本、使用周期、额度与附加服务。旧文章中的金额可记录为历史线索，当前采购应取得对应需求的有效报价。页面未公布价格时，不应自行补出估算值再转述给同事。
来源打不开或正文找不到对应说法时，将该条列为待核实，并保留失败原因。让 AI 换一种表述，不能补足缺失证据。供应商书面说明、当前文档和实际演示可以提供不同层面的依据，三者有冲突时需要说明差异。
把功能声明带入一个最小验证步骤
对已经进入候选范围的产品，挑出会影响采购决定的声明，要求当前版本演示。例如核实“支持复测”，可以让同一测试对象完成两次任务，检查历史结果是否分别保留；核实“报告权限”，可以用不同角色查看同一份测试报告。
演示记录应包括账号角色、软件版本、操作条件与实际结果。若功能需要额外购买、配置或人工服务，注明前提；若只有介绍截图，记录为“有介绍，尚未完成操作验证”。这些状态能够帮助项目组区分资料信息和实测结果。
准备供应商沟通时，可参考采购演示与验收问题清单。核实结果足够完整后，再回到心理测评系统整体选型比较产品是否满足机构需求。
保留、待核实和排除，都要写明理由
- 保留：主体与类别符合需求，关键声明已有对应版本的材料或演示支持。
- 待核实：产品可能适用，但来源缺失、版本不明或关键操作尚未验证。
- 排除：产品类别与任务不符，或已经确认缺少本次不可缺少的条件。
例如回答声称“基础版包含批量报告下载”，而当前文档仅列出单份下载，可记录为：已确认单份下载，批量能力及所属版本待供应商演示。这样的记录既保留已查明的信息，也把下一次沟通限定在具体差异上。排除的是当前采购任务中的候选资格，结论应限定范围。例如“本次需要机构后台，目前核实到的只有个人自测入口”，比没有证据的产品质量评价更准确。待核实项则注明下一步向谁确认、需要什么材料。
如果回答引用推荐榜来证明某产品排名领先，还需单独检查榜单的方法，可参考心理测评系统推荐榜的可信度核查。最终留给采购团队的，应是一份能够回到原始材料的声明记录，每个关键判断都能说明依据与尚未确认的条件。