2026年必备：6大作战知识库构建子系统工具全面对比

2026年搭建作战知识库，最容易选错的不是“功能最少”的工具，而是把知识库误当成文档仓库：资料能上传、页面能搜索，却无法说明哪一版有效、谁能看、谁负责更新、内容失效后如何撤下。六类工具的差异，最终落在知识生产方式、权限边界、检索路径和长期维护成本上；选型前先判断知识库要支撑什么决策，再比较软件，通常比先看功能清单更有效。

2026年必备：6大作战知识库构建子系统工具全面对比

一、先讲核心结论：工具不是知识库，工作机制才是

1. 六类工具，六种内容生产方式

本文比较六种常见构建路线：MediaWiki、BookStack、DokuWiki、Wiki.js、MkDocs Material，以及 Confluence。它们不是六个完全同类的产品，而是分别代表大型协作百科、结构化手册、轻量本地维基、可定制的现代维基、文档即代码和商业协作空间。把它们简单排成“第一名到第六名”，会掩盖真正重要的差异。

如果团队经常多人改同一份知识、需要复杂页面关联，优先评估 MediaWiki 或 Confluence；如果内容更像按章节组织的标准手册，BookStack 往往更容易理解；如果环境离线、资源有限，DokuWiki值得进入候选；如果团队习惯 Git、代码审查和版本发布，MkDocs Material更匹配；如果希望自托管，同时要现代化界面和较强配置能力，可以测试 Wiki.js。

我的核心判断是：先选内容治理模型，再选工具。一套工具如果让作者难以更新、审核人无法追踪版本、读者找不到权威答案，即使功能丰富，也只是把低效流程搬进了新界面。

2. 选型先看六个问题

第一次筛选时，我不会先问“有没有 AI 搜索”，而会先确认知识的生命周期。下面六个问题能迅速排除大量不合适选项：

• 内容由谁写：少数专家集中编写，还是一线人员持续补充？
• 内容如何审核：是否需要提交、复核、批准、发布等明确状态？
• 知识如何组织：按主题自由链接、按书籍章节、按目录树，还是按代码仓库版本管理？
• 用户如何访问：仅内网、跨部门、外部协作，还是不同密级和角色分层？
• 部署受什么限制：能否使用云服务，是否必须自托管，是否需要断网可用？
• 谁负责维护：有没有管理员、内容负责人、备份负责人和定期复核机制？

如果上述问题尚未达成一致，立刻进入产品演示通常只会让讨论被按钮、模板和界面带跑。先回答这些问题，再用真实资料做验证，才能知道工具到底解决了什么。

3. 本文比较的口径

六种方案采用同一套评估框架：作者上手难度、结构表达能力、版本与审核、检索与关联、权限和部署、维护成本。产品能力会随版本、插件、部署方式和授权套餐变化，因此本文不承诺某个功能在所有版本中都相同；涉及商业报价、身份集成或高级权限时，应以供应商当前官方文档和实际合同为准。

为避免把推测伪装成实测，后文中所有效率、成本、耗时数字都明确标为情景模拟或建议基准，不是六款产品的公开基准测试，也不是厂商承诺。它们的用途是帮助团队建立可复现的试用方法，而不是替代现场验证。

二、背景和真实场景：作战知识库究竟承载什么

1. 它不是“把资料放到一起”

知识库面对的通常不是单一文档，而是一组相互关联、有效期不同、责任人不同的知识对象。例如任务准备清单、装备维护规程、异常处置流程、培训材料、复盘记录和术语定义。这些内容既要能被查到，也要能判断是否适用、是否过期、是否允许当前用户阅读。

如果只把 PDF、表格和扫描件集中上传，团队得到的是一个文件柜。文件柜解决了“资料放在哪里”，却没有解决“哪份资料是当前有效版本”“某项规定适用于哪个场景”“旧版内容是否仍可参考”。当组织规模变大，这些问题会比存储容量更早变成瓶颈。

2. 三类典型使用场景

场景一：标准流程型。内容稳定、章节顺序明确，读者需要按步骤执行。典型对象包括检查表、培训手册和常见故障处理指南。此类场景重视结构一致、版本可见和快速浏览，BookStack或文档站点路线通常比完全自由的页面网络更自然。

