企业官网建设流程全解析

做这个项目之前，我一直有个执念：业务部门嘴里那些“差不多”“尽量均衡”“别太过分”，到底能不能变成一行行严谨的数学约束？前两年做制造业排产和物流路径优化的项目，每次都有一段极其痛苦的沟通——业务方用自然语言描述需求，算法团队把它翻成线性规划模型。翻译过程中，语义损失、边界模糊、目标函数拍脑袋，返工是家常便饭。后来大语言模型的能力上来了，我就在想：能不能让 LLM 只负责“翻译”这件事，把人话变成结构化的模型描述，再由求解器算出最优方案？于是就有了这个从零构建的自然语言优化求解系统。

这篇博文会从架构设计、核心模块、Prompt 模板、建模代码到踩坑实录，把整个 0-1 过程完整复盘一遍。适合两类人：一是正在研究 LLM 应用落地、想让大模型干点“正经事”的工程师；二是做运筹优化、想把求解能力封装成产品的算法同学。即使你完全没碰过优化求解，只要懂一点 Python，也能顺着这篇文章搭出一个能跑的 Demo。

1. 先说清楚：这个系统到底要解决什么问题

1.1 “翻译”才是真难点，不是“求解”

很多人一听“自然语言优化求解”，第一反应是让 AI 直接给出最优答案。真做起来你会发现，大模型做数学计算非常不靠谱，让它算三位数乘法都可能出错，更别提带几十个约束条件的整数规划问题。但大模型有一个强项：理解语义、抽取结构化信息。让 LLM 直接把“请选择 5 个仓储点，使总运输成本最低，且不能覆盖风险等级高的区域”翻译成一个标准数学模型，它给出的结果往往能直接用。

这个系统的核心思路是：LLM 只做语义到中间表达的转换，真正的计算交给专业求解器。业务方说人话，系统先抽取出决策变量、约束条件、目标函数，生成一个结构化的 JSON 描述，再调用 OR-Tools 之类的求解器完成数学计算。回头想想，这也是整个项目里最关键的架构决策——没有把“计算”硬塞给 LLM，避免了大量幻觉问题。

从编程角度看，这件事本质上是在做一个“领域特定语言”的编译器：输入是自然语言，输出是数学规划模型。你不需要教会 LLM 什么是单纯形法，只需要让它把你的话翻译成编译器能识别的中间代码。这个思路一旦想通，后面所有模块设计都顺了。

1.2 整体架构：四层分工，各干各的

系统分为四个层次，层与层之间通过 JSON 传递数据，职责非常清晰：

• 语义解析层：接收自然语言输入，识别问题意图、抽取变量和约束，输出标准 JSON。这一层用 LLM + 少量规则兜底实现。
• 中间表达层：定义一套严格的 JSON Schema，描述变量、约束、目标函数。这是整个系统的“通用语言”，上层说话再乱，到这里必须结构化。
• 建模求解层：将 JSON 转为 OR-Tools 模型，设置求解参数，执行计算，返回结果集。
• 结果回译层：把求解结果套入模板，或让 LLM 润色，生成用户能直接看懂的自然语言方案说明。

为什么中间一定要加一个 JSON 表达层，而不是让 LLM 直接输出代码？我试过后者。LLM 直接写 OR-Tools 代码时，经常写出不存在的 API、搞错变量作用域，或者把约束方向写反。而 JSON 只是数据描述，不涉及 API 调用，错误率低很多，校验也简单——不需要编译 Python，用 JSON Schema 就能做合法性检查。

这种四层结构还有一个好处：每一层都能独立测试。你可以先用写死的 JSON 测试求解层，确认数学逻辑没问题，再回头调 Prompt。项目 debug 时，如果最终答案不对，能快速定位是“翻译错了”还是“求解错了”，不用一锅烩。

1.3 技术选型：为什么是 LLM + OR-Tools，而不是别家

