标签 思维链 下的文章

在大模型算法快速迭代演进的背景下，业务研发人员负责工程、算法研究人员负责模型优化的协作模式，已经无法满足大模型产品快速创新、模型效果快速迭代的业务需求，业务团队需要建设自有的大模型优化能力。如何建设一个人人都能训大模型的技术氛围，已成为加速大模型业务落地、推动组织创新与发展的关键。

2025 年 4 月，在 InfoQ 举办的 QCon 全球软件开发大会（北京站） 上，科大讯飞消费者 BG 大数据研发部总监吕昕分享了“如何建设人人都能训的大模型技术氛围”，他从平台基础设施、大模型思维、协作文化 3 个角度，阐述如何建设“人人能用、人人会训”的大模型文化，有效提升组织效能，进而推动业务的持续成长。

预告：2026 年 QCon 全球软件开发大会（北京站）策划了「AI 时代的“超级团队”」专题，将探讨如何弥补人与 AI 的能力鸿沟，重构产品与技术的协作关系，并建立一套适应 AI 时代的全新管理与度量体系，打造高适应性、高产出的“超级团队”。如果你也有相关方向案例想要分享，欢迎提交。

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。

大模型时代组织创新的必要性

大模型时代创新的必要性在于，无论是 C 端还是 B 端业务，直接使用大模型完成工作都存在困难，需要进行优化。每个业务线或单元都有必要自己训练大模型，我的分享一方面可以帮助小团队或业务线从 0 到 1 建设大模型训练能力，另一方面能让想转大模型的工程人员了解如何转型。

大模型算法优化的几种模式

从业务优化需求来看，C 端业务场景零散但可划分到特定场景优化，业务线要求高且效果优化永无止境，核心是围绕用户场景建立数据和快速优化能力。B 端业务以解决方案为主，对效果要求相对有限，主要是满足国产化和安全要求，达到可用即可。

大模型优化模式与传统机器学习有所不同。传统机器学习中，算法需求由算法研究人员或团队主导，业务线研发主要负责部署上线和维护。而在大模型时代，特征工程基本不存在，但出现了两种新的合作模式：一种是以算法研究人员为主，业务线辅助定义需求、标数据等；另一种是以业务线为主导，算法人员辅助问题定义与选型、模型训练。DeepSeek 等技术的出现，使得业务线或产品线有可能自己优化大模型训练效果，不再依赖算法辅助。

大模型吋代的 BLM 模型

从组织架构角度，各个业务线更希望业务线自己训练大模型。因为大模型技术发展迅速，战略需灵活调整，组织活力需进一步激活，以实现敏捷创新和更好的信息拉齐与穿透。传统的算法团队与工程团队分开的模式已不能满足业务发展需要，每个业务线或团队都需要具备从 0 到 1、端到端优化大模型的能力。

在大模型时代，DeepSeek 的出现既带来了危机也带来了机遇。它在基础模型方面表现出色，一些场景直接使用深度探索就能取得不错的效果。同时，开源生态的成熟，包括训练框架、推理框架和智能代理框架，降低了训练基础设施的建设成本。通过蒸馏深度探索，可以快速构建高质量数据，如思维链数据，节省了大量人工标注成本。此外，模型优化范式也在变革，从之前的底座模型训练和监督微调（SFT），转变为现在的知识蒸馏，并且广泛采用 GRPO 来优化效果。

从 0 到 1 自建大模型优化能力面临的问题

业务线如果想自己从 0 到 1 建设大模型的优化能力，会面临诸多挑战。首先是基础设施的缺失，包括算法、算力、平台、数据，以及训练框架和推理框架。其次是缺乏算法优化经验，不清楚如何选择模型、技术方案，如何评估和优化效果。最后是人才短缺，不清楚需要什么样的人才、到哪里找以及需要掌握哪些技术栈。

大模型效果优化团队的协作与流程

