# 回复样本库 (Reply Samples)

这里存放优秀的回复范例，供 Butler 机器人生成回复时参考 (Few-Shot Prompting)。
重点关注：**逻辑清晰**、**责任撇清**、**情绪安抚**、**专业性**。

---

## 示例 1：项目延期 (Project Delay)

**场景**: 业务方质疑为什么项目上线时间推迟了 3 天。
**角色**: 研发总监
**回复**:

> 1.  **现状确认**：确实如您所见，项目原定于 15 日上线，目前调整为 18 日。
> 2.  **原因分析 (客观)**：我们在最后一轮压测中发现了一个偶发的并发数据一致性风险 (风险等级 High)。虽然它出现的概率仅为 0.1%，但考虑到该模块涉及核心计费逻辑，我们不能让用户承担即使是万分之一的资金风险。
> 3.  **决策逻辑 (担当)**：这也是我坚持叫停上线的原因。与其上线后紧急回滚造成业务中断，不如现在花 3 天时间彻底修复。这 3 天我们将进行 72 小时不间断的稳定性验证。
> 4.  **下一步 (承诺)**：我们已协调 QA 团队周末加班保障，确保 18 日上午 9 点准时发布。感谢您的理解，我们也是为了保障业务的长治久安。

---

## 示例 2：需求变更拒绝 (Requirement Rejection)

**场景**: 客户上级在项目后期突然提出增加一个非核心的展示功能。
**角色**: 产品负责人
**回复**:

> 1.  **肯定价值**：这是一个非常有洞察力的需求。从长期看，增加这个展示确实能提升用户对数据的掌控感。
> 2.  **资源约束 (现实)**：当前距离封版测试仅剩 2 天。如果现在强行插入此功能，我们需要打开已封闭的代码分支，这会使现有核心流程的回归测试覆盖率下降 40% 以上，极大概率引入新的未知 Bug。
> 3.  **替代方案 (共赢)**：为了保障按时交付给老板承诺的里程碑，我建议采用“分步走”策略：
>     *   **P0 (本期)**：按原计划稳步上线，确保核心业务跑通。
>     *   **P1 (下周)**：我们将此通过 Hotfix 或首个迭代版本快速跟进。
> 4.  **询问意见**：您看这样安排，既保住了上线时间点，又没有丢掉这个好想法，是否更稳妥？

---

## 示例 3：线上故障致歉 (Incident Apology)

**场景**: 昨晚系统出现短暂抖动，导致部分用户访问超时。
**角色**: 技术负责人
**回复**:

> 1.  **诚恳致歉**：首先对昨晚的服务波动给业务带来的困扰表示歉意。
> 2.  **故障定性**：经排查，这是由于底层云服务商的网络抖动引发了我们数据库连接池的拥塞。虽然是外部不可抗力，但在容灾机制的触发灵敏度上，我们确实还有优化空间。
> 3.  **止损措施**：系统在 5 分钟内已自动触发熔断保护，业务在 10 分钟后完全恢复。实际受影响用户占比小于 0.5%。
> 4.  **改进计划 (闭环)**：为了避免此类“黑天鹅”再次影响业务，我们今天上午已经调优了重试策略，并计划在下周引入新的多活灾备方案。请放心，技术团队始终是业务最坚实的后盾。

## 示例 4：供应商故障引发问题

**场景**: 供应商接口传递参数错误，导致用户获取错误信息。
**角色**: 产品负责人
**回复**:

> 1. **诚恳致歉**: 非常抱歉。
> 2. **故障描述**: 这个问题原因是外部供应商亚数在进行证书供应变更时，供应商提供的证书域名验证接口调用成功，但传递错误的返回类型，导致部分用户按照展示信息操作而导致验证不通过，无法签发证书。
> 3. **改进计划**:
获得用户报障后，我们立即联系了供应商回滚恢复。在监控层面，目前没有对供应商接口返回内容做强校验，这里需要全面审查加强。