和 AI 编程助手交流,是一场＂证据先行＂的对话

by Sandy · AI 实战

你有没有过这种时刻——

AI 告诉你”已修复”,你点下刷新,错误还在。

再改一次,它再说”修好了”,你再刷新,还是那个红色报错。

我花了一周调试一个 Chrome 扩展,反复看到这一行：

AI 连续三轮说”修好了”,三轮都没修好。

第四轮,我换了一句话——不让它改代码,只让它先诊断。

十分钟后真相浮现:API Key 根本没配,系统一直在走”云端失败 → 冷启动本地 CLI → 加载 Skill”的降级长链路。配 Key 前 30 秒,配 Key 后 3 秒。差了 10 倍。

那一刻我才明白:

和 AI 交流的关键,不是”你帮我修 bug”,而是”我们先把证据摆出来”。

回头看这一周,像一场慢动作回放:

前三轮,我甩日志,AI 改代码。症状不消失。

第四轮我只问了一句:“别急着改。先告诉我,调用链长什么样？慢在哪一层？”

AI 停下来,画出了这张图:

真因瞬间浮出水面。前面三轮的每一次”修复”,都只是在给症状打补丁。

这一趟踩坑,让我沉淀出和 AI 协作的四个动作。顺序不能乱:

1证据先行:完整读完端到端日志

甩日志不是”告状”,是铺证据。完整读完端到端日志,再下结论。

我第一轮看到”卡死”就猜是超时,结果——超时只是症状,不是根因。

2根因定位:逐层拆开独立验证

一个问题看上去一团乱,就把它拆成三层单独验证:

· UI 层前端收到的是什么？

· 传输层curl 直打桥接,原始返回是什么？

· 后端层Python 脚本直接 spawn 子进程,行为是什么？

每层独立跑通,才能确认这不是一堆 bug 互相遮挡。

3一次性全链路改:列清单,避免套娃

动手前先回答一句:“这个改动会不会影响 X、Y、Z？”

否则就是”解决一个、冒出一个”的套娃。我花了 4 轮,才换来其实一轮就能搞定的答案。

4真实场景回归:用真实数据测试

用”hi”两个字测出来的”修好了”,不是修好了。

长文本、冷启动、特殊字符、真实用户路径——边界场景,每一个都要专门造用例。

这趟下来,我写下了几条和 AI 共事的”潜规则”——每一条都是自己踩出来的:

说到底,这些规矩只有一句话——把 AI 当”协作工程师”,而不是”全自动修 bug 机器”。它没有直觉,只能基于你给的信息推理。你给的越结构化,它的输出越靠谱。

这一周最大的收获,不是”修好了一个 bug”,而是“重新学了一遍怎么复盘”。

《道德经》有句话很重——“知人者智,自知者明。”

复盘不是事后的写总结,是过程中的持续自知。每结束一轮,都要在心里问四句话:

1这一轮,真的解决了什么？

2哪些症状没消失？

3是不是又埋了新问题？

4下一轮,应该聚焦什么？

这四句话,不只是用来和 AI 共事。做项目、做流程、收拾一地鸡毛

——任何复杂的事,都需要证据先行、根因定位、一次性改、真实场景验证的闭环。

AI 不是魔法棒。它不会替你想清楚问题在哪。

你给的信息越完整,它越准；你复盘越清晰,它越高效。

AI 是你的”协作工程师”。

而你,是那个知道证据在哪、知道怎么验证、知道怎么复盘的人。

这份能力,AI 时代只会更值钱。

· · ·

点赞+关注 ，共同成长