在大模型时代，对研发岗位的要求也发生了变化。核心岗位包括大模型算法工程师和大模型测试工程师。大模型算法工程师相比传统搜索、广告、推荐算法工程师，门槛降低，需要调的参数少，但需要更好的业务感知能力，将业务需求转化为大模型优化场景，并具备创新思维和前沿跟进能力。大模型测试工程师相比传统测试工程师，需要更高的自动化测试要求，能够基于业务感知能力自动化构建大模型测试样本和制定测试标准。除了这两个核心岗位，还有其他岗位，如提示词工程师因天花板低和深度探索出现后需求减少而不再热门；大模型平台架构师、大模型平台开发工程师和大模型应用开发工程师这些岗位和传统软件开发岗位基本没有太大区别。

在研发和测试的协作方面，之前让团队野蛮发展，未重视项目管理，导致模型训练完成、上线前测试环节出现问题，训练样本与业务未对齐，浪费了大量时间。因此，我增加了样本评估环节，要求在训练前与业务线对齐样本，确保样本能满足业务需求。同时要求每次算法上线时提供详尽的自测报告和提示词文档，明确参数设置等细节，以避免因参数错误导致的测试问题，因为大模型训练结果是黑盒，测试时不易发现问题。

建设人人能训大模型的基础设施

大模型优化平台的建设

基于我对整个平台架构设计的理解，基本分为三层。最底层是基础设施，公有云可以解决 90%，甚至 100% 的问题。因为业务线的训练样本数和情况一般不支持训练 32B 以上的模型，32B 的全参训练是上限。此时租用几十张显卡基本能解决大部分训练问题，大部分业务场景 7B 模型也能搞定。所以公有云租卡基本能解决 90% 的训练和部署问题。在训练的第二层是训练工具。这里使用了公司内部已有的星火训练平台，同时也基于开源搭建了相关工具，开源生态的成熟对此帮助很大。再往上是大模型应用开发的三个工程：数据工程、模型工程和 Agent 工程，也可称为大模型的应用开发。核心需要自己扩建设的资源主要是数据资源和应用开发资源。数据资源方面，要掌握如何通过调用 API 构建样本，如何蒸馏 Deepseek，公有云的 API 基本能满足需求。应用开发方面，主要涉及 Agent 和 RAG。Agent 的开源项目众多，star 超过 1000 的都有 50 个左右，可以基于开源搭建自己的 Agent 和 RAG 平台。如果想低成本建设从 0 到 1 的基础设施，利用公司内部资源复用和拥抱开源，基本能解决所有问题。

开源模型的技术选型

有了基础设施后，简单介绍一下开源技术栈。之前没显卡时还考虑过 Qlora，但后来发现 32B 模型的 Lora 训练，16 张显卡基本都能搞定，没必要再用 Qlora。在模型选型上，简单模型用 7B、14B、32B 基本都能满足，复杂一点的长文本和复杂任务，32B 模型也能差不多应对。使用开源模型进行部署和训练基本没什么太大问题。

数据管理平台

在数据管理平台方面，我看了所有开源项目并梳理了公司内部所有数据相关平台后，得出结论是必须由业务线自建，因为没有任何两个业务的数据管理需求是一样的。其核心有两点：一是 Badcase 驱动，Badcase 管理非常重要，我每次训练时核心任务是修复 Badcase；二是要进行模型样本管理，避免引入脏数据，出问题时能追溯模型来源，所以要建设模型溯源能力，而不仅仅是数据管理能力。

培养全员大模型思维与能力

如何培养全员训练大模型的思维和能力，重点在于提升能力，尤其是让普通研发人员快速掌握大模型训练，建设他们的算法能力。大模型训练流程包括问题定义、提示词设计、样本构建、微调（蒸馏、强化学习）、评估和上线。模型优化能力由四个能力叠加而成：模型问题定义能力、样本构建能力、训练能力和评测能力。最初认为模型训练能力最难，但实际上最容易，一周内所有人都能学会调参，且调参不超过 3 个。研发团队最需要提升的是问题定义和评测能力。

大模型的应用场景和优化方式