LLM 的选择上，我考虑过两个方向：一是调用商业 API（比如 GPT 系列或国产大模型），二是本地部署开源模型（Qwen、ChatGLM 等）。起步阶段建议直接用 API，因为你需要的是稳定的结构化输出能力和较长的上下文窗口，这些商业模型成熟度更高。本地模型的优势是隐私和数据合规，但初期调试 Prompt 时频繁调用，成本和速度都会成为阻碍。等逻辑跑通以后，再根据业务需要换成私有化部署。

求解器选型比较有意思。Gurobi 和 CPLEX 是工业级标杆，但商业授权费用非常贵，个人项目或者中小团队根本扛不住。开源界有个 HiGHS，性能不错，但纯 Python API 用起来不够顺滑。最终我选了 Google OR-Tools，核心原因是它的 CP-SAT 求解器对整数规划支持很好，而且 API 设计直观，几千行代码就能封装一个建模层。它还自带一些工具函数，比如计算两个区间是否有交集，省去不少事。

有人会问 CP-SAT 和线性规划求解器有什么区别。简单说，CP-SAT 更适合离散决策问题，比如“选哪几个仓库”“哪些机器开工”这类 0-1 整数变量；而线性规划求解器擅长连续变量的资源分配。日常业务需求里，离散决策占大头，所以 CP-SAT 更实用。如果需要做纯线性规划，OR-Tools 底层也封装了相关的求解器，可以无缝切换。

2. 核心模块拆解：从一句话到一份可求解的模型

2.1 意图识别与问题类型判断

拿到用户输入后，第一步不是急着抽变量，而是判断这是哪类优化问题。同样是“最大化利润”，如果变量是连续的，可能是线性规划；如果变量是“选还是不选”，那就是整数规划；如果核心是“满足约束即可”而不是“最大化某目标”，那是约束满足问题。判断错了，后面建模方向全偏。

我在 Prompt 里要求 LLM 输出一个problem_type字段，取值是lp、mip、csp三种之一，并给出判断依据。为了让 LLM 判断得更准，我在 few-shot 示例里放了几个典型场景：比如“分配有限资源给多个任务，求总收益最大”对应lp或mip；“排班，每人每周最多上 5 天，求能否满足”对应csp。

这个分类看起来简单，但实际很有效。它还直接影响后续的求解策略：mip会设置较长的求解时间上限和 MIP gap；csp则优先搜索可行解，不需要目标函数都能跑。一个正确的意图分类，能省掉大量不必要的 Prompt 纠缠。

分类完了还要识别“求解目标”，也就是目标函数里的方向。用户说“降低成本”是 minimize，“提高收益”是 maximize，但说“平衡各产线负荷”时，目标函数经常要写成最小化方差或最大最小差值。这类表达不能只靠关键词匹配，需要 LLM 理解语义后给出一个数学上可实现的目标函数描述。

2.2 变量抽取：找出所有需要“拍板”的东西

变量就是决策里需要你做选择的东西。用户说“选出 5 个候选位置”，那变量就是“每个位置是否被选中”——布尔类型；用户说“给三个工厂分配产量”，那变量就是“每个工厂生产多少”——非负整数或连续类型。

我在 JSON Schema 里给每个变量定义了五个属性：name（变量名）、type（continuous/integer/boolean）、lower_bound、upper_bound、description（对这个变量含义的简要说明）。其中description是我后来加上的，求解完回译结果时非常有用——你不再需要去猜变量 x0 到底代表什么，直接从 JSON 里就能拿出来用。

有一个细节需要特别注意：变量抽取时，LLM 容易把逻辑中间量也当成决策变量。比如用户说“如果选择 A 仓库就不能选择 B 仓库”，这里“A 是否被选”是决策变量，“不能同时选”是约束，不是新变量。为了防止这种冗余，我在 Prompt 里强调：只抽取业务方可以直接控制的量作为变量，其他都由约束表达。这一步做干净了，后面建模的模型规模会小很多，求解速度也随之提升。

