夜雨聆风那天下午快下班时，项目经理丢过来一份十二页的需求文档，附言：“几天后要给客户演示，前端原型你先顶一下。” 你打开 Figma 看了看，又瞄了一眼还跑着线上报警的后端服务——那种熟悉的绝望感，又来了。
这场景不算少见。很多项目里都有后端临时被拉去写前端原型的情况，文档看不懂、页面搭得慢、接口联调总出错。直到有人摸索出一套组合打法，才把这种临时任务从噩梦变成流水线。下面这份清单就是这套打法的核心骨架——不用学新框架，不用折腾复杂配置，只靠两个工具把需求文档一路跑成可点击的 HTML+JS 原型。拿走直接用。
1. 先用 Claude Code 拆需求，别一上来就画页面
拿到文档的第一反应通常是打开 VS Code 开始抄 UI 组件。但后端出身的人最怕的不是写不出组件，是对需求理解有偏差，做完了发现根本不是产品要的东西。这一步踩过不少坑之后，固定成了一个动作：把需求文档整段贴给 Claude Code，让它先输出一张“页面结构树”和一份“交互流程说明”。
Claude Code 的核心功能在这里不是写代码，而是作为需求理解的中转站。你只需要在对话里说：“这是一份给前端原型的 PRD，帮我拆出每个页面的核心元素和跳转关系，用树形结构表示，并列出每个页面需要调用的接口。” 它会给出比你自己啃文档快得多的结构化输出。接下来再让它基于这个结构生成一份极简的 HTML 骨架——不要样式、不要美观，只有语义化标签和占位数据。这一下就把“理解需求”和“搭建骨架”一次打通了，省去反复翻文档、反复调整页面结构的时间。
适用场景：需求文档超过 5 页、页面间跳转逻辑复杂、或你对业务领域不熟悉的时候。如果只是一个单页表单，跳过这一步，直接进入第 2 条。
2. WorkBuddy 接手重复劳动，把骨架填成能看的页面
Claude Code 生成的只是一个极简骨架，下一步通常是要往里面灌组件：表单、表格、弹窗、导航栏。后端开发写这些，大概率会陷入 CSS 调来调去、组件库文档查到焦躁的循环。这时候就轮到 WorkBuddy——它可以在浏览器里自动操作你指定的组件库文档，按照你的描述生成对应的 HTML 片段。
举个例子：你只要告诉 WorkBuddy “在 Ant Design 里找一个带搜索和分页的表格示例，把配置项提取出来，并生成一个包含 5 条 mock 数据的完整代码”，它就会在浏览器里自动打开 Ant Design 文档、定位到表格组件、提取代码示例，然后填充上你给的 mock 数据，最终输出一个可以直接粘贴进项目的代码块。不用手动打开十几个 TAB，不用一个一个参数去试。被浏览器自动化接管掉的，是开发过程中最消磨耐心的琐碎环节。
适用场景：需要大量重复粘贴组件代码、需要对照官方文档调参、或需要快速生成带 mock 数据的完整页面时。不适合的场景：页面交互非常定制化、组件库没有现成示例的时候——这种情况还是得手写。
3. 接口联调这一步，让 WorkBuddy 帮你写 mock 和请求代码
页面填得差不多了，接下来要让它“动起来”——调用接口、渲染数据。但后端出身做原型的一个巨大优势是熟悉接口结构，劣势是手写前端请求逻辑时容易写出各种边界 bug（比如没处理 loading 态、没处理异常）。这里有个很省力的做法：把后端接口文档喂给 WorkBuddy，让它自动生成前端请求函数和 mock 数据，同时处理好各种状态。
具体操作：把 Swagger 文档或接口说明贴给 WorkBuddy，指令写成 “根据这个接口生成一个符合项目 fetch 封装风格的请求函数，包含 loading、空数据、错误三种状态，并生成一组 10 条 mock 数据”。WorkBuddy 不仅能直接输出代码，还能在浏览器里验证 mock 数据的结构是否匹配接口定义——这比你自己脑补 mock 数据再调试半天快得多。后端开发最擅长的数据结构部分你亲自把关，最烦的胶水代码交给工具，这是效率最高的分工。
一个小建议：不要追求一步到位让 WorkBuddy 写完所有接口联调逻辑。先挑 1 个最重要的接口跑通，验证整套流程，再把剩下接口批量生成。你会发现错误率从 40% 降到接近零。
4. 串起来：从需求到可演示原型的完整链路
单独用每一个工具效果有限，真正让效率翻倍的是把它们串成一条线。固定下来的流程是四步：① 需求文档 → Claude Code（输出页面结构树 + HTML 骨架）；② HTML 骨架 → WorkBuddy（逐个页面填充组件代码）；③ 接口文档 → WorkBuddy（生成请求函数和 mock）；④ 把所有片段拼回 Claude Code，让它做最后的整合和清理。整个过程里你只做两件事：给工具下达指令、检查输出结果。那些在编辑器里反复复制粘贴、来回查文档的动作，被降到最低。
这套流程跑通一个包含 5 个页面的后台原型，从拿到需求到生成一个可点击演示的 HTML+JS 包，耗时不到 3 小时。换做手动搭建，2 天都不一定够，还得搭上半条命。
5. 什么人不适合这套组合——以及对你们的一点建议
这套方案不是银弹。如果你原本就是资深前端，页面复杂度又极高（比如带大量 canvas 动画、复杂拖拽交互），那 WorkBuddy 的自动化在细节处理上可能不够精细，还是直接手写更靠谱。另外，需求文档本身写得非常粗糙、连基本字段都没对齐的情况下，Claude Code 拆解的结果也会充满歧义——这时候第一步卡住，后续流程都会打折扣。
最合适的用户画像：后端开发、全栈但前端偏弱、或临时被要求交付原型的任何人。 你懂接口、懂数据结构，缺的只是快速把界面搭出来并跑通交互。这两工具恰好补的就是这块短板。而且所有操作都基于官方公开功能，没有部署门槛，不需要公司额外批准或采购。
最后一条建议：别等下一次被临时抓差再翻出这篇文章。现在就花 10 分钟，用一份手头的旧需求文档跑一遍上面第一条和第二条。你会发现，脑子里那堵“前端太难了”的墙，其实薄得很。
你是被临时抓差做前端的后端吗？说说你用过哪些省力的工具组合。
#Claude Code#WorkBuddy#原型开发#多工具工作流#后端做前端