让 AI 画原型这件事,开始更像在带一个很快但不稳定的同事

这周我用 Gemini 生成原型的时候，有几位产品经理来问我：你这是用什么 AI 画的，怎么生成得这么好？

我当时第一反应其实不是“我 prompt 写得还可以”，而是另一种更具体的感觉：我最近做这件事，越来越像在带一个很快、很能干，但也很不稳定的同事。

它出东西很快，理解力也不差。你把方向说清楚，它往往能一下子把页面做出个七八分的样子，很多以前要自己一点点画、一点点改的东西，现在确实快了很多。

但它也有很明显的问题。

比如它很容易一边帮你新增内容，一边把原来已经做好的东西改掉。你明明只是想补一个弹窗、补一段流程、调一个页面区块，它却可能顺手把原来的结构一起动了。改得多了以后，你会发现页面看起来越来越丰富，但系统本身越来越不稳，前面已经确认过的东西也开始飘。

所以我这周一个挺深的感觉是：AI 画原型这件事，真正难的地方已经不是“能不能生成”，而是“怎么让它稳定地沿着你的方向生成”。

我后来慢慢发现，结果好不好，关键不在那一句 prompt 写得多漂亮，而在于你有没有先把这场协作搭起来。

我现在这套流程，核心不是提需求，而是先给它搭工作环境

我现在已经不会一上来就丢一句“帮我生成一个某某页面原型”了。

那种方式当然也能出结果，但很不稳。它更像一次性的运气，不像一个能持续往下走的工作方式。

我现在更常用的做法是，先把这件事拆开。

先描述现有功能，让 AI 基于现状生成一版需求文档；再把现有系统的页面截图喂给它，让它知道当前页面长什么样，不至于完全脱离现实；项目背景也要先固化，不然它很容易只看局部页面，不知道这件事为什么要做、业务边界在哪里。

然后才开始聊这次要优化什么。

这个“聊”也不是随便聊两句就结束，而是会一边讨论功能点，一边拆业务流程。流程拆出来以后，再单独去梳理每一条业务流程，生成流程图、改流程图，同时继续聊里面有没有没想清楚的细节。很多业务规则其实就是在这个过程中慢慢被说清楚、再被固化下来的。

等这一层差不多稳定了，我才会继续往页面原型走。

页面也不会一起生成。我更习惯一页一页来，甚至一个模块一个模块来。先单独生成某个页面的原型提示词，再去生成页面，再去改，再去确认。页面在改的过程中，新的需求细节和业务规则还会继续冒出来，这时候就顺手再补回去。

这套流程跑下来，我会更强烈地感觉到：原型本身只是最后看到的那层东西。真正影响生成质量的，往往是前面这些背景、流程、规则有没有先长出来。

分模块生成，不是为了省事，是为了减少失控

我现在很少让 AI 一次改很多内容。

这不是因为它做不到，而是因为我越来越不相信“大改一次更高效”这件事。

AI 很适合做增量修改，但不太适合在一个很复杂、约束很多的页面里大面积重写。你让它一次改太多，它当然会努力配合你，但最后经常会变成：你以为自己在推进，实际上是在引入新的不确定性。

所以我现在更偏向分模块生成。

一个模块聊清楚了，就先把这个模块做出来。这个页面稳定了，再做下一个。一次只动一小块，虽然看起来慢一点，但整体反而更稳。

这里面其实有点像你带一个新人做事。

你不会一开始就把一个特别大的东西整包扔给他，然后期待他一次做对。更现实的方式还是先划边界，先给清楚一段，再看他做出来的东西偏没偏，再决定下一步怎么走。

AI 也是一样。它很快，但不代表它适合无边界地快。

我后来加的那些“通用约束词”，本质上是在防它乱动

这周我还有一个很明显的体会，就是很多人会把 AI 出偏，归因到“模型不够聪明”或者“提示词没写好”。

但很多时候，问题更像是：你没有把不该动的地方说死。

我现在会比较明确地给它加一类通用约束。大意就是，这次是增量修改，不是重写；必须基于现有内容做定点编辑；除非我明确要求，否则不能改旧结构、不能重组布局、不能替换原有实现、不能删除旧内容；如果必须联动，也只能做最小必要改动，而且要说清楚原因。

这类话看起来有点硬，甚至有点啰嗦。

但实际很有用。

因为 AI 很容易把“帮你优化”理解成“我顺手帮你改得更完整一点”。可对真实项目来说，很多时候我们要的根本不是“更完整一点”，而是“别把已经确认好的东西改丢”。

这也是我最近越来越在意的一件事：和 AI 协作时，很多约束不是多余的，它们其实是在替你保住上下文，保住已经做出来的成果。

生成完再回查，是我现在很少省掉的一步

以前我也会觉得，页面生成出来差不多就行了，再继续下一页。

后来发现这样很容易出问题。

因为 AI 生成是连续的，但人的项目不是。前面确认过的内容、已经固化下来的业务规则、页面里一些细节性的处理，它未必会一直稳稳地记住。尤其是改过几轮以后，前面原本还在的东西，可能会被新一轮生成悄悄带偏。

所以我现在基本都会多做一步：生成完以后，回头重新检查之前做过的内容，看有没有变化。

这一步很笨，但很有必要。

后面我其实也想往前再走一点。比如参考 Harness Engineering 这类思路，不只是靠我自己盯，而是让 AI 自己先做一部分检查，把明显的问题先筛一轮，再由我来处理那些真正需要判断的地方。

但就现阶段来说，哪怕只是人工回查，也已经比“生成完就算了”稳定很多。

存版本这件事，看起来土，但能救命

还有一个我现在觉得很实用的动作，就是经常把几个相对完整的版本单独保存下来。

因为你很难保证每一轮生成都会往正确方向走。

有时候前面已经一点点磨顺了，结果某一轮突然偏得很厉害。这个偏差不一定是页面变丑，有时候是结构乱了，有时候是之前确认好的内容丢了，有时候是业务规则开始对不上了。

如果没有阶段性版本，你就只能在一个已经被改坏的基础上继续修。修到后面，成本会越来越高，人也会越来越烦。

但如果前面有留版本，很多时候就不用在那里死磕，直接回到上一个还健康的状态，再继续往下改，反而更快。

这件事也让我觉得，AI 协作不是只看“生成能力”就够了。版本管理、回退意识、阶段性存档，这些以前更像工程里的习惯，现在在原型协作里也越来越重要了。

我现在更愿意把这件事理解成：产品经理在给 AI 搭轨道

这周这件事对我最大的影响，不是让我更相信 AI 会画原型了。

这一点我本来就相信。

真正让我更确定的是，AI 开始进入产品工作以后，产品经理的工作重心也会跟着变一点。以前我们更像是在自己把东西一点点做出来，现在越来越像是在组织一场协作：背景怎么给，边界怎么划，流程怎么拆，规则怎么固化，页面怎么分模块推进，哪些地方必须增量修改，生成完以后谁来检查，出偏了以后怎么回退。

这些动作听起来不像“画原型”，但它们才是决定原型最后能不能稳定长出来的东西。

到这里，我会这么看这件事：

让 AI 画原型这件事，开始更像在带一个很快但不稳定的同事。你不能只会提要求，还得先把工作环境、协作边界和检查方式搭起来。前面这些东西搭得越清楚，后面的生成才越像在帮你往前走，而不是一边做，一边把事情做乱。