我将自己最近半年工作中的教训和经验总结，把所有训练过的大模型场景做了拆分，发现大部分大模型场景都能映射到下表几个类别中。每次模型训练时，思考一下可以放到哪个类别，然后按照相应的优化方式去做，基本都能取得不错的效果。以写作类为例，这是最常用的大模型优化场景，现在 DeepSeek 效果较好，大家开始广泛使用。以前不敢碰写作类，因为需要构建样本，难度较大。但现在通过 DeepSeek 蒸馏和强化学习（GRPO），基本能取得较好的效果。要素抽取类场景中，公有云模型准确率能达到 90%，自身优化空间不大。问答类场景中，大模型能力很少单独训练，大家主要做 RAG 和搜索插件，因为底层工程化可以提升更多效果。还有 API 调用类场景，训练大模型时将其抽象到某个场景，再看每个场景的优化方式。无论是写作还是交互，最核心的是要有一套快速构建样本训练的链路能力，从业务驱动出发，快速构建样本训练，再快速进行评测和 Badcase 修复，以及与之相配合的平台能力。

大模型测试

大模型测试曾是我最不关心的环节，但后来发现它对模型优化迭代效率影响最大。首先，数据来源很重要。如果线上有 Badcase，建议直接使用 Badcase 作为优化数据。性能测试方面，大模型性能测试与普通性能测试存在差距，可能会考虑 GPU 并发等因素。但我认为，同样 Token 长度和 Size 模型性能差异不大，不要投入过多精力。最核心的是找一个测过的开源的数据源，拿来即用。效果测试很关键，就是理解模型效果并进行测试。我的感受是，合作的业务线中，是否有优秀的测试人员对最终模型效果影响很大。优秀的测试人员可以从业务需求出发，将业务标准和测试标准转化为测试用例，自动化生成样例，并用大模型自动评测。一个这样的测试人员对于团队能力的提升，相当于三个以上的大模型算法人员，而那些配合较差、反复优化效果不好的业务线，往往缺少这样的人。因此，我在公司内进行大模型测试能力评估，尽管自己做算法工作，但感觉没有优秀的测试人员，工作开展会很困难。

大模型优化案例 1 一多轮改写

我最早做搜索时，用户输入多轮搜索结果，需要多轮改写来理解用户意图。之前使用传统方法和一些大模型，都无法很好地理解几轮对话之间的关系，上下文无关和上下文有关的内容都识别不出来。DeepSeek 出现后，发现其 R1 效果非常好，因为它有思维链，能思考上下文关系。于是尝试用 R1 做蒸馏，结果效果也很好。这个实验有几点结论：一是使用 DeepSeek 后，提示词简化了很多，这也是提示词工程师现在市场不大的原因；二是蒸馏时仍需要底座模型，像 1.5B 的底座模型较弱，学不到东西；三是思维链加入后，可以做一些以前做不到的事情。举个例子，用户在搜索中要求生成双色球下期中奖号码，以前在 Query 理解上做了很多尝试，但都无法解决。DeepSeek 给出的回复是“双色球号码不靠谱，远离赌博，珍爱生命”，这让我觉得自己之前的尝试很愚蠢。这个案例说明，当新技术如 DeepSeek 出现后，要勇于探索和尝试，会得到超出预期的惊喜，也能让团队成员感到开心。

大模型优化案例 2 一公文写作

写作场景以前是我不敢碰的，因为构建样本难度大。DeepSeek 出现后，针对政府公文写作场景，直接使用 DeepSeek，通过公文反推生成大纲，再基于大纲生成要素，然后进行写作。这个过程中有几点分享：一是 DeepSeek 可以帮助做样本构建，节省大量工作量，甚至可以做样本评测；二是用多轮改写的成功经验来训练和蒸馏 COT，发现写作类加 COT 后效果更差，说明之前的经验证到新技术面前可能需要更多实验来验证；三是写作类模型优化并非一次生成文章即可，大部分写作类模型优化是先生成大纲，再基于大纲写作，这样才能取得较好效果，即使使用 DeepSeek，直接一步生成的效果也不如两步走（先生成大纲再生成文章）的效果好；四是通过尝试新技术，即使之前在该领域没有积累，基于 DeepSeek 等最新开源成果，也能实现技术跨越，从原来 30 分的能力提升到 75 分。

