缺陷描述不清时，先别急着退回或自行猜测。按缺项、复现路径断裂、表述含混三类原因逐一核对，再向提交人补齐环境、步骤、预期与实际结果和证据，最后让非提交人仅凭记录做一次复现或走查来确认补全有效。本文围绕这条处置路径展开，只处理缺陷记录质量问题，缺陷分级规则和服务事件受理不在讨论范围内。
要点总览（TL;DR）
- 缺陷描述不清先按三类原因核对：必填字段缺项、复现路径断裂、表述含混；排查从字段缺失开始，再做一次复现尝试，最后核对表述歧义。
- 补全时按清单一次性追问环境与版本、前置条件、操作步骤、预期结果、实际结果和证据附件，补充内容单独标注补充人与时间，保留提交人原始描述。
- 补全是否有效，由非提交人仅凭记录独立复现或定位来判断；未通过就回到对应环节继续补，不靠补充字数衡量。
- 预防复发靠模板必填字段、提交前自查、进入开发前的记录质量检查和对反复缺项者的定向反馈，用退回率和平均补问次数观察效果。
- 这些约束需要在缺陷流转工具中落地，ONES Project 支持一键提交 Bug 并统计缺陷状态分布，ONES TestCase 中未通过的用例可快速创建缺陷任务。
缺陷描述不清通常表现在哪些地方
判断一条缺陷是否属于“描述不清”，看的是记录本身能否支撑他人独立理解和复现，与这条缺陷该定什么级别无关。以下症状可以帮你对号入座。
- 缺环境信息：只写“页面报错”，没有浏览器或客户端版本、操作系统、测试环境地址、账号角色、数据条件。
- 步骤跳跃：从登录直接跳到“点击保存后失败”，中间的前置操作、入口路径、输入数据缺失，读者无法按顺序走一遍。
- 预期与实际混写：一段话里既说“应该显示列表”，又说“结果空白”，没有分开标注哪句是期望、哪句是观察到的现象。
- 无日志或截图：报错信息只写“系统异常”，没有错误码、堆栈、请求标识、截图或录屏，开发无法定位到具体环节。
- 指代含糊：使用“那个按钮”“上次那个页面”等依赖上下文的说法，换一个人阅读就失去指向。
需要区分的是：描述质量问题关注“记录能不能被处理”；分级争议关注“这条缺陷该多严重、先修哪个”；事件受理关注“线上问题是否进入应急流程”。三者可能同时出现，但处置动作不同。本文只解决记录质量，分级和受理按各自流程处理。
先判断原因：缺项、路径断裂还是表述含混
把症状归到原因之前，先把它当假设，用可观察的证据验证。三类原因对应的证据和排查顺序如下。
| 原因假设 | 可观察证据 | 验证方式 |
|---|---|---|
| 必填字段缺项 | 环境、版本、账号角色、证据附件等字段为空或只填“无” | 对照缺陷模板逐项检查，缺一项记一项 |
| 复现路径断裂 | 步骤之间存在未说明的操作，或缺少前置数据、入口条件 | 按记录原样走一遍，记录在哪一步无法继续 |
| 表述含混 | 预期与实际混在一段、指代不明、同一现象有两种说法 | 请另一位同事只读记录，复述他理解的现象，比对是否一致 |
排查顺序建议从字段缺项开始，因为字段缺失最容易核对，也最常是补问的起点；字段齐全后再做一次复现尝试，看路径能否走通；路径走通但现象仍说不清时，才进入表述歧义的核对。一次复现尝试往往能同时暴露路径断裂和表述含混：走到某一步卡住，说明路径有问题；走完了却得到与描述不同的结果，说明预期与实际至少有一处写错。
证据不足时不要替提交人补推断。例如记录写“偶尔失败”，你不能自行判定为并发问题；记录没写环境，你不能默认是测试环境。此时应回到提交人确认，把“待确认”作为记录状态保留下来。
按缺项补全缺陷记录的具体做法
补全的目标是让记录可被他人处理，同时不改变提交人的原意。操作上分追问、补写、留痕三步。
第一步，按清单追问。向提交人一次性问清以下内容，避免来回多轮：
- 环境与版本：测试或生产环境、客户端或浏览器版本、服务端版本号。
- 前置条件：账号角色、权限、所需数据、依赖的配置或开关。
- 操作步骤：从入口开始的完整顺序，每步的输入值。
- 预期结果：按需求或设计，正确表现应该是什么。
- 实际结果：观察到的现象、报错文案、错误码、发生时间与频率。
- 证据附件：截图、录屏、日志片段、请求标识。
追问话术尽量具体，例如“请补充出现问题时使用的浏览器版本和登录账号角色”，比“请补充环境信息”更容易得到有效回答。
第二步，补写并保留原始信息。在缺陷记录中保留提交人原始描述，补充内容单独成段，标注补充人和补充时间，例如“补充（张三，某月某日）：经与提交人确认，环境为……”。这样后续追溯时能分清哪些是原始观察、哪些是二次整理，避免覆盖提交人原意导致争议。
第三步，注意数据与权限边界。涉及生产数据、用户信息或完整日志时，先脱敏再附入记录，隐去手机号、身份证号、订单号等敏感字段；获取日志前确认自己有对应环境的访问权限，按权限范围取用，不把生产数据转发到无关群组。
如果多次追问后仍无法复现，记录应写明已尝试的环境、步骤和结果，标注“暂无法复现”及已确认的信息范围，并约定后续观察条件（如再次出现时保留现场）。到这里可以停止继续追问，把记录留在待观察状态，避免无限循环补问。
怎么验证补全后描述已可处理
补全是否有效，不看补充了多少字，而看他人能否只凭这条记录独立复现或定位。验证标准可以归纳为一条：一位没有参与补全的开发或测试人员，按记录中的环境、步骤和数据操作，能够复现同一现象，或能据此定位到具体模块与报错位置。
验证由非提交人执行，方式有两种：按记录完整走一遍复现路径；或对无法复现的问题做一次走查，确认记录中的证据足以指向问题范围。验证人应在记录中写明结论，例如“已按记录复现，现象一致”或“按记录走到第三步无法继续，缺少前置数据”，并签上姓名和日期。
未通过验证时，回到补全步骤中对应的环节：缺字段就继续追问字段，路径走不通就补前置条件和步骤，现象对不上就重新核对预期与实际。每次回到补全都保留上一轮记录，便于看出哪类信息反复缺失。
减少缺陷描述不清复发的机制
单条缺陷补全后，把有效做法固化成流程约束，才能减少同类问题反复出现。
- 模板与必填字段：在缺陷模板中把环境与版本、前置条件、操作步骤、预期结果、实际结果、证据附件设为必填或强提示项，让提交时就被引导填写。
- 提交前自查：给提交人一份短清单，提交前逐项确认“别人能否按我写的步骤走一遍”，把自查作为提交动作的一部分。
- 评审时点：在缺陷进入开发处理前设置一次记录质量检查，由测试或缺陷管理员按验收标准判断，不合格的退回补充而不是直接排期。
- 定向反馈：对反复出现描述缺项的提交人，结合其具体缺陷记录给出修改示例，说明缺的是哪类信息、下次怎么填，比泛泛培训更有效。
- 效果观察：用缺陷退回率和平均补问次数作为观察指标，按周或按迭代统计，看这两项是否下降；若某类缺项反复集中出现，再回头调整模板字段。
这些约束需要在缺陷流转工具中落地，否则模板和检查容易停留在文档里。ONES Project 适配缺陷管理等研发场景，支持一键提交 Bug 至对应项目或迭代，并统计缺陷状态分布；ONES TestCase 中未通过的用例可快速创建缺陷任务，让缺陷在测试与研发团队间流转。把必填字段、补充留痕和验证结论放进缺陷工作项的记录与状态中，退回补充和评审时点就有了统一的承载位置，退回率与补问次数也能从工作项数据中统计。字段的具体配置方式以团队实际使用的产品版本为准。
常见问题
缺陷描述不清和缺陷分级争议同时出现时，先处理哪个？
两件事分开处理，顺序上先补记录质量。描述不清时，分级判断缺少依据，容易凭印象定级；把环境、步骤、预期与实际结果补齐后，再按分级规则评估严重程度和优先级。如果这条缺陷同时涉及线上问题是否进入应急流程，按服务事件受理流程单独走，不占用补全记录的动作。
提交人已经离职或联系不上，缺陷记录还能补全吗？
可以补全，但要把信息来源标注清楚。由当前处理人按记录做一次复现尝试，把能确认的环境、步骤和现象写入补充段落，标注补充人和时间；无法确认的部分保留“待确认”状态，写明已尝试的范围。涉及生产数据时先脱敏再附入。补全后仍按非提交人独立复现的标准验收，验证不通过就留在待观察状态，不强行给出结论。
追问几次提交人仍说不清，什么时候可以停止补问？
设定一个停止点：已按清单问过环境、步骤、预期与实际结果和证据，且做过至少一次复现尝试，仍无法得到可操作的信息时，把已尝试的环境、步骤和结果写入记录，标注“暂无法复现”及已确认的信息范围，约定再次出现时保留现场，然后转入待观察。继续无限补问会拖住流转，记录下停止点和后续观察条件更利于追溯。
必填字段设得太多，提交人嫌麻烦绕过去填“无”，怎么办？
先区分哪些字段真正影响处理。环境与版本、操作步骤、预期与实际结果、证据附件属于直接影响复现的字段，设为必填；其余字段可设为选填或提供默认选项。对填“无”的情况，在进入开发前的记录质量检查中退回补充，并给出具体示例说明该怎么填。字段设计后按退回率观察效果，若某类缺项集中出现，再回头调整模板，而不是一味增加必填项。
用工具固化必填字段和记录质量检查，ONES 能覆盖哪些环节？
ONES Project 适配缺陷管理等研发场景，支持一键提交 Bug 至对应项目或迭代，并统计缺陷状态分布；ONES TestCase 中未通过的用例可快速创建缺陷任务，让缺陷在测试与研发团队间流转。把补充留痕和验证结论放进缺陷工作项的记录与状态中，退回补充和评审时点就有了统一承载位置。字段的具体配置方式以团队实际使用的产品版本为准。
