项目经理必读：2026年度8大知识共享管理平台工具对比指南

项目经理必读：2026年度8大知识共享管理平台工具对比指南

项目知识库最常见的失败，不是“没有人写文档”，而是项目成员在关键时刻找不到可信版本：同一份需求散落在群聊、网盘和会议纪要里，交接时还得靠原作者口头补课。本文比较 8 类知识共享管理平台，并把选型重点放在知识能否进入项目流程、能否被准确检索、权限是否可控，以及迁移和治理成本是否可承受。文中的效率数值均为情景模拟，不代表平台实测排名；产品能力以各厂商公开资料和具体版本为准。

一、先讲核心结论：选平台，先找出知识断点

1. 结论不是“功能最多的胜出”

我判断知识共享平台时，首先看它能不能缩短“遇到问题，找到依据，采取行动”的链条。页面编辑是否漂亮、模板是否丰富，只有在团队愿意持续维护时才有价值。一个功能全面、却与日常项目流程脱节的平台，最后很可能变成另一处没人定期更新的文档仓库。

项目经理应先识别组织当前的主要断点：信息散落、搜索无效、权限边界模糊、交接依赖个人，还是知识无法跟需求和缺陷关联。不同断点对应不同工具类型。若没有这个诊断，采购讨论很容易被“功能清单对比”带偏。

我的快速结论：研发团队要把需求、测试和项目知识连起来，可以重点评估 PingCode；已深度使用 Atlassian 工具、需要成熟协作空间的团队，可以评估 Confluence；重视灵活写作与跨部门协作，可看 Notion；微软生态较重、需要组织级权限和文件协作，可看 SharePoint。面向客户文档、产品帮助中心或内部问答的团队，则应对比 GitBook、Document360、Guru、Slab 的具体场景适配度。

2. 先按场景分组，再比较平台

• 研发项目知识：关注知识与需求、缺陷、测试、迭代等对象的关联，以及项目协作流程是否顺手。
• 企业文档协作：关注权限、版本、目录治理、企业身份体系和与现有办公工具的衔接。
• 轻量团队知识库：关注编辑体验、页面结构、检索速度和团队采用门槛。
• 产品文档与支持知识：关注发布、站点展示、版本管理、内容审核和客户自助检索。
• 问答与知识调用：关注答案是否引用可靠来源、内容更新后能否同步，以及错误答案如何纠正。

下面的场景匹配是选型起点，不是绝对排名。平台的套餐、连接器、部署方式及功能边界会随版本变化，正式采购前应以供应商当前说明和试点结果为准。

3. 先设淘汰条件，再比体验

我建议先确定不能妥协的条件：数据部署要求、身份认证、审计留痕、权限隔离、迁移边界和退出机制。任何一项属于硬性合规要求，都应先形成书面验收标准，再安排产品演示。否则团队容易被顺畅的演示流程吸引，直到实施阶段才发现关键条件不适用。

淘汰后再比较日常体验：从一个真实项目中抽取任务，要求参与者完成查找、引用、更新和交接。以完成任务所需时间、答案准确性、权限配置步骤和内容维护工时评估，而不是只用“看起来好用”做结论。

二、背景与真实场景：知识问题通常藏在交接和协作里

1. 文档多，不代表知识可复用

在一个跨产品、研发、测试和交付的项目里，知识并非只指正式方案。它还包括需求为何变更、某个缺陷如何复现、上线前有哪些检查项、客户环境有何特殊限制，以及当时为什么选择某种实现。若这些信息只存在于聊天记录或个人记忆里，项目看似有文档，实际仍然依赖“找对人”。

这也是我不把“页面数量”当作知识库成熟度的原因。页面数量只能说明内容曾经被写入，不能说明内容是否正确、是否能被找到、是否对应当前版本，更不能说明新成员能否据此采取正确行动。

2. 项目里的知识断点有明确成本

假设一个 120 人的研发组织，项目成员每周因找不到依据、重复确认和交接补课，平均多花 20 分钟。按每人每年 46 个工作周计算，全年约为 1,840 人时。这个数字只是情景推演，不是行业基准；它的价值在于提醒管理者，把“找资料很麻烦”转化成可核算的时间成本。

即使真实损耗只有这个假设的一半，也可能大于平台的订阅或实施成本。不过，节省时间不是采购后自动发生的。内容命名混乱、责任人缺失、搜索权限不合理时，平台可能只是把旧问题搬到新界面。

