前段时间帮一个做工业网关的朋友整理售后资料。事情不大但很典型设备说明书有 80 多页里面混着安装步骤、指示灯说明、串口参数、网络配置、常见故障、保养建议。售后同事真正需要的其实不是“完整读一遍说明书”而是在客户问问题时能快速判断这是什么故障、要看哪些参数、下一步怎么排查。我一开始以为把 PDF 丢给 AI让它总结成 FAQ 就行。试了几轮才发现直接总结出来的内容看着很完整但不太能用。原因很简单说明书里的内容是面向“读者阅读”的售后知识库需要的是面向“问题处理”的结构。两者不是一回事。后来我换了做法不让模型一次性生成最终文档而是把任务拆成“抽取信息、重组结构、生成排查清单、人工校验”几步。这里用到的模型包括 ChatGPT、Claude、Gemini、DeepSeek 等实际体验下来不同模型擅长的环节不一样但关键不是选哪个模型而是把流程设计得可验证。先说失败版本AI 总结得很漂亮但售后用不上我第一次给模型的提示词大概是text请阅读下面的工业网关说明书内容整理成一份常见问题 FAQ。输出很快格式也不错设备无法上电怎么办网络无法连接怎么办串口通信异常怎么办指示灯闪烁代表什么如何恢复出厂设置。问题在于这份 FAQ 更像说明书的缩写版而不是故障处理工具。比如“网络无法连接怎么办”模型会写请检查网线是否连接正常确认 IP 地址配置是否正确检查网关与服务器之间的网络连通性。这当然没错但售后同事看到后仍然要继续问看哪个指示灯先查本地 IP还是先查云端状态DHCP 和静态 IP 的排查顺序一样吗如果客户不会抓包能不能用更简单的方法判断哪些情况应该转给研发也就是说AI 给了一个“正确但不够落地”的答案。这个坑很常见。AI 擅长把长文压缩成短文但工作场景里更重要的是把“信息”变成“动作”。我后来采用的四步流程这次整理设备说明书我最后固定成四步从原文中抽取事实参数、状态、操作步骤、限制条件按故障场景重组上电、联网、串口、数据上报、恢复配置生成排查清单一步一步问、看、测、记录人工校验和补充边界售后、硬件、研发一起过一遍。这四步的好处是每一步都能检查不会让模型直接“自由发挥”。第一步只抽取原文事实不让它猜我先把说明书拆成几个部分产品概述接口和指示灯安装接线网络配置串口配置平台接入常见故障维护和注意事项。每次只给模型一小段让它按固定字段抽取text请只基于原文抽取信息不要补充经验判断。 输出字段- 模块名称- 涉及部件- 参数名称- 参数取值- 操作步骤- 指示灯状态- 注意事项- 原文页码或段落位置- 不确定内容 要求1. 原文没有写的内容标记为“未提供”2. 不要推测原因3. 不要改写关键参数4. 保留单位、数值和条件。这一步看起来有点笨但很重要。工业设备文档里经常有这类信息信息类型示例电源范围DC 12V24V串口参数9600 / 8 / N / 1指示灯状态常亮、慢闪、快闪网络模式DHCP、静态 IP恢复操作长按按钮 5 秒注意事项接线前断电这些内容如果被模型随意改写就很麻烦。比如“长按 5 秒”写成“长按几秒”现场人员可能就会误操作。所以第一步只做抽取不做解释。第二步把说明书结构改成故障场景结构说明书通常按产品模块写但售后处理问题时不是这么想的。客户不会说“我在阅读第 4.2 节网络配置时遇到了问题”客户会说设备灯不亮插上网线没反应平台看不到数据串口收不到设备数据配置完重启后又失效换了现场网络后连不上。所以第二步要把“文档结构”转成“问题结构”。我用的提示词是text请把上一步抽取的信息按售后故障场景重新组织。 故障场景包括1. 上电异常2. 网络连接异常3. 串口通信异常4. 数据上报异常5. 配置保存异常6. 指示灯状态不明确7. 恢复出厂设置相关问题 每个场景输出- 可能涉及的部件- 需要确认的参数- 可观察现象- 原文依据- 不能确定的地方这里我会特别要求“原文依据”。如果模型说某个故障可能和电源有关就必须指出来自说明书哪一段如果没有依据就写“不确定”。整理后类似这样故障场景可观察现象需要确认原文依据上电异常电源灯不亮电源范围、接线极性、适配器输出电源说明、接线章节网络连接异常网口灯不亮或平台离线IP 模式、网线、网关地址网络配置章节串口通信异常采集不到下位机数据波特率、校验位、接线方式串口配置章节数据上报异常本地正常但平台无数据服务器地址、设备编号、网络连通性平台接入章节这张表就比原始说明书更接近售后工作了。第三步生成“可执行”的排查清单知识库不是给人看的百科而是给人用的流程。所以我把每个故障场景都整理成排查清单要求每一步必须满足三个条件现场人员能操作能得到明确结果能决定下一步。提示词如下text请根据已整理的故障场景生成售后排查清单。 要求1. 每个步骤使用“检查 / 观察 / 记录 / 尝试”这类动作开头2. 每一步都要有预期结果3. 如果结果不符合预期说明下一步去哪里4. 不要引入原文没有提到的专业工具5. 不要建议拆机或进行高风险操作6. 不确定的内容标记为“需研发确认”。以“平台看不到数据”为例第一次输出是这样的text1. 检查设备是否正常上电确认电源指示灯状态。2. 检查网线是否连接正常观察网口指示灯是否亮起。3. 检查设备 IP 配置是否与现场网络一致。4. 检查服务器地址和端口配置是否正确。5. 重启设备后再次观察平台状态。6. 如果仍无法恢复记录设备编号、网络配置和指示灯状态转研发排查。这个版本已经能用了但我又让模型补了一版“记录字段”text请为上面的排查清单补充售后记录字段方便后续研发复盘。得到的字段包括字段示例设备型号GW-XXXX固件版本v1.2.3现场网络模式DHCP / 静态 IP电源指示灯常亮 / 不亮 / 闪烁网口状态亮 / 不亮 / 闪烁服务器地址已脱敏最近一次配置时间2025-xx-xx排查结果已恢复 / 未恢复 / 转研发这部分对后续复盘很有用。以前售后反馈给研发的信息经常是“客户说连不上”研发很难判断问题在哪里。有了记录字段至少能减少来回追问。第四步不要省掉人工校验这一步我觉得最容易被忽略。AI 整理出来的知识库必须让熟悉设备的人过一遍。尤其是工业、硬件、IoT 这类场景错误不一定出在文字上而是出在操作顺序和风险边界上。我一般让三类人看售后同事这套话术和流程现场能不能用硬件或嵌入式同事参数、指示灯、接线描述有没有错研发同事哪些情况应该转研发哪些不需要。校验时我会用这张表检查项通过标准参数准确电压、波特率、端口、时间等没有改错操作安全不引导非专业人员进行高风险操作步骤可执行每一步现场人员能完成结果可判断每一步都有明确观察结果转交边界清楚哪些情况转售后哪些转研发资料已脱敏不包含客户名称、真实地址、内部账号与原文一致关键结论能追溯到说明书这张表比“读起来顺不顺”更重要。不同模型适合放在哪些环节这次没有做严格测评只是从使用感受上说一下。ChatGPT适合把流程写得更像人话它在把排查步骤改成售后话术时比较自然。比如把“确认网络连通性”改成“请先确认网口灯是否亮起再检查设备 IP 是否与现场网段一致”可读性会更好。Claude适合长文档的结构化整理如果一次给的资料比较长Claude 对层级结构的保持还不错适合做章节摘要、字段归类、风险提示。Gemini适合快速生成多个版本我常用它做“给我三种知识库结构”的草稿比如按故障类型、按设备模块、按现场角色分别整理。速度快适合前期试结构。DeepSeek适合中文技术表达和本地化描述在中文说明书、中文售后话术、中文表格整理方面DeepSeek 的表达比较贴近日常工作。用来整理内部知识库修改成本不高。这里不需要纠结“哪个最好”。更实际的做法是把同一份材料交给不同模型处理一小段看哪一个输出更接近你的验收标准。一个可复用的知识库 Prompt 模板下面这个模板可以直接改text你是工业设备售后知识库整理助手。 请根据我提供的设备说明书内容整理成可用于售后排查的知识库。 处理步骤1. 先抽取原文事实包括参数、状态、操作步骤、注意事项2. 再按故障场景重组不要沿用说明书目录3. 为每个故障场景生成排查清单4. 每个步骤必须包含操作动作、预期结果、异常时下一步5. 对原文没有依据的内容标记为“需确认”6. 不要编造参数7. 不要引导高风险操作8. 输出适合放入企业知识库的 Markdown 表格。 故障场景包括- 上电异常- 网络连接异常- 串口通信异常- 数据上报异常- 配置保存异常- 指示灯状态异常- 恢复配置相关问题如果你整理的是软件系统也可以把故障场景换成登录异常接口超时数据同步失败权限配置错误文件上传失败任务执行失败。核心思路一样先抽取事实再按用户遇到的问题重新组织。资料处理放进模型前先做脱敏这里要多说一句。设备说明书本身可能没什么问题但实际整理时经常会把售后记录、客户现场截图、平台配置一起放进来。这些内容要先处理。建议替换掉text客户名称 - 客户 A设备编号 - Device-001服务器地址 - server.example.com现场 IP - 192.168.x.x联系人 - userexample.com项目名称 - Project-X内部账号 - account_removed如果涉及未公开产品、客户现场、内部平台地址不要原样放进模型。AI 可以帮忙整理资料但不应该接收没有筛选过的业务信息。知识库落地时我会保留三个版本这次整理完后我没有只保留一份文档而是分了三个版本。1. 售后快查版特点是短、直接、按故障现象组织。适合一线人员在客户沟通时快速查看。2. 研发复盘版保留更多字段比如固件版本、配置参数、日志片段、复现条件。适合研发分析问题时使用。3. 客户可读版删掉内部字段语气更温和避免使用过多内部术语。适合放进用户手册或帮助中心。同一份说明书面向不同人群结构应该不一样。AI 的作用不是生成一个“万能文档”而是帮你更快地改成不同版本。常见误区误区一让 AI 直接写最终知识库可以让它写初稿但不要直接发布。尤其涉及设备参数、操作步骤和现场处理建议一定要人工确认。误区二只追求总结完整知识库不是越全越好。一线人员更需要“下一步做什么”。如果一条答案太长现场反而不好用。误区三忽略原文依据每个关键结论最好能追溯到说明书、测试记录或研发确认。没有依据的内容宁可标记为“待确认”。误区四把所有资料一次性塞进去长文档、截图、日志、售后记录混在一起模型很容易丢细节。分章节处理再合并结构结果会稳定很多。结尾从一个小场景开始不要一上来做“大知识库”如果你也想用 AI 整理技术资料我建议不要一开始就做完整知识库。可以先选一个高频问题比如“设备无法联网”或“数据不上报”只整理这一类场景。一个比较稳的顺序是选一个真实高频问题把说明书中相关章节单独拿出来让模型只抽取事实按故障场景重组生成排查清单找熟悉业务的人校验再逐步扩展到其他问题。AI 在这类场景里的价值不是替代售后、研发或硬件工程师而是把散落在 PDF、表格、记录里的信息整理成更容易使用的结构。只要保留人工校验和安全边界它就能成为一个很实用的文档助手。