一、问题：它解决的是任务，还是只展示 AI 能力？
我会先用一句不包含技术名词的话描述用户任务。例如：修改简历时能及时发现问题并看到最终版式；从旅行照片里重新找到地点与路线；根据已有衣物、天气和场景完成穿搭并生成不重复的行李清单。
如果一句话里只能看到“大模型、识别、生成、智能推荐”，却看不到用户在什么时刻得到什么结果，说明产品还停留在能力展示阶段。
- 用户是谁，在哪个具体场景下遇到问题？
- 不用这个产品时，他现在怎样完成任务？
- 第一版只改善哪一个关键环节？
- 结果怎样被用户检查、修改或拒绝？
二、范围：第一版是否形成最小闭环？
最小闭环至少包括输入、处理、结果与下一步行动。只有一个“生成”按钮通常不够，因为用户还需要理解结果、纠正错误并把结果带回自己的工作流。
以公开案例为例：Easy Resume 把编辑、实时预览、问题定位和用户采纳连接起来；TabiFun 围绕照片、地点、路线和地图回看组织体验；AI 衣橱 则把入库、每日选择与旅行打包放在同一条生活任务中。它们的共同点不是都使用 AI，而是都有可说明的用户闭环。
三、控制：AI 结果是否给用户保留决定权？
生成内容、改写原文、识别照片或自动整理清单都可能出错。产品需要把不确定性变成可操作界面，而不是隐藏起来。
- 先预览：在写回原数据之前展示建议、差异和影响范围。
- 可采纳：让用户明确选择接受、拒绝或局部修改。
- 可恢复：保存原内容或提供撤销，避免一次错误破坏用户资产。
- 不编造：缺少事实时明确提示，不自动补数字、经历或地点。
四、证据：你证明的是哪一层完成？
我把完成证据分成几个不能互相替代的层级：
- 静态检查：HTML、脚本、链接、元数据和配置格式正确。
- 本地运行：通过真实 HTTP 或应用运行环境打开，主要流程可以操作。
- 视觉与文件结果：移动端没有溢出，导出的 PDF、图片或安装包需要真正打开检查。
- 自动化与 CI：测试和构建在目标系统通过，不能被管道吞掉退出码。
- 生产或真机：部署后的域名、接口、监控，或实体设备上的权限、性能和兼容性得到验证。
只完成其中一层，就只报告这一层。清楚地说“本地已通过、生产待验证”比一句模糊的“全部完成”更可靠。
五、发布：是否有回滚、监控和事实边界？
发布前我会记录当前版本、新版本、切换方式与恢复路径。静态站可以用版本目录和符号链接原子切换；应用需要保留数据库、环境变量和健康检查的边界。发布后要从外部验证正式 URL，而不是只看服务器内部返回 200。
内容同样需要事实边界。产品页写已经存在并能验证的能力；正在开发的新版、尚未公开的仓库和依赖外部权限的功能，都应明确标注状态。
六、数据：下一轮依据什么继续？
早期产品不需要一开始就建立复杂指标体系，但至少要知道当前假设和观察信号。搜索内容可以看抓取、索引、搜索词、点击和到站后的行动；产品流程可以看用户是否走完核心任务、在哪一步退出、哪些建议被采纳。
数据的作用不是证明自己原来就对，而是帮助决定：继续、修改、缩小，还是停止。
发布前的简版清单
- 能够用一句用户任务解释产品，不依赖 AI 术语。
- 第一版核心流程从输入到结果可以完整走通。
- AI 结果有预览、采纳、拒绝或恢复机制。
- 没有用演示数据冒充真实结果，没有补造缺失事实。
- 本地、自动化、生产或真机证据被分别记录。
- 失败时有恢复路径，发布后有可观察信号。
- 页面、文档和对外文案与当前真实状态一致。