线上缺陷提单要解决的是把“线上发生了什么”整理成一份可复现、可判断、可追踪的记录。提单前先确认现象与影响范围，再按固定字段写清环境、复现步骤、期望与实际结果、影响用户与业务、证据附件和紧急程度线索；提交后由缺陷管理流程完成受理、定级与分派。本文覆盖提单环节的字段、步骤与检查方法，并说明这些记录如何在ONES的缺陷工作项中承载与流转。
要点总览（TL;DR）
- 线上缺陷提单的目标是让记录可复现、可判断、可追踪：现象、环境与版本、复现步骤、期望与实际结果、影响范围、证据附件、时间点缺一不可。
- 提单人只写可观察的事实与紧急程度线索，严重程度与优先级的正式判定由受理与定级角色按分类分级规则完成。
- 操作按四步推进：发现与初步确认、信息收集与证据留存、填写提单并自查、提交后跟踪受理状态并追加补充信息。
- 提交前对照阻断项自查：关键字段无空白、复现步骤可被他人跟随、证据带时间标记；重复问题在原记录中补充，不另起新单。
线上缺陷提单前先确认什么
提单前的判断决定这份记录后续能否被受理和定位。需要先分清三件事：线上缺陷记录是把已发生的异常写成可复现的事实；服务事件受理是另一套响应机制，关注服务中断的通报与恢复；严重程度判定属于分类分级规则，由对应角色在受理后完成。提单人在这一步只做事实确认，不替受理人下结论。
确认动作围绕四个问题展开。第一，现象是什么：哪个页面、接口或功能出现异常，报错文案或异常表现的具体形态。第二，影响范围有多大：涉及哪些用户群体、哪些业务操作、是否涉及数据错误、从什么时间点开始。第三，能否复现：在相同环境下按相同步骤操作，异常是否稳定出现；只能偶发出现时，记录发生频次和已知触发条件。第四，证据是否在手：日志片段、截图、请求与响应内容、发生时间点是否已经留存。
信息不足时的处理方式有两种。关键证据（如报错日志、发生时间）尚可获取的，先收集再提交，避免记录只有一句“线上有问题”。确实无法补齐的，在记录中标注待补充项和已知边界，例如“仅收到一位用户反馈，未能复现，附用户操作截图”，让受理人知道信息的可靠程度，而不是凭推测把字段填满。
提单前确认清单：
- 现象：异常的具体表现与出现位置已写明；
- 范围：受影响用户、业务操作、数据与时间窗口已有初步判断；
- 可复现性：已尝试复现，并记录稳定复现、偶发或暂未复现；
- 证据：日志、截图、请求响应、时间点中至少留存可支撑现象的关键项；
- 边界：无法确认的信息已标注为待补充，未写成确定结论。
线上缺陷提单的核心字段与填写方法
字段设计的目标是让受理人不必反复追问就能判断“这是什么问题、影响多大、去哪里复现”。下表给出一套可直接套用的字段与填写要求，组织可在此基础上增减必填项。
| 字段 | 填写要求 | 常见错误 |
|---|---|---|
| 标题 | 一句话写清“位置+异常表现”，如“订单详情页提交按钮点击后无响应” | 只写“线上bug”“页面报错”，无法区分问题 |
| 现象描述 | 按用户视角描述看到什么、做了什么操作后出现，附报错原文 | 混入原因猜测，把“疑似缓存问题”写成现象 |
| 环境与版本 | 记录发生环境（生产）、涉及的系统版本、客户端类型与版本、浏览器或设备 | 只写“线上”，缺少版本与终端信息 |
| 复现步骤 | 编号列出从进入页面到异常出现的每一步，含使用的账号类型与数据条件 | 步骤跳跃，省略前置条件，他人无法跟随操作 |
| 期望结果 | 按业务规则应出现的结果 | 空缺，或写成“应该正常” |
| 实际结果 | 实际出现的表现，与期望结果逐条对应 | 与现象描述重复但信息更少 |
| 影响范围 | 受影响用户群体与数量线索、受阻的业务操作、是否涉及数据错误、异常开始的时间窗口 | 只写“影响很大”，没有具体对象 |
| 证据附件 | 日志片段、截图或录屏、请求与响应内容、关键时间点，附件命名带时间 | 只贴一张无上下文的截图 |
| 紧急程度线索 | 描述客观事实，如“核心下单流程受阻，已收到多条用户反馈” | 直接写“P0”“紧急”，替受理人做定级 |
影响范围一栏要落到具体对象。用户维度写清是全部用户还是特定角色、特定区域；业务维度写清哪条流程被阻断、是否有替代操作；数据维度写清是否出现错误数据、是否已扩散；时间窗口写清首次发现时间与持续时长。这四项决定了受理人判断处置顺序的依据。
紧急程度线索与正式定级要分开。提单人填写的是可观察的事实，例如业务受阻程度、受影响用户规模、是否仍在持续、有无临时绕行方案；严重程度与优先级的正式判定由分类分级规则和对应角色完成。把线索写成事实，受理人才能复核；直接写级别，容易让定级变成对提单人判断的确认。
从发现到提交的操作步骤
提单动作按顺序推进，每一步都有明确的输入、输出和完成标志，避免边查边填导致记录残缺。
第一步：发现与初步确认
输入是异常现象或用户反馈。动作是确认异常是否真实存在、发生在哪个功能、是否仍在持续，并判断属于线上缺陷记录还是应走服务事件响应。输出是一句可描述的现象和初步影响判断。完成标志：能用一句话说清“什么位置、什么表现、是否持续”。
第二步：信息收集与证据留存
输入是初步确认的现象。动作是截取报错界面、导出相关时间段日志、保存请求与响应内容、记录首次发现时间，并尝试按操作路径复现。输出是一组带时间标记的证据材料。完成标志：他人依据这些材料能独立尝试复现，或能理解为何无法复现。
第三步：填写提单并自查
输入是现象描述与证据材料。动作是按字段表逐项填写，标题写清位置与表现，复现步骤编号，影响范围落到用户、业务、数据、时间四个维度，紧急程度只写事实线索。输出是一份完整记录。完成标志：对照后文检查清单，阻断项全部通过。
第四步：提交后跟踪受理状态
输入是已提交的记录。动作是关注受理状态，受理人要求补充信息时在原记录中追加日志、截图或复现结果，不另起新单。输出是信息完整的受理记录。完成标志：记录进入已受理状态，或已明确补充项并完成追加。
提单人、受理人与处置人的角色分工
三个角色各自交付不同产物，职责边界清楚，记录才不会在交接中丢失信息。提单人对事实负责，受理人对流转负责，定级与处置角色对判断和修复负责。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 提单人 | 记录现象、环境、复现步骤、影响范围与证据，标注待补充项 | 字段完整、证据可追溯的缺陷记录 |
| 受理人 | 查重、确认信息是否达到受理标准、受理并转派给对应处置角色 | 受理结论、查重结果、转派记录 |
| 定级与处置角色 | 按分类分级规则判断严重程度与优先级，安排修复与验证 | 定级结论、处置安排、修复与验证结果 |
交接环节需要回执。受理人受理后应告知提单人记录已进入处理，或说明退回补充的具体字段；处置角色接手后如需更多信息，应指明需要哪类证据，由提单人在原记录中补充。提单人收到补充要求后追加材料并回复，形成一次完整交接，避免信息散落在聊天工具里。
在ONES中，这类记录可以由缺陷工作项承载：ONES Project 适配缺陷管理等场景，支持一键提交 Bug 至对应项目或迭代，用于记录和跟踪缺陷修复情况，并可统计缺陷状态分布；由测试用例执行结果发起的缺陷，也可在ONES TestCase 中从未通过用例快速创建缺陷任务，在测试与研发团队间流转。提单字段、证据附件与状态变化放在同一条工作项里，受理、转派与补充信息都留在这条记录上，交接时不必再拼接多个来源。
一个线上缺陷提单的完整示例
以下为演示情景，用于说明字段如何落地，不代表真实业务数据。背景：某电商系统在促销活动开始后，部分用户在订单详情页点击“提交订单”无响应，客服陆续收到反馈。
| 字段 | 填写内容 |
|---|---|
| 标题 | 订单详情页点击“提交订单”后按钮无响应，订单未生成 |
| 现象描述 | 用户在订单详情页点击“提交订单”，按钮点击后无加载提示，页面停留原处，订单列表中没有新订单。浏览器控制台出现一条接口超时错误。 |
| 环境与版本 | 生产环境；Web端 v3.8.2；Chrome 与 Safari 均有出现；移动端暂未收到反馈 |
| 复现步骤 | 1. 使用普通买家账号登录；2. 将一件参与活动的商品加入购物车；3. 进入结算页并选择默认收货地址；4. 在订单详情页点击“提交订单”；5. 观察按钮状态与订单列表 |
| 期望结果 | 点击后进入支付流程，订单列表生成待支付订单 |
| 实际结果 | 按钮无响应，无报错提示，订单未生成；控制台显示提交接口超时 |
| 影响范围 | 活动商品下单流程受阻；客服已收到多条同类反馈，涉及不同地区用户；未发现错误订单数据；首次反馈时间为活动开始后约10分钟，目前仍在持续 |
| 证据附件 | 操作录屏一段；控制台错误截图；提交接口请求与超时响应记录；客服反馈汇总截图，均标注发生时间 |
| 紧急程度线索 | 核心下单流程受阻，反馈持续增加，暂无替代下单路径 |
逐项看填写理由：标题把位置和表现写在一起，受理人一眼能判断问题类型；复现步骤包含账号类型和数据条件，他人可以跟随操作；影响范围写清了业务受阻点、反馈来源和时间窗口，为定级提供事实依据；紧急程度只描述受阻程度和反馈趋势，级别判断留给受理与定级角色。可改进之处是补充一条成功下单的对照记录，帮助处置角色判断问题是否与活动商品配置相关。
提交后的自查与完成检查
提交前和提交后各做一次核对，判断这份记录是否达到可受理标准。以下检查项中，标注为阻断项的任何一项未通过，都应先补充再提交或推动补充。
- 字段完整性（阻断项）：标题、现象、环境与版本、复现步骤、期望与实际结果、影响范围均已填写，无空白关键项；
- 可复现性（阻断项）：复现步骤可被他人跟随执行，或已明确说明暂未复现及已知触发条件；
- 证据可追溯（阻断项）：附件与日志带时间标记，能与现象描述中的时间点对应；
- 影响范围具体：用户、业务、数据、时间窗口四个维度均有描述，未使用“影响较大”一类笼统表述；
- 紧急线索与定级分离：只写客观事实，未自行标注严重程度级别；
- 重复提单处理：提交前检索同类记录，已有相同问题时在原记录中补充信息，不另起新单；
- 信息冲突处理：新证据与已填内容不一致时，在原记录中更新并说明变更原因，保留旧信息的时间标记。
未通过检查时的补充动作按优先级排列：先补证据和时间点，再补复现步骤，最后完善影响范围描述。补充完成后重新对照阻断项核对一遍，确认记录可以被受理人直接判断，而不需要再次向提单人追问基础事实。
常见问题
线上问题还在持续、证据暂时收集不全，应该先提交还是等齐了再提？
按信息对受理判断的影响程度决定。现象、发生时间、影响范围这类关键事实已经能说清时，可以先提交，并在记录中标注待补充项和已知边界，例如“仅收到一位用户反馈，暂未复现，附用户操作截图”，受理人据此判断信息的可靠程度。
如果缺少的是定位所必需的证据，例如报错日志、请求响应内容，且这些材料仍可获取，先收集再提交更合适。无论哪种情况，都不要用推测把字段填满，把不确定的内容写成确定结论会误导后续定级与处置。
提单人填了紧急程度线索，受理人还会重新定级吗？
会。紧急程度线索是提单人提供的客观事实，例如核心流程受阻、反馈持续增加、暂无替代路径；严重程度与优先级的正式判定属于分类分级规则，由受理与定级角色完成。两者分开填写，受理人才能复核线索是否成立，避免定级变成对提单人判断的确认。
提单时把受阻的业务操作、受影响用户规模、是否仍在持续、有无临时绕行方案写清楚，比直接标注级别更有助于定级角色判断。
提交后发现信息写错了，或者又拿到了新证据，应该怎么处理？
在原记录中更新，并说明变更原因，保留旧信息的时间标记。新证据与已填内容冲突时，写清哪一项被修正、依据是什么，让受理人能看到信息变化的过程。
被受理人要求补充信息时同样在原记录中追加日志、截图或复现结果，不另起新单。另起新单会造成同一问题出现多条记录，查重和状态跟踪都会变得困难。
提单前检索到已有同类记录，还需要再提一单吗？
不需要另起新单。在已有记录中补充你掌握的信息，例如新的复现条件、不同终端上的表现、新增的用户反馈，让受理人看到问题的影响在扩大或条件在变化。
如果确认是不同问题，例如位置相同但表现和触发条件不同，再单独提交，并在标题和现象描述中写清与已有记录的区别，方便受理人查重时区分。
线上缺陷记录和需要立即响应的服务中断，走同一个入口吗？
两者目的不同。线上缺陷记录关注把已发生的异常写成可复现的事实，供后续定位与修复；服务中断的通报与恢复属于服务事件受理，是另一套响应机制。发现异常时先判断当前更需要恢复服务还是记录缺陷，需要立即恢复的按服务事件流程通报，同时保留现象与时间点，待恢复后再补缺陷记录。
严重程度判定不在提单环节完成，提单人只需把受阻程度、影响范围和持续时间写成事实。
