不是 AI 跑偏了，是你根本没把问题讲明白
说句不好听的。很多人天天说自己会用 AI、会提效、会搞 Agent。可一到真 bug 面前，马上打回原形：打开公司 bug 系统扫两眼，问测试怎么复现，自己点页面乱试一通，再把截图、日志、curl 一股脑丢给 AI，来一句：“你帮我看看。”
最后问题没收敛，AI 还背锅。但说穿了，不是 AI 不行，是你根本没把问题讲明白。
所以我现在越来越确定一件事：处理 bug，值钱的不是修掉这一次，而是把这次处理过程，顺手做成 SOP。 修一个 bug，只能爽一次；做成 SOP，后面才是真的省时间。
我以前也这样。看系统、翻日志、补截图，这边问一句，那边答一句，和 AI 来回拉几十轮，最后还是一团乱麻。现在回头看，这套搞法不是慢，是蠢。你以为自己在分析，其实只是在陪 bug 聊天。
很多 bug 处理得慢，不是因为真有多难，而是过程太散，信息太乱，全靠感觉硬顶。没有结构，就很难交给 AI；没有结构，就很难复盘；没有结构，就很难交给下一个人。最后每个 bug 都像第一次上岗。
真正难的，不是修 bug，而是先把问题整理成问题
我现在处理 bug，第一步不是修，而是先把问题整理干净。场景是什么，怎么触发，哪个接口能复现，参数是什么，现象是什么，预期是什么，报错和日志是什么，可能涉及哪些表、字段、代码路径。你把这些东西理顺，很多 bug 其实已经轻了一半。
因为真正难的，往往不是修，而是把一堆烂信息整理成一个能分析的问题。这一层不做，后面基本都在赌。
很多人喜欢一把梭喂上下文：bug 系统截图一贴，报错截图一贴，curl 一贴，聊天记录一贴，最后来一句“你帮我分析下”。看着材料很多，其实全是生料。AI 最怕的，不是信息少；AI 最怕的是信息乱。
所以我现在更习惯先做一层结构化。把原始描述、系统记录、复现方式、报错线索先收干净，再丢给 Agent 去排查。这一步一点都不花哨，但特别值钱：它不让 Agent 吃垃圾输入，不让自己一直看不清重点，也不让后面换人换模型之后又从头来。
很多人总问，为什么 Agent 老跑偏，为什么改完又炸。答案很简单：你给它的不是战场，是垃圾堆。 一个像样的 bug 输入，至少得有业务背景、复现方式、现象和预期、关键线索、任务边界。这些齐了，Agent 才是在干活；不然，它只是在陪你猜。
真正拉开差距的，是你能不能把这次修法留下来
所以我现在更在意的，已经不是这次修好了没有，而是下次能不能更快。这才是 SOP 的意义。别只盯着“今天搞定”，真正拉开差距的，是你有没有把这次处理路径留下来：先抽背景，再做接口复现，再把信息结构化，再让 Agent 定向排查，再人工 review，最后补一份可复用记录。这才叫 SOP。
不是写个文档放那吃灰，而是下次再来同类问题，真能直接拿出来用。bug 最烦的地方就在这：它不会只来一次，它只会换个皮再来一次。字段长度不够会再来，状态判断反了会再来，NULL 条件漏了会再来，参数映射错了也会再来。如果每次都重新问、重新看、重新排查，那你不是在进步，你只是在重复劳动。
所以我现在只盯两件事：标准输入，标准流程。 前者决定 AI 会不会跑偏，后者决定你下次是不是还要从零开始。
很多人喜欢吹自己会用 AI 修 bug。但真到实战里，能不能跑通，不看嘴。就看你能不能复现，能不能抽线索，能不能把问题讲清楚，能不能卡住任务边界，能不能看懂 AI 改了什么，能不能把过程沉淀下来。没有这些，AI 再强也只是陪聊。
说到底，我现在做的，不是让 AI 帮我修 bug，而是把整个 bug 处理流程压成一套稳定动作。前者只是偶发提效，后者才是长期复利。很多人修 bug，像在救火，火灭了就散了。但更好的做法是：这次灭火，顺手把灭火流程写下来。
别每次都靠经验、情绪和临场发挥。那种方式看起来猛，其实最不耐打。真正有价值的，不是你今天多会修，而是下次再来一个类似问题，你不用重新当一次新人。
说白了：会修 bug，不稀奇。能把修 bug 这件事做成 SOP，才真开始有点东西。
