Files

T

starmen1265 b2820ec024 docs(workflow): 建立问题管理三段式工作流与经验知识库

- 新增 problem-solving skill：固化「问题分析→工作记录→知识沉淀」9步流程与3模板
- 新建 docs/knowledge/ 经验知识库（README/INDEX/临时方案登记/坑-UE5引擎含2条迁移示例）
- GIT-GUIDE 补 §2.7 临时代码 [TEMP-INVESTIGATE] 约定、§2.8 fix 提交引用 issue
- CLAUDE.md 项目管理段加问题管理引用
- 配套 Gitea 标签 type:bug / type:investigation（后台已建）

2026-07-16 19:19:59 +08:00

5.5 KiB

Raw Blame History

name, description

name	description
problem-solving	问题解决技能 — 改 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 描述 / 首条评论）

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

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

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

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

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

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

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

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

核心原则

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

5.5 KiB Raw Blame History Unescape Escape