企业官网建设流程全解析

1. 第 100 篇文档写完之后，我最想删掉的不是文档，而是当初对 Prompt 的执念

1.1 从第一天起我就把劲用错了地方

去年秋天我开始带着团队做内部知识库的 AI 化改造，目标很朴素：让沉淀在个人笔记、旧 Wiki、聊天记录里的技术资料，变成一套能被反复检索、引用、再加工的结构化文档体系。最开始我的注意力几乎全部放在 Prompt 上，网上流传的各种提示词工程技巧我基本都试过一遍——角色设定、few-shot 示例、思维链引导、输出格式约束、语气词表、自洽性检查……前 20 篇文档确实让人产生一种“我已经掌握 AI 写作”的错觉。给一段零散的需求描述，配一个精心设计的 Prompt，模型就能吐出一篇结构完整、措辞专业的产品说明。那时候我甚至觉得，所谓 AI 写文档，本质上就是 Prompt 写得好不好的问题。

到了第 50 篇左右，情况开始不对了。同一套 Prompt 模板，换一批输入材料，产出质量急剧波动。有时候文档里 A 处说某个接口的限流阈值是 500 QPS，B 处写成了 5000；有时候上个月刚定稿的术语定义，新生成的文档里又出现了旧叫法。我第一反应还是 Prompt 写得不够细，于是继续加约束，把能想到的规则都塞进提示词里，甚至给模型准备了一份“文档写作军规”，洋洋洒洒三千多字。效果有，但远没到根治的程度。

写着写着，到第 100 篇的时候我终于想明白一件事：我一直在试图用 Prompt 去解决一个知识管理问题。单篇文档的生产效率可以靠 Prompt 提升，但文档之间的术语一致性、指标可信度、版本同步性，这些是 Prompt 根本管不了的。它们属于更底层、更隐蔽、也更值钱的一个环节——知识治理层。这篇文章想把这段从“迷之自信”到“不得不重构”的过程完整复盘一遍，尤其是那套让我真正摆脱返工泥潭的知识治理方法，如果你也在用 AI 批量产出文档，或者正在搭团队知识库，希望这篇能帮你少走我走过的弯路。

1.2 用 Prompt 堆出来的高产，本质是在给一团乱麻打蝴蝶结

打个比方，Prompt 就像装修时的软装方案，它能决定墙面刷什么颜色、家具摆哪个位置，但它改变不了房子的承重结构。当房子本身盖歪了，你用再高级的软装去掩盖，住进去还是会出问题。文档背后的“承重结构”就是知识本身——它来自哪里、定义是什么、谁说了算、什么时候生效、怎么被引用。这些东西一团乱的时候，Prompt 的唯一作用是让每一篇文档乱得“很好看”而已。

100 篇文档的返工记录特别能说明问题。我把写完之后需要人工修正的次数按原因分类统计了一下，结果发现：因为行文逻辑不通而返工的不到两成，真正大量返工的原因是事实性错误、跨文档不一致、旧版本信息没被替换。这些恰恰都不是 Prompt 层面的问题。

• 事实性错误：模型把输入材料里的某个示例数据的年份算错，或者把不同客户的定制参数混在一起；
• 跨文档不一致：一篇文档说“用户画像系统采用实时特征计算”，另一篇说“采用 T+1 批量更新”，两篇都基于同一个项目背景，却互相矛盾；
• 版本滞后：参考了已经废弃的旧版接口文档，新文档里还在介绍一个下线半年的参数。

这些问题的共性是：缺少一个统一的知识底座。模型在生成每一篇文档时，只能看到我临时塞进 Prompt 里的上下文，而这份上下文往往是不完整的，甚至是过期的。我越是精心设计 Prompt，越是在把错误知识包装得漂亮。痛定思痛，我才把重心从提示词换到了知识治理层。

2. 知识治理层到底是什么？它不是知识库，也不是 RAG

2.1 知识库只是仓库，治理层才是仓库的运营规则

很多人一听“知识治理层”，第一反应是“这不就是做个知识库嘛，或者接个 RAG（检索增强生成）”。我一开始也这么想，后来发现完全不是一回事。知识库和 RAG 解决的是“知识在不在、能不能被检索到”的问题；治理层解决的是“知识对不对、新不新、能不能被信任”的问题。

你可以把知识库想象成一个仓库：RAG 是传送带，能把仓库里的货按需送到生产线（也就是模型）面前。但仓库里的货如果是过期的、标签贴错的、同一种物料有三种不同编号的，那么传送带越高效，送到生产线上的垃圾就越多。知识治理层，就是给这个仓库定下的一整套运营规则——谁负责进货、货物如何验收、同类商品如何统一编码、过期商品怎么下架、下游产品线应该引用哪个批次的货。

