功能跑得越快，越要补上那个没人看的步骤：代码上线前，有没有人认真问过一句“这里有没有危险写法”。
先说我遇到的真实情况
我最近准备把一个工具站做上线。项目里有一部分后端代码是 AI 辅助生成的，功能测试也过了，看起来能跑。
但越接近上线，我越不踏实：
AI 生成代码的问题不是“写不出来”，而是它会把 f-string 拼 SQL、pickle.loads、subprocess.run(..., shell=True) 这些写法写得非常自然。只要功能正常，人眼很容易跳过去。
比如这一段：
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 就可能是注入点。
再看这一段：
encoded = request.args.get("data")
data = pickle.loads(base64.b64decode(encoded))
用 pickle.loads 处理来自请求的参数，轻则逻辑异常，重则可能被构造恶意序列化数据。
所以我的判断是：AI 代码可以帮我写得快，但不能替我做安全检查。
我要的不是“保证没漏洞”，而是先筛出该看哪里
我不是安全工程师，也不想假装自己能人工审计整个项目。
上线前我需要的是三件事：
- 在本地跑一遍，不把还没公开的代码传给别人；
- 快速得到“哪里可能有危险”的问题清单；
- 扫完之后，我知道哪些要人工看，哪些可以跳过。
我用 code-audit-cli 做了一个实验：拿一份自己准备的示例项目，先扫描，再人工逐条看结果。
安装很简单：
python -m pip install dist/code_audit_cli-0.1.0-py3-none-any.whl
运行扫描：
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 拼接
sql = f"SELECT ... WHERE username='{username}' AND password='{password}'"
用户输入直接进入 SQL 字符串。真正修复应该改成参数化查询，而不是靠过滤关键字。
pickle.loads
pickle.loads(base64.b64decode(encoded))
反序列化不可信数据时，恶意载荷可能触发任意代码执行。能用普通 JSON 的地方，不要随便上 pickle。
subprocess + shell=True
subprocess.run(command, shell=True)
如果 command 里有用户可控内容，shell=True 会放大风险。优先用参数列表形式，避免让 shell 解释整段字符串。
这些都不是“扫描器自己发现漏洞”，它们只是把可疑代码从几千行里捞出来。最后要不要上线、怎么修，还是得人来判断。
拿到结果之后，我还做了两件事
1. 处理误报，而不是无脑全信
启发式规则一定有误报。比如规则只是看到了“看起来像”的写法，不一定代表它真的能被打。
项目里如果某个规则确实不适用，可以临时跳过：
code-audit demo_app --skip-rule raw-html-reflect
真正上线前，我不会只执行这一句，而是逐条人工确认后再决定是否忽略。
2. 先生成基线，以后只关注新增问题
一次扫描的价值有限。代码还会继续改，改了可能又会带回危险写法。
所以我会先保存基线：
code-audit src --write-baseline baseline.json
后续每次改动后只跑增量：
code-audit src --baseline baseline.json
这样“上线前检查”不会变成一次性心理安慰。
最后，说说 AI 代码上线前最缺什么
AI 生成代码真正的问题，不是“它有没有漏洞”，而是：
一个项目从“AI 能写出来”到“敢上线”，中间缺少一道可重复的安全检查。
自动扫描不会替我证明代码绝对安全，也不会替代人工审计。它能做的是让这步检查变快、可复现、能接入流程。
如果你也准备把 AI 辅助写的代码放到线上，我的建议是：先拿一个示例项目跑一遍，看清报告长什么样，再决定要不要把它接进自己的发布流程。
我用的是 code-audit-cli 代码安全体检 CLI，它支持本地扫描并输出 Markdown、HTML、JSON 和 SARIF，也可以接 CI。当前定位是轻量快速体检，不是“扫一次就万事大吉”的万能工具。
你觉得 AI 生成代码上线前，最该先补的是哪一步？
