企业官网建设流程全解析

最近接的几个项目，目标都很类似：调用大语言模型产出高质量内容。真正做完一圈，我最强烈的感受是——生成本身已经不是瓶颈，瓶颈在于“生成之后怎么验收”。规则引擎能拦明显格式问题，却拦不住逻辑断裂和事实夹生；人工抽检质量高，但量一大就人力告急。后来我把思路反过来，让模型之间互相当审稿人：生成方先把结果交出来，另一个模型独立找毛病、打分、写修改意见，生成方再根据这些评语做自我批评和修订。这一套“大语言模型对大语言模型进行的批评和自我批评”机制，解决的就是内容生产链路里最痛苦的最后一公里质量问题。

这套办法不是凭空想出来的，它的底层逻辑近似于人类评审：写作者自己看不出自己的盲区，换一个阅读者往往一眼就能找到破绽。文章会围绕这套机制展开，从为什么有效、怎么搭建，到提示词模板、参数配置、回归测试，再到踩坑排障，尽量把能直接复用的细节都写出来。

1. 为什么需要让大语言模型去批评大语言模型

1.1 单个模型既当选手又当裁判的困境

我以前也试过最简单的方式：让生成模型自己检查自己的输出。做法是在提示词末尾加一句“请检查上面内容的准确性”，结果发现效果十分有限。原因不复杂，模型在同一个会话里带着上下文惯性，生成和自检用的是同一套注意力分布，很容易沿着自己刚写出来的逻辑路径滑下去。就像刚写完一段论述的人往往觉得字字有理，等过几天再回头读才发现哪里跳跃了、哪里压根站不住脚。

更深的隐患在于，同一个模型的系统偏差是稳定的。它擅长编造的地方，自检时大概率也会放过；它语料里缺失的知识点，自我复读时照样补不回来。让同一个模型既产粮又验收，本质上等同于让考生自己给自己判卷，判卷标准还和答题标准高度重合，这种复检更像是一场走形式的自我确认。

还有一层现实问题，单模型对话式自检会消耗大量上下文窗口。长文生成过程中，反复要求模型“重读一遍并指出错误”，模型会越来越倾向于回头复述已有的内容，而不是跳出框架做全局审视。这种时候，换一个完全独立的模型视角，效果要明显得多。

1.2 批评与自我批评的分层结构

标题里的“批评和自我批评”不是一个修辞，工程上可以拆成至少三个层次。

第一层是“自我批评”，生成模型在提交正式结果之前，先对自己做一轮反向审问：这段回答里的数据能不能溯源？论证链条有没有明显缺口？有没有偏离用户指令的地方？这一层做的是一种低成本预筛，把一堆低级错误挡在提交之前。

第二层是“批评”，由一个独立的大语言模型担任评审者，针对生成文本逐项打分并给出批判性意见。这层的关键在于视角隔离，评审模型不应该知道自己是由哪个模型生成的结果，也不应该看到生成模型的自检日志，这样它才能像真正的审稿人一样，只盯着文本本身说话。

第三层是“仲裁”，当评审模型给出的评分与修改意见被生成模型认为不合理，或者两个评审模型给出冲突结论时，需要另一个模型独立裁决。这个模型通常选能力更强、偏好更保守的版本，只看争议片段和双方论据，不受任何一方之前结论的干扰。

三层都串起来，批评才不是一句口头反馈，而是能驱动修订的行为闭环。

1.3 适用场景与不适合的场景

不是所有任务都需要上这套机制。从成本角度算一笔账，引入批评和自我批评意味着生成成本至少翻倍，评审模型还要占用额外的token和延迟。只有当下面的条件成立时才值得做：

• 内容质量要求高，一次性错漏代价大，比如官方公告、产品手册、行业报告；
• 生成链路允许延迟，适合离线批量处理；
• 用户愿意为质量提升付费，或者内部流程愿意为质量投入算力；
• 质量维度不只依赖格式正确，还需要事实一致性、逻辑严密性和合规性。

反过来，实时聊天、低风险客服回复、简单改写这类需求，这套机制就属于杀鸡用牛刀。低延迟场景里用户等不起两轮调用，直接一个模型生成完就返回反而体验更好。判断标准其实很简单：如果一个问题答错了用户也不会有什么损失，那就别费这个劲，如果答错一次可能导致信任受损或返工成本飙升，那批评机制就物有所值。

2. 搭建一套评审体系：角色分工与评价维度

2.1 三类角色怎么分：被评者、评审者、仲裁者

我搭过的方案里，最常用的角色结构有三个。第一个是被评者，也就是负责实际内容产出的生成模型；第二个是评审者，负责挑毛病、打分、出建议；第三是仲裁者，负责处理评审结果的分歧。

