发布第一个可用版本
发布首版要把范围冻结到可交付状态，记录版本并准备回退。发布后先确认核心任务可完成，再邀请用户使用。
- 发布任务应用首版，完成发布清单、版本记录、核心冒烟测试和回退演练。
- 发布清单、数据迁移和回滚
- 检查发布第一个可用版本后，应当发布任务应用首版，完成发布清单、版本记录、核心冒烟测试和回退演练，并保留用户任务观察、改动差异、冒烟测试和版本复盘作为可重复检查的依据。
- 完成 8.2「建立可靠的 AI 开发工作流」
FOUNDATION
必须理解
发布第一个可用版本意味着真实用户能在真实环境完成核心任务，并且失败时有恢复办法。它不要求功能齐全，但要求主链路可信。
本课依次讲清发布清单、数据迁移和回滚、移动端、空状态、失败状态和首次使用和真实域名、真实账户和真实数据验证，最后通过“邀请三位真实用户操作，观察而不替他们解释”检查学习结果。
试营业不会提供完整菜单，却必须保证营业时间、招牌菜、付款和食品安全都真实可用。不能只在厨师自己的桌上演示。
任务应用首版发布登录、创建、查看、完成与删除；使用正式域名和数据库，准备迁移、备份、回滚和用户反馈入口。
发布清单、数据迁移和回滚
发布清单会把代码、环境配置、数据库、域名和最后验证放到一条线上。构建成功只是其中一格，不能代表用户已经能正常使用。
基础概念
发布清单把代码版本、配置、依赖、数据库迁移、域名、监控、备份和验证组织成有顺序的交付过程；回滚则定义失败时如何恢复服务。
进一步理解
清单每项应有执行者、证据和阻塞条件。构建成功只是代码产物可生成，环境变量、迁移和真实流程仍需单独验证。
数据库变化可能无法随代码一起回滚，发布顺序要保证新旧版本兼容，并在修改真实数据前完成备份。
先部署兼容新旧字段的代码，再迁移并验证，最后启用新功能；错误率升高时关闭开关并切回稳定版本。
回滚不是“再部署一次”四个字。必须写明目标版本、数据兼容、配置恢复、负责人和重新验证方法。
这一小节记住：发布是可观察、可中止、可恢复的过程，不是一条部署命令。
移动端、空状态、失败状态和首次使用
生产数据库迁移前要备份，也要拿带旧数据的副本先跑一遍。代码可以切回旧版本，数据库结构和已经改掉的数据却不一定会自动回来。
基础概念
移动端、空状态、失败状态和首次使用决定用户在非理想条件下能否完成主流程。开发者熟悉产品，不能代表新用户知道入口和下一步。
进一步理解
空状态应解释为何为空并提供主要动作；失败状态保留用户输入并给出恢复；移动端重新安排层级与触摸目标。
首次使用说明应在需要的位置出现，避免大段教程阻挡任务。加载慢、弱网和重复点击也属于真实体验。
新账户打开任务页看到“还没有任务”和清楚的新增按钮；保存失败时标题仍在；手机键盘弹出后提交按钮仍可见。
空状态不是把列表区域留白，错误 Toast 也不能在用户读完前消失且没有恢复入口。
这一小节记住：用第一次来、没有数据、网络失败和小屏四种条件重新走主流程。
真实域名、真实账户和真实数据验证
你天天开发这个产品，当然知道按钮在哪；第一次来的用户并不知道。空账户、说明文字、手机布局、加载和失败提示，都要站在新用户视角重新走一遍。
基础概念
真实验证使用正式域名、真实认证路径和与生产结构一致的数据完成任务。它能暴露本地假数据、预存会话和开发配置掩盖的问题。
进一步理解
建立受控测试账户，从无痕窗口或新设备开始，记录每一步请求与结果。验证数据隔离、邮件、第三方服务和刷新后状态。
测试数据要可识别和可清理，不能拿真实用户敏感数据做随意实验。发布后监控核心成功率与错误，确认流量变化没有新问题。
三位邀请用户从正式域名注册、创建并完成任务；观察而不代操作，记录卡点与服务端错误。
开发者在已登录浏览器打开首页不是端到端验证，也不能证明新账户、权限和数据持久化正常。
这一小节记住：让陌生用户在真实环境独立完成核心结果，才算可用版本。
AI COLLABORATION
AI 如何参与
在发布第一个可用版本这一课，AI 负责根据真实材料解释发布清单、数据迁移和回滚并指出遗漏，学习者负责控制范围、执行修改和核对用户任务观察、改动差异、冒烟测试和版本复盘。
推荐协作顺序
- 1
把核心用户流程和环境清单交给 AI，让它按发布前后分组。
- 2
让每项检查都写出证据和失败后的处理。
- 3
发布后把真实冒烟结果与日志交给 AI 协助判断，但回滚由你确认。
这是首版 Brief、待发布提交、测试结果和部署配置摘要。请生成发布前、发布中、发布后清单，明确每项证据和停止条件。不要索取生产凭证，不自动扩大功能，不省略回退步骤。
清单覆盖代码之外的配置、数据、身份、域名和恢复；冒烟测试以真实用户流程而不是内部接口为中心；发布第一个可用版本的人工验收必须回到真实页面、请求、终端、测试或数据结果，不能用 AI 的文字说明代替。
人工检查清单
- 确认生产环境变量、迁移与备份被单独检查，回滚不会假设数据库自动倒退。
- 让 AI 的发布清单为每项写出真实证据、阻塞条件与回滚动作。
- 从无痕窗口、手机和新账户完成主流程，并在发布后观察错误与成功率。
COMMON TRAPS
常见误区
下面三类问题会让任务看似完成，却经不起刷新、错误输入或真实环境检查。先看现象，再找原因和修正方法。
发布前临时塞功能
- 你会看到
- 未经验证的改动扩大风险
- 为什么发生
- 临近上线时没有足够时间验证新路径，任何新增都会扩大故障面。
- 怎样纠正
- 只修复阻塞发布的问题
部署完成就宣布上线
- 你会看到
- 核心流程在生产配置下失败
- 为什么发生
- 平台完成发布不代表生产变量、域名和核心用户流程都能工作。
- 怎样纠正
- 执行独立冒烟测试
没有可执行回退
- 你会看到
- 故障时只能现场继续修改
- 为什么发生
- 故障发生后再研究旧版本和数据恢复，会把停机时间继续拉长。
- 怎样纠正
- 提前记录版本与恢复步骤
HANDS-ON
动手任务
发布任务应用首版，完成发布清单、版本记录、核心冒烟测试和回退演练。
- 完成 8.2「建立可靠的 AI 开发工作流」
跟着做
- 01
冻结首版功能并记录部署提交。
- 02
完成生产配置、备份和迁移演练。
- 03
在预览环境执行完整主流程。
- 04
发布后用新账户在手机和无痕窗口冒烟验证。
- 05
邀请三位真实用户操作，观察而不替他们解释。
发布任务应用首版，完成发布清单、版本记录、核心冒烟测试和回退演练。
模拟发布后创建任务失败，按回滚卡走一遍判断与沟通，不实际破坏生产数据。
离开本课前，自问四件事
- 发布清单为什么必须包含证据、阻塞条件和回滚？
- 数据库迁移如何影响代码回滚设计？
- 首次使用、空状态、失败和移动端各要验证什么？
- 什么样的操作才算在真实环境完成了端到端验证？
确认完成后，会同步更新学习中心的课程学习进度。