变量上下界的设定也很关键。用户没明说时，我默认布尔变量的下界是 0、上界是 1；整数变量默认下界 0、上界 9999，避免模型无解时业务方完全看不懂。后面的校验环节会再检查一遍：如果上界设得太离谱或者明显不符合常识，直接报错让你人工确认。

2.3 约束抽取：模糊表达如何变成数学不等式

约束抽取是整个项目中坑最多的部分。中文表达里的“不超过”“至少”“尽量”“必须”各有各的语义密度，翻译错了模型就跑偏。我总结了一套处理规则：

• “不超过”“最多”“不能高于” → 小于等于约束；
• “至少”“不少于”“不能低于” → 大于等于约束；
• “必须等于”“正好” → 等式约束；
• “尽量”“最好”“倾向于” → 软约束，不进硬性条件，放进目标函数加惩罚项；
• “要么选 A 要么选 B”“二选一” → 互斥约束或布尔变量关联。

举个典型例子。“每天工作时间不超过 8 小时”和“整个项目周期内每天平均不超过 8 小时”是两种完全不同的数学约束。前者是逐日的硬约束，后者需要引入一个连续变量“总工时除以天数”，再设上限。如果不加分析就直接生成x <= 8，模型会解读为前者，结果方案在业务上完全不可用。所以约束抽取模块必须做一件事：识别时间维度、主体维度和范围限定词，在抽取前先将自然语言拆解成“谁 + 在什么范围 + 限制条件是什么”。

软约束的处理我额外多说一句。不要直接丢弃“尽量”类表达，也不要把它硬塞进约束集合。正确做法是引入一个松弛变量和一个惩罚系数，把违背程度放进目标函数。比如“尽量均衡”可以写成目标函数里最小化各变量之间的最大差值，而不是约束里加“所有变量相等”。这样既尊重了业务偏好，又保证模型可解。

抽取完成后，约束集合用一个数组存起来，每一条包含：name、left_expression（左侧表达式）、operator（<=、>=、==）、right_value（右侧值）、is_soft（是否软约束）、penalty_weight（软约束惩罚系数）。有了这个结构，建模层遍历一次就能生成全部约束。

2.4 中间表达层：JSON Schema 就是你的“建模语言”

中间表达层是整个系统的心跳。我设计 Schema 时坚持三个原则：严格、完整、易校验。最终定下来的结构大致是这样：

{ "problem_type": "mip", "objective": { "direction": "minimize", "expression": "sum(transport_cost[i] * x[i] for i in sites)", "description": "总运输成本最小化" }, "variables": [ { "name": "x", "index": ["sites"], "type": "boolean", "lower_bound": 0, "upper_bound": 1, "description": "是否选择候选位置 i" } ], "constraints": [ { "name": "select_five", "expression": "sum(x[i] for i in sites) == 5", "operator": "==", "right_value": 5, "description": "恰好选择 5 个候选位置" } ] }

expression字段里我直接用类 Python 语法描述数学表达式。这样做的好处是求解层能直接 eval，不用再写一个数学表达式解析器。当然 eval 有安全风险，所以求值前必须做语法白名单校验，只允许sum、min、max、变量名、数字和加减乘除符号。

为什么不用 SMT 或者专门的建模语言表达式？因为 JSON 的通用性最好。LLM 生成 JSON 的成功率远高于生成代码，而且 JSON 可以直接用常规库解析，不需要依赖具体求解器的语法。后续即使把求解器换掉，中间表达层不用改，成本大大降低。

这一层还承担一个职责：可解释性。每个变量、每条约束都有description，所以就算你是第一次看这个模型，也能很快知道每一行在说什么。调试时拿这份 JSON 跟业务方确认，比拿一堆 x1、x2、x3 的数学公式靠谱多了。

2.5 合法性校验与自动修复

LLM 生成的 JSON 不可能 100% 合法。我遇到最多的问题包括：变量在约束里引用了但没定义、约束右侧值明显不对、变量上下界反了、表达式里有未知函数。所以在建模前加了一个校验函数，逐条检查：

