功能跑通，但产品不可用
「宝贝轻松记」不是一个后台表单，也不是一个只要字段正确就算完成的工具。
它面向的是新手父母，产品气质需要温柔、轻量、低压力。页面不只是承载功能，还要让用户愿意每天打开。
早期我让 AI 按阶段实现启动分流和宝宝档案功能。功能层面看，流程确实跑通了：页面能打开，数据能填，逻辑能走。
但实际看效果时，问题很明显：
- 页面像默认模板；
- Material / Compose 风格痕迹太重；
- 视觉源里的温暖感没有还原；
- 页面结构能用，但不像宝贝轻松记；
- 从产品视角看，不能接受。
这不是简单调几个颜色和圆角能解决的问题。
真正的问题不是没有视觉源
当时项目并不是没有设计依据。
已经有 PRD、UI Spec、流程图、HTML/CSS 视觉源和样式 token。理论上，AI 有足够多的材料去实现页面。
但失败说明一个更关键的问题：
有视觉源，不等于 AI 会自动按视觉源施工。
如果直接让 AI “实现这个页面”，它很容易在理解后重新设计一遍。它会补默认组件，会按自己熟悉的范式组织布局，会把“能跑”放在“像不像”前面。
对重体验产品来说，这个顺序是错的。
修正后的流程：先静态还原，再接业务
后来我把流程改成两段。
第一段只做静态 UI 还原：
冻结视觉源
↓
拆样式 token
↓
拆组件
↓
还原页面骨架
↓
对照视觉源验收这一阶段不急着接 Room、Repository、ViewModel、权限、录音、ASR。它只回答一个问题：页面像不像宝贝轻松记。
第二段才接业务：
静态页面通过
↓
接入真实状态
↓
接入数据流
↓
处理异常和边界
↓
功能验收这样 AI 的自由度会小很多。它不再同时处理视觉、架构、业务、状态和数据，而是在每个阶段完成一个明确目标。
为什么不能让 AI 一步到位
AI 很容易给人一种错觉：既然它能写代码，那就应该可以直接从需求到完整页面。
但产品级 App 的页面并不是一坨代码。它同时包含：
- 信息层级；
- 视觉气质；
- 组件复用；
- 状态切换；
- 数据绑定；
- 异常反馈；
- 生命周期；
- 测试与验收。
这些东西如果一次性交给 AI，结果往往是“都有一点，但都不够稳”。
对个人开发者来说，最危险的不是 AI 不会做，而是 AI 做得太快，让你误以为流程可以省掉。
AI 协作需要事实源，也需要验收门
这次之后，我对 AI 协作的理解变得更具体。
事实源很重要，但事实源不是越多越好。它要能被 AI 找到、理解、执行，并且要对应明确的验收标准。
比较有效的组合是：
- PRD 说明产品目标；
- UI Spec 固定页面结构；
- HTML/CSS 视觉源固定视觉结果；
- token 文件固定颜色、字号、间距；
- 组件清单固定复用边界；
- 验收清单固定放行标准。
如果只有文档，没有验收门，AI 仍然可能写偏。
最后沉淀下来的原则
这次 UI 还原失败对我来说很有价值，因为它把一个模糊感觉变成了明确流程。
以后类似页面，我不会再让 AI 直接“把功能做完”。
更稳的路径是：
先确定视觉事实源
再做静态 UI
再截图对照
再接真实业务
再做状态和异常验收AI 的作用不是替我跳过这些步骤，而是让每一步执行得更快。
产品判断、审美判断、验收判断，仍然要留在人手里。