最近在技术社区看到一条标题为“Im done coding with AI”的视频讨论度很高。开发者在视频里回顾了自己从最初使用 AI 编程工具完成功能到后期陷入“生成—报错—再生成”循环的过程最终选择退回传统手写代码。这个观点不见得适合所有人但它把 AI 编程从“输入几句话就能出功能”的兴奋感重新拉回到工程现实面前AI 生成的代码到底能不能被维护、被审计、被安全地部署到生产环境这篇文章想借这个“退坑”现象拆解 AI 编程在日常开发中的真实问题。我会先把当前 AI 编码工具常见的工作方式、失控点讲清楚再通过一个模拟的批量任务处理脚本演示 AI 生成代码为什么会在线上暴雷以及人类工程师应该如何一步步重构它。最后给出如果还想继续使用 AI coding 工具团队和个人应该遵守的工程底线。内容比较适合正在使用 Cursor、GitHub Copilot、通义灵码、CodeGeeX 等 AI 编程助手的开发者也适合团队里已经出现“AI 写代码测试靠感觉”的项目负责人阅读。读完你至少能回答三个问题AI 生成的代码最容易坏在哪里为什么越修越乱如何把工具回归到“辅助”而不是“主导”的位置。1. AI Coding 热潮与“退坑潮”为什么会同时出现1.1 从自动补全到 vibe codingAI 编程工具刚兴起时大多数人接触的是“代码补全”开发者写一个函数名AI 根据上下文把函数体补齐。这种模式的风险可控因为补全范围通常只覆盖几行代码而且真正理解需求的人仍然是开发工程师自己。后来事情发生了变化。自然语言描述需求、AI 自动生成整块代码甚至整个模块的能力越来越强社区把这种编码方式称为 vibe coding。这个词翻译过来可以理解为“凭感觉编程”开发者把需求直接扔给 AIAI 生成代码开发者运行一下感觉“差不多能用”就算完成。整个过程中开发者没有逐行阅读代码也没有思考边界条件和异常路径。再往后是 AI Agent 与 coding plan 这类概念流行起来。工具不再满足于补全函数而是能主动拆解任务、修改多个文件、执行命令甚至调用外部测试工具。很多平台把调用次数折算成 credits 或额度用户购买一个月度/项目制 coding plan就能持续使用这种“虚拟开发助手”。这确实提升了写原型、做实验的效率。但问题也出现在这里当 AI 的修改范围从一个函数扩大到整个代码库开发者实际上失去了对每一次改动的直接感知。代码能不能跑有时候可以通过运行看出来但代码是否安全、是否幂等、是否在极端输入下仍然可控运行一两次根本验证不出来。1.2 “Im done coding with AI”在抵制什么那类标题为“Im done coding with AI”的退坑内容本质上不是在否定 AI 能生成代码而是在表达一种工程上的挫败感用 AI 写 demo半小时交付很爽把 demo 变成生产功能开始补异常、加日志、处理超时发现 AI 不理解整个系统的约束反复生成不兼容代码让 AI 继续修 bug结果它为了修复一个问题引入了两个新问题最后花掉的时间比自己写还长且代码质量不可控。这种“退坑”并不是打脸而是把 AI 编码从演示场景迁移到生产场景之后必然会遇到的阵痛。要理解为什么我们得先看 AI 编码工具在实际工程中的工作方式和失控点。2. 当前 AI 编码工具的工作方式与失控点2.1 工具从“补全”走向“执行”风险也在升级如果把当前主流的 AI 编码工具按能力分层大致可以分成四类能力定位典型工作方式开发者的控制程度代码补全根据当前文件上下文补全函数体、参数、注释较高改动范围小对话式代码生成在聊天窗口描述需求AI 返回一段完整代码中需要人工粘贴项目内代码编辑AI 能读取工程目录、修改文件、创建新文件中低改动多但逐条可见Agent 式任务执行AI 自己列步骤、执行命令、跑测试、修改多文件低需要最终审查工具越接近右侧用户获得的“便利感”越强但工程风险也越高。因为 Agent 类工具会主动跨文件修改而它的决策依据往往是你提供的一段自然语言描述再加上它对代码库当前的模糊理解。如果项目本身结构复杂、约束分散在不同模块中AI 很容易改坏一个表面无关的地方。一个很典型的例子是依赖升级。AI Agent 在准备升级某个第三方库时会顺手改动多处调用代码但它通常不会完整阅读这个库的历史迁移文档也不会掌握你自己的业务对旧行为的隐性依赖。因此升级结束后单元测试可能仍然通过但生产环境的某些数据路径已经悄悄发生了变化。2.2 AI 代码为什么容易“越修越乱”很多开发者放弃 AI 编程的直接诱因不是第一次生成失败而是后续修复过程中上下文逐步失控。我给这种模式起了个名字叫“上下文雪崩”。假设你在做一个订单模块。第一轮 AI 生成的代码里没有考虑库存不足以太频繁的场景你告诉它“增加库存校验”。AI 在订单创建函数里加了查询库存的逻辑但它没有意识到这个函数有事务边界跨模块查询引入了新的连接占用和锁等待。接下来你又让它修复锁等待AI 在代码外面套了一个超时参数影响面变大但问题没有根治。反复几轮之后一段原本 30 行的简单函数变成 120 行注释和各种兼容逻辑堆叠在一起没有一个人能完整解释每行代码存在的理由。这种现象的根本原因在于AI 对上下文的理解是概率性的不是结构性的。它能记住你最近一两轮对话里的要求但它很难同时维护“数据库连接生命周期、事务边界、幂等性、失败重试策略、日志脱敏、权限校验、上游接口超时、下游接口兼容性”这些在真实项目中必须同时成立的约束。开发者如果从一开始就没有建立验收基线就会陷入无休止的局部修复循环。3. 核心问题拆解看起来正确本质上脆弱3.1 幻觉接口生成一段“看起来能用”的代码大模型生成代码的方式本质上是根据训练数据预测最可能的 token 序列。这意味着它优先保证的是“看起来像一段正确代码”而不是“真的能被当前环境编译/解释执行”。当模型遇到训练数据中没有覆盖的新 API 或新参数时它可能一本正经地编造出不存在的方法、参数或类名。一个常见的场景是调用 SDK。假设业务需要用某个内部或第三方 SDK 获取任务信息你让 AI 生成调用代码。AI 很可能输出类似下面的写法def fetch_task(task_id: int): # 注意这里 task_client.get_task 可能根本没有 retries 参数 # 这是 AI 基于常见调用习惯“脑补”出来的参数 return task_client.get_task(task_idtask_id, retries3, timeout5)如果 SDK 文档里确实没有 retries 参数这段代码在类型检查比较严格的环境会直接报错即使不报错AI 生成的 timeout 单位可能是秒而 SDK 实际要求毫秒运行后就会出现“为什么总是超时”的诡异问题。这也是为什么任何 AI 生成的 API 调用代码都必须经过官方文档校验。不要因为代码看起来结构完整就信任它编译型语言还能帮你拦截一部分问题解释型语言往往要跑到运行时才暴露。3.2 错误处理被吞掉线上静默死亡AI 生成代码时有一个非常让人头疼的倾向为了“不打断主流程”它会生成空 except 或只打印日志的异常处理。这在 demo 阶段似乎没什么影响程序没有崩溃界面没有报错开发者会以为一切正常。到了生产环境这种写法会掩盖大量真实故障。下面这段是 AI 很容易生成的反面例子try: send_notification(task[payload]) except Exception: # AI 总觉得不能让任务挂掉所以选择吞掉异常 pass看起来“稳如泰山”实际上是一条静默死亡通道。当通知服务因为网络波动、认证失败或消息体格式问题抛异常时程序不会崩溃但任务也不会进入重试队列。数据停留在数据库里状态永远是 pending但没有任何日志告诉你它为什么没有继续处理。等到用户反馈“我为什么一直没收到通知”你才需要把日志、数据库状态、上游服务监控串起来慢慢排查。正确的异常处理原则很简单要么把异常明确抛给上层决策要么在捕获后执行补偿逻辑并记录结构化日志。“记录一行日志然后继续”在某些场景确实够用但必须具备完整的上下文信息否则就是给未来的自己埋雷。3.3 测试只证明“AI 懂自己生成的代码”让 AI 帮自己写单元测试是很多开发者的常规操作但这里有一个很容易被忽略的陷阱AI 生成的测试往往会参考被测试函数的实现内容而不是业务需求。如果被测试函数本身有 bug测试却会成立因为测试断言的正是这个不正确行为。比如你让 AI 实现一个“计算订单总金额”的函数要求满 100 减 20。AI 实现成了满 100 减 5然后它又根据这个实现生成测试断言订单金额为 195。测试通过但业务需求已经被悄悄改写了。如果开发者在 review 时不看测试背后的业务规则这个问题就会一路流到生产。这也是为什么工程上我一直强调AI 生成的测试可以保留但必须由人来补充“行为级”测试用例。行为级测试不关心内部实现只关心给定输入和业务规则后输出是否符合预期比如满 99 是否不减、满 100 是否减 20、满 200 满减是否叠加等边界情况。4. 从“能跑”到“事故”完整代码复盘下面这个案例可以视为 AI 开发时常见问题的浓缩版。需求非常简单写一个后台任务 Worker定期扫描数据库里状态为 pending 的任务调用通知服务发送消息然后更新任务状态。我们先用“让 AI 写第一版”的思路生成一份代码再观察它为什么会在生产环境中出问题。4.1 数据表结构为了方便在线演示我用 SQLite 存储任务数据。真实项目中这张表通常是订单、消息或异步任务表。建表语句如下CREATE TABLE tasks ( id INTEGER PRIMARY KEY AUTOINCREMENT, owner TEXT NOT NULL, payload TEXT NOT NULL, status TEXT NOT NULL DEFAULT pending, created_at TEXT NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at TEXT );owner 表示该任务归属哪个用户或系统模块payload 存任务内容status 用来标记任务当前状态。4.2 AI 初版表面完整深坑遍地以下是综合了多段 AI 生成结果的“初版代码”。代码可以运行但隐藏了很多问题# 文件路径worker_ai_initial.py import sqlite3 import time import requests DB_PATH tasks.db def fetch_pending_tasks(): conn sqlite3.connect(DB_PATH) cur conn.cursor() # 问题 1使用 f-string 拼接 SQL cur.execute(fSELECT id, payload FROM tasks WHERE status pending) rows cur.fetchall() conn.close() return rows def send_notification(payload): # 问题 2没有指定 timeout依赖上游默认超时 resp requests.post(http://notify.internal/api/send, jsonpayload) return resp def process_once(): rows fetch_pending_tasks() for task_id, payload_text in rows: payload eval(payload_text) # 问题 3raw 字符串用 eval 转成对象 try: resp send_notification(payload) if resp.status_code ! 200: print(通知失败等待下次扫描) continue # 问题 4成功之后没有更新任务状态 except Exception: # 问题 5空 except吞掉所有异常 pass while True: # 问题 6死循环扫描没有限流、没有退避、没有退出条件 process_once() time.sleep(1)这段代码的问题可以逐条拆解第一f-string 拼接 SQL。这段代码因为查询条件里没有外部参数所以直接执行不会出大问题但它建立了一种错误的示范。一旦后来有人把查询条件改成cur.execute(fSELECT id, payload FROM tasks WHERE owner {owner})owner 来自用户输入SQL 注入风险就出现了。AI 初版往往会写出这种风格因为它只关心“能不能查到数据”完全不关心查询条件可控性。第二requests.post 没有设置 timeout。如果通知服务响应很慢或连接被卡住那么这个 Worker 线程会一直挂在那里。单线程程序会卡住整个扫描循环多线程版本则会导致线程不断堆积最终把服务器连接池耗尽。第三用 eval 解析 payload。数据库里存储的 payload 如果是 JSON 字符串正确做法是json.loads(payload_text)。eval 会把任意字符串当作 Python 代码执行如果 payload 被攻击者控制后果等同于远程代码执行。这段代码恰好是 AI 根据“把字符串变成字典”这个常见需求生成出来的危险写法。第四成功之后不更新状态。任务发送成功之后状态仍然是 pending下一轮循环又会再次扫描到这条消息并重复通知。在真实场景里用户可能收到几十条相同通知。第五空 except 吞掉异常。一旦通知服务不可用程序不会报错任务也不会进入失败重试队列。所有任务卡在 pending 状态数据库在增长但系统外表看起来毫无波澜。第六while True 无限循环。这种写法作为本地脚本或许可以但作为后台任务需要由进程管理器或分布式调度平台来管理。直接在业务代码里写死循环既不方便优雅退出也无法感知任务积压情况。4.3 事故复盘为什么线上会“安静地崩溃”把这段代码部署到生产几小时后就会出现典型事故从监控面板看Worker 进程 CPU 使用率不高内存也在正常范围日志输出为零。但数据库里 pending 状态的任务越来越多用户反馈收不到任何通知。原因并不复杂通知服务在凌晨做了一次升级短暂返回 500请求异常被空 except 吞掉某些任务被重复处理用户收到重复但零散的通知没有日志没有监控事件所有异常都消失在了代码的静默分支里任务状态一直不更新消息积压问题被“看起来正常的进程”掩盖。如果开发者没有对 AI 生成的代码做代码审查直接部署那么凌晨处理这个问题的唯一方式就是通过数据库手动修改状态和手动触发通知。这显然不是理想状态。4.4 修复版让工程约束重新回到代码里先声明一点这个修复版本面向的是“中小项目的一次性 Worker”重点在于演示异常处理、超时控制、状态更新和安全解析。真实生产项目需要结合你团队的任务队列、消息中间件和进程管理方式二次调整。下面是重构后的核心代码# 文件路径worker_refactored.py import json import logging import sqlite3 import time from datetime import datetime, timezone import requests DB_PATH tasks.db NOTIFY_URL http://notify.internal/api/send logging.basicConfig( levellogging.INFO, format%(asctime)s %(levelname)s %(name)s %(message)s, ) logger logging.getLogger(task_worker) BATCH_SIZE 50 def get_connection(): conn sqlite3.connect(DB_PATH) conn.row_factory sqlite3.Row conn.execute(PRAGMA journal_modeWAL) return conn def claim_task(conn, task_id: int) - bool: 将 pending 状态改为 processing。 只有在更新前任务仍处于 pending 时才会成功避免多个 Worker 重复消费。 cur conn.execute( UPDATE tasks SET status processing, updated_at ? WHERE id ? AND status pending , (datetime.now(timezone.utc).isoformat(), task_id), ) conn.commit() return cur.rowcount 1 def mark_task_done(conn, task_id: int) - None: conn.execute( UPDATE tasks SET status done, updated_at ? WHERE id ? , (datetime.now(timezone.utc).isoformat(), task_id), ) conn.commit() def mark_task_failed(conn, task_id: int, reason: str) - None: conn.execute( UPDATE tasks SET status failed, updated_at ?, payload payload || ? WHERE id ? , (, task_id), ) # 简化演示失败原因单独记日志 logger.error(task %s failed, reason: %s, task_id, reason) conn.commit() def send_notification(payload: dict) - None: # 设置连接超时 3 秒读超时 10 秒 resp requests.post(NOTIFY_URL, jsonpayload, timeout(3, 10)) resp.raise_for_status() def run_once() - int: processed 0 with get_connection() as conn: rows conn.execute( SELECT id, payload FROM tasks WHERE status pending ORDER BY id LIMIT ? , (BATCH_SIZE,), ).fetchall() for row in rows: task_id row[id] if not claim_task(conn, task_id): # 被其他 Worker 抢占了 continue try: payload json.loads(row[payload]) send_notification(payload) mark_task_done(conn, task_id) processed 1 except json.JSONDecodeError: mark_task_failed(conn, task_id, invalid json payload) except requests.RequestException as exc: mark_task_failed(conn, task_id, str(exc)) except Exception as exc: # 兜底异常但保留日志绝不静默 logger.exception(unexpected error for task %s, task_id) mark_task_failed(conn, task_id, funexpected: {exc}) return processed if __name__ __main__: while True: try: count run_once() if count 0: time.sleep(5) except KeyboardInterrupt: logger.info(worker stopped by user) break修复版和 AI 初版最大的区别不是代码行数而是工程状态机开始变得清晰每个任务从 pending 进入 processing发送成功后进入 done失败后进入 failed使用claim_task的原子更新避免多个 Worker 并发时重复消费使用json.loads而不是 eval避免任意代码执行网络请求设置了连接超时和读超时每一类异常都有明确的处理分支失败原因通过日志保留在现场每轮没有任务时休息 5 秒避免空轮询造成资源浪费。4.5 验证思路与预期结果为了验证这段代码是否正常工作可以手动插入一条任务数据INSERT INTO tasks (owner, payload, status) VALUES (order-service, {user_id: 1001, content: 您的订单已发货}, pending);然后运行python worker_refactored.py如果通知服务正常日志会记录任务处理成功如果通知服务返回 500requests 会抛出 HTTPErrortask 状态会被更新为 failed并在日志中看到失败原因。你需要根据自己实际的接口返回格式调整模拟方式。有一点必须强调这段修复代码对“发送成功但标记失败”这种极端情况也没有做到完全幂等。真实消息系统中如果要严格避免重复通知通常需要引入消息 ID 去重表或者让下游服务支持幂等键。这个案例的重点是展示人工重构如何比 AI 初版更可靠而不是宣称只要照着写就不会出问题。5. 如果还想继续用 AI一套防“退坑”的开发流程5.1 把任务拆小避免一次性生成整个系统想让 AI 输出可靠代码第一条原则不是写更好的 prompt而是拆小任务。AI 在生成一个 30 行的函数时出现严重逻辑错误的概率远低于一口气生成一个 300 行的服务模块。推荐的拆法是把需求拆成“一个输入、一个输出、一个副作用”的单位。例如“从数据库读取明日到期的订单”“判断订单是否满足自动续费条件”“调用支付平台发起扣款”分别交给 AI比一句“帮我写一个自动续费系统”稳妥得多。每个任务都要带有明确的验收标准例如“输入明日到期的订单列表输出需要续费的订单列表规则近 30 天有过成功扣款的订单跳过。” AI 生成完代码后你第一件事不是运行而是拿着验收标准和代码逐行比对。5.2 给 AI 建立“上下文卡”很多 AI coding 工具效果差不是模型不行而是没有给它足够准确的项目上下文。团队可以维护一份面向 AI 的说明文档放在仓库 docs/ai-context.md 中内容包括项目技术栈和语言版本已有模块的目录结构本地开发环境和测试启动命令依赖管理方式代码规范和禁止事项当前任务涉及的领域约束。如果你让 Agent 修改某个模块可以在对话开始前先让 AI 阅读这份文档并明确要求“涉及修改公共函数、数据库表结构、外部接口时先列出影响范围再给出代码变更”。这一步能有效减少 AI 跨模块修改时的“自作主张”。5.3 加一道机器门禁Lint、测试与安全扫描很多人不用 AI 写代码时也未必会在每个提交之前跑 lint 和自动化测试。但一旦代码由 AI 批量生成机器门禁就不是可选项而是必需品。没有门禁AI 引入的问题可能要等到代码审查或者上线之后才会暴露。下面是一个比较通用的 GitHub Actions 配置适用于 Python 项目的 Pull Request 流程。它会在每次代码合并前执行 lint 检查和测试不通过则阻止合并name: ci on: pull_request: branches: [main] jobs: check: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkoutv4 - name: Set up Python uses: actions/setup-pythonv5 with: python-version: 3.11 - name: Install dependencies run: | pip install --upgrade pip pip install -r requirements-dev.txt - name: Lint run: ruff check . - name: Test run: pytest如果你使用的不是 GitHub 而是 GitLab CI 或 Jenkins对应的思路也是一样的只要代码没有通过 lint、测试、安全扫描就不能进入主干分支。依赖安全扫描可以加入 pip-audit、npm audit 或 Dependabot 之类的工具。AI 在生成代码时往往会顺手建议引入一个“看起来刚刚好”的新依赖小依赖的生命周期和底层安全风险很难靠直觉判断。安全扫描能帮你拦截已知漏洞的依赖版本。5.4 代码审查从“看语法”变成“问决策”团队成员在用 AI 编码之后代码审查的负担会增加但审查重点应该发生转移。传统的代码审查是检查缩进、命名、变量作用域这些基础问题AI 代码审查则要更关注“为什么这样实现”这段代码为什么用了这个算法为什么在这个地方直接 return而不是继续后续流程这个函数的边界条件是什么输入为空时怎么办如果第三方服务超时任务会被阻塞多久这个异常被捕获后系统如何感知如果 AI Agent 的 Pull Request 描述里没有解释清楚这些问题可以让开发者先补充设计决策说明再进入人工审查。不要因为“AI 跑的测试都过了”就让评审过程缩水。6. 常见误区与高频问题排查由于 AI coding 工具种类较多不同项目和模型的差异也很大这里列几个高频共性问题并给出排查方向。问题现象常见原因解决思路AI 修改 A 模块导致 B 模块功能异常Agent 跨文件修改但没有识别 B 模块对 A 的依赖缩小修改范围让AI先列出影响面增加跨模块集成测试AI 修复一个 bug结果引入了两个新 bug上下文碎片化AI 掌握不了完整的约束条件改为人工修复给 AI 提供失败现场的最小复现用例代码能运行但类型检查/严格 lint 过不了AI 生成时忽略了类型标注和代码风格规范先跑 lint将规范文件作为上下文提供给 AI调用 API 时报错“参数不存在”模型幻觉训练数据中的 API 版本与当前版本不一致查询官方文档用真实 SDK 信息修正调用生成单测全绿但线上行为不对单测基于实现而非业务需求补业务级测试用例代码审查时回归需求AI 输出代码中包含大量重复逻辑没有识别已有公共函数明确告知要复用的函数名人工去重Pull Request 过大一个 PR 改了 30 个文件Agent 自动拆任务但范围失控限制单次任务文件数要求小步提交排查时建议按下面这个清单逐一确认先复现问题把“现象”变成稳定的“输入—输出”对再检查改动范围确认哪些文件是本次变更引入的第三步缩小上下文把无关代码从 AI 对话里移除只保留最小问题现场第四步验证边界条件注意检查空值、超时、并发、重复请求等场景最后补回归测试如果 AI 生成的代码没有配套测试禁止合入主干。7. 总结与我的建议“I’m done coding with AI”这个标题背后反映的并不是工具失效而是工作方法没有跟上工具变化。AI coding 从代码补全演进到 Agent 自动执行后它对开发者的要求反而提高了你需要更敏锐地审查代码更严格地定义验收标准更坚定地保留代码的可解释性。在实际项目里我会建议把 AI 定位成“结对程序员”而不是“代班程序员”。它可以帮你快速生成基础代码、补齐测试骨架、搜索不熟悉的 API 用法但涉及核心业务规则、资金链路、数据一致性、安全权限这些高风险区域仍然要由工程师手写或者至少逐行审查并补充完整测试。如果你正在经历“AI 越修越乱”的阶段不妨做一次退让先把 AI Agent 关闭改用代码补全模式把系统里最核心的那个模块找出来自己手写重构一遍当你重新理解了这个模块的每一个分支条件后再把 AI 工具加入进来让它辅助你完成周边重复性工作。是否彻底告别 AI 编程并不取决于工具好不好用而取决于你还需要为这段代码负责多久。只要代码会运行在生产环境你就要保证自己有能力解释每一行代码为什么存在。如果哪一天 AI 生成的代码已经超出了你的理解范围那你离“退坑”也就不远了。希望这篇文章能帮你在完全放弃和失控使用之间找到一条更稳妥的路径。