1. 所有在约束和目标函数里出现的变量名，必须在变量列表里；
2. 变量下界必须小于上界；
3. 约束右侧值必须与实际变量范围和常识匹配；
4. 表达式经过白名单语法检查，不能包含import、exec这类危险操作。

如果校验失败，我不会直接报错，而是把错误信息反馈给 LLM，让它修正一次。这个“校验—修复”循环最多执行两轮，两轮还不过就直接人工查看 JSON。实测下来，加了这一层后，JSON 整体可用率从 70% 提升到 95% 左右，效果非常明显。

修复循环的成本也很低——一次 LLM 调用通常几百毫秒到一两秒，比人工去改结构快得多。但要注意给 LLM 提供清晰的报错信息，比如“变量 z 未定义”而不是笼统说“模型不合法”，它才知道怎么改。这一步做得好，整个系统的可用性就有保障了。

3. 实操过程：Prompt 设计、模型生成与求解器对接

3.1 Prompt 设计要点与一个可直接用的模板

Prompt 是这个系统里最核心的“代码”。我调试了很多版，总结出几个关键经验：

第一，给 few-shot 示例，不要只给规则。LLM 对“请输出 JSON”这种命令的理解，远不如直接给它三个完整的输入输出示例来得快。示例要覆盖不同问题类型，最好包含一个带软约束的案例，让它学会处理“尽量”类表达。

第二，严格限定输出格式。我在 Prompt 末尾加了“只输出 JSON，不要输出其他文字”。但实际测试时模型偶尔还是会加些解释话语。更可靠的办法是告诉它“把输出放在一个 markdown 代码块中”，然后用正则剥离代码块内容再解析 JSON，容错率更高。

第三，在 Prompt 里内置数学常识。比如提醒它：变量和约束的数量越少越好；能用布尔变量就不要用整数变量；尽量复用变量而不是为每个条件引入新变量。这能显著减少模型生成过程中冗余变量和冗余约束的数量，让求解速度更快。

下面是一个实际可用的系统提示词模板（进行了适度精简）：

你是一个数学优化建模助手。用户会给你一段自然语言描述的业务需求，你需要将其转化为结构化的 JSON 建模信息。 要求： 1. 识别问题类型：lp、mip、csp。 2. 抽取变量：只抽取业务方可直接控制的决策量，区分 continuous、integer、boolean 三种类型。 3. 抽取约束：将自然语言约束转化为数学表达式，使用合法的 Python-like 语法；优先使用已有变量，不要新增无关变量。 4. 目标函数：将业务目标（如成本、利润、均衡度）转化为 minimize 或 maximize 表达式；无法用线性表达时，请拆解为可计算的数学形式。 5. 输出格式：只输出 JSON，且必须包含 problem_type、objective、variables、constraints 四个字段。每条约束和变量都必须有 description 说明其含义。 6. 不要输出任何解释文字，不要使用 markdown 代码块包裹 JSON 以外的内容。 示例： 用户输入：从 10 个候选仓库中选出 4 个，使得总运输成本最低，且每个被选仓库的容量至少为 1000 件。 输出： {...}

温度我设置在 0 到 0.2 之间。温度太高会导致 JSON 结构不稳定，太低则会在多种合理建模方式中过于保守。回退策略是如果第一次输出解析失败，用温度 0.4 重新生成一次，经常能修复格式问题。

3.2 LLM 输出解析与容错处理

拿到 LLM 返回的文本，需要先做一层解析。我的处理顺序是：

import json import re def parse_llm_response(text): # 尝试直接解析 try: return json.loads(text) except json.JSONDecodeError: pass # 剥离 markdown 代码块 code_block = re.search(r"```(?:json)?\s*(\{.*\})\s*```", text, re.DOTALL) if code_block: try: return json.loads(code_block.group(1)) except json.JSONDecodeError: pass # 兜底：寻找第一个 { 和最后一个 } left = text.find("{") right = text.rfind("}") if left != -1 and right != -1 and right > left: fragment = text[left:right + 1] try: return json.loads(fragment) except json.JSONDecodeError: return None return None