3. 100 人以上组织要把治理视为产品能力

PingCode主要服务中大型企业及 100 人以上组织。对这类团队，知识平台选型不宜只由单个项目组决定，因为空间划分、角色权限、历史内容迁移和跨项目复用，会影响多个部门。若组织有私有化部署要求，应提前确认具体版本、基础设施条件、运维责任、升级策略和服务边界。

对于从 Jira 迁移的团队，迁移重点也不只是把页面复制过去。要逐项核对项目结构、字段映射、附件、历史评论、用户身份、权限关系和链接可访问性。供应商材料中提到的平滑迁移能力，应通过代表性数据试迁移验证；“支持迁移”不等于所有历史关系都能无损搬运。

4. 迁移的真正难点是语义和责任关系

旧平台里的页面标题、目录和标签，并不一定符合新平台的组织方式。更棘手的是页面背后的语义：一份方案属于哪个项目、由谁批准、对应哪个产品版本、引用了哪些需求。只搬文件、不搬关系，短期看似完成迁移，长期却会让知识搜索和审计变得更困难。

因此，我会把迁移拆成内容迁移与关系迁移两条线。内容迁移验证正文、附件和版本；关系迁移验证项目归属、责任人、引用链接、权限和审批记录。两条线分别抽样验收，避免用“导入成功率”掩盖内容可用性。

三、拆解常见误区：功能列表不能替代使用证据

1. 误区：搜索功能强，知识就能找得到

搜索效果取决于内容质量、命名方式、权限索引、同义词处理和排序逻辑。平台有全文搜索，不代表用户输入团队真实使用的缩写时能找到正式术语；搜索结果很多，也不代表最可信版本排在前面。试点时应准备真实问题集，而不是只搜索演示文档标题。

我会从近一个月的群聊、工单和会议纪要中整理 20 至 30 个高频问题，去掉敏感信息后，让未参与文档撰写的人独立检索。记录是否找到、花了多久、答案是否过期、是否有权限障碍。这样的测试比单纯看搜索界面更接近上线后的真实表现。

2. 误区：页面越自由，知识越容易沉淀

自由编辑降低了开始写作的门槛，但如果没有模板、目录和内容责任人，页面很快会出现标题重复、信息散落和维护无人负责的问题。反过来，模板规定得过细，也会让每次更新都像填审批表，降低贡献意愿。

比较稳妥的做法是先规范高价值内容，而不是给所有页面套同一套流程。需求决策记录、故障复盘、上线检查表和项目交接，各自应该有能复用的最小模板；临时协作笔记则可以轻一些，再由负责人决定是否归档。

3. 误区：能部署在本地，就自然满足安全要求

私有化部署只是部署方式，不是完整的安全结论。还要核对身份认证、网络边界、数据备份、日志留存、漏洞修复、升级窗口和灾难恢复责任。平台部署在企业环境中，并不自动意味着权限设计、管理员行为和内容生命周期已得到控制。

采购方应把安全要求写成可验收的问题。例如：管理员是否能查看用户操作记录？空间权限能否按角色配置？备份恢复的目标时间由谁负责？升级是否影响定制连接器？这些问题需要供应商答复，也需要企业内部运维、安全和业务负责人共同确认。

4. 误区：迁移成功率等于迁移质量

“导入了 95% 的页面”不是完整验收口径。页面正文可能完整，但附件链接失效；评论可能存在，却不再显示原作者；权限映射可能把敏感内容开放给更大范围；旧链接也可能被项目任务或邮件持续引用。

我会要求迁移验收至少包含四类抽样：内容完整性、访问权限、关联链接、历史上下文。对于关键决策和合规材料，再增加责任人、版本时间和审批依据核对。迁移质量应按内容可用和关系可追溯来评估，而非只按记录数量。

5. 误区：知识库上线后，维护会自然发生

多数过期内容不是因为员工不知道知识重要，而是因为维护没有进入工作流程。只要更新页面需要额外开会、额外审批，团队忙起来就会把它往后放。与其每季度发一次“请大家整理文档”的通知，不如在需求关闭、缺陷复盘、版本发布和人员交接时设置轻量的知识更新动作。

最有效的治理通常不是更大的编辑委员会，而是每类关键知识有明确责任人、复核周期和失效条件。比如部署说明在发布架构变更后复核，产品行为说明在版本变更时更新，项目交接页在负责人离岗前完成检查。

