速读#
这篇不是 AI 使用技巧，而是半年后划出的边界：AI 适合查找、解释、生成重复结构，不适合替我完成第一次理解。两次教训都不是「AI 给错了」，而是「跑通了但我没懂」，所以规则很硬：生成后必须逐行能解释。
先分清：有些事交给它合理，有些事不能交#
我用自己总结的「AI 六面」来卡这件事——任务边界、提示上下文、验证、理解缺口、失败纠偏、能力边界。这不是哪本书上的框架，是半年里每次用完觉得「哪里不对」时记下来的检查点，攒到最后正好六个。前两面（什么任务、给它什么上下文）大家都会想；真正决定 AI 是「加速器」还是「跑偏放大器」的，是后面四面。
合理的杠杆（我交给它的）：
| 场景 | 例子 | 它替我省的是 |
|---|---|---|
| 查语法/参数 | 「Nginx 的 proxy_set_header 有哪些常用的」 | 从翻文档 10 分钟 → 10 秒 |
| 缩小排查方向 | 贴 Java 堆栈问「最可能的原因」 | 不用盲目 Google |
| 生成重复结构 | 「帮我写一个 systemd unit 模板」 | 省去记格式的心力 |
这些本质是用 AI 替代机械查找，把注意力释放给真正该想的部分。这是合理杠杆。
不能交的：新概念第一次接触时的「理解」这一步。下面两次栽跟头，根子都在这里。
两次栽跟头：答案对了，我不懂为什么#
危险不在「它给错答案」——那种验证一下就知道。真正的坑是：它给的答案是对的、跑通了，但我不理解为什么。两次具体经历。
多阶段构建的 Dockerfile#
写容器化部署那篇时，我让 AI 生成了多阶段构建的 Dockerfile。它给的能跑，我直接用了。两天后想加一层缓存优化，发现自己完全不理解 COPY --from=build 的机制，也不知道为什么把 pom.xml 单独先拷进去能加速依赖缓存。
我不得不回头从 Docker 层缓存机制重新学，花的时间比一开始自己写还多。
这对应的恰好是 AI 六面里的理解缺口：任务完成了（能力边界内的活它干了），但任务背后的理解留在了它那边，没过到我这边。等我需要在这个基础上做第二步，缺口就暴露了。
漏了 X-Forwarded-Proto#
AI 给我的 Nginx 反代配置里漏了 X-Forwarded-Proto 这个 header。配置跑得起来，看起来一切正常——直到上了 Cloudflare HTTPS，WordPress 开始无限重定向。排查一小时才定位到是协议头没传，后端不知道外层是 HTTPS。
这个错误如果我当时逐行理解了每个 proxy_set_header 的作用，根本不会发生。它对应的是验证这一面：我验证了「能跑」，没验证「每行在干嘛」。能跑 ≠ 对。
两次都是同一种债：跳过理解这一步，等于借了一笔迟早要还的债。 第一次是显性的（回头重学），第二次是隐性的（上线后翻车）。
失败纠偏之后，我形成了几条规则#
栽过两次，我对 AI 辅助有了一套明确的纪律，不再凭感觉。这几条本质都是在补「验证/理解缺口」那一面：
- 生成之后必须能逐行解释。 对着它给的代码，我没法给别人讲清每一行在做什么，就不算完成——要么追问，要么自己查。这条直接针对第二次那个漏 header 的坑。
- 破坏性命令绝不盲执行。
rm -rf、DROP TABLE、改 SSH 配置这类，哪怕它给了，我也逐字看完、确认影响范围再敲。能力边界：AI 不替我对不可逆动作负责。 - 用「解释」代替「给答案」。 大多数时候我问的是「这段报错意味着什么」「这两种写法区别是什么」，而不是「帮我写一个 XXX」。问法决定了我是要理解还是只要成品。
- 新概念第一次接触时不让 AI 生成代码。 第一次学的东西，自己敲一遍的理解深度远超复制粘贴。AI 留给第二次、第三次那种纯效率场景。
能力边界#
回看这半年，AI 对我帮助最大的地方集中在「我已经知道方向、只差机械劳动」的场景；栽跟头的地方，清一色是「我还不知道方向，却让它替我走」。
所以我现在对它的定位很明确：它是一个极其高效的加速器，但加速的前提是知道方向。方向错了，它只会让我更快地跑偏。
能力边界这一面，我最后形成的判断是——它替我干「查找和生成」，我不替它干「理解和判断」。理解和判断这两个环节，一旦交出去，债就开始计息了。
AI 是搭子，不是替我思考的人。搭子的价值是搭把手，不是替我决定往哪走。半年用下来，真正省下的时间，来自我越来越清楚哪一步该自己走、哪一步可以搭车。