AI 做出来的应用的生产就绪检查清单
这就是我们做付费体检时逐条走的那份清单，公开出来，是因为其中大部分你自己一个下午就能做完。它是按哪一条会先出事来排序的，不是按哪一条最容易。
免费 不用注册，不用留邮箱
先看这一项：什么东西是暴露的
这几条的共同点是：等你发现的时候，损失已经造成了。所以不管你的应用是怎么做出来的，它们都排在最前面。
- 在仓库的历史记录里搜密钥，不要只搜当前的文件。一个提交过一次、后来又删掉的密钥，仍然留在历史里，也仍然能用。
- 在自己的网站上打开浏览器开发者工具，看网络面板，检查前端打包产物里都有什么。浏览器能读到的东西，陌生人也能读到。
- 找一个能显示你自己数据的网址，退出登录，再打开一次。如果它还能打开，那其他每一个用户的数据也是一样的。
- 把那个网址里的 id 换成别人的。这是生成出来的代码里最常见的一个洞，因为当初要求生成工具做的是把数据显示出来，不是检查是谁在要。
- 看看你的错误页面写了什么。生产环境里的一段调用栈，等于把你数据库的形状告诉了陌生人。
然后：它停下来的时候会怎么样
- 把进程杀掉，然后看着。它会自己回来，还是就一直死在那里，直到有人发现？
- 你会知道吗？不是问“有没有一个监控面板”——而是问：会不会有一条消息，送到你真的会看的那台设备上，而且赶在客户写信给你之前？
- 在一份副本上，故意部署一个坏掉的版本。把上一个版本弄回来要花多久，以及那条命令你不查资料就知道吗？
- 把这件事写下来：你依赖的那家服务商一旦出故障，会怎么样。你可以决定接受它；重点是你做了这个决定。
然后：你的数据能不能活下来
这一条是大家最有把握、也最常搞错的一条，因为备份通常是存在的，只是从来没有被用过。
- 把一份备份恢复到一个临时环境里。真的动手做一次。没验证过的备份不是备份——那只是一个你寄予希望的文件。
- 查一下备份能回溯到多久以前，以及多久跑一次。每晚一次、保留七天，是一个选择；不知道，不是。
- 确认备份不是只存在同一个账号里——而那个账号里放的，正是被备份的那样东西。
- 如果你的数据库迁移带回滚路径，把它读一遍。一个会删掉线上仍然要用的字段的回滚，是换了个好听名字的数据丢失。
然后：那些会自己过期的东西
- TLS 证书。如果它不是自动续期的，现在就把到期日期写进日历——否则它会挑一个周末过期。
- 域名续费，以及绑定的那张卡是不是还有效。
- 带有效期的 API 密钥和 OAuth 令牌，尤其是支付和邮件服务商那边的。
- 你依赖着搭起来的那些免费额度。它们会变，而变化是以一封你不会读的邮件的形式到来的。
然后：那些无聊的正确性问题
- 每一个对外调用都要有超时。没有超时的请求不会失败——它会挂住，然后把整个进程一起拖住。
- 重试要有上限，而且只能包在可以安全重复的操作外面。给“转账”加一个没有上限的重试，那不是什么容错能力。
- 凡是陌生人能调用的东西都要限流，尤其是你官网页面上的那个表单。
- 测一下超大的输入和很奇怪的输入会怎么样——一个 emoji，一个单引号，一次 10MB 的粘贴。
- 如果两个人可能在同一时刻动手，那就测这种情况，而不是拿一个先后进行的版本顶替。
最后：那条没人写下来的
换一个不是你的人，能把这套东西跑起来吗？如果你的应用只能从你的笔记本、用你的密钥、按照只存在你脑子里的步骤部署，那这个风险已经不是技术风险了。把运维手册写出来——怎么跑起来，怎么部署，怎么回滚——然后交给一个人照着做，你在旁边一句话都不说。他卡在哪里，那里就是你的文档的真实状态。
如果你更希望这件事由别人来做
那就是生产环境体检：我们拿这份清单，在你的代码库和它运行的地方逐条走一遍，然后写清楚：最先出问题的是什么，每一处修复要花多少钱，以及先做哪一件。$450，五个工作日；不管你接下来做不做，报告都归你。
大家最先问的问题
这份清单是专门给 AI 做出来的应用用的吗？
清单本身不是，但它的排序是。这些是生成出来的代码最常没通过的检查；排列的顺序，按的是东西已经上线、已经在承载用户时真正要紧的先后，而不是教科书会用的顺序。
走完一遍要多久？
暴露那一节，一个下午就够。剩下的取决于你发现了什么——而什么都没发现，本身也是一个值得拥有的结果。
读这份东西需要注册什么吗？
不需要。整份清单就在这个页面上。没有下载，没有留邮箱的门槛，也没有 PDF。