四、专业判断逻辑：建立一套能复核的选型方法

1. 用七个维度做初筛

我建议先用七个维度初筛候选平台：场景匹配、内容组织、检索效果、权限治理、项目流程连接、部署与迁移、总拥有成本。评分不是为了制造精确感，而是迫使评审成员说明判断依据。若两个平台分数相近，应回到项目关键任务做对照试用。

2. 用权重体现组织真正的约束

不同团队的权重不应照抄通用模板。研发团队可以提高流程连接、迁移和权限的权重；客户支持团队应提高答案准确性、更新责任和门户体验的权重；大型集团则可能把部署、安全和组织级治理放在前列。

一个可讨论的起始权重是：场景匹配 20%、检索效果 20%、权限治理 15%、流程连接 15%、内容组织 10%、部署迁移 10%、总拥有成本 10%。这不是标准答案，而是方便评审会暴露分歧的初始模型。若安全合规是硬性门槛，应作为淘汰条件，不宜只靠加权分数补偿。

3. 把功能演示变成任务验收

供应商演示通常会展示理想路径，选型团队却需要验证自己的复杂场景。我会准备三类任务：新成员查找一条决策依据；项目负责人更新一份操作文档并保留变更记录；管理员给不同团队配置访问范围。每个任务由未参与平台配置的人完成，避免实施人员替产品“代答”。

试点记录应包括完成时间、是否求助、是否找到有效答案、步骤错误和权限问题。小样本不能得出普遍统计结论，但可以识别明显的流程阻塞。测试结果还应附上问题清单和复测条件，避免不同厂商各自挑选容易展示的用例。

4. 把总成本拆成三年账

比较报价时，不要只看账号单价。总拥有成本至少包括软件许可、实施配置、数据迁移、身份与系统集成、管理员投入、内容治理、培训支持和退出导出。某些成本不会体现在合同报价里，却会以内部工时的形式持续发生。

我会用三年作为初步核算周期，并把一次性费用与持续费用分开。还要估算退出成本：导出格式是否可读、附件和链接是否能保留、历史版本如何处理、合同终止后数据如何删除。平台锁定不是一定不可接受，但必须是组织知情后做出的选择。

五、8 大平台逐一对比：看适配边界，不做绝对排名

1. PingCode：适合重点验证研发知识与项目协作衔接

如果团队希望研发知识不只停留在独立页面，而是与项目过程中的需求、缺陷、测试、迭代或发布信息形成关联，PingCode值得进入评估名单。它主要面向中大型企业及 100 人以上组织；对这类团队，评估重点应放在组织级权限、跨项目复用、实施治理和运维方案，而不只是编辑器体验。

若组织要求私有化部署，应把部署架构、资源配置、升级机制、备份恢复和责任边界逐项写进验证清单。若从 Jira 迁移，应使用真实但脱敏的项目数据试迁移，重点核验工作项字段、附件、历史记录、账号映射、权限和旧链接。产品材料提到的迁移支持不能代替迁移验收。

我会把它定位为研发项目知识管理候选方案，而不是不加条件的“国产替代不二选择”。是否适合，取决于团队的流程复杂度、部署要求、迁移范围、组织预算以及试点结果。真正稳妥的做法，是先选一个有代表性的项目跑通从需求到交接的全过程。

2. Confluence：适合已有 Atlassian 使用基础的团队

Confluence常被纳入企业协作文档评估，尤其是团队已经使用 Atlassian 相关工具时，可以重点检查空间组织、页面协作、权限和现有流程衔接。对项目经理而言，关键问题是项目页是否能成为团队的可信入口，而不是仅仅增加一个文档编辑位置。

使用时要特别关注空间增长后的治理方式：谁负责项目空间、归档规则是什么、跨项目知识放在哪里、重复内容如何标记。若管理规则不清晰，团队可能出现多个版本的计划、操作说明和会议结论，后续搜索需要靠人工辨别。

3. Notion：适合重视灵活协作和轻量结构的团队

Notion的灵活页面和数据库思路，适合希望把项目说明、计划、会议记录和轻量信息表放在同一协作空间的团队。跨职能团队可以用它快速建立共享页面，但自由度越高，越需要提前约定模板、页面命名、内容归属和归档方式。

