AI生成原型很快,为什么产品返工反而更多?

一句话生成几个页面，按钮、表格、图表都有了。拿去开会，大家很快就能讨论颜色、位置和交互。这确实比盯着一段文字想象产品方便。

但如果需求本身还没想清楚，漂亮的页面也会让人更快地误以为事情已经确定。

我担心的就是这一点：原型生成越快，团队越容易跳过那些不直接出现在页面上的问题。等开发开始，权限、状态、例外和数据来源逐渐出现，原型又得一遍遍修改。

于是节省的是画页面的时间，增加的却可能是后面的返工。

假设要做一个客户报价页面。AI很快生成客户名称、产品选择、数量、折扣和提交按钮。看起来完整，销售也觉得符合直觉。

可提交以后发生什么？报价是谁确认，折扣超过什么范围需要审核，产品停用以后历史报价如何查看，客户修改数量要不要生成新版本？这些问题如果没有回答，页面只是把缺口藏得更漂亮了。

我会先要求自己说清楚一个任务从哪里开始，到哪里结束。谁发起，依据什么资料，哪些条件必须满足，结果给谁。然后才让AI把这个过程表现出来。

原型当然可以帮助思考，不必等全部规则确定才画。但未确定的部分要明确标出来。比如审批方式待确认，页面里就写明，不要让系统随手补一条看似合理的流程，后来大家又默认接受。

生成工具很擅长把界面补齐，人却要判断补出来的东西是否属于真实需求。

有时一个按钮会悄悄扩大项目范围。原本只需要查看订单，原型多了“批量修改”；原本只提供参考，页面多了“自动执行”。评审时大家习惯于讨论怎么做，而没有先问为什么需要。

因此，看AI原型时，我会专门找那些需求中没有明确提出的动作。不是一律删除，而是逐个确认：谁需要，什么条件下使用，带来什么责任，当前阶段值不值得做。

这种检查尤其适合放在评审早期。等页面被反复展示，大家对它产生熟悉感，再删功能就容易被理解为退步。

另一个问题，是示例数据太整齐。

生成出来的客户名称长短适中，表格只有几行，所有状态都正常。真实数据却可能字段缺失、名称超长、记录重复，还有历史遗留的特殊状态。

只看正常页面，很难发现使用中的障碍。可以拿几条脱敏或模拟的复杂材料试一下：没有联系人怎么办，查不到产品怎么办，权限不够时看到什么，提交失败以后内容还在不在。

这些情况不必每种都画成精细页面，但至少要有处理说明。原型的价值包括帮助团队看见问题，不能只负责展示最顺利的一条路。

我还会检查角色差异。同一张页面，普通员工、主管和维护人员能做的事可能不同。看见不等于能改，能改也不等于能批准。

如果原型没有区分，开发人员往往只能在实现过程中不断追问。此时再补规则，界面和数据设计都可能受到影响。

所以讨论原型时，最好让参与者沿着一个具体角色走完整任务。不要一会儿站在管理员角度，一会儿又替普通员工点击，把所有权限拼成一个现实中不存在的超级用户。

还要让真实使用者参与，而不是只让项目组互相认可。

使用者可能不会指出某个交互规则错误，但会问一句：“客户还没确认，我为什么必须填这个？”这类问题能暴露业务顺序不合理，也可能提醒团队某项信息在这个阶段根本拿不到。

请他解释现在怎样完成工作，遇到特殊情况怎样处理，再看原型是否接得上。不要只问好不好看、方不方便，问题太宽，反馈也容易停在礼貌层面。

返工还有一个来源，是评审意见没有区分性质。有人提出明确业务错误，有人表达个人偏好，有人只是想到未来可能需要的功能。如果全都立即改，原型会变成不断移动的目标。

我倾向于先处理阻碍任务完成和违反已确认规则的问题。视觉偏好集中调整，未来需求放到后续范围讨论。每次改动都说明为什么，避免同一处来回反复。

版本也要留清楚。旧链接继续流传，开发按旧图实现，业务又拿新图验收，这类返工与AI能力无关，却可能因为生成速度快而更加频繁。

可以保留一份明确的当前版本，说明对应哪些已确认需求。讨论稿和交付稿有所区分，让参与者知道哪份只是探索，哪份可以作为实现依据。

对AI生成的代码原型，更要留意“能点”与“能交付”之间的距离。演示中的数据可能写死，保存动作可能只是页面提示，外部系统连接也可能没有完成。评审时应把这些边界说清楚。

否则业务人员看到按钮有效，就以为功能已经开发完。后面技术团队解释仍需建设，反而像是在拖延。误解最好在第一次展示时就消除。

我会在每次演示前写三句话：这次主要验证什么，哪些行为已经真实实现，哪些只是模拟。说明越明确，讨论越容易集中。

还有一个很实用的做法，是让评审者先说任务，再看页面。比如请销售描述一次改价请求的处理过程，记录关键判断后，再打开原型对照。这样大家不容易被既有页面限制思路。

如果一打开页面就开始讨论，生成工具给出的字段和布局会成为默认起点。那些没有画出来的业务问题，很可能整场会议都不会被提到。

也可以在开发交接时附几条验收情形：正常提交应得到什么，缺少信息应怎样提示，重复点击是否会重复处理。它们不需要写成复杂测试文档，却能让产品、开发和业务对行为有共同理解。

交接以后出现新想法，再确认它是原需求遗漏还是新增范围。两种情况都可以处理，但对进度和投入的影响应该分别说清，不能统统算成原型画错了。

完成一轮修改后，还要回到原任务再走一遍。修好了一个页面，可能改变后续动作；新增必填项，可能让原来能够提交的情况卡住。不要只看改动位置本身。

如果原型一直在改，可以暂停出新图，重新核对任务范围和决策人。方向没有定下来，生成更多页面只会增加待确认内容。

我很愿意使用AI画原型，因为它能让模糊想法更快被看见。但我不会因为它把页面做得很完整，就省略需求判断。

真正减少返工的，是在交付前把关键问题暴露出来，并让有权决定的人作出确认。页面生成得快，可以为这件事争取时间，也可能让团队更快地跳过去。取决于我们怎样使用它。