用了 AI 还在重复踩坑？该升级的不是提示词，是你的认知

用了 AI 还在重复踩坑？该升级的不是提示词，是你的认知

几个版本连着出了事。

这事本身不稀奇——做开发的谁没在线上翻过车。稀奇的是：我当时已经在用 AI 写代码了。

按理说，AI 帮我分析需求、生成方案、自检影响范围，出错概率应该比纯手写低才对。可现实是，我用着 AI，照样连着把同一类 bug 送上了线。

那一刻我意识到一件事：问题不在 AI 写错了什么，而在我用 AI 的方式，没有让我真正"升级"。

一个反直觉的事实：AI 不会自动消除你的盲区

我们容易有个错觉：有了 AI，等于身边坐了个永不疲倦的高级工程师，那重复犯错的概率应该趋近于零。

但连续三个版本都漏了同类问题之后，我开始怀疑这个假设。

AI 确实能补全我知识的缺口。但它补全的方式，是顺着我的指令、我的上下文、我对问题的定义来补全。如果我对"这次改动的风险"本身就有盲区，AI 会非常体贴地沿着这个盲区继续往下写——它不会主动跳出来质疑你的前提。

换句话说，AI 放大的是你已有的工作方式，而不是自动修复你的工作方式。 你的流程有个洞，AI 只会帮你更快地把东西填进洞里。

所以重复犯错这件事，在 AI 时代有了全新的含义：它不再是"我粗心了"，而是一个清晰的信号——你的方法论、工作流、或者认知模型，有一处需要升级了。

重复犯错 = 方法论在报警

我开始换个角度问自己：为什么会重复踩同一类坑？

如果只犯一次，可以说运气不好、测试没覆盖。但如果同一类问题反复出现——Category 改坏了全局行为、cancel 逻辑破坏了旧契约——这就不是"偶然"，而是我的认知模型里缺了一块：我从来没有把"改动会影响哪些我没写进需求的地方"当成一道必须过的关。

这里有个关键的区分：

• 低水平重复：同样的代码写错两次 → 这是粗心
• 高水平重复：不同的需求，触发同一类系统性风险 → 这是方法论缺陷

我遇到的是第二种。每次需求不同，AI 生成的代码不同，但底层漏掉的东西一样：影响面建模。

所以真正该升级的不是"让 AI 写得更准"，而是让我自己建立一套能看见影响面的方法论。AI 在这里的角色，应该是帮我升级这套方法论的杠杆，而不是替我写代码的工具。

用 AI 升级方法论，而不是用 AI 写代码

这个认知转变之后，我的做法完全反过来了。

以前我的默认动作是：把需求丢给 AI，让它产出代码，然后我（或它）检查一下。

现在我的默认动作是：先逼自己（和 AI）把"这次改动可能在哪里翻车"说清楚，再谈写代码。

具体到那两次事故，我做了三件事，每一件都不是在"修代码"，而是在"修我看待改动的方式"：

1. 把"最小改动"换成"最小风险改动"

原来我让 AI 检查"是不是最小、最优改动"。这个问题隐含了一个错误假设：改动越少越安全。

在老项目里这恰恰相反。改一行公共 Category，可能比改三十行业务代码风险大一百倍。我把问题换成"从最小风险的角度审查"，AI 的回答就从"我改了三行，很干净"变成了"这三行改了之后，哪些调用方的行为会变"。

这不只是换了个 prompt，是我对自己决策标准的升级。

2. 把每次事故变成"外部化的检查清单"

以前出了事，我在心里记一笔"下次注意 Category"。但人的记忆是不可靠的，下次换个场景照样忘。

现在每条线上 bug 都变成一条写进 AI_REVIEW.md 的固定检查项。下次我再让 AI 改代码，这份清单是前置上下文的一部分。

这是我把自己易漏的点，从"靠脑子记"升级成了"靠系统记"。

3. 让 AI 当"变更审计员"，而不是"实现者"

最大的转变是角色定义。我不再把 AI 放在"帮我写"的位置，而是放在"逼我问对问题"的位置。

写代码前，先让 AI 列调用链、列所有调用方、列禁止项。它做不到这些，我就不能声称影响可控。

这本质上是用 AI 来强制我走完原本会跳过的思考步骤。

一个更底层的结论

回看整个过程，技术细节（Category、请求契约、XCTest）反而是最不重要的部分。

真正有用的东西是一个简单的循环：

重复犯错 → 承认是自己的方法论有盲区 → 把盲区外部化成规则/测试/提问框架 → 用 AI 把这个框架固化进每次工作 → 下一轮盲区往上抬一层

AI 在这里的价值，不是它比你聪明，而是它给你一个低成本把你的认知显性化的界面。你原来脑子里的"感觉不对劲但说不清"，可以通过和 AI 的对话逼自己变成"明确规定、可检查、能复用"的东西。

大多数人用 AI 的方式是"让它替我干活"。但如果你发现自己用了 AI 还在重复踩坑，那说明你需要的不是更努力地用 AI 干活，而是停下来问一句：

我是不是该用 AI，来升级一下我干活的方式本身？

三件你可以立刻做的事

如果你也在用 AI 工作，尤其是做需要判断力的复杂任务，我建议把这个逻辑跑起来：

1. 建立你自己的 AI_REVIEW.md — 不是让 AI 更会写，而是把你反复踩的坑写成固定规则，每次对话前置喂给它。把"人记着"变成"系统记着"。
2. 给每次重复犯错做一次"认知溯源" — 别只修 bug，问自己：这次漏掉的，是我哪一层认知模型没覆盖到的？把它显式化。
3. 把"最小改动"改成"最小风险改动" — 不只针对代码，对任何改动都适用：少改不等于安全，要看它动的是不是公共的、隐式的、别人依赖的东西。

AI 不会替你升级认知。但如果你愿意，它可以是一面镜子，照出你工作流里那些你以为没问题、其实一直在漏的地方。