缺陷摘要的价值在于让接手的人快速判断“出了什么问题、在什么条件下出现、影响多大、下一步查哪里”。把标题、复现步骤、日志和讨论记录整理成摘要，可以按一条可复核的加工流程来做：先固定输入字段，再按“现象—触发条件—影响范围—定位线索”四段抽取，由模型生成初稿，最后由缺陷提出人或模块负责人按清单核对后回写。输入齐全、规则明确、复核有清单，是这条流程稳定运行的前提。
要点总览（TL;DR）
- 缺陷摘要固定为现象、触发条件、影响范围、定位线索四段，每段对应标题、复现步骤、日志、讨论记录等固定输入，模型抽取有目标，人工复核有对照。
- 生成初稿分五步：整理输入字段、按来源抽取、带约束生成初稿、处理讨论记录、提交复核；错误码、堆栈、版本号保留原文，未确认判断标注待核实。
- 复核按角色分工：缺陷提出人核对现象与可复现性，模块负责人核对定位线索，测试负责人核对影响描述与敏感信息；任一项不通过退回初稿状态并记录原因。
- 上线前逐项检查输入字段、抽取规则、提示词约束与复核留痕位置；上线后按周或按迭代抽检摘要质量，提示词与抽取规则按版本维护。
缺陷摘要要写清哪四段内容
缺陷摘要建议固定为四段：现象、触发条件、影响范围、定位线索。四段各回答一个问题，读者按顺序读下来就能形成处理判断。结构固定后，模型抽取有明确目标，人工复核也有对照物。
| 段落 | 回答的问题 | 主要信息来源 | 写法要求 |
|---|---|---|---|
| 现象 | 用户或系统实际表现是什么 | 缺陷标题、讨论记录中的现象描述 | 一句话说清可观察到的异常表现，避免只写“有问题”“异常” |
| 触发条件 | 在什么操作路径、数据、环境下出现 | 复现步骤、版本号、环境信息 | 按步骤顺序压缩为关键前置条件，保留必要的数据特征 |
| 影响范围 | 影响哪些用户、功能、数据或流程 | 讨论记录、关联需求或工单、提出人补充 | 区分已确认影响和推测影响，推测部分标注待核实 |
| 定位线索 | 日志、错误码、堆栈指向哪里 | 日志片段、错误码、堆栈信息 | 保留原文，不做转述或归纳 |
长度上，一条缺陷摘要控制在四到八句或一个短段落加若干要点即可。判断详略的标准是：接手人能否据此决定是否复现、找谁确认、先查哪个模块。与这三点无关的背景叙述可以删去。复现步骤特别长时，摘要只保留触发缺陷的最小路径，完整步骤留在原字段中供查阅。
错误码、堆栈片段、版本号、环境标识、接口返回原文必须保留原样，不做改写或翻译。现象描述可以压缩措辞，但不能改变事实方向，例如把“偶发失败”写成“必现失败”就属于改变事实。讨论记录中未经确认的猜测，进入摘要时要标注“待核实”，与已确认信息区分开。
从标题、复现步骤和日志抽取摘要的操作步骤
生成初稿可以拆成五步，每步都有明确的输入、动作、输出和完成标志。按步骤推进，能避免把不完整的信息直接交给模型自由发挥。
第一步：整理输入字段
输入包括标题、复现步骤、日志片段和讨论记录。标题要规范化，去掉“紧急”“帮忙看下”这类与缺陷本身无关的词，保留模块名和异常表现。复现步骤按操作顺序拆成编号步骤，每步只写一个动作和一个观察结果。日志截取与缺陷时间点相关的片段，保留错误码、异常堆栈和关键上下文行，去掉大段无关输出。完成标志是四类输入都能在缺陷记录中找到对应位置，且日志片段能对应到复现步骤中的某一步。
第二步：按字段执行抽取
抽取规则按来源分工：从标题取现象，从复现步骤取触发条件，从日志取错误码与堆栈线索，从讨论记录取影响范围和已确认的补充信息。抽取时逐段标注来源，便于复核时回溯。完成标志是四段内容都有对应来源，缺失的段落明确标为“待补充”，不用推测内容填充。
第三步：生成初稿
提示词需要包含四项要素：输出结构（四段式及每段一句话要求）、长度上限、必须保留原文的字段清单（错误码、堆栈、版本号、环境）、禁止项。禁止项至少包括：不得编造未出现的错误码和堆栈、不得把推测写成结论、不得省略复现步骤中的关键前置条件、不得改写日志原文。完成标志是初稿四段齐全，保留字段与原文一致，无来源的内容没有出现在摘要中。
第四步：处理讨论记录
讨论记录只补充两类信息：已由多人确认的影响描述，以及提出人补充的环境或数据条件。开发人员的初步判断可以作为定位线索的候选，但要标注为“初步判断”。与当前缺陷无关的讨论、重复确认的内容不进入摘要。完成标志是摘要中每条补充信息都能指回具体讨论内容。
第五步：提交复核
初稿完成后不直接写入缺陷库，转入复核环节。完成标志是初稿状态标记为“待复核”，并指派到具体复核人。
人工复核环节怎么设计
复核的作用是拦住事实错误和敏感信息，让摘要达到可流转的质量。角色分工按“谁最接近信息源”来安排，避免所有核对压到一个人身上。
| 角色 | 核对内容 | 核对依据 |
|---|---|---|
| 缺陷提出人 | 现象描述是否准确、复现步骤是否可执行、影响范围是否符合实际 | 原始操作记录和业务场景 |
| 模块负责人 | 定位线索是否指向合理模块、日志片段是否完整、初步判断是否被误写成结论 | 代码模块归属和日志上下文 |
| 测试负责人 | 影响描述是否夸大或遗漏、敏感信息是否已处理、摘要格式是否符合团队规范 | 缺陷分级规则和脱敏要求 |
复核时点分两处：提交前复核，由提出人或测试负责人确认摘要可以进入缺陷库；流转中复核，缺陷转给开发处理时，模块负责人对定位线索做一次确认。两处复核的核对项不同，提交前侧重事实与可复现性，流转中侧重定位方向。
核对清单可以固定为四项：事实准确性（现象、条件、影响与原始记录一致）、可复现性（按摘要中的触发条件能走通复现路径）、影响描述（已确认与待核实分开标注）、敏感信息（账号、密钥、用户数据已脱敏或移除）。任一项不通过，摘要退回初稿状态，由原生成人或提出人修改后重新提交，退回原因记录在缺陷讨论中。
复核记录要留痕：谁复核、复核时间、修改了哪一段、退回原因。留痕方式可以直接使用缺陷工作项的评论或状态变更记录，保证摘要版本和复核意见能对应上。
一个完整示例：从原始缺陷到复核通过的摘要
以下为演示情景，用于说明流程，不对应真实项目数据。
原始输入
标题：“订单导出偶发失败，帮忙看下”。复现步骤：进入订单列表，筛选近七天订单，点击导出，等待约十秒后提示导出失败；重复三次出现两次。日志片段包含错误码 EXPORT_TIMEOUT_504 和一段导出服务的超时堆栈。讨论记录中，提出人补充“大促期间订单量大的账号更容易出现”，开发人员回复“可能是导出任务队列积压，待确认”。
模型初稿
现象：订单导出功能偶发失败。触发条件：在订单列表筛选近七天订单后执行导出。影响范围：大促期间订单量大的账号受影响更明显。定位线索：日志出现 EXPORT_TIMEOUT_504，导出服务超时堆栈，疑似任务队列积压。
复核发现的问题
提出人指出“偶发失败”应写明三次出现两次的频次，否则接手人无法判断严重程度；模块负责人指出“疑似任务队列积压”来自讨论中的未确认判断，应标注待核实，不能与日志事实并列；测试负责人指出影响范围中“大促期间”属于提出人观察，需标注为待验证的观察结论。
复核通过的最终摘要
现象：订单导出在等待约十秒后提示失败，三次操作出现两次。触发条件：订单列表筛选近七天订单后点击导出。影响范围：提出人观察到大促期间订单量大的账号更易出现，影响面待验证。定位线索：日志错误码 EXPORT_TIMEOUT_504，导出服务超时堆栈；开发初步判断可能为导出任务队列积压，待核实。
这个示例体现的规律是：频次、环境、数据特征这类信息要写进摘要才有判断价值；讨论中的判断与日志事实要分层标注；观察性结论标注待验证，避免被下游当成定论。
上线前检查与持续维护
流程上线前，先逐项核对输入和产出是否稳定，再安排抽检和版本维护。
上线检查清单
- 缺陷模板中标题、复现步骤、日志、讨论记录四个字段是否都有固定位置和填写要求。
- 抽取规则是否覆盖四段来源，缺失段落是否有“待补充”标记方式。
- 提示词是否包含输出结构、长度上限、保留原文清单和禁止项。
- 复核角色是否已指派到人，核对清单是否随缺陷模板一起可见。
- 退回与修改规则是否明确，复核记录是否有固定留痕位置。
- 敏感信息处理要求是否写入复核清单。
质量抽检与维护
摘要质量抽检可以按周或按迭代进行，每次抽取一定数量的已复核缺陷，检查四段是否齐全、保留字段是否与原文一致、待核实标注是否规范。抽检发现的高频问题，回流到提示词或抽取规则中修正。提示词和抽取规则按版本管理，每次修改记录修改原因和生效时间，避免不同时期的摘要口径混杂。
常见失败情形及处理：输入字段缺失时，摘要标为待补充并退回补充信息，不用推测填充；日志片段过长导致模型抓错重点时，收窄截取范围到缺陷时间点前后；讨论记录中的猜测被写成结论时，在复核清单中增加“判断与事实分层”检查项；摘要格式不统一时，检查提示词中的结构约束是否被执行。
流程落地需要缺陷工作项承载输入字段、初稿状态、复核记录和回写结果。ONES 的缺陷管理与工作项协作可以承担这一层：缺陷记录本身保存标题、复现步骤和日志附件，讨论记录保留补充信息，状态流转对应“待复核—复核通过—回写”的节点。ONES Assistant 能理解项目、工作项和 Wiki 页面等工作上下文，并可将自然语言指令转化为创建缺陷、更新状态、通知负责人等操作，适合把摘要初稿的生成和状态更新放进同一条工作流；其 AI 能力基于 ONES 权限体系执行，输出过程可追踪、结果可审计，便于复核留痕。具体到单条缺陷摘要的生成入口和字段映射，需按团队实际配置核验后再确定操作方式。
常见问题
缺陷标题写得很笼统，比如只有“导出失败”，还能生成合格摘要吗？
可以生成初稿，但摘要质量会受限于输入。标题笼统时，现象段只能写到“导出失败”这一层，触发条件和影响范围需要从复现步骤和讨论记录中补。建议在整理输入阶段先做标题规范化：保留模块名和异常表现，去掉“紧急”“帮忙看下”这类无关词。如果复现步骤和日志也缺失，摘要中对应段落标为“待补充”并退回补充信息，不用推测内容填充。
日志很长，截取多少合适？截多了模型抓不住重点，截少了又怕漏线索。
截取范围以缺陷发生时间点为中心，保留错误码、异常堆栈和关键上下文行，去掉大段无关输出。判断标准是：截出的片段能对应到复现步骤中的某一步，且能支撑定位线索段。如果日志中同一错误反复出现，保留首次出现和最后一次出现的片段即可。截取后可以在摘要中注明日志片段对应的时间范围，方便复核人回查完整日志。
讨论记录里开发人员说“可能是队列积压”，这种判断能写进摘要吗？
可以写，但要与日志事实分层标注。日志中的错误码和堆栈属于已确认事实，讨论中的判断属于初步判断，摘要中应写成“开发初步判断可能为……，待核实”，不能与事实并列成结论。复核时模块负责人重点核对这一点，避免下游把推测当成定论去排查。多人确认过的判断可以提升为已确认信息，但仍需注明确认来源。
复核环节会不会拖慢缺陷流转？小缺陷也要走完整复核吗？
复核时点可以分两处：提交前复核和流转中复核。提交前复核由提出人或测试负责人确认摘要可进入缺陷库，流转中复核由模块负责人在缺陷转给开发时确认定位方向。对于影响范围小、复现路径清晰的缺陷，可以只保留提交前复核，核对事实准确性和敏感信息两项；涉及多模块或影响面大的缺陷，两处复核都保留。复核清单可以按缺陷分级调整核对项数量，不必所有缺陷套用同一套完整流程。
摘要生成和复核的流程怎么落到缺陷管理工具里？
流程落地需要缺陷工作项承载四类输入字段、初稿状态、复核记录和回写结果。ONES 的缺陷管理与工作项协作可以承担这一层：缺陷记录保存标题、复现步骤和日志附件，讨论记录保留补充信息，状态流转对应“待复核—复核通过—回写”的节点。ONES Assistant 能理解项目、工作项和 Wiki 页面等工作上下文，并可将自然语言指令转化为创建缺陷、更新状态、通知负责人等操作，适合把摘要初稿的生成和状态更新放进同一条工作流；其 AI 能力基于 ONES 权限体系执行，输出过程可追踪、结果可审计，便于复核留痕。具体到单条缺陷摘要的生成入口和字段映射，需按团队实际配置核验后再确定操作方式。
