最近社区里有一条视频标题被反复转贴《Im done coding with AI》。有人翻译成“我已经不用 AI 写代码了”也有人理解成“我终于把 AI 编程这件事跑完了”。不管视频原意是什么这个话题确实值得展开AI 编程不是“能用/不能用”的两极而是一个需要边界、验收和退出机制的工作方式。很多人用 AI 写代码前两周效率很高后面就陷入“改完 A 坏 B”的循环最后只能对着屏幕说一句 done。我更愿意把“done”理解成一种状态切换从“盲目相信 AI 生成结果”切到“把 AI 当作一个很会写草稿但不负责质量的协作者”。下面不评价那支视频而是把我自己跑 AI 编程工作流时遇到的环境、参数、失败点和边界整理出来覆盖从单条代码生成到批量任务再到什么时候应该手工接管。看完至少能回答三个问题AI 编程到底能稳定处理什么任务一套最小可复现的流程长什么样什么情况下你该说“我不再继续依赖 AI 了”。1. “done” 到底是什么意思一次对 AI 编程的重新定位1.1 两种完全相反的解读短视频标题的优势是留白。“Im done coding with AI”可以读成“我用 AI 编程已经完事了”也可以读成“我被 AI 编程折腾够了”。这两种解读在社区里都有不少支持者。前一种人把 AI 编程当作加速器用自然语言描述需求让 AI 生成样板代码、写测试、修小 bug然后人做最终审查。后一种人则见过太多“AI 生成的漂亮代码”在真实业务里崩盘表面逻辑完整实际没有处理空值、没有考虑并发、没有做错误恢复。这两种体验并不矛盾。区别在于你有没有给 AI 划清楚边界。只给一句话就让它写整个项目大概率会翻车给它一个小到可以验证的任务同时准备好测试数据和回滚方案反而很稳。1.2 把“done”当成状态切换点我自己的判断是done 不是一个永久状态而是一种“从这里开始AI 不再主导”的信号。它意味着你已经把需求、环境、验收标准都摸清楚了AI 能帮你完成的代码骨架也完成了接下来需要人去做语义审查、性能验证和异常处理。所以这篇文章真正想聊的不是“AI 编程好还是不好”而是“你在哪个阶段、用哪种方式、按什么标准验收 AI 生成的代码”。这个话题重新热起来和 vibe coding 的流行有关。所谓 vibe coding大意是根据感觉持续向 AI 提需求让模型一段一段生成代码人只负责看整体氛围对不对。这种方式做原型很快但产品一旦进入长期维护问题就会集中爆发。很多喊出 done 的人其实不是对 AI 失望而是对“没有边界地使用 AI”失望。2. 先别急着 doneAI 编程真正能稳定解决的四类任务2.1 样板代码和胶水代码样板代码包括读取配置、初始化数据库连接、写一个 CLI 入口、把某个数据结构序列化成 JSON。这类代码结构化强、模式固定AI 很擅长。胶水代码也类似。两个内部接口之间的字段映射、时间格式统一、从 CSV 转成数据库表记录AI 只要看到输入和输出的样例基本能一次生成。关键是你必须把字段对应关系写清楚而不是只给一句“把它接起来”。2.2 单个函数的补全和重构如果你已经有完整函数只是希望增加一个参数、调整返回值、把一个大函数拆成几个小函数AI 的稳定性会明显更高。因为上下文已经存在AI 不需要猜太多。这里我的习惯是先把原函数贴出来再说明改动点而不是让 AI 重写整个文件。改动越小diff 越清晰出问题越好回滚。判断标准不是“它能不能理解我的意图”而是“这次改动能不能直接进入版本控制”。2.3 测试用例生成让 AI 针对一个纯函数生成测试用例通常比较靠谱。尤其是边界条件比如空字符串、None、超大整数、负数、重复值只要你在提示词里点名AI 基本都会覆盖。但 AI 生成的测试断言不一定符合业务预期。比如它可能断言某个排序算法返回“升序列表”你以为应该是“原地排序并返回 None”。所以测试用例可以交给 AI 写断言必须人确认。2.4 日志和报错解读把一段报错信息贴给 AI让它解释可能原因和排查顺序这个用途经常被低估。AI 不需要改代码只需要做信息整理和模式匹配往往能直接指出你忽略的常见问题比如依赖版本冲突、时区转换错误、编码问题。这类任务的成功标准很明确它给出的排查建议能否被日志佐证。如果它给了一堆“可能”但没有一条能解释日志中的关键行那就不要继续深聊先自己打开日志看实际字段。任务类型AI 适合度人需要重点检查什么样板代码很高命名、配置路径、依赖版本胶水代码较高字段映射、异常处理单函数重构高diff、边界行为测试用例生成中高断言是否符合业务语义报错解读中高建议是否与日志关键行对应3. 把 AI 编程从聊天变成工程工具、环境与最小流程3.1 编辑器插件还是 Coding Plan现在使用 AI 编程不只有聊天窗口这一条路。常见入口可以分成两类一类是编辑器插件比如 PyCharm AI 插件、Cursor 这类带 AI 补全和对话能力的 IDE。优势是把 AI 生成结果直接放进代码上下文你不用复制粘贴省掉很多格式问题。另一类是云厂商的 Coding Plan 服务比如阿里云百炼 Coding Plan、火山方舟 Coding Plan、智谱 GLM Coding 体验卡这类入口。它们通常会提供一个可编程调用的接口适合把 AI 编程能力接入你自己的脚本、批量任务或 CI 流程。我不建议一上来就同时开一堆工具。先用一个最顺手的编辑器插件跑通日常单文件任务再根据批量需求决定是否开通 Coding Plan。工具数量多不代表效率高维护成本和 API 额度都是真实开销。3.2 API Key、模型选型与额度不管用哪家服务第一步基本都是开通服务、创建 API Key、确认模型名。拿一个 OpenAI 兼容接口作为示例流程可以是这样from openai import OpenAI client OpenAI( api_key你的API Key, base_urlhttps://你的服务商兼容地址/v1, ) resp client.chat.completions.create( model你开通的模型名, messages[ {role: system, content: 你是代码助手只输出可运行的Python代码。}, {role: user, content: 写一个从JSON文件读取配置并返回字典的函数。}, ], temperature0.2, ) print(resp.choices[0].message.content)这里最容易忽略的是三点base_url 要按你开通服务的文档填写不同服务不一定相同。模型名要精确填错会直接返回模型不存在。temperature 建议先调到 0.2 附近代码生成任务不需要太高随机性数值越高越容易得到花哨但不可靠的输出。同时要关注 credits 或 token 用量。很多 Coding Plan 会以 credits 为单位计费一次高复杂度请求消耗的 credits 可能比想象中多。我的建议是在正式批量跑之前先用小样本模型或短文本确认输出格式再切换到完整任务。3.3 一条最小验证流程不管是什么工具我都建议先跑通一条最小任务。所谓最小任务是输入足够小、结果足够好判断的任务。比如让 AI 生成一个read_config函数输入是 JSON 文件路径输出是字典。流程拆开是这样先把需求写成一句话明确输入和输出。调用 AI 生成代码。把生成结果复制进项目执行一次单元测试。检查 diff看它是否引入了额外依赖或改动了无关代码。如果没问题再让 AI 补一个边界用例。这个流程的关键在于每次只让 AI 做一件事。多任务塞进同一个提示词虽然看起来省时间但一旦结果不如预期你很难判断是哪个环节出了问题。注意不要一上来就让 AI 生成整个模块。先用单函数验证工具链是否稳定再逐步扩大范围。4. 从单条任务到批量任务什么时候会失控4.1 批量生成代码的代价单条任务跑通之后很多人会自然想能不能把 100 个文件丢给 AI让它统一加日志、统一改错误处理、统一重构函数签名这个想法本身没错但不能只关注生成速度。批量任务真正的成本在于一致性、命名风格、依赖版本冲突以及“上一批成功、下一批失败”时的排查负担。举个例子AI 可以给 100 个文件各加一段 try-except但如果它遇到两个不同风格的错误处理方式就会随机选择甚至把原来的自定义异常改成内置异常。这比不加更危险。4.2 Agent 模式不是万能现在很多 Coding Plan 和 AI 编程工具都提供 Agent 模式你给一个总目标AI 自己拆解任务、读取文件、修改代码、运行命令直到完成。这个模式看起来很酷但它会放大中间过程的不可控性。你看到的可能只是它最终输出了一个“成功”但它到底改了多少文件、为什么改了某个不相关的配置你可能完全不知道。如果只是改一个文件的函数逻辑用普通补全或对话就够了不需要开 Agent。即使要开 Agent也建议给它设定最小工作目录明确“只允许修改 src/ 目录”“不允许运行安装命令”“不允许修改测试数据”这类约束。约束写得越清楚它乱跑的几率越低。4.3 失败重试的本质是写约束批量任务不能只靠“失败就重试”。重试之前要先定义什么算成功输出文件是否存在、代码能否通过语法检查、日志里有没有出现异常关键字。如果这些条件没有定义AI 重试一百次也没用因为它不知道自己在失败。真正要做的是把提示词变成可验证的规范比如输入文件的 schema 是什么。输出必须遵守什么格式。遇到空值或缺失字段时应该怎么处理。如果某个文件已经处理过是否跳过。还有一个实际参数是并发。刚开始批量跑时并发建议设成 1跑通后再逐步提高到 2 到 4。并发提高会明显减少总耗时但也会让失败问题更难复现。低配置机器直接开高并发还会遇到内存不足或接口限流。参数新手建议批量任务建议并发数1先从 1 开始再提到 2-4超时时间按单条任务预计耗时的 2 倍根据日志统计后调整失败重试次数1不要无限制重试最多 2-3 次输出命名固定文件名输入文件_批次号_时间戳日志级别INFODEBUG 且单独记录失败项5. 真正的 done 不是不碰 AI而是把 AI 放进验收流程5.1 把 AI 生成的代码当成外部 PR很多团队对 AI 生成的代码有一种错觉因为是 AI 写的所以应该和手写代码不一样。实际上你应该把它当成一个外部开发者提交的 PR逐行审查 diff检查命名、依赖、异常处理和性能风险。我最常用的一种做法是让 AI 生成代码后先在本地跑测试然后看git diff --stat和git diff。如果它改动了我没有要求的模块说明提示词里的范围没有限制住这时候不应该继续让它改而是先缩小范围。5.2 测试门槛不能省无论 AI 多强测试都不能省。更好的做法是让测试先于功能代码先让 AI 根据需求写几个核心测试用例人确认断言正确后再让 AI 实现功能来通过这些测试。这个方法的好处是AI 在写功能代码时能看到测试约束输出会收敛很多。如果反过来先让 AI 写功能再让它写测试它很容易写出和功能一致但错得一致的测试。5.3 把需求和约束写进提示词提示词不是越长越好但关键约束必须写清楚。一个稳定的提示词模板可以包含四部分任务目标一句话说明要做什么。输入输出说明参数类型、返回结构、文件路径。边界条件空值、超长文本、重复数据怎么处理。禁止事项不要修改哪些文件、不要安装新依赖、不要改变原有接口。任务把传入的时间字符串从 2026-08-01 12:00:00 转成 2026-08-01T12:00:00Z。 输入一个字符串格式固定为 YYYY-MM-DD HH:mm:ss。 输出一个字符串ISO8601 格式。 边界如果输入为 None 或空字符串返回空字符串。 禁止不要改动其他函数不要新加依赖。这种提示词看起来不酷但很实用。因为 AI 代码生成最大的问题不是“不理解”而是“输入信息不足时自行发挥”。6. 常见失败现场与排查顺序6.1 现象AI 改完代码后项目启动不了先不要急着让 AI 继续改你已经知道它改坏了一次继续用同样的方式改很可能越来越乱。我的排查顺序是看 git diff确认它改动了哪些文件。找出和本次需求无关的改动先回滚这些部分。手动运行核心命令拿到完整报错。把报错贴回给 AI问它应该回滚哪一部分而不是问它如何重新实现。很多启动失败不是逻辑问题而是 AI 改了配置文件、删除了必要 import或者在自动修复时引入了一个新依赖版本。回滚无效改动比继续提示词修复更快。6.2 现象生成结果看起来对一跑就错看起来对说明格式和命名都对一跑就错通常是边界条件没有处理。重点检查三处空值AI 生成的函数很可能没有处理 None、空列表、空文件。路径问题它可能写死了相对路径但你从项目根目录运行时路径不对。编码问题如果处理中文文本要确认打开文件时指定了正确编码比如 UTF-8。遇到这种问题建议在提示词里追加一行“请先检查所有输入可能为空的场景”然后重新生成。但如果连续两次都是同一个问题就不要再问 AI 了自己打开函数看第一段逻辑。6.3 现象批量任务一半成功一半乱码批量任务的排查和单任务不同。单任务只要看代码逻辑批量任务还要看输入和输出之间的对应关系。先看失败的几条和成功的有何共同点是文件名包含特殊字符还是某些字段缺失还是输入文件编码不一致。然后看输出目录里是否有文件名冲突是否被同一个任务覆盖。最后检查失败重试逻辑看它有没有把成功项重复处理。批量任务里很多“乱码”不是 AI 生成的问题而是文件读写时没有统一编码。CSV 文件里混入 GBK 和 UTF-8AI 再聪明也猜不出每一行的作者意图。让 AI 写一个统一转码脚本比在生成代码时反复修更稳妥。注意批量任务一旦出现异常先把成功项和失败项分开记录。不要原地重跑重跑可能会覆盖已有日志。7. 到底什么时候该说 “Im done coding with AI”7.1 你开始盲改代码的时候如果你已经不知道自己想让 AI 改成什么只会一遍遍说“还是不对再改改”这时候就该停下来。这种状态说明你已经失去了对代码的控制权。AI 可以是一个快速生成草稿的协作者但不能替你做技术决策。我见过很多同学在提示词里越写越细最后不是让 AI 改代码而是让 AI 猜一个连自己都描述不清楚的目标。这种时候与其继续消耗 credits不如自己打开代码把变量名理清楚再重新定义任务。7.2 你跳过测试的时候如果因为“AI 写的应该没问题”而跳过测试这是一个很危险的信号。AI 写代码的准确性取决于任务范围、上下文清晰度、模型能力而不是“它觉得没问题”。哪怕是一个三行的小函数我也建议先跑一下再提交。这里的测试不一定非要完整单元测试哪怕只是手动执行一次确认返回值符合预期也比重头排查问题强。7.3 你把 credits 和 token 当成进度条的时候消耗量不等于进度也不等于质量。如果某个任务已经跑了很多次每次只是消耗 credits没有产生新的有效信息那说明你的提示词有问题或者这个任务根本不适合交给 AI。真正健康的信号是每次调用都能缩小一个可选范围或者给出一个可验证的中间结果。如果连续多次调用只是换来不同姿势的同一份代码马上切换人工处理。我个人更建议把“done”当成一种可随时触发的手动模式开关。该用 AI 的时候让它先写该人工接管的时候马上切过去。最重要的是你得知道边界在哪。踩过几次坑之后会发现很多问题不是工具能力不够而是前置环境和输入材料没有处理干净。把输入管住把测试立住把 diff 看清楚再决定要不要继续把代码交给 AI。