企业官网建设流程全解析

1. 为什么我们需要一个“模型分工”的思维框架

1.1 从“一个模型打天下”到“各司其职”的认知转变

过去两年，我身边不少做研究、写代码、搞内容的朋友都有一个习惯：认准一个模型，恨不得所有任务都交给它。结果呢？读文献的时候嫌它总结得不够细，写代码的时候嫌它逻辑跳步，画图的时候又嫌它审美不在线。折腾一圈下来，时间全花在反复调提示词和换工具上了。

这个问题的根源不在于模型不够强，而在于我们潜意识里把大语言模型当成了一个“全能选手”。但实际用下来你会发现，不同模型在训练数据、微调策略、推理架构上的差异，直接决定了它们在不同任务上的表现差距可能非常大。DeepSeek 在长文本理解和信息抽取上有独特优势，GPT 系列在复杂逻辑推理和代码生成上积累深厚，Gemini 在多模态理解和科研可视化方面有天然基因。这不是谁强谁弱的问题，而是“什么活儿找什么人”的问题。

我自己的做法是：把日常任务分成三大类——文献阅读与信息提取、逻辑推理与代码实现、科研绘图与多模态输出。然后针对每一类任务，固定使用最擅长的那个模型，形成肌肉记忆。这样一来，我不再需要每次纠结“用哪个”，而是直接进入“怎么用”的状态。效率提升非常明显，以前一篇论文从读到整理笔记要两三个小时，现在四十分钟左右就能出一份结构化的摘要加关键数据表。

这篇文章就是把我这套分工方法论完整拆开，从任务分类、模型选型、提示词设计到实操流程，一步步讲清楚。不管你是刚接触大模型的新手，还是已经用过一段时间但总觉得“差点意思”的老用户，都能从中找到可以直接抄作业的方案。

1.2 三类核心任务的边界划分

在展开具体操作之前，先把我对这三类任务的划分标准说清楚。这个划分不是拍脑袋定的，而是根据实际使用中“模型表现差异最明显”的维度来切的。

第一类：文献阅读与信息提取。典型场景包括：读学术论文并提取研究方法、实验数据、结论；读技术文档并整理关键配置参数；读长篇报告并生成结构化摘要。这类任务的核心需求是“不遗漏、不曲解、可追溯”。模型需要具备强大的长上下文理解能力、对专业术语的准确识别能力，以及把非结构化文本转成结构化表格的能力。DeepSeek 在这方面的表现让我最放心，尤其是它处理中文文献和混合语言内容时的稳定性。

第二类：逻辑推理与代码实现。典型场景包括：算法设计、代码调试、数学证明、复杂业务逻辑梳理。这类任务的核心需求是“步骤可验证、逻辑可追溯、边界条件考虑周全”。GPT 系列在推理链的完整性和代码生成的可用性上，目前仍然是我用过最稳的。特别是涉及多步推理和条件分支的时候，GPT 的“思考过程”更接近一个严谨的工程师。

第三类：科研绘图与多模态输出。典型场景包括：根据数据生成图表、根据描述生成示意图、把文字结论转成可视化摘要、处理图像和文本混合的任务。这类任务的核心需求是“视觉表达准确、风格可控、可迭代修改”。Gemini 在多模态理解上的积累让它在这类任务中优势明显，尤其是它能把数据表格直接转成带标注的图表，省去了大量手动调整的时间。

这三类任务之间当然有重叠，比如读文献的时候也可能需要画个流程图，写代码的时候也可能需要生成架构图。我的处理原则是：以任务的主要矛盾为准。如果主要目标是“理解内容”，就用 DeepSeek；如果主要目标是“生成逻辑”，就用 GPT；如果主要目标是“视觉呈现”，就用 Gemini。下面逐个展开。

2. DeepSeek 读文献：从“读完就忘”到“结构化知识库”

2.1 为什么读文献这件事需要专门的方法论

