AI辅助编程实战：9分钟修复遗留系统顽固Bug

一、问题背景：顽固Bug为什么总修不好

在一个持续迭代的自研项目里，我负责的内容分发工具压着一个陈年Bug：批量分发任务时，超过某个数量后，后续任务会被静默丢弃——不报错、不告警，只有用户投诉时才会被发现。这个问题前后换了几种排查思路都没能根治，原因很典型：

1. 跨模块链路长。任务从创建、入队、调度到状态回写，横跨多个模块，任何一环都可能“吞掉”异常。
2. 静默失败难定位。没有报错日志，意味着传统“看日志—定位—修复”的路径失效，只能靠埋点和二分排查。
3. 复现条件苛刻。问题只在任务数量超过阈值时出现，本地环境难以稳定构造。
4. 历史包袱重。相关代码经过多轮修补，存在大量防御性判断，阅读成本高。

这个项目三个月内累计新增与修改了数十万行代码，迭代节奏快，这类“低频但致命”的问题如果靠人工逐行排查，动辄消耗一到两天。这次我决定把整个排障过程交给AI编程助手，做一次完整实测。

二、9分钟排障时间线：人是决策者，AI是执行者

整个过程的实际耗时约9分钟，我一行代码都没有写，但每一步的关键决策都由我做出。拆解如下：

• 第0~2分钟：准备上下文。 整理三样东西：一段稳定复现的操作步骤、最近一次相关的运行日志、涉及分发的两三个核心模块代码。这一步是全程最重要的投入。
• 第2~4分钟：提交任务与根因假设。 AI在阅读上下文后给出两个候选假设，并指出优先验证方向：批量查询接口存在默认分页上限，超过上限的数据被静默截断。
• 第4~7分钟：生成并应用补丁。 AI给出最小化修改方案：将单次批量查询改为按上限分页循环拉取，并对截断场景补充显式日志。
• 第7~9分钟：验证与回归。 按AI给出的步骤在本地复现，确认120条任务全部分发成功；同时让AI补了一组边界用例（99、100、101、120条），全部通过。

值得强调的是分工逻辑：AI负责压缩搜索空间——在海量代码中快速收敛到可疑位置；人负责判断与验收——确认假设是否合理、补丁是否越界、验证是否充分。这个分工是整个流程能在个位数分钟内跑通的前提。

三、核心方法：上下文工程决定修复质量

复盘这次经历，真正决定成败的不是模型“聪明不聪明”，而是喂给它的上下文质量。可归纳为四条原则：

1. 复现优先。 在让AI修Bug之前，先拿出一个稳定、可重复的复现路径。复现路径本身就是最强的定位线索，它把“玄学问题”变成了“确定性输入”。
2. 信息完备但不冗余。 报错日志、运行环境、依赖版本、相关代码缺一不可，但不要把整个代码库丢进去。围绕可疑链路精选模块，能显著减少AI的误判。
3. 约束显式化。 哪些接口不能动、哪些兼容性必须保留、性能红线在哪里，都要写清楚。没有约束的修复方案，往往“顺手重构”，引入比原Bug更麻烦的回归。
4. 输出结构化。 要求AI按“根因假设—定位依据—最小补丁—回归用例”的顺序输出，强制它先解释再动手，可以提前拦截大量似是而非的方案。

一个可以直接套用的提示词模板：

【任务】修复"批量分发任务超过100条后被静默丢弃"的问题
【复现步骤】
1. 创建120条待分发任务
2. 触发批量分发
3. 现象：第100条之后的任务状态停留在"待处理"，无报错日志
【环境信息】运行时版本、依赖锁定文件、部署方式
【相关代码】任务调度模块、状态回写模块、批量查询封装
【约束】
- 不修改对外状态枚举与接口签名
- 不引入新的中间件依赖
- 修复需兼容存量数据
【输出要求】
1. 先给出根因假设与定位依据
2. 再给出最小化修复补丁
3. 最后列出建议补充的回归测试用例

四、修复之后：验证与回归是不可省略的一环

AI给出的补丁“看起来对”和“真的对”之间，隔着一整套验证流程。我的做法分三层：

1. 行为验证：按原始复现路径完整跑一遍，确认目标现象消失。
2. 边界验证：让AI围绕阈值生成边界用例。以本次为例：

def make_tasks(n):
    return [create_task(i) for i in range(n)]
def test_dispatch_boundary():
    for n in (99, 100, 101, 120):
        result = dispatch(make_tasks(n))
        assert result.success_count == n, f"n={n} 时分发不完整"

1. 影响面审查：人工审阅diff，重点看两件事——修改是否被限制在声明过的范围内；是否存在AI“顺手”引入的重构或防御性代码膨胀。

如果项目已有测试资产，务必让AI先跑通存量测试再交付补丁；如果没有，至少要求它为被修改的函数补齐单元测试。跳过这一步的AI修复，本质上是在积累新的技术债。

五、成本视角：万元级年预算怎么花在刀刃上

很多团队关心投入产出。以常见的市场形态看，AI编程工具主要有两种计费模式：订阅制按席位按年付费，个人与小团队的年度预算通常在数千至万元级；按量计费则与token消耗正相关，弹性大但需要治理。结合几个月的高强度使用，我的结论是：

• 分层使用。日常代码补全、注释生成用轻量档位即可；疑难排障、跨模块分析、测试生成这类高价值场景，才值得调用能力更强的模型档位。
• 把预算投向高频刚需。排障、写测试、代码评审是三项回报最确定的能力，预算应优先保障。
• 用工程师时薪衡量ROI。一次顽固Bug排查节省一到两天，就足以覆盖数月订阅成本。真正的成本不是订阅费，而是“该用而没用”的时间损耗。

无论是接入开源模型自建推理，还是直接使用百度智能云等云平台提供的模型服务，上述使用策略与成本框架都是通用的。关键在于建立“按场景分层”的使用规范，而不是全员无差别地消耗最高档位。

六、边界与风险：AI不是银弹

最后必须泼一盆冷水。这次9分钟的顺利修复，建立在前置条件齐备的基础上，实践中还有几个不能回避的坑：

1. 幻觉与错误修复。AI可能给出“能编译但不正确”的补丁，甚至编造不存在的接口。一切以验证为准，不能因为生成速度快就放松审查。
2. 数据合规。涉及核心业务代码或敏感数据时，要评估上下文出域风险，选择合规的部署形态（私有化推理或满足合规要求的云服务）。
3. 架构级问题仍需人主导。AI擅长在既有架构内定位与修复，但涉及架构演进、技术选型的决策，仍然是人的责任。
4. 团队规范先行。AI生成代码同样要过评审、补测试、明确归属，建议在团队层面固化流程，而不是依赖个人自觉。

七、写在最后

这次实测最大的收获不是“9分钟”这个数字，而是一套可复用的分工模型：人负责复现、约束与验收，AI负责搜索、定位与生成。上下文给得越准，修复质量越高；验证做得越实，回归风险越小。对被陈年Bug反复消耗的团队来说，AI编程助手的价值不在于替代谁，而在于把工程师从低效的搜索劳动中解放出来，让人的时间花在真正需要判断力的地方。