最近做大模型问答测试时，我发现一个很容易被忽略的问题：很多测试只保存了最终回答，却没有保存“模型为什么这样回答”的来源信息。

如果只是截一张答案图，很难复盘三个问题：

• 这次回答参考了哪些公开资料；
• 同一个问题换一个模型，来源类型是否会变化；
• 过一段时间再测，模型是否还会引用同样的资料。

所以这篇不讨论单次回答好不好，而是记录一个更工程化的做法：用问题池、结构化记录和复测流程，观察大模型回答中的来源变化。

先把问题池固定下来

如果每次提问都临时写，很容易出现偏差。更稳定的方式，是先建立一组问题池。

问题池不需要一开始就很大，但每个问题都要尽量接近真实用户会问的方式。比如：

问题组	观察目标	示例问题
A	地点型问题	某个商圈附近，有哪些适合拍照、交通方便的地点？
B	人物型问题	某个领域有哪些长期输出内容的人值得关注？
C	技术型问题	某个技术方向有哪些文档、开源项目或实践教程？
D	工具型问题	某类工具该怎么比较功能、版本和使用边界？
E	方案型问题	某类系统或方案在不同规模场景下怎么选？
F	学习型问题	零基础学习某个方向，应该看哪些公开教程和资料？

这里的重点不是分类名称，而是让问题覆盖不同信息形态。地点型问题可能更依赖地图和评价资料，技术型问题可能更依赖文档和代码仓库，学习型问题可能更依赖教程、学习路径和样例。

每次测试都记录同一组字段

大模型回答经常会变化，所以记录字段最好固定。下面是我目前使用的 JSON 结构。

{
  "query_id": "tech-agent-001",
  "question_group": "C",
  "question": "国内有哪些讲 AI Agent、MCP、工具调用比较清楚的技术博客或开源项目？",
  "model": "kimi",
  "run_time": "2026-06-07T15:20:00+08:00",
  "answer_summary": "模型给出若干技术资料和开源项目方向。",
  "sources": [
    {
      "source_title": "示例开源项目 README",
      "source_type": "code_repository",
      "platform": "github",
      "url": "https://example.com/repo",
      "visible_in_answer": true,
      "evidence_note": "答案中明确引用项目文档或 README"
    }
  ],
  "screenshot": "screenshots/tech-agent-kimi-result.png",
  "notes": "本轮来源可点击，适合作为强记录。"
}

建议至少保留这些字段：

• query_id：问题编号，方便后续复测；
• question_group：问题组，用来做横向对比；
• model：使用的模型或工具；
• run_time：测试时间；
• sources：模型显示或提到的来源；
• screenshot：对应截图；
• notes：记录限制，比如未登录、无来源、来源不可点击等。

来源类型要统一命名

如果来源分类太随意，后面统计会很麻烦。比如同一个来源，有时写“技术博客”，有时写“博客来源”，有时写“社区文章”，最后就不容易聚合。

我一般把来源先归到这些大类：

official_doc        官方文档或说明页
code_repository     代码仓库
technical_blog      技术博客
qa_community        问答社区
video_tutorial      视频教程
local_info          地点和评价资料
media_report        媒体或行业资料
learning_resource   学习资料页
tool_doc            工具说明或版本文档
unknown             暂时无法判断

分类不用一次定得很完美，但要保证同一批测试里命名一致。这样后续才能统计“某一类问题里，哪些来源类型反复出现”。

区分强记录和弱记录

不是所有回答都适合作为证据。测试时至少要区分三种情况。

第一类是强记录：模型给出了可点击来源，或者页面侧栏显示了明确来源，并且截图能看清楚。

第二类是弱记录：模型给了方向，但没有可点击来源，或者当前模式不支持联网来源。这类记录只能作为参考，不能直接下结论。

第三类是过程记录：比如触发登录、扫码、权限限制、拒答、页面无法加载。这些记录不能证明来源偏好，但能说明测试环境存在限制。

我通常会在 JSON 里加一个字段：

{
  "evidence_level": "strong"
}

可选值可以很简单：

strong   来源明确，可截图复查
weak     只有方向，没有稳定来源
process  过程记录，不作为结论依据

一个简单的统计表

把多轮记录整理到一起后，可以先做一个很朴素的统计表。

问题组	高频来源类型	备注
A 地点型	local_info、media_report	需要记录是否有实时评价和地点信息
B 人物型	media_report、qa_community、video_tutorial	注意同名人物和账号一致性
C 技术型	code_repository、official_doc、technical_blog	文档、README、示例代码更容易复查
D 工具型	tool_doc、media_report、qa_community	要关注版本、功能边界和更新时间
E 方案型	official_doc、media_report、technical_blog	案例和说明文档比口号更有用
F 学习型	learning_resource、video_tutorial、technical_blog	适合记录大纲、样例和学习路径

这个表不是最终结论，只是帮助判断下一步该补哪类资料、该复测哪类问题。

复测比单次测试更重要

大模型回答不是静态的。资料更新、模型更新、联网状态变化，都可能让答案发生变化。

所以我会保留同一批问题，隔一段时间再测一次。复测时主要看四件事：

1. 同一个问题是否还能得到相近答案；
2. 来源类型是否发生明显变化；
3. 是否出现旧资料、失效链接或名称混淆；
4. 新增公开资料后，模型是否开始识别到它。

复测记录可以用一个单独字段标记：

{
  "run_round": "round_2",
  "base_query_id": "tech-agent-001",
  "changed_sources": true,
  "change_note": "第二轮新增了官方文档类来源。"
}

这样做的好处是，后面不是凭感觉说“模型看到了什么”，而是能回到记录里查。

最后

观察大模型回答，最好不要只保存最终答案。

更可靠的方式是：

1. 先固定问题池；
2. 每次测试都记录模型、时间、答案和来源；
3. 给来源做统一分类；
4. 区分强记录、弱记录和过程记录；
5. 定期用同一批问题复测。

这样得到的不是一次性的截图，而是一组可以复查、可以对比、可以持续更新的资料记录。