读文献这件事，很多人觉得“把 PDF 丢给模型让它总结”就完了。但实际用下来你会发现，通用总结往往停留在“这篇文章研究了什么”的层面，而真正有价值的信息——比如实验的具体参数、对比基线的方法细节、结论的适用边界——经常被一笔带过。问题出在两个地方：一是提示词太笼统，没有引导模型去提取关键信息；二是没有建立“读完之后怎么用”的输出结构。

我的做法是把读文献拆成三个阶段：预读筛选、精读提取、归档复用。每个阶段用不同的提示词策略，最终输出一份可以直接放进知识库的结构化笔记。DeepSeek 在这个流程中的角色是“精读提取”和“归档复用”的主力，因为它的长上下文窗口能一次性吞下整篇论文，而且对中文文献的理解准确度很高。

2.2 预读筛选：三分钟判断一篇论文值不值得精读

预读阶段的目的是快速判断一篇论文是否与你的研究方向相关。这个阶段不需要模型做深度理解，只需要它帮你回答三个问题：这篇论文解决什么问题？用了什么方法？结论是什么？我常用的提示词模板是这样的：

请阅读以下论文的摘要和引言部分，用三句话回答： 1. 这篇论文要解决的核心问题是什么？ 2. 它采用的主要方法或技术路线是什么？ 3. 它的主要结论或贡献是什么？ 如果这篇论文与[你的研究方向]的相关性低于中等水平，请直接说明“建议跳过”。

这个模板的关键在于最后那句“建议跳过”。不加这句话，模型会倾向于给每篇论文都找出相关性，浪费你的时间。加了之后，它会更诚实地评估相关性。我实测下来，这个筛选步骤能帮我过滤掉大约六成不需要精读的论文，节省的时间非常可观。

注意：预读阶段不要用太长的提示词，也不要把整篇论文丢进去。摘要加引言足够了，模型在这个阶段的任务是“判断”而不是“理解”。

2.3 精读提取：把论文拆成可复用的知识单元

预读通过之后，进入精读阶段。这个阶段的目标是把论文的核心内容拆成结构化的知识单元，方便后续检索和引用。我通常会把整篇论文（或者至少是方法、实验、结论三个部分）输入给 DeepSeek，然后用下面这个提示词模板：

请仔细阅读这篇论文，并按照以下结构输出一份精读笔记： 一、研究背景与问题定义 - 该领域已有的工作有哪些？ - 这篇论文指出的现有方法的不足是什么？ - 论文要解决的具体问题是什么？ 二、方法细节 - 核心方法的技术路线是什么？ - 关键模块或步骤有哪些？请逐步说明。 - 用到了哪些数学工具或算法？请给出关键公式及其含义。 三、实验设置与结果 - 使用了哪些数据集？数据规模如何？ - 对比了哪些基线方法？ - 主要评价指标是什么？结果如何？ - 是否有消融实验？结论是什么？ 四、结论与局限性 - 论文的主要结论是什么？ - 作者自己提到的局限性有哪些？ - 你认为还有哪些潜在的改进方向？ 五、关键术语与概念 - 列出论文中出现的专业术语，并给出简明解释。

这个模板看起来有点长，但实际用下来效果非常好。DeepSeek 会按照这个结构逐项填充，输出的笔记直接可以放进 Obsidian 或 Notion 里作为永久笔记。我特别喜欢它在“方法细节”部分的表现，能把复杂的算法流程拆成一步步的说明，而且公式的 LaTeX 格式也保留得很好。

2.4 归档复用：建立可检索的文献知识库

精读笔记生成之后，如果不做归档，过两周就找不到了。我的做法是建立一个简单的文献知识库，每篇论文的笔记按照统一格式命名和存储。文件名格式是“年份-第一作者-关键词”，比如“2024-Zhang-Transformer优化”。笔记内部除了上面五个部分，我还会在开头加一个“一句话总结”和“与我研究的关联”两个字段。

