1. 高能耗企业的能源优化为什么老办法到了天花板前段时间去一家大型制造企业做能耗诊断他们厂区里有8台大型空压机、两组冷却塔、一座上千平米的恒温车间。电费账单每个月都在刺痛管生产的副总的神经。他们在用的系统并不差有基础的SCADA、有历史数据库、有一套外采的能源管理平台平台里灌了专家规则和几个回归模型。可问题恰恰在于这套系统“很聪明但不会自己进化”。传统能源优化项目我做过不少套路基本逃不出三类第一类靠老师傅经验手动调参比如“夜班峰谷电价时段关掉两台空压机压力下限保持0.55MPa”。第二类建立机理或统计模型做预测把未来的负荷、温度、电价作为输入算出最优运行区间。第三类直接上数学规划或者启发式算法比如混合整数规划MILP、遗传算法、粒子群这类把复杂的启停组合问题交给求解器跑。这三类方案在教科书里很漂亮但到了现场我却见过太多项目死在“现场工况不满足算法假设”这一步。以空压机群为例最经典的优化目标是“在满足用气负荷的前提下让电耗最小”。可实际生产里用气负荷本身是波动的管道容量有缓冲各台空压机的能效曲线随着老化和环境温度漂移再加上峰谷电价、维护计划、备用要求……这些约束叠在一起单纯建一个MILP模型光是把约束写全就要折腾两个月写完还不敢让调度员信。数据驱动的AI同样有边界。很多团队尝试过用深度强化学习直接控制设备启停和设定值训练出来的策略在仿真环境里表现不错一上现场就露怯。原因很直观强化学习需要大量“试错”而工厂不可能让你拿价值几百万的设备去反复试错。于是策略只能靠离线数据训练学到的往往是历史数据里“最常见的操作模式”而不是“最优的操作模式”。这也是为什么当“大模型设计互补算法”这个思路出现时我一下就来了兴趣。它跟常规的“用大模型做预测”“用大模型做调度”完全不同。它的核心不是让大模型自己去替代整个优化系统而是让大模型扮演“算法设计师”快速生成一批小巧的、可解释的、能与既有系统配合的补充算法模块。这些模块的作用是把那些老办法够不着的角落填补起来形成一套“主系统互补算法”的组合拳。这篇文章我会把整条路线的逻辑、做法、落地步骤和踩过的坑都摊开讲。适合正在做工业能源优化项目的工程师、做AI落地的算法同学以及被电费压得头疼的企业技术负责人看。内容尽量不端着你可以直接抄作业。2. “互补算法”到底补什么与主系统的三组协作关系先界定一个关键概念什么叫互补算法。我把它定义为运行在既有能源管理系统之外不与主系统抢地盘而是对主系统的输出做修正、补充、扩展的小型算法模块。它可以是几条判断规则可以是一个轻量的回归模型也可以是一段用于缩小搜索空间的剪枝逻辑。它的核心特征是“补位”而不是“替代”。这三组协作关系是我在项目里最常遇到的。2.1 与预测模型互补填上规则盲区大部分企业已经上了负荷预测模块用历史数据预测未来半小时的用电负荷。预测模型擅长处理“平稳波动”但遇到生产节奏突变就失灵——比如一条产线临时加单、空压机因故障跳停、天气骤变导致车间负荷突变。这些事件在历史数据里往往样本极少预测模型学不到。互补算法在这里的角色是针对这些“长尾场景”设计专门的修正规则。大模型可以读设备日志和维护记录把“故障后的负荷反弹特征”“加单后的设备启停节奏”这种隐性知识提取出来转化成几条可执行的修正公式或规则叠加在预测输出之上。拿我参与过的制冷站项目举例。常规做法是用随机森林预测冷冻水负荷效果一直不错但每逢周一早上负荷都会异常升高预测总是滞后一拍。后来我们让大模型分析三个月的工单记录发现周一早班启动的设备数量比平时多15%——这不是历史负荷能看出来的规律是生产计划信息。把它写成一条“周一早班负荷修正系数”规则后预测误差直接降了三分之一。2.2 与求解器互补给MILP提供热启动和剪枝方向大型能源优化通常绕不开数学规划。无论是空压机机组组合、窑炉升温曲线安排还是蓄冷罐的充放策略本质都是大规模组合优化。MILP求解器比如Gurobi、Cplex能保证最优解但计算时间经常长得无法接受尤其是约束复杂、变量上万的时候。互补算法在这里的职责是“帮求解器少走弯路”。具体手段有三种一是生成高质量热启动解让求解器从一个不错的可行解开始分支二是设计剪枝规则把明显不可能进入最优解的变量空间先排除掉三是动态调整部分参数——比如把某些设备的启停次数上限从代码硬编码改成根据当前工况实时计算的软约束。有次做一个电力需量优化项目8台大功率设备的启停组合要满足最大需量约束MILP模型求解一次要40多分钟根本没法做实时滚动优化。我们让大模型产出一组“优先级启发式规则”——基于设备能效、当前负载率、历史启停次数给设备排序排序靠前的优先开启。把这个规则作为热启动喂给求解器之后求解时间压到了4分钟以内解的质量损失不到1%。这正是“互补”的价值所在不碰求解器内部逻辑只是通过外围算法帮它把搜索空间缩小。大模型强在知识迁移和模式总结它未必能写出比求解器更好的数学框架但它知道“这种场景下哪种搜索方向大概率有效”。2.3 与人工经验互补把老师傅的隐性知识显式化高能耗企业的能源优化现场往往有几位特别厉害的老师傅。他们不需要看任何仪表听空压机的声音就知道该开哪台、该关哪台。但他们一旦退休这些经验就跟着人走了你再多的数字模型也补不回来。大模型在这些年积累了大量通用知识又擅长从文本中归纳信息。我们可以把老师傅的操作日志、交接班记录、调度说明、异常处理报告扔给大模型让它把这些非结构化文本里的经验抽出来变成结构化规则。这项工作放在以前需要知识工程师做几个月的访谈和编码但现在大模型几小时就能出第一版草案再由老师傅做复核确认。需要注意这不是为了替代老师傅而是帮他“留一手”。我们项目里有一次做得特别顺老师傅提到“下雨天的夜里冷却塔效率偏高可以晚半小时开启第二台塔”。这句随口一说的话被大模型转换成了包含天气、时段、冷却塔效率阈值的可执行规则后来整个夏天都靠这条规则省下了可观的电费。3. 大模型设计算法的技术路径迭代生成、验证与筛选那么大模型具体是怎么“设计”出这些算法的光靠一次Prompt问它“给我写个节能算法”它只能给你一个看起来很漂亮但完全不可用的泛泛方案。真正能落地的流程是一个“生成-评估-进化”的闭环。3.1 前置工作把工艺约束翻译成机器可执行的数据契约这一步是整个流程的地基做不好后面全是空中楼阁。所谓数据契约就是把现场的物理设备、运行参数、约束条件和大模型的输入输出格式统一起来。我习惯让大模型先读一遍设备台账、管道拓扑说明书和历史数据字段清单然后输出一份JSON Schema描述设备ID、设备类型、启停状态、功率、负荷率、环境温度、时段电价、生产计划标记等等。这份Schema就是大模型后续生成算法时的“世界模型”——它必须严格遵守。为什么要这么做因为大模型的幻觉问题在自由生成时尤其严重。如果不给它强约束它很可能设计出一个“每5分钟启停一次空压机”的规则——物理上完全不可能压缩机会直接报废。有了数据契约我们在生成阶段就能做第一轮硬校验把不符合物理常识的输出直接丢掉。数据契约的产出格式不复杂但定义过程要非常考究。比如“时段电价”是取实时值还是预测值“生产计划标记”的粒度是分钟还是小时“设备启停次数上限”从哪张表里读取这些问题都要在契约里写明白。我见过不少项目卡在这一步因为现场数据库字段命名混乱描述文档又严重滞后导致大模型生成的算法根本读不到正确数据。3.2 核心循环生成候选规则、仿真评估、反馈进化数据契约就位后进入核心循环。我通常把这个过程封装成一个“算法孵化器”自动化程度可以很高。第一步是大规模生成。给大模型输入一段任务描述比如“请设计一组用于夜间空压机群节能调度的规则目标函数是电费最小化约束条件见数据契约”。要求它输出5到10条候选规则每条规则都包含触发条件、执行动作、预期收益和风险说明。第二步是仿真评估。必须有一个基于历史数据或者机理模型的仿真环境。把候选规则放到仿真环境里去跑历史场景统计每天的能耗、电费、设备启停次数、压力波动等指标。这一步不能省也是项目里最花时间的部分。第三步是反馈进化。把仿真评估的结果哪些规则效果好、哪些不理想、偏差出在哪里反馈给大模型让它基于上一次的结果做修正。比如“你上轮生成的规则A在夜间高压时段有效但在午间低压时段导致压力偏低请修改触发条件”。循环迭代直到候选规则在历史数据上的表现稳定达标。这套循环本质上是一种“算法层面的进化搜索”。大模型在这里面扮演的不是演绎推理者而是一个高效的模式生成器——它把从无数代码、论文、工业文档中学到的算法套路按照当前任务需求重新组合。它一次能产出大量候选然后由仿真器做裁判淘汰劣质方案保留优秀方案。这比人工写规则快了一个数量级而且不依赖某个专家全程盯场。3.3 筛选标准互补增益比绝对最优更重要仿真评估里最容易犯的错误是拿单独运行效果来评判候选算法。前面反复强调过这些算法是“补位”的它必须和主系统协同工作才有效。所以评估标准不是“这条规则单独跑能省多少电”而是“在现有系统的输出基础上叠加这条规则后系统整体能省多少电”。这个“互补增益”的度量方式我一般用三个指标看整体电费下降幅度、设备运行稳定性启停次数变化、调度员采纳率这条规则是否减少了人工干预。三者缺一不可。有个项目让我印象很深。孵化器产出一条“蓄冷罐放冷时间提前1小时”的规则单独评估时它让蓄冷罐在高峰时段的放冷量更充足电费看起来降了不少。但放进主系统跑联动仿真发现提前放冷导致低谷时段的充冷量不足第二天的蓄冷罐在下午三点就放空了反而增加了晚高峰的电费。这个例子说明只看局部不看协同很容易被假增益误导。所以我在筛选阶段会坚持做“系统级A/B测试”而不是“规则级A/B测试”。候选规则必须放到完整的主系统闭环里跑和纯主系统的基线做对比。哪怕一条规则单独看很平庸只要能让系统整体稳定提升它就值得保留反之一条单独看效果惊艳但干扰主系统的规则再漂亮也要砍掉。4. 一条可参考的落地路线从搭建实验台到影子部署讲完技术原理说说落地层面的实操路线。这条路我带着团队走过几遍现在基本形成了固定的四段式流程。4.1 第一步基线和工况库是评判的唯一标尺无论算法写得再好没有基线就没法证明价值。上线之前必须先把“现有系统人工操作”在当前工况下的表现完整记录下来作为对照基准。同时建立一个工况库把过去至少三个月的生产数据按工况分桶——高温日、低温日、峰谷电价差异大或小的日子、生产满负荷或半负荷的日子。这步最大的价值是让评估有了锚点。后面不论是大模型生成算法还是参数调优全部以“在相同工况下比基线省了多少”为最终度量。没有工况库你在夏天训练出来的算法到了冬天可能完全不适用有了工况库每次迭代都能在历史全工况上回归验证防止过拟合。4.2 第二步在“算法孵化器”里批量试错所谓算法孵化器就是一套把数据契约、大模型调用、仿真环境和评估脚本串起来的工具链。你可以用Python每天跑几十个循环每次生成新的算法变体丢进仿真器跑历史工况再自动汇总指标写回日志。整个过程不需要人工介入算法工程师的工作从“手写规则”变成了“审核大模型产出”。我建议这一步尽量自动化但保留一个人类审查舱位。千万不要让大模型自动把规则直接推给现场执行这个红线必须盯死。每一批备选规则在进仿真前至少要有一个人眼扫一遍排除明显离谱的输出。自动化之后你能明显感觉到效率的跨代提升。同等工作量下过去人工写规则一个月出三五个版本已经是极限现在孵化器一个周末就能跑出几十个版本关键不是数量而是这些版本覆盖了更多以前没考虑过的边界工况。4.3 第三步沙箱对拍和在线影子验证仿真通过是第一步但仿真终归是“过去的数据”现场环境还有仿真里模拟不了的噪声。所以在正式上线前我强烈建议做一轮“影子部署”——也就是新算法和现有系统并行运行新算法只出建议、不直接执行由调度员对照着看连续跑两到四周。影子部署阶段要重点观察几个问题建议被采纳的比例有多高有没有出现算法建议和现场安全约束冲突的情况算法在极端工况下的反应是否合理这些观察数据再反馈回孵化器做最后一轮微调。我遇到过最典型的情况是仿真里表现很好的规则一到现场就被调度员否了原因不是电费算得不对而是规则要求“两台空压机同时切换”现场操作规程只允许逐台切换。这个约束写在操作规程PDF里数据契约里没体现仿真器更不知道。影子部署、人工复核是发现这类“隐性约束”的唯一办法。4.4 上线前必须完成的两个审查到了这一步进入上线流程。除了常规的IT安全审查我还坚持做两个“非技术”审查。第一个是操作风险审查。逐条跑一遍算法在极端工况下的行为——比如所有负荷同时涌来、设备突发故障、电价尖峰——确认算法不会给出危险动作建议。算法不需要在所有情况下都最优但必须在所有情况下都不造成安全风险。这条是红线中的红线。第二个是解释性审查。找现场调度员和工程师请他们用大白话复述每条推荐规则背后的逻辑。如果他们说不出来、或者理解的和算法实际执行的不一致这条规则就必须改进。算法优化能源用得再漂亮如果不能变成一线人员信任和理解的工具最终只会被关掉。5. 实测中的坑这些是我认为你必须绕开的地方项目做多了踩坑是免不了的。我把记忆最深、最容易重复犯的几个坑拎出来给后面做同类项目的人提个醒。5.1 幻觉不只会编事实更会编出看似严谨的约束大模型的幻觉问题在“设计算法”这个场景下尤其危险。因为算法输出看起来特别专业充满了公式、参数和看似合理的假设很容易让人放松警惕。有一回孵化器生成了一条“动态压力设定值规则”规则里引用了一个“容积效率系数0.87”的假设。看起来没什么问题但对照设备铭牌一看实际容积效率是0.92。这个0.05的误差传导到压力设定值上会导致空压机长时间在错误的高压区间运行一个月下来多耗几万度电。处理办法只能是在数据契约里把一切参数来源都锁死。所有物理常数、设备参数、价格数据必须从数据库或设备台账读取不允许大模型“凭经验给出”。翻译成人话就是大模型只负责编逻辑不负责编数字。每次生成的结果还要做一次参数一致性校验凡是在契约里找不到依据的数字一律打回重写。5.2 搜索空间收敛过快可能只是过拟合孵化器的迭代机制有个隐患如果反馈信号过于单一比如只盯电费指标大模型产出的规则会迅速收敛到同一个套路。初期迭代很有创造力迭代十几轮之后每轮生成的规则开始长得越来越像几乎是在同一个模板上微调参数。原因在于大模型的偏好跟随性和评估指标的选择性。如果评估指标里没有纳入足够多的维度设备磨损、响应延迟、负荷波动等它就会把搜索空间里的多样性快速牺牲掉以换取单一指标上的局部最优。我的对策是在反馈里同时喂“正面样本”和“负面样本”。不仅要告诉大模型哪些规则跑得好也要展示那些被淘汰的规则在什么工况下表现得意外不错。这相当于逼着生成器保留探索空间不要只往一个方向钻。另外一个土办法是定期加噪声——随机离散化一些阈值参数让规则不会在某个精确到小数点后三位的数值上“焊死”。5.3 忽略运维侧的“两班倒”现实烧钱买大模型、跑算法、搭孵化器都很容易让人陷入技术的兴奋里。但现场真正的执行者是两班倒的运维师傅他们的工作习惯和注意力水平才是算法能否落地的最后一道关。有次我们设计了一套很智能的制冷站启停规则逻辑完全正确省电效果也验证了。但上线后发现采纳率不到两成。回访才知道运维师傅在夜班要看十几个监控画面根本不会盯着我们算法的推荐弹窗看。再好的建议在执行端缺一条可靠触达路径就是零。后来我们把推荐输出集成到了他们的即时通讯工具每天定时推送三句话格式的指令“建议14:30开启2号冷却塔”“建议15:00关闭1号冷冻泵”采纳率立刻回到七成以上。这个教训让我明白算法设计的最后一步不是代码是“人机交互接口”。要让算法推荐真正被用起来输出方式必须适配执行者的工作流而不是要求执行者适配算法。5.4 成本与反馈时延的平衡大模型的API调用有真实成本迭代频繁了光调用费就够喝一壶。更麻烦的是时延——完整跑一轮“生成-仿真-评估”可能要十几分钟其中仿真占大头但大模型生成本身也不便宜。我的经验是分阶段控制调用频次初期探索阶段每次生成50条候选覆盖更大的想法空间到了收敛阶段改成每次只生成10条重点做局部微调。另外尽可能复用大模型的中间产出——比如让同一批规则共享一个“场景特征分析”结果而不是每条规则都重新让大模型分析一遍工况。可以省大概三分之一到一半的调用量。动辄上百轮的迭代配合并发池跑一个中型项目下来成本还能接受。但如果放任不管成本会迅速失控。建议在孵化器里加一个简单的预算控制逻辑超出预算自动降级为低质量模型或者减少每轮候选数量。6. 一个可以立刻动手的小实验文章最后分享一个轻量级的实验思路。不需要太重的工业环境哪怕你只有一段历史数据也能跑通。选一个你熟悉的小场景比如办公室空调群控、公司机房精密空调、或者某个车间的水泵机组。关键是数据可获取、边界清晰。评估器写好是这个实验的灵魂。我的做法是写一个纯Python的模拟函数把历史数据里的负荷序列和电价序列作为输入给定一套启停规则返回总电费和舒适度指标。评估器一定要比规则本身更早写出来。让大模型产出一批规则放在这个评估器里跑历史数据看哪些规则在历史上能省钱。然后挑历史表现最好的三条规则人工检查一遍逻辑合理性再决定要不要在实际场景里试运行。整个实验从开始到看到第一版效果快的话一到两周就能完成。虽然规模小但能让团队完整跑通“大模型生成算法-评估器验证-人工复核-部署”全链路。等做好了再把同样的一套方法平移到空压机群、制冷站这类更复杂的场景。根据我个人经验必须提醒一点这个实验的价值不在最终的几条规则本身而在于建立评估文化和校验习惯。我在实际项目中最大的体会是大模型设计算法这条路的前景很好但真正让它能产生价值的不是模型本身有多聪明而是你有没有一套能把“模型产量”变成“可靠产能”的工程脚手架。数据契约、仿真评估、A/B筛选、影子部署这些听起来不那么炫的硬功夫才是这条新路线真正走得通的地方。 
长河君 · 2026/10/28 17:32:37 · 阅读 1.2k 大模型设计互补算法：工业能源优化新路径
1. 高能耗企业的能源优化为什么老办法到了天花板前段时间去一家大型制造企业做能耗诊断他们厂区里有8台大型空压机、两组冷却塔、一座上千平米的恒温车间。电费账单每个月都在刺痛管生产的副总的神经。他们在用的系统并不差有基础的SCADA、有历史数据库、有一套外采的能源管理平台平台里灌了专家规则和几个回归模型。可问题恰恰在于这套系统“很聪明但不会自己进化”。传统能源优化项目我做过不少套路基本逃不出三类第一类靠老师傅经验手动调参比如“夜班峰谷电价时段关掉两台空压机压力下限保持0.55MPa”。第二类建立机理或统计模型做预测把未来的负荷、温度、电价作为输入算出最优运行区间。第三类直接上数学规划或者启发式算法比如混合整数规划MILP、遗传算法、粒子群这类把复杂的启停组合问题交给求解器跑。这三类方案在教科书里很漂亮但到了现场我却见过太多项目死在“现场工况不满足算法假设”这一步。以空压机群为例最经典的优化目标是“在满足用气负荷的前提下让电耗最小”。可实际生产里用气负荷本身是波动的管道容量有缓冲各台空压机的能效曲线随着老化和环境温度漂移再加上峰谷电价、维护计划、备用要求……这些约束叠在一起单纯建一个MILP模型光是把约束写全就要折腾两个月写完还不敢让调度员信。数据驱动的AI同样有边界。很多团队尝试过用深度强化学习直接控制设备启停和设定值训练出来的策略在仿真环境里表现不错一上现场就露怯。原因很直观强化学习需要大量“试错”而工厂不可能让你拿价值几百万的设备去反复试错。于是策略只能靠离线数据训练学到的往往是历史数据里“最常见的操作模式”而不是“最优的操作模式”。这也是为什么当“大模型设计互补算法”这个思路出现时我一下就来了兴趣。它跟常规的“用大模型做预测”“用大模型做调度”完全不同。它的核心不是让大模型自己去替代整个优化系统而是让大模型扮演“算法设计师”快速生成一批小巧的、可解释的、能与既有系统配合的补充算法模块。这些模块的作用是把那些老办法够不着的角落填补起来形成一套“主系统互补算法”的组合拳。这篇文章我会把整条路线的逻辑、做法、落地步骤和踩过的坑都摊开讲。适合正在做工业能源优化项目的工程师、做AI落地的算法同学以及被电费压得头疼的企业技术负责人看。内容尽量不端着你可以直接抄作业。2. “互补算法”到底补什么与主系统的三组协作关系先界定一个关键概念什么叫互补算法。我把它定义为运行在既有能源管理系统之外不与主系统抢地盘而是对主系统的输出做修正、补充、扩展的小型算法模块。它可以是几条判断规则可以是一个轻量的回归模型也可以是一段用于缩小搜索空间的剪枝逻辑。它的核心特征是“补位”而不是“替代”。这三组协作关系是我在项目里最常遇到的。2.1 与预测模型互补填上规则盲区大部分企业已经上了负荷预测模块用历史数据预测未来半小时的用电负荷。预测模型擅长处理“平稳波动”但遇到生产节奏突变就失灵——比如一条产线临时加单、空压机因故障跳停、天气骤变导致车间负荷突变。这些事件在历史数据里往往样本极少预测模型学不到。互补算法在这里的角色是针对这些“长尾场景”设计专门的修正规则。大模型可以读设备日志和维护记录把“故障后的负荷反弹特征”“加单后的设备启停节奏”这种隐性知识提取出来转化成几条可执行的修正公式或规则叠加在预测输出之上。拿我参与过的制冷站项目举例。常规做法是用随机森林预测冷冻水负荷效果一直不错但每逢周一早上负荷都会异常升高预测总是滞后一拍。后来我们让大模型分析三个月的工单记录发现周一早班启动的设备数量比平时多15%——这不是历史负荷能看出来的规律是生产计划信息。把它写成一条“周一早班负荷修正系数”规则后预测误差直接降了三分之一。2.2 与求解器互补给MILP提供热启动和剪枝方向大型能源优化通常绕不开数学规划。无论是空压机机组组合、窑炉升温曲线安排还是蓄冷罐的充放策略本质都是大规模组合优化。MILP求解器比如Gurobi、Cplex能保证最优解但计算时间经常长得无法接受尤其是约束复杂、变量上万的时候。互补算法在这里的职责是“帮求解器少走弯路”。具体手段有三种一是生成高质量热启动解让求解器从一个不错的可行解开始分支二是设计剪枝规则把明显不可能进入最优解的变量空间先排除掉三是动态调整部分参数——比如把某些设备的启停次数上限从代码硬编码改成根据当前工况实时计算的软约束。有次做一个电力需量优化项目8台大功率设备的启停组合要满足最大需量约束MILP模型求解一次要40多分钟根本没法做实时滚动优化。我们让大模型产出一组“优先级启发式规则”——基于设备能效、当前负载率、历史启停次数给设备排序排序靠前的优先开启。把这个规则作为热启动喂给求解器之后求解时间压到了4分钟以内解的质量损失不到1%。这正是“互补”的价值所在不碰求解器内部逻辑只是通过外围算法帮它把搜索空间缩小。大模型强在知识迁移和模式总结它未必能写出比求解器更好的数学框架但它知道“这种场景下哪种搜索方向大概率有效”。2.3 与人工经验互补把老师傅的隐性知识显式化高能耗企业的能源优化现场往往有几位特别厉害的老师傅。他们不需要看任何仪表听空压机的声音就知道该开哪台、该关哪台。但他们一旦退休这些经验就跟着人走了你再多的数字模型也补不回来。大模型在这些年积累了大量通用知识又擅长从文本中归纳信息。我们可以把老师傅的操作日志、交接班记录、调度说明、异常处理报告扔给大模型让它把这些非结构化文本里的经验抽出来变成结构化规则。这项工作放在以前需要知识工程师做几个月的访谈和编码但现在大模型几小时就能出第一版草案再由老师傅做复核确认。需要注意这不是为了替代老师傅而是帮他“留一手”。我们项目里有一次做得特别顺老师傅提到“下雨天的夜里冷却塔效率偏高可以晚半小时开启第二台塔”。这句随口一说的话被大模型转换成了包含天气、时段、冷却塔效率阈值的可执行规则后来整个夏天都靠这条规则省下了可观的电费。3. 大模型设计算法的技术路径迭代生成、验证与筛选那么大模型具体是怎么“设计”出这些算法的光靠一次Prompt问它“给我写个节能算法”它只能给你一个看起来很漂亮但完全不可用的泛泛方案。真正能落地的流程是一个“生成-评估-进化”的闭环。3.1 前置工作把工艺约束翻译成机器可执行的数据契约这一步是整个流程的地基做不好后面全是空中楼阁。所谓数据契约就是把现场的物理设备、运行参数、约束条件和大模型的输入输出格式统一起来。我习惯让大模型先读一遍设备台账、管道拓扑说明书和历史数据字段清单然后输出一份JSON Schema描述设备ID、设备类型、启停状态、功率、负荷率、环境温度、时段电价、生产计划标记等等。这份Schema就是大模型后续生成算法时的“世界模型”——它必须严格遵守。为什么要这么做因为大模型的幻觉问题在自由生成时尤其严重。如果不给它强约束它很可能设计出一个“每5分钟启停一次空压机”的规则——物理上完全不可能压缩机会直接报废。有了数据契约我们在生成阶段就能做第一轮硬校验把不符合物理常识的输出直接丢掉。数据契约的产出格式不复杂但定义过程要非常考究。比如“时段电价”是取实时值还是预测值“生产计划标记”的粒度是分钟还是小时“设备启停次数上限”从哪张表里读取这些问题都要在契约里写明白。我见过不少项目卡在这一步因为现场数据库字段命名混乱描述文档又严重滞后导致大模型生成的算法根本读不到正确数据。3.2 核心循环生成候选规则、仿真评估、反馈进化数据契约就位后进入核心循环。我通常把这个过程封装成一个“算法孵化器”自动化程度可以很高。第一步是大规模生成。给大模型输入一段任务描述比如“请设计一组用于夜间空压机群节能调度的规则目标函数是电费最小化约束条件见数据契约”。要求它输出5到10条候选规则每条规则都包含触发条件、执行动作、预期收益和风险说明。第二步是仿真评估。必须有一个基于历史数据或者机理模型的仿真环境。把候选规则放到仿真环境里去跑历史场景统计每天的能耗、电费、设备启停次数、压力波动等指标。这一步不能省也是项目里最花时间的部分。第三步是反馈进化。把仿真评估的结果哪些规则效果好、哪些不理想、偏差出在哪里反馈给大模型让它基于上一次的结果做修正。比如“你上轮生成的规则A在夜间高压时段有效但在午间低压时段导致压力偏低请修改触发条件”。循环迭代直到候选规则在历史数据上的表现稳定达标。这套循环本质上是一种“算法层面的进化搜索”。大模型在这里面扮演的不是演绎推理者而是一个高效的模式生成器——它把从无数代码、论文、工业文档中学到的算法套路按照当前任务需求重新组合。它一次能产出大量候选然后由仿真器做裁判淘汰劣质方案保留优秀方案。这比人工写规则快了一个数量级而且不依赖某个专家全程盯场。3.3 筛选标准互补增益比绝对最优更重要仿真评估里最容易犯的错误是拿单独运行效果来评判候选算法。前面反复强调过这些算法是“补位”的它必须和主系统协同工作才有效。所以评估标准不是“这条规则单独跑能省多少电”而是“在现有系统的输出基础上叠加这条规则后系统整体能省多少电”。这个“互补增益”的度量方式我一般用三个指标看整体电费下降幅度、设备运行稳定性启停次数变化、调度员采纳率这条规则是否减少了人工干预。三者缺一不可。有个项目让我印象很深。孵化器产出一条“蓄冷罐放冷时间提前1小时”的规则单独评估时它让蓄冷罐在高峰时段的放冷量更充足电费看起来降了不少。但放进主系统跑联动仿真发现提前放冷导致低谷时段的充冷量不足第二天的蓄冷罐在下午三点就放空了反而增加了晚高峰的电费。这个例子说明只看局部不看协同很容易被假增益误导。所以我在筛选阶段会坚持做“系统级A/B测试”而不是“规则级A/B测试”。候选规则必须放到完整的主系统闭环里跑和纯主系统的基线做对比。哪怕一条规则单独看很平庸只要能让系统整体稳定提升它就值得保留反之一条单独看效果惊艳但干扰主系统的规则再漂亮也要砍掉。4. 一条可参考的落地路线从搭建实验台到影子部署讲完技术原理说说落地层面的实操路线。这条路我带着团队走过几遍现在基本形成了固定的四段式流程。4.1 第一步基线和工况库是评判的唯一标尺无论算法写得再好没有基线就没法证明价值。上线之前必须先把“现有系统人工操作”在当前工况下的表现完整记录下来作为对照基准。同时建立一个工况库把过去至少三个月的生产数据按工况分桶——高温日、低温日、峰谷电价差异大或小的日子、生产满负荷或半负荷的日子。这步最大的价值是让评估有了锚点。后面不论是大模型生成算法还是参数调优全部以“在相同工况下比基线省了多少”为最终度量。没有工况库你在夏天训练出来的算法到了冬天可能完全不适用有了工况库每次迭代都能在历史全工况上回归验证防止过拟合。4.2 第二步在“算法孵化器”里批量试错所谓算法孵化器就是一套把数据契约、大模型调用、仿真环境和评估脚本串起来的工具链。你可以用Python每天跑几十个循环每次生成新的算法变体丢进仿真器跑历史工况再自动汇总指标写回日志。整个过程不需要人工介入算法工程师的工作从“手写规则”变成了“审核大模型产出”。我建议这一步尽量自动化但保留一个人类审查舱位。千万不要让大模型自动把规则直接推给现场执行这个红线必须盯死。每一批备选规则在进仿真前至少要有一个人眼扫一遍排除明显离谱的输出。自动化之后你能明显感觉到效率的跨代提升。同等工作量下过去人工写规则一个月出三五个版本已经是极限现在孵化器一个周末就能跑出几十个版本关键不是数量而是这些版本覆盖了更多以前没考虑过的边界工况。4.3 第三步沙箱对拍和在线影子验证仿真通过是第一步但仿真终归是“过去的数据”现场环境还有仿真里模拟不了的噪声。所以在正式上线前我强烈建议做一轮“影子部署”——也就是新算法和现有系统并行运行新算法只出建议、不直接执行由调度员对照着看连续跑两到四周。影子部署阶段要重点观察几个问题建议被采纳的比例有多高有没有出现算法建议和现场安全约束冲突的情况算法在极端工况下的反应是否合理这些观察数据再反馈回孵化器做最后一轮微调。我遇到过最典型的情况是仿真里表现很好的规则一到现场就被调度员否了原因不是电费算得不对而是规则要求“两台空压机同时切换”现场操作规程只允许逐台切换。这个约束写在操作规程PDF里数据契约里没体现仿真器更不知道。影子部署、人工复核是发现这类“隐性约束”的唯一办法。4.4 上线前必须完成的两个审查到了这一步进入上线流程。除了常规的IT安全审查我还坚持做两个“非技术”审查。第一个是操作风险审查。逐条跑一遍算法在极端工况下的行为——比如所有负荷同时涌来、设备突发故障、电价尖峰——确认算法不会给出危险动作建议。算法不需要在所有情况下都最优但必须在所有情况下都不造成安全风险。这条是红线中的红线。第二个是解释性审查。找现场调度员和工程师请他们用大白话复述每条推荐规则背后的逻辑。如果他们说不出来、或者理解的和算法实际执行的不一致这条规则就必须改进。算法优化能源用得再漂亮如果不能变成一线人员信任和理解的工具最终只会被关掉。5. 实测中的坑这些是我认为你必须绕开的地方项目做多了踩坑是免不了的。我把记忆最深、最容易重复犯的几个坑拎出来给后面做同类项目的人提个醒。5.1 幻觉不只会编事实更会编出看似严谨的约束大模型的幻觉问题在“设计算法”这个场景下尤其危险。因为算法输出看起来特别专业充满了公式、参数和看似合理的假设很容易让人放松警惕。有一回孵化器生成了一条“动态压力设定值规则”规则里引用了一个“容积效率系数0.87”的假设。看起来没什么问题但对照设备铭牌一看实际容积效率是0.92。这个0.05的误差传导到压力设定值上会导致空压机长时间在错误的高压区间运行一个月下来多耗几万度电。处理办法只能是在数据契约里把一切参数来源都锁死。所有物理常数、设备参数、价格数据必须从数据库或设备台账读取不允许大模型“凭经验给出”。翻译成人话就是大模型只负责编逻辑不负责编数字。每次生成的结果还要做一次参数一致性校验凡是在契约里找不到依据的数字一律打回重写。5.2 搜索空间收敛过快可能只是过拟合孵化器的迭代机制有个隐患如果反馈信号过于单一比如只盯电费指标大模型产出的规则会迅速收敛到同一个套路。初期迭代很有创造力迭代十几轮之后每轮生成的规则开始长得越来越像几乎是在同一个模板上微调参数。原因在于大模型的偏好跟随性和评估指标的选择性。如果评估指标里没有纳入足够多的维度设备磨损、响应延迟、负荷波动等它就会把搜索空间里的多样性快速牺牲掉以换取单一指标上的局部最优。我的对策是在反馈里同时喂“正面样本”和“负面样本”。不仅要告诉大模型哪些规则跑得好也要展示那些被淘汰的规则在什么工况下表现得意外不错。这相当于逼着生成器保留探索空间不要只往一个方向钻。另外一个土办法是定期加噪声——随机离散化一些阈值参数让规则不会在某个精确到小数点后三位的数值上“焊死”。5.3 忽略运维侧的“两班倒”现实烧钱买大模型、跑算法、搭孵化器都很容易让人陷入技术的兴奋里。但现场真正的执行者是两班倒的运维师傅他们的工作习惯和注意力水平才是算法能否落地的最后一道关。有次我们设计了一套很智能的制冷站启停规则逻辑完全正确省电效果也验证了。但上线后发现采纳率不到两成。回访才知道运维师傅在夜班要看十几个监控画面根本不会盯着我们算法的推荐弹窗看。再好的建议在执行端缺一条可靠触达路径就是零。后来我们把推荐输出集成到了他们的即时通讯工具每天定时推送三句话格式的指令“建议14:30开启2号冷却塔”“建议15:00关闭1号冷冻泵”采纳率立刻回到七成以上。这个教训让我明白算法设计的最后一步不是代码是“人机交互接口”。要让算法推荐真正被用起来输出方式必须适配执行者的工作流而不是要求执行者适配算法。5.4 成本与反馈时延的平衡大模型的API调用有真实成本迭代频繁了光调用费就够喝一壶。更麻烦的是时延——完整跑一轮“生成-仿真-评估”可能要十几分钟其中仿真占大头但大模型生成本身也不便宜。我的经验是分阶段控制调用频次初期探索阶段每次生成50条候选覆盖更大的想法空间到了收敛阶段改成每次只生成10条重点做局部微调。另外尽可能复用大模型的中间产出——比如让同一批规则共享一个“场景特征分析”结果而不是每条规则都重新让大模型分析一遍工况。可以省大概三分之一到一半的调用量。动辄上百轮的迭代配合并发池跑一个中型项目下来成本还能接受。但如果放任不管成本会迅速失控。建议在孵化器里加一个简单的预算控制逻辑超出预算自动降级为低质量模型或者减少每轮候选数量。6. 一个可以立刻动手的小实验文章最后分享一个轻量级的实验思路。不需要太重的工业环境哪怕你只有一段历史数据也能跑通。选一个你熟悉的小场景比如办公室空调群控、公司机房精密空调、或者某个车间的水泵机组。关键是数据可获取、边界清晰。评估器写好是这个实验的灵魂。我的做法是写一个纯Python的模拟函数把历史数据里的负荷序列和电价序列作为输入给定一套启停规则返回总电费和舒适度指标。评估器一定要比规则本身更早写出来。让大模型产出一批规则放在这个评估器里跑历史数据看哪些规则在历史上能省钱。然后挑历史表现最好的三条规则人工检查一遍逻辑合理性再决定要不要在实际场景里试运行。整个实验从开始到看到第一版效果快的话一到两周就能完成。虽然规模小但能让团队完整跑通“大模型生成算法-评估器验证-人工复核-部署”全链路。等做好了再把同样的一套方法平移到空压机群、制冷站这类更复杂的场景。根据我个人经验必须提醒一点这个实验的价值不在最终的几条规则本身而在于建立评估文化和校验习惯。我在实际项目中最大的体会是大模型设计算法这条路的前景很好但真正让它能产生价值的不是模型本身有多聪明而是你有没有一套能把“模型产量”变成“可靠产能”的工程脚手架。数据契约、仿真评估、A/B筛选、影子部署这些听起来不那么炫的硬功夫才是这条新路线真正走得通的地方。