12｜AI Coding 反模式清单：14 个让项目失控的错误

本篇是《从头重新学 AI 编程》系列第 12 篇，也是正文的最后一篇。

上一篇聊了 CI、Hooks 和测试，怎么给 AI 写的代码加护栏。

到这篇，正文就要收尾了。我想做个不太一样的总结。

前面十一篇，我一直在跟你讲「应该怎么做」。这一篇，我想反过来，讲「不该怎么做」。

为什么？因为我自己的经验是，正确的做法你听一遍可能记不住，但那些坑，你一旦踩过、疼过，就再也忘不掉了。我把这个系列里反复提到的、加上我自己实打实踩过的坑，整理成了 14 条反模式。

你不用一次记住。把它当成一份自查表，每隔一阵子拿出来对一遍，看看自己有没有不知不觉又掉进去了。

我大概把它分成三段。前面是工作方式上的坑，中间是验证环节的坑，最后是安全上的坑。越往后，出事的代价越大。

先从最常见的开始。

第 1 个，让 AI 直接动手，不先出计划。

你跟它说「帮我加个搜索功能」，它立刻就开写了。十分钟后给你看一堆改动，你一看，方向完全不对，它做的是全局搜索，你要的是列表内筛选。

推倒重来，前面那一通全白费。

这个坑第 1 篇就讲过了，正确的做法是先让它说它打算怎么干。先告诉我你打算怎么实现、改哪些文件、有什么边界情况。花三十秒对齐方向，省下后面三十分钟返工。

第 2 个，需求只甩一句话，没有验收标准。

「帮我做个导出功能」，导出什么格式，导出哪些字段，筛选条件带不带上，导出失败怎么办。这些 AI 不会主动问你，它会自己替你做决定。做完你才发现，又不是你要的。

第 2 篇讲的 Spec 就是干这个的。给需求的时候至少说清三件事，做什么、不做什么、怎么算做完。

第 3 个，上下文越塞越多，舍不得开新会话。

你在一个会话里聊了五十轮，改了十个文件，中间还推翻过三个方案。AI 的上下文窗口早就满了，它开始忘前面的约束，开始自相矛盾，开始走偏。

你以为它变笨了，其实是上下文被污染了。第 5 篇讲过那几个信号，忘记约束、反复改同一个地方、解释越写越长但 diff 越来越差。一旦出现，别恋战，果断换会话。

第 4 个，不看 diff，只看 AI 的总结。

它跟你说「已完成，添加了导出功能，测试通过」。你信了，合并了。

但你没看到的是，它顺手改了你的路由配置，把一个不相关的组件重命名了，还删了几行它觉得没用的代码。

AI 的总结是它的视角，diff 才是事实。永远自己看 diff，重点看改动范围有没有超出任务、有没有顺手动了无关文件、有没有删掉你看不懂的代码。

第 5 个，不跑测试，信 AI 那句「应该没问题」。

上一篇刚用一整篇讲过这事。AI 说测试通过了，不代表测试真的跑了。可能是旧测试，可能测试被它改过了，可能压根没跑。

让它把命令和输出贴出来，或者你自己跑。「应该没问题」不是验证结果，「测试跑了，输出贴在这」才是。

第 6 个，一个会话从头聊到尾，从不压缩和交接。

你在一个会话里，从需求讨论聊到方案设计，聊到实现，再聊到修 bug，整整聊了一天。到下午 AI 已经开始重复上午讨论过的东西，你解释过的约束它又问了一遍。

这不是 AI 的问题，是上下文太长了。每个阶段结束，让它写一份交接总结，第 5 篇有模板，然后开新会话。需求归需求，实现归实现，修 bug 归修 bug，别全堆在一个会话里。

第 7 个，让同一个 Agent 又做实现又做 review。

你让 AI 写完代码，又在同一个会话里让它审自己写的代码。结果当然是「一切正常」。

这就像让考生自己批卷子。第 7 篇讲的 Subagent 就是为这个设计的，实现和 review 必须分开，要么开新会话让另一个 AI 审，要么你自己审。

第 8 个，没有 AGENTS.md，AI 全靠猜。

你的项目没有 AGENTS.md，每次开新会话 AI 都从零开始猜。它不知道你的目录结构，不知道你的编码规范，不知道你的红线。有时候猜对，有时候猜错，而你也不知道它这次猜得对不对。

第 3 篇有模板，花二十分钟写一次，后面每次对话都省心。

第 9 个，没有 git 回滚点，改坏了回不去。

你让 AI 一通改，改了十几个文件，改完发现不对，想退回改之前的状态。但你一次都没 commit 过，git 里没有记录。

你只能一个个文件手动改回去。或者更惨，你已经不记得改之前长什么样了。

让 AI 每完成一个独立改动就 commit 一次。出问题就 git reset，不用心疼。git 就是你的 ctrl-z，多按几次不丢人。

第 10 个，把 AI 的解释当成验证结果。

AI 给你解释了一大段「为什么这样写是对的」，逻辑清晰，条理分明。你觉得有道理，就信了。

但「说得通」和「跑得通」是两码事，而 AI 最擅长的恰恰就是生成看起来很合理的解释。解释只是它的假设，验证才是结论。让它跑给你看，跑测试、贴输出、给证据，别被「解释得通」迷惑了。

聊到这，前十条基本都是工作方式和验证上的坑。接下来这四条，性质不太一样，它们关乎安全。

我把安全放在最后，不是因为它不重要，恰恰相反，是因为前面那些坑顶多让你返工、让你这次白干，而安全这几条，一旦出事，可能就是不可逆的。

第 11 个，让 AI 直接接触生产密钥。

你把 .env 里的生产数据库密码、API key 直接贴给 AI 让它帮你调试。或者你的 .env 没加进 .gitignore，AI 读文件的时候顺手就把它读进了上下文。

