AI 输出质检流水线实战:规则检查、结构化结果和人工兜底
来源:17golang原创
时间:2026-06-13 09:51:01 394浏览 收藏
AI 应用上线后,最容易被低估的不是“能不能生成”,而是“生成后能不能稳定可用”。一段回复看起来很完整,但可能缺少来源、格式不符合页面字段、出现不该出现的承诺,或者和用户问题偏离太远。如果这些内容直接进入页面、工单或运营后台,后续返工成本会很高。
本文用“AI 生成帮助中心回答”的场景,搭一条轻量质检流水线:模型先产出草稿,程序按规则检查,再要求结构化结果,低分内容进入自动返修或人工兜底。思路参考了 OpenAI 官方关于结构化输出和提示工程的建议,但示例是面向普通业务系统的简化版本。
摘要
AI 输出质检不要只靠人工肉眼看,也不要只靠一句“请严格输出”。更稳的方式是把规则拆成可检查的字段:是否回答了问题、是否有来源、是否触发风险词、是否符合 JSON 结构、是否达到最低质量分。这样系统可以自动决定“直接通过、自动返修、人工复核”。
适合人群
适合正在做 AI 客服、知识库问答、内容生成、运营文案辅助、工单摘要的开发者。你需要了解基本 JavaScript、JSON 和接口返回处理。
目录
- 为什么 AI 输出需要质检
- 把模型输出接入质检流水线
- 用结构化结果固定字段
- 低分输出进入返修或人工兜底
- 上线前检查清单
一、为什么 AI 输出需要质检
很多团队刚接入 AI 时,会把重点放在提示词上:写清楚角色、任务、语气、长度限制。这当然重要,但提示词不是保险箱。业务系统仍然需要在模型返回后做一层检查,尤其是以下几类场景:
- 回答要展示给外部用户,不能出现过度承诺。
- 回复必须带来源,否则客服无法追溯依据。
- 内容要进入固定字段,比如标题、摘要、标签、风险提示。
- 低质量内容不能直接发布,要进入返修或人工复核。
因此,AI 输出更像“候选内容”,不是最终内容。它应该先经过规则检查,再决定去向。
二、把模型输出接入质检流水线
一条最小可用的质检流水线可以分成四步:用户问题和模型草稿进入系统;规则检查器扫描格式、来源和风险;模型或程序返回结构化 JSON;最后根据结果决定通过还是返修。

这张图里有两个关键点:第一,规则检查要靠近输出入口,不能等到发布前才发现问题;第二,质检结果要结构化,方便后续程序分支处理。
先写一个简单的规则检查器,模拟业务侧对回答文本做快速扫描:
const riskWords = ["保证赚钱", "百分百解决", "无需审核"];
function checkDraft(answer) {
const issues = [];
if (answer.length answer.includes(word));
if (risky) {
issues.push({ type: "risk_word", message: `命中风险词:${risky}` });
}
return issues;
}
真实业务里,规则可以来自数据库配置,也可以按栏目、业务线、用户等级做不同阈值。最重要的是:规则要能解释,方便运营和开发一起调整。
三、用结构化结果固定字段
如果只让模型返回一段自然语言,后续程序很难稳定判断质量。更推荐让模型输出固定字段,例如 score、passed、issues、nextAction。官方结构化输出文档也强调,可以用 JSON Schema 约束模型返回的结构。
{
"score": 82,
"passed": true,
"issues": [],
"nextAction": "publish",
"rewriteHint": ""
}
业务侧可以先定义一个结果对象,再把规则检查和模型自检结果合并:
function buildQualityResult(answer) {
const issues = checkDraft(answer);
const baseScore = 100;
const score = Math.max(0, baseScore - issues.length * 25);
let nextAction = "publish";
if (score 0) {
nextAction = "rewrite";
}
return {
score,
passed: nextAction === "publish",
issues,
nextAction,
rewriteHint: issues.map((item) => item.message).join(";"),
};
}
这样做的好处是清楚:页面只关心 passed,任务队列只关心 nextAction,运营后台可以展示 issues 和 rewriteHint。
四、低分输出进入返修或人工兜底
不要把所有失败都丢给人工。更合理的策略是按分数和问题类型分流:
- 分数高且无问题:直接通过。
- 缺来源、太短、格式不齐:自动返修一次。
- 命中风险词、事实不确定、用户投诉相关:进入人工复核。

