AI 总结功能能返回文字，不等于它已经可用。模型更换、提示词调整、正文清洗规则变化，甚至同一模型的服务版本更新，都可能让总结悄悄变长、漏掉关键事实、混入原文没有的结论，或者破坏前端依赖的 JSON 格式。
因此，AI 总结不能只靠管理员偶尔阅读几条结果。更稳妥的方式是建立一套回归测试：固定一批有代表性的原文，为每篇文章保存人工评审依据，每次修改模型或提示词后重新生成，再比较质量与格式是否退步。
本文关注的是“怎样验证总结质量”，不重复讲抓取和任务调度。流水线拆分可先阅读Node.js AI 总结管线设计，多模型切换则参考Node.js 多模型轮询与故障切换。
一、先定义什么是合格总结
如果团队只说“读起来不错”，评审结果很难复现。可以把质量拆成六个可观察维度：
- 事实一致性：人物、产品、版本、时间和数字是否来自原文；
- 关键点覆盖：是否保留文章最重要的结论与限制条件；
- 信息密度：有没有重复、套话和不必要的背景；
- 表达清晰度：句子是否自然，主语和指代是否明确；
- 边界意识：原文不确定的内容，是否被模型写成确定事实；
- 格式合规：字段、长度、条目数量和数据类型是否符合程序约束。
其中，格式可以自动检查；事实一致性和关键点覆盖仍需要人工评审或有证据约束的辅助检查。不要把“模型自评 0.95”直接当作准确率。
二、建立固定且可追溯的测试集
测试集不应只选结构工整的短文。它需要覆盖线上真实会遇到的困难样本，例如：
- 包含多个相近产品名或模型名；
- 有版本号、日期、价格或百分比；
- 标题带有夸张表述，但正文结论更克制；
- 中文正文中混有英文代码和引用；
- 页面正文很短，或抓取后残留导航文本；
- 多个来源报道同一事件，但细节不同；
- 原文明确表示尚未确认或仅为预测。
每个样本至少保存稳定 ID、原文快照、来源 URL、抓取时间、正文哈希、关键事实清单和人工参考摘要。保存原文快照很重要：如果只保留 URL，上游页面更新后，同一次回归测试的输入就已经不同。
{
"id": "fixture-001",
"sourceUrl": "https://example.com/article",
"contentHash": "sha256:...",
"mustInclude": ["产品名称", "主要变化"],
"mustNotClaim": ["原文没有确认的发布日期"],
"referenceSummary": "由编辑审核的参考摘要"
}
参考摘要不是唯一标准答案。它的作用是帮助评审者对齐关键事实，而不是要求模型逐字复现。
三、用评分量表减少主观差异
可以给每个维度设置 0 到 2 分：
| 分值 | 事实一致性 | 关键点覆盖 | 清晰度 |
|---|---|---|---|
| 0 | 存在关键事实错误或无依据结论 | 遗漏核心结论 | 难以理解或严重重复 |
| 1 | 次要表述不够准确 | 覆盖部分关键点 | 基本可读但需要编辑 |
| 2 | 未发现与原文冲突的陈述 | 覆盖人工清单中的关键点 | 简洁、明确、可直接使用 |
上线门禁不应只看总分。一个总结即使其他维度得分较高，只要出现关键事实错误，也应进入人工复核。具体分值、权重与通过条件必须用真实样本校准，本文不把示例阈值当作本站实测结论。
如果多人参与评审，先让两位评审者独立打分，再讨论差异较大的案例。这样比共同阅读后直接达成一个分数，更容易发现量表定义是否含糊。
四、把确定性规则变成自动断言
程序最适合检查明确约束，例如字段是否存在、摘要是否为空、条目数量是否越界、是否泄露 HTML、是否重复标题。
import assert from 'node:assert/strict';
export function assertSummaryShape(result) {
assert.equal(typeof result.intro, 'string');
assert.ok(result.intro.trim().length > 0, 'intro 不能为空');
assert.ok(Array.isArray(result.picks), 'picks 必须是数组');
assert.ok(result.picks.length >= 1, '至少需要一条精选');
for (const item of result.picks) {
assert.equal(typeof item.title, 'string');
assert.equal(typeof item.summary, 'string');
assert.ok(!/<script|<iframe/i.test(item.summary), '摘要包含危险 HTML');
}
}
如果模型返回 JSON，还应使用 JSON Schema 或等价校验器约束类型、必填字段和额外属性。具体解析与修复策略可参考GLM-4.7-Flash 结构化 JSON 输出。
长度规则要以字符或分词后的单位明确计算，不能只在提示词里写“简短”。同样，不应自动断言某个总结必须包含全部原文数字，因为有些数字并非关键信息。适合写成规则的，必须是业务真正确定的约束。
五、记录每次生成的完整实验信息
如果只保存最终摘要，发生退化时很难定位原因。每次回归运行建议记录：
const runRecord = {
runId: crypto.randomUUID(),
fixtureId: fixture.id,
inputHash: fixture.contentHash,
provider: model.provider,
model: model.name,
promptVersion: 'summary-v3',
configVersion: '2026-08-13',
startedAt: new Date().toISOString(),
output: result,
validation: { passed: true, errors: [] },
usage: response.usage ?? null
};
记录模型配置 ID 即可，不要保存 API Key。供应商名称、模型名、提示词版本、输入哈希和运行时间，都是复现问题所需的信息。后台显示“当前使用哪个模型总结”时，也应来自这份执行记录，而不是只读取当前配置，因为配置可能在任务完成后被修改。
六、比较候选版本，而不是覆盖基线
设当前线上组合为基线 baseline，待发布的模型或提示词为 candidate。对同一批固定输入分别生成结果，再按样本展示差异。
function compareRuns(baseline, candidate) {
return candidate.map(next => {
const prev = baseline.find(x => x.fixtureId === next.fixtureId);
return {
fixtureId: next.fixtureId,
formatChanged: JSON.stringify(prev?.validation) !== JSON.stringify(next.validation),
previousOutput: prev?.output ?? null,
candidateOutput: next.output
};
});
}
纯文本 diff 能显示词句变化，却无法判断变化是否更准确。因此后台最好同时展示原文证据、旧总结、新总结、自动校验结果和人工评分。不要让候选结果直接覆盖基线；只有审核通过后，才更新生产配置和基线版本。
七、为事实核验建立证据链
完全依赖另一个模型判断“是否忠实”仍可能产生误判。更可审核的方式，是让总结中的关键陈述附带原文证据位置，然后由程序或人工核对。
{
"summary": "某产品增加了结构化输出能力。",
"claims": [
{
"text": "增加了结构化输出能力",
"evidence": ["paragraph-12"]
}
]
}
证据位置只能证明模型指向了某段原文，不能自动证明它理解正确，但能显著降低人工回查成本。涉及数字、否定词、时间范围和对比结论时，应优先进入严格核验。
八、设置分层发布门禁
一次回归测试可以分三层：
- 硬性失败：JSON 解析失败、必填字段缺失、关键事实冲突；
- 需要复核：输出变化明显、低把握样本、边界案例或新模型首次使用；
- 允许发布：自动规则通过，且抽样人工评审没有发现阻断问题。
“允许发布”不意味着总结永久正确。生产环境仍要保留人工编辑入口、失败重跑和旧版本回退。抓取与总结分开执行后，可以固定抓取结果，只重跑总结，从而避免上游内容变化干扰比较。
九、模型轮询场景要分别评估
如果网站支持多个模型轮询，不能只评估默认模型。每个可能承担总结任务的模型都需要跑同一测试集，并单独保存结果。故障切换后的备用模型还可能使用不同上下文长度、JSON 支持方式或敏感词策略。
建议把“模型配置 ID + 提示词版本”看作一个可发布单元。某个组合未通过回归时，即使 API 连通测试成功，也不应自动加入总结轮询池。多模型的重试、熔断和健康状态设计，可继续阅读Node.js 多模型轮询与故障切换。
十、推荐的最小落地顺序
对于刚开始建立原创内容系统的网站，可以按以下顺序实施：
- 从已人工审核的文章中选出一批不同类型样本；
- 固定原文快照，并写出关键事实清单；
- 保存当前模型、提示词和输出作为基线；
- 先实现 JSON、字段和长度等确定性断言；
- 在后台增加旧版与候选版并排审核；
- 记录人工评分、修改原因和最终决定；
- 模型或提示词变更前自动运行整套回归；
- 发布后持续收集失败案例，补充进测试集。
测试集不是一次性文件。每次遇到漏事实、错误归因、格式破坏或异常长文，都应把脱敏后的案例加入回归集，让同类问题以后更容易被发现。
上线前检查清单
- 测试输入使用固定快照并保存哈希；
- 测试集覆盖短文、长文、数字、否定与不确定表述；
- 模型、提示词、参数和执行时间可追溯；
- 格式错误与事实错误采用硬性门禁；
- 候选输出不会覆盖线上基线；
- 多模型轮询池中的每个模型分别通过评估；
- API Key 不进入日志和测试夹具；
- 未完成真实评估前，不对外宣称准确率或质量提升比例。
FAQ
可以只用另一个大模型当裁判吗？
可以把模型裁判作为筛查信号，但不应把它当作唯一真值。裁判模型也可能偏好特定文风、忽略细小事实错误，或受到输入顺序影响。关键样本仍应由人工结合原文证据审核。
每次运行结果不同，回归测试还有意义吗？
有意义。回归测试不是要求每个字完全相同，而是检查结构、事实边界和人工评分是否退化。固定输入、模型参数和提示词版本可以减少变量；对重要变更也可以重复运行，观察输出是否稳定。
自动测试通过后能直接发布吗？
不一定。格式断言只能证明输出符合程序约束，不能证明全部事实正确。高风险内容、新模型首次上线、明显变化和边界样本应进入人工复核。
应该先测模型还是先优化提示词？
先保存当前组合的基线，再一次只改变一个变量。否则模型和提示词同时更换，即使质量变化，也无法判断原因。
总结
可持续的 AI 总结系统，需要的不只是一个能返回文本的接口，而是一套能发现退化、保留证据并支持回退的质量流程。固定测试集让输入可复现，人工量表让质量有共同语言，自动断言守住格式底线，版本对比与发布门禁则避免未经审核的变化直接进入生产。
先从少量真实样本开始，把每次线上失败沉淀成新的测试夹具，比发布一个未经验证的“高准确率”数字更有价值。
让评估结果可以回到具体版本
质量回归必须绑定不可变的提示词版本和配置快照，才能判断变化来自模型还是 Prompt。可继续阅读 生产环境 Prompt 版本管理：灰度、评估与回滚 与 AI 内容管线可观测性。