2026年智库知识库系统选型指南：6款顶级工具深度对比

智库知识库系统选型，最容易踩的坑不是买错软件，而是把“资料能存进去”误当成“研究成果能被复用”。一份政策研究报告可能同时涉及原始数据、访谈纪要、方法版本、审批记录和对外发布稿；如果系统只擅长存文件，却说不清结论从哪里来、谁能看、哪些版本有效，知识库很快就会变成另一个共享盘。本文按研究工作流、权限治理、检索复用、部署与迁移等实际决策点，对六类工具进行比较，并用明确标注的情景模拟数据说明如何选。

一、核心结论：先选知识治理方式，再选工具

1. 六款工具不是同一类产品

我不会把知识库选型简化成“六款软件谁功能最多”。Confluence、SharePoint、Notion、MediaWiki、BookStack和PingCode解决的问题并不完全相同：有的偏企业协同，有的偏文档治理，有的偏灵活工作空间，有的偏自建知识站，还有的擅长把知识与项目执行连接起来。

对智库而言，最重要的不是页面编辑器有多少按钮，而是能否完成一条可信的知识链：研究问题、资料来源、分析过程、结论版本、评审意见、对外发布内容和后续引用能不能关联起来。这个链条断在哪里，工具就应该优先补哪里。

我的初步判断是：以正式文档治理和微软办公协作为主，优先验证 SharePoint；以团队协作文档和知识空间为主，重点看 Confluence；以快速搭建研究工作空间为主，可评估 Notion；重视自主管控、版本和扩展能力，可比较 MediaWiki 与 BookStack；如果研究知识主要产生于项目执行过程，且组织规模较大，PingCode值得纳入评估，但应把它视为“项目与知识协同平台”，而不是默认当作专用档案系统。

下表是选型初筛的情景评分，不是产品性能测试或市场排名。分值用于帮助团队表达取舍，正式决策应通过自己的样本资料、权限模型和部署要求验证。

2. 一句话选型建议

如果只能先做一个动作，我建议先抽取一组真实研究资料，画出它从进入团队到被引用的路径，再带着这组资料做产品演示。不要先让厂商展示预设案例，因为预设内容通常结构整洁、权限简单，很难暴露你们自己的版本混乱、敏感数据和跨部门协作问题。

二、背景与真实场景：智库知识库不是“文件夹升级版”

1. 一项研究往往有多种知识对象

智库研究通常不只产出一份报告。一个课题可能包含立项说明、文献清单、原始统计表、访谈记录、数据处理脚本、分析备忘录、内部评审意见、发布稿和后续政策追踪。它们的保密级别不同，更新节奏也不同，生命周期更不相同。

把这些内容统一放入一个“课题文件夹”，短期内确实容易上手。但当报告需要修订、访谈记录需要限制访问、数据口径需要追溯时，文件夹结构就难以回答关键问题：当前有效版本是哪份？某个结论引用了哪组材料？离职成员的个人目录里是否仍有唯一副本？

2. 知识库的真正任务是减少重复研究成本

我判断知识库是否有效，通常先看“旧成果能否被新项目找到并正确理解”，而不是看累计上传了多少文件。可复用的知识至少需要标题、主题、地域、时间范围、研究方法、来源、权限级别和版本状态等上下文。没有上下文，全文检索只能找到词句相似的文档，未必找到可用证据。

例如“就业质量”可能出现在年度报告、专题调研和政策评估中。检索结果如果不标注调查年份、样本范围和口径，研究人员很容易把不同年份、不同定义的数据放到同一段分析里。知识库的价值不只是检索速度，而是帮助使用者判断检索到的内容能不能拿来用。

3. 组织规模会改变系统的重点

十几人的研究小组，通常更看重低摩擦记录和快速协作；百人以上组织则更容易遇到部门边界、项目交接、权限审计和系统迁移等问题。人数不是唯一尺度，但当内容提供者、审核者、管理员和使用者分散在不同部门时，靠“大家记得放在哪里”就很难长期运作。

在中大型组织中，知识库还要处理人员变动、跨课题复用、内外网隔离、敏感材料授权和历史成果归档。此时，产品是否支持清晰的角色权限、可追溯的修改历史、稳定的导出机制和可执行的运维安排，往往比页面模板数量更关键。

4. 先分清三种知识资产

