AI 编程最容易让人产生的一种错觉是：
“代码都写出来了，应该差不多了。”
但真正做过几轮项目以后，你会越来越清楚：
代码写出来，和项目能交付，中间还隔着一整段收尾工作。
而这段工作，偏偏最容易被漏掉。
所以我后来把上线前检查也单独整理成了一类 Skill。
为什么交付收尾总是最容易被跳过
因为它不像写代码那样有即时反馈。
你写完一个组件、一个接口、一个测试，很快就能看到结果。
但上线前检查通常是一些看起来不那么“高光”的动作：
- 跑 build
- 跑 migration
- 跑 seed
- 做 smoke
- 看环境变量
- 检查已知缺口
这些动作不性感，但缺任何一项，都可能让项目停在最后一公里。
我后来固定会检查哪些事情
我现在比较稳定的一套检查项是：
- 核心主链路有没有真实走通过
- 数据库迁移能不能执行
- 默认数据和初始化脚本是否齐全
- 核心接口有没有做最小冒烟
- 前端生产构建是否通过
- 环境变量和配置边界是否清楚
- 浏览器 / 代理 / 跨域链路是否明确
- 失败路径和错误提示是否可接受
- 启动、部署、回滚方式是否明确
- 当前已知缺口是否被记录
这些内容看起来像 checklist，但本质上已经是一套很适合复用的流程。
为什么这类流程特别适合写成 Skill
因为它几乎每个项目都会出现，而且检查项的形态也相对稳定。
不管你做的是：
- 小型工具
- 内部系统
- 个人产品
上线前都绕不开这些基本问题：
- 能不能跑
- 能不能重复跑
- 别人能不能接
- 出问题能不能快速判断
如果这些事情每次都靠临场回忆，就很容易漏。
Skill 的价值，就是把这些容易被忘掉的动作固定下来。
一个交付 Skill 里最值得写什么
我现在觉得至少要写清三类东西。
第一类，是检查顺序。
比如先看主链路，再看依赖，再看构建，再看配置，而不是想到哪查到哪。
第二类，是输出格式。
比如要求 AI 最后明确输出：
- 已验证项
- 未验证项
- 当前阻塞
- 剩余风险
第三类，是“做不到时怎么说”。
这点很重要。因为现实里不是每次都能把所有上线动作完整跑完。
如果某一步受环境限制做不了，AI 也应该明确说明：
- 目前卡在哪
- 已经验证到哪一步
- 下一步需要什么条件
Skill 化之后，最大的变化是什么
最大的变化是，团队不再只问：
“代码是不是写完了？”
而会开始问：
- 主链路真的验证了吗
- 生产构建跑过了吗
- 配置讲清楚了吗
- 还有哪些已知缺口
这会让项目从“能演示”更接近“能交付”。
这类 Skill 特别适合和文档配合
还有一个很实际的好处是，它会逼着你把原本散的东西收回来：
- 启动说明
- 环境变量模板
- migration 步骤
- seed 顺序
- smoke 结果
也就是说，交付 Skill 不只是一个检查工具，它还会反过来推动文档和留痕变得更完整。
最后
我怎么把上线前检查整理成一个交付 Skill？
核心不是把流程做重，而是把那些最容易被忽略、但又直接决定项目能不能真正交付的动作固定下来。
AI 很会帮你把“写出来”提速。
而交付 Skill 的价值，是帮你把“收干净”这件事也稳定下来。 我怎么把上线前检查整理成一个交付 Skill？
核心不是把流程做重，而是把那些最容易被忽略、但又直接决定项目能不能真正交付的动作固定下来。
AI 很会帮你把“写出来”提速。
而交付 Skill 的价值，是帮你把“收干净”这件事也稳定下来。
