上周二测试 GPT-4o 生成的一段 Python 数据处理脚本时，我发现它在处理用户输入时完全没考虑 SQL 注入，直接把敏感数据暴露在了日志里。这种看似“跑得通”但实际“带毒”的代码，在生产环境下就是定时炸弹。

很多人觉得调个 API 就算用 AI 了，其实真正的门槛在于：你怎么确保 AI 重构代码后的逻辑既高效又安全？

别被“看起来能跑”的代码骗了

AI 生成代码有个通病：过度追求逻辑闭环，却忽视了边界防御。如果你只是简单地把一段旧逻辑喂给模型，让它进行 AI 重构代码，结果往往是逻辑变丝滑了，安全性却降级了。

我整理了一份实测对比，看看如果不加干预，直接用 AI 重构的代码会有多离谱：

| 评估维度 | 原始代码 (Legacy) | AI 重构后 (Naive Prompt) | 安全加固后 (Security-Aware) |
| :--- | :--- | :--- | :--- |
| 逻辑复杂度 | 高 (冗余分支多) | 低 (极其简洁) | 低 (简洁但有校验) |
| SQL 注入风险 | 中 (硬编码拼接) | 极高 (追求简洁直接拼接) | 低 (强制使用参数化查询) |
| 异常处理 | 粗糙 | 几乎没有 | 完善 (包含 Try-Except 捕获) |
| 执行效率 | 慢 | 快 | 快 |

如果你想深入研究这类安全逻辑的构建，去 PromptCube 首页 搜一下相关的 Prompt 模板，能少走很多弯路。

三步走：搭建你的 LLM 代码安全评估流水线

我现在的做法是建立一套自动化的 Pipeline。当 AI 生成一段代码后，不会直接上线，而是先经过一个专门的“审计 Agent”。

第一步：环境隔离与静态扫描 (SAST)

首先，绝对不能在本地开发环境直接运行 AI 给的代码。我会用 Docker 容器把运行环境彻底隔离。

配置一个极简的扫描环境：

# 创建一个隔离的沙盒目录
mkdir ai_sandbox && cd ai_sandbox
使用 Bandit 进行 Python 安全扫描 (这是目前最轻量级的工具)

pip install bandit
假设 AI 生成的代码存为 generated_script.py

运行扫描，看看有没有明显的安全漏洞

bandit -r generated_script.py -f txt -o scan_report.txt

运行 bandit 后，如果输出里出现了 High 级别的风险（比如 B608: hardcoded sql string），那这段代码直接打回重做。

第二步：构建 AI 安全评估方法论

单纯靠工具扫描是不够的，工具只能识别已知的模式。真正的 AI 安全评估方法需要结合“语义理解”。

我写了一个简单的评估脚本，利用另一个高参数量的模型（比如 Claude 3.5 Sonnet）来充当“红队专家”。这个过程本质上是让一个模型去审视另一个模型的产出。

import openai
def evaluate_code_safety(generated_code):
    """
    模拟 AI 安全审计 Agent
    """
    prompt = f"""
    你现在是一名资深网络安全专家。
    请评估以下 AI 生成的代码是否存在安全隐患（如注入、内存溢出、逻辑漏洞）：
    
    --- 代码开始 ---
    {generated_code}
    --- 代码结束 ---
    
    请按以下格式输出：
    风险等级：[低/中/高]
    风险描述：[具体说明原因]
    修复建议：[给出具体的防御代码]
    """
    
    # 调用审计模型
    response = openai.ChatCompletion.create(
        model="claude-3-5-sonnet", # 建议用逻辑能力极强的模型做审计
        messages=[{"role": "user", "content": prompt}]
    )
    return response.choices[0].message.content
这里的测试代码是模拟 AI 生成的“坏代码”

bad_code = "import sqlite3\ndef query(user_id): conn = sqlite3.connect('db.db'); conn.execute(f'SELECT * FROM users WHERE id={user_id}')"
print(evaluate_code_safety(bad_code))

第三步：接入工作流自动化

如果你每天要处理成百上千次重构请求，手动跑脚本肯定会累死。我建议把这个逻辑沉淀到 工作流交流 中讨论的自动化链路里。

一个标准的自动化链路应该是这样的：
用户输入需求 -> LLM 重构代码 -> Bandit/Semgrep 静态扫描 -> LLM 安全审计 Agent -> 单元测试 (Unit Test) -> 人工确认/自动部署

避坑指南：那些我踩过的雷

1. 不要迷信“全自动”：我曾经尝试过完全去掉人工环节，结果模型在重构一段涉及文件操作的代码时，把路径拼接写成了 os.path.join('/tmp', user_input)，导致用户可以通过 ../../etc/passwd 访问系统文件。
2. 审计模型的 Prompt 偏见：如果你给审计模型的指令太模糊，它会倾向于说“代码没问题”。在写审计 Prompt 时，一定要强制它“先找茬，再表扬”。
3. 性能与安全的平衡：有时候为了安全，代码会变得非常臃肿（比如加了大量的校验逻辑）。我会对比重构前后的执行耗时，如果安全增量导致性能下降超过 30%，我会重新调整 Prompt 的约束条件。

不要试图一步到位就构建完美的 AI 开发环境。先从一个简单的 bandit 扫描开始，慢慢把你的安全评估维度加进去。