我见过三个不同的人在同一个三十秒的界面上——提示词和构建之间出现的计划卡片——处理不当，而每个人付出的代价都不一样。一个付出的是重新构建的代价。一个付出的是白打的字。还有一个得到的是一个无法完成他们真正需求的产品。计划卡片是整个流程里最便宜的、可以改变主意的时刻，而这恰恰也是它最容易被草草略过的原因。
错误一：盲目批准
这是最常见的一种。骨架看起来没问题，点击批准，继续下一步——我这样做了好几个星期才吃了苦头。最终让我改掉这个习惯的那次构建，是把 Stripe 结账功能接到了一个静态网站上，而这个网站根本没有地方存放 Stripe 所需要的账户状态。计划上其实白纸黑字写着产品类型：静态网站，就在卡片上，而我因为页面列表看起来没问题、又赶时间，直接跳过了它。
这类错误造成的损害总是同一种形态：计划之后的每一步相对于计划本身都是正确的，所以问题不会以报错的形式暴露出来，而是表现为一个结构性错误、却能正常运行的构建。没有人会标记出问题，因为表面上一切正常——一个带结账按钮的静态网站只会默默地做错事，或者只在真实用户点击「支付」的那一刻才失败。你会在审查阶段才发现问题，而那正是发现问题成本最高的地方。
错误二：过度指定以避免第二轮修改
反方向的错误看起来更负责任，实际上并非如此。有些人在被错误一坑过一次之后，会矫枉过正，在计划阶段写下一整段精确的需求——确切的文案、间距偏好、哪些功能一定要有、哪些一定不能有，写得像一份规格文档。我自己也这样做过，出于一种模糊的焦虑，觉得现在不写细节，以后就会「浪费」一轮构建。
这其实是本末倒置，原因在于：不管你第一轮写得多仔细，一旦你看到实际页面，计划都会再次被修改。而修改发生时，你得到的不是一份改动对比，而是一张已经融合了你修改内容的全新卡片，仅此而已，没有变更说明。所以你在第一轮里打的那些精确内容，并不能原封不动地带入第二轮——反正你都得把整张卡片重新读一遍。经过两三轮「不，是这样的」调整，得到的结果会比一份详尽的需求文档更好、耗时更短——尽管写需求文档的过程中你会觉得自己效率更高。
真正有效的简单语言修改往往很短：
- 「去掉博客，加一个定价页」——干净利落地替换页面列表。
- 「改成双人模式而不是单人模式」——比听起来影响更大。它可能会波及数据模型，比如从追踪一个参与者变成追踪两个，修改后的计划会展示这种连锁影响，而不是隐藏它。
- 「这需要用户账户」——如果当前计划是静态网站，这句话会直接把产品类型这个问题摆到台面上来。
错误三：把产品类型当作可以随意调整的字段
这是代价最高的一种错误，之所以代价高，是因为卡片上其他一切几乎都是可以补救的。页面、推断出的功能、大部分分支问题——这些都可以在构建完成后通过版本迭代来修复。产品类型不行。一共有四种类型：
| 产品类型 | 它的含义 |
|---|---|
| 静态网站 | 纯前端，没有服务器逻辑。 |
| 可安装应用 | 类 PWA 应用——支持离线使用，可添加到主屏幕，仍然没有服务器逻辑。 |
| 框架构建 | 类 React/Next 结构，客户端交互性更强，但仍没有持久化后端。 |
| 服务器支撑应用 | 四种类型中唯一具备真正数据库和账户系统的一种。 |
批准一个静态网站的计划，三个版本之后才决定需要登录功能，那就不是一次版本升级——而是从另一种产品类型重新构建，你会失去版本历史为其他一切内容带来的连续性。
人们通常会以两种方式弄错这个问题。首先，他们没有对照实际情况检查自己的提示词——如果你的提示词中出现了「账号」「登录」「保存」「实时更新的仪表盘」「支付」，或「多个用户同时编辑同一内容」，而卡片上却没有标注需要服务器支持，那么这正是你批准前值得做的那一处修改，没有例外。其次，他们把可安装应用和框架构建混为一谈，因为在日常对话中两者 看起来 都像是「一个应用」。但它们并不能互换：可安装应用适用于所有状态都保存在用户设备本地的工具——比如小费计算器、健身计时器。框架构建则意味着更强的交互性和组件结构，但仍然没有任何数据会跨会话、跨设备持久保存在服务器端。这两者都不是通常意义上「拥有账号、数据可跨设备同步」的「应用」——只有服务器支持型才是。而为了「以防万一」，给一个作品集网站或文档页面过度配置服务器支持型架构，也并非稳妥之选；日后降级同样需要像升级一样重建一遍。
不再犯这三个错误之后，剩下的是什么
一旦你不再略过产品类型那一行，不再在规划阶段跳过撰写说明文档，也不再把自己提示词中涉及账号、数据、支付的措辞视为可有可无，剩下要做的就是一次快速而聚焦的核查：
- 阅读产品类型。
- 对照你的提示词进行核对。
- 浏览推断出的功能列表,看看有没有你一眼就想否掉的东西。
这份列表存在的意义就在这里——一句「面向美发沙龙的预约工具」这样的提示词,会带出很多你没打字的东西:日历视图、短信提醒、客户名单,有些是你想要的,有些则是范围蔓延,只是因为这些功能在统计上经常同时出现,模型才加了进来。在这句话阶段就把不属于这里的东西剪掉,而不是等它被构建出来之后再剪。
其余的一切——文案、间距、强调色用哪种色调、按钮上写「开始使用」还是「免费试用」——根本不在卡片上,这是刻意为之。这些东西在可运行的构建成果上一看就明白,改起来也很便宜,所以卡片不该把你的注意力浪费在这些上面,你也不该。这大概就是读这张卡片所需三十秒里,真正需要判断力的那十五秒。
