1. AI 写代码这件事真正的风险不在生成端这两年我参与过好几个把 AI 编程助手接进研发流程的项目从最早的代码补全到后来的整函数生成、单元测试自动产出再到现在的 Agent 式多文件改写。团队里一开始最兴奋的是“效率”最容易被忽略的却是“安全”。很多人以为 AI 写代码的风险在于它会不会写出逻辑错误的代码其实真正在生产环境里炸过的坑绝大多数都集中在同一个地方输入边界。所谓边界说白了就是外部数据进入你系统的那道门。用户提交的表单、第三方回调的 JSON、上传的文件名、URL 里的查询参数、甚至环境变量和配置中心拉下来的字符串全都是“外部输入”。AI 在生成代码时天然倾向于把注意力放在“主流程能不能跑通”上它会把一个函数写得漂漂亮亮参数直接用、字符串直接拼、数组直接索引至于这个参数是不是空、是不是超长、是不是带了特殊字符它默认“调用方会保证”。而现实世界里调用方永远不会替你保证。这篇文章我想聊的就是当你的代码有相当比例是 AI 生成的时候怎么在“边界”处把输入这件事管住。内容会覆盖为什么 AI 生成的代码在输入处理上特别容易出问题、边界验证到底该放在哪一层、具体的校验手段怎么写、以及我在实际项目里踩过的那些坑。不管你是刚把 AI 接进工作流的新手还是已经在做 AI Native 研发范式实践的团队负责人这里面的东西应该都能直接拿去用。2. 为什么 AI 生成的代码在输入处理上格外脆弱2.1 训练数据的“平均脸”效应AI 编程模型的训练语料里充斥着大量的示例代码、教程片段和开源项目。这些代码有个共同特点为了把核心逻辑讲清楚它们会主动省略掉防御性代码。你在教程里看到的def get_user(user_id): return db.query(user_id)几乎不会带上if not isinstance(user_id, int)这种判断因为教程要的是“一眼看懂”。模型学到的就是这种“平均脸”写法它生成出来的代码自然也是干净利落、毫无防备的。我做过一个不太严谨但很有说服力的统计让同一个模型生成 50 个处理 HTTP 请求参数的函数其中主动做类型校验的不到 8 个做长度限制的不到 5 个做白名单过滤的只有 2 个。这不是模型“不会”而是它在概率上更倾向于输出“看起来正常”的代码而防御性代码在语料里本来就是少数派。2.2 上下文窗口里的“信任假设”AI 生成代码时它的判断依据是你给的上下文。如果你在提示词里写“写一个根据 id 查询订单的函数”模型就会默认 id 是合法的。它没有动机去质疑你的输入因为质疑会显得“不配合”。更麻烦的是当 AI 在一个已有文件里续写代码时它会观察周围代码的风格。如果这个文件里其他函数都没做校验它大概率也不会做——它在模仿而不是在审查。这就导致一个连锁反应一个项目里只要有几个函数没做输入校验AI 在后续生成时就会把这种风格延续下去最后整个代码库的边界都是敞开的。我见过一个真实案例某个服务上线三个月所有接口的参数校验都是靠前端做的后端一行都没写原因就是最初那个核心文件是 AI 生成的后面所有新接口都照着它的样子写。2.3 “能跑就行”的验证盲区AI 生成的代码通常会被拿去跑测试。但问题在于测试用例往往也是 AI 写的而 AI 写的测试用例输入数据也倾向于“正常值”。你让它给一个登录接口写测试它会写test_login_success和test_login_wrong_password很少会主动写test_login_with_10mb_username或者test_login_with_null_byte。于是代码和测试形成了一种默契大家都假设输入是干净的测试全绿上线然后被真实世界的脏数据打穿。提示AI 生成的测试用例默认只覆盖“快乐路径”。边界用例必须由人来补或者用专门的提示词强制模型生成异常输入场景。3. 边界到底在哪里把校验放在正确的层3.1 三层边界模型在动手写校验之前得先想清楚一件事输入从哪来经过哪些层每一层该负责什么。我习惯把边界分成三层来看。第一层是传输边界也就是请求刚到达服务的那一刻。这一层能拿到的是原始字节、HTTP 头、URL、body 流。它的职责是挡住明显不合法的东西body 超过大小限制、Content-Type 不对、请求方法不允许。这一层不该做业务校验因为它还不懂业务。第二层是解析边界也就是把原始数据反序列化成程序里的对象。JSON 解析、表单解析、protobuf 解码都属于这一层。这一层的核心任务是“结构正确”字段存在吗、类型对吗、必填项齐吗。这一层是 AI 最容易漏掉的地方因为它生成的代码经常直接json.loads(request.body)然后就开始取字段。第三层是业务边界也就是进入领域逻辑之前。这一层校验的是“值是否合理”金额不能为负、时间范围不能倒置、状态流转是否合法。这一层和业务强相关AI 更难自动生成到位的校验。3.2 为什么不能只靠一层我见过两种极端做法。一种是所有校验都堆在 Controller 里一个函数几百行全是 if业务逻辑反而找不到。另一种是觉得“框架会帮我挡”比如用了某个 ORM 就以为 SQL 注入不存在了用了某个序列化库就以为类型安全了。这两种都会出问题。正确的做法是分层拦截每层只做自己该做的事。传输层挡体积和协议解析层挡结构和类型业务层挡语义。这样做的另一个好处是当 AI 生成代码时你可以给它一个明确的“模板”每个新接口都必须经过这三层模型只要照着填就行不需要它自己判断该在哪校验。3.3 一个具体的分层示例假设有一个“提交评论”的接口。传输层检查 body 不超过 64KB、Content-Type 是 application/json。解析层用一个 schema 定义{content: string, parent_id: int|null}检查 content 存在且是字符串、parent_id 是整数或空。业务层检查 content 长度在 1 到 2000 之间、parent_id 对应的评论确实存在、当前用户没有被禁言。这三层里传输层和解析层几乎可以完全自动化用框架或中间件就能搞定。业务层需要人写但也可以让 AI 先生成一版然后人来补边界条件。关键是这个结构要先定下来否则 AI 每次生成都是随机发挥。4. 输入校验的实操手段从类型到语义4.1 类型与结构校验schema 优先最基础也最有效的做法是给每个入口定义一个 schema。Python 里可以用 PydanticNode 里可以用 ZodJava 里可以用 Bean Validation。核心思想是先把输入变成一个有类型的对象再让业务代码去用这个对象而不是让业务代码直接操作原始字典。我让 AI 生成接口代码时会强制要求它先写 schema。提示词大概是这样“为这个接口定义一个输入 schema包含字段名、类型、是否必填、取值范围。然后再写处理函数处理函数的参数是这个 schema 的实例不允许直接访问原始请求数据。”这样生成出来的代码边界就自然收紧了。from pydantic import BaseModel, Field, validator class CommentInput(BaseModel): content: str Field(..., min_length1, max_length2000) parent_id: int | None Field(defaultNone, ge1) validator(content) def no_control_chars(cls, v): if any(ord(c) 32 and c not in \n\t for c in v): raise ValueError(content contains control characters) return v这段代码里min_length、max_length、ge都是声明式的AI 很容易学会照着写。no_control_chars这种自定义校验AI 不一定想得到但你可以把它做成一个项目里的公共 validator让 AI 在需要时引用。4.2 长度与体积限制别等内存爆了才后悔长度限制是最容易被忽略、后果又最严重的一类校验。AI 生成的代码经常直接content.split(,)或者for item in items如果 content 是 100MB 的字符串或者 items 是百万级数组服务直接就被拖垮了。我的经验是在解析层就给所有字符串和数组设上限。字符串默认不超过 64KB数组默认不超过 1000 个元素超出直接拒绝。这个限制不需要很精确宁可严一点也不要留一个无上限的口子。对于确实需要大体积的接口单独开白名单并且要在传输层就限制 body 大小。注意长度校验要放在解析之前或解析的同时。如果等 JSON 完全解析成对象再检查长度内存已经被占用了攻击者可以用一个超大 JSON 把你的服务打挂。4.3 字符集与编码看不见的坑最多字符层面的问题是 AI 最不敏感、实际却最容易出事的地方。空字节、Unicode 控制字符、方向覆盖字符、超长组合字符这些东西在正常输入里几乎不会出现但一旦出现可能导致日志截断、数据库存储异常、甚至下游系统解析错误。我的做法是在解析层统一做一次“字符清洗”去掉所有 C0/C1 控制字符保留换行和制表符、拒绝包含空字节的字符串、对超长 Unicode 序列做规范化。这一步可以写成一个公共函数所有字符串字段都过一遍。AI 生成代码时只要在 schema 里引用这个函数就行。4.4 数值与范围边界值要专门测数值校验看起来简单其实边界值最容易出错。AI 生成的代码经常写if age 0但忘了age可能是浮点数、可能是字符串、可能是NaN。我一般要求所有数值字段都明确上下界并且用ge/le这种闭区间写法避免和搞混。对于金额这类敏感数值还要考虑精度问题。AI 可能会用 float 来存金额然后出现0.1 0.2 ! 0.3的经典问题。我的建议是金额一律用整数分或者 Decimal并且在 schema 层就拒绝浮点数输入。4.5 白名单与枚举能穷举就别用黑名单凡是取值范围有限的字段一律用枚举或白名单。状态、类型、排序字段、操作动作这些都应该在 schema 里定义成枚举。AI 有时候会图省事写成字符串然后在业务逻辑里用 if-else 判断这种写法既容易漏又容易被绕过。白名单的另一个好处是它天然防注入。比如排序字段如果允许用户传任意字符串就可能被拼进 SQL 的 ORDER BY 里。用枚举限定成几个固定值这个风险就没了。5. 把校验变成 AI 能学会的“项目惯例”5.1 建立可复用的校验模板光靠每次提示词里写“记得校验”效果很不稳定。更靠谱的做法是在项目里建立一套校验模板让 AI 有样学样。比如在项目根目录放一个validation_patterns.py里面写好常见的校验函数和 schema 基类然后在提示词里告诉 AI“所有输入 schema 必须继承 BaseInput所有字符串字段必须用 SafeStr 类型。”这样做的效果非常明显。我做过对比同一个模型在没有模板的项目里生成 20 个接口平均每个接口有 1.2 个未校验字段在有模板的项目里这个数字降到 0.3。模型不是变聪明了而是有了明确的参照物。5.2 用 lint 规则兜底模板能覆盖大部分情况但总会有漏网的。这时候需要静态检查来兜底。可以写一些自定义的 lint 规则比如“禁止直接访问 request.json”“禁止把未校验的变量传给 db.query”“所有路由处理函数的参数必须是 schema 类型”。这些规则可以在 CI 里跑AI 生成的代码如果违反直接打回。我用的比较多的是基于 AST 的检查Python 里可以用ast模块Node 里可以用 ESLint 自定义规则。规则不用多抓住几个关键点就行原始输入不能直接进业务、字符串拼接不能进查询、数组访问前必须有长度检查。5.3 让 AI 自己写边界测试前面说过 AI 写的测试偏向快乐路径但如果你明确要求它写“异常输入测试”它其实能写得不错。我的提示词模板是“为这个函数写测试覆盖以下场景空值、超长字符串、错误类型、边界数值、特殊字符、并发重复提交。每个场景一个测试用例断言必须明确。”这样生成的测试虽然不一定全面但至少能把最常见的边界覆盖到。然后我再人工补几个刁钻的比如超长 Unicode、嵌套超深 JSON、负数索引之类的。测试写完之后反过来还能用来验证校验逻辑本身有没有漏洞。6. 实操给一个 AI 生成的接口补上边界6.1 原始代码典型的 AI 风格假设 AI 生成了这样一个接口功能是“根据标签查询文章列表”app.route(/articles) def list_articles(): tag request.args.get(tag) limit request.args.get(limit, 20) articles db.query( SELECT * FROM articles WHERE tag %s LIMIT %d % (tag, limit) ) return jsonify(articles)这段代码问题很多tag 直接拼进 SQLlimit 没有类型转换也没有范围限制tag 为空时行为未定义。但它在“正常输入”下确实能跑所以很容易被放过。6.2 第一步定义输入 schema先把这个接口的输入结构化。tag 是必填字符串长度 1 到 50只允许字母数字和连字符limit 是可选整数范围 1 到 100默认 20。from pydantic import BaseModel, Field import re class ArticleQuery(BaseModel): tag: str Field(..., min_length1, max_length50) limit: int Field(default20, ge1, le100) validator(tag) def tag_format(cls, v): if not re.fullmatch(r[A-Za-z0-9\-], v): raise ValueError(tag contains invalid characters) return v6.3 第二步改写处理函数处理函数不再直接读 request而是先构造 schema 实例。构造失败就返回 400成功才进业务逻辑。SQL 改用参数化查询彻底消除拼接。app.route(/articles) def list_articles(): try: query ArticleQuery(**request.args) except ValidationError as e: return jsonify({error: e.errors()}), 400 articles db.query( SELECT * FROM articles WHERE tag %s LIMIT %s, (query.tag, query.limit) ) return jsonify(articles)6.4 第三步补边界测试针对这个接口至少要覆盖这些用例tag 缺失、tag 为空、tag 超长、tag 含特殊字符、limit 为 0、limit 为 101、limit 为非数字、limit 缺失走默认值。每个用例都断言返回码和错误信息。def test_tag_missing(client): resp client.get(/articles) assert resp.status_code 400 def test_tag_too_long(client): resp client.get(/articles?tag a * 51) assert resp.status_code 400 def test_limit_out_of_range(client): resp client.get(/articles?tagpythonlimit101) assert resp.status_code 4006.5 第四步把模式固化下来这个接口改完之后把 schema 和测试模板存进项目模板库。下次 AI 生成新接口时提示词里带上“参考 ArticleQuery 的写法”生成质量会明显提升。这一步是长期收益最大的因为它把一次性的修复变成了可复用的惯例。7. 常见问题与排查技巧实录7.1 校验做了但还是被绕过最常见的原因是校验和实际使用之间出现了“分叉”。比如 schema 校验的是tag但业务代码里又用request.args.get(tag)取了一次原始值。这种问题在 AI 生成的代码里特别多因为它经常在函数中间又去读一次 request。排查方法很简单在业务层禁止直接访问 request 对象。可以用 lint 规则也可以把 request 封装成一个只暴露 schema 实例的对象。只要业务代码拿不到原始输入就不存在绕过的问题。7.2 性能被校验拖慢有人担心每个请求都做 schema 校验会影响性能。实测下来Pydantic 这种库对一个普通对象的校验在微秒级别相比一次数据库查询可以忽略不计。真正影响性能的是那些“深度校验”比如对超大数组逐个元素检查。这种场景应该把校验前移在解析层就限制数组长度而不是等解析完再遍历。7.3 AI 生成的校验逻辑本身有 bugAI 写的校验代码也可能出错比如把and写成or或者边界值写反。我的做法是要求 AI 同时生成校验代码和对应的测试然后人工 review 测试用例是否覆盖了边界。如果测试里没有limit0和limit101这种用例就说明校验逻辑没有被真正验证过。7.4 历史代码太多改不过来存量代码是现实问题。我的策略是“新代码严格老代码渐进”。新接口一律走 schema老接口在下次改动时顺手补上。同时可以在网关层加一层通用校验挡住最明显的异常请求给后端争取时间。不要试图一次性重写所有接口那样风险太大。问题现象可能原因排查方向解决手段校验通过但数据异常业务层重复读取原始输入搜索 request 直接访问封装输入对象禁止直接访问服务被大请求打挂缺少体积限制检查 body 大小和数组长度传输层限制 body解析层限制数组特殊字符导致下游报错未做字符清洗检查日志中的异常字符统一字符清洗函数数值边界判断错误开闭区间写反检查测试用例边界值补ge/le边界测试AI 生成代码风格不一致缺少项目模板检查是否有校验模板建立模板库并写入提示词7.5 一个容易被忽略的点错误信息泄露校验失败时返回的错误信息也可能泄露内部结构。AI 生成的代码经常直接把异常堆栈返回给前端里面包含字段名、类型、甚至数据库信息。我的做法是统一错误响应格式只返回“哪个字段不合法”和“为什么不合法”不返回堆栈和内部路径。8. 我个人的几条实操心得第一把校验当成接口设计的一部分而不是事后补丁。每次让 AI 生成接口第一句话就是“先定义输入 schema”而不是“先写处理逻辑”。顺序变了结果完全不一样。第二模板比提示词更可靠。提示词是临时的模板是持久的。项目里有一套好的校验模板AI 生成质量的下限就被抬高了。第三测试要专门针对边界写不要指望 AI 主动覆盖。我现在的习惯是AI 生成完代码后单独再让它生成一轮“异常输入测试”然后人工补几个极端用例。这一步花不了多少时间但能挡住大部分线上事故。第四不要追求一次到位。边界校验是个持续的过程新接口严格做老接口慢慢补配合 lint 和网关兜底比一次性大重构靠谱得多。第五定期用真实流量回放测试。把线上脱敏后的请求日志拿来跑一遍看看有没有校验没覆盖到的输入形态。真实世界的脏数据永远比你能想象到的更脏。