技术文档库

🏦 场景与客户

一家硬件+软件混合产品的公司，技术文档分散在 Confluence、共享盘、个人电脑三处。售后工程师现场遇到问题，常常找不到对应版本的说明书；同一个问题，文档里写的和实际做法不一致。

客户要的是单一可信来源：一个版本一个入口，改一处全站生效。

📅 实施节奏

• 第 1–2 周：盘点现有文档，按「产品 / 版本 / 读者角色」归类
• 第 3 周：确定唯一来源，其余位置改为跳转，消灭副本
• 第 4 周：接入发布流程，产品发版必须同步更新文档
• 第 5 周起：按检索日志补充缺口，被搜但搜不到的优先补

🗝️ 方案要点

• 消灭副本：同一内容只存一处，其他地方一律引用。副本是版本不一致的根源
• 按角色切分入口：安装部署、日常操作、故障处理、二次开发，四类读者四个入口，别让人翻整本书
• 版本与产品对齐：文档带产品版本号，切换版本时同步切换内容
• 缺口驱动补齐：用检索无结果的关键词反推该写什么，比拍脑袋列大纲有效

⚖️ 选型与权衡

🚧 实施难点与排查

• 没人愿意放弃本地文件：做法是让共享盘目录只读并挂提示，逐步迁移而不是一刀切
• 图文不符：截图是旧版界面，误导用户。加截图版本标注与更新提醒
• 发版漏更文档：把文档更新纳入发版检查清单，未完成不放行
• 搜索找不到：用户搜的是口语（「连不上网」），文档写的是术语（「网络连接超时」）。补同义词表

💵 成本与收益

• 成本：盘点与迁移约 2 人 × 3 周 + 平台费用
• 收益：售后现场问题解决时间缩短；因文档不一致导致的误操作减少
• 可量化：盯「售后平均处理时长」与「文档检索零结果率」

🛡️ 风险与保障

• 保密：内部文档与对外文档分区，涉密内容不外发
• 准确性：关键操作步骤需经测试验证后发布
• 可追溯：文档变更留版本记录与修改人

♾️ 可复用与演进

• 可复用到培训教材、投标技术方案、客户交付手册
• 演进方向：把售后工单里的问题反哺成文档缺口清单
• 再进一步：面向客户的智能问答，直接基于文档回答使用问题