这个知识库的价值在于，当你写综述或者找参考文献的时候，不需要重新读论文，直接搜索关键词就能定位到相关笔记。我试过用 DeepSeek 来辅助检索，把知识库的目录结构或者部分笔记内容输入给它，然后问“哪些论文讨论了小样本场景下的模型泛化问题”，它能很快给出相关论文的列表和简要说明。这个用法虽然简单，但实际效率提升很明显。

实操心得：DeepSeek 在处理中文文献时有一个小技巧——如果论文是中文的，提示词也用中文写；如果是英文的，提示词用英文写效果更好。混合语言的情况下，用英文提示词加中文输出指令的组合最稳。

3. GPT 搞推理：把复杂问题拆成可验证的步骤

3.1 推理任务的核心痛点：跳步与幻觉

用大模型做推理，最让人头疼的两个问题是“跳步”和“幻觉”。跳步是指模型在推理过程中省略了关键步骤，直接给出结论，导致你无法验证它的逻辑是否正确。幻觉是指模型在某个步骤上编造了不存在的事实或数据，然后基于这个错误继续往下推，最终结论完全不可靠。

这两个问题的根源是一样的：模型在生成文本时，倾向于“流畅”而不是“严谨”。它会把最可能的下一个词接上去，而不是把逻辑上最正确的下一步接上去。GPT 系列在这方面做得相对好一些，尤其是开启了“逐步推理”模式之后，它会显式地展示思考过程。但即便如此，如果不加约束，它仍然会在某些步骤上偷懒。

我的应对策略是：把推理任务拆成“定义问题-列出假设-逐步推导-验证结论”四个阶段，每个阶段用独立的提示词，并且强制模型在每一步都给出理由。下面详细展开。

3.2 定义问题：让模型先复述再动手

很多人拿到问题就直接问“怎么解决”，结果模型给了一个看似合理但实际跑不通的方案。我的习惯是先用一个独立的提示词让 GPT 复述问题：

请先不要给出解决方案。请用你自己的话复述以下问题，并指出： 1. 这个问题的核心目标是什么？ 2. 有哪些已知条件和约束？ 3. 有哪些隐含的假设需要确认？ 4. 你认为这个问题的难点在哪里？

这个步骤看起来多余，但实际用下来能避免大量“答非所问”的情况。GPT 在复述问题的过程中，往往会发现一些我原本没有明确说清楚的约束条件，然后主动提出来让我确认。这个过程本身就是在帮我把问题定义得更清晰。

3.3 列出假设：把“默认前提”摆到台面上

复述问题之后，下一步是列出所有假设。这一步非常关键，因为很多推理错误都源于“默认前提”没有被明确。比如你让模型设计一个推荐算法，它可能会默认用户数据是充足的、特征是干净的、计算资源是无限的。这些假设如果不摆出来，你根本不知道它的方案在什么条件下才成立。

我常用的提示词是：

基于你对问题的理解，请列出解决这个问题所需的所有假设。包括： - 数据相关的假设（规模、质量、分布等） - 计算资源相关的假设（内存、算力、延迟要求等） - 业务逻辑相关的假设（用户行为、约束条件等） - 技术栈相关的假设（可用工具、框架、库等） 对于每个假设，请说明如果该假设不成立，会对解决方案产生什么影响。

这个步骤的输出通常是一张表格，左边是假设，右边是影响。我一般会逐条检查，把不成立的假设标记出来，然后让 GPT 基于修正后的假设重新推理。这个来回通常只需要一两轮，但能把方案的可靠性提升一大截。

3.4 逐步推导：强制展示每一步的理由

到了真正的推理阶段，提示词的设计要围绕“可验证”这个目标。我常用的模板是：

请逐步解决以下问题。对于每一步： 1. 说明这一步的目标是什么。 2. 给出具体的操作或计算过程。 3. 解释为什么这一步是必要的，以及它如何推进整体目标。 4. 如果这一步涉及公式，请给出完整的推导过程。 5. 如果这一步涉及代码，请给出可运行的代码片段并解释关键行。 在完成所有步骤后，请回头检查： - 是否有步骤之间存在逻辑跳跃？ - 是否有假设在推导过程中被无意中改变？ - 最终结论是否与问题定义中的目标一致？