在实践的早期，我的团队其实已经搭了向量数据库，也做了语义检索，文档上传后能被 AI 引用。那为什么还是问题频出？因为向量检索只管“语义相似的片段”，它不管这些片段是不是彼此矛盾的。一份 2023 年的旧文档和一份 2024 年的新文档，在语义上可能高度相近，但结论可能完全相反。RAG 会把两段都抓给模型，模型为了拼出一篇通顺的文档，会把旧观点和新观点揉在一起，生成一篇看似合理、实则致命的内容。这正是我前 50 篇文档里大量返工的原因。

2.2 治理层的四块基石：抽取、分类、关联、版本

我做知识治理改造时，没有一上来就上复杂平台，而是先把治理对象拆成了四件事，后面所有工具和流程都绕着这四件事转。

2.2.1 抽取：从“整篇文档”到“最小知识单元”

很多人做知识库习惯以“篇”为单位，把一篇文档整体丢进去。但知识的最小单位通常不是文档，而是文档里的某个定义、某个指标、某个结论。比如一份登录接口文档里，真正会被多处引用的知识点是“Token 有效期默认 7200 秒”“Refresh Token 可续期一次”，而不是整篇文档。所以在治理层，我要求所有入库内容先经过一个抽取动作，把关键实体、指标和定义抽出来，按统一格式记录。这样 AI 在生成新文档时，拿到的是“最小知识单元”，而不是整篇原文。

抽取工作最初也有过很痛苦的阶段。我用 AI 自动抽取，结果它自己也会抽错。后来加了个人工复核环节，再往后，我在 Prompt 中为抽取任务单独设计了输出 Schema，把“定义类”“指标类”“流程类”“合规类”分开处理，准确率才算稳定下来。这块后面讲落地步骤时会细说。

2.2.2 分类：形成团队共同的知识地图

分类的意义不只是检索方便，更重要的是建立团队对“知识边界”的共识。我按业务域、产品线、文档类型、受众四个维度来给知识项打标签，而不是单纯按文件名建目录。比如“订单查询接口”既属于“交易域”，也属于“API 文档类”，还属于“开发者受众”。一套多维分类下来，当模型生成一份面向新员工的“订单系统入门”时，它能准确召回最相关的三个维度。

2.2.3 关联：让文档之间形成引用链，而不是互相复制

过去团队写文档喜欢复制粘贴，A 文档里写了一段话，B 文档里又复制一份改改。短期看很省事，长期看是灾难：一旦源头修改，下游全部跟着过时。治理层要求文档之间尽量使用“引用”而不是“复制”，每条被引用的知识项都有唯一 ID。AI 生成文档时，遇到可以引用的内容，直接用引用 ID，而不是自己重新写一遍，这样就从根本上避免了版本漂移。

2.2.4 版本：给每条知识一个“生效状态”

知识是有生命周期的。新接口上线、旧参数废弃、团队调整了命名规范，这些都会让旧知识失效。治理层为每条知识项维护状态字段：草稿、生效中、已废弃。AI 在生成文档时，默认只引用“生效中”的知识。对于已废弃的内容，除非明确说明历史背景，否则不进入生成上下文。这一条看起来简单，却是我整套治理方案里收益最明显的一块。

3. 从零搭建知识治理层的六个落地步骤

3.1 第一步：先盘家底，建一份“知识资产清单”

搭建治理层的第一步不是写一堆制度和规范，而是把你现在手头到底有什么知识盘清楚。我们当时把散落在个人电脑、旧 Wiki、云文档里的所有材料统一拉出来，让 AI 先自动生成一份粗略清单，再人工逐条确认。清单字段包括：文档名称、所属业务域、内容类型、最近更新时间、当前状态（有效/过时/待确认）、可能的负责人。

这份清单的价值在于，它让后续治理有了一个明确的操作对象。没有清单之前，知识治理容易陷入“万事开头难”的迷茫；有了清单，你能看到大量过时内容沉淀在知识库里，它们正是 AI 幻觉和文档矛盾的污染源。第一步做完后，我们的首要任务不是继续写新文档，而是清理和标注旧知识——把明显失效的标记为废弃，把不确定的先挂起并找人确认。

3.2 第二步：定义一套统一的知识元数据模型

知识清单跑通之后，就要给所有知识项规定“身份证格式”。我最终确定了一套六要素元数据：知识项 ID、标题、主题域、内容类型、版本号、生效状态，另外附加负责人和更新时间。这套元数据必须是机器可读的，最好用 YAML 或 JSON 维护，方便后续被 AI Agent 读取。

我踩过的一个大坑是：不同来源的文档里，同一概念叫法不同。比如“用户活跃度”在一份文档里叫 DAU，另一份叫“日活跃用户数”，还有一份直接写成“活跃”。如果不统一命名，AI 在生成文档时就会混用这些说法。所以元数据模型里我特别加了一个“规范术语”字段，把实体别名映射到唯一标准名。这一步极其枯燥，但它是知识治理层的立身之本。

