结果判定字段要解决两个问题：不同人看同一条检查项时结论口径一致，事后能追溯这个结论由谁、在什么时候、依据什么证据给出。本文给出一套可直接改到模板里的字段结构、受控取值、填写步骤和完成检查清单，适用于单项目交付物验收场景。
要点总览（TL;DR）
- 结果判定字段建议拆成判定结论、判定依据、判定人、判定时间四个必填字段，结论用受控枚举，依据指向具体证据，记录才能回答谁在何时依据什么给出什么结论。
- 判定结论建议取值为通过、有条件通过、不通过、不适用，并把检查状态独立出来，未检查的记录不允许填写判定结论，避免漏检被掩盖。
- 有条件通过要写成可关闭的附加条件，包含遗留事项、责任人、期限和关闭证据；不通过要关联偏差描述、整改责任人与整改期限，复检结论单独记录。
- 检查执行人、判定人、复核人、整改责任人分工明确，各自在清单上留下不同字段痕迹；判定人与执行人是否合并取决于项目规模与质量要求。
- 模板启用前按枚举互斥穷尽、必填划分、依据可追溯、版本变更四项自查，使用后结合结论分布和返工关闭情况调整验收标准。
结果判定字段的核心结构与取值规则
建议把结果判定拆成四个必填字段：判定结论、判定依据、判定人、判定时间。判定结论回答“过没过”，判定依据回答“凭什么”，判定人和判定时间回答“谁负责、何时定的”。四个字段齐备，一条检查项才算完成判定；缺任何一个，记录都只能算草稿。
判定结论使用受控枚举，不使用自由文本。自由文本看似灵活，实际会带来三类问题：同一含义出现“合格／符合／OK／没问题”等多种写法，统计和筛选失效；模糊表述如“基本可以”无法判断是否放行；返工与复检无法按结论自动触发。受控枚举把判断压缩到有限选项，填写人必须做出明确选择。
| 字段名 | 类型 | 必填 | 取值说明 |
|---|---|---|---|
| 判定结论 | 单选枚举 | 是 | 通过／有条件通过／不通过／不适用 |
| 判定依据 | 文本或证据链接 | 是 | 指向具体证据位置、检查记录或偏差编号，写明看到什么 |
| 判定人 | 人员字段 | 是 | 对结论负责的人，与检查执行人可区分 |
| 判定时间 | 日期时间 | 是 | 结论落定的时间，精确到日即可满足多数项目 |
| 检查执行人 | 人员字段 | 是 | 实际执行检查动作的人 |
| 检查状态 | 单选枚举 | 是 | 未检查／已检查待判定／已判定 |
四个枚举值的含义需要在模板说明中固定下来。“通过”表示检查项全部满足验收标准，无需附加动作；“有条件通过”表示主体满足标准，但存在不影响当前放行的遗留项，需写明条件和关闭期限；“不通过”表示存在必须整改的偏差，交付物不能按当前状态放行；“不适用”表示该检查项对本次交付物在定义上不成立，例如某类文档按项目裁剪规则本就不需要产出。
“不适用”与“未检查”必须分开。未检查是执行状态，表示还没做；不适用是判定结论，表示做了判断后确认该项不要求。把未执行误记为不适用，会让清单看起来全部有结论，实际漏检被掩盖。因此检查状态字段独立于判定结论字段，未检查的记录不允许填写判定结论。
从检查项到判定结论：填写步骤
一条检查项的判定过程可以拆成五步，每步都有明确输入和输出，完成标志是判定记录四个必填字段全部填写且检查状态变为“已判定”。
- 对齐验收标准。输入是检查项条目和对应的验收标准；动作是确认该检查项要验证的具体属性，例如文档完整性、内容准确性或格式合规性；输出是一句可判断真假的验收描述。完成标志是验收标准中不含“尽量”“基本”“适当”这类无法判定的词。
- 执行检查并采集证据。输入是待检交付物和验收标准；动作是逐项核对，记录看到的事实，例如文档章节缺失、数据与源系统不一致、签字页未签署；输出是证据位置或检查记录。完成标志是每条结论都能指向一个具体位置，而非只有一句“已检查”。
- 给出判定结论。输入是证据和验收标准；动作是按口径选择枚举值：完全满足选通过，主体满足但有遗留项选有条件通过，存在必须整改的偏差选不通过，定义上不要求选不适用；输出是判定结论。完成标志是结论与证据一致，不存在证据支持通过而结论填不通过的情况。
- 写清判定依据。输入是上一步采集的证据；动作是用一句话说明依据，格式建议为“看到什么＋对照哪条标准＋得出什么判断”；输出是可追溯的依据文本。完成标志是第三人读依据能复现同样的结论。
- 填写判定人与时间，落定记录。输入是判定人和当前日期；动作是确认判定人对结论负责后提交；输出是一条完整判定记录。完成标志是检查状态变为“已判定”，记录进入后续流转。
“有条件通过”的附加条件要写成可关闭的形式，包含三要素：遗留事项是什么、由谁在什么时间前完成、关闭时需要什么证据。例如“附件三的测试报告缺少环境说明，由开发负责人在交付评审前补充环境配置页截图，复检时核对”。只写“后续补充”不构成可关闭条件。
角色分工与各角色交付物
判定字段空转，通常是因为检查、判定、复核、整改四个动作落在同一个人身上且没有记录区分。建议在模板中显式设置四类角色，各自在清单上留下不同字段痕迹。
| 角色 | 主要动作 | 在清单上留下的字段 | 交付物 |
|---|---|---|---|
| 检查执行人 | 按验收标准逐项核对，采集证据 | 检查执行人、检查记录、证据位置 | 检查记录与证据 |
| 判定人 | 依据证据给出结论，对放行负责 | 判定结论、判定依据、判定人、判定时间 | 判定记录 |
| 复核人 | 抽查判定质量，确认依据充分 | 复核结论、复核意见、复核时间 | 复核记录 |
| 整改责任人 | 处理不通过或有条件通过的遗留项 | 整改说明、整改完成时间、复检结论 | 整改与复检记录 |
判定人与检查执行人是否可以为同一人，取决于项目规模和质量要求。小项目中检查与判定合并可以减少交接成本，但判定依据必须写清，且关键交付物建议由独立角色复核。涉及对外交付、合同验收或安全合规的交付物，判定人与执行人分开更稳妥，避免自己检查自己放行。
复核不通过时，记录退回判定人，检查状态回到“已检查待判定”，判定人需补充依据或修改结论后重新提交。复核意见要写明退回原因，例如“依据只写了已核对，未指向具体证据位置”，便于判定人一次改到位。复核记录保留在原记录上，不覆盖此前的判定内容，形成可追溯的修改链。
判定结论与返工闭环字段
判定结论不是终点。不通过和有条件通过都需要后续动作，模板要为这些动作预留字段，否则清单只能记录问题，无法跟踪问题是否解决。
不通过时，以下字段转为必填：偏差描述、整改责任人、整改期限。偏差描述写清实际状态与验收标准的差距；整改责任人是对整改结果负责的人；整改期限给出明确日期。有条件通过时，必填字段为附加条件描述和关闭条件，关闭条件说明复检时核对什么。通过和不适用不触发返工字段。
| 状态 | 触发条件 | 可执行动作 | 流转到 |
|---|---|---|---|
| 待判定 | 检查已执行，结论未填 | 判定人给出结论与依据 | 已判定 |
| 已判定 | 四个必填字段齐全 | 通过则关闭；不通过或有条件通过则派发整改 | 已关闭或整改中 |
| 整改中 | 已指定整改责任人与期限 | 责任人提交整改说明与证据 | 待复检 |
| 待复检 | 整改完成待验证 | 复检人核对并填写复检结论 | 已关闭或退回整改中 |
| 已关闭 | 复检通过或原判定为通过／不适用 | 归档，不再变更 | — |
复检结论单独记录，不复用原判定结论字段。复检通过表示遗留项已消除，记录关闭；复检不通过则退回“整改中”，更新整改期限并保留历次复检记录。有条件通过的关闭条件是附加条件全部满足且复检通过，未满足前记录停留在整改中，不因期限到期自动关闭。
当检查清单条目较多、交付物分散在不同阶段时，判定记录、整改任务和复检结果需要有统一的承载位置。ONES 的项目计划支持按交付物或项目阶段分解工作，并可用里程碑标记重要决策点；判定记录与整改项可以作为工作项关联到对应交付物，整改状态和复检结论随工作项流转，项目层面通过计划与执行对比查看哪些交付物尚未关闭。这样清单字段与项目进度使用同一套对象，减少在表格和项目系统之间反复核对。
填写示例：一条交付物检查记录
以下为演示情景，展示各字段如何配合，不对应真实项目数据。
检查项：接口设计文档是否包含全部对外接口的请求参数、响应结构和错误码说明。验收标准：文档中每个对外接口均有上述三项内容，且与最新接口定义一致。
| 字段 | 填写内容 |
|---|---|
| 检查执行人 | 测试工程师甲 |
| 检查记录 | 共核对 18 个接口，15 个完整；接口 I-07、I-11、I-14 缺少错误码说明 |
| 判定结论 | 有条件通过 |
| 判定依据 | 对照验收标准第三条，18 个接口中 3 个缺错误码章节，主体结构完整，缺项不影响联调启动 |
| 判定人 | 质量负责人乙 |
| 判定时间 | 2025-03-12 |
| 附加条件 | 接口 I-07、I-11、I-14 补充错误码说明，由接口负责人丙在联调开始前完成 |
| 关闭条件 | 复检时核对三个接口的错误码章节已补充且与接口定义一致 |
| 整改责任人 | 接口负责人丙 |
| 整改期限 | 2025-03-18 |
| 复检结论 | 2025-03-17 复检，三个接口错误码章节已补充，与接口定义一致，关闭 |
这条记录中，判定结论与判定依据相互支撑，附加条件写明了对象、责任人和时限，关闭条件给出了复检时核对的具体内容，复检结论单独记录并注明日期。任何人拿到这条记录，都能判断当时为什么放行、遗留什么、后来是否解决。
模板落地与完成检查
模板启用前，建议从取值设计、必填划分、依据可追溯和版本管理四个方面做一次自查。下表可直接作为完成检查清单使用，每项都应有明确的是或否，不满足的项在启用前修正。
| 检查项 | 合格标准 | 结果 |
|---|---|---|
| 枚举取值互斥 | 同一检查项只能落入一个结论，不存在既通过又不通过的模糊地带 | 是／否 |
| 枚举取值穷尽 | 通过、有条件通过、不通过、不适用覆盖实际可能出现的全部结论 | 是／否 |
| 未检查与不适用分离 | 检查状态字段独立，未检查记录不能填判定结论 | 是／否 |
| 必填划分合理 | 四个判定字段全部必填；返工字段仅在对应结论下必填 | 是／否 |
| 依据可追溯 | 每条判定依据能指向具体证据位置或偏差编号 | 是／否 |
| 有条件通过可关闭 | 附加条件包含事项、责任人、期限和关闭证据 | 是／否 |
| 复检独立记录 | 复检结论单独字段，不覆盖原判定 | 是／否 |
| 版本与变更记录 | 清单有版本号，字段或枚举调整时记录变更内容和生效日期 | 是／否 |
版本管理容易被忽略。判定枚举增加取值、必填规则调整、验收标准修订，都会影响历史记录的可比性。建议在清单头部保留版本号和变更说明，历史记录按当时版本解释，新记录按新版本执行。项目结束后回看判定记录时，版本信息能说明为什么早期记录和后期记录的字段不完全一致。
完成上述检查后，模板即可投入单项目使用。使用一段时间后，可结合判定结论分布和返工关闭情况评估模板质量：如果“有条件通过”占比过高且关闭条件长期未关闭，说明验收标准或放行口径需要收紧；如果“不适用”集中在少数检查项，说明这些条目可能不适合当前项目类型，应在下一版本中调整适用范围。
常见问题
小项目里检查执行人和判定人合并成一个人，判定字段还怎么保证有效？
合并角色在小项目中可以减少交接成本，前提是把判定依据写实。判定依据要指向具体证据位置或检查记录，例如“第 3 章缺少签字页，对照验收标准第二条”，让第三人读依据能复现同样的结论。涉及对外交付、合同验收或安全合规的交付物，建议由独立角色复核，复核记录保留在原记录上，不覆盖原判定内容。
判定结论填了“不适用”，还需要写判定依据和判定人吗？
需要。不适用是做了判断后确认该项在定义上不要求，例如某类文档按项目裁剪规则本就不需要产出，这个判断同样要有依据和责任人。判定依据写明依据哪条裁剪规则或项目约定，判定人和判定时间照常填写。检查状态为未检查的记录不能填不适用，未执行和确认不要求是两件事。
有条件通过的遗留项到期没完成，记录应该怎么处理？
记录停留在整改中，不因期限到期自动关闭。到期未完成时，更新整改期限并保留原期限记录，说明延期原因；复检时按关闭条件逐项核对，全部满足才关闭。如果遗留项长期无法关闭，说明验收标准或放行口径需要收紧，可在下一版本模板中调整该检查项的判定要求。
判定记录分散在多个交付物上，怎么在项目层面看整体关闭情况？
可以让判定记录与整改项作为工作项关联到对应交付物，整改状态和复检结论随工作项流转。ONES 的项目计划支持按交付物或项目阶段分解工作，并可用里程碑标记重要决策点；设置基线后可对比计划与执行的偏差，查看哪些交付物尚未关闭。这样清单字段与项目进度使用同一套对象，减少在表格和项目系统之间反复核对。
清单用了一段时间，怎么判断判定字段设计得好不好？
看两个分布：一是有条件通过的占比和关闭情况，占比过高且关闭条件长期未关闭，说明验收标准或放行口径需要收紧；二是不适用的集中度，集中在少数检查项说明这些条目可能不适合当前项目类型，应在下一版本调整适用范围。评估时按清单版本分别统计，避免不同版本的记录混在一起比较。
