bug-triage-prioritizer

Bug 分类与修复优先级

专业地处理 Bug。让客户在项目上线后依然满意。

此技能的作用

输入：客户提交的 Bug 报告
输出：严重级别、修复优先级、客户沟通模板、免费修复或收费的判断、Claude Code 提示词

Bug 严重级别

🔴 严重（立即修复）

• 软件完全无法使用
• 数据丢失或损坏
• 安全漏洞
• 主要功能完全失效

响应时间： 4 小时内
沟通方式： 立即电话联系并发送邮件
收费： 绝不收费（属于保修范围）

示例：

• 用户无法登录
• 数据库损坏
• 支付处理失败
• 数据泄露

---

🟠 高（24 小时内修复）

• 主要功能部分失效
• 严重影响用户工作流
• 影响大多数用户

响应时间： 24 小时内
沟通方式： 发送邮件并告知时间安排
收费： 通常不收费（在 30 天保修期内）

示例：

• 无法生成 PDF 报告
• 搜索功能失效
• 无法上传照片

---

🟡 中（1 周内修复）

• 次要功能失效
• 存在临时解决方案
• 有时会影响部分用户

响应时间： 3-5 个工作日
沟通方式： 通过邮件确认收到并告知修复日期
收费： 视情况而定（30 天后可能收费）

示例：

• 下拉列表排序不正确
• 邮件通知延迟
• UI 元素错位

---

🟢 低（在下次更新中修复）

• 外观问题
• 轻微不便
• 罕见边缘情况

响应时间： 下次计划更新时
沟通方式： “已加入待办列表”
收费： 通常收费（保修期后）

示例：

• 按钮颜色错误
• 标签中有拼写错误
• 功能请求（不是 Bug）

---

免费修复或收费决策树

免费修复（30 天保修期内）： ✅ 软件未按说明正常工作
✅ 严重或高优先级问题
✅ Bug 是由你引入的（你的失误）
✅ 影响核心功能

修复收费： 💵 超过 30 天保修期
💵 用户操作失误（不是 Bug）
💵 低优先级外观问题
💵 伪装成“Bug”的新功能请求
💵 需求范围蔓延（“我以为它还会做 X”）

客户沟通模板

严重 Bug 响应

主题：[紧急] 正在调查 [Issue] - 预计 4 小时内解决

“嗨，[Client]：

我刚看到你关于 [issue] 的报告。目前这是我最优先处理的事项。

我正在调查原因，并会在 4 小时内部署修复。

在问题解决前，我会每小时向你更新进展。

很抱歉给你带来不便。

[Your Name]”

---

高/中优先级 Bug 响应

主题：已收到 Bug 报告 - 修复时间安排

“嗨，[Client]：

感谢你报告 [issue]。我已将其归类为 [severity level]。

问题情况： [brief explanation]
修复时间： [specific date/time]
临时解决方案（如有）： [temporary solution]

修复完成后，我会立即通知你。

[Your Name]”

---

低优先级 Bug 响应

主题：[Issue] 已加入待办列表

“嗨，[Client]：

感谢你报告 [issue]。这是一个轻微的外观问题，不会影响功能。

我已将其加入待办列表，并会在下次月度更新中修复。

如果这个问题比我理解的更紧急，请告诉我，我可以提高其优先级（可能需要额外的开发工时）。

[Your Name]”

---

应对“为什么这不免费？”的对话

客户：“我付了 15K 美元，你们的软件里怎么还有 Bug？！”

回应： “我完全理解你的不满。情况是这样的：

这个 [bug type] 属于 [severity level] 问题，会 [impact description]。

此问题在保修范围内，因为 [reason: affects core functionality / within 30 days / my oversight]。

我会免费修复，并在 [date] 前解决。

以下情况不在保修范围内：

• 30 天保修期之后出现的问题
• 新功能请求
• 更改功能的工作方式（而非修复失效的功能）

这样说清楚了吗？”

预防策略

在合同中包含：

• 30 天缺陷修复保修
• 明确定义“缺陷”与“功能请求”
• 响应时间承诺
• 保修期后的支持选项

这可以避免：

• “为什么修复缺陷还要收费？”
• 将无休止的免费工作伪装成“缺陷”
• 借由缺陷报告不断扩大范围

请记住

缺陷难免会出现。你如何处理，体现了你的专业素养。

• 快速响应（即使修复需要时间）
• 清晰沟通（明确预期）
• 立即修复关键问题（维护你的声誉）
• 对范围蔓延收费（保护你的时间）

妥善处理缺陷 = 客户信任你 = 获得推荐 + 持续收入