全盘照搬 AI 的方案，逻辑与安全双双翻车

那天发生了什么

你用 AI 做了一个带用户系统的应用。AI 帮你写了注册、登录、用户数据展示的全套功能。你在自己的电脑上试了试——能注册、能登录、能看到自己的数据。"不错，上线吧。"

上线后第一天，一个稍懂技术的用户发现：只要在浏览器的地址栏里修改一下用户 ID，就能看到其他用户的私密数据。AI 写的认证逻辑里缺少了一个关键的检查——虽然验证了"用户是否已登录"，但没有验证"这个用户是否有权限访问这条数据"。

与此同时，当注册用户超过几百人后，用户列表页面开始变得极其缓慢。AI 选择了一种在小数据量下"看起来没问题"的方案，但在数据量增长后完全无法承受。

安全漏洞和性能问题同时爆发。你不得不紧急下线应用，花了好几天才把两个问题都修好。

这个故事的核心问题不在于 AI 写了有漏洞的代码——AI 不是完美的，这在前面的章节中已经反复提过。真正的问题在于：从头到尾没有人对 AI 的方案提出过任何质疑。

AI 说"用这种方式做认证"，开发者就照做了——没有追问"这种方式安全吗？有没有绕过的可能？"

AI 说"用这种方式加载数据"，开发者也照做了——没有追问"如果数据量增长到一千条、一万条，这种方式还扛得住吗？"

AI 给出方案时的语气和给出正确答案时一模一样——自信、果断、不带犹豫。如果你不主动质疑，就会把这种自信误认为是正确的保证。

不要跳过验证。 AI 的输出在使用前必须经过检验。对于涉及安全的功能（认证、权限、支付），验证的标准要更高——不仅要测"正常能用"，还要测"能不能被绕过"。

主动质疑方案。 每次 AI 给出一个技术方案时，至少问它一个问题："这个方案有什么潜在的风险或薄弱点？"AI 不会主动告诉你，但当你问的时候，它通常能给出有价值的自我审查。

在正常测试之外加入"恶意测试"。 不仅测试功能是否正常工作，还要试着去"破坏"它——修改网址参数看能不能访问其他人的数据、模拟大量用户同时使用看系统会不会崩溃。

在关键节点保持独立判断。 AI 是你的助手，不是你的决策者。方案好不好、安不安全、上不上线——最终的判断权在你手里。