简介：围绕DeepSeek在职场的落地应用，这份PDF文档面向研发人员、产品经理、设计师及关注人机协同的学习者，重点回应模型选型、提示语设计与多场景实践之间的衔接问题。包内共1个PDF文件，大小约9.78MB，便于集中阅读和检索。内容梳理V3与R1的适用边界：V3偏重规则清晰、结果可预期的通用任务，R1更适合数理推理、代码等开放复杂任务；同时介绍基础模型、深度思考与联网搜索等模式，以及RTGO、CO-STAR提示框架的操作要点。文中还结合PPT大纲生成、图表设计、海报制作等场景，呈现智能体开发与人机协作沟通的实践视角，并引用高校团队在人机共生方向的研究与竞赛成果。已有508人学习，适合希望提升提示工程能力、理解模型边界并推动AI应用的职场读者参考。
1. 结论先给：把提示语写得更“完整”，在推理模型上反而拖后腿
很多人第一次打开 DeepSeek 的深度思考模式，会把手头最精细的那套提示语模板原样贴进去：角色、示例、思维链、格式约束一应俱全。结果输出反而不如一句大白话，甚至更绕。这个反直觉的现象，恰好是理解从提示语技巧走向智能体开发的门槛：提示语的作用不是把要求说全，而是把模型不需要自己猜的部分补齐。V3 和 R1 需要的补齐方式完全不同，AI 应用场景里的人机协同质量，很大程度上取决于你有没有分清这两件事。搞懂这层分工，能省下大量反复调模板的时间，也能判断一个所谓的智能体到底真的在自主执行，还是被一堆格式约束限制成了只会套格式的模板机器。
2. 两种模型的底层分野：V3 的“过程-结果”与 R1 的“目标-结果”
2.1 自回归补全与强化学习推理：两种模型在“想”什么
基础模型 V3 的工作机制，本质上是自回归的 next-token 预测。给定一段上下文，它输出的是下一个 token 在整个词表上的条件概率分布，然后采样、拼接、再预测。经过指令微调和对齐之后，这个分布会被“驯化”得更像人类期待的答复，但底层机制没变：你的上下文就是它唯一的条件，上下文里没写的东西，它只能用训练先验去填。这就是为什么在 V3 上，提示语里每一个未言明的维度——字数、语气、结构、受众——都会被它用“平均样本”补齐，而平均样本往往不是你要的。
推理模型 R1 的机制则多了一层。它在给出最终答案之前，会先生成一段较长的内部推理轨迹，这段轨迹在训练阶段被强化学习塑造过：凡是能推出正确答案、能通过测试用例的路径，被保留和强化；绕圈、自相矛盾、跳步的路径被抑制。换句话说，R1 的“怎么想”是它自己搜索出来的，而不是你告诉它的。这带来一个关键后果：当你用结构化提示词把步骤一二三四规定死，等于给一个已经会自己规划路线的执行者硬塞了一份固定的操作流程。轻则模型忽略你的结构、照自己的思路走；重则它把你的错误路径当成前提，一路推理到错误的结论上，而且错得很自信。
把这两者放进同一句话里对比更清楚：V3 是指令跟随者，它需要你把过程说清楚，因为它的默认行为就是接续你的文本；R1 是目标求解者，它需要你把目标说清楚，因为中间过程本来就是它的搜索空间。同一份提示语在两者身上效果相反，不是模型玄学，而是机制决定的。
底线是：一切都是在 token 空间里做条件概率的条件化。提示语工程 = 用最少的 token 把输出分布收窄到你要的那个子集。
2.2 5R 维度：为什么规范约束越强，模型越像工具
把两种模型的差异拆成五个可观测维度，比“V3 简单、R1 复杂”这种说法有用得多。这五个维度在文本生成任务上尤其明显，换个任务类型（比如多模态理解），各维度的权重会变，但判断逻辑是通用的。
| 维度 | V3 表现 | R1 表现 |
|---|---|---|
| Regulation 规范性 | 强规范约束，操作路径明确 | 弱规范约束，操作路径开放 |
| Result 结果导向 | 目标确定性高，结果可预期 | 目标开放性高，结果多样性大 |
| Route 路径灵活性 | 线性路径，流程标准化 | 网状路径，多路径探索 |
| Responsiveness 响应模式 | 被动适配，按规则执行 | 主动创新，自主决策 |
| Risk 风险特征 | 低风险，稳定可控 | 高风险，不确定性高 |
这张表真正的价值不在“谁更强”，而在风险那一栏。R1 的高不确定性不是缺陷，是它产生创新解的必要代价：搜索空间大，才可能找到你没想过的路径。但代价是同一个提示语跑三次可能给三个不同结构的结果，如果你的下游流程（比如自动解析、自动入库）依赖固定格式，这种方差就是故障源。
所以选型的判断标准应该反过来问：这个任务的产出，是“必须可预期”还是“允许有惊喜”？周报润色、格式转换、字段抽取，属于前者，V3 加严格格式约束最省事；方案设计、根因分析、多约束下的权衡取舍，属于后者，R1 的方差恰恰是价值所在。很多人踩的坑是拿 R1 做字段抽取，然后抱怨“输出格式每次都不一样”——这不是模型的问题，是任务和模型错配。
再看第三种模式：联网搜索，机制上是 RAG，把检索到的片段拼进上下文再生成。它的知识新鲜度来自检索而不是参数，所以能绕开训练截止时间的限制。但它引入了新的不确定性来源：检索质量。检索词是你原始问句的时候，召回往往很差；而检索片段一旦被拼进上下文，模型倾向于“既然给了就用”，哪怕这段内容和问题只是表面相关。RAG 的正确用法会在第 5 章展开，这里先记住一点：RAG 把“模型不知道”的问题，换成了“检索没找对”的问题，问题没消失，只是转移了。
最后是部署形态带来的能力差异。全量模型和蒸馏小模型不是同一件事的两种包装：前者参数量大，复杂推理的稳定性明显更好；后者体积小、响应快、成本低，适合高频轻任务。同一份提示语在两者上的表现差异，很多时候不是提示语写错了，而是模型容量撑不住那么多隐含约束。看到有资源提供参数可调的部署入口时，先去调温度这类采样参数，比反复改提示语更快定位问题——温度高，输出发散；温度低，输出收敛但可能重复。这是排查的第一步。
3. 提示语的编译原理：RTGO 与 CO-STAR 在收束什么
3.1 RTGO：四要素如何把模糊需求编译成可执行指令
RTGO 的四要素在 V3 上特别好用，原因是它精准对应了条件概率里四个最容易被“平均先验”填错的维度。
- Role 角色：定义模型以什么身份作答。经验丰富的数据分析师和刚入职的实习生，对同一个问题给出的答案深度、术语密度、判断口径完全不同。角色设定等价于给输出分布加一个偏移项，把它从“通用助手”推向“某个专业切面”。
- Task 任务：具体要产出什么。这里最容易写虚，“写一份活动文案”和“写一份面向 25 至 35 岁女性用户、300 字以内、带三个行动号召的小红书宣推文案”，是两种任务。
- Goal 目标：期望达成什么效果。吸引潜在客户、促成咨询、为管理层提供决策支撑——目标决定了模型在多个可选方案之间怎么取舍。没有目标，它只能选“看起来最全面”的那个。
- Objective 操作要求：字数、段落结构、用词风格、内容要点、输出格式。这是硬约束层，也是唯一适合写成清单的部分。
四者的分工其实是“谁来定义好”。Role 定义视角，Task 定义产物，Goal 定义验收标准，Objective 定义编码方式。很多人写提示语只写 Task，然后抱怨模型给的“不够专业”——专业度是 Role 和 Goal 的事，Task 管不了。
一个可直接套用的骨架，注意注释标的是每个字段真正在约束什么：
# RTGO 骨架：字段顺序不影响效果，字段完整性影响效果 role: | # 约束视角：决定术语密度与判断口径 具备多年经验的 SaaS 行业内容运营，熟悉 B 端决策链 task: | # 约束产物：动词 + 交付物 + 数量 撰写一篇产品功能上线的宣推文案 goal: | # 约束取舍：当多种写法冲突时，模型按这个标准选 让技术负责人产生"值得试用"的判断，而非单纯获取点击 objective: length: "600-800 字" # 硬约束，防止模型自由发挥长度 structure: "痛点-能力-证据-行动" # 段落骨架，减少结构随机性 tone: "克制、少形容词、多具体数字" format: "markdown，含三级小标题"写完这份骨架，可以把 Task 单独抽出来问自己一句：如果换成另一个人执行这个 Task，他能不能只靠 Goal 和 Objective 判断自己做对了没有？如果不能，说明 Goal 还太虚。
3.2 CO-STAR：六个维度收束输出空间的边界
CO-STAR 适合表达型任务——文案、报告、演讲稿这类“对不对”之外还要看“像不像”的产出。六个维度对应六个收紧方向：
| 维度 | 收紧的是什么 | 缺失时的典型症状 |
|---|---|---|
| Context 上下文 | 背景信息的边界 | 泛泛而谈，全是通用结论 |
| Objective 目标 | 取舍标准 | 面面俱到但不解决任何问题 |
| Style 风格 | 句长、修辞、结构习惯 | 一股模型腔，句式高度对称 |
| Tone 语调 | 情绪强度与正式度 | 严肃场合用活泼语气，或反之 |
| Audience 受众 | 词汇分布与解释深度 | 给专家讲基础概念，给新手堆术语 |
| Response 响应格式 | 最终编码方式 | 该给表格的地方给散文 |
风格和语调这维度最容易被忽略，也最难事后补救。因为它们在训练数据里和“模型味”强绑定：不加约束，模型会默认输出那种句式整齐、每段三句、爱用排比的文本。Style 约束的作用就是把这个默认分布强行掰开，比如要求“句子长短交错，允许出现不完整句”“避免使用首先其次最后这类顺序词”。这类约束写得越具体，效果差异越明显，写“语言自然”基本等于没写。
受众维度则直接决定解释深度。同一个技术概念，写给决策者和写给实现者的两版文本，术语密度、是否展开实现细节、是否给类比，全都不同。把受众写清楚，等于替模型做完了“这个信息对方知不知道”的判断。
实践里 RTGO 和 CO-STAR 并不是二选一。常见做法是 RTGO 管骨架和验收，CO-STAR 管语气呈现：Task 和 Objective 决定产物长什么样，Style、Tone、Audience 决定它读起来像谁写的。两者叠加，提示语会变长，但在 V3 上这个长度是划算的，因为每一个字都在收窄分布。
3.3 减配清单：R1 上那五个“不需要”背后的机制
到了 R1，前面那套做加法的思路要整体反过来。五个“不需要”不是经验口诀，每一个都能从机制上解释清楚：
不需要角色设定。R1 在推理轨迹里本来就会自建问题求解框架。你再给它一个人格，它会在推理时额外做一次“这个角色会怎么想”的模拟，这段模拟消耗 token，而且可能引入与正确答案无关的立场偏差。角色设定在 V3 上是偏移项，在 R1 上更像噪声项。
不需要思维链提示。“让我们一步步思考”这类话术在早期模型上是有效的，因为它把模型引导到分步输出的模式上。R1 已经在分步了，你再要求一遍，属于重复劳动，还会让它在轨迹里浪费一段篇幅复述你的要求。
不需要结构化提示词。步骤一二三四会限制它的搜索空间。R1 的价值恰恰在于它可能走出你没想到的第四种路径，你规定死三步，它就只能在三步里找解，找到的是局部最优。
不需要给示例。示例对 R1 的副作用比对 V3 大得多：它倾向于模仿示例的解法结构，而不是针对当前问题找全局最优解。给一个不够好的示例，等于把上限锁死。
不需要做太多解释。冗长的背景说明在 R1 上容易被当成约束条件全部纳入推理，导致它在无关维度上反复权衡，输出变慢且变啰嗦。背景该给还是要给，但给事实，别给铺垫。
这里有一条清晰的分界线，值得单独记住：约束路径会伤害 R1，约束产物不会。要求“输出一个 Markdown 表格，三列，列名固定”完全不干扰它的推理过程，它只是在最终编码阶段遵守格式。要求“先分析市场，再分析竞品，最后给结论”就干扰了，因为你替它决定了求解顺序。判断标准很简单：这句话是在描述“怎么想”，还是在描述“最后长什么样”。前者删掉，后者保留。
这也解释了为什么 R1 的提示语风格是“目标清晰、结果可以模糊”。目标清晰指的是验收标准必须明确——什么算做对了，什么情况下算失败，边界在哪。结果可以模糊指的是不要预设产出的具体形态和推导路径，让它自己找。这两句话听起来矛盾，其实是把约束放在了不同的层：约束目标函数，放开搜索空间。
4. 智能体化：CAP 框架把提示词从一次性指令变成常驻契约
4.1 核心层与能力矩阵：身份定义要写成可执行契约
从 Chatbot 到 Reasoner 再到 Agent，能力跃迁的关键不在“更会说话”，而在状态与行动。Chatbot 基本无状态，一轮一问；Reasoner 多了一层内部推演，但仍然是一次性输出；Agent 则要维护跨轮状态、调用外部工具、根据观察结果调整下一步。到了更高一层，系统要能独立管理子任务、对目标本身提出修正，这时候提示语的角色彻底变了——它不再是“这一次请求什么”，而是“你在什么范围内、以什么权限、按什么流程长期工作”。
这个转变的技术含义是：一次性提示语是请求，智能体提示语是接口约定。请求只需要覆盖当前这一种情况，接口约定要覆盖未来可能遇到的所有输入，包括异常输入。所以智能体的提示框架必须是分层的，不同层承担不同职责，改一层不影响另一层。
核心层是身份定义，包含角色属性、专业背景、交互特征三件套。前两个好理解，第三个最常被漏掉。交互特征指的是这个智能体遇到不确定信息时是主动追问还是自行假设，遇到超范围请求是拒绝还是转交，输出是先给结论还是先给推导。不写这一层，智能体会用模型的默认习惯——通常是“自行假设并给出完整答案”，这恰恰是很多自动化流程出错的起点。
功能执行层是能力矩阵，包含技能、功能范围、专业技能、决策权限。决策权限这一项在原型阶段经常被忽略，上线后就成了事故来源：这个智能体能不能直接修改数据？能不能对外发送消息？能不能在信息不足时自行补充？把权限写进提示语不是为了限制模型，而是为了让整个系统在越界时有明确的拒绝行为，而不是靠调用方事后校验。
4.2 边界系统与工作引擎：长流程靠什么不跑偏
约束层是边界系统：伦理规范、安全限制、资源约束、输出格式。前三项里，资源约束最容易被当成软要求，实际上它在长流程里是硬需求。没有 token 预算、调用次数、重试上限这类约束，智能体在遇到无法收敛的子任务时会无限展开，表现为“越跑越长、越跑越偏”。给出上限，等于给它一个“到这里就该收手并汇报”的出口。
操作层是工作引擎：输入处理、执行流程、输出规范。这三项的分工值得细看。
输入处理定义的是“收到不完整输入时怎么办”。好的写法是列出必填字段清单，缺哪个问哪个，而不是笼统写“必要时向用户确认”——模型对“必要时”的判断极不稳定。
执行流程可以写步骤，但要留弹性。智能体的流程描述和 R1 的思维链提示不是一回事：后者是让模型在推理时按顺序想，前者是让系统在多个轮次之间按顺序做。流程可以规定“先产出资料摘要，再产出大纲，最后产出流程图”，因为这是三个独立的交付物，有明确的先后依赖；但不能规定“第一段先写行业背景，第二段写竞争格局”，那是推理路径。
输出规范是三层里最容易被低估的。它其实是下游系统的解析接口。多个产物混在一次输出里，解析器就要靠正则去猜边界，猜错就整条链路失败。所以“三者不要混杂到一起”这种要求不是洁癖，是工程约束：每种产物单独成块，块之间有明确分隔标记，下游才能稳定切分。
四层合起来的关系可以这样理解：
| 层级 | 对应字段 | 回答的问题 | 改动频率 |
|---|---|---|---|
| 核心层 | 身份定义 | 你是谁，从什么视角看问题 | 低 |
| 功能执行层 | 能力矩阵 | 你能做什么，做到什么程度，有多大权限 | 中 |
| 约束层 | 边界系统 | 什么不能做，资源上限在哪 | 低 |
| 操作层 | 工作引擎 | 收到输入后按什么顺序产出什么 | 高 |
改动频率这一列是设计取舍的直接体现：身份和能力是长期契约，一改就要重新验证全部行为；流程和输出格式随业务变化频繁调整，所以必须和上层解耦。把四层混成一段自然语言，改一个格式要动全文，这就是很多智能体配置越改越乱的原因。
4.3 字段级拆解：一个 PPT 大纲智能体的完整配置
以“根据主题生成 PPT 大纲”这个任务为例，能看清四层怎么落到具体字段。这个任务有三个交付物：资料摘要表、Markdown 大纲、关键页流程图，且三者顺序固定。
# 核心层：身份定义 identity: role: "演示文稿结构设计助手" background: "熟悉行业研究方法与咨询报告的结构惯例" interaction: "主题信息不足时先列出缺失项并追问，不自行假设行业" # 功能执行层：能力矩阵 capability: skills: - "检索并归纳公开报告的核心结论，整理为表格" - "按层级拆分大纲：章节标题 / 页面标题 / 内容要点" - "将关键页面的逻辑关系转写为流程图源码" scope: "仅输出大纲与结构化文本，不生成图片、不排版" authority: "可自行决定章节划分，不可自行增删用户给定的必讲要点" # 约束层：边界系统 boundary: quality: "内容完整，避免空泛表述；数据须标注来源，无法核实的结论标注为推断" resource: "资料摘要不少于 5 份；大纲不少于 30 页；单次输出不超过上下文预算的 70%" format: "三种产物分块输出，块间用分隔线隔开，不混写" # 操作层：工作引擎 engine: input_check: "主题、受众、时长、必讲要点，四项缺一即追问" flow: - "先输出资料摘要表格" - "再输出 Markdown 大纲" - "最后输出关键页流程图源码" output_spec: summary_table: "列：报告主题 / 关键摘要 / 来源" outline: "三级结构：章节 / 页面标题 / 要点" diagram: "纯文本流程图语法，节点名用中文，边标注条件"这份配置里有几个字段值得单独说。input_check把“追问”从一种模糊的礼貌行为变成了确定的触发条件，四项缺一即问，不多问也不少问。authority里那句“可自行决定章节划分，不可自行增删必讲要点”，是在划分决策权的边界：结构层面放权，内容层面收权，这正是智能体该有的权限粒度。resource里的页数和份数下限，看起来是内容要求，实际是防止模型给出一个“看起来很完整但只有八页”的敷衍产物。
流程图那个交付物，输出的是纯文本语法而不是图片，这一点很关键：
graph TD A[问题背景] --> B{现有方案是否满足} B -->|满足| C[维持现状并优化细节] B -->|不满足| D[引入新机制] D --> E[评估改造成本] E -->|可接受| F[分阶段落地] E -->|不可接受| G[退回方案选型]这种文本语法可以被下游工具直接渲染成图，模型不需要理解渲染过程，只需要保证语法正确、节点语义清晰。要求里写“节点名用中文、边标注条件”，是因为不加这两条约束，模型容易生成一堆A1、B2这种无语义节点名，图渲染出来没人看得懂。这是典型的“约束产物不约束路径”：格式管住了，怎么设计图的逻辑关系仍然由模型自己判断。
5. 避坑与排查：五条从提示语到智能体的踩坑记录
5.1 提示语阶段的三次输出不符合预期
第一条：在推理模型上贴完整模板，输出反而不如一句话。
现象很典型：把 RTGO 四要素、角色设定、示例、分步要求全部堆上去，跑出来的答案结构工整但内容空洞，还特别长。原因是路径约束和推理搜索打架——模型把你的分步要求当成了既定解法，不再自己探索，于是它在“按你说的做完”和“找到正确答案”之间选了前者。解决方式是做减法：只留目标、验收标准、产物格式三项，其余删掉。删完再跑一次，如果答案质量明显提升，说明之前的模板确实在拖后腿；如果没变化，说明这个任务本来就不需要推理模型。
第二条：V3 输出格式每次都不一样，下游解析经常失败。
现象是同一份提示语跑十次，八次格式对、两次格式错，错的那两次字段顺序变了或者多了段说明文字。原因几乎总是格式约束写在了自然语言段落里，比如“请用表格输出，包含主题、摘要、来源三列”，模型有时会把这句话当成建议而不是硬要求。解决方式是把格式单独成块，给出最小可解析样例，并在约束里明确“只输出该结构，不加任何前后说明”。格式约束是接口，接口就要写成接口的样子，混在散文里必然不稳定。
第三条：开了联网搜索之后，答案引用了不相关或过时的来源。
现象是回答里带了引用，但点开发现内容和问题只是表面相关。原因有两层：检索词直接用原始问句时召回质量差；检索片段被拼进上下文后，模型倾向于“既然给了就用”，缺少“该不该用”的判断。解决方式分两步，先让模型把问句改写成检索式（关键词化、去掉口语成分），再在约束里明确规定“仅当检索片段与问题直接相关时引用，并标注来源；无相关片段时明确说明未检索到”。后一条约束的作用是给它一个“不用”的许可，没有这个许可，它几乎一定会硬用。
5.2 智能体编排阶段的两次隐性故障
第四条：智能体在第一步就自问自答，跳过了本该追问的环节。
现象是用户只给了一个主题，智能体自己假设了受众、时长、行业，然后一路做完。看输出很完整，但方向全错。原因是身份定义里只写了角色和专业背景，没写交互特征，边界系统里也没有“信息不足时的处理策略”。模型的默认习惯是补全而非追问，不显式禁止，它就会补全。解决方式是在工作引擎里加一个缺失字段清单，列出必填项，缺一即问，并明确“追问时只列缺失项，不做任何内容生成”。这条约束要写得足够硬，否则模型会一边追问一边顺手把内容也生成了。
第五条：长流程跑到中途开始偏离，输出越来越长、越来越绕。
现象是前两步还正常，从第三步开始答案里出现了大量重复表述，原定的格式约束也逐渐失效。原因是上下文里塞进了模型自己前几轮的长输出，早期的系统约束在长上下文里的相对权重被稀释了——这不是玄学，是注意力被自身产出占据后的必然结果。解决方式是在每一步结束时产出一段简短的进度摘要（当前完成什么、下一步做什么、有哪些硬约束），下一步的输入用摘要加新任务，而不是完整的历史输出。摘要的作用是把约束重新提到上下文的前部，等于每一步都重新加载一次合约。
注意：这五条里，第一、三、五条属于“约束错了层”，第二、四条属于“该约束的没约束”。排查时先判断属于哪一类，再决定是删约束还是加约束，比盲目改提示语快得多。
6. 设计取舍：什么时候该“说清楚”，什么时候该“留白”
整套方法论的骨架，其实就一条分界线：约束产物，放开路径。所有具体技巧都是这条线的推论。
V3 上可以把路径也适度约束，因为它的机制就是跟随指令，你给的过程越清晰，它填错的维度越少；R1 上必须放开路径，因为搜索空间就是它的能力来源，收窄了就等于把它降级成一个昂贵的指令跟随模型。智能体层面同理，流程可以规定交付物的先后顺序（产物依赖），不能规定思考的先后顺序（推理路径）。
落到实际决策上，可以按这个顺序判断：
| 判断项 | 倾向 V3 | 倾向 R1 |
|---|---|---|
| 产出是否必须可预期 | 是 | 否 |
| 是否存在唯一正确答案 | 是 | 否，需要权衡 |
| 下游是否依赖固定格式解析 | 是 | 否，人工复核 |
| 失败代价 | 可重跑 | 需人工兜底 |
| 提示语策略 | RTGO 全字段 + 格式样例 | 目标 + 验收标准 + 产物格式 |
这张表里最容易被忽略的是“失败代价”那一行。很多人选型只看效果上限，不看错误成本。字段抽取这类任务，错一条数据可能要人工回溯几十条；方案分析这类任务，答案不好但能人工筛，重跑一次的成本远低于选错模型带来的格式维护成本。
验证方法也可以很朴素：同一份提示语，同一任务，连跑三次看输出方差。方差大，要么是模型选错了（该用 V3 的场景用了 R1），要么是约束不足（格式、验收标准没写死）。方差小但质量差，那是约束写错了方向，对着 Goal 字段重写一遍比逐句微调有效。这个三次采样法我现在基本是条件反射，比读十篇提示语技巧都管用。
还有一个取舍值得说透：结构化提示词在很多教程里被奉为标准答案，但它有明确的适用边界。它解决的是“模型不知道你要什么”的问题，代价是把模型的能力上限锁在你写的那套结构里。当你对任务本身还不够了解、不知道好答案长什么样的时候，写死的结构反而会误导——你以为你在提要求，其实你在暴露自己没想清楚。这种时候正确的做法是先放开让它跑几次，看它给出的路径里哪些是你没想到的，再把其中稳定的部分固化成约束。先探索后约束，顺序反了就会得到一堆格式完美但内容平庸的产出。
从那以后我每次配一个新智能体，都强制走一遍“先裸跑三次、再固化约束、再跑三次对比”的流程，绝不跳过裸跑那一步。跳过的人通常会花更多时间在改模板上，因为压根不知道原始的分布长什么样，调参全靠猜。希望帮到你。
本文还有配套的精品资源，点击获取
