Appearance
Shipping and Launch 解决的是 AI 写完代码后缺少上线收尾的问题。真正的发布要看测试、构建、安全、性能、监控、回滚和上线后验证，而不是只把代码推到生产环境。
AI 写完功能怎么上线：Shipping and Launch 怎么用
下载 shipping-and-launch 中文版 Skill ZIP
AI 写完代码，不代表功能已经上线。
测试通过，也不代表用户不会遇到问题。
代码能部署，更不代表你知道出事后怎么回滚。
shipping-and-launch 这个技能关注的是发布收尾：怎么把一个功能安全地交到用户手里。
上线前要检查什么
个人项目也需要上线清单，只是可以轻一点。
最少要看这些：
- 相关测试是否通过。
- 构建是否成功。
- 关键用户路径是否走过。
- 有没有硬编码密钥、调试日志、临时 TODO。
- 新增接口有没有输入校验和权限检查。
- 页面或接口性能有没有明显退化。
- 出问题时怎么回滚。
这不是大公司流程病，而是减少半夜救火。
发布不是一次性动作
很多人把发布理解成“push 到 main，然后等 CI 部署”。
这只是部署。
发布还包括：
- 部署前知道要验证什么。
- 部署中知道哪里看日志和错误。
- 部署后走一遍关键路径。
- 指标异常时知道怎么撤回。
如果你让 AI 帮你做发布准备，不要只说“准备上线”。要让它列出当前项目适用的检查项。
小项目怎么做轻量发布清单
不需要上来就做完整 feature flag、灰度、监控平台。
个人站点或小工具，可以用一张轻量清单：
md
上线前检查：
- 本地构建通过。
- 关键页面能打开。
- 新增链接没有 404。
- 没有硬编码密钥和调试日志。
- 部署脚本没有改错目标目录。
- 回滚方式明确：回退到上一个 commit 或重新部署上一版产物。
上线后检查：
- 生产首页能访问。
- 新页面能访问。
- 关键按钮能点击。
- 统计或日志没有异常错误。这已经能挡住很多低级事故。
有用户的产品要更谨慎
如果是登录、支付、数据迁移、多租户后台，发布就不能太随意。
你要提前确认：
- 数据库迁移能不能回滚。
- 新旧数据是否兼容。
- 是否需要分批开放。
- 错误率和延迟看哪里。
- 谁负责观察上线后的异常。
- 出事后先关开关，还是回滚版本。
这些问题不应该在事故发生后才问。
让 AI 帮你做上线准备
AI 很适合做 checklist，但前提是你要给它项目上下文。
比如：
md
请根据这次 diff，生成上线前检查清单。
项目是 VitePress 站点，用 Bun 构建。
这次改动包括 Markdown 内容和 sidebar 配置。
不要生成大公司灰度流程，只列这个项目真正需要的检查项。这样它就不会给你一套 Kubernetes、feature flag、SRE 值班表。
发布清单要贴合项目规模。
回滚计划要提前写
上线前最该问的问题是：如果坏了，怎么退？
静态站点可能是重新部署上一版。后端服务可能是回滚镜像。数据库迁移可能需要更仔细，因为不是所有迁移都能安全撤回。
只要涉及数据结构变更，就要多想一步：
- 新代码能不能读旧数据？
- 旧代码能不能读新数据？
- 回滚后新增数据怎么办？
- 是否需要先做兼容迁移，再切代码？
AI 可以帮你列风险，但不要让它替你拍板。
上线后也要验证
发布结束后，不要只看 CI 绿色。
至少走一遍真实路径：页面能打开，接口能返回，关键按钮能用，日志没有新增错误。
如果是内容站，就检查新文章、sidebar、内部链接、统计脚本。如果是应用，就检查登录、核心功能和错误监控。
这一步很容易省，出问题时也最容易后悔。
你可能还需要
同类技能：
如果功能已经写完，下一步不是急着发布，而是先确认它可回滚、可观察、可验证。