AI生成应用上线前的工程自检清单

AI 写出来的应用，能在自己的电脑上点通流程，离交付还差多远？这篇文章给出的答案很具体：换台机器、重启服务、输错参数、停掉数据库，再看看它还能不能正常工作，以及出错后能不能查清原因。

作者列了 10 项检查，覆盖安装、配置、超时、输入、数据库启动、迁移、健康检查和日志。没有复杂架构，也没有实测对照数据，但很适合拿来检查 AI 编程留下的工程缺口：页面能跑，往往只证明正常流程走通了。

换台电脑还能跑，才算通过第一关

前两项检查解决的是同一个问题：项目是否依赖你机器上的隐形条件。

先把仓库克隆到空目录，重新安装并运行。已有的依赖目录、本地配置、没提交的文件，都可能让开发环境看起来一切正常。干净目录会把这些条件暴露出来。

接着，使用 CI 流水线实际执行的干净安装命令。作者没有给出具体命令，不能替他指定某个包管理器。重点是本地验证与 CI 使用相同的安装方式，尤其要检查锁文件和依赖清单是否一致。

第三项虽然在原文里漏了编号，内容却不能漏：搜索 diff 中的密钥、token 和连接字符串。AI 可能把示例配置直接复制进业务代码。作者建议将秘密放进环境变量，并确保环境文件被 Git 忽略。

这三项分别检查「环境能否重建」「依赖能否一致安装」「配置有没有混进代码」。它们检查的不是界面，而是别人能否接手这个项目。

别只测正确输入，还要测试等待和失败

作者接下来的要求很朴素：主动让应用难受一次。

对外部调用设置超时，并检查超时后用户会看到什么。请求迟迟不返回时，页面一直转圈并不能帮助用户判断该重试、修改输入，还是稍后再来。原文没有给出统一的超时值，需要按调用场景决定。

输入验证也一样。至少试三类数据：空字段、应该填数字却填了文本、远超预期范围的值。检查目标不是单纯「没有崩溃」，还包括错误提示是否让人知道下一步该做什么。

最后一项把故障测试推进到服务层：停掉数据库、让某个路由抛错、删除一个环境变量，然后读日志。

错误发生时，日志应该告诉你哪里失败、什么失败。

如果日志里只有一句含糊的报错，应用即使暂时能用，也很难在故障时维护。对 AI 生成的接口代码，这一步尤其适合检查异常是否被吞掉，以及失败路径是否留下了足够线索。

数据库启动、迁移和健康检查，不能混成一件事

原文最有工程含量的部分，是区分服务之间的启动顺序。

API 进程启动了，不代表 Postgres 已经能接受连接。作者要求声明依赖，并等待数据库真正就绪。否则，第一次请求可能撞上数据库尚未准备好的窗口，得到难以理解的失败。

迁移则应该从应用启动路径中拆出来。放在启动脚本里的迁移会随每次重启执行，多实例启动时还可能同时运行。

作者以 Flisk 为例：迁移由独立的 migrator 资源承担，配置为 appType: migrator，顺序排在 Postgres 之后、API 之前。flisk doctor 会标记在服务自身启动脚本中执行迁移的情况。这是工具提供的具体检查，不能直接推成所有项目都已有的保障。

健康检查也要验证真实依赖。一个永远返回 200 的路由，只能说明进程还活着。作者同时强调检查要足够轻，才能持续执行。

还有一项容易被忽略：工具生成的 Dockerfile 或路由配置，应修改生成源，而非直接修改产物。否则，下次生成就可能覆盖手工改动。Flisk 会在 flisk up 启动前，将生成文件与保存的快照比较；发现手工修改后阻止启动，并指出文件。

我的判断

这份清单的价值，在于把验收从「点通页面」推进到「能够重建、承受异常、定位故障」。这些检查成本通常可控，也比继续让 AI 打磨正常流程更接近交付需要。

但它是一份经验清单。作者没有提供样本、失败率或修复前后的数据，「多数项目前三项能过、后面会垮」只能视为经验判断。

有些表述也需要带着前提读。锁文件与依赖清单不一致是否导致 CI 失败，取决于实际安装命令；迁移「只运行一次」则没有交代失败重试、多实例协调等细节。健康检查同样没有区分进程存活与服务就绪，直接把所有外部依赖都塞进检查，未必合适。

Flisk 展示的是一种实现方式。已有 CI、迁移任务和部署编排的团队，更适合把这些检查补进现有流程，无须因这份清单更换工具。

能拿来做什么

• 给 AI 生成的前端或全栈项目做一次干净克隆验收，使用 CI 的安装命令启动，并核对必需环境变量是否有清楚说明。
• 检查 Node API 的外部调用和输入边界，实际触发超时、空值、类型错误与越界值，同时观察页面提示和服务端日志。
• 使用 Postgres 的项目，把数据库就绪、迁移完成和 API 启动分别核对，确认迁移是否仍藏在应用启动脚本里。
• 在交付前安排一次小型故障演练：停止数据库、删除必需配置、触发路由异常，逐项确认错误能被识别和定位。