51172e8c5a
All checks were successful
Docker Build & Deploy / Build Docker Image (push) Successful in 4m27s
Docker Build & Deploy / Deploy to Production (push) Successful in 7s
Docker Build & Deploy / Cleanup Dangling Images (push) Successful in 1s
Docker Build & Deploy / WeChat Notification (push) Successful in 1s
203 lines
6.4 KiB
Markdown
203 lines
6.4 KiB
Markdown
---
|
||
name: bug-fix
|
||
description: Bug诊断与修复技能 - 强调交互式确认和影响分析
|
||
metadata:
|
||
tags:
|
||
- bug-fix
|
||
- debugging
|
||
- troubleshooting
|
||
- interactive
|
||
version: 1.0.1
|
||
---
|
||
|
||
# Bug修复技能
|
||
|
||
## 技能概述
|
||
|
||
专门用于诊断和修复项目中的bug,强调谨慎的分析流程和充分的交互式确认,确保修复的准确性和完整性,避免引入新的问题或破坏现有功能。
|
||
|
||
## ⚠️ 强制交互规则(MUST FOLLOW)
|
||
|
||
**遇到需要用户确认的情况时,必须立即调用 `question` 工具:**
|
||
|
||
❌ **禁止**:"我需要向用户确认..."、"请用户回答..."、"在Plan模式下建议先询问..."
|
||
✅ **必须**:直接调用工具,不要描述或延迟
|
||
|
||
**调用格式**:
|
||
```javascript
|
||
question({
|
||
header: "问题确认",
|
||
questions: [{
|
||
question: "具体触发场景是什么?",
|
||
options: ["新增时", "修改时", "批量导入时", "定时任务时", "其他"]
|
||
}]
|
||
})
|
||
```
|
||
|
||
**规则**:
|
||
- 每次最多 **3个问题**
|
||
- 每个问题 **3-6个选项**(穷举常见情况 + "其他"兜底)
|
||
- 用户通过**上下键导航**选择
|
||
- 适用于**所有模式**(Build/Plan)
|
||
|
||
## 执行原则
|
||
|
||
### 1. 充分理解问题(必要时交互确认)
|
||
|
||
**触发条件**:
|
||
- 用户对bug的描述含糊不清
|
||
- 问题复现步骤不完整
|
||
- 预期行为与实际行为表述存在歧义
|
||
- 涉及多个可能的问题根因
|
||
|
||
**执行策略**:
|
||
- ✅ **立即调用 `question` 工具**(不要描述,直接执行)
|
||
- ✅ **暂停其他操作**,不要基于假设进行修复
|
||
- ✅ 澄清:错误现象、触发条件、预期行为、是否有日志
|
||
|
||
### 2. 风险评估与影响分析(必要时交互确认)
|
||
|
||
**触发条件**:
|
||
- 发现潜在的边界情况用户未提及
|
||
- 代码修改可能影响其他功能模块
|
||
- 存在多种修复方案,各有利弊
|
||
- 发现可能的性能、安全或兼容性隐患
|
||
|
||
**执行策略**:
|
||
- ✅ 代码分析后,**不要直接修改代码**
|
||
- ✅ 报告潜在问题:影响范围、边界情况、测试场景、数据迁移需求
|
||
- ✅ **使用 `question` 工具**让用户选择方案或确认风险
|
||
|
||
### 3. 关联代码检查(必要时交互确认)
|
||
|
||
**触发条件**:
|
||
- 发现多个位置存在相似的代码逻辑
|
||
- 修复需要同步更新多个文件
|
||
- 存在可能依赖该bug行为的代码(反模式)
|
||
- 发现测试用例可能基于错误行为编写
|
||
|
||
**执行策略**:
|
||
- ✅ 使用代码搜索工具查找相似逻辑和调用链
|
||
- ✅ 报告关联代码:是否需要同步修复、依赖关系、测试更新
|
||
- ✅ **使用 `question` 工具**让用户确认修复范围
|
||
|
||
## 修复流程
|
||
|
||
### 阶段1: 问题诊断
|
||
1. 阅读用户的bug描述
|
||
2. 定位相关代码文件(使用 semantic_search, grep_search)
|
||
3. 分析代码逻辑和调用链
|
||
4. **触发点1**: 如有不明确之处 → **立即调用 `question` 工具**(不要描述计划)
|
||
|
||
### 阶段2: 根因分析
|
||
1. 确定bug的根本原因
|
||
2. 识别影响范围和边界情况
|
||
3. **触发点2**: 发现用户未考虑的问题 → **立即调用 `question` 工具**
|
||
|
||
### 阶段3: 方案设计
|
||
1. 设计修复方案
|
||
2. 评估方案的影响和风险
|
||
3. 查找相似代码和依赖关系
|
||
4. **触发点3**: 可能影响其他逻辑 → **立即调用 `question` 工具**
|
||
|
||
### 阶段4: 实施修复
|
||
1. 获得用户最终确认后执行代码修改
|
||
2. 使用 `multi_replace_string_in_file` 批量修改
|
||
3. 确保修改的原子性和一致性
|
||
|
||
### 阶段5: 验证建议
|
||
提示用户执行:单元测试(`dotnet test`)、手动测试场景、回归测试
|
||
|
||
## 反模式与成功标准
|
||
|
||
❌ **不要**在未明确理解问题的情况下猜测修复
|
||
❌ **不要**在未评估影响范围的情况下直接修改代码
|
||
❌ **不要**假设用户已考虑所有边界情况
|
||
❌ **不要**在发现关联逻辑时仅修复单个位置
|
||
❌ **不要**跳过风险通知直接实施有争议的修复方案
|
||
❌ **不要**修改代码后不提供验证建议
|
||
❌ **不要**描述"我会询问用户..."而不调用 `question` 工具
|
||
❌ **不要**列出问题清单让用户自行回答
|
||
❌ **不要**在Plan模式下说"如果用户确认..."而不执行工具调用
|
||
|
||
## 成功标准
|
||
|
||
✅ 用户明确确认问题理解无误(通过 `question` 工具获取)
|
||
✅ 所有潜在风险和影响已向用户说明(通过 `question` 工具确认)
|
||
✅ 修复方案获得用户明确同意(通过 `question` 工具选择)
|
||
✅ 相似逻辑和关联代码已同步处理(如适用)
|
||
✅ 提供了完整的验证和测试建议
|
||
|
||
## 示例工作流
|
||
|
||
```
|
||
用户: "策略计算结果不对,加价逻辑有问题"
|
||
|
||
Agent:
|
||
[阶段1 - 问题诊断]
|
||
我需要确认几个细节:
|
||
1. 具体是哪种类型的策略计算不对?(机票、动态加价、固定加价?)
|
||
2. 能否提供一个具体的测试用例输入和错误输出?
|
||
3. 预期的正确输出是什么?
|
||
|
||
用户: "动态加价,百分比计算错误,应该是基准价×10%,但实际是×100%"
|
||
|
||
Agent:
|
||
[阶段2 - 根因分析]
|
||
已定位到问题:
|
||
- 位置: src/Domain.Service/Services/AgentService.cs:234
|
||
- 原因: 百分比未除以100
|
||
|
||
[阶段3 - 方案设计]
|
||
⚠️ 发现以下需要确认的点:
|
||
|
||
1. **关联代码**: 在 PolicyService.cs 中发现相似的百分比计算(3处),
|
||
是否也存在相同问题?
|
||
|
||
2. **单元测试**: UnitTestPolicy.cs:67 的断言值为100%,可能基于错误行为,
|
||
修复后需要更新测试
|
||
|
||
3. **前端影响**: 如果历史数据按错误逻辑存储,前端展示需要迁移脚本吗?
|
||
|
||
请确认是否需要一并处理这些关联问题?
|
||
|
||
用户: "是的,PolicyService 也需要修复,测试用例也要改,历史数据没有存储"
|
||
|
||
Agent:
|
||
[阶段4 - 实施修复]
|
||
好的,我将修复以下位置:
|
||
1. AgentService.cs:234
|
||
2. PolicyService.cs:156, 178, 201
|
||
3. UnitTestPolicy.cs:67
|
||
|
||
[执行代码修改...]
|
||
|
||
[阶段5 - 验证建议]
|
||
修复完成!建议验证:
|
||
1. 运行单元测试: dotnet test
|
||
2. 手动测试场景:
|
||
- 输入基准价1000,加价10%,期望结果1100
|
||
- 验证策略列表API返回正确百分比
|
||
3. 回归测试: 检查其他类型策略未受影响
|
||
```
|
||
|
||
## 适用场景
|
||
|
||
- ✅ 逻辑错误修复
|
||
- ✅ 空指针异常修复
|
||
- ✅ 数据计算错误
|
||
- ✅ API行为异常
|
||
- ✅ 性能问题修复
|
||
- ✅ 边界条件处理
|
||
|
||
## 相关技能
|
||
|
||
- `refactor`: 重构优化(非bug修复)
|
||
- `feature`: 新功能开发
|
||
- `test`: 测试用例编写
|
||
|
||
## 核心约束(必须遵守)
|
||
1. **禁止开放式提问** - 所有需要用户输入的场景,必须提供选项列表
|
||
2. 每次交互最多提出5个问题,避免信息过载
|
||
3. 选项设计要穷举常见情况,并保留"其他"兜底选项
|