knowledge_item_id: KB-TRADE-00042 standard_name: 订单超时关闭时间 aliases: [订单自动关闭时间, 超时未支付关单时间] domain: 交易域 content_type: 指标定义 version: "2.1" status: active owner: 交易中台-张XX updated_at: 2024-11-03

3.3 第三步：建立主题域和知识层级

元数据解决“每个知识项是谁”的问题，主题域解决“它们之间是什么关系”的问题。我按业务逻辑把团队知识分成交易域、用户域、商品域、营销域、数据基础能力域、平台工程域等主题域。每个主题域再往下挂二级主题，比如“交易域”下面拆成“下单流程”“支付能力”“退款流程”等知识点组。

有了这层结构，AI 生成文档时就有一套“知识地图”作为约束。比如写退款流程相关的文档，系统会优先召回“退款流程”组下的知识项，而不是把整个交易域的所有内容都塞进上下文。这既提高了准确性，也降低了 Token 消耗。团队内部评审的时候也能快速定位问题属于哪个域，责任人一目了然。

3.4 第四步：用“引用 ID”替代复制粘贴，落实版本约束

第四步是最能体现“治理”二字的环节。在旧流程里，A 文档引用 B 文档的某段结论，是把那段结论直接复制进来；新流程要求，所有可引用的结论都必须以知识项为单位注册，拿到唯一 ID，文档里只保留 ID 和必要的上下文提示。

AI 生成文档时，我会在 Prompt 中明确指示：如果遇到已知的知识项，请以“引用 KB-XXX”的方式插入，并附上标准定义；不要自己改写定义内容。这其实是在对抗大模型的“自由发挥”。模型非常倾向于用自己的话重新表达，但表达得越自然，越容易偏离原意。强制引用 ID 的做法如果碰到老版模型，它可能会乱编 ID，所以我加了校验规则：生成完成后，自动检测引用 ID 是否存在且处于生效状态，不存在的直接拦截。

3.5 第五步：把 Prompt 从“万能写作模板”改成“任务卡 + 知识注入”

到了这一步，Prompt 才重新回到我的视野，但它已经不再是主角，而成了一套“任务卡”。任务卡只负责三件事：说明当前任务类型（比如写产品 PRD、写接口文档、写培训手册）、规定输出结构（章节顺序、标题层级、字数范围）、要求必须遵守的约束（引用生效知识、禁止自创指标）。

真正的领域知识不再靠 Prompt 里写一大堆背景资料来硬塞，而是通过知识治理层，按任务需要动态抽取相关的最小知识单元注入到上下文中。这样做的好处是：Prompt 本身变得很短很稳定，不需要每次为了修正一个文档错误就往提示词里加一段规定，最终整个团队维护 Prompt 的成本大幅下降。

我还是坚持写了一个“文档写作军规”，但它的内容已经从原来的“知识条款”变成纯流程规则，比如“所有涉及指标的内容必须给出知识项引用”“禁止把示例数据写成真实数据”等。这些规则虽然也放在 Prompt 里，但它们属于写作约束，不是知识本身。

3.6 第六步：设置质量闸门，让错误文档进不了知识库

最后一步是把“质量检查”做成一道闸门，AI 生成的文档未经检查不能进入正式知识库。检查分三层：

• 第一层是规则检查：标题层级是否完整、必填字段是否缺失、引用 ID 是否有效；
• 第二层是事实比对：把文档中的实体和指标与知识库中的标准知识项做一次自动比对，发现不一致直接标红；
• 第三层是人工抽审：保留随机人工抽检，尤其对高风险主题域（比如对外 API 文档），必须过一遍人工评审。

这道闸门才是把模型输出从“草稿”变成“资产”的关键。经过闸门过滤，文档的返工率从最初的三成降到了不到一成，团队写文档的积极性也提高了，因为大家都知道写出来的东西是可用的，不是写完还要重来。

4. 实战记录：我的 100 篇文档如何从“高产”走向“可信”

4.1 阶段一：批量生产的高产幻觉

我最初两个月几乎每天都在“生产”文档，速度惊人。一个下午能出 3 篇接口文档，一周能搞定 10 篇培训手册。当时的群聊里大家都在夸效率提升，我当时也发过“用 Prompt 批量写文档”的经验帖。直到我决定对已写完的 40 篇做一次全面核查，结果让所有人沉默：其中 12 篇含有事实性错误或者自相矛盾的内容，比例 30%。

这些错误并不难改，但修改过程比想象中耗时，因为你要先找到机器哪里错了，再去找正确的来源。有时候，一篇文档里的同一个错误会出现在三四个地方，改起来像打地鼠。批量生产带来的不是效率，而是把错误批量复制到了各个角落。