场景二：持续协作型。多个岗位共同补充内容，知识之间存在大量交叉引用，问题和答案会持续演进。此类场景需要低门槛编辑、页面关联和变更追踪，MediaWiki、Wiki.js或 Confluence 更值得测试。

场景三：受控发布型。内容必须经过同行评审、变更审批和正式发布，某些版本需要与软件、装备或流程版本绑定。若技术团队本来就使用 Git，MkDocs Material 可以把审查和发布流程纳入熟悉的代码协作方式；但对不习惯 Markdown 的人员，学习成本不能忽略。

3. 知识库子系统应拆成哪些环节

我通常把“构建知识库”拆成七个子系统，而不是按软件菜单来拆：内容采集、分类与元数据、编辑与协作、审核发布、检索与导航、权限与审计、备份与生命周期管理。工具可能只强于其中两三项，其他能力要靠插件、外围流程或组织规则补足。

尤其要注意，搜索框并不等于可用检索。用户能否找到内容，还受到标题命名、同义词、标签、文档拆分粒度、搜索权限和过期内容处理影响。搜索引擎再先进，也无法稳定补救一套含糊的分类体系。

三、六种工具路线：优势、限制和适用边界

1. MediaWiki：适合内容密集、链接关系复杂的知识网络

MediaWiki以页面和链接为核心，适合建立条目数量较多、主题交叉频繁的知识网络。它的优势不是“看起来像百科”，而是鼓励内容拆成可独立维护的主题单元，再通过链接和分类建立关系。团队若已有稳定的编辑规范、分类体系和管理员制度，扩展空间较大。

它的代价是需要治理。页面命名、分类规则、模板和权限策略如果没有统一约定，站点可能很快出现重复条目、概念混用和分类膨胀。对只想发布一套几十页标准手册的小团队而言，这种自由度可能大于实际需要。

适用判断：知识条目多、交叉引用多、持续补充者较多时值得测试；若内容必须严格按固定章节顺序阅读，或者作者几乎不愿意学习维基语法，应先做可用性试验。

2. BookStack：适合章节感强、结构相对固定的手册

BookStack采用书架、书籍、章节和页面等结构，读者容易理解内容层级。它适合把一组制度、操作说明或培训材料组织成一册“可浏览的手册”，并能降低新用户面对空白页面时的困惑。对以阅读和查阅为主、协作关系不太复杂的团队，这种明确结构是优点。

但固定结构也会形成边界。知识如果天然是网状关系，一条内容横跨多个主题，维护者可能要在章节归属、重复引用和交叉链接之间做取舍。试用时应检查内容能否既保留书籍结构，又方便跨章节引用，而不是只看首页是否整洁。

适用判断：内容层次清晰、读者按目录浏览、管理者希望快速建立章节模板时优先试用。若大量用户会同时编辑相互交叉的条目，需重点验证审核与变更协作是否够用。

3. DokuWiki：适合轻量自托管和低依赖场景

DokuWiki以较轻量的部署方式和文件存储特征受到一些自托管团队关注。对网络受限、运行环境简单、希望减少数据库依赖的场景，它可能有实际吸引力。它的价值在于“够轻、能自己管”，而不是追求最现代的协作体验。

轻量并不代表零维护。权限配置、插件兼容、安全更新、备份恢复和内容迁移仍需负责人。尤其是插件带来的能力，必须纳入版本升级和安全审查计划。试用时别只看首次安装耗时，也要模拟一次插件升级和备份恢复。

适用判断：部署自主性、低资源占用和简单维护优先，且团队有基本运维能力时可列为候选。若核心用户希望获得现代化编辑体验或复杂工作流，需通过真实作者测试验证落差。

4. Wiki.js：适合需要自托管并重视现代界面的团队

Wiki.js提供现代化维基体验，并支持多种部署和身份认证相关集成能力，具体可用范围应以对应版本文档为准。它适合既希望自托管、又不想接受过于传统界面的团队。对技术能力较强的组织，它的配置和整合空间值得试验。

需要留意的是，功能丰富与运维简单不是一回事。数据库、身份认证、存储、备份、升级路径和权限模型都要在概念验证中检查。不要把“能连上身份系统”直接等同于“权限设计已经正确”，还需要测试用户离职、角色变化、外部访问和恢复场景。

适用判断：团队具备容器、数据库或应用运维能力，并且需要可控部署和现代界面时，可优先进入试点。若组织没有明确的服务负责人，先评估托管型方案或降低自定义范围。

