缺陷流转要落地，靠四件事：状态与准入条件、每个状态的责任角色、切换时必须留下的字段、以及退回和关闭等分支的处置规则。本文按这四步给出可直接套用的状态表、责任表、异常处置清单和一条完整流转示例，最后附执行检查清单，帮助团队把靠口头推动的缺陷处理改成可核对的流程。
要点总览（TL;DR）
- 先用六个主状态（新建、已确认、处理中、待验证、已关闭）加挂起、重复、不予修复三个分支状态搭骨架，每个状态写清进入条件和退出条件，状态与严重程度、优先级分开填写。
- 每个状态只设一个当前责任人，交接时由交出方补齐必填字段、接收方确认后才算完成流转；已确认后须在约定时限内指派到具体处理人，转派要留原因。
- 退回、挂起、重复、不予修复和关闭都要记录原因、责任人和回到主路径的条件；同一缺陷退回次数设上限，长期挂起定期复核。
- 用一条缺陷走完全流程并保留每次状态变化的时间、操作人与关键字段，流转记录是后续检查执行情况的依据。
- 按状态停留时长、必填字段缺失率、退回原因分布、记录与实际动作一致性定期检查，发现偏差后修规则或补执行，并在下一个周期复查。
缺陷流转先定哪几个状态和准入条件
状态设计的起点是让每个状态回答一个问题：这条缺陷现在卡在谁那里、等什么条件才能往下走。建议先用六个主状态构成主干，再用三个分支状态处理非正常情况。状态数量以团队能记住、能核对为准，不必一次求全。
主状态：新建、已确认、处理中、待验证、已关闭。分支状态：挂起、重复、不予修复。延期处理可以作为挂起的一种原因记录，也可以单列，取决于团队需要多细地区分“等排期”和“等外部条件”。
每个状态都要写清进入条件和退出条件。进入条件决定“什么情况下允许把缺陷推到这个状态”，退出条件决定“满足什么才能离开”。只写状态名称、不写条件，流转就会退化成个人判断。
| 状态 | 进入条件 | 退出条件 |
|---|---|---|
| 新建 | 提交人填写标题、复现步骤、实际结果、期望结果、影响范围与严重程度 | 确认人完成有效性判断：可复现且属于缺陷，转入已确认；信息不足退回补充；非缺陷转入不予修复或关闭 |
| 已确认 | 确认人复现成功，影响范围与严重程度经确认，优先级已给出 | 处理人接受指派并给出计划修复时间，转入处理中；确认暂不处理时转入挂起或不予修复 |
| 处理中 | 处理人已接受指派，缺陷有明确负责人 | 处理人提交修复说明与影响版本，转入待验证；确认无法在当前版本修复时转入挂起或延期 |
| 待验证 | 修复说明已填写，修复版本可获取 | 验证人按复现步骤验证通过，转入已关闭；验证不通过，退回处理中并记录失败现象 |
| 已关闭 | 验证结论已填写，关闭责任人确认 | 出现回归或新证据时重开，回到已确认或处理中 |
| 挂起 | 写明挂起原因（等排期、等外部依赖、等版本合并等）、责任人和恢复条件 | 恢复条件满足，由挂起责任人推回已确认或处理中 |
| 重复 | 确认人与已有缺陷比对，指明被重复的主缺陷编号 | 主缺陷关闭后随之关闭；若比对有误，可退回已确认 |
| 不予修复 | 写明理由（设计如此、影响可接受、成本高于收益等）并经约定角色审批 | 业务条件变化时重开，回到已确认重新评估 |
状态要与严重程度、优先级分开。严重程度描述缺陷本身造成的后果，优先级描述修复的先后安排，状态描述缺陷当前处在流程的哪一步。三者混用最常见的表现是：用“高优先级”代替“已确认”，导致缺陷没有经过复现就被排进处理；或者用“处理中”表达“已经知道但还没排期”。建议在字段上分开填写，并在确认环节同时给出严重程度和优先级，进入处理中之后只允许按规则调整，调整要留记录。
每个状态由谁负责、要填什么字段
状态只有落到角色和字段上才能执行。角色划分的原则是：每个状态有且只有一个当前责任人，交接时由交出方补齐字段、接收方确认后才算完成流转。
常见分工如下。提交人负责把问题说清楚；确认人负责判断是不是缺陷、严重程度是否准确；处理人负责定位与修复；验证人负责按原步骤复验；关闭责任人负责最终确认关闭条件成立。小团队可以一人兼多个角色，但同一状态的责任人要明确，避免“大家都觉得别人在看”。
| 状态 | 当前责任人 | 切换时必填字段 |
|---|---|---|
| 新建 | 提交人 | 标题、复现步骤、实际结果、期望结果、影响范围、严重程度、环境信息 |
| 已确认 | 确认人 | 复现结论、确认后的严重程度与优先级、影响范围修订 |
| 处理中 | 处理人 | 接受指派记录、计划修复时间、根因（可在修复后补）、修复说明、影响版本 |
| 待验证 | 验证人 | 修复版本、验证步骤、验证结论 |
| 已关闭 | 关闭责任人 | 关闭依据、关闭时间 |
| 挂起 | 挂起责任人 | 挂起原因、恢复条件、预计恢复时间 |
| 重复 | 确认人 | 主缺陷编号、比对说明 |
| 不予修复 | 审批人 | 不修复理由、审批记录 |
指派与转派要有规则。缺陷进入已确认后必须在约定时限内指派到具体处理人，超过时限由确认人或模块负责人兜底指派。转派时原处理人填写转派原因，接收人确认后才变更责任人；不允许把缺陷改回“新建”来变相换人。处理人休假或离职时，由其上级在缺陷上直接改派并留记录，避免缺陷长期停在无人负责的状态。
字段填写要区分“必填”和“补充”。复现步骤、影响范围、修复说明、验证结论属于流转必需信息，缺失时下一环节可以拒收；根因分析、改进建议可以在关闭前后补充。把必填项控制在切换状态真正需要的范围内，字段才不会变成走过场。
当缺陷数量增多、跨模块协作变多时，状态、责任人和字段需要由工具承载，否则流转记录散落在聊天和表格里，难以核对。ONES 的工作项支持自定义状态与流转，切换时可要求填写指定字段，并保留操作人与时间记录，适合把上面这套状态表和责任表固化成系统里的流转规则；具体配置方式按团队实际使用的版本确定。
退回、挂起、重复与关闭怎么处置
实际执行中最容易卡住的往往不是正常路径，而是退回、挂起、重复、不予修复和关闭这几种分支。分支规则要写清触发条件、记录要求和审批人，否则缺陷会在状态之间来回移动而没有结论。
- 验证不通过退回处理中。验证人必须写明失败现象、复验环境和与修复说明不一致的地方，缺陷退回处理中并重新指派原处理人。同一缺陷退回次数要设上限，例如连续两次退回后升级给模块负责人参与定位，避免处理人与验证人对现象理解不一致时反复往返。
- 挂起。挂起适用于当前无法推进但有明确恢复条件的情况，例如等待上游版本、等待外部依赖、等待排期。挂起时必须写原因、责任人和恢复条件，责任人随缺陷保留，不能因为挂起就视为无人负责。到达预计恢复时间或恢复条件满足时，由责任人推回已确认或处理中；长期挂起要定期复核，复核结论记入流转记录。
- 判定重复。由确认人比对已有缺陷后判定，必须填写主缺陷编号和比对说明。重复缺陷跟随主缺陷的关闭而关闭；如果后续发现比对有误，可以退回已确认重新处理。
- 不予修复与延期。不予修复要有明确理由，例如设计如此、影响范围可接受、修复成本明显高于收益，并经过约定角色审批。延期处理要给出延期原因和重新评估的时间点，到期由责任人重新评估，不能以延期代替结论。
- 关闭。关闭的判定标准是验证结论已填写且验证通过，或经审批确认不予修复、重复。关闭后出现回归、新环境复现或业务条件变化时可以重开，重开要写明新证据，并回到已确认重新评估严重程度与优先级。
这些分支规则的共同点是：每次离开主路径都要留下原因、责任人和回到主路径的条件。只改状态不写原因，事后就无法判断这条缺陷是处理完了还是被搁置了。
一次完整的缺陷流转示例
下面用一条演示缺陷说明各步骤的输入、动作与输出，示例中的角色和时间为示意，不代表真实项目数据。
某后台页面在筛选条件为空时点击查询，返回报错页。提交人在新建状态填写：标题“筛选条件为空时查询报错”，复现步骤三步，实际结果为报错页，期望结果为返回全部数据，影响范围为该模块所有用户，严重程度为高，环境为测试环境指定版本。
确认人按步骤复现成功，补充确认严重程度为高、优先级为高，影响范围修订为“该模块全部查询入口”，缺陷转入已确认，并在当天指派给处理人。
处理人接受指派，缺陷转入处理中，填写计划修复时间。定位后填写根因为参数为空时未做默认值处理，修复说明为补充空值判断并增加回归用例，影响版本为下一发布版本，随后转入待验证。
验证人在待验证状态按原复现步骤复验，发现筛选条件为空的场景已修复，但多条件组合时仍报错，填写验证结论为不通过、失败现象为组合条件报错，缺陷退回处理中。处理人补充修复说明后再次转入待验证，验证人复验通过，填写验证结论与验证版本，关闭责任人确认后关闭。
这条缺陷的流转记录应能看出：每次状态变化的时间、操作人、填写的关键字段，以及一次退回的原因和再次提交的修复说明。查看记录即可回答“谁在什么时候因为什么把缺陷推到了下一步”，这也是后续检查执行情况的依据。
怎么检查缺陷流转是否真的执行到位
流程写完不等于执行到位。检查的目标是发现“状态在动但信息不全”“缺陷长期停在同一状态”“记录与实际动作不一致”这几类偏差，并按固定节奏复查。
- 状态停留时长。统计各状态的平均停留时长和超期未流转的缺陷数量，重点看已确认未指派、处理中长期无更新、待验证积压三类。超期缺陷要能列出清单并指明当前责任人。
- 必填字段缺失率。按状态抽查切换时必填字段的填写情况，缺失率高的字段要么是规则不合理，要么是执行不到位，需要分别处理。
- 退回原因分布。统计验证不通过的退回原因，如果集中在“修复说明不清”“复验环境不一致”，说明交接字段或验证约定需要调整；如果集中在同一处理人，则需要单独跟进。
- 记录与实际动作一致性。抽取一定数量的已关闭缺陷，核对流转记录中的修复说明、验证结论与实际提交、验证动作是否对应，防止先改状态后补动作。
- 分支状态清理。定期检查挂起、重复、不予修复的缺陷是否仍有明确责任人和恢复条件，长期无变化的挂起项要重新评估。
发现偏差后的修正动作要具体：字段缺失率高的，先修必填规则再培训；超期集中的环节，明确该环节的时限和兜底责任人；记录与实际不一致的，要求补齐记录并对相关角色说明要求。复查时点建议与团队的迭代节奏对齐，例如每个迭代结束检查一次，连续两个周期观察同一指标是否改善。检查结果和修正动作记入团队的过程改进记录，形成“检查—修正—复查”的闭环。
常见问题
团队规模小、一人兼多个角色时，缺陷流转规则要不要简化？
可以简化角色数量，但每个状态仍要指定唯一的当前责任人。小团队常见的做法是确认人与关闭责任人由同一人承担，处理人与验证人分开，避免自己修自己验。状态集也可以先保留主干六个状态，挂起和不予修复按需启用，重复状态在缺陷量少时可以并入关闭并注明主缺陷编号。简化的是角色和分支数量，进入条件、退出条件和切换必填字段这三项建议保留，否则流转又会回到口头确认。
缺陷已经进入处理中，但排期一直排不上，应该挂起还是留在处理中？
判断标准是这条缺陷当前有没有人在推进。如果处理人已经接受指派、只是排在队列里等排期，可以留在处理中，但要填写计划修复时间并在超期时进入检查清单；如果短期内确定无法安排、需要等外部依赖或上游版本，转入挂起更合适，同时写明挂起原因、责任人和恢复条件。两种做法都要避免的状态是：缺陷挂在处理中、没有计划时间、也没有人跟进，这类缺陷在状态停留时长检查中应被列为超期项。
验证不通过退回时，应该退回到处理中还是退回到已确认？
默认退回处理中并重新指派原处理人，因为缺陷已经过确认、严重程度和优先级也已给出，重新走确认环节会拉长周期。退回时验证人要写明失败现象、复验环境和与修复说明不一致的地方。出现以下情况可以退回已确认：复验发现原确认的严重程度或影响范围判断有误，或者缺陷现象与最初描述明显不同、需要重新判断是否属于缺陷。同一缺陷连续退回达到设定次数后，升级给模块负责人参与定位。
缺陷关闭后又被用户复现，重开时应该回到哪个状态？
重开要写明新证据，例如复现环境、复现步骤和现象，然后回到已确认重新评估严重程度与优先级，再进入处理中。直接回到处理中会跳过重新判断这一步，容易出现按旧优先级排期、实际影响已经变化的情况。如果新证据表明这是另一个问题而非原缺陷回归，按新缺陷提交并在描述中关联原缺陷编号，比直接重开更利于后续统计回归率。
流转记录要保留到什么程度才算够用？
够用的标准是：只看记录就能回答谁在什么时候因为什么把缺陷推到了下一步。具体包括每次状态变化的时间与操作人、切换时填写的关键字段（复现结论、修复说明、验证结论、挂起原因等）、退回和重开的原因。根因分析和改进建议可以在关闭前后补充，不作为流转必需项。记录不必追求字段齐全，重点是与实际动作对应，抽查已关闭缺陷时能核对上提交、修复和验证动作即可。