构建开放共享的协作文化

在推动工程人员转向大模型工作时，会遇到一些疑虑。例如，一位有五六年的软件开发经验的同学对转向大模型工作非常抵触，他提出了两个疑虑：一是自己不会深度学习理论技术怎么办，我对此解释是大模型工作不需要这些，只要会搞样本、调参数、写 Python 代码就行；二是大模型优化与写代码差距太大，我展示了一个在 QCon 学到的关于工程师文化的图，就是李云老师在 2024 年 QCon 上海演讲分享的 《AI 时代团队管理的不变与变》 中的一张图，该图将工程师文化的关键项总结得很好，指出工程师的工程能力包括设计能力和工程能力两块，之前做工程开发可能是 30% 时间设计、70% 时间工程，而大模型优化可能是 80% 时间设计、20% 时间写代码，本质上仍是工程师工作，只是比例变化，底层活动也一样，都是设计、文档化、写代码以及敏捷开发等。

如果有人担心自己的效果比不上专业的研究团队，那是因为缺乏经验，存在知识壁垒和技术孤岛。解决方法是打破壁垒，通过开源和分享打破技术孤岛，大家团结起来共同成长。遇到问题时，可以找人问、开分享会、开会研讨。

一些解决遇到的大模型优化问题的经验

我在做多轮搜索时，面临模型合并、样本合并问题，如果每个模型都单独训练，最后需要维护几百个模型，这是无法维护的，所以把相似数据放在一起同时训练，但这样导致准确率下降很多，当时不知所措，于是向研究院同学请教，对方建议把多轮与单轮的 promot 差异加大，尝试后发现有效；又向工程同学请教，对方说 VLLM 支持动态的 Lora 加载，每个模型训练一个 Lora，然后动态加载即可，这两种方式都能解决问题。

在写作场景中，出现前面写得正常，后面突然出不来标点符号的问题，当时甚至想用强化学习设置 Reward 来解决，但训练底座大模型写作的人说把 decay 的惩罚从 0.6 设到 0.1，尝试后发现可以解决。现在回看去年做的事，觉得当时犯了低级错误，但认为这不是黑历史，而是成长之路，想跟大家分享的是遇到问题找别人会得到帮助，能力是逐渐积累的。

工程师文化建设

我在公司负责一些工程师文化建设工作，梳理出工程师文化最核心的几点是技术过硬、专业靠谱和开放共享。在大模型时代，我个人最认同的是开放和乐于分享，整个团队、公司或组织需要有更开放共享的文化心态。

总结与展望

从组织氛围或组织变革角度看，训练大模型很简单，只要有平台、有业务 Sense 就能做起来。大模型基础平台可以低成本建设，有众多开源资源可复用。大模型场景就那几类，按流程优化就行。要拥抱开源，避免闭门造车。

最后是致敬：一是 QCon 上一位老师的分享，他讲的“优化算法最好的办法就是找 bug”这句话对我后续工作影响很大，认为在大模型时代，找 bug 和 review 数据比调参更有用；二是 Hugging Face，感谢它提供很多优秀的开源模型和数据，每个公司都需要有自己的类似 Hugging Face 的共享平台，用于模型数据、训练方法论和经验的共享，打造开放共享的团队氛围。

嘉宾介绍

吕昕，负责科大讯飞消费者 BG 大数据和大模型技术平台相关工作，先后负责建设了讯飞 C 端用户数据中台、大数据分析平台和大模型应用开发平台等，目前负责多个 C 端产品的大模型效果优化工作。 在大数据平台、个性化推荐、广告算法、商业分析、大模型算法领域有多年经验。

会议推荐

从基础设施、推理与知识体系，到研发与交付流程，再到前端、客户端与应用体验——AI 正在以更工程化的方式进入软件生产。2026 年 QCon 全球软件开发大会（北京站）将以 「Agentic AI 时代的软件工程重塑」 作为大会核心主线，把讨论从 「AI For What」，走向真正可持续的 「Value From AI」。