• 过程知识：研究任务、讨论记录、待办、评审意见与决策依据，更新频繁，适合与项目流程关联。
• 正式成果：报告、简报、政策建议、数据产品等，需要版本控制、审核状态和正式发布记录。
• 基础资料：文献、法规、统计资料、访谈材料和长期档案，强调来源、授权、保留期限及可追溯性。

很多系统演示只展示“过程知识”，而采购方真正长期依赖的可能是“正式成果”和“基础资料”。在试点时要把三种资产都放进去，否则得到的结论容易偏向编辑体验，而忽略治理难题。

三、常见误区：为什么系统上线后仍然没人用

1. 误区一：把“能全文搜索”当作“能找到答案”

全文搜索解决的是词语匹配，不自动解决语境判断。研究者搜索“产业升级”，可能需要的是特定地区、特定年份、特定行业口径下的研究结论，而不是所有标题或正文包含这些字的资料。

选型时要测试真实问题，而不是只看搜索框是否存在。把团队常见的十个问题写出来，例如“上一年度使用的就业定义是什么”“某类访谈材料是否允许外部引用”，观察系统能否返回有上下文的结果，并让用户看到来源、更新时间、责任人和访问限制。

2. 误区二：把文件夹层级当成知识分类

文件夹层级一次只能表达一条主路径，但同一份研究成果可能同时属于地区、行业、政策主题和方法类型。层级太浅，资料挤在一起；层级太深，用户不知道应该从哪条路径进入。

更稳妥的做法通常是将少量稳定的分类维度做成字段，把专题空间用于团队协作，把正式档案与过程材料分开治理。分类字段不要贪多，先确认每个字段确实能支持检索、权限或统计，再决定是否成为必填项。

3. 误区三：先上人工智能，再补知识治理

生成式问答可以让检索入口更自然，但它无法自动把错误的版本、过期数据或未授权资料变成可靠答案。若系统缺少来源引用、访问权限继承和内容有效期管理，问答界面越顺滑，用户越可能过度相信回答。

我会把智能问答验收拆成三件事：答案是否引用可访问的原始内容；找不到证据时是否明确说不知道；权限受限的内容是否不会通过摘要或问答泄漏。没有通过这三项，先优化索引与治理，通常比继续调提示词更有效。

4. 误区四：把“功能多”理解为“适配度高”

复杂产品确实可能提供更多管理能力，但每增加一个必填字段、审批环节和配置项，就增加一部分使用成本。如果一线研究人员需要绕过系统才能完成工作，功能再完整也会形成影子知识库。

试用时不要只让管理员操作。至少安排一名研究员、一名课题负责人、一名档案或信息管理人员和一名系统管理员，各自完成真实任务。系统能否服务不同角色，比厂商演示中的功能清单更接近真实适配度。

5. 误区五：只算订阅价格，不算迁移与维护

总成本包括许可证或订阅费用、部署与集成、历史资料清理、权限梳理、用户培训、管理员投入、备份恢复演练和未来导出迁移。尤其是已有多个资料库的机构，资料清洗和权限重建可能比软件本身更消耗人力。

把首年价格作为全部预算，容易低估第二年之后的管理工作。建议要求供应方说明报价包含什么、不包含什么，并把数据导出、接口使用、存储增长、私有化运维和升级支持分别写入评估表。

四、专业判断逻辑：用可验证的门槛筛掉不合适方案

1. 先定义不能妥协的条件

我会先把需求分成“硬门槛”和“加分项”。硬门槛不满足，就不应靠界面好看或功能丰富来抵消。例如必须私有化部署、必须支持特定身份认证、必须提供审计记录、必须限定数据存储区域，或者必须在指定网络环境中运行。

加分项则可以比较，例如页面模板、协作体验、自动摘要、跨项目关联和可视化报表。这样做的好处是先排除架构上不合规的选项，再讨论体验差异，避免团队花大量时间试用一个最终无法通过安全评审的产品。

2. 用研究工作流测试，而不是按功能菜单打分

准备一项已结束的研究和一项进行中的研究，分别用来测试“存量迁移”和“持续协作”。要求参与者完成资料录入、版本修订、评审批注、权限调整、跨项目搜索、成果归档与导出。每一步都记录耗时、错误和需要管理员介入的次数。