这个模板的关键在于最后那个“回头检查”的指令。GPT 在生成完整个推理链之后，如果被要求自我检查，往往能发现一些之前忽略的问题。我实测下来，加了自我检查的推理链，错误率能降低不少。

3.5 验证结论：用反例和边界条件做压力测试

推理链生成之后，不要直接采信。我的做法是让 GPT 自己找反例：

请针对上述结论，尝试构造三个反例或边界条件，说明在什么情况下这个结论可能不成立。对于每个反例，请说明： 1. 具体的场景或输入是什么？ 2. 为什么这个场景会导致结论失效？ 3. 如果要在该场景下仍然得到正确结论，需要做什么修正？

这个步骤能暴露出很多潜在问题。比如一个算法在数据量大的时候表现很好，但在小样本场景下可能完全失效。GPT 在构造反例的时候，往往会发现一些我根本没有想到的边界情况。这些反例本身也很有价值，可以直接作为测试用例。

实操心得：GPT 在推理任务中有一个“温度”参数，建议设置在 0.2 到 0.5 之间。温度太高会导致推理过程不稳定，温度太低又会让模型过于保守，不敢尝试不同的推理路径。我一般用 0.3，兼顾稳定性和灵活性。

4. Gemini 做科研绘图：从数据到图表的最后一公里

4.1 科研绘图的三个层次：数据图、示意图、摘要图

科研绘图不是一个单一任务，我把它分成三个层次。第一层是数据图，比如折线图、柱状图、散点图，这类图的核心是准确呈现数据关系。第二层是示意图，比如算法流程图、系统架构图、实验装置图，这类图的核心是清晰表达逻辑结构。第三层是摘要图，比如论文的图形摘要、汇报用的总结图，这类图的核心是视觉吸引力和信息密度的平衡。

Gemini 在这三个层次上的表现各有特点。数据图方面，它能根据表格数据直接生成带标注的图表代码，省去了手动调整样式的时间。示意图方面，它能理解文字描述的逻辑关系，生成结构合理的流程图。摘要图方面，它的多模态理解能力让它能同时处理文字和图像输入，生成风格统一的视觉摘要。

4.2 数据图：从表格到出版级图表的完整流程

数据图是最常见的需求，也是最容易标准化的。我的流程是：先把数据整理成 CSV 或 Markdown 表格，然后用 Gemini 生成绘图代码，最后在本地运行代码生成图片。提示词模板如下：

我有一组数据，格式如下： [粘贴数据表格] 请帮我生成一张[图表类型]的 Python 代码，要求： 1. 使用 matplotlib 或 seaborn 库。 2. 图表尺寸为 8x6 英寸，分辨率 300 DPI。 3. X 轴标签为[xxx]，Y 轴标签为[xxx]。 4. 标题为[xxx]。 5. 如果有多个数据系列，请使用不同的颜色和标记，并添加图例。 6. 请添加网格线，但不要过于密集。 7. 请把代码中的字体设置为支持中文的字体。 8. 生成代码后，请解释每个关键参数的作用。

这个模板的关键在于“解释每个关键参数的作用”。Gemini 在生成代码之后，会逐行解释参数的含义，这对于后续修改非常有帮助。比如你想调整图例的位置，直接看它的解释就知道改哪个参数。

注意：Gemini 生成的绘图代码有时候会使用一些不常见的库或函数，建议在本地运行之前先检查一下依赖是否齐全。我一般会要求它“只使用 matplotlib 和 seaborn 的标准功能”，避免引入额外的依赖。

4.3 示意图：用文字描述生成逻辑清晰的流程图

示意图的需求通常来自论文或汇报。比如你需要画一个算法流程图，或者一个系统架构图。Gemini 在这方面的能力让我比较惊喜，它能根据文字描述生成结构合理的 Mermaid 或 Graphviz 代码。提示词模板如下：

