企业官网建设流程全解析

超大件设备运输方案的编制，在很长一段时间里都是一个“靠人肉堆经验”的活。一根一百米长的风电叶片要从生产厂区出发到达沿海风场，或者一台四五百吨的变压器要从码头转运到内陆变电站，运输方案的每一页纸背后都牵扯到车辆选型、桥梁验算、道路净空、护送安排、审批流程甚至沿途天气风险。老师傅们能靠着几十年积累下来的数据和直觉，在几天之内编出一份看起来像那么回事的方案。但新人很难复制，企业也难沉淀，每一份方案都像是一次全新的赌博。

我们这次做的项目，就是尝试把“超大件设备运输方案”的编制流程，用大模型重做一遍。不是让大模型凭空生成方案，而是让它基于历史数据、法规要求、真实路网和专业计算，把原本散落在老师傅脑子里、电脑文件夹里、聊天记录里的经验，系统地组织成一份可执行、可复核、可交付的智能生成方案。这篇文章从头到尾复盘整个项目的技术路线、数据整理、生成链路设计和落地踩坑，希望能给正在做类似“行业知识+大模型”应用的朋友一些参考。

1. 超大件运输方案生成：一个被忽视的高价值场景

1.1 这不是普通的“运输方案”

很多人听到“运输方案”会觉得很简单——找个车，规划个路线，把货拉过去不就行了。但超大件设备运输完全不是这个逻辑。货物本身的尺寸和重量远超常规车辆标准，装车方案要考虑轴数、轴线车数量、悬挂方式、前后牵引配置；路线方案要逐段核对道路限高、限重、转弯半径，每一座桥、每一个收费站、每一个上跨线缆都可能成为限制条件。

我举个最直观的例子：一根风电叶片出厂时接近一百米长，整车组合后的转弯半径可能超过三十米。常规导航软件给出的路线基本无法使用，因为它在普通小客车的地图逻辑里，根本不会去算叶片扫过时是否会被路边树木、信号灯或对向车辆干扰。方案编制人员必须把整条路“跑”一遍，结合实际勘测数据，才能确定从国道到高速再到乡村道路的接驳点。

这种方案的真正价值在于风险前置。开工前把桥梁载荷、道路宽度、空中障碍物、审批材料、护送和封闭方案全部列清楚，最大程度避免运行时出现“车卡在桥下”“超重压坏路面”“临时发现限高不足”这类重大事故。这已经不是普通的物流文档，而是一份结合了大量工程数据的综合性决策文件。

1.2 为什么传统流程和规则系统都难以应对

超大件运输方案的编制流程，本质上是把三类信息做交叉匹配：货物结构参数、运输装备能力、沿途道路基础设施条件。听起来很简单，但现实中每一类信息都高度分散，而且很多数据长得完全不一样。

老师傅的做法通常是“逐个打电话确认”：问司机这条路能不能走，查之前类似尺寸的货物走过哪条路线，翻政府网站的审批公告，甚至亲自去现场量限高。这样的流程有几个绕不开的问题。第一，个人经验难以复制，核心知识都在少数人脑子里；第二，历史案例往往是按项目存在PDF或Excel里，没有统一的数据格式，检索起来极其困难；第三，即便有了数据，也需要大量的手动拼接工作，一个项目的方案初稿经常要花三到五天。

至于传统规则引擎，我也尝试过搭建候选路线判断逻辑：如果总高度超过5米，则排除净空不足的路线；如果总重量超过某座桥的承载等级，则标记需绕行。这种硬编码方式在条件少的时候确实很快，但只要到了实际场景，就知道它根本无法穷举。不同车型的轴距不同，对桥梁的载荷影响不同，同一座桥在不同天气和车辆速度下的通过性也不同。规则引擎能处理前80%的简单情况，但真正有风险、有挑战的价值恰恰在那后20%的组合约束里。

1.3 大模型在这个场景里真正该干的是什么

我一开始也想过“用大模型一键生成整个方案”，但很快放弃了这种想法。原因很简单，超大件运输方案涉及大量必须精确计算的内容，比如桥梁弯矩验算、轮压计算、转弯通道宽度校核，这些根本不归大模型管。大模型的强项是理解、归纳、生成和判断逻辑，而不是数值计算。

