我如何把一次 AI 文档迁移，整理成同事可以复用的经验包

第一批文档迁移完，我打开本地预览，一张小操作图孤零零地占在页面中央。

图片没丢，路径也正常，但它原本只是夹在步骤里的示意图。转换程序认为任务结束了，这一页却显然还不能发布。

后来整理 Mintlify 文档站经验包时，这类问题也被写进了处理规则。

AI 把内容搬过来了，问题才刚刚出现

当时，我们要把原有付费文档站里的内容迁移到 Mintlify。资料散落在旧文档站和飞书文档中，迁移时我还会提供对应的原始 HTML。

AI 负责读取、转换和整理内容。我会先让它读取旧页面，再用原始 HTML 核对读取是否准确。图片按约定下载到本地仓库；视频原本就在云端，因此继续保留远程地址。

第一轮跑完，问题不只是一张小图。原文的标题层级有时会错位，旧站内链到了新站会失效，一些原本尺寸很小的图片被统一居中，单独占一整行。

AI 完成了大量读取和格式转换，但它看到的终点是“成功显示”。我的检查还包括正文有没有漏、标题关系对不对、图片和视频是否正常、内链能不能跳转、页面是否适合发布。

第一轮真正暴露出来的，是这些原本存在我脑子里的要求，还没有进入迁移规则。

我没有让它只改这一张图

最省事的办法，是让 AI 把眼前这张图缩小，然后继续检查下一页。但文档足够多以后，同类问题还会不断出现，人仍然要逐页找、逐张改。

我换了一个处理方式：先把这张图作为例子，让 AI 从原始 HTML 中读取图片尺寸，再扫描其他文档，找出尺寸特征相近的图片，统一按照同一要求处理。

任务从“修这张图”变成了“找出这一类图”。

AI 批量处理后，我审核了这一批结果，没有发现需要单独返工的情况。这里不能推出“图片尺寸是一条万能规则”。图标、二维码、横幅都有可能需要另外判断。尺寸只是当时那批文档里可用的信号。

但这次修改让我确认了一件事：人的经验如果只停留在“看起来不对”，AI 很难稳定复用；把它改写成工具能够读取的条件，才有机会从一个例外扩展到一类问题。

这也影响了我对 Skill 的理解。它不该只是一段碰巧有效的 Prompt。至少要留下几个东西：什么情况需要处理，依据什么判断，处理完怎样才算通过。

整站迁移，我选择一批一批做

我没有接着让 AI 一次迁完整个站，而是按不同业务模块推进。

一个模块结束后，我先检查正文、标题层级、图片、视频、内链和排版。发现问题，先改处理规则，再开下一批。这样，前一批出现的错误不会一路复制到后面的模块。

规则逐渐稳定后，后续批次的主要输入也收敛为页面链接和原始 HTML；图片、视频、内链和发布检查分别按约定处理。

这套做法没有“一键迁移”那么好听。它依靠的是小批次、人工审核和明确的返工边界。AI 可以承担大范围读取和重复处理，但最终什么能发布，仍然由人判断。

这不是对 AI 过度谨慎。对 758 名咨询顾问进行的一项预注册实验发现，在 AI 擅长的任务范围内，参与者完成得更多、更快；换到能力边界之外的任务，使用 AI 的参与者反而更不容易得到正确答案。研究测试的并不是文档迁移，却提醒了我：看起来相近的两个任务，未必都适合用同样的自动化程度。研究原文 ↗

全量迁移也给后续维护留下了基础。比如产品新增一种采集方式，旧教程里凡是列举采集方式的页面，都可能需要同步更新。过去靠维护者凭记忆查找，很容易漏；内容进入统一仓库后，可以先让 AI 扫描并列出候选页，再由人确认修改范围。

目前真正完成的是全量迁移和分模块验收。影响面分析是接下来可以继续使用的维护方式，还不能写成更新已经全自动完成。它至少让我看清：文档维护最累的地方，经常不是改一句话，而是找出这句话牵动了哪些页面。

项目做完后，另一个产品线拿走了经验包

文档站上线以后，我把搭建步骤、迁移 SOP、检查项和踩过的坑整理了出来。相比“操作手册”，我更愿意叫它经验包。

操作手册通常告诉人按钮在哪里。经验包还要回答：开始前准备什么，下一步做什么，什么结果不能通过，出了问题先查哪里。

后来，这套经验包交给了另一条 RPA 产品线。一位从零开始搭建文档站的同事沿着主线推进，最终完成了 RPA 文档站的正式上线。

他并不是拿走文件以后就再也没有找过我。过程中有一些疑问，主要来自不同 Agent 工具的差异。同一句问法换个模型可能会跑偏，我们就调整表达，或者把任务拆得更细。

主线没有因此变化：准备材料、按模块处理、逐批检查，达到上线条件再发布。

这次交接没有做到“零交流”，我也不认为那是判断复用是否成立的标准。变化在于，我不需要替另一个部门重新搭一遍；对方承担主要执行，我只在少数工具问题上答疑。

一项覆盖 5,172 名客服人员的真实部署研究提供了一个相近观察：AI 辅助带来的改善更多出现在经验较少的员工身上，研究者认为，其中一个可能机制是 AI 帮助传播了更熟练员工的做法。这项研究只发生在一家公司的客服场景，不能拿来证明一份 SOP 必然有效，但它说明，把少数人的成熟做法传递给更多人，并不只是一个口号。研究原文 ↗

让第二个人做成，能力才开始属于团队

这次复用只发生在一个同事、一条产品线，还不能说明方法已经规模化。不同 Agent 也确实需要不同的任务拆分和问法。

因此，我没有把每次针对某个工具调整的提示词全部写进经验包。模型会变，工具会变；应该长期保留的是输入要求、处理主线、常见错误和验收标准。工具跑偏时可以换一种问法，发布条件不能跟着降低。

文档站之外，客户问题也有类似结构。售前更擅长需求引导和价值表达，售后或技术支持熟悉系统细节和后期维护。适合沉淀的是反复出现的提问、处理步骤和检查标准；关系判断、临场经验和最终责任仍然留给人。

所以我现在判断一项 AI 能力有没有进入团队，会看一个很朴素的问题：原执行者不在场时，接手的人是否知道从哪里开始，什么结果可以通过，出了问题应该停在哪里。

这次 RPA 文档站的上线，只回答了一次“可以”。

对我来说，这已经比一次漂亮的演示更有价值。