温度设0后，正则表达式竟击败了提示词

在构建一个将WhatsApp消息自动转换为订单台账的离线小工具时，开发者Khushighosh记录了三个出乎意料的发现。这些发现不仅改变了她的开发流程，也提供了一个关于LLM工程实践的鲜活样本：当模型输出足够确定时，传统软件工程方法的价值会重新凸显。

确定性输出让提示词工程变成A/B测试

第一个意外是：相同模型、相同提示词、temperature: 0 下，每次重跑的结果逐字节完全相同——包括那些失败案例。

这听起来像是常识，但实际体验中，许多开发者习惯了LLM输出的随机性，把"重试几次"当作调试手段。而在这个项目里，失败是稳定复现的。据作者描述，这直接让提示词调整从"玄学调参"变成了可量化的A/B测试：改一版提示词，跑一遍，对比失败模式是否变化。

这个观察对AI应用开发有普遍意义。当任务对确定性要求高（如结构化数据抽取），固定温度配合固定输入，可以把LLM当作一个确定性的函数来调试。提示词迭代从此有了对照组和实验组。

temperature 是 LLM 采样过程中的一个参数，用于控制输出的随机性。在基于 softmax 的概率分布中，温度值会缩放 logits：温度越低，概率分布越尖锐，模型越倾向于选择概率最高的 token；温度趋近于 0 时，采样退化为贪心解码（greedy decoding），即每一步都选择概率最大的 token。因此在 temperature: 0 下，给定相同的模型权重、相同的输入 token 序列，解码路径完全确定，输出自然逐字节一致。

需要注意的是，这种确定性有前提条件：推理后端（如 Ollama 的运行时）不能引入额外的随机性，例如动态批处理导致的浮点累加顺序变化、GPU 非确定性算子或 tokenizer 版本差异。在本地单请求场景下通常可以满足，但在云端批量 API 中未必成立。这也是为什么作者在离线环境中能够稳定复现失败案例——确定性是「相同模型 + 相同输入 + 相同运行时」三者共同保证的结果，而非温度参数单独决定的。

正则表达式比提示词更可靠

第二个意外更值得玩味：一条正则表达式击败了精心设计的提示词。

虽然原文在此处截断，但结合上下文可以推断：在从WhatsApp聊天记录中提取订单信息时，开发者发现某些模式化的内容——比如金额、日期、商品编号——用正则匹配比让模型"理解并输出"更稳定。模型可能偶尔漏掉字段或格式漂移，而正则对固定模式的捕获是确定性的、零成本的。

这不是否定LLM的价值。恰恰相反，它指向一种更成熟的工程思路：把确定性任务交给确定性工具，把模糊语义交给模型。例如，聊天消息的意图分类、非结构化描述的归一化适合模型；而手机号、订单号、货币符号这类强模式字段，正则或解析器更合适。混用两者，才能兼顾鲁棒性与开发效率。

结构化输出约束（structured output / constrained decoding）是解决格式漂移的另一类工程手段。其基本思路是在解码阶段对 token 选择施加语法约束：例如通过 JSON Schema 或正则文法，将每一步允许采样的 token 集合限制在符合目标格式的范围内，从而在生成层面保证输出合法。主流实现包括基于 GBNF 文法的 llama.cpp、Ollama 的 format 参数（接受 JSON Schema），以及 OpenAI 的 Structured Outputs。

与「写提示词要求模型输出 JSON」相比，约束解码把格式正确性从概率问题变成了必然问题。但它只保证语法合法，不保证语义正确——字段值仍可能抽错。因此在订单抽取这类任务中，约束解码适合兜住输出结构，正则或解析器适合兜住强模式字段，提示词则负责意图理解和歧义消解，三者各司其职。

离线运行与开放模型的实际取舍

项目名为Order Ledger，定位是一个"跑在开放模型上、可离线运行"的副业工具，技术栈涉及Ollama。作者在Dev.to的Hacktoberfest Open-Source AI Challenge中提交了它，标签包括ollama和ai。

选择本地开放模型意味着放弃云端API的便利，换来数据不出本地、无调用成本、可离线使用。对于处理WhatsApp订单这类含客户信息的数据，隐私是实打实的卖点。代价则是模型能力上限、推理速度以及部署复杂度。作者的三个发现都发生在这个约束条件下——正因为模型能力有限且输出确定，才更需要用工程手段补齐短板。

Ollama 是一个本地大模型运行时，封装了模型下载、量化加载与推理服务，对外暴露类 OpenAI 的 HTTP 接口，并支持自定义 Modelfile 来设定系统提示词、温度、上下文长度等参数。它底层通常依赖 llama.cpp 做推理，因此能在消费级 CPU 或单张消费级 GPU 上运行 7B–14B 级别的量化模型。

对副业工具而言，Ollama 的价值在于把「部署一个模型」简化为「拉取并运行一个模型」，省去了环境配置和推理框架适配。但它也意味着开发者要接受量化带来的精度损失、有限的上下文窗口，以及单机吞吐的瓶颈。理解这层技术边界，才能合理判断哪些任务适合放在本地模型上、哪些仍需更大型的模型或规则系统来兜底。

对AI应用开发的启示

把这三个发现串起来，能得到一条实用的开发原则：先测确定性，再谈提示词。在写复杂提示词之前，先用固定输入跑几遍，看失败是否稳定。如果稳定，说明问题出在任务设计或工具选型上，而非提示词措辞。此时引入正则、解析器或结构化输出约束，往往比反复修改提示词见效更快。

另一个启示关乎评估。当输出可复现，你就可以建立一个小型回归测试集：每次改动后跑一遍，看失败案例是否减少、是否引入新失败。这种测试驱动的提示词开发，比凭感觉调参可靠得多。

最后，开放模型的离线路线适合数据敏感、成本敏感的场景，但需要开发者对任务做更细的拆解。模型不是万能胶，把它放在合适的位置，其余交给传统代码——这可能是这个副业项目最值得带走的一课。