最近一个视频标题在开发者圈子里流传Im done coding with AI。乍看像是对 AI 编程的全面反水但更准确地说这是“让 AI 直接把功能写完”这个幻想破灭后的清醒。它不是个例而是一部分开发者从工具狂热进入冷静期后的真实情绪。如果你也经历过“AI 写代码十分钟Debug 两小时”那这篇文章就是写给你看的。我的判断是AI 编程工具不会消失但“直接让 AI 把功能写完”的工作方式正在被淘汰。真正留下来的是一套把 AI 当成“可随时回滚的实习工程师”来使用的工作流先写规格、再写测试、最后让 AI 填充实现每一步都有验收关卡。本文会从技术现状、失败原因、评估方法、实践流程四个角度展开最后给出一个可以在本地跑通的最小示例帮助你判断自己到底该不该继续用 AI 写代码以及怎么用才是低成本、低风险的方式。1. 这篇文章真正要解决的问题先说痛点。很多开发者最初接触 AI 编程工具时的预期是我描述需求AI 生成代码我复制粘贴功能上线。这个预期在前几个 demo 里确实成立AI 能很漂亮地写一个排序算法、一个登录接口、一个 CRUD 页面。但随着项目规模变大问题开始密集出现AI 改了一个文件却忘记改调用方AI 为了满足一个错误提示生成了完全不符合业务逻辑的代码AI 在上下文窗口里看到的需求和产品经理真实说出来的需求根本不是一回事。这些现象积累到一定程度就会产生“Im done coding with AI”的声音。但这其实不是 AI 技术本身失败了而是使用方式失败了。大多数人把 AI 当成“一次生成、直接交付”的承包商却没有给它配套需求基线、测试验收、代码评审和回滚机制。在真实工程项目里这四个环节恰恰是不能省的。所以这篇文章要解决的不是“要不要用 AI 写代码”而是为什么一部分开发者会出现“放弃 AI 编程”的情绪。哪些场景适合 AI 辅助哪些场景现阶段很不适合。如何设计一套“用 AI 但不失控”的工程流程。如何用规格先行、测试先行、评审兜底的方式把 AI 的产出控制在可维护范围内。如果你是刚接触 AI 编程的新手读完能少踩很多坑如果你已经在团队里使用 Cursor、Copilot、通义灵码等工具读完也能帮你定位效率下降的根因。2. AI 编程的核心概念与工具现状在讨论“要不要用 AI 写代码”之前先厘清几个容易混淆的概念。这些词在最近的开发讨论里高频出现但很多人并没有准确理解它们的边界。2.1 AI Coding 与 Vibe CodingAI Coding是当前 AI 编程领域的总称主要指通过大语言模型辅助甚至自动完成代码编写、重构、测试和修复的工作方式。Vibe Coding是 2025 年前后流行起来的一种更随性的用法指开发者用自然语言描述感觉和意图让 AI 顺着“氛围”把代码写出来自己只负责运行看效果。Vibe Coding 强调快速验证想法不强调对每一行代码的理解。Vibe Coding 在原型阶段很有价值但在生产项目里风险很高。原因很简单AI 不知道你的业务约束、部署环境、权限边界和既有架构它只能根据你给出的上下文和你对话窗口里的信息推测。一旦“推测”变成“默认”代码就充满了不可见的假设。2.2 Spec Coding 与需求先行为了对抗 Vibe Coding 的失控一些团队开始强调Spec Coding。所谓 Spec就是编写代码前先写清楚规格说明这个功能要解决什么问题、输入输出是什么、异常情况怎么处理、边界条件有哪些。Spec Coding 的核心思路是把 AI 当成一个执行者而不是决策者。你负责把“做什么”和“怎么验收”讲清楚AI 负责给出“怎么实现”的第一版。这样即使 AI 生成的代码有问题评审者也能对照 Spec 快速发现偏差。2.3 AI Agent 与 Coding Plan从工具形态上看AI 编程工具正在从“代码补全”走向AI Agent。代码补全类工具是“你写它补”Agent 类工具是“你提需求它自己规划步骤、修改多个文件、运行命令、查看结果然后继续调整”。Cursor 等工具已经具备了一部分 Agent 能力。与此同时国内外的云平台也推出了Coding Plan这类按额度或按计划购买 AI 编程能力的服务。你可以把它理解为账号层面的资源配额通常通过Credits点数/信用额度来计费。AI Agent 每执行一次多步骤任务就会消耗一定数量的 Credits。开发者需要注意:不要以为“无限对话”等于“无限任务”复杂任务和长上下文很容易把额度快速跑完。2.4 AI 编程的两种工作模式结合当前的工具现状可以把 AI 编程分成两种模式模式特征适合场景风险辅助补全开发者主导AI 提供片段写测试、写模板、翻译代码风险低但提效有限Agent 自主AI 主导多文件修改重构、修 bug、生成完整功能上下文丢失验收成本高大多数“Im done coding with AI”的开发者其实是在第二种模式里吃了亏。他们让 Agent 自主完成任务却忽略了 Agent 并不具备对业务全局的理解能力。更稳的做法是让 Agent 在高度受限的任务边界内工作并强制配好验收门禁。3. 为什么一部分开发者会选择放弃 AI 编程这一章不打算贬低 AI 编程工具而是客观分析失败案例背后的共性原因。理解这些原因才能避免踩同样的坑。3.1 上下文丢失与局部最优AI Agent 本质上是在有限的上下文窗口里做“局部最优”。它可以读到当前打开的文件但如果项目的核心逻辑分散在十几个模块里Agent 很容易为了满足某个函数签名而忽略整体设计。更常见的是它修改了 A 模块却不知道 B 模块已经依赖 A 模块的旧行为最终在测试阶段才暴露问题。这不是模型能力不够而是任务描述和工程现实之间存在信息差。开发者如果直接把“帮我实现 xxx 功能”丢给 AI得到的往往是一个“看起来能跑”但并不符合真实约束的版本。3.2 验收成本没有减少很多人忽略了一点AI 编程并没有消灭我们理解代码的责任。无论代码是 AI 写的还是人写的上线前都必须评审、测试、确认需求。如果让 AI 一口气生成大量代码你的评审成本会爆炸因为你必须逐一核对每个文件是否与需求一致。换句话说AI 把“写代码的体力活”转化成了“理解别人代码的脑力活”。如果你本来就没打算理解 AI 写的代码那后续修复缺陷时就会特别痛苦。3.3 Credits 消耗与成本失控在 Agent 模式下AI 看起来“很勤奋”它反复运行命令、反复报错、反复自我修复但这些步骤会持续消耗 Credits。很多开发者在月度账单出来后才意识到自己用 AI 修一个需求的时间虽然变短了但成本并没有变少甚至因为大量无效尝试而变高了。更稳妥的策略是先让 AI 给出实现方案而不是直接让它执行。方案评审通过后再让 AI 按步骤执行避免它在错误方向上反复烧钱。3.4 安全与合规约束在企业项目里AI 编程还面临代码安全和合规问题。AI 生成代码可能引入不安全的依赖版本、硬编码的密钥、不合理的权限配置这些都比“代码风格差”更致命。另一个问题是很多 AI 工具会把你的代码片段发送到云端模型处理这在不允许代码出网的团队里是无法接受的。因此安全团队通常会要求AI 生成代码必须经过安全扫描、敏感信息扫描和最小权限检查。如果你所在的团队没有这些关卡那么“不用 AI 写代码”反而是更安全的选择。4. 如何正确评估 AI 编程工具的适用范围讨论到这一步核心判断已经很清楚了不是“能不能用 AI”而是“什么任务适合用 AI、什么任务必须人来主导”。我建议用下面这套评估清单来过滤任务。4.1 适合同 AI 配合的任务独立的、可测试的单元功能如生成工具函数、写正则、写 CRUD 接口、补单元测试。跨语言的代码翻译把 Python 代码翻译成 Java或者把旧框架的写法迁移到新框架。模板化代码生成 DTO、实体类、配置文件、HTTP 客户端。已有测试约束的 Bug 修复当测试已经写清楚预期行为时AI 在约束内修改代码的成功率会高很多。文档和注释生成对已有函数生成注释、生成接口文档、总结变更。这些任务的共同点是边界清晰、输入输出明确、容易验证。即使 AI 出错你也能通过测试或对比快速发现。4.2 不适合直接交给 AI 的任务跨多模块的架构调整比如把单体拆成微服务或者调整核心数据模型。需要业务判断的功能比如优惠券和订单状态的联动必须理解业务规则。安全敏感的权限逻辑比如登录鉴权、支付回调、数据脱敏。性能要求苛刻的核心链路AI 生成的代码往往“能过单测”但不一定满足极端请求量的性能要求。历史包袱重的老项目AI 读不到团队内部的“口头约定”容易写出和既有风格完全不同的代码。需要说明的是“不适合”不代表“完全不能做”而是说在这些场景里AI 只能当建议者不能当执行者。你可以用 AI 做方案草稿但最终实现和决策必须由人来把关。4.3 一个简单的任务分级模型维度低风险任务高风险任务边界输入输出明确依赖全局状态验证有自动化测试依赖人工回归影响面独立模块核心链路成本低高在实际项目里我更推荐给 AI 分配“低风险任务”把“高风险任务”留给有经验的工程师。这样既能享受效率提升又不会让 AI 成为生产事故的主要来源。5. 一套“用 AI 但不失控”的实践工作流既然已经明确了 AI 的边界接下来就是具体的工程实践。下面这套工作流可以在本地跑通不依赖任何特定厂商的云服务。它分为四步写规格、写测试、让 AI 生成实现、自动化验收。这套流程的核心原则是AI 只负责“实现层”规格与验收由人负责。这样无论 AI 生成的质量如何你都有一个可回滚、可验证、可审查的基线。5.1 第一步先写规格文件不要一上来就让 AI 写代码先写一个简洁的规格文件。这个文件不需要很长但必须包含功能范围、输入输出约定、异常处理和验收标准。# 文件路径specs/login-api.md # 登录接口规格 ## 功能范围 提供邮箱密码登录能力返回用户 token。 ## 输入 - email: 字符串符合邮箱格式 - password: 字符串长度 8-32 位 ## 输出成功 - code: 0 - token: 字符串 - user: 用户对象 ## 输出失败 - code: 1001参数不合法 - code: 1002邮箱或密码错误 ## 异常情况 - 邮箱格式非法不查询数据库直接返回 1001 - 用户不存在返回 1002 - 密码错误统一返回 1002避免用户枚举 ## 验收标准 1. pytest tests/test_login_api.py 全部通过 2. 不打印密码明文日志 3. 不返回密码字段把这份 Spec 发给 AI 时AI 的实现就有了约束。它不能只写一个“看似能跑”的函数还必须满足你定义的错误码和边界行为。5.2 第二步先写验收测试有了 Spec 之后先写测试而不是先写实现。这是传统 TDD 的思路但你依然可以用 AI 帮你生成测试代码。重点是测试必须能表达规格里定义的验收标准。# 文件路径tests/test_login_api.py import pytest def validate_email(email: str) - bool: return in email and . in email.split()[-1] def login(email: str, password: str): # 示例实现后续由 AI 填充 if not validate_email(email): return {code: 1001, message: invalid email} if len(password) 8 or len(password) 32: return {code: 1001, message: invalid password} # 模拟用户校验 if email testexample.com and password password123: return {code: 0, token: demo-token, user: {email: email}} return {code: 1002, message: invalid email or password} def test_invalid_email_format(): result login(not-an-email, password123) assert result[code] 1001 def test_invalid_password_length(): result login(testexample.com, short) assert result[code] 1001 def test_wrong_credentials(): result login(testexample.com, wrongpass123) assert result[code] 1002 def test_success_login(): result login(testexample.com, password123) assert result[code] 0 assert result[token] assert password not in result在这个文件里login()目前是示例实现你可以把这份代码和 Spec 一起交给 AI要求 AI “在不修改测试逻辑的前提下重写一个更合理的实现”。这样 AI 的任务边界被测试框住了它自由发挥的空间被大幅压缩。5.3 第三步给 AI 一个高质量提示词AI 编程的效果很大程度取决于提示词的质量。与其写“帮我实现登录接口”不如给出一份结构化的任务描述。下面这个提示词模板可以直接复用任务 实现一个邮箱密码登录接口。 约束 1. 请先阅读 specs/login-api.md 中的规格说明。 2. 实现代码必须通过 tests/test_login_api.py 中的所有测试。 3. 不需要修改测试文件。 4. 禁止在日志中打印密码。 5. 返回数据结构必须与规格中的输出约定保持一致。 输出要求 1. 先给出实现方案摘要不超过 200 字。 2. 再给出完整可运行的代码。 3. 最后列举你做出的关键假设。注意最后一条“列举关键假设”非常重要。它能把 AI 隐藏的判断暴露出来方便你在评审时发现偏差。比如 AI 可能会假设“用户数据从内存字典读取”你可以根据假设决定是否接入真实数据库。5.4 第四步用脚本做自动化验收在本地项目里可以写一个自动化验收脚本把测试、静态检查和敏感信息扫描合并成一次执行。这样 AI 生成的代码一旦不合格你不需要人工逐行排查。# 文件路径scripts/verify_ai_change.sh #!/usr/bin/env bash set -euo pipefail echo echo Step 1: run tests echo pytest tests/ -q echo echo Step 2: scan sensitive info echo if grep -RInE (password|secret|api[_-]?key)\s*[:]\s*[\][^\][\] --include*.py app/; then echo ERROR: potential hardcoded secret found exit 1 fi echo echo Step 3: check TODO/FIXME count echo count$(grep -RInE TODO|FIXME --include*.py app/ | wc -l | tr -d ) echo TODO/FIXME count: $count echo echo All checks passed. echo 运行方式很简单chmod x scripts/verify_ai_change.sh bash scripts/verify_ai_change.sh这段脚本做三件事跑全部测试、扫描硬编码敏感信息、统计 TODO/FIXME 数量。如果你的团队有更完善的门禁可以把 SonarQube、ESLint、shellcheck 等工具加进来。关键不是脚本本身而是你想通过脚本建立一条“AI 代码不能直接绕过验收”的规则。5.5 第五步利用版本控制实现快速回滚AI 生成的代码未必能一次通过验收。因此每一次 AI 修改都应该在独立的 Git 分支里进行方便对比和回滚。一个典型流程是# 在干净的主分支基础上创建任务分支 git checkout -b feature/ai-login-api # 执行自动化验收脚本 bash scripts/verify_ai_change.sh # 如果验收通过再人工审查差异 git diff main --stat # 如果验收失败放弃当前分支重新生成 git checkout main git branch -D feature/ai-login-api这个工作流的价值在于你不必在 AI 生成的错误代码上反复修修补补。发现方向不对直接丢弃分支重新生成即可。这比在原来的坏代码上“打补丁”效率高得多。6. 运行结果与效果验证以第 5 章的登录接口示例为例完整流程应该是先写好specs/login-api.md。先写好tests/test_login_api.py。把 Spec 和测试文件交给 AI让 AI 重写login()的实现。运行bash scripts/verify_ai_change.sh。如果 AI 的正确预期输出是 Step 1: run tests 4 passed in 0.12s Step 2: scan sensitive info Step 3: check TODO/FIXME count TODO/FIXME count: 0 All checks passed. 这里判断成功有两个标准所有测试通过。脚本没有在代码中扫描到硬编码密钥。如果测试失败第一步应该看失败的是哪条测试并对照 Spec 检查对应约束。不要直接让 AI 反复重试而要把失败的测试消息回传给 AI让它感知到具体失败点。比如当前实现未通过 test_invalid_password_length原因是密码长度校验和 Spec 不一致。请根据测试消息修复实现不要修改测试。这样把“失败的反馈”变成“新的输入”AI 修复的成功率会比直接说“还是不行”高很多。7. 常见问题与排查思路在实际使用 AI 编程工具的过程中开发者经常会遇到几个典型问题。下面用表格整理常见的现象、原因和排查方向。问题现象可能原因排查方式解决方案AI 生成的代码能运行但业务逻辑不对提示词没有给出业务边界和异常约定检查是否提供了 Spec 和测试基线先写验收测试再让 AI 实现AI 修改一个文件导致另一个文件报错上下文窗口没有覆盖跨模块调用关系查看错误日志定位调用链让 AI 先给出影响面分析再决定是否执行Agent 任务消耗 Credits 很快任务规模过大AI 反复试错查看任务日志统计失败尝试次数拆分小任务每步手动确认AI 生成的代码中有硬编码密钥提示词没有禁止敏感信息运行敏感信息扫描脚本把扫描加入自动化验收门禁测试通过但代码风格与组内规范不一致提示词没有指定规范检查代码风格差异在提示词中加入编码规范或使用现成规则集AI 不断重复同样的错误修复方式反馈信息不够具体检查回传的错误信息是否完整将完整错误堆栈和测试失败信息回传给 AI一个容易被忽略的点是AI 编程工具并不能理解“团队内部的上下文”。比如你们团队约定错误码 1002 统一表示“账号或密码错误”如果你不把这个约定写在 Spec 里AI 很可能生成一个完全不同的错误码体系。因此文档和规格在 AI 编程时代不是被淘汰了而是更重要了。8. 最佳实践与工程建议综合前面的分析这一章给出八条可以直接落到团队的工程建议。8.1 规格先行测试兜底无论你是用 Cursor、Copilot、通义灵码还是其他 AI 编程工具都应该在动手之前先写一个短规格文件。规格不一定要很长但必须有输入、输出、异常和验收标准。测试是规格的可执行版本两者配套使用才能有效约束 AI。8.2 一次只给 AI 一个小任务AI 在单任务上的表现通常优于多任务。因为任务越小上下文越容易覆盖AI 也越不会“自由发挥”。如果你有一个复杂需求先拆成多个可独立交付的小任务再逐个交给 AI。每个任务完成后运行一遍验证脚本。8.3 所有 AI 修改都进独立分支这是成本最低的保险措施。AI 的产出不稳定第一次生成可能方向正确但细节粗糙第二次生成可能彻底跑偏。如果没有分支隔离你只能在坏代码上不断修补有了分支隔离你可以随时丢弃重来。8.4 为 Agent 设置资源上限如果你使用的平台支持任务级资源控制尽量设置单次任务可消耗的 Credits 上限。这样即使 AI 在一个错误方向上反复尝试也不会把额度烧完。设置上限的意义是避免“沉没成本效应”影响你的决策。8.5 强制输出“关键假设”在提示词的最后要求 AI 列出它做出的关键假设。这一步看起来简单却能暴露大量问题。比如 AI 假设“用户表只有一个 email 字段”这在你没提到 username 字段时是合理的但如果你有多个登录标识那这个假设就需要人工干预。8.6 敏感信息必须扫描把敏感信息扫描加进 AI 代码的验收脚本里。重点检查硬编码密码、API Key、Token、私钥、数据库连接串。不要信任 AI 对“不会提交密钥”的承诺因为它的训练数据里见过太多错误示例。8.7 安全变更走最小权限原则如果 AI 生成的代码涉及权限、认证、支付、数据库操作不要直接在测试环境或开发环境之外使用。先把变更限制在最小权限范围内确认逻辑正确后再逐级放开。生产环境变更必须在窗口期执行并配备备份和回滚方案。8.8 记录 AI 任务的失败日志形成团队经验库当 AI 在某类任务上反复失败时不要把原因归结为“AI 不行”而要把失败模式记录下来。比如“AI 经常忽略列表空值”“AI 经常忘记关闭资源”。这些记录可以反过来指导提示词模板优化让团队的整体效率逐步提升。9. 总结与后续学习方向回到开头那个视频标题Im done coding with AI。真正该停止的不是使用 AI 编程工具而是“把 AI 当成全自动程序员”的幻觉。AI 可以帮你把代码写出来但它无法替你理解业务、无法替你承担验收责任、也无法替你在生产事故后复盘。这篇文章真正想传达的技术判断是AI 编程的可控性取决于你给它的约束是否清晰。规格文件、验收测试、自动化脚本、分支隔离这些传统软件工程手段在 AI 编程时代依然是最可靠的护栏。如果你想继续深入可以从这几个方向入手学习更多 Agent 类工具的任务编排能力但一定要先建立自己的验收门禁。研究 Spec-driven development 与测试驱动开发的结合方式。基于团队现有的代码规范打造适合自家项目的 AI 提示词模板库。关注 Coding Plan 与 credits 的计费模型建立 AI 成本预算。最后给你一个具体建议下一次让 AI 写代码之前先花十分钟写下三个内容——这个功能要解决什么问题、怎么样才算完成、哪些行为绝不允许。写完之后把这段话贴进提示词里再让 AI 动手。你会发现AI 写出来的代码从“能跑”到“能用”差的就是这十分钟。