Bug / 缺陷问题教程：产品经理实操方法，避坑指南

一条缺陷单写着“支付失败，尽快修复”，开发改了两天，测试仍然复现；另一条只影响少数用户的重复扣款，却被标成普通问题，直到客服升级才进入处理队列。Bug 管理最容易踩的坑，不是不会填单，而是把“记录问题”误当成“推动问题闭环”。我处理这类问题时，先判断用户影响和证据是否足以支持决策，再决定谁来处理、何时处理、怎样确认修复有效。

一、先讲结论：缺陷管理的核心是降低决策成本

1. 一张好缺陷单，应该让团队能做出下一步决定

缺陷单不是事后存档，也不只是开发的待办事项。它的价值在于让产品、研发、测试和客服对同一件事形成可执行的共识：发生了什么、影响谁、影响多大、如何复现、谁负责判断、什么条件下算修好。

如果团队打开一条缺陷后，还要在群聊里追问“哪个环境”“用户到底做了什么”“是不是已经有人修过”，这条记录就没有完成它的工作。字段写得再多，也不能弥补关键信息缺失。

我的判断原则是：缺陷单要尽可能减少下一位处理者的猜测，而不是尽可能增加填写者的负担。因此，流程不应该从“必填字段有多少”开始设计，而应该从“下一步决策需要什么证据”倒推。

2. 先分清严重程度、处理优先级和修复时限

团队经常把“严重”“紧急”“优先级高”混成一个标签，结果每个人理解都不一样。严重程度描述故障造成的影响，优先级表达团队当前的处理顺序，修复时限则是团队对响应或解决时间的承诺。三者有关联，但不能互相替代。

ISTQB 术语体系也区分缺陷造成的影响程度与处理上的优先顺序。这个区分对产品团队很实用：一个影响范围很小的问题，可能因为合规窗口而需要先处理；一个影响很多用户的问题，如果存在稳定绕行方案，也可能先进入评估而不是立即打断发布。

3. 流程要形成闭环，而不是把状态做得越来越多

一个可用的基础闭环通常包含：提交、补充信息、确认、分级、分派、修复、验证、发布观察和关闭。状态名称可以因团队而异，关键是每次状态变化都应有明确责任人和进入条件。

例如，“已解决”不等于“已关闭”。前者通常表示研发认为修复已完成，后者表示测试或产品验证满足约定条件。如果团队把二者合并，回归失败、版本未发布和验证环境不一致等情况就容易被误判为已经结案。

二、真实工作场景：为什么“报了 Bug”不代表问题被管理

1. 一线反馈往往是现象，不是可直接执行的诊断

产品经理收到的第一句话通常很短：“页面坏了”“刚才点不了”“客户说数据不对”。这类反馈有价值，因为它指出了用户受阻的位置；但它通常还不足以支持研发定位。复述用户原话可以保留语境，却不能替代复现证据。

我会先把原始反馈拆成四部分：用户目标、实际结果、出现条件和影响范围。比如“客户导出失败”要继续问：导出的是什么数据、筛选条件是什么、是否所有账号都失败、失败时有没有提示、是否换浏览器仍然发生、有没有成功过的样本。

这些问题不是为了让提交人写一篇事故报告，而是为了排除会改变处理方向的条件。一个只在大数据量下出现的超时，和一个所有用户都打不开导出入口的问题，可能表面相似，实际责任模块和风险优先级完全不同。

2. 线上问题和测试环境问题，处理证据不能完全相同

测试环境中，测试人员通常可以重置数据、重复操作并观察日志；线上问题却可能受账号权限、用户数据、缓存、网络、灰度配置和第三方服务影响。仅仅写“测试环境没复现”，不能证明线上问题不存在；仅仅写“线上有人遇到”，也不能据此断定所有用户都受影响。

对线上问题，我会优先补充发生时间、受影响租户或账号的脱敏标识、客户端版本、接口请求标识、错误截图或日志摘要，以及用户是否有可用绕行方案。涉及个人信息、凭证或业务敏感数据时，证据必须经过脱敏，不能为了方便把敏感数据原样复制进工单。

对测试环境问题，则优先明确构建版本、测试账号权限、数据准备方式、浏览器或设备、前置状态和操作步骤。缺少前置数据条件时，研发复现失败并不一定是研发能力问题，可能是问题描述省略了触发条件。

