AI开始替企业写SOP：知识库该从工作里长出来

9 月 2 日，AWS 发布了一套面向企业支持运营的生成式 AI 方案。它做的第一件事，不是给工单写回复，而是把培训录像和系统操作演示自动拆成结构化 SOP：步骤、截图、校验要求和预期结果一起生成，每一步还能点回原视频对应的时间点，由业务人员核验。

AWS 称，这套架构在生产环境把 SOP 创建时间减少了 80%。更值得关注的是后半段：SOP 入库后用于检索增强生成，指导工单处理；每个已解决工单和每次流程更新，又继续补强知识库。

这让我重新理解了企业知识库：它不该只是一间等人搬资料进去的仓库，而应该是业务每天运行时自然留下的“副产品”。

知识库最贵的，不是存储而是“停下来写”

传统做法通常是：请老员工回忆流程，写文档，审核，再上传。问题在于，最懂业务的人往往也是最忙的人。很多例外处理、判断顺序和跨部门交接都发生在真实工作里，一旦要求他停下来重新讲一遍，知识提取就成了额外项目，更新速度永远追不上流程变化。这不是员工不愿分享，而是企业一直把知识沉淀设计成了本职工作之外的第二份工作。

9 月 1 日发布的 Boomi Scribe 案例给了另一种证据。它不等开发人员事后补文档，而是直接解析企业集成流程的图结构，在开发进行时生成流程说明、业务上下文和逐步文档，并自动比较前后版本。Boomi 披露，其已部署流程平均留有 42 个版本、中位数为 16；多个案例中，文档耗时最多减少 85%。这些是厂商案例数据，不能当作行业平均，但方向很清楚：先读取工作证据，再生成待确认知识。

过去是“人写文档，AI来读取”；现在正在变成“工作留下证据，AI先写草稿，人只确认关键判断”。

真正有价值的是一条会回流的知识链

我把这两套做法放在一起看，发现它们都不是单纯“用 AI 写文档”。AWS 从视频、工单和处理结果里取证，Boomi 从系统流程和版本差异里取证；两者都保留原始依据，再把人工确认过的结果送回下一次执行。知识因此不再是静态文件，而是一条可验证、可更新的链路。

这条链里最不能省的不是生成，而是核验。AWS 为生成步骤绑定原视频时间点，Boomi 保留流程版本和差异，目的都是让确认者能回答三个问题：这条知识从哪来、何时有效、哪次变化让它失效。没有这层来源与版本，自动生成只会更快制造一堆看起来像真的旧文档。

OpenAI 9 月 1 日披露的 Basis 案例也印证了同一逻辑：团队只演示一次新员工入职流程，就把它包装成可复用技能，首日入职从 2 小时缩到 30 分钟；后续出现新问题和例外，HR 再更新技能。可复制的不是一份答案，而是“执行—发现例外—修订流程”的节奏。

STARBOX视角：让BOX成为知识回流站

在 STARBOX 的三层架构里，组织层不必亲自撰写每一份文档，但要定义什么可以成为“权威知识”、谁负责确认、多久复核；BOX 层保存原始证据、已确认版本、适用场景和失效条件；智能体层调用知识执行任务，并把人工改写、异常退回和新案例重新送回 BOX。

DDABC 闭环在这里不是抽象流程：Deploy 让知识进入工作，Analyze 捕捉例外，Benchmark 对比新旧结果，Calibrate 决定哪条经验升级成下一版规则。这样，企业专属知识才不会停在一次访谈或一批导入文件里，而会跟着业务一起生长。

如果你的知识库还主要靠员工“抽空整理”，不妨先换个问题：公司每天已经发生的哪些工作，最适合直接留下可核验的知识草稿？答案可能就藏在培训录像、已解决工单和系统版本记录里。

资料来源：AWS《Modernizing and scaling support operations with generative AI on AWS》（2026年9月2日）、AWS/Boomi《How Boomi Scribe streamlines documentation using AWS》（2026年9月1日）、OpenAI《How AI-native companies turn workflows into operating capability》（2026年9月1日）。