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_ok=True)，但AI不一定想得到。覆盖问题更隐蔽，AI写的导出逻辑可能默默覆盖同名文件，审查时要确认有没有做备份或重命名策略。
遍历要查的是递归深度和符号链接循环。AI写的递归遍历如果不限制深度、不处理符号链接，遇到循环链接会无限递归直到栈溢出。这个坑我在处理大型项目目录时踩过，AI生成的统计脚本跑了半天卡死，最后发现是符号链接成环。
2.2 进程与子进程权限：Agent场景下的重灾区
只要代码里出现subprocess、os.system、exec这类调用，审查等级立刻拉满。AI生成子进程调用时，常见问题有三个。
一是命令注入。AI可能把用户输入直接拼进shell命令，这在Agent场景下极其危险，因为Agent的输入可能来自不可信来源。审查时必须确认参数是列表形式传递（subprocess.run(["ls", path])）而不是字符串拼接（subprocess.run(f"ls {path}", shell=True)）。
二是子进程权限继承。子进程会继承父进程的权限，如果父进程权限过高，子进程就能做超出预期的事。在沙箱环境里，AI生成的代码如果试图起子进程，很可能被沙箱策略直接拦截，报"权限不足"或"操作被拒绝"。我审查时会确认：这个子进程调用在目标沙箱里是否被允许？有没有降级方案？
三是僵尸进程和超时。AI写的子进程调用经常不设timeout，一旦子进程卡住，整个流程就挂起。审查时必查有没有timeout参数、有没有check=True配合异常处理。
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 path
AI生成的代码经常只考虑正常路径，异常路径基本不管。文件不存在怎么办、网络超时怎么办、权限不足怎么办，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代码的产出效率才能真正转化为可靠的生产力。至于具体清单怎么落地成检查表、怎么和团队协作流程结合，那就是另一个话题了，后面有机会再展开。
