插件替代能力清单是一张按“插件—原使用行为—替代承载方式—验证证据”逐项记录的对照表，核心信息包括插件名称与用途、使用角色与频次、触发的具体行为、原依赖的接口或扩展点、目标平台的替代承载方式、能力差距、验证方法与结论、负责人与截止时间。本文直接给出一张可复制的空白表，并配套字段说明、必填判定、完整填写示例与维护规则；清单只回答“行为能否被承接、如何验证”，数据搬运记录和目标平台日常配置分别归其他主题。清单落地时，可用ONES的工作项与文档能力承载记录、状态流转和复核。
要点总览（TL;DR）
- 清单按“插件—原使用行为—替代承载方式—验证证据”逐项记录，一行对应一个插件下的一项可独立验证的操作。
- 核心字段分四类：插件与用途、行为与依赖、替代承载与差距、验证与责任，模板、字段说明与示例使用同一套字段名。
- 必填判定以“能否进入验证”为标准，缺少插件名称、触发行为、替代承载方式、验证方法、负责人或截止时间的行停留在待补充状态。
- 填写时把触发行为写到操作与对象，把验证方法写到样例数量与判定标准，验证结论用判定词加一句依据。
- 清单随迁移批次更新，按团队规模裁剪字段，状态按“待梳理—待验证—验证中—已结论—已归档”流转，并定期复核归档。
可复制空白模板：插件替代能力清单表
下表可直接复制到电子表格工具中使用。行结构按“一个插件下的一项具体行为”拆分：同一插件有多项行为时占多行，插件名称与用途列重复填写，便于逐条验证、逐条关闭。表头下方保留两行空白示例行，填写时替换为实际内容即可。
| 序号 | 插件名称 | 插件用途 | 使用角色 | 使用频次 | 触发行为 | 原依赖接口/扩展点 | 替代承载方式 | 能力差距 | 验证方法 | 验证结论 | 负责人 | 截止时间 | 状态 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | ||||||||||||||
| 2 |
纯文本版本便于粘贴到在线文档或工单系统中，字段顺序与上表一致：
序号 | 插件名称 | 插件用途 | 使用角色 | 使用频次 | 触发行为 | 原依赖接口/扩展点 | 替代承载方式 | 能力差距 | 验证方法 | 验证结论 | 负责人 | 截止时间 | 状态 | 备注
1 | | | | | | | | | | | | | |
2 | | | | | | | | | | | | | |
如果团队已有插件使用台账，可先按插件逐条导入，再拆分为行为行；拆分标准是“一次可独立验证的操作”。例如同一插件同时承担“自动生成周报”和“同步外部工单”两项行为，应拆成两行分别填写替代方式与验证结论。
字段说明：每一列记录什么、怎么填
字段说明与上表使用同一套字段名，按四类组织：插件与用途、行为与依赖、替代承载与差距、验证与责任。填写口径统一为“可观察、可复核”，避免写入主观评价。
| 字段名 | 含义 | 填写口径 |
|---|---|---|
| 序号 | 行标识 | 按插件分组连续编号，便于引用与讨论 |
| 插件名称 | 被评估的插件 | 填写插件正式名称；同一插件多行时名称保持一致 |
| 插件用途 | 插件解决什么问题 | 用一句话描述业务目的，例如“按模板批量生成周报” |
| 使用角色 | 实际使用该插件的人或岗位 | 填写角色或团队名，不写个人姓名以外的隐私信息 |
| 使用频次 | 行为发生的频率 | 按日、周、月或“每次发布时”等可核对口径填写 |
| 触发行为 | 用户实际执行的具体操作 | 写动作与对象，例如“在需求页点击按钮生成周报文档” |
| 原依赖接口/扩展点 | 插件依赖的平台接口、事件或扩展机制 | 记录插件调用的接口、Webhook、自定义字段或脚本入口；不清楚时标注“待查证” |
| 替代承载方式 | 目标平台上承接该行为的标准能力或开放能力 | 写明具体能力与配置位置，例如“流程自动化规则+文档模板”；无对应能力时写“暂无对应，需评估” |
| 能力差距 | 替代方式与原行为之间的差异 | 描述差异点及影响，例如“缺少批量导出，需逐条操作”；无差距时写“无” |
| 验证方法 | 如何证明行为被承接 | 写可执行的验证步骤与判定标准，例如“用10条样例数据跑通并核对输出字段” |
| 验证结论 | 验证后的判定 | 填写“通过”“有条件通过”“不通过”或“待验证”，并附一句依据 |
| 负责人 | 对该行验证负责的人 | 填写具体责任人，便于跟进 |
| 截止时间 | 完成验证的时间点 | 填写日期，与迁移计划节点对齐 |
| 状态 | 该行的处理阶段 | 按“待梳理—待验证—验证中—已结论—已归档”填写 |
| 备注 | 补充信息 | 记录待查证事项、依赖条件或相关链接编号 |
“替代承载方式”一列需要写到可操作的程度。只写“用平台标准功能替代”无法支撑验证，应写明具体能力名称、配置位置和触发条件，让验证人能够按描述复现。能力差距一列同样要落到影响上，说明差异会导致哪些操作变化、需要多少额外人工步骤。
必填与选填：哪些字段缺失就不能进入验证
必填判定以“能否进入验证”为标准：缺少任一必填字段的行停留在“待梳理”状态，不进入验证环节，避免用不完整信息得出替代结论。选填字段缺失不影响验证启动，但会影响后续追溯与统计。
| 字段名 | 判定 | 理由或触发条件 |
|---|---|---|
| 插件名称 | 必填 | 行标识的基础，缺失则无法定位评估对象 |
| 插件用途 | 必填 | 判断替代是否满足业务目的的前提 |
| 触发行为 | 必填 | 清单验证的对象，缺失则无法设计验证步骤 |
| 替代承载方式 | 必填 | 没有承接方案就无从验证；确无对应能力时填“暂无对应，需评估” |
| 验证方法 | 必填 | 决定验证能否执行与复核 |
| 验证结论 | 条件必填 | 状态进入“已结论”时必填，且需附依据 |
| 负责人 | 必填 | 保证验证有人推进 |
| 截止时间 | 必填 | 与迁移计划对齐，缺失则无法排期 |
| 原依赖接口/扩展点 | 条件必填 | 涉及自定义脚本、Webhook或非标准扩展时必填；纯界面操作类插件可标注“无” |
| 能力差距 | 条件必填 | 替代方式与原行为不完全一致时必填；完全一致时填“无” |
| 使用角色 | 选填 | 影响范围评估时建议填写 |
| 使用频次 | 选填 | 用于排优先级，缺失不阻断验证 |
| 状态 | 选填 | 由流程自动维护时可省略手工填写 |
| 备注 | 选填 | 用于记录待查证事项与依赖 |
字段缺失时的处理规则：必填缺失的行标记为“待补充”，由负责人补齐后再流转；条件必填在触发条件成立时按必填处理，未成立时填写“无”或“不适用”，不留空；选填字段留空即可，不用“未知”占位。对于暂时无法确认的接口或版本信息，在备注中写明“待查证”及查证方式，不把推测写成结论。
填写示例：一条插件行为从记录到验证结论
以下为演示情景，用于说明字段填写方式，不代表任何真实插件或真实迁移结论。示例插件名为虚构名称“周报生成助手”，目标平台以通用表述“目标平台”指代。
| 字段名 | 填写内容 |
|---|---|
| 序号 | 1 |
| 插件名称 | 周报生成助手（演示） |
| 插件用途 | 按固定模板汇总本周需求进展并生成周报文档 |
| 使用角色 | 项目经理 |
| 使用频次 | 每周一次 |
| 触发行为 | 在项目页点击“生成周报”，选择时间范围后输出文档并附到项目空间 |
| 原依赖接口/扩展点 | 调用项目查询接口读取需求状态，通过文档接口写入附件（接口明细待查证） |
| 替代承载方式 | 用流程自动化按周汇总需求状态，配合文档模板生成周报并归档到项目文档库 |
| 能力差距 | 原插件支持一键生成并自动附到项目空间；替代方案需先配置自动化规则，首次配置约需半天，之后每周自动执行 |
| 验证方法 | 选取一个进行中的项目，配置规则后连续运行两周，核对周报中的需求条数、状态分布与手工统计一致，并确认文档归档位置正确 |
| 验证结论 | 有条件通过：两周输出与手工统计一致，归档位置正确；首次配置成本需计入迁移计划 |
| 负责人 | 项目经理A |
| 截止时间 | 迁移计划第二周周五 |
| 状态 | 已结论 |
| 备注 | 接口明细待查证；若后续需要按团队维度拆分周报，需补充验证 |
这条示例体现了三条填写规范：触发行为写到操作与对象，验证方法写到样例数量与判定标准，验证结论给出判定词加一句依据。能力差距没有写成“功能缺失”，而是说明差异带来的操作变化和配置成本，便于迁移计划评估工作量。示例中的“待查证”标注保留了不确定性，没有把未核实的信息写成结论。
调整与维护方法：清单如何随迁移推进更新
清单在迁移期间是动态文档，需要按团队规模和推进节奏裁剪字段、流转状态并定期复核。以下规则可按实际情况取用。
按团队规模裁剪字段
- 小型团队（插件数量少、使用人集中）：保留必填字段加“能力差距”“备注”，合并“使用角色”与“使用频次”为一列“使用情况”，减少填写负担。
- 中型团队（多团队共用插件）：保留全部必填与条件必填字段，增加“所属团队”列，便于按团队汇总验证进度。
- 大型组织（插件多、定制场景多）：在模板基础上增加“关联迁移批次”“依赖系统”两列，与迁移计划批次对齐，避免清单与计划脱节。
状态流转与更新节奏
状态按“待梳理—待验证—验证中—已结论—已归档”流转。待梳理行补齐必填字段后进入待验证；负责人开始执行验证方法时改为验证中；得出判定后改为已结论并填写验证结论；迁移完成且无后续依赖时归档。更新节奏建议与迁移批次同步：每批次开始前复核待验证行，批次结束前完成已结论行的归档，验证中发现的新行为及时补行。
复核与归档规则
- 每周复核一次“验证中”行，超过截止时间未结论的行在备注中说明原因并调整时间。
- “已结论”行需有验证方法与结论两项内容，缺一不可；结论为“不通过”的行转入替代方案再评估，不直接关闭。
- 归档时保留原始字段内容，不删除历史行；后续插件版本变化时新增行记录，不覆盖旧结论。
清单与其他迁移记录的边界
本清单只记录插件行为能否被承接以及如何验证。插件数据的实际搬运与字段映射记录在数据迁移与映射文档中；目标平台的日常配置与治理操作记录在平台配置治理文档中；具体插件的兼容版本、价格与认证结论不在本清单内下结论，只在备注中记录查证方式与待查事项。三类记录通过序号或批次编号互相引用，避免同一信息在多处重复维护。
清单落地时，可将每一行作为ONES工作项管理，用状态字段驱动流转，用文档页面保存字段说明与验证记录；涉及流程自动化与开放能力的替代方案，可在对应工作项中记录配置位置与验证证据，便于复核时追溯。
常见问题
插件替代能力清单和插件使用台账有什么区别？
插件使用台账回答“团队在用哪些插件”，通常一个插件一行；替代能力清单回答“这个插件的每项行为能否被承接、如何验证”，按行为拆行。已有台账时，可以先按插件导入，再把同一插件下的多项行为拆成多行，拆分标准是一次可独立验证的操作。这样同一插件可能占多行，插件名称与用途列重复填写，验证结论也各自独立。
清单里“替代承载方式”一列写到什么程度才算可验证？
写到验证人能够按描述复现即可。需要写明具体能力名称、配置位置和触发条件，例如“用流程自动化按周汇总需求状态，配合文档模板生成周报并归档到项目文档库”。只写“用平台标准功能替代”无法支撑验证。确无对应能力时填“暂无对应，需评估”，让这一行进入再评估流程，避免留空。
验证结论为“不通过”的行应该怎么处理？
不直接关闭，转入替代方案再评估。可以在同一行更新替代承载方式与验证方法后重新验证，也可以拆出新行记录备选方案，原行保留历史结论。归档时保留原始字段内容，不删除历史行；后续插件版本变化时新增行记录，不覆盖旧结论，便于追溯当时的判断依据。
清单里的接口、版本信息暂时查不到怎么办？
在备注中写明“待查证”及查证方式，不把推测写成结论。原依赖接口/扩展点属于条件必填，涉及自定义脚本、Webhook 或非标准扩展时必须填写；暂时无法确认接口明细时，先记录已知的调用关系，把待查事项挂在备注里。具体插件的兼容版本、价格与认证结论不在本清单内下结论，只记录查证方式与待查事项。
清单落地时用什么工具承载比较合适？
取决于团队已有的协作工具和迁移节奏。若迁移本身在项目管理平台中推进，可以把每一行作为工作项管理，用状态字段驱动流转，用文档页面保存字段说明与验证记录。ONES 的工作项与文档能力可以承载这类记录、状态流转和复核；涉及流程自动化与开放能力的替代方案，可在对应工作项中记录配置位置与验证证据，便于复核时追溯。团队规模小、插件数量少时，用电子表格维护也能满足要求。
