知识库工具试用结束后，团队往往面对一堆截图、会议纪要和零散反馈，却难以回答“这款工具是否值得进入下一轮”。要把试用转成可比较的结论，需要先把功能满足、使用体验、实施可行性拆成可打分的指标，用统一口径记录证据，再按公式汇总分项得分与总分，并保留未通过项和风险清单作为决策依据。下文给出一套可复算的评估方法，并在流程承载处说明 ONES 如何承接试用任务与评审记录。
要点总览（TL;DR）
- 试用评估先拆成功能满足、使用体验、实施可行性三类判断，并事先约定结论出口：进入下一轮、补充试用或终止。
- 功能看关键场景覆盖率与必备能力可用性，体验看任务完成率、完成耗时与卡点数，实施可行性看权限适配、数据导入、集成方式与运维培训投入。
- 不同候选工具使用同一套任务脚本、记录字段和评分规则，记录任务、结果、耗时、卡点、证据与打分人，保证结果可横向比较。
- 单项得分统一换算到 0–100 分，按权重加权汇总；未执行或未验证项单独标注，不按零分计入，并在结论中注明覆盖比例。
- 总分用于排序，风险清单与未验证项决定下一步动作；总分接近时回到分项得分比较，主观体验分样本过小时仅作参考。
试用评估要回答哪三个判断
试用评估的产出是一份能支撑决策的结论，而非一份功能罗列。它需要回答三个判断：候选工具能否覆盖团队的关键知识场景（功能满足）；真实用户能否顺畅完成任务（使用体验）；在现有组织架构、数据与系统环境下能否落地（实施可行性）。三个判断分别对应不同的证据来源和观察方式，缺一项就容易得出片面结论。
结论的用途需要事先约定，通常有三种：进入下一轮（如进入商务谈判、扩大试用范围或安全评审）、补充试用（针对未验证项追加场景或延长试用）、终止（关键场景无法跑通或实施成本超出可接受范围）。在试用开始前就把这三种出口写进评估方案，可以避免试用结束后因结论口径不一致而反复争论。
当有多个候选工具时，评估结论还必须能横向比较。这意味着不同工具的试用要使用同一套任务脚本、同一套记录字段和同一套评分规则；否则各工具由不同试用者、在不同时间、用不同任务得出的印象无法放在一起排序。评估方案应在试用启动时冻结指标与口径，试用过程中只补充证据，不随意调整标准。
功能、体验、实施可行性各用哪些指标
三类判断需要拆成可观察、可打分的指标。指标数量不宜过多，建议每类控制在三到五项，确保试用期内能完整采集。下表给出一个可直接采用的指标框架，团队可按知识库的实际用途增删。
| 类别 | 指标 | 观察对象 | 评分方式 |
|---|---|---|---|
| 功能 | 关键场景覆盖率 | 试用脚本中预设的知识场景（如文档创建、分类归档、全文检索、权限隔离、版本回溯）是否跑通 | 按跑通场景数占脚本场景总数的比例换算分值 |
| 功能 | 必备能力可用性 | 团队列出的必备能力清单（如协同编辑、评论、附件预览、模板）逐项验证 | 每项按“完全可用 / 部分可用 / 不可用”三档打分 |
| 体验 | 任务完成率 | 真实目标用户按脚本独立完成任务的比例 | 完成任务人数 ÷ 参与人数 |
| 体验 | 完成耗时 | 同一任务从开始到完成的时长 | 与预设基准时长比较，或取多次任务的中位数分档 |
| 体验 | 卡点数 | 任务过程中需要求助、返工或放弃的节点 | 按卡点数量与严重程度扣分 |
| 实施可行性 | 权限与组织架构适配 | 能否按部门、项目、角色配置读写权限，与现有组织架构的匹配程度 | 按适配程度分档，未验证项单独标注 |
| 实施可行性 | 数据导入 | 历史文档、附件、目录结构能否导入，导入后格式与链接是否完整 | 按导入成功率与人工修复量分档 |
| 实施可行性 | 集成方式 | 与现有系统（如项目管理、单点登录、消息通知）的对接方式与工作量 | 按对接可行性分档，未验证项单独标注 |
| 实施可行性 | 运维与培训投入 | 日常维护所需人力、用户上手所需培训时长 | 按预估投入分档 |
指标范围要与试用时间窗绑定。例如“关键场景覆盖率”只统计试用期内脚本覆盖的场景，不把未安排进脚本的能力算作未通过；“数据导入”若试用环境不具备导入条件，应标注为未验证，而非直接判为不可行。试用时间窗、参与人数、任务清单应在方案中写明，作为后续解释得分的边界条件。
实施可行性中的权限、导入、集成、运维四项，往往需要厂商配合或额外环境，建议在试用计划中单独安排验证窗口。对于资料或环境暂不具备的项，记录“未验证”并注明原因，比给出一个猜测分数更有决策价值。
试用记录的数据口径与证据要求
可比较的前提是记录口径统一。试用开始前应准备一份场景脚本，把团队最关心的知识管理任务写成可执行的任务清单，例如“新建一篇项目复盘文档并归档到对应目录”“检索一份三个月前的附件并在线预览”“为外部协作方配置只读权限”。每个候选工具都按同一脚本执行，任务顺序和操作要求保持一致。
记录表建议包含以下字段，每个任务一行：
- 任务编号与任务描述：对应脚本中的条目，保证跨工具可比。
- 执行人：记录真实目标用户，而非仅由项目组成员代操作。
- 结果：完成 / 部分完成 / 未完成，并写明未完成的具体环节。
- 耗时：从任务开始到结束的时长，注明是否包含求助时间。
- 卡点：记录卡点位置、现象和严重程度（阻断 / 需绕行 / 轻微）。
- 证据：截图或录屏，命名规则与任务编号对应，便于复核。
- 打分人与评分档位：写明由谁按哪条规则打分，避免事后追溯不清。
评分口径要事先分档。例如必备能力可用性分为“完全可用记 2 分、部分可用记 1 分、不可用记 0 分”，体验耗时可按“优于基准、接近基准、明显超出”三档换算。分档标准写进方案后，不同试用者按同一把尺子打分，减少主观差异。
缺失数据和主观评价需要单独处理。任务未执行或环境不具备时，记录“未执行”并注明原因，不按零分计入；纯主观感受（如界面是否顺手）可作为补充意见记录，但不直接进入总分，或单独作为一列参考分。这样汇总时能清楚区分“测过且不达标”和“没测到”。
试用过程中的任务分配、记录归档与评审结论，可以借助 ONES 的项目与 Wiki 承载：把每个试用任务建为工作项分配给对应试用者，记录与截图作为附件归档，评审结论沉淀在关联的 Wiki 页面中，使文档与项目工作保持对应关系。ONES Wiki 支持页面树组织内容、页面组关联项目，文档可嵌入任务进度与报表，便于在评审时直接对照任务完成情况。这一承载方式适用于需要多人分工、留痕和复盘的试用组织，单人小范围试用用普通表格记录即可。
如何计算分项得分与总分
单项得分建议统一到 0–100 分区间，便于不同指标横向比较。以分档打分为例，单项得分公式为：单项得分 =（该项实际得分 ÷ 该项满分）× 100。例如必备能力共 8 项，每项满分 2 分，实际得 13 分，则单项得分 = 13 ÷ 16 × 100 ≈ 81.3 分。
比例型指标直接换算：关键场景覆盖率得分 = 跑通场景数 ÷ 脚本场景总数 × 100；任务完成率得分 = 完成任务人数 ÷ 参与人数 × 100。耗时类指标可先设定基准时长，再按“实际耗时 ÷ 基准耗时”落入分档区间换算分值，基准值需在方案中写明来源。
权重按决策重要性设定，三类权重之和为 100%。例如功能 40%、体验 30%、实施可行性 30%，类别内各指标再分配子权重。加权总分 = Σ（单项得分 × 该项权重）。权重应在试用前确定并记录，试用后不因结果调整。
分母为零或任务未执行时，该项不计入得分，也不按零分处理。处理方式有两种：一是从总分计算中剔除该项，并按剩余权重重新归一化；二是单独列出“未验证项”清单，总分只覆盖已验证部分，并在结论中注明覆盖比例。两种方式都要在汇总表中写明，避免读者误以为该项已通过或已失败。
汇总表建议按“类别—指标—原始记录—单项得分—权重—加权得分”排列，底部给出分项得分（类别内加权）与总分，右侧附未验证项和风险项清单。这样任何一个总分都能回溯到原始记录和计算公式。
一个试用评估的算例
以下为演示情景，数字用于说明计算过程，不代表任何真实产品的实测结果。假设两个候选工具 A 和 B 参加同一轮试用，脚本包含 10 个知识场景，参与试用 6 人，权重为功能 40%、体验 30%、实施可行性 30%。
功能部分：A 跑通 9 个场景，覆盖率得分 90；必备能力 8 项共 16 分，实得 14 分，得分 87.5。功能类别内两项子权重各 50%，功能分项得分 = 90 × 0.5 + 87.5 × 0.5 = 88.75。B 跑通 7 个场景，覆盖率得分 70；必备能力实得 12 分，得分 75，功能分项得分 = 72.5。
体验部分：A 的 6 人中 5 人独立完成任务，完成率得分 83.3；耗时中位数接近基准，按分档记 80 分；卡点 2 个（1 个需绕行、1 个轻微），按规则扣至 75 分。三项子权重分别为 40%、30%、30%，体验分项得分 = 83.3 × 0.4 + 80 × 0.3 + 75 × 0.3 ≈ 79.8。B 的完成率 4/6 得 66.7，耗时明显超出记 60 分，卡点 4 个记 55 分，体验分项得分 ≈ 61.2。
实施可行性部分：A 的权限适配 85、数据导入 80、集成方式未验证、运维培训 70。剔除未验证项后按剩余权重归一化，实施分项得分 ≈ 78.3，并在结论中标注集成方式未验证。B 的权限适配 70、数据导入 65、集成方式 60、运维培训 60，实施分项得分 = 63.75。
加权总分：A = 88.75 × 0.4 + 79.8 × 0.3 + 78.3 × 0.3 ≈ 83.0；B = 72.5 × 0.4 + 61.2 × 0.3 + 63.75 × 0.3 ≈ 66.5。结合风险清单，A 的集成方式尚未验证，需在下一轮补充验证；B 在关键场景覆盖和耗时上明显落后。结论可写为：A 进入下一轮并补充集成验证，B 终止或待场景补齐后重新评估。这个推导过程说明，总分用于排序，风险清单用于决定下一步动作，两者共同构成决策依据。
如何解读得分并避免误判
总分接近时不宜直接按小数点排序。例如两个工具总分相差 2 分以内，应回到分项得分比较：若差异主要来自主观体验分，参考价值有限；若差异集中在关键场景覆盖率或数据导入成功率这类可复核指标上，则更有说服力。比较时优先看与团队核心用途直接相关的分项，而非总分排名。
主观体验分的偏差来源需要说明。试用者的熟悉程度、任务顺序、界面偏好、是否由项目组成员代操作，都会影响完成耗时和卡点记录。解读时应注明参与人数、任务次数和打分人，样本过小时把体验分作为参考而非决定性依据。必要时安排同一批用户交叉试用多个工具，减少个人偏好带来的偏差。
实施可行性中的未验证项必须单独标注，不能因为总分高就默认可行。权限粒度、数据导入格式、集成接口等若在试用期内未实际验证，应在结论中写明“待验证”及验证方式（补充试用、厂商确认或技术评审），并把验证动作列入下一轮计划。资料未覆盖的能力不等于产品不具备，结论应表述为“未验证”，而非“不支持”。
指标得分与最终决策之间是支撑关系，而非替代关系。总分反映试用范围内的相对表现，最终是否进入下一轮还要结合预算、合规、现有系统兼容性和团队接受度综合判断。把分项得分、未验证项和风险清单并列呈现，让决策者看到结论的依据和边界，比给出一个孤立的总分更可靠。
常见问题
试用期内权限、数据导入、集成这些实施项来不及验证，评估结论怎么写？
把这类项标注为“未验证”，写明未验证的原因（如试用环境不具备导入条件、集成接口需厂商配合）和后续验证方式，例如补充试用、厂商技术确认或单独的技术评审。计算总分时可将该项从加权中剔除并按剩余权重归一化，同时在结论中注明已验证部分的覆盖比例。未验证不等于产品不具备该能力，结论表述用“待验证”，并把验证动作列入下一轮计划。
参与试用的人太少，体验分波动很大，还能用吗？
可以用，但要降低它的决策权重。记录参与人数、任务次数和打分人，在结论中说明样本规模；样本过小时把体验分作为参考列，不直接决定排序。若条件允许，安排同一批用户交叉试用多个候选工具，或对同一任务重复执行取中位数，减少个人熟悉程度和界面偏好带来的偏差。关键场景覆盖率和数据导入成功率这类可复核指标，在样本不足时更适合作为主要比较依据。
两个候选工具总分只差一两分，怎么判断谁进入下一轮？
先看分项得分而不是总分排名。差异若集中在关键场景覆盖率、数据导入成功率这类可复核指标上，说服力较强；若主要来自主观体验分，参考价值有限。再对照风险清单：一方存在阻断级卡点或关键场景未跑通，即使总分略高也应谨慎。最后结合预算、合规要求和现有系统兼容性综合判断，必要时对差异项安排补充试用，用新增证据消除分歧。
试用记录用表格还是用协作工具承载，怎么选？
单人小范围试用、任务数量有限时，普通表格足够，字段固定、汇总方便。多人分工、需要留痕和复盘的试用，可以把每个试用任务建为工作项分配给对应试用者，记录与截图作为附件归档，评审结论沉淀在关联的知识库页面中。ONES 的项目与 Wiki 可以承接这种组织方式：ONES Wiki 以页面树组织内容、页面组可关联项目，文档支持嵌入任务进度和各类报表，评审时能直接对照任务完成情况。选择依据是参与人数、是否需要跨轮次追溯，以及结论是否要长期留存。
试用开始后能调整指标或权重吗？
指标与权重应在试用启动时冻结，试用过程中只补充证据，不因中间结果调整标准，否则不同工具之间失去可比性。确有遗漏时，可新增指标并单独记录，注明它是试用中途加入、只对后续任务生效，不回溯修改已完成任务的评分。若必须调整权重，应对所有候选工具按同一新权重重新计算，并在汇总表中保留调整前后的两版结果，说明调整原因。