3. 产品经理的作用不是代替研发判断根因

产品经理需要把用户影响说清楚，推动优先级决策，确认业务验收条件，并在跨团队争议时让讨论回到证据。产品经理不必在信息不足时猜测“是缓存问题”或“应该是接口异常”，否则猜测一旦写进缺陷单，后续排查容易被错误锚定。

更有效的表述是：“在某版本、某账号权限、某操作条件下，点击导出后出现 502；同一账号重试三次结果相同，其他低数据量筛选条件可成功。”这给出了现象和对照条件，但没有越权替研发指定根因。

4. 管理工具能承载流程，但不会自动产生判断

像 PingCode 这类面向中大型企业及 100 人以上组织的项目管理平台，可以把需求、缺陷、迭代、测试和版本信息连接起来，便于跨团队追踪；但工具中的字段、工作流和权限配置，只是执行规则的载体。字段越多，并不自然意味着缺陷质量越高。

我通常先做小规模流程试运行，再决定是否增加字段或自动化。例如，先观察两周：提交人是否能填清复现条件、分派后的等待点在哪里、哪些状态长期无人处理。若问题集中在“缺少版本信息”，再增加版本校验；若问题在于没人愿意接单，增加必填字段也解决不了责任边界。

三、常见误区：看起来规范，实际增加了返工

1. 把所有问题都叫缺陷

产品团队的反馈池里，至少可能混有产品缺陷、使用咨询、数据修正、需求变更、兼容性问题、环境故障和重复报告。它们都值得处理，但处理路径不同。把所有条目放进一个“Bug”队列，会让真正影响用户的缺陷被咨询和需求讨论淹没。

我建议保留统一入口，但在确认阶段做轻量分类。提交人不确定类别时可以选“待判断”，不要逼迫一线同事先做专业诊断。产品或质量负责人确认后，再路由到缺陷、需求、运维或支持流程。

2. 用“严重程度”替代影响分析

“严重”是结论，不是证据。要问清楚：受影响的是一个用户、一个租户还是全部用户？用户能否完成核心任务？是否存在可接受的替代路径？数据是否丢失、泄露或被错误修改？问题发生的概率和持续时间有多长？

影响范围也不能只看报告数量。一个客户可能代表关键业务流程，也可能只是一次偶发操作；反过来，只有一条报告也可能暴露一个潜在的全量风险。报告数是线索，不是最终影响范围。

3. 认为“开发已修复”就可以关闭

修复代码合并、构建成功、部署到测试环境和用户问题消失，是不同的事实。关闭前至少要明确验证对象、验证环境、验证步骤和结果。若问题无法稳定复现，可采用日志、监控、对照样本或修复后的针对性测试，但要把验证方式记录下来。

对高风险缺陷，我会要求验证的不只是原步骤，还包括相邻路径。例如修复重复扣款时，除了重复提交，也要确认正常单次提交、超时重试和支付结果回调不会引入新的异常。回归范围应由变更影响决定，而不是简单地“多测一点”。

4. 只看关闭数量，忽略返工与风险转移

团队每天关闭很多缺陷，不代表质量一定变好。如果大量条目被改为“无法复现”、被拆成低优先级、或在发布后重新打开，关闭数就会制造虚假的进展感。需要一起看重新打开率、逾期未处理数、线上逃逸问题、缺陷平均等待时间和影响等级分布。

指标的目标不是给个人排名，而是发现流程瓶颈。比如确认时间变长，可能是报告信息不足；修复时间变长，可能是依赖关系复杂；重新打开率上升，可能是验收标准含糊或测试覆盖不足。只把数字用于考核，团队往往会优化数字而不是问题。

四、专业判断逻辑：从证据到优先级，而不是从声音大小到排期

1. 先确认它是不是缺陷，再判断要不要立即处理

我会把判断拆成两个问题。第一，现象是否违背已确认的需求、交互、技术约束或公开承诺？第二，如果它确实是缺陷，现在处理的业务价值和风险是否高于其他工作？把两个问题分开，可以避免把“用户很着急”直接等同于“产品行为一定错误”。

如果产品定义没有说明某种边界行为，先不要轻率地将问题判为研发缺陷。团队需要明确这是需求缺口、设计歧义还是实现偏差，并决定补定义、改实现或接受现状。判定结果应记录原因，避免几个月后同一争议重新发生。