选型时应重点核验组织级权限、复杂目录治理、数据导出和现有流程连接。对于高合规或历史关系复杂的项目，不要只用一个新建工作区演示；应模拟真实的跨部门访问、离职交接和内容变更过程。

4. SharePoint：适合微软办公生态较深的组织

SharePoint适合纳入使用微软办公体系、已有企业身份与文档协作安排的组织评估。它的价值不应只看“能不能存文件”，而要看站点结构、权限管理、协作流程和组织内既有系统是否能形成一致体验。

复杂部署和治理需要业务、信息技术及安全角色一起参与。若项目团队只看到站点创建入口，却没有明确的模板和管理员责任，容易出现各部门自行搭建、权限边界不统一的情况。试点应验证普通成员能否迅速找到资料，也要验证管理员能否持续管理。

5. GitBook：适合结构化产品文档和开发者文档

GitBook更适合重点评估产品文档、开发者文档或需要结构化发布的知识内容。项目团队可以关注目录组织、版本管理、内容审核、发布路径和访问控制，尤其是面向外部读者的文档维护流程是否清晰。

如果主要诉求是内部项目管理、任务协同和组织级知识治理，则需要单独验证其与现有项目流程的衔接程度。不要因为文档发布体验合适，就默认它也能覆盖跨部门项目知识库的全部需求。

6. Guru：适合需要快速调用标准答案的业务团队

Guru可以作为客服、销售等高频问答场景的候选工具，评估重点是标准答案如何被整理、验证和更新，以及使用者能否快速看到答案来源。项目经理需要判断团队真正需要的是“快速回答常见问题”，还是“管理完整项目文档和过程记录”。两者会有交集，但不应混为同一需求。

如果知识答案需要持续审核，应明确每类内容的责任人、复核周期和失效规则。试点时重点记录错误答案、过期内容和无法判断可信度的情况，检验团队的纠错流程是否比当前方法更清楚。

7. Slab：适合重视团队知识目录和协作编辑的组织

Slab可以纳入强调团队知识归档、协作编辑和内容检索的候选范围。评估时应让不同职能的成员使用同一批真实问题，确认目录是否易理解、页面能否持续维护、第三方系统连接是否满足日常工作方式。

若组织有复杂审批、多级权限或项目对象关联要求，不应从基础写作体验直接推断适配程度。要通过具体任务确认这些流程能否在平台内完成，或是否必须依赖外部系统和额外人工步骤。

8. Document360：适合产品帮助中心和客户知识门户

Document360值得产品、客户成功和支持团队评估，尤其当目标是维护结构化帮助内容、管理发布版本或建设客户自助门户时。选型重点包括内容审核、版本更新、访问方式和用户如何找到答案，而不是把它直接等同于研发项目协作平台。

如果内部项目资料和外部客户文档都要管理，应确认两类内容的权限、发布流程和维护角色如何隔离。客户门户上的答案一旦过期，影响可能直接传递到支持工单和客户体验，因此需要明确更新责任和内容验证机制。

六、具体案例与数据观察：用一个试点看出平台是否真的有用

1. 构造一个可复核的试点案例

以下案例是用于说明测量方法的情景模拟，不是某家企业的真实客户数据。假设一个 120 人研发组织正在整合分散的项目知识，选取两个项目组、约 30 名成员，持续运行 6 周。试点只覆盖需求决策、缺陷复盘、发布检查和项目交接四类高频知识，避免一开始就迁移全部历史文档。

基线阶段先抽取 30 个真实问题，记录首次找到有效答案的时间、答案是否有效、是否需要询问原作者。试点结束后，用同一类问题重新测试，并要求参与者在平台上完成更新和引用。比较的重点是任务结果变化，而不是平台页面数或登录次数。

2. 设定有业务含义的观测指标

对项目经理来说，指标至少要覆盖查找、正确性、维护和采用四个方面。只看使用量容易得到虚高结论，因为用户可能频繁访问，却仍然找不到答案；只看搜索命中，也可能把过期页面算成成功。

• 有效答案找到率：测试问题中，用户找到当前有效且可执行答案的比例。
• 首次有效答案时间：从提出问题到确认答案可信的耗时，不把打开搜索结果算作完成。
• 重复询问率：在已有可用知识的前提下，仍需向原作者重复确认的问题比例。
• 内容更新及时率：触发复核的关键内容中，在约定周期内完成更新或确认的比例。
• 交接补充工时：交接期间原负责人额外解释项目背景的时间。
• 权限异常数：测试中发现的越权访问、无法访问或权限配置错误次数。

