AI现在帮我写了大量代码，确实省下了很多时间。但我有一条从不打破的规则：AI可以写代码，结果仍然必须由我负责。这意味着我不会盲目复制、运行、合并或部署它给出的任何内容。它可能看起来很有把握，同时也可能错得很有把握。
以下是10件我从不让AI未经检查就做的事。
1. 运行命令
AI可能会建议运行 npm install some-package、rm -rf some-folder 或 git reset --hard 这类命令。有时命令是对的，有时则具有破坏性。在运行任何命令之前，我会问自己：这个命令到底做什么？它会影响哪些文件？如果出错，我能恢复吗？如果我不理解这条命令，就不会运行它。绝不仅仅因为AI说安全就去执行。
2. 安装依赖
AI会推荐看起来完全真实的依赖，比如 npm install react-super-auth-helper。但这个名字听起来专业，并不代表这个包真的可信。一个听起来很专业的包名远远不够。我总是自己核实依赖，而不是直接安装。
3. 处理密钥和令牌
.env 文件里可能包含 DATABASE_URL、STRIPE_SECRET_KEY、OPENAI_API_KEY、AWS_SECRET_KEY、JWT_SECRET 等内容。这些不是普通代码片段。我不会随意把它们粘贴进提示词，也不会让AI把它们移到客户端代码里。这在前端项目中尤其危险。如果 const secretKey = "sk_live_..." 出现在浏览器代码里，你的密钥可能就会公开。
4. 编写认证逻辑
认证代码看起来可能很简单：登录、检查密码、创建令牌、完成。但真正的认证涉及的内容要多得多。AI可能生成在演示里能跑、但在生产环境不安全的代码。所以每当AI接触认证相关代码，我都会仔细审查。“能用”对于认证来说远远不够。
5. 修改数据库
一条错误的迁移就可能毁掉真实数据，比如 DROP COLUMN phone_number 或 ALTER TABLE users ...。在运行迁移之前，我会检查：它会影响哪些数据？有没有备份？回滚方案是什么？永远不要把生产数据当成测试数据。数据库变更永远值得第二次检查。
6. 大范围重写
有时候我只是想修一个小问题，AI却回应说改了15个文件。危险就从这里开始。一个小bug可能突然变成更大的问题。我更喜欢小改动。与其说“重写整个功能”，不如说“先找到原因”或“给我最小的可行修复”。小改动更容易理解，也更容易回退。
7. 合并看不懂的代码
这大概是我最大的规则。如果AI给我一段 reduce 里塞了25行逻辑的代码，而我不理解它为什么能工作，我就不会合并它。我会让它逐行解释这段代码。我会问自己：我能向另一个开发者解释清楚吗？如果答案是不能，那我就还没准备好拥有这段代码。因为总有一天这段代码会出问题，而到那时AI未必还在你身边救你。永远不要保留你完全不懂的代码。
8. 相信通过的测试
AI很擅长写测试。但有个有趣的地方：AI可以写出有问题的代码，然后再写出愉快地通过这段错误代码的测试。一个通过的测试并不会自动说明功能是正确的。错误函数加上通过的测试，仍然可能是错误的功能。测试结果需要和实际行为一起看，而不是只看绿灯。
热门跟贴