第一次写这个函数时我漏了“剥代码块”这一步，导致大量 JSON 因为前面多了三个反引号解析失败。后来学乖了，按照“直接解析 → 剥代码块 → 切 JSON 片段”三级策略处理，成功率提升非常多。

还有一个容易被忽略的细节：LLM 有时会在 JSON 里输出中文变量名，比如“仓库_i”。虽然 Python 表达式也能处理这种名字，但 OR-Tools 对变量名的类型和处理逻辑更挑剔，我倾向于在解析阶段就把所有非 ASCII 变量名统一替换成x0、x1这种格式，并保留映射关系，方便回译时还原。

解析出来的 JSON 先入库缓存一份。因为同一个业务问题，如果只是参数变了，你可以复用解析结果，不需要重新调用 LLM。这一步对成本控制帮助很大。

3.3 从 JSON 到 OR-Tools：建模与求解代码

下面这段代码演示了如何把 JSON 模型转换为 OR-Tools CP-SAT 模型。我这里展示核心逻辑，实际项目中你会发现各类型表达式分歧较大，需要不断扩展表达式解析，建议把表达式解析单独抽成一个函数。

from ortools.sat.python import cp_model def build_model(model_json): m = cp_model.CpModel() vars_map = {} # 创建变量 for var in model_json["variables"]: vtype = var["type"] lb = var.get("lower_bound", 0) ub = var.get("upper_bound", 9999) name = var["name"] if vtype == "boolean": v = m.NewBoolVar(name) elif vtype == "integer": v = m.NewIntVar(int(lb), int(ub), name) else: v = m.NewIntVar(int(lb), int(ub * 1000), name) # 连续变量近似为整数 vars_map[name] = v # 添加约束 for cons in model_json["constraints"]: expr = parse_expression(cons["expression"], vars_map, m) op = cons["operator"] rhs = cons["right_value"] if op == "<=": m.Add(expr <= rhs) elif op == ">=": m.Add(expr >= rhs) else: m.Add(expr == rhs) # 设置目标 obj_expr = parse_expression(model_json["objective"]["expression"], vars_map, m) if model_json["objective"]["direction"] == "minimize": m.Minimize(obj_expr) else: m.Maximize(obj_expr) return m, vars_map def solve_model(m): solver = cp_model.CpSolver() solver.parameters.max_time_in_seconds = 30 solver.parameters.relative_gap_limit = 0.05 status = solver.Solve(m) return status, solver

连续变量这里我用“乘以 1000 变成整数”的方式做近似，绝大多数业务场景精度足够。后续如果需要更高精度，可以换成 OR-Tools 内部的线性规划求解器，或者直接用 HiGHS 的扩展接口。

parse_expression函数负责把 JSON 里的表达式字符串变成 CP-SAT 对象。实现思路是：先做词法分析，把变量名、数字、操作符拆开，递归下降解析乘除和加减，遇到sum(x[i] for i in sites)这种生成器表达式时，转成所有变量的和再加起来。这块代码写起来比较原始，但测试覆盖做好后运行非常稳定。

求解参数我设置了 30 秒的上限和 5% 的相对 gap。实际业务中，30 秒基本能找到还不错的解；如果 30 秒内找不到最优解，CP-SAT 会返回当前最优可行解，并告诉你 gap 是多少。对于内部工具型系统，这种“差不多最优”的方案通常已经能让业务方满意了。

3.4 结果回译：把 x1=1、x2=0 变回人话

求解器返回的是一堆数字：x0 = 1、x1 = 0、x2 = 1。如果直接把这个丢给业务方，肯定不行。结果回译层要做的事是：结合原始 JSON 里的description字段，把每个变量的取值还原成业务含义。

