最近整理一份数据库故障处理 SOP手头攒了一堆东西——运维同事的口述记录、几次故障复盘会的速记、监控告警截图上的手写标注还有散落在飞书文档里的处理步骤。信息密度不低但格式混乱、术语不统一直接写文档会很花时间。我决定让 AI 先把这些零散素材“理成线”自己再做验证和修改。实际动手的时候我并没有把希望寄托在单一模型上。因为素材来源太杂有的片段是口语转文字有的是表格截图里提取的字段不同模型在“提取关键信息”和“补全上下文”上的表现差异很大。为什么“技术文档整理”适合交给 AI 做第一轮写技术文档有两类工作一类是格式排版、生成目录、检查链接有效性这类现成的文档工具和脚本就能搞定另一类是把散乱的信息提炼成结构化的操作步骤并且保证术语一致、前置条件明确、回滚动作清晰。后一类任务属于“高消耗但可验证”的劳动正好适合 AI 介入。我这次要整理的故障处理 SOP 包含约 15 个典型场景每个场景需要按“现象—诊断—操作—验证—回滚”的结构来写。原始素材里有 4 个场景的步骤描述是完整的剩下的要么缺前置条件要么诊断命令和现象对应不上。如果纯人工拼凑至少要花两三天。让 AI 先做一轮信息提取和结构填充人再审核纠正整个周期能压到一天以内。工作流把文档整理拆成四步每步用不同模型下面是我实际走通的四步流程。第一步信息提取与去重把脱敏后的故障记录、口述转文字、告警截图说明全部输入给 Gemini 3.5 Flash让它做一件事按故障场景分类提取每个场景的“现象关键词”“触发条件”“涉及组件”“操作步骤片段”“来源人/文档”。这一步要求输出 Markdown 表格并且强制要求“如果某个字段在素材中未提及标注为待补充”避免模型自己编造。Gemini 在多来源资料整合和结构化输出上效率不错响应也快适合做这种量大但不涉及深度推理的“粗筛”。输出示例场景现象关键词触发条件涉及组件操作步骤片段来源Redis 内存打满OOM、响应超时大 Key 未设置 TTLRedisflush 命令、key 分析运维口述主从切换延迟从库落后、数据不一致网络抖动MySQL查看 relay log、跳过事务复盘记录第二步结构化填充拿到第一步的表格后我把它交给 DeepSeek让它按 SOP 模板填充每个场景。Prompt 示例角色技术文档工程师负责将零散的故障信息整理成标准 SOP。 输入材料一份已提取的故障场景表按场景分类列出了现象、触发条件、涉及组件、操作步骤片段。 任务为每个场景生成完整的 SOP 条目包含以下结构 - 现象描述一句话概括 - 诊断命令列出具体可执行命令标注参数说明 - 处理步骤按时间序列每步包含操作内容、预期结果和异常处理 - 回滚步骤如果能推断出 - 前置条件需要什么权限、工具、环境 输出格式Markdown每个场景一个 H3 标题。 限制条件 - 如果素材中缺失诊断命令标注“待补充”不要自行编造命令 - 步骤中的命令语法必须可执行不确定参数时用方括号标注[需确认] - 不要添加素材中未提到的监控指标或告警阈值 验证要求每个场景的操作步骤必须能在本地或测试环境复现。DeepSeek 对中文技术表述的理解比较到位输出的诊断命令和步骤描述几乎不需要润色缺的地方也会老实标“待补充”。这一步产出了一个初版 SOP 草稿每个场景的结构已经成形但细节还需要补充和校对。第三步术语统一与上下文一致性检查把 DeepSeek 的草稿交给 Claude让它做两件事检查全文术语是否一致比如不能同时出现“主节点”和“主库”两种叫法以及跨场景间是否有逻辑冲突比如场景 A 的回滚步骤在场景 B 里被重复引用但前提条件不同。Claude 在长文档一致性保持上比较稳标出了 7 处术语不统一和 2 处跨场景逻辑矛盾。其中一处是“Redis 主从切换”场景里提到的“哨兵模式”在另一处素材中实际用的是 Cluster 模式模型标了“冲突待确认”我找运维确认后修正了。第四步人工终审与链接/命令验证最后一步是人工通读重点检查每条诊断命令能否在对应组件上实际执行文档中的内部链接和跳转是否有效操作步骤的权限要求是否明确回滚路径在真实环境中是否可行这一步写了个简单的 Python 脚本校验 Markdown 文档中所有内部锚点链接的有效性避免发布后出现死链。脚本长这样import re def check_internal_links(md_text): 校验 Markdown 文档中的内部锚点链接 # 提取所有标题 headings set() for m in re.finditer(r^(#{1,6})\s(.)$, md_text, re.MULTILINE): # 将标题转为锚点格式 anchor re.sub(r[^\w\s-], , m.group(2)).strip().lower() anchor re.sub(r\s, -, anchor) headings.add(anchor) # 提取所有内部链接 [text](#anchor) links re.findall(r\[([^\]])\]\(#([^)])\), md_text) broken [] for text, target in links: if target not in headings: broken.append((text, target)) if broken: print(断链) for text, target in broken: print(f [{text}] - #{target}) else: print(所有内部链接有效。) return len(broken) 0这类校验脚本逻辑简单交给 AI 生成后跑一遍就能确认属于低风险可信任任务。但如果脚本涉及文件操作或网络请求一定先在沙箱环境里跑一遍。不同模型在文档整理任务上的差异这次实践让我对几个模型的适用场景有了更清晰的判断Gemini 3.5 Flash多来源资料快速提取和结构化适合做信息归集和去重的“第一棒”响应快但提炼观点偏保守。DeepSeek中文技术文档填充表现最好诊断命令和操作步骤贴合实际工程环境术语自然。Claude适合做长文档的一致性校对和跨场景逻辑检查上下文保持能力强但耗时偏长。ChatGPT在写引言、使用说明等偏“可读性”的段落时更流畅但容易在技术细节上过度推断需要提防幻觉。模型选择不是看谁更“聪明”而是看谁在具体环节上更可控。把任务拆开各取所长效率提升才明显。风险边界技术文档整理必须注意的三条红线技术文档整理比写代码更容易触发信息安全问题因为素材往往直接来自线上环境和内部记录。我的底线是这三条所有输入素材必须脱敏。IP 地址、数据库连接串、内网域名、真实用户 ID 全部替换为占位符。哪怕是内部培训用的文档也不应该出现真实配置。不要直接上传未脱敏的故障复盘日志。日志里可能夹着堆栈信息、请求参数甚至 Token先做一轮过滤只保留与故障现象和修复步骤相关的片段。AI 输出的文档不能直接作为最终操作手册发布。必须经过人工核对诊断命令、回滚步骤和权限要求尤其涉及金融、医疗、生产环境的操作错了就是线上事故。常见误区Q技术文档能完全交给 AI 写吗不能。AI 输出的文档可能包含编造的命令、错误的参数或缺失的前置条件。必须人工核对每条操作是否可执行、每条回滚路径是否安全。Q素材太杂一个模型处理不了怎么办拆成多步用不同模型分工。Gemini 做信息提取DeepSeek 做中文填充Claude 做一致性校对最后人工终审。一个模型包揽全流程的出错概率更高。Q怎么防止 AI 在文档里编造命令或配置在 Prompt 里明确要求“如果素材中未提及标注为待补充”并且加一条限制“不要引入输入材料中未提到的命令、参数或组件”。如果模型还是编了换一个模型再试。Q公司内部的故障记录能直接贴给 AI 吗绝对不能。涉及生产环境的操作细节、架构信息、客户数据必须先脱敏。抽象化描述不影响 AI 理解信息结构但能避免安全风险。总结这次用 AI 辅助技术文档整理的实践可以总结成一条把任务拆到“可验证”的粒度再交给模型。从最小切口入手——选一个格式固定、信息密度高但边界清晰的文档类型用四步流程把整理工作拆开信息提取用 Gemini结构填充用 DeepSeek一致性校对用 Claude最后人工终审。每个环节都要求模型在“信息不足”时诚实标注而不是硬编。脚本和工具只做格式校验不做内容决策。文档发布前所有诊断命令、回滚步骤和权限要求必须经过人工验证生产环境相关的操作手册还需要同行 Review。AI 能帮你把零散素材变成可交付初稿但最终签字的只能是人。