经过几轮讨论后，我们把它定位成“方案编制的智能编排引擎”。大模型负责三件事：根据货物参数理解运输需求，从知识库里检索并重组相关的历史案例和规则经验，再把零散的专业信息组织成结构化的方案文档。所有关键数值、可行性判断、路线选择都交给专门的计算模块和规则校验模块来处理，最后由人工在几个关键节点做确认。这个定位在后面整个系统设计中起了决定性作用。

2. 技术路线与模型选型：私有化是底线，生成按模块拆开

2.1 为什么不直接调用云端API

项目启动时，业务方首先问的问题就是：模型部署在哪里？我们的回答很明确——必须私有化部署，不能直接把自己的项目数据发送到外部API。

这个决定背后不全是合规原因，更多是业务风险考量。超大件运输方案里包含了大量货主信息、项目路线、设备具体参数和商务报价，这些数据一旦落到外部API，对甲方来说就是不可控的泄露风险。而且这类项目的客户对接周期通常很长，方案文档常常要反复调整，如果每次调用都依赖外部服务，一旦服务出现波动或者接口策略调整，整个方案的产出节奏都会被打断。

所以我们把模型全部部署在内网环境中。推理框架方面，早期实验用了Ollama做快速验证，进入正式系统后切到vLLM来承载并发请求，稳定性和吞吐量都明显好于早期版本。整条链路最大程度保证了“数据不出内网”，这也是我们后续能在业务侧建立信任的基础。

2.2 基座模型选型的取舍

模型选型这块我做了不少对比测试。在确定私有化部署的前提下，第一选项自然是开源模型，关键是选什么参数级别和什么能力的底座。

产品早期我们把精力放在流程打通上，没有一上来就做微调，而是直接选择了通用能力比较强的开源基座模型，优先考虑三个指标：中文理解能力、长文本组织能力、在单张或两张显卡上可运行的体积。最终选择了14B级别左右的模型，在vLLM部署下推理速度能够控制在合理范围内。

后来做了一轮更细致的对比，大致如下：

我们最终选的是“本地部署开源模型+微调预留”的组合。先靠提示词工程和检索增强跑通业务，如果后续某个模块效果始终不够好，再针对该模块做微调。这个思路在后面也被证明是省心且务实的。

2.3 智能体编排：把生成任务拆成可管控的步骤

刚做原型时我犯了一个典型的错误，想着一个大的Prompt，把所有约束和示例都塞进去，让模型直接输出完整方案。结果也很典型：输出内容看着头头是道，细看却在自相矛盾，前半部分说某条路线可行，后半部分又把同一座桥标记成需绕行。

后来改成智能体工作流的方式：整个系统是一个统一的编排引擎，模型不再是“一次性纸面生成器”，而是通过多个节点完成各自独立的子任务。比如“货物信息理解”是一个节点，“路线初筛”由规则引擎完成并返回候选集，“某段运输方案的生成”只在一个独立上下文中执行。每个节点都有明确的输入输出格式和校验逻辑，上一个节点的输出审核通过后才进入下一个环节。

这个设计带来的最大好处是可控。业务方可以对中间结果做检查，某个环节生成的描述有问题，可以直接定位到具体节点修正，不用从头再生成一遍。对后续维护而言，任何一个节点升级或替换模型，也不会影响其他模块的运行。

3. 知识资产梳理：把老师傅的“脑内数据库”搬进系统

3.1 知识资产分四类，得先分清楚再数字化

做这套系统前，我们调研了运输公司内部积累了很久的各类资料，发现大体可以分成四类。我把它们列成了一个表，这四类知识是后面所有生成逻辑的“燃料”。

一开始我们试图把全部数据统一成一个巨大的表格，通过SQL硬查来做决策。后来发现这不可行，因为大量信息是文字描述和现场照片，根本无法塞进关系型数据库。我们最终的做法是“能结构化就结构化，不能结构化就向量化，两种形式并行建库”。

3.2 结构化知识库：车辆、路线、桥梁三张大表

