你跳过的计划，就是你日后要排查的故障
软件工程领域的每一套方法论都告诉你要快速推进、尽早上线、在生产环境中迭代。但对于AI生成网站而言，这恰恰是反过来的。这里的构建器拒绝直接从你的提示词里一股脑生成代码——它会停下来，先写一份计划，等你看过之后再继续——而这个"拒绝"正是这整套流程背后唯一的核心决策。前期慢一点，后面全程都更省心。这笔交易我每次都愿意做，而我觉得大多数持相反观点的人，根本没仔细看过一个错误的猜测在后续会付出多大代价。
这正是计划存在的目的所要防止的失败模式。你输入"给我的工作室做个预约网站"然后点击开始。系统必须猜测"预约"到底是什么意思——一个日历小组件、一个第三方嵌入、还是一个带冲突检测的真正预约系统——而且它必须在什么都还没写之前就猜，因为没有别的顺序可走。如果在计划阶段猜错了，修正只需要一句话，五秒钟，搞定。但如果在生成的代码里猜错了，你修改的就不再是一句话了，而是要拆解十个已经依赖这个错误假设的文件。这两种情况我都见过。计划阶段的纠正是一次对话。生成之后针对同一个歧义进行的调转方向，是推倒重建。
计划也不只是一份待办清单，这也是大多数人忽略的地方。它是一份契约，系统会严格遵守它：一个一致性检查验证器——构建上线前必须签字确认的智能体之一——会把最终生成的网站和你批准的计划进行对比。计划里的每个页面都做出来了吗？功能清单是否和实际上线的一致？"完成"在这里不是一种感觉——它是相对于一份书面承诺而言的，可以逐行核对。这比"代码能跑"是更强的保证，而你能获得这种保证，正是因为有一份文档可以对照。拿掉计划，就拿掉了这根标尺。
这真正带来回报的地方
作为主导构建的人，你的发力点是前置的，无论你是否去用它。如果你关心信息架构、页面结构、哪些功能进v1还是v2——这种挑剔在计划评审阶段的价值是生成之后的十倍。多花四分钟重读一份计划，胜过花一轮来回修复一个已经跑偏的构建。
最明显的例子就是产品类型——纯静态网站、可安装应用、框架构建、带真实数据持久化的服务器支撑应用。它看起来像一个下拉菜单。其实不是。这是整个流程中最具结构性的选择，因为它悄无声息地决定了一大堆和网站外观毫无关系的事情。
| 产品类型 | 预览 | 发布 | 账户/数据库 |
|---|---|---|---|
| 纯静态网站 | 即时完成，因为只是静态文件 | 静态输出可以干净地直接复制过去 | 不可能——要求登录就是要求这个类型在结构上根本做不到的事 |
| 框架构建 | 先编译；构建失败的表现是"没有预览"，而不是"页面损坏" | 编译完成后，走的是同样干净的静态复制路径 | 不可能 |
| 服务器支撑应用 | — | 需要有地方实际运行一个进程，失败方式也不同——表现为进程崩溃，而不是文件缺失 | 唯一一种存在账户和数据库的产品类型 |
而且你之后没法随意升级类型。从纯静态网站变成有服务端支持的应用不是一个设置开关能搞定的——这几乎等同于重新构建一次，因为计划里一半的假设（页面如何加载、数据存在哪里、"发布"意味着什么）都是基于旧类型做出的。所以在制定计划时就说出来，哪怕你只有一半把握："我可能需要账户系统。"为一个有服务端支持的应用做规划、但只用到其中的静态部分，这不会有任何成本。而事后才发现自己需要它，则要付出重建的代价。
批评者说得有道理的地方
这一切都不是免费的，我也不会假装它是。每次运行都在隔离的工作区中进行，意味着你的知识文件会被重新复制进去，不会有任何东西回传到你的机器——如果你的笔记本电脑在构建中途出问题，这对你有好处，但对延迟不利，因为准备一个工作区，以及对于框架类构建，要在容器边界内运行真正的依赖安装，这些都需要实打实的时间。之所以存在这个容器边界，是因为一次框架构建会运行 `npm install` 和任意构建脚本——这些不是你写的代码，却拥有构建期的权限——如果在没有隔离的共享主机上这样做，一次依赖混淆攻击就能碰到另一个租户的数据。快而不安全本是可选项，只是不值得这样权衡。
验证也是同样的道理。一次完整的构建不是在生成停止时离开流水线的；而是在一组独立的验证者不再发现值得阻断的问题时才算完成：
- 代码审查
- 安全
- 链接与 SEO
- 无障碍访问
- 一致性
- 一次真实的浏览器运行
这不是一次性的检查，而是标记问题—修复—复查的循环，直到没人还有话要说，因为单次的检查很可能漏掉修复本身引入的回归问题。在同一个页面上修好一个失效链接，却不小心破坏了标题层级结构，这正是一次性检查会漏掉、而复查能抓住的情况。这个循环带来的真实代价是，构建偶尔会在快结束时莫名多花一分钟。人们会注意到这一分钟，却不会注意到刚刚为了这个网站争论了一番的六个智能体。这是关于体验的合理抱怨——我只是不认为这能成为跳过这场争论、直接发布的理由。