5. MkDocs Material：适合文档即代码和受控发布

MkDocs Material以 Markdown 文件生成文档站点，适合把内容放入版本控制，让变更通过提交、审查和发布流程管理。对于开发、工程、技术保障团队，版本差异可追溯、构建可自动化是显著优势。内容和代码、配置或发布版本需要同步时，这条路线尤其自然。

它的主要门槛是作者工作方式。熟悉 Git 的人会觉得审查流程清晰；习惯在线富文本编辑的一线人员，可能觉得提交文件、解决冲突和等待发布不够直接。工具可以让审核严格，却不能保证审核者真的读了内容，也不能保证非技术用户愿意参与。

适用判断：内容由技术团队维护、版本绑定要求高、发布过程需要审计时非常适合验证。若内容主要来自大量非技术用户，必须先设计低门槛采集入口和编辑支持。

6. Confluence：适合已有协作生态的组织知识空间

Confluence的优势通常来自团队协作、页面编辑和既有生态的整合，而不仅是知识页面本身。若组织已经在使用相关协作套件、身份管理和项目工作方式，采用同一生态可能减少账户和协作摩擦。但云端、自托管或不同授权方案的可用能力、价格和限制可能不同，采购前要逐项核验。

商业协作平台常见的风险不是“功能不够”，而是空间、页面、权限和模板逐渐增多，却没有统一的内容责任机制。没有所有者和过期处理规则时，页面越多，用户越难分辨哪些是规范、哪些是讨论记录、哪些已失效。

适用判断：组织已形成相应协作生态、需要广泛参与和较低编辑门槛时可优先评估。若部署边界、数据驻留或离线能力非常严格，应把合规和架构约束放在功能体验之前。

四、常见误区：功能列表看起来完整，知识却未必可用

1. 把上传量当作知识资产

文件数量、页面总数和存储容量，都不能直接说明知识库的可用程度。一个拥有数万份文件的库，如果标题含糊、版本混杂、无责任人，用户仍会回到群聊里问“谁有最新版本”。上传越快，未经整理的重复内容越多，后期清理可能越昂贵。

建议把衡量口径从“收录多少”改成“任务能否完成”。例如新成员能否在限定时间内找到当前有效流程；遇到异常时，能否判断文档适用条件；审核人能否看出变更影响了哪些相关页面。这些问题比页面总量更接近真实价值。

2. 把全文搜索当作信息架构

搜索能处理用户记得关键词的情况，却不擅长弥补概念缺失和内容重复。若“故障处置”“异常处理”“问题解决”分别指向不同但相近的页面，搜索结果可能很多，却没有明确答案。检索效果需要标题规范、别名词表、标签、适用条件和权威版本共同支撑。

我建议试用时准备一组真实问题，而非只搜索产品演示中的标准词。每个问题要记录首屏是否出现权威答案、用户是否需要打开多页、是否误读旧版本。没有这组测试，所谓“搜索效果好”往往只是主观感觉。

3. 以为权限配置等于内容安全

权限控制至少包含身份认证、角色授权、页面或空间边界、外部分享、审计记录、离职回收和备份保护。某项功能在产品中存在，不代表已经正确配置；更不代表用户能理解自己为什么看不到内容，或管理员能追踪谁修改了关键页面。

权限验证应使用不同角色的测试账号，覆盖查看、编辑、审核、管理和外部协作者等身份。还要模拟角色变化和账号停用。对敏感知识，必须确认搜索结果不会泄露标题、摘要或附件信息，不能只检查页面正文是否受限。

4. 把“人人可编辑”当成协作成熟

开放编辑可以扩大知识来源，但如果没有内容责任人和质量门槛，可能提高误改、重复创建和未经确认的经验传播风险。相反，所有内容都由少数管理员录入，也容易形成瓶颈，让一线经验迟迟进不了系统。

更务实的办法是区分内容等级：一般经验可以社区协作；标准流程要指定审核人；高风险内容需要版本、批准和回滚规则。工具选型要看它能否支撑这样的分级，而不是只比较“可不可以编辑”。

5. 只看首日搭建，不看一年后的维护

演示环境里建一个页面很快，真正的成本出现在内容增加、作者更换、插件升级、权限调整和旧知识清理之后。工具越可定制，越要计算管理能力；流程越严谨，越要计算作者等待时间。试点至少要覆盖一次内容变更、一次撤回、一次权限调整和一次恢复演练。