结构化部分我们做了三张核心表。车辆装备表记录每一种可用车型的详细参数，包括纵横向轴距、每轴载重上限、满载总重、高/宽/长的极限等。路线网表记录不同道路段的等级、宽度、限高、限重、限速，以及是否允许超限运输车通行。桥梁表则记录每座桥的跨径、结构形式、设计载荷单位、实测承载数据。

这三张表是大模型生成方案的“硬数据底座”。在生成任何运输方案前，系统会先把货物尺寸重量与车辆表和路线表做匹配计算，筛掉不满足基本条件的选项，再结合桥梁表做载荷校核。这一步完全通过传统代码完成，不依赖大模型输出。

3.3 历史方案与专家经验的向量化

历史方案和老师傅经验是非结构化程度最高的一类。我们处理了几百份过去的运输方案文档，格式五花八门，有的是Word，有的是PDF扫描件，有的直接就是一封邮件里的附件截图。

清洗这套数据花费了大量精力。核心思路是：把每份文档按章节切块，每个块尽量保持独立语义，然后转成向量存进向量库。切分粒度没有一刀切，而是根据文档类型动态调整。比如“装车方案”章节整体就是一个块，因为它描述的是一个完整单元；而“沿线桥梁载荷说明”如果涉及多座不同桥梁，就要按每座桥单独切块，方便后续精准检索。

这里有一个关键细节：切块后保留原始段落标题和文档编号，并将这段文字与出处文件关联起来。这样大模型在生成方案时引用某个历史做法，我们可以直接追溯到是哪一份历史方案里的内容，对人工复核非常关键。

3.4 检索增强的目标是让模型学会“用证据说话”

很多RAG项目效果差，不是模型不够强，而是检索回来的内容根本没有被模型当成必须遵守的依据。我们的做法是在Prompt里明确写了一条规则：所有涉及路线选择、车型配置、桥梁判断的内容，必须基于检索返回的知识片段，并在输出中标注对应知识来源标号。

比如我们要求模型在生成“沿线交通限制及应对措施”时，先列出它使用的所有检索来源，再根据这些来源组织段落。如果检索不到相关内容，模型必须明确写“历史资料中无直接案例，需人工核实”，而不是编造一个“通常可以通过审批”的说法。这种写法会牺牲一部分“流畅感”，但极大提升了方案的可信度。

4. 从货物参数到可执行方案：生成主流程拆解

4.1 第一关：货物信息结构化，先把人话翻译成机器语言

整个生成流程的输入不是一段自然语言描述，而是一个经过约束的JSON结构。货物数据来自业务系统或人工录入，我们把长宽高、重心位置、单件重量、件数、是否需要举升等关键参数全部结构化，作为所有后续环节的输入源头。

例如，一份货物信息结构化后的形式大致长这样：

{ "cargo_id": "WB20250115", "name": "风电叶片", "length_m": 96.5, "width_m": 4.2, "height_m": 3.8, "weight_t": 72.0, "center_of_gravity_percent": 42, "overlength_flag": true, "support_points": 2, "transport_type": "road" }

不要小看这一步。货物参数是后面所有规则计算的源头，如果这里数据不干净，后面再强的模型也白搭。我们专门设计了输入校验逻辑，比如长度与宽度明显倒挂的、重量缺失的、重心位置超范围的，都会提示业务人员补充确认后才能进入生成流程。

4.2 第二关：路线初筛与可行性校验，规则引擎先跑一遍

货物参数解析完成后，系统会先调用规则计算模块做一次硬性筛选。这个模块不考虑大模型，而是基于车辆库、路线库和桥梁表做依次匹配。

具体逻辑是：先从车辆库选出能承载该货物重量和尺寸的候选车型，然后对每个候选车型，逐一检查路线网表中每条可通行道路的限高、限宽和限重，排除不满足基本约束的路段。接着对保留下来的路线逐桥做载荷估算，用一个简化的计算模型判断整车总重和轴载是否在桥梁安全范围内。最后输出的候选路线集合会被附上每段路线的车型、桥梁载荷余量、预估通行时间等附加信息，作为生成阶段的原料。

