阿程在创业园开了一家“AI 快餐店”，后厨有位大厨——一台大模型——出菜又快又香。可时间一长，阿程发现大厨偶尔会把盐当成糖，端出一道“黑暗料理”。顾客投诉多了，阿程想了个办法：在出菜口请了一位试味师。每一份菜端给顾客前，试味师先尝一口，对照菜品标准卡打分：不合格的菜当场打回后厨重做，合格的才端上桌。试味师还会把每天的失败记录整理成册，后厨照着改进菜谱，菜单也越做越稳。这个“出菜—试味—回炉—上桌—沉淀经验”的循环，就是我们要讲的 Loop Engineering——不过这次，大厨和试味师都是 AI，而“菜品”是 AI 输出的每一条内容。

岗位关联

掌握“AI 自主检查输出质量”这套方法，你能让 AI 应用从“能跑”升级为“可信”，这是 AI 应用开发者、LLM 架构师做质量保障时绕不开的核心能力。

目录
  1. 可视化演示
  2. 检查基座
  3. 机制设计
  4. 标准定义
  5. 失败处理
  6. 闭环迭代
  7. 成本平衡
  8. 风险边界
  9. 落地实践
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

展示Loop工程实践中AI输出自我检查闭环流程、质量标准多维度评估与成本效果权衡决策。

本节配有交互动效（进入视口后自动加载，约 3KB）。

AI输出自我检查闭环 生成阶段：AI模型输出初始结果 检查阶段：自动校验质量标准 Loop = Gen → Chk → Judge → Fix 闭环迭代流程

检查基座

阿程刚提出“让 AI 检查 AI”时，店里的老员工都摇头：“大厨自己尝自己的菜，能尝出毛病吗？”阿程却觉得未必。他试了一下，让大厨把同一道菜先放下勺子，换一身试味师的白袍，用另一套话术重新审视这道菜——果然，大厨真能挑出自己刚才没注意到的咸淡问题。原来，大模型天生具备一种“退一步看自己”的能力，这种能力在工程上叫“自省”。

要让这种自省真正可靠，关键不是换人，而是“换流程”。大厨还是那位大厨，但生成和检查必须拆成两个独立环节：先闷头做菜，再冷静尝菜。如果一边做一边尝，很容易自我陶醉。对应到工程上，就是生成器（Generator）和检查器（Checker）在流程上严格分离——它们可以是同一个模型，但角色、提示词、上下文必须分开。

事实上，大模型在训练中学习了海量高质量文本，已经具备一定的“元认知”能力，也就是能评估“我这个回答到底靠不靠谱”。把这种能力和流程分离结合起来，就构成了自检闭环的底座：

大厨换不换白袍不重要，重要的是他必须站在“试味师”的位置上重新看菜。当生成与检查在流程上彻底分离，AI 的自省才真正可靠。