五、专业判断逻辑：怎样把六种候选缩到一两种

1. 先设置不可妥协的门槛

打分之前先写清楚硬约束。比如必须自托管、必须支持内网身份认证、必须保留可审计版本、必须允许断网访问，或者必须在指定环境运行。硬约束不满足的方案，不应靠“界面好看”加分救回来。

我建议把硬约束控制在五到八项，并指定每项的验证方式。比如“支持权限”太笼统，可以改为“普通读者看不到受限页面标题，离职账号在约定时间内撤销访问，管理员能导出变更记录”。可验证的要求才能减少供应商演示和实际部署之间的落差。

2. 再按工作负载分配权重

权重不是行业标准，而是帮助决策者明确取舍的工具。流程手册项目可以提高可读性和版本治理的权重；开放协作知识库可以提高编辑便利和页面关系的权重；受控发布场景则应提高审计和权限的权重。

不要把所有项目都用同一套分值。试点之前，业务负责人、知识管理员、运维人员和实际作者应分别给出优先级，再讨论分歧。比如管理员重视备份，作者重视编辑，读者重视搜索；如果只让采购负责人填评分表，评分就不会反映实际使用。

3. 用任务脚本而不是产品导览做试用

试用最好以同一批材料、同一组用户和同一套任务脚本进行。每款工具至少覆盖四类角色：内容作者、审核人、读者和管理员。只让管理员评估，会高估配置能力、低估日常编辑阻力；只让读者体验，也看不到审核和恢复成本。

我会让参与者完成这些任务：新建一页内容、补充适用范围、引用相关页面、提交审核、定位当前有效版本、纠正错误并撤回、调整某角色权限、恢复被误删内容。记录成功率、耗时、求助次数和错误类型，而不是只问“你喜欢哪个界面”。

4. 评分必须保留证据，不要只留总分

每个分数后面都应附一条证据，例如“作者在无需培训的情况下完成了页面更新”，或“管理员无法从默认界面完成指定的权限回收”。没有证据的分数只是偏好；总分也可能掩盖关键缺陷。若一款工具在硬约束上失败，即使总分最高，也不应进入采购决策。

六、具体案例和数据观察：一个六周试点应该怎么做

1. 案例设定：先试一条业务链，不要一次搬完整个资料库

下面用一个示例组织说明试点设计：约120名使用者，分布在三个业务小组，原始资料散落在共享盘、群聊和个人笔记中；知识内容包括标准流程、常见问题和复盘记录。这个设定是情景案例，不代表某家真实组织，也不是产品客户数据。

最常见的错误是先把所有旧资料迁移进新工具，再期待用户自然采用。更稳妥的做法是选一个重复查找频率高、内容边界相对清楚的流程，整理30至50条内容，包含最新版本、历史版本、重复材料和权限受限内容。这个小样本足以暴露分类、审核和权限问题。

2. 六周节奏：每周都要留下可观察证据

1. 第一周：基线调查。收集用户常问问题、当前查找路径、平均耗时和错误来源。至少访谈读者、作者、审核人和管理员，不只听项目发起人意见。
2. 第二周：内容整备。给样本内容补充标题、来源、责任人、适用条件、有效版本和复核日期。无法确认来源的材料单独标记，不要悄悄当作正式知识发布。
3. 第三周：候选工具配置。只配置试点必需能力，避免花时间打磨首页视觉。建立相同目录、用户角色和权限边界，确保各候选大致可比较。
4. 第四周：角色任务测试。让真实作者和读者独立完成任务，记录失败、求助和返工。测试问题要来自日常工作，而不是产品功能说明中的示例。
5. 第五周：变更与恢复演练。改动一条关键内容，走完整审核和发布过程；再模拟错误修改、账号变动、备份恢复和旧版本查找。
6. 第六周：复盘与决策。汇总任务完成率、查找时间、内容质量、维护投入和用户反馈。写清楚哪些问题是工具造成，哪些是流程、数据或培训造成。

3. 示例指标：用同一口径比较前后变化

示例试点可以跟踪五项指标：任务成功率、找到正确版本的中位耗时、无帮助完成编辑的作者比例、逾期未复核内容占比、每周管理员维护时间。所有指标都应明确样本量和计算方式。比如“查找时间”从用户读到任务题目开始，到确认权威页面为止，不应只计算搜索框响应速度。

