核心论点AI 调试不是把报错贴进去就能修好——幻觉修复比报错本身更危险。AI 的真正价值在于做系统化的排除法穷举可能原因 → 逐条验证 → 定位根因。人负责判断该信什么AI 负责不漏掉什么。一个每天都发生的场景你盯着experiment_service.py的这段逻辑前端实验配置刷新后有时不生效asyncdefrefresh_experiment_config(self,shop_id:str):cache_keyfexp_cfg:{shop_id}cachedawaitself.redis.get(cache_key)ifcached:returnjson.loads(cached)configawaitself.db.fetch_config(shop_id)awaitself.redis.set(cache_key,json.dumps(config),ex300)returnconfig本地测了 10 次8 次正常2 次拿到旧数据。没有报错——没有任何 traceback 可以贴给 AI。这就是调试中最难的那一种不是语法错了是逻辑在某个你不知道的条件下不可靠。不是贴报错而是构造可复现的诊断实验反模式给 AI 一个模糊场景❌ refresh_experiment_config 有时候返回旧数据帮我看看哪里有问题 → AI 可能给你 5 种猜测全是一般做法——Redis 连接池满了、序列化问题、时间窗口问题…… → 你不知道该信哪个只能一个一个试正确做法把症状翻译成可验证的假设✅ 上下文 1. 环境FastAPI redis (aioredis) PostgreSQL 2. 症状refresh_experiment_config 间歇性返回旧数据~20% 概率 3. 触发条件观察高并发时才出现单请求测试正常 4. 已排除的日志显示 redis.get 返回的 key 存在且 ttl 250s 请帮我做排除法 第一步列出这个函数中能导致拿到旧数据的所有可能原因 第二步为每个原因设计一个验证实验不用改代码先做观察 第三步按概率从高到低排序AI 的输出会比模糊提问精确得多因为间歇性 高并发限制了搜索空间——不是序列化问题是并发读写的时序问题已排除redis.get 返回值正常避免了无意义的方向要求设计验证实验而非直接改代码——控制风险排除法框架不是问怎么修而是问怎么找到原因调试中最值钱的不是修复方案AI 很擅长——是定位到正确的根因AI 需要你的引导。标准四步对话模板Step 1: 画边界 这是症状、这是环境、这是我已排除的、这是我怀疑的方向 Step 2: 穷举可能原因 这个症状的可能原因有哪些按大类列代码逻辑 / 依赖组件 / 并发时序 / 数据问题 Step 3: 逐个排除 针对原因 2并发时序我应该加哪些日志/断点来确认 → AI 给一组诊断插桩 → 你跑一次 → 反馈结果 Step 4: 根因确认 修复 确认是 redis.set 在 await 之后可能被并发请求覆盖。请给出修复方案需要考虑(a) 不引入分布式锁 (b) 保留 5 分钟缓存这个框架的核心每一步你都只做一件事AI 的答案窄而深。来自 Shop-Agent 的真实案例permissions.py的check_tool_permission函数曾经有一个 bugrequest-return工具在ROLE_TOOL_PERMISSIONS定义里被排除OPERATOR但实际运行时OPERATOR也能执行退款。给 AI 的正确喂法是症状OPERATOR 角色能执行 request-return权限配置已排除 环境contextvars 存储 client 角色中间件设置 → 路由层调用 check_tool_permission 我已查过_MOCK_CLIENTS 中 OPERATOR 的 role 值正确 (Role.OPERATOR) 请做排除法 可能原因 A — set_current_client 在请求中没被正确调用 → 用什么日志验证 可能原因 B — check_tool_permission 的 frozenset 查找逻辑有问题 → 加什么断言 可能原因 C — 工具注册时绕过了权限检查 → 在哪个调用点加日志AI 输出三组验证实验逐条排查后定位到工具的注册入口在tool_registry.py里直接暴露了所有工具没有调用get_client_accessible_tools做过滤。识别看起来对但实际错的幻觉修复这是 AI 调试最危险的陷阱。AI 给出的修复在语法上是对的但逻辑上有致命缺陷。三类典型幻觉类型特征例子缺少边界条件修复了新问题没覆盖旧路径if config: cache.set()→ 但config可能为{}空 dict 也是 truthy修了症状没修根因绕过问题而非解决问题“加asyncio.sleep(0.1)避免竞争” → 真正的问题是缺少写屏障引入不必要方案用重型方案解决轻量问题“用 Redis 分布式锁解决并发写” → 你的并发量用asyncio.Lock就够了防御策略三个追问拿到 AI 的修复方案后三个追问Q1: 这个修复在什么情况下会失效 → 让 AI 自己暴露边界条件 Q2: 如果不用你建议的依赖如 redis-lock纯代码层面有方案吗 → 防止 AI 引入不必要的依赖 Q3: 这个修复和原逻辑的差异是什么哪些调用方的行为会改变 → 发现 API 兼容性问题实际操作中Q1 是必问的——它揭穿了大量 AI 自己都没意识到的脆弱点。什么时候放弃 AI自己上不是所有 bug 都适合交给 AI。以下信号意味着你比 AI 更快信号原因行动AI 连续三轮给的修复方向都不同它在猜没有收敛停止对话你自己做一次二分法定位涉及你项目特有的中间件黑盒行为AI 不知道你的 k8s configmap 刷新延迟是 30 秒你查文档别把时间浪费在给 AI 解释上问题出在第三方库的 bugAI 会当它是正确行为来分析直接看 GitHub issues你已经有了一个很窄的怀疑范围直接动手验证比写 prompt 快加print()比跟 AI 聊天快 10 倍一条铁律AI 在调试中的最佳角色是帮你穷举你没想过的因素——而不是替你做判断。当你已经有了清晰假设直接验证不需要 AI。核心要点调试效率不由 AI 能力决定由你喂的信息质量决定——模糊输入 随机猜测排除法是 AI 调试唯一可靠的框架——穷举可能原因 → 逐条验证 → 定位根因三个追问防幻觉什么情况下失效不用新依赖能做吗哪些调用方受影响当你有了清晰假设直接自己验证——花 5 分钟加日志比花 10 分钟给 AI 解释你的项目快