请根据以下描述生成一张流程图的代码： [描述流程的步骤和逻辑关系] 要求： 1. 使用 Mermaid 的 flowchart 语法。 2. 节点名称使用中文，但节点 ID 使用英文。 3. 用不同的形状区分不同类型的节点（矩形表示处理步骤，菱形表示判断，圆角矩形表示开始/结束）。 4. 用箭头标注流程方向，并在箭头上标注条件（如果有）。 5. 请确保流程的逻辑完整，没有断开的节点。 6. 生成代码后，请用文字描述这张图的整体结构。

Mermaid 代码的好处是可以在很多 Markdown 编辑器里直接渲染，修改起来也方便。Gemini 生成的流程图结构通常比较合理，但偶尔会出现节点命名不一致的问题。我的做法是生成之后自己检查一遍节点 ID，确保没有重复或遗漏。

4.4 摘要图：多模态输入下的视觉摘要生成

摘要图是最高层次的需求，通常用于论文的图形摘要或汇报的总结页。这类图的特点是信息密度高、视觉吸引力强、需要同时处理文字和图像。Gemini 的多模态能力在这里体现得最明显，你可以同时输入文字描述和参考图片，让它生成风格一致的摘要图。

我的做法是：先用文字描述清楚摘要图需要包含的核心信息，然后提供一两张风格参考图，让 Gemini 生成一个视觉方案。提示词模板如下：

我需要为一项研究生成一张图形摘要。研究的核心内容是： [描述研究背景、方法、主要结果] 请帮我设计一张图形摘要，要求： 1. 整体布局分为三个区域：左侧展示研究问题，中间展示方法流程，右侧展示主要结果。 2. 使用简洁的图标和箭头表示逻辑关系。 3. 配色方案使用[xxx]，整体风格偏向[xxx]。 4. 请用文字详细描述每个区域的内容和布局，包括图标的位置、文字的大小和颜色。 5. 如果你能直接生成图像，请生成；如果不能，请给出详细的绘图指令，我可以交给其他工具执行。

这个模板的关键在于“详细描述每个区域的内容和布局”。即使 Gemini 不能直接生成图像，它的文字描述也足够详细，可以交给设计师或者绘图工具执行。我试过把它的描述直接输入给一些在线绘图工具，出来的效果基本符合预期。

实操心得：Gemini 在处理中文文字嵌入图像时，偶尔会出现字符显示问题。我的做法是尽量用英文标注图中的关键文字，然后在图注中用中文解释。这样既避免了显示问题，又保证了可读性。

5. 工具链整合：把三个模型串成一条工作流

5.1 为什么需要工作流而不是单点使用

单独用 DeepSeek 读文献、单独用 GPT 搞推理、单独用 Gemini 画图，这当然可以。但实际工作中，这三类任务往往是交织在一起的。比如你读了一篇文献，发现它的方法有改进空间，然后你设计了一个新算法，最后需要把算法流程和实验结果画成图。如果每个环节都手动切换工具、复制粘贴内容，效率会大打折扣。

我的做法是建立一个简单的工作流：DeepSeek 负责“输入理解”，GPT 负责“逻辑处理”，Gemini 负责“输出呈现”。三者之间通过结构化的中间产物连接。比如 DeepSeek 输出的精读笔记，可以直接作为 GPT 推理的输入；GPT 生成的算法描述，可以直接作为 Gemini 绘图的输入。这样每个模型的输出都是下一个模型的输入，形成一条流水线。

5.2 用 Coze 搭建智能体工作流的实操步骤

如果你想让这条流水线自动化，Coze 是一个值得尝试的平台。它支持把多个模型和工具串成一个工作流，通过可视化界面配置节点和连接。我搭建过一个简单的“文献阅读-方法改进-绘图输出”工作流，大致步骤如下：

第一步：创建 DeepSeek 节点。在 Coze 的工作流编辑器中，添加一个“大模型”节点，选择 DeepSeek 作为模型，配置提示词为精读提取模板。输入变量设置为“论文全文”，输出变量设置为“精读笔记”。