以下数据只用于展示如何制定目标，属于建议基准和情景模拟，不应被引用为行业平均值。真实试点中，用户熟悉度、内容复杂度、网络环境和训练方式都会改变结果。

4. 如何判断结果是工具带来的

如果试点后查找时间下降，不能立即归功于软件。可能是内容被集中整理、用户接受了培训、问题更简单，或者试点期间管理员随时提供帮助。为了减少误判，尽量使用同一组任务和相近用户，记录是否接受过培训、是否求助，以及内容是否经过人工清洗。

可以把结果拆成三层：内容质量变化、流程变化、工具变化。比如“标题统一后搜索改善”主要是信息架构的贡献；“审批时间下降”可能来自审核职责明确；“版本差异更容易追踪”才可能是工具功能的直接贡献。区分原因后，组织才能知道应该复制哪种改进。

七、不同情况下的行动建议：让选型匹配组织成熟度

1. 小团队、少量内容、运维能力有限

如果内容量不大、作者集中、没有复杂权限，优先考虑结构直观、日常维护简单的方案。不要因为未来可能需要复杂工作流，就在第一阶段引入大量插件、自动化和定制开发。先把内容分类、责任人和复核频率跑通，通常比堆功能更能减少混乱。

候选可从 BookStack、托管协作平台或轻量自托管路线开始。选择时要回答：普通作者是否愿意更新、内容能否导出、权限是否够用、管理员离开后谁接手。若团队没有运维负责人，自托管方案看似省授权费，实际可能把成本转移到少数技术人员身上。

2. 技术团队、内容和软件版本强绑定

如果每次软件或流程发布都会更新配套文档，优先验证 MkDocs Material 和版本库工作流。把文档与变更审查放在同一条流程里，可以更容易追踪“哪次修改导致文档变化”。但要把非技术人员纳入流程，必须明确谁负责把业务经验转成可审查的文档。

不要只试“工程师写一页 Markdown”。还要测试预览、链接检查、图片管理、版本切换、发布回滚和紧急修订。若操作人员无法提交修改，可设立轻量反馈表单或内容提案入口，但要避免让提案长期停留在没人处理的队列中。

3. 多部门参与、知识关联密集

若不同团队持续补充知识，且条目间交叉引用频繁，可重点比较 MediaWiki、Wiki.js 和 Confluence。试点不要只看编辑器体验，还要看如何处理术语冲突、重复条目、页面所有权、空间边界和跨部门审核。

此类组织最好设立知识治理角色，但不必让一个中心团队审核所有内容。可采用分级责任制：内容作者对事实负责，领域负责人对专业性负责，知识管理员对结构和生命周期负责。工具要配合责任分工，而不是把所有治理工作塞给系统管理员。

4. 网络或部署约束严格

若业务环境必须自托管、限制外部网络，或要求离线访问，先验证架构和数据边界，再讨论界面和插件。候选可包括 DokuWiki、Wiki.js、MediaWiki，以及构建为静态站点的 MkDocs Material；最终适配取决于身份系统、存储策略、更新方式和现场运维能力。

建议做一次断网演练：普通用户能否访问、搜索是否可用、附件是否完整、更新如何分发、备份能否在隔离环境恢复。离线可用不只是“页面能打开”，还涉及搜索索引、附件链接、权限缓存和版本同步。

5. 内容审核和审计要求高

先列出哪些知识需要正式批准、哪些只需同行复核、哪些属于非正式经验。然后用真实案例测试权限、审核状态、版本对比、回滚和日志导出。不要假定所有平台的页面历史记录都等于完整审计能力；对法规或内部控制要求，应由安全、法务或合规责任方确认。

如果试点发现工具本身缺少关键控制能力，评估外围流程是否能可靠补足，并计算补足后的维护成本。若需要大量脚本和人工登记，长期风险通常高于短期省下的授权费用。

6. 现有协作生态已经成熟

如果组织已有统一账号、协作平台和内容协作习惯，Confluence等既有生态方案的推广摩擦可能较低。此时重点不是“从零选最强产品”，而是核查现有许可证是否覆盖需求、数据能否迁移、权限是否可治理，以及未来退出成本是否可接受。

