AI 时代的产品原型之困：从“手工死磕”到“Vibe Coding”，我为什么最终选择了 HTML？作为产品经理或独立开

作为产品经理或独立开发者，我们几乎每天都在和“原型”打交道。原型是我们的大脑和现实世界之间的第一座桥梁。但在追求“敏捷”的今天，如何高效地把脑海中的 Idea 具象化，却成了一个让人头疼的难题。

最近，我在探索原型制作方法的路上，经历了一次完整的“否定之否定”。今天想和大家聊聊，在 AI 时代，我们到底需要什么样的原型工作流。

最开始，我像大多数人一样，老老实实地在画布上拖拽组件。无论是低保真的线框图，还是高保真的交互稿，本质上都是一种劳动密集型的工作。

效率的瓶颈是“手速”： 哪怕你的思路如泉涌，你的鼠标和快捷键也跟不上大脑的速度。
高保真的“熟练度陷阱”： 想要画出让人眼前一亮、且具有复杂交互的高保真原型，对工具的熟练度要求极高。很多时候，我们把 80% 的精力花在了对齐像素、调整阴影和制作跳转逻辑上，反而忽略了产品核心逻辑的推敲。

当你的时间被这种机械劳动填满时，原型的迭代周期就会被无限拉长。

既然手工太慢，那让 AI 直接帮我写出来行不行？于是，我尝试了第二条路：前端 Vibe Coding（直出代码）。

初看这是一种降维打击：输入自然语言，直接生成一套可运行的前端代码。不仅原型有了，连初步的开发工作都省了。但深入实践后，现实却给了我沉重一击：

薛定谔的审美： AI 生成的 UI 往往自带一种难以名状的“拼凑感”。由于缺乏全局的 UI 规范约束，生成的界面经常在及格线边缘疯狂试探，很多时候可以说是“丑得千奇百怪”。
修改细节的噩梦： 当你想微调一个按钮的位置或是一个弹窗的层级时，灾难开始了。直接开发原型的周期太长，且对前端技术有硬性要求。如果你不懂 CSS 或前端框架的底层逻辑，你就只能用自然语言去“盲猜”和“抽卡”，沟通成本远大于自己上手改。

核心问题在于：直接生成现代前端代码，跨度太大了。 AI 需要同时处理逻辑、结构、样式和交互，这就导致了信息量过载，最终失去了对细节的精准控制。

在放弃了“直接一步到位”的幻想后，我找到了一条折中，但却异常优雅的路径：只让 AI 生成纯 HTML 文件。

为什么是 HTML？因为它是结构化信息的完美载体。

极短的上下文，极高的控制力： 相比于夹杂着复杂框架逻辑（如 React/Vue）和庞大样式表（Tailwind/CSS）的前端工程文件，纯粹的 HTML 代码上下文非常短。这意味着 AI 不会轻易“遗忘”你的需求，你可以非常精准地对页面结构进行自然语言微调，命中率极高。
解耦“结构”与“表现”：

HTML 只负责骨架（DOM 树），不负责皮囊。我们利用 AI 强大的逻辑梳理能力，快速生成页面的层级和内容结构；至于页面好不好看？那是下一步的事情。
无缝衔接现代设计工具：

这也是最关键的一点。现在的设计生态已经非常成熟，我们可以通过各类插件（比如 Figma / 墨刀的 HTML to Design 插件），将 AI 生成的 HTML 骨架一键转化为可编辑的原型文件。

回顾这三次尝试，我发现了一个在 AI 时代做产品的核心逻辑：不要试图让 AI 一次性走完 100% 的路，而是要找到一个合适的“中间态语言”。

HTML 在这里扮演了人类意图与 AI 算力之间的标准化接口（API）。它既具备机器可读的结构化特征，又保留了向高保真原型转换的延展性。

在未来，最强大的生产力或许不是那些能“一键生成万物”的黑盒工具，而是那些懂得如何将复杂任务拆解，并在最关键的节点上，把控制权优雅地交还给人类的系统。而对于我们来说，掌握如何定义和生成这些“中间态”，比熟练使用任何单一的画图工具都更为重要。