AI编程进入理性期：放下失控的vibe coding，重建控制权

最近有一段视频标题让我停下来多看了几秒：I'm done coding with AI。初看像是又一个“博主受够了 AI 编程”的情绪宣泄，但细想之后，我反而觉得这句话比那些“AI 编程神器实测”更值得讨论。因为它出现的时间点很特殊，正好是 AI coding 助手、vibe coding、各类 coding plan 套餐铺天盖地的时候。一个人说要放弃，不一定代表工具没用，更可能是他走到了 AI 编程工作流的深水区，发现单次生成惊艳、长期维护失控，最后不得不喊停。

我自己的判断是：“I'm done coding with AI”不是退场宣言，而是 AI 编程进入冷静期的一次集体提醒。真正让开发者想离开的，往往不是代码写得不够快，而是控制权变得模糊：AI 生成得越多，人需要判断的地方就越多，如果流程没有跟着改，效率红利很快会被返工成本吃掉。这篇文章不打算劝任何人“继续用”或“别用了”，我只想拆开这句话背后的真实原因，并给出一套能让 AI coding 继续落地的工作流约束。

1. 一句“I'm done coding with AI”背后，是 AI 编程进入理性期

1.1 这个标题不是打翻工具，而是打翻“只生成不负责”的工作方式

如果只看标题，会以为作者在否定 AI 编程。但你往回翻这类讨论的上下文，会发现大部分人不是真想把 Cursor、Copilot 一类工具卸载。他们真正受不了的是当下常见的一种使用方式：让 AI 一口气生成整套功能，然后直接合入，出了问题再继续丢给它修。这种方式的第一个小时很爽，第二个小时开始微妙，到晚上可能变成一场灾难。

AI 编程工具本质上是“极高效率的初稿生成器”。它帮你把从零到一的时间压缩到极短，代价是输出的可预测性很低。你把需求描述得清楚，它可以给出结构完整的代码；同样一段需求，稍微换个模型、换一次上下文，结果可能完全不同。对短期原型来说这是优势，对长期维护的工程来说这是成本。

所以“I'm done coding with AI”真正指向的，不是工具退场，而是旧工作方式失效。过去我们写代码，每一行都是自己敲的，至少在合入前对逻辑有天然记忆；现在大量代码由模型生成，开发者成了 review 者和集成者。如果依然用“生成完就完事”的心态，那返工只是时间问题。

1.2 从惊艳到怀疑：为什么大量用户走到了同一个反思节点

我见过不少开发者最初接触 AI coding 时，体验都带有一种“被点亮”的感觉：一个复杂的 React 页面、一个数据处理脚本，几句话就出来了。这种惊艳建立在两个前提上：任务边界清晰，接受度够宽。代码能跑、界面能看，就觉得成功了。

等到用 AI coding 处理真实项目时，需求开始变得含混：要接旧系统、要遵循团队规范、要考虑错误处理、要兼容现有数据。AI 生成的方案可能在单点功能上没问题，但放在整个仓库里，就会暴露出缺少上下文、缺少回归验证、修改范围过大等问题。这时开发者的体验会急转直下：省下来的生成时间，全都花到了审查、调试、回滚和说服自己“还能继续用”上面。

这不是某个产品的缺陷，而是生成式编码工具目前的共性。理解这一点，你才会明白那句“I'm done”不是在抱怨模型不够聪明，而是在质疑现有协作流程是否可持续。

1.3 先别急着站队：要区分“受够了”和“想明白怎么用”

面对这个议题，我更建议不要走“AI 编程好或不好”的两极路线。真正有价值的讨论是：它在什么场景下值得用，在什么场景下必须设防，以及你愿意为它补上哪些工程约束。

如果只是写一次性脚本、做概念验证、快速搭 demo，AI coding 带来的收益非常明显，这个阶段确实可以“vibe coding”，想到哪说到哪。但只要是会持续演进的代码，是别人也要维护的代码，是需要保证稳定性的业务代码，就必须把控制权重新拿回到人手里。

所以与其说“I'm done coding with AI”，不如说“I'm done coding without control”。没有控制效率，最终会被效率反噬。接下来的几章，就是围绕这个控制权的核心展开的。

2. AI coding 真正缺的不是代码量，而是控制权

2.1 AI 负责生成，人的工作反而从“写”变成“判断”

