Jev类型化决策：提示词工程让LLM输出结构化结果

1. 从“Jev不写文本”说起类型化决策到底在解决什么问题先说一个我踩过几次坑之后才想明白的判断在Codex环境里接Jev这类模型最大的误区就是把它当成“又一个会写文章的LLM”来用。我最早接触Jev的时候想法很自然——让它在代码任务里帮我生成设计说明、写注释、整理变更日志。结果呢输出确实流畅但根本没法直接用同一段代码昨天让它解释一下它写了两百字今天再问一次又是另一套说法而且措辞、格式、关注点全在漂移。真正让我停下来重新思考的是一个做API编排的任务——我让Jev帮忙判断“当前这个异常应该重试、降级还是直接抛出”它给我回了三段带情绪的散文里面有分析、有建议、有风险提示但程序没法消费。我只能自己再去读文本、提炼结论、写代码。那一瞬间我意识到这种用法把模型的长处和短处全部用反了。Jev这类模型真正适合做的事不是“写文本”而是“做决策”。它天然具备在给定条件下从候选集合里挑选最优解的能力而且它的上下文理解能力和约束遵循能力比通用Chat型模型更适合做结构化输出。问题在于你必须在提示词里把“决策空间”定义清楚必须让输出格式是程序能直接吃的类型化结果而不是一篇作文。这就是“Jev不写文本”这个标题背后的真实含义把Jev当作一个类型化决策引擎来用。你给它一个结构化的场景描述它返回一个结构化的决策结果——字段是什么、取值有哪些、边界条件怎么表达全部预先定义好。文本只是决策过程的中间产物真正的产出是那个可解析、可校验、可落地的决策对象。这个转变带来的收益是实打实的。拿我自己在Codex里的一个真实场景举例我需要Jev在每个Pull Request里做代码评审标签分类判断变更属于“重构”“缺陷修复”“性能优化”“功能新增”还是“风险变更”。改成类型化决策之后Jev每轮输出一个固定的JSON对象比如{label:refactor,confidence:0.92,reason:将重复的数据库连接逻辑抽取到Repository层}。程序可以直接读可以直接统计可以在CI里按标签决定是否人工复核。整条链路从“人读文本”变成了“程序消费决策”这才是模型落地的正确姿势。这篇文章我会围绕这个核心思路把类型化决策的提示词工程拆开讲清楚为什么自由文本不可控、决策空间怎么定义、提示词怎么写才能让模型稳定落在约束内、输出如何校验和容错、以及我在实际项目中踩过的那些坑。2. 自由文本的失控成本为什么“写作文式输出”在工程里走不通很多从ChatGPT时代过来的同学习惯了一种“模型输出自然语言回答”的心智模型。但在工程链路里这个心智模型是要付出真金白银的。2.1 文本输出的三个隐藏成本解析、对齐、漂移第一个成本是解析成本。模型输出的文本格式千变万化同一句话可以有十种表达方式。你要从里面提取“重试”这个动作得写正则匹配“重试”“retry”“try again”“重新发起请求”还得处理否定句——“不建议重试”“不要重试”“重试的意义不大”。这些自然语言的灵活性放到程序里全是防御式解析的噩梦。第二个成本是对齐成本。文本回答没有固定的字段结构信息密度忽高忽低。以代码评审为例模型可能输出“这里存在潜在问题”但“潜在问题”具体对应代码的哪一行、严重程度是高中低还是其他等级完全没有确定性。你为了让下游程序能理解被迫再加一层“信息抽取”模型或者干脆人工去读。对齐成本层层叠加最后发现模型省下的时间全被解析和清洗吞掉了。第三个成本是漂移成本。这也是最隐蔽的。同一个问题模型在不同温度、不同上下文长度、不同轮次下给出的表述风格会漂移。今天输出“建议使用连接池”明天变成“推荐引入连接池机制”后天是“可以考虑对连接进行池化处理”三句话语义相同但你的关键词匹配规则可能只认其中一句。一旦规则命中不了下游逻辑就静默出错——这在生产环境里比直接报错更可怕。2.2 类型化决策的本质把连续空间压缩成有限选择类型化决策的思路是把“开放性生成”变成“封闭式选择”。你在提示词里规定好决策空间、字段结构和取值枚举让模型的思维过程收敛在一个可穷举的集合里。打个比方好比你去餐厅点餐。自由文本模式是服务员问你“你想吃什么”你讲一段话描述自己的口味偏好、忌口和当天心情服务员再自己翻译成具体菜品——翻译错了你还没处说理。类型化决策模式则是服务员递给你一张菜单前菜五种选一种主食八种选一种饮料四种选一种辣度三档选一档。你只要做选择就行服务员不会发挥你也不会收到意外。这个“菜单思维”是类型化决策提示词工程的核心隐喻。模型不是一个作家而是一个决策者。你给它足够多的背景信息它在预设的枚举类型、数值范围、结构体字段里做出选择然后把结果以固定schema返回。2.3 Jev这类模型在Codex场景里的特殊适配为什么说Jev在Codex这类编程智能体环境里特别适合做类型化决策因为Codex的工作流本身就是高度结构化的——任务清单、函数调用、工具返回、错误栈全是标准的程序化输入。Jev被设计成一个能在这类结构化信息流里做判断的模型它的注意力机制对“约束性指令”和“上下文中的关键变量”更敏感更适合“在给定条件下选择一个动作”而不是“自由生成一段文本”。我在实践中一个很直观的感受是让Jev“分析一下这个报错”它输出平庸但让Jev“从A/B/C三个修复方案里选一个并输出选择依据的JSON”它的判断质量和稳定性明显更好。这不是玄学而是模型被设计出来的目的和你的用法终于对齐了。提示词工程的第一步就是认清模型“擅长什么”然后把自己的需求翻译成它擅长的形态。3. 决策空间的定义schema先行让模型在约束内做选择很多人写提示词一上来就是“请你分析……然后输出……”——这是一条通向失控的路。类型化决策的提示词工程第一原则是“schema先行”。3.1 输出schema给模型一张必须遵守的答题卡所谓schema先行就是先定义好模型输出的数据结构再让模型在这个结构里填充内容。以我常用的代码变更分类场景为例schema是这样定义的{ type: object, properties: { category: { type: string, enum: [refactor, bugfix, performance, feature, risk] }, confidence: { type: number, minimum: 0, maximum: 1 }, affected_files: { type: array, items: {type: string} }, rationale: { type: string, maxLength: 200 } }, required: [category, confidence, affected_files, rationale] }这个schema在做三件事。第一约束取值空间——category只能是那五个枚举值模型不能自己发明一个“架构调整”出来第二定义字段结构——必须包含哪些字段、哪些是可选字段一目了然第三给置信度留出表达空间——confidence字段让模型可以表达“我拿不准”而不是被迫硬选。3.2 场景描述模板把上下文变成决策的依据有了schema还不够模型没有上下文照样判断不准。所以提示词里必须有一张“场景描述模板”把决策所需的信息按固定字段喂给模型。你是代码变更分类引擎请基于以下信息给出类型化决策结果。 变更说明 {PR_DESCRIPTION} 变更文件列表及变更行数 {FILE_DIFF_STATS} 关联任务上下文 {TICKET_CONTEXT} 请根据schema输出JSON决策结果category必须从枚举值中选择rationale控制在160字以内。这里的关键在于输入信息的字段要和决策项强相关。PR描述决定“语义分类”文件变更统计决定“改动范围大小”任务上下文决定“变更意图是否对齐业务目标”。三者齐全模型才能做出有依据的决策而不是瞎猜。3.3 实操中怎么定义枚举小而精边界清晰枚举值定义是类型化决策最容易翻车的地方翻车点集中在两个枚举太粗、枚举太模糊。枚举太粗的典型例子是只有“好/中/差”三档。模型面对一个复杂变更时只能硬压到一个粗糙的档位里信息量被抹平下游几乎无法依据这个分类做差异化处理。枚举太模糊的例子是“optimize”“enhance”“improve”这种近义词堆砌。模型在语义空间里分不清它们之间的边界输出就会在相邻枚举之间随机漂移一周的统计结果根本没法看。我常用的做法是用“业务动作词明确边界说明”定义枚举。每个枚举值后面都跟一句话说清楚什么样的情况选它、什么样的情况不选它。比如refactor行为不变仅重构内部实现不修改对外接口和业务结果bugfix修复了与预期行为不符的缺陷行为发生正确性变化performance优化执行效率或资源占用但不改变正确行为feature新增可感知的功能或能力risk大范围变更、涉及核心链路、或行为变化不可完全评估需要人工复核这个边界说明的好处是给模型提供了一个可判定的判据而不是模糊的词汇印象。实操下来枚举漂移率能降低一个数量级。4. 提示词的执行细节示例锚定、格式刚性和概率裁决schema定义了“决策空间”下一步是让模型稳定地在这个空间里“正确落子”。这一节讲提示词里三个最关键的执行细节。4.1 Few-shot示例用正反例给模型划定边界纯schema对模型来说是抽象的。一个更有效的做法是给1-2个完整的正反例让模型从具体案例里领悟边界。正例是这样的输入示例 变更说明修复了用户登录后token未刷新的问题 变更文件统计auth_service.py12/-5token_manager.py8/-3 输出示例 {category:bugfix,confidence:0.95,affected_files:[auth_service.py,token_manager.py],rationale:登录后token未刷新属于修复缺陷行为判定为bugfix}反例则要展示“模型容易滑向错误方向”的情况输入示例 变更说明调整了订单导出功能的实现方式底层从同步写入改为异步队列 变更文件统计order_export.py120/-80queue_client.py30/-10 反例输出错误 {category:refactor,confidence:0.60,...} 错误原因虽然实现方式变了但订单导出功能对外行为不变仍应归为feature因为导出的行为模式发生了变化用户可感知或performance如果核心目标是性能提升。判断依据是“用户是否有可感知的行为变化”。这类正反例的价值在于它直接告诉模型“你以为的边界和真正的边界之间的缝隙在哪里”。比在提示词里强调十遍“仔细判断”有用得多。4.2 格式刚性输出“锚定”到JSON上类型化决策最怕的一件事模型在JSON之外多输出了一句话。这句话在日志里看起来人畜无害但一进解析器就是异常。处理办法是在提示词里给格式加上“刚性锚定”。我的固定写法是输出要求 1. 只输出一个JSON对象不要输出任何解释性文字 2. 不适用代码块标记直接输出JSON文本 3. 如果信息不足confidence必须低于0.5并在rationale中说明缺失信息加一个“输出要求”块比在提示词里笼统说“请严格遵守格式”有效得多。原因在于模型对结构化指令的遵循度取决于指令本身的结构清晰度。你把要求列成编号列表模型会把它当作硬性规则来执行你写在一段话里模型会认为那是“可参考的建议”。4.3 概率裁决让模型敢说“不确定”自由文本模型最糟糕的坏习惯之一是过度自信。你问它一个信息不足的问题它照样给出一个斩钉截铁的答案。类型化决策模式可以通过confidence字段给模型留出“不确定”的出口。我在提示词里显式说明confidence字段含义 - 0.9~1.0上下文信息充分分类无疑义 - 0.6~0.9信息较充分但存在少量歧义 - 0.3~0.6信息不足分类依据薄弱 - 0~0.3完全无法判断需要人工介入配合一个硬规则confidence低于0.5时category允许选择risk或输出unknown占位。这样模型在拿不准的时候不会硬着头皮猜一个看起来合理的答案而是会诚实地降置信度、给risk标签。下游代码看到risk标签就走人工复核通道而不是自动执行决策。这等于在模型和业务之间加了一层概率缓冲层。模型说“我拿不准”的能力越强你整个自动化链路的可靠性就越高。5. 从单次决策到多轮链路Jev在Codex里的组合用法单次类型化决策只是入门Jev在Codex里真正值钱的是多轮决策链。所谓多轮决策就是把一个复杂任务拆成多个决策节点每个节点输出一个类型化结果上一个节点的输出作为下一个节点的输入。5.1 一个完整的Codex决策链路案例我做一个自动化代码评审机器人时把流程拆成了四个决策节点变更分类节点判断这个PR属于refactor/bugfix/performance/feature/risk之一输出{category, confidence}风险定位节点如果confidence低于阈值或category是risk定位风险集中在哪些文件、是否需要修改评审清单输出{risk_files, review_depth}评审清单生成节点基于风险文件列表生成当前PR专属的评审关注点输出{review_items: [string]}通过/打回决策节点综合以上信息输出{verdict: approve|request_changes|needs_human_review, reason}每两个节点之间传递的都是标准JSON没有自由文本的“翻译损耗”。Jev在每个节点上都只做“在有限选项里选最优”这类事情判断质量和速度都稳定得多。def run_code_review_pipeline(pr_info: dict) - dict: # 节点1分类 category_result jev_decision( schemaCATEGORY_SCHEMA, contextbuild_category_context(pr_info), examplesCATEGORY_EXAMPLES ) # 节点2风险定位按需触发 if category_result[confidence] 0.5 or category_result[category] risk: risk_result jev_decision( schemaRISK_SCHEMA, contextbuild_risk_context(pr_info, category_result), examplesRISK_EXAMPLES ) # 节点3评审清单 review_items jev_decision( schemaREVIEW_ITEMS_SCHEMA, contextbuild_review_context(pr_info, category_result, risk_result) ) # 节点4最终裁决 verdict jev_decision( schemaVERDICT_SCHEMA, contextbuild_verdict_context(pr_info, category_result, review_items) ) return verdict5.2 多轮决策的关键上下文串接别丢信息多轮链路最容易出的问题是信息衰减。第一个节点输出{category:bugfix, confidence:0.9}第二个节点的提示词里如果只写了“基于此结果继续判断”模型根本不知道“此结果”是什么。正确做法是把上一个节点的完整输出JSON原样拼进下一个节点的输入上下文里再辅以必要的原文摘要。我用了一个简单的组装函数每个节点的提示词模板里都预留{PREVIOUS_DECISIONS}占位符运行时把前面所有节点的JSON输出序列化后填进去。模型能看到完整的决策历史判断的上下文一致性提升非常明显。5.3 与Skill Agent相比Jev决策链的边界在哪里热搜词里有人问“系统提示词工程和Skill Agent有什么区别”这里也顺带聊两句。Skill Agent的核心思路是给模型一组可调用的“技能”模型自己判断该调用哪个技能、怎么编排调用顺序。它的自由度很高但也正因为高输出稳定性很难保证。Jev决策链的思路恰恰相反编排逻辑由外部代码决定模型只负责在每个节点上做类型化决策。这不是取代Skill Agent而是互补关系——Skill Agent负责“选哪条路走”Jev负责“在选定的那条路上做确定性判断”。在需要高可靠性的生产链路上我倾向于把决策节点用Jev硬约束住把自由探索的空间留给上层编排器。6. 输出校验与失败回退类型化决策的最后一公里提示词写得再好模型也可能在极端情况下输出非法JSON、枚举越界或字段遗漏。作为工程师你不能把“模型必须正确”当成设计前提而是要把“模型可能出错”纳入架构设计。6.1 校验层不要信任任何一次输出我的固定做法是每次拿到模型输出先用schema校验框架做严格校验。我自己用Pydantic写了一个轻量校验器核心逻辑是from pydantic import BaseModel, Field, ValidationError from typing import Literal, List class CategoryDecision(BaseModel): category: Literal[refactor, bugfix, performance, feature, risk] confidence: float Field(ge0.0, le1.0) affected_files: List[str] rationale: str Field(max_length200) def parse_decision(raw_output: str) - CategoryDecision: # 先尝试直接解析 try: data json.loads(raw_output) return CategoryDecision(**data) except (json.JSONDecodeError, ValidationError): raise校验不过直接抛异常让上层走回退逻辑绝不静默容忍。很多同学在这里会心软想着“这个字段缺失影响不大补个默认值算了”。我的建议是在生产链路上缺失字段就是风险信号说明模型这一次的输出偏离了约束后续内容同样不可信必须触发重试或人工接管。6.2 回退策略重试、简化、人工三档我的回退策略分三档第一档重试解析失败或校验失败时带着原上下文重新调用一次Jev通常能解决大多数偶发问题。重试前可以修改温度参数让输出更保守。第二档简化重试后仍失败把提示词里的示例砍掉一半把期望输出的schema原样附在提示词末尾用更强硬的口吻要求“严格按此JSON结构输出”。为什么简化示例有用因为示例过多时模型容易被示例里的噪音带偏简化后注意力更集中在基本规则上。第三档人工前两档都失败直接把raw_output和上下文整包推给人工处理队列同时标记“模型重复失败”以触发告警。这套三档回退看起来简单但在实际项目里帮我挡掉了大量奇奇怪怪的线上事故。6.3 观测比调试更重要把决策质量变成可量化的指标最后还得说一句类型化决策链路上线之后观测是比调试更重要的事。因为是模型在做决策你无法像普通代码一样单步调试“逻辑走到哪一步错了”。你能做的是持续收集决策质量指标。我每个决策节点都会记录四个指标响应成功率合法JSON通过校验的比例、枚举分布category取值的分布是否合理如果bugfix占比一个月内从30%涨到80%大概率是模型漂移了、置信度分布高分决策占比是否稳定、人工介入率落在第三档的比例。这些指标配好 dashboard每天扫一眼发现异常再复查提示词或示例。类型化决策系统不是一次性搭好就完事的它需要像养盆栽一样定期修剪和调整。7. 绕过文本化输出的进阶技巧自一致性投票如果单次决策的稳定性还是不能满足你还有一个进阶技巧值得一试自一致性投票Self-Consistency。思路非常简单——同一个决策问题用不同的采样参数比如改变temperature让Jev独立决策多次然后把多次结果做聚合取众数作为最终决策。我在一个故障定级场景里用过这个方案。线上告警进来系统自动调用Jev判断故障等级P0/P1/P2/P3最初单次判断的准确率大概在85%左右误判导致了一两次不必要的紧急on-call。后来改成一次调用5次、取投票结果准确率拉到96%以上关键场景的误判率直接腰斩。代价也很明显延迟增加、token消耗增加。所以我的经验是只在两种场景下启用自一致性投票——高影响决策故障定级、发布门禁、风险拦截以及模型表现近期有漂移的决策节点。其他常规节点保持单次调用够用就行。另一个和自一致性搭配的小技巧是让Jev在输出决策结果的同时给出一条假设性质疑——“如果这个决策是错误的最可能的原因是什么”。这一条质疑信息不参与投票但会随着决策结果一起记录下来。它不会直接提升准确率但能大幅提升之后排查“为什么误判”时的效率。这属于低成本高回报的投入我强烈建议加上。8. 我对Jev提示词工程的一些实操体会写了这么多最后聊聊我在实际使用Jev做类型化决策过程中比较主观但很真实的一些体会。第一提示词不是越复杂越好。Jev这类模型的上下文理解很强但提示词越长模型对每条规则的权重分配就越分散。我早期吃过亏为了把所有边界情况都写进提示词一条决策提示逼近2000字结果模型输出为了“讨好”规则而过度修正反而不稳定。后来精简到500字核心规则2组示例准确率反而上升了。规则宁可少而精不要多而杂。第二示例是提示词里ROI最高的部分。花半小时精心设计2个正反例效果超过花两个小时堆砌描述性指令。原因是模型对“具体案例”的泛化能力远强于对“抽象指令”的遵循能力。写示例时一定要包含“容易滑向错误边界”的反例那才是模型真正需要被纠正的地方。第三不要怕给模型加“硬约束”。很多人写提示词时习惯礼貌——比如“请尽量输出JSON格式”这种语气翻译成模型的执行逻辑就是“JSON格式是一个可选建议”。改成“必须只输出JSON对象”模型的表现立刻不一样。对行为约束的指令语气越硬遵循度越高。这不是什么技术黑魔法而是和模型打交道的沟通方式。第四类型化决策最终要做成一条流水线而不是一个孤立的prompt。单次决策的稳定性天花板就在那了真正的可靠性要靠schema定义、上下文组装、输出校验、回退策略、观测指标这一整套链路来保证。你花在链路设计上的时间回报率远高于在同一版提示词上反复修修补补。Jev“不写文本”这件事本质上是一个提醒真正有工程价值的不是你让模型写了什么而是你让模型在哪个约束空间里替你做选择。把思考重心从“让模型说得更好”转向“让模型选得更准”这个转变会直接影响你的LLM应用到底能不能从Demo走向生产。