AI给出的风险提示往往只有一句话，要变成项目组能复核、能追溯的记录，还需要一张人工核验清单。下面这份模板按“提示信息—AI原始提示与依据—核验过程与证据—核验结论与处置—反馈与留痕”五组字段排列，可直接复制到表格工具中使用，并附字段口径、必填规则、一条完整填写示例和维护方法。
要点总览（TL;DR）
- 清单按“提示信息—AI原始提示与依据—核验过程与证据—核验结论与处置—反馈与留痕”五组字段排列，一行记录一条AI风险提示。
- 最小可用记录保留六个必填列：提示编号、风险描述、AI依据、核验人、核验结论、反馈状态，其余字段按项目需要启用。
- 填写时把AI依据与核验证据分开记录，前者说明AI看到了什么，后者说明人工查到了什么，结论才能被复查。
- 清单需设版本号并定期归档，必填字段只增不减，口径变更单独留说明，跨版本数据分段统计。
- 核验结论登记为工作项、清单沉淀在项目文档中，可让反馈状态与处置动作和实际工作项对应。
可复制空白核验清单模板
下表为空白清单，一行对应一条AI风险提示。字段顺序按核验动作推进：先登记提示来源，再记录AI原话与依据，随后填写人工核查过程，最后落结论和反馈。复制到电子表格后，建议冻结表头，并为“提示编号”设置唯一性校验。
| 提示编号 | 提示日期 | 来源工具/场景 | 关联项目 | 关联工作项 | 风险描述 | AI原始提示 | AI依据 | 初判等级 | 核验人 | 核验日期 | 核验方式 | 核验证据 | 核验结论 | 实际等级 | 处置动作 | 责任人 | 反馈对象 | 反馈状态 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
如果项目只需要最小可用记录，可先保留“提示编号、风险描述、AI依据、核验人、核验结论、反馈状态”六个必填列，其余列按需启用，具体取舍见第三节。表格中的“初判等级”指AI提示给出的严重程度，“实际等级”指人工核验后的判断，两列分开记录，便于后续比较AI提示与人工判断的差异。
每个字段记录什么：字段说明
字段口径统一，不同核验人填出的记录才能横向比较。下面按五组字段说明含义和填写要求，填写时以“让未参与核验的人能看懂并复查”为标准。
提示基本信息类字段
| 字段名 | 含义 | 填写口径 |
|---|---|---|
| 提示编号 | 该条风险提示的唯一标识 | 建议采用“项目缩写-日期-序号”，如 PRJ-0612-01；全表不重复 |
| 提示日期 | AI给出提示的日期 | 填写到日；同日多条按编号区分 |
| 来源工具/场景 | 提示由哪个AI工具或哪类分析场景产生 | 写工具名称加场景，如“项目助手-进度分析”；便于回溯原始输出 |
| 关联项目 | 提示指向的项目 | 使用项目正式名称，与项目管理系统中的名称保持一致 |
| 关联工作项 | 提示涉及的具体任务、缺陷或需求 | 填写工作项编号或名称；无法定位到具体工作项时写“项目级” |
AI原始提示与依据类字段
| 字段名 | 含义 | 填写口径 |
|---|---|---|
| 风险描述 | 用一句话概括提示指向的风险 | 写清对象和影响，如“支付模块联调延期，影响版本提测”；避免只写“有风险” |
| AI原始提示 | AI输出的原文或关键原句 | 尽量保留原话，不改写、不删减关键限定词；过长时摘录核心句并注明“摘录” |
| AI依据 | AI作出提示所依据的数据或信息 | 记录AI引用的数据范围，如“近两周迭代燃尽图、3个延期工作项”；AI未说明依据时写“未提供依据”，作为核验重点 |
| 初判等级 | AI提示给出的风险等级 | 按团队统一等级填写（如高/中/低）；AI未分级时留空，不自行补填 |
核验过程与证据类字段
| 字段名 | 含义 | 填写口径 |
|---|---|---|
| 核验人 | 执行人工核验的人员 | 填写真实姓名或工号，便于复查时找到当事人 |
| 核验日期 | 完成核验的日期 | 填写到日；分多次核验时填最后一次 |
| 核验方式 | 人工核查采用的手段 | 写具体动作，如“查看迭代看板与提交记录”“与负责人当面确认”“抽查缺陷单” |
| 核验证据 | 支撑结论的材料出处 | 记录可复查的位置，如工作项编号、文档页面、会议纪要日期；不写“已确认”这类无出处的表述 |
结论与反馈类字段
| 字段名 | 含义 | 填写口径 |
|---|---|---|
| 核验结论 | 人工核验后的判断 | 使用固定选项：属实、部分属实、不属实、无法核验；选“无法核验”时在备注说明原因 |
| 实际等级 | 人工判断的风险等级 | 与初判等级使用同一套等级标准；与初判不一致时在备注简述理由 |
| 处置动作 | 针对该风险采取或计划采取的措施 | 写动作和对象，如“调整排期，将联调顺延两天”；无需处置时写“无需处置” |
| 责任人 | 处置动作的负责人 | 填写具体人员，不写“项目组”等集体称谓 |
| 反馈对象 | 核验结论需要告知的人员或群体 | 写角色加姓名，如“项目经理张某、测试负责人”；按项目沟通机制确定范围 |
| 反馈状态 | 结论是否已传达 | 使用固定选项：未反馈、已反馈、已确认；选“已确认”表示对方已回复收到 |
必填与选填：最小可用记录
必填字段承担“能追溯、能判断、能反馈”三项功能，缺一项，记录就难以支撑后续复查。选填字段用于补充上下文，项目可按提示的重要程度决定是否填写。
| 字段 | 必填/选填 | 理由或适用情形 |
|---|---|---|
| 提示编号 | 必填 | 唯一标识，是追溯和引用该记录的前提 |
| 风险描述 | 必填 | 让人不看原始输出也能知道提示指向什么 |
| AI依据 | 必填 | 区分“有数据支撑的提示”和“无依据的提示”，是核验的起点 |
| 核验人 | 必填 | 明确谁对结论负责，便于复查时追问 |
| 核验结论 | 必填 | 清单的核心产出，没有结论的记录无法反馈 |
| 反馈状态 | 必填 | 证明结论已传达，闭环才算完成 |
| 提示日期 | 选填 | 提示量大、需要按时间排序时建议填写 |
| 来源工具/场景 | 选填 | 使用多个AI工具时建议填写，便于比较不同来源的提示质量 |
| 关联项目、关联工作项 | 选填 | 跨项目汇总时建议填写；单项目使用时可由表格所在位置体现 |
| AI原始提示 | 选填 | 提示原文较长或需要复核AI表述时填写 |
| 初判等级、实际等级 | 选填 | 项目实行风险分级管理时填写，两列配合使用 |
| 核验日期、核验方式、核验证据 | 选填 | 高风险提示或需要审计时建议填写，用于证明核验过程 |
| 处置动作、责任人 | 选填 | 结论为属实或部分属实时建议填写，明确后续动作 |
| 反馈对象 | 选填 | 反馈渠道固定时可省略，由团队约定代替 |
| 备注 | 选填 | 记录等级调整理由、无法核验原因等补充信息 |
只填必填项时，一条记录仍能回答四个问题：提示是什么、AI凭什么提示、谁核验的、结论是否已反馈。若必填项暂时缺失，例如核验人尚未确定，应在备注中写明待补原因和计划补齐时间，并保持反馈状态为“未反馈”，避免记录被误认为已完成。核验结论无法给出时，填“无法核验”并说明卡点，比留空更利于后续跟进。
填写示例：一条完整核验记录
以下为演示情景，用于说明字段如何配合，不代表真实项目案例。
| 字段 | 填写内容 |
|---|---|
| 提示编号 | PAY-0612-01 |
| 提示日期 | 6月12日 |
| 来源工具/场景 | 项目助手-迭代进度分析 |
| 关联项目 | 支付系统二期 |
| 关联工作项 | PAY-318 支付网关联调 |
| 风险描述 | 支付网关联调进度落后，可能影响本迭代提测时间 |
| AI原始提示 | “PAY-318 近五日无状态更新，按当前进度预计延期三天，建议关注提测风险。” |
| AI依据 | 近两周迭代燃尽图、PAY-318 状态变更记录 |
| 初判等级 | 中 |
| 核验人 | 李某 |
| 核验日期 | 6月12日 |
| 核验方式 | 查看工作项评论与代码提交记录，与开发负责人当面确认 |
| 核验证据 | PAY-318 评论区6月10日说明“等待第三方沙箱环境”；提交记录显示联调代码已就绪 |
| 核验结论 | 部分属实 |
| 实际等级 | 低 |
| 处置动作 | 协调第三方于6月13日开通沙箱环境，提测时间不变 |
| 责任人 | 开发负责人王某 |
| 反馈对象 | 项目经理张某、测试负责人赵某 |
| 反馈状态 | 已确认 |
| 备注 | 延期原因在外部依赖，非开发进度问题，故等级由中调为低 |
这条记录中，AI依据指向燃尽图和状态记录，核验证据则落到评论区和提交记录，两者对应但不等同：前者说明AI看到了什么，后者说明人工查到了什么。结论“部分属实”与证据中“代码已就绪、卡在外部环境”一致，实际等级调整的理由写在备注里，反馈对象和状态则表明结论已传达并被确认。按同样方式填写，每条提示都能形成从AI输出到人工结论的完整链路。
当这类记录需要在项目组内长期留存和流转时，可以把核验结论登记为工作项、把清单与证据说明沉淀在项目文档页面中。ONES Assistant 能理解项目、工作项、迭代和 Wiki 页面等上下文，并可将结果保存为工作项、Wiki 页面等内容；ONES 的 AI 能力基于权限体系执行，输出过程可追踪、结果可审计。这样，核验清单的反馈状态和处置动作就能与项目中的实际工作项对应起来，减少在多个页面之间重复录入。
调整与维护：让清单适配不同项目
模板需要在保持核心字段稳定的前提下适配项目差异。调整时遵循一条原则：必填字段只增不减，新增字段先明确口径再启用。
按项目类型增减字段
- 研发迭代类项目：建议启用“关联工作项、初判等级、实际等级、处置动作”，风险多落在具体任务上，需要定位到工作项。
- 多团队协作项目：建议启用“反馈对象、反馈状态、责任人”，明确跨团队告知路径。
- 合规或审计要求较高的项目：建议启用“核验方式、核验证据、AI原始提示”，保证核验过程可复查。
- 提示量很小的项目：可只保留必填六列，避免为低频场景维护过多空列。
字段口径变更的记录方式
等级标准、结论选项、编号规则发生变化时，在清单之外维护一份简短的变更说明，记录变更日期、涉及字段、旧口径、新口径和生效范围。已归档的记录保持原口径，不回溯改写；跨版本汇总时，按变更说明分段统计，避免把不同口径的数据直接相加。
清单版本与归档维护
- 为清单设置版本号，如 v1.0、v1.1，版本号写入表头或文件命名。
- 按迭代或按月归档，归档文件只读保存，保留核验人和反馈状态原始值。
- 每季度抽查一次记录完整性，重点看必填项缺失和“未反馈”长期未更新的条目。
- 根据抽查结果决定是否调整字段，调整后更新版本号并通知填写人。
维护的目标是让不同时期、不同核验人填写的记录仍能放在一起比较。字段可以随项目变化，但提示编号、核验结论和反馈状态这三类信息应始终保持稳定，它们是清单能够支撑留痕与反馈的基础。
常见问题
AI提示没有说明依据时，核验清单里“AI依据”一栏怎么填？
填“未提供依据”，并把这一条作为核验重点。AI依据是判断提示是否值得跟进的第一道线索，缺失本身就是需要记录的信息。核验时改为人工查找相关数据，把查到的内容写进“核验证据”，并在备注中说明AI未给出依据。这样后续统计时能区分“有数据支撑的提示”和“无依据的提示”，也便于比较不同来源的提示质量。
核验结论选“无法核验”后，这条记录还需要继续跟进吗？
需要。选“无法核验”时应在备注写明卡点，例如数据未开放、负责人暂时联系不上、外部环境未就绪，并把反馈状态保持为“未反馈”或按实际传达情况填写。清单维护时把这类条目列入待办，等条件具备后补充核验。留空或直接关闭会让记录看起来已完成，反而掩盖了尚未处理的风险。
多个项目共用一张清单时，如何避免编号重复和口径不一致？
编号建议采用“项目缩写-日期-序号”，项目缩写由团队统一分配并登记，避免不同项目取到相同前缀。等级标准、结论选项这类口径应集中维护一份说明，各项目引用同一版本，不各自改写。跨项目汇总时先确认各项目使用的清单版本，版本不同则分段统计，不把不同口径的数据直接相加。
核验记录需要长期留存并向项目组反馈，放在哪里比较合适？
常见做法是把核验结论登记为工作项，把清单和证据说明沉淀在项目文档页面中，让反馈状态、处置动作与实际工作项对应。ONES Assistant 能理解项目、工作项、迭代和 Wiki 页面等上下文，并可将结果保存为工作项、Wiki 页面等内容；ONES 的 AI 能力基于权限体系执行，输出过程可追踪、结果可审计。选择承载方式时，优先考虑团队成员日常已经在用的入口，减少重复录入。
提示量很少的项目，是否也需要完整填写二十个字段？
不需要。提示量小的项目可只保留六个必填列，把清单控制在容易维护的规模。等提示数量增加、或项目开始实行风险分级管理时，再启用等级、处置动作、反馈对象等选填列。新增字段前先明确填写口径并更新版本号，避免不同时期填写的记录无法放在一起比较。
