企业官网建设流程全解析

最近整理一份数据库故障处理 SOP，手头攒了一堆东西——运维同事的口述记录、几次故障复盘会的速记、监控告警截图上的手写标注，还有散落在飞书文档里的处理步骤。信息密度不低，但格式混乱、术语不统一，直接写文档会很花时间。我决定让 AI 先把这些零散素材“理成线”，自己再做验证和修改。

实际动手的时候，我并没有把希望寄托在单一模型上。因为素材来源太杂，有的片段是口语转文字，有的是表格截图里提取的字段，不同模型在“提取关键信息”和“补全上下文”上的表现差异很大。

为什么“技术文档整理”适合交给 AI 做第一轮

写技术文档有两类工作：一类是格式排版、生成目录、检查链接有效性，这类现成的文档工具和脚本就能搞定；另一类是把散乱的信息提炼成结构化的操作步骤，并且保证术语一致、前置条件明确、回滚动作清晰。后一类任务属于“高消耗但可验证”的劳动，正好适合 AI 介入。

我这次要整理的故障处理 SOP 包含约 15 个典型场景，每个场景需要按“现象—诊断—操作—验证—回滚”的结构来写。原始素材里，有 4 个场景的步骤描述是完整的，剩下的要么缺前置条件，要么诊断命令和现象对应不上。如果纯人工拼凑，至少要花两三天。让 AI 先做一轮信息提取和结构填充，人再审核纠正，整个周期能压到一天以内。

工作流：把文档整理拆成四步，每步用不同模型

下面是我实际走通的四步流程。

第一步：信息提取与去重

把脱敏后的故障记录、口述转文字、告警截图说明全部输入给 Gemini 3.5 Flash，让它做一件事：按故障场景分类，提取每个场景的“现象关键词”“触发条件”“涉及组件”“操作步骤片段”“来源人/文档”。

这一步要求输出 Markdown 表格，并且强制要求“如果某个字段在素材中未提及，标注为待补充”，避免模型自己编造。Gemini 在多来源资料整合和结构化输出上效率不错，响应也快，适合做这种量大但不涉及深度推理的“粗筛”。

输出示例：

第二步：结构化填充

拿到第一步的表格后，我把它交给 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：在写引言、使用说明等偏“可读性”的段落时更流畅，但容易在技术细节上过度推断，需要提防幻觉。

模型选择不是看谁更“聪明”，而是看谁在具体环节上更可控。把任务拆开，各取所长，效率提升才明显。

风险边界：技术文档整理必须注意的三条红线

技术文档整理比写代码更容易触发信息安全问题，因为素材往往直接来自线上环境和内部记录。我的底线是这三条：

1. 所有输入素材必须脱敏。IP 地址、数据库连接串、内网域名、真实用户 ID 全部替换为占位符。哪怕是内部培训用的文档，也不应该出现真实配置。

2. 不要直接上传未脱敏的故障复盘日志。日志里可能夹着堆栈信息、请求参数甚至 Token，先做一轮过滤，只保留与故障现象和修复步骤相关的片段。

3. AI 输出的文档不能直接作为最终操作手册发布。必须经过人工核对诊断命令、回滚步骤和权限要求，尤其涉及金融、医疗、生产环境的操作，错了就是线上事故。

常见误区

Q：技术文档能完全交给 AI 写吗？

不能。AI 输出的文档可能包含编造的命令、错误的参数或缺失的前置条件。必须人工核对每条操作是否可执行、每条回滚路径是否安全。

Q：素材太杂，一个模型处理不了怎么办？

拆成多步，用不同模型分工。Gemini 做信息提取，DeepSeek 做中文填充，Claude 做一致性校对，最后人工终审。一个模型包揽全流程的出错概率更高。

Q：怎么防止 AI 在文档里编造命令或配置？

在 Prompt 里明确要求“如果素材中未提及，标注为待补充”，并且加一条限制：“不要引入输入材料中未提到的命令、参数或组件”。如果模型还是编了，换一个模型再试。

Q：公司内部的故障记录能直接贴给 AI 吗？

绝对不能。涉及生产环境的操作细节、架构信息、客户数据必须先脱敏。抽象化描述不影响 AI 理解信息结构，但能避免安全风险。

总结

这次用 AI 辅助技术文档整理的实践可以总结成一条：把任务拆到“可验证”的粒度，再交给模型。

从最小切口入手——选一个格式固定、信息密度高但边界清晰的文档类型，用四步流程把整理工作拆开：信息提取用 Gemini，结构填充用 DeepSeek，一致性校对用 Claude，最后人工终审。每个环节都要求模型在“信息不足”时诚实标注，而不是硬编。脚本和工具只做格式校验，不做内容决策。

文档发布前，所有诊断命令、回滚步骤和权限要求必须经过人工验证，生产环境相关的操作手册还需要同行 Review。AI 能帮你把零散素材变成可交付初稿，但最终签字的只能是人。