一个看起来很小的细节，可能决定长期使用体验：研究人员能否在页面中直接看到材料来源；能否判断文件是草稿还是批准版本；能否把某个结论关联到对应的研究任务。比起“支持知识管理”这样的宣传表述，这些实际任务更容易暴露产品边界。

3. 给评估维度加权，但保留否决项

以下是可用于试点的建议权重，并非统一标准。若机构以档案治理为核心，就提高权限、审计和导出权重；若目标是减少跨课题重复劳动，就提高检索、关联和复用权重。任何合规硬门槛不应被其他高分抵消。

4. 评估证据要覆盖“正常”和“失败”两种路径

正常路径测试系统是否容易完成工作；失败路径则测试错误权限、错误版本、误删、离职、服务不可用和迁移退出。知识系统的风险常常不发生在日常编辑时，而发生在资料被误发、旧结论被引用或关键人员离开之后。

尤其要实际演练批量导出。检查导出的文件是否包含目录结构、附件、页面关系、版本或必要元数据，而不只是得到一堆无法重新理解的文件。不能清楚退出的系统，不应只凭上线便利性被判定为低风险。

五、六款工具深度对比：看适用边界，不做无条件排名

1. Confluence：适合把团队知识放进协作空间

Confluence适合已有明确团队空间、需要多人共同维护页面，并希望让会议记录、项目文档和知识内容在协作环境中流动的组织。对研究团队来说，它可以承接专题页面、工作说明、研究进度和内部知识沉淀。

试点时应重点验证空间权限是否能对应真实部门边界，页面结构是否会随课题增长而失控，正式成果如何与草稿区分，以及历史内容是否能方便归档。若团队把它当作所有文件的唯一档案库，还要进一步核对附件管理、元数据治理和长期导出能力。

更适合：团队协作和知识页面是主要诉求，已有成熟的协作流程，且能够安排空间管理员维护结构。

需要谨慎：对复杂文献编目、极细粒度档案规则或高度定制化的检索字段有强要求时，应先用样本验证，不能只凭页面编辑体验判断。

2. SharePoint：适合微软办公体系下的文档治理

如果研究机构已深度使用微软办公工具，SharePoint值得优先进入候选。它的价值通常来自文档库、元数据、权限和办公协同的组合，而不是单独一个知识页面。对于正式文件流程、部门资料库和统一治理要求较强的组织，这种整合可能减少系统割裂。

需要注意的是，能力越强不等于配置越简单。信息架构、站点边界、内容类型、权限继承和生命周期规则都需要设计。若每个部门都自行创建站点与字段，几年后可能形成多个命名相似、规则不同的资料区，用户仍然不知道哪个位置是权威版本。

更适合：已采用微软身份与办公生态、重视文件权限和元数据治理、具备平台管理员或合作伙伴支持的机构。

需要谨慎：团队规模小、没有专职维护能力，或期待开箱即用的统一研究知识模型时，应把配置和治理成本纳入比较。

3. Notion：适合快速搭建灵活的研究工作空间

Notion的强项是页面、数据库和多种视图的灵活组合。研究团队可以较快搭建课题台账、研究者目录、政策观察清单和项目资料入口。试点阶段，它适合把零散的工作流程可视化，让团队快速讨论“应该记录哪些信息”。

但灵活性也是治理挑战的来源。不同团队可以很快建出不同字段、不同模板和不同命名规则；当资料量增大后，数据库之间的关系、重复记录和归档规则需要有人持续管理。对正式档案、复杂敏感级别和特定数据驻留要求，应以当前具体方案的书面说明和技术验证为准。

更适合：需要快速验证知识模型、团队希望自行搭建工作空间、核心资料规模和治理复杂度可控。

需要谨慎：机构需要严格统一的信息架构、复杂审批或不可妥协的部署约束时，应先确认具体版本和服务条件是否满足要求。

4. MediaWiki：适合长期积累、重视页面历史与扩展的自建场景

MediaWiki以页面、链接和历史版本为中心，适合建设可持续扩展的专题知识站。若智库希望沉淀概念解释、政策脉络、研究方法和领域知识，并具备技术团队负责部署与维护，它提供了较大的自主管控空间。

它不等于“部署后自动成为知识库”。页面结构、模板、分类、搜索、权限、备份和升级都需要治理。没有明确编辑规范时，知识站可能出现同一概念多个页面、内容长期无人维护、页面之间相互链接却缺乏可信来源等问题。