LLM幻觉问题至今没有根治方案。RAG能缓解一部分，但成本高、架构复杂，而且只适用于有外部知识源的场景。而对于模型"应该知道但经常搞错"的那类问题，比如历史事件的时间线、人物履历的细节，RAG帮不上什么忙。

Chain-of-Verification（CoVe）的思路是既然模型会在生成时犯错，那就让它生成完之后再检查一遍自己的输出，把能发现的错误纠正掉，然后再给用户看。

听起来像是废话？关键在于"怎么检查"。

直接让模型审视自己刚写的东西，它大概率会坚持原有立场，这是确认偏差在作祟。CoVe的核心贡献是发现了一个绕过这个陷阱的方法：验证时必须把原始输出藏起来，让模型在"失忆"状态下重新回答事实性问题，然后用这些独立验证的答案去校对初稿。

某种意义上，这是给LLM装上了"系统2"思维：快思考先出初稿，慢思考再做验证。

工作流程：起草、规划、验证、修复

CoVe不是什么新的模型架构，它是一种提示编排模式，它把生成过程拆成四步：先让模型写初稿（这时候幻觉随便来），然后让它针对自己的初稿生成一组事实核查问题，接着独立回答这些问题，最后用验证过的事实重写原文。

Factored：真正的关键

前面说的四步里，第一、二、四步都是常规提示工程，用思维链就能搞定，而第三步才是核心。

让LLM一边看着自己写的东西一边验证，会有一个问题，这个在学术上管这叫"sycophancy"，也就是说模型会顺着自己的话往下说。草稿就在上下文窗口里摆着，概率分布会被带偏，模型倾向于认同自己刚编出来的东西。

所以最简单的解决办法是把上下文剥掉。

CoVe论文里发现，回答验证问题时必须把原始草稿藏起来。举个例子：如果你问"根据这个草稿，X是不是在1998年发生的？"模型八成会点头同意自己。但如果你只问"X是什么时候发生的？"它就得老老实实从训练权重里检索答案，没有偏差可言。

隔离验证问题就是逼模型去查自己的知识库，而不是复读自己刚说过的话。

代码实现

下面是CoVe流程的Python实现，封装成一个类。注意第三步里的CRITICAL注释，那就是Factored验证的精髓。

 classChainOfVerification:  
    def__init__(self, llm):  
        self.llm=llm  

    defrun(self, query):  
        # Step 1: Baseline Generation
        # Let the model hallucinate freely here.
        draft_prompt=f"Question: {query}\nAnswer:"  
        draft=self.llm.generate(draft_prompt)  
        print(f"--- DRAFT ---\n{draft}\n")  

        # Step 2: Plan Verifications
        # Ask the model to identify what needs checking.
        plan_prompt=f"""  
        Context: {query}  
        Draft: {draft}  
        Task: Create a list of 3-5 verification questions to check the facts   
        in the draft. Output ONLY the questions.  
        """  
        plan_text=self.llm.generate(plan_prompt)  
        questions=self.parse_questions(plan_text)
        print(f"--- QUESTIONS ---\n{questions}\n")  

        # Step 3: Factored Verification (The Key Step)
        verification_results= []  
        forqinquestions:  
            # CRITICAL: Do NOT include 'draft' in this prompt context.
            # We want the raw model weights to answer this, uninfluenced by the previous lie.
            verify_prompt=f"Question: {q}\nAnswer:"  
              
            # Low temperature is crucial here for factual retrieval
            answer=self.llm.generate(verify_prompt, temperature=0)  
            verification_results.append((q, answer))  

        # Step 4: Final Synthesis
        # Now we bring it all together.
        verification_context=self.format_pairs(verification_results)  
        synthesis_prompt=f"""  
        Original Query: {query}  
        Draft Response: {draft}  
          
        Verification Data:  
        {verification_context}  
          
        Task: Rewrite the Draft Response to be fully accurate.   
        Remove any details contradicted by the Verification Data.  
        """  
        final_response=self.llm.generate(synthesis_prompt)  
          
        returnfinal_response  

    defparse_questions(self, text):  
        return [line.strip() forlineintext.split('\n') if'?'inline]  

    defformat_pairs(self, pairs):  
         return"\n".join([f"Q: {q}\nA: {a}"forq, ainpairs])

