Claude Code 时代,原型该从代码起还是从 Google Stitch 起
在 Claude Code 上跑过一段时间原型流之后,有一个容易被忽略的问题:工具升级了,工作流没跟着调,效率反而比之前低。最典型的例子就是原型阶段——从 HTML 直接起,还是先去 Google Stitch 这类设计工具里画一稿。这两条路径在传统手写代码模式下差异不算大,但放到 Claude Code 工作流下,差距开始拉开了。
下面把两条路径的差异拆开讲,顺带给一个目前在跑的混合流。

直出 HTML 原型:Claude Code 工作流下的默认路径
Claude Code 的特点是它直接读写本地文件、看得到完整项目上下文。这件事放在原型阶段,有几个具体收益:
原型即代码,没有翻译损耗。设计稿到代码这一步在传统流程里默认存在,设计稿映射到 DOM 是一回事,响应式断点和实际可实现性又是另一回事。如果原型本身就是 HTML + Tailwind,验证通过后直接拆组件就行,不存在"设计师画得出、前端实现不了"的断点。
上下文同源。Claude Code 已经知道项目里有什么组件、用了哪个 UI 库、配色 token 在哪个文件里。让它生成原型时,产出的代码风格能跟现有项目对齐。这一点 Google Stitch 起手做不到——它不知道你 tailwind.config.ts 里 primary 色是什么。
迭代成本低。"把表格改成卡片流"、"加一个抽屉侧边栏"、"主色再克制一点"这种需求,在 HTML 上是改 DOM 和 class,在 Claude Code 里一句话就能落地;在设计工具里是手工拖拽。一个原型从空文件到能点的状态,5–10 轮自然语言迭代基本到位。
可复现的最小起手姿势(用 Tailwind CDN,不走构建链,适合一次性原型):
# 项目目录下
ni prototype.html
# 让 Claude Code 把内容写进去,Tailwind 用 CDN 引入即可
python -m http.server 8000
# 或者
npx live-server --port=8000
提示词样例:
用单个 HTML 文件做一个数据监控面板原型,Tailwind 用 CDN 引入。需要:1) 顶部异常指标横向滚动条;2) 中间的图表占位区域(用 div 模拟,标注尺寸);3) 右侧可折叠的详情抽屉。加最少量的原生 JS 让抽屉点击展开收起,不引第三方库。
跑出来的产物在浏览器里就能直接演示,后续验证通过再一句话拆成 React 组件,不需要重写。

Google Stitch 先行:位置在收缩,但没消失
Google Stitch 这条路径的优势在 Claude Code 工作流下被压缩了,但没消失。
纯视觉探索。当前阶段就是"看看不同布局长啥样"、"配色试一下"这类纯视觉发散,Stitch 的拖拽思维阻力比写 HTML 低,从一句话生成多套视觉方案这件事它做得比直接写代码更顺。这种场景不需要产物能跑起来,Stitch 仍然合适。
跨职能沟通。需要拉产品、运营、客户对齐"是不是长这样",一个能点的 Stitch 分享链接,比让对方 clone 仓库再跑 dev server 现实得多。

但跟 Claude Code 配合时,痛点也很明确:
- Claude Code 看不到 Stitch 里的稿。Claude Code 的输入是文件和文本,Stitch 的产物是另一个 SaaS 里的私有数据。中间多了"截图发给多模态模型 → 拿到文字描述 → 把文字描述再喂给 Claude Code"这一串翻译步骤。Stitch 自己有"导出代码"按钮,导出来的 HTML 也还是要再喂回 Claude Code 才能进项目,没省掉这一步。
- 描述损耗。把"左侧 200px 深色侧边栏,顶部三个 icon,主区域 12 列网格"这类视觉细节用文字描述给 Claude Code,远不如直接让它读现有的 HTML/CSS 来得准。截图喂多模态模型可以缓解,但精度仍然不如代码。
简单说:Claude Code 介入越深,Stitch 在原型阶段的边际收益越低;但在跨职能沟通环节它仍然不可替代。
目前在跑的混合流
把两条路径的优势混起来,工作流大概是这样:
Step 1:结构在脑子里或白板上想清楚。Excalidraw 画几个方块标一下模块名就够,不进 Stitch 调像素。
Step 2:让 Claude Code 直接出 HTML + Tailwind 原型。一次性产物,文件命名走 prototype-xxx.html,反正是要丢的。
Step 3:浏览器看效果,在终端继续对话迭代。改完一刷新就行,不需要构建链。
Step 4:原型在产品同学或客户那边过了之后,让 Claude Code 把 HTML 拆成项目里的组件、接 mock 数据、接路由。因为 Claude Code 在原型阶段就看过完整结构,拆解的准确率比从一份 Stitch 设计稿翻译过来高一截。
Step 5:中间需要找非技术同事看时,把 Step 3 的 HTML 跑一个临时 deploy(Cloudflare Pages 或 Vercel 都行),分享 URL。这一步替代了"Stitch 分享链接"的角色。

一个踩过的坑
第一次跑这套流程时,把所有原型迭代直接写在主项目 src/ 下,结果原型试错产生的 index2.html、Test.tsx、Demo-final-v3.tsx 跟正式代码混在一起,后面整理花的时间比省下来的还多。后来固定一个 prototypes/ 目录单独放,在 CLAUDE.md 里写明"新建原型文件都放这里",问题就解决了。这件事属于"工具变了,目录约定也得跟着变"——原本 Stitch 的稿是另存为一个云端文件,天然跟代码隔离;HTML 原型如果不主动隔离,会污染主仓库。
几点判断
- Claude Code 介入越深,原型从代码起手的收益越大。"原型即代码"在传统流程里是个理想,在 Claude Code 工作流下是默认选项。
- Google Stitch 在原型阶段的角色在收缩,但在沟通环节没被替代。需要拉非技术角色对齐时,可分享的可点击稿仍然比 GitHub 仓库友好。
- 混合流的关键是物理隔离。原型代码和正式代码放在不同目录,避免试错产物污染主仓库——这是迁移到新工作流时最容易忽略的一步。
- 不要让 Claude Code 替代视觉判断。它在结构、布局、状态机这些"可被语言描述"的层面很强,但"这个间距 12 还是 16 看起来更舒服"这种纯视觉手感上,肉眼仍然不可替代。原型出来后用浏览器过一遍是必要的。