当“Im done coding with AI”这类标题开始频繁出现在开发者社区时很多人的真实态度并不是“我再也不碰 AI”而是被 AI 编程工具“看起来很快、实际收尾很慢”的体验反复折磨之后决定重新审视自己的使用方式。早期的兴奋很容易理解把需求描述成自然语言AI 就能生成几百行代码补齐样板代码尤其迅速。但很快问题开始堆积AI 生成了不存在的 API改了一个函数导致三个模块同时报错没有人知道这段代码为什么这样写测试用例也一直缺位。于是出现了“vibe coding”和“spec coding”的讨论也出现了各类 coding plan 订阅和 credits 计费。这篇文章想和你一起整理一套可复现的 AI 辅助编程工作流。核心建议是不要“让 AI 写代码”而要“让 AI 按规格实现代码”。文章会从概念辨析、失败模式、最小案例、工程门禁、适用边界和排错链路几个方面展开最后给出一份可以贴在工位上的检查清单。1. 先看清 AI 编程热潮里的几个关键词vibe coding、coding agent 和 coding plan1.1 从“氛围编码”到“接管式编码”“vibe coding”指的是开发者把整体氛围、目标或一段模糊想法告诉 AI然后让 AI 连续生成大段代码人只是偶尔确认“看起来没问题”。这个词之所以流行是因为它精准描述了一种真实场景项目里很多代码并非逐行理解后写出来的而是“顺着 AI 的节奏滑过去”。这种方式在原型验证阶段很高效。比如临时写一个脚本把 CSV 文件读进来、过滤几行、输出统计结果AI 可以在几十秒内完成。对结果不负有长期维护责任时vibe coding 完全够用。问题出在把它当成生产环境的默认开发方式。当代码数量超过一定规模后项目会变成“AI 生成、无人负责”的状态。此时没有设计文档没有测试没有依赖版本记录甚至没人知道某个函数的预期行为是什么。开发者认为自己“做了很多”实际只是在 AI 生产的代码堆里做选择题。与之相对的是“spec coding”。这个概念的核心是先写规格spec再让 AI 实现。规格不是一句话需求而是包含输入、输出、边界条件、异常处理、依赖约束和验收标准的描述。把规格写清楚后AI 生成代码的稳定性会明显提升因为它的行为被限制在一个可验证的范围内。1.2 AI coding 工具的三种形态目前常见的 AI 编码工具大致有三种形态理解它们之间的差别能避免选错使用方式。形态典型交互方式能力边界适合场景AI 补全 / 聊天助手在编辑器里补全代码或通过对话框生成片段单点生成上下文有限写函数、写测试、翻译语言、解释代码AI 编码代理coding agent接管命令行或编辑器自动修改多个文件并运行命令可以完成跨文件改动但容易误改机械重构、批量替换、添加样板代码coding plan / credits 服务云端模型能力以订阅额度方式开放按 credits 计费取决于绑定的模型和上下文长度团队统一接入、企业级用量管理、成本控制“coding plan”是很多云平台推出的面向编码场景的服务计划通常用 credits 来表示可用额度。比如一次代码生成、一次代码解释、一轮多文件修改都可能消耗不同数量的 credits。对个人开发者来说关注 credits 的消耗速度很有必要因为它会直接影响你的使用策略是把全部任务交给 AI还是只把高价值、低风险的子任务交给 AI。这里要特别注意AI 编程工具不是“越贵越强”或“额度越多越好”。真正的成本不是订阅费而是代码进入生产后产生的可维护成本。2. 为什么有人“受够了”AI 编程四个典型失控场景2.1 生成代码不断引用不存在的 API项目被“幻觉”拖垮幻觉不是聊天模型独有的问题在代码生成中同样高频出现。模型会非常流畅地写出一段调用但对应的函数、类或方法在真实版本中并不存在。看一个典型例子。假设你想让 AI 用 pandas 把某个字段做归一化处理它生成了一段类似这样的代码import pandas as pd df pd.read_csv(data.csv) df[score] df[score].map_values(lambda x: (x - x.min()) / (x.max() - x.min()))这段代码看起来合理但DataFrame.map_values并不是 pandas 的公开 API。运行时会得到AttributeError: Series object has no attribute map_values正确写法通常是apply配合 lambda或者直接用向量化运算df[score] (df[score] - df[score].min()) / (df[score].max() - df[score].min())这类问题的隐蔽之处在于报错只发生在运行时而不是生成时。如果项目没有足够的测试覆盖这类“假 API”会像地雷一样埋在业务代码里。排查时开发者不仅要找到报错位置还要判断 AI 到底想表达什么逻辑再决定是换成真实 API 还是自己重写双倍时间消耗就在这里出现。2.2 没有测试保护代码能跑但没人敢改AI 生成代码时如果你没有在提示词中明确要求“同时生成测试”它往往只输出功能实现。进入项目后这段代码天然没有测试保护。后续业务需求一变开发者动这段代码时只能依靠“肉眼验证”和“小心试探”。测试缺失的最大风险不是“现在跑不了”而是“将来无法安全演进”。当项目里有大量 AI 生成的代码且相互之间存在隐式依赖时任何局部修改都可能产生连锁反应。由于没有自动化测试快速反馈开发者只能靠启动项目、手动点击页面来验证效率很低而且容易漏掉边界分支。推荐做法是在提示词里把“必须包含单测”写死并且在代码评审时把“有没有测试”作为第一道闸门。如果 AI 生成的功能无法写出测试通常说明这段代码的职责不清、耦合过重应该先调整设计而不是硬接进项目。2.3 过度依赖上下文改动像“拆盲盒”编码代理类工具可以跨文件修改但它的“全项目上下文”并不等于“理解整个项目”。它可能只读取了部分文件或者读取了过长的上下文后在深层逻辑上产生遗漏。一个常见现象是你让 AI 修改某个接口的入参它除了修改接口定义和调用方还把存储层的字段名也“顺手”改了因为你之前提到过某个相似字段。这种无意识的连带修改会让 code review 的 diff 变得非常难读甚至掩盖真正的变更意图。要控制这类风险使用 AI 编码代理时有一条重要纪律每次任务只给它一个明确的修改边界在提示词里写清楚“只允许修改以下三个文件其余位置不得改动”。还要在任务执行后检查一下总的 diff 行数。如果一次“小改动”产生了上百行 diff大概率是 AI 把上下文理解宽了。2.4 算成本账验收 AI 代码可能比手写更贵很多人忽略的一点是AI 生成代码只是“生产环节”真正消耗时间的是理解、验证、修复、review 和后续维护。如果一个函数手写需要二十分钟AI 生成只要三十秒但你需要花四十分钟去验证边界条件、补测试、修复幻觉 API 并把代码风格调整成团队规范那这次 AI 使用就是亏的。更现实的情况是开发者觉得“自己不用写了”就会降低对代码细节的敏感度。等到代码评审时才发现一大堆命名混乱、异常处理缺失、日志没有上下文的问题评审成本反而比手写更高。因此比较 AI 编码是否值得不能用生成耗时对比手写耗时而要用“从需求到可合入的总工时”来对比。3. 建立可控的 AI 辅助编程工作流从“让 AI 写”到“让 AI 按规格实现”3.1 先写规格再写代码一套能长期使用的 AI 编程工作流核心不是选哪个工具而是把需求描述得足够精确。这里推荐一个“需求描述四要素”模板要素要写清楚的内容输入函数参数、文件格式、数据结构、来源输出返回值类型、文件写出格式、打印内容边界条件空值、重复值、超长文本、文件不存在、权限不足约束依赖版本、禁止使用的库、代码风格、必须包含测试实际使用时可以把模板直接放到提示词里。比如请实现一个 Python 函数 read_user_scores(file_path: str) - list[dict]。 输入CSV 文件路径CSV 包含 headeruser_id, score, created_at。 输出list[dict]每个 dict 包含 user_id 和 score 两个字score 转为 float。 边界条件 - 文件不存在时抛出 FileNotFoundError错误信息包含 file_path。 - score 为空或非数值字符时跳过该行并记录 warning不中断处理。 约束 - 只使用标准库 csv 和 logging不要引入第三方依赖。 - 函数上方提供 docstring包含参数、返回值和异常说明。 - 同时生成 pytest 测试覆盖正常文件、缺失文件和 score 异常行。这段描述比“写个读取 CSV 的函数”要清晰得多。AI 收到的不是模糊意图而是可验证的规格。生成结果是否符合预期也能通过测试用例来确认。3.2 给 AI 提供最小但完整的上下文如果任务涉及已有项目不能只贴一个函数让 AI 补全也不能把整个项目丢给它。比较好的方式是提供“最小上下文包”项目使用的语言和框架版本。相关目录结构只列出与任务有关的文件。需要修改的文件名和关键函数签名。已有的错误日志或测试失败信息。期望的输出样例。例如项目是 Python 3.11 Flask 2.3使用 SQLAlchemy 2.0。 需要修改 app/service/order_service.py 中的 create_order 函数。 当前失败测试 tests/test_order_service.py::test_create_order_with_invalid_product 错误sqlalchemy.exc.NoReferenceError 期望调用 products_table 的 id 作为外键但当前代码使用了 product_code。 请阅读后给出修复方案并同时更新相关单元测试。这样 AI 的任务范围就非常收敛。它不需要猜测“项目是不是 Flask”“数据库是 MySQL 还是 SQLite”也不需要从几百个文件里推断业务规则。3.3 小步生成强制验证一个 Python 最小案例下面用一个最小案例演示完整链路。目标是实现一个工具函数统计一段文本里每个单词出现的次数忽略大小写和标点。先按规格写出提示词实现 count_words(text: str) - dict[str, int]。 输入一段英文文本。 输出单词到出现次数的映射key 使用小写value 为 int。 要求 - 按非字母字符切分连续字母作为一个单词。 - 空文本返回空 dict。 - 不引入第三方库。 - 生成 pytest 测试。AI 可能给出类似这样的实现import re from collections import Counter def count_words(text: str) - dict[str, int]: if not text: return {} words re.findall(r[A-Za-z], text.lower()) return dict(Counter(words))如果只看代码它看起来没问题。但“看起来没问题”不能作为验收标准必须运行测试。测试文件可以这样写from count_words import count_words def test_count_basic_words(): assert count_words(Hello hello world) {hello: 2, world: 1} def test_ignore_punctuation(): assert count_words(Hi, there! Hi...) {hi: 2, there: 1} def test_empty_text(): assert count_words() {}执行验证python -m pytest test_count_words.py -q如果测试通过说明基本行为符合预期。接下来还要思考边界its这种包含撇号的单词应不应该保留当前正则会匹配its可能不符合“连续字母”的规格。这种规格歧义就是 review 阶段需要人工判断的内容。这个例子的重点不是代码本身而是流程规格明确 - 生成代码 - 测试验证 - 边界讨论。每一步都有检查点而不是直接把 AI 的输出合入主干。3.4 让 AI 做代码审查而不是背锅AI 除了生成代码还可以作为代码审查的辅助工具。推荐三种用法让 AI 解释代码把一段复杂的 AI 生成代码粘贴给另一个模型要求它用自然语言解释每一段逻辑生成注释。这能帮助 reviewer 快速理解。让 AI 生成测试基于已有函数签名和业务描述要求 AI 列出需要覆盖的测试用例再实现为 pytest 或 JUnit。让 AI 找 bug把报错堆栈和相关代码一起贴给 AI要求它给出“可能原因”和“验证方法”而不是直接给出“最终修复”。这里的关键是不要问“这段代码为什么有问题帮我改正确”而要问“这段代码在什么输入下会出错用什么测试可以复现”。前者容易让 AI 直接输出一个未经思考的新版本后者能让你保留判断权。4. 用工程门禁兜底测试、静态检查和 CI 配置4.1 为什么 AI 代码更需要门禁人工手写代码出现错误时作者通常知道错误出现在什么语义背景下。AI 生成代码则不然它可能在不同语义片段之间拼接出“语法正确但逻辑错误”的结果。因此项目里如果存在大量 AI 生成代码自动化门禁就不能只是“能编译”而要尽可能早地拦截格式、类型、常见错误、测试覆盖、依赖漏洞。推荐在项目里加入四条基本门禁格式化门禁统一代码风格避免 AI 生成的代码与团队风格不一致。静态检查门禁发现未使用变量、未处理异常、可疑逻辑等问题。类型检查门禁适合 Python、TypeScript 等动态类型语言能拦截一部分接口变更问题。测试门禁最小要求是核心逻辑至少有单测关键路径不能裸奔。4.2 一个最小 CI 配置示例以 Python 项目为例假设使用 GitLab CI一个包含格式、静态检查、类型检查和测试的最小.gitlab-ci.yml可以这样写stages: - lint - test lint: stage: lint image: python:3.11-slim before_script: - pip install ruff mypy script: - ruff check . - mypy app test: stage: test image: python:3.11-slim before_script: - pip install -r requirements.txt - pip install pytest script: - pytest tests -q如果项目使用 pre-commit可以在提交前先跑一遍快速检查pip install pre-commit cat .pre-commit-config.yaml EOF repos: - repo: https://github.com/astral-sh/ruff-pre-commit rev: v0.6.9 hooks: - id: ruff args: [--fix] - repo: https://github.com/pre-commit/mirrors-mypy rev: v1.11.2 hooks: - id: mypy EOF pre-commit install这段配置里的args: [--fix]表示让 ruff 在本地先尝试自动修复格式问题。mypy 的版本要和项目使用的 Python 版本匹配否则会出现误报。4.3 参数选择与效果对照门禁不是越严越好参数配置要根据团队规模和维护成本调整。下面是一张常见参数调整对照表。配置项推荐值调严的影响调松的影响ruff 选择规则E,F,I,UP,B能发现更多未使用导入和 bug 模式但初期报错多容易放过低级错误mypy 检查模式--strict或按模块开启对类型一致性有强约束开发成本高能发现关键错误但漏检多pytest 最小通过率100% 或核心模块强制覆盖提高回归安全但测试维护成本高出现回归时更容易漏CI 超时时间10-15 分钟减少排队等待但可能截断大型测试集等更久开发节奏变慢这些参数没有绝对正确答案但有一条原则生产项目里的 AI 代码越密集门禁的严格程度越应该往高处走。4.4 门禁阶段最常见的四类问题问题现象常见原因处理建议ruff 报大量格式错误AI 生成的代码风格不一致缩进和引号混乱让 ruff --fix 自动修复再提交mypy 报“模块没有类型声明”三方库缺少类型 stub在配置中加入ignore_missing_imports True或安装对应类型包测试运行很慢AI 测试用例过多且依赖外部服务将单元测试与集成测试分开外部服务使用 mockCI 里依赖安装失败requirements.txt 由 AI 生成版本号拼写错误用pip freeze生成的版本锁定文件替换手工版本5. 判断边界什么时候该与 AI 编码保持距离5.1 学习阶段AI 太体贴反而有害如果你是刚开始学编程不建议把 AI 作为“答案生成器”。学习编程的关键是建立“预测代码行为”的能力。AI 直接给出正确答案时学习者会跳过“为什么”的思考环节。正确的做法是先用编辑器手写遇到编译错误再问 AI 解释错误写完功能后再让 AI 做 review对比自己的实现和 AI 建议之间的差别。这样 AI 就从“答案机”变成了“陪练”。5.2 生产关键路径需要人工设计和评审涉及支付、权限、数据一致性、高并发、加密等关键逻辑时AI 只能作为辅助写代码和执行审查的工具不能直接主导设计。因为这些场景的错误成本很高而且业务规则通常不在 AI 的上下文里。实际操作中可以先把接口设计、数据库表结构、状态机流转画清楚再让 AI 根据设计生成实现。关键是设计文档必须由人完成并经过评审。5.3 高风险合规场景来源追踪和数据隐私在涉及用户隐私数据、合规审计、多租户数据隔离的项目里使用 AI 编码工具前要确认代码是否会传到云端模型服务、日志中是否包含敏感信息、生成的代码能否追溯到具体来源。很多企业会选择私有化部署模型或关闭代码上传功能这时 coding plan 和 credits 的消费模式也会随之改变。这类场景的原则是不是你输出了正确代码就一定能合入数据流向和合规要求同样属于验收条件。5.4 可以放心把代码交给 AI 的场景有些任务交给 AI 很划算因为错误影响小、验证成本低样板代码配置类、DTO、简单的 CRUD 接口。机械重构重命名变量、拆分长函数、生成 getter/setter。测试骨架根据函数签名生成参数化和边界测试用例。文档生成把代码流程整理为 Markdown 文档。技术调研让 AI 列出某类框架的选型对比再由人确认细节。5.5 AI 编码使用边界决策表场景是否推荐 AI使用方式个人原型验证推荐vibe coding 快速生成不做长期维护团队业务功能开发有条件推荐先写规格小步生成强制测试和 review学习编程入门不推荐作为答案生成器先手写再用 AI 解释和 review支付/权限/安全相关慎重人工设计AI 只做实现辅助和代码评审合规审计项目需要额外评估确认数据流向必要时私有化部署遗留系统维护推荐辅助用 AI 解释历史代码、生成调用关系、补测试6. AI 生成代码出问题时的排错链路6.1 现象一Python 项目导入第三方库失败AI 生成代码时经常会生成使用某个库的代码但项目里并没有安装对应依赖。现象ModuleNotFoundError: No module named openpyxl排查顺序先确认当前虚拟环境是否激活运行which python看解释器路径。再查看项目依赖清单pip show openpyxl如果没有输出说明未安装。确认需求文件里有没有这一项grep openpyxl requirements.txt。如果确实是 AI 引入了新依赖需要判断这个库是否必要。如果只是为了读取 Excel也可以用标准库csv或项目已有的pandas能力完成。决定安装后固定版本号pip install openpyxl3.1.5再写入requirements.txt。这里特别容易踩的坑是直接运行pip install openpyxl后新版本引入的 API 与 AI 生成的代码不一致。建议安装后马上运行测试而不是直接启动业务。6.2 现象二Maven 依赖版本不匹配AI 生成 Java 代码时常见的错误是在pom.xml里引入一个依赖但版本过旧或不存在。dependency groupIdcom.example/groupId artifactIdfake-utils/artifactId version1.0.0/version /dependency运行mvn compile时会报Could not find artifact com.example:fake-utils:jar:1.0.0 in central排查链路检查坐标是否正确在 Maven Central 上搜索 groupId 和 artifactId。检查版本是否存在不要盲目相信 AI 给出的版本号。检查本地仓库缓存删除本地仓库中的错误目录后重新拉取排除缓存污染。如果是企业内部依赖需要确认是否已发布到私有 nexus 仓库。这类问题看起来很小但在 AI 生成代码场景里非常高频。原因是模型训练数据中的版本信息可能滞后或者它直接把记忆中的“相似依赖”拼了过去。6.3 通用排错优先级遇到 AI 生成代码报错时不要第一时间把错误贴回去让 AI 改这会陷入“改错 - 再错 - 再改”的循环。推荐按以下顺序排查检查输入数据是否符合预期文件路径、参数格式、环境变量。检查代码中的引用是否存在类名、函数名、模块路径、依赖版本。检查上下文是否完整AI 是否修改了不该碰的文件。检查测试是否覆盖该路径如果有测试失败先看失败的断言。检查日志和异常堆栈不要只看最后一行要看完整调用链。最后才考虑把报错给 AI并附上相关代码和规格描述。6.4 如何把错误反馈给 AI让下一轮更准向 AI 反馈错误时至少包含三块信息目标、现状、证据。目标create_order 函数在库存不足时应返回 HTTP 400。 现状当前代码在库存不足时仍然创建订单并返回 200。 证据 - pytest 失败输出tests/test_order_service.py::test_create_order_no_stock - 断言期望 status_code 400实际 status_code 200 - 相关代码片段如下这样 AI 看到的是可复现的问题而不是模糊的“这不对”。减少 AI 猜测空间是提高下一轮生成质量最有效的方法。7. 可复用的 AI 编程协作清单与下一步练习7.1 使用前、使用中、使用后的检查清单下面的清单可以根据团队情况直接引用粘贴到项目 README 或开发规范文档里。阶段检查项是否通过使用前需求是否包含输入、输出、边界和约束是/否使用前是否确认 AI 只允许修改指定文件是/否使用前是否确认外部依赖版本可查是/否使用中生成的代码是否一次性输出大段而缺少解释是/否使用中是否在关键逻辑上要求 AI 给出验证步骤是/否使用后是否有自动化测试覆盖核心分支是/否使用后是否运行过格式、静态检查和类型检查是/否使用后是否人工 review 过 diff理解每处改动是/否使用后是否确认没有敏感数据被上传到外部服务是/否入库前是否有回滚方案或版本记录是/否这张清单最关键的一点是AI 生成代码不能绕过“人工理解”这一关。你可以让 AI 提速但不能让 AI 替你承担设计责任。7.2 给刚接触 AI 编程的开发者几条进阶建议第一条建议是“先会用再依赖”。先熟练掌握核心语言和框架再引入 AI 工具。这样 AI 出错时你能快速识别。第二条建议是“从补全开始”。不要一开始就使用编码代理自动修改整个项目先用编辑器里的补全功能写函数体逐步建立对 AI 输出质量的判断。第三条建议是“刻意练习规格化描述”。把真实需求写成规格再让 AI 实现。坚持两周你会发现 AI 输出的一次通过率明显提升评审成本下降。第四条建议是“保留关键时刻的手写能力”。遇到难以理解的问题时关掉 AI 补全完全手写一遍。这个过程不是为了证明“自己能写”而是为了确保你对系统行为有真实理解。7.3 AI 是协作者但项目负责人仍然是你回到“Im done coding with AI”这个标题。真正让人想放弃的不是 AI 本身而是失控的协作方式。当 AI 被当作一台“自动提交代码的机器”时项目的复杂度会迅速超过团队的维护能力。当 AI 被当作一个“能加速实现的协作者”并且有规格、测试、评审等约束时它的价值才能真正体现出来。下一步你可以做三件小事挑一个近期需要实现的小功能按规格模板重写需求并让 AI 实现为现有项目补上最少一道 CI 门禁把今天提到的排查清单贴在常见故障文档里。这样你就不再是被 AI 带着走的角色而是真正掌控项目节奏的开发者。