线上缺陷提单的目标，是让处理人拿到一张单就能判断“出了什么问题、影响谁、怎么复现、证据在哪、该谁先看”。具体做法是：先确认问题属于缺陷记录范围，再按固定字段填写环境、影响范围、复现步骤、期望与实际结果、证据和紧急程度建议值，提交后由值班或缺陷负责人完成首次确认与分流，信息不足时退回补充，以信息完整、可复现、可交接作为完成标志。
要点总览（TL;DR）
- 线上缺陷提单先判断问题是否属于缺陷记录：可观察的异常行为、与预期不符、影响用户或业务三个条件同时成立才按缺陷提单，无法判断时先记录现象并标注待确认。
- 一张单按五步填完：收集现场信息、写复现步骤与期望/实际结果、附证据、标注影响范围与紧急程度建议值、提交并完成首次确认与分流。
- 必填字段包括标题、发现时间、环境、影响范围、复现步骤、期望结果、实际结果、证据和提交人；标题写成现象+对象+条件，复现步骤写成带前置条件的编号列表。
- 提交人对现场事实和可复现性负责，值班或缺陷负责人负责首次确认、去重、分流和退回补信息，退回时写明具体缺项。
- 合格标志是缺陷单处于已分流状态且处理人明确；无复现步骤、无证据、影响范围空白的单子退回待补充，不进入处理队列。
提单前先确认：哪些线上问题需要记录为缺陷
提单的第一步是判断眼前的问题要不要进入缺陷记录，这一步决定了后续信息收集的方向。判断口径可以归纳为三个条件同时成立：存在可观察的异常行为，该行为与产品预期不符，并且已经影响用户或业务。三个条件都满足时，按缺陷提单；只满足部分条件时，先记录现象并标注待确认，交给值班或缺陷负责人判断。
需要区分的是，用户报障后的服务事件受理、问题严重程度分级，属于相邻环节的工作，不在提单动作内展开。提单人只需把观察到的事实写清，严重程度给出建议值即可，最终定级由受理方决定。
| 情形 | 是否进入缺陷记录 | 提单时的处理方式 |
|---|---|---|
| 页面报错、功能结果与预期不符，有明确操作路径 | 是 | 按完整字段提单 |
| 用户反馈异常，但提单人尚未复现 | 是，标注待确认 | 记录现象、时间、用户与数据范围，复现步骤写已尝试的操作 |
| 数据看起来不对，但无法判断是否符合业务规则 | 先记录，标注待确认 | 附数据截图与业务规则出处，交值班判断 |
| 用户咨询使用方法、操作不符合业务规则 | 否 | 转咨询或需求渠道处理 |
| 计划内的发布、维护导致的短时不可用 | 否 | 核对发布公告后关闭 |
无法判断时不要压着不报。先按“现象+时间+影响对象”记录，标注待确认，让有判断权限的人接手，比事后补记更可靠。
核心答案与操作步骤：一张线上缺陷单怎么填完
一张合格的线上缺陷单，按五步走完：收集现场信息、写复现步骤与期望实际结果、附证据、标注影响范围与紧急程度、提交并完成首次确认与分流。每一步都有明确的输入、动作、输出和完成标志，缺一步就会把补信息的成本转给处理人。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 一、收集现场信息 | 发现时间、访问环境、账号或数据范围、操作路径 | 在问题现场立即记录，不凭记忆回填 | 时间、环境、对象、路径四项要素 | 四项要素齐全，时间精确到分钟 |
| 二、写复现步骤与结果 | 第一步记录的操作路径 | 按编号写出可执行步骤，分别写期望结果与实际结果 | 编号步骤、期望结果、实际结果 | 他人按步骤操作能观察到同一现象 |
| 三、附证据 | 截图、日志片段、请求标识 | 截取关键画面，复制相关日志行，记录请求标识或单号 | 可打开的附件或文本片段 | 证据能对应到复现步骤中的具体环节 |
| 四、标注影响范围与紧急程度 | 受影响用户、订单、功能范围 | 写清影响的功能、数据范围和用户量级，给出紧急程度建议值及理由 | 影响范围描述、紧急程度建议 | 影响范围可量化或可界定，建议值有依据 |
| 五、提交并首次确认 | 前四步产出 | 提交后由值班或缺陷负责人确认、去重、分流 | 已分流的缺陷单 | 单子有明确处理人和当前状态 |
五步中最容易被跳过的是第一步。很多单子写“用户反馈打不开”，缺少时间和环境，处理人只能回头再问。现场信息在发现时记录成本最低，隔一小时再补，细节往往已经丢失。
字段规范：线上缺陷单必填项与填写示例
字段规范解决的是“写不清”的问题。必填项保证处理人不用追问就能开始定位，选填项在能提供时补充，帮助缩短排查路径。
| 字段 | 必填/选填 | 填写口径 |
|---|---|---|
| 标题 | 必填 | 现象+对象+条件，例如“订单详情页在iOS端点击退款按钮后白屏” |
| 发现时间 | 必填 | 精确到分钟，注明时区 |
| 环境 | 必填 | 线上环境标识、端类型、版本、网络条件 |
| 影响范围 | 必填 | 受影响功能、用户或数据范围、是否持续发生 |
| 复现步骤 | 必填 | 编号、可执行、含前置条件（账号、数据状态） |
| 期望结果 | 必填 | 按业务规则应出现的结果 |
| 实际结果 | 必填 | 实际观察到的现象，含报错文案 |
| 证据 | 必填 | 截图、日志片段、请求标识，确保可打开 |
| 提交人 | 必填 | 姓名与联系方式，便于补充信息 |
| 相关订单或用户标识 | 选填 | 便于定位具体数据 |
| 初步怀疑原因 | 选填 | 标注为猜测，与事实分开写 |
| 关联需求或变更 | 选填 | 近期上线内容、相关需求编号 |
标题写法要避免“报错”“打不开”“有问题”这类只有情绪没有信息的表述。合格标题包含三要素：什么现象、发生在哪个对象上、在什么条件下出现。复现步骤要写成别人能照着做的编号列表，前置条件单独列出，例如使用的账号类型、数据状态、是否登录。
一条完整的填写示例如下（演示情景）：
- 标题：订单详情页在iOS客户端点击“申请退款”后白屏
- 发现时间：2024-06-12 14:35
- 环境：线上环境，iOS客户端 5.2.1，Wi-Fi网络
- 影响范围：已支付且处于可退款状态的订单，客服反馈近半小时有3位用户遇到，持续发生
- 复现步骤：1）使用测试账号登录iOS客户端；2）进入“我的订单”，选择一笔已支付订单；3）点击“申请退款”按钮；4）观察页面表现
- 期望结果：进入退款申请页，显示退款金额与原因选项
- 实际结果：页面白屏，停留约5秒后回到订单列表，无错误提示
- 证据：白屏截图1张、客户端日志片段（含请求标识 req-88213）
- 提交人：张三，企业通讯录可查
- 初步怀疑原因（猜测）：退款入口依赖的配置接口返回异常，待确认
角色与交接：谁提单、谁确认、谁补信息
提单环节涉及三类角色，职责边界清楚，交接才不丢信息。提交人对现场事实和可复现性负责，值班或缺陷负责人对首次确认与分流负责，开发或处理人对信息是否足够定位给出反馈。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 提交人 | 记录现场信息、写复现步骤、附证据、提交 | 字段完整的缺陷单 |
| 值班或缺陷负责人 | 首次确认、去重、判断分流方向、退回补信息 | 已确认并分流的缺陷单，或退回说明 |
| 开发或处理人 | 判断信息是否足够定位，提出具体补充要求 | 补充要求清单或受理确认 |
交接时状态与字段同步变化：提交后状态为“待确认”；值班确认并指定处理人后变为“已分流”；信息不足退回时变为“待补充”，并在评论中写明缺哪几项；提交人补齐后回到“待确认”。每次状态变化都对应一次责任转移，接手人应能在单子里看到上一环节留下了什么。
退回补充要具体。写“信息不全”没有意义，应写“缺少复现步骤第2步使用的账号类型和退款入口的请求标识”。补充要求越具体，往返次数越少。
完成检查：提交前与受理后的核对项
判断一张缺陷单是否合格，用两份清单核对：提交前由提交人自查，受理后由值班或缺陷负责人核对。
提交前检查清单：
- 必填字段全部填写，没有留空或写“无”
- 标题包含现象、对象、条件三要素
- 复现步骤编号完整，前置条件已写明
- 期望结果与实际结果分开描述
- 证据附件能正常打开，且对应到具体步骤
- 影响范围已写清功能、数据或用户范围
- 紧急程度建议值附有理由
受理后检查清单：
- 是否与已有缺陷单重复，重复则合并并注明原单
- 是否已指定处理人或分流到对应团队
- 信息是否足够定位，不足则列出具体补充项并退回
- 状态是否已更新，接手人是否明确
阻断项的处理要统一：无复现步骤、无证据、影响范围空白时，不进入处理队列，由值班退回“待补充”并写明缺项。完成标志是缺陷单处于“已分流”状态且处理人明确，责任人为值班或缺陷负责人。提交人补齐信息后，单子重新进入待确认，不直接跳到处理中。
把提单规范落到协作工具里
字段和流程写在文档里容易走样，落到协作工具里才能稳定执行。以ONES为例，可以把上述规范拆成几个承载点：用工作项模板固定标题、环境、影响范围、复现步骤、期望结果、实际结果、证据等必填字段，提交时缺项无法直接通过，减少漏填；用状态流转记录“待确认—已分流—待补充”的交接过程，每次状态变化留下操作人和时间；用附件与评论承载截图、日志片段和补充说明，让证据与单子在一起，不散落在聊天记录里；用查询视图筛出“待补充”和“待确认”的缺陷单，值班人员按视图逐条处理，避免单子停在中间状态无人跟进。
这套承载方式适合提交人分散、值班轮换的团队。规范能否执行，取决于模板字段是否够用、状态是否与真实交接一致，落地时应先用几张真实缺陷单试填，再调整字段和状态设置。
常见问题
提单人自己没能复现问题，还能提交缺陷单吗？
可以提交，但要标注待确认。此时把已经掌握的事实写清：发现时间、用户或数据范围、用户描述的现象、自己已尝试过的操作。复现步骤一栏写实际做过的尝试和观察到的结果，不虚构未发生的步骤。值班或缺陷负责人接手后，再判断是否需要进一步复现或直接分流给处理人。
这类单子的价值在于保留现场信息。压着不报等复现，往往错过用户还在线的窗口，事后补记的细节也容易失真。
线上问题同时涉及多个功能模块，应该拆成几张单？
按可独立定位和独立修复的最小单元拆单。如果多个模块的异常来自同一个入口或同一次变更，先合成一张单，在影响范围里列出涉及的模块，由值班确认后再决定是否拆分。如果各模块现象不同、复现路径不同，分开提单更利于分派和跟踪。
拆单时在每张单里注明关联单号，避免处理人只看到局部。合并时保留信息最完整的一张作为主单，其余标注重复并指向主单。
紧急程度建议值填高了或填低了会怎样？
建议值只是提单人的判断输入，最终定级由受理方决定。填高了会占用值班的确认时间，填低了可能让真正紧急的问题排在后面。填写时附上理由，例如受影响用户量级、是否阻断核心交易、是否有替代操作路径，让受理方有依据快速复核。
如果情况在提交后发生变化，例如影响范围扩大，及时在评论中补充说明并提示值班重新评估，不直接改单子状态。
值班人员退回补充信息时，怎么写才不至于来回多次？
退回说明要指向具体字段和具体缺项，例如“缺少复现步骤第2步使用的账号类型”“证据附件无法打开，请重新上传日志片段”。避免只写“信息不全”。一次列全所有缺项，让提交人一轮补齐，减少往返。
退回后状态置为待补充，提交人补齐再回到待确认。值班在下次确认时先核对上次列出的缺项是否都已解决，再决定是否分流。
团队刚推行提单规范，怎么减少提交人的抵触？
先把必填字段压到真正影响定位的最小集合，其余作为选填，避免一张单填十几项。再用几张真实缺陷单试填模板，看字段是否够用、状态是否与真实交接一致，按试填结果调整。
同时让值班在退回时给出具体缺项而不是笼统评价，提交人能感知到补齐后确实推进了处理。规范执行一段时间后，用待补充和待确认的单量观察效果，再决定是否增加字段或收紧要求。