这一步的意义在于：大模型永远不需要自己去“发明”一条路线。它只能从规则引擎给出的候选路线中挑选、解释和组织方案。数值判断和硬约束全部由代码负责，模型负责的是表达和推理。

4.3 第三关：分模块生成，不追求一次性写完整个方案

运输方案本身是一份很长很长的文档，不可能靠一个上下文全部生成。我们按方案结构拆成了六个独立模块：装车方案说明、运输路线与行程计划、沿线限制与应对措施、护送与交通组织方案、应急预案、费用估算与资源清单。

每个模块对应一个独立的生成任务，输入内容也不相同。装车方案模块只需要货物参数和选定的车型配置；运输路线模块需要路线候选集和沿途设施记录；应急预案模块则需要历史事故案例和天气风险数据。模块化生成的好处很明显——每个模型上下文窗口只需要关注一小块内容，输出质量更容易控制，也方便后续人工逐段审核和修改。

生成完的各个模块并不直接简单拼装成一个大文档。我们会先经过一个“一致性检查”节点，用规则校验模块之间是否存在前后矛盾。比如装车方案里总高度是5.2米，路线模块里却说可以通过限高4.8米的隧道，这就会被自动标记为异常，并反馈给人工复核。

4.4 第四关：人工复核点的设计，哪些地方必须留给人

大模型项目最忌讳的事情是不分青红皂白“全自动”。在超大件运输方案这个场景，我们保留了三个必须人工确认的节点。

第一个节点是方案开头的“货物吊装与装载规划”，这里面涉及实际操作的细节，比如吊点位置、平衡配重、临时加固方式，模型即使能参考历史方案，也无法替现场工程师做最终决定。第二个节点是“特殊路段处理建议”，凡是遇到规则引擎标记为“风险较高”的路段，系统只自动生成备选方案和说明，必须由人工确认是否采用或需要实际派员去现场勘察。第三个节点是费用估算，报价涉及商务细节，模型可以给出建议区间，但最终数字由业务人员填写。

这三个节点的核心逻辑是把系统的能力边界划清楚。大模型能做的是把80%的标准化文字工作省掉，剩下20%需要人类经验判断的地方，系统做得越少越好，做多了反而添乱。

5. 落地时踩过的四个大坑与应对方案

5.1 数值幻觉：桥梁承载力写错一个字就是安全事故

这是我们在测试阶段遇到的最严重问题。模型在生成“沿线桥梁说明”时，把某座桥的承载能力从“限载40吨”写成了“限载55吨”，直接超过了实际桥梁安全范围。如果不仔细核对，按照这版方案上路，后果不堪设想。

根治方法不是靠提示词让模型“小心”，而是在架构上把数值生成从模型那里移走。所有桥梁载荷、轴载数据、限高限重这些关键数值，一律通过查表和计算模块灌入，生成阶段所用的文本编辑区只允许包含这些数值的变量，模型无权自行填写。通过这种方式，数值幻觉被从源头上杜绝了。

5.2 “模板味”过重：生成内容正确但一读就是外行

第一版方案生成出来后，业务方看完说了一句话：“内容都是对的，但这个味儿不对。”所谓味儿不对，就是模型写出来的句子太“通用”——任何一家运输公司都能用，但并不是一个真正做过超大件运输的老师傅会写的语言。

后来我们做了两处调整。第一，为每个方案模块都准备了三至五篇可参考的高质量历史方案作为示例，通过提示词让模型模仿这些范文的叙述方式和章节组织习惯。第二，在Prompt里加入了针对性的风格要求，比如“像一份现场勘测后撰写的技术文件，不像是宣传材料”，避免模型自动切换成那种“多快好省”的通用商务腔。效果显著，评审通过率一下子提高了不少。

5.3 上下文长度与长文档的矛盾，越写越散

大模型的上下文窗口虽然一直在增长，但真的拿来生成一份几万字的方案文档，依然会出现“写到后面忘了前面”的情况。我们试过把全部需求材料放进上下文里，让模型一次生成整个方案，结果前几千字非常精准，越到后面越跑偏。

