一篇来自 SafeWeave 博客的分析文章指出，AI 编程助手（如 Cursor）生成不安全代码的根源，并非模型缺乏安全知识，而是其训练数据主要来自教程和问答网站，而非经过安全审查的生产代码。这些教学代码为了可读性，通常会刻意省略安全控制。
作者用一个实验验证了这一点：让 Cursor 为一个 Express API 添加搜索端点，它生成了存在 SQL 注入漏洞的代码；但把这段代码原样粘贴回去询问是否安全，模型却能准确指出问题并给出参数化查询的修复方案。这说明模型"知道"安全写法，但生成代码时却走了另一条路径。
教程代码在传播过程中，作者附带的"生产环境请勿这样做"等警告往往被丢弃，只有代码片段被大量复制。这导致训练语料中不安全代码模式占绝对多数，而安全警告却很少见。提示模型"写安全代码"只能影响明确提到的模式，无法覆盖所有细节，且随着对话变长，默认行为会重新占据主导。
文章建议，不要依赖模型自我审查，而应使用独立的确定性工具（如 semgrep、gitleaks）或 pre-commit 钩子来检查生成代码。这类工具不依赖模型的"直觉"，能系统性地发现教程式默认写法产生的问题。作者也提到其开发的 SafeWeave 可作为 MCP 服务器接入 Cursor 和 Claude Code 进行代码检查。
#GitHub #开源 #AI编程 #Cursor #代码安全 #SQL注入 #DevSecOps
@GitHubTrendingHub