给内部工具撰写操作手册：用DeepSeek模型整理散落的经验记录

团队里有一些知识，存在的方式比较特殊。不是Wiki里的正式文档，也不是需求评审的会议纪要，而是聊天记录里的几段话、某次排查后的随手笔记、一个README里塞在末尾的使用提醒。这些材料如果原样交给新同事，对方可能需要翻好几天的聊天记录和文档才能拼凑出完整的操作路径。但如果要整理成一份结构清晰的操作手册，手工提取、归类、统稿又需要不少时间。

这种“将散落的操作经验整理成SOP文档”的任务，有一个特点：输入材料分散且格式不统一，但输出结构是固定的——按步骤组织、标注前置条件和注意事项、说明异常情况的处理方法。KULA作为第三方AI多模型聚合工具，提供了一个可以集中调用不同模型的统一工作环境。在它的工作区中，可以把多份零散材料汇总输入，让模型完成提取和结构化，再切换另一个模型做完整性检查。它的网站域名是 ouai.me ，可以直接在浏览器中访问。需要说明的是，KULA不是模型厂商的官方网站，而是一个多模型调用平台。以下使用DeepSeek系列模型，演示从零散记录到结构化操作手册的完整整理过程。

输入材料：一批格式各异的操作记录

先看输入材料。以下是模拟的三份记录，分别来自聊天记录片段、运维笔记和README文档的备注，已经过脱敏处理，去掉了具体的服务器地址和账号信息：

材料A——聊天记录片段：

问：部署脚本执行到第三步报权限错误怎么处理？
答：检查一下 /opt/app/config 目录的属主是不是 appuser。之前有一次就是因为用 root 跑了
第一步，后面几步的目录权限全乱了。改回来之后还要确认一下 systemd 服务有没有 reload。
另外如果报错信息里包含 "Permission denied (publickey)"，可能是 SSH key 没加载，先跑
一下 ssh-add 再重试部署。

材料B——运维笔记（片段）：

部署前检查清单：
- 目标服务器磁盘剩余空间至少2GB（/opt分区）
- appuser 账号可以免密 sudo（/usr/bin/systemctl 和 /usr/bin/nginx）
- 防火墙已开放 8080 和 8443 端口
- 如果上次部署回滚过，先清理 /opt/app/rollback 目录

常见失败原因：
1. 磁盘空间不足 → 清理旧日志文件
2. sudo 权限缺失 → 联系管理员添加
3. 端口冲突 → 检查是否有残留进程占用 8080

材料C——README备注（片段）：

部署步骤：
1. 上传部署包到 /opt/app/releases/
2. 解压并创建软链接到 /opt/app/current
3. 执行数据库迁移脚本
4. 重启应用服务
注意：步骤3的迁移脚本如果执行失败，不要继续步骤4。先在 /opt/app/logs/migration.log
里查具体错误。常见问题是新增字段和旧数据不兼容，需要手动调整 SQL。

这三份材料的信息有重叠、有补充，也有一条材料里有而其他材料没有的内容。如果手工整理，需要先通读三份材料，提取所有操作步骤，然后对比哪些步骤在不同材料中都有提到、哪些步骤只有一份材料提到，最后按顺序组织成一份完整的操作手册。

整理流程：分阶段提取与结构化

整理过程拆为三个阶段：信息提取、内容合并与去重、完整性复查。每个阶段使用DeepSeek系列中适合的模型版本，所有操作在 KULA 的工作区内完成。

阶段一：用DeepSeek-V4-Pro提取关键信息

DeepSeek-V4-Pro于2026年4月发布，是DeepSeek系列的百万级上下文开源旗舰模型，Agent能力有质变——可以主动规划并执行任务。选择它作为提取阶段的主模型，主要原因是输入材料虽然总长度不长，但格式差异较大（对话、清单、备注），需要模型在同一上下文中理解三种不同的表达方式并提取结构化信息。

使用的Prompt模板如下：

请从以下三份操作记录中提取所有与部署操作相关的信息。
要求：
1. 按“操作步骤”“前置检查项”“异常处理”三类输出；
2. 每条信息标注来源（材料A/B/C），便于回查；
3. 原文中的具体路径、命令和参数不得改动；
4. 不同材料中对同一操作的描述，不自行合并，分别列出并标注；
5. 不补充材料中未提及的操作或配置；
6. 材料内容如下：
[此处粘贴三份材料]

首轮提取完成后，得到一份分类清晰的原始信息清单，每一条都带上了来源标记。

阶段二：用DeepSeek-V4-Flash合并去重并生成结构化文档

DeepSeek-V4-Flash与V4-Pro同日发布，284B参数中130亿激活，专为速度和效率设计，推理速度比前代提升了85%。在这个阶段，任务目标是把阶段一的提取结果合并为一份按操作顺序组织的完整手册——检查哪些操作在多份材料中重复出现，合并为一条，同时保留各自独有的补充信息。

具体做法是把阶段一的输出交给DeepSeek-V4-Flash，用另一条Prompt要求它按“前置检查—操作步骤—异常处理”的顺序生成一份SOP文档。遇到两个材料对同一操作有不同的补充说明时，合并为“要点1、要点2”的形式，而不是取其中一份而丢弃另一份。

阶段三：完整性复查

合并完成后，在 KULA 中切换到辅助模型做最后的完整性复查。复查不是重写手册，而是对照原始三份材料，逐条检查合并后的SOP是否遗漏了任何来源中的操作步骤或注意事项。辅助模型使用的Prompt核心逻辑是“检查SOP是否覆盖了所有材料中的操作项”，输出遗漏清单和对应来源。

整理结果对照

下表展示了从原始材料到最终SOP中几个关键操作项的变化过程：

从对照可以看出，材料A中关于SSH key的提醒和材料B中关于sudo权限的检查，在合并后的SOP中被分别保留在了前置检查和异常处理两个不同的环节里。材料C中“迁移脚本失败后不要继续步骤4”这条关键约束，在SOP的异常处理部分被明确标注。

验收标准

SOP整理完成后，用以下清单逐项检查，确认整理结果可以进入团队审核环节：

需要留意的几个问题

这次整理的输入材料是从公开渠道模拟的，不包含生产环境的真实路径和账号信息。在实际操作中，如果原始材料里包含服务器地址、账号密码、密钥路径或内部系统名称，输入任何模型之前务必完成脱敏处理。生成的操作手册在正式采纳之前，需要由熟悉对应系统的运维同事确认所有路径、命令和权限描述的准确性。

DeepSeek系列的一个特点是其开源定位和百万级上下文能力。DeepSeek-V4-Pro在处理长文档提取任务时，能够一次性输入更多背景材料而不需要分段处理，这对于将多个来源的零散记录汇总整理到统一环境中的场景是实用的。而DeepSeek-V4-Flash在速度和效率上的提升（推理速度提升85%），则适合在合并去重阶段快速输出结构化文档。如果后续需要处理更大体量的材料——比如同时整理多个模块的操作记录——可以在 KULA 中继续使用这两个版本的组合来完成提取和结构化的工作流。

下一步可以做什么

如果团队里也有类似的散落操作记录需要整理，可以先选一个范围明确的模块做一次尝试。把涉及这个模块的聊天记录、笔记和文档备注汇总到一起，用阶段一的Prompt完成信息提取，观察提取结果中“来源标记”这一列是否完整——这能反映出原始材料的信息密度和重叠程度。整理完一个模块之后，可以判断这份SOP模板的结构是否适合其他模块复用，如果结构稳定，后续整理其他模块时可以直接套用模板。