提示词优化不能解决安全问题，只有流程和责任心才能。
AI coding agents 会让你快速生成代码，但它们不会让你的代码自动安全，不会为安全问题承担责任，不能替代你的专业判断。
你部署的代码，安全责任在你。
根据这个blog的测试： https://blog.tenzai.com/bad-vibes-comparing-the-secure-coding-capabilities-of-popular-coding-agents/
使用AI coding agents 用相同的提示词构建 15 个应用程序，结果发现了 69 个安全漏洞。测试结果显示，Claude Code 产生了 16 个漏洞，是所有 agents 中最多的，而且包含最多的严重级别漏洞。Cursor 和 Replit 表现最好，各产生 13 个漏洞但零严重漏洞。Codex 也产生了 13 个漏洞。即使在提示词中明确要求"实现安全的应用”，这些 agents 仍然会产生严重的安全漏洞。
测试中所有 5 个 agents 都存在授权逻辑漏洞。典型的场景包括管理员可以绕过数据验证直接操作系统，或者通过在 URL 中添加 ?public=true 参数就能绕过认证访问私有数据。更糟糕的是，很多实现只检查用户"是否登录"而不检查角色权限，导致任何登录用户都能删除其他用户甚至管理员账户。
这些漏洞在现实中意味着普通用户可能删除管理员账户，攻击者可以绕过认证访问敏感数据，或者通过权限提升攻击获得更高级别的访问权限。
Agents 不会主动验证业务常识。测试数据中，5 个 agents 中有 4 个允许负数订单数量，这意味着用户可以通过提交 quantity=-10 获得退款而不用退货，5 个 agents 中有 3 个允许负数价格，用户可以创建 price=-100 的商品然后购买它来获利。这些漏洞会直接导致财务损失
CSRF 保护没有被考虑，这意味着用户访问恶意网站时可能被盗刷或执行非预期操作。
安全响应头（CSP、X-Frame-Options、HSTS 等）攻击也没有预防，这让应用容易受到点击劫持等攻击。
Rating Limiting也没有被限制，攻击者可以尝试数千个密码组合来暴力破解账户。
所有 agents 在防护 SQL 注入和 XSS 攻击方面都表现出色。这是因为现代框架默认使用参数化查询和自动转义，这些都是"已解决的问题”，框架已经内置了保护机制，训练数据中也有大量正确示例。这个现象揭示了一个重要规律：agents 只在框架有默认保护的领域表现好，那些需要主动思考和显式配置的安全特性会被完全忽略。
训练数据的偏差：教程代码为了保持简洁，往往会省略授权和验证逻辑。业务规则是"隐含知识”，很少在技术文档中明确列出。安全配置通常出现在"生产部署"章节，而不在快速开始教程中，但 agents 主要学习的是那些简化的快速开始代码。
上下文理解的局限。Agents 擅长遵循技术模式，但无法推理业务常识。当你说"创建订单”，agents 会机械地生成创建 Order 对象的代码，但它们不会停下来问：“等等，负数订单在业务上合理吗？” 这种业务判断需要人类的常识和经验。
优先级的错位。Agents 优先实现功能需求，把安全视为"可选的"而非"必需的”。当提示词说"创建一个安全的 API"时，agents 理解的是"创建一个 API”，“安全的"这个形容词太抽象，无法转化为具体的实现步骤。
说"创建一个用户管理 API"是无效的。我们必须说：
"创建一个用户管理 API，必须包含 JWT 认证且所有端点强制要求，实现基于角色的访问控制分为 admin 和 user，
使用框架内置方案添加 CSRF 保护，
配置安全响应头包括 CSP、HSTS、X-Frame-Options 和 X-Content-Type-Options，
所有输入必须验证且价格和数量必须大于 0、字符串有长度限制，
登录端点添加速率限制每个 IP 每分钟最多 5 次且使用 Redis 存储状态，
记录所有删除和权限变更操作到审计日志。"
不要依赖隐含理解。每一项安全需求都要明确列出，具体到使用什么技术、什么参数、什么阈值。
生成代码后，逐项检查：
认证与授权方面，所有敏感端点都需要认证吗？
实现了角色权限检查而不只是"是否登录"吗？
没有条件性认证路径可以被绕过吗？
输入验证方面，数值字段不允许负数吗？
字符串有长度限制吗？
边界条件比如空值、超大值、特殊字符都处理了吗？
安全配置方面，启用了 CSRF 保护吗？
配置了安全响应头吗？实现了登录速率限制吗？
配置了 CORS 策略吗？
日志与监控方面，记录了认证和授权失败吗？记录了敏感操作吗？确保没在日志中记录密码和 token 吗？
关键原则是将 agent 生成的代码视为"初稿"而不是"成品”。重点检查每个端点的授权逻辑是否完整，数值输入是否可以是负数、零或超大值，管理员能否绕过验证直接操作，错误消息是否会泄露敏感信息如数据库结构或内部路径。
在代码提交前运行静态分析工具。例如，对于 Python 项目使用 bandit -r ./src 进行安全漏洞扫描，使用 semgrep --config=auto . 进行代码模式匹配。对于 JavaScript 项目使用 npm audit 检查依赖漏洞。对于多语言项目可以使用 snyk test 进行通用扫描。
在部署前执行手动渗透测试。尝试提交负数值测试业务逻辑，尝试在移除认证 token 后访问敏感端点测试授权，尝试使用无效的认证信息测试认证绕过等等。
用 agents 来发现漏洞，而不只是生成代码。工作流程是让 Agent A 生成功能代码，然后让 Agent B 在新会话中审计 Agent A 的代码，根据审计结果修复问题，最后人工进行最终确认。
审计提示词应该要求 agent 列出所有授权问题（哪些端点缺少认证、角色检查是否完整）、输入验证问题（哪些字段允许负数或无效值）、业务逻辑问题（是否有不合理的流程）和安全配置问题（缺少 CSRF、速率限制或安全头）。对每个漏洞，agent 应该说明具体位置（文件和行号）、攻击场景（如何被利用）以及修复方案（提供代码示例）。
我们不能说"这是 AI 生成的，不是我写的”。现实是用户自己部署了这些代码，用户自己的名字出现在 git 提交记录中，用户的公司要承担法律责任，数据泄露的责任最终在你身上。
作为开发者，我们的职责是理解你部署的每一行代码，验证代码符合安全标准，为代码的后果负责。AI agent 是工具，就像 Stack Overflow、GitHub Copilot 或代码模板一样。使用工具不能免除专业责任。