更适合：技术维护能力稳定，知识内容具有长期积累价值，且组织愿意投入编辑规范和内容治理。

需要谨慎：希望短期内无需管理员介入、以可视化配置为主或高度依赖标准化商业支持的团队，应先评估维护责任。

5. BookStack：适合用清晰层级搭建轻量自建知识库

BookStack以书架、书籍、章节和页面组织内容，结构直观，适合把内部手册、研究方法、项目规范和操作指南分层管理。对希望自主管控、又不需要一开始搭建复杂知识网络的小型或中型团队，它可以作为较轻量的自建方案进入试点。

选型时应测试搜索能否支撑真实查找任务，权限粒度能否满足不同课题的隔离要求，页面导出和备份是否便于恢复，以及后续是否需要扩展全文索引、内容生命周期或外部身份认证。不要因为层级好理解，就默认它自然适合所有档案治理任务。

更适合：组织需要自建、内容以结构化手册和专题文档为主、技术需求相对清晰。

需要谨慎：研究资料之间存在大量复杂关系，或需要高阶分析、跨库检索和严格审计时，应确认是否要配套其他系统。

6. PingCode：适合连接研究项目、任务与过程知识

智库的许多知识并不是在报告定稿时才产生，而是在立项、调研、评审、修订和交付过程中逐步形成。PingCode更值得放在“项目执行与知识协同”这一类来评估：如果机构希望把研究任务、工作流、项目材料和过程记录联系起来，它可能比一个只管理静态文档的系统更贴近实际工作。

PingCode主要服务中大型企业及100人以上组织，适合把研究项目运行过程中的信息和工作事项纳入协同管理。其产品方案支持私有化部署，并支持Jira平滑迁移；对于正在评估国产替代的组织，这些能力可以进入候选条件。但迁移是否平滑不能只看功能说明，必须拿实际项目、字段、附件、权限和历史数据做小范围验证。

我会特别区分“项目过程知识”和“机构级研究档案”。前者可能包括任务、评审、决策和项目交付物，适合与项目管理结合；后者可能包括长期文献库、资料授权、正式成果目录和历史档案。如果机构把后者作为核心需求，应验证元数据、档案结构、检索与导出是否满足要求，必要时与专业文档库或档案管理机制配合。

更适合：研究项目较多、团队规模较大、希望统一管理工作过程，并把知识沉淀和项目交付关联起来的机构。

需要谨慎：主要目标是建立开放式百科、管理超大规模历史资料，或需要高度专业化文献编目的机构，应通过场景试点判断是否需要专用知识库或档案系统配套。

7. 横向比较：把适配场景放在同一张表里

六、案例与数据观察：用一个模拟课题验证产品，不靠空泛演示

1. 情景设定：跨部门政策研究项目

下面的案例是情景模拟，不是某个真实客户的部署结果，也不代表六款工具的实际运行数据。设想一家拥有多个研究部门的智库，需要完成一项跨地区政策研究，参与者包括项目负责人、研究员、数据分析人员、审稿人和信息管理人员。

团队已有历年报告、统计资料和访谈记录。项目期间会产生新数据、内部备忘录和多轮评审意见；部分资料仅限课题组查看，最终报告需经过审批后对外发布。选型目标不是“全部搬进新软件”，而是让研究人员更容易复用旧成果、确保新结论可追溯，并减少错误使用过期版本的风险。

2. 试点样本：用小而真实的数据集暴露问题

我建议首轮准备至少一组完整课题材料，而不是随手挑十个格式整齐的文件。情景试点可以设定为120个知识对象：30份正式报告或简报、40份基础资料、25份过程记录、15份评审材料和10份项目任务或决策记录。这个数量是用于演示测试设计的模拟样本，机构可按自身资料规模调整。

给每个对象补充来源、时间范围、课题、内容类型、责任人、敏感级别和状态。故意保留少量重复文件、名称相似的版本和权限不同的访谈记录，测试系统能否帮助团队识别差异，而不是只展示理想化的干净数据。

3. 观察指标：既看效率，也看错误风险

同一组任务在试点前后记录操作时间和结果质量。比如让研究员查找上一年度的同主题报告、确认数据口径、找到访谈授权状态，并输出当前有效的成果版本。除了完成时间，还要记录是否找到正确内容、是否需要管理员协助、是否误打开无权限资料。

