BUG-FIX-PROTOCOL Skill
Source: https://github.com/CodeAlive-AI/ai-driven-development/blob/main/BUG-FIX-PROTOCOL.md
Concept by Rodion Mostovoy
Core Philosophy
Тест-система = страховочная сетка (safety net)
- - Баг на проде = баг тест-системы в первую очередь
- Каждый баг-фикс = два фикса: код + патч тест-системы
- "Тесты" — это не только unit-тесты. Это всё:
- Unit / Integration / E2E тесты
- PRD assessment (соответствие продукт-требованиям)
- Review спеки и документации
- Code review
- Статический анализ (linters, type checkers)
- Визуальные тесты
⚠️ ГЛАВНОЕ ПРАВИЛО
НИКОГДА не фиксить баг без воспроизведения через тест.
Если воспроизвести через тест невозможно — скажи явно с обоснованием. Но не фикси молча.
8-Шаговый Протокол (Чеклист)
[ ] Шаг 1 — Понять баг
- - Разберись, что именно сломалось
- Придумай способ воспроизведения
- Непонятно → спроси, не гадай
- Не трогай код, пока не понял проблему
[ ] Шаг 2 — Воспроизвести через тест
- - Напиши тест, который падает на баге
- Тест должен быть красным ДО фикса
- Если воспроизвести через тест невозможно — скажи явно с обоснованием
- Не переходи к шагу 3 без красного теста (или явного объяснения почему нельзя)
[ ] Шаг 3 — Найти корневую причину
- - Ищи корень, не симптом
- Задай себе "почему?" минимум 3 раза
- Не фиксируй то, что видишь — найди то, что это вызвало
[ ] Шаг 4 — Спроектировать правильный фикс
- - Придумай грамотный фикс, не костыль
- Оцени scope изменений
- Большой рефакторинг → остановись, спроси перед началом
- Фикс должен решать корень, не симптом
[ ] Шаг 5 — Применить минимальные правки
- - Чини с минимальными изменениями
- Не затрагивай части кода, не связанные с багом
- Каждое изменение должно быть обосновано
[ ] Шаг 6 — Проверить тесты
- - Запусти тест из шага 2 → должен быть зелёным
- Запусти соседние/связанные тесты → не сломались?
- Запусти полный test suite если возможно
- Только зелёный suite → идём дальше
[ ] Шаг 7 — Deep Review: похожие проблемы
- - Раз тест-система не поймала этот баг — похожие проблемы могут быть везде
- Проведи поиск аналогичных паттернов в кодовой базе
- Проверь похожие модули/компоненты
- Задокументируй находки
[ ] Шаг 8 — Аудит тест-системы
- - Разберись, почему тест-система упустила этот баг
- Улучши тест-систему чтобы предотвратить класс подобных багов
- Это обязательный шаг, не опциональный
Шаблон: Документация баг-фикса
CODEBLOCK0
Шаблон: Аудит тест-системы после бага
CODEBLOCK1
Применение скилла
Когда тебе дают баг на фикс:
- 1. Прочитай этот чеклист
- Иди по шагам строго по порядку
- Не перепрыгивай шаги
- Если застрял — скажи на каком шаге и почему
- Финальный PR должен включать: фикс кода + патч тест-системы + документацию по шаблону выше
Помни: быстрый фикс без теста — это не фикс, это технический долг с процентами.
BUG-FIX-PROTOCOL 技能
来源:https://github.com/CodeAlive-AI/ai-driven-development/blob/main/BUG-FIX-PROTOCOL.md
概念作者:Rodion Mostovoy
核心理念
测试系统 = 安全网
- - 生产环境中的 Bug = 首先是测试系统的 Bug
- 每个 Bug 修复 = 两个修复:代码 + 测试系统补丁
- 测试不仅仅是单元测试。它包括所有:
- 单元测试 / 集成测试 / 端到端测试
- PRD 评估(是否符合产品需求)
- 规格和文档审查
- 代码审查
- 静态分析(代码检查工具、类型检查器)
- 视觉测试
⚠️ 核心规则
绝不在没有通过测试复现的情况下修复 Bug。
如果无法通过测试复现,请明确说明原因。但不要默默修复。
8 步协议(检查清单)
[ ] 第 1 步 — 理解 Bug
- - 弄清楚具体是什么出了问题
- 想出一种复现方法
- 不清楚 → 询问,不要猜测
- 在理解问题之前不要动代码
[ ] 第 2 步 — 通过测试复现
- - 编写一个因 Bug 而失败的测试
- 测试在修复前应为红色
- 如果无法通过测试复现 — 请明确说明原因
- 没有红色测试(或明确说明无法复现的原因)不要进入第 3 步
[ ] 第 3 步 — 找到根本原因
- - 寻找根源,而非症状
- 至少问自己三次为什么?
- 不要修复你看到的表象 — 找到导致问题的根本原因
[ ] 第 4 步 — 设计正确的修复方案
- - 想出合理的修复方案,而非临时补丁
- 评估修改范围
- 大规模重构 → 停下来,开始前先询问
- 修复方案应解决根源,而非症状
[ ] 第 5 步 — 应用最小修改
- - 以最小改动进行修复
- 不要触及与 Bug 无关的代码部分
- 每个改动都应有充分理由
[ ] 第 6 步 — 检查测试
- - 运行第 2 步中的测试 → 应为绿色
- 运行相邻/相关测试 → 没有破坏吧?
- 如果可能,运行完整测试套件
- 只有绿色套件 → 继续下一步
[ ] 第 7 步 — 深度审查:类似问题
- - 既然测试系统没有捕获这个 Bug — 类似问题可能到处存在
- 在代码库中搜索类似模式
- 检查类似模块/组件
- 记录发现
[ ] 第 8 步 — 审计测试系统
- - 弄清楚为什么测试系统漏掉了这个 Bug
- 改进测试系统以防止此类 Bug 再次发生
- 这是必须步骤,不是可选项
模板:Bug 修复文档
markdown
Bug 修复:[简短名称]
出问题的地方
[从用户/系统角度描述症状]
复现方式
[复现步骤或测试链接]
根本原因
[真正的原因,而非症状]
解决方案
[修改了什么以及为什么这样修改]
测试
- - 文件:path/to/testfile
- 测试:testname
- 修复前状态:🔴 红色
- 修复后状态:🟢 绿色
深度审查
[在类似位置检查了什么,发现了什么]
测试系统补丁
[在测试系统中添加/改进了什么]
模板:Bug 后测试系统审计
markdown
测试系统审计:[日期] — [Bug 类型]
漏掉的 Bug
[简要描述]
为什么测试系统没有捕获?
- - [ ] 测试未被编写
- [ ] 测试编写不正确(断言错误)
- [ ] 测试覆盖了快乐路径,未覆盖边界情况
- [ ] 集成层面未被覆盖
- [ ] 视觉变化没有视觉测试
- [ ] 静态分析未针对此模式进行配置
- [ ] 其他:_
改进内容
| |
| 端到端测试 | | |
| 静态分析 | | |
| 视觉测试 | | |
行动项
已接受处理
技能应用
当给你一个 Bug 需要修复时:
- 1. 阅读此检查清单
- 严格按照顺序执行步骤
- 不要跳过步骤
- 如果卡住了 — 说明卡在哪一步以及原因
- 最终的 PR 应包括:代码修复 + 测试系统补丁 + 按上述模板编写的文档
记住: 没有测试的快速修复不是修复,而是带利息的技术债务。