先说一下我当时的状态AI 编程用得越顺手代码越来越能跑但我也越来越看不懂自己项目里的代码。改一个按钮样式要顺着 AI 生成的组件树翻半天加一个字段七处地方都要动最夸张的是有些模块我甚至不敢自己改只能把需求重新粘贴给 AI等它再生成一版。看起来我在写代码实际上我只是一个“提示词搬运工”。项目还能跑但代码已经不属于我了。后来我意识到这不是 AI 变笨了而是我用错了方式。AI 擅长生成代码但它不会替我维护代码更不会替我为项目负责。当我把“理解代码”这件事完全外包出去项目就一定会慢慢失控。这篇文章想聊的就是我当时如何把自己从这堆 AI 生成的代码里捞出来。核心思路不是“弃用 AI”而是把 AI 从自动驾驶模式调回辅助驾驶模式。我会按我当时自救的实际顺序来写先判断你是不是真的被困住了然后冻结项目、画数据流、整理代码结构、跑稳单条链路最后谈长期怎么避免再次陷入同样困境。最后附一份排查清单适合你以后又被 AI 生成的代码卡住时直接对照。1. 先判断你属于哪种“被 AI 代码困住”不是所有用了 AI 编程的人都会被困住。有些项目规模小一次生成的代码能全部看完有些项目边界清楚AI 只负责某个独立脚本这种反而很安全。真正危险的是项目开始变大、需求开始迭代而你仍然沿用“让 AI 生成一大段代码”的习惯。我整理了自己和身边几个朋友遇到的症状基本可以分成三类。1.1 典型症状代码能跑但离开 AI 就改不动这是最隐蔽的一种困境。项目跑得好好的没有报错功能也正常。但只要需求一变你就发现自己没法定点修改。你找不到那个“按钮颜色”到底在哪一层你不知道改了这个函数会不会影响另一个调用方你不敢随手删掉看起来没用的变量因为不确定它是不是哪个流程里的隐含依赖。最后你只能把整个需求描述粘贴给 AI让它重新生成一份“包含新功能”的代码。一次两次还好次数多了项目里就会堆满废弃函数、重复变量、互相不一致的命名。代码量越来越大但你真正理解的部分越来越少。1.2 典型症状需求变更靠重新生成而不是靠修改正常开发是“改代码”AI 依赖式开发会变成“重新生成代码”。你给 AI 一个上下文告诉它新增一个功能它给你一份新代码你发现这里不对再告诉它“把 XX 改一下”它又给你一份新代码。结果就是你的手不再是用来改代码的只用来复制粘贴。你甚至不知道新代码和旧代码之间的差异在哪里也不清楚新代码引入了什么新的依赖、新的全局变量、新的副作用。这种模式最大的问题在于项目不会沿着可维护的方向演进只会沿着“对话记录”的方向膨胀。AI 生成的每一版代码都像一次提交但这些提交之间没有规范没有取舍没有一致性设计。1.3 典型症状多段 AI 生成代码靠“补丁式粘合”凑在一起更复杂一点的情况是项目里不同部分由不同 AI 对话生成。前端一个对话后端一个对话工具脚本又一个对话。它们各自都能跑但拼在一起就出问题。比如前端传递的参数是一套命名后端期望的又是另一套两个 AI 都生成了一份配置文件一份生效另一份成了隐患某个逻辑在 A 函数里处理过又被 B 函数的补丁重复处理了一遍。这类项目的典型表现是一次小改动会引起连环反应修好一个 bug 又冒出一个新 bug。你很难说清楚某个问题到底出在哪一段因为你并不真正拥有这些代码的地图。1.4 怎么判断自己是不是已经困住了我用两个标准来判断你能不能不看 AI 给出的解释凭自己对项目现状的理解直接回答“某个功能的数据从哪来、经过哪些处理、最后输出到哪去”你有没有一个自己完整读过、理解过的核心文件还是说全部文件都是从 AI 对话里复制出来的如果这两个问题的答案都是否不用怀疑你已经从“用 AI 辅助编程”滑向了“被 AI 生成物绑架”。2. 自救第一阶段先把项目“冻结”建可回退基线很多人在意识到代码失控后第一反应是“推倒重写”。我劝你不要这样做。原因很简单你连现在的代码都没理解透重写出来的东西只会更乱。所谓重写大概率是再把需求丢回给 AI让它重新生成一遍最后得到另一个你没看过的新烂摊子。正确做法是先冻结项目。2.1 为什么要先冻结而不是先动手改困境中的项目就像一个正在高空飞行的飞机你知道仪表盘有点问题但飞机目前还能飞。如果你在空中就开始拆仪表盘大概率会摔下去。冻结的意思是在这一段时间里不新增功能不做大重构不随意改逻辑只做理解、记录、拆解。你得先确定“当前这个版本是可以稳定跑起来的”然后以它为基准逐步把失控部分找回来。我一般会这么做建一个新的 Git 分支或者至少把当前项目目录完整复制一份。这一步帮你建立一个“安全岛”后面改坏了可以随时回退。记录当前环境的依赖清单包括 Python 包、Node 包、系统环境变量、启动命令。很多项目跑不起来不是代码问题而是依赖版本被升级过、环境变量缺失、启动命令不一致。冻结新增需求。团队协作时可以说清楚个人项目也要对自己说清楚两周内不做新功能。写一份“现状说明”哪个功能目前是正常的哪个功能是半成品哪些代码你自己都看不懂。不需要写长篇大论列清单就行。2.2 建立可回退的判定标准冻结不是目的可回退才是目的。你得给“成功”和“失败”定一个标准。我当时的判断标准是任何一次修改之后当前版本能重新跑起来并且核心功能的行为没有发生变化。如果跑不起来或者行为出现新的异常就回到基线重新再来。这里有三个细节容易忽略依赖锁定。最好把依赖版本固定下来不要用“最新版”。AI 生成的代码经常不管版本兼容性过几天重装环境可能就会出现莫名其妙的错误。可重复部署。你要确保同一个项目目录、同一套依赖、同一条启动命令在另一台机器上也能跑起来。如果不能说明你对项目运行条件还欠缺理解。输出目录。很多 AI 生成的项目会把输出写到临时目录或者相对路径一旦目录不存在、磁盘满、路径带中文就会失败。先把这个问题解决比改业务逻辑更要紧。注意如果你发现自己连“当前版本能否稳定复现”都不确定那第一步不是重构而是先把环境跑通、把版本固定、把部署步骤写清楚。没有稳定基线后面所有改动都是在流沙上盖房子。3. 自救第二阶段不急着改代码先把数据流和调用链画出来冻结项目之后我开始做第二次理解项目。这一步非常关键不是直接看代码而是先把项目里每个入口、每个处理步骤、每个输出摸清楚。AI 生成的代码普遍有一个问题表面结构完整但设计意图缺失。注释经常是 AI 自己编的“这段代码用于处理用户请求”却不会告诉你“这个函数负责把表单里的日期字符串转成时间戳因为它后面的比较逻辑要求 UTC 格式”。你只有搞清楚数据流才能把代码从“对话生成物”变成“可维护工程”。3.1 找入口、出口和中间步骤我建议按下面顺序走一遍找入口。程序启动的入口、路由表、主函数、定时任务的启动位置。先不要管里面调用了什么先标记出来。找出口。最终输出到哪文件数据库接口返回控制台把这些终点列出来。把入口和出口之间经过的关键函数按顺序写下来每个函数只记三件事输入是什么、输出是什么、大致承担什么职责。标记出不确定的地方。比如“这个变量不知道从哪来的”“这个函数不知道被谁调用”“这个全局状态很奇怪”。这个阶段不需要把每一行代码都看懂只需要建立“数据从 A 走到 B中间经过 C、D、E”的认知。你甚至可以把它画在纸上或者用文本方式记录下来。3.2 给每个关键函数写一句“人话注释”AI 生成的代码注释经常有两种问题一种是废话“这段代码循环遍历列表”另一种是马后炮“由于需求变化这里临时增加判断”。两种对理解项目都没有帮助。我的做法是把每个关键函数用一句话写成“人类可读的职责说明”。比如原本的注释“# 处理用户输入”改成“# 将用户提交的出生日期字符串转为 UTC 时间戳供后续年龄计算使用”又比如原本的注释“# 初始化配置”改成“# 从 config.yaml 读取数据库地址若环境变量 DATABASE_URL 存在则覆盖”这种注释的目的不是解释语法而是还原决策。有了这些注释你不需要重新进入 AI 的对话上下文就能快速理解每个模块存在的理由。3.3 不要在这个阶段用 AI 帮你梳理整个项目我自己踩过这个坑给 AI 丢了一整个项目目录让它分析依赖关系结果它生成了很漂亮的文档但里面出现了好几个不存在的函数名。连续问了几次答案还不一致。问题在于大模型处理长上下文时容易“脑补”缺失信息尤其是面对它自己生成风格很接近的大量代码时它会倾向于编造一个合理的解释而不是准确地告诉你“这个文件的 connection 参数没有被任何地方传入”。所以我之后的策略是让 AI 解释单个函数或者解释单个模块内的一小段逻辑并明确提示它“如果信息不足请直接说不知道不要推测”。这样得到的解释可靠性会明显更高。3.4 验证你是否完成了第二阶段判断标准只有一个你能不能在完全不打开代码编辑器的情况下用你自己的话把“这个项目的输入是什么输出是什么中间经历了哪几个步骤”讲清楚。如果能说明你已经部分拿回了代码的所有权。如果不能继续读代码不要急着改。4. 自救第三阶段按“入口—处理—出口”重排代码位置当你已经能画出数据流下一步才是动手整理代码。但注意这里不是让你把 AI 写的东西全部删掉重来而是按“入口、处理、出口”的结构重新摆放代码让项目的物理结构和你脑中的模型保持一致。AI 生成代码最典型的结构问题是什么是代码生长顺序不等于工程结构。你的项目是第一轮让 AI 生成主逻辑第二轮让它加了输入校验第三轮让它加错误处理第四轮让它加导出功能。最终呈现出来的代码就是这四轮需求的物理堆叠而不是一个按功能边界划分的工程。4.1 把“临时补丁”合并回正式流程我会先搜索代码里类似“临时”“补丁”“后面再优化”“workaround”的注释再找 AI 生成代码里常见的异常处理块。很多时候你会发现有一些逻辑是为了绕过另一个 AI 代码产生的 bug 而加的。对于这类补丁需要判断这个补丁本身是否必要如果必要把它的逻辑合并到正确的位置如果只是“当时跑不过去加了个判断”那很可能上游真实原因是输入格式不一致或者参数没传对补丁只是掩盖了问题。处理原则是能不删就不删但一定要标记清楚。标记含义后续动作已确认这段逻辑真实有效能跑通保留并加人话注释待确认不确定为什么要写这段但删了会报错标记 TODO继续观察可疑冗余看起来没用但删了不影响运行先注释掉跑一轮测试再删代码必须重构逻辑正确但位置不合理等本阶段再做移动这张表可以一直挂在项目根目录的 README 里越到后期越有用。4.2 把输入校验、业务逻辑、输出处理分开不是所有项目都需要严格的分层架构但对 AI 生成的代码来说至少应该做到输入校验不要和业务逻辑混在一起输出处理不要和计算逻辑混在一起。为什么因为混在一起会导致三个问题你想改输入格式不知道会影响哪些计算逻辑你想改输出格式结果误改了一个核心判断你想单测某个核心函数但它依赖外部输入和输出渲染压根没法单元测试。正确的做法很简单把纯计算函数单独拎出来它们只接收参数、返回结果把输入解析放在入口附近把输出渲染放在出口附近。中间核心逻辑保持“无副作用”这样下次再让 AI 改代码时AI 也更容易生成正确结果。4.3 删除 AI 生成的多余抽象AI 很喜欢生成“过度工程化”的代码。比如一个简单的配置读取它给你封装成 ConfigManager、ConfigLoader、ConfigValidator 三个类一个只需要打印几行结果的小脚本它给你引入了一整套命令行参数解析框架。这类抽象在新项目里看着很专业但当你需要理解项目时它就是负担。我处理的方法是先看抽象有没有被真正用到。如果只有一处调用那就直接把它展开把代码放回调用处如果多处调用保留抽象但要写清楚它存在的理由。这里有个容易走极端的提醒不要为了“简洁”把所有抽象都删掉。删除抽象的前提是你能完全掌控这段逻辑。如果删完之后代码变短了但你更看不懂了那说明留下来的部分你并没有理解。4.4 验证整理后的项目仍然能跑每次整理完一个模块立刻回到基线跑一遍你之前确认过的核心场景。我一般会准备一个最小测试输入这样改完某个函数后可以快速验证它是否还能输出正确结果。如果结果显示正常继续下一步如果结果异常立刻看是不是刚才移动代码时引用了错误变量或者把一个函数从“类内部方法”移出去后没有加参数。大部分情况下AI 生成的代码移动位置后报错问题都出在隐式依赖上比如某个全局变量、某个类属性、某个模块级常量。注意移动代码时不要同时修改逻辑。先搬位置再运行验证代码移动完还能跑再考虑逻辑调整。位置变动和逻辑调整混在一起出了问题很难定位。5. 自救第四阶段单条链路跑稳再考虑批量和自动化项目整理到能看、能改、能运行之后下一步是验证“可扩展性”。很多 AI 生成的项目只针对单条输入跑通了但一旦进入批量处理、定时任务、接口调用就会出现各种问题。你会发现一个规律真正“把你写进死胡同”的往往不是单条逻辑而是批量执行时暴露出来的资源、命名、异常处理问题。5.1 为什么先跑通单条任务再上批量单条任务只要输入输出符合预期就行批量任务有一套新规则文件名冲突。第 1 条输出的文件会被第 2 条覆盖。输出命名不可预测。没有排序规则后面没法按目录找到对应结果。异常中断。某一条输入失败脚本直接退出后面所有任务都停掉。内存不释放。长列表循环处理大量数据时模型推理、图片解码、文件读写都会占用资源。我对自己的要求是先让单条任务连续跑 10 次并且每次输出内容都一致。如果发现随机结果、顺序不确定、偶发错误先解决单条稳定性再考虑批量。5.2 批量化前必改的三个点第一个是输出命名。无论你处理的是文本、图片、视频还是数据文件输出命名必须包含任务 ID 或时间戳。这样即使个别任务失败你也能通过命名对应回原始输入。第二个是失败重试。批量脚本里每一条输入都要用独立异常捕获包裹。出错时记录错误原因但不要中断整个队列。可以设置重试次数上限通常 2 到 3 次超过上限就跳过并写入日志。第三个是日志可追溯。至少记录三件事本轮任务开始时间、每条输入的处理结果、失败任务的错误堆栈。日志级别可以先开到 INFO排查问题时再切 DEBUG。下面是一个通用的批量任务伪代码思路适合按这个骨架完善自己的脚本import time import logging from pathlib import Path logging.basicConfig(levellogging.INFO, format%(asctime)s - %(levelname)s - %(message)s) def process_one(input_path, output_path): # 这里是你的核心处理逻辑 pass def process_batch(input_dir, output_dir, max_retry2): input_files sorted(Path(input_dir).glob(*)) for idx, input_file in enumerate(input_files, start1): output_file output_dir / f{idx:04d}_{input_file.stem}.out logging.info(start %s - %s, input_file.name, output_file.name) for attempt in range(1, max_retry 1): try: process_one(input_file, output_file) logging.info(done %s, input_file.name) break except Exception as e: logging.warning(failed %s, attempt %d/%d: %s, input_file.name, attempt, max_retry, e) time.sleep(1) else: logging.error(give up %s, input_file.name)这里不是让你照抄而是告诉你批量脚本的核心结构遍历、记录、重试、跳过。缺少任何一个批量任务都会变成麻烦。5.3 “批量”也适用于 AI 编程本身一次只改一个函数我刚才说的批量是指最终代码处理业务数据时的批量任务。但在 AI 编程实践中还有一个“反向批量”的问题你让 AI 一次修改的代码范围太大本质上也是一种批量操作。比如你让 AI “把这个项目的登录逻辑改成 JWT 认证”这句话信息量极大涉及配置文件、路由、中间件、用户模型、异常处理、前端调用AI 一次生成的代码可能覆盖所有地方但它并不了解你的具体代码细节。结果就是它生成了一份看起来很合理但和你项目现有结构根本对不上的方案。正确的做法是拆成小步先让 AI 解释当前登录逻辑是怎么工作的。再让它提供 JWT 方案的依赖清单和配置示例。你自己手动改配置文件运行验证。让 AI 只改用户登录这一个函数范围控制到最小。跑通后再让 AI 改下一个点。看起来效率变低了但长期下来你的代码会保持清晰AI 每次介入也只是局部增强了你的能力而不是替你做全局决策。6. 自救最终阶段建立长期“不再被 AI 困住”的工程习惯自救成功之后不能立刻回到原来“依赖 AI 生成一切”的模式。否则三个月后你又会回到原点。我给自己定了几条规则每一条都是吃过亏之后总结出来的。6.1 关键逻辑人写模板逻辑 AI 写需要严格保证正确性的代码例如权限校验、支付金额计算、数据一致性、核心业务判断这些逻辑我不会让 AI 直接生成。最多少量借鉴 AI 参考但最终形态一定是我自己逐行确认并手写。AI 适合做的是对正确性要求相对低的模板代码配置文件格式转换、读写文件、数据清洗、命令行参数解析、代码脚手架生成。这类代码出错了容易发现改起来也不伤筋动骨。6.2 让 AI 解释再决定是否让 AI 修改遇到看不懂的代码我现在的默认动作不是“直接让 AI 重新生成”而是先粘贴相关函数问“这段逻辑是什么前置条件是什么哪里可能出错”等我自己理解清楚之后再决定是否让 AI 修改。这个区别很大。直接让 AI 改你得到的是一个新结果仍需重新理解和验证先解释再改你得到的是可复用的判断能力下次遇到类似代码就能自己定位。6.3 每次改动范围要小要可回退我给自己定了一个硬标准一次只改一个函数或者一个模块最多不超过 50 行逻辑。改动前先记下当前版本能跑改动后立即运行验证。如果跑不过回退重来。你可能会觉得 50 行太少。但实际情况是AI 生成的代码往往隐式依赖很多改一个看起来不起眼的变量都可能牵出几个隐藏调用点。范围越小定位问题越容易。6.4 至少保留一个核心回归测试不需要高密度测试但你至少要有一个“核心回归测试”。它的作用是不管你后面怎么改代码只要这个测试通过你就知道最核心的路径没有断。这个测试可以是简单的函数调用也可以是一条命令行命令。重点不是覆盖率而是它有明确断言能在 30 秒内给出通过或失败的结果。有了它你在整理、迁移、重写代码时会更有底气。6.5 定期“只读不写”地重读代码我现在的习惯是每周挑一个固定时间只读代码不写代码。读的时候不看需求文档不看 AI 之前的对话只看当前代码和注释。如果哪段代码我需要重新解释才能看懂说明它的注释还不够或者结构还不对。这个习惯看起来不起眼但它就是防止“再次被困住”最有效的动作。因为很多失控是从小处开始的一个没法理解的小函数一次临时补丁一段冗余逻辑。等到失控范围变大再想收拾就难了。7. 再次被卡住时的排查顺序最后我想给你一份排查清单。以后不管你继续用 AI 写代码还是在别人的 AI 生成代码里做维护只要你发现自己卡住了就按这个顺序走一遍。看现象。是编译报错、运行报错、结果不对、任务卡住还是你纯粹“看不懂这段代码”前三种有具体错误信息可以先找堆栈第四种没有报错只靠人力理解需要回到数据流分析。看输入。刚才改了什么数据什么参数什么文件路径输入格式是否变化了很多问题不是代码坏了而是输入不再满足代码隐含的假设。看上下文。你让 AI 改代码时有没有给它足够的上下文是不是只丢了一句“改一下 XX”但它引用了很多外部状态AI 根本看不见看环境。依赖版本是不是被升级过环境变量是否变了启动命令是否当前目录不同权限、磁盘、内存是否不足看提交记录。项目能正常跑的上一个版本是什么这个版本和当前版本之间改了什么如果代码是 AI 生成后直接覆盖的没有提交记录那你只能通过文件备份来判断。看设计边界。你是不是想让 AI 生成的代码处理它本不该处理的场景比如一个只处理 100 行文本的脚本强行改成支持 10 万条记录的批量服务或者一个只用于本地演示的工具直接拿去当生产 API。这个顺序的核心是先排除外部因素再怀疑代码逻辑最后反思是不是使用方法出了偏差。大多数时候卡住的原因都不是“AI 智力不够”而是项目本身已经进入了一种不可维护状态继续靠 AI 打补丁只会更糟。如果你发现自己已经处在“改一个点崩一片区域”的阶段我的建议是不要再往里面加补丁。后退一步按本文的顺序冻结、画数据流、整理位置、跑稳单条链路。这个过程不快但它能让你真正重新成为项目的主人。我自己做完这一轮整理之后最大的感受是AI 仍然在帮我写代码但我现在每提交一段代码前都能在心里画出它的位置和数据走向。不是 AI 变强了而是我终于知道自己在建什么了。