第二步：创建 GPT 节点。添加第二个大模型节点，选择 GPT 作为模型，配置提示词为推理模板。输入变量设置为“精读笔记”，输出变量设置为“改进方案”。

第三步：创建 Gemini 节点。添加第三个大模型节点，选择 Gemini 作为模型，配置提示词为绘图模板。输入变量设置为“改进方案”，输出变量设置为“绘图代码”。

第四步：连接节点。把 DeepSeek 节点的输出连接到 GPT 节点的输入，把 GPT 节点的输出连接到 Gemini 节点的输入。这样就形成了一条完整的流水线。

第五步：测试和调试。上传一篇论文，运行工作流，检查每个节点的输出是否符合预期。如果某个节点的输出格式不对，调整提示词或者增加格式约束。

这个工作流搭建起来大概需要半小时到一小时，但搭建完成之后，每次处理新论文只需要上传文件、点击运行，几分钟就能得到从精读笔记到绘图代码的完整输出。我实测下来，处理效率比手动操作提升了至少三倍。

5.3 工作流中的变量传递与格式约定

工作流能否稳定运行，关键在于节点之间的变量传递格式是否一致。我的经验是：每个节点的输出都尽量用 Markdown 格式，并且用固定的标题层级来组织内容。比如 DeepSeek 节点的输出固定用“一、研究背景”“二、方法细节”“三、实验设置”“四、结论与局限性”“五、关键术语”这五个二级标题。GPT 节点在接收输入时，提示词里明确说明“请从‘二、方法细节’部分提取方法信息”，这样就能准确定位到需要的内容。

如果某个节点的输出格式不稳定，可以在提示词里加一句“请严格按照以下格式输出，不要添加额外的标题或说明”。我试过在 Gemini 节点的提示词里加这句话，绘图代码的格式一致性明显提升。

注意：Coze 的工作流有执行时间限制，如果论文特别长或者推理步骤特别多，可能会超时。我的做法是把长论文拆成几个部分分别处理，或者把工作流拆成两个：一个负责“文献到方案”，一个负责“方案到绘图”。

6. 常见问题与排查技巧实录

6.1 模型输出格式不稳定的排查思路

这是最常见的问题。你明明在提示词里写了“请用表格输出”，结果模型给你来了一段散文。排查思路如下：

第一，检查提示词是否有歧义。“请用表格输出”这句话本身没有说明表格的列名和行名，模型只能自己猜。改成“请用 Markdown 表格输出，表头为：方法名称、核心思想、优点、缺点”就明确多了。

第二，检查是否有格式示例。如果提示词里能给出一个输出示例，模型模仿的准确率会大幅提升。比如在提示词末尾加一句“输出格式参考：| 方法名称 | 核心思想 | 优点 | 缺点 |”。

第三，检查温度参数。温度太高会导致输出随机性增加，格式不稳定的概率也会上升。把温度调到 0.2 以下，格式一致性会明显改善。

第四，检查输入内容是否过长。如果输入内容超过了模型的上下文窗口，它可能会截断或者压缩输出，导致格式丢失。这种情况下需要分段处理。

6.2 推理链断裂的修复方法

推理链断裂的表现是：模型在某个步骤突然跳到结论，中间缺少必要的推导。修复方法如下：

方法一：强制分步。在提示词里明确要求“每一步只做一件事，完成后再进行下一步”。比如“第一步：列出所有已知条件。第二步：根据已知条件推导第一个中间结论。第三步：基于第一个中间结论推导第二个中间结论。”这样模型就不容易跳步。

方法二：要求自我检查。在推理完成后，加一句“请检查上述推理链，找出其中逻辑不连贯的地方，并补充缺失的步骤。”模型在自我检查时，往往能发现之前忽略的跳跃。

方法三：用反例验证。让模型针对每个中间结论构造一个反例，如果反例成立，说明该结论的适用范围需要修正。这个方法比较耗时，但对于关键推理任务非常值得。