y=G(x),q=C(y,R),D(q,τ)={通过q≥τ重试q<τy = G(x), \quad q = C(y, R), \quad D(q, \tau) =\begin{cases}\text{通过} & q \ge \tau \\\text{重试} & q < \tau\end{cases}
这个公式描述了一次完整的“生成—质检—裁决”闭环：生成器产出答案，检查器对照标准打分，最后根据阈值决定放行还是回炉。
  1. 生成输出生成器 \( G \) 接收用户请求 \( x \)，产出一份候选答案 \( y \)。这就好比大厨根据订单先做出一道菜。
    y=G(x)y = G(x)
  2. 质量打分检查器 \( C \) 拿着参考标准 \( R \) 审视 \( y \)，给出一个质量分 \( q \)。这就是试味师对照标准卡打分。
    q=C(y,R)q = C(y, R)
  3. 判定函数把得分 \( q \) 与合格阈值 \( \tau \) 比较，输出“通过”或“重试”两种裁决。
    D(q,τ)D(q, \tau)
  4. 通过分支当质量分不低于阈值，答案直接放行，交付给用户。
    q≥τ⇒通过q \ge \tau \Rightarrow \text{通过}
  5. 重试分支当质量分低于阈值，答案被打回，进入下一轮生成。
    q<τ⇒重试q < \tau \Rightarrow \text{重试}

机制设计

出菜口有了试味师，阿程又发现新问题：试味师有时会凭感觉放行，同样的菜今天觉得咸、明天觉得淡。阿程决定把试味这件事“流程化”：每道菜必须走完“出品—检查—记录—裁决”四步，一步不能少。这就是自检机制设计的核心思路。

工程上最常见的做法是双模型架构：用一个强模型做生成器，再用另一个（或同一个模型的不同实例）做检查器，两边角色隔离、互不干扰。这样即使生成器产生了幻觉，检查器也能用更冷静的视角发现异常。与此同时，检查提示词要精心设计：让检查器扮演“挑剔的评审”，明确列出“请找出事实错误、逻辑断裂、信息缺失”，而不是笼统地问“这回答好吗”——笼统的问题只会得到笼统的“挺好的”。

更进一步，复杂的任务可以配置检查链：先做最廉价的完整性检查（有没有缺遗漏），再做中等成本的事实性检查，最后做昂贵但严格的语义一致性检查。由易到难逐级过滤，就像试味师先看菜品是否少配菜，再尝咸淡，最后才评判整体火候。每一级不过关，直接打回，不必浪费后面几级的算力。

这套机制让“自我检查”不再是灵光一现，而是一条有固定顺序、固定角色、固定话术的流水线。流程越固定，结果越稳定。

标准定义

试味师上岗前，阿程和他一起制定了一份“菜品合格标准卡”：咸淡占 40 分、火候占 30 分、摆盘占 20 分、出餐速度占 10 分，总分低于 70 分一律回炉。有了这张卡，试味师不再“凭感觉”，而是逐项打分、算出总分。这个标准卡，就是工程质量标准。

在 AI 输出质检中，标准卡需要先做维度拆解：把笼统的“质量好”拆成可打分的小项，比如完整性（关键信息是否齐全）、准确性（事实是否真实）、可读性（表达是否通顺）、业务合规（是否遵守既定规则）。拆完之后做权重设计：不同业务对各维度的侧重不同，金融风控文案更看重准确性，营销文案更看重可读性，权重就应当相应放大。最后把这些维度翻译成机器可执行的自查清单：每个维度下写明“检查什么、扣几分、什么情况一票否决”。

维度得分和权重的组合，用一个加权评分公式来描述：

标准卡不是挂在墙上当摆设的。阿程把这张卡压在试味师的案头，每一道菜都按它打分。有了可量化的标准，AI 自检才从“我觉得”变成了“数据说”。

S=∑i=1nwisi∑i=1nwiS = \frac{\sum_{i=1}^{n} w_i s_i}{\sum_{i=1}^{n} w_i}
加权评分公式把多个维度的得分按重要程度综合成一个总分，是“标准卡”的数学化表达。
  1. 维度得分\( s_i \) 是第 \( i \) 个质量维度的得分，取值通常在 0 到 1 之间。
    si∈[0,1]s_i \in [0,1]
  2. 维度权重\( w_i \) 表示第 \( i \) 个维度的重要程度，权重越大越关键。
    wi>0w_i > 0
  3. 加权求和把所有维度的得分乘以权重后累加，重要维度对总分影响更大。
    ∑i=1nwisi\sum_{i=1}^{n} w_i s_i
  4. 权重归一除以权重总和，把总分的量纲归一化，避免因维度数量不同导致分数虚高。
    ∑i=1nwi\sum_{i=1}^{n} w_i

失败处理

就算有了标准卡，回炉的菜也不可能无限重做。阿程定下规矩：一道菜最多回炉 3 次，3 次还不过就换一道更简单的菜（降级），或者请店长亲自品（人工接管）。这个“上限”的设计，就是失败处理的核心。

重试生成是最直接的兜底：打回的菜换个做法再试一次。在 AI 里，这相当于修改生成提示词（比如补充“请更严谨”）、调整采样温度、或者换一个模型版本重新生成。但重试不是免费的，每一次重试都在消耗时间和算力，而且如果任务本身就超出模型能力，重试再多也会失败。因此需要设定重试上限，超过上限就进入降级方案：生成一个更保守、更简短的回答（比如“抱歉，我无法回答这个问题，请提供更多信息”），保证系统永远有一个基本可用的输出兜底。若业务场景不允许降级，则触发人工接管：把生成结果、检查报告、重试记录一起打包推送给人工客服处理。

为什么需要重试上限？可以用概率来理解：

阿程在试味记录本上画了一条线：3 次不过就换方案。这不是认输，而是聪明的止损——把有限的资源留给下一道更有可能通过的菜。

P(连续 N 次失败)=(1−p)N,E[T]=1pP(\text{连续 } N \text{ 次失败}) = (1-p)^N, \quad E[T] = \frac{1}{p}
这个公式说明：如果单次通过率是 \( p \)，连续多次失败的概率会指数下降，但永远不会严格为零。期望尝试次数是 \( 1/p \)，据此可以设计合理的重试上限。
  1. 单次通过率\( p \) 表示每次生成恰好质检合格的概率，取值在 0 到 1 之间。
    p∈(0,1)p \in (0,1)
  2. 连续失败概率每轮失败概率是 \( 1-p \)，连续 \( N \) 次都失败的概率按指数衰减。
    (1−p)N(1-p)^N
  3. 期望尝试次数每次尝试独立且通过率为 \( p \) 时，平均需要 \( 1/p \) 次才能通过。
    E[T]=1pE[T] = \frac{1}{p}
  4. 上限设计根据期望次数再加一点裕量设定重试上限 \( N_{\max} \)，防止极端情况下的死循环。
    Nmax⁡≈1p+裕量N_{\max} \approx \frac{1}{p} + \text{裕量}

闭环迭代

阿程发现，光有标准卡还不够。开业一个月，他翻看试味记录，发现“酱油类菜品总是偏咸”反复出现。于是他把这条教训加到标准卡里：以后试味师对酱油类菜品额外加查一轮咸淡。这就是闭环迭代——把每一次失败变成下一次做得更好的依据。

闭环的第一步是反馈收集：每一次检查不通过的样本、检查器的评分明细、最终的人工裁定，都要结构化地存下来。这些记录是闭环的“燃料”。有了燃料，才能做第二步规则沉淀：对失败样本做高频统计，把反复出现的问题翻译成新的检查项或调整原有维度的权重。比如“合同类回答总是遗漏违约责任条款”，那就新增一条检查项“是否包含违约责任”。第三步是效果度量：定期抽取一批人工标注的样本，用它来评估检查器自身是否偏严或偏松——如果检查器的判断和人工判断经常不一致，说明评分标准本身需要校正。

权重如何随反馈调整？可以用一个增量更新的公式：

阿程每天打烊后都会翻试味记录，把最近的“翻车点”沉淀到标准卡里。日子久了，菜单的通过率越来越高，顾客投诉也越来越少。闭环不是一次性工程，而是让系统越用越聪明的永动机。

wi(t+1)=wi(t)+α(sihuman−simodel)w_i^{(t+1)} = w_i^{(t)} + \alpha \left( s_i^{\text{human}} - s_i^{\text{model}} \right)
这个公式表示：用“人工标注分”与“模型自评分”的差距，去修正第 \( i \) 个检查项的权重，让检查标准持续向人工标准靠拢。
  1. 旧权重\( w_i^{(t)} \) 是第 \( t \) 轮迭代里第 \( i \) 个检查项的权重。
    wi(t)w_i^{(t)}
  2. 偏差信号人工标注分 \( s_i^{\text{human}} \) 与模型自评分 \( s_i^{\text{model}} \) 的差值，代表检查器在哪个方向“偏了”。
    sihuman−simodels_i^{\text{human}} - s_i^{\text{model}}
  3. 学习步长\( \alpha \) 控制每次修正的幅度，取一个很小的正数，避免一次改太猛。
    0<α≪10 < \alpha \ll 1
  4. 新权重在旧权重上加上“偏差乘以步长”，算出下一轮的权重。
    wi(t+1)w_i^{(t+1)}

成本平衡

试味师每道菜都细细品尝，确实稳，但成本也高——后厨出菜变慢了，高峰期顾客等得直跺脚。阿程开始琢磨：能不能在“都尝”和“不尝”之间找个折中？他决定：大客户套餐全检，普通工作餐按 30% 比例抽检。这就是成本平衡。

对应到 AI 工程，检查频次是第一层调节旋钮：对高风险场景（对外合同、法律意见、医疗建议）做全量检查；对低风险场景（内部摘要、临时草稿）降低检查频次。第二层旋钮是抽样策略：在低风险内容中按比例随机抽检，抽到不合格就整批提示风险，让模型“时刻觉得可能被查”。第三层是分级检查：低价值内容只做一次轻量检查（比如用规则检查关键词是否齐全），高价值内容才走完整的多级检查链。

如何决定抽检比例？本质上是在“检查成本”和“漏检损失”之间取平衡：

大客户的菜全检，员工餐抽检，高峰期动态调整抽检率——阿程的店在成本和质量之间找到了平衡点。Loop 工程不是不计代价地追求完美，而是在可接受的成本里守住质量底线。

C(r)=r⋅Ccheck+(1−r)⋅pmiss⋅LC(r) = r \cdot C_{\text{check}} + (1-r) \cdot p_{\text{miss}} \cdot L
这个公式把总成本拆成两部分：抽检付出的检查成本，加上漏检带来的期望业务损失。通过调节抽检率 \( r \)，可以让总成本最低。
  1. 抽检率\( r \) 表示内容被检查的比例，取值 0 到 1 之间。
    r∈[0,1]r \in [0,1]
  2. 检查成本被抽检的内容需要花费的算力与时间成本。
    r⋅Ccheckr \cdot C_{\text{check}}
  3. 漏检损失没被抽检的内容中，漏掉质量问题造成的业务损失期望。
    (1−r)⋅pmiss⋅L(1-r) \cdot p_{\text{miss}} \cdot L
  4. 寻优目标找到一个 \( r \) 让总成本最小，这就是“最优抽检率”。
    r∗=arg⁡min⁡rC(r)r^{*} = \arg\min_{r} C(r)

风险边界

试味制度运转了三个月，阿程发现试味师也有“失灵”的时候。有次一位顾客投诉菜太咸，试味师却坚称“咸淡刚好”；还有一次，试味师在记录本上写了“已复检”，但实际上只是把上次的结论原封不动抄了一遍。这些失灵，就是 AI 自检的风险边界。

第一种风险叫伪反思：模型嘴上说“我检查过了”，实际上只是复述原答案，没有真正改进。比如让它找错误，它把原文重新输出一遍并声称“未发现问题”。第二种叫自洽陷阱：生成器和检查器共享同样的偏见，生成器编了一个错误事实，检查器因为拥有同样的“知识盲区”，反而觉得这个错误很合理，一错再错。第三种是盲区：模型对某些领域本身就缺乏判断能力——它不知道自己不知道，这时候无论检查多少次，都查不出问题。

如何防范？阿程的办法是“引入外部信号”：让试味师偶尔把菜品端给隔壁店的老师傅尝一口（外部工具/知识库校验），或者请真正的顾客（人工抽检）参与打分。在工程上，这意味着用检索增强（RAG）校验事实、用规则引擎校验格式、用人工抽检校准结果。自检不是万能的，它需要外部信号来兜住边界。

试味师不是神，他也有自己的口味盲区。承认自检的边界，并用外部信号补上盲区，才是对质量真正的负责。

落地实践

阿程准备把试味制度推广到他的第二家分店，但他没有直接全面铺开。他先让第二家店试运行一周，观察试味记录和顾客反馈，确认没问题后才正式开店；同时，每一份试味记录都存档，标准卡每次更新前都保留旧版本，一旦新标准卡导致通过率暴跌，立刻回退到旧版。这套落地方法，对应工程上的三个关键动作。

全程追踪：每一次 AI 请求，从生成、检查、重试到最终交付的完整链路都要留痕。线上出了问题，能顺着链路快速定位是哪一环节失守。版本回滚：检查器的提示词、标准卡的权重、重试上限这些配置都应当版本化管理，任何一次变更都要能一键回退到上一个稳定版本。灰度上线：新检查规则先在 5% 流量上跑一段时间，对比通过率和用户反馈，确认稳定后再逐步放大到全量。

回滚与灰度是“质量闭环”的保险丝。没有保险丝的闭环，一旦检查规则写错，可能把大量合格输出误杀，反而制造更大的事故。

阿程的第二家分店顺利开业，试味制度从一家店复制到两家，又从两家复制到一个品牌。Loop 工程的价值不在于某一次“检查”有多聪明，而在于这套“生成—检查—回炉—沉淀”的循环能够稳定地、可复制地运转下去。

AI 应用场景

智能客服工单回复自检

阶段：生成后置质检与兜底

解决的问题：传统客服 AI 直接回复用户，一旦大模型生成错误信息（如错误退款政策），会直接引发客诉。自检闭环在回复发出前先由第二个模型扮演“质检员”，对照知识库校验要点，不合格就重新生成或转人工。

具体案例：某电商平台在客服机器人后端接入自检 Loop：每次回复先做完整性检查（是否回答用户核心问题），再做事实性检查（关键政策编号是否与知识库一致）。某次大模型漏写了“7 天无理由退换货”条款，被检查器拦截并触发重试，最终用户收到了完整回复。

AI 代码生成提交前的自检

阶段：生成后的自动审查与闭环修正

解决的问题：开发者让 AI 生成的代码片段直接合入仓库，往往带着潜在 bug。自检机制让 AI 先审查自己生成的代码——检查是否有未定义变量、资源是否释放、边界条件是否处理，不通过就自动重写。

具体案例：某团队用 AI 生成 Python 数据处理脚本，接入检查链后，检查器发现生成代码中遗漏了空值处理分支，自动触发重试并补上了 dropna() 逻辑，避免了线上数据管道崩溃。

批量营销文案的分级抽检

阶段：批量生成后的分级质量管控

解决的问题：全量检查上千条营销文案成本过高，不检查又怕出现违规表述。通过分级检查和抽样策略，把高风险的金融产品文案全检，普通文案按比例抽检，在成本可控的前提下守住合规底线。

具体案例：某广告平台每天生成数千条商品卖点文案，对涉及“最低价”“疗效”等敏感词的文案触发全量检查，普通文案按 20% 抽检。抽检发现的敏感词问题被自动打回重写，整体合规率从 82% 提升到 97%。

Python 演示

python35 行
import random  def generate_answer(task: str):    """模拟大模型生成，质量在 0.40 到 0.98 之间波动"""    quality = random.uniform(0.40, 0.98)    return "答:" + task, quality  def check_answer(answer: str, quality: float, threshold: float):    """模拟检查器：把质量拆成 3 个维度打分，低于阈值判不合格"""    dims = {        "完整性": min(1.0, quality + random.uniform(-0.10, 0.10)),        "准确性": min(1.0, quality + random.uniform(-0.10, 0.10)),        "可读性": min(1.0, quality + random.uniform(-0.10, 0.10)),    }    score = (dims["完整性"] + dims["准确性"] + dims["可读性"]) / 3    return score >= threshold, round(score, 3), dims  def run_loop(task: str, threshold: float, max_retries: int):    """自检闭环: 生成 -> 检查 -> 不合格重试, 超限转人工"""    for attempt in range(1, max_retries + 1):        ans, quality = generate_answer(task)        ok, score, dims = check_answer(ans, quality, threshold)        print("第%d次 | 总分=%.2f | %s"              % (attempt, score, "通过" if ok else "重试"))        if ok:            return {"答案": ans, "尝试次数": attempt, "结果": "通过"}    return {"答案": ans, "尝试次数": max_retries, "结果": "转人工"}  if __name__ == "__main__":    report = run_loop("如何开通会员?", threshold=0.70, max_retries=3)    print(report)
目的：用一个轻量模拟器演示 AI 输出自检闭环——生成、检查、重试、兜底四个环节一应俱全，你可以直接运行并观察“重试次数”与“通过率”的关系。
  1. quality = random.uniform(0.40, 0.98)模拟大模型输出的质量随机波动，每轮生成都是一次“开盲盒”。
  2. dims = {...}将质量拆成完整、准确、可读三个维度，对应正文中的“标准卡”。
  3. score = (dims["完整性"] + ...) / 3这是加权评分的简化版：先算各维度分，再平均得到总分。
  4. ok, score, dims = check_answer(...)检查器返回通过与否、总分和维度明细，供闭环记录。
  5. if ok:检查器判定通过则交付答案；否则继续 for 循环重试。
  6. for attempt in range(1, max_retries + 1):重试上限的设计：试到第 max_retries 次还没过就结束循环。
  7. return {"答案": ans, "尝试次数": attempt, "结果": "转人工"}超过上限返回“转人工”，这就是失败处理里的兜底方案。
  8. threshold=0.70, max_retries=3对应正文中的阈值 τ 和重试上限 N_max，是调优的两个核心旋钮。

常见误区

误区很多人一听“让 AI 检查 AI”就摇头：“自家大厨尝自家菜，怎么可能尝出问题？这不是左手检查右手吗？肯定是在走形式。”

正解关键不在于“是不是同一个模型”，而在于流程上是否分离。就像阿程的大厨换上试味师的白袍、用另一套话术重新审视菜品，同一个模型只要在独立的上下文、独立的提示词、独立的角色下执行检查任务，就能发现不少生成阶段忽略的问题。再加上“生成器—检查器”双角色隔离、外部知识库交叉验证，自检的效果是真实可用的。

为何常见：人们容易把“同一个模型”等同于“同一个人思考”，忽略了 LLM 的输出高度依赖提示词和上下文，换一个角色设定就会产生不同的判断视角。

误区“既然要保证质量，那把合格阈值设到 0.95 不就好了？标准严一点，输出质量肯定更高。”

正解阈值越高，重试次数越多，成本和延迟都成倍上涨，甚至可能永远达不到合格线——因为模型能力存在上限。阈值应该结合业务风险、重试成本、期望通过率综合设定，而不是一味追求高分。阿程把标准卡定在 70 分，是因为他算过账：80 分以上回炉率翻倍，顾客等待时间反而让满意度下降。

为何常见：直觉上“越严越好”很简单，但忽视了质量与成本、体验之间的权衡关系，这正是成本平衡一节要解决的问题。

误区“反正可以重试，那就多试几次，总会成功的。把重试上限设成 10 次，质量肯定有保障。”

正解如果任务本身超出模型能力，重试 100 次也是同样结果，只会白白消耗算力和用户耐心。重试上限的真正意义是“止损”：超过上限就触发降级或人工接管，避免系统陷入死循环。阿程规定 3 次不过就换菜，不是不努力，而是把资源留给更可能成功的任务。

为何常见：只看到重试的收益，没看到每一次重试的延迟成本和失败概率的指数衰减特性。

误区“检查器给了 92 分，这道菜肯定没问题，直接上桌吧。” 很多人把模型自评的高分当成质量合格的“铁证”。

正解模型自评分是模型对自己输出的估计，不等于客观事实。检查器同样可能产生幻觉或偏见，需要定期用人工标注样本校准——对照“人工分”和“模型分”的偏差，及时调整标准权重。阿程每个月都会请真实顾客盲测，就是为了校准试味师的口味。

为何常见：把“模型说好”误当成“真的好”，忽略了检查器本身也需要被校验、被迭代。

误区“自检系统上线了，标准卡也定好了，以后就能自动保证质量，不用再管了。”

正解业务在变、模型在变、用户需求在变，检查标准和规则必须跟着迭代。今天的检查项可能下个月就不再覆盖主要风险，需要定期从失败样本里沉淀新规则、调整权重、度量效果。阿程每周都翻试味记录，正是这个道理——闭环的水不流动，就会变成死水。

为何常见：把 Loop 工程误解为一次性交付物，忽视了它本质上是一个需要持续运营的反馈系统。

面试题

Q1. Loop Engineering 的核心特征是什么？

单选题 · easy

  • A.单次生成后直接交付
  • B.在环上反复校验修正← 正确答案
  • C.增加模型参数量
  • D.减少请求调用链

答案：B。Loop Engineering 的核心是让输出经过“生成—检查—回炉—再交付”的循环，而不是一次成型。就像阿程的试味师反复把关菜品，而不是大厨做完直接上桌。

Q2. 在自检机制中，生成器与检查器的正确关系是？

单选题 · easy

  • A.必须使用不同模型
  • B.必须使用同一模型
  • C.流程上分离即可← 正确答案
  • D.检查器必须由人担任

答案：C。生成器与检查器可以复用同一个模型，关键在于流程和角色分离——同一大厨换一身白袍当试味师也能发现问题。是否用双模型取决于成本与效果，而不是硬性要求。

Q3. 下列哪项更适合作为 AI 输出的质量标准描述？

单选题 · easy

  • A.覆盖关键信息并符合事实← 正确答案
  • B.回答要生动有感染力一些
  • C.体现出较高的专业感
  • D.返回格式统一并且速度快

答案：A。质量标准必须可量化、可执行。A 给出了“覆盖关键信息”“符合事实”这样可验证的维度；B/C 偏主观，难以打分；D 讲的是性能和格式，属于另一类指标，不是内容质量标准。

Q4. 加权评分公式 \( S = \frac{\sum w_i s_i}{\sum w_i} \) 中，\( w_i \) 的含义是？

单选题 · mid

  • A.第 i 个检测项的得分
  • B.第 i 个检测项的权重← 正确答案
  • C.所有检测项的数量
  • D.最终计算出的总分

答案：B。\( w_i \) 表示第 i 个质量维度的权重，决定该维度在总分中的话语权。比如标准卡上“准确性”权重高，它就会对总分影响更大。\( s_i \) 才是各维度得分。

Q5. 设单次生成通过率 p=0.8，最多重试 3 次，最终仍失败的概率是多少？

单选题 · mid

  • A.三次连续失败，概率约 0.008← 正确答案
  • B.三次生成必有一次成功，概率约 1
  • C.单次失败后再成功，概率约 0.2
  • D.三次中至多失败一次，概率约 0.9

答案：A。只有连续失败 3 次才算最终失败，概率是 (1-p)³ = 0.2³ = 0.008。这说明带重试上限的闭环绝大多数情况下能产出合格结果，剩余 0.8% 则交给降级或人工兜底。

Q6. 检查不通过时，常见的兜底策略包括哪些？

多选题 · mid

  • A.修改提示词重新生成← 正确答案
  • B.降低要求放宽判定阈值
  • C.切换降级简化答案← 正确答案
  • D.转交人工进行复核处理← 正确答案

答案：ACD。重试（换提示词）、降级（简化回答）、人工接管是三类标准兜底。降低阈值属于放宽质量标准，是“降低要求”而不是兜底，可能让不合格内容蒙混过关，因此不该选。

Q7. 下列哪种场景最适合对 AI 输出做“全量检查”？

单选题 · mid

  • A.低风险每日简报自动生成
  • B.面向客户的合同摘要生成← 正确答案
  • C.内部会议纪要的要点整理
  • D.低频边缘场景下的临时试用

答案：B。面向客户的合同摘要是高影响场景，出错会带来真实损失，必须全检。低风险内部内容可以抽样或轻量检查，这是成本平衡原则——大客户的菜全检，员工餐抽检。

Q8. 闭环迭代中，下列哪项最能体现“规则沉淀”？

单选题 · hard

  • A.把失败样本保存进数据库
  • B.将高频缺陷固化为新检查项← 正确答案
  • C.持续提升生成模型参数量
  • D.动态调低质检时的阈值

答案：B。规则沉淀的核心是把失败教训翻译成新的检查规则。保存样本只是第一步，提升参数量不解决质检偏差，调低阈值是降低标准。只有把“酱油类菜品总偏咸”固化成一条新检查项，才算真正的沉淀。

Q9. 关于“伪反思”现象，下列说法正确的有哪些？

多选题 · hard

  • A.模型修改后仍保留原错误← 正确答案
  • B.检查提示词无法解决它
  • C.需要外部信号辅助纠错← 正确答案
  • D.增加重试次数必然根治

答案：AC。伪反思的特征是“自称检查了但没改”，A 描述了这一现象；缓解方式包括优化提示词、引入外部知识库等，C 正确。B 过于绝对——提示词虽无法根治但可以缓解；D 错误，重试不改变模型的错误倾向，只会增加成本。

Q10. 质量自检闭环上线时，正确的工程实践有哪些？

多选题 · extreme

  • A.先小流量灰度再逐步放量← 正确答案
  • B.每次检查结论全程留痕← 正确答案
  • C.检查规则变更支持回滚← 正确答案
  • D.上线后立即删除历史日志

答案：ABC。灰度、留痕、回滚是质量闭环上线的三件套。删日志等于切断反馈数据，闭环将无法迭代。阿程推广试味制度时也是先试点、存记录、留旧版标准卡——工程实践与生活直觉完全一致。