2. 用影响、概率、可逆性和绕行方案做优先级判断

实操中，我会使用一个轻量判断框架：影响有多大、再次发生的概率有多高、错误是否容易撤销、是否存在绕行方案、是否有明确业务窗口。这不是精确的数学模型，而是帮助团队把关键差异说清楚。

涉及资金、隐私、安全、合规或不可逆数据损害时，应先按照风险升级机制处理，不要用普通缺陷评分把它稀释。对低风险体验问题，则可以结合用户数量、任务频率、品牌承诺和版本成本安排，不必为了“全部清零”打断每个迭代。

3. 把紧急程度和修复策略分开讨论

高优先级不一定意味着马上提交一个范围很大的代码改动。有时更稳妥的顺序是先止损：关闭受影响入口、回滚版本、限制条件、提供人工处理路径，再安排彻底修复。这个区分尤其适用于线上问题，因为“尽快修复”与“尽快恢复可用”并不总是同一个动作。

我会把应对动作分成三层：临时缓解、根因修复、预防复发。临时缓解要注明有效范围和失效条件；根因修复要对应到触发机制；预防复发则可以是测试、监控、告警或设计约束。不能因为用户暂时不再投诉，就把临时绕行当成彻底解决。

4. 给优先级决定附上理由和复核时间

优先级不是永久标签。新证据出现、影响范围扩大、绕行失效、业务窗口变化，都可能改变处理顺序。因此，记录“为什么现在是这个优先级”比只留一个 P0 或 P1 更有价值。

对于暂缓处理的缺陷，我会写明接受了什么风险、谁确认、什么时候复核，以及什么条件触发升级。没有复核条件的“以后再看”，本质上是把问题从视野中移走。

5. 严重程度分级要有可观察的边界

团队可以使用四级或五级分级，但每一级都要能回答“什么情况下属于这一档”。例如，最高等级可以定义为核心服务不可用、存在数据或安全风险、且没有安全绕行路径；普通等级则可能是局部功能受限、影响范围有限并存在可接受替代方案。

定义不必追求全行业通用。企业业务形态、服务承诺和风险承受能力不同，统一照搬别人的等级表，往往会造成全员 P1 或全员 P2。先用最近一段时间的真实工单做校准：同类问题是否被打到相近等级，升级和降级是否有一致理由。

五、缺陷单怎么写：把“可复现、可判断、可验证”落到字段

1. 标题写事实，不写情绪和结论

标题应该让人快速识别对象、动作和异常结果。比如“订单详情页修改地址后，保存成功但列表仍显示旧地址”，比“地址保存有问题”更有定位价值。若标题写成“紧急！影响客户！”，读者看到的是态度，却看不到故障。

标题中尽量避免提前断定根因，例如“缓存导致地址不更新”。如果根因尚未验证，这句话会诱导排查方向。可以把推测放在“初步线索”字段，并明确标记为待验证。

2. 复现步骤要能让另一个人从干净状态开始操作

好的步骤应按发生顺序描述，并写清前置条件。不要把“登录后操作一下就报错”当作完整步骤，也不要只给一段长视频而没有指出关键时间点。视频和截图是证据补充，不是对文字步骤的替代。

我常用的写法是先描述初始状态，再列出最短操作路径，最后写观察结果。若问题只在特定账号、数据量、权限或网络条件下出现，这些约束必须出现在前置条件中。

3. 预期结果和实际结果分开写

“页面不对”无法作为验收标准。预期结果应来自需求、设计、合同承诺或已经确认的产品行为；实际结果应描述观察到的事实。两者分开后，团队才能判断是实现不符合定义，还是定义本身有空白。

4. 一份可复用的缺陷模板

下面的模板可以按团队实际流程删减。我的建议是先保留足以支撑判断和复现的字段，暂时不要把所有字段都设为必填。对于提交人无法掌握的信息，标为“待补充”比填入猜测更可靠。

标题：
反馈来源与发生时间：

环境、版本、设备或浏览器：

账号角色或权限（不含敏感信息）：

前置条件：

复现步骤：

预期结果：

实际结果：

影响范围与业务影响：

发生频率及最近一次发生时间：

截图、录屏、日志或请求标识（完成脱敏）：

已有绕行方案：

初步判断（可留空，推测须标明）：

