企业官网建设流程全解析

前段时间帮一个做工业网关的朋友整理售后资料。事情不大，但很典型：设备说明书有 80 多页，里面混着安装步骤、指示灯说明、串口参数、网络配置、常见故障、保养建议。售后同事真正需要的，其实不是“完整读一遍说明书”，而是在客户问问题时，能快速判断：这是什么故障、要看哪些参数、下一步怎么排查。

我一开始以为，把 PDF 丢给 AI，让它总结成 FAQ 就行。试了几轮才发现，直接总结出来的内容看着很完整，但不太能用。原因很简单：说明书里的内容是面向“读者阅读”的，售后知识库需要的是面向“问题处理”的结构。两者不是一回事。

后来我换了做法：不让模型一次性生成最终文档，而是把任务拆成“抽取信息、重组结构、生成排查清单、人工校验”几步。这里用到的模型包括 ChatGPT、Claude、Gemini、DeepSeek 等，实际体验下来，不同模型擅长的环节不一样，但关键不是选哪个模型，而是把流程设计得可验证。

先说失败版本：AI 总结得很漂亮，但售后用不上

我第一次给模型的提示词大概是：

text

请阅读下面的工业网关说明书内容，整理成一份常见问题 FAQ。

输出很快，格式也不错：

• 设备无法上电怎么办；
• 网络无法连接怎么办；
• 串口通信异常怎么办；
• 指示灯闪烁代表什么；
• 如何恢复出厂设置。

问题在于，这份 FAQ 更像说明书的缩写版，而不是故障处理工具。

比如“网络无法连接怎么办”，模型会写：

请检查网线是否连接正常，确认 IP 地址配置是否正确，检查网关与服务器之间的网络连通性。

这当然没错，但售后同事看到后仍然要继续问：

• 看哪个指示灯？
• 先查本地 IP，还是先查云端状态？
• DHCP 和静态 IP 的排查顺序一样吗？
• 如果客户不会抓包，能不能用更简单的方法判断？
• 哪些情况应该转给研发？

也就是说，AI 给了一个“正确但不够落地”的答案。

这个坑很常见。AI 擅长把长文压缩成短文，但工作场景里更重要的是把“信息”变成“动作”。

我后来采用的四步流程

这次整理设备说明书，我最后固定成四步：

1. 从原文中抽取事实：参数、状态、操作步骤、限制条件；
2. 按故障场景重组：上电、联网、串口、数据上报、恢复配置；
3. 生成排查清单：一步一步问、看、测、记录；
4. 人工校验和补充边界：售后、硬件、研发一起过一遍。

这四步的好处是，每一步都能检查，不会让模型直接“自由发挥”。

第一步：只抽取原文事实，不让它猜

我先把说明书拆成几个部分：

• 产品概述；
• 接口和指示灯；
• 安装接线；
• 网络配置；
• 串口配置；
• 平台接入；
• 常见故障；
• 维护和注意事项。

每次只给模型一小段，让它按固定字段抽取：

text

请只基于原文抽取信息，不要补充经验判断。 输出字段：- 模块名称- 涉及部件- 参数名称- 参数取值- 操作步骤- 指示灯状态- 注意事项- 原文页码或段落位置- 不确定内容 要求：1. 原文没有写的内容标记为“未提供”；2. 不要推测原因；3. 不要改写关键参数；4. 保留单位、数值和条件。

这一步看起来有点笨，但很重要。

工业设备文档里经常有这类信息：

这些内容如果被模型随意改写，就很麻烦。比如“长按 5 秒”写成“长按几秒”，现场人员可能就会误操作。所以第一步只做抽取，不做解释。

第二步：把说明书结构改成故障场景结构

说明书通常按产品模块写，但售后处理问题时不是这么想的。

客户不会说“我在阅读第 4.2 节网络配置时遇到了问题”，客户会说：

• 设备灯不亮；
• 插上网线没反应；
• 平台看不到数据；
• 串口收不到设备数据；
• 配置完重启后又失效；
• 换了现场网络后连不上。

所以第二步要把“文档结构”转成“问题结构”。

我用的提示词是：

text