过去一个开发者一天写 500 行代码，每 100 行都跟着自己的思考；现在 AI 一上来生成 500 行，你面临的是 500 行陌生代码的审计压力。这导致一个反直觉结果：写代码的时间变短，但判断代码的时间变长。如果工具用得越多，你的判断能力却没有相应升级，那项目质量并不会自动提高，反而更容易失控。

这里最需要理解的一层是：AI 编程提供的是“候选答案”，不是“最终判断”。你让模型生成一段排序算法，它能写得很标准；但你让模型为某个业务模块决定应该在哪个文件里放哪个函数，它只能根据概率猜测。真实项目的代码质量，往往不是单段代码好坏，而是代码放置的位置、依赖的边界、修改的影响范围。这些是模型无法替你负责的。

所以在 AI 主导生成的工作流里，开发者最有价值的技能不再是“代码写得快”，而是“能看出方案哪里不对、边界在哪里、怎么拆解任务”。这一点决定了你是被工具拖着走，还是让工具为你服务。

2.2 单点正确的代码，未必能合入真实项目

很多人大骂 AI coding 写出的代码“跑不通”，可实际情况是：它给出的代码往往能跑，只是在你的项目里跑不通。为什么？因为你的项目有一堆没人完整写进 prompt 的隐性约束：某个目录结构约定、某种错误处理风格、某个历史遗留的兼容逻辑、某条只能在代码库里局部看到的依赖链。

AI 没有看到这些信息，它只能依照训练时见过的“通用最佳实践”来回答。你觉得它给了你一个标准答案，但这个答案没有对齐你项目的具体上下文。这也解释了为什么同一个 AI coding 工具，在 LeetCode 式任务上表现惊艳，在推动一个活跃仓库的功能分支时经常翻车。

解决方案不是给模型塞越来越多的上下文，而是控制输入输出的范围。你可以先让 AI 只负责某个文件、某个函数、某块逻辑，再手动处理它和整个项目的对接。小范围的高确定性，远好过大范围的“看起来差不多”。

2.3 当 Agent 自动改文件，谁的兜底机制没建立，谁就会先翻车

现在的 AI coding 工具已经从“补全代码”进化到“Agent 自主执行”：它读项目文件、调用命令、修改多个文件、甚至提交 commit。听起来很省心，但真正让开发者感到失控的往往就是这个阶段。

Agent 的一个特点是“路径依赖”：它一旦顺着某个错误判断开始改代码，后面会沿着这个错误继续补丁式修改。如果你没有在它执行前设置清晰的边界，它可能把无关的文件也动了一遍。最典型的例子是，你只是想改一个登录接口，它却顺手帮你重构了工具函数、改了 lock 文件，甚至安装了新依赖。

面对这种场景，单纯靠“别让它做”并不现实，因为 Agent 能力本身就是这类工具的核心卖点。更稳妥的做法是建立一层兜底：执行前打基线、限制文件读写范围、要求它先把修改计划写在 diff 里再动手。控制权的本质不是限制 AI 的能力，而是让 AI 的每一步都可回退、可解释、可审查。

3. vibe coding 的尽头，是 coding plan 还是工程约束？

3.1 vibe coding 适合“从零到一”，不适合“从一到稳定”

“vibe coding”已经成了 AI coding 圈里的高频词。它描述的是一种氛围很松弛的开发状态：你不太需要关心语法细节，只要把意图说清楚，AI 会帮你把整段代码写出来。有人把它当作未来，有人把它当作风险，我的看法是：它是一套不错的“原型方法论”，但不是一套完整的“工程方法论”。

vibe coding 最理想的场景是：你有一个明确的小目标，时间紧、容错高、不会长期维护。比如做一个展示用的网页、验证一个算法思路、跑一个数据处理脚本。这时候把节奏交给 AI，人会非常舒服。

但一旦代码要进入稳定期，要处理真实用户、要持续迭代，vibe 就不再够用。你需要的是回归测试、性能边界、异常处理、版本兼容。这些不能靠“感觉”，只能靠流程约束。可以说，vibe coding 解决的是“从想法到草稿”的问题，而 AI coding 的长期价值在于“从草稿到可交付产品”这一段，这一段恰恰不能 vibe。

3.2 plan、credits 和体验卡，把 AI 编程变成一种可计量的服务

热搜词里有一串和“coding plan”有关的内容：GLM Coding Plan 7 天体验卡、火山 agent plan 和 coding plan、Cursor 订阅里的 credits。它们共同说明一件事：AI 编程正在从工具变成一种基础设施服务，正在变成按额度、套餐、计划来消费的资源。