CoVe和RAG该怎么选？

每次聊到CoVe，总有人问：为什么不直接用RAG？

两者解决的是不同问题。

RAG适用于模型根本不可能知道答案的场景，比如你公司Q3的销售数据。CoVe适用于模型理论上应该知道、但可能搞混或偷懒的场景，比如按时间顺序列出纽约市历任市长。

而且研究表明两者可以混用：先用CoVe验证RAG检索回来的文档是否真的相关，再决定要不要用。代价是成本翻倍，但在医疗、法律这种高风险场景下，还是可行的。

从Vibe Coding到系统2代理

关注2026年初Agentic爆发的人，大概都听过"Ralph Wiggum"技术这个梗。

名字来自《辛普森一家》里那个喊着"我在帮忙！"却啥也没干成的角色。这技术的核心就是把LLM塞进一个while循环，让它反复尝试直到单元测试通过。暴力验证，Token消耗会爆表但最后确实能撞出正确答案。虽然听起来很好笑，实际上还挺管用。

工具增强版CoVe

opencode、OpenDevin、Windsurf这些现代自主代理已经在用"工具增强"版本的CoVe了。

它们不再只是问自己"这代码对不对"，而是直接动手：先写代码，然后在沙盒里跑npm test或linter，读stderr输出，根据真实报错来修。

这就把CoVe的验证环节从概率猜测变成了确定性判断。

2026年的新拓扑：分支验证

最前沿的做法已经不是简单的线性循环了。是分支。

分支拓扑下，代理不是失败了就重试一次。它会同时提出三个修复方案，在三个隔离容器里并行跑，哪个能让构建变绿就提交哪个。

验证的消耗

这是2026年工程实践必须面对问题

Vibe Coding走系统1路线：快、便宜、但有20%左右的幻觉率，做原型够用。系统2代理反过来：慢、Token成本翻10倍、但可靠性过硬，生产环境离不开。

也就是说是拿计算资源换安心，当业务从聊天机器人升级到自主工程师，这笔成本不是能不能接受的问题，而是必须付的保险费——除非你想承担"Ralph Wiggum式"的风险，比如AI自己把数据库删了。

总结

CoVe的代价很明确：延迟。

生成初稿、生成问题、并行验证、综合重写，整套流程跑下来，Token消耗和响应时间基本翻四倍。对于实时聊天场景，这个延迟可能难以接受。但换个角度看，异步报告生成、代码审查、自动邮件起草这类任务，多等几秒换来输出可信度的大幅提升，这笔账怎么算都划算。

更值得关注的是CoVe带来的转变：过去几年，行业把大量精力投入到"如何让模型生成得更好"上——更大的参数、更多的数据、更精细的对齐。CoVe指向了另一个方向：与其追求一次生成就完美，不如承认模型会犯错，然后在架构层面把纠错机制build进去。

这和软件工程的演进路径很像。早期写代码追求一次写对，后来发现测试驱动开发、持续集成、灰度发布这些"验证优先"的实践才是规模化的正确姿势。

CoVe不会是终点，我们未来大概率会看到更多CoVe与RAG、外部工具、多模型交叉验证的组合方案。

https://avoid.overfit.cn/post/1f3da2d8396d44c6bab8bfea80405cb6

作者：Digvijay Mahapatra

LLM幻觉问题至今没有根治方案。RAG能缓解一部分，但成本高、架构复杂，而且只适用于有外部知识源的场景。而对于模型"应该知道但经常搞错"的那类问题，比如历史事件的时间线、人物履历的细节，RAG帮不上什么忙。

Chain-of-Verification（CoVe）的思路是既然模型会在生成时犯错，那就让它生成完之后再检查一遍自己的输出，把能发现的错误纠正掉，然后再给用户看。

听起来像是废话？关键在于"怎么检查"。

直接让模型审视自己刚写的东西，它大概率会坚持原有立场，这是确认偏差在作祟。CoVe的核心贡献是发现了一个绕过这个陷阱的方法：验证时必须把原始输出藏起来，让模型在"失忆"状态下重新回答事实性问题，然后用这些独立验证的答案去校对初稿。