被评者的选择逻辑和日常生成一致，重点看业务场景的术语能力、指令遵循度和输出格式稳定性。评审者则要看三个能力：长上下文理解力、指令遵循度、批判性分析能力。很多人有一种误解，以为评审模型必须比生成模型强一大截，实际操作中我发现，只要评审模型具备清晰的规则理解力和稳定的输出格式，即使复杂度和生成模型持平，效果也不错。真正拉开体验差距的反而在系统设计，也就是评审指令是否清楚、评价维度是否可量化、分歧处理机制是否靠谱。

仲裁者一般只在两类情况出现：一类是评审给出的修改意见一针见血，但生成模型死活不认，坚持按自己的方式解释；另一类是多个评审模型之间的评分差异跨过了阈值，比如同一个维度一个打5分一个打1分，这时候需要仲裁模型出场。

2.2 评审清单：十个可执行的评价维度

给评审模型下指令时，最忌讳只让它“检查一下质量”。这听起来像是把定义权交给了模型，实际上每个模型心里对“质量”的看法都不一样，这也正是很多人觉得批评机制忽好忽坏的原因。我的做法是给一份可量化的维度清单，让模型逐项判定。

我给一个完整度比较高的评审清单模板：

1. 事实准确性：文本中的数字、时间、专有名词、信源是否可信，是否存在无法验证的断言；
2. 逻辑一致性：前后文有无矛盾，论证链是否完整，结论是否被论据支撑；
3. 指令遵从度：是否完整响应用户诉求，是否遗漏了关键限制条件；
4. 内容相关性：是否围绕主题展开，有没有冗余段落或跑题内容；
5. 结构完整度：是否有明确的开头、中部、结尾，段落过渡是否自然；
6. 语言规范性：错别字、标点误用、语病、术语是否统一；
7. 信息密度：是否存在大段空话、套话，有效信息是否被稀释；
8. 可执行性：如果文本涉及步骤或方案，用户能不能照着落地；
9. 适度创新：是真正提供了新角度，还是在拙劣地拼凑已有内容；
10. 安全合规：是否包含隐私泄露、偏激观点、高危误导等信息。

每一项用1到5分，强制要求评审模型给出证据文本。只有“3分”没有摘录原文，只有“逻辑有问题”没有指出具体在哪一句，这种评审结果在后续使用中毫无价值。

2.3 防止随声附和与盲目互相吹捧

这套机制最怕的一件事，是评审变成互夸大会。两个模型明明能力不相上下，却在提示词里被设计成“客观评价对方”，结果经常是彼此客套，评分一路飙升。这种现象的成因主要有两个：模型对正面语言的偏好，以及评审与被评双方在上下文里存在容易被感知的关联设定。

我踩过几次坑之后，总结出三条比较管用的对策。

第一条是盲评。评审模型只拿到被评文本，以及一个简短的背景说明，不被告知这个文本是谁生成的，不提供生成模型的自我介绍、角色设定或历史对话。模型没法对“人”留情面，就只能对“文本”说事。

第二条是强制证据链。在提示词里写明“必须引述原文片段作为支撑”，同时禁止使用“总体不错、不过……”这类句式。我会直接要求：如果所有维度都给了4分以上，就必须说明这一条输出与样例标准之间为什么完全匹配。这个约束一开始听起来有点苛刻，但确实能把很多“假好评”逼成真理由。

第三条是独立调用。评审和被评不能放在同一个会话里，要么通过API并行调用两个独立上下文，要么至少在提示中隔离。如果评审模型的对话上下文里带着被评模型的历史，它会不自觉地把“维护一致性”当成目标，就容易顺着对方的思路走。

2.4 分歧仲裁与分数归一化

无论指令设计得多好，模型天然都有评分差异。不同模型对同一段文本的判断本来就有偏好，有的更在意逻辑完整，有的更在意文风流畅，所以多模型评审更适合输出对同一张清单的评分，再做归纳。

最简单的融合办法是取均值，但均值容易掩盖极端分歧。比如一个评审给出逻辑一致性5分，另一个给出1分，平均下来是3分，看似平庸，实则反映的是判断基准直接冲突。我的经验是引入一个更合理的规则：先看分差，若同一维度分差超过2分，直接标记为争议项，进入仲裁步骤；只有分差在可接受范围内的维度才参与平均或加权计算。

仲裁环节也不是让仲裁模型全盘重新打分，而是只对争议项进行审查。给仲裁者的输入包括该项评价标准、两个评审模型的判断与依据、被评文本的对应片段，以及一句清晰指令：“你不是在做全面评估，你只需要判断双方谁更拿得出证据，或者是否存在双方都没看到的新问题。”这种轻量仲裁速度更快，分歧解决也更准。