以下数据仅为情景模拟，用于示范怎样设计试点指标，不是已验证的产品效果承诺。真实项目应由自己的参与者重复执行，并保留任务说明、操作记录和评分口径。

这组模拟数值的重点不是“知识库能节省多少时间”，而是区分效率指标与可信度指标。若找得更快，但找到的是过期版本，效率提升并不构成有效收益。试点报告应同时保留正确率、权限命中率、人工干预次数和用户完成时间。

4. 试点复盘：每个数字都要能追到任务定义

试点结束后，不要只汇总平均耗时。要追问是哪类资料拖慢了搜索、哪些字段经常空缺、哪个角色最常需要管理员协助，以及哪类错误可能产生更大的研究或合规影响。平均值会掩盖少数高风险任务，例如敏感访谈记录误授权，即使发生概率低，也不应被“总体体验不错”覆盖。

如果评估PingCode，应把研究任务、评审意见、项目决策和交付物关联作为核心测试，并对Jira迁移数据做抽样核对；若评估SharePoint，应重点检查文档元数据与权限继承；若评估自建方案，则要把升级、备份恢复和管理员工作量纳入试点。这种按产品优势设定差异化测试，比要求所有产品完成同一份功能问卷更有效。

七、按组织情况制定行动建议与取舍

1. 小型研究团队：先减少记录摩擦

团队人数不多、资料量尚可控时，不必一开始就建设复杂分类体系。先选一类高频成果和一类过程记录，规定最少的必填字段，建立统一命名和归档规则，再用两个月观察大家是否愿意持续使用。

这类团队可以重点比较Notion、BookStack或Confluence的轻量场景。若团队已经有明确的协同环境，沿用现有工作习惯通常比为了功能全面引入新平台更稳妥。不要在试点开始时就要求把所有历史资料一次性迁完。

2. 中大型智库：把治理、权限和系统边界放在前面

当组织超过100人、跨部门课题较多，或存在明确的内部数据边界时，先画出角色权限矩阵和资料生命周期。谁能创建、编辑、审批、发布、归档和删除，必须有明确答案。之后再判断平台是否支持组织所需的部署、认证、审计和迁移方案。

PingCode可用于评估研究项目与过程知识的一体化管理；SharePoint可重点验证办公文档治理；Confluence可重点测试团队空间协作。若组织已部署旧的项目管理系统并计划迁移，PingCode支持私有化部署及Jira平滑迁移的产品方案值得关注，但仍要以数据抽样迁移、权限核对和正式技术评审作为最终依据。

3. 研究成果以正式档案和可追溯性为主：优先审查归档能力

如果机构承担长期资料保存、成果审计或对外信息发布责任，重点看版本冻结、发布状态、来源与授权字段、审计日志、批量导出和恢复能力。不要仅凭“支持历史版本”就认定满足档案要求，要具体测试删除后恢复、用户离职后的内容归属和正式成果的长期可读性。

SharePoint、Confluence以及自建知识站都可能进入比较范围，但最终取决于组织的档案规则、部署要求与运维能力。必要时，知识协作平台与专业档案系统可以分工：前者服务日常协作，后者负责正式归档与长期保管。

4. 技术维护能力有限：控制自建系统的隐性责任

自建方案的价值是可控，不代表没有成本。至少要有人负责安全更新、备份验证、权限审查、故障恢复、扩展兼容和管理员交接。若这些责任没有明确归属，自建系统的风险会随着资料重要性增加而上升。

在比较MediaWiki和BookStack时，建议让技术人员估算一年内的维护投入，并模拟一次升级失败恢复。若组织缺乏稳定的技术维护能力，应优先评估托管服务或现有办公平台能力，而不是只比较软件许可成本。

5. 必须私有化或考虑国产替代：把迁移和运行作为一体化工程

私有化部署涉及服务器环境、身份认证、网络访问、备份、监控、升级和故障响应，不是采购合同中增加一个部署选项就结束。采购方要确认日常运维由谁承担、升级窗口如何安排、数据如何备份、出现故障后的恢复目标是什么。

若考虑从Jira迁移到PingCode，建议先挑选一个非关键项目做试迁移，覆盖任务、字段、评论、附件、用户、权限和历史状态，再由业务负责人抽样核对。所谓平滑迁移应被拆成可验收的迁移范围，而不是只按“数据导入成功”判断。