5. 证据完整度应服务于风险，而不是形式主义

低风险的视觉偏差，可能一张截图就足以确认；涉及数据错写的问题，则需要样本范围、发生时间和数据一致性证据。团队不应要求每种缺陷都上传同一套材料，更不应因为没有录屏就拒绝处理明确的高风险报告。

对于无法稳定复现的问题，记录“不稳定”本身也是信息。可以补充已尝试次数、成功与失败比例、不同网络或账号的对照，以及问题出现后是否能通过刷新恢复。不要把“目前无法复现”写成“问题不存在”。

六、案例拆解：一个“偶发重复提交”如何从投诉变成闭环

1. 初始反馈：信息不足，但风险信号不能忽略

下面是一个情景化案例，用于说明判断过程，不对应某家企业的真实事故记录。某订阅产品客服反馈：“有用户说付款后订单重复了。”初始信息只有一段用户描述，既不知道用户是否被扣款两次，也不知道是重复订单、重复通知，还是支付渠道的状态回调重复。

这时我不会直接把它定成最高级，也不会因为只有一名用户报告就按普通问题排队。我会先把可能后果标出来：如果只是列表重复展示，可能是显示问题；如果出现重复扣款，涉及资金和用户信任，风险显著不同。下一步要快速补证据，而不是先猜技术原因。

2. 补证过程：用对照问题缩小可能范围

我会让客服确认订单编号和发生时间，并通过合规方式核对支付渠道的交易记录；同时询问用户操作过程、是否重复点击、是否出现超时、页面是否提示失败，以及订单最终状态。所有账号和交易信息都应按内部数据安全规则处理，不能把完整支付凭证放进普通缺陷描述。

团队随后比较订单创建记录、支付回调日志和前端操作时间。如果只有页面显示两行，而底层仅有一次交易，处置方向可能是展示或数据同步；如果底层确实有两笔成功交易，就需要先联系支付或财务流程确认资金状态，同时安排止损和用户沟通。

这个案例的关键不是某个字段填得漂亮，而是把“重复订单”拆成能够区分风险的事实。若一开始就把问题命名为“用户误操作”，团队可能停止调查；若一开始就断言“支付接口重复扣款”，也可能把资源投到错误模块。

3. 处置顺序：先保护用户，再确认根因

在情景推演中，团队核对后发现：同一订单出现两条业务记录，但只有一笔成功支付；第二条记录来自超时后重试，状态同步延迟导致用户误以为付款失败。即便最终没有重复扣款，用户仍可能重复操作，因此不能只把它当作后台显示问题。

合理的处理顺序是：先确认是否存在真实资金损失；随后评估重试行为是否还能继续触发；必要时暂时限制重复提交或给出清晰的处理中提示；再修复状态同步和幂等保护；最后验证正常支付、超时重试、重复点击和回调延迟等相邻场景。

4. 验收条件：不只检查页面提示

验收标准可以写成可观察条件：在相同业务请求被重复提交时，只产生一笔有效支付；超时后重试时，系统返回已有订单或明确处理中状态；支付结果延迟到达时，前端不会鼓励用户再次付款；出现异常时，客服能够通过可追踪标识核实当前状态。

注意，产品经理不需要决定采用哪种数据库约束或技术实现，但需要确认用户侧行为和业务结果。技术方案由研发评审，验收条件由产品和质量角色共同确认，涉及资金风险时还需要相关业务责任人参与。

5. 复盘要找控制点，而不是只追责提交人

问题关闭后，我会追问几个流程问题：为什么用户会认为付款失败？前端是否缺少处理中反馈？重试策略有没有边界？监控能否区分重复请求和重复扣款？客服是否能快速确认交易状态？这些答案决定改进是在文案、交互、服务端保护、告警还是支持流程。

如果只记录“用户不要重复点击”，风险并没有真正转移，只是把系统的不确定性留给用户承担。优秀的缺陷复盘应该识别可以被产品和系统控制的环节，而不是把防错责任简单推给使用者。

七、用数据看流程：别让平均值掩盖高风险问题

1. 先定义指标口径，再做趋势比较

缺陷管理没有一个对所有团队都适用的“正常缺陷率”。产品复杂度、发布频率、用户规模、测试策略和故障定义都不同，直接拿别的公司的数字做目标，容易制造错误激励。更重要的是先确保团队内部口径一致，再比较本月和上月、版本之间或不同业务线之间的变化。

