GLM-5.3-Flash最近在开发者圈子里讨论得不少作为GLM系列里主打低延迟、低成本的一个版本它在快速原型、私有化部署和嵌入式场景里表现确实不错。但如果你想要的是那种每一步都按规矩来、把决策过程拆得明明白白的Jev-like decision model直接用默认提示词是远远不够的。这周我花了不少时间把GLM-5.3-Flash改造成一个具备结构化决策能力的模型也就是标题里说的Jev-like决策模型这里面涉及的提示词设计、决策流程约束、输出层规范化每一步都有不少坑。这篇文章想把整个改造过程完整记录下来包括我为什么选择提示词工程的路线而不是微调、决策链怎么拆、系统提示词怎么写、评测集怎么搭、以及实际调试中遇到的格式漂移、幻觉、长上下文丢失等问题的排查方法。适合正在做AI应用开发的工程师、提示词设计师以及想在业务里接入稳定决策模块的朋友参考。内容会比较长但每一步都是可以直接照着落地的。1. 先搞清楚GLM-5.3-Flash和Jev-like决策模型之间差了什么1.1 GLM-5.3-Flash是一把好用的刀但它不知道何时该切GLM-5.3-Flash的能力大家应该不陌生单从语言理解、常识问答、代码生成这些通用任务来看它都能交出不错的答案。尤其它把推理延迟压得很低成本也比同系列的大尺寸模型低不少这让它成了很多实时交互场景的首选。但能用和能稳定决策是两码事。通用模型的设计目标是给用户一个合理的回答而决策模型的设计目标是给用户一个经过权衡、可回溯、符合既定规则的建议。打个比方GLM-5.3-Flash默认状态下就像一个知识面很广但不守规矩的参谋你问他这笔投资该不该做他能滔滔不绝说很多但他不会主动告诉你我基于什么假设、考虑了哪几个方案、每种方案风险权重多少、为什么最后选了B而不是A。而Jev-like决策模型的核心恰恰是这些。所以改造的第一步不是去调整模型权重而是想清楚决策这件事到底需要模型展现出什么行为。我把它拆成了四个要求分层推理、硬性输出约束、过程可回溯、支持多轮修正。这四个要求决定了后续所有提示词和代码怎么写。1.2 Jev-like决策模型的四个核心特征先说分层推理。好的决策模型不会一上来就给出结论而是先把问题拆开输入信息里哪些是事实、哪些是假设、哪些是未知项。比如面对要不要上线这个新功能这个问题模型需要先识别这是一个优先级判断问题再提取用户提到的目标、资源、时间线这些关键信息然后才进入方案生成阶段。其次是硬性输出约束。决策模型必须保证同样的输入结构产生同样的输出结构。你不能让模型有时回答我建议做有时又给一大段散文。决策结果要落在一个明确的框架里比如包含候选方案列表、评分、风险、理由这些字段而且字段不能缺。再次是过程可回溯。这就是Jev-like风格里比较关键的一点模型不仅要说我选了什么还要说清楚我为什么这么选。哪条证据支撑了这个判断哪个假设被推翻了这些信息对业务方来说往往比结论本身更重要因为它让人能审查模型的判断逻辑而不是盲信结果。最后是支持多轮修正。决策很少是一次定终身的。模型先给一个初步建议用户反馈成本约束没考虑模型要能在这个反馈基础上重新评估而不是完全推翻重来。这决定了我们不能只用一次模型调用解决问题而是需要设计一个决策循环让模型反复自我审视。这四个特征就是我后面所有工作的验收标准。1.3 改造目标与验收标准目标定清楚后面做的事才有数。我给自己定下的验收标准有三条第一决策输出格式通过率。随机抽样200次决策请求模型返回的JSON格式能被解析的比例不低于95%漏字段的比例不高于2%。第二决策步骤完整率。每一条决策输出都必须包含信息解析、方案生成、评估打分、最终选择四个阶段的关键记录不能跳过其中任何一环。第三人工评估通过率。我找了几个同事盲测让他们看模型给出的决策理由是否站得住脚逻辑是否通顺评分在4分以上5分制的比例要高于80%。这些指标看起来简单但实际操作中会逼着你去处理很多细节。比如格式通过率这一项就让我花了整整两天去处理模型偶尔在JSON里夹杂注释、换了字段大小写、多输出了一层嵌套的问题。这些后面我会单独讲。2. 整体方案设计先搭骨架再调血肉2.1 提示词工程优先于微调在动手之前我认真考虑过是微调还是提示词工程。GLM-5.3-Flash本身是一个已经训练好的模型要在它基础上微调一套决策能力需要准备大量高质量的决策样本、做训练配置、还要防止灾难性遗忘整个周期非常长。而且一旦业务决策规则变了比如你希望模型先考虑合规因素再考虑成本微调模型就得重新训练迭代速度完全跟不上。提示词工程就不一样。决策规则全部写在系统提示词里改规则就是改文字几分钟就能测一版。模型底层的通用能力没有变化但通过明确指令和示例让它把已有的推理能力导向我们需要的决策路径上。所以我选择了以提示词工程为主体、代码逻辑做辅助的方案。这里也解释一下为什么代码逻辑很重要。单纯靠提示词约束模型是不够的因为语言模型的输出天然带有随机性。我需要在外层写一层解析和校验代码当模型输出不符合规范时自动重试、自动修复。提示词负责引导代码负责兜底两者一起才能达到稳定决策。2.2 把决策过程拆成四个阶段决策流程是整个系统的骨架我把它拆成了四个阶段阶段一信息解析。模型把用户的原始输入转成结构化的事实和条件列表包括显性信息用户直接说的和隐形信息用户没说但可以合理推断的同时标记出信息缺口也就是做出决策还缺哪些东西。阶段二方案生成。基于解析结果模型枚举出所有合理的候选方案。这一步要求模型发散一些哪怕有些方案一眼看起来不太合适也要先摆出来避免过早陷入局部最优。阶段三评估选择。模型对每个候选方案按既定标准打分包括可行性、风险、成本、收益等维度并给出打分的理由。这一步最关键的就是理由两个字没有理由的评分是没有说服力的。阶段四最终决策。模型综合评估结果输出推荐方案并附上一个简要的执行建议和需要注意的风险点。四个阶段顺序执行前一阶段的输出就是后一阶段的输入。但是如果阶段四发现所有方案都存在致命缺陷模型必须回到阶段二重新生成方案而不是硬选一个这个回退逻辑我会在代码里实现。2.3 设计输出Schema让模型学会格式化地说话决策流程定了之后最核心的问题是输出结构。我要求模型每一步都用JSON格式输出因为JSON结构化程度高、字段清晰、方便下游程序处理。在阶段三的评估环节我定义了如下Schema{ evaluation: { candidate_id: B, scores: { feasibility: 8, risk: 6, cost: 7, benefit: 9 }, score_reason: B方案在技术上已有成熟实现成本适中但存在合规审查风险需要法务介入, assumptions: [ 用户量级与预期持平, 现有团队可以在两周内完成开发 ] } }最终的决策输出Schema则长这样{ decision: { chosen: B, alternatives: [A, C], summary: 选择B方案主要原因是性价比最高且实现周期最短, risks: [合规审查存在不确定性], next_actions: [联系法务完成合规评估, 启动后端开发排期] } }这些字段都要求模型严格遵守一个都不能少。为了让模型更好理解我还在提示词里写了几个完整的示例而不是只给一个空模板。示例对模型的约束力比规则描述强得多这一点在后面的实际测试中体现得非常明显。3. 实操过程从零开始搭一个可用的决策模型3.1 环境准备只需要一个模型接口和一段Python代码改造GLM-5.3-Flash不需要本地部署完整模型只需要能调用它的API。我习惯用OpenAI兼容的SDK来写因为这样切换模型厂商时不需要改太多代码。以下是我这边的环境准备步骤第一步确认Python版本不低于3.9安装openai库。第二步准备好模型接口的访问凭证在环境变量里配置好对应的地址和凭证信息。第三步确认GLM-5.3-Flash的模型标识在代码里直接引用。基础调用代码如下import os from openai import OpenAI client OpenAI( api_keyos.getenv(MODEL_API_TOKEN), base_urlos.getenv(MODEL_API_BASE) ) def ask_glm(messages, temperature0.2, max_tokens2000): resp client.chat.completions.create( modelglm-5.3-flash, messagesmessages, temperaturetemperature, max_tokensmax_tokens ) return resp.choices[0].message.content这里我强烈建议把temperature设低决策场景需要的是稳定和保守而不是随机和发散。0.2是我反复测试后觉得比较合适的值在有足够约束的情况下它既能保证输出稳定又不会因为概率分布过于集中导致候选方案单一化。3.2 第一版系统提示词把规矩一项项写清楚系统提示词是整个决策模型的核心。我写的第一个版本非常详细包含了角色定义、决策四阶段说明、输出格式要求、禁止事项、以及两个完整示例。这里给大家看一个简化但结构完整的版本你是一个严谨的决策分析引擎。你的任务是对用户提出的问题进行信息解析、方案生成、评估选择和最终决策。 你必须遵循以下流程 1. 信息解析列出输入中的事实、假设与信息缺口。 2. 方案生成给出至少两个候选方案用大写字母编号。 3. 评估选择对每个方案按可行性、风险、成本、收益四个维度分别打分并给出理由。 4. 最终决策选择其中一个方案说明理由、风险和下一步行动。 输出规范 - 每一阶段的输出使用JSON格式。 - 字段名必须与User指令给出的Schema完全一致。 - 禁止在JSON之外输出任何解释性文字。 - 如果某个维度的信息不足在assumptions字段中明确标注不允许猜测硬填。 示例请参考用户消息中提供的决策案例。 注意事项 - 不要输出我觉得我认为这类主观表达用基于当前信息替代。 - 如果所有方案都不可行必须重新生成方案禁止硬选。这段提示词看上去不长但背后有几个设计细节第一你必须遵循以下流程用的是命令式而非建议式模型对强指令的遵从度明显更高第二明确说了禁止在JSON之外输出任何解释性文字这一条直接解决了模型偶尔多说话导致解析失败的问题第三强调查缺信息要标注而不是硬填避免模型在信息不足时编造理由。3.3 决策循环实现一次调用不够就跑三轮当用户问题稍微复杂一点单次模型调用很难完成完整决策流程。实际跑下来一是输出长度容易超限二是四个阶段塞在一个请求里模型经常只做前两个阶段就开始给结论。所以我改成了多轮调用每一轮只负责一个阶段的输出并在外层维护一个决策上下文变量。核心代码如下class DecisionEngine: def __init__(self, system_prompt): self.system_prompt system_prompt self.history [{role: system, content: system_prompt}] def _call(self, user_content, temperature0.2): messages self.history [{role: user, content: user_content}] text ask_glm(messages, temperaturetemperature) self.history.append({role: user, content: user_content}) self.history.append({role: assistant, content: text}) return text def parse_json(self, text): # 稳健解析先直接尝试失败后截取花括号片段 try: return json.loads(text) except json.JSONDecodeError: start, end text.find({), text.rfind(}) if start ! -1 and end ! -1: return json.loads(text[start:end1]) raise def decide(self, question): parsed self.parse_json(self._call( f请完成第一阶段信息解析。\n问题{question}\n只输出JSON。 )) alternatives self.parse_json(self._call( f上一阶段解析结果{json.dumps(parsed, ensure_asciiFalse)}\n 请完成第二阶段生成至少两个候选方案用A、B、C编号。只输出JSON。 )) evaluation self.parse_json(self._call( f候选方案{json.dumps(alternatives, ensure_asciiFalse)}\n 请完成第三阶段按可行性、风险、成本、收益逐项打分并给出理由。只输出JSON。 )) final self.parse_json(self._call( f评估结果{json.dumps(evaluation, ensure_asciiFalse)}\n 请完成第四阶段给出最终决策、理由、风险和下一步行动。只输出JSON。 )) return {info: parsed, options: alternatives, evaluation: evaluation, decision: final}每一轮只执行一个阶段的好处是上下文更短模型注意力更集中输出格式更容易控制哪一步出问题我能立刻定位到。代价是多花几次请求但Flash本身成本低、延迟小这个代价完全可以接受。3.4 评测集构建与效果验证流程搭起来之后最忌讳的就是在几个顺手的例子上反复试觉得效果好就上线。我搭了一个二十条的评测集把问题分成三类正常业务问题、边界条件问题、陷阱问题。正常业务问题就是普通的决策场景比如项目预算有限应该先做A功能还是B功能两个候选人背景接近怎么选。边界条件问题会故意制造信息不足比如没有历史数据的情况下要不要进入新市场成本数据缺失如何评估方案C。陷阱问题则是模拟用户隐含偏好或相互矛盾的需求比如用户说要低成本又要高速度但这两者当前技术水平下不可兼得。评测方法不复杂跑完二十条之后统计格式通过率、步骤完整率和人工满意度。我第一版的结果如下指标第一版结果目标值JSON格式通过率86%≥95%步骤完整率74%100%人工满意度70%≥80%第一版离目标差得很远。格式通过率低是因为模型偶尔会在JSON前后加一行以下是解析结果之类的文字步骤完整率低则是因为部分问题在阶段三就出现了评估异常模型自作主张跳到了阶段四。这两个问题直接触发了后面章节里的调优工作。4. 常见问题与调优记录4.1 输出格式不稳定宁可多写解析代码也不要完全信任模型格式问题是我遇到的第一个大坑。现象很直接明明说好了只输出JSON模型偶尔还是在JSON外面加一句话或者把字段名从chosen写成selected更有甚者把score_reason拆成了子对象。这种问题在平时聊天时无所谓但决策系统里就是致命的因为下游程序解析失败整个流程就断了。我做了两件事。第一件事是防御性解析也就是代码里写完json.loads之后立刻写一个fallback逻辑如果整体解析失败就尝试截取第一个{到最后一个}之间的内容再解析如果还失败就带着错误信息重新调用一次模型。第二件事是调整提示词把示例加得更多更具体而不是仅仅强调只输出JSON。模型对示例的学习能力比对规则强得多加完示例之后格式通过率直接提升到了94%再配合重试逻辑实测能稳定在96%以上。4.2 决策理由浮于表面用假设-评分-风险结构逼出深层推理第二个坑是模型给出的决策理由很空。它可能会说选择A方案因为成本较低但完全不提成本数据从哪里来、假设是什么、有没有更优解。这种决策结果给业务方看基本等于没有。我排查之后发现问题出在提示词的环节描述不够具体。我只是说评估选择要给理由但没说清楚理由要包含哪些成分。后来我改成了强制要求每个候选方案都按前提假设评分理由潜在风险三段式输出并且在示例里展示了完整的写法。这样模型才会真正去想我打8分是根据什么假设如果这个假设不成立分数会不会变改完之后人工满意度从70%升到了83%效果很明显。核心体会是想让模型输出更深的内容与其说请深入分析——这种话基本没用——不如直接定义深层输出的格式。格式会倒逼模型按特定路径思考。4.3 长上下文丢失早期约束让状态独立保存第三个坑出现在多轮决策中。我在决策循环里一直把历史消息堆在self.history里当用户连续做五六次决策之后早期的系统提示词约束会被大量新的对话内容冲淡。具体表现是第五轮决策时模型开始用自然语言回答问题而不是按JSON输出。解决这个问题的思路也和提示词有关。我调整了设计不再把全部历史消息都塞进每次请求而是只保留当前决策轮次的四阶段过程记录上一轮决策只保留一个summary字段。同时在每次调用时都重新注入一遍核心系统提示词而不是只靠历史消息里那条system message。这样每一轮决策开始时模型都是带齐规矩上考场的状态早期约束丢失的问题基本消失。4.4 温度、采样参数和重复惩罚的调节经验调参这块我也踩了不少次。最初我图省事直接用默认温度1.0跑结果输出五花八门同一个问题每次给的方案都不一样。后来我把温度降到了0.2稳定性立刻上来了。但温度太低也有副作用方案生成阶段会变得保守——它倾向于只给两个非常相似的方案而不是发散出不同思路。我的做法是分阶段设定温度信息解析和评估阶段用0.1这两个阶段要的是确定性越一致越好方案生成阶段用0.5给模型更多探索空间更容易提出多样化候选方案。这样一个一冷一热的组合既保证了决策链路的稳定又不会让方案生成环节太过单一。阶段温度推荐理由信息解析0.1追求一致性和准确性方案生成0.5保留足够的发散空间评估选择0.1减少随机因素保证打分可复现最终决策0.2综合权衡兼顾稳定与微调4.5 防御性重试让模型自己修复错误最后一个技巧是在外层加重试机制。我遇到一种情况是模型在方案生成阶段产出的候选方案本身不合理比如两个方案本质上是同一件事的两种表述。如果我不加检查后面的评估和决策就全建立在错误地基上。我在代码里加了一个简单的一致性检查把生成的候选方案转成向量做相似度对比如果相似度过高就让模型重新生成。这个思路其实就是模拟了两个思路第一机器校验和人天津校验双保险第二发现错误及时回到上游修正而不是带病往下走。对于没有向量模型的场景也可以用关键词重合率来判断方案是否重复效果虽然粗糙一点但也能挡掉一批明显不合格的输出。5. 实践中的几点体会整套跑下来我最想跟准备做类似改造的朋友分享的体会大概有三条。第一条决策提示词的编写本质上是在写一份极其严谨的需求文档而不是在写你好请帮我分析一下。模型能不能达到Jev-like的决策水平很大程度不取决于它本身有多强而取决于你给它的边界和示例够不够精确。把规则写到字段名都不能变这种颗粒度模型才会真的按规矩办事。第二条不要指望一次就调好。我前前后后改了十几个版本提示词每次改一个点然后拿评测集跑一遍看指标有没有提升。决策系统的调优和写代码一样要相信数据而不是感觉。第三条Flash这类轻量模型做决策场景完全可行前提是你愿意在外层多做一点工作。把多阶段拆开、加校验、加重试、做参数分级这些事情做完之后它输出结果的稳定程度并不会比大模型差太多但成本和延迟优势却非常明显。我在实际项目里就是用这套思路把决策模块跑起来的稳定性和可解释性都比一开始直接问模型怎么办高了好几个量级。以后如果再扩展可以考虑把决策结果接入到具体的自动执行流程里让模型不仅会选方案还会把方案落实成可追踪的任务那又是另一个值得折腾的方向了。
用提示词工程将GLM-5.3-Flash改造成Jev-like决策模型
GLM-5.3-Flash最近在开发者圈子里讨论得不少作为GLM系列里主打低延迟、低成本的一个版本它在快速原型、私有化部署和嵌入式场景里表现确实不错。但如果你想要的是那种每一步都按规矩来、把决策过程拆得明明白白的Jev-like decision model直接用默认提示词是远远不够的。这周我花了不少时间把GLM-5.3-Flash改造成一个具备结构化决策能力的模型也就是标题里说的Jev-like决策模型这里面涉及的提示词设计、决策流程约束、输出层规范化每一步都有不少坑。这篇文章想把整个改造过程完整记录下来包括我为什么选择提示词工程的路线而不是微调、决策链怎么拆、系统提示词怎么写、评测集怎么搭、以及实际调试中遇到的格式漂移、幻觉、长上下文丢失等问题的排查方法。适合正在做AI应用开发的工程师、提示词设计师以及想在业务里接入稳定决策模块的朋友参考。内容会比较长但每一步都是可以直接照着落地的。1. 先搞清楚GLM-5.3-Flash和Jev-like决策模型之间差了什么1.1 GLM-5.3-Flash是一把好用的刀但它不知道何时该切GLM-5.3-Flash的能力大家应该不陌生单从语言理解、常识问答、代码生成这些通用任务来看它都能交出不错的答案。尤其它把推理延迟压得很低成本也比同系列的大尺寸模型低不少这让它成了很多实时交互场景的首选。但能用和能稳定决策是两码事。通用模型的设计目标是给用户一个合理的回答而决策模型的设计目标是给用户一个经过权衡、可回溯、符合既定规则的建议。打个比方GLM-5.3-Flash默认状态下就像一个知识面很广但不守规矩的参谋你问他这笔投资该不该做他能滔滔不绝说很多但他不会主动告诉你我基于什么假设、考虑了哪几个方案、每种方案风险权重多少、为什么最后选了B而不是A。而Jev-like决策模型的核心恰恰是这些。所以改造的第一步不是去调整模型权重而是想清楚决策这件事到底需要模型展现出什么行为。我把它拆成了四个要求分层推理、硬性输出约束、过程可回溯、支持多轮修正。这四个要求决定了后续所有提示词和代码怎么写。1.2 Jev-like决策模型的四个核心特征先说分层推理。好的决策模型不会一上来就给出结论而是先把问题拆开输入信息里哪些是事实、哪些是假设、哪些是未知项。比如面对要不要上线这个新功能这个问题模型需要先识别这是一个优先级判断问题再提取用户提到的目标、资源、时间线这些关键信息然后才进入方案生成阶段。其次是硬性输出约束。决策模型必须保证同样的输入结构产生同样的输出结构。你不能让模型有时回答我建议做有时又给一大段散文。决策结果要落在一个明确的框架里比如包含候选方案列表、评分、风险、理由这些字段而且字段不能缺。再次是过程可回溯。这就是Jev-like风格里比较关键的一点模型不仅要说我选了什么还要说清楚我为什么这么选。哪条证据支撑了这个判断哪个假设被推翻了这些信息对业务方来说往往比结论本身更重要因为它让人能审查模型的判断逻辑而不是盲信结果。最后是支持多轮修正。决策很少是一次定终身的。模型先给一个初步建议用户反馈成本约束没考虑模型要能在这个反馈基础上重新评估而不是完全推翻重来。这决定了我们不能只用一次模型调用解决问题而是需要设计一个决策循环让模型反复自我审视。这四个特征就是我后面所有工作的验收标准。1.3 改造目标与验收标准目标定清楚后面做的事才有数。我给自己定下的验收标准有三条第一决策输出格式通过率。随机抽样200次决策请求模型返回的JSON格式能被解析的比例不低于95%漏字段的比例不高于2%。第二决策步骤完整率。每一条决策输出都必须包含信息解析、方案生成、评估打分、最终选择四个阶段的关键记录不能跳过其中任何一环。第三人工评估通过率。我找了几个同事盲测让他们看模型给出的决策理由是否站得住脚逻辑是否通顺评分在4分以上5分制的比例要高于80%。这些指标看起来简单但实际操作中会逼着你去处理很多细节。比如格式通过率这一项就让我花了整整两天去处理模型偶尔在JSON里夹杂注释、换了字段大小写、多输出了一层嵌套的问题。这些后面我会单独讲。2. 整体方案设计先搭骨架再调血肉2.1 提示词工程优先于微调在动手之前我认真考虑过是微调还是提示词工程。GLM-5.3-Flash本身是一个已经训练好的模型要在它基础上微调一套决策能力需要准备大量高质量的决策样本、做训练配置、还要防止灾难性遗忘整个周期非常长。而且一旦业务决策规则变了比如你希望模型先考虑合规因素再考虑成本微调模型就得重新训练迭代速度完全跟不上。提示词工程就不一样。决策规则全部写在系统提示词里改规则就是改文字几分钟就能测一版。模型底层的通用能力没有变化但通过明确指令和示例让它把已有的推理能力导向我们需要的决策路径上。所以我选择了以提示词工程为主体、代码逻辑做辅助的方案。这里也解释一下为什么代码逻辑很重要。单纯靠提示词约束模型是不够的因为语言模型的输出天然带有随机性。我需要在外层写一层解析和校验代码当模型输出不符合规范时自动重试、自动修复。提示词负责引导代码负责兜底两者一起才能达到稳定决策。2.2 把决策过程拆成四个阶段决策流程是整个系统的骨架我把它拆成了四个阶段阶段一信息解析。模型把用户的原始输入转成结构化的事实和条件列表包括显性信息用户直接说的和隐形信息用户没说但可以合理推断的同时标记出信息缺口也就是做出决策还缺哪些东西。阶段二方案生成。基于解析结果模型枚举出所有合理的候选方案。这一步要求模型发散一些哪怕有些方案一眼看起来不太合适也要先摆出来避免过早陷入局部最优。阶段三评估选择。模型对每个候选方案按既定标准打分包括可行性、风险、成本、收益等维度并给出打分的理由。这一步最关键的就是理由两个字没有理由的评分是没有说服力的。阶段四最终决策。模型综合评估结果输出推荐方案并附上一个简要的执行建议和需要注意的风险点。四个阶段顺序执行前一阶段的输出就是后一阶段的输入。但是如果阶段四发现所有方案都存在致命缺陷模型必须回到阶段二重新生成方案而不是硬选一个这个回退逻辑我会在代码里实现。2.3 设计输出Schema让模型学会格式化地说话决策流程定了之后最核心的问题是输出结构。我要求模型每一步都用JSON格式输出因为JSON结构化程度高、字段清晰、方便下游程序处理。在阶段三的评估环节我定义了如下Schema{ evaluation: { candidate_id: B, scores: { feasibility: 8, risk: 6, cost: 7, benefit: 9 }, score_reason: B方案在技术上已有成熟实现成本适中但存在合规审查风险需要法务介入, assumptions: [ 用户量级与预期持平, 现有团队可以在两周内完成开发 ] } }最终的决策输出Schema则长这样{ decision: { chosen: B, alternatives: [A, C], summary: 选择B方案主要原因是性价比最高且实现周期最短, risks: [合规审查存在不确定性], next_actions: [联系法务完成合规评估, 启动后端开发排期] } }这些字段都要求模型严格遵守一个都不能少。为了让模型更好理解我还在提示词里写了几个完整的示例而不是只给一个空模板。示例对模型的约束力比规则描述强得多这一点在后面的实际测试中体现得非常明显。3. 实操过程从零开始搭一个可用的决策模型3.1 环境准备只需要一个模型接口和一段Python代码改造GLM-5.3-Flash不需要本地部署完整模型只需要能调用它的API。我习惯用OpenAI兼容的SDK来写因为这样切换模型厂商时不需要改太多代码。以下是我这边的环境准备步骤第一步确认Python版本不低于3.9安装openai库。第二步准备好模型接口的访问凭证在环境变量里配置好对应的地址和凭证信息。第三步确认GLM-5.3-Flash的模型标识在代码里直接引用。基础调用代码如下import os from openai import OpenAI client OpenAI( api_keyos.getenv(MODEL_API_TOKEN), base_urlos.getenv(MODEL_API_BASE) ) def ask_glm(messages, temperature0.2, max_tokens2000): resp client.chat.completions.create( modelglm-5.3-flash, messagesmessages, temperaturetemperature, max_tokensmax_tokens ) return resp.choices[0].message.content这里我强烈建议把temperature设低决策场景需要的是稳定和保守而不是随机和发散。0.2是我反复测试后觉得比较合适的值在有足够约束的情况下它既能保证输出稳定又不会因为概率分布过于集中导致候选方案单一化。3.2 第一版系统提示词把规矩一项项写清楚系统提示词是整个决策模型的核心。我写的第一个版本非常详细包含了角色定义、决策四阶段说明、输出格式要求、禁止事项、以及两个完整示例。这里给大家看一个简化但结构完整的版本你是一个严谨的决策分析引擎。你的任务是对用户提出的问题进行信息解析、方案生成、评估选择和最终决策。 你必须遵循以下流程 1. 信息解析列出输入中的事实、假设与信息缺口。 2. 方案生成给出至少两个候选方案用大写字母编号。 3. 评估选择对每个方案按可行性、风险、成本、收益四个维度分别打分并给出理由。 4. 最终决策选择其中一个方案说明理由、风险和下一步行动。 输出规范 - 每一阶段的输出使用JSON格式。 - 字段名必须与User指令给出的Schema完全一致。 - 禁止在JSON之外输出任何解释性文字。 - 如果某个维度的信息不足在assumptions字段中明确标注不允许猜测硬填。 示例请参考用户消息中提供的决策案例。 注意事项 - 不要输出我觉得我认为这类主观表达用基于当前信息替代。 - 如果所有方案都不可行必须重新生成方案禁止硬选。这段提示词看上去不长但背后有几个设计细节第一你必须遵循以下流程用的是命令式而非建议式模型对强指令的遵从度明显更高第二明确说了禁止在JSON之外输出任何解释性文字这一条直接解决了模型偶尔多说话导致解析失败的问题第三强调查缺信息要标注而不是硬填避免模型在信息不足时编造理由。3.3 决策循环实现一次调用不够就跑三轮当用户问题稍微复杂一点单次模型调用很难完成完整决策流程。实际跑下来一是输出长度容易超限二是四个阶段塞在一个请求里模型经常只做前两个阶段就开始给结论。所以我改成了多轮调用每一轮只负责一个阶段的输出并在外层维护一个决策上下文变量。核心代码如下class DecisionEngine: def __init__(self, system_prompt): self.system_prompt system_prompt self.history [{role: system, content: system_prompt}] def _call(self, user_content, temperature0.2): messages self.history [{role: user, content: user_content}] text ask_glm(messages, temperaturetemperature) self.history.append({role: user, content: user_content}) self.history.append({role: assistant, content: text}) return text def parse_json(self, text): # 稳健解析先直接尝试失败后截取花括号片段 try: return json.loads(text) except json.JSONDecodeError: start, end text.find({), text.rfind(}) if start ! -1 and end ! -1: return json.loads(text[start:end1]) raise def decide(self, question): parsed self.parse_json(self._call( f请完成第一阶段信息解析。\n问题{question}\n只输出JSON。 )) alternatives self.parse_json(self._call( f上一阶段解析结果{json.dumps(parsed, ensure_asciiFalse)}\n 请完成第二阶段生成至少两个候选方案用A、B、C编号。只输出JSON。 )) evaluation self.parse_json(self._call( f候选方案{json.dumps(alternatives, ensure_asciiFalse)}\n 请完成第三阶段按可行性、风险、成本、收益逐项打分并给出理由。只输出JSON。 )) final self.parse_json(self._call( f评估结果{json.dumps(evaluation, ensure_asciiFalse)}\n 请完成第四阶段给出最终决策、理由、风险和下一步行动。只输出JSON。 )) return {info: parsed, options: alternatives, evaluation: evaluation, decision: final}每一轮只执行一个阶段的好处是上下文更短模型注意力更集中输出格式更容易控制哪一步出问题我能立刻定位到。代价是多花几次请求但Flash本身成本低、延迟小这个代价完全可以接受。3.4 评测集构建与效果验证流程搭起来之后最忌讳的就是在几个顺手的例子上反复试觉得效果好就上线。我搭了一个二十条的评测集把问题分成三类正常业务问题、边界条件问题、陷阱问题。正常业务问题就是普通的决策场景比如项目预算有限应该先做A功能还是B功能两个候选人背景接近怎么选。边界条件问题会故意制造信息不足比如没有历史数据的情况下要不要进入新市场成本数据缺失如何评估方案C。陷阱问题则是模拟用户隐含偏好或相互矛盾的需求比如用户说要低成本又要高速度但这两者当前技术水平下不可兼得。评测方法不复杂跑完二十条之后统计格式通过率、步骤完整率和人工满意度。我第一版的结果如下指标第一版结果目标值JSON格式通过率86%≥95%步骤完整率74%100%人工满意度70%≥80%第一版离目标差得很远。格式通过率低是因为模型偶尔会在JSON前后加一行以下是解析结果之类的文字步骤完整率低则是因为部分问题在阶段三就出现了评估异常模型自作主张跳到了阶段四。这两个问题直接触发了后面章节里的调优工作。4. 常见问题与调优记录4.1 输出格式不稳定宁可多写解析代码也不要完全信任模型格式问题是我遇到的第一个大坑。现象很直接明明说好了只输出JSON模型偶尔还是在JSON外面加一句话或者把字段名从chosen写成selected更有甚者把score_reason拆成了子对象。这种问题在平时聊天时无所谓但决策系统里就是致命的因为下游程序解析失败整个流程就断了。我做了两件事。第一件事是防御性解析也就是代码里写完json.loads之后立刻写一个fallback逻辑如果整体解析失败就尝试截取第一个{到最后一个}之间的内容再解析如果还失败就带着错误信息重新调用一次模型。第二件事是调整提示词把示例加得更多更具体而不是仅仅强调只输出JSON。模型对示例的学习能力比对规则强得多加完示例之后格式通过率直接提升到了94%再配合重试逻辑实测能稳定在96%以上。4.2 决策理由浮于表面用假设-评分-风险结构逼出深层推理第二个坑是模型给出的决策理由很空。它可能会说选择A方案因为成本较低但完全不提成本数据从哪里来、假设是什么、有没有更优解。这种决策结果给业务方看基本等于没有。我排查之后发现问题出在提示词的环节描述不够具体。我只是说评估选择要给理由但没说清楚理由要包含哪些成分。后来我改成了强制要求每个候选方案都按前提假设评分理由潜在风险三段式输出并且在示例里展示了完整的写法。这样模型才会真正去想我打8分是根据什么假设如果这个假设不成立分数会不会变改完之后人工满意度从70%升到了83%效果很明显。核心体会是想让模型输出更深的内容与其说请深入分析——这种话基本没用——不如直接定义深层输出的格式。格式会倒逼模型按特定路径思考。4.3 长上下文丢失早期约束让状态独立保存第三个坑出现在多轮决策中。我在决策循环里一直把历史消息堆在self.history里当用户连续做五六次决策之后早期的系统提示词约束会被大量新的对话内容冲淡。具体表现是第五轮决策时模型开始用自然语言回答问题而不是按JSON输出。解决这个问题的思路也和提示词有关。我调整了设计不再把全部历史消息都塞进每次请求而是只保留当前决策轮次的四阶段过程记录上一轮决策只保留一个summary字段。同时在每次调用时都重新注入一遍核心系统提示词而不是只靠历史消息里那条system message。这样每一轮决策开始时模型都是带齐规矩上考场的状态早期约束丢失的问题基本消失。4.4 温度、采样参数和重复惩罚的调节经验调参这块我也踩了不少次。最初我图省事直接用默认温度1.0跑结果输出五花八门同一个问题每次给的方案都不一样。后来我把温度降到了0.2稳定性立刻上来了。但温度太低也有副作用方案生成阶段会变得保守——它倾向于只给两个非常相似的方案而不是发散出不同思路。我的做法是分阶段设定温度信息解析和评估阶段用0.1这两个阶段要的是确定性越一致越好方案生成阶段用0.5给模型更多探索空间更容易提出多样化候选方案。这样一个一冷一热的组合既保证了决策链路的稳定又不会让方案生成环节太过单一。阶段温度推荐理由信息解析0.1追求一致性和准确性方案生成0.5保留足够的发散空间评估选择0.1减少随机因素保证打分可复现最终决策0.2综合权衡兼顾稳定与微调4.5 防御性重试让模型自己修复错误最后一个技巧是在外层加重试机制。我遇到一种情况是模型在方案生成阶段产出的候选方案本身不合理比如两个方案本质上是同一件事的两种表述。如果我不加检查后面的评估和决策就全建立在错误地基上。我在代码里加了一个简单的一致性检查把生成的候选方案转成向量做相似度对比如果相似度过高就让模型重新生成。这个思路其实就是模拟了两个思路第一机器校验和人天津校验双保险第二发现错误及时回到上游修正而不是带病往下走。对于没有向量模型的场景也可以用关键词重合率来判断方案是否重复效果虽然粗糙一点但也能挡掉一批明显不合格的输出。5. 实践中的几点体会整套跑下来我最想跟准备做类似改造的朋友分享的体会大概有三条。第一条决策提示词的编写本质上是在写一份极其严谨的需求文档而不是在写你好请帮我分析一下。模型能不能达到Jev-like的决策水平很大程度不取决于它本身有多强而取决于你给它的边界和示例够不够精确。把规则写到字段名都不能变这种颗粒度模型才会真的按规矩办事。第二条不要指望一次就调好。我前前后后改了十几个版本提示词每次改一个点然后拿评测集跑一遍看指标有没有提升。决策系统的调优和写代码一样要相信数据而不是感觉。第三条Flash这类轻量模型做决策场景完全可行前提是你愿意在外层多做一点工作。把多阶段拆开、加校验、加重试、做参数分级这些事情做完之后它输出结果的稳定程度并不会比大模型差太多但成本和延迟优势却非常明显。我在实际项目里就是用这套思路把决策模块跑起来的稳定性和可解释性都比一开始直接问模型怎么办高了好几个量级。以后如果再扩展可以考虑把决策结果接入到具体的自动执行流程里让模型不仅会选方案还会把方案落实成可追踪的任务那又是另一个值得折腾的方向了。
