知识库选型评估表要能直接支撑决策，打分规则和通过阈值需要一起设计：先把评估目标与否决项定下来，再把维度拆成可观察的评分项并分配权重，用统一分档逐项打分、加权汇总为百分制；通过条件由总分线、关键项最低分与否决项三层共同构成，三者同时满足才算通过。下面给出可直接套用的结构、公式、算例和校准方法。
要点总览（TL;DR）
- 评估表先定决策目标与否决项，再把维度拆成3–6个可观察评分项，权重按业务优先级分配且合计100%，单一维度权重建议不超过30%。
- 打分采用0/1/3/5四档，每档对应明确证据状态（演示验证、文档说明、部分满足、不满足），同一评分项所有候选使用同一证据标准与时间窗。
- 加权公式为总分=Σ(评分项得分÷5×权重)×100，满分100；某维度全部缺失时该维度不计入总分，按已评权重折算并标注缺失比例。
- 通过阈值分三层：总分线（如70分）、关键项最低分（核心维度不低于3分）、否决项全过，三者同时满足才算通过；阈值评审前锁定，评审后复盘校准。
评估目标：这张表要支撑哪个决策
评估表首先回答一个具体问题：在若干候选知识平台中，选出可以进入试点或采购流程的一款。评分只是手段，结论要能被评审会直接使用。因此开篇应写一页评估目标说明，包含三部分内容。
决策问题写成一句话，例如“从3款候选平台中选出1款进入为期两个月的试点”。结论用途明确为三档：通过（进入试点或采购）、有条件通过（列出整改项，整改完成后再进入试点）、不通过（本轮退出）。三档结论都要在评审会上有明确的使用方式，避免出现“分数很高但没人知道下一步做什么”的情况。
角色分工按评分项归属划分，而不是按部门平均分配：
- 业务方负责知识组织与检索、协作与编辑等贴近日常使用的评分项，提供真实使用场景和试用反馈；
- IT负责集成与迁移、运维与成本，确认接口、数据导入导出和技术栈匹配度；
- 知识运营负责内容结构、模板规范、运营机制等评分项，判断平台能否支撑长期内容治理；
- 安全合规负责权限与安全、数据合规与否决项核验，对硬性条件给出明确结论。
这一页说明的作用是让每个评委知道自己对哪些分数负责，也便于后续追溯：某个评分项分数异常时，能找到对应的证据提供方。
指标与范围：维度、评分项和权重怎么拆
评估表采用“维度—评分项”两级结构。维度是评审会关注的几个大方向，评分项是评委实际打分的单元。评分项要写成可验证的事实问题，例如“是否支持按页面层级配置读写权限”，而不是“权限管理是否强大”这类无法对照证据的判断。
维度可按以下六类设置，每个维度拆3–6个评分项：
| 维度 | 评分项示例（事实问题） | 建议权重 |
|---|---|---|
| 知识组织与检索 | 是否支持多级页面树组织内容；全局搜索是否覆盖正文与附件；搜索结果能否按空间或标签过滤 | 25% |
| 权限与安全 | 能否按页面或空间配置读写权限；是否支持导出权限单独控制；操作日志是否可查询 | 25% |
| 协作与编辑 | 是否支持多人同时编辑；是否支持评论与提及；版本历史能否查看与回滚 | 15% |
| 集成与迁移 | 是否提供开放接口；能否批量导入既有文档；是否支持与项目任务关联 | 15% |
| 运维与成本 | 部署方式是否匹配现有环境；许可与运维成本是否在预算内；备份与恢复机制是否明确 | 10% |
| 服务与生态 | 是否提供实施支持与培训；文档与社区资源是否充足；版本迭代节奏是否稳定 | 10% |
权重按业务优先级分配，合计必须为100%。单一维度权重建议不超过30%，防止某一维度主导总分、掩盖其他短板。权重来源要写清依据，例如“权限与安全权重高，因为知识库承载内部制度与项目资料”，便于后续复盘时判断权重是否合理。
范围边界同样要写进表头：本次只评新平台选型，不含Confluence替换迁移的具体方案，也不含系统部署与配置细节。范围写清楚，评委就不会把迁移工作量或部署调试问题混进选型分数。
数据口径与证据：每一分靠什么支撑
打分可比的前提是证据标准统一。每个评分项在表中预留“证据类型”和“证据位置”两列，评委打分时必须填写对应证据，不能只写分数。
可用证据类型包括：产品演示记录（注明演示日期与演示人）、试用环境操作截图、官方文档条款（注明章节）、POC测试结果、报价单。同一评分项的所有候选应使用同一证据标准和时间窗，例如统一要求“近三个月内的演示或试用记录”，避免一款候选用旧资料、另一款用现场演示造成不可比。
定性评分项要写明通过标准的两面：满足条件与不满足条件。例如“权限配置”一项，满足条件为“可按页面层级分别配置读写权限并有操作记录”，不满足条件为“仅支持空间级权限或权限配置需人工维护名单”。标准写具体，不同评委对同一证据容易得出接近的判断。
缺失值处理规则单独规定：未取得证据的评分项记为空缺并标注原因，不按0分处理，也不按满分处理。把“没查到”当成“不满足”会低估候选，把“没查到”当成“满足”会高估候选，两种做法都会让结论失真。空缺项在汇总时按下一节的折算规则处理，并在结论中显式披露。
打分规则：分档、加权与汇总公式
分档采用0/1/3/5四档，每档对应明确的证据状态，评委对照证据选档，而不是凭印象给分：
| 档位 | 证据状态 | 含义 |
|---|---|---|
| 5 | 演示或试用环境验证满足 | 现场操作确认能力存在且符合评分项描述 |
| 3 | 官方文档说明满足 | 文档明确描述该能力，尚未在试用环境验证 |
| 1 | 部分满足 | 能力存在但覆盖范围或条件受限，需注明限制 |
| 0 | 不满足 | 有证据表明当前不满足评分项要求 |
加权公式为：
总分 = Σ（评分项得分 ÷ 5 × 该评分项权重）× 100，单位为分，满分100分。评分项权重以百分数表示，各评分项权重之和等于其所属维度权重，各维度权重合计100%。
维度得分用于定位短板：维度得分 = 该维度下评分项加权得分之和 ÷ 该维度权重合计，结果同样折算为百分制，便于与总分对照。
分母为零的处理要提前写进规则：某维度全部评分项缺失时，该维度不计入总分，总分按“已评权重”折算，即折算总分 = 原始加权得分 ÷ 已评权重合计 × 100，并在结论中标注缺失维度及其权重占比。缺失权重超过一定比例（例如超过20%）时，应提示结论可靠性不足，建议补充证据后再评审。
一票否决项单列在评估表末尾，不参与加权计算。任一否决项不满足，整体结论直接为不通过，无论总分多高。否决项通常包括数据合规要求、账号与权限模型是否满足组织要求、数据能否完整导出等硬性条件。
通过阈值：总分线、关键项底线与否决项
阈值采用三层结构，避免单一总分掩盖关键短板：
| 层级 | 规则 | 作用 |
|---|---|---|
| 总分线 | 建议70分作为进入试点的参考线，结合候选差距与业务底线校准 | 判断整体适配度是否达到可试点水平 |
| 关键项最低分 | 核心维度（如权限与安全、知识组织与检索）得分不低于3分（百分制60分） | 防止总分达标但核心能力薄弱 |
| 否决项 | 数据合规、账号与权限模型、数据可导出等硬性条件全部满足 | 排除不可接受的硬伤 |
三者同时满足才算“通过”。总分达标但个别非核心评分项偏低时，可给出“有条件通过”：列出具体整改项、责任方和完成时间，整改确认后再进入试点。总分未达线或关键项低于底线，结论为不通过，并在评审记录中写明主要失分项。
70分是参考线而非通用达标线，设定依据应来自业务底线和历史可接受水平。例如上一轮选型中进入试点的平台得分在72–80分之间，可把70分作为下限；若候选整体差距明显，评审会可在评审前调整分数线，但必须在所有候选评分完成前锁定，评审过程中不改线。改线会直接改变结论，破坏评估的可信度。
算例：两款候选如何算出结论
假设两款候选A、B按前述六个维度评分，权重分别为25%、25%、15%、15%、10%、10%。为便于演示，每个维度取一个代表性评分项，得分如下（演示情景，非真实测评）：
| 维度（权重） | 候选A得分 | 候选B得分 | A加权得分 | B加权得分 |
|---|---|---|---|---|
| 知识组织与检索（25%） | 5 | 3 | 25.0 | 15.0 |
| 权限与安全（25%） | 3 | 5 | 15.0 | 25.0 |
| 协作与编辑（15%） | 5 | 3 | 15.0 | 9.0 |
| 集成与迁移（15%） | 3 | 3 | 9.0 | 9.0 |
| 运维与成本（10%） | 5 | 1 | 10.0 | 2.0 |
| 服务与生态（10%） | 3 | 3 | 6.0 | 6.0 |
| 合计 | — | — | 80.0 | 66.0 |
计算过程：以候选A“知识组织与检索”为例，得分5÷5×25=25.0；其余维度同理，六项相加得80.0分。候选B合计66.0分。维度得分按“该维度加权得分÷维度权重合计”折算，例如候选A权限与安全维度为15.0÷25=60分，刚好达到关键项底线3分对应的60分。
对照阈值：候选A总分80分达到70分线，关键维度均不低于3分，否决项全部满足，结论为通过，进入试点。候选B总分66分未达线，且运维与成本维度仅得1分，结论为不通过。
再看缺失值折算：假设候选A“服务与生态”维度证据未取得，该维度10%权重不计入，已评权重为90%。原始加权得分为74.0分，折算总分=74.0÷90×100≈82.2分，结论中需标注“服务与生态维度缺失，权重10%，结论可靠性待补充证据后确认”。缺失权重未超过20%，可继续评审，但要把补充证据列为试点前的确认事项。
解读与限制：分数能说明什么、不能说明什么
分数反映的是评估时点、按既定证据标准下的相对适配度。它回答“在当前证据下哪款更符合本次选型要求”，不回答“上线后一定好用”。同一款产品换一套权重，排序可能变化，因此结论中要写明权重来源，必要时做敏感性说明：把权重上下调整5个百分点后，排序是否稳定。排序稳定，结论更可靠；排序翻转，说明候选差距小，应结合试点判断。
未验证项与缺失项对结论的影响要显式披露。文档说明满足（3分）与演示验证满足（5分）之间存在证据强度差异，若某候选大量评分项停留在3分，即使总分达标，也应在结论中提示“多项能力未经试用验证”，并把验证动作列入试点计划。
阈值是决策门槛，不替代试点验证。建议在试点结束后用实际使用数据回校阈值：例如试点中暴露的检索效果问题，可反过来检查当初“知识组织与检索”维度的评分项是否写得不够具体、权重是否偏低，并在下一轮评估中修正。评估表本身也需要版本管理，每次评审后记录调整点和原因，让打分规则逐步贴近业务实际。
当评估表需要多人协作填写、评审记录需要留存和流转时，可以把评分表、证据附件和评审结论放在同一文档空间里管理。ONES Wiki 支持页面树组织文档、文档关联项目任务，并记录页面版本、支持查看与回滚，权限可按角色配置读写范围，适合承载这类评审材料与结论的沉淀；具体采用哪种承载方式，仍以团队现有的评审流程为准。
常见问题
评估表打分到一半发现权重不合理，可以中途调整吗？
不建议在评审过程中调整权重。权重变化会直接改变总分和排序，中途改权重会让已完成的评分失去可比性。如果确实发现权重与业务优先级严重不符，应在所有候选评分完成前由评审会集体确认调整，并记录调整原因；调整后所有候选需按新权重重新计算。更稳妥的做法是在正式评审前用一款候选做试评，检验权重分配是否合理，再锁定权重进入正式评分。
关键项最低分和总分线冲突时，以哪个为准？
两者是并列条件，同时满足才算通过。总分达到70分但核心维度（如权限与安全）低于3分，结论仍为不通过，因为总分线反映整体适配度，关键项底线防止核心能力存在硬伤。实际操作中，若总分很高但某一关键项略低于底线，可先判断该短板是否可通过整改在试点前解决：能解决则列为“有条件通过”的整改项，不能解决则维持不通过。关键项清单应在评审前明确，不宜临时增减。
缺失证据的评分项按0分算还是按平均分算？
两者都不建议。按0分算会把“没查到”误判为“不满足”，低估候选；按平均分算会掩盖证据缺口，高估候选。正确做法是记为空缺并标注原因，汇总时该评分项不计入已评权重，总分按已评权重折算，同时在结论中披露缺失项及权重占比。若缺失权重超过20%，应提示结论可靠性不足，建议补充证据后再评审。缺失项清单可作为试点前需要确认的事项。
否决项应该放在打分表里还是单独列？
建议单独列在评估表末尾，不参与加权计算。否决项是硬性门槛，例如数据合规、账号与权限模型、数据可导出等，任一不满足即整体不通过，无论总分多高。如果把否决项混入加权评分，可能出现“总分达标但硬伤仍在”的结论，失去否决的意义。单独列示也便于安全合规角色直接给出通过/不通过结论，不需要参与逐项打分。
评估表用文档管理还是用表格工具管理更好？
取决于评审规模和协作方式。候选少、评委少时，用文档承载评分表、证据附件和结论即可，便于版本留存和评论讨论；候选多、需要多人并行打分和汇总时，表格工具在计算和汇总上更直接。无论用哪种载体，关键是评分项、证据位置和结论在同一处可追溯。ONES Wiki 支持页面树组织文档、文档关联项目任务，并记录页面版本、支持查看与回滚，权限可按角色配置读写范围，适合承载评审材料与结论的沉淀；具体采用哪种承载方式，仍以团队现有的评审流程为准。
