历史 Dig · 2026 年 7 月—8 月
AI 产品第一版，先做网页、小程序、App 还是游戏？
第一版常按熟悉的开发工具或看起来完整的产品形态开工，之后才发现真正的门槛是另一件事：用户怎样进入、核心动作需要什么设备能力、是否依赖平台身份与分发，以及哪一步必须在真机上发生。
它和 Workflow 001 的关系
与当前主题的关系
它把“哪个工具最会做 App”改成“这条任务路径到底需要什么载体”。
Workflow 001 先按交付物、运行位置、成本与权限选择工作方式；这条历史记录把同一逻辑落到产品界面：先确定核心动作和目标设备，再决定网页、小程序、原生 App 或游戏运行时。它与 Q01 的运行位置，以及生成后的界面与交付核验直接相连。
当时的记录状态
- AI 产品原型
- 第一版载体
- 标准记录
- 继续调查
- 历史 E2 · 三个项目方案例与两份平台文档 · 无同题跨平台试跑
当时的建议
当时的判断
没有默认载体：先冻结动作，用必要条件排除，再在真机上完成一次。
展开完整判断与退回规则
不要先选产品类别。先冻结一个“进入—动作—可见结果”的交互契约，再列出目标用户与设备、必要硬件、身份与分享关系、离线或后台要求、审核与付款边界。用排除法选择承诺最小、又能在目标设备完成这条路径的载体；模拟器和截图只用于检查布局，最终判断必须来自一次真机路径。网页、小程序、原生 App 或游戏运行时都不是默认答案。
- 适合谁
- 已经能写出一个具体用户动作，却在网页、小程序、原生 App 和游戏运行时之间反复换工具的个人与小团队
- 为什么当时值得看
展开说明
载体选得过重，会在核心动作尚未成立时提前引入账号、审核、签名、权限、适配和维护；选得过轻，则可能把必要的设备能力或平台关系藏到最后。两种情况都会把“能不能完成一次”误写成“已经做了多少界面”。
- 这份判断到哪里为止
展开说明
Fly Pieter 是作者自述，不能用其收入或传播数字证明网页导致成功；SpookSeek 的商店页能说明设备、系统与商店约束，但隐私信息由开发者申报且未经 Apple 验证；MobileReady 只提供模拟预览，不是真机验证。MDN 与 Apple 文档说明能力、权限和审核机制，不替任何具体产品做兼容性、隐私、商店通过率或用户效果结论。本站没有把同一核心动作分别做成四种载体，也没有外部用户结果。
读之前先对一下
是否适用
只有能写出一个用户动作和可见结果时，才值得做这次载体预检。
这条记录可能帮得上
- 能用一句话写出一个用户、一个入口、一个动作和一个可见结果。
- 愿意先用固定演示数据，并在目标设备上走完一次，而不是先搭完整后台或申请商店账号。
这些情况先不要照着做
- 核心动作仍是“做一个 AI 产品”“做个社区”或“做个平台”，没有可观察结果。
- 第一轮就必须接入真实支付、生产账号、敏感数据或不可撤销权限。
- 只想用截图或模拟器证明摄像头、后台、离线、分享或商店分发已经可用。
历史试法 · 一条固定演示路径
当时的试法
45–90 分钟写约束、排除载体，并在一台目标设备上记录入口到结果。
- 大概用时
- 45–90 分钟：20 分钟写约束，25–70 分钟做一条固定演示路径；到点即停
- 可能花费
- 第一轮不用付费模板、开发者账号、商店服务或真实模型调用
- 权限边界
- 只用固定演示数据；默认不申请摄像头、通讯录、位置、支付、生产身份或后台常驻权限
- 01
先做什么
展开这一步
写下一个“进入—动作—可见结果”契约，并列出目标设备、必要能力、身份/分享、离线/后台、审核/付款五类约束。给网页、小程序、原生 App、游戏运行时各写一行；任何不满足必要条件的载体直接排除。用剩余承诺最小的载体做一条固定演示路径，再在一台目标设备上记录入口、权限提示、完成结果与失败点。
- 02
手里应该多出什么
展开这一步
一张载体排除表、一条固定演示路径、一份真机结果记录，以及一个可撤销的继续或换载体决定。
- 03
怎样算成功
展开这一步
目标设备能从约定入口走到可见结果；被排除的每种载体都对应一条明确约束，而不是个人偏好。这里只证明这一条演示路径可行，不证明用户需要、商店通过、规模化维护或商业结果。
- 04
遇到什么就停
展开这一步
核心动作写不清；候选差异只剩审美；模拟器被当作真机；或继续前必须申请商店账号、真实支付、生产身份、敏感数据与高风险权限。
- 05
怎么恢复原状
展开这一步
保留交互契约、约束表和真机记录；删除平台脚手架与演示凭证，撤销试验权限，回到仍能满足必要条件的最低承诺载体。
BITSHOVEL R2 说明图 · 固定虚构数据
方法与界面
示例先排除不需要的平台承诺，再把剩余路线送到真机闸门。
展开方法边界
图中的任务、数据、设备和选择都是固定虚构演示。它只解释如何推导载体，不是网站、App、小程序或游戏的运行截图，也不证明网页路线已经通过真机。
示例任务不需要商店、后台或游戏循环，因此先保留网页路线；这只是约束推导，不是“网页永远更好”的结论。
依据和来源
依据和来源
截至 2026-08-16，三个项目方案例和两份能力/审核文档分别支持入口、硬件、模拟与发布边界；它们不构成格式成功率比较。
展开证据边界
历史 E2 保留为当时标签。R2 把三个案例降回案例线索，并加入当前能力与审核文档；它们共同支持“先写约束再选载体”的方法，但不构成同题比较、格式排名或产品成功证据。
- 01作者自述案例 · 本轮复核
Fly Pieter：浏览器入口减少安装与更新摩擦
- 02商店与设备案例 · 本轮复核
SpookSeek AR：iPhone、摄像头与商店分发构成明确约束
- 03项目方预览工具 · 本轮复核
MobileReady：多设备框架是模拟与演示，不是真机完成记录
- 04Web 能力参考 · 本轮复核
MDN：网页摄像头需要安全上下文、用户许可与支持的设备
- 05原生发布参考 · 本轮复核
Apple：App Store 提交会引入审核、元数据、账号、硬件与权限要求
修订记录
修订记录
R2 撤掉“普通表单优先网页”的捷径，改成一套可停止、可回退的排除法。
展开 2 次修订
- 第 1 次
不再同时比较整个平台，只看完成一次核心动作所需的设备能力与分发入口。
- 第 2 次
把“普通表单优先网页”改成可执行的排除法：先冻结交互契约和五类约束，再选择承诺最小的可行载体，并要求一次真机路径。
- 更正前的说法
- 先列设备能力与分发入口；普通表单与分享优先网页，必须调用平台关系或硬件时再选小程序、App 或游戏运行时。
- 更正后的判断
- 先写一个进入—动作—可见结果契约和五类约束；没有任何载体天然优先。排除不满足必要条件的选项，选择承诺最小的剩余载体，并用目标设备上的一次完成记录，而不是模拟器或截图，决定是否继续。
这条记录留下什么
这条记录留下什么
第一版的目标不是选出最完整的平台，而是用最小承诺完成一次核心动作。
如果不能说清哪条必要条件排除了某个载体，或者只有模拟器截图而没有真机记录，就还没有做出载体决定。
回到 Dig 索引