尧图网页设计 
不开玩笑最近有个视频标题一直在圈子里转“Im done coding with AI”。看到这个标题的时候我第一反应不是“又一个唱衰 AI 编程的”而是觉得这条争论终于被摆到台面上了AI 编程到底行不行大家为什么一边说解放生产力一边又有不少人说不想继续这样写代码了。先给结论这条视频讨论的核心不是“AI 能不能写代码”而是“AI 写的代码到底应不应该直接进入你的项目”。如果只把它当成更快的自动补全或者当成一个不用动脑的代码生成器那后面一定会遇到一串麻烦。今天这篇文章我不打算复述视频内容而是站在一个普通开发者的角度把 AI coding 这件事从能玩到能用的关键问题拆开讲一遍。想搞清楚这话题下面这几个问题才是关键AI 写代码的真实边界在哪里。从“生成一段代码”到“进入生产环境”中间到底隔了多少坑。为什么同样用 AI有人效率翻倍有人觉得反而不如自己写。2026 年这个时间点上AI coding agent、vibe coding、coding plan 这些词背后什么才是可落地的经验。这篇文章写的是我自己的实测过程和判断标准。如果你正处于“AI 写得很快但是我不敢用”的阶段可以重点看后面的排查思路和验收方法。如果你已经在用但批量任务经常跑飞后半部分对你更有用。1. 先搞清楚是“不想用 AI 写代码”还是“不想用 AI 写的代码”1.1 AI coding 的核心冲突从来不是速度先说点实在的。现在主流 AI 编程工具比如 Cursor、GitHub Copilot、通义灵码、Codex 这些在生成代码的速度上已经远远超过人类。你给一个清晰需求它几十秒就能给你一段能跑的代码。这个体验在 2023 年的时候就已经很成熟了不是 2026 年才有的事。那为什么现在反而有人站出来说“Im done coding with AI”我的理解是速度上来之后问题转移了。原来你自己写代码速度慢但你清楚每一行是干什么用的。现在 AI 生成代码速度飞快但你要做的事从“写”变成了“审”和“修”。如果你没有建立一套审核和验证机制AI 写得越快你埋下的坑就越多。我见过不少新手最喜欢做的是把需求描述得特别详细然后让 AI 直接生成一个完整模块。AI 给了看起来都对一运行就各种报错。更麻烦的是AI 自己会把报错信息拿回去修修完第二轮结果引入了新的问题。这不是工具的错。工具好不好用取决于你怎么用它。1.2 vibe coding 背后的问题爽感不等于可用性热词里有个“vibe coding”指的大概是一种跟着感觉走、靠 AI 反复反馈来写代码的方式。这个词在一些学习资源里被包装成 0 基础也能编程的入口。但作为一个在真实项目里踩过坑的人我必须给你泼一点冷水。低门槛不代表低风险。用 vibe coding 方式写一段个人脚本或者做一个小工具确实可以因为出错了没什么后果。但它不适合直接搬到生产环境。原因很简单生产环境中最重要的不是“代码能跑”而是“代码在边界情况下也不出问题”。AI 生成代码最擅长的是常规逻辑最不擅长的是你没在提示词里说清楚的异常情况。举个例子。你让 AI 写一个文件批量重命名脚本常规路径它写得很好。但它大概率不会主动考虑这些问题文件名包含特殊字符怎么办目标目录里已经有同名文件怎么办运行到一半断电已经改名的文件怎么恢复磁盘空间不足时怎么处理权限被拒绝时是跳过还是中断这些不是写代码不会写而是问题根本没有被纳入需求描述。AI 不知道你也没问结果就是前半段顺利后半段事故。1.3 判断要不要用 AI coding先回答三个问题很多人看到别人说好就开用看到别人说坑就放弃。我个人觉得先别急着站队先回答下面三个问题你写的代码是会跑一次就扔还是要长期维护如果 AI 生成了错误代码你能多快发现你对这个项目的理解深度是否足以判断 AI 的输出是否合理这三个问题比“AI 编程好不好”更重要。如果项目是一次性脚本你懂需求AI 生成完你快速验证一下就能用那就可以大胆用。如果是核心业务模块你又不清楚业务逻辑AI 说什么你就信什么那我劝你还是先别偷懒。2. AI coding 正确启动顺序先跑最小样例再做批量任务2.1 环境的准备比选哪个工具更重要现在平台上有非常多可选的 AI coding 工具有人用 Cursor有人用 Codex有人用各类 coding plan 或 coding agent。热搜里也出现了很多相关词汇比如“glm coding 7天体验卡”“pi coding agent”“火山agent plan和coding plan”。这些具体产品我不多做评价因为更新速度太快今天推荐的下个月可能就换了。但我可以告诉你一个不变的判断思路选工具之前先把运行环境准备好。这里的“环境”不只是指代码运行环境还包括你的项目代码有没有放在版本管理里有没有独立的测试环境你平时写代码是靠编译报错发现问题的还是靠运行时测试AI 工具可能需要网络请求、安装依赖、创建文件你的系统权限允许吗如果 AI 生成的代码需要安装第三方库这些库的版本和你的环境兼容吗这些前置条件没有处理好AI 工具能发挥的空间就很有限。你可能会遇到现象AI 生成代码报了错你把它重新贴给 AI 修AI 给的方案也是在它自己虚拟环境里猜的不代表你的机器上就能跑。2.2 从单条任务开始不要直接开全量不管用哪种 AI coding 方案我都建议你把第一次测试拆成三个步骤。第一步启动一个极小的任务。比如读取一个文件解析里面的 JSON输出结果。这个任务的目的不是有意义而是验证 AI 工具从理解需求到生成代码再到运行成功的完整链路是否通畅。第二步选一个你以前写过的、逻辑比较简单但不是搜索一下就能找到现成代码的任务。让它写一版然后你自己再写一版或者用你原来的版本对比一下。这一步看的是AI 生成的结果是否可维护变量命名、函数拆分、注释习惯是不是你需要的样子。第三步安全地把 AI 接入你的工作流。比如让 AI 帮你生成单元测试、生成接口文档、补充类型定义。这些任务本身对正确性要求没那么高即使错了影响也不大很适合作为 AI coding 的入口。批量任务一定要放在单任务跑稳之后。这个顺序不是保守而是为了省钱省时间。你想想看如果单条任务生成的代码是有问题的你丢 100 条进去就是 100 份错误代码还得自己清理。2.3 量化和验证 AI 辅助代码的质量很多人说 AI 生成代码“质量差”但问到底哪里差又说不出个所以然。为了让判断更客观我一般会从下面几个维度来看可读性变量名是不是有明确含义函数长度是否合理有没有不必要的大段注释。完整度有没有把异常处理、空值判断、资源释放这些基础细节补上。一致性代码风格是否和现有项目一致有没有引入完全不同的命名规范。可测试性生成模块能不能单独运行能不能方便地打日志、看中间值。依赖风险有没有引入不必要的第三方库这些库是不是维护活跃的。如果一个 AI 生成的模块五条里能有四条达到你自己审核标准那它在这个任务上就是可用的。如果连一半都达不到先别升级工具先把任务拆得更细或者把提示词里的需求边界写得更清楚。3. 从“AI 会写代码”到“AI 真的帮你省事”中间隔着几个关键步骤3.1 语义理解和需求拆解不是复制粘贴就能解决AI coding 最容易被误解的一点是你只要给一句完整的自然语言它就能知道你想要什么。说实话大模型在语义理解上已经很强了但它对“你真正想要什么”的理解依赖的是你把上下文描述得多完整。比如你说“写一个 Python 脚本把某目录下的图片压缩一下”。AI 第一版大概会生成一个基于 PIL 的脚本遍历目录压缩图片。但真正落地时你可能要面对的问题包括是压缩到指定宽度还是指定文件大小输出目录和原目录重复时怎么处理保留 EXIF 信息吗输出文件命名怎么处理遇到非图片文件怎么办如果这些都要靠你来回追问 AI 才能确认那你省下的写代码时间全都花在和 AI 对话上了。所以我在实际工作中不会直接要求 AI“生成一个完整模块”而是先让它列出它对这个任务的理解和假设。比如我会让它先输出请先不要写代码。以下是需求描述请先列出你理解的需求、假设、以及需要我确认的问题然后再给出实现方案。这样做的原因很简单先对齐边界再让 AI 生成代码成功率会高很多。如果上来就让它写代码写得再漂亮也可能不是你要的东西。3.2 代码评审你的“验收标准”是什么AI coding 不只是写代码还涉及到怎么验收代码。传统开发流程里你写完代码会做代码审查检查逻辑、风格、边界情况。这个过程对 AI 生成代码同样适用。我见过一个常见错误让 AI 补全一个函数它返回的结果看起来正常长度也对但内部实现里用了一个不合适的全局变量或者依赖了一个已经废弃的 API。代码不会在编译期报错但运行时就会出现很隐蔽的 bug。因此我建议你给 AI coding 设定一套比较明确的验收标准。比如生成代码后先做静态检查。然后跑单元测试。再准备一个最小复现数据做真实验证。最后人工阅读核心逻辑。不要觉得这太繁琐。真正的 AI coding 使用场景不应该是“生成完直接放进主分支”而是“把 AI 当作一个生产力极高的初级开发者它提交一个 PR你是 reviewer你需要 review 后再合入”。3.3 生产代码里的边界AI 可以帮你写但不能完全替你想边界问题是 AI 写代码和人类写代码差异最大的地方。人类开发者因为做过类似业务知道某些数据字段可能为空知道某个接口在超时的时候应该怎么处理知道不能把用户输入直接拼进 SQL。AI 如果看不到这些上下文只能靠默认假设生成常规做法。这就是为什么有些代码看起来没问题但一到生产环境就崩。我给大家一个比较稳妥的思路把 AI 当作“代码生成模块”把你自己当作“业务语义负责人”。AI 负责把你的描述转成代码你负责保证描述本身覆盖了关键边界。举个例子。如果我要写一个外部 API 调用客户端我会在提示词里强制要求它处理以下内容请求超时时间。非 200 状态码的处理方式。API 返回字段缺失时的默认值。日志记录。要不要重试重试间隔是多少。如果你没有明确写出来AI 大概率只生成最简单的请求代码甚至不处理异常。到时候不是 AI 不聪明是你给它的需求就只有那个深度。4. 换个角度不用 AI 写代码不等于不用 AI 辅助开发4.1 “不再用 AI 写代码”的真实含义可能是“不再盲从 AI 的输出”回到视频标题那句“Im done coding with AI”。我觉得想表达的不是“AI 编程这个方向失败了”而是作者可能经历了某些项目事故决定不再让 AI 直接主导代码生成或者放弃低质量的某类 agent 工作流。这种表达在网络传播里很容易被放大成“AI 编程不行”。但实际工作中还有更大一块 AI 辅助开发价值被很多人忽略用 AI 读代码解释一段手写逻辑。用 AI 做代码 review找出遗漏的边界条件。用 AI 生成测试用例。用 AI 写 commit message。用 AI 分析报错日志。用 AI 把一段复杂代码翻译成更通俗的注释。这些并不是“直接生成业务代码”但它们在真实开发中同样能节省大量时间。而且这些任务的容错度高得多就算 AI 理解有偏差你也不会把坏代码合入主分支。4.2 Coding plan、AI agent 和账号机制背后的使用建议2026 年很多 AI 平台都在推“coder plan”或“agent plan”。热词里能看到“glm coding 7天体验卡怎么用”“火山agent plan和coding plan”“credits在ai里指什么”“coding plan是什么”这类热门问题。说明大家已经过了“AI 能不能写代码”的新鲜期开始关心怎么用、额度怎么算、哪种套餐适合自己。我给几个实用建议。首先不要把 coding plan 理解为无限好用。这类计划通常会给你一定数量的“credits”或者“快速请求次数”用完之后排队或降速。开始一个批量项目之前先算好你的任务量大概会消耗多少 credits别等任务跑到一半额度用完反而影响节奏。其次agent 类和单轮 chat 类要区分开。单轮 chat 适合问问题、生成片段。agent 类更适合处理多文件修改、跨函数重构、自动调试这类复杂任务。但是 agent 的自主性越高越需要你提前设定好“允许修改范围”。有的 agent 会自作主张去修改配置文件、增加依赖包如果你没有拦住后面可能就会出现一堆无意义的变更。最后拿到体验卡、免费额度这些资源之前先确认你准备测试什么。我之前见过有人拿完 7 天体验卡不知道怎么用随便写了几个 prompt效果一般然后得出“AI coding 不好用”的结论。这个结论其实只说明他没有提前设计测试任务。4.3 适合尝试 AI 辅助代码的场景根据我自己的经验以下这些场景非常适合 AI 辅助开发值得深入探索按已有代码风格补全模块。根据注释生成对应函数初版。将复杂逻辑翻译成更易读的浅层实现。为老代码写单元测试。自动分析测试失败日志并给出修复建议。数据清洗和格式转换脚本。代码迁移例如把旧接口调用改成新 SDK。生成数据库建表语句和索引建议。根据 OpenAPI 文档生成客户端调用代码。复杂正则表达式解释和调整。这些场景有一个共同点核心语义是明确的AI 只要按照输入输出关系生成代码即可。它不是帮你拍板业务方向而是帮你把明确的事情写得更快。5. 如果你仍然决定写“自己的代码”也躲不开工具链的变化5.1 手工编码和 AI 辅助并不对立很多人理解“coding with AI”是一个非此即彼的选择。要么全用 AI 写要么回到手敲。但实际上绝大多数成熟开发者采用的早就已经是混合模式。手写核心逻辑AI 处理样板代码。你自己掌握架构和数据流AI 帮你在局部实现填充。你对 API 设计负责AI 帮你做 API 的 params 校验代码。这种方案既能控制风险又能享受效率提升。真正要警惕的是完全依赖 AI 生成代码而失去理解能力。当你懒得读 AI 生成的每一行懒得跟踪改动懒得出问题后去查根因那你就已经从“用工具”变成了“被工具带动”。这种状态确实容易让人说出“Im done coding with AI”。5.2 什么样的开发者不需要 AI codingAI coding 不是万能的所以也确实存在不太需要它的开发者类型。如果日常工作已经高度标准化项目模板、代码生成工具、内部脚手架都很完善新功能的开发节奏是“复制前一个项目然后改改”那 AI coding 带来的边际收益确实不高。如果工作内容以算法研究、底层内核、硬件驱动为主需要高度精确的硬件状态和系统调用理解AI 生成的代码可能帮你写出来但你需要大量时间验证它的正确性反而不如自己写。这种情况下AI 更适合用来辅助阅读文档、解释样例代码。还有一种情况工作环境中代码仓库严格隔离不允许把代码外发到第三方 AI 平台那这类工具从合规上就不可用。需要找企业私有化部署方案或者选择完全离线的代码模型。这是部署问题不是能力问题。5.3 AI coding 后的开发者核心能力是什么如果只让我说一条我会说读代码和改代码的能力比写代码的能力更重要。以前代码大多数是自己一个字符一个字符敲出来的写的过程本身就是理解过程。现在AI 帮你敲你接收到的是一段成品。这时候你如果没有能力快速看懂它没有能力发现隐藏 bug没有能力在需要修改时不破坏其它逻辑那么 AI 就不是你的助手而是你的风险源。我建议每个想长期吃开发这碗饭的人在日常工作中刻意训练“代码审查”能力。看到 AI 生成代码先别急着运行试着做这几件事读一遍看看主流程是否能理解。找异常处理看它有没有预防输入错误。检查资源释放连接、文件句柄有没有关闭。思考并发场景如果多个用户同时调用会怎样。查依赖有没有引入没必要的包。这个习惯不仅能帮你更安全地用 AI coding也能让你和不用 AI 的开发者形成真正的差异化优势。6. 深入实战我用 AI coding 的一次完整落地过程6.1 目标设定和拆解为了让你知道上面的方法怎么用我拿一个实际场景拆解一遍。这里不涉及具体业务代码但完整过程可以参考。假设需求是开发一个小型爬虫系统从某公开网站抓取公开文章信息保存到数据库并支持增量更新。考虑到合规性先说明一点实际开发中爬虫一定要确认网站协议和内容授权我这边的例子只做技术演示。我会拆成六个子任务用 AI 生成抓取列表页的代码。用 AI 生成详情页字段解析代码。用 AI 生成数据库表结构。用 AI 生成数据入库和去重逻辑。用 AI 生成定时任务入口。用 AI 生成日志和异常告警。这个顺序有一个好处每一步都可以独立验证前一步跑通了再进入下一步。如果让 AI 一次性生成整个项目中途任何一个依赖出问题你都很难定位到具体是哪一段代码的问题。6.2 让 AI 先生成接口定义再生成实现真正开始前我先让 AI 输出这个模块的接口设计而不是代码实现。比如我会这样写提示词我需要开发一个定时抓取公开网页标题和正文摘要并保存到 SQLite 的小模块。 请先给出这个模块的函数接口设计包含函数名、入参、返回值和职责说明不要写具体实现。为什么要这一步因为 AI 直接写实现往往会按照它自己的数据库设计、函数命名、异常类型来生成整体可用但和你后续期望的调用方式可能相差很大。先确定接口等于把 API 边界固定下来了后面如果觉得实现不理想你可以单独重写而不会影响到调用方。AI 给出的接口还是值得参考的。接着你只需要审查设计调整你需要的地方然后再让它按接口逐个实现。这种做法比一次性让它生成“整个项目”稳定得多。6.3 运行后的验证和调试子任务跑完以后不要只看“程序没有报错”就当作成功。真正的验证要做三件事。第一件用一条真实数据验证抓取结果。可以和手抓的结果对比看看字段映射是否正确。第二件用一个异常数据验证容错能力。比如一条没有摘要的文章一条超长的标题一条重复数据看看系统是否会崩溃。第三件观察日志。如果没有日志说明你以后出问题只能瞎猜。建议每个子任务都加入可视化的日志输出。实测中我经常遇到一个场景AI 生成的代码顺序是“先抓取然后解析然后入库”。如果抓取失败它会抛异常后面两步直接不执行。这看起问题不大但如果你要定时任务连续处理 1000 个 URL其中一个 URL 超时就会让整个任务中断。这时你需要在代码里让单个 URL 的失败不影响后续任务。这就是一个很典型的边界条件需要通过人工经验补进去。所以当出现不稳定时你不要第一时间怀疑“AI 能力不行”而是检查这些关键点失败是否会导致整体中断是否有超时限制是否有重复数据唯一索引特殊字符是否会引起解析错误文件、数据库、网络连接有没有正规关闭错误日志够不够你判断是哪一步出错把这些问题处理干净AI 生成代码的可用率会翻倍。6.4 这套流程所花费的时间一位完全手写的开发者这个模块大概要 3 到 4 个小时包括数据库设计和异常处理。用 AI 生成基础代码大概 30 分钟但剩下的审查、验证、补边界大概需要 1 到 2 小时。总时长可能缩短到一半左右。如果你平时本来就会写代码并且对自己写的逻辑有足够信心AI coding 的核心价值不是让你节省写代码的那部分时间而是节省你去搜索 API 文档、写模板代码、理清语法细节的时间。写业务逻辑这件事基本功越好AI 用起来越顺手。7. 常见误区和报错排查清单7.1 AI coding 常见的六个误区我整理了几个常见误区新手尤其容易踩误区一让 AI 生成完代码不看就直接运行。结果报错了还在问“为什么 AI 写的代码运行不了”。运行代码本来就是你要负责的环节。误区二认为 AI 上下文越长越好。上下文长度是有限的如果你的项目很庞大AI 很容易遗忘最早的那些约束。比较稳妥的方式是单独让 AI 处理某个文件或某个模块不要把整个工程一次性丢进去。误区三AI 生成代码后不能一次通过测试就换工具。工具选择确实重要但更多问题出在提示词不够准确和需求拆解不够细。误区四忽视项目自身的构建方式。比如项目用的是 pnpmAI 可能在文档假设下使用了 npm结果生成了 package-lock.json破坏了团队统一依赖管理这同样是一种“错误代码”。误区五直接让 AI 修改生产主分支代码。AI agent 有权限操作文件之后危险性会上升。最好的方式是让 agent 开分支或者提供 diff你人工确认后再合并。误区六所有代码都想让 AI 写。AI 生成时需要编译时间较长的小模块时性价比不高。自己几秒钟能写完的代码没有必要让它生成因为等它返回加上你校验的时间足够手敲了。7.2 当 AI coding 没有按预期工作时按什么顺序排查我自己的排查顺序一般是这样的先看 AI 返回的内容和你询问的问题是否一致。不一致先补提示词。看代码是否能单模块运行。不能检查它依赖的环境和函数是否存在。看运行时报错的位置。如果报错在 AI 生成的代码内部先把完整的报错信息重新喂给它。如果修复后引发新的报错需要判断是不是 AI 在修一个问题的同时引入了另一个问题。此时不要反复让 AI 自己猜而是自己阅读相关代码修改得更稳妥。如果 AI 生成的代码看起来没有任何问题但仍运行失败检查你的环境包括 Python 版本、Node 版本、依赖包版本、系统架构。注意不要一看到错误就让 AI 重复生成。错误日志、期望行为、运行环境、最近改动这四类信息一次描述完整比来回追问十轮更高效。7.3 代码生成后的 review 清单最后给你一份我每次合入 AI 生成代码前会过一遍的 review 清单。可以把它保存下来当成自己的模板有完整的入参校验吗有没有在没有数据时返回错误提示而不是崩溃外部依赖是否必要版本锁定没有文件路径是否使用相对路径或配置文件而不是写死关键操作是否有日志记录是否处理了运行时中断有没有把不应该提交的本地参数硬编码进去是否遵循了项目现有的代码风格递归或循环有没有防止死循环的机制敏感信息是否已经从代码里移除例如密码、密钥、token8. 往后怎么走AI coding 真正的下一步8.1 从“让 AI 写代码”到“让 AI 做工程决策辅助”现在很多 AI coding agent 已经开始不只是生成代码而是能根据报错信息自己改代码再运行测试直到通过。这看起来离“自动化编程”很近了。但我的判断是这些工具对开发者要求不但没有降低反而更高了。你如果不是很清楚“测试通过”和“逻辑正确”之间的差异agent 会给你一种虚假的安全感。测试通过只能说明某个路径上没问题却不能完全说明所有用户场景下没问题。开发者如果没能力补全测试覆盖没有能力理解 agent 为何这样修改那 agent 的自主性越强你越难控制结果。我希望 2026 年以后 AI coding 的发展方向不是把程序员变成“只负责描述需求的人”而是把程序员从重复劳动里解放出来让他们有更多时间思考数据模型、边界情况、代码架构和用户体验。8.2 适合个人开发者和小团队的落地建议如果你是个人开发者或者小团队没有专门平台工程团队我建议你在引入 AI coding 时走下面这条相对稳妥的路径重点先从“辅助任务”开始使用。包括测试用例生成、注释、代码解释、日志分析、脚本编写。然后再上升到“有代码库上下文的重构任务”。这一阶段AI 需要能读取你的工程文件并做局部修改。你可以小步尝试注意每次改动后对比现有测试。最后才是探索“放权模式”。也就是让 agent 有更高的权限自己去改代码、运行命令、修复问题。这个模式必须建立在你有完善的 Git 版本管理、自动测试和可回滚机制的基础上。没有这些不要随便放开权限。这里提到 Git 回滚是建议你在让 agent 大幅修改代码前先建立一个明确的提交点。实际使用时会遇到 agent 修改了你不希望它碰的文件的情况。如果你的改动已经分散在多个文件里回滚的难度会变大。有干净的版本点你随时可以推倒重来不会浪费时间。8.3 最后的一点个人看法我属于那种“工具一出来就马上试用”的人。AI coding 从早期只能补齐函数到后来能改多文件再到可以当 agent 自动调试这个过程我自己也是跟着踩坑走过来的。遇到过 AI 把项目配置文件改乱的时候也遇到过 AI 连续改同一段代码三次才修好的情况。它确实不完美但不代表这个方向不可用。视频标题是“Im done coding with AI”但我更愿意做另一个判断AI coding 不会消失消失的是那些把 AI 输出直接当成可用代码的做法。未来几个季度这类工具的门槛会进一步降低coding plan 会成为标配真正拉开差距的仍然是开发者判断代码能不能用、边界在哪里、风险在哪层的能力。如果你看完这篇文章最终选择在某些项目里少用甚至不用 AI 写代码我觉得也是理性的。不过最好不要因为一次失败就放弃它。换个思路从代码审查角度开始用 AI从写单元测试开始用 AI从写一次性脚本来用 AI你会发现它依旧能给你节省不少时间。我更建议把这次讨论当成一次提醒AI 时代的手艺已经从“字符级编码手艺”变成了“系统级控制能力”。你能让代码按你预期的方式运行你能预见边界你能保证项目在别人接手时依然可维护这些能力比是否使用 AI coding 更值得长期投入。 AI写代码到底能不能用？从能玩到能用的关键问题拆解
不开玩笑最近有个视频标题一直在圈子里转“Im done coding with AI”。看到这个标题的时候我第一反应不是“又一个唱衰 AI 编程的”而是觉得这条争论终于被摆到台面上了AI 编程到底行不行大家为什么一边说解放生产力一边又有不少人说不想继续这样写代码了。先给结论这条视频讨论的核心不是“AI 能不能写代码”而是“AI 写的代码到底应不应该直接进入你的项目”。如果只把它当成更快的自动补全或者当成一个不用动脑的代码生成器那后面一定会遇到一串麻烦。今天这篇文章我不打算复述视频内容而是站在一个普通开发者的角度把 AI coding 这件事从能玩到能用的关键问题拆开讲一遍。想搞清楚这话题下面这几个问题才是关键AI 写代码的真实边界在哪里。从“生成一段代码”到“进入生产环境”中间到底隔了多少坑。为什么同样用 AI有人效率翻倍有人觉得反而不如自己写。2026 年这个时间点上AI coding agent、vibe coding、coding plan 这些词背后什么才是可落地的经验。这篇文章写的是我自己的实测过程和判断标准。如果你正处于“AI 写得很快但是我不敢用”的阶段可以重点看后面的排查思路和验收方法。如果你已经在用但批量任务经常跑飞后半部分对你更有用。1. 先搞清楚是“不想用 AI 写代码”还是“不想用 AI 写的代码”1.1 AI coding 的核心冲突从来不是速度先说点实在的。现在主流 AI 编程工具比如 Cursor、GitHub Copilot、通义灵码、Codex 这些在生成代码的速度上已经远远超过人类。你给一个清晰需求它几十秒就能给你一段能跑的代码。这个体验在 2023 年的时候就已经很成熟了不是 2026 年才有的事。那为什么现在反而有人站出来说“Im done coding with AI”我的理解是速度上来之后问题转移了。原来你自己写代码速度慢但你清楚每一行是干什么用的。现在 AI 生成代码速度飞快但你要做的事从“写”变成了“审”和“修”。如果你没有建立一套审核和验证机制AI 写得越快你埋下的坑就越多。我见过不少新手最喜欢做的是把需求描述得特别详细然后让 AI 直接生成一个完整模块。AI 给了看起来都对一运行就各种报错。更麻烦的是AI 自己会把报错信息拿回去修修完第二轮结果引入了新的问题。这不是工具的错。工具好不好用取决于你怎么用它。1.2 vibe coding 背后的问题爽感不等于可用性热词里有个“vibe coding”指的大概是一种跟着感觉走、靠 AI 反复反馈来写代码的方式。这个词在一些学习资源里被包装成 0 基础也能编程的入口。但作为一个在真实项目里踩过坑的人我必须给你泼一点冷水。低门槛不代表低风险。用 vibe coding 方式写一段个人脚本或者做一个小工具确实可以因为出错了没什么后果。但它不适合直接搬到生产环境。原因很简单生产环境中最重要的不是“代码能跑”而是“代码在边界情况下也不出问题”。AI 生成代码最擅长的是常规逻辑最不擅长的是你没在提示词里说清楚的异常情况。举个例子。你让 AI 写一个文件批量重命名脚本常规路径它写得很好。但它大概率不会主动考虑这些问题文件名包含特殊字符怎么办目标目录里已经有同名文件怎么办运行到一半断电已经改名的文件怎么恢复磁盘空间不足时怎么处理权限被拒绝时是跳过还是中断这些不是写代码不会写而是问题根本没有被纳入需求描述。AI 不知道你也没问结果就是前半段顺利后半段事故。1.3 判断要不要用 AI coding先回答三个问题很多人看到别人说好就开用看到别人说坑就放弃。我个人觉得先别急着站队先回答下面三个问题你写的代码是会跑一次就扔还是要长期维护如果 AI 生成了错误代码你能多快发现你对这个项目的理解深度是否足以判断 AI 的输出是否合理这三个问题比“AI 编程好不好”更重要。如果项目是一次性脚本你懂需求AI 生成完你快速验证一下就能用那就可以大胆用。如果是核心业务模块你又不清楚业务逻辑AI 说什么你就信什么那我劝你还是先别偷懒。2. AI coding 正确启动顺序先跑最小样例再做批量任务2.1 环境的准备比选哪个工具更重要现在平台上有非常多可选的 AI coding 工具有人用 Cursor有人用 Codex有人用各类 coding plan 或 coding agent。热搜里也出现了很多相关词汇比如“glm coding 7天体验卡”“pi coding agent”“火山agent plan和coding plan”。这些具体产品我不多做评价因为更新速度太快今天推荐的下个月可能就换了。但我可以告诉你一个不变的判断思路选工具之前先把运行环境准备好。这里的“环境”不只是指代码运行环境还包括你的项目代码有没有放在版本管理里有没有独立的测试环境你平时写代码是靠编译报错发现问题的还是靠运行时测试AI 工具可能需要网络请求、安装依赖、创建文件你的系统权限允许吗如果 AI 生成的代码需要安装第三方库这些库的版本和你的环境兼容吗这些前置条件没有处理好AI 工具能发挥的空间就很有限。你可能会遇到现象AI 生成代码报了错你把它重新贴给 AI 修AI 给的方案也是在它自己虚拟环境里猜的不代表你的机器上就能跑。2.2 从单条任务开始不要直接开全量不管用哪种 AI coding 方案我都建议你把第一次测试拆成三个步骤。第一步启动一个极小的任务。比如读取一个文件解析里面的 JSON输出结果。这个任务的目的不是有意义而是验证 AI 工具从理解需求到生成代码再到运行成功的完整链路是否通畅。第二步选一个你以前写过的、逻辑比较简单但不是搜索一下就能找到现成代码的任务。让它写一版然后你自己再写一版或者用你原来的版本对比一下。这一步看的是AI 生成的结果是否可维护变量命名、函数拆分、注释习惯是不是你需要的样子。第三步安全地把 AI 接入你的工作流。比如让 AI 帮你生成单元测试、生成接口文档、补充类型定义。这些任务本身对正确性要求没那么高即使错了影响也不大很适合作为 AI coding 的入口。批量任务一定要放在单任务跑稳之后。这个顺序不是保守而是为了省钱省时间。你想想看如果单条任务生成的代码是有问题的你丢 100 条进去就是 100 份错误代码还得自己清理。2.3 量化和验证 AI 辅助代码的质量很多人说 AI 生成代码“质量差”但问到底哪里差又说不出个所以然。为了让判断更客观我一般会从下面几个维度来看可读性变量名是不是有明确含义函数长度是否合理有没有不必要的大段注释。完整度有没有把异常处理、空值判断、资源释放这些基础细节补上。一致性代码风格是否和现有项目一致有没有引入完全不同的命名规范。可测试性生成模块能不能单独运行能不能方便地打日志、看中间值。依赖风险有没有引入不必要的第三方库这些库是不是维护活跃的。如果一个 AI 生成的模块五条里能有四条达到你自己审核标准那它在这个任务上就是可用的。如果连一半都达不到先别升级工具先把任务拆得更细或者把提示词里的需求边界写得更清楚。3. 从“AI 会写代码”到“AI 真的帮你省事”中间隔着几个关键步骤3.1 语义理解和需求拆解不是复制粘贴就能解决AI coding 最容易被误解的一点是你只要给一句完整的自然语言它就能知道你想要什么。说实话大模型在语义理解上已经很强了但它对“你真正想要什么”的理解依赖的是你把上下文描述得多完整。比如你说“写一个 Python 脚本把某目录下的图片压缩一下”。AI 第一版大概会生成一个基于 PIL 的脚本遍历目录压缩图片。但真正落地时你可能要面对的问题包括是压缩到指定宽度还是指定文件大小输出目录和原目录重复时怎么处理保留 EXIF 信息吗输出文件命名怎么处理遇到非图片文件怎么办如果这些都要靠你来回追问 AI 才能确认那你省下的写代码时间全都花在和 AI 对话上了。所以我在实际工作中不会直接要求 AI“生成一个完整模块”而是先让它列出它对这个任务的理解和假设。比如我会让它先输出请先不要写代码。以下是需求描述请先列出你理解的需求、假设、以及需要我确认的问题然后再给出实现方案。这样做的原因很简单先对齐边界再让 AI 生成代码成功率会高很多。如果上来就让它写代码写得再漂亮也可能不是你要的东西。3.2 代码评审你的“验收标准”是什么AI coding 不只是写代码还涉及到怎么验收代码。传统开发流程里你写完代码会做代码审查检查逻辑、风格、边界情况。这个过程对 AI 生成代码同样适用。我见过一个常见错误让 AI 补全一个函数它返回的结果看起来正常长度也对但内部实现里用了一个不合适的全局变量或者依赖了一个已经废弃的 API。代码不会在编译期报错但运行时就会出现很隐蔽的 bug。因此我建议你给 AI coding 设定一套比较明确的验收标准。比如生成代码后先做静态检查。然后跑单元测试。再准备一个最小复现数据做真实验证。最后人工阅读核心逻辑。不要觉得这太繁琐。真正的 AI coding 使用场景不应该是“生成完直接放进主分支”而是“把 AI 当作一个生产力极高的初级开发者它提交一个 PR你是 reviewer你需要 review 后再合入”。3.3 生产代码里的边界AI 可以帮你写但不能完全替你想边界问题是 AI 写代码和人类写代码差异最大的地方。人类开发者因为做过类似业务知道某些数据字段可能为空知道某个接口在超时的时候应该怎么处理知道不能把用户输入直接拼进 SQL。AI 如果看不到这些上下文只能靠默认假设生成常规做法。这就是为什么有些代码看起来没问题但一到生产环境就崩。我给大家一个比较稳妥的思路把 AI 当作“代码生成模块”把你自己当作“业务语义负责人”。AI 负责把你的描述转成代码你负责保证描述本身覆盖了关键边界。举个例子。如果我要写一个外部 API 调用客户端我会在提示词里强制要求它处理以下内容请求超时时间。非 200 状态码的处理方式。API 返回字段缺失时的默认值。日志记录。要不要重试重试间隔是多少。如果你没有明确写出来AI 大概率只生成最简单的请求代码甚至不处理异常。到时候不是 AI 不聪明是你给它的需求就只有那个深度。4. 换个角度不用 AI 写代码不等于不用 AI 辅助开发4.1 “不再用 AI 写代码”的真实含义可能是“不再盲从 AI 的输出”回到视频标题那句“Im done coding with AI”。我觉得想表达的不是“AI 编程这个方向失败了”而是作者可能经历了某些项目事故决定不再让 AI 直接主导代码生成或者放弃低质量的某类 agent 工作流。这种表达在网络传播里很容易被放大成“AI 编程不行”。但实际工作中还有更大一块 AI 辅助开发价值被很多人忽略用 AI 读代码解释一段手写逻辑。用 AI 做代码 review找出遗漏的边界条件。用 AI 生成测试用例。用 AI 写 commit message。用 AI 分析报错日志。用 AI 把一段复杂代码翻译成更通俗的注释。这些并不是“直接生成业务代码”但它们在真实开发中同样能节省大量时间。而且这些任务的容错度高得多就算 AI 理解有偏差你也不会把坏代码合入主分支。4.2 Coding plan、AI agent 和账号机制背后的使用建议2026 年很多 AI 平台都在推“coder plan”或“agent plan”。热词里能看到“glm coding 7天体验卡怎么用”“火山agent plan和coding plan”“credits在ai里指什么”“coding plan是什么”这类热门问题。说明大家已经过了“AI 能不能写代码”的新鲜期开始关心怎么用、额度怎么算、哪种套餐适合自己。我给几个实用建议。首先不要把 coding plan 理解为无限好用。这类计划通常会给你一定数量的“credits”或者“快速请求次数”用完之后排队或降速。开始一个批量项目之前先算好你的任务量大概会消耗多少 credits别等任务跑到一半额度用完反而影响节奏。其次agent 类和单轮 chat 类要区分开。单轮 chat 适合问问题、生成片段。agent 类更适合处理多文件修改、跨函数重构、自动调试这类复杂任务。但是 agent 的自主性越高越需要你提前设定好“允许修改范围”。有的 agent 会自作主张去修改配置文件、增加依赖包如果你没有拦住后面可能就会出现一堆无意义的变更。最后拿到体验卡、免费额度这些资源之前先确认你准备测试什么。我之前见过有人拿完 7 天体验卡不知道怎么用随便写了几个 prompt效果一般然后得出“AI coding 不好用”的结论。这个结论其实只说明他没有提前设计测试任务。4.3 适合尝试 AI 辅助代码的场景根据我自己的经验以下这些场景非常适合 AI 辅助开发值得深入探索按已有代码风格补全模块。根据注释生成对应函数初版。将复杂逻辑翻译成更易读的浅层实现。为老代码写单元测试。自动分析测试失败日志并给出修复建议。数据清洗和格式转换脚本。代码迁移例如把旧接口调用改成新 SDK。生成数据库建表语句和索引建议。根据 OpenAPI 文档生成客户端调用代码。复杂正则表达式解释和调整。这些场景有一个共同点核心语义是明确的AI 只要按照输入输出关系生成代码即可。它不是帮你拍板业务方向而是帮你把明确的事情写得更快。5. 如果你仍然决定写“自己的代码”也躲不开工具链的变化5.1 手工编码和 AI 辅助并不对立很多人理解“coding with AI”是一个非此即彼的选择。要么全用 AI 写要么回到手敲。但实际上绝大多数成熟开发者采用的早就已经是混合模式。手写核心逻辑AI 处理样板代码。你自己掌握架构和数据流AI 帮你在局部实现填充。你对 API 设计负责AI 帮你做 API 的 params 校验代码。这种方案既能控制风险又能享受效率提升。真正要警惕的是完全依赖 AI 生成代码而失去理解能力。当你懒得读 AI 生成的每一行懒得跟踪改动懒得出问题后去查根因那你就已经从“用工具”变成了“被工具带动”。这种状态确实容易让人说出“Im done coding with AI”。5.2 什么样的开发者不需要 AI codingAI coding 不是万能的所以也确实存在不太需要它的开发者类型。如果日常工作已经高度标准化项目模板、代码生成工具、内部脚手架都很完善新功能的开发节奏是“复制前一个项目然后改改”那 AI coding 带来的边际收益确实不高。如果工作内容以算法研究、底层内核、硬件驱动为主需要高度精确的硬件状态和系统调用理解AI 生成的代码可能帮你写出来但你需要大量时间验证它的正确性反而不如自己写。这种情况下AI 更适合用来辅助阅读文档、解释样例代码。还有一种情况工作环境中代码仓库严格隔离不允许把代码外发到第三方 AI 平台那这类工具从合规上就不可用。需要找企业私有化部署方案或者选择完全离线的代码模型。这是部署问题不是能力问题。5.3 AI coding 后的开发者核心能力是什么如果只让我说一条我会说读代码和改代码的能力比写代码的能力更重要。以前代码大多数是自己一个字符一个字符敲出来的写的过程本身就是理解过程。现在AI 帮你敲你接收到的是一段成品。这时候你如果没有能力快速看懂它没有能力发现隐藏 bug没有能力在需要修改时不破坏其它逻辑那么 AI 就不是你的助手而是你的风险源。我建议每个想长期吃开发这碗饭的人在日常工作中刻意训练“代码审查”能力。看到 AI 生成代码先别急着运行试着做这几件事读一遍看看主流程是否能理解。找异常处理看它有没有预防输入错误。检查资源释放连接、文件句柄有没有关闭。思考并发场景如果多个用户同时调用会怎样。查依赖有没有引入没必要的包。这个习惯不仅能帮你更安全地用 AI coding也能让你和不用 AI 的开发者形成真正的差异化优势。6. 深入实战我用 AI coding 的一次完整落地过程6.1 目标设定和拆解为了让你知道上面的方法怎么用我拿一个实际场景拆解一遍。这里不涉及具体业务代码但完整过程可以参考。假设需求是开发一个小型爬虫系统从某公开网站抓取公开文章信息保存到数据库并支持增量更新。考虑到合规性先说明一点实际开发中爬虫一定要确认网站协议和内容授权我这边的例子只做技术演示。我会拆成六个子任务用 AI 生成抓取列表页的代码。用 AI 生成详情页字段解析代码。用 AI 生成数据库表结构。用 AI 生成数据入库和去重逻辑。用 AI 生成定时任务入口。用 AI 生成日志和异常告警。这个顺序有一个好处每一步都可以独立验证前一步跑通了再进入下一步。如果让 AI 一次性生成整个项目中途任何一个依赖出问题你都很难定位到具体是哪一段代码的问题。6.2 让 AI 先生成接口定义再生成实现真正开始前我先让 AI 输出这个模块的接口设计而不是代码实现。比如我会这样写提示词我需要开发一个定时抓取公开网页标题和正文摘要并保存到 SQLite 的小模块。 请先给出这个模块的函数接口设计包含函数名、入参、返回值和职责说明不要写具体实现。为什么要这一步因为 AI 直接写实现往往会按照它自己的数据库设计、函数命名、异常类型来生成整体可用但和你后续期望的调用方式可能相差很大。先确定接口等于把 API 边界固定下来了后面如果觉得实现不理想你可以单独重写而不会影响到调用方。AI 给出的接口还是值得参考的。接着你只需要审查设计调整你需要的地方然后再让它按接口逐个实现。这种做法比一次性让它生成“整个项目”稳定得多。6.3 运行后的验证和调试子任务跑完以后不要只看“程序没有报错”就当作成功。真正的验证要做三件事。第一件用一条真实数据验证抓取结果。可以和手抓的结果对比看看字段映射是否正确。第二件用一个异常数据验证容错能力。比如一条没有摘要的文章一条超长的标题一条重复数据看看系统是否会崩溃。第三件观察日志。如果没有日志说明你以后出问题只能瞎猜。建议每个子任务都加入可视化的日志输出。实测中我经常遇到一个场景AI 生成的代码顺序是“先抓取然后解析然后入库”。如果抓取失败它会抛异常后面两步直接不执行。这看起问题不大但如果你要定时任务连续处理 1000 个 URL其中一个 URL 超时就会让整个任务中断。这时你需要在代码里让单个 URL 的失败不影响后续任务。这就是一个很典型的边界条件需要通过人工经验补进去。所以当出现不稳定时你不要第一时间怀疑“AI 能力不行”而是检查这些关键点失败是否会导致整体中断是否有超时限制是否有重复数据唯一索引特殊字符是否会引起解析错误文件、数据库、网络连接有没有正规关闭错误日志够不够你判断是哪一步出错把这些问题处理干净AI 生成代码的可用率会翻倍。6.4 这套流程所花费的时间一位完全手写的开发者这个模块大概要 3 到 4 个小时包括数据库设计和异常处理。用 AI 生成基础代码大概 30 分钟但剩下的审查、验证、补边界大概需要 1 到 2 小时。总时长可能缩短到一半左右。如果你平时本来就会写代码并且对自己写的逻辑有足够信心AI coding 的核心价值不是让你节省写代码的那部分时间而是节省你去搜索 API 文档、写模板代码、理清语法细节的时间。写业务逻辑这件事基本功越好AI 用起来越顺手。7. 常见误区和报错排查清单7.1 AI coding 常见的六个误区我整理了几个常见误区新手尤其容易踩误区一让 AI 生成完代码不看就直接运行。结果报错了还在问“为什么 AI 写的代码运行不了”。运行代码本来就是你要负责的环节。误区二认为 AI 上下文越长越好。上下文长度是有限的如果你的项目很庞大AI 很容易遗忘最早的那些约束。比较稳妥的方式是单独让 AI 处理某个文件或某个模块不要把整个工程一次性丢进去。误区三AI 生成代码后不能一次通过测试就换工具。工具选择确实重要但更多问题出在提示词不够准确和需求拆解不够细。误区四忽视项目自身的构建方式。比如项目用的是 pnpmAI 可能在文档假设下使用了 npm结果生成了 package-lock.json破坏了团队统一依赖管理这同样是一种“错误代码”。误区五直接让 AI 修改生产主分支代码。AI agent 有权限操作文件之后危险性会上升。最好的方式是让 agent 开分支或者提供 diff你人工确认后再合并。误区六所有代码都想让 AI 写。AI 生成时需要编译时间较长的小模块时性价比不高。自己几秒钟能写完的代码没有必要让它生成因为等它返回加上你校验的时间足够手敲了。7.2 当 AI coding 没有按预期工作时按什么顺序排查我自己的排查顺序一般是这样的先看 AI 返回的内容和你询问的问题是否一致。不一致先补提示词。看代码是否能单模块运行。不能检查它依赖的环境和函数是否存在。看运行时报错的位置。如果报错在 AI 生成的代码内部先把完整的报错信息重新喂给它。如果修复后引发新的报错需要判断是不是 AI 在修一个问题的同时引入了另一个问题。此时不要反复让 AI 自己猜而是自己阅读相关代码修改得更稳妥。如果 AI 生成的代码看起来没有任何问题但仍运行失败检查你的环境包括 Python 版本、Node 版本、依赖包版本、系统架构。注意不要一看到错误就让 AI 重复生成。错误日志、期望行为、运行环境、最近改动这四类信息一次描述完整比来回追问十轮更高效。7.3 代码生成后的 review 清单最后给你一份我每次合入 AI 生成代码前会过一遍的 review 清单。可以把它保存下来当成自己的模板有完整的入参校验吗有没有在没有数据时返回错误提示而不是崩溃外部依赖是否必要版本锁定没有文件路径是否使用相对路径或配置文件而不是写死关键操作是否有日志记录是否处理了运行时中断有没有把不应该提交的本地参数硬编码进去是否遵循了项目现有的代码风格递归或循环有没有防止死循环的机制敏感信息是否已经从代码里移除例如密码、密钥、token8. 往后怎么走AI coding 真正的下一步8.1 从“让 AI 写代码”到“让 AI 做工程决策辅助”现在很多 AI coding agent 已经开始不只是生成代码而是能根据报错信息自己改代码再运行测试直到通过。这看起来离“自动化编程”很近了。但我的判断是这些工具对开发者要求不但没有降低反而更高了。你如果不是很清楚“测试通过”和“逻辑正确”之间的差异agent 会给你一种虚假的安全感。测试通过只能说明某个路径上没问题却不能完全说明所有用户场景下没问题。开发者如果没能力补全测试覆盖没有能力理解 agent 为何这样修改那 agent 的自主性越强你越难控制结果。我希望 2026 年以后 AI coding 的发展方向不是把程序员变成“只负责描述需求的人”而是把程序员从重复劳动里解放出来让他们有更多时间思考数据模型、边界情况、代码架构和用户体验。8.2 适合个人开发者和小团队的落地建议如果你是个人开发者或者小团队没有专门平台工程团队我建议你在引入 AI coding 时走下面这条相对稳妥的路径重点先从“辅助任务”开始使用。包括测试用例生成、注释、代码解释、日志分析、脚本编写。然后再上升到“有代码库上下文的重构任务”。这一阶段AI 需要能读取你的工程文件并做局部修改。你可以小步尝试注意每次改动后对比现有测试。最后才是探索“放权模式”。也就是让 agent 有更高的权限自己去改代码、运行命令、修复问题。这个模式必须建立在你有完善的 Git 版本管理、自动测试和可回滚机制的基础上。没有这些不要随便放开权限。这里提到 Git 回滚是建议你在让 agent 大幅修改代码前先建立一个明确的提交点。实际使用时会遇到 agent 修改了你不希望它碰的文件的情况。如果你的改动已经分散在多个文件里回滚的难度会变大。有干净的版本点你随时可以推倒重来不会浪费时间。8.3 最后的一点个人看法我属于那种“工具一出来就马上试用”的人。AI coding 从早期只能补齐函数到后来能改多文件再到可以当 agent 自动调试这个过程我自己也是跟着踩坑走过来的。遇到过 AI 把项目配置文件改乱的时候也遇到过 AI 连续改同一段代码三次才修好的情况。它确实不完美但不代表这个方向不可用。视频标题是“Im done coding with AI”但我更愿意做另一个判断AI coding 不会消失消失的是那些把 AI 输出直接当成可用代码的做法。未来几个季度这类工具的门槛会进一步降低coding plan 会成为标配真正拉开差距的仍然是开发者判断代码能不能用、边界在哪里、风险在哪层的能力。如果你看完这篇文章最终选择在某些项目里少用甚至不用 AI 写代码我觉得也是理性的。不过最好不要因为一次失败就放弃它。换个思路从代码审查角度开始用 AI从写单元测试开始用 AI从写一次性脚本来用 AI你会发现它依旧能给你节省不少时间。我更建议把这次讨论当成一次提醒AI 时代的手艺已经从“字符级编码手艺”变成了“系统级控制能力”。你能让代码按你预期的方式运行你能预见边界你能保证项目在别人接手时依然可维护这些能力比是否使用 AI coding 更值得长期投入。