请把上一步抽取的信息，按售后故障场景重新组织。 故障场景包括：1. 上电异常2. 网络连接异常3. 串口通信异常4. 数据上报异常5. 配置保存异常6. 指示灯状态不明确7. 恢复出厂设置相关问题 每个场景输出：- 可能涉及的部件- 需要确认的参数- 可观察现象- 原文依据- 不能确定的地方

这里我会特别要求“原文依据”。
如果模型说某个故障可能和电源有关，就必须指出来自说明书哪一段；如果没有依据，就写“不确定”。

整理后类似这样：

这张表就比原始说明书更接近售后工作了。

第三步：生成“可执行”的排查清单

知识库不是给人看的百科，而是给人用的流程。

所以我把每个故障场景都整理成排查清单，要求每一步必须满足三个条件：

• 现场人员能操作；
• 能得到明确结果；
• 能决定下一步。

提示词如下：

text

请根据已整理的故障场景，生成售后排查清单。 要求：1. 每个步骤使用“检查 / 观察 / 记录 / 尝试”这类动作开头；2. 每一步都要有预期结果；3. 如果结果不符合预期，说明下一步去哪里；4. 不要引入原文没有提到的专业工具；5. 不要建议拆机或进行高风险操作；6. 不确定的内容标记为“需研发确认”。

以“平台看不到数据”为例，第一次输出是这样的：

text

1. 检查设备是否正常上电，确认电源指示灯状态。2. 检查网线是否连接正常，观察网口指示灯是否亮起。3. 检查设备 IP 配置是否与现场网络一致。4. 检查服务器地址和端口配置是否正确。5. 重启设备后再次观察平台状态。6. 如果仍无法恢复，记录设备编号、网络配置和指示灯状态，转研发排查。

这个版本已经能用了，但我又让模型补了一版“记录字段”：

text

请为上面的排查清单补充售后记录字段，方便后续研发复盘。

得到的字段包括：

这部分对后续复盘很有用。以前售后反馈给研发的信息经常是“客户说连不上”，研发很难判断问题在哪里。有了记录字段，至少能减少来回追问。

第四步：不要省掉人工校验

这一步我觉得最容易被忽略。

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联系人 -> user@example.com项目名称 -> Project-X内部账号 -> account_removed

如果涉及未公开产品、客户现场、内部平台地址，不要原样放进模型。
AI 可以帮忙整理资料，但不应该接收没有筛选过的业务信息。

知识库落地时，我会保留三个版本

这次整理完后，我没有只保留一份文档，而是分了三个版本。

1. 售后快查版

特点是短、直接、按故障现象组织。
适合一线人员在客户沟通时快速查看。

2. 研发复盘版

保留更多字段，比如固件版本、配置参数、日志片段、复现条件。
适合研发分析问题时使用。

3. 客户可读版

删掉内部字段，语气更温和，避免使用过多内部术语。
适合放进用户手册或帮助中心。

同一份说明书，面向不同人群，结构应该不一样。AI 的作用不是生成一个“万能文档”，而是帮你更快地改成不同版本。

常见误区

误区一：让 AI 直接写最终知识库

可以让它写初稿，但不要直接发布。尤其涉及设备参数、操作步骤和现场处理建议，一定要人工确认。

误区二：只追求总结完整

知识库不是越全越好。一线人员更需要“下一步做什么”。如果一条答案太长，现场反而不好用。

误区三：忽略原文依据

每个关键结论最好能追溯到说明书、测试记录或研发确认。没有依据的内容，宁可标记为“待确认”。

误区四：把所有资料一次性塞进去

长文档、截图、日志、售后记录混在一起，模型很容易丢细节。分章节处理，再合并结构，结果会稳定很多。

结尾：从一个小场景开始，不要一上来做“大知识库”

如果你也想用 AI 整理技术资料，我建议不要一开始就做完整知识库。可以先选一个高频问题，比如“设备无法联网”或“数据不上报”，只整理这一类场景。

一个比较稳的顺序是：

1. 选一个真实高频问题；
2. 把说明书中相关章节单独拿出来；
3. 让模型只抽取事实；
4. 按故障场景重组；
5. 生成排查清单；
6. 找熟悉业务的人校验；
7. 再逐步扩展到其他问题。

AI 在这类场景里的价值，不是替代售后、研发或硬件工程师，而是把散落在 PDF、表格、记录里的信息整理成更容易使用的结构。只要保留人工校验和安全边界，它就能成为一个很实用的文档助手。