Jev 是个怪东西。它不是用来聊天的也不是用来写文章、写代码注释、写周报的。它最大的特点是不写文本只做决策。你丢给它一段上下文它返回的不是一段通顺的话而是一个结构化的选择结果——一个枚举值、一个 JSON 对象、一个动作指令。我第一次接触这类“类型化决策”模型引擎的时候第一反应是那提示词工程岂不是没用了后来踩了半个月的坑才明白恰恰相反——当模型不写文本的时候提示词工程不仅没有简化反而变得更严苛、更靠近编程。这篇文章写给所有在做智能体编排、工具路由、结构化输出、或者想搞明白“系统提示词工程和 skill agent 到底怎么分工”的人。我会用 Jev 这个具体的决策引擎当例子把“类型化决策的提示词工程”这件事掰开揉碎讲清楚它和传统文本生成提示词差在哪、四个核心构造模块是什么、具体怎么从零到一迭代一版能用的提示词以及那些网上不会告诉你的翻车现场和排查思路。如果你手里也有一个类似的“不写文本”的模型或者你正准备把自己的应用从“让模型写一段话”改成“让模型做一个判断”这篇文章应该能帮你少走很多弯路。1. 先搞清楚“类型化决策”和“写文本”到底差在哪很多人第一次接触 Jev 这类决策型引擎时都会下意识地拿写提示词的旧经验往上套。结果就是一连串的不适配上下文写得太长决策反而变糊示例给得太多模型开始抄答案而不是做判断输出约束写得像作文要求模型直接罢工。要理解这些现象得先把底层差异掰扯清楚。1.1 输出空间从“开放字符串”变成“封闭选项集”写文本的本质是生成一个开放的字符串。同样是“今天天气怎么样”你可以写成“今天晴气温 25 度”也可以写成“晴天微风适合出门”还可以写一大段抒情散文。模型在开放空间里生成评价标准是语义相似度、信息完整性、语气是否自然——这些指标都有模糊地带差不多就行。类型化决策不一样。Jev 的输出空间从一开始就被限制死了要么是几个枚举值里的一个要么是符合 JSON Schema 的一个结构化对象要么是一个预设动作集合里的某项。没有中间地带没有“差不多”。你让模型从[{action: search}, {action: calculate}, {action: chat}]里选一个它选了search就是search选了calculate就是calculate不能含糊地给你来一句“我觉得应该搜索一下”。这个差异带来的第一个影响是评判标准从“像不像”变成了“对不对”。文本生成可以容忍一定程度的语义漂移决策输出一漂就是 bug。第二个影响是提示词里最关键的已经不是“怎么说清楚需求”而是“怎么把决策空间定义得没有歧义”。1.2 文本生成可以糊弄决策输出没办法糊弄写文本的时候模型偶尔胡诌两句你还能从上下文里猜出它的意图。比如它把“100 美元”写成了“100 元”你至少知道它想表达的是价格。但决策输出一旦错了后果是直接传导到系统层面的。拿智能体场景举例你让 Jev 决定“用户这句话应该触发哪个工具调用”。它如果选错了工具——把本该触发“日程查询”的请求路由到了“邮件发送”——那后面执行的就是一个完全错误的行为。这个错误不会停留在文本层面它会真的发一封不该发的邮件、真的删掉一条不该删的记录。类型化决策的容错率极低因为它直接连接着动作和后果。我做第一版 Jev 集成时最深的感受就是文本模型写错了你顶多改一版内容决策模型选错了你得上线回滚、道歉、补偿。这种“输出即行动”的特性决定了提示词工程的思路必须从“表达导向”转向“工程导向”。1.3 为什么这反而更难做提示词我一开始以为“不写文本”意味着提示词更简单——毕竟不用管语气、风格、篇幅只要把选项列出来就行。实际做下来发现完全反了。文本生成有很多隐形的容错机制比如用户可以自己脑补、后续处理可以修正、润色可以兜底。但类型化决策把一切模糊地带都暴露出来了。你说“如果用户的话比较紧急就选 high”什么叫“比较紧急”模型没法理解这种模糊条件它需要的是可操作、可枚举、可判定的规则。更麻烦的是文本模型的很多技巧在决策场景里会失效。比如“少样本示例”在文本生成里给三五个例子就能显著提升风格一致性但在决策提示词里示例给多了反而会让模型陷入“找最像的示例”而不是“按规则判断”的误区。再比如系统提示词里常见的“你是一个乐于助人的助手”这类人格设定在决策场景里几乎无用甚至可能干扰模型做出中立判断。所以总结下来类型化决策的提示词工程本质上不是在“教模型说话”而是在“给模型搭建一个判断框架”。后面所有的模块、技巧、踩坑经验都围绕这个核心展开。2. 类型化决策提示词的四个构造模块跟文本生成提示词讲“角色、任务、背景、示例”那套不同面向 Jev 这类决策引擎的提示词我实践下来最有效的是四个模块角色与目标、决策空间定义、上下文注入、输出约束。这四个模块缺一个决策质量都会肉眼可见地下滑。2.1 角色与目标让模型知道自己是“选择器”不是“作家”很多人忽略这一步觉得“反正它不写文本角色不重要”。这是误区。角色设定的作用不是为了让模型“扮演”某个身份而是为了锚定它的注意力方向。我有一个实验数据同一套决策规则分别用“你是 Jev 决策引擎请基于以下规则做选择”和“请读取用户输入并返回对应结果”开头后者的错误率明显更高。原因不难理解——“请读取并返回”更像一个开放请求而“你是决策引擎做选择”直接把模型拉进了“判定模式”。在实际设计时我建议在三句话以内完成角色设定不要写一堆“你是一个经验丰富的助手擅长理解用户需求”之类的废话。重点写两件事一是“你是做什么的”比如“你是智能体的意图路由模块”二是“你唯一要做的事是什么”比如“你的唯一任务是从给定的决策选项中选择一项”。明确“唯一任务”很重要因为它能抑制模型多想的冲动防止它在决策之外附带输出说明文字。2.2 决策空间定义枚举、Schema、判定条件三件套这是整个提示词的核心也是最容易做砸的部分。决策空间的定义不是简单地把选项列出来而是要包含三个层次。第一个层次是枚举把所有可能的决策结果显式列出。如果选项太多至少要把“其他”或“无法判断”作为兜底选项写进去否则模型在遇到边界情况时会自己 invent 一个选项那你后端的类型校验就会直接炸。第二个层次是Schema结构化定义如果决策结果是带参数的对象必须用 Schema 把字段名、字段类型、取值范围、是否必填都写清楚。给 Jev 这类引擎写 Schema 跟给 API 客户端写文档一样越精确越好。举个例子{action: search, query: string, limit: integer 1-50}比“返回搜索动作和关键词”靠谱一百倍。第三个层次是判定条件这是很多人忽略的。你要告诉模型“在什么条件下选什么”而不是只告诉它“有这些选项可选”。比如“当用户输入包含地点、时间、天气类关键词时选择check_weather”“当用户输入以疑问句结尾且没有明确指令动词时选择general_chat”“当以上条件均不满足时选择human_handoff”判定条件写得好不好直接决定了模型的决策准确率。我的经验是条件写得越像代码分支模型执行得越准条件写得越像作文描述模型越容易跑偏。2.3 上下文注入把“上下文工程”用起来热搜词里有“大模型提示词工程与上下文工程”这个说法放到 Jev 这类决策引擎里上下文工程的比重比提示词本身更大。道理很朴素决策需要依据依据得在上下文里给到。这里我总结了一套“三层上下文注入法”第一层是**“必要静态上下文”**比如系统当前状态、可用工具列表、业务规则常量。这些信息稳定不变可以直接拼在系统提示词里。但要注意控制篇幅——决策型模型对无效信息的敏感度比文本模型更高塞太多背景故事反而会稀释判定条件。第二层是**“动态业务上下文”**比如用户当前所在页面、会话历史摘要、最近一次操作结果。这类信息我习惯单独拼接成一个结构化的数据块放在系统提示词和用户输入之间用清晰的标签隔开比如[CURRENT_PAGE: settings]、[HISTORY_SUMMARY: 用户两次尝试修改密码失败]。第三层是**“即时输入”**也就是用户当次的原话或者结构化事件。这里有个很关键的技巧即时输入尽量原样传递不要先做一层自然语言转写。你让 Jev 直接看原始输入它做判断的依据更完整你给它一段“摘要”那模型就只能基于摘要做判断信息损耗极大。我见过很多团队把上下文工程做成了“上下文灌水工程”一次推理塞进去几万字结果决策准确率不升反降。核心原则应该是上下文不是越多越好而是越“相关”越好。什么算相关就是那些会直接影响判定条件成立与否的信息。2.4 输出约束结构化返回和类型校验最后一个模块是输出约束。Jev 这类引擎通常都强调结构化输出但你在提示词里不写清楚它还是可能给你输出一堆多余的解释。我在提示词里固定会加这么一段输出要求 你必须只输出一个 JSON 对象不要包含任何 Markdown 代码块标记、不要输出解释文字、不要输出其他内容。JSON 必须严格符合以下 Schema {...}有几个容易踩的细节值得单独说。第一“不要输出解释文字”得单独写。你以为“只输出 JSON”就够了但模型在某些意图不确定时还是会写上两句“根据您的输入我选择了...”之类的话。你后端如果用JSON.parse去解析遇到这种输出直接抛异常。第二“不要包含 Markdown 代码块标记”也必须写。很多模型默认喜欢把 JSON 包在json ...里这在文本展示场景没问题在程序化解析场景就是灾难。一句话的事不写就是坑。第三类型校验不能全指望模型。我在实际工程里始终会在提示词之外再加一道程序化校验层——拿到 Jev 的返回结果后先做 Schema 校验不合格就重试或走兜底分支。提示词负责提高概率校验层负责兜住底线两者缺一不可。3. 实操一个“不写文本”的决策提示词从零到一理论讲再多不如跑一遍。我拿一个最常见的场景来做完整演示智能体工具路由——用户说一句话Jev 决定应该调用哪个工具这个场景完美展现了“类型化决策”的特点。3.1 场景定义以智能体工具路由为例假设我们手头有一个智能体集成了三个工具search_web搜索互联网信息send_email给指定联系人发邮件check_calendar查看用户日历安排用户的输入可能千变万化“帮我搜一下最新的显卡评测”、“明天上午有空吗”、“给张三发邮件说下午开会推迟”、“我想了解下上海天气”。Jev 要做的就是根据输入判断该触发哪个工具并且把工具需要的参数提取出来以结构化 JSON 的形式返回。这个场景很有代表性因为它同时涉及分类选型和参数提取两个决策层次。第一个层次决定“做不做、做什么”第二个层次决定“怎么做、参数是什么”。3.2 第一版提示词核心结构我当时写的第一版提示词长这样简化版系统提示词 你是智能体的工具路由模块。你的唯一任务是根据用户的输入从以下工具中选择一个并返回结构化参数。 可选工具 1. search_web搜索互联网信息。参数query搜索关键词。 2. send_email发送邮件。参数recipient收件人、subject主题、body正文。 3. check_calendar查询日历。参数date日期格式YYYY-MM-DD、time_range时间段可选。 规则根据用户的指令选择最匹配的工具如果无法判断选择 none。 用户输入{user_input} 输出要求只输出 JSON 对象不要输出其他文字。这个版本能用吗能用但效果很差。我跑了 20 个测试用例大概有 30% 的决策是错的。典型错误包括用户说“明天早上到公司后提醒我跟项目经理对需求”它选了search_web而不是check_calendar用户说“问问小王周末要不要打球”它选了send_email——实际上这更像是check_calendar或general_chat还有几个 case 返回的 JSON 里多了解释字段。第一版的问题很清晰规则太粗、没有给“边界情况”定义、输出约束不够硬。3.3 第二版迭代从自由文本到强类型枚举第二版我做了一个关键改造——引入了明确的枚举和优先级排序。每次 Jev 犹豫不决一定有一部分原因来自“可能性没列全”或“并列条件的优先级不明确”。改造后的部分提示词决策类型 你必须选择一个 action可选值严格限定为以下枚举之一search_web、send_email、check_calendar、none。 决策优先级从高到低 1. 如果用户输入包含“发邮件/回复邮件/转告”等明确动作意图且包含接收人信息选 send_email。 2. 如果用户输入包含“搜索/查一下/找一下/了解一下”且指向外部信息新闻、评测、资料、价格等选 search_web。 3. 如果用户输入涉及日期/时间/日程/提醒/安排等与个人日历相关的内容选 check_calendar。 4. 如果以上均不匹配选 none。 注意优先级从上到下执行一旦满足即停止判断。这一版效果明显改善尤其是在“发邮件”和“查日历”的区分上错误率降到了 15% 左右。但我又发现了新问题模型开始过度套用优先级规则。比如用户说“提醒我明天下午三点开会”它按规则 2 判断“明天下午”不是外部信息按规则 3 判断“开会”涉及日程选了check_calendar——这个没错但参数把用户本来要表达的时间信息提取得乱七八糟。这暴露了一个更深层的问题Jev 这类模型对“已有参数”和“需要提取的参数”之间的映射关系理解得不够好。它需要看到更明确的“参数提取”指令。3.4 第三版迭代引入 few-shot 与反例第三版我做了两件事一是把参数提取的 Schema 在提示词里贴得更完整二是引入了少量经过精心挑选的 few-shot 示例并且刻意加入反例。先看参数提取这块我给 Jev 的定义变成了输出 JSON 格式 { action: search_web | send_email | check_calendar | none, parameters: { // 根据不同 action 传入不同的字段 // search_web 必须包含 query字符串 // send_email 必须包含 recipient字符串、subject字符串、body字符串 // check_calendar 必须包含 dateYYYY-MM-DD、time_range可选例如09:00-10:00 // none 时 parameters 必须为空对象 {} } }然后加入的 few-shot 示例我选了三个正例和一个反例。这个反例很关键反例示范错误决策 用户输入明天下午的会帮我推迟到下周三。 错误输出{action: send_email, parameters: {recipient: 张三, subject: 会议推迟, body: 明天下午的会推迟到下周三}} 错误原因用户没有指定收件人也没有要求“发邮件”这个动作只是在表达一个日程变更需求。这里应选择 check_calendar并提取对应日期。加上这个反例后模型对“日程操作”和“邮件发送”的边界理解提升了一大截。整体准确率从 85% 提升到了 92% 左右。但我必须说实话这个提升有代价。示例多了之后模型偶尔会“模仿示例的语气”在 JSON 里加入示例中出现过的多余字段甚至直接复刻示例中的参数值。所以 few-shot 在决策场景里要用得非常克制宁缺毋滥。3.5 校验层的兜底你不可能只靠提示词迭代到第三版提示词的边际收益已经明显递减。继续调词的性价比不如加一层校验兜底。我现在的做法是Jev 返回结果后先做JSON.parse解析失败直接重试一次校验action是否在枚举值内不在则返回none并告警校验parameters中的必填字段是否齐全缺字段的按none处理记录所有校验失败样本用于后续迭代提示词你永远不要指望提示词能覆盖 100% 的决策场景。决策型模型的价值在于把 95% 的常规情况处理好剩下 5% 的边界情况应该由工程手段去兜底而不是靠反复雕琢提示词去硬搬。这个认识是花了很大代价换来的分享出来省得大家再走一遍弯路。4. 踩坑实录类型化决策提示词的常见翻车现场这段时间跟 Jev 死磕积累了不少真实翻车案例。很多问题在文本生成场景里根本不会出现但在决策场景里却特别普遍。我挑四个最典型的展开讲讲每一个都对应具体的排查思路。4.1 决策漂移答案每次都不同所谓“决策漂移”就是同样的输入跑五次 Jev五次选了不同的 action。文本生成也有随机性但大家不敏感因为大致意思差不多就行。决策输出的随机性是致命的——同一个用户请求这次触发search_web下次触发check_calendar后端逻辑根本无法稳定复现。我遇到这个问题的第一反应是调temperature。把 Jev 采样温度降到接近 0 之后漂移确实少了很多但没有完全消失。后来查了日志才发现部分漂移来自“判定条件先后顺序不明确”——我在提示词里写了两条并列条件模型在两者之间反复横跳。解决办法就是文章前面提到的“决策优先级”写法给条件排好序让模型从上到下执行只要满足就短路。排查决策漂移时我建议按这个顺序来先看采样参数temperature 是否过高再看条件的模糊度是否有能同时命中两条规则的输入最后看上下文注入的稳定性动态上下文字段是否每次都有变化。4.2 枚举外输出模型就是不按选项来这是我在类型化决策场景中遇到频率最高的问题。明明在提示词里写了“action 可选值严格限定为 search_web、send_email、check_calendar、none”它还是有可能输出action: search或action: OPEN之类的非定义值。甚至有时候会输出一个数组把多个 action 放在一起。后来我想明白了Jev 虽然“不写文本”但它的底层仍然是语言模型语言模型天生有“生成自由文本”的惯性。你要做的不是骂它而是从两个方向约束第一把输出 Schema 定义得更死连字段名都给到确切写法第二在提示词里加一句“action 字段必须严格等于可选值之一不得扩展、不得缩写、不得翻译”。如果这还不够我实测有效的办法是在后处理阶段做一次模糊匹配。比如把模型输出的内容先根据枚举值做包含匹配search匹配到search_web再不行就归为none。提示词负责减少这种错误后处理负责兜底双保险。4.3 提示词过拟合示例越多反而越蠢前面提过一句这里详细展开。我在第三版迭代的时候给提示词加了 5 个正例准确率反而掉了 3 个百分点。现象很诡异模型开始把跟示例长得像的用户输入判成一个结果哪怕实际情况应该走另一个 action。我举个具体例子示例里有一条“给张三发邮件说下午开会推迟”Jev 看到这个之后对“给李四发消息说晚上聚餐取消”这种输入就倾向于直接复制示例的输出格式甚至把 action 定为send_email——但“发消息”可能根本不该走邮件工具。排查之后我把示例数量缩减到 1 个正例 1 个反例效果反而比 5 个正例好。这里我的经验是在类型化决策场景里正例主要用来展示“输出的形状”反例用来厘清“决策的边界”。示例量超过 3 个边际收益通常转为负。你要给模型的是判断依据不是模仿样板。4.4 上下文污染把无关信息带进决策还有一个非常隐蔽的坑普通文本生成里无关紧要的上下文在决策场景里会成为干扰信息。我试过把整个会话历史全部塞给 Jev想着“上下文越多决策越准”结果 Jev 被前面某条消息里的“邮件”字样带偏把当前输入错误地判断成了send_email。后来我优化了上下文拼接策略做了两件事一是只传最近 3-5 条会话消息更早的压缩成一句话摘要二是把当前用户输入和上下文历史用分隔符明确分开并在提示词里强调“当前输入为准历史仅作参考”。改完之后误判率明显下降。上下文污染的核心原因是类型化决策模型对“当前判断焦点”的注意力更敏感。传统文本模型可以同时参考大量上下文做衔接决策模型只关心此刻这个输入应该归到哪个选项。所以做上下文注入时要主动帮它净化焦点而不是把信息一股脑倒进去。5. 评测与迭代怎么知道提示词改得好不好提示词工程做一段时间之后你会发现自己开始“凭感觉调词”——改一个条件、加一个示例直觉上觉得应该好一点但缺乏数据支撑。这种状态特别危险因为提示词是可容错的工程没有评测体系的迭代就是在黑暗中乱撞。我自己是在吃了几次“改崩了之后才发现”的亏之后才沉淀出一套装评测方法。5.1 指标设计用“决策准确率”而不是“文本相似度”文本生成场景大家习惯用 BLEU、ROUGE 这类指标或者干脆人工看几条样本主观打分。类型化决策完全不能用这套。决策要么对要么错没有“部分相似”这一说。我给 Jev 提示词迭代用的核心指标只有一个决策准确率Decision Accuracy。计算方式是在固定测试集上跑一遍 Jev统计“正确决策数 / 总样本数”。正确决策怎么定义必须同时满足两个条件action 分类正确且 parameters 字段的关键参数提取正确。哪怕 action 选对了但参数错了这一条样本也要算失败。另外建议再加一个辅助指标兜底率。也就是出现“无法判断、走向none或重试”的样本比例。如果兜底率太高说明决策空间定义有问题如果太低了可能说明模型在强行决策容易出错。5.2 回归集积累一小组固定 case做提示词迭代最怕的就是“改好了一个旧问题带崩了三个原有的正确行为”。没有回归集的提示词工程本质上是在拆东墙补西墙。我的做法是准备了一个小型回归集规模不用大30-50 条就够但要覆盖以下类型每个 action 至少 5 条常规样本、每个 action 至少 2 条边界样本、跨 action 的混淆样本、明显应该走none的样本。每改一版提示词就在这个回归集上跑一遍对比准确率变化。如果准确率下降我会先看是哪几条样本崩了判断是偶发还是系统性偏差再决定是回调改动还是继续优化。回归集的样本也要定期更新。每次在线上收集到新的错误决策样本我会筛选后补充进回归集里。回归集不是一个静态素材它应该跟着你对业务的理解一起成长。5.3 迭代节奏小步改动、批量验证最后说说迭代节奏。很多人在调提示词时喜欢“一次改很多东西”这边加了个条件那边换了几个示例又改了输出约束。结果一跑准确率变了但根本不知道是哪一处改动引起的。我现在遵循的节奏很简单一次只改一个变量改完立刻在回归集上跑一遍。比如这一版只改“决策优先级”的顺序下一版只加一条判定条件再下一版只调整 few-shot 示例。这样做有几个好处一是能准确归因准确率变化的原因二是每个变量对效果的真实影响都能被积累下来时间长了你会形成一种“直觉数据库”知道哪些模块对准确率影响最大。还有一个经验很实用每轮迭代都要把提示词存个版本。我用最简单的办法在提示词文件头部加注释写上当前版本号、改动点、回归集准确率。这样即使改崩了也能快速回滚到上一个可用版本。别小看这个习惯它救了我太多次了。如果把所有经验浓缩成一句话我想说类型化决策的提示词工程本质上是把“教模型说话”变成“给模型写代码注释”。你写的每一行条件、每一个枚举定义、每一条示例都是在给一个“不写文本”的决策引擎描述清楚判断逻辑。尊重它的特质按决策系统的规律去做评测和迭代这套东西最后会成为你手里最可靠的自动化组件之一。我个人现在做新项目时凡是涉及路由、分类、参数提取这类任务第一反应就是让 Jev 上场——不写文本只给结论反而让整个系统干净利落得多。