我采用基于模板的生成方式，而不是让 LLM 自由发挥。因为 LLM 自由发挥有个风险：它会“脑补”一些求解器没算出来的细节，编造成本、收益、时间等数据，造成业务决策错误。模板方式如下：

根据优化计算结果，优化方案如下： - 候选位置 1：选择（原因：运输成本 120 万元） - 候选位置 3：选择（原因：运输成本 95 万元） 综合评估，本方案总运输成本为 312 万元，比原方案降低约 18%，满足容量不低于 1000 件的约束要求。

成本数据从哪来？这些应该从输入里带出来，或者在建模前由业务方补充录入。如果只通过自然语言输入，模型没法算出“成本 120 万元”，除非用户输入时就带了。所以我在设计 JSON Schema 时额外加了一个context_data字段，用于存放数据表或参数表，建模层从里面取值计算目标函数和约束值。回译模板直接引用这些数据，保证每个数字都有出处。

如果想让回译结果更生动，可以先用模板生成，再让 LLM“只润色语言，不改动数据”。但要在 Prompt 里明确强调“不要新增任何数据”，否则它还是会给你加戏。实测下来，加了这句限制后，编数据的情况大幅减少。

4. 常见问题与排查技巧实录

4.1 结构化输出不稳定：模型不按 JSON 出牌

这个问题太常见了。即使 Prompt 写了“只输出 JSON”，模型还是会在前面加一句“好的，这是为您生成的 JSON”。遇到这种情况，不要试图在 Prompt 里反复加强措辞，而是做好解析容错。我上面写的那段解析代码，就是专门对付这类问题的。

另一个大招是 few-shot 里放一个“错误示例”：给一个模型输出带解释文字的例子，再给一个正确的 JSON 示例，让它对比着学。大模型对对比学习很敏感，这比单纯强调“只输出 JSON”有效得多。

如果模型连续三次输出都无法解析，我会启动降级策略：调用一个更便宜的快速模型重新生成，或者让用户确认是否愿意拉长响应时间。毕竟系统是给人用的，不能因为一个解析错误就让整个流程卡死。

4.2 专业术语和业务隐语：模型听不懂“红线”“三班倒”

业务方经常说一些只有内部人才懂的词。比如排产系统里的“红线”指某个关键设备不可用时段，“三班倒”指一天分早中晚三班，每班 8 小时。这些词直接丢给 LLM，它大概率建模错误。

我的解决办法是在 Prompt 里内置一个术语映射表，或者在 LLM 解析前先做一轮“同义归一”。具体做法是：维护一个术语词典，把常见业务隐语映射成标准数学表达里的“设备不可用约束”“每天三班制”等。词典一开始人工维护，跑一段时间后把 LLM 成功解析过的“隐语 → 标准表达”对追加进去，越用越准。

这个词典的维护成本不高，但收益极大。我项目里大概积累了两百多对映射词后，绝大部分常见业务描述都能一次解析成功。

4.3 数字单位和时间粒度混淆，模型建模错得悄无声息

我遇到过最隐蔽的问题来自这句话：“每个工人每周工作时间不超过 40 小时。”LLM 把“每周”理解成约束的周期，建模成sum(work_hours) <= 40。但它没意识到：如果每周限制成立，那么每天平均其实只需 8 小时；但这个约束是从整周视角出发，中间可能出现某天干 14 小时、另一天只干 2 小时的“合法”方案，而业务方真正想要的是每天 8 小时封顶。这种错误如果不拿回给业务方确认，几乎不可能发现。

解决方案是：在抽取约束时，把时间粒度作为独立字段提取出来（time_granularity），然后由建模层决定是否需要展开成多个约束。我最终的做法是让 LLM 在输出 JSON 时，对于所有时间类约束额外给出一个time_scope字段，比如per_day、per_week、total。建模层根据这个字段决定约束是逐日展开还是汇总成一条。

单位混淆问题同理。“成本 5 万元”和“成本 50000 元”建模结果完全一样，但如果输入里出现“5 万”而数据表里单位是“元”，表达式解析时就会出错。我的兜底策略是在context_data里强制所有数值统一单位，LLM 解析阶段就把“万”“亿”等数量词换算成标准数字。

