Grok Build实战指南④：Bug修复实战——让AI从错误日志里找出问题根源

上一期讲了代码重构，这一期讲另一个开发者日常痛点：Bug 修复。

Bug 修复是 Grok Build 最实用的场景之一——你不需要花半小时读错误日志，只需要把日志扔给 Agent，让它帮你定位问题。

为什么 Grok Build 适合修 Bug？

修 Bug 有两个最难的部分：

• 定位问题：错误信息通常只告诉你哪里出错了，而不是为什么出错
• 理解上下文：一个错误可能是多个文件、多个调用链共同导致的

Grok Build 的优势在于：它可以同时读取多个文件，理解完整的调用链，然后告诉你问题的根源在哪里。

场景：Flask API 的 500 错误

假设你有一个 Flask API，运行时出现 500 错误，日志如下：

ERROR in app.py:34
Traceback (most recent call last):
  File "app.py", line 34, in get_user
    return jsonify(user_service.get_user_by_id(user_id))
  File "/app/services/user_service.py", line 28, in get_user_by_id
    return db.query(User).filter_by(id=user_id).first()
AttributeError: 'NoneType' object has no attribute 'query'

第一步：把日志扔给 Grok Build

修复这个 500 错误：

错误日志：
ERROR in app.py:34
Traceback (most recent call last):
  File "app.py", line 34, in get_user
    return jsonify(user_service.get_user_by_id(user_id))
  File "/app/services/user_service.py", line 28, in get_user_by_id
    return db.query(User).filter_by(id=user_id).first()
AttributeError: 'NoneType' object has no attribute 'query'

相关文件：
- app.py
- app/services/user_service.py
- app/models/user.py

第二步：Grok Build 会做什么

1. 分析错误类型

Agent 识别出这是一个 AttributeError——db 变量是 None。

2. 追踪 db 变量的来源

Agent 读取 user_service.py，找到 db 的初始化代码：

from app import db

class UserService:
    def get_user_by_id(self, user_id):
        return db.query(User).filter_by(id=user_id).first()

问题可能是：db 在 import 时还没有初始化（Flask 应用上下文问题）。

3. 生成修复方案

Agent 识别出两个可能的根因：

1. Flask 应用上下文没有正确初始化
2. db 对象在 app/__init__.py 中没有正确绑定

第三步：Agent 的修复代码

Agent 会修改 user_service.py，使用 Flask 的 current_app 来获取 db：

from flask import current_app

class UserService:
    def get_user_by_id(self, user_id):
        db = current_app.extensions['sqlalchemy'].db
        return db.session.query(User).filter_by(id=user_id).first()

或者更简洁的方式：

from app import db

class UserService:
    def get_user_by_id(self, user_id):
        with db.session.begin():
            return db.session.query(User).filter_by(id=user_id).first()

第四步：运行验证

Agent 会运行测试或实际请求来验证修复是否成功。

更复杂的场景：跨文件的 Bug

有时候一个 Bug 的根源不在报错的地方，而在别处。比如：

ERROR: TypeError: unsupported operand type(s) for +: 'int' and 'str'
  File "calculate.py", line 45, in total_price
    return sum(items)  # 看起来没问题

问题可能不在 calculate.py，而在上游：某个地方把数字转成了字符串。

让 Grok Build 追踪：

追踪 TypeError 的根源：

错误：TypeError: unsupported operand type(s) for +: 'int' and 'str'
位置：calculate.py:45 in total_price

请分析整个数据流，找到把数字变成字符串的地方。

Agent 会向上追溯调用链，找到具体是哪个函数在哪个位置把类型弄混了。

修 Bug 的最佳实践

• 提供完整的错误日志：包括完整的 Traceback，不要只贴最后一行
• 说明相关文件：告诉 Agent 哪些文件可能和问题相关
• 描述预期行为：告诉 Agent 你期望的输出是什么，帮助它判断修复是否正确
• 让 Agent 先分析再修复：可以先问"这个错误的根本原因是什么"，确认理解正确后再让 Agent 动手

下期预告

下一期讲 Grok Build 的团队协作场景：如何用 Grok Build 做 Code Review，以及如何在团队中推广 AI 编程工具。

---

Grok Build 实战指南系列 ④ 待续，共七期。