返修不是简单地“再生成一次”,而是把质检结果写回提示词,让模型明确知道要改什么:
function buildRewritePrompt(question, answer, qualityResult) {
return [
"请根据质检问题修正回答。",
`用户问题:${question}`,
`原回答:${answer}`,
`需要修正:${qualityResult.rewriteHint}`,
"要求:补足来源,删除不确定承诺,保持回答简洁。"
].join("\\n");
}
自动返修建议限制次数,比如最多 1 到 2 次。多次仍然不过,就进入人工复核,避免系统在低质量内容上反复消耗。
五、接口返回建议
对接前后端时,可以把 AI 草稿和质检结果一起返回,方便页面展示状态。
{
"draft": "这里是 AI 生成的回答正文...",
"quality": {
"score": 75,
"passed": false,
"issues": [
{ "type": "missing_source", "message": "缺少来源说明" }
],
"nextAction": "rewrite",
"rewriteHint": "缺少来源说明"
}
}
前端可以用这个结构做三种状态:绿色表示可发布,橙色表示返修中,红色表示需要人工处理。这样运营同学不需要猜测模型为什么被拦下。
常见问题
1. 质检规则要不要全部交给模型判断?
不建议。长度、必填字段、风险词、JSON 格式这类规则更适合程序检查;语义完整度、回答是否贴题,可以交给模型辅助判断。两者结合更稳。
2. 分数阈值怎么定?
先从简单阈值开始,比如 80 分以上通过,60 到 79 分返修,低于 60 分人工复核。上线后根据真实误拦和漏拦情况调整。
3. 结构化结果还需要人工看吗?
需要。结构化结果解决的是“程序能读懂”,不代表内容一定正确。涉及投诉、法律、医疗、财务等高风险场景,人工兜底仍然要保留。
上线前检查清单
- 是否定义了通过、返修、人工复核三种去向。
- 规则是否能解释,方便运营和开发共同调整。
- 结构化字段是否稳定,前端和队列是否只依赖固定字段。
- 自动返修是否限制次数,避免反复消耗。
- 人工复核是否能看到原问题、原回答、质检问题和返修建议。
参考资料
总结
AI 输出上线前,最好先经过一条明确的质检流水线。规则检查负责发现硬性问题,结构化结果负责让程序稳定分支,低分内容进入自动返修或人工复核。这样既能减少人工重复检查,也能避免低质量内容直接进入线上流程。
-
284 收藏
-
387 收藏
-
328 收藏
-
426 收藏
-
147 收藏
-
101 收藏
-
233 收藏
-
174 收藏
-
339 收藏
-
260 收藏
-
438 收藏
-
152 收藏
-
232 收藏
-
280 收藏
-
152 收藏
-
102 收藏
-
247 收藏
-
- 前端进阶之JavaScript设计模式
- 设计模式是开发人员在软件开发过程中面临一般问题时的解决方案,代表了最佳的实践。本课程的主打内容包括JS常见设计模式以及具体应用场景,打造一站式知识长龙服务,适合有JS基础的同学学习。
- 立即学习 543次学习
-
- GO语言核心编程课程
- 本课程采用真实案例,全面具体可落地,从理论到实践,一步一步将GO核心编程技术、编程思想、底层实现融会贯通,使学习者贴近时代脉搏,做IT互联网时代的弄潮儿。
- 立即学习 516次学习
-
- 简单聊聊mysql8与网络通信
- 如有问题加微信:Le-studyg;在课程中,我们将首先介绍MySQL8的新特性,包括性能优化、安全增强、新数据类型等,帮助学生快速熟悉MySQL8的最新功能。接着,我们将深入解析MySQL的网络通信机制,包括协议、连接管理、数据传输等,让
- 立即学习 500次学习
-
- JavaScript正则表达式基础与实战
- 在任何一门编程语言中,正则表达式,都是一项重要的知识,它提供了高效的字符串匹配与捕获机制,可以极大的简化程序设计。
- 立即学习 487次学习
-
- 从零制作响应式网站—Grid布局
- 本系列教程将展示从零制作一个假想的网络科技公司官网,分为导航,轮播,关于我们,成功案例,服务流程,团队介绍,数据部分,公司动态,底部信息等内容区块。网站整体采用CSSGrid布局,支持响应式,有流畅过渡和展现动画。
- 立即学习 485次学习