某种意义上，这是给LLM装上了"系统2"思维：快思考先出初稿，慢思考再做验证。

工作流程：起草、规划、验证、修复

CoVe不是什么新的模型架构，它是一种提示编排模式，它把生成过程拆成四步：先让模型写初稿（这时候幻觉随便来），然后让它针对自己的初稿生成一组事实核查问题，接着独立回答这些问题，最后用验证过的事实重写原文。

Factored：真正的关键

前面说的四步里，第一、二、四步都是常规提示工程，用思维链就能搞定，而第三步才是核心。

让LLM一边看着自己写的东西一边验证，会有一个问题，这个在学术上管这叫"sycophancy"，也就是说模型会顺着自己的话往下说。草稿就在上下文窗口里摆着，概率分布会被带偏，模型倾向于认同自己刚编出来的东西。

所以最简单的解决办法是把上下文剥掉。

CoVe论文里发现，回答验证问题时必须把原始草稿藏起来。举个例子：如果你问"根据这个草稿，X是不是在1998年发生的？"模型八成会点头同意自己。但如果你只问"X是什么时候发生的？"它就得老老实实从训练权重里检索答案，没有偏差可言。

隔离验证问题就是逼模型去查自己的知识库，而不是复读自己刚说过的话。

代码实现

下面是CoVe流程的Python实现，封装成一个类。注意第三步里的CRITICAL注释，那就是Factored验证的精髓。

 classChainOfVerification:  
    def__init__(self, llm):  
        self.llm=llm  

    defrun(self, query):  
        # Step 1: Baseline Generation
        # Let the model hallucinate freely here.
        draft_prompt=f"Question: {query}\nAnswer:"  
        draft=self.llm.generate(draft_prompt)  
        print(f"--- DRAFT ---\n{draft}\n")  

        # Step 2: Plan Verifications
        # Ask the model to identify what needs checking.
        plan_prompt=f"""  
        Context: {query}  
        Draft: {draft}  
        Task: Create a list of 3-5 verification questions to check the facts   
        in the draft. Output ONLY the questions.  
        """  
        plan_text=self.llm.generate(plan_prompt)  
        questions=self.parse_questions(plan_text)
        print(f"--- QUESTIONS ---\n{questions}\n")  

        # Step 3: Factored Verification (The Key Step)
        verification_results= []  
        forqinquestions:  
            # CRITICAL: Do NOT include 'draft' in this prompt context.
            # We want the raw model weights to answer this, uninfluenced by the previous lie.
            verify_prompt=f"Question: {q}\nAnswer:"  
              
            # Low temperature is crucial here for factual retrieval
            answer=self.llm.generate(verify_prompt, temperature=0)  
            verification_results.append((q, answer))  

        # Step 4: Final Synthesis
        # Now we bring it all together.
        verification_context=self.format_pairs(verification_results)  
        synthesis_prompt=f"""  
        Original Query: {query}  
        Draft Response: {draft}  
          
        Verification Data:  
        {verification_context}  
          
        Task: Rewrite the Draft Response to be fully accurate.   
        Remove any details contradicted by the Verification Data.  
        """  
        final_response=self.llm.generate(synthesis_prompt)  
          
        returnfinal_response  

    defparse_questions(self, text):  
        return [line.strip() forlineintext.split('\n') if'?'inline]  

    defformat_pairs(self, pairs):  
         return"\n".join([f"Q: {q}\nA: {a}"forq, ainpairs])

CoVe和RAG该怎么选？

每次聊到CoVe，总有人问：为什么不直接用RAG？

两者解决的是不同问题。

RAG适用于模型根本不可能知道答案的场景，比如你公司Q3的销售数据。CoVe适用于模型理论上应该知道、但可能搞混或偷懒的场景，比如按时间顺序列出纽约市历任市长。

而且研究表明两者可以混用：先用CoVe验证RAG检索回来的文档是否真的相关，再决定要不要用。代价是成本翻倍，但在医疗、法律这种高风险场景下，还是可行的。