这些信息可能被存储、被转发、被记在日志里。一旦泄露，你只能轮换密钥，而且你根本不知道已经泄露多久了。

生产密钥永远不要进 Agent 能读到的文件。开发环境用单独的 dev 凭证，权限给到最小。.env 必须在 .gitignore 里，而且要确认它从来没被 commit 过。

第 12 个，让 Agent 不设权限边界地访问外部工具。

你给 AI 接了 GitHub MCP、数据库 MCP、浏览器 MCP，每个都用 admin 权限，图个方便，省得一个个配。

方便是方便了。但 AI 现在能读你的私有仓库、能改你的数据库、能访问任意网页。万一它被 prompt injection 攻击，也就是有人在它读到的网页或 issue 里埋了一段恶意指令，后果不堪设想。

第 6 篇讲过 MCP 的正确用法，核心就一条，最小权限。能用只读 token 就别用写权限，能用受限 token 就别上 admin，不需要的 MCP 干脆别接。

第 13 个，把内部敏感数据随手塞进上下文。

你把客户的订单数据、员工的薪资信息、公司的内部文档，直接贴给 AI 帮你分析。

这些数据现在就躺在 AI 的对话记录里了。这些记录会被存多久、谁能访问、会不会被用来训练，你都不知道。

敏感数据别直接往上下文里塞。如果非处理不可，用脱敏后的数据，或者干脆在本地跑模型。

第 14 个，让 AI 自动执行危险命令。

你开了 auto-run 模式，AI 不用确认就能跑 shell 命令。大多数时候确实没事，直到有一天它跑了一句 rm -rf，或者 git push --force。

一条命令，不可逆。

危险命令永远要留一道确认。用 Hooks 把 rm -rf、git push --force、DROP TABLE 这类操作拦下来，第 11 篇讲过怎么配。

这十四条过完，你可能也发现了，后面那四条全跟安全有关。这不是我硬凑的。

AI Coding 的安全风险，比传统开发大一个量级。因为 Agent 能读文件、能跑命令、能联网、能提交代码，它的攻击面实在太大了。

业内有个说法叫致命三重，Lethal Trifecta，说的是当一个 Agent 同时具备这三样能力的时候，被攻击的后果就是灾难性的。

• 第一，能接触私有数据，源码、.env、客户数据。

• 第二，能接触不可信内容，网页、外部 issue、用户输入。

• 第三，能把数据发出去，网络请求、git push、发消息。

你想想看，如果一个 Agent 这三样齐了，攻击者只要在它读得到的某个网页里埋一段话，就有可能让它把你的私有数据打包发出去。

所以防御的关键，不是把 AI 调得更聪明，而是想办法拆掉这三者的交集。不可信的内容，丢给一个只读、隔离的 subagent 去处理。MCP 一律用最小权限的 token。生产密钥，永远不进 Agent 能读的文件。

我一直觉得，安全这东西，不是拖住你用 AI 的刹车，反过来才对，它是让你敢放手用更多自动化的前提。权限锁得越死、hook 设得越严，你心里越有底，越敢让 Agent 在后台自己跑。

这份清单怎么用，我也说一下我的习惯。

它不是让你一口气背下来的。它是给你定期对照用的。

刚开始上手 AI Coding 的时候，你重点看第 1、2、8、9 这几条，先把基本习惯立住。等你开始频繁用了，再回头看第 3 到第 7 条，上下文和 review 的问题会越来越明显。等你开始在正经项目里用了，第 10 到 14 条就得拎出来反复看了，因为安全这事一旦出岔子就是大事。

每隔一阵子回来对一遍，你大概率会发现自己又不小心踩进了某个坑。没关系，踩过才知道疼，下次自然就知道绕了。

写到这，正文十二篇就全部结束了。从第 1 篇的角色转变，一路走到这份反模式清单。我陪你快速捋一遍。

第 1 篇说的是，你不是在写代码，你是在管 AI 的注意力。
第 2 篇，用 Spec 把需求说清楚，别让 AI 自由发挥。
第 3 篇，写 AGENTS.md，让 AI 一开对话就懂你的项目。
第 4 篇，接手旧项目，先让 AI 看懂再动手。
第 5 篇，上下文管理，知道什么时候该停、该换会话。
第 6 篇，MCP，给 AI 接上真实环境。
第 7 篇，Subagent，把不同工种分开。
第 8 篇，把前七篇串成一套完整流程。
第 9 篇，Git worktree，让多个 Agent 并行又互不打架。
第 10 篇，Skill，把重复的话固化成模板。
第 11 篇，CI、Hooks、测试，给代码加护栏。
第 12 篇，也就是这篇，反模式清单，定期自查。

你回头看会发现，这些不是十二个孤立的知识点，它是一整套连贯的工作方式。从怎么定义需求、到怎么管上下文、到怎么接工具、到怎么拆工种、到怎么加护栏、再到怎么避坑，每一步都有章可循。

回到这个系列最开始说的那句话，你和 AI 写代码之间，差的从来不是一句更厉害的 prompt，是一整套工作流。走到这里，我希望你手里已经有这套东西了。

它不会让你从此再也不踩坑，我自己到现在也还在踩。但它会让你每次踩坑之后，知道是哪一环出了问题，知道下次该在哪里补一道防线。这就够了。从碰运气，变成有手感，这中间的距离，就是这十二篇。

正文到此为止，但还没完全结束。

番外篇我会用一个完整的需求，从第一天到第四天，把这十二篇的所有能力真刀真枪地串成一个实战案例，让你看看一套完整的 AI Coding 工作流跑起来到底长什么样。

我们番外见。

作者声明本文无利益相关，欢迎值友理性交流，和谐讨论～