做这个项目之前我一直有个执念业务部门嘴里那些“差不多”“尽量均衡”“别太过分”到底能不能变成一行行严谨的数学约束前两年做制造业排产和物流路径优化的项目每次都有一段极其痛苦的沟通——业务方用自然语言描述需求算法团队把它翻成线性规划模型。翻译过程中语义损失、边界模糊、目标函数拍脑袋返工是家常便饭。后来大语言模型的能力上来了我就在想能不能让 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 gapcsp则优先搜索可行解不需要目标函数都能跑。一个正确的意图分类能省掉大量不必要的 Prompt 纠缠。分类完了还要识别“求解目标”也就是目标函数里的方向。用户说“降低成本”是 minimize“提高收益”是 maximize但说“平衡各产线负荷”时目标函数经常要写成最小化方差或最大最小差值。这类表达不能只靠关键词匹配需要 LLM 理解语义后给出一个数学上可实现的目标函数描述。2.2 变量抽取找出所有需要“拍板”的东西变量就是决策里需要你做选择的东西。用户说“选出 5 个候选位置”那变量就是“每个位置是否被选中”——布尔类型用户说“给三个工厂分配产量”那变量就是“每个工厂生产多少”——非负整数或连续类型。我在 JSON Schema 里给每个变量定义了五个属性name变量名、typecontinuous/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% 合法。我遇到最多的问题包括变量在约束里引用了但没定义、约束右侧值明显不对、变量上下界反了、表达式里有未知函数。所以在建模前加了一个校验函数逐条检查所有在约束和目标函数里出现的变量名必须在变量列表里变量下界必须小于上界约束右侧值必须与实际变量范围和常识匹配表达式经过白名单语法检查不能包含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 结果回译把 x11、x20 变回人话求解器返回的是一堆数字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_relaxtrue的约束加上松弛变量并设置惩罚告诉业务方“如果放宽某条约束可行解存在且目标值会变化多少”。这种“软硬分离”设计在落地过程中帮了大忙。4.5 求解性能从 200 秒到 4 秒的优化心法业务模型不会永远停留在二三十个变量的小规模。当候选位置增加到几百个或者排班问题有几十个人乘三十天时CP-SAT 的求解时间可能从秒级直接翻到分钟级。我的优化策略排序如下减少变量数。这是性价比最高的优化。如果 100 个候选位置里只有 80 个真的值得考虑就先把明显差的选项过滤掉。这个过滤逻辑可以在 Prompt 阶段让 LLM 忽略也可以在建模层后处理。收紧变量上界。比如库存变量的上界从 9999 改成实际最大库存 2000CP-SAT 的搜索空间能大幅缩小。加 MIP gap 和 time limit。追求“差不多最优”而不是“绝对最优”大多数业务场景下 5% 的 gap 完全能接受。使用 hint 初始解。我试过先用启发式生成一个可行解作为 CP-SAT 的 hint求解速度提升非常明显。比如选仓库问题先用贪心思路选 5 个成本最低的位置把这个解作为 hint 传给求解器它在这个基础上做局部搜索比从零开始快得多。实测数据一个 120 个布尔变量、40 条约束的选址模型不设 time limit 时跑了 180 秒还没收敛设置 10 秒时间限制和 5% gap 后3 秒返回一个只差最优解 2% 的方案业务上完全够用。下面把常见坑整理成一个速查表方便你直接对着排查问题现象可能原因排查手段JSON 解析失败模型输出多余文字或代码块包裹异常剥代码块 切 JSON 片段三级解析变量名冲突或未定义LLM 抽取变量时命名不规范校验函数统一检查报错后让 LLM 修复一次目标函数建模方向相反“成本最低”与“利润最低”表达混淆在 Prompt 中加入明确的最小/最大方向抽取并二次校验模型无解约束过强、互相矛盾约束松弛标记 逐条移除定位冲突求解时间过长变量数量太多、上界过宽减少变量数、收紧上界、设置 time limit 和 gap回译结果与求解不符LLM 润色时脑补数据回译只走模板不动数据润色时明令禁止新增数字结尾一点个人心得整套系统从立项到第一个完整可用的 Demo大概花了三周时间。第一版只有“LLM 出 JSON OR-Tools 求解”这条最简链路甚至没有校验和回译层纯粹的“翻译 计算”。后来在真实业务场景里跑了一周才陆续补上校验、修复、结果回译和术语映射。所以如果你也想复刻这个系统我的建议是千万不要一上来就设计一个“全自动完美方案”先把最简链路跑通哪怕只支持一种问题类型、十几个变量的规模也足够验证这件事靠不靠谱。我在实际运营中发现最容易被低估的是“语料库”的价值。每个成功解析的输入输出对都值得存下来它就是你的训练集和测试集。每次改 Prompt 或者调系统先用这批历史用例跑一遍回归比什么都管用。我个人体会是这个系统的瓶颈从来不是求解器而是语言到模型的翻译质量——翻译做好了所有后续环节都会非常顺。后续如果想把系统推向生产可以考虑加入多轮对话修正、自动生成求解报告、对接实物数据源这些方向但这些都是后话了先把 0-1 这一版跑踏实再去想 1-10 的事。