我理解这些 plan 的价值，它让开发者不用再担心单次调用成本，可以更放心地把任务交给 Agent。很多服务会提供体验卡，让新手先试试 coding plan 怎么用。这类设计降低了尝试门槛，也把 AI 编程推向更接近“云服务订阅”的形态。

但这里必须提醒一件事：coding plan 解决的是“能用多少次”，而不是“用得好不好”。你买了大量 credits，不代表 AI 改出来的代码会自动符合你的项目要求。它只保证你有足够的额度去试错，但试错带来的返工成本依然需要你自己承担。所以流量和额度不是项目质量的充分条件，工程约束才是。

3.3 订阅能解决额度，不能解决“上下文混乱”和“验收缺失”

我见过一些团队，买了高级 coding plan，开了 Agent 权限，结果一晚上生成大量代码，第二天 code review 到崩溃。问题不在于没有额度，而在于他们从来没有定义“什么算改完了”。AI 说完成了，但没有测试；AI 说改好了，但没有说明改动了哪些文件；AI 说兼容旧功能，但只是靠模型记忆在猜测。

这也是为什么讨论 coding plan 时必须同步讨论“验收规则”。如果你不允许一个没有跑通测试的分支合入主分支，那 AI 给多少代码都不重要；如果你要求每个改动都附带修改说明，那 Agent 的透明度就会提高。真正值得花钱买的，不只是一个套餐，而是配套的自动化验证和审查体系。

4. 如果你想继续用 AI coding，先把这几类翻车路径堵住

4.1 输入边界：prompt 太像“作文题”，得到的只能是一篇更像作文的代码

很多翻车从 prompt 就开始了。你写“帮我优化一下用户模块”，这个需求给人类开发者也很难执行。AI 会替你脑补出很多细节，然后写出一堆你并不需要的抽象封装，最后你看到代码还会觉得“内容很多，但不知道从何 review”。

更稳的控制方式是：把需求和验收写入同一个 prompt。不是只描述“做什么”，还要明确“不改什么”“怎样算完成”“只动哪些文件”。我一般会这样搭一个可操作的 prompt 骨架：

背景：现有登录接口位于 modules/auth/login.ts，使用 JWT 校验。 任务：增加一个“连续登录失败 5 次后锁定 15 分钟”的规则。 限制：只允许修改 authService.ts 和 authRepository.ts，不要改动数据库迁移。 验收： 1. 在测试环境中跑通这个用例：错误密码连续 5 次，第 6 次返回 423。 2. 增加或更新对应单元测试。 3. 运行 pnpm test:auth，确保结果全绿。

这样 AI 就不再是“写作文”，而是完成一个可检查的任务。如果你的项目里没有一个稳定的测试命令，先别急着用 Agent 改重要代码，否则你连“是否完成”都无法判断。

4.2 执行边界：不要让它带着全部权限在仓库里自由行动

AI Agent 对项目越熟悉，改动范围越大，风险也越高。第一代辅助编程工具只是在编辑器里给建议，现在的 Agent 会自己读文件、运行命令、写入代码。这种能力是一把双刃剑，尤其是当它把整个仓库都当成“可自由修改”的空间时，你根本无法人工跟踪每次变化。

比较好的做法是给它设置类似“驾驶范围”的限制：

• 默认只允许读取，不允许自动写文件。
• 需要真正修改时，先让它列出要改的文件清单，再手动允许。
• 在分支里操作，不要直接对主分支执行。
• lock 文件、配置密钥、生成目录等强制排除在可写范围之外。

这不只是为了防 AI 犯蠢，也是为了保留人的决策点。毕竟你写的是产品代码，不是单机游戏，每一步都该有被检查的机会。

4.3 验收边界：跑通不等于正确，要通过测试、diff 和回归三关

我经常看到有人说“AI 写的代码一次跑通”，但这在工程上只是最低标准。跑通只代表这条路径没有立刻报错，不代表边界情况、异常输入、权限校验、竞态条件都处理好了。所谓“正确”，至少要经过三层验证：

1. 测试层：单元测试、集成测试是否通过。
2. Diff 层：改动范围是否符合预期，有没有夹带“顺手重构”。
3. 回归层：原有功能是否被破坏，相关模块是否受影响。

如果你每次让 AI 改完代码后，都只靠“运行一次主路径”来判断，那你其实是在随机测试。只有把验收固定成一条可复用命令、固定成一段手工检查清单，你才敢在后续更复杂任务里放开手让它做更多事。

