研发平台选型清单如果只做一次、存成一个静态表格，人员一变动、产品一改版，结论就会过期。更稳妥的做法是把它当作有版本、有负责人、有触发条件的决策台账来维护：先固定字段结构和评分口径，再明确谁提出变更、谁评估、谁批准，最后设定定期复核与事件触发两类更新节奏，每次更新留下变更记录和依据。下面按字段、节奏、角色、示例和检查五个部分展开。
要点总览（TL;DR）
- 把选型清单当作有版本、有负责人、有触发条件的决策台账维护，字段结构固定为需求与场景、候选对象、评估维度与权重、证据来源、结论与状态、负责人、版本与日期七类。
- 更新节奏分两类：按季度或半年定期复核易变字段（价格、版本、认证、集成能力），并在需求变化、候选产品重大变更、合规调整或原结论被推翻时立即触发更新。
- 角色上区分清单负责人、需求方、技术评估角色和决策批准角色，让提变更与批准变更分开，每次更新留下提出人、核实人和批准人的痕迹。
- 每次更新至少完成改字段、写依据、递增版本号、通知使用方四个动作，保证结论可追溯到具体证据和核实日期。
- 用字段完整、口径统一、易变信息有核实日期、变更可追溯、使用方拿到最新版本、过期结论已处理六项检查判断维护是否到位。
清单先定结构：哪些字段决定它能否长期维护
清单能否长期维护，取决于字段是否覆盖“为什么选、选了谁、依据是什么、谁负责、什么时候核实的”。字段分组建议固定为七类，新增候选产品或评估维度时只增加行，不改结构，这样不同批次、不同人填写的清单才能横向比较。
| 字段分组 | 建议字段 | 填写要求 |
|---|---|---|
| 需求与场景 | 需求编号、业务场景、使用角色、约束条件（合规、部署、集成） | 每条需求可追溯到提出方；约束条件写清是硬性要求还是加分项 |
| 候选对象 | 产品名称、厂商、版本或交付形态、适用规模 | 同一候选只出现一次，避免同一产品多行重复评估 |
| 评估维度与权重 | 维度名称、权重、评分标准、满分定义 | 权重合计为100%；每个维度的评分标准写成可判断的描述，而非“好/较好” |
| 证据来源 | 证据类型（演示、文档、试用、客户访谈）、证据位置、核实人、核实日期 | 结论必须挂到具体证据；口头信息标注为待验证 |
| 结论与状态 | 单项得分、加权总分、结论（入选/备选/淘汰）、状态（评估中/已定稿/已失效） | 状态变化要能看出时间点，淘汰项保留原因 |
| 负责人 | 维度负责人、清单负责人 | 每个维度有明确核实人，清单整体有唯一负责人 |
| 版本与日期 | 清单版本号、本次更新日期、下次复核日期 | 版本号随每次定稿递增，日期精确到日 |
其中价格、版本、认证、集成能力属于易变信息，应单独设“核实日期”和“有效期”两列。复核时优先检查这类字段，超过有效期的结论在清单中标注“待复核”，避免被继续当作有效依据使用。
字段口径统一是长期维护的前提。同一维度必须使用同一套评分标准，例如“集成能力”统一按“是否提供开放接口、是否支持单点登录、是否需要额外开发”三档打分，而不是让不同评估人各自理解。权重调整属于口径变更，需要走一次正式更新并记录原因，不能在中途悄悄改动，否则前后批次的分数不可比。
更新节奏怎么定：定期复核与事件触发
清单更新分两类节奏：定期复核解决“信息自然过期”，事件触发解决“条件发生实质变化”。两者检查范围不同，不能互相替代。
定期复核建议按季度或半年执行，具体周期结合研发平台的采购周期和产品迭代速度确定。复核范围以易变字段为主：价格与商务条件、版本与功能变化、认证与合规状态、集成方式是否调整。复核产出是一份复核记录，列明哪些字段已确认、哪些发生变化、哪些需要重新评估，并更新下次复核日期。对于结论未变的候选，只需更新核实日期，不必重算全部评分。
事件触发则在以下情况出现时立即启动更新：
- 业务需求变化，例如新增合规要求、使用范围扩大、部署条件调整；
- 候选产品发生重大变更，例如核心功能下线、交付形态改变、厂商经营状况变化；
- 组织或合规要求调整，例如权限管理、数据留存、审计要求变化；
- 原选型结论被推翻，例如试用中发现关键场景不满足，或实际使用成本明显偏离评估。
每次更新至少完成四个动作：修改受影响字段、写明变更依据、递增版本号、通知清单使用方。四个动作缺一不可，只改表格不写依据，下一次复核时就无法判断这条结论是否仍然成立。
角色与交付物：谁提变更、谁评估、谁批准
清单无人负责就会随人员变动失效，人人可改则会让结论失去可信度。建议区分四类角色，每类角色有明确的输入、动作和交付物。
| 角色 | 输入 | 主要动作 | 交付物 |
|---|---|---|---|
| 清单负责人 | 各角色的变更申请与评估结论 | 维护字段结构与版本，组织复核，归档变更记录 | 最新版清单、变更记录、复核计划 |
| 需求方/业务代表 | 业务场景、使用反馈、约束条件 | 提出需求变化，确认场景约束是否仍然成立 | 需求变更说明、场景确认意见 |
| 技术评估角色 | 产品文档、演示与试用结果、集成测试记录 | 核实能力、集成与兼容信息，标注证据来源与核实日期 | 维度评估记录、证据清单 |
| 决策与批准角色 | 评估结论、变更原因、影响范围 | 确认结论变更与优先级调整，批准定稿 | 批准意见、定稿版本 |
分工的关键是让“提变更”和“批准变更”分开。需求方可以随时提出场景变化，技术评估角色负责把变化转成可核实的证据，清单负责人判断影响哪些字段，决策角色确认是否改变结论。小团队可以一人兼多角，但每次更新仍要写清是谁提出、谁核实、谁批准，保留可追溯的痕迹。
当清单条目较多、参与角色分散时，可以把需求条目、评估任务和评审记录放到研发管理平台中流转。ONES Project 支持编写需求、自定义需求状态与多种属性，并可将需求和相关任务规划至迭代、分配负责人；评估任务可以按维度拆成工作项，状态变化即形成更新记录。ONES Wiki 支持文档关联任务，并可插入 ONES Project 的工作项列表，适合把评估依据与清单条目放在一起维护。多层权限体系可按组织架构、用户组、项目角色分配权限，让需求方、评估人和批准角色各自看到与职责对应的内容。
一次完整更新示例：从触发到定稿
以下为演示情景，用于说明更新流程，不对应具体产品或组织。
触发。某研发团队在季度复核中发现，候选平台A的“单点登录集成”一项原记录为“支持标准协议，无需额外开发”，但厂商近期调整了交付方式，该能力改为需要单独配置。技术评估角色在试用环境中确认了这一变化，提出更新申请。
定位受影响字段。清单负责人核对后确认，受影响的是“集成能力”维度下的单点登录评分、证据来源和结论状态三处，其他维度不受影响，无需全表重算。
补充证据并重算。技术评估角色补充试用记录和厂商说明作为新证据，标注核实日期；按统一评分标准，该项由“无需额外开发”降为“需要额外配置”，该维度得分下调，加权总分相应变化。
| 项目 | 更新前 | 更新后 |
|---|---|---|
| 单点登录评分 | 3（无需额外开发） | 2（需要额外配置） |
| 证据来源 | 厂商文档，核实日期为上一版本 | 试用记录+厂商说明，标注新核实日期 |
| 结论状态 | 入选 | 备选，待评估配置工作量 |
| 清单版本 | V1.2 | V1.3 |
评审与定稿。清单负责人把变更原因、影响范围和重算结果提交决策角色确认；需求方确认该集成要求仍为硬性约束。批准后版本号递增为V1.3，变更记录写明触发原因、修改字段、证据位置和批准人，并通知所有清单使用方。
完成标志。清单状态、证据和结论三者一致：状态显示为“备选”，证据列指向新的试用记录，结论列写明待评估配置工作量，任何使用方都能从当前版本追溯到这次变更的原因。
完成检查：清单维护是否做到位
维护机制是否有效，可以用下面这组检查项逐条核对。建议在每次定稿和每轮复核后各执行一次。
| 检查项 | 核验方式 | 通过标准 |
|---|---|---|
| 字段完整 | 对照字段表逐项检查 | 七类字段均有内容，无空缺的关键结论 |
| 口径统一 | 抽查同一维度不同候选的评分 | 评分依据同一标准，权重合计为100% |
| 易变信息有核实日期 | 检查价格、版本、认证、集成能力字段 | 每项均有核实日期，过期项已标注待复核 |
| 变更可追溯 | 抽查最近若干次变更记录 | 每次变更均有依据、有记录、有批准人 |
| 使用方拿到最新版本 | 核对分发记录或平台中的当前版本 | 使用方访问的版本号与定稿版本一致 |
| 过期结论已处理 | 检查淘汰项和失效项 | 已清理或明确标注失效原因与时间 |
如果清单条目和评审过程已经在研发管理平台中流转，还可以借助统计视图观察更新频率和待复核项数量。ONES Performance 支持对研发过程中产生的数据进行多维度、自定义的分析，并提供多种图表类型，可用于查看评估任务的完成情况和状态分布；其按角色配置读写权限的能力，也有助于让清单相关数据只对相应角色开放。检查中发现的问题应回到对应角色处理，而不是在检查表上直接改结论。
清单维护做到位的最终标志是：任何人拿到当前版本，都能看懂每条结论的依据、核实时间和负责人，并能判断哪些结论仍然有效。做到这一点，清单才能在人员更替和产品变化中持续作为选型决策的依据。
常见问题
清单刚建立时字段很多，团队规模小、评估候选少，是否可以先简化？
可以按评估范围裁剪字段数量，但七类字段分组建议保留，尤其是证据来源、负责人和版本与日期三组。候选少时可以把评估维度合并，权重仍要合计为100%，评分标准仍要写成可判断的描述。简化的是行数和维度数量，不是追溯链条；否则后续增加候选时，前后结论无法比较。
定期复核时发现某候选产品的价格或版本变了，但结论没变，需要走完整更新流程吗？
结论未变时不必重算全部评分，但仍要更新核实日期、写明信息来源，并递增版本号。这样使用方看到的是最新核实过的信息，下次复核也能判断这条结论的有效期从何时起算。只改数字不写来源，会让后续复核无法判断依据是否可靠。
需求方和技术评估角色对同一维度的判断不一致时，清单以谁为准？
以证据为准，不以角色层级为准。技术评估角色负责把能力、集成与兼容信息落到可核实的证据上，需求方负责确认场景约束是否成立。两者冲突时，清单负责人应把分歧记录在案，由决策角色确认是按硬性约束处理还是调整权重。分歧本身也是清单的一部分，写清楚比强行统一更有价值。
清单条目和评审记录分散在多个表格和文档里，怎么保证使用方拿到的是最新版本？
关键是设定唯一的分发入口：清单负责人定稿后只在一个位置发布当前版本，其他副本标注为历史版本或直接归档。如果需求条目、评估任务和评审记录已经在研发管理平台中流转，可以把清单条目与对应工作项关联，状态变化即形成更新记录。ONES Project 支持编写需求、自定义需求状态与多种属性，并可将需求和相关任务规划至迭代、分配负责人；ONES Wiki 支持文档关联任务，并可插入 ONES Project 的工作项列表，便于把评估依据与清单条目放在一起维护。
清单维护了一段时间后，淘汰的候选和过期结论怎么处理？
不建议直接删除。淘汰项保留淘汰原因和时间，过期结论标注失效原因与失效日期，状态改为已失效。这样在新一轮选型时能快速判断某个候选是否值得重新评估，也避免同一产品被重复调研。检查时把过期结论的处理情况作为一项核验内容，确保清单里没有仍被当作有效依据的旧结论。
