Jeandoom maycur-ai-code-dever — 代码修复
maycur-ai-coder 插件第二个 skill——负责 bug 修复链路的代码变更。所有 Edit 必须经用户确认 + Read 验证。
Claude vs 脚本分工
| 角色 | 职责 |
|---|---|
| Claude | 读 root-cause.md 拿方案 → 让用户选 → 半自动 Edit（每步确认） → Read 验证 → 写 02-修复报告 |
| 无 Python 脚本 | 代码 Edit 是 Claude 强项 |
| code-manager（协作） | 阶段 ② 完成（bugfix 分支就绪）后移交；阶段 ③ 之前等回 |
输入源
| 来源 | 提取什么 |
|---|---|
root-cause/root-cause.md |
核心输入：解决方案字段（临时 hotfix + 根治）+ 置信度 |
code/code-analysis.md |
涉及文件位置（精确定位 file:line） |
repos/{project}/ |
code-manager 切好的 bugfix 分支工作区 |
| 用户输入（独立模式） | 工作区路径 + 改动描述（可选关联根因） |
半自动 Edit 安全闸（硬约束）
① 置信度门槛
读 root-cause.md 的"结论摘要"字段：
- 置信度=高/中 → 允许执行 Edit
- 置信度=低 → 拒绝执行，输出提示建议回 root-cause-analyzer 补证据
② 每个 Edit 前 AskUserQuestion
| 字段 | 说明 |
|---|---|
| 文件路径 | src/foo.py:88 |
| 变更类型 | 新增/修改/删除 |
| diff 预览 | 红绿对比（markdown 代码块） |
| 关联根因点 | 引用 root-cause.md 的疑似根因点 ID |
| 操作选项 | 确认 / 修改后确认 / 跳过 / 中止全部 |
③ 同模式批量 Edit 可一次性确认
若多个改动是相同模式（如多处加同一个空值校验），合并为一次确认：
即将应用 5 处同模式 Edit：
src/foo.py:88 — 加 `if not data: return None`
src/foo.py:120 — 同上
src/bar.py:42 — 同上
...
[全部确认] [逐个确认] [跳过全部]
④ Edit 后立即 Read 验证
每次 Edit 完成后：
Read文件检查语法/缩进/导入完整性- 验证通过 → 记录到变更清单（状态 ✅）
- 验证失败 → 回滚该次 Edit + 标记 ❌ + 询问用户（重试/放弃）
方案选择（用户决策）
root-cause.md 可能含多个方案（临时 + 根治 + 多个改动点）：
- 解析"解决方案"字段所有候选
- AskUserQuestion 让用户选应用到本次 commit 的方案：
- 全选 / 部分选 / 都不选（中止）
- 用户可补充 root-cause.md 未覆盖的改动（如手工加注释/优化）
- 选定的方案 → 拆分为 Edit 列表（每个改动点一项）
执行流程
- 接收
{bug_dir}或独立模式用户输入 - 模式探测：检查
{bug_dir}/code/code-analysis.md+ 当前工作区分支 - 编排模式 → 读
root-cause/root-cause.md拿解决方案 + 置信度 - 置信度门槛：=低 → 拒绝执行，提示回 root-cause-analyzer；=高/中 → 继续
- 方案选择：AskUserQuestion 让用户选要应用的方案
- 拆分为 Edit 列表（同模式合并）
- 逐个/批量 Edit：
- AskUserQuestion 展示 diff 预览 + 关联根因点
- 用户确认 → Edit
- Edit 后 Read 验证 → 失败回滚
- 写
reports/02-修复报告.md（修复概要 + 变更清单 + 验证记录 + MR 描述） - 回流 code-manager 阶段 ③ commit（明确移交点）
物料产出 reports/02-修复报告.md
# 修复报告：bug-{id}
## 修复概要
- **bug_id**: bug-20260723-login-npe
- **branch**: bugfix-task12345678-login-npe-check
- **改动文件数**: 2
- **新增/删除行数**: +15 / -3
- **MR url**: （code-manager 阶段 ⑤ 后回写）
## 变更清单
| 文件 | 行号 | 变更类型 | 关联根因点 | 状态 |
|------|------|---------|-----------|------|
| src/foo.py | 88 | 加空值校验 | baz.py:88 NPE | ✅ Edit + 验证通过 |
| src/foo.py | 42 | 入口参数校验 | bar.py:42 防御 | ✅ Edit + 验证通过 |
## 验证记录
- ✅ Edit 后 Read 语法检查
- ⚠️ 未跑测试（建议人工跑 xxx）
- ❌ xxx 验证失败（已回滚）
## MR 描述（自动生成，供 code-manager 使用）
### 根因
（引用 root-cause.md 结论摘要）
### 变更
（引用上方变更清单）
### Review 关注点
- src/foo.py:88 — 核心 NPE 修复
- src/foo.py:42 — 防御性校验（可选讨论）
### 测试建议
- 单元测试：xxx case
- 回归测试：xxx 路径
字段说明：
- 修复概要：bug_id / branch / 改动统计（code-manager commit 时引用）
- 变更清单：每个 Edit 的状态 + 关联根因点（可追溯）
- 验证记录：诚实标注通过/未跑/失败
- MR 描述：自动生成 markdown，供 code-manager 阶段 ⑤ 创建 MR 时使用
独立模式
| 模式 | 触发 | 输入来源 |
|---|---|---|
| 编排模式 | bug-killer / code-manager 调度 | 读 bugs/bug-{id}/{code,root-cause}/ + repos/ |
| 独立模式 | 用户单独调用 | 用户给工作区路径 + 改动描述（可选关联根因） |
探测约定：
- 工作区已是 bugfix 分支 + 存在
code/code-analysis.md→ 编排模式 - 工作区是任意路径 + 用户给改动描述 → 独立模式（跳过 root-cause.md 方案提取）
独立模式不做置信度门槛检查（用户自负其责）。
边界
- 不做根因分析（root-cause-analyzer 职责）
- 不做 git 操作（commit/push/MR 全归 code-manager）
- 不做测试编写（除非用户显式要求）
- 不做无确认的 Edit（硬约束）
- 不在置信度=低时执行（拒绝并回退到 root-cause-analyzer）
- 不做在线代码查询（用本地 repos/）
依赖
- root-cause-analyzer（上游）：
root-cause/root-cause.md（核心输入：解决方案 + 置信度） - code-analyzer（上游）：
code/code-analysis.md（涉及文件位置） - code-manager（协作）：阶段 ② 完成（bugfix 分支就绪）后移交；阶段 ③ 之前等回