4.2 阶段二：知识抽取是我做过最值的一笔投入

被 30% 的错误率刺激后，我开始尝试治理。第一件事就是上面说的知识抽取和元数据建模。我们花了两周时间，把已有文档里最重要的知识项全部抽出来，逐条录入。过程很枯燥，但效果立竿见影：AI 在写一篇新文档时，如果相关知识点已经在库里，它会以引用 ID 的方式直接给出定义，而不是自由发挥。

最典型的变化是“订单超时关闭时间”这个指标。之前有 6 篇文档写了 4 种不同的值，有的说 30 分钟，有的说 15 分钟，还有一篇没写清单位。治理之后，知识库里只有一条标准项，其他文档全部改为引用。AI 再也没在这个指标上报错过数。我开始意识到，知识治理层的价值不在于让单篇文档写得更好，而在于让多篇文档之间不再互相打架。

4.3 阶段三：AI Agent 把治理流程变成自动化闭环

治理规则跑通之后，我还想进一步压缩人工成本，于是尝试用 AI Agent 来做部分校验工作。这个 Agent 不负责“写”文档，它只做三件事：读取新生成的文档、提取其中的实体和指标、与知识库的标准项做一致性比对，然后把不一致的地方标记出来。

这套流程跑通后，文档评审的效率提高了一个量级。原来人工抽审一篇 3000 字的接口文档要 40 分钟，现在 Agent 自动预审只需要 2 分钟，剩下的时间只需要处理被标记的少数冲突点。而且 Agent 在比对时能严格按照我们定义的主数据来，不存在“看多了文档反而被带偏”的问题。

我把这整个过程理解为：AI 生成文档就像流水线生产，知识治理层就是质检和供应链管理。没有供应链管理，流水线开得越快，次品率越高。把治理层建好，AI 的产出才能从一个“高效的撰稿人”升级为“可信的协作伙伴”。

5. 三个绕不开的坑和一套避坑心法

5.1 坑：把知识治理当成一次性项目，做完就松懈

知识治理不是运动会，办完一届就结束。知识是持续生产出来的，治理必须跟着业务节奏常态化运行。我们一度在项目期奋力把 100 篇文档全部治理完，就觉得一劳永逸了，结果两个月后新文档又冒出大量未纳入治理的内容。后来我定了一个简单规则：新文档必须先在草稿区完成治理流程，才能进入正式知识库，有效杜绝了“边生产边污染”。

5.2 坑：想用 Prompt 解决知识正确性问题

这是我最开始的病根。我总觉得只要提示词写得足够强硬、足够详细，模型就不会犯错。但大模型的本质是概率生成，它只要在“猜”，就一定有猜错的时候。知识正确性问题只能靠“引用标准知识项 + 质量闸门校验”来解决，不能靠“吓唬模型”。后来团队里每次有人想往 Prompt 里加常识条款时，我都会问一句：这条应该是一条知识项，还是一句规则？如果它是事实，就该进知识库；如果它是行为约束，才该进 Prompt。

5.3 坑：治理流程脱离用户，文档没人看也照样“治理”

知识治理最容易变成文档管理员的自嗨。我们早期设计了很多元数据字段，做得又规范又细，但使用者根本不在乎；大家只关心“我能不能快速找到我要的东西”以及“看到的东西是不是对的”。后来我做了一次用户回访，发现文档检索系统虽然功能齐全，但用户最常用的还是搜索引擎式的全局搜索，而不是我们精心设计的分类导航。这个反馈帮我调整了治理优先级：优先治理那些被高频检索和引用的知识项，而不是追求所有知识项的平均整洁度。

避坑的心法总结起来就一句话：治理不是为了让知识本身好看，而是为了让知识的消费者睡得着觉。消费者可能是人，可能是 AI Agent，甚至可能是下游的自动化流水线。只要他们因为“知识不可信”多花过时间，治理就有价值。

6. 写在最后：我依然每天写 Prompt，但我先看知识地图

现在工作室的项目里，AI 写文档依旧是日常，Prompt 我也没丢。但每次落笔之前，我第一个打开的不再是提示词编辑器，而是知识治理层的地图页面。先确认这条文档要涉及哪些知识域、哪些知识项处于生效状态、哪些关键定义必须引用，然后再开始搭建 Prompt 的调用逻辑。

如果你也在用 AI 大批量产出内容，无论你是写技术文档、产品手册还是运营文案，我都建议你提前盯住三样东西：第一，你的知识来源是否唯一且可信；第二，你的输出能否追溯到某条标准定义；第三，你的流程里有没有一道机制能在内容进入正式库之前拦住错误。别像我一样，等写完 100 篇再去补课。知识治理这个功夫，越早做，后面省的事越多。