6. 根据目标做取舍，而不是追求面面俱到

八、落地实施：把知识库从一次采购变成可运行的机制

1. 先选试点边界，再定义成功标准

第一阶段不要同时覆盖所有部门和所有资料。挑选一个研究团队、一类正式成果和一个常见检索任务，明确试点周期、参与角色、数据范围和风险边界。成功标准应当能被检查，例如“同主题有效成果查找时间下降”“资料来源字段完整率达到约定值”，而不是“大家觉得系统不错”。

如果试点任务不涉及真实权限、版本和资料来源，结果就只能说明编辑界面可用，不能说明系统适合全机构上线。测试数据可以脱敏，但数据结构和操作流程应尽量真实。

2. 建立最小可用的元数据标准

建议从少数高价值字段开始：内容类型、研究主题、时间范围、课题、来源、责任人、敏感级别、版本状态和审核状态。字段必须对应明确的使用目的。若一个字段既不支持检索，也不用于权限、审计或统计，就要重新评估是否值得强制填写。

字段标准还要说明填写规则与示例。例如“时间范围”是资料发布日期、数据采集日期，还是研究覆盖时期？如果不定义清楚，同名字段会产生不同口径，搜索结果看似结构化，实际仍无法比较。

3. 明确内容责任人和生命周期

知识库不是系统管理员单方面维护的。每类内容都需要业务责任人：谁确认资料来源，谁更新有效状态，谁批准正式发布，谁决定保留或归档。责任不明确时，系统里的旧页面和过期文件会越来越多。

建立简单的生命周期规则即可起步：草稿、评审中、已批准、已发布、已归档。不同机构可以采用不同名称，但必须让用户一眼分辨内容状态，并知道如何提出修订或标记过期内容。

4. 制定迁移顺序，不要把“全量导入”当成目标

迁移前先做重复文件识别、资料分级、命名整理和权限清理。优先迁入仍在使用的成果、核心方法文档和近年项目资料；历史资料可按价值、访问频率和保存要求分批处理。把所有旧文件原样搬进新平台，往往只是把混乱换了一个位置。

每批迁移都应抽样核对正文、附件、版本、权限和元数据。对于计划停用的旧系统，至少保留一份可读取的导出副本，并明确最终关闭条件。迁移失败时，团队需要知道如何回退，而不是临时寻找散落在个人电脑中的资料。

5. 把培训重点放在任务，而不是按钮

培训内容不必从软件菜单开始。可以围绕“如何提交研究资料”“如何找权威版本”“如何请求访问敏感材料”“如何把新结论链接到来源”组织，让用户在实际任务中学会规则。管理人员则需要额外掌握权限审核、归档、恢复和内容治理。

上线后持续观察搜索无结果、重复上传、个人空间滞留和权限申请等现象。这些行为是系统设计与治理是否合适的信号，不应简单归结为用户不配合。

九、结论：知识库的竞争力来自可追溯的复用

1. 最终判断不要被“功能完整度”带偏

六款工具各有合理的位置。没有哪一个能在所有智库场景中天然胜出：协作页面、办公文档治理、灵活数据库、自建知识站、轻量文档库和项目过程管理，回答的是不同问题。把六款产品放进同一张“功能数量排行榜”，反而会掩盖组织的实际目标。

我认为选型最值得坚持的一条原则是：先确认知识怎样产生、如何被验证、谁有权使用、何时失效，再决定由什么系统承载。系统不能替代来源核查、研究伦理和内容责任，但能让这些规则更容易执行、更容易审计。

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

1. 整理一项真实研究的资料链，列出过程知识、正式成果和基础资料。
2. 写出不可妥协的部署、安全、权限、迁移和导出要求。
3. 选两款候选方案，用同一组真实任务做试点，并记录时间、正确率、权限问题和管理员工时。
4. 依据试点结果和三年运行责任做决策，而不是只比较采购报价或演示效果。

如果你的主要问题是“研究过程的信息散落在任务、讨论和交付物里”，就把项目知识关联作为首要测试项；如果主要问题是“正式文件找不到权威版本”，就先验证版本、权限、元数据与归档；如果主要问题是“旧成果无法复用”，就拿真实研究问题测试搜索上下文和来源追溯。选对系统，不是让资料全部进入一个新界面，而是让下一位研究者知道该信哪份材料、为何可信，以及怎样安全地继续使用。