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