1. 从一个看似“反直觉”的设计说起第一次看到 Breatic 团队这个设计的时候我的反应和大多数人一样一个视频节点为什么要为每种模式单独保存一套提示词直接把提示词写死在节点里或者用一个全局变量统一管理不是更省事吗但真正动手做过 Agent 驱动的视频生成流水线之后我才意识到这个设计背后藏着不少工程上的必然性。Breatic 是一个面向团队协作的实时内容生成平台核心工作单元是“视频节点”——你可以把它理解成流水线上的一个工位每个工位负责把上游的素材、指令、参数加工成下游能用的视频片段或中间产物。而“模式”指的是这个节点当前所处的运行状态或任务类型比如草稿模式、精修模式、批量模式、审核模式等等。提示词则是驱动底层 AI 模型产出内容的关键输入。问题就出在这里同一个视频节点在不同模式下需要的提示词往往完全不同。草稿模式要的是快速、粗糙、方向性的描述精修模式要的是细节丰富、风格锁定、参数明确的指令批量模式要的是可复用、可参数化、容错率高的模板审核模式要的是判断标准、合规边界、质量阈值的说明。如果你用同一套提示词硬扛所有模式结果就是要么草稿太慢要么精修太糙要么批量崩掉要么审核漏判。所以这篇文章我想从实际工程的角度把“为什么一个视频节点要为每种模式保存不同提示词”这件事拆开讲清楚。不管你是正在做 AI Agent 开发、提示词工程还是单纯对多模式系统的设计感兴趣这篇实录应该都能给你一些可以直接抄作业的思路。2. 核心设计思路模式即上下文提示词即接口2.1 为什么不能共用一套提示词先讲一个我踩过的坑。早期做类似系统的时候我图省事给一个视频节点只配了一套“万能提示词”想着靠模型自己理解当前该干什么。结果在实际跑的时候问题一个接一个冒出来。最典型的是语义漂移。草稿模式下模型倾向于快速给出一个模糊的方向这本来没问题。但当同一个节点切换到精修模式时模型仍然带着草稿模式的“惯性”输出的内容依然偏概括细节怎么都压不出来。你可能会说那我在提示词里加一句“现在是精修模式请输出详细内容”不就行了实测下来这种“模式声明”式的提示词在复杂任务上几乎不起作用。模型对模式的理解和人类对模式的理解完全不是一回事。第二个问题是参数冲突。草稿模式通常要求低延迟、高吞吐提示词里会强调“快速生成”“不需要细节”精修模式要求高质量、高一致性提示词里会强调“逐帧检查”“风格统一”。这两套要求放在同一个提示词里模型会陷入一种“既要快又要好”的矛盾状态最终输出一个四不像。第三个问题是可维护性灾难。当你的系统支持五种、十种模式时一套提示词里会堆满条件分支“如果是A模式则……如果是B模式则……”。这种提示词写出来人类读着都费劲更别说让模型准确执行了。每次新增一个模式都要在原有提示词里小心翼翼地插入新逻辑改错一个标点都可能导致整个流水线崩掉。所以结论很明确模式不是提示词里的一个变量模式是提示词本身的组织维度。一个视频节点要为每种模式保存不同提示词本质上是因为每种模式代表了一套独立的上下文、一套独立的约束条件、一套独立的成功标准。2.2 模式与提示词的映射关系设计那具体怎么组织Breatic 团队的做法是给每个视频节点维护一个“模式-提示词映射表”。这个表的结构大致是这样的模式标识提示词版本核心目标关键约束典型输出长度draftv3.2快速探索方向低延迟、允许模糊50-150字refinev5.1细节精修风格锁定、参数明确300-800字batchv2.8批量复用可参数化、容错高100-300字reviewv4.0质量审核合规边界、阈值判断80-200字fallbackv1.5异常兜底保守输出、不崩溃30-80字这张表看起来简单但每一列都有讲究。模式标识是节点状态机里的枚举值切换模式就是切换状态。提示词版本让每次修改都可追溯出问题能快速回滚。核心目标决定了提示词的整体语气和优先级。关键约束是硬性边界比如精修模式必须锁定风格那提示词里就要有明确的风格锚点。典型输出长度是一个经验值用来做输出校验太短或太长都触发告警。提示这张映射表不要写死在代码里建议用配置文件或数据库管理。我试过写死在代码里后来加一个模式要改三处代码、重新部署两次效率极低。2.3 为什么是“保存”而不是“生成”有人可能会问既然模式是确定的提示词能不能在运行时动态生成比如用一个元提示词根据当前模式拼装出实际提示词。这个思路听起来很优雅但实际落地有几个硬伤。第一动态生成引入不确定性。元提示词本身也是提示词它也会受到模型状态、上下文长度、温度参数的影响。你本来想要一个稳定的精修提示词结果元提示词这次生成的和上次生成的略有不同导致输出质量波动。在团队协作场景里这种波动是致命的因为下游节点依赖上游的稳定输出。第二调试成本极高。当输出出问题时你需要排查是元提示词的问题、拼装逻辑的问题、还是最终提示词的问题。三层嵌套下来定位一个 bug 可能要花半天。而保存固定提示词出问题直接看那一套提示词就行排查路径短得多。第三版本管理困难。动态生成的提示词没有稳定的版本号你无法回答“上周三精修模式用的到底是哪套提示词”这个问题。而在团队协作里这种可追溯性是刚需。所以 Breatic 的选择是每种模式的提示词都是显式保存的、有版本号的、可独立修改的。动态生成只用在极少数场景比如根据用户输入做参数填充但提示词的主体结构是固定的。3. 核心细节解析每种模式的提示词到底差在哪3.1 草稿模式速度优先允许模糊草稿模式的核心任务是“快速试错”。团队在头脑风暴阶段需要的是大量方向性的输出而不是一个完美但慢吞吞的结果。所以草稿模式的提示词设计有几个关键点。首先是降低输出精度要求。提示词里会明确写“不需要细节”“允许概括”“优先给出方向”。这听起来简单但很多模型默认行为是“尽量详细”你不明确说它就会往精修的方向跑。其次是缩短输出长度。草稿模式的典型输出长度控制在 50 到 150 字之间。提示词里会写“用一句话概括”“不超过三个要点”。为什么要限制因为草稿阶段读太多字是负担团队需要快速扫一眼就知道这个方向行不行。第三是提高温度参数。草稿模式通常配合较高的温度值比如 0.8 到 1.0让输出更多样化。提示词里会写“给出三个不同方向的建议”配合高温度能快速铺开可能性空间。我实测下来草稿模式最忌讳的就是“既要快又要好”。你一旦在提示词里加入“确保质量”“仔细检查”这类词模型就会放慢速度草稿的意义就没了。3.2 精修模式细节锁定风格锚定精修模式和草稿模式几乎是两个极端。草稿要快、要模糊、要多样精修要慢、要精确、要一致。精修模式的提示词里风格锚点是最关键的部分。所谓风格锚点就是一组明确的参考描述比如“画面色调偏冷”“镜头运动缓慢”“旁白语气克制”。这些锚点要写得足够具体让模型没有发挥空间。我见过太多精修提示词写“保持风格一致”结果模型每次理解的“一致”都不一样。参数明确是第二个关键点。精修模式通常需要指定分辨率、帧率、时长、转场方式等硬参数。这些参数不能靠模型猜必须在提示词里写死。比如“输出 1080p、24fps、时长 15 秒、使用淡入淡出转场”。逐项检查是第三个关键点。精修提示词里会要求模型“逐帧检查”“逐段确认”确保每个细节都符合要求。这听起来很笨但在精修阶段笨办法往往最可靠。注意精修模式的提示词长度通常是草稿模式的三到五倍。不要试图压缩它压缩会导致细节丢失最终输出质量下降。3.3 批量模式参数化模板容错优先批量模式面对的是“一次生成几十上百个视频节点”的场景。这时候提示词的设计目标从“精确”变成了“稳定”和“可复用”。参数化是批量模式提示词的核心特征。提示词里会有大量占位符比如{product_name}、{scene_id}、{duration}运行时由系统填充。这样一套提示词可以覆盖大量相似但不完全相同的任务。容错设计是第二个关键点。批量模式下个别节点失败是常态不能因为一个节点出错就整个批次崩掉。所以提示词里会写“如果输入不完整使用默认值”“如果参数冲突优先保证输出可用”。这种容错逻辑在草稿和精修模式里是不需要的但在批量模式里是刚需。输出格式统一是第三个关键点。批量模式的输出要能被下游自动处理所以格式必须严格统一。提示词里会明确指定 JSON 结构、字段名、字段类型。我试过在批量模式里允许模型自由发挥格式结果下游解析器直接崩了排查了半天才发现是模型多输出了一个逗号。3.4 审核模式判断标准边界清晰审核模式比较特殊它的输出不是内容本身而是对内容的判断。所以审核模式的提示词更像是一份“检查清单”。合规边界是审核模式提示词的第一要务。哪些内容允许、哪些不允许、边界在哪里都要写得清清楚楚。模糊的边界会导致审核结果不稳定同一个内容这次通过下次不通过团队会疯掉。质量阈值是第二个关键点。比如“画面清晰度低于 X 则判定不合格”“音频信噪比低于 Y 则判定不合格”。这些阈值要具体到数字不能写“清晰度不够”这种主观描述。判断理由是第三个关键点。审核模式不能只输出“通过”或“不通过”还要输出理由。提示词里会要求“给出判断依据”“引用具体规则条款”。这样当审核结果有争议时团队可以快速定位是规则问题还是执行问题。3.5 兜底模式保守输出绝不崩溃兜底模式是最后一道防线。当其他模式都失败时系统会切到兜底模式确保至少有一个可用的输出。兜底模式的提示词极其保守。不追求质量只追求可用。提示词里会写“输出最基础的内容”“不要尝试复杂操作”“如果无法完成输出占位内容”。这种设计看起来很低级但在系统稳定性上价值巨大。我踩过的坑是早期没有兜底模式某个节点在异常状态下卡死整个流水线停了两个小时。后来加了兜底模式最坏情况也能输出一个占位内容下游节点可以继续跑团队可以事后修复。4. 实操过程从零搭建多模式提示词管理体系4.1 第一步定义模式枚举和状态机动手之前先把模式定义清楚。不要一边写提示词一边想模式那样会反复返工。我的做法是先用一个简单的状态机把模式流转关系画出来。比如草稿模式可以切到精修模式精修模式可以切到审核模式任何模式异常都可以切到兜底模式。状态机确定后模式枚举就固定了。from enum import Enum class VideoNodeMode(Enum): DRAFT draft REFINE refine BATCH batch REVIEW review FALLBACK fallback这个枚举是后续所有配置的基础。模式一旦确定就不要轻易增删因为每增一个模式就要多维护一套提示词。4.2 第二步为每种模式编写独立提示词接下来是核心工作为每种模式写提示词。我的建议是先写草稿和精修再写批量最后写审核和兜底。因为草稿和精修是使用频率最高的先把它们打磨好后面的模式可以参考它们的结构。写提示词的时候我习惯用三段式结构角色定义 任务描述 约束条件。角色定义告诉模型“你是谁”任务描述告诉模型“做什么”约束条件告诉模型“不能做什么”。以精修模式为例[角色] 你是一名资深视频精修师擅长在既定风格框架内完成细节打磨。 [任务] 根据上游提供的草稿内容和风格锚点输出精修后的视频描述。 风格锚点{style_anchors} 草稿内容{draft_content} [约束] 1. 必须严格遵循风格锚点不得引入新风格元素。 2. 输出长度控制在 300-800 字。 3. 必须包含分辨率、帧率、时长、转场方式四项参数。 4. 逐段检查确保每段都符合风格锚点。这个结构清晰、可维护新增模式时直接套模板就行。4.3 第三步建立提示词版本管理提示词不是写完就完了它会不断迭代。所以版本管理必须从第一天就做。我的做法是用一个简单的目录结构prompts/ draft/ v1.0.txt v1.1.txt v3.2.txt refine/ v2.0.txt v5.1.txt batch/ v1.0.txt v2.8.txt review/ v4.0.txt fallback/ v1.5.txt每个版本文件独立保存不覆盖旧版本。然后在配置表里指定当前使用的版本。这样出问题时可以快速回滚也可以对比不同版本的输出差异。提示版本号不要用日期用语义化版本。日期版本看起来直观但无法表达“这次改动是大改还是小改”。4.4 第四步模式切换与提示词加载模式切换的逻辑要足够简单简单到不会出错。我的实现是一个字典查找PROMPT_MAP { VideoNodeMode.DRAFT: prompts/draft/v3.2.txt, VideoNodeMode.REFINE: prompts/refine/v5.1.txt, VideoNodeMode.BATCH: prompts/batch/v2.8.txt, VideoNodeMode.REVIEW: prompts/review/v4.0.txt, VideoNodeMode.FALLBACK: prompts/fallback/v1.5.txt, } def load_prompt(mode: VideoNodeMode) - str: path PROMPT_MAP.get(mode) if not path: path PROMPT_MAP[VideoNodeMode.FALLBACK] with open(path, r, encodingutf-8) as f: return f.read()这段代码看起来平淡无奇但它的价值在于确定性。给定一个模式永远加载同一套提示词不会因为运行时状态不同而加载不同的东西。4.5 第五步输出校验与反馈闭环提示词加载之后还要对输出做校验。每种模式的输出特征不同校验规则也不同。模式校验项阈值失败处理draft输出长度50-150字截断或重试refine参数完整性四项参数齐全重试一次仍失败切兜底batch格式合法性JSON可解析记录日志跳过该节点review判断理由非空重试一次fallback非空长度大于0告警校验失败的处理策略也要按模式区分。草稿模式可以宽松一点精修模式要严格批量模式要能跳过审核模式要能重试兜底模式要告警。这个闭环跑通之后整个系统的稳定性会提升一个档次。因为你知道每种模式在什么情况下会失败失败之后会发生什么而不是两眼一抹黑。5. 常见问题与排查技巧实录5.1 模式切换后输出风格突变这是最常见的问题。原因通常是提示词加载了错误的版本或者模式切换时没有清空上下文。排查步骤先确认当前模式对应的提示词版本是否正确再检查上下文是否被正确重置。我遇到过一种情况模式从草稿切到精修但草稿模式的上下文还留在对话历史里导致模型仍然带着草稿的“惯性”输出。解决方法模式切换时强制清空上下文或者在新提示词开头加一句“忽略之前的对话历史”。5.2 批量模式下个别节点输出格式错误批量模式最怕的就是格式不统一。我遇到过的典型情况是模型在某个节点多输出了一个换行符导致下游 JSON 解析失败。排查技巧在批量模式提示词里加一句“输出必须是单行 JSON不得包含换行符”。同时在代码里做预处理把多余换行符去掉。注意批量模式的容错逻辑要写在提示词里也要写在代码里。双保险不能只靠一边。5.3 精修模式输出长度不稳定精修模式要求输出 300 到 800 字但实际输出有时候 200 字有时候 1000 字。原因是提示词里的长度约束不够强硬。解决方法把长度约束从“建议”改成“硬性要求”并在提示词里给出正反例。比如“输出 300-800 字。少于 300 字视为不合格多于 800 字视为不合格。”同时配合代码层面的截断和重试。5.4 审核模式判断结果不一致同一个内容两次审核结果不同。这通常是提示词里的判断标准不够具体。排查方法把审核提示词里的每一条标准拿出来逐条检查是否有模糊表述。比如“画面质量差”就是模糊的“画面分辨率低于 720p”就是具体的。把所有模糊表述替换成具体阈值。5.5 兜底模式被频繁触发兜底模式频繁触发说明上游模式失败率太高。这时候不要急着优化兜底模式要回头查上游模式的问题。常见原因提示词版本不匹配、参数缺失、上下文超长、模型服务不稳定。逐个排查找到根因。5.6 常见问题速查表问题现象可能原因排查方向解决动作输出风格突变提示词版本错误检查 PROMPT_MAP修正版本映射格式不统一提示词约束不足检查格式约束条款增加硬性格式要求长度不稳定长度约束太软检查长度描述改为硬性范围正反例判断不一致标准模糊逐条审查标准替换为具体阈值兜底频繁触发上游失败率高统计各模式失败率定位并修复上游问题切换模式后卡死上下文未清空检查上下文管理强制清空或忽略历史6. 一些实操心得和扩展思路6.1 提示词不要追求“万能”我见过太多团队试图写一套“万能提示词”结果就是哪哪都不好用。提示词工程里有一个反直觉的结论越通用的提示词实际效果越差。因为通用意味着模糊模糊意味着模型需要猜猜就意味着不稳定。Breatic 这个设计给我的最大启发就是把通用性放在模式层面把具体性放在提示词层面。模式负责分类提示词负责执行。分类越清晰执行越稳定。6.2 模式数量要克制虽然每种模式独立保存提示词有很多好处但模式数量不能无限扩张。每增加一个模式就多一套提示词要维护、多一套校验规则要写、多一套测试用例要跑。我的经验是核心模式控制在 5 到 7 个。超过这个数量就要考虑合并或者用参数化来替代。比如“精修-冷色调”和“精修-暖色调”不需要两个模式一个精修模式加一个色调参数就够了。6.3 提示词评审要成为流程提示词修改不能一个人说了算。我们团队的做法是任何提示词修改都要经过至少两人评审评审通过才能合并。评审的重点是修改是否影响其他模式、是否引入新的模糊表述、是否有回滚方案。这个流程看起来麻烦但能避免很多低级错误。我见过一次因为改了一个标点导致批量模式全部输出格式错误的事故如果有评审流程这个问题在合并前就能发现。6.4 后续可以这样扩展这套多模式提示词管理体系后续可以往几个方向扩展。一是自动化测试为每种模式建立基准测试集每次修改提示词后自动跑一遍对比输出差异。二是A/B 测试同一模式下并行跑两套提示词用数据决定哪套更好。三是提示词继承让精修模式继承草稿模式的部分配置减少重复维护。不过这些都是后话先把基础的多模式独立提示词跑通比什么都重要。我在实际项目里的体会是先把确定性做足再谈优化。确定性不够的时候任何优化都是空中楼阁。