研发工具能力差距比对要能支撑替换决策，关键是把每条结论都落到可回溯的证据上。做法是先建立现状清单和目标清单，按需求、测试、缺陷、知识等域拆成可判断的能力项，再逐项比对，把结论、依据、证据位置、验证人和日期写进同一张差距记录表。结论分为已满足、部分满足、不满足、待验证四类，避免凭印象打分。下文给出拆分口径、两份清单的字段、记录表模板、角色分工、完整示例和完成检查清单。
要点总览（TL;DR）
- 比对前先统一口径：按需求、测试、缺陷、知识等域把能力拆成可判断的陈述句，并约定截图、录屏、配置导出、访谈记录、试用记录五类证据的采集要求。
- 现状清单从现有工具配置、团队访谈和历史使用记录中提取，目标清单从业务需求、流程规范、合规与集成约束中推导，两份清单共用域、能力项、使用角色、频率、约束条件字段。
- 差距记录表一条记录只承载一个能力项，结论分为已满足、部分满足、不满足、待验证四类，每条结论必须挂证据编号或标注待验证并附验证计划。
- 角色分工上由业务负责人确认目标与优先级、一线使用者提供现状证据、工具管理员验证配置与集成、复核人抽查结论与证据一致性。
- 提交决策前逐条核对：结论可回溯、证据标注版本与采集时间、部分满足写清缺口与影响范围、待验证项有责任人和完成时间。
先定比对口径：能力项怎么拆、证据算到什么程度
比对开始前先统一三件事：比对哪些域、能力项拆到多细、什么材料算证据。口径不统一，后面各人填出来的记录无法横向比较，复核时也容易陷入争论。
按域拆分，每项写成可判断的陈述
建议先按研发主流程划分比对域，常见的是需求、测试、缺陷、知识四类，再按需要补充迭代计划、发布、报表等域。每个域下把能力拆成一句话能判断真假的陈述，例如“缺陷可从测试用例一键创建并自动关联原用例”“需求变更后能追溯受影响的下游任务”。避免“缺陷管理好用”“知识库功能强”这类无法验证的描述，它们既不能比对，也无法挂证据。
能力项的粒度以“一个角色完成一个动作”为宜。拆得过粗，一条记录里混着多个判断，结论只能写“部分满足”却说不清缺在哪；拆得过细，记录数量膨胀，复核成本上升。实际操作中可先按角色主任务列一遍，再合并明显重复的条目。
明确证据类型与采集要求
证据要能指向具体页面或具体操作，常见类型及采集要求如下：
| 证据类型 | 采集要求 | 适用能力项 |
|---|---|---|
| 界面截图 | 含系统版本号、采集时间，截到关键字段和操作入口 | 字段、状态、权限、页面配置类 |
| 操作录屏 | 包含完整操作路径，从入口到结果，不剪辑关键步骤 | 流程流转、自动化、联动类 |
| 配置导出 | 注明导出范围和导出时间，保留原始文件 | 工作流、字段方案、权限结构类 |
| 访谈记录 | 记录被访者角色、日期、原话要点 | 使用习惯、协作痛点、隐性约束类 |
| 试用记录 | 记录试用环境、操作步骤、实际结果与预期差异 | 候选工具的能力验证类 |
定义结论分级与判定门槛
结论统一为四类，判定门槛写进口径说明：已满足指能力项在约定条件下可完整实现且有证据；部分满足指主体能力可用但存在明确缺口，必须写明缺口部分和影响范围；不满足指能力缺失或实现方式与要求冲突；待验证指现有证据不足以判断，必须挂验证计划和责任人。四类之外不设“基本满足”“差不多”等模糊档位，也不允许用分数替代分级。
证据还要标注时效与版本。截图和录屏对应的是采集当时的系统状态，工具升级或配置调整后可能失效，因此每条证据记录采集日期和版本号；跨版本比对时，旧证据只能作为历史参考，结论需重新确认。
建立现状清单与目标清单
两份清单是比对的输入，必须使用同一套字段和同一粒度，否则逐项比对时会出现“现状按功能列、目标按场景列”的错位。
现状清单：从现有工具和实际使用中提取
现状清单回答“今天团队实际怎么用”。来源包括现有工具的配置导出（工作流、字段、权限、通知规则）、团队访谈、历史工单与使用记录。填写时以实际使用为准，不以工具文档宣称的能力为准：某个字段存在但没人用，现状应记为“已配置、低频使用”，并在约束条件里注明。
目标清单：从业务需求和约束中推导
目标清单回答“替换后必须达到什么”。来源包括业务方的流程要求、研发管理规范、合规与审计要求、与周边系统的集成约束。目标项同样写成可判断的陈述，并标注优先级：必须满足、应当满足、可选。优先级决定后续差距的处置方式，必须满足项出现不满足时，替换方案需要调整或补充替代手段。
两份清单共用的字段
| 字段 | 填写说明 | 示例 |
|---|---|---|
| 域 | 需求、测试、缺陷、知识等 | 缺陷 |
| 能力项 | 可判断的陈述句 | 缺陷可从测试用例一键创建并关联原用例 |
| 使用角色 | 主要操作该能力的角色 | 测试工程师 |
| 频率 | 高/中/低，或按次/日、次/周描述 | 高，每日多次 |
| 约束条件 | 版本、权限、集成、合规等前提 | 需与需求条目双向关联 |
目标清单中出现无法确认的条目时，不要凭推测填写。处理方式是先标记为“待确认”，写明需要谁确认、通过什么方式确认（访谈、试用、厂商文档），确认后再进入比对；在确认前，该条目对应的差距结论只能记为待验证。
逐项比对并记录证据的表格怎么填
差距记录表是整项工作的核心交付物，原则是一条记录只承载一个能力项的判断，结论与证据编号绑定在同一行，任何人拿到表都能顺着编号找到原始证据。
记录表字段
| 字段 | 填写要求 |
|---|---|
| 编号 | 按域加序号，如 DEF-012，全表唯一 |
| 域 | 与两份清单一致 |
| 能力项 | 直接引用清单中的陈述句，不改写 |
| 现状 | 现有工具的实际表现，注明版本 |
| 目标 | 目标清单中的要求及优先级 |
| 差距描述 | 现状与目标的差异，部分满足时写缺口和影响范围 |
| 结论 | 已满足/部分满足/不满足/待验证 |
| 证据编号 | 对应证据库中的编号，至少一条；待验证可暂空但须有验证计划 |
| 证据位置 | 文件路径、页面地址或录屏时间点 |
| 验证人 | 实际核对证据的人 |
| 验证日期 | 证据采集或核对的日期 |
填写中的几个要点
每条结论必须挂至少一条证据，或明确标注待验证并写明验证计划。没有证据支撑的“已满足”在复核时一律退回。
部分满足是最容易写含糊的档位。写法是先写可用部分，再写缺口，最后写影响范围，例如“可从用例创建缺陷并关联，但无法批量关联多个用例，影响回归测试阶段的缺陷归集效率”。影响范围写到角色和场景，便于后续判断这个缺口能否接受。
证据编号与证据库一一对应。证据库可按域建目录，文件名采用“编号_能力项简称_日期”的格式，录屏在记录中注明关键时间点。这样复核人抽查时不必重新走一遍操作，直接定位到证据即可。
差距记录与证据归档需要长期维护时，可以把每条能力项作为工作项管理，证据作为附件或关联文档挂在对应条目下，评审意见留在条目评论中。ONES 的项目工作项与 Wiki 文档可以承载这种“条目加附件加评审记录”的组织方式，便于按编号检索和交接。
角色分工与交付物
比对结果如果只由工具管理员一方拍板，业务方往往不认；如果只由业务方判断，配置和集成类结论又缺少技术依据。建议按下列分工推进，每个角色都有明确的交付物。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 业务或流程负责人 | 确认目标清单、标注优先级、裁定差距是否可接受 | 目标清单及优先级说明 |
| 一线使用者 | 按实际工作方式演示现状操作，提供截图、录屏和访谈记录 | 现状证据及使用说明 |
| 工具管理员或技术负责人 | 导出配置、验证集成与权限类证据、核对候选工具试用结果 | 配置导出件、试用记录、技术验证结论 |
| 复核人 | 抽查结论与证据一致性，检查分级是否统一 | 复核意见与退回清单 |
复核建议按比例抽查，重点覆盖“已满足”和“部分满足”两类结论，以及所有必须满足项。复核人发现证据与结论不符时，退回给验证人补充证据或调整结论，并在记录中保留退回原因，形成可追溯的修订痕迹。
一个完整示例：缺陷域的一条差距记录
以下为演示情景，用于说明填写方式，数据为示例值。
能力项：缺陷可从测试用例一键创建并关联原用例，关联关系在需求追溯中可见。
现状：现有工具支持从用例创建缺陷，但关联关系仅在缺陷详情页显示，需求追溯视图不展示。版本为当前在用版本，采集日期为比对启动当月。
目标：测试执行失败后一键创建缺陷并自动关联用例，需求追溯中可查看缺陷分布。优先级为必须满足。
证据采集：由测试工程师在测试环境完整操作一遍，录屏保存从用例执行失败到缺陷创建成功的全过程；工具管理员导出缺陷与用例的关联字段配置。录屏和配置导出件存入证据库，编号 DEF-EV-007，记录中注明录屏关键时间点。
结论判定：一键创建与关联可用，追溯视图缺失，判定为部分满足。差距描述写为“可从用例创建缺陷并关联，需求追溯视图不展示缺陷分布，影响需求负责人评估测试覆盖时的判断效率”。
复核意见：复核人核对录屏与配置导出件，确认关联字段存在、追溯视图确未展示，结论维持部分满足；要求补充一条候选工具试用记录，验证追溯视图是否可配置实现。
后续动作：由工具管理员在试用环境中验证追溯视图配置，验证完成后更新证据编号与结论；若仍不满足，提交业务负责人裁定该缺口是否影响替换决策。
完成检查：证据记录是否可用
在把差距记录提交给决策层之前，逐条核对以下清单。全部通过，记录才具备支撑替换决策的基础。
- 每条结论都能回溯到至少一条证据，或标注待验证并附验证计划与责任人。
- 每条证据标注了版本与采集时间，跨版本引用的旧证据已注明需重新确认。
- 部分满足的记录写清了缺口部分和影响范围，影响范围落到角色和场景。
- 待验证项列明了验证方式、验证人和完成时间。
- 结论分级统一使用四类，没有混入分数或“基本满足”等模糊表述。
- 记录覆盖了需求、测试、缺陷、知识等约定域，且与两份清单的能力项一一对应。
- 证据编号与证据库文件一一对应，抽查任意编号都能定位到原始材料。
- 复核意见与退回原因已保留，修订痕迹可追溯。
检查中发现的问题按类型处理：证据缺失的退回验证人补充；结论与证据不符的由复核人裁定；覆盖不全的回到清单阶段补齐能力项。完成检查通过后，差距记录表连同证据库一并归档，作为替换方案评审和后续验收的对照基线。
常见问题
能力项拆到多细比较合适，拆粗拆细各有什么问题？
建议以“一个角色完成一个动作”为粒度。拆得过粗，一条记录里混着多个判断，结论只能写“部分满足”却说不清缺在哪；拆得过细，记录数量膨胀，复核成本上升。实际操作中可以先按角色主任务列一遍，再合并明显重复的条目，最后检查每条能力项是否能写成一句可判断真假的陈述。
目标清单里有条目暂时无法确认，比对还能继续吗？
可以继续，但该条目对应的差距结论只能记为待验证。处理方式是先标记“待确认”，写明需要谁确认、通过访谈、试用还是厂商文档确认，确认后再进入比对。不要凭推测把目标项填成确定值，否则后续结论会建立在假设上。
证据采集后工具升级了，旧截图还能用吗？
旧证据只能作为历史参考，结论需要重新确认。每条证据都应记录采集日期和版本号，跨版本比对时，复核人应要求验证人按当前版本重新采集关键证据，或在记录中注明该结论基于旧版本、待新版本复核。
部分满足的结论怎么写才不会被复核退回？
按“可用部分、缺口部分、影响范围”三段写。先写现有工具能实现什么，再写缺什么，最后写缺口影响哪个角色、哪个场景，例如“可从用例创建缺陷并关联，但无法批量关联多个用例，影响回归测试阶段的缺陷归集效率”。影响范围落到角色和场景，业务方才好判断这个缺口能否接受。
差距记录和证据文件用什么方式归档便于长期维护？
可以把每条能力项作为工作项管理，证据作为附件或关联文档挂在对应条目下，评审意见留在条目评论中，按编号即可检索和交接。ONES 的项目工作项与 Wiki 文档可以承载这种“条目加附件加评审记录”的组织方式。证据库按域建目录，文件名采用“编号_能力项简称_日期”格式，录屏在记录中注明关键时间点。
