AI风险提示核验记录表用于把AI给出的风险提示转成可追溯、可判断、可处置的记录。建议以“一条提示一行记录”为基本单位，至少覆盖提示来源与原文、关联项目与工作项、核验人与时间、核验方式与证据、核验结论、风险等级与影响、处置动作与责任人、反馈对象与关闭状态八类信息。下面给出可直接复制的空白表、字段说明、必填划分、填写示例与维护方法。
要点总览（TL;DR）
- 核验记录表以“一条提示一行记录”为单位，覆盖提示来源与原文、关联项目与工作项、核验人与时间、核验方式与证据、核验结论、风险等级与影响、处置动作与责任人、反馈对象与关闭状态八类信息。
- 最小可用字段集为记录编号、提示原文、关联项目、核验人、核验时间、核验结论、风险等级、处置动作、责任人、关闭状态十项，其余字段按风险等级补充。
- 高风险提示要求关联工作项、证据链接、影响范围、截止时间与反馈对象全部填写；中风险提示要求证据链接与截止时间；低风险提示可只填最小字段集。
- 向项目组反馈时可直接引用记录编号与关键字段，把提示、判断、证据和动作放在同一段表述中。
- 模板投入使用后，按“是否影响核验判断、是否已有字段承载、是否有人维护”三条标准增删字段，并定期抽查证据链接与结论一致性。
可复制空白核验记录表
将下表复制到表格工具或文档中即可使用。表头行保持固定，每条AI风险提示新增一行。记录编号建议采用“项目缩写-年月-序号”的格式，例如“CRM-202506-001”，便于检索和引用。版本标识行用于标注模板版本与修订日期，避免不同项目使用不同口径的表单。
| 记录编号 | 模板版本 | 提示来源 | 提示原文 | 生成时间 | 模型或工具标识 | 关联项目 | 关联工作项 | 关联里程碑 | 关联风险条目 | 核验人 | 核验时间 | 核验方式 | 证据链接 | 核验结论 | 风险等级 | 影响范围 | 置信度 | 处置动作 | 责任人 | 截止时间 | 反馈对象 | 关闭状态 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
配套的核验清单用于逐条确认核验动作是否完成。清单可以放在主表下方，也可以作为独立页签，按记录编号关联。
| 核验动作 | 完成情况 | 备注 |
|---|---|---|
| 已核对提示原文与原始输出，确认无截断或转述偏差 | □ 是 □ 否 | |
| 已定位提示涉及的项目、工作项或里程碑 | □ 是 □ 否 | |
| 已查阅支撑证据（数据、文档、会议记录、系统状态） | □ 是 □ 否 | |
| 已判断提示属于真实风险、误报或信息不足 | □ 是 □ 否 | |
| 已评估风险等级与影响范围 | □ 是 □ 否 | |
| 已明确处置动作、责任人与截止时间 | □ 是 □ 否 | |
| 已向反馈对象同步核验结论 | □ 是 □ 否 | |
| 已确认关闭条件满足并更新关闭状态 | □ 是 □ 否 |
字段说明：每个字段记录什么
字段说明的作用是统一口径。同一个列名在不同人手里容易填出不同含义，例如“置信度”可能被理解为AI输出的置信度，也可能被理解为核验人对结论的把握程度。下表逐字段说明填写内容与示例方向，团队可据此在表头添加批注。
| 字段 | 记录什么 | 填写示例方向 |
|---|---|---|
| 记录编号 | 本条记录的唯一标识，按团队约定格式生成 | CRM-202506-001 |
| 模板版本 | 当前使用的记录表版本与修订日期 | v1.2，2025-06修订 |
| 提示来源 | 提示产生的渠道，如项目周报分析、风险扫描、会议纪要整理、人工提问 | 迭代风险扫描 |
| 提示原文 | AI输出的原始表述，保留完整句子，不改写 | “支付模块联调进度落后计划3天，可能影响上线” |
| 生成时间 | 提示产生的时间，精确到日期即可，必要时到小时 | 2025-06-12 10:30 |
| 模型或工具标识 | 产生提示的AI工具名称与版本或配置标识 | 团队内部助手，默认配置 |
| 关联项目 | 提示所属项目名称或编号 | 客户管理系统二期 |
| 关联工作项 | 提示指向的具体任务、缺陷或需求编号 | 任务-支付联调-018 |
| 关联里程碑 | 受影响或相关的里程碑节点 | 6月30日上线评审 |
| 关联风险条目 | 若已登记在风险清单中，填写对应风险编号；未登记则留空待建 | RISK-042 |
| 核验人 | 实际执行核验的人员姓名 | 项目跟踪负责人 |
| 核验时间 | 完成核验的日期 | 2025-06-12 |
| 核验方式 | 采用的核验手段，如查阅系统状态、比对计划与实际、访谈责任人、查看文档 | 比对迭代燃尽图与联调记录 |
| 证据链接 | 支撑结论的文档、页面、报表或记录位置 | 迭代看板链接、联调日志页面 |
| 核验结论 | 对提示的判断，建议使用固定选项：属实、部分属实、误报、信息不足待补充 | 属实 |
| 风险等级 | 按团队风险标准划分，如高、中、低 | 中 |
| 影响范围 | 受影响的范围，如进度、成本、质量、范围、干系人 | 上线时间与测试窗口 |
| 置信度 | 核验人对本条结论的把握程度，建议用高、中、低三档，并注明依据是否充分 | 高，有系统记录支撑 |
| 处置动作 | 针对该风险采取的具体动作，如调整排期、增加人力、拆分任务、持续观察 | 调整联调排期并增加一名后端支持 |
| 责任人 | 负责执行处置动作的人员 | 后端负责人 |
| 截止时间 | 处置动作的完成期限 | 2025-06-16 |
| 反馈对象 | 需要知悉核验结论的人员或群体，如项目经理、项目组例会、干系人 | 项目经理与项目周会 |
| 关闭状态 | 记录当前所处状态，建议使用固定选项：待核验、核验中、已反馈、处置中、已关闭、已转风险清单 | 处置中 |
提示类字段需要保留原文，原因是核验结论要与原始表述对应，避免后续复盘时只看到结论而无法判断当时的提示是否准确。关联类字段把提示落到具体项目对象上，使记录能够进入项目跟踪流程，而不是停留在独立表格中。核验类与结论类字段共同构成判断依据，处置类与反馈类字段则保证结论有人接、有回音。
必填与选填的划分
人力有限时，记录表仍要能运转。最小可用字段集建议为：记录编号、提示原文、关联项目、核验人、核验时间、核验结论、风险等级、处置动作、责任人、关闭状态。这十项保证每条提示可识别、可判断、有人负责、有状态可查。其余字段按风险等级和场景补充。
| 字段 | 建议 | 理由或适用场景 |
|---|---|---|
| 记录编号、提示原文、关联项目、核验人、核验时间、核验结论、风险等级、处置动作、责任人、关闭状态 | 必填 | 缺少任一项，记录无法追溯或无法推动处置 |
| 提示来源、生成时间、模型或工具标识 | 建议必填 | 用于判断提示的可信背景；批量扫描场景下可统一填写 |
| 关联工作项、关联里程碑 | 高风险必填，低风险选填 | 高风险提示需要精确落到执行对象；低风险观察项可只关联项目 |
| 关联风险条目 | 转正式风险时必填 | 提示升级为登记风险后，需与风险清单建立对应关系 |
| 核验方式、证据链接 | 高风险必填，中低风险建议填写 | 高风险结论需要可复核；低风险可简要说明核验途径 |
| 影响范围、置信度 | 中高风险必填 | 影响范围决定处置优先级；置信度提示结论的可靠程度 |
| 截止时间、反馈对象 | 进入处置阶段必填 | 没有期限和反馈对象的处置动作容易悬空 |
| 模板版本 | 选填 | 多项目共用同一模板时建议填写，便于版本追溯 |
按风险等级调整必填范围时，可采用这样的规则：高风险提示要求关联工作项、证据链接、影响范围、截止时间与反馈对象全部填写；中风险提示要求证据链接与截止时间；低风险提示允许只填最小字段集，并在备注中说明观察理由。规则一旦确定，应写入模板说明，避免同一等级在不同项目中执行不一致。
填写示例：一条完整核验记录
以下为演示情景，用于说明字段之间的对应关系，不代表真实项目数据。假设某项目在迭代风险扫描中得到一条提示，项目跟踪负责人完成核验并向项目组反馈。
| 字段 | 填写内容 |
|---|---|
| 记录编号 | CRM-202506-001 |
| 模板版本 | v1.2，2025-06修订 |
| 提示来源 | 迭代风险扫描 |
| 提示原文 | “支付模块联调进度落后计划3天，可能影响6月30日上线评审。” |
| 生成时间 | 2025-06-12 10:30 |
| 模型或工具标识 | 团队内部助手，默认配置 |
| 关联项目 | 客户管理系统二期 |
| 关联工作项 | 任务-支付联调-018 |
| 关联里程碑 | 6月30日上线评审 |
| 关联风险条目 | RISK-042 |
| 核验人 | 项目跟踪负责人 |
| 核验时间 | 2025-06-12 |
| 核验方式 | 比对迭代燃尽图、联调记录与任务状态，访谈后端负责人 |
| 证据链接 | 迭代看板页面、联调日志页面、6月11日站会记录 |
| 核验结论 | 属实 |
| 风险等级 | 中 |
| 影响范围 | 上线评审时间与测试窗口 |
| 置信度 | 高，有系统记录与责任人确认 |
| 处置动作 | 调整联调排期，增加一名后端支持，6月16日前完成支付主流程联调 |
| 责任人 | 后端负责人 |
| 截止时间 | 2025-06-16 |
| 反馈对象 | 项目经理与项目周会 |
| 关闭状态 | 处置中 |
这条记录中，核验结论“属实”对应证据链接中的燃尽图与联调记录；风险等级“中”对应影响范围限于上线评审时间，未波及合同交付；处置动作与截止时间对应责任人的承诺。向项目组反馈时，可直接引用记录编号与关键字段，例如：“CRM-202506-001核验结论为属实，支付联调落后约3天，影响6月30日上线评审，已安排增加后端支持，6月16日前完成主流程联调，由后端负责人跟进。”这样的表述把提示、判断、证据和动作放在同一段里，项目组成员无需再翻原始输出。
当核验结论为“误报”时，记录仍需保留，并在处置动作中写明误报原因与后续观察方式，关闭状态可填“已关闭”。当结论为“信息不足待补充”时，应明确补充责任人与补充期限，关闭状态填“核验中”，避免记录长期停留在待核验状态。
调整与维护方法
模板投入使用后，字段会随项目类型和AI工具变化而增减。判断是否新增字段的标准可以归纳为三条：该信息是否影响核验结论的判断；是否已有其他字段可以承载；新增后是否有人实际填写和维护。满足第一条且不满足第二条的，才考虑新增。删除字段时，先确认连续两个抽查周期内该字段填写率低且未被任何反馈引用，再合并或移除。
记录归档建议按项目或季度分批保存，保留周期由团队合规要求与项目复盘需要决定。一般项目可在结项后保留至下次同类项目复盘结束；涉及合同交付或审计要求的项目，按约定周期延长。归档时保留模板版本号，确保历史记录可读。
定期抽查核验质量可采用抽样方式：每两周抽取若干条记录，检查证据链接是否可打开、核验结论与证据是否一致、处置动作是否有责任人和期限、关闭状态是否与实际进展相符。抽查结果不必逐条通报，可在项目例会上说明共性问题和改进口径。
与项目状态跟踪流程衔接时，建议把核验记录中的关联工作项、风险条目和关闭状态作为同步点：核验结论为属实的提示，进入风险清单或工作项备注；处置中的记录，在项目周报中体现进展；已关闭的记录，在里程碑评审时作为输入之一。若团队使用ONES承载项目跟踪，可将核验结论保存为工作项或Wiki页面，并借助ONES Assistant理解项目、工作项、迭代和Wiki页面等上下文，减少在记录表与项目页面之间反复补充背景；在权限体系配置前提下，相关输出过程可追踪、结果可审计。这样记录表负责留痕与反馈，项目工具负责状态流转，两者通过记录编号和关联字段对应起来。
常见问题
核验记录表中的“置信度”字段，应该填AI输出的置信度还是核验人的把握程度？
建议填写核验人对本条结论的把握程度，用高、中、低三档表示，并简要注明依据是否充分。例如“高，有系统记录与责任人确认”。这样填写与核验结论、证据链接形成对应关系，便于后续复核时判断结论的可靠程度。如果团队希望同时记录AI输出的置信度，可以在提示类字段中单独增加一列，避免与核验判断混用。
低风险提示是否也需要走完整的核验记录流程？
低风险提示可以简化记录，但仍建议保留最小字段集：记录编号、提示原文、关联项目、核验人、核验时间、核验结论、风险等级、处置动作、责任人、关闭状态。关联工作项、证据链接、影响范围等字段可按需填写，并在备注中说明观察理由。简化不等于不记录，保留最小字段集可以保证每条提示可追溯、有状态可查，避免低风险提示在无人跟进的情况下被遗忘。
核验结论为“误报”或“信息不足待补充”时，记录应该怎么处理？
结论为“误报”时，记录仍需保留，并在处置动作中写明误报原因与后续观察方式，关闭状态可填“已关闭”。结论为“信息不足待补充”时，应明确补充责任人与补充期限，关闭状态填“核验中”，避免记录长期停留在待核验状态。两类记录都建议在项目例会上简要说明，帮助团队了解AI提示的准确性和信息缺口。
核验记录表如何与项目现有的风险清单或工作项跟踪衔接？
建议把核验记录中的关联工作项、关联风险条目和关闭状态作为同步点：核验结论为属实的提示，进入风险清单或工作项备注；处置中的记录，在项目周报中体现进展；已关闭的记录，在里程碑评审时作为输入之一。若团队使用ONES承载项目跟踪，可将核验结论保存为工作项或Wiki页面，并借助ONES Assistant理解项目、工作项、迭代和Wiki页面等上下文，减少在记录表与项目页面之间反复补充背景；在权限体系配置前提下，相关输出过程可追踪、结果可审计。记录表负责留痕与反馈，项目工具负责状态流转，两者通过记录编号和关联字段对应起来。
模板使用一段时间后，如何判断某个字段该保留还是删除？
新增字段前先问三个问题：该信息是否影响核验结论的判断；是否已有其他字段可以承载；新增后是否有人实际填写和维护。满足第一条且不满足第二条的，才考虑新增。删除字段时，先确认连续两个抽查周期内该字段填写率低且未被任何反馈引用，再合并或移除。字段调整后应更新模板版本号，并在模板说明中记录变更原因，避免不同项目使用不同口径的表单。