4.4 环境边界：版本、依赖和上下文，是 AI 最容易产生幻觉的地方

生成式模型的训练数据有时间截断，它未必知道你的项目正在使用的框架最新版本有什么破坏性变更。如果你直接问“新版实现方式是什么”，它可能给一个看起来很流畅、但实际已经过时的答案。

所以在真实项目里，不要让 AI 依赖“记忆”来决定依赖版本。你可以让它在项目目录里搜索 package.json、requirements.txt、go.mod 等文件，先读取锁定版本，再给出方案。如果它要安装新依赖，则必须说明用途，并建议你独立确认版本兼容性。

环境相关的常见坑还包括：你的代码跑在 Linux 上，AI 默认给了 Windows 路径；你有内部 eslint 规则，AI 生成的代码风格完全不符合；你的过程中需要使用代理访问某些服务，但工具没有本地 CLI 的密钥配置。这些问题很难靠模型自己规避，只能靠执行环境和 review 流程去补位。

5. 一套更可控的 AI coding 协作流程：从 plan 到 merge

5.1 第一步：把需求写成可验收的任务，而不是一句“帮我写一个功能”

这里的核心原则是：先定义结果，再开放过程。你希望 AI 做什么，不只它自己知道，最好你和它都能看到一套判断标准。你可以用一句话概括任务目标，再拆成几个小点：输入是什么、输出是什么、约束是什么、如何验证。

一个比较稳的任务描述模板是：

任务：对用户的上传文件增加大小校验。 输入：multipart 上传请求。 输出：超过 10MB 时返回 413，并记录一条 warning 日志。 约束：不改变文件存储路径，不引入新的存储 SDK。 验证：curl 模拟超过 10MB 文件上传，观察返回状态和日志。

当你写出这个模板时，可能已经提前发现了不少坑，比如“413 是否符合团队对错误的约定”。这个过程本身就是 AI coding 协作里最值钱的一部分，因为它逼着人先想清楚再让 AI 干活。

5.2 第二步：先让它给你 plan，而不是直接产出代码

不少人用 AI coding 的习惯是：问题一出现，立刻让 AI 给解决方案。效率很高，但如果方案方向错了，后面所有代码都是浪费。更稳的一步是，先让 AI 输出修改计划，包括它准备改哪些文件、大致怎么改、风险和影响范围。

你可以这样要求它：

先不要直接写代码。请先阅读 modules/auth 下的相关文件，输出一份修改计划： 1. 涉及文件清单。 2. 每个文件改动要点。 3. 需要新增或修改的测试用例。 4. 你可能遇到的风险点。 等计划确认后，再开始执行。

这一步看起来多了一次交互，但对复杂任务来说价值巨大。它把 AI 从“盲目执行者”变成了“先表态的协作方”，让人的判断提前介入。

5.3 第三步：小步执行，保留基线，让 AI 自己给出验证路径

真正写代码时，不建议让 AI 一次性改完五个文件再交给你。每改完一个小目标，就停下来验证一次。尤其是在 Agent 模式下，你可以在每一步设置一个 checkpoint：先提交当前基线，再让 AI 执行下一步，如果出问题，能快速回滚。

也可以要求 AI 在提交代码时附带它自己的验证路径。比如它改了一个函数，告诉你“我准备用这个测试用例验证”，或者“请运行 yarn test login --watch”。如果它自己都说不清怎么验证，那说明它对这个改动没有把握。这可以帮你提前发现“其实只是照葫芦画瓢”的输出。

5.4 第四步：review 收口，人工合入

不管 AI coding 工具多强，我都建议把分支合入的权限保留给人，并且让代码审查变成一个显式环节。可以这样安排：

• AI 在功能分支上工作，不开直达主分支的权限。
• 生成代码后，先在本地查看git diff --stat，理解文件改动范围。
• 跑完测试和 lint，看是否通过。
• 人工或使用 review 工具检查关键逻辑，尤其要关注错误处理和边界情况。
• 全部通过后，由开发者手动合入并删除分支。

这套流程看起来比“一句话生成代码”慢，但它能让 AI coding 的输出变得可控。如果你只追求单次任务的速度，可以跳过一些环节；但如果代码要进入生产，慢一点反而是节省时间。

5.5 不同工具的“模式选择”不是玄学，是责任边界

