不开玩笑，最近有个视频标题一直在圈子里转，“I'm 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 年才有的事。
那为什么现在反而有人站出来说“I'm 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 的输出”
回到视频标题那句“I'm 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 生成的每一行，懒得跟踪改动，懒得出问题后去查根因，那你就已经从“用工具”变成了“被工具带动”。这种状态确实容易让人说出“I'm done coding with AI”。
5.2 什么样的开发者不需要 AI coding
AI 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 生成代码后不能一次通过测试就换工具。工具选择确实重要，但更多问题出在提示词不够准确和需求拆解不够细。
误区四：忽视项目自身的构建方式。比如项目用的是 pnpm，AI 可能在文档假设下使用了 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 清单。可以把它保存下来，当成自己的模板：
- 有完整的入参校验吗？
- 有没有在没有数据时返回错误提示而不是崩溃？
- 外部依赖是否必要，版本锁定没有？
- 文件路径是否使用相对路径或配置文件，而不是写死？
- 关键操作是否有日志记录？
- 是否处理了运行时中断？
- 有没有把不应该提交的本地参数硬编码进去？
- 是否遵循了项目现有的代码风格？
- 递归或循环有没有防止死循环的机制？
- 敏感信息是否已经从代码里移除，例如密码、密钥、token？
8. 往后怎么走：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 连续改同一段代码三次才修好的情况。它确实不完美，但不代表这个方向不可用。
视频标题是“I'm done coding with AI”，但我更愿意做另一个判断：AI coding 不会消失，消失的是那些把 AI 输出直接当成可用代码的做法。未来几个季度，这类工具的门槛会进一步降低，coding plan 会成为标配，真正拉开差距的，仍然是开发者判断代码能不能用、边界在哪里、风险在哪层的能力。
如果你看完这篇文章，最终选择在某些项目里少用甚至不用 AI 写代码，我觉得也是理性的。不过最好不要因为一次失败就放弃它。换个思路，从代码审查角度开始用 AI，从写单元测试开始用 AI，从写一次性脚本来用 AI，你会发现它依旧能给你节省不少时间。
我更建议把这次讨论当成一次提醒：AI 时代的手艺，已经从“字符级编码手艺”，变成了“系统级控制能力”。你能让代码按你预期的方式运行，你能预见边界，你能保证项目在别人接手时依然可维护，这些能力，比是否使用 AI coding 更值得长期投入。