另外还有一个细节：给不同评审模型的分数做归一化。有些模型天生趋于保守，打1分2分很常见；有些模型受训练偏好影响，整体打在4分以上。如果不做映射，直接比较没有意义。比如以某次测试的前100条结果为基准，给每个评审模型算分布，再做百分位映射，所有分数落在统一尺度上，后续统计才靠谱。

3. 从提示词到闭环：工程化落地要点

3.1 一份能直接改用的评审提示词

下面是一个我实际项目中比较常用的评审提示词模板，考虑到通用性，把业务相关的细节做了简化。可直接整段复制，替换成自己的业务上下文。

你是一名严格的中立评审员。你需要对下面的“被评输出”逐项打分，并给出可执行修改建议。 评分维度： 1. 事实准确性：包括数据、时间、专有名词、信源可验证性。 2. 逻辑一致性：前后矛盾、论证链断裂、结论与论据不匹配。 3. 指令遵从度：是否完成用户提出的所有要求，有无忽略限制。 4. 内容相关性：是否围绕着核心主题，有无偏离或冗余。 5. 结构完整度：开头、中间、结尾是否完整，过渡是否自然。 6. 语言规范性：错别字、语病、标点误用、术语统一性。 7. 信息密度：有效信息比例，是否用套话填充篇幅。 8. 可执行性：步骤类或方案类内容能否直接落地。 9. 适度创新：有没有新的角度，是否为无意义拼凑。 10. 安全合规：是否存在隐私泄露、偏激观点、误导风险。 打分为1-5分。 打分规则： - 每项分数都必须有文本片段作为证据； - 总分为十项分数简单平均，但你需要明确指出最严重的短板项； - 禁止客套用语，禁止使用“总体不错”“整体良好”等空泛表述。 输出格式： 总分：xx 分项得分：1-10逐项列出 最严重问题：严重级别1-3，列出对应原文片段并说明原因 修改建议：3条以内，按优先级排序 被评输出： {这里粘贴文本}

需要提醒的是，如果你的项目还要做多轮修改，可以在每个问题前加上编号，生成模型回复时直接引用编号“修改第3个问题”，比让它重新复述整个评语要省很多token。

3.2 关键参数配置：温度、Top-p与输出长度

很多人把精力都放在提示词上，却忽略了参数配置对评审结果的干扰。评审模型一旦温度太高，打分就会跳动，同一份文本跑两次能差出1分以上。温度太低又容易让模型陷入重复性表述，评语不够具体。

我给评审模型推荐的是低温方案：temperature取0.2以下，Top-p取0.8到0.9之间。这样模型输出结果相对稳定，同时又保留了一定的多样性，不至于每次都重复同一套模板。被评模型的温度需要根据业务情况来定，如果做创意类生成，可以维持0.7到1.0；如果做事实密集型内容，则建议降到0.3以下。

输出长度也要单独控制。很多API默认的最大token数对于长文生成是够用的，但对评审结果可能不够，因为一份9分的评审意见可能会包含总分、十个分项、若干条证据摘录和修改建议。建议把评审模型的max_tokens设成不低于生成模型输出的四分之一，至少确保留出相当于被评文本三分之一的输出空间，否则评语写到一半就被截断，后半部分维度全为空值。

还有个小技巧，如果API支持seed参数，可以固定一个seed。它不能保证结果百分百可复现，但能显著降低跨请求的随机波动，排查问题时方便不少。

3.3 并行评审与回归测试

上线批评机制前，强烈建议先做小范围样本验证。我通常的做法是准备一份100到200条问题的测试集，问题覆盖典型业务场景，比如既包含事实问答，也包含开放式写作，再让生成模型产出结果，接着并行调用两个评审模型各自打分，最后人工抽检对比。

并行评审在工程上没什么门槛，流程大概长这样：

准备生成样本集 → 批量生成初稿 → 把初稿按固定帧切块，分发到多个评审任务 → 汇总每个维度的得分和建议 → 统计分差与争议项 → 进入仲裁或人工复核。

真正要注意的是回归测试。一次改动可能只动了提示词里的一个词，但在几十条样本里体现出的平均分波动可能微乎其微，只有追踪过一段时间才看得出好坏。我每改一版提示词，都会在同一批测试集上重新跑一次评分，比较平均分、争议项数量、评审置信度三个指标。经过一段时间迭代，你会发现系统级方针：评审口径一旦稳定，较长时间内都不需要再动。

回归测试还有一个容易被忽略的作用，它能捕捉模型版本模型的问题。某个模型供应商升级了一阵之后，评分偏好可能会悄悄变化，评审得出的平均分就比上周高了0.3分。这种漂移靠肉眼很难发现，但每周跑一次固定样本，变化一目了然。