4.4 模型无解：连“死棋”都找不出来怎么办

CP-SAT 求解无解时，不会告诉你“哪条约束出问题”，只会返回一个INFEASIBLE状态。新手看到这个状态直接懵了。我推荐的做法是启动“不可行性分析”或“约束松弛”流程。

OR-Tools 里没有直接给出冲突集，但我们可以自己做一个简化版：把所有约束逐条移除，重新求解，如果去掉某条后模型可解，就说明这条约束与别的约束冲突。或者反过来，从空约束开始逐条加入，找到第一条导致不可解的约束。这个方法测试起来比较笨，但业务规模不大时很实用，基本能定位到冲突点。

另外，可以在 Prompt 阶段就减少无解概率：要求 LLM 给所有硬约束加一个“可松弛”标记。我在 JSON Schema 里给每条约束加了can_relax字段，默认 false。建模时如果求解器判定不可行，自动对can_relax=true的约束加上松弛变量并设置惩罚，告诉业务方“如果放宽某条约束，可行解存在，且目标值会变化多少”。这种“软硬分离”设计在落地过程中帮了大忙。

4.5 求解性能：从 200 秒到 4 秒的优化心法

业务模型不会永远停留在二三十个变量的小规模。当候选位置增加到几百个，或者排班问题有几十个人乘三十天时，CP-SAT 的求解时间可能从秒级直接翻到分钟级。我的优化策略排序如下：

1. 减少变量数。这是性价比最高的优化。如果 100 个候选位置里只有 80 个真的值得考虑，就先把明显差的选项过滤掉。这个过滤逻辑可以在 Prompt 阶段让 LLM 忽略，也可以在建模层后处理。
2. 收紧变量上界。比如库存变量的上界从 9999 改成实际最大库存 2000，CP-SAT 的搜索空间能大幅缩小。
3. 加 MIP gap 和 time limit。追求“差不多最优”而不是“绝对最优”，大多数业务场景下 5% 的 gap 完全能接受。
4. 使用 hint 初始解。我试过先用启发式生成一个可行解作为 CP-SAT 的 hint，求解速度提升非常明显。比如选仓库问题，先用贪心思路选 5 个成本最低的位置，把这个解作为 hint 传给求解器，它在这个基础上做局部搜索，比从零开始快得多。

实测数据：一个 120 个布尔变量、40 条约束的选址模型，不设 time limit 时跑了 180 秒还没收敛，设置 10 秒时间限制和 5% gap 后，3 秒返回一个只差最优解 2% 的方案，业务上完全够用。

下面把常见坑整理成一个速查表，方便你直接对着排查：

结尾：一点个人心得

整套系统从立项到第一个完整可用的 Demo，大概花了三周时间。第一版只有“LLM 出 JSON + OR-Tools 求解”这条最简链路，甚至没有校验和回译层，纯粹的“翻译 + 计算”。后来在真实业务场景里跑了一周，才陆续补上校验、修复、结果回译和术语映射。所以如果你也想复刻这个系统，我的建议是千万不要一上来就设计一个“全自动完美方案”，先把最简链路跑通，哪怕只支持一种问题类型、十几个变量的规模，也足够验证这件事靠不靠谱。

我在实际运营中发现，最容易被低估的是“语料库”的价值。每个成功解析的输入输出对，都值得存下来，它就是你的训练集和测试集。每次改 Prompt 或者调系统，先用这批历史用例跑一遍回归，比什么都管用。我个人体会是，这个系统的瓶颈从来不是求解器，而是语言到模型的翻译质量——翻译做好了，所有后续环节都会非常顺。后续如果想把系统推向生产，可以考虑加入多轮对话修正、自动生成求解报告、对接实物数据源这些方向，但这些都是后话了，先把 0-1 这一版跑踏实，再去想 1-10 的事。