知识库工具试用结束后，要把各候选的表现整理成可比较、可复核的评估结论，关键是先明确评估目标和结论形式，再统一维度、评分口径与证据要求，最后按加权得分排序并结合风险项判断是否进入下一轮。本文给出一套可直接套用的记录表与计算步骤，并说明结论解读的边界。
要点总览（TL;DR）
- 试用评估先写清结论形式：候选排序、通过判定、风险清单，再开始记录，避免试用结束后补标准。
- 维度覆盖功能、使用体验、实施可行性三类，每类选3到5个可观察指标，权重总和100%并写明理由。
- 各候选共用一张记录表，评分用1/3/5分锚点，证据与评分同步留存，未测指标单独标注不按0分计。
- 加权得分按已测指标权重作分母，覆盖比例低于70%标注覆盖不足；得分接近时比较关键指标原始分和未测项。
- 得分只用于排序参考，是否进入下一轮还要看否决条件与风险清单，结论需写明适用条件。
试用评估要回答什么问题
试用评估的目标是判断候选知识库工具是否进入下一轮，结论形式应包含三部分：候选排序、通过或不通过的判定、风险清单。排序回答“谁更符合当前需求”，通过判定回答“是否值得继续投入”，风险清单回答“即使得分高，还有哪些问题需要在下一轮验证”。
评估范围建议覆盖三类内容。功能维度看工具是否支持团队实际需要的知识组织、检索、权限与协作能力；使用体验维度看编辑、查找、分享等高频操作是否顺畅；实施可行性维度看部署方式、数据准备、权限配置和推广成本是否在团队可承受范围内。三类范围之外的内容，例如具体价格谈判、合同条款，属于采购环节，不纳入本次试用评分。
在开始记录前，先把结论形式写进评估说明，例如“按加权得分排序，前三名进入下一轮；任一候选在权限或数据安全指标上低于阈值则不通过”。这样后续记录和计算才有明确指向，避免试用结束后再回头补标准。
评估维度与指标怎么定
维度确定后，每个维度下选3到5个可观察的指标，指标过多会让试用记录变得难以完成。指标要写成能通过操作或访谈确认的具体现象，避免“好用”“强大”这类无法打分的描述。
| 维度 | 指标示例 | 可观察定义 |
|---|---|---|
| 功能覆盖 | 知识组织与检索 | 能否按空间、目录、标签组织文档，能否在指定范围内检索到目标文档 |
| 功能覆盖 | 权限控制 | 能否为不同角色配置读写权限，权限变更是否即时生效 |
| 功能覆盖 | 版本与协作 | 是否记录页面版本、支持查看与回滚，多人同时编辑时的表现 |
| 使用体验 | 编辑与排版效率 | 完成一篇含表格、列表的文档所需操作步骤与时间 |
| 使用体验 | 查找与导航 | 新成员在无指导下找到指定知识所需时间 |
| 实施可行性 | 部署与开通 | 从申请到可用的实际耗时，是否需要额外环境准备 |
| 实施可行性 | 数据准备与迁移 | 导入现有文档的工作量与格式兼容情况 |
| 实施可行性 | 权限与组织配置 | 按团队结构完成权限配置所需时间 |
权重设置遵循两条原则：与本次评估目标直接相关的指标权重高，例如以知识沉淀为主要目的时，知识组织与检索、权限控制的权重应高于界面美观类指标；差异小、各候选表现接近的指标权重可以降低，把权重留给能区分候选的指标。权重总和设为100%，并在评估说明中写明每个权重的理由，便于评审时讨论。
试用记录表与数据口径
各候选必须使用同一张记录表，否则数据无法横向比较。记录表至少包含以下字段：候选工具、评估维度、指标、评分、证据、记录人、记录日期、备注。评分采用统一分制，建议使用1分、3分、5分三档，并为每档写清锚点。
| 评分 | 锚点定义 |
|---|---|
| 5分 | 指标要求完全满足，操作顺畅，有截图或操作记录佐证 |
| 3分 | 基本满足，存在需要绕行或额外步骤的情况，有记录说明 |
| 1分 | 明显不满足，或需要大量人工补救，有记录说明 |
| 未测 | 本次试用未覆盖或资料不足，单独标注，不按0分计入 |
证据要求与评分同步记录。功能类指标保留操作截图或录屏片段，体验类指标保留任务完成时间与操作步骤记录，实施可行性类指标保留与实施人员或管理员的访谈记录。证据的作用是事后复核评分是否站得住，也能在评审会上减少“凭印象打分”的争论。记录人和日期用于追溯，同一指标由不同人评分时，应在备注中说明分歧点。
评分计算与比较步骤
加权得分按以下公式计算：候选加权得分 = Σ（指标得分 × 指标权重）÷ Σ（已测指标权重）。分母使用已测指标权重之和，而不是全部权重之和，这样未测指标不会因为按0分处理而拉低得分。如果某候选的已测指标权重合计低于总权重的70%，该候选的得分应标注为“覆盖不足”，不参与直接排序。
计算步骤按顺序执行：
- 核对记录表，确认每个已评分指标都有证据，未测指标单独列出。
- 按维度汇总各指标得分，检查同一维度内是否存在明显矛盾，例如功能满足但操作记录显示无法完成。
- 代入公式计算加权得分，保留一位小数，并记录分母覆盖比例。
- 按得分从高到低排序；得分相同且覆盖比例接近时，比较关键指标的原始得分，例如权限控制或检索效率，而不是继续细分小数。
- 把风险项单独列出，包括未测指标、访谈中提到的隐患、下一轮需要验证的问题。
排序结果与通过判定分开处理。得分高只说明在当前指标下表现较好，是否进入下一轮还要看是否触发否决条件，例如权限配置无法满足团队结构，或数据导入工作量超出可接受范围。
一个试用记录与比较的例子
以下为演示情景，用于说明记录到结论的过程，不代表真实产品数据。假设有三个候选工具A、B、C，评估目标为选择进入下一轮的知识库工具，权重设置为功能覆盖50%、使用体验20%、实施可行性30%。
| 指标 | 权重 | A得分 | B得分 | C得分 |
|---|---|---|---|---|
| 知识组织与检索 | 20% | 5 | 3 | 3 |
| 权限控制 | 15% | 3 | 5 | 3 |
| 版本与协作 | 15% | 5 | 3 | 未测 |
| 编辑与排版效率 | 10% | 3 | 3 | 5 |
| 查找与导航 | 10% | 5 | 3 | 3 |
| 部署与开通 | 10% | 3 | 5 | 5 |
| 数据准备与迁移 | 10% | 3 | 3 | 3 |
| 权限与组织配置 | 10% | 5 | 3 | 3 |
候选A的加权得分 =（5×20 + 3×15 + 5×15 + 3×10 + 5×10 + 3×10 + 3×10 + 5×10）÷ 100 =（100 + 45 + 75 + 30 + 50 + 30 + 30 + 50）÷ 100 = 4.1。候选B的加权得分 =（3×20 + 5×15 + 3×15 + 3×10 + 3×10 + 5×10 + 3×10 + 3×10）÷ 100 =（60 + 75 + 45 + 30 + 30 + 50 + 30 + 30）÷ 100 = 3.5。候选C的版本与协作指标未测，已测权重合计85%，加权得分 =（3×20 + 3×15 + 5×10 + 3×10 + 5×10 + 3×10 + 3×10）÷ 85 =（60 + 45 + 50 + 30 + 50 + 30 + 30）÷ 85 ≈ 3.5，覆盖比例85%，可参与排序但需标注未测项。
结论可以写成：A得分最高，进入下一轮，风险是权限控制得分偏低，需在下一轮验证多角色场景；B得分次之，权限控制表现好，但检索与协作指标一般，作为备选；C的编辑体验好，版本与协作未测，建议补充测试后再判断。这个例子说明，得分接近时不能只看总分，还要看关键指标和未测项。
结果解读与限制
得分差异要结合证据强弱解读。分差在0.3以内且证据记录不完整时，不宜据此做排他性结论，应补充测试或增加评审讨论。单个指标得分高不能代表整体适用，例如检索效率高但权限配置复杂，仍可能给推广带来负担。反过来，某指标得分低也要看是否属于本次目标的关键项，避免用次要指标否决整体表现。
试用样本和场景有限是常见限制。试用通常只覆盖部分团队、部分文档类型和较短时间，得分反映的是试用期内的表现，不能直接外推为长期使用效果。未测指标应显式保留在风险清单中，进入下一轮时优先验证。评估结论还应写明适用条件，例如“在本次试用场景和权重设置下，A更适合进入下一轮”，而不是写成普遍适用的推荐。
评估记录和评审过程需要有承载的地方，避免记录散落在个人文档和聊天记录中。ONES Wiki 可用于集中沉淀评估说明、记录表和访谈纪要，页面版本记录支持查看与回滚，便于评审前核对修改；按角色配置读写权限，可以让评估成员、评审人和管理员看到各自需要的内容。评估结论形成后，还可以结合 ONES 的项目与任务场景，把下一轮验证项作为待办跟进，使文档记录和后续动作保持关联。具体使用方式可在试用中结合团队流程确认。
常见问题
试用时间有限，指标测不全怎么办？
把未测指标显式标注为“未测”，不按0分计入，并在加权计算时从分母中扣除对应权重。若某候选已测权重合计低于总权重的70%，得分标注为“覆盖不足”，不参与直接排序。未测项同时写入风险清单，作为下一轮优先验证的内容，这样既保留记录完整性，也避免因缺测误判候选表现。
不同评审人打分差异大，怎么处理？
先检查评分锚点是否写得足够具体。每个指标应写清1分、3分、5分分别对应什么可观察现象，例如“完成一篇含表格的文档所需步骤与时间”。同一指标由多人评分时，在备注中记录分歧点和各自依据的证据，评审会上围绕证据讨论，而不是重新凭印象打分。分歧集中在锚点模糊的指标上时，优先补充锚点定义再复评。
两个候选总分接近，怎么判断谁进入下一轮？
分差在0.3以内且证据记录不完整时，不宜直接做排他性结论。可以比较与评估目标直接相关的关键指标原始得分，例如权限控制或检索效率；同时检查双方的未测项和风险清单，看哪一方的遗留问题更影响后续推广。必要时补充一轮针对性测试，把关键指标测完再排序。
试用得分高的工具，能直接作为最终选型结论吗？
不能直接等同。试用通常只覆盖部分团队、部分文档类型和较短时间，得分反映试用期内的表现。结论应写明适用条件，例如“在本次试用场景和权重设置下更适合进入下一轮”。价格谈判、合同条款、长期运维成本等属于采购环节，需在试用评估之外单独核实。
评估记录和评审过程放在哪里管理比较合适？
记录散落在个人文档和聊天记录中，评审时难以核对。可以用 ONES Wiki 集中沉淀评估说明、记录表和访谈纪要，页面版本记录支持查看与回滚，便于评审前确认修改；按角色配置读写权限，让评估成员、评审人和管理员各看所需内容。结论形成后，还可结合 ONES 的项目与任务场景，把下一轮验证项作为待办跟进。
