针对性修复

focused-fix

分类通用

作者Alireza Rezvani

许可MIT

评分4.90/5

使用4.7K

/focused-fix

使用 5 阶段协议系统性地修复整个功能或模块。目标：$ARGUMENTS（功能路径或模块名称）。

如果 $ARGUMENTS 为空，请询问用户需要修复哪个功能/模块。

协议 —— 按顺序执行全部 5 个阶段

第一阶段：SCOPE（范围） —— 映射功能边界

1. 识别目标功能的主要文件夹/文件
2. 读取该文件夹中的每一个文件 —— 理解其用途
3. 创建功能清单：

code

功能范围 (FEATURE SCOPE):
  主路径: <path>
  入口文件: [被应用其他部分导入的文件]
  内部文件: [仅在该功能内部使用的文件]
  文件总数: N

第二阶段：TRACE（追踪） —— 映射所有依赖

入站依赖 (INBOUND)（本功能导入的内容）：

追踪每个 import 语句至源头，验证其存在且已导出

检查环境变量、配置文件、数据库模型、API 端点、第三方包

出站依赖 (OUTBOUND)（导入本功能的内容）：

在整个代码库中搜索对本功能的导入

验证调用方是否使用了正确的 API/接口

输出一份包含入站、出站、环境变量和配置文件的依赖图谱。

第三阶段：DIAGNOSE（诊断） —— 找出所有问题

运行所有诊断检查：

代码: 导入是否可解析、是否存在循环依赖、类型是否一致、错误处理、TODO/FIXME

运行时: 环境变量是否设置、迁移是否最新、API 结构是否正确

测试: 运行所有相关测试，记录失败项，检查覆盖率

日志: 检查 git log 中的近期变更，搜索错误日志

配置: 验证配置文件，检查开发/生产环境的不一致

对于发现的每个问题：

在加入修复列表前，通过证据确认根本原因

分配风险等级：高 (HIGH: 公共 API, 鉴权, 调用方 > 3 个) / 中 (MED: 有测试的内部模块) / 低 (LOW: 叶子模块)

输出一份按严重程度分组的诊断报告。

第四阶段：FIX（修复） —— 系统性修复

严格按此顺序修复：
1. 依赖 —— 损坏的导入、缺失的包
2. 类型 —— 边界处的类型不匹配
3. 逻辑 —— 业务逻辑 Bug
4. 测试 —— 为每项修复修复或创建测试
5. 集成 —— 与调用方进行端到端验证

规则：

一次只修复一个问题，每次修复后运行相关测试

如果修复导致其他功能损坏 $\rightarrow$ 返回 DIAGNOSE 阶段

优先级：高 $\rightarrow$ 中 $\rightarrow$ 低

三次机会原则 (3-Strike Rule)：如果 3 次以上的修复产生了新问题，立即停止。告知用户架构可能需要重新设计，而非简单的打补丁。

第五阶段：VERIFY（验证） —— 确认一切正常

1. 运行功能文件夹中的所有测试
2. 运行所有导入该功能的文件的测试
3. 如果可用，运行全量测试套件
4. 总结所有已做的更改

输出一份完成报告，包含修改的文件、应用的修复、测试结果以及验证的调用方。

铁律