AI 前端代码修复：能改一行，就别重写半个组件

AI 前端代码修复：能改一行，就别重写半个组件

AI 修代码很快，复制报错、贴上组件，它能给一段“修复版”。问题是很多修复太猛：一个类型错误，重写半个组件；一个样式错位，换一套布局；一个 effect 依赖问题，顺手改状态模型。能改一行，就别重写半个组件。

前端代码修复要遵守最小变更原则。AI 可以给方案，但必须解释风险和影响范围。否则修 bug 修出新 bug，像拿扫帚打蚊子，蚊子没了，玻璃也没了。

一、先定位失败类型

修复前要分类：类型错误、运行时报错、样式回归、性能退化、测试失败、可访问性问题。不同问题用不同策略。

flowchart TD
  A[失败信息] --> B[分类]
  B --> C[最小修改建议]
  C --> D[影响范围分析]
  D --> E[生成 Patch]
  E --> F[运行测试]

不要一上来让 AI “优化整个组件”。这句话基本等于邀请它自由发挥。

二、给 AI 足够上下文，但限制输出

输入包括报错、相关代码、测试、期望行为。输出要求 diff，不要整文件重写。

请只返回最小 unified diff。
不要重命名组件。
不要修改无关样式。
解释为什么这个改动能修复测试。

限制越清楚，结果越可控。AI 修复不是许愿池。

三、修复结果要跑验证

至少跑相关单测、类型检查和 lint。UI 问题还要截图或视觉回归。

repair_checks:
  - pnpm typecheck
  - pnpm test Button.spec.tsx
  - pnpm lint
  - visual_snapshot: Button

没有验证的 AI 修复，只是“看起来像修了”。前端很多问题就是看起来没问题。

四、记录被拒绝的修复

AI 生成的修复如果太大、改错方向、引入副作用，要记录原因。后续可以优化提示词和上下文选择。

团队也可以建立“禁止修复模式”：禁止无理由重构、禁止删除测试、禁止扩大类型 any、禁止隐藏报错。

还要把修复范围和文件数作为风险信号。一个按钮测试失败，AI 给出 12 个文件改动，这不是聪明，这是失控。CI 可以拦截超范围 patch，让开发者重新拆任务。

ai_repair_guard:
  max_files_changed: 3
  forbid:
    - "delete test"
    - "add any"
    - "disable eslint"

对于复杂 bug，可以让 AI 先写诊断报告，再人工决定改法。别让它一边猜一边改，前端项目受不了这种热情。

修复完成后，Review 评论也要简短：改了什么、为什么、验证了什么。AI 生成一大段自我感动的解释，只会污染 PR。

还可以把 AI 修复分成两个阶段：先生成诊断，再生成补丁。诊断阶段只允许读代码和日志，不允许改文件；补丁阶段必须引用诊断里的证据。这样能减少“没看清问题就开改”的情况。

repair_flow:
  diagnose: 找到失败原因和影响范围
  patch: 只修改与诊断匹配的最小代码
  verify: 运行相关测试

前端项目已经够乱了，不需要一个过度自信的自动重构器再添柴。

最后还要保留人工接管入口。AI 修不动时，不要连续生成十版补丁污染上下文。输出诊断、停止自动修改、交给开发者，反而更专业。

停手，也是工程能力的一部分。

五、总结

AI 前端代码修复要坚持最小变更。先分类问题，限制输出为 diff，跑验证，并记录被拒绝原因。

能改一行，就别重写半个组件。修复的美德不是华丽，是克制。