3.4 批评结果回流：让质量越评越稳

批评与自我批评机制最珍贵的地方，在于它能持续积累质量数据。修改完的文本、评审者的意见、仲裁者的判断，这些不应该只是运行日志，而是可以沉淀为资产。

我目前用得比较顺的沉淀路径有三条。

路径一：常见问题库。每轮评审结束后，把出现频率最高的五类问题写入一个文本文件，定期补充成生成模型的Few-shot示范。例如“最近总犯知识点堆砌、逻辑跳跃这两个毛病”，在生成提示词里轻描淡写约束一条，就能明显减少同类问题复现。

路径二：少数区域对齐调整。如果某个业务场景的评审意见非常规律，比如总是缺行业术语、总是写不出数据后标注，可以考虑拿生成模型做一次轻量微调。训练数据不用多，把“原始指令+之前被批评的输出+评审意见+修改后输出”组成四元组，数据量几百条都能带来稳定提升。这种方法兼备参考性和成本可控性，但要注意别让模型在一个语料库上反复循环，否则会逐渐丢掉泛化能力。

路径三：质量标准文档沉淀。把评审清单和优秀样例结合成一份文档，后续新团队接手时就不用从头摸索。这听着不算是技术，但对项目长期维护来说，价值比任何代码都大。

4. 踩坑实录与排障速查

4.1 评审模型自己也会幻觉

这是我们项目早期最头痛的问题。评审模型一本正经地指出“这段内容出现了事实矛盾”，然而我回去对照原文，发现它引用的片段根本不存在。原因是评审模型在打分时为了满足“必须引述原文”的指令，自己拼凑了看起来风格相近的内容。

解决起来有两条约束要同时加：一是要求“引述必须逐字一致，不允许概括和改写”，二是把检查范围限定在原始文本内，明确说“如果原文没有出现某项，不得自行补充”。后来我甚至会在评审后加一道小校验程序，用字符串匹配判断引述片段是否有原文支撑，匹配不上直接标记该条评审为低置信。这套组合拳基本清掉了九成以上的幻觉引述。

4.2 分数漂移与批间不稳定

有段时间我发现同一份文本，上午跑评审输出平均分4.2，下午平均分变成了3.6。查了各项配置，温度没变，提示词没动，最后把问题定位到两点：一是模型服务端悄悄换了版本，行为分布发生了变化；二是上下文里样本顺序不同，模型受到前几条样本的暗示。

预防措施并不复杂：锁prompt、锁温度、锁seed、锁模型版本号，每次变更都及时记录。再加上基础的回归测试，即每个工作日跑20条基准样本，观察平均分是否漂移。只要漂移幅度超过阈值，就立刻回滚或调整评审端配置，别让线上评分变成“随机数生成器”。

4.3 隐私安全与责任边界

评审过程需要把文本内容喂给大语言模型，这在很多场景下就涉及隐私风险。尤其当被评文本包含用户个人信息、内部业务数据、未公开商业信息时，必须提前做脱敏处理。比如把客户姓名替换成代号，把内部项目代号转成映射字段，再把脱敏后的段落送入评审流程。

另外必须给评审机制设定清晰的责任边界。大语言模型给出的批评意见只是辅助决策，不能直接当成最终审核结论。尤其是涉及人身安全、财产交易、法律风险的场景，必须保留人工终审环节。我团队的内部原则是：机器做“初筛”，人做“终判”，机器筛出的问题率越低，人为终审的负担才越少。

4.4 问题速查表

下面这张表是我在项目维护过程中整理的高频问题与处理对策，直接把踩过的坑简化成可用于快速排查的形式：

这套问题速查表可以挂在项目文档里，凡是新加入的人遇到类似现象，先查表再动手，能省下不少排查时间。

我最近实际跑过一次比较有代表性的场景：一份两百篇内容的质量清点工作，按原来人工逐篇复核的节奏，预估要一整天。用这套批评机制先批量初筛，再人工只挑争议排名靠前的20篇细看，整体耗时压到了两小时以内，查出的问题类型也比原来纯人工抽检更全面。当然过程中也遇到过评审模型对某些幽默类文本过于严苛的尴尬事，这算是提示词口径过硬的副作用。

最后聊一句个人体会。这套机制的真正价值不只在自动化省钱，而是把“质量”从抽象感觉变成了可以被质疑、被修订、被度量的标准。你不需要把评审模型想象成无所不知的评论家，把它当成一面认真找茬的镜子就够用了。只要你愿意根据镜子里的反馈持续调整，生成质量就会一点点逼近团队真正想要的样子。