企业知识库案例核验：问题集测试、权限检查与效果数据复核

验证企业知识库建设的客户案例，需要分别回答四个问题：项目是否真实存在、功能是否经过验证、业务效果是否有据可查、客户是否允许公开。演示截图不替代上线验收，供应商自述不替代客户确认，功能测试通过也不能直接写成业务收益。

在没有已核实客户案例和效果数据的情况下，应先收集资料、开展测试与复核，不发布客户成功故事或收益结论。以下流程适用于企业知识库选型、试点验收和案例发布审核，是建议采用的核验方法，不代表任何供应商已经通过验证，也不是实际项目的测试报告。

核验前需要准备哪些资料？

先确定准备验证的具体主张，再索取对应材料。不要只问“有没有成功案例”，而应问“哪项交付、哪次测试、哪个结果可以复核”。

建议指定业务负责人、技术复核人和发布审核人，按下表准备资料：

资料类别　建议准备的内容　用于判断什么

项目资料　客户主体、项目编号、实施时间、合同范围或客户确认记录　项目是否存在、与客户是什么关系

交付资料　交付清单、验收范围、版本、知识来源、适用用户和权限边界　实际交付了什么

测试资料　问题集、参考答案、评分规则、原始回答、引用内容、执行时间和运行配置　功能结论能否复核

效果资料　实施前后原始记录、统计周期、样本范围、计算方法及同期业务变化　效果数据能否复算、比较条件是否一致

发布资料　客户名称、标识、截图、引语和数据的使用授权　哪些内容可以公开

通过受控渠道传递资料，将核验用材料与可公开素材分开保存，并记录来源、日期、版本、保管人和访问范围。只收集核验所需的信息，不要求无关敏感内容。

如何按步骤验证客户案例？

1. 把案例文案拆成可验证的主张

逐句检查候选文案，将内容分别归入项目真实性、交付范围、功能表现、业务效果和公开授权。

为每项主张记录四件事：准备说什么、适用范围、由谁确认、依据是什么。例如，不直接接受“知识库效果显著”，而将其改成核验问题：“在指定版本、指定问题集和指定评分规则下，回答是否达到事先约定的要求？”这只是测试问题，不是测试结论。

本步应形成主张清单。无法明确对象、范围或判断条件的表述，先删除或暂缓审核，不用“全面落地”“显著提升”等措辞补足。

1. 核实客户身份与项目关系

核对客户主体、项目时间和实施范围，并请客户授权联系人确认其与项目的关系。

可检查合同相关页、项目确认记录或验收文件。敏感字段可按需要遮盖，但应保留足以关联客户、项目和范围的信息。交叉核对主体名称、项目编号、时间与服务范围，并通过独立取得且确认的联系方式联系客户，不只依赖转发截图。

本步应留下确认人、确认时间和核对结果。主体不一致、时间矛盾或联系人无法确认时，暂停该项目的案例审核；不得把内部测试或演示环境写成客户上线项目。

1. 对照验收范围检查实际交付

将拟发布的功能逐项对应交付记录，区分“计划建设”“已配置”“已测试”和“已验收”。

由核验人员使用约定账号执行对应任务，记录运行环境、版本和实际结果，再与需求范围、交付清单及验收结论核对。仅有功能截图时，不据此判定已经上线运行。

如果无法访问环境，可安排客户见证的受控演示并保留记录，但结论应限定在演示条件内。仍不能复核的功能，不列入已验证的交付范围。

1. 用固定问题集复核知识库表现

测试前确定问题集、参考答案、评分规则和通过条件，不在看到结果后调整标准。

按拟发布的功能范围覆盖以下情形：

• 常见业务问题：检查回答是否符合业务负责人确认的参考答案。

• 资料中没有答案的问题：检查系统是否按约定提示无法回答，而不是给出无依据的结论。

• 过期或相互冲突的资料：检查回答是否符合事先约定的版本处理规则。

• 不同权限账号：检查回答和引用是否遵守对应用户的访问范围。

逐题保留问题、原始回答、引用片段、判定理由和异常情况。“引用可追溯”在这里指核验人员能够找到回答依据的具体文档及版本，还需检查该引用是否真正支持回答。

测试前约定是否重复执行、如何汇总结果，并保留全部执行记录，不只挑选表现较好的回答。发现问题后，记录修正内容，重新测试受影响的题目及相关权限场景。

1. 复算效果数据，限制收益结论

先确认指标定义，再比较实施前后数据。基线是用于比较的实施前记录，应写清统计对象、时间范围和计算口径。

建议由非原统计人员按同一公式复算，并检查以下条件：

• 前后是否比较相同或可比的任务与人员范围；

• 样本纳入、排除规则是否一致；

• 流程、人员、业务量或其他工具是否同期发生变化；

• 若统计耗时，是否明确包含查找、等待、人工复核和返工时间。

