1. 为什么我坚持让AI写完代码后先过我这道人工审查关让AI写代码这件事现在几乎成了日常。Claude Code、各种Agent工具、本地模型接入VS Code写个函数、补个测试、搭个脚手架几分钟就能出一大段。但我这两年踩下来最深的体会是AI写得越快人工审查这道关卡就越不能省。标题里说的四条清单两次打回不是噱头是我自己审AI代码时固定走的一套流程——四条检查清单逐条过过不了就打回重写通常一个稍微复杂点的模块至少要打回两次才能进主干。先说清楚这套东西适合谁。如果你只是让AI写个一次性脚本、跑完就扔那没必要这么较真。但只要你把AI产出的代码往生产环境、往团队仓库、往有权限边界的系统里放那审查就是刚需。我见过太多人把AI生成的代码直接commit结果权限配置写错、沙箱逃逸、依赖版本冲突最后排查半天发现是AI想当然补的一段逻辑。这篇文章就把我这套审查方法完整拆开讲包括四条清单具体查什么、为什么这么设计、两次打回通常卡在哪、以及我在实操中总结的那些文档里不会写的坑。核心关键词先摆出来AI代码审查、Claude Code、沙箱、权限、Agent。这几个词基本覆盖了当前AI辅助开发最核心的矛盾——AI能力越强它触碰系统边界文件、权限、网络、进程的机会就越多而审查的重点恰恰就在这些边界上。下面我按先讲清楚AI代码为什么容易出问题再逐条拆解四条清单最后讲打回重写的实操链路这个顺序展开中间会穿插大量我自己的真实案例和参数细节。1.1 AI生成代码的三个典型想当然要理解审查清单为什么这么设计得先明白AI写代码时到底在哪些地方容易想当然。我总结下来主要是三类。第一类是权限假设。AI默认你的运行环境权限是充足的。比如它写一段删除临时目录的代码直接rm -rf或者shutil.rmtree完全不考虑目标目录可能被占用、可能有只读属性、可能当前用户根本没有删除权限。在Windows上尤其明显你经常会遇到你需要来自Administrators的权限才能删除这类提示AI生成的清理逻辑如果没做异常捕获和权限降级直接就把整个流程搞崩。更隐蔽的是注册表权限、应用程序容器权限这类AI基本不会主动考虑。第二类是沙箱边界假设。现在很多Agent工具跑在沙箱里AI生成的代码如果试图访问沙箱外的路径、试图起子进程、试图监听端口在沙箱环境下会直接失败。但AI在生成时是按理想环境写的它不知道你的沙箱策略限制了什么。我遇到过AI写的代码在本地跑得好好的一进Agent沙箱就因为创建视图权限不足、无法绑定端口而挂掉。第三类是依赖与版本假设。AI的训练数据有时间窗口它补的依赖版本、API签名可能已经过时或者它假设你装了某个包但实际没装。这类问题在跨平台时特别突出比如同一段代码在Ubuntu和Windows上行为完全不同。提示审查AI代码时先把它假设了什么环境这件事想清楚比逐行看逻辑更高效。环境假设错了逻辑再对也跑不起来。2. 第一条清单权限与边界——AI最容易翻车的地方四条清单里我把权限与边界放在第一条因为这是AI代码出事概率最高、后果也最严重的地方。权限问题轻则报错重则误删数据、越权访问。这一条清单我具体查四样东西文件系统权限、进程与子进程权限、网络与端口权限、以及系统级特殊权限。2.1 文件系统权限删除、写入、遍历三件事分开查AI生成的代码只要涉及文件操作我就会重点看三个动作删除、写入、遍历。删除是最危险的。AI经常写os.remove、shutil.rmtree、rm -rf这类操作但很少加防护。我审查时必查三点目标路径是不是硬编码的绝对路径危险、有没有做存在性判断、有没有捕获权限异常。举个真实例子我让AI写一个清理构建产物的脚本它直接写了删除整个build目录但没考虑这个目录可能是符号链接指向别处也没考虑Windows下文件被占用删不掉的情况。打回后我要求它加上先判断路径是否是符号链接、删除前检查目录是否在预期的工作区内、对每个文件单独try-catch并记录失败项。写入要查的是目录是否存在、是否有写权限、是否覆盖已有文件。AI经常假设父目录一定存在直接open写文件结果目录不存在就报错。正确做法是先os.makedirs(exist_okTrue)但AI不一定想得到。覆盖问题更隐蔽AI写的导出逻辑可能默默覆盖同名文件审查时要确认有没有做备份或重命名策略。遍历要查的是递归深度和符号链接循环。AI写的递归遍历如果不限制深度、不处理符号链接遇到循环链接会无限递归直到栈溢出。这个坑我在处理大型项目目录时踩过AI生成的统计脚本跑了半天卡死最后发现是符号链接成环。2.2 进程与子进程权限Agent场景下的重灾区只要代码里出现subprocess、os.system、exec这类调用审查等级立刻拉满。AI生成子进程调用时常见问题有三个。一是命令注入。AI可能把用户输入直接拼进shell命令这在Agent场景下极其危险因为Agent的输入可能来自不可信来源。审查时必须确认参数是列表形式传递subprocess.run([ls, path])而不是字符串拼接subprocess.run(fls {path}, shellTrue)。二是子进程权限继承。子进程会继承父进程的权限如果父进程权限过高子进程就能做超出预期的事。在沙箱环境里AI生成的代码如果试图起子进程很可能被沙箱策略直接拦截报权限不足或操作被拒绝。我审查时会确认这个子进程调用在目标沙箱里是否被允许有没有降级方案三是僵尸进程和超时。AI写的子进程调用经常不设timeout一旦子进程卡住整个流程就挂起。审查时必查有没有timeout参数、有没有checkTrue配合异常处理。2.3 网络与端口权限绑定、监听、出站三方向网络这块AI代码的问题集中在端口绑定和出站请求。绑定端口时AI经常写死一个端口号不考虑端口被占用、不考虑低端口号1024以下需要特权。审查时要确认有没有端口探测和重试逻辑。出站请求要查的是目标地址是否可控、有没有超时、有没有重试上限。AI写的HTTP请求经常不设超时遇到网络不通就无限等待。在Agent沙箱里出站请求可能被策略限制AI生成的代码如果没做失败降级整个任务就卡死。2.4 系统级特殊权限Windows下的Administrators与TrustedInstaller这块是Windows环境特有的坑也是我在热搜词里看到大量相关问题的原因。AI生成的代码如果涉及系统目录、注册表、服务操作经常会撞上你需要来自Administrators的权限或你需要来自TrustedInstaller的权限这类提示。审查这类代码时我会确认三件事操作是否真的需要管理员权限很多时候可以用用户级替代方案、有没有做权限检测和友好提示、有没有提供降级路径。比如AI写一个修改注册表的逻辑如果目标键在HKEY_LOCAL_MACHINE下普通用户根本改不了正确做法是先检测权限没有就提示用户或改用HKEY_CURRENT_USER下的对应位置。注意AI生成的代码里出现获取完整权限强制删除这类字眼时一定要警惕。这类操作往往绕过正常权限模型在受管环境里会直接失败甚至触发安全告警。3. 第二条清单沙箱兼容性——本地能跑不代表Agent里能跑第二条清单专门查沙箱兼容性。现在用Claude Code、各类Agent工具的人越来越多代码在本地IDE里跑通一进Agent沙箱就各种报错这是高频问题。我审查时重点看四类操作文件系统访问范围、进程创建、网络访问、以及环境变量依赖。3.1 文件系统访问范围沙箱通常只放行特定目录Agent沙箱一般会限制代码能访问的目录范围通常只放行工作目录及其子目录。AI生成的代码如果试图访问工作目录之外的路径比如用户主目录、系统临时目录、绝对路径下的配置在沙箱里会直接失败。我审查时会做一件事把代码里所有文件路径列出来逐个确认是否在沙箱允许范围内。常见问题包括AI用/tmp或C:\Temp存中间文件沙箱可能不放行、AI读取用户主目录下的配置文件沙箱外、AI写入日志到系统目录无权限。正确做法是统一用工作目录下的相对路径或者用环境变量传入的路径。3.2 进程创建沙箱可能完全禁止很多Agent沙箱出于安全考虑直接禁止创建子进程。AI生成的代码如果依赖subprocess调用外部命令比如调用git、调用编译器、调用系统工具在沙箱里会直接失败。审查时我会确认这个外部调用有没有沙箱内的替代方案比如用Python库替代命令行工具、用内置API替代外部程序。如果确实需要子进程我会要求AI加上能力检测先尝试创建失败则走降级路径或明确报错而不是让整个流程崩掉。3.3 网络访问出站可能被白名单限制沙箱的网络策略通常比本地严格出站请求可能只允许特定域名或完全禁止。AI生成的代码如果依赖外部API、下载依赖、拉取远程资源在沙箱里可能失败。审查时要确认有没有超时、有没有失败降级、有没有把网络依赖做成可配置。3.4 环境变量与路径依赖跨平台最容易翻车AI生成的代码经常假设某些环境变量存在比如HOME、PATH里的特定工具或者假设路径分隔符是/。在沙箱和跨平台场景下这些假设都可能不成立。审查时我会确认路径拼接用的是os.path.join还是硬编码分隔符、环境变量读取有没有默认值、有没有处理变量不存在的情况。检查项本地环境常见情况沙箱环境常见限制审查要点文件访问全盘可读写仅工作目录路径是否在允许范围子进程可自由创建常被禁止有无降级方案网络出站基本放行白名单或禁止有无超时和降级环境变量完整可能精简有无默认值处理端口绑定可绑高端口常被限制有无端口探测4. 第三条清单依赖与版本——AI的时间窗口陷阱第三条清单查依赖与版本。AI的训练数据有时间窗口它补的依赖版本、API用法可能已经过时或者它假设你装了某个包但实际没装。这条清单我查三样依赖声明完整性、版本兼容性、以及跨平台行为差异。4.1 依赖声明完整性AI经常漏掉隐式依赖AI生成代码时如果用了某个库它可能不会主动告诉你需要安装。比如它写import requests但不会提醒你pip install requests。更隐蔽的是间接依赖AI用了A库的某个功能但A库依赖B库的特定版本AI不会提。审查时我会做一件事把代码里所有import列出来逐个确认是否在依赖清单里。对于Python项目我会检查requirements.txt或pyproject.toml是否完整对于Node项目检查package.json。AI生成的代码经常漏掉一些它以为你知道的依赖。4.2 版本兼容性API签名可能已经变了AI补的代码可能用的是旧版API。比如某个库在新版本里改了函数签名、废弃了某个参数、或者改变了默认行为。审查时我会确认代码里用到的API在当前主流版本里是否还存在、签名是否一致。一个实用技巧是让AI生成代码后让它自己说明这段代码依赖哪些库的哪些版本然后你去核对。如果AI说不清楚那大概率有问题。4.3 跨平台行为差异同一段代码两个样跨平台差异是AI最容易忽略的。文件路径分隔符、换行符、权限模型、进程管理、信号处理Windows和Linux差异巨大。AI生成的代码如果没做平台判断很可能在一个平台上跑通、另一个平台报错。审查时我会确认有没有用os.path或pathlib处理路径、有没有处理换行符差异、有没有对平台特有的权限模型做适配。比如删除文件Windows下文件被占用会报错Linux下则可能直接成功AI生成的清理逻辑如果不处理这个差异在Windows上就会失败。5. 第四条清单可测试性与可观测性——AI代码最缺的两样第四条清单查可测试性与可观测性。这是AI代码最薄弱的地方因为AI倾向于写能跑就行的代码很少主动加测试、加日志、加错误处理。这条清单我查三样错误处理完整性、日志与可观测性、以及可测试性。5.1 错误处理完整性AI经常只写happy pathAI生成的代码经常只考虑正常路径异常路径基本不管。文件不存在怎么办、网络超时怎么办、权限不足怎么办AI很少主动处理。审查时我会确认每个可能失败的操作有没有try-catch、异常有没有被合理处理而不是简单pass、失败后有没有清理和回滚。一个典型问题是AI写的资源管理打开文件、连接数据库、申请锁但异常时没有释放。审查时要确认有没有用with语句、有没有finally块做清理。5.2 日志与可观测性出问题时能不能定位AI生成的代码经常没有日志或者只有print。在生产环境里没有日志意味着出问题只能靠猜。审查时我会确认关键操作有没有日志、日志级别是否合理、有没有记录足够的上下文比如操作对象、参数、结果。在Agent场景下可观测性尤其重要因为Agent的执行过程往往是自动化的出问题没人盯着。我会要求AI在关键节点加结构化日志方便后续排查。5.3 可测试性能不能写单元测试AI生成的代码经常难以测试因为它把逻辑和IO、网络、时间耦合在一起。审查时我会确认核心逻辑能不能脱离外部依赖单独测试、有没有把可注入的依赖比如时间、随机数、外部服务做成参数。如果一段代码没法写单元测试那它的质量基本靠运气。我会要求AI重构把纯逻辑抽出来外部依赖通过参数注入。6. 两次打回我的实操链路和判断标准讲完四条清单说说两次打回这个说法。这不是我故意为难AI而是实操下来一个稍微复杂点的模块第一遍基本过不了四条清单打回重写后第二遍通常还有残留问题再打回一次才能进主干。下面讲我具体的打回链路和判断标准。6.1 第一次打回通常卡在权限和沙箱第一次打回问题基本集中在第一条和第二条清单。AI生成的代码在权限假设和沙箱兼容性上最容易翻车。我打回时会给出具体的失败场景比如这段删除逻辑在Windows下会因文件占用失败这个子进程调用在沙箱里会被禁止让AI针对具体场景重写。打回时我会要求AI做三件事明确说明代码假设的运行环境、对每个可能失败的操作加处理、提供降级路径。这样第二遍出来的代码权限和沙箱问题基本能解决。6.2 第二次打回通常卡在依赖和可观测性第二次打回问题集中在第三条和第四条清单。依赖声明不全、版本不兼容、错误处理缺失、日志不足这些是第二遍的常见残留。我打回时会要求AI补全依赖清单、确认API版本、加错误处理和日志。第二次打回后代码基本能达到可进主干的标准。但我会保留一个习惯进主干前自己再跑一遍四条清单因为AI有时候会在重写时引入新问题。6.3 打回时的沟通技巧给场景不给结论打回AI代码时我发现一个技巧很管用给具体失败场景而不是直接给结论。比如不要说这段代码权限有问题而要说这段代码在Windows下删除被占用的文件时会抛异常需要处理。给场景能让AI更准确地定位问题重写质量更高。另外打回时最好附上期望的行为比如删除失败时应该记录并继续而不是中断整个流程。这样AI重写时目标明确减少来回次数。7. 我在实操中总结的几个反直觉经验最后分享几个我在审AI代码过程中总结的反直觉经验这些是文档里不会写、但实操中很管用的。第一个经验AI代码审查的重点不是逻辑是边界。逻辑错误其实好发现跑一遍就暴露了。真正难发现的是边界问题——权限边界、沙箱边界、平台边界。这些在本地跑通时不会暴露一到目标环境就出事。所以我把审查精力大部分放在边界上。第二个经验让AI自己解释假设比你自己猜更高效。我经常在审查前先问AI这段代码假设了什么运行环境AI的回答往往能直接暴露它的假设比逐行读代码快得多。第三个经验打回次数不是越少越好。有些人觉得打回多次是效率低但我的体会是一个模块打回两次换来的是进主干后不出事比进主干后半夜被叫起来排查强太多。AI写得快打回的成本其实很低。第四个经验沙箱兼容性要在写之前就约束。与其等AI写完再打回不如在给AI的指令里就明确沙箱限制比如代码将在只允许访问工作目录、禁止子进程、禁止网络出站的沙箱里运行。提前约束能大幅减少打回次数。第五个经验权限问题优先用降级方案而不是提权。AI遇到权限不足时倾向于建议提权用管理员权限跑。但在生产环境里提权往往不可行也不安全。正确做法是设计降级方案权限不足时跳过、记录、或用替代路径。审查时我会特别关注AI有没有提供降级路径。这套四条清单、两次打回的方法我用了大半年覆盖了从简单脚本到复杂Agent模块的各种场景。核心就一句话AI负责写人负责守边界。边界守住了AI代码的产出效率才能真正转化为可靠的生产力。至于具体清单怎么落地成检查表、怎么和团队协作流程结合那就是另一个话题了后面有机会再展开。