这个问题的解法就是前面说到的模块化生成。每个模块只使用它真正需要的那一小部分上下文，模型永远不需要记住整份方案。另外每个模块生成时都会携带固定的货物信息和路线候选集摘要，保证每个模块都在同一个事实基础上工作，而不是依赖自己对“前文”的记忆。

5.4 验收标准不明确：业务方和管理层的预期管理

这是项目中最容易忽略的一环。业务方起初以为模型能“一键出完整方案，只需签名盖章”，管理层则担心系统“会不会出错变成事故隐患”。两边预期差异很大，导致验收阶段反复拉扯。

我们的应对办法是建立了一套量化评分表。把方案内容拆成信息完整性、数据准确性、结构规范性、上位专业度、可执行性五个维度，由业务骨干对模型生成方案和人工方案进行抽样盲评打分。虽然评分过程耗时，但数据出来后，双方便很快达成了一致：模型生成的初稿在信息完整性和规范度上明显占优，在专业判断和异常处理上仍需人工介入。有了这个分数，系统的上线范围和人工互动模式就清晰了。

6. 什么情况下该考虑微调，什么情况下不该

6.1 我的决策路径：先检索增强，再规则增强，最后才微调

很多团队一上来就打算微调模型，我们这次是反过来，明确了一条决策路径。

第一步是检索增强。确保模型能够调用已有的知识库、车辆库、路线库和历史方案数据。这一步能解决90%的知识信息来源问题，而且成本最低。第二步是规则增强。把所有能计算、能校验的逻辑全部前置到代码层，让模型不用承担任何数值正确性的责任。第三步才是微调。当系统运行一段时间后，如果发现某些模块生成的风格、术语或特定句式仍然不稳定，且人工修正量一直很大的时候，才考虑针对这些模块做专门的参数微调。

判断是否需要微调，我自己的标准很简单：如果错误可以靠补充检索数据或调整提示词解决，就不要微调；如果问题出在模型的表达能力上——比如永远写不出符合特定行业习惯的长句——且该模块使用频率很高，那微调就值得做。

6.2 一个从RAG到微调的典型案例

项目进入第三个月时，“装车方案说明”模块一直被业务方反馈译文太生硬。模型总把装载方案写成“采用液压平板车装载，设置前部支架固定，后部平衡支撑”这类教科书式语句，但实际上资深工程师的写法是“采用四纵列轴线车，前部配重块压载1.5吨，叶片叶根朝向车头方向，重心距前支点6.3米，叶片主体通过双层垫木固定”。这两种写法之间的差别非常明显。

检索增强能够解决“知道有哪些历史方案”的问题，但解决不了“用自己的行业语言把方案组织出来”的问题。于是我们收集了大约一百多条带人工修正的装车方案样例，使用LoRA方式进行轻量微调。微调后该模块的输出风格明显向真实工程师的叙述方式靠拢，业务方一次性通过了这个模块的验收。

6.3 微调数据怎么攒，就不能靠拍脑袋造

这里给一个非常实用的提醒：高质量的微调数据靠“攒”不靠“造”。我们在系统一开始就设置了人工修正留痕功能，每当业务人员在某个生成模块上做了修改，系统都会自动记录“原始生成内容”和“人工修改后内容”的配对。这些配对是微调最好的训练数据来源。

等到系统运行两三个月后，自然就能积累出几百条甚至上千条高质量的真实修正数据。用这部分数据来做微调，比任何人工构造样本都更符合业务实际场景。这就是“先用系统产生数据，再用数据反哺系统”的闭环思路。

做完这个项目，我最大的体会是大模型在工业级场景里根本不需要扮演“全能专家”的角色。它更像一个底子很好的实习生，你给它一个清晰的流程、一份可信的资料库和几条不可逾越的红线，它就能帮你把过去几个小时甚至几天的重复性工作压缩到十几分钟。但红线本身，得靠规则计算和人工复核来画。

最后再分享一个小经验：如果你也在做类似的行业智能生成系统，开工第一天就要把“数据来源可追溯”作为硬性要求。模型可以写出漂亮的句子，但审计时人们关心的永远是这句话的依据在哪里。把这一点做好了，系统从工具进化为生产力工具的路就会顺得多。