我现在越来越确定一件事：AI 原型开发最怕的不是工具不够强，而是你把所有复杂度都丢给一个工具。
上周日晚上，我差点又踩这个坑。第二天下午两点要给客户演示基础代码原型，我原本想得很直接：需求清单已经有了，功能也沉淀很久了，那就让 Codex 直接开干。
结果第一轮出来，页面能看，但不够能用。
它有一种很明显的 AI 味，布局像是拼出来的，交互也没有从真实用户的使用感受出发。
先别急着让 AI 写代码这个问题其实很典型。
很多人一上来就把需求文档丢给 Codex，或者丢给类似的 IDE 工具，然后期待它直接生成一个像样的前端原型。
理论上可以。
现实里，经常像开盲盒。
不是代码写不出来，而是前端原型最难的部分，并不只是代码。
菜单怎么组织，信息优先级怎么排，哪个动作要一眼能找到，哪个页面要让客户马上理解业务流程，这些东西如果没有先定住，AI 写得越快，返工也可能越快。
AI 写代码很快，但它不能替你判断一个业务系统应该怎么被人使用。
我当时很快意识到，不能继续在 Codex 里反复抽卡。
第二天就要交付，活不能停。
我换了一个顺序。
我把同一份功能清单给到 ChatGPT，让它先输出一套完整的高保真原型图，包括主菜单、页面布局和核心交互。
中间也不是一次就完美，大概抽了两三轮，但页面方向很快就框住了。
这个阶段，我要的不是代码，而是一个可讨论、可判断的界面锚点。
等高保真原型大差不差后，我再让它按我实际使用的架构输出可交互原型。我这边主要是 Vue 3 + Element Plus，所以生成出来后下载到本地，再放进 Codex 里运行。
这一步之后，Codex 的价值才真正出来。
因为它不再是在一片空地上猜“这个系统应该长什么样”，而是基于已经确定的原型、需求文档和技术栈，继续补功能页面、前后端交互和工程细节。
ChatGPT 更适合先帮我把“看起来像什么”定住，Codex 更适合把“它能不能真的跑起来”做实。
真正的分水岭，是不用 Mock
这次我对 Codex 的要求有一条硬边界：不能用 Mock。
包括前后端都要有，测试验收也必须对接我提供的真实测试服务器、真实测试数据库。建表、数据初始化、接口联调这些逻辑，都要一起完善。
为什么我很在意这一点？
因为客户现场看的不是一个静态壳子。
一个页面如果只能点开、不能走通业务，它在内部讨论时也许够用，但在客户面前很容易露怯。
原型当然不等于最终系统，可它至少要让业务方看到：这个流程是怎么走的，数据是怎么来的，问题会卡在哪里。
这也是我现在越来越不愿意接受纯 Mock 原型的原因。
Mock 可以帮你快速讲故事，但真实环境才能暴露问题。
尤其是客户交流场景，越接近真实链路，讨论越不容易飘。
人不能从验收里消失当天晚上差不多做到两点，我把后续开发、测试和验收任务交给 Codex 跑着，自己先睡了。
第二天起来，整体原型已经可以接受。
最大的问题反而不在功能，而是主题和布局还要稍微调整一下。上午快速改完，下午两点，我就拿着这套包括前后端交互的代码原型去客户面前展示。
这次交流明显顺了很多。
客户不是听我口头解释“未来会有一个什么功能”，而是直接看见页面，点进流程，提出疑问。
每一个业务方的问题都变得更直观，也减少了很多需要反复二次确认的地方。
当然，这不是因为工具突然替我完成了产品判断。
我本身是业务岗出身，转产品经理也有五六年。现在虽然是 IT 负责人，但在小团队里，客户交互、打单、业务交流这块还是以我为主，研发做辅助。
这次原型能撑住会议，本质上还是因为我们对这个领域、这个系统、这些业务方的诉求有积累。
AI 只是把原本压在我和研发身上的一部分复杂度接走了。
真正能交付的 AI 工作流，不是人退场，而是人把判断、边界和验收抓得更紧。
AI 开发不是一个工具包打天下这次之后，我对 AI 原型开发的理解更清楚了一点。
不要幻想一个工具从需求清单直接打穿所有环节。至少在真实业务交付里，这件事还不稳定。
更靠谱的方式，是把不同工具放到合适的位置。
ChatGPT 负责帮我快速沉淀高保真原型，让页面方向、菜单结构和交互感觉先能被判断。
Codex 负责把这个原型放进真实工程里，补功能、连接口、跑环境、做验收。
人负责最关键的部分：判断这个原型是不是服务业务，客户能不能看懂，哪些地方必须真实，哪些地方可以先放一放。
从这个角度看，AI 提效不是“我终于不用管了”。
恰恰相反，它要求人更会组织工作。
你要知道什么该交给 ChatGPT，什么该交给 Codex，什么必须自己拍板，什么绝对不能用 Mock 糊弄过去。
这才是我这次最大的收获。
AI 原型开发真正提效的地方，不是把人从交付里拿掉，而是把复杂度重新分配：工具进后厨，人站在前台，负责点菜、验菜、上桌。
你现在用 AI 做原型时，最难的是页面好看、功能跑通，还是客户真正看得懂？
