1. 为什么单一模型扛不住真实工作流1.1 从“选哪个模型”到“哪个环节用哪个模型”我刚开始接触大模型那会儿也犯过一个典型错误总想找到一个“最强模型”然后所有任务都交给它。结果就是读一篇三十页的英文综述用推理型模型硬啃token烧得飞快输出还经常漏掉关键数据反过来让一个偏对话的模型去做多步逻辑推导它会在第三步就开始编造中间结论。踩了几次坑之后我才想明白一件事——模型不是用来“选一个最好的”而是用来“分工”的。这个思路的转变其实对应着真实工作流里三种截然不同的任务形态。第一种是信息吞吐型典型场景就是读文献、读长报告、读合同特点是输入极长、输出要求结构化、对“不漏”比对“聪明”更重要。第二种是逻辑推演型比如拆解一个算法、推导一个公式、审查一段代码的边界条件特点是需要多步思考、需要自我校验、对“想清楚”比“读得快”更重要。第三种是多模态生成型比如把实验数据画成示意图、把流程描述转成架构图、把一段文字变成配图特点是跨模态、需要审美和结构感。把这三类任务混在一起用一个模型就像让一个擅长写散文的人去干会计的活——不是干不了是效率低、错误率高。所以这篇东西的核心就是把我自己跑通的这套“分工方案”完整拆开DeepSeek 负责读GPT 负责推Gemini 负责画中间用 Coze 这类工作流工具串起来形成一个可复用的 AI Agent 流水线。1.2 三个模型各自的“性格”与适用边界先说说我对这三个模型的体感这部分是后面所有操作的基础不理解性格就谈不上分工。DeepSeek 的性格是“耐得住”。它的长上下文处理能力在实际使用中非常突出尤其是面对几十页 PDF 转出来的纯文本时它不会像某些模型那样“读到后面忘了前面”。我实测过把一篇 2 万词的综述丢进去让它按“研究方法—样本量—核心结论—局限性”四栏做表它基本能把散落在各段落里的数据捞干净。这个特性决定了它天然适合做文献阅读和信息抽取的第一道工序。GPT 的性格是“想得深”。它在多步推理、代码逻辑、数学推导上的稳定性是我目前用下来最放心的。尤其是当你要求它“先列出假设再逐步推导最后回头验证”时它会真的按这个结构走而不是跳步。所以推理、代码审查、复杂决策拆解这类活交给它。Gemini 的性格是“画得像”。它的多模态生成能力特别是在科研绘图、流程图、示意图这类需要“结构审美”的场景里出图质量明显更贴合学术和工程表达习惯。你给它一段实验流程描述它能生成带箭头、带分层、带标注的示意图而不是那种一眼假的 AI 画风。所以科研绘图、流程可视化、架构示意归它。注意这里的“分工”不是绝对的而是基于我大量实测后的性价比判断。你也可以根据自己手头的账号和额度灵活调整但核心逻辑——长文本归长文本模型深推理归推理模型多模态归多模态模型——是不变的。1.3 用 Coze 把三个模型串成一条流水线单独用三个模型你只是在“切换工具”用 Coze 这类工作流平台把它们串起来你才是在“搭建系统”。这两者的差别相当于手动挡换自动挡。Coze 的工作流搭建逻辑很直白输入节点 → 处理节点 → 输出节点。你可以把 DeepSeek 的文献抽取设成第一个处理节点把 GPT 的推理分析设成第二个把 Gemini 的绘图设成第三个中间用变量传递数据。这样你只需要丢进去一篇 PDF最后拿到的就是“结构化摘要 推理结论 配图”的完整包。我搭第一版的时候没想清楚变量传递结果 DeepSeek 输出的表格格式和 GPT 需要的输入格式对不上中间卡了半天。后来我加了一个“格式规整”的中间节点专门做字段对齐整条流水线才跑顺。这个坑后面会详细讲。2. DeepSeek 读文献把长文本榨干2.1 文献阅读的真正难点不是“读”是“抽”很多人以为读文献的难点在于“看不懂”其实对从业者来说真正的难点是从大量文本里稳定地抽出结构化信息。一篇综述里研究方法可能散在第 2 节样本量藏在一张表的注释里核心结论又在讨论部分绕了三段才说清楚。你要的不是“读懂”而是“不漏、不错、可对比”。DeepSeek 在这件事上的优势是它对长文本的“注意力保持”比较稳。我做过一个对比同样一篇 1.8 万词的论文让不同模型做“方法—样本—结论—局限”四栏抽取DeepSeek 的字段完整率明显更高尤其是“局限性”这种通常写在角落里的信息它也能捞出来。具体操作上我习惯把 PDF 先转成纯文本去掉页眉页脚和参考文献列表再喂给 DeepSeek。这一步很关键因为参考文献列表会占用大量 token而且对抽取核心信息毫无帮助。转文本我用的是常见的 PDF 转文本工具转完手动扫一遍把明显的乱码段落删掉。2.2 提示词怎么写才能让抽取稳定提示词这块我踩过的最大坑是“要求太模糊”。早期我写的是“请总结这篇文献”结果每次输出的结构都不一样有的按章节有的按主题根本没法横向对比。后来我改成固定字段 固定格式 固定示例稳定性立刻上来了。我常用的模板是这样的你是一名文献信息抽取助手。请阅读以下文本并严格按以下四个字段输出每个字段用二级标题内容用无序列表 1. 研究方法列出所有使用的方法每条注明出现在原文哪个部分。 2. 样本量列出所有涉及的样本数量及对应群体。 3. 核心结论列出作者明确陈述的结论不要加入你的推断。 4. 局限性列出作者自己承认的局限若原文未提及则写“未提及”。 要求只输出上述四部分不要额外解释不要总结全文。这个模板的关键在于**“不要加入你的推断”和“若原文未提及则写未提及”**这两句。前者防止模型自由发挥后者防止它为了凑字段而编造。我实测下来加了这两句之后幻觉率明显下降。2.3 长文本分块与上下文窗口的取舍即便 DeepSeek 长上下文能力不错我仍然建议对超长文献做分块处理。原因有两个一是单次输入太长时模型对中间部分的注意力会下降这是所有长上下文模型的通病二是分块后你可以并行处理速度更快。我的分块策略是按章节切不按字数切。因为章节本身就是语义边界按章节切能保证每块内部逻辑完整。切完之后每块单独跑一次抽取最后用一个“合并节点”把结果拼起来。合并的时候要注意去重尤其是“核心结论”这种可能跨章节重复的字段。实操心得分块时给每块加一个“块编号”和“所属章节”的元信息合并时按编号排序能避免结果乱序。这个小细节我一开始没做导致合并后的结论顺序和原文对不上返工了一次。2.4 抽取结果的二次校验DeepSeek 抽出来的东西我从来不会直接用一定会做一次回查校验。方法很简单让它把每个结论对应的原文句子也一并输出然后我抽查几条看是否真的在原文里。这一步看起来麻烦但对于要写进报告的数据值得。如果发现某条结论找不到原文支撑大概率是模型推断出来的直接删掉。我遇到过好几次“样本量”字段被模型自动补全的情况比如原文只写了“共招募 120 人”它却在输出里写成“120 人其中实验组 60 人对照组 60 人”——后一半是它自己猜的。这种如果不校验写进报告就是事故。3. GPT 搞推理把逻辑链条走完3.1 推理任务的三种典型形态GPT 在我这套流水线里承担的是“深加工”角色。具体来说它处理三类任务逻辑推导、代码审查、决策拆解。逻辑推导最常见的就是“从前提推到结论”。比如你有一组实验数据想让它判断“这个差异是否支持某个假设”它会先列出前提再逐步推导最后给出结论和置信度。代码审查则是把一段代码丢进去让它找边界条件、找潜在的空指针、找性能瓶颈。决策拆解是把一个模糊的目标拆成可执行的步骤比如“我要在三个月内搭一个 AI Agent 中台”它会拆成需求梳理、技术选型、模块划分、测试上线几个阶段。这三类任务的共同点是需要多步、需要自校验。GPT 在这方面的稳定性是我目前用下来最满意的。3.2 让 GPT“先想再答”的提示词结构GPT 有个特点如果你直接问结论它会给你一个“看起来对”的答案如果你要求它先展示推理过程它的答案质量会明显提升。所以我所有的推理类提示词都会强制它先列假设、再推导、最后验证。我常用的结构是这样的请按以下三步回答不要跳步 第一步列出你解决这个问题所依赖的所有前提假设每条注明来源是题目给出的还是你补充的。 第二步基于上述假设逐步推导每一步都要说明依据。 第三步回头检查你的推导指出其中不确定的环节并给出你的置信度高/中/低。 问题[你的具体问题]这个结构的好处是它把“推理”变成了一个可审计的过程。你能看到它每一步的依据也能看到它自己承认的不确定环节。我实测下来加了第三步的“自检”之后它在复杂问题上的错误率明显下降因为它会主动暴露自己的薄弱点。3.3 代码审查与逻辑校验的实操代码审查是我用得最多的场景。我通常会把代码和“审查清单”一起给它清单包括边界条件、异常处理、资源释放、并发安全、性能热点。让它逐项检查而不是泛泛地“看看有没有问题”。有一次我让它审查一段数据处理代码它指出“当输入为空列表时后续的索引操作会抛异常”。这个点我自己确实没考虑到因为我的测试数据里从来没有空列表。这就是 GPT 的价值——它会从“最坏情况”出发而不是从“正常情况”出发。逻辑校验也是类似。我经常把一段推理链丢给它让它找“哪一步的跳跃最大”。它会指出“从 A 到 B 的推导缺少一个中间条件”然后建议我补上。这种“找断点”的能力在写报告和做决策时特别有用。3.4 推理结果的置信度评估GPT 给出的置信度我一般会当作“参考”而不是“结论”。它的“高置信度”通常意味着“这个推导在逻辑上很直接”但不代表“事实一定正确”。因为如果前提假设本身是错的推导再严谨也没用。所以我的做法是把 GPT 的推理结果和 DeepSeek 抽取的原文事实做交叉验证。如果 GPT 的结论和原文数据一致置信度就高如果它基于原文数据推出了一个原文没说的结论我就会标记为“待验证”。这个交叉验证的环节是整条流水线里最能防幻觉的一步。4. Gemini 做科研绘图把描述变成图4.1 科研绘图和普通 AI 绘图的区别普通 AI 绘图追求“好看”科研绘图追求“准确”。一张实验流程图箭头方向错了、分层逻辑乱了、标注对不上图再好看也是废的。所以用 Gemini 做科研绘图关键不在于“描述得多美”而在于“描述得多结构化”。我一般会把绘图需求拆成四个要素元素、关系、层级、标注。元素是图里有哪些方块和箭头关系是谁指向谁层级是哪些属于同一组标注是每个元素旁边写什么字。把这四个要素写清楚Gemini 出图的准确率会高很多。4.2 用结构化描述驱动绘图我常用的绘图提示词模板是这样的请生成一张科研流程示意图要求如下 元素 - 三个主模块数据采集、特征提取、模型训练 - 每个主模块下有两个子步骤 关系 - 数据采集 → 特征提取 → 模型训练单向箭头 - 子步骤之间用虚线连接 层级 - 主模块用实线框子步骤用虚线框 标注 - 每个模块下方标注其核心输出 风格简洁、学术、黑白为主不要装饰性元素。这个模板的关键是**“不要装饰性元素”**。科研图最怕花里胡哨Gemini 如果不加这句有时候会给你加一堆渐变和阴影反而不利于印刷和阅读。4.3 绘图结果的迭代与修正Gemini 出图很少一次就完美通常需要两到三轮迭代。我的修正策略是每次只改一个要素比如“把第二个模块的箭头方向反过来”而不是“重新画一张”。因为一次改太多你很难判断是哪处修改导致了结果变化。另外如果 Gemini 连续几次都画不对某个结构我会换一种描述方式。比如“并列关系”它画成了“串联”我就改成“这三个模块是同一层级的没有先后顺序请用并排布局”。换一种说法往往就通了。注意Gemini 生成的图如果要用在正式报告里一定要人工检查箭头方向和标注文字。我遇到过箭头方向反了但整体看起来很合理的情况差点就发出去了。4.4 多模态输出的格式与导出Gemini 出图后导出格式我一般选 PNG 或 SVG。PNG 适合直接插入文档SVG 适合后续用矢量工具微调。如果图里有文字建议导出 SVG因为 PNG 放大后文字会糊。导出后我还会做一件事把图重新丢回 Gemini让它描述这张图的内容然后和我原本的需求对比。如果它的描述和我的需求一致说明图基本没问题如果不一致说明某处画错了。这个“反向验证”的小技巧帮我抓过好几次错误。5. 用 Coze 串起完整工作流5.1 工作流的节点设计与变量传递Coze 工作流的核心是节点和变量。我的标准流水线有五个节点输入节点、DeepSeek 抽取节点、格式规整节点、GPT 推理节点、Gemini 绘图节点最后是输出节点。变量传递是最容易出问题的地方。DeepSeek 输出的是一段带标题的文本GPT 需要的是结构化的字段中间如果不做格式转换GPT 就会把整段文本当成一个问题来处理效果很差。所以我加了一个“格式规整节点”专门把 DeepSeek 的输出拆成“研究方法”“样本量”“核心结论”“局限性”四个变量再传给 GPT。这个格式规整节点我一开始想用代码写后来发现用 Coze 自带的文本处理节点就能做配置起来更快。具体就是按标题分割然后提取每个标题下的内容。5.2 从 0 到 1 搭建的完整步骤搭建步骤我按顺序列一下方便你照着做创建 Coze 工作流选择“空白工作流”。添加输入节点定义一个变量叫input_text类型为文本。添加 DeepSeek 节点把input_text传进去提示词用第 2 节里的抽取模板。添加文本处理节点按二级标题分割 DeepSeek 的输出提取四个字段。添加 GPT 节点把四个字段拼成推理提示词用第 3 节里的三步结构。添加 Gemini 节点把 GPT 的结论转成绘图描述用第 4 节里的模板。添加输出节点把三个模型的输出汇总。测试运行用一篇真实文献跑一遍检查每个节点的输出。我第一次搭的时候在第 4 步卡了很久因为 DeepSeek 的输出格式偶尔会变导致分割失败。后来我在提示词里加了“严格按二级标题输出不要用其他格式”稳定性才上来。5.3 调试与性能优化工作流跑通之后下一步是优化。我主要优化两个点速度和成本。速度方面DeepSeek 和 GPT 的调用可以并行的地方就并行。比如文献抽取和绘图描述生成其实不依赖彼此可以同时跑。Coze 支持并行节点配置一下就行。成本方面主要是控制 token 消耗。DeepSeek 那边我会在输入前做一次“去噪”把参考文献、致谢、附录删掉能省不少 token。GPT 那边我会限制输出长度避免它写太长。5.4 工作流的复用与扩展这套工作流跑顺之后复用性很强。换一篇文献只需要改输入换一个推理任务只需要改 GPT 的提示词换一种图只需要改 Gemini 的描述。整个骨架不用动。扩展方向也很多。比如你可以加一个“翻译节点”把英文文献先翻译成中文再抽取或者加一个“对比节点”把两篇文献的抽取结果做对比。我最近在试的是加一个“引用生成节点”让 GPT 根据抽取结果自动生成引用格式省得手动整理。6. 常见问题与排查技巧实录6.1 模型输出格式不稳定的排查格式不稳定是最常见的问题。表现是同样的提示词有时候输出带标题有时候不带有时候用列表有时候用段落。排查思路是先看提示词有没有歧义再看模型版本有没有变。我的经验是提示词里凡是涉及格式的要求都要用“必须”“严格”“不要”这类强约束词。比如“必须用二级标题”“严格按四栏输出”“不要额外解释”。软性的“请尽量”基本没用。如果提示词没问题但格式还是飘那可能是模型版本更新了。这时候我会把提示词里的示例再写具体一点通常能拉回来。6.2 长文本截断与信息丢失的处理长文本截断的表现是模型只处理了前半部分后半部分完全没提。排查方法是在输入末尾加一句“请确认你已阅读全文”如果它的回答里没有体现后半部分的内容就是截断了。处理方法是分块。分块的时候注意块与块之间要有重叠比如上一块的最后一段和下一块的第一段重复这样能避免边界处的信息丢失。重叠比例我一般设 10% 左右。6.3 绘图结果与预期不符的修正绘图不符的表现很多箭头方向反了、层级乱了、标注错了。修正的核心原则是一次只改一个要素并且用肯定句描述你想要的而不是否定句描述你不想要的。比如“不要画成串联”不如“请画成三个并排的模块没有先后顺序”。前者模型可能理解成“不要串联但可以画成环形”后者就明确多了。6.4 常见问题速查表问题表现可能原因排查方法解决方法输出格式每次不同提示词约束不够强检查是否有“必须/严格”等强约束词加固定字段和示例长文本只处理前半上下文截断末尾加“请确认已阅读全文”按章节分块块间重叠 10%抽取结果有编造模型自由推断要求输出原文对应句加“不要推断”约束回查校验绘图箭头方向错关系描述不清反向让模型描述图内容用肯定句明确指向关系工作流变量传不过去格式不匹配检查上下游字段类型加格式规整节点推理结论置信度虚高前提假设有误交叉验证原文事实标记待验证人工复核6.5 我踩过的三个坑第一个坑是过度信任单次输出。早期我拿到 DeepSeek 的抽取结果就直接用后来发现有几处数据对不上原文返工重做。现在的习惯是凡是关键数据一定回查原文。第二个坑是提示词写得太长。我以为写得越详细越好结果模型被一堆约束绕晕了反而抓不住重点。后来我改成“核心约束三条其余用示例说明”效果好很多。第三个坑是工作流节点太多。我一开始想一步到位加了七八个节点结果调试起来极其痛苦。后来精简到五个核心节点跑顺了再逐步加效率高多了。7. 几个提升效率的实战技巧7.1 建立自己的提示词库提示词不要每次现写建一个库按任务类型分类。我自己的库分四类抽取类、推理类、绘图类、格式规整类。每类下面存几个经过实测的模板用的时候直接复制改参数。这个习惯帮我省了大量时间。库的维护也有讲究每次发现一个好用的提示词立刻存进去并注明适用场景和注意事项。我还会定期清理那些效果变差的因为模型更新后有些老提示词会失效。7.2 用变量减少重复输入Coze 的变量功能可以把常用的参数抽出来比如“输出语言”“详细程度”“绘图风格”。这样换任务的时候只需要改变量值不用改整个提示词。我现在的绘图节点风格变量设了“学术”“简洁”“彩色”三个选项切换起来很方便。7.3 定期回顾与迭代工作流工作流不是搭完就不管了。我每个月会回顾一次看哪些节点经常出问题哪些提示词需要更新。这个习惯让我这套流水线越跑越顺现在处理一篇文献从输入到出图大概十几分钟就能搞定。7.4 关于模型选择的最后一点个人体会回到标题里的“选择困难症”。我的体会是困难不是因为模型太多而是因为你想用一个模型解决所有问题。一旦你接受了“分工”这个思路选择就变得很简单读文献找 DeepSeek搞推理找 GPT做绘图找 Gemini串流程用 Coze。每个环节用最合适的整体效率反而最高。这套方案我跑了小半年中间迭代了三四版现在基本稳定。如果你也在搭类似的工作流建议先从单个环节跑通再串起来不要一上来就追求全自动。先把 DeepSeek 的抽取跑稳再加 GPT再加 Gemini每一步都验证过再往下走这样出问题的时候好定位。