只有能够复算的指标，才进入效果审核。缺少基线时不计算提升比例；缺少成本构成时不推算投资回报；同期变化无法区分时，不把观察结果全部归因于知识库。

本步可以得出“本次不形成效果结论”，不必为了凑齐案例而用估计值补成客户实绩。

1. 取得公开授权并逐句审稿

将最终正文、数据、截图和引语交客户确认，逐句检查内容是否超出已经核验的范围。

授权审核应覆盖客户名称、标识、截图、引语和效果数据，并明确适用稿件、使用渠道及其他约定条件，不只依据早期访谈中的笼统同意。

没有公开授权的内容不发布。拟采用匿名形式时，也应检查行业、地区、项目时间、截图等剩余信息是否足以识别客户，不把“删掉名称”当作完成授权审核。

如何判断案例验证是否通过？

分项记录结论，不用一个笼统的“通过”覆盖真实性、功能、效果和公开授权。

核验状态　建议允许表达的范围　不应扩展的结论

仅确认项目存在　经授权描述已核实的项目背景和实施范围　不写功能达标或业务收益

项目与功能测试均已确认　经授权描述指定版本、环境和问题集下的测试结果　不推断全量业务或长期表现

效果记录可复算，比较条件已说明　经授权在明确周期、样本和口径下描述观察结果　不向其他客户承诺相同结果

未取得公开授权　仅按约定范围用于内部核验　不公开客户身份或相关素材

建议安排未参与原实施的人员复核关键材料。未通过的部分应删除或缩小表述范围，不影响其他已经独立核实且获准公开的内容。

资料缺失或测试失败时，如何修正并复核？

先暂停对应结论，再将问题交给能处理它的负责人。部分测试通过，不作为整篇案例放行的理由。

1. 身份或项目范围不清：由项目负责人补齐主体、范围及客户确认记录；未解决前不作为已验证客户案例发布。
2. 回答或引用有误：由业务内容负责人检查知识来源，再由技术负责人排查运行配置；修正后复测受影响项目。
3. 出现越权访问：暂停相关测试或发布，交权限管理与安全负责人处理，确认访问边界后重新验收。
4. 效果数据不足：改为不含收益结论的实施说明，或另行开展有明确记录规则的前瞻性试点，不预告尚未测得的提升结果。
5. 授权范围有争议：由客户授权联系人与发布审核人员确认；解决前移除争议内容。

再次提交审核时，应附问题编号、责任人、修正记录、修正后的版本和复测结果。旧版本的通过结论不直接沿用于新版本。

发布前的验收清单应检查什么？

只核对拟发布内容涉及的检查项；不涉及效果结论时，可将效果项标为“不适用”，但不能因此写入收益暗示。未通过的主张应删除或缩小范围。

• 客户主体和项目关系已核实，确认记录可查。

• 项目范围、上线状态和交付版本已区分清楚。

• 功能结论对应可检查的测试或验收记录。

• 问题集、参考答案、评分规则和全部原始测试结果已留存。

• 异常结果未被选择性删除，修正与复测记录完整。

• 如发布效果数据，原始记录可复算，周期、样本、计算口径和限制已说明。

• 未将缺少基线、成本或可比条件的内容写成收益结论。

• 客户名称、标识、截图、引语和数据的公开使用已获确认。

• 正文未把单个项目结果推广为普遍承诺。

常见问题

没有已核实客户案例，还能发布什么？

建议发布验证方法、选型问题或试点设计，不写成客户成功案例。待项目、功能、效果和授权分别完成核验后，再发布相应范围的结论。

匿名客户案例是否可以降低核验要求？

不建议降低。对外匿名与内部可核验应分开处理：内部仍应确认客户主体、项目关系及结果依据，对外则按授权决定披露范围。无法核实主体和项目关系的材料，不作为已验证客户案例。

客户说“很好用”，能否据此发布效率提升？

不应据此推导时间节省或收益比例。建议仅作为经客户确认并获准公开的主观反馈；效率结论另行核对任务定义、耗时记录、样本范围和统计方法。

钉云官网宣传能否直接作为企业知识库案例的效果证明？

不应直接作为证明。现有钉云相关材料包含客户规模、满意度等官网自述，但尚不足以核实具体企业知识库客户案例及其效果。审核具体案例时，仍应取得客户确认、交付与验收记录、原始测试结果；涉及收益结论时，还应核对基线、效果原始记录、计算口径及公开授权。

只有演示，没有生产环境记录怎么办？

建议仅描述演示条件下已经确认的结果，不表述为生产上线成效。要形成上线案例，应继续核对实际运行范围、用户权限、版本和验收记录。

没有实施前数据，能否事后补算收益？

不应把事后估计写成客户实绩。可以从当前阶段开始建立后续比较所需的记录；如果系统已经投入使用，当前记录应注明对应阶段，不能称为原项目的实施前基线。在完成适当比较与复核前，不发布提升比例或投资回报结论。