我见过太多做工业智能的团队，折腾了好几年，上了一堆大屏和报表系统，最后真正被一线工人用起来的却没几个。但大模型是个例外——它是少数能让老师傅主动天天打开来问问题的AI技术。原因不复杂，因为它真的能“听懂人话”，你用大白话问它，它就用大白话回你，还告诉你依据在哪。
这份指南想做的事情就三件：第一，把大模型那些绕口的概念用大白话讲清楚，确保一个没写过代码的小白也能听懂；第二，讲透这些概念在工业现场到底怎么用，尤其是知识问答、文档处理、辅助排查这些真正能落地出效果的场景；第三，给出一套可以直接抄作业的实操流程，从文档整理到提示词编写，从效果评估到问题排查，完整走一遍。
适合谁看呢？一类是从零起步的产品经理、项目经理、设备工程师，你想搞清楚大模型能在自己工厂里干什么；另一类是写过代码但对大模型不熟的开发者，你想跳过理论轰炸，直接掌握落地需要的核心知识。两类人读这一篇都够了，看完你能对“工业+大模型”这件事建立一套完整的判断框架，而不是零碎地刷一堆名词。
1. 为什么工业场景需要大模型，到底能帮我们干什么
1.1 先看清工业数据的真实模样
很多人在谈工业智能的时候，开口就是“大数据”“传感器”“数字孪生”，听着很高级。但真正在现场待过的人知道，工业环境里最值钱的往往不是那些采集上来的时序数据，反而是散落在各处的非结构化文本——设备说明书、检修规程、工艺卡、历史工单、化验报告，还有老师傅脑子里那些没写下来的经验判断。
这些文本有几个让人头疼的特点。
形态极其杂乱。有PDF，有Word，有Excel，有扫描件，甚至还有手写的点检记录。PDF里有的能复制文字，有的就是一张图片，得OCR才能读出来。页眉页脚、目录、页码混在一起，直接扔给模型，它很容易抓到一些没用的内容。
知识高度分散。同一个设备的故障排查方法，可能散落在操作手册的第80页、一张三年前的维修工单、和某个老师傅的培训记录里。你要查完整，得把好几份文档来回翻。更麻烦的是很多流程中“怎么做”和“为什么这么做”是断开的，操作步骤写在一份文件里，原因和注意事项又写在另一份里。
严重依赖人的经验。老师傅能通过声音判断设备异常，能靠一次故障的现象快速锁定几个可能的根因。这些东西他讲得出来，但没人及时记录下来，等项目一过、人一退休，经验和知识就永久性流失了。我见过不少工厂做过“老师傅经验访谈”，但访谈记录整理完就进了文件夹，之后再没人打开过。
一句话总结：工业场景的真实痛点不是没有数据，而是数据里的知识密度太高、太分散，传统的检索工具和看板根本挖不出来。
1.2 大模型在工业里最值钱的几类用途
搞清楚痛点之后，大模型能干的活就很清晰了。我把它归成四类，也是工业落地目前最成熟、ROI最明显的几类场景。
第一类：知识问答与检索。这是当之无愧的第一落地场景。把设备手册、维修案例、安全规范全部塞进知识库，现场工人用自然语言提问：“液压站压力上不去，先查哪里？”系统返回的不是一份80页的PDF，而是精确到步骤的排查流程，并且每一步都标注了出处。这就相当于给每个班组配了一个24小时在线的、永远不嫌烦的专家。
第二类：文档处理与结构化。工业现场每天产生大量文本记录：维修工单、巡检记录、交接班日志、事故调查报告。这些文字有用，但格式乱、描述口语化、关键信息埋没在叙事里。大模型可以把一段“今天三号机有点响，换了轴承，后来正常了”转成结构化字段：设备编号、故障现象、处理措施、处理结果、工时，直接对接MES工单系统。这一个场景的落地价值往往被低估，其实它是真正能上线进业务流程的硬需求。
第三类：辅助排查与根因分析。把设备当前的状态信息和历史故障案例交给大模型，让它列出最可能的排查方向。这个场景要谨慎，因为工业设备一旦误判后果严重，所以我更愿意称它为“辅助决策”——模型给出建议和依据，人来判断。它最大的价值是打开思路，尤其对经验不足的年轻维修工，非常像“一个见多识广的同事在旁边提建议”。
第四类：培训与知识传承。把老师傅和徒弟的对话录下来，把维修案例问答整理成培训材料，大模型可以根据这些语料生成试题、模拟问答、甚至“虚拟专家陪练”。这件事在老龄化严重的制造业里，价值会越来越突出。
我顺便列个表，方便你对照自己所在的行业找切入点：
| 应用场景 | 输入 | 输出 | 落地难度 | 价值量级 |
|---|---|---|---|---|
| 设备知识问答 | 手册+工单+案例 | 排查步骤+出处 | 低 | 高 |
| 工单自动结构化 | 口语化维修记录 | MES格式数据 | 低 | 高 |
| 事故调查报告分析 | 历史报告文本 | 原因归类+建议 | 中 | 中高 |
| 工艺参数辅助优化 | 历史工艺数据+文本记录 | 参数调整建议 | 中高 | 高 |
| 培训材料生成 | 访谈记录+案例库 | 试题+模拟陪练 | 中 | 中 |
要特别说明一件事：大模型在工业场景里，多数情况下不是取代原有的MES、SCADA、专家系统，而是补上它们最薄弱的一环——让人用自然语言就能拿到结构化的知识。它更像是给老系统装上一个“会说话的接口层”。
2. 吃透核心概念：从Token到微调，一次搞清楚
2.1 大模型的底层直觉：一本会接龙的书
想理解大模型，不用先陷进注意力机制或者反向传播这些数学细节，先从直觉上建立一个模型。
你把大模型想象成一本非常会“接龙”的书。给它看一句开头：“设备启动后出现异响，首先应该检查______”，它根据读过的海量资料预测，这里最可能接的词是“轴承”或“润滑”。训练阶段做的事情，就是让它读天文数字一样的文本，不断练习“根据前面的话猜后面的话”，猜错了就调整内部参数，慢慢参数里就沉淀下了语言规律和世界知识。
到了使用阶段，输入你的问题，就是给它一个开头，它就开始一个接一个地预测后续的词，最终生成一段连贯的回答。明白了这个原理，你就能理解大模型一个让人头疼的特性：它并不知道自己“知道什么”，它只是在做一个概率选择。所以当训练数据里没有相关内容时，它不会说“我不知道”，而是会顺着你的话头“编一个最像样的答案”——这就是大家常说的“一本正经地胡说八道”。
大模型的完整能力分成两个阶段。预训练阶段注入知识，让模型会说话、懂常识；对齐阶段让它学会“听话”，也就是按照人的偏好来回答。后者是为什么你用现在的大模型感觉比前几年的好用很多的关键——它不仅知道得多，还知道怎么答你才满意。
2.2 绕不开的关键术语，一个一个说透
下面这些词你会在各种资料里反复碰到，我挑工业落地相关的重点讲。
Token（词元）。这是模型处理文本的最小单位。中文场景下，一个字大约对应一到两个Token，但也不是绝对，一个常见中文词语可能是一个Token，一个英文单词可能被切成好几个Token。为什么它重要？因为按字数计价、按上下文长度计算，全部以Token为单位。一个10万字的设备手册，大概相当于十几万Token。商用模型API按Token收费，开源自部署则决定你需要的显存和算力。
上下文窗口。指模型一次能“看到”多少Token。以前的模型只有4K、8K，换算成中文也就三四千字到一万多字，一份小手册都放不下。现在主流能到32K甚至更大，但窗口大不等于效果好——塞进去的东西越多，模型越容易“看不过来”，捡了芝麻丢了西瓜。工业落地中，宁可控制塞进上下文的资料数量，也不要一味追求大窗口。
参数与模型规模。常说7B、13B、70B，指的是模型的参数数量分别是70亿、130亿、700亿。参数越多，通常代表学到的知识越多、能力越强，但推理成本也越高。70B模型跑一次得到的答案，不一定比7B模型强多少，尤其在垂直领域的专业问答里，喂给模型的知识质量往往比模型本身大小更关键。
Embedding（向量化）与向量检索。把一段文字变成一串数字坐标，含义相近的文字在坐标空间中距离更近。“轴承损坏”和“轴承故障”在文字上不完全一样，但向量距离很近，机器能据此判断它们是同一类问题。这个技术是RAG（检索增强生成）的底层基础，也是工业知识检索中识别同义表达的关键手段。想象一下地图App：每个地址是一个坐标，你要找“公司附近最近的咖啡店”，靠的就是坐标距离。向量检索就是这个逻辑。
Temperature（温度）与采样。控制生成的随机性。温度越低，输出越保守、越可预测；温度越高，越有创造性、越发散。工业问答建议用偏低的温度，范围在0.1到0.3之间，因为现场要的是确定性和可靠性，不是创意写作。文档摘要可以稍微高一点，让表达更自然，但也别超过0.5。
LoRA微调。这是一种参数高效微调技术。通俗讲，原模型像个已经训练好的大厨，你不想把整个后厨推翻重来，只想教他几道你们本店的特色菜——那就只训练一个很小的“调味模块”挂在他身上，这就是LoRA。工业场景里，如果模型输出的术语习惯、格式风格和你们行业不符，用LoRA调整一下是性价比很高的做法。
提示词工程（Prompt Engineering）。字面意思，就是设计给模型的输入指令。有人觉得它是“雕虫小技”，但说实话，在工业落地项目里，提示词的质量直接影响上线效果，而且是调整成本最低的手段。我后面会专门展开讲。
2.3 部署侧的显存账，必须学会自己算
程序员或者项目经理迟早要面对一个问题：这个模型要跑在什么硬件上？这里教你一个最常用的估算方法。
模型权重占用的显存，大致等于参数量乘以精度字节数。一个7B模型，用FP16（半精度，每参数2字节）加载，约需14GB显存。但这只是权重，推理时还有KV Cache、计算中间态，实际跑起来至少再加几GB。所以你要部署一个7B模型，单张24GB显存的卡是刚刚好能动的，但并发一多就容易撑不住。如果量化为INT8（每参数1字节），权重降到7GB左右，一张16GB显存的卡就能跑；INT4甚至可以把权重压到4GB级别，但精度有所损失，对中文和专业术语的理解力会下降，工业场景要谨慎使用。
在硬件需求上，我做项目会这样估算：7B模型量化为INT8，配32GB内存的服务器，一张24GB显存的显卡，足够支撑车间内几十个低并发客户端的问答服务。如果并发要求高，优先横向加推理卡，而不是换更大的模型。工业场景的核心诉求是稳定和低延迟，对“模型很博学但回复要等一分钟”这种事根本不能接受。
关于算力，我再多说一句：部署大模型不是越高端越好，而是匹配你的场景。做知识库问答，7B-13B量级的开源模型配合RAG，效果已经相当能打；硬上70B模型，除非你有充裕的GPU预算，否则性价比往往不合算。
3. 工业落地怎么选型：提示词、RAG还是微调
3.1 三条技术路线，先分清谁管什么
凡是做大模型落地的，绕不开三个名词：提示词工程、RAG（检索增强生成）、微调。很多新手一上来就想微调，觉得不训练一下就不算“自己做大模型”，这是最大的误区。这三条路线解决的问题根本不同。
提示词工程解决的是“怎么让模型按我的要求输出”。买现成的模型，设计一套指令模板，让模型按照模板来回答。比如规定“只根据提供的资料回答，如果资料没有答案就明确说不知道”，就属于提示词工程。它的优点是零成本、见效快，缺点是模型本身不知道你们公司的内部知识。
RAG解决的是“怎么让模型知道我不知道的事情”。把公司文档、手册、案例做成知识库，用户提问时先检索相关知识，再把“检索结果+问题”一起塞给模型，让模型结合资料回答。你可以理解为让模型开卷考试——先翻书再作答。这是目前工业知识类应用的最优解，没有之一。
微调解决的是“怎么让模型的行为方式和风格变成你们的”。让模型学会你们行业的术语习惯、工单格式、语气风格。但它不能给模型注入新知识，因为训练数据中模型记不牢具体事实，这是工业场景中最容易被误解的一点：以为微调能让模型掌握内部知识，做完了才发现该不知道还是不知道。
三者的适用关系，我的经验是：
| 维度 | 提示词工程 | RAG | 微调 |
|---|---|---|---|
| 知识来源 | 模型内置 | 外部知识库 | 训练数据 |
| 知识更新 | 无法更新 | 即时更新 | 需重新训练 |
| 幻觉控制 | 弱 | 强（有引用） | 中 |
| 开发成本 | 极低 | 低-中 | 高 |
| 适合场景 | 通用问答、格式控制 | 企业知识问答 | 风格与术语适配 |
一个典型的决策路径是：先写提示词试试，满足需求就收工；不满足，上RAG解决知识缺失；还不够，做小规模LoRA微调调整风格。我今年做过的项目里，九成需求在“提示词+RAG”这一层就解决了，真正走到微调的很少。
3.2 工业RAG的典型链路
把RAG再拆细一点，完整链路包含四段：文档预处理、检索、组装、生成校验。
文档预处理是地基。PDF要转文字，扫描件要OCR，图片要加说明文字，然后按章节切分成小块，每块配上标题和上下文信息，最后用Embedding模型把每一块转成向量存进向量数据库。这个环节最耗时，也最决定天花板。资料没弄干净，后面做什么都白搭。
检索阶段包括查询改写和召回。用户问“液压站为啥压力上不去”，系统先把这句话改写得更适合检索，比如“液压站 压力不足 原因”，然后同时做向量检索（找语义相似的内容）和关键词检索（找字面匹配的内容），最后把两路结果合并、去重、重排，取最相关的3到5段。
组装阶段是把检索回来的资料和用户的问题拼成一个完整的Prompt。工业场景对Prompt要求比较严格，一般要包括角色设定、任务说明、资料内容、输出格式要求。这一步看起来简单，实际对最终效果影响非常大，我后面会给一个可以直接用的模板。
生成与校验阶段，模型根据Prompt生成最终回答。更稳妥的做法是要求模型在回答中标注引用来源，再做一个后置校验：如果回答里的关键信息在检索资料中找不到对应文本，就判定为可疑，打回重生成或直接拒答。这一步能大幅降低幻觉，让业务方建立信任。
3.3 数据安全与系统边界，先解决问题再谈智能
工业环境的数据安全要求比其他行业高一个量级，这不是空话。设备参数、工艺配方、故障记录，都属于企业核心资产，出不去厂门。所以工业落地第一条原则就是：优先考虑私有化部署或者混合部署。
私有化部署，就是把开源模型跑在工厂内部的服务器上，数据全程不出内网，这是最稳妥的。成本上，一套小模型+RAG的服务，硬件投入基本可控，相比每年给云厂商交推理费用长期看更划算。如果确实想用商用大模型API，至少要做到数据和提示词层面的脱敏，把设备编号、人员姓名、工艺参数全部替换成代号。
其次是权限设计。不同角色的员工应该只能访问各自范围内的知识库。操作工能查操作手册和故障代码，但不该能查工艺配方；工艺工程师能查配方，但不该能查薪酬相关的文档。知识库的权限管理和文档管理要一一对应，否则就会出问题。
还要设计“模型挂了怎么办”的降级方案。大模型服务一旦出现故障，前端系统要能自动切换为一个简单的关键词检索模式，宁可答得粗糙一点，也不能让现场工人面对一个打不开的工具。这一条在项目初验和复盘中是必查项。
4. 手把手实操：从零搭一个“设备故障问答助手”
4.1 先想清楚使用者、场景和知识范围
理论知识说够了，下面用一套完整的实操流程，带你从零搭一个可靠性比较高的“设备故障问答助手”。我选这个场景是因为它需求具体、答案有标准、出错不会引发安全事故，非常适合作为第一个大模型落地项目。
先回答三个灵魂问题。
给谁用？给车间现场的维修工和操作工。他们的问题是口语化的，比如“空压机老跳机咋回事”，没什么技术规范性，但要求答案落地、能照做。
问什么？集中在设备故障排查、保养规范、备件更换标准。比如“液压报警代码E023是啥意思，该查哪里”“皮带多久换一次”这类。
答到什么程度？要给出明确的步骤顺序，每一步写清楚操作内容和注意事项，同时注明这句话出自哪份文档的哪个章节。答不上来的情况下，明确说不确定，而不是硬编一个答案。
把这三个问题定清楚，后面所有的数据整理、提示词编写、效果评估都有了标尺。
4.2 把散文档变成可检索的知识库
知识库建设是整个项目里工作量最大、最影响效果的一步，我习惯把它拆成五个步骤来走。
收集文档。从设备管理员、技术科、老师傅手里把相关手册、保养记录、故障案例、整改报告全部收上来。这一步重点不是“多”，而是“新”——一定要用最新版本文档，旧版标准反而会误导模型。
解析文档。PDF先试直接提取文字，不行就上OCR。Excel要用程序读表格，图片类的运行记录要按页转文本。解析完成后人工抽查10%-20%，确认没有严重乱码。
清洗内容。去掉页眉页脚、重复的封面版权页、目录和页码；把表格转成“字段:值”的文本描述，因为模型读表格的能力有限，转成文本更稳定；对明显残缺的段落标注“原文不完整”。
切分文本。按照标题层级和自然段落，把文档切成200到400字的小块，相邻两块保留50字左右的重叠。为什么要这么切？太长了相关知识点淹没在无关内容里，检索召回精度下降；太短了上下文断裂，模型理解不了前后逻辑。重叠是为了避免句子被从中间截断，导致语义不完整。
向量化入库。用Embedding模型把每一块文本转成向量，连同标题、文档来源、原文内容一起存进向量数据库。这一步完全是批量处理的活，跑完就算知识库建好了。
注意：这一步占了整个项目60%的工作量，也决定了最终效果的60%。别指望跳过它直接让模型“自己学”，模型不会自己读你公司的内部文档。
4.3 写Prompt和跑通主流程（附Python示例）
知识库建好之后，写一套能稳定运行的Prompt。我提供一套验证过多次的模板，你按需改。
角色：你是一名设备维修助手，服务于生产车间的维修工。 任务：根据【参考资料】回答用户关于设备故障排查和保养的问题。 原则： 1. 只能根据【参考资料】回答，不得使用资料之外的假设。 2. 如果参考资料中没有明确答案，直接回复：“资料库中没有找到相关说明，建议联系设备厂家或查阅最新手册。” 3. 回答必须按操作步骤列出，步骤要具体可执行。 4. 每条步骤后标注来源，格式为“【来源：文档名/章节名】”。 5. 如果用户描述的现象模糊，先请他补充关键信息，再给出排查建议。 【参考资料】 {检索回来的文本片段} 【用户问题】 {用户输入}你看到这个Prompt的核心价值在哪吗？它把模型的角色限定死，把回答边界框死，把“不装懂”写成了硬性规定，把引用来源变成了必答项。这一套组合拳下来，模型就算想“自由发挥”，也无从发挥。
跑通整个流程，核心逻辑其实不复杂，给你一段简化的Python伪代码，帮助理解主流程：
def answer_question(user_query: str) -> str: # 1. 查询改写 rewritten_query = rewrite_query(user_query) # 2. 向量检索 + 关键词检索 + 融合重排 candidates = vector_search(rewritten_query, top_k=20) candidates += keyword_search(rewritten_query, top_k=20) best_chunks = rerank(candidates, user_query, top_k=5) # 3. 组装Prompt reference_text = "\n\n".join( f"[{chunk.meta['doc']}/{chunk.meta['chapter']}]\n{chunk.text}" for chunk in best_chunks ) prompt = PROMPT_TEMPLATE.replace("{参考资料}", reference_text) prompt = prompt.replace("{用户问题}", user_query) # 4. 调用模型生成回答 answer = call_llm(prompt, temperature=0.2) # 5. 简单可靠性校验：关键信息是否能在参考资料中找到 if not verify_answer(answer, reference_text): answer = "无法根据现有资料确认答案，建议联系设备厂家。" return answer这段代码就是RAG的全部核心。看到没，真正复杂的不是调用模型，而是前两步——把问题找对、把相关资料找全。这两步做扎实了，最后生成的答案往往是高质量的。
第一版代码跑通后，强烈建议你做一次“人工走查”：挑10个问题，先手动从文档里找出对应的参考资料，把“正确资料+问题”喂给模型，看输出是否合格。合格，说明Prompt没问题；不合格，先改Prompt，不要急着怀疑模型。
4.4 用20条真实问题做效果评估
系统跑起来之后，要有据可依地判断它行不行，不能光靠“感觉还行”。我的做法是建一套迷你评测集。
收集20条真实问题，分成三类：高频故障类（如“泵打不上压”）、模糊描述类（如“设备有异响怎么回事”）、资料中无答案类（如“xx型号停产了没有”）。前两类测模型能不能答对、答全，第三类测模型会不会老老实实拒答。
评估指标设四个：答案正确率、引用命中率、格式合规率、拒答率。正确率也就是跟标准答案比对是否给出正确的排查方向；引用命中率看答案标注的来源是否真实存在于知识库；格式合规率看是否按步骤输出；拒答率看“无答案的题”中模型是否克制住没瞎编。
这四组数字跑完，你基本知道问题出在哪层。如果答案内容对但引用是编的，那问题出在“模型自由发挥”，调Prompt、加校验；如果答案里根本没有相关信息，那问题出在检索，排查切分和重排；如果特定主题老答错，大概率是知识库里这块资料太少，补充文档比调模型更有效。记住这个调优顺序：先检索，再Prompt，最后才考虑微调。
5. 工业落地中的常见问题与排查心得
5.1 模型答错、胡编、查不到怎么办
工业落地现场你会遇到的九成问题，归纳起来就三种：答非所问、答案里掺了假东西、明明有资料却查不到。
答非所问，先看是不是用户的问题太模糊。“设备坏了”和“设备启动时报E023报警，电机不转”，前者神仙难救。解法是在Prompt里加一条“如果用户描述模糊，先引导补充关键信息”，同时系统层面做一次查询改写，把口语问题补全成更完整的描述。
答案里掺假，也就是幻觉，是最破坏信任感的问题。缓解手段我已经说了不少，这里再补充一个细节：在Prompt里明确写“你的回答中每个关键结论必须能从参考资料的原文中找到”，并且把所有不明确的地方都换成保守表达。再配合最后的引用校验，能挡掉八成以上的明显幻觉。
查不到资料，先怀疑切分粒度。如果正确内容被切成了两三块，没被召回到前5名，那模型看不到就答不出来。把窗口从5提到8一两个反复实验就明白了。还有一个常见坑是Embedding模型对专业词支持不好，厂里的“E023”“离心泵机封”这种词，在向量空间里没有得到很好区分，这时就要补充关键词检索，或者给知识库里的文本做二次清洗，把专业名词单独列出和正文关联。
我整理了一张排查速查表，项目上线初期你大概率用得上：
| 现象 | 可能原因 | 处理方式 |
|---|---|---|
| 答案与资料矛盾 | Prompt未限定资料来源 | 加强Prompt边界+引用校验 |
| 相关段落未被召回 | 切分粒度不合理 | 调整切分长度、补充关键词检索 |
| 回答过于笼统 | 检索内容覆盖不全 | 增加召回数、补充知识库资料 |
| 相同问题答案不稳定 | Temperature过高 | 调到0.1-0.2 |
| 特定型号设备老答错 | 该型号资料缺失 | 补充对应文档，而非调模型 |
| 引用来源不存在 | 模型编造引用 | 强制引用格式+后置校验 |
5.2 性能上不去、成本兜不住怎么办
工业系统对响应时间的要求很现实：现场工人没耐心等一个超过10秒才出答案的工具。性能排查先分清慢在哪一段。是检索慢？向量库里数据量也不大，不太可能；是模型生成慢？7B模型生成100个Token大约需要两三秒，属于正常范围。
如果并发一高就卡，最常见的原因是显存带宽不够，模型同时处理太多请求。优先解法不是换更强的卡，而是给推理服务加副本、加负载均衡，同时控制单请求的输入长度——把召回的片段从5段减到3段，对响应时间的改善立竿见影。
成本控制在工业项目里同样不可忽视。建议从日志里统计每天每个问答平均消耗的Token数，你会惊讶地发现大量成本浪费在“用户重复提问同样的问题”和“上下文里塞了太多没用资料”上。前者可以做缓存：一模一样的提问，直接返回缓存答案；后者靠优化检索质量，别让模型每次开卷都看一大堆无关内容。
5.3 最难的不是技术，是让业务方相信它
做工业落地久了，你会发现技术问题都有解，真正磨人的是人。
老师傅不信任AI，怎么办？我的经验是从一个低风险、可快速验证的场景切入。别上来就做“工艺参数自动优化”这种动辄影响产品质量的项目，先做一个“查手册”工具，让工人自己验证答案的正确性。系统每一条答复都标注来源，工人可以亲手去翻原文核对，核对了几次没问题，信任就建立了。
专家不愿把知识写成文档，怎么办？别指望专家坐在那里写知识文档，他们没这个时间也不擅长。换个思路：让工程师去和专家聊天，录下来，整理成问答记录，导入知识库。或者让模型根据历史工单生成一版案例初稿，专家只需要做修改确认。把专家的角色从“作者”变成“审核者”，配合度能高好几倍。
跨部门协同散，怎么办？项目要成立一个虚拟小组，IT负责部署和开发，工艺部门负责提供资料和审核答案，车间班组负责实际试用和反馈。没有这个三角结构，项目多半会在某个环节断掉。
从一个具体场景、一个明确痛线出发，做出可量化的效果，再逐步扩展范围。这比一开始就承诺“给全厂做大模型平台”靠谱得多。
最后分享一点个人的经验。这两年我做过多个大模型项目，最大的体会是：先把一个最小闭环跑通，比规划一个宏大体系重要一百倍。哪怕只是“一个设备、两份文档、二十个测试问题”，跑通了，团队的信心、业务方的信任才有基础，后续推广只是复制粘贴。
另一个体会是，工业场景里，一个“不太聪明但稳定可靠、每个答案都有依据”的系统，远比一个“聪明但偶尔胡编”的系统更有生命力。在这一点上，RAG加严格Prompt，永远是我的首选方案，不是因为它最先进，而是因为它最能守住底线。
