知识库工具试用结束后，要把零散体验转成可比较的结论，评估指标应围绕三条主线：功能覆盖、使用体验、实施可行性。功能看核心场景是否跑通、覆盖比例多少；体验看任务完成时间、首次成功率和评分；实施可行性看导入耗时、权限配置工作量与集成验证结果。每项指标都要写明公式、分母、时间窗和取数方式，用同一张记录表逐项留证，再按权重汇总并标注证据强度。
要点总览（TL;DR）
- 试用评估围绕功能覆盖、使用体验、实施可行性三条主线设计指标，每条主线对应一个决策判断，避免指标堆砌。
- 每个指标要写明公式、单位、时间窗、分母和取数方式，保证不同评分人、不同候选之间可以复算和比较。
- 主观评分采用1—5分量表并给出行为描述，多人独立打分、记录分歧，减少单一评分人的偏差。
- 试用记录表按一次操作一行填写，未测项和缺失数据显式标注，不能默认按通过处理。
- 汇总时先归一化再按权重加总，做敏感性检查，结论区分推荐进入下一轮、有条件通过、淘汰三档并注明样本范围。
试用评估要回答的三个判断
试用评估的产出是一份能支撑决策的结论，需要明确回答三个判断：候选工具能否支撑团队的核心知识场景，目标用户是否愿意持续使用，实施过程是否在可接受的工作量内可控。三个判断分别对应功能、体验、实施可行性三条主线，每条主线最终落到“进入下一轮”“有条件通过（补测后复核）”或“淘汰”三种结论之一。
评估开始前先固定范围，避免试用过程中不断追加场景导致候选之间不可比。范围至少包含三项内容：参与角色（如知识库管理员、内容贡献者、普通查阅者，各角色人数与分工）、试用时长（从开通到记录截止的起止日期）、知识场景清单（如文档创建与协作编辑、历史版本回溯、按权限查阅、全文检索、附件检索、页面与项目关联）。场景清单建议分为“核心场景”和“边界场景”两档，核心场景是业务必须跑通的路径，边界场景用于观察失败情况和异常处理。
需要说明结论的边界：试用反映的是特定角色、特定场景、有限时长内的表现。单次试用中某个操作顺畅，不能推断长期使用中内容规模增长后仍然顺畅；某次导入失败，也不能直接判定工具不具备导入能力，应记录失败原因并安排补测。评估结论应写明样本范围和时间窗，供下一轮决策时复核。
指标清单与计算口径
指标设计的原则是可复算：任何人拿到原始记录，按同一公式能算出相同结果。下表给出三条主线的常用指标，公式中的分母需在试用前确定并写入评估方案。
| 类别 | 指标 | 公式 | 单位 | 时间窗与分母 | 数据来源 |
|---|---|---|---|---|---|
| 功能 | 核心场景通过率 | 通过的核心场景数 ÷ 核心场景总数 | % | 试用全程；分母为场景清单中的核心场景数 | 场景验证记录 |
| 功能 | 功能覆盖比例 | 已实现预期结果的检查项数 ÷ 检查项总数 | % | 试用全程；分母为评估方案中的功能检查项 | 功能核对表 |
| 功能 | 边界场景失败数 | 边界场景中未达预期结果的次数（计数） | 次 | 试用全程；分母为边界场景执行次数 | 异常记录与日志 |
| 体验 | 任务完成时间 | 各次任务从开始到完成的耗时，取中位数与最大值 | 分钟 | 按任务类型分别统计；分母为有效执行次数 | 计时记录 |
| 体验 | 首次成功率 | 首次执行即达预期结果的任务数 ÷ 执行任务总数 | % | 试用全程；分母为执行任务总数，重试不计入首次 | 任务记录 |
| 体验 | 主观评分 | 各评分人对指定维度的打分均值，并记录极差 | 分 | 试用结束后统一打分；分母为有效评分人数 | 评分表 |
| 实施 | 数据导入耗时 | 从开始导入到完成校验的总耗时 | 分钟 | 按批次记录；分母为导入批次数 | 导入日志 |
| 实施 | 导入失败条数 | 导入后校验不通过的记录条数 | 条 | 按批次统计；分母为该批次总条数 | 导入校验报告 |
| 实施 | 权限配置工作量 | 完成预设权限方案所需的配置步骤数与耗时 | 步/分钟 | 按权限方案执行一次；分母为方案数 | 配置记录 |
| 实施 | 集成验证结果 | 验证通过的集成点数量 ÷ 计划验证的集成点数量 | % | 试用全程；分母为计划集成点清单 | 集成验证记录 |
主观评分建议采用1—5分量表，并对每个分值给出行为描述，例如5分表示“无需帮助即可完成且结果符合预期”，3分表示“需要查阅帮助或他人协助后完成”，1分表示“无法完成”。评分维度可设为易学性、操作效率、结果可信度、整体满意度四项，避免只给一个笼统总分。评分人应覆盖不同角色，且在实际操作后独立打分，不集中讨论后再填。
实施可行性中的导入指标需要提前约定数据样本：导入条数、字段类型、附件数量、目录层级。不同样本量下的耗时不可直接比较，因此候选之间应使用同一份样本数据。权限配置工作量按预设的权限方案执行，记录配置步骤数、涉及角色数和实际耗时，避免只凭“配置简单”这类印象判断。
试用记录表怎么填：字段与证据要求
记录表是评估的证据基础，建议按“一次操作一行”的方式填写，字段包括：场景编号与名称、执行角色、操作步骤摘要、开始与结束时间、耗时、结果（达成/部分达成/未达成）、截图或日志位置、主观评分、备注。场景编号与评估方案中的场景清单一一对应，便于后续按场景汇总。
定量与定性证据要能互相印证。耗时和成功率来自计时与结果字段，截图或日志用于证明结果状态；主观评分旁应附一句简短理由，说明打分依据。只有评分没有操作记录，或只有截图没有耗时，都会让汇总时难以判断数据是否可用。
多人评分时，每位评分人独立填写自己的记录行，汇总时计算均值并记录分歧。若两位评分人对同一场景的评分相差2分及以上，应记录分歧原因，必要时安排复测或由第三人复核。分歧本身是有价值的信息，说明该场景的体验在不同角色间差异较大。
缺失数据的标注规则需要提前写死：未执行的场景标“未测”，执行了但未记录耗时的标“数据缺失”，因环境问题中断的标“无效并说明原因”。未测项不能默认按通过处理，也不能直接按失败计入分母，应在汇总时单独列出并说明对结论的影响。分母为零的情况（如某候选未安排集成验证）应标注“不适用”，不参与该项加权。
从记录到结论：汇总与比较步骤
汇总的第一步是归一化，把不同单位的指标折算到同一尺度。常用做法有两种：按满分折算，例如主观评分1—5分折算为（得分−1）÷4；按阈值分档，例如核心场景通过率≥90%记100分、70%—89%记70分、低于70%记40分。阈值应来自业务要求而非行业通用标准，并在评估方案中写明依据。
第二步是设定权重。权重反映各主线对本次决策的重要程度，例如以内容沉淀为主要目标的团队可提高功能权重，以快速上线为约束的项目可提高实施可行性权重。权重设定后应做敏感性检查：把某一主线权重上下调整10个百分点，观察候选排序是否发生变化。排序稳定说明结论稳健；排序翻转则说明结论对权重假设敏感，需要在报告中说明。
第三步是横向比较。比较表按候选逐行排列，列包括各主线得分、加权总分、证据完整度（已测项占计划项的比例）、主要短板和结论建议。证据完整度低的候选，即使总分靠前也应标注“需补测”，避免用不完整数据下结论。
结论表述建议分为三档：推荐进入下一轮（核心场景全部通过、总分达到预设门槛、证据完整）、有条件通过（核心场景通过但存在需补测项或单项明显短板）、淘汰（核心场景存在未通过项且无法通过配置或流程弥补）。每档结论后附一句证据说明，指明依据的记录范围和时间窗。
试用过程中的场景验证、问题记录和结论评审，可以在 ONES 的工作项与文档中承载：把每个试用场景建成工作项，记录执行状态与结果，评估结论文档引用这些记录作为附件依据。ONES Wiki 支持页面版本记录与回滚，也支持按角色配置读写权限，适合在试用期间沉淀评估方案、记录表和结论文档，并控制不同角色的查看与编辑范围。具体能力是否满足团队要求，仍以实际试用验证为准。
一个算例：三个候选的试用评分
以下为演示情景，数据为假设值，仅用于说明计算过程。设定试用范围：3个候选工具（A、B、C），核心场景6个、边界场景4个、功能检查项20个，参与角色3类共6人，试用期两周，导入样本为500条文档记录。
功能类计算：候选A核心场景通过5个，通过率5÷6≈83.3%；功能检查项实现16项，覆盖比例16÷20=80%；边界场景失败2次。候选B核心场景通过6个，通过率100%；覆盖比例18÷20=90%；边界失败1次。候选C核心场景通过4个，通过率66.7%；覆盖比例14÷20=70%；边界失败3次。
体验类计算：候选A任务完成时间中位数12分钟，首次成功率18÷24=75%，主观评分均值3.8分，折算为（3.8−1）÷4=70分。候选B中位数9分钟，首次成功率21÷24=87.5%，评分均值4.2分，折算80分。候选C中位数15分钟，首次成功率15÷24=62.5%，评分均值3.2分，折算55分。
实施类计算：候选A导入耗时40分钟，失败12条，失败率12÷500=2.4%，权限配置18步、耗时35分钟，集成验证通过3÷4=75%。候选B导入耗时25分钟，失败3条，失败率0.6%，权限配置12步、耗时20分钟，集成验证4÷4=100%。候选C导入耗时55分钟，失败28条，失败率5.6%，权限配置22步、耗时50分钟，集成验证2÷4=50%。
缺失与零分母处理示例：假设候选C未安排附件检索场景，该场景标“未测”，在核心场景通过率中不计入分母，同时在报告中注明“核心场景实际评估5个”。若某候选未计划集成验证，集成项标“不适用”，其权重按比例分摊到其余实施指标，而不是记0分。
加权汇总示例：设功能权重50%、体验30%、实施20%，各主线内指标等权折算为百分制。候选A功能得分约（83.3+80+边界扣分后折算）≈78，体验约72，实施约70，加权总分约78×0.5+72×0.3+70×0.2=74.6。候选B功能约93，体验约84，实施约88，总分约93×0.5+84×0.3+88×0.2=89.3。候选C功能约62，体验约58，实施约52，总分约62×0.5+58×0.3+52×0.2=58.8。排序为B、A、C。结合核心场景通过情况，B可推荐进入下一轮，A有条件通过（边界场景失败需补测），C淘汰。上述数值与权重均为演示假设，实际评估应按团队业务要求重新设定。
结果怎么读：常见误判与限制
样本量与角色覆盖直接影响结论可信度。每类角色只有一人参与、每个场景只执行一次时，结果容易受个人熟练度和单次环境影响。建议核心场景至少由两类角色各执行一次，关键任务重复执行并取中位数。参与人数少时，主观评分的均值波动较大，应同时报告极差和分歧记录。
主观评分存在宽容偏差和集中趋势，评分人可能普遍打高分或集中在中间分值。校准方法包括：评分前统一行为描述、安排一名评分人交叉复核部分记录、对分歧超过2分的场景安排复测。评分结果用于比较候选之间的相对差异，不宜当作绝对质量结论。
单指标领先不能代表整体适配。某候选检索速度最快，但权限配置步骤多、导入失败率高，整体实施成本可能更高。汇总时应同时看主线得分和证据完整度，避免用一项亮眼指标覆盖其他短板。
试用环境与正式环境存在差异：试用期数据量小、并发低、权限方案简化，正式上线后内容规模增长、角色增多，检索响应和权限维护工作量可能变化。试用结论应写明环境条件，进入下一轮后安排小范围真实场景验证，重点复核导入、权限和检索三项在真实数据量下的表现。
结论复核建议在评估报告完成后由未直接参与试用的负责人审阅，检查指标口径是否一致、缺失项是否已标注、权重假设是否合理。进入下一轮的候选应列出待验证清单，把试用中未覆盖或证据不足的项目转为下一阶段的验证任务，而不是直接视为已满足。
常见问题
试用期只有一两周，指标是不是要精简？
时间紧时优先保留能支撑决策的指标，而不是把清单砍到只剩主观印象。建议保留核心场景通过率、首次成功率、任务完成时间中位数、导入耗时与失败条数、权限配置步骤数这几项，它们分别对应功能、体验、实施三条主线，且都能从操作记录中直接算出。功能覆盖比例和集成验证结果可以按计划项缩减，但分母要在试用前定好，事后不再调整。
场景数量可以减少，核心场景仍建议覆盖文档创建与协作、权限查阅、检索三类路径。每类至少由两类角色各执行一次，样本虽小，结论中写明角色和次数即可。
主观评分大家普遍打高分，怎么处理？
先检查量表是否给了行为描述。只写“1—5分”而不说明各分值对应什么表现，评分人容易集中在4分附近。把每个分值锚定到具体行为，例如5分表示无需帮助即可完成且结果符合预期，3分表示需查阅帮助或他人协助后完成，1分表示无法完成，分布会拉开。
汇总时同时报告均值和极差，对同一场景评分相差2分及以上的记录写明分歧原因，必要时安排复测或第三人复核。主观评分用于比较候选之间的相对差异，不宜当作绝对质量结论。
某个候选没有安排集成验证，这项怎么算？
标“不适用”，不记0分，也不计入该项分母。汇总时把该指标的权重按比例分摊到其余实施类指标，并在报告中注明分摊方式。若集成验证属于本次决策的必要条件，则应安排补测后再出结论，而不是用分摊掩盖空缺。
同理，未执行的场景标“未测”，在通过率计算中不计入分母，同时注明实际评估的场景数，让读者知道结论覆盖了多大范围。
试用分数高的候选，能直接判定上线吗？
试用分数反映的是特定角色、特定场景、有限时长内的表现，可以作为进入下一轮的依据，不能替代正式上线的验证。试用期数据量小、并发低、权限方案简化，内容规模增长后检索响应和权限维护工作量可能变化。
建议把试用中未覆盖或证据不足的项目转为下一阶段的验证任务，重点复核导入、权限和检索在真实数据量下的表现。评估报告由未直接参与试用的负责人复核指标口径、缺失项标注和权重假设，再作决策。
权重怎么定才不算拍脑袋？
权重来自本次决策的业务约束，而不是行业通用值。以内容沉淀为主要目标的团队可以提高功能权重，以快速上线为约束的项目可以提高实施可行性权重。设定时写明依据，例如“核心场景未跑通则无法上线，功能权重设为50%”。
定完权重做敏感性检查：把某一主线权重上下调整10个百分点，看候选排序是否变化。排序稳定说明结论稳健；排序翻转说明结论对权重假设敏感，需要在报告中说明并请决策人确认权重。
