2026年一个开发者对着镜头说了句“Im done coding with AI”视频在技术社区里被反复转发。他列举的理由听起来都很成立AI生成的代码不可维护、上下文窗口不够用、改来改去反而更慢、出了问题根本不知道从哪查起。每一句都让人点头。但同一个时间窗口里搜索侧的热度一点没降GLM coding plan的7天体验卡怎么用、阿里云百炼的coding plan怎么申请、火山方舟的agent plan和coding plan有什么区别、Cursor还值不值得续费、spec coding里的spec到底是什么……一边有人宣布“我不干了”一边有大把人排队研究怎么把AI编程接进自己的项目。这不是精神分裂这是AI编程走到换挡期的正常现象。我先把结论放在这里说“Im done”的人大概率不是被AI编程本身劝退的而是被一种错误的使用方式劝退的。他们把AI当成一个“你说需求、它出代码”的自动生成器结果第一次遇到生产环境就翻车然后得出“这玩意不行”的结论。真正的问题不在AI而在于工作流没有跟着升级——你还在用旧的方式验收代码却把写代码的环节交给了AI。下面不打算替任何工具说话也不打算劝谁必须用AI编程。我想做的是把几件事讲清楚为什么这么多人走到“Im done”这一步vibe coding和spec coding这两个词到底在说什么各家coding plan、agent、credits背后是什么逻辑以及AI编程真正翻车的地方从来不是代码生成而是工程边界。1. “Im done”的真相你大概率不是被AI劝退而是被“预期差”劝退1.1 demo里有多顺畅真实项目里就有多狼狈先说一个几乎所有尝试过AI编程的人都经历过的路径。前30分钟你会觉得这玩意是神。写一个脚本、生成一个React组件、补一份单元测试AI几秒钟就能给出一版能跑的代码。你甚至会想以后再也不用手写样板代码了。然后项目开始变大从单个文件变成几个目录从一次调用变成多个接口对接从“能跑”变成“要在CI里跑、要处理异常输入、要写日志、要支持回滚”。这个时候AI生成的代码第一次开始让你头疼。它可能在一个文件里用了相对路径在另一个文件里用了绝对路径它可能给你写了一层try/catch但捕获异常之后什么都没做它可能把敏感信息直接写进了配置它可能在你没注意的地方引入了一个你完全不认识的依赖然后那个依赖的版本又和项目里另一个库冲突。更麻烦的是当这些错误叠在一起出现时AI自己也不知道问题出在哪——因为它的上下文里只有你贴过去的片段没有整个系统的运行状态。于是你开始花大量时间做三件事解释问题、验证修复、回滚重来。到某个晚上你盯着屏幕上第三版还是不对的代码心里冒出那句话算了我自己写吧。1.2 问题不是“AI没看懂需求”而是“你希望它自己看懂一切”这里很关键。大多数人用AI编程时脑子里还是“人用自然语言交代任务”的模式。可是AI不是实习生它是一个没有系统记忆、没有全局状态、没有业务背景的代码生成器。你给它一句“把这个接口改成支持分页”它能写但它不会主动去查这个接口有哪些调用方、数据库里有没有现有索引、分页参数命名和你现在的风格是否一致。这些信息不是它靠推理能补出来的而是需要你明确告诉它或者由它去读代码库才知道。所以“Im done”这个结论对一部分人来说其实是一种自我保护他们发现AI编程让代码变多了但没有让理解变少。这个判断没有错。只不过他们退出的不是一个工具而是一种用法的失败。一句话总结AI编程的拐点不在“能不能生成代码”而在“你能不能把一个模糊想法变成一份可执行、可验证的任务描述”。2. 从 vibe coding 到 spec codingAI编程正在换挡2.1 vibe coding是什么以及它为什么只适合特定阶段vibe coding 这个词这两年火得很快。它描述的是一种状态你把想法随口说出来让AI一路往下写遇到报错就把报错贴回去AI改了再跑你甚至不太关心代码具体长什么样只要最终效果符合预期就行。这种模式对原型验证、学习实验、个人小工具非常有用。它的价值在于把“从想法到可运行程序”的时间压缩到了极短。你不需要会全部语法细节不需要先设计完整架构只要能把需求和报错描述清楚就能得到一个能跑的东西。但如果你把 vibe coding 直接用到生产项目里问题会立刻暴露出来。因为 vibe coding 的核心假设是“最终结果对就行”它绕过了审查、测试、边界处理、可维护性这些工程问题。做原型可以接受一段看不懂但能跑的代码做生产项目就不行——你看不懂的代码出事了也没人救得回来。2.2 spec coding把“感觉”换成“规格”AI才真正成为干活的人于是 spec coding 出现了。它不是反对 vibe coding而是把 vibe coding 里的“感觉”部分抽出来换成一份明确的规格说明。这里的 spec 不是产品经理写的那种PRD而是一段可以直接让AI执行的、边界清晰的任务描述。它至少应该包含目标这个任务要实现什么用来解决什么问题。输入数据从哪来格式是什么有哪些必填字段哪些允许为空。输出返回什么结构成功和失败分别是什么表现。约束不能修改哪些文件不能引入哪些依赖必须遵循什么代码规范。验收标准什么情况下算完成测试用例有哪些。举一个粗糙的对比。普通prompt“给我写一个读取CSV文件并统计每列平均数的脚本。”spec式prompt“写一个Python函数 analyze_csv(file_path: str) - dict返回每列的平均数。输入是UTF-8编码的CSV第一行是列名数值列包含空值时跳过并记录该列跳过条数非数值列平均数返回None。输出格式为{column_name: {mean: float|None, skipped: int}}。不要修改原文件不要引入pandas以外的依赖错误处理用try/except并打印具体错误信息。验收标准用附带的test_data.csv运行结果与期望字典一致。”区别很明显。前者给AI留了大量自由发挥空间后者把边界、约束、输出结构、验收方式全部固定了。后者看起来更啰嗦但它的可预测性要高得多也更容易检查——因为你可以按验收标准去验证而不是看AI“跑出来了”就算赢。2.3 spec coding的spec到底是谁的spec很多人问过spec coding里的spec是什么是需求文档吗是设计文档吗不完全是。它更接近“可执行的工程契约”。你负责定义“做什么”和“怎么样算对”AI负责“怎么实现”。这份契约的价值不在于写得有多工整而在于它把验收标准前置了。AI写代码之前你们先达成了共识什么算对。这也是AI编程真正改变的地方——它改变的不是“写代码”这个动作而是“表达需求”和“定义完成”这两个环节。过去这两个环节经常被省略因为人脑会自动补齐上下文但AI不会它只会按照你给的信息行动。所以谁能把空档补上谁就能从AI编程里获益谁补不上谁就会走到“Im done”那一步。3. coding plan、agent、credits这些词背后是同一件事3.1 各家coding plan到底在卖什么相关热搜里频繁出现GLM coding plan、阿里云百炼coding plan、火山方舟agent plan和coding plan、Qwen Cloud coding plan API key。第一次看到这些词的人会困惑coding plan是指“编程计划”吗是不是平台帮我规划项目不是。这里的plan本质上是一个使用套餐或算力额度包。各平台提供AI编程相关的模型服务和Agent能力按调用量、上下文长度、工具执行次数等维度计费。购买coding plan相当于你买了一个时间段内的“算力弹药”用credits或配额来结算。你可以把credits理解成积分。AI每次对你说的话、每次读文件、每次调用工具、每次返回代码都会消耗一定数量的credits。不同操作消耗不同长上下文任务通常更贵Agent反复执行工具调用也会累积消耗。用完就得续。这个概念本身不神秘但理解它有什么实际问题有。它会直接影响你的使用方式如果你把一次性大任务丢给Agent它可能在一个任务里就烧掉大量credits因为Agent要反复读文件、跑测试、改代码。如果你把任务拆小减少无效上下文钱的效率就会高很多。如果你是新手先用体验卡或免费额度跑通一个小任务理解消耗逻辑再考虑买多少额度。3.2 agent plan和coding plan有什么不一样这两个词经常并列出现很容易混淆。从使用体验上看区别可以这么理解coding plan 更贴近“AI辅助写代码”你提问AI给答案你来选择、粘贴、修改。它像一个话很多、懂得也很多的助手但最终动作由你执行。agent plan 更贴近“AI自主执行任务”你把一个任务描述交出去Agent自己去读文件、写代码、运行测试、根据报错继续修改直到完成或达到上限。它更像一个被授权干活的人。但这里有一个非常现实的坑Agent模式看起来很省事实际上对任务描述的清晰度要求更高。你给它一个模糊任务它不是停下来问你而是自己猜猜错了继续猜最后给你一个“看起来能跑但根本不是你要的”结果。不要被Agent的“自动化”三个字骗了。你给它一份模糊任务它不是停下来问你而是自己猜猜错了继续猜。先把spec能力练好这既是质量保障也是钱袋保障。所以用Agent之前先练好上一节说的spec能力。这不是理论正确这是省钱。3.3 这些工具能做什么不能做什么现在的主流AI编程工具确实能覆盖很大一部分编码工作生成样板代码、写单元测试、补注释、做代码审查建议、解释报错、重构小范围函数、生成SQL、写脚本、搭项目骨架。配合Spring AI、PyCharm AI插件、各类代码规范插件比如Alibaba Java Coding GuidelinesAI还可以在已有代码库里做局部增强。类似的现象也出现在其他内容生产场景里技术文档、广告脚本、短视频文案AI做的都是同一件事——把人的想法快速变成可用的初稿再由人来判断和打磨。但有一个边界必须认清AI不理解你的业务价值。它不理解为什么这个接口要限流为什么这个字段不能暴露为什么这个数据库不允许全表扫描。它只能把“你告诉它的规则”变成代码。所以代码里最重要的那些决策部分——架构、安全边界、数据模型、失败策略——仍然需要人来定。如果你把AI当成“能自动处理所有事情的工程师”肯定会失望。但如果你把它当成“一个执行力不错但需要明确指令的协作者”它的价值就能落地。4. AI编程真正翻车的地方不是代码生成而是工程边界4.1 为什么单次跑通不等于能稳定使用我对所有想认真用AI编程的人只有一个建议先别急着追求“一下生成整个项目”先把“单次跑通”和“稳定使用”这两件事分开。单次跑通说明AI今天给的代码在你的环境里、用你的输入、跑出了你预期的结果。但离稳定使用还差几块关键拼图日志AI生成的代码有没有日志报错时你能不能定位到具体位置权限它有没有在代码里留下硬编码密钥或者绕过权限校验的逻辑异常处理收到异常输入、网络超时、外部服务降级时程序会怎样表现依赖锁定它引入的依赖版本是否锁定换台机器会不会装不上回滚和幂等批量任务跑了一半失败重跑会不会造成重复写入监控线上有没有人关心这段代码跑得好不好这些不是AI的锅而是“从生成代码到运行服务”之间本来就存在的工程工作。过去你手动写代码时一样要处理只不过当你手动写时你会慢慢想清楚这些边界而AI生成时它只按你的任务描述输出不会主动考虑生产环境需要什么。4.2 一套实际的排查顺序假设AI生成的代码出了问题先不要慌按这个顺序排查先看现象是报错、卡住、无输出还是输出结果不对把现象记录下来这是你回到AI面前提问的素材。再看输入文件路径对不对编码对不对字段名对不对上下文是否完整。很多“AI写错了”的问题其实是输入描述漏了关键信息。再看环境依赖版本、语言版本、操作系统差异、环境变量、网络权限。再看参数并发数、批量大小、超时时间、输出目录、是否覆盖文件。再看工具边界当前模型上下文是否够用Agent是否已经跑了太多轮导致状态混乱credits是否已经耗尽。这个顺序的关键在于它避免了你一遇到问题就把代码丢给AI“这段代码报错了帮我改。”如果你还没确认输入和环境AI改来改去也只是盲猜。真正的问题可能根本不在代码里而在你对代码运行环境的所有假设里。4.3 什么时候能放心用什么时候必须自己写我建议把“能不能让AI写”分成四档场景建议原因一次性脚本、学习实验、原型验证可以大胆用AI甚至用vibe coding错了成本低重来就行已有项目里的低风险模块用spec式任务小步提交边界清晰便于审查和回滚核心业务逻辑、支付、权限、数据一致性