从Vibe Coding到系统2代理

关注2026年初Agentic爆发的人，大概都听过"Ralph Wiggum"技术这个梗。

名字来自《辛普森一家》里那个喊着"我在帮忙！"却啥也没干成的角色。这技术的核心就是把LLM塞进一个while循环，让它反复尝试直到单元测试通过。暴力验证，Token消耗会爆表但最后确实能撞出正确答案。虽然听起来很好笑，实际上还挺管用。

工具增强版CoVe

opencode、OpenDevin、Windsurf这些现代自主代理已经在用"工具增强"版本的CoVe了。

它们不再只是问自己"这代码对不对"，而是直接动手：先写代码，然后在沙盒里跑npm test或linter，读stderr输出，根据真实报错来修。

这就把CoVe的验证环节从概率猜测变成了确定性判断。

2026年的新拓扑：分支验证

最前沿的做法已经不是简单的线性循环了。是分支。

分支拓扑下，代理不是失败了就重试一次。它会同时提出三个修复方案，在三个隔离容器里并行跑，哪个能让构建变绿就提交哪个。

验证的消耗

这是2026年工程实践必须面对问题

Vibe Coding走系统1路线：快、便宜、但有20%左右的幻觉率，做原型够用。系统2代理反过来：慢、Token成本翻10倍、但可靠性过硬，生产环境离不开。

也就是说是拿计算资源换安心，当业务从聊天机器人升级到自主工程师，这笔成本不是能不能接受的问题，而是必须付的保险费——除非你想承担"Ralph Wiggum式"的风险，比如AI自己把数据库删了。

总结

CoVe的代价很明确：延迟。

生成初稿、生成问题、并行验证、综合重写，整套流程跑下来，Token消耗和响应时间基本翻四倍。对于实时聊天场景，这个延迟可能难以接受。但换个角度看，异步报告生成、代码审查、自动邮件起草这类任务，多等几秒换来输出可信度的大幅提升，这笔账怎么算都划算。

更值得关注的是CoVe带来的转变：过去几年，行业把大量精力投入到"如何让模型生成得更好"上——更大的参数、更多的数据、更精细的对齐。CoVe指向了另一个方向：与其追求一次生成就完美，不如承认模型会犯错，然后在架构层面把纠错机制build进去。

这和软件工程的演进路径很像。早期写代码追求一次写对，后来发现测试驱动开发、持续集成、灰度发布这些"验证优先"的实践才是规模化的正确姿势。

CoVe不会是终点，我们未来大概率会看到更多CoVe与RAG、外部工具、多模型交叉验证的组合方案。

https://avoid.overfit.cn/post/1f3da2d8396d44c6bab8bfea80405cb6

作者：Digvijay Mahapatra

众所周知，gpt5 系列的长思考一直被诟病，在之前，由于没有回传思考，导致 gpt 的每次对话都要重新思考，会导致时间的大幅浪费

然而目前 kilo roo 等对于 gpt 系列又不会回传思考签名，所以就只能自己做了

gpt 本身其实也提供了回传思考签名的方法，需要走 responses 格式的接口

实际体验来说，确实如预期那样，整体思考时间大幅缩减，只会在首次几轮存在长思考的情况，后续长思考就几乎没有了：

开头几轮：

简单测评一下带回传思考的 gpt-5.2-xhigh，节省了大量思考时间，整体用时大幅缩减1

之后：

简单测评一下带回传思考的 gpt-5.2-xhigh，节省了大量思考时间，整体用时大幅缩减2


简单测评一下带回传思考的 gpt-5.2-xhigh，节省了大量思考时间，整体用时大幅缩减4

和在 cursor 里的 gpt 表现一致，所以建议使用 gpt 时，尽量使用能支持回传思考签名的

gpt 本身 debug 的能力是比 claude 要更强的

一回合做出来的效果：

简单测评一下带回传思考的 gpt-5.2-xhigh，节省了大量思考时间，整体用时大幅缩减3

测试使用的插件来自：

📌 转载信息
原作者：
Lianues
转载时间：
2026/1/6 12:07:23