1. 为什么“看代码对不对”这条路走不通了1.1 从人工审查到AI生成代码的范式转移过去我们审查代码核心逻辑是“找bug”——变量有没有初始化、循环边界对不对、异常有没有捕获、SQL有没有拼接。这套方法论建立在一个人写代码、另一个人读代码的基础上审查者的心智模型是“我来看你写得对不对”。但现在情况变了。AI编程助手能在几秒内生成几百行代码你不可能逐行去判断“对不对”因为AI生成的代码在语法层面几乎不会出错它甚至能写出比你更规范的异常处理和更完整的类型注解。问题不在于代码“对不对”而在于这段代码“该不该信任”。我刚开始用AI辅助编程的时候踩过一个典型的坑让AI帮我写一个文件上传的接口它生成的代码逻辑严密、参数校验完整、错误处理优雅我扫了一眼觉得没问题就合并了。结果上线后发现这个接口没有对上传文件的类型做白名单限制任何文件都能传上来。代码本身“对”吗对。但它跨越了一条信任边界——它默认了调用方会传合法的文件类型。这就是我想聊的核心问题AI生成代码的安全审查不是看代码写得对不对而是看信任边界画在哪里。1.2 三条信任边界的定义与来源所谓“信任边界”简单说就是系统中不同信任级别的区域之间的分界线。数据从低信任区域流向高信任区域时必须经过验证和净化。这个概念在传统安全领域并不新鲜但AI生成代码的场景下它有了新的含义。我把AI生成代码的信任边界归纳为三条第一条输入边界。外部数据进入系统的入口。AI生成的代码往往对输入的处理过于“信任”因为它训练数据中的代码示例大多假设输入是合法的。比如用户提交的表单、API请求的参数、上传的文件、第三方回调的数据这些都属于低信任输入。第二条执行边界。代码执行过程中的权限和资源隔离。AI生成的代码可能在不经意间执行了高权限操作比如直接拼接SQL、调用系统命令、访问文件系统、发起网络请求。这些操作本身没问题但如果执行上下文没有做隔离就会成为攻击面。第三条输出边界。数据离开系统时的处理。AI生成的代码可能把敏感信息直接返回给前端或者在日志中打印了不该打印的内容或者在没有转义的情况下把用户输入渲染到页面上。这三条边界构成了一个完整的审查框架。你不需要逐行判断代码“对不对”只需要问三个问题输入从哪里来、执行在什么权限下、输出到哪里去。1.3 适合谁来参考这套方法这套方法最适合两类人一是正在使用AI编程助手进行日常开发的工程师你不需要成为安全专家但需要知道AI生成的代码在哪些地方容易出问题二是技术团队的负责人你需要建立一套审查流程让团队成员在享受AI编程效率的同时不引入安全风险。不需要你有深厚的安全背景但需要你对系统的基本架构有理解——知道数据从哪里来、经过哪些处理、最终到哪里去。如果你能画出系统的数据流图这套方法就能直接套用。2. 输入边界AI最容易“信任”的地方2.1 为什么AI生成的代码对输入过于信任AI编程助手的训练数据来自海量的开源代码和公开项目。这些代码有一个共同特点它们大多是示例代码、教程代码或者理想化场景下的实现。在这些代码中输入通常被假设为合法的、格式正确的、没有恶意意图的。举个例子你让AI写一个根据用户ID查询用户信息的接口它大概率会生成类似这样的代码def get_user(request): user_id request.GET.get(id) user User.objects.get(iduser_id) return JsonResponse({name: user.name, email: user.email})这段代码有问题吗从功能角度看没问题。但它隐含了一个假设user_id是合法的、存在的、且当前请求者有权限查看的。AI不会主动帮你加权限校验因为在它的训练数据中权限校验往往被省略以保持示例简洁。这就是输入边界的核心问题AI生成的代码默认输入是可信的而实际系统中任何来自外部的数据都不可信。2.2 输入边界的三个检查点我在审查AI生成代码时会在输入边界上重点检查三个地方检查点一输入来源是否明确。这段代码处理的数据是从哪里来的是用户直接输入、API调用方传入、还是第三方系统回调不同来源的信任级别不同。用户直接输入的数据需要最严格的校验第三方回调需要验证签名内部服务调用也需要确认调用方身份。检查点二输入校验是否完整。AI生成的代码通常只做最基本的类型校验比如判断是否为空、是否是数字。但完整的输入校验应该包括类型检查、长度限制、格式验证、范围约束、白名单过滤。特别是白名单AI很少主动使用因为它倾向于用黑名单来“排除已知的坏输入”而安全实践要求用白名单“只允许已知的好输入”。检查点三输入是否被直接使用。这是最危险的情况。AI生成的代码可能把用户输入直接拼接到SQL语句、系统命令、文件路径、模板渲染中。这些操作如果没有经过净化就会导致注入类漏洞。2.3 实操给AI生成的输入处理代码补上边界假设AI帮你生成了这样一段代码app.route(/search) def search(): keyword request.args.get(q) results db.execute(fSELECT * FROM articles WHERE title LIKE %{keyword}%) return render_template(search.html, resultsresults)这段代码有两个明显的输入边界问题SQL拼接和模板渲染。我来演示怎么补上边界。第一步处理SQL注入。不要用字符串拼接用参数化查询app.route(/search) def search(): keyword request.args.get(q, ) if len(keyword) 100: keyword keyword[:100] results db.execute( SELECT * FROM articles WHERE title LIKE %s, (f%{keyword}%,) ) return render_template(search.html, resultsresults)第二步处理模板渲染。确保模板引擎默认开启自动转义或者在渲染前对数据进行转义from markupsafe import escape app.route(/search) def search(): keyword escape(request.args.get(q, )) # ... 后续处理第三步加长度限制和字符白名单。如果搜索关键词只允许中文、英文和数字就用正则表达式过滤import re keyword request.args.get(q, ) if not re.match(r^[\w\u4e00-\u9fa5]{1,50}$, keyword): return jsonify({error: invalid keyword}), 400注意AI生成的代码往往缺少这些边界处理不是因为它“不知道”这些技术而是因为它在生成时优先考虑功能实现安全处理被默认为“你可以自己加”。所以审查时要把输入边界作为第一优先级。2.4 常见输入边界漏洞速查漏洞类型AI生成代码的典型表现修复方向SQL注入字符串拼接SQL语句参数化查询XSS直接渲染用户输入模板自动转义或手动转义命令注入拼接系统命令避免拼接使用参数化API路径遍历直接使用用户输入作为文件路径白名单校验规范化路径参数篡改直接信任前端传来的价格、权限等参数服务端重新计算和校验越权访问只校验登录状态不校验资源归属每次操作都校验资源所有权这张表是我在实际审查中总结出来的AI生成的代码在这几类问题上出现频率最高。特别是越权访问AI生成的代码通常只检查“用户是否登录”而不检查“用户是否有权限操作这个资源”。3. 执行边界权限与隔离的隐形战场3.1 AI生成代码的执行上下文盲区AI在生成代码时它看到的是代码本身看不到代码运行的上下文。它不知道这段代码是运行在容器里还是宿主机上不知道当前进程有什么权限不知道网络策略是怎样的。这就导致AI生成的代码在执行边界上存在大量盲区。我遇到过最典型的情况让AI写一个图片处理的功能它生成的代码直接调用了系统的convert命令来处理图片。代码逻辑没问题但它没有考虑执行这个命令的进程是否有权限、命令参数是否可能被注入、处理大图片时是否会耗尽资源。执行边界的核心问题是代码在什么权限下执行、能访问哪些资源、执行时间是否可控。3.2 执行边界的四个审查维度维度一权限最小化。AI生成的代码往往以当前进程的权限执行所有操作。如果当前进程是root那代码就能做任何事。正确的做法是不同的操作使用不同的权限上下文。比如读取配置文件用低权限写入日志用中等权限修改系统状态用高权限但需要额外验证。维度二资源隔离。AI生成的代码可能直接访问文件系统、网络、数据库连接池等共享资源。如果多个请求共享同一个资源而没有隔离一个请求的异常可能影响其他请求。比如AI生成的代码可能用一个全局的数据库连接在高并发下就会出现连接争用。维度三执行时间控制。AI生成的代码通常不会考虑超时和资源限制。一个正则表达式匹配、一个循环、一个递归调用如果没有时间限制就可能被恶意输入触发拒绝服务。我见过AI生成的代码用正则表达式验证邮箱那个正则表达式在特定输入下会消耗大量CPU时间。维度四副作用控制。AI生成的代码可能在不该产生副作用的地方产生副作用。比如一个查询接口AI生成的代码可能在查询失败时自动创建记录一个日志函数可能在日志写入失败时抛出异常导致主流程中断。3.3 实操审查AI生成代码的执行边界假设AI帮你生成了一个文件导出功能import subprocess def export_report(report_id, format): report get_report(report_id) filename f/tmp/report_{report_id}.{format} with open(filename, w) as f: f.write(report.content) subprocess.run([convert, filename, f{filename}.pdf]) return filename这段代码的执行边界问题很明显直接写文件到/tmp、调用外部命令、没有清理临时文件。我来逐步修复。第一步限制文件写入路径。不要用/tmp这种全局可写目录用应用专属的临时目录并且校验文件名import os import tempfile EXPORT_DIR os.path.join(tempfile.gettempdir(), app_exports) os.makedirs(EXPORT_DIR, exist_okTrue) def export_report(report_id, format): if format not in (pdf, csv, xlsx): raise ValueError(unsupported format) report get_report(report_id) filename os.path.join(EXPORT_DIR, freport_{report_id}.{format}) # 确保路径在EXPORT_DIR内 if not os.path.realpath(filename).startswith(os.path.realpath(EXPORT_DIR)): raise ValueError(invalid path) # ... 后续处理第二步避免直接调用外部命令。如果必须调用使用参数列表而不是shell字符串并且限制命令的权限subprocess.run( [convert, filename, f{filename}.pdf], timeout30, checkTrue, capture_outputTrue )第三步确保临时文件被清理。用try/finally或者上下文管理器try: # ... 处理逻辑 finally: if os.path.exists(filename): os.remove(filename)提示AI生成的代码在执行边界上最常见的问题是“假设一切顺利”。它不会考虑命令执行失败、文件写入失败、网络超时等情况。审查时要把异常路径作为重点。3.4 执行边界的常见陷阱我在实际项目中遇到过几个AI生成代码的执行边界陷阱值得单独拿出来说。陷阱一正则表达式拒绝服务。AI生成的邮箱验证正则可能是这样的^([a-zA-Z0-9]([._-][a-zA-Z0-9])*)...这个正则在特定输入下会指数级回溯。修复方法是使用更简单的正则或者限制输入长度。陷阱二递归深度失控。AI生成的树形结构处理代码可能用递归实现但没有深度限制。恶意构造的深层嵌套数据会导致栈溢出。修复方法是改用迭代或者设置递归深度上限。陷阱三并发资源争用。AI生成的代码可能用全局变量或单例来管理资源在多线程环境下会出现竞态条件。修复方法是使用线程安全的资源管理方式或者为每个请求分配独立资源。陷阱四日志注入。AI生成的日志代码可能直接把用户输入写入日志攻击者可以通过换行符伪造日志条目。修复方法是对日志内容进行转义或者使用结构化日志。4. 输出边界数据离开系统前的最后一道关4.1 输出边界为什么容易被忽视输入边界大家都会关注因为“外部数据不可信”是安全常识。但输出边界往往被忽视因为直觉上“数据要离开系统了还有什么好审查的”。实际上输出边界是数据泄露和注入攻击的最后一道防线。AI生成的代码在输出边界上的问题主要有三类敏感信息泄露、输出编码缺失、错误信息过度暴露。敏感信息泄露是指代码把不该返回的数据返回了。比如用户查询接口返回了用户的密码哈希、内部ID、权限列表。AI生成的代码通常会把数据库查询结果直接序列化返回不会主动过滤敏感字段。输出编码缺失是指代码把用户输入直接渲染到输出中没有做转义。这在Web场景下就是XSS漏洞在API场景下可能导致JSON注入。错误信息过度暴露是指代码在出错时返回了堆栈信息、数据库结构、文件路径等内部细节。AI生成的代码通常有比较完整的错误处理但错误信息往往过于详细。4.2 输出边界的三个过滤层第一层数据过滤。在返回数据之前明确哪些字段可以返回、哪些不可以。不要直接把数据库模型序列化返回而是定义一个明确的输出结构。第二层编码转义。根据输出目标做相应的编码。HTML输出做HTML转义JSON输出做JSON转义URL输出做URL编码。不要依赖框架的默认行为要显式处理。第三层错误处理。对外返回的错误信息应该是通用的、不包含内部细节的。详细的错误信息应该记录在服务端日志中而不是返回给调用方。4.3 实操审查AI生成代码的输出边界假设AI帮你生成了一个用户信息接口app.route(/api/user/int:user_id) def get_user(user_id): user User.query.get(user_id) if not user: return jsonify({error: fUser {user_id} not found}), 404 return jsonify({ id: user.id, name: user.name, email: user.email, password_hash: user.password_hash, role: user.role, created_at: user.created_at.isoformat() })这段代码的输出边界问题很明显返回了password_hash、错误信息暴露了用户ID、没有做权限校验。我来修复。第一步定义明确的输出结构def serialize_user(user): return { id: user.id, name: user.name, email: user.email, created_at: user.created_at.isoformat() }第二步处理错误信息app.route(/api/user/int:user_id) def get_user(user_id): user User.query.get(user_id) if not user: return jsonify({error: resource not found}), 404 # ... 后续处理第三步加权限校验from flask_login import current_user app.route(/api/user/int:user_id) def get_user(user_id): if not current_user.is_authenticated: return jsonify({error: unauthorized}), 401 if current_user.id ! user_id and current_user.role ! admin: return jsonify({error: forbidden}), 403 # ... 后续处理注意AI生成的代码在输出边界上最危险的问题是“过度返回”。它倾向于把能查到的数据都返回而不是只返回需要的字段。审查时要问这个接口真的需要返回这些字段吗4.4 输出边界的检查清单检查项检查内容常见问题敏感字段是否返回了密码、密钥、内部ID直接序列化数据库模型权限校验是否校验了当前用户对资源的访问权限只校验登录状态输出编码是否根据输出目标做了转义直接拼接HTML或JSON错误信息是否暴露了内部细节返回堆栈信息或数据库错误数据量是否限制了返回的数据量没有分页或数量限制缓存控制是否设置了合适的缓存头敏感数据被缓存这张清单可以直接用在代码审查中每次审查AI生成的接口代码时过一遍。5. 把三条边界串起来一套可复用的审查流程5.1 审查流程的整体设计前面分别讲了三条边界但在实际操作中你需要一套流程把它们串起来。我的做法是拿到AI生成的代码后先画数据流图再逐条边界审查最后做交叉验证。画数据流图的目的不是画得好看而是强迫自己理清数据的来龙去脉。数据从哪里进入系统、经过哪些处理、最终到哪里去。这个过程不需要工具在纸上画或者在心里过一遍都行。逐条边界审查就是按照输入边界、执行边界、输出边界的顺序用前面讲的检查点逐一核对。交叉验证是指检查三条边界之间的衔接处比如输入边界校验过的数据在执行边界是否被正确使用执行边界产生的数据在输出边界是否被正确过滤。5.2 审查流程的实操步骤第一步识别AI生成代码的范围。不是所有代码都需要同等程度的审查。AI生成的代码中处理外部输入、执行敏感操作、返回敏感数据部分需要重点审查。纯逻辑计算、格式化输出、内部工具函数可以适当放宽。第二步标记信任边界。在代码中标记出数据跨越信任边界的位置。比如request.args.get()是输入边界subprocess.run()是执行边界jsonify()是输出边界。标记出来后重点审查这些位置。第三步逐边界检查。对每个标记的位置用对应的检查清单核对。输入边界检查来源、校验、使用方式执行边界检查权限、隔离、超时、副作用输出边界检查敏感字段、权限、编码、错误信息。第四步补充缺失的边界处理。AI生成的代码通常缺少边界处理你需要补上。补的时候遵循最小改动原则不要重写整个函数只加必要的校验和过滤。第五步记录审查结果。把发现的问题和修复方式记录下来形成团队的知识库。下次遇到类似代码时可以直接参考。5.3 一个完整的审查案例假设AI帮你生成了一个“用户反馈提交”功能app.route(/feedback, methods[POST]) def submit_feedback(): data request.get_json() content data.get(content) email data.get(email) rating data.get(rating) feedback Feedback( contentcontent, emailemail, ratingrating, iprequest.remote_addr ) db.session.add(feedback) db.session.commit() send_email( toadminexample.com, subjectfNew feedback from {email}, bodyfRating: {rating}\nContent: {content} ) return jsonify({status: ok, id: feedback.id})我来按三条边界审查这段代码。输入边界审查content、email、rating都来自用户输入没有做任何校验。content可能包含恶意内容email可能格式不正确rating可能是任意值。修复加长度限制、格式校验、范围校验。执行边界审查send_email是同步调用如果邮件服务超时整个请求会阻塞。db.session.commit()没有异常处理如果数据库写入失败会返回500错误。修复邮件发送改为异步数据库操作加异常处理。输出边界审查返回了feedback.id这个ID是自增的可能被用来枚举反馈数量。错误信息没有处理如果数据库出错会返回堆栈信息。修复返回一个不透明的标识符加全局异常处理。修复后的代码import re from celery import shared_task shared_task def send_feedback_email(email, rating, content): # 异步发送邮件 pass app.route(/feedback, methods[POST]) def submit_feedback(): try: data request.get_json() if not data: return jsonify({error: invalid request}), 400 content data.get(content, ) email data.get(email, ) rating data.get(rating, 0) if not isinstance(content, str) or len(content) 2000: return jsonify({error: invalid content}), 400 if not re.match(r^[^][^]\.[^]$, email): return jsonify({error: invalid email}), 400 if not isinstance(rating, int) or rating 1 or rating 5: return jsonify({error: invalid rating}), 400 feedback Feedback( contentcontent, emailemail, ratingrating, iprequest.remote_addr ) db.session.add(feedback) db.session.commit() send_feedback_email.delay(email, rating, content) return jsonify({status: ok}) except Exception: db.session.rollback() return jsonify({error: internal error}), 500这个案例展示了三条边界审查的完整过程。修复后的代码在输入边界做了校验在执行边界做了异步和异常处理在输出边界做了错误信息过滤。5.4 审查流程的注意事项注意事项一不要追求完美。安全审查的目标是降低风险不是消除所有风险。把精力集中在最关键的边界上不要为了一个低风险问题花大量时间。注意事项二结合业务场景。同样的代码在不同业务场景下风险不同。一个内部工具的用户输入校验可以宽松一些一个面向公网的服务就需要严格校验。注意事项三持续更新。AI编程助手在进化它生成的代码质量在提高但新的攻击手法也在出现。审查清单需要定期更新把新发现的边界问题加进去。注意事项四团队协作。审查不是一个人的事。把审查清单分享给团队让每个人在提交AI生成代码前先自查。这样可以大大减少审查的工作量。6. 常见问题与排查技巧实录6.1 AI生成代码的安全审查常见问题在实际操作中我遇到过很多关于AI生成代码安全审查的问题。这里整理几个最典型的附上我的排查思路和解决方法。问题一AI生成的代码看起来没问题但总觉得哪里不对。这是最常见的情况。我的经验是当你觉得“哪里不对”的时候通常是因为代码缺少了某个边界处理。这时候不要凭感觉按三条边界的检查清单过一遍很快就能定位到问题。问题二AI生成的代码太多审查不过来。这是效率问题。我的做法是优先审查跨越信任边界的代码纯内部逻辑可以快速扫过。另外可以让AI自己生成安全审查清单然后你按清单核对效率会高很多。问题三修复了AI生成的代码后功能不正常了。这是因为边界处理改变了代码的行为。比如加了输入校验后原本能通过的输入被拒绝了。解决方法是先写测试用例覆盖正常和异常输入修复后跑一遍测试。问题四不确定某个操作是否跨越了信任边界。判断标准很简单如果这个操作的数据来源是外部的或者这个操作会影响外部系统那它就跨越了信任边界。不确定的时候按“跨越了”来处理。问题五团队里其他人不重视AI生成代码的安全审查。这是流程问题。我的做法是先把审查流程跑通用实际案例证明它的价值然后推动团队采纳。不要一上来就要求所有人执行先做出效果。6.2 排查技巧速查表问题现象可能原因排查方向接口返回了不该返回的数据输出边界缺少字段过滤检查序列化逻辑用户能操作别人的数据执行边界缺少权限校验检查资源归属校验特殊输入导致服务异常输入边界缺少校验检查输入处理逻辑日志中出现异常内容输出边界缺少转义检查日志写入逻辑服务在高并发下变慢执行边界缺少资源隔离检查共享资源使用错误信息暴露内部细节输出边界缺少错误处理检查异常处理逻辑这张表可以贴在工位上遇到问题时快速定位排查方向。6.3 独家避坑技巧技巧一让AI自己审查自己。你可以把AI生成的代码再喂给AI让它从安全角度审查。虽然AI的审查不一定完整但它能发现一些你忽略的问题。我的做法是让AI分别从输入、执行、输出三个角度审查然后我复核它的发现。技巧二用“攻击者视角”读代码。审查时不要想“这段代码是做什么的”而要想“如果我想攻击这个系统我会从哪里入手”。这个视角的转换能让你发现很多平时忽略的问题。技巧三关注“默认行为”。AI生成的代码大量依赖框架的默认行为。比如模板引擎的默认转义、ORM的默认参数化、HTTP客户端的默认超时。这些默认行为大部分是安全的但有些不是。审查时要确认这些默认行为是否符合安全要求。技巧四建立自己的“边界模式库”。把常见的边界处理方式整理成代码片段审查时直接对照。比如输入校验的模式、权限校验的模式、输出过滤的模式。这样审查速度会快很多也不容易遗漏。技巧五定期回顾已修复的问题。每隔一段时间回顾一下之前修复过的边界问题看看有没有类似的代码没有修复。AI生成的代码有很强的模式性一个问题往往会在多个地方出现。6.4 一个真实的排查案例有一次AI帮我生成了一个“文章评论”功能。代码逻辑很简单用户提交评论服务端保存并返回。我按三条边界审查了一遍输入边界加了长度限制和内容过滤执行边界加了频率限制输出边界过滤了敏感字段。看起来没问题。但上线后有用户反馈说评论提交后偶尔会消失。我排查了很久最后发现是执行边界的问题AI生成的代码在保存评论后会同步更新文章的评论计数。如果两个用户同时评论同一篇文章计数更新会出现竞态条件导致计数不准确前端根据计数判断评论是否提交成功计数不对就以为提交失败了。这个问题在代码审查时很难发现因为它不是安全漏洞而是并发问题。但它本质上也是执行边界的问题共享资源的并发访问没有做隔离。修复方法是把计数更新改为原子操作或者用消息队列异步处理。这个案例给我的教训是执行边界的审查不仅要看权限和隔离还要看并发和一致性。AI生成的代码在单线程场景下没问题但在并发场景下可能出问题。7. 工具与流程的配合7.1 静态分析工具能帮上什么忙静态分析工具可以自动发现一些常见的边界问题比如SQL注入、XSS、路径遍历。但静态分析工具有两个局限一是误报率高二是无法理解业务上下文。我的做法是把静态分析工具作为第一道过滤用它快速扫一遍AI生成的代码把明显的问题找出来。然后人工审查剩下的部分重点关注静态分析工具无法覆盖的边界问题比如权限校验、业务逻辑边界。常用的静态分析工具包括SonarQube、Semgrep、CodeQL等。这些工具都支持自定义规则你可以把三条边界的检查点写成规则让工具自动检查。7.2 如何把审查流程嵌入开发流程审查流程要嵌入开发流程才能持续执行。我的做法是在代码提交前加一个检查环节AI生成的代码必须经过边界审查才能提交。审查可以是一个人做也可以是团队交叉做。具体操作上可以在代码仓库中加一个审查清单文件提交代码时对照清单自查。也可以在CI流程中加静态分析步骤自动检查常见的边界问题。关键是让审查成为习惯而不是一次性的活动。我见过很多团队一开始很重视过一段时间就松懈了。解决方法是把审查结果和代码质量指标挂钩让审查有可见的产出。7.3 审查流程的持续改进审查流程不是一成不变的。随着AI生成代码的质量变化和攻击手法的演进审查流程需要持续改进。我的做法是每季度回顾一次审查流程看看哪些检查点已经过时、哪些新的边界问题需要加入。回顾的依据包括实际发现的问题、静态分析工具的误报、团队成员的反馈。另外我会定期收集AI生成代码的边界问题案例整理成内部文档。这些案例比抽象的检查清单更有说服力也更容易被团队成员接受。8. 一些个人体会这套方法我用了大半年从最初的“凭感觉审查”到现在的“按边界审查”最大的变化是效率。以前审查AI生成的代码我总是不放心要逐行看花大量时间还不一定看得全。现在按三条边界过一遍十分钟就能完成一个接口的审查而且覆盖度更高。另一个体会是AI生成的代码在边界处理上确实有规律可循。它倾向于省略输入校验、忽略权限检查、过度返回数据。知道这些规律后审查时就有了重点不用面面俱到。最后分享一个小技巧如果你不确定某个边界处理是否必要就问自己一个问题——“如果这段代码被恶意用户利用最坏的结果是什么”如果最坏结果是数据泄露、权限提升、服务不可用那这个边界处理就是必要的。如果最坏结果只是功能异常那可以适当放宽。这个判断标准不是绝对的但能帮你在审查时快速做决策。毕竟安全审查的目标是管理风险不是消除所有风险。把精力集中在真正重要的边界上才是可持续的做法。 AI生成代码安全审查：三条信任边界与实操指南
1. 为什么“看代码对不对”这条路走不通了1.1 从人工审查到AI生成代码的范式转移过去我们审查代码核心逻辑是“找bug”——变量有没有初始化、循环边界对不对、异常有没有捕获、SQL有没有拼接。这套方法论建立在一个人写代码、另一个人读代码的基础上审查者的心智模型是“我来看你写得对不对”。但现在情况变了。AI编程助手能在几秒内生成几百行代码你不可能逐行去判断“对不对”因为AI生成的代码在语法层面几乎不会出错它甚至能写出比你更规范的异常处理和更完整的类型注解。问题不在于代码“对不对”而在于这段代码“该不该信任”。我刚开始用AI辅助编程的时候踩过一个典型的坑让AI帮我写一个文件上传的接口它生成的代码逻辑严密、参数校验完整、错误处理优雅我扫了一眼觉得没问题就合并了。结果上线后发现这个接口没有对上传文件的类型做白名单限制任何文件都能传上来。代码本身“对”吗对。但它跨越了一条信任边界——它默认了调用方会传合法的文件类型。这就是我想聊的核心问题AI生成代码的安全审查不是看代码写得对不对而是看信任边界画在哪里。1.2 三条信任边界的定义与来源所谓“信任边界”简单说就是系统中不同信任级别的区域之间的分界线。数据从低信任区域流向高信任区域时必须经过验证和净化。这个概念在传统安全领域并不新鲜但AI生成代码的场景下它有了新的含义。我把AI生成代码的信任边界归纳为三条第一条输入边界。外部数据进入系统的入口。AI生成的代码往往对输入的处理过于“信任”因为它训练数据中的代码示例大多假设输入是合法的。比如用户提交的表单、API请求的参数、上传的文件、第三方回调的数据这些都属于低信任输入。第二条执行边界。代码执行过程中的权限和资源隔离。AI生成的代码可能在不经意间执行了高权限操作比如直接拼接SQL、调用系统命令、访问文件系统、发起网络请求。这些操作本身没问题但如果执行上下文没有做隔离就会成为攻击面。第三条输出边界。数据离开系统时的处理。AI生成的代码可能把敏感信息直接返回给前端或者在日志中打印了不该打印的内容或者在没有转义的情况下把用户输入渲染到页面上。这三条边界构成了一个完整的审查框架。你不需要逐行判断代码“对不对”只需要问三个问题输入从哪里来、执行在什么权限下、输出到哪里去。1.3 适合谁来参考这套方法这套方法最适合两类人一是正在使用AI编程助手进行日常开发的工程师你不需要成为安全专家但需要知道AI生成的代码在哪些地方容易出问题二是技术团队的负责人你需要建立一套审查流程让团队成员在享受AI编程效率的同时不引入安全风险。不需要你有深厚的安全背景但需要你对系统的基本架构有理解——知道数据从哪里来、经过哪些处理、最终到哪里去。如果你能画出系统的数据流图这套方法就能直接套用。2. 输入边界AI最容易“信任”的地方2.1 为什么AI生成的代码对输入过于信任AI编程助手的训练数据来自海量的开源代码和公开项目。这些代码有一个共同特点它们大多是示例代码、教程代码或者理想化场景下的实现。在这些代码中输入通常被假设为合法的、格式正确的、没有恶意意图的。举个例子你让AI写一个根据用户ID查询用户信息的接口它大概率会生成类似这样的代码def get_user(request): user_id request.GET.get(id) user User.objects.get(iduser_id) return JsonResponse({name: user.name, email: user.email})这段代码有问题吗从功能角度看没问题。但它隐含了一个假设user_id是合法的、存在的、且当前请求者有权限查看的。AI不会主动帮你加权限校验因为在它的训练数据中权限校验往往被省略以保持示例简洁。这就是输入边界的核心问题AI生成的代码默认输入是可信的而实际系统中任何来自外部的数据都不可信。2.2 输入边界的三个检查点我在审查AI生成代码时会在输入边界上重点检查三个地方检查点一输入来源是否明确。这段代码处理的数据是从哪里来的是用户直接输入、API调用方传入、还是第三方系统回调不同来源的信任级别不同。用户直接输入的数据需要最严格的校验第三方回调需要验证签名内部服务调用也需要确认调用方身份。检查点二输入校验是否完整。AI生成的代码通常只做最基本的类型校验比如判断是否为空、是否是数字。但完整的输入校验应该包括类型检查、长度限制、格式验证、范围约束、白名单过滤。特别是白名单AI很少主动使用因为它倾向于用黑名单来“排除已知的坏输入”而安全实践要求用白名单“只允许已知的好输入”。检查点三输入是否被直接使用。这是最危险的情况。AI生成的代码可能把用户输入直接拼接到SQL语句、系统命令、文件路径、模板渲染中。这些操作如果没有经过净化就会导致注入类漏洞。2.3 实操给AI生成的输入处理代码补上边界假设AI帮你生成了这样一段代码app.route(/search) def search(): keyword request.args.get(q) results db.execute(fSELECT * FROM articles WHERE title LIKE %{keyword}%) return render_template(search.html, resultsresults)这段代码有两个明显的输入边界问题SQL拼接和模板渲染。我来演示怎么补上边界。第一步处理SQL注入。不要用字符串拼接用参数化查询app.route(/search) def search(): keyword request.args.get(q, ) if len(keyword) 100: keyword keyword[:100] results db.execute( SELECT * FROM articles WHERE title LIKE %s, (f%{keyword}%,) ) return render_template(search.html, resultsresults)第二步处理模板渲染。确保模板引擎默认开启自动转义或者在渲染前对数据进行转义from markupsafe import escape app.route(/search) def search(): keyword escape(request.args.get(q, )) # ... 后续处理第三步加长度限制和字符白名单。如果搜索关键词只允许中文、英文和数字就用正则表达式过滤import re keyword request.args.get(q, ) if not re.match(r^[\w\u4e00-\u9fa5]{1,50}$, keyword): return jsonify({error: invalid keyword}), 400注意AI生成的代码往往缺少这些边界处理不是因为它“不知道”这些技术而是因为它在生成时优先考虑功能实现安全处理被默认为“你可以自己加”。所以审查时要把输入边界作为第一优先级。2.4 常见输入边界漏洞速查漏洞类型AI生成代码的典型表现修复方向SQL注入字符串拼接SQL语句参数化查询XSS直接渲染用户输入模板自动转义或手动转义命令注入拼接系统命令避免拼接使用参数化API路径遍历直接使用用户输入作为文件路径白名单校验规范化路径参数篡改直接信任前端传来的价格、权限等参数服务端重新计算和校验越权访问只校验登录状态不校验资源归属每次操作都校验资源所有权这张表是我在实际审查中总结出来的AI生成的代码在这几类问题上出现频率最高。特别是越权访问AI生成的代码通常只检查“用户是否登录”而不检查“用户是否有权限操作这个资源”。3. 执行边界权限与隔离的隐形战场3.1 AI生成代码的执行上下文盲区AI在生成代码时它看到的是代码本身看不到代码运行的上下文。它不知道这段代码是运行在容器里还是宿主机上不知道当前进程有什么权限不知道网络策略是怎样的。这就导致AI生成的代码在执行边界上存在大量盲区。我遇到过最典型的情况让AI写一个图片处理的功能它生成的代码直接调用了系统的convert命令来处理图片。代码逻辑没问题但它没有考虑执行这个命令的进程是否有权限、命令参数是否可能被注入、处理大图片时是否会耗尽资源。执行边界的核心问题是代码在什么权限下执行、能访问哪些资源、执行时间是否可控。3.2 执行边界的四个审查维度维度一权限最小化。AI生成的代码往往以当前进程的权限执行所有操作。如果当前进程是root那代码就能做任何事。正确的做法是不同的操作使用不同的权限上下文。比如读取配置文件用低权限写入日志用中等权限修改系统状态用高权限但需要额外验证。维度二资源隔离。AI生成的代码可能直接访问文件系统、网络、数据库连接池等共享资源。如果多个请求共享同一个资源而没有隔离一个请求的异常可能影响其他请求。比如AI生成的代码可能用一个全局的数据库连接在高并发下就会出现连接争用。维度三执行时间控制。AI生成的代码通常不会考虑超时和资源限制。一个正则表达式匹配、一个循环、一个递归调用如果没有时间限制就可能被恶意输入触发拒绝服务。我见过AI生成的代码用正则表达式验证邮箱那个正则表达式在特定输入下会消耗大量CPU时间。维度四副作用控制。AI生成的代码可能在不该产生副作用的地方产生副作用。比如一个查询接口AI生成的代码可能在查询失败时自动创建记录一个日志函数可能在日志写入失败时抛出异常导致主流程中断。3.3 实操审查AI生成代码的执行边界假设AI帮你生成了一个文件导出功能import subprocess def export_report(report_id, format): report get_report(report_id) filename f/tmp/report_{report_id}.{format} with open(filename, w) as f: f.write(report.content) subprocess.run([convert, filename, f{filename}.pdf]) return filename这段代码的执行边界问题很明显直接写文件到/tmp、调用外部命令、没有清理临时文件。我来逐步修复。第一步限制文件写入路径。不要用/tmp这种全局可写目录用应用专属的临时目录并且校验文件名import os import tempfile EXPORT_DIR os.path.join(tempfile.gettempdir(), app_exports) os.makedirs(EXPORT_DIR, exist_okTrue) def export_report(report_id, format): if format not in (pdf, csv, xlsx): raise ValueError(unsupported format) report get_report(report_id) filename os.path.join(EXPORT_DIR, freport_{report_id}.{format}) # 确保路径在EXPORT_DIR内 if not os.path.realpath(filename).startswith(os.path.realpath(EXPORT_DIR)): raise ValueError(invalid path) # ... 后续处理第二步避免直接调用外部命令。如果必须调用使用参数列表而不是shell字符串并且限制命令的权限subprocess.run( [convert, filename, f{filename}.pdf], timeout30, checkTrue, capture_outputTrue )第三步确保临时文件被清理。用try/finally或者上下文管理器try: # ... 处理逻辑 finally: if os.path.exists(filename): os.remove(filename)提示AI生成的代码在执行边界上最常见的问题是“假设一切顺利”。它不会考虑命令执行失败、文件写入失败、网络超时等情况。审查时要把异常路径作为重点。3.4 执行边界的常见陷阱我在实际项目中遇到过几个AI生成代码的执行边界陷阱值得单独拿出来说。陷阱一正则表达式拒绝服务。AI生成的邮箱验证正则可能是这样的^([a-zA-Z0-9]([._-][a-zA-Z0-9])*)...这个正则在特定输入下会指数级回溯。修复方法是使用更简单的正则或者限制输入长度。陷阱二递归深度失控。AI生成的树形结构处理代码可能用递归实现但没有深度限制。恶意构造的深层嵌套数据会导致栈溢出。修复方法是改用迭代或者设置递归深度上限。陷阱三并发资源争用。AI生成的代码可能用全局变量或单例来管理资源在多线程环境下会出现竞态条件。修复方法是使用线程安全的资源管理方式或者为每个请求分配独立资源。陷阱四日志注入。AI生成的日志代码可能直接把用户输入写入日志攻击者可以通过换行符伪造日志条目。修复方法是对日志内容进行转义或者使用结构化日志。4. 输出边界数据离开系统前的最后一道关4.1 输出边界为什么容易被忽视输入边界大家都会关注因为“外部数据不可信”是安全常识。但输出边界往往被忽视因为直觉上“数据要离开系统了还有什么好审查的”。实际上输出边界是数据泄露和注入攻击的最后一道防线。AI生成的代码在输出边界上的问题主要有三类敏感信息泄露、输出编码缺失、错误信息过度暴露。敏感信息泄露是指代码把不该返回的数据返回了。比如用户查询接口返回了用户的密码哈希、内部ID、权限列表。AI生成的代码通常会把数据库查询结果直接序列化返回不会主动过滤敏感字段。输出编码缺失是指代码把用户输入直接渲染到输出中没有做转义。这在Web场景下就是XSS漏洞在API场景下可能导致JSON注入。错误信息过度暴露是指代码在出错时返回了堆栈信息、数据库结构、文件路径等内部细节。AI生成的代码通常有比较完整的错误处理但错误信息往往过于详细。4.2 输出边界的三个过滤层第一层数据过滤。在返回数据之前明确哪些字段可以返回、哪些不可以。不要直接把数据库模型序列化返回而是定义一个明确的输出结构。第二层编码转义。根据输出目标做相应的编码。HTML输出做HTML转义JSON输出做JSON转义URL输出做URL编码。不要依赖框架的默认行为要显式处理。第三层错误处理。对外返回的错误信息应该是通用的、不包含内部细节的。详细的错误信息应该记录在服务端日志中而不是返回给调用方。4.3 实操审查AI生成代码的输出边界假设AI帮你生成了一个用户信息接口app.route(/api/user/int:user_id) def get_user(user_id): user User.query.get(user_id) if not user: return jsonify({error: fUser {user_id} not found}), 404 return jsonify({ id: user.id, name: user.name, email: user.email, password_hash: user.password_hash, role: user.role, created_at: user.created_at.isoformat() })这段代码的输出边界问题很明显返回了password_hash、错误信息暴露了用户ID、没有做权限校验。我来修复。第一步定义明确的输出结构def serialize_user(user): return { id: user.id, name: user.name, email: user.email, created_at: user.created_at.isoformat() }第二步处理错误信息app.route(/api/user/int:user_id) def get_user(user_id): user User.query.get(user_id) if not user: return jsonify({error: resource not found}), 404 # ... 后续处理第三步加权限校验from flask_login import current_user app.route(/api/user/int:user_id) def get_user(user_id): if not current_user.is_authenticated: return jsonify({error: unauthorized}), 401 if current_user.id ! user_id and current_user.role ! admin: return jsonify({error: forbidden}), 403 # ... 后续处理注意AI生成的代码在输出边界上最危险的问题是“过度返回”。它倾向于把能查到的数据都返回而不是只返回需要的字段。审查时要问这个接口真的需要返回这些字段吗4.4 输出边界的检查清单检查项检查内容常见问题敏感字段是否返回了密码、密钥、内部ID直接序列化数据库模型权限校验是否校验了当前用户对资源的访问权限只校验登录状态输出编码是否根据输出目标做了转义直接拼接HTML或JSON错误信息是否暴露了内部细节返回堆栈信息或数据库错误数据量是否限制了返回的数据量没有分页或数量限制缓存控制是否设置了合适的缓存头敏感数据被缓存这张清单可以直接用在代码审查中每次审查AI生成的接口代码时过一遍。5. 把三条边界串起来一套可复用的审查流程5.1 审查流程的整体设计前面分别讲了三条边界但在实际操作中你需要一套流程把它们串起来。我的做法是拿到AI生成的代码后先画数据流图再逐条边界审查最后做交叉验证。画数据流图的目的不是画得好看而是强迫自己理清数据的来龙去脉。数据从哪里进入系统、经过哪些处理、最终到哪里去。这个过程不需要工具在纸上画或者在心里过一遍都行。逐条边界审查就是按照输入边界、执行边界、输出边界的顺序用前面讲的检查点逐一核对。交叉验证是指检查三条边界之间的衔接处比如输入边界校验过的数据在执行边界是否被正确使用执行边界产生的数据在输出边界是否被正确过滤。5.2 审查流程的实操步骤第一步识别AI生成代码的范围。不是所有代码都需要同等程度的审查。AI生成的代码中处理外部输入、执行敏感操作、返回敏感数据部分需要重点审查。纯逻辑计算、格式化输出、内部工具函数可以适当放宽。第二步标记信任边界。在代码中标记出数据跨越信任边界的位置。比如request.args.get()是输入边界subprocess.run()是执行边界jsonify()是输出边界。标记出来后重点审查这些位置。第三步逐边界检查。对每个标记的位置用对应的检查清单核对。输入边界检查来源、校验、使用方式执行边界检查权限、隔离、超时、副作用输出边界检查敏感字段、权限、编码、错误信息。第四步补充缺失的边界处理。AI生成的代码通常缺少边界处理你需要补上。补的时候遵循最小改动原则不要重写整个函数只加必要的校验和过滤。第五步记录审查结果。把发现的问题和修复方式记录下来形成团队的知识库。下次遇到类似代码时可以直接参考。5.3 一个完整的审查案例假设AI帮你生成了一个“用户反馈提交”功能app.route(/feedback, methods[POST]) def submit_feedback(): data request.get_json() content data.get(content) email data.get(email) rating data.get(rating) feedback Feedback( contentcontent, emailemail, ratingrating, iprequest.remote_addr ) db.session.add(feedback) db.session.commit() send_email( toadminexample.com, subjectfNew feedback from {email}, bodyfRating: {rating}\nContent: {content} ) return jsonify({status: ok, id: feedback.id})我来按三条边界审查这段代码。输入边界审查content、email、rating都来自用户输入没有做任何校验。content可能包含恶意内容email可能格式不正确rating可能是任意值。修复加长度限制、格式校验、范围校验。执行边界审查send_email是同步调用如果邮件服务超时整个请求会阻塞。db.session.commit()没有异常处理如果数据库写入失败会返回500错误。修复邮件发送改为异步数据库操作加异常处理。输出边界审查返回了feedback.id这个ID是自增的可能被用来枚举反馈数量。错误信息没有处理如果数据库出错会返回堆栈信息。修复返回一个不透明的标识符加全局异常处理。修复后的代码import re from celery import shared_task shared_task def send_feedback_email(email, rating, content): # 异步发送邮件 pass app.route(/feedback, methods[POST]) def submit_feedback(): try: data request.get_json() if not data: return jsonify({error: invalid request}), 400 content data.get(content, ) email data.get(email, ) rating data.get(rating, 0) if not isinstance(content, str) or len(content) 2000: return jsonify({error: invalid content}), 400 if not re.match(r^[^][^]\.[^]$, email): return jsonify({error: invalid email}), 400 if not isinstance(rating, int) or rating 1 or rating 5: return jsonify({error: invalid rating}), 400 feedback Feedback( contentcontent, emailemail, ratingrating, iprequest.remote_addr ) db.session.add(feedback) db.session.commit() send_feedback_email.delay(email, rating, content) return jsonify({status: ok}) except Exception: db.session.rollback() return jsonify({error: internal error}), 500这个案例展示了三条边界审查的完整过程。修复后的代码在输入边界做了校验在执行边界做了异步和异常处理在输出边界做了错误信息过滤。5.4 审查流程的注意事项注意事项一不要追求完美。安全审查的目标是降低风险不是消除所有风险。把精力集中在最关键的边界上不要为了一个低风险问题花大量时间。注意事项二结合业务场景。同样的代码在不同业务场景下风险不同。一个内部工具的用户输入校验可以宽松一些一个面向公网的服务就需要严格校验。注意事项三持续更新。AI编程助手在进化它生成的代码质量在提高但新的攻击手法也在出现。审查清单需要定期更新把新发现的边界问题加进去。注意事项四团队协作。审查不是一个人的事。把审查清单分享给团队让每个人在提交AI生成代码前先自查。这样可以大大减少审查的工作量。6. 常见问题与排查技巧实录6.1 AI生成代码的安全审查常见问题在实际操作中我遇到过很多关于AI生成代码安全审查的问题。这里整理几个最典型的附上我的排查思路和解决方法。问题一AI生成的代码看起来没问题但总觉得哪里不对。这是最常见的情况。我的经验是当你觉得“哪里不对”的时候通常是因为代码缺少了某个边界处理。这时候不要凭感觉按三条边界的检查清单过一遍很快就能定位到问题。问题二AI生成的代码太多审查不过来。这是效率问题。我的做法是优先审查跨越信任边界的代码纯内部逻辑可以快速扫过。另外可以让AI自己生成安全审查清单然后你按清单核对效率会高很多。问题三修复了AI生成的代码后功能不正常了。这是因为边界处理改变了代码的行为。比如加了输入校验后原本能通过的输入被拒绝了。解决方法是先写测试用例覆盖正常和异常输入修复后跑一遍测试。问题四不确定某个操作是否跨越了信任边界。判断标准很简单如果这个操作的数据来源是外部的或者这个操作会影响外部系统那它就跨越了信任边界。不确定的时候按“跨越了”来处理。问题五团队里其他人不重视AI生成代码的安全审查。这是流程问题。我的做法是先把审查流程跑通用实际案例证明它的价值然后推动团队采纳。不要一上来就要求所有人执行先做出效果。6.2 排查技巧速查表问题现象可能原因排查方向接口返回了不该返回的数据输出边界缺少字段过滤检查序列化逻辑用户能操作别人的数据执行边界缺少权限校验检查资源归属校验特殊输入导致服务异常输入边界缺少校验检查输入处理逻辑日志中出现异常内容输出边界缺少转义检查日志写入逻辑服务在高并发下变慢执行边界缺少资源隔离检查共享资源使用错误信息暴露内部细节输出边界缺少错误处理检查异常处理逻辑这张表可以贴在工位上遇到问题时快速定位排查方向。6.3 独家避坑技巧技巧一让AI自己审查自己。你可以把AI生成的代码再喂给AI让它从安全角度审查。虽然AI的审查不一定完整但它能发现一些你忽略的问题。我的做法是让AI分别从输入、执行、输出三个角度审查然后我复核它的发现。技巧二用“攻击者视角”读代码。审查时不要想“这段代码是做什么的”而要想“如果我想攻击这个系统我会从哪里入手”。这个视角的转换能让你发现很多平时忽略的问题。技巧三关注“默认行为”。AI生成的代码大量依赖框架的默认行为。比如模板引擎的默认转义、ORM的默认参数化、HTTP客户端的默认超时。这些默认行为大部分是安全的但有些不是。审查时要确认这些默认行为是否符合安全要求。技巧四建立自己的“边界模式库”。把常见的边界处理方式整理成代码片段审查时直接对照。比如输入校验的模式、权限校验的模式、输出过滤的模式。这样审查速度会快很多也不容易遗漏。技巧五定期回顾已修复的问题。每隔一段时间回顾一下之前修复过的边界问题看看有没有类似的代码没有修复。AI生成的代码有很强的模式性一个问题往往会在多个地方出现。6.4 一个真实的排查案例有一次AI帮我生成了一个“文章评论”功能。代码逻辑很简单用户提交评论服务端保存并返回。我按三条边界审查了一遍输入边界加了长度限制和内容过滤执行边界加了频率限制输出边界过滤了敏感字段。看起来没问题。但上线后有用户反馈说评论提交后偶尔会消失。我排查了很久最后发现是执行边界的问题AI生成的代码在保存评论后会同步更新文章的评论计数。如果两个用户同时评论同一篇文章计数更新会出现竞态条件导致计数不准确前端根据计数判断评论是否提交成功计数不对就以为提交失败了。这个问题在代码审查时很难发现因为它不是安全漏洞而是并发问题。但它本质上也是执行边界的问题共享资源的并发访问没有做隔离。修复方法是把计数更新改为原子操作或者用消息队列异步处理。这个案例给我的教训是执行边界的审查不仅要看权限和隔离还要看并发和一致性。AI生成的代码在单线程场景下没问题但在并发场景下可能出问题。7. 工具与流程的配合7.1 静态分析工具能帮上什么忙静态分析工具可以自动发现一些常见的边界问题比如SQL注入、XSS、路径遍历。但静态分析工具有两个局限一是误报率高二是无法理解业务上下文。我的做法是把静态分析工具作为第一道过滤用它快速扫一遍AI生成的代码把明显的问题找出来。然后人工审查剩下的部分重点关注静态分析工具无法覆盖的边界问题比如权限校验、业务逻辑边界。常用的静态分析工具包括SonarQube、Semgrep、CodeQL等。这些工具都支持自定义规则你可以把三条边界的检查点写成规则让工具自动检查。7.2 如何把审查流程嵌入开发流程审查流程要嵌入开发流程才能持续执行。我的做法是在代码提交前加一个检查环节AI生成的代码必须经过边界审查才能提交。审查可以是一个人做也可以是团队交叉做。具体操作上可以在代码仓库中加一个审查清单文件提交代码时对照清单自查。也可以在CI流程中加静态分析步骤自动检查常见的边界问题。关键是让审查成为习惯而不是一次性的活动。我见过很多团队一开始很重视过一段时间就松懈了。解决方法是把审查结果和代码质量指标挂钩让审查有可见的产出。7.3 审查流程的持续改进审查流程不是一成不变的。随着AI生成代码的质量变化和攻击手法的演进审查流程需要持续改进。我的做法是每季度回顾一次审查流程看看哪些检查点已经过时、哪些新的边界问题需要加入。回顾的依据包括实际发现的问题、静态分析工具的误报、团队成员的反馈。另外我会定期收集AI生成代码的边界问题案例整理成内部文档。这些案例比抽象的检查清单更有说服力也更容易被团队成员接受。8. 一些个人体会这套方法我用了大半年从最初的“凭感觉审查”到现在的“按边界审查”最大的变化是效率。以前审查AI生成的代码我总是不放心要逐行看花大量时间还不一定看得全。现在按三条边界过一遍十分钟就能完成一个接口的审查而且覆盖度更高。另一个体会是AI生成的代码在边界处理上确实有规律可循。它倾向于省略输入校验、忽略权限检查、过度返回数据。知道这些规律后审查时就有了重点不用面面俱到。最后分享一个小技巧如果你不确定某个边界处理是否必要就问自己一个问题——“如果这段代码被恶意用户利用最坏的结果是什么”如果最坏结果是数据泄露、权限提升、服务不可用那这个边界处理就是必要的。如果最坏结果只是功能异常那可以适当放宽。这个判断标准不是绝对的但能帮你在审查时快速做决策。毕竟安全审查的目标是管理风险不是消除所有风险。把精力集中在真正重要的边界上才是可持续的做法。