AI 帮我写的代码，上线前到底能不能信？我跑了一轮代码安全体检

功能跑得越快，越要补上那个没人看的步骤：代码上线前，有没有人认真问过一句"这里有没有危险写法"。

先说我遇到的真实情况

我最近准备把一个工具站做上线。项目里有一部分后端代码是 AI 辅助生成的，功能测试也过了，看起来能跑。

但越接近上线，我越不踏实：

AI 生成代码的问题不是"写不出来"，而是它会把 f-string 拼 SQL、pickle.loads、subprocess.run(..., shell=True) 这些写法写得非常自然。只要功能正常，人眼很容易跳过去。

比如这一段：

python 复制代码

username = request.form["username"]
password = request.form["password"]

sql = f"SELECT * FROM users WHERE username='{username}' AND password='{password}'"
cursor.execute(sql)

如果只看"能不能登录"，它是能跑的。

但它最应该被上线前拦下来，因为 username 和 password 来自用户输入，直接拼进 SQL 就可能是注入点。

再看这一段：

python 复制代码

encoded = request.args.get("data")
data = pickle.loads(base64.b64decode(encoded))

用 pickle.loads 处理来自请求的参数，轻则逻辑异常，重则可能被构造恶意序列化数据。

所以我的判断是：AI 代码可以帮我写得快，但不能替我做安全检查。

我要的不是"保证没漏洞"，而是先筛出该看哪里

我不是安全工程师，也不想假装自己能人工审计整个项目。

上线前我需要的是三件事：

在本地跑一遍，不把还没公开的代码传给别人；
快速得到"哪里可能有危险"的问题清单；
扫完之后，我知道哪些要人工看，哪些可以跳过。

我用 code-audit-cli 做了一个实验：拿一份自己准备的示例项目，先扫描，再人工逐条看结果。

安装很简单：

bash 复制代码

python -m pip install dist/code_audit_cli-0.1.0-py3-none-any.whl

运行扫描：

bash 复制代码

code-audit demo_app --format json --output scan.json

第一轮结果大概是这样：

级别	规则	风险原因	示例片段
High	`sql-concat`	SQL 由 f-string 拼接生成，可能被注入	`SELECT * FROM users WHERE username='{username}'`
High	`pickle-loads`	反序列化不可信输入，可能执行危险代码	`pickle.loads(base64.b64decode(encoded))`
High	`eval-exec-subprocess`	使用 shell 执行动态命令	`subprocess.run(command, shell=True)`
Medium	`raw-html-reflect`	用户输入直接反射到 HTML，可能需要编码	`results for {query}`
Medium	`unvalidated-file-path`	文件路径可能来自用户输入且未限制范围	`(WEB_DIR / file_name).resolve()`

汇总结果：high=3、medium=2、low=0、total=5。

这个结果不算"这个项目被黑定了"，但它足够告诉我：上线前应该先把这三处 high 看一遍。

我为什么先重视三条 High

SQL 拼接

python 复制代码

sql = f"SELECT ... WHERE username='{username}' AND password='{password}'"

用户输入直接进入 SQL 字符串。真正修复应该改成参数化查询，而不是靠过滤关键字。

pickle.loads

python 复制代码

pickle.loads(base64.b64decode(encoded))

反序列化不可信数据时，恶意载荷可能触发任意代码执行。能用普通 JSON 的地方，不要随便上 pickle。

subprocess + shell=True

python 复制代码

subprocess.run(command, shell=True)

如果 command 里有用户可控内容，shell=True 会放大风险。优先用参数列表形式，避免让 shell 解释整段字符串。

这些都不是"扫描器自己发现漏洞"，它们只是把可疑代码从几千行里捞出来。最后要不要上线、怎么修，还是得人来判断。

拿到结果之后，我还做了两件事

1. 处理误报，而不是无脑全信

启发式规则一定有误报。比如规则只是看到了"看起来像"的写法，不一定代表它真的能被打。

项目里如果某个规则确实不适用，可以临时跳过：

bash 复制代码

code-audit demo_app --skip-rule raw-html-reflect

真正上线前，我不会只执行这一句，而是逐条人工确认后再决定是否忽略。

2. 先生成基线，以后只关注新增问题

一次扫描的价值有限。代码还会继续改，改了可能又会带回危险写法。

所以我会先保存基线：

bash 复制代码

code-audit src --write-baseline baseline.json

后续每次改动后只跑增量：

bash 复制代码

code-audit src --baseline baseline.json

这样"上线前检查"不会变成一次性心理安慰。

最后，说说 AI 代码上线前最缺什么

AI 生成代码真正的问题，不是"它有没有漏洞"，而是：

一个项目从"AI 能写出来"到"敢上线"，中间缺少一道可重复的安全检查。

自动扫描不会替我证明代码绝对安全，也不会替代人工审计。它能做的是让这步检查变快、可复现、能接入流程。

如果你也准备把 AI 辅助写的代码放到线上，我的建议是：先拿一个示例项目跑一遍，看清报告长什么样，再决定要不要把它接进自己的发布流程。

我用的是 code-audit-cli 代码安全体检 CLI，它支持本地扫描并输出 Markdown、HTML、JSON 和 SARIF，也可以接 CI。当前定位是轻量快速体检，不是"扫一次就万事大吉"的万能工具。

你觉得 AI 生成代码上线前，最该先补的是哪一步？