缺陷提交的质量取决于三件事：一份固定字段的缺陷记录模板、提交前由提交人完成的自检、以及缺陷受理人对信息完整性的回退规则。本文给出可直接套用的字段表、提交步骤、角色分工和检查清单，只处理缺陷记录本身怎么写；严重程度判定归缺陷分类与分级，服务事件受理归服务事件与问题管理。
要点总览（TL;DR）
- 缺陷记录按固定字段模板填写：标题写现象+对象+条件，复现步骤从初始状态写起且他人可照做，环境信息细到能重建现场，证据附件按能证明现象的最小集合提交。
- 提交流程分六步：提交前自查、检索重复缺陷、一次性补全字段、提交并通知、受理确认、补充与回退，每步都有明确的完成标志。
- 提交人对事实负责，模块负责人确认归属与复现，缺陷受理人校验完整性并执行退回或分派，三者交接同一条记录。
- 规范落地靠提交前自检清单和固定的退回标准，用退回率、平均补充次数、提交到受理时长等信号按月观察效果。
- 严重程度只写建议值和理由，最终等级由分级流程判定；服务事件受理不在本文范围。
缺陷提交要写清哪些字段
缺陷记录的价值在于让未参与发现过程的人也能独立复现问题。字段设计围绕这个目标展开：凡是复现所必需的信息设为必填，凡是帮助判断影响范围的信息设为选填。字段一旦固定，提交人每次按同一顺序填写，受理人也能按同一顺序校验，减少来回追问。
下表给出一套通用字段模板，可按产品形态调整字段名，但必填与选填的划分建议保持稳定。
| 字段名 | 是否必填 | 填写要求 | 反例 |
|---|---|---|---|
| 标题 | 必填 | 现象+对象+触发条件，一句话可读，控制在30字左右 | “页面有问题”“登录失败” |
| 复现环境 | 必填 | 版本号、操作系统与浏览器/客户端版本、测试环境或生产环境、账号类型与关键配置 | “测试环境” |
| 复现步骤 | 必填 | 从初始状态开始，按操作顺序编号，每步一个动作，最少3步，包含数据准备 | “正常操作后报错” |
| 预期结果 | 必填 | 依据需求文档或业务规则说明应该发生什么 | “应该正常” |
| 实际结果 | 必填 | 客观描述观察到的现象，含报错文案或错误码，不加推测性结论 | “系统崩了” |
| 复现频率 | 必填 | 写明尝试次数与出现次数，如“5次尝试出现3次” | “偶尔出现” |
| 严重程度建议 | 必填 | 提交人给出建议值并附一句理由，最终等级由分级流程判定 | 直接写“P0，必须马上修” |
| 证据附件 | 必填（有则附） | 日志片段、截图、录屏，按能证明现象的最小集合提交 | 上传整段几小时的录屏 |
| 影响范围 | 选填 | 受影响的用户群体、模块或数据，便于判断波及面 | — |
| 关联需求或工单 | 选填 | 指向对应的需求编号、历史缺陷或客户工单 | — |
| 发现来源 | 选填 | 测试、线上监控、客户反馈等，帮助判断场景真实性 | — |
标题写法决定检索效率。合格标题包含三个要素：现象、对象、条件。例如“结算页点击提交后提示‘库存不足’，仅当购物车含预售商品时出现”，读者不看正文也能判断是否与自己遇到的问题相同。笼统标题会让重复缺陷检索失效，也让受理人无法分派。
复现步骤要写成别人能照着执行的动作序列。第一步交代初始状态和数据准备，中间步骤只写一次操作，最后一步指向现象出现的位置。步骤过少往往遗漏前置条件，步骤过多则混入了无关操作，建议控制在3到8步，把与现象无关的浏览、切换动作删掉。
预期结果与实际结果要成对出现，并且指向同一观察点。预期结果引用需求条款或业务规则，实际结果只记录看到的内容，包括完整报错文案和错误码。把“可能是缓存问题”这类推测写进实际结果，会干扰后续定位，推测可以放在备注里并标明是猜测。
环境信息要细到能重建现场。版本号精确到构建号，客户端写明操作系统与版本，Web端写明浏览器与版本，同时注明数据状态，例如账号权限、开关配置、测试数据量。环境写得含糊，开发往往需要先花时间还原环境才能开始定位。
证据附件的取舍标准是“能证明现象且便于查看”。日志截取报错前后各若干行并保留时间戳，截图圈出异常位置，录屏只保留复现的那一段并配一句文字说明。附件过多会淹没关键信息，附件缺失则让受理人只能退回。
严重程度一栏只写建议值和理由。提交人最了解现象对业务的影响，给出建议有助于分级，但最终等级由缺陷分级流程结合影响面、发生频率和业务优先级判定。提交人把建议写成结论，容易在分级会上产生争议，也不利于后续统计口径统一。
从发现缺陷到进入待处理：提交操作步骤
字段表解决写什么，提交流程解决按什么顺序写、什么时候算完成。下面把提交拆成六个步骤，每步都有明确的输入、动作、输出和完成标志，提交人可据此判断自己是否已经做完。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 提交前自查 | 已观察到的现象、手头日志与截图 | 按检查清单逐项核对，补做一次干净环境下的复现 | 可稳定复现的操作序列 | 能连续两次按步骤复现，或已记录复现频率 |
| 2. 检索重复缺陷 | 标题关键词、模块名、报错文案 | 在缺陷库按关键词和模块检索，查看相似记录 | 检索结论：新增或补充已有记录 | 确认无重复，或在已有记录下追加复现信息 |
| 3. 一次性补全字段 | 字段模板 | 按必填字段顺序填写，选填字段有信息则填 | 完整缺陷记录草稿 | 所有必填字段无空项，附件已上传 |
| 4. 提交并通知 | 缺陷记录草稿 | 提交记录，按约定渠道通知模块负责人或受理人 | 状态为“待受理”的缺陷记录 | 记录已生成编号，通知已送达 |
| 5. 受理确认 | 待受理记录 | 受理人校验完整性与归属，确认受理或退回 | 受理结论与分派结果 | 状态变为“待处理”，或收到退回原因 |
| 6. 补充与回退 | 退回原因 | 按退回项补充信息后重新提交，保留原记录编号 | 补充后的记录 | 补充项全部关闭，记录重新进入受理 |
自查环节最容易省略，也最影响后续效率。提交人应在提交前用干净账号或新会话再走一遍步骤，确认现象不依赖本地缓存或临时数据。若现象无法稳定复现，也要如实记录尝试次数和出现次数，并附上出现时的日志，这比强行编造步骤更有价值。
重复缺陷检索要覆盖三种线索：标题关键词、报错文案原文、模块与版本组合。检索到相似记录时，优先在已有记录下补充自己的环境和复现信息，由受理人判断是否合并。直接新建相似记录会分散讨论，也让修复验证缺少统一出口。
受理确认是流程的分水岭。受理人按完整性标准逐项校验，信息齐全则确认受理并分派给模块负责人；信息不足则退回，并在退回原因中写明缺哪一项、需要什么形式的补充。退回不是否定提交人的工作，而是把补充动作明确到具体字段，避免“再补充一下”这类模糊要求。
补充与回退要保留原记录编号。提交人按退回项逐条补充，补充完成后在记录中说明改了什么，再重新提交受理。若补充过程中发现现象与最初描述不一致，应更新实际结果并说明变化，而不是另开一条记录，保持问题线索的连续性。
缺陷记录需要承载字段、附件和状态流转，ONES 工作项可以按上述字段配置缺陷类型，提交后通过状态从“待受理”流转到“待处理”，退回时在记录中留下原因，提交人补充后在同一工作项内重新提交，受理与分派动作都落在同一条记录上。
提交人、模块负责人与缺陷受理人的分工
缺陷提交环节涉及三类角色，职责边界清晰，信息缺口就不会被推给下游。提交人对事实负责，模块负责人对归属与可复现性负责，受理人对完整性负责。三者交接的是同一条记录，交接物明确，责任就不会悬空。
| 角色 | 核心职责 | 交付物 | 交接对象 |
|---|---|---|---|
| 提交人 | 记录观察到的事实：现象、步骤、环境、证据，给出严重程度建议 | 字段完整的缺陷记录与附件 | 缺陷受理人 |
| 模块负责人 | 确认缺陷归属模块，判断是否可复现，补充技术侧线索 | 归属结论与复现确认意见 | 缺陷受理人、修复负责人 |
| 缺陷受理人 | 校验信息完整性，执行退回或受理，完成分派 | 受理结论、退回原因、分派结果 | 提交人、模块负责人 |
提交人负责的是事实性信息，包括看到了什么、在什么环境、按什么步骤、出现几次。提交人不需要判断根因，也不需要在记录中给出修复方案，把推测写成结论反而会误导定位。提交人需要保证的是：任何人拿到这条记录，都能按步骤走到现象出现的位置。
模块负责人负责归属与复现确认。收到记录后，模块负责人判断问题是否属于本模块，若不属于则说明应转给哪个模块；若属于则尝试复现，复现成功补充技术线索，复现失败则说明差异点，请提交人补充环境或数据。模块负责人的确认意见是分派和排期的依据。
缺陷受理人负责完整性校验与退回。校验按必填字段逐项进行，缺项即退回并写明补充要求；字段齐全则确认受理，按模块归属分派。受理人还要处理重复缺陷的合并判断，把相似记录归并到同一条主记录下，避免同一问题多处讨论。
响应时限需要团队事先约定，例如受理人在一个工作日内完成受理或退回，模块负责人在两个工作日内给出归属与复现结论，提交人在收到退回后一个工作日内完成补充。时限写进团队约定即可，具体数值按业务节奏调整，关键是每个交接点都有明确的等待上限，避免记录长期停在“待受理”。
一个完整的缺陷提交示例
下面用一条订单模块的缺陷记录示范字段如何落地。示例为演示情景，数据为虚构，写法可直接迁移到其他模块。
标题：订单详情页点击“再次购买”后提示“商品已下架”，仅当原订单含赠品时出现。
复现环境：客户端 3.8.2（构建号 20240612），iOS 17.4，生产环境，普通会员账号，原订单包含一件主商品和一件赠品。
复现步骤：
- 使用测试账号登录，进入“我的订单”，找到含赠品的已完成订单。
- 进入订单详情页，点击“再次购买”。
- 观察页面提示与购物车状态。
预期结果：主商品加入购物车并跳转购物车页，赠品按活动规则提示是否加购。
实际结果：页面弹出提示“商品已下架”，购物车未新增任何商品，主商品详情页可正常访问。
复现频率：5次尝试出现5次；不含赠品的订单执行同样操作正常。
严重程度建议：建议中高，理由是影响复购入口，且仅涉及含赠品订单，附一句说明供分级参考。
证据附件：操作录屏一段（约20秒，覆盖三步操作）、提示弹窗截图一张、接口返回日志一段（含请求时间与错误码）。
对比修改前的写法：原标题为“再次购买报错”，修改后补充了对象（订单详情页的再次购买）、现象（提示商品已下架）和条件（原订单含赠品）。原步骤只有“点再次购买就报错”，修改后交代了账号、订单类型和观察点，开发可直接按步骤复现。附件从整段录屏改为覆盖复现的短录屏加日志，受理人查看成本明显下降。
这条示例体现的写法规律可以迁移：标题用“条件+对象+现象”的结构；步骤从数据准备写起，最后一步落在观察点；预期与实际指向同一个页面元素；附件按“能证明现象的最小集合”选取；严重程度只给建议并附理由。换到支付、登录或报表模块，这套结构同样适用，只需替换对象和观察点。
提交前检查清单与规范落地
规范是否生效，取决于提交前有没有人逐项核对，以及受理环节有没有稳定的退回标准。检查清单让提交人自己完成第一道校验，退回标准让受理人有一致的判断依据，两者配合才能把字段模板变成日常动作。
提交前自检清单，逐项勾选后再提交：
- 标题是否包含现象、对象和触发条件，能否被关键词检索到。
- 复现步骤是否从初始状态写起，每步一个动作，他人可照做。
- 预期结果是否引用了需求或业务规则，实际结果是否只写观察到的现象。
- 环境信息是否包含版本号、系统或浏览器版本、环境类型和关键数据状态。
- 复现频率是否写明尝试次数与出现次数。
- 严重程度是否只写建议值并附一句理由。
- 附件是否覆盖现象且便于查看，日志是否保留时间戳和错误码。
- 是否已检索重复缺陷，确认无重复或已在已有记录下补充。
受理环节的退回判断标准同样要固定：必填字段缺任意一项即退回；复现步骤无法照做即退回；实际结果只有结论没有现象描述即退回；附件无法打开或与现象无关即退回。退回时写明缺项和补充形式，例如“请补充出现时的接口日志，含请求时间和错误码”，避免只写“信息不全”。
规范生效可以从几个可观察信号判断：退回率是否下降，单条缺陷的平均补充次数是否减少，从提交到受理的时长是否缩短，重复缺陷新建数量是否下降。这些信号按月看趋势即可，不必追求单条数据的精确，重点是观察规范执行后补充往返是否变少。
规范本身也需要维护。字段模板随产品形态变化调整时，同步更新检查清单和退回标准；每季度回看一次退回原因分布，若某一字段反复成为退回原因，说明填写要求写得不够具体，应补充示例而不是增加字段。模板变更后通知提交人和受理人，并在缺陷库中保留变更记录，保证新旧记录的统计口径可对照。
在工具层面，ONES 工作项可以把必填字段设为提交时的校验项，缺项无法提交；状态流转记录受理、退回和补充的全过程，退回原因留在记录中可供季度回看；附件与日志随工作项保存，受理人校验时在同一页面完成。这样字段规范、检查清单和退回标准就落在同一条记录上，规范执行情况也能从状态流转中直接观察。
常见问题
缺陷无法稳定复现时，还要不要提交？
要提交，但写法要调整。无法稳定复现时，把复现频率写清楚，例如“5次尝试出现2次”，并附上出现时的日志和截图，说明尝试的环境与数据条件。复现步骤按你实际操作的顺序写，同时注明哪一步之后现象开始出现、哪一步不一定触发。受理人收到这类记录后，会请模块负责人尝试复现并补充技术线索。把不稳定复现的情况如实写出来，比编造一套看起来完整的步骤更有助于定位。
提交人给出的严重程度建议和最终分级不一致，怎么处理？
这是正常情况。提交人的建议值反映的是自己观察到的业务影响，最终等级由分级流程结合影响面、发生频率和业务优先级判定。出现不一致时，受理人或分级负责人应在记录中说明调整理由，提交人如有补充信息可以在同一记录下追加。团队可以定期回看建议值与最终等级的偏差分布，如果某一类缺陷经常被低估或高估，说明分级标准或填写说明需要补充示例，而不是要求提交人少提建议。
检索到相似缺陷时，新建记录还是在已有记录下补充？
优先在已有记录下补充。补充内容包括你的环境信息、复现频率和附件，由受理人判断是否合并到主记录。判断是否算重复，看的是现象和触发条件是否指向同一个问题，标题相似但触发条件不同的，应作为新记录提交并在关联字段中指向已有记录。直接新建相似记录会分散讨论，修复验证也缺少统一出口。
退回后补充信息，需要重新开一条缺陷记录吗？
不需要，保留原记录编号。按退回原因逐条补充，补充完成后在记录中说明改了什么，再重新提交受理。如果补充过程中发现现象与最初描述不一致，更新实际结果并说明变化原因，保持问题线索连续。另开新记录会让原记录停在退回状态，也切断了从发现到受理的过程记录。
字段模板定好之后，多久需要调整一次？
没有固定周期，按触发条件调整。常见触发条件包括：产品形态变化导致环境信息需要新增维度；某一字段反复成为退回原因，说明填写要求不够具体；团队发现某些必填字段对复现没有实际帮助。调整时同步更新检查清单和退回标准，并通知提交人和受理人。建议每季度回看一次退回原因分布，用数据判断是补示例还是改字段，避免字段越加越多。