同一款工具里的 chat、inline edit、agent plan 和 coding plan，往往让人困惑。其实可以用责任边界来理解：chat 模式适合讨论问题和理解方案，它不负责真正改动代码；inline edit 适合局部修改，改错了能快速撤回；agent plan 模式适合先出方案再执行，是复杂任务的安全入口；coding plan 或 credits 更多是资源配额，可以理解为“运输里程”，不代表 AI 一定能带你到终点。

不同工具的名字会变，但工作流原则是一致的：从纯问答到自动执行，人的控制力度逐级递减，所以每一步要配上对应的风险保护。如果你是一个新手，想体验 coding plan 的 7 天体验卡，完全可以从小项目开始，但记得先看官方文档，确认额度类型、生效时间和使用入口，别把“体验卡”和“生产环境可用方案”等同起来。

6. 如果你真的想从 AI coding 里拿到长期价值，记住这三个前提

6.1 AI 是初稿提供者，你是需求解释者和结果裁决者

说得更直白一点：AI coding 不是要把开发者替代掉，而是把开发者从“照着需求敲代码”的位置，推向“把需求转化为可验证约束”的位置。那些能把问题拆得很清楚的人，能反复给出上下文的人，能让 AI 在安全范围里试错的人，才是 AI coding 的受益者。

反过来，如果你只是把问题丢给它，等结果不好再骂工具不行，那你很难从任何编码工具里得到长期价值。没有人类的判断，AI 生成的代码只是概率文本。让它变成一个稳定的协作者，前提是你自己先知道哪些约束不能让步。

6.2 测试和可观测性，比模型版本更重要

模型能力当然是变量，新版本往往带来更好的理解力。但从项目长期稳定性看，测试比模型版本更值得投入。模型可以升级，你的业务规则不会变；Agent 可以更快，但你的代码库复杂度不会减少。有了一套能快速验证基本行为的测试，你才敢在换了新模型、新工具之后继续维持原有质量。

可观测性同理。AI agent 改了什么、为什么改，需要能被记录和追踪。如果一个工具只能给你“完成”的结果，不能给你“如何完成”的日志，那它更适合用来做单次产出，而不是承担项目里的关键维护任务。

6.3 给团队立规矩：用什么范围、不做什么、失败如何回滚

AI coding 不应该只是个人偏好，它正在变成团队级的协作变量。如果团队里有人用 Agent 自动改 20 个文件，其他人不知道，那 code review 会变成一场灾难。比较好的做法是定一套团队内可接受的使用边界：

• 哪些分支允许 AI agent 自动提交，哪些分支必须人工 review。
• 哪些目录/锁文件默认禁止 AI 修改。
• 允许使用的工具和禁止临时安装的依赖名单。
• AI 提交的代码必须附带验证信息。
• 失败后如何回滚，是否有统一的基线策略。

这不需要写成多长的制度，哪怕是几条 checklist，也能减少很多混乱。AI coding 提高的是单兵效率，如果团队协同没有相应升级，效率会在边界摩擦中被消耗掉。

7. 结尾：I'm done 不是终点，是一个新起点

7.1 “受够了”的真正启示：没有控制权的效率会反噬

回到最初那个标题。我现在再看到I'm done coding with AI，已经不再把它理解成“对 AI 编程绝望”，而是一个信号：很多人开始意识到，仅靠生成速度解决不了真实开发的核心问题。这种“受够了”的感觉，实际上是在提醒我们，要尽快把工具能力装进一个可靠的人类决策框架里。

无论你最后是继续使用 AI coding 工具，还是停下来手动写几周代码，都不是重点。重点是你有没有获得对流程的控制权：能不能先让 AI 出方案再执行，能不能用测试拦住坏代码，能不能在不满意时快速回滚。如果这些能力没有建立起来，那你换哪个工具、增加多少 credits，都只是暂时缓解焦虑。

7.2 下一步：从最小可控单元重新开始

如果你对 AI coding 感到疲惫，我建议不要急着彻底停用，而是把规模缩小。找一个边界清晰的小模块，用前面说的流程重新跑一遍：写清任务、先要 plan、小步执行、跑测试、手动合入。当你在这套流程里重新体验到“能控制”，你才能判断自己是该继续大范围使用，还是该退回辅助位置。

AI coding 不会消失，它只会越来越像编程基础设施的一部分。但基础设施不等于自动正确。决定一段代码能否长期健康的，依然是人的判断、测试的约束和流程的回退空间。那句话的正确读法也许是：我不再用没有控制的 AI 写代码。而这，恰好是新一轮工作流升级的起点。