聚焦式功能修复
将以下提示词粘贴到你的 AI 对话框中:
请根据 https://skillhub.cn/install/skillhub.md,安装 @user_3c6cb52e/focused-fix
技能介绍
面对复杂功能模块的修复困境
在维护大型代码库时,开发者常遇到某个功能模块整体失效或行为异常的情况。这类问题往往不是单行代码的逻辑错误,而是由于依赖断裂、环境配置缺失、类型不匹配或上下游消费者未同步更新等多重因素交织导致的。如果直接凭直觉去改代码,很容易陷入“打地鼠”式的修修补补,导致问题不断蔓延。focused-fix 技能正是为了解决这种系统性故障而设计的。
严格的五阶段修复协议
该技能通过一套不可妥协的结构化协议来确保修复的彻底性,核心分为五个严格按序执行的阶段:
- Phase 1: SCOPE(界定范围):在触碰代码前,必须完整阅读功能文件夹内的所有文件,理解其职责并生成功能清单(Feature Manifest)。
- Phase 2: TRACE(追踪依赖):全面映射模块的入站(Inbound)和出站(Outbound)依赖,验证所有导入、环境变量、配置和 API 端点的真实存在性与一致性。
- Phase 3: DIAGNOSE(深度诊断):系统化检查代码质量、运行时状态、测试、日志和配置。对每个关键问题进行根因确认,并按照 HIGH、MED、LOW 进行风险分级。
- Phase 4: FIX(系统性修复):遵循严格的修复顺序:先修依赖,再修类型,接着修业务逻辑,然后补充测试,最后处理集成。若连续 3 次修复引发新问题,将触发架构级告警并强制停止。
- Phase 5: VERIFY(全面验证):运行该功能及其所有消费者的全部测试,确保没有引入回归错误。
适用边界与注意事项
focused-fix 并非用于快速修复单个 bug 的工具,如果问题仅局限于单个函数或文件的逻辑错误,应使用专门的系统调试技能。此外,该协议强调“诊断未完成前禁止提出修复方案”的铁律,任何试图跳过依赖追踪或根因确认的直觉修复都会被协议明确拦截。
使用场景
- 修复因依赖断裂导致整个功能模块失效的复杂问题
- 重构后需验证接口变更是否破坏了所有下游消费者的调用
- 排查因环境变量缺失引发的运行时异常并修复根因
- 遇到连续修复引发连锁报错时评估架构风险并决定重构
适合人员
- 维护大型遗留代码库且常需修复跨模块故障的后端工程师
- 需要确保组件库更新不破坏业务项目的前端架构师
- 负责排查生产环境配置与运行时依赖问题的研发团队