3. 不把模拟目标误当成平台承诺

比如，试点团队可以把“有效答案找到率提高 15 个百分点”设为内部目标，但这个目标要结合基线和项目复杂度决定，不能作为任何平台的效果保证。若基线已很高，提高空间会变小；若内容本身缺失，单靠搜索功能也不可能快速提高正确答案比例。

复盘时应把结果归因到具体原因：是导入了高价值内容、模板减少了信息缺项、成员更愿意更新，还是权限配置更合理。只有知道变化来自哪里，组织才能判断扩大试点时需要复制哪些流程，而不是误以为采购本身带来了全部改善。

4. 从模拟案例提炼可执行判断

如果搜索时间下降、有效答案率却没有改善，说明平台可能更快地呈现了内容，但内容质量或版本治理仍未解决。若答案率提高、交接补充时间没有变化，则要检查交接材料是否覆盖了决策背景和隐性约束，而不是只记录最终结论。

若使用量上升但维护率持续偏低，应先减少更新阻力，并把维护责任嵌入项目流程；若权限异常增加，则暂停扩大范围，优先修复权限模型。把“何时继续、何时整改、何时停止”预先写进试点方案，比试点结束后临时解释数据更有说服力。

七、不同情况下的行动建议：把选型落到项目节奏上

1. 需求尚未明确时：先做知识断点盘点

不要先收集厂商报价。先选一个典型项目，整理近几周的重复提问、交接补课、资料查找和内容过期案例。每个案例标记发生环节、造成的影响、当前信息存放位置和责任人，初步区分是平台缺陷、内容缺失还是流程没有要求。

这一阶段的产出不必是厚重报告。一张问题清单、一个内容类型表和一份硬性要求列表，通常已足以支撑候选范围缩小。至少让项目、技术、安全和知识维护责任人都参与一次讨论。

2. 已有平台但使用率低时：先找阻塞，不要急着换

低使用率可能来自登录入口不方便、目录结构难理解、内容过期或权限过严，也可能是团队根本不需要另一个独立平台。先观察用户真实路径：他们从哪里提出问题、如何寻找答案、何时放弃搜索、最后找了谁。

如果核心问题是没有责任人和复核机制，迁移到新工具未必解决问题；如果主要问题是平台无法适配部署和权限要求，或关键工作流无法连接，才更有理由启动替换评估。把当前系统的问题具体化，能减少重复采购和二次迁移。

3. 从 Jira 迁移时：先做小范围试迁移

迁移团队应先选一个结构相对复杂、但范围可控的项目做试迁移。样本要包含常见字段、附件、评论、不同角色权限和跨项目引用。迁移完成后由原项目负责人和普通成员分别验收，避免只有管理员确认“导入成功”。

对于 PingCode 的评估，可把平滑迁移作为待验证能力：确认哪些数据可迁、哪些关系会转换、哪些内容需要人工处理，并记录迁移工具、服务和内部人力的边界。对历史链接有外部依赖的团队，还应测试旧链接跳转或建立可查询的映射表。

4. 有私有化部署要求时：安全与运维同步评审

把业务要求翻译成部署验收项：数据存储位置、网络访问路径、身份认证方式、日志留存、备份恢复、升级频率、漏洞响应和运维角色。不要只由业务采购者评估，也不要把所有技术细节留到合同签署以后再讨论。

如果供应商提供多种部署或服务方案，应要求对方说明每种方案的责任边界。企业内部也应指定平台负责人、基础设施负责人和安全负责人，避免上线后出现“系统有人管、知识没人管”或“内容有人写、故障没人处理”的分离状态。

5. 面向客户发布知识时：把内容生命周期作为核心流程

客户帮助内容必须从撰写延伸到审核、发布、版本更新和撤下。应明确哪些内容可公开、谁负责技术确认、产品变更后多久更新、错误答案如何快速撤回。文档门户的访问量只是使用信号，不足以证明客户问题已得到解决。

试点时可选取高频支持问题，比较客户是否能自行找到答案、是否仍重复提交工单，以及内容变更后多久同步。若内部项目知识和外部客户文档使用同一平台，也要单独验证公开边界与内部材料隔离。

