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.py（+12/-5），token_manager.py（+8/-3） 输出示例： {"category":"bugfix","confidence":0.95,"affected_files":["auth_service.py","token_manager.py"],"rationale":"登录后token未刷新，属于修复缺陷行为，判定为bugfix"}反例则要展示“模型容易滑向错误方向”的情况：
输入示例： 变更说明：调整了订单导出功能的实现方式，底层从同步写入改为异步队列 变更文件统计：order_export.py（+120/-80），queue_client.py（+30/-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( schema=CATEGORY_SCHEMA, context=build_category_context(pr_info), examples=CATEGORY_EXAMPLES ) # 节点2：风险定位（按需触发） if category_result["confidence"] < 0.5 or category_result["category"] == "risk": risk_result = jev_decision( schema=RISK_SCHEMA, context=build_risk_context(pr_info, category_result), examples=RISK_EXAMPLES ) # 节点3：评审清单 review_items = jev_decision( schema=REVIEW_ITEMS_SCHEMA, context=build_review_context(pr_info, category_result, risk_result) ) # 节点4：最终裁决 verdict = jev_decision( schema=VERDICT_SCHEMA, context=build_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(ge=0.0, le=1.0) affected_files: List[str] rationale: str = Field(max_length=200) 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走向生产。