6.3 绘图代码运行报错的常见原因

Gemini 生成的绘图代码有时候在本地运行会报错，常见原因和解决方法如下：

实操心得：我一般会在提示词里加一句“请确保代码在 Python 3.9 及以上版本、matplotlib 3.5 及以上版本中可以直接运行”。这样 Gemini 生成的代码兼容性会好很多。

6.4 多模型协作中的上下文丢失问题

在工作流中，如果节点之间的变量传递格式不对，下一个模型可能会丢失上下文。比如 DeepSeek 输出的精读笔记里用了“方法细节”这个标题，但 GPT 的提示词里写的是“请从‘方法’部分提取信息”，模型就找不到对应的内容。

解决方法是在工作流设计阶段就统一术语。我的做法是：所有节点的提示词都使用同一套标题体系，比如统一用“一、研究背景”“二、方法细节”“三、实验设置”“四、结论与局限性”“五、关键术语”。这样无论哪个模型接收输入，都能准确找到需要的内容。

另外，如果工作流中某个节点的输出特别长，可以在传递给下一个节点之前做一个摘要。比如 DeepSeek 输出的精读笔记可能有三千字，但 GPT 只需要其中的方法细节部分，可以在 Coze 里加一个“文本提取”节点，只提取“二、方法细节”下面的内容。

7. 我个人的使用节奏与工具组合建议

7.1 日常任务中的模型切换时机

我每天的工作大致分为三个时段：上午读文献和整理笔记，下午写代码和做实验，晚上整理结果和准备汇报材料。对应的模型使用节奏是：上午用 DeepSeek，下午用 GPT，晚上用 Gemini。这个节奏不是刻意安排的，而是任务性质自然决定的。

上午读文献的时候，我需要的是准确理解和结构化提取，DeepSeek 的中文理解能力和长上下文窗口最合适。下午写代码的时候，我需要的是严谨推理和可运行代码，GPT 的推理链和代码生成能力最稳。晚上画图的时候，我需要的是视觉表达和多模态处理，Gemini 的绘图代码生成和图像理解能力最强。

当然，这个节奏不是固定的。如果下午的实验需要读一篇新论文，我也会临时切换到 DeepSeek。关键是根据任务的主要矛盾来选择模型，而不是根据时间或习惯。

7.2 什么情况下应该换模型而不是死磕提示词

这是一个很实际的问题。我的经验是：如果同一个提示词换了三种写法，模型仍然无法给出满意结果，那就该换模型了。比如你让 GPT 读一篇中文文献并提取方法细节，试了三次都觉得提取不完整，那就直接换 DeepSeek。不同模型在训练数据和微调策略上的差异，不是靠提示词能完全弥补的。

反过来，如果某个模型在某个任务上表现很好，也不要轻易换。比如 DeepSeek 读中文文献很稳，那就固定用它，不要因为听说另一个模型出了新版本就换过去。稳定比新鲜更重要。

7.3 给新手的入门建议：从单点突破到工作流

如果你刚开始接触这三个模型，我的建议是不要一上来就搭工作流。先从一个单点任务开始，比如用 DeepSeek 读一篇你熟悉的论文，看看它的精读笔记是否符合你的预期。如果符合，再尝试用 GPT 基于这篇笔记设计一个改进方案。如果也符合，再尝试用 Gemini 把方案画成流程图。

这个“单点突破-逐步串联”的路径，比一上来就搭复杂工作流要稳妥得多。因为你在每个单点上都建立了对模型能力的信任，串联的时候才知道哪些环节可以放心交给模型，哪些环节需要人工检查。

最后分享一个小技巧：我习惯在每个模型的提示词开头加一句“你是一位[领域]的资深研究者，擅长[具体技能]”。这句话看起来简单，但能明显提升模型输出的专业度和针对性。比如“你是一位计算机科学领域的资深研究者，擅长算法设计和实验分析”，GPT 在后续推理中会更多地使用专业术语和严谨的逻辑结构。