八、不同情况下的取舍：明确什么值得放弃，什么不能妥协

1. 速度与治理之间的取舍

轻量平台通常更容易快速启动，但组织治理可能需要额外约定；治理能力强的平台可以支撑复杂管理，却可能增加配置、培训和维护成本。项目经理要判断团队目前最缺的是快速采用，还是跨部门一致性，不要把某一侧的优势当成全组织的答案。

若团队规模小、内容风险低，可先用轻量规则验证知识需求；若跨项目协作频繁、权限边界清晰且审计要求较高，应把治理能力列为先决条件。两种路径都要设置后续复核点，避免早期便捷成为长期失控的理由。

2. 灵活度与统一标准之间的取舍

高度灵活的页面结构更适合不断变化的团队，但容易造成目录和模板不一致；统一标准更利于搜索和交接，却可能让团队觉得写作负担过重。建议只规范对协作结果有明显影响的内容类型，其余内容保留适当弹性。

例如，决策记录至少应包含背景、选项、结论和责任人；项目随手笔记则不一定要套同样复杂的字段。把标准按风险分层，比要求所有页面同等正式更容易持续执行。

3. 全量迁移与分批迁移之间的取舍

全量迁移能保留更多历史材料，却会把大量过期内容和结构问题一起带入新环境。分批迁移便于控制风险，但需要接受旧系统在一段时间内继续存在。项目经理应按内容价值、有效期限、关联复杂度和访问频率进行分层，不必把所有历史页都当成必须搬运的资产。

• 立即迁移：当前项目正在引用的关键决策、流程和操作知识。
• 整理后迁移：仍有长期价值、但需要补责任人和版本信息的内容。
• 只读归档：法律、审计或历史追溯需要保留，但不再日常使用的材料。
• 不迁移：明显重复、已过期且无合规留存要求的内容。

4. 自动化与人工审核之间的取舍

自动化可以减少重复动作，但不应让错误内容更快传播。自动生成摘要、问答或内容推荐时，项目团队仍需确认答案是否引用正确版本、是否继承了原文权限、是否明确标注不确定信息。尤其是安全、上线操作和客户承诺等高风险内容，人工审核不能轻易省略。

可以先把自动化用于低风险的内容整理、标签建议和重复页面识别，再通过小范围试点验证准确性。对于会改变项目决策或指导生产操作的答案，必须保留来源链接和责任人，并设计纠错入口。

5. 单一平台与组合方案之间的取舍

单一平台有助于减少系统切换，但未必在研发协作、客户文档、组织文件管理等所有场景都最合适。组合方案可以让各类内容使用更贴近场景的工具，却会增加身份、链接、权限和内容去重的治理成本。

如果选择组合方案，应明确每类知识的“权威来源”在哪里，避免同一说明在多个系统分别维护。跨平台搜索和链接体验也要纳入试点，否则用户仍需记住资料分布，系统数量增加反而会拉长查找路径。

九、结尾：选型的终点不是上线，而是减少对个人记忆的依赖

1. 用一个可验证的判断收束选型

我最看重的不是平台拥有多少功能，而是团队能否把关键项目知识变成可查找、可复核、可交接的工作资产。知识共享真正成功的标志，不是“建了多少页面”，而是新成员能否找到可信依据、负责人离开后项目能否继续，以及内容变化后旧答案能否及时失效。

对中大型研发组织，可以把 PingCode纳入候选评估，重点验证研发流程衔接、私有化部署要求和 Jira 迁移范围；对其他团队，应按办公生态、内容发布和问答需求比较相应平台。无论选择哪种方案，都要以当前版本的产品资料、合同范围和试点验收为准。

2. 下一步按四个动作推进

1. 盘点断点：收集近期找资料、重复询问、交接补课和内容过期案例。
2. 确定门槛：列出部署、权限、迁移、身份和审计等不可妥协条件。
3. 设计试点：选一个代表性项目、30 个左右真实问题和三类用户任务，建立基线。
4. 按证据决策：比较答案有效率、查找时间、维护负担、权限风险和三年成本，再决定扩大、整改或停止。

项目经理不必追求一次选出“永远正确”的平台。更可靠的目标，是先让最重要的一类知识在一个真实项目里实现可检索、可更新、可交接，再把经过验证的规则复制到其他团队。工具可以更换，知识责任、来源可信度和维护机制必须留下来。