至少要把统计范围说清楚：只统计确认的产品缺陷，还是包含咨询和环境问题？计时从提交、确认还是分派开始？暂停等待用户信息的时间是否纳入？关闭后重新打开算新单还是原单？这些口径不统一，趋势图看似精确，实际不可比较。

2. 推荐跟踪的指标及其盲区

3. 看分布和变化，不只看平均值

平均修复时间容易被少数长周期问题拉高，也容易被大量一小时内关闭的重复单拉低。建议同时看中位数、分位区间和按风险等级拆分的等待时间。如果团队数据量较小，图表应标注样本数，避免把偶然波动解读成确定趋势。

例如，整体中位确认时间下降，不一定说明高风险问题变快了；它可能只是低风险咨询更快分流。把高风险问题单独拉出来，观察首次响应、止损时间和关闭后的验证结果，通常比一个全量平均值更接近管理需要。

4. 找到瓶颈后再决定是否自动化

如果大量缺陷在等待补充信息，可以在提交表单中提供条件提示、复现步骤示例和自动采集的版本信息。如果缺陷常被错误分派，可能需要明确模块负责人或增加产品与研发联合分诊。如果问题集中在验证等待，则可以检查测试环境、数据准备和版本发布节奏。

自动化适合处理重复、规则明确、风险可控的动作，例如缺陷进入某状态时通知责任人、关联版本或提醒超时。需要依赖上下文的判断，例如是否涉及资金风险、是否可以接受绕行，不应简单用规则替代人工决策。

八、不同情况下的行动建议与取舍

1. 小团队：优先减少信息往返，不必先搭复杂流程

十人以内的产品研发团队，角色往往兼任。此时流程最重要的不是审批层级，而是有人负责确认、有人负责修复、有人负责验证。可以从统一入口、清晰模板、固定分诊时间和简洁状态开始。

小团队的取舍是：宁可少一些状态，也要确保每个状态有人负责。若问题足够简单，提交人可以与研发直接沟通，但最终结论、优先级理由和验证结果仍应回写到缺陷记录中，避免决策只留在即时消息里。

2. 多团队协作：先统一定义，再统一工具配置

跨产品线或多研发团队环境中，同一个“高优先级”可能被不同团队理解为不同的响应要求。应先对齐等级定义、升级路径、责任边界和跨团队移交规则，再把这些规则映射到管理平台。

像 PingCode 这类支持多团队协作和工作流管理的平台，可以帮助团队关联需求、缺陷、迭代和版本，但配置前要先回答：哪个角色有权调整优先级？跨团队问题由谁做单一责任人？移交后原团队是否仍承担协同责任？这些问题不清楚时，复杂工作流只会把争议电子化。

3. 线上高风险问题：先止损，再完整定位

出现资金、隐私、安全、关键数据或核心服务可用性风险时，不要等待所有根因证据齐备才行动。启动对应应急机制，确认影响范围，指定统一沟通负责人，评估回滚、限流、关闭入口或人工替代方案，并按企业规则通知相关责任人。

这类问题的取舍在于：短期恢复与彻底修复可能要分两步。临时方案可能牺牲部分体验或功能，但必须评估副作用和退出条件。若采用人工处理，还要核算处理能力、数据留痕和持续时间，避免止损措施本身制造新的风险。

4. 偶发、难复现问题：保留不确定性，增加可观测证据

遇到偶发问题，不要为了让工单“有结论”而过早关闭。可以标记当前复现状态，记录已排查条件，补充监控、日志关联标识或用户侧诊断信息，并约定出现新样本时如何重新开启调查。

在风险较低且短期无法复现时，团队可以选择观察而非立即改动。但这个决定应有边界：观察哪些信号、持续多久、达到什么阈值升级、是否有用户沟通方案。没有观测计划的“先放一放”，只是把不确定性转嫁给未来。

5. 发布前缺陷太多：分层处理，不以清零作为唯一目标

发布前出现缺陷集中积压，应该按风险、影响范围、修复复杂度和回归成本分层。高风险问题通常需要解决或明确阻断发布；低风险问题可以在已知限制、替代方案和后续排期都明确的前提下延期。