反过来，如果现有生态的空间和页面已经非常混乱，不应把“大家都在用”当作充分理由。先抽样审计内容和权限，再决定沿用、重构还是新建。迁移旧混乱只会让新系统继承旧问题。

八、不同情况下的取舍：不要把不存在的“全能工具”当目标

1. 灵活度与治理成本之间的取舍

自由编辑、灵活分类和高度定制能适应复杂知识，却会提高命名、标签和权限治理难度。结构越固定，维护越简单，但遇到跨主题关系时可能需要重复内容或额外导航。团队要问的不是“哪种结构最好”，而是“哪种不一致最容易被发现和纠正”。

如果组织尚无内容规范，倾向结构清晰的起步方案；如果已有成熟编辑规范和维护者，可以接受更灵活的工具。不要在没有治理能力时追求最大的自由度。

2. 自托管控制权与持续运维之间的取舍

自托管可以增加部署和数据控制的灵活性，但同时意味着补丁、备份、监控、身份接入和恢复都需要责任人。云端或托管方案可能减少基础设施维护，却需要认真评估数据处理、网络依赖、授权变化和迁移能力。

总拥有成本至少应包含：授权或基础设施费用、部署工时、每月运维、管理员培训、内容迁移、备份恢复、升级测试和退出迁移。只比较许可费用，会把最重要的隐性成本漏掉。

3. 作者开放度与内容可靠性之间的取舍

开放贡献提高知识覆盖面，也可能增加未经验证内容进入正式流程的概率。严格审批有助于控制风险，却会让内容更新变慢。较好的折中不是在“完全开放”和“全部封闭”之间二选一，而是按影响范围和风险等级配置不同流程。

一般经验可以允许快速补充并标记“待验证”；规范性内容应指定审核人和复核日期；高风险内容则需要授权发布、变更记录和撤回机制。工具如果无法表达这些状态，团队就要评估是否值得用外部流程补足。

4. 功能丰富与长期可维护之间的取舍

插件、自动化和 AI 检索能提升体验，但也引入安全审查、兼容性、数据授权和结果解释问题。不要在第一阶段为了展示效果就叠加多个插件。先确认基础内容质量、权限边界和反馈闭环，再逐项引入增强能力。

对生成式搜索尤其要设定边界：回答应能回到来源页面，展示版本和更新时间；权限应在检索环节生效，而不只是打开页面时才检查；对缺少依据的问题，应允许系统明确表示未找到可靠答案。若这些条件无法满足，AI摘要可能让错误内容更容易被相信。

5. 迁移便利与供应商锁定之间的取舍

采购前要抽取一批真实页面和附件进行导出、再导入测试。检查标题、链接、图片、表格、标签、权限和版本历史能保留多少。只看到“支持导出”并不能说明迁移可行，格式变形和链接失效会影响知识可用性。

迁移能力还包括组织能力：谁能批量导出、是否有稳定格式、附件是否能成组获取、历史记录是否保留、账号数据如何处理。越依赖专有模板、插件和自动化，越应提前设计退出方案。

九、结尾：下一步不是继续看演示，而是跑完一组真实任务

1. 用最小试点得到可复核的结论

六种工具没有脱离场景的绝对优胜者。MediaWiki偏向知识网络，BookStack偏向结构化手册，DokuWiki偏向轻量自托管，Wiki.js偏向现代化自托管维基，MkDocs Material偏向版本化技术文档，Confluence偏向协作生态中的团队知识。它们的优劣必须放回作者、读者、管理员和部署条件中判断。

下一步可以按这个顺序行动：先写硬约束，再选30至50条代表性内容；确定四类测试角色，使用同一组真实任务；记录成功率、查找时间、求助次数、权限缺陷和维护工时；最后保留原始试用证据，而不是只留一张总分表。

2. 最重要的选型判断

真正值得采购的不是“最强知识库工具”，而是能让权威知识持续产生、被正确找到、按时更新并在必要时撤回的系统。如果一个候选方案在演示中令人惊艳，却没有人愿意写、没有人负责审、没有办法复核旧内容，它就还没有通过选型。

从一条高频业务链开始，先跑通采集、整理、审核、发布、检索和复核，再决定是否扩展到整个组织。知识库的竞争力不来自页面数量，而来自用户在关键时刻能否找到正确、有效且有责任人的答案。