最近有一段视频标题让我停下来多看了几秒Im done coding with AI。初看像是又一个“博主受够了 AI 编程”的情绪宣泄但细想之后我反而觉得这句话比那些“AI 编程神器实测”更值得讨论。因为它出现的时间点很特殊正好是 AI coding 助手、vibe coding、各类 coding plan 套餐铺天盖地的时候。一个人说要放弃不一定代表工具没用更可能是他走到了 AI 编程工作流的深水区发现单次生成惊艳、长期维护失控最后不得不喊停。我自己的判断是“Im done coding with AI”不是退场宣言而是 AI 编程进入冷静期的一次集体提醒。真正让开发者想离开的往往不是代码写得不够快而是控制权变得模糊AI 生成得越多人需要判断的地方就越多如果流程没有跟着改效率红利很快会被返工成本吃掉。这篇文章不打算劝任何人“继续用”或“别用了”我只想拆开这句话背后的真实原因并给出一套能让 AI coding 继续落地的工作流约束。1. 一句“Im done coding with AI”背后是 AI 编程进入理性期1.1 这个标题不是打翻工具而是打翻“只生成不负责”的工作方式如果只看标题会以为作者在否定 AI 编程。但你往回翻这类讨论的上下文会发现大部分人不是真想把 Cursor、Copilot 一类工具卸载。他们真正受不了的是当下常见的一种使用方式让 AI 一口气生成整套功能然后直接合入出了问题再继续丢给它修。这种方式的第一个小时很爽第二个小时开始微妙到晚上可能变成一场灾难。AI 编程工具本质上是“极高效率的初稿生成器”。它帮你把从零到一的时间压缩到极短代价是输出的可预测性很低。你把需求描述得清楚它可以给出结构完整的代码同样一段需求稍微换个模型、换一次上下文结果可能完全不同。对短期原型来说这是优势对长期维护的工程来说这是成本。所以“Im done coding with AI”真正指向的不是工具退场而是旧工作方式失效。过去我们写代码每一行都是自己敲的至少在合入前对逻辑有天然记忆现在大量代码由模型生成开发者成了 review 者和集成者。如果依然用“生成完就完事”的心态那返工只是时间问题。1.2 从惊艳到怀疑为什么大量用户走到了同一个反思节点我见过不少开发者最初接触 AI coding 时体验都带有一种“被点亮”的感觉一个复杂的 React 页面、一个数据处理脚本几句话就出来了。这种惊艳建立在两个前提上任务边界清晰接受度够宽。代码能跑、界面能看就觉得成功了。等到用 AI coding 处理真实项目时需求开始变得含混要接旧系统、要遵循团队规范、要考虑错误处理、要兼容现有数据。AI 生成的方案可能在单点功能上没问题但放在整个仓库里就会暴露出缺少上下文、缺少回归验证、修改范围过大等问题。这时开发者的体验会急转直下省下来的生成时间全都花到了审查、调试、回滚和说服自己“还能继续用”上面。这不是某个产品的缺陷而是生成式编码工具目前的共性。理解这一点你才会明白那句“Im done”不是在抱怨模型不够聪明而是在质疑现有协作流程是否可持续。1.3 先别急着站队要区分“受够了”和“想明白怎么用”面对这个议题我更建议不要走“AI 编程好或不好”的两极路线。真正有价值的讨论是它在什么场景下值得用在什么场景下必须设防以及你愿意为它补上哪些工程约束。如果只是写一次性脚本、做概念验证、快速搭 demoAI coding 带来的收益非常明显这个阶段确实可以“vibe coding”想到哪说到哪。但只要是会持续演进的代码是别人也要维护的代码是需要保证稳定性的业务代码就必须把控制权重新拿回到人手里。所以与其说“Im done coding with AI”不如说“Im 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 写的代码一次跑通”但这在工程上只是最低标准。跑通只代表这条路径没有立刻报错不代表边界情况、异常输入、权限校验、竞态条件都处理好了。所谓“正确”至少要经过三层验证测试层单元测试、集成测试是否通过。Diff 层改动范围是否符合预期有没有夹带“顺手重构”。回归层原有功能是否被破坏相关模块是否受影响。如果你每次让 AI 改完代码后都只靠“运行一次主路径”来判断那你其实是在随机测试。只有把验收固定成一条可复用命令、固定成一段手工检查清单你才敢在后续更复杂任务里放开手让它做更多事。4.4 环境边界版本、依赖和上下文是 AI 最容易产生幻觉的地方生成式模型的训练数据有时间截断它未必知道你的项目正在使用的框架最新版本有什么破坏性变更。如果你直接问“新版实现方式是什么”它可能给一个看起来很流畅、但实际已经过时的答案。所以在真实项目里不要让 AI 依赖“记忆”来决定依赖版本。你可以让它在项目目录里搜索 package.json、requirements.txt、go.mod 等文件先读取锁定版本再给出方案。如果它要安装新依赖则必须说明用途并建议你独立确认版本兼容性。环境相关的常见坑还包括你的代码跑在 Linux 上AI 默认给了 Windows 路径你有内部 eslint 规则AI 生成的代码风格完全不符合你的过程中需要使用代理访问某些服务但工具没有本地 CLI 的密钥配置。这些问题很难靠模型自己规避只能靠执行环境和 review 流程去补位。5. 一套更可控的 AI coding 协作流程从 plan 到 merge5.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 的输出变得可控。如果你只追求单次任务的速度可以跳过一些环节但如果代码要进入生产慢一点反而是节省时间。模式适合场景风险级别建议用法聊天问答学习语法、理解概念低让 AI 解释现有代码内联补全在已有函数里补代码中低给出明确输入输出或函数签名内联 agent 修改单文件重构、局部修复中先用 plan 确认改动范围再执行全仓 agent 自动执行大型重构、批量修改高配独立分支、可回滚基线、测试闸门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. 结尾Im done 不是终点是一个新起点7.1 “受够了”的真正启示没有控制权的效率会反噬回到最初那个标题。我现在再看到Im done coding with AI已经不再把它理解成“对 AI 编程绝望”而是一个信号很多人开始意识到仅靠生成速度解决不了真实开发的核心问题。这种“受够了”的感觉实际上是在提醒我们要尽快把工具能力装进一个可靠的人类决策框架里。无论你最后是继续使用 AI coding 工具还是停下来手动写几周代码都不是重点。重点是你有没有获得对流程的控制权能不能先让 AI 出方案再执行能不能用测试拦住坏代码能不能在不满意时快速回滚。如果这些能力没有建立起来那你换哪个工具、增加多少 credits都只是暂时缓解焦虑。7.2 下一步从最小可控单元重新开始如果你对 AI coding 感到疲惫我建议不要急着彻底停用而是把规模缩小。找一个边界清晰的小模块用前面说的流程重新跑一遍写清任务、先要 plan、小步执行、跑测试、手动合入。当你在这套流程里重新体验到“能控制”你才能判断自己是该继续大范围使用还是该退回辅助位置。AI coding 不会消失它只会越来越像编程基础设施的一部分。但基础设施不等于自动正确。决定一段代码能否长期健康的依然是人的判断、测试的约束和流程的回退空间。那句话的正确读法也许是我不再用没有控制的 AI 写代码。而这恰好是新一轮工作流升级的起点。