发布决策不是“有 Bug 就不能发”，也不是“时间到了就必须发”。关键是决策人看得见尚未解决的问题、风险依据、用户影响和回滚方案，并且有权承担或拒绝相应风险。对外承诺、行业监管和合同条款可能进一步限制延期选择，应纳入评审。

6. 是否购买或升级管理工具：先验证流程问题是否真的可由工具解决

如果团队缺的是统一记录、跨项目可见性、权限控制、版本关联和审计留痕，项目管理平台可能有实际价值；如果缺的是分诊责任、产品定义、测试策略和修复资源，换工具通常不会带来根本变化。

评估工具时，我会用一段真实工作流做试点：从用户反馈进入，经过确认、分派、修复、测试、发布和复盘。观察是否减少重复录入、状态追问和跨团队信息丢失；再评估权限、数据迁移、集成、培训成本和长期维护责任。

九、把方法落地：一周内可以启动的最小改进

1. 第一天：抽样检查最近的缺陷记录

随机抽取最近 20 至 30 条已关闭和未关闭记录，检查标题、复现步骤、影响范围、优先级理由和验证结果。不要先评价个人填写习惯，先统计哪些字段缺失最多、哪些缺失会造成返工或风险判断错误。

如果团队规模较小，样本不足时可以延长时间范围，并注明样本数。观察结果是流程诊断，不是组织绩效排名。检查目的在于找出最值得改的一个断点，而不是一次性重做所有字段。

2. 第二天：定义分类、等级和升级边界

用团队最近发生的真实案例校准缺陷、需求变更、咨询和环境问题的边界。再定义严重程度和处理优先级的判断依据，重点明确高风险问题的升级条件、响应负责人和临时止损权限。

如果团队对某个案例无法达成一致，不要急着投票解决。把分歧拆开：是对影响事实理解不同、对产品行为定义不同，还是对风险承受能力不同？不同类型的分歧需要不同责任人参与。

3. 第三至五天：试用精简模板和固定分诊节奏

将模板控制在能够复现和判断的核心字段，设立固定分诊时段，例如每日一次或每周数次，频率按业务风险和问题量决定。高风险事件仍走即时升级路径，不应等待例行分诊。

试运行期间记录补充信息次数、错误分派、长时间无人处理和验证失败等情况。若某个字段几乎没人理解或长期为空，先确认是字段不必要，还是填写责任和采集方式不合理。

4. 第六至七天：复盘一个已闭环和一个未闭环问题

选择一条处理顺畅的记录，找出哪些信息帮助团队快速判断；再选一条反复等待或重新打开的问题，定位等待发生在哪个环节。把经验转化为具体流程变化，例如补版本自动采集、指定升级负责人或明确关闭条件。

一周试点不够证明长期效果，但足以发现明显的信息断点。若要比较改进效果，最好用相同口径继续观察多个迭代，并记录样本量、业务变化和发布节奏，避免把季节性或项目差异当成流程成效。

十、最后的判断：缺陷管理不是追求零问题，而是控制未知风险

1. 不要把“Bug 数量归零”当作质量目标

产品持续变化，用户场景也持续变化，任何团队都不可能用一个缺陷数量证明产品质量。真正值得追求的是：高风险问题能被及时发现和升级，普通问题可以被透明取舍，修复结果能够验证，已知风险不会悄悄遗失。

零缺陷可能是某个封闭测试范围内的结果，却不等于真实用户环境没有问题。与其追求一个容易被口径操纵的数字，不如追踪未处理风险是否下降、线上问题是否更早发现、修复是否少返工、用户是否能更快恢复任务。

2. 产品经理要守住三条边界

• 不把猜测写成根因：事实、推断和待验证假设分开记录。
• 不把紧急情绪直接变成优先级：依据影响、风险、时效和绕行条件做判断。
• 不把代码完成等同于问题关闭：明确验证范围、发布状态和观察条件。

3. 下一步先做一个小动作

现在就抽取最近 20 条缺陷，标出哪几条缺少复现条件、哪几条没有优先级理由、哪几条没有验证证据。选出出现频率最高且最影响决策的一项，先调整模板或责任规则，再用下一轮工单验证效果。

我最看重的不是缺陷单写得多完整，而是团队能否从证据走到一致决策，并把修复结果带回用户场景验证。如果每条记录都能说明发生了什么、为什么先处理或暂缓、怎样确认已经解决，Bug 管理才真正从“登记问题”变成了产品质量控制。