---
name: "problem-solving"
description: "问题解决技能 — 改 bug / 排查复杂问题时，按「问题分析 → 工作记录 → 知识沉淀」三段式产出。当需要「修 bug」「排查问题」「调查原因」「问题分析」「写工作记录」「沉淀知识库」时使用。"
---

# 问题解决（Problem Solving）

> 改 bug / 做复杂改动时，按「问题分析 → 工作记录 → 知识沉淀」三段式产出。
> **核心范式**：Gitea issue 是工作台（承载问题分析 + 工作记录，事务性）；`docs/knowledge/` 是精选集（只收值得长期保留的坑）；临时代码验证完即删。

## 触发条件

- 用户要求**修 bug、排查问题、调查根因**，且问题非一行 typo 类简单修改
- 用户说「修 bug」「排查」「为什么…」「调查」「这个问题怎么回事」等
- 改动涉及多个文件 / 需要先理解现状才能动手的复杂改动

**不触发**（直接改 + 普通 `fix(scope)` 提交）：明显的单行修复、typo、数值微调。

---

## 九步流程

### 1. 判断复杂度

简单修复（单行、明显错误）→ 直接改 + `fix(scope)` 提交，**不走本流程**。
复杂问题（需调查、跨文件、根因不明）→ 继续后续步骤。

### 2. 开 / 关联 Gitea issue

调用 `gitea-pm` / `gitea-collab` skill：
- 没有对应 issue → 开一个，打标签 `type:bug`（缺陷修复）或 `type:investigation`（纯调查）+ `status:in-progress`
- 已有 issue → 关联，更新为 `status:in-progress`

> 每个「要解决的问题」都应有对应 issue——问题分析和工作记录都挂在它上面。

### 3. 问题分析（写入 issue 描述 / 首条评论）

按「问题分析模板」填写：现象 / 复现 / 影响范围 / 假设与验证 / 初步结论。这是调查过程的留痕。

### 4. 本地调查

写临时验证代码验证假设（文件名前缀 `tmp_` / `dev_`，文件头 `// [TEMP-INVESTIGATE: issue#XX] 验证后删除`）。**关键验证代码片段**以代码块形式记入 issue「假设与验证」章节。

### 5. 清理临时代码

验证完**即删**——删除 `tmp_`/`dev_` 文件、`git revert` 或删除 `[TEMP-INVESTIGATE]` 的 commit。最后 `grep -r "TEMP-INVESTIGATE" Source/ tools/` 确认无残留。

> 原则：删除的是可运行 artifact，保留的是 insight（结论 + 片段已写入 issue）。

### 6. 修复

写正式代码 / 蓝图，遵循 `code-implementation` skill 规范 + Git 规范（`fix(scope)`，C++ 与蓝图分开提交，见 `docs/common/GIT-GUIDE.md`）。

### 7. 工作记录（写入 issue 关闭总结评论）

按「修复总结模板」发一条评论：问题 / 根因 / 解决方案 / 验证 / 影响范围 / 是否沉淀知识库。

> **与 deviation-report 的分工**：问题涉及「实现 vs 执行案偏差」时（有执行案对照）→ 用 `deviation-report` skill 写偏差报告；纯 bug 修复（无执行案对照）→ 用本「修复总结」。两者互补。

### 8. 知识库评估

判断这个坑是否值得长期保留（**任一为是**即提炼）：
- 会复发吗？（换人/换系统会再踩）
- 根因非显而易见吗？（光看代码看不出来）
- 当前是临时方案吗？

**是** → 提炼一条进 `docs/knowledge/` 对应主题文件（`坑-<主题>.md`），更新 `docs/knowledge/INDEX.md`；若是临时方案，再登记到 `docs/knowledge/临时方案登记.md`。
**否** → issue 关闭即可，不必沉淀。

> 动手前先读 `docs/knowledge/INDEX.md`，看有没有相关坑可避让。

### 9. 关闭 issue

更新 issue 为 `status:done`，在评论里记录产出位置（分析评论 / 修复总结评论 / 知识库条目路径）。

---

## 模板

### 问题分析模板（issue 描述 / 首条评论）

```markdown
## 问题现象
## 复现步骤
## 影响范围
## 假设与验证（调查过程）
- 假设1：… → 验证手段：… → 结论：…
- 假设2：…
## 初步结论 / 根因
## 关键验证代码片段（临时代码已删，仅留片段）
```

### 修复总结模板（issue 关闭总结评论）

```markdown
## 修复总结
### 问题（一句话）
### 根因
### 解决方案（改了哪些 文件/蓝图/C++，分条）
### 验证（怎么确认修好）
### 影响范围（是否波及其他系统）
### 是否沉淀知识库？（是→已提炼到 docs/knowledge/xxx；否→为何不必）
```

### 知识条目模板（`docs/knowledge/坑-<主题>.md`）

```markdown
### [K-XXX] 标题
- 来源: Gitea issue #XX
- 症状: …
- 根因: …
- 避坑做法: …（核心价值）
- 状态: ✅正式方案 / ⚠️临时方案（预计转正时机：…）
- 关联: [[系统-技术方案]]、相关代码位置 file:line
```

ID 全库统一递增（K-001、K-002…），不分主题。新增后同步更新 `INDEX.md`。详见 `docs/knowledge/README.md`。

---

## 产出物清单（每次复杂问题必须交付）

1. ✅ issue 问题分析（描述 / 首条评论）
2. ✅ issue 关闭总结评论（修复总结）
3. ⚙️〔条件〕`docs/knowledge/` 知识条目 + `INDEX.md` 更新（仅当值得沉淀）
4. ✅ 临时代码已清理（`grep TEMP-INVESTIGATE` 无残留）

---

## 核心原则

- **issue 是工作台，知识库是精选集**：别把过程流水账灌进 docs，只提炼有长期价值的。
- **临时代码验证完即删**：仓库只留正式实现，结论和片段留在 issue。
- **诚实记录根因**：工作记录的价值在于「为什么」，不在于「我改了什么」——后者看 commit 就知道。