一个被忽略的成本问题
用 AI 写前端，大家都有过这样的体验：让它生成一个 Hero 区块，出来的东西能跑，但不好看；让它改，改三轮才勉强能用；下一个页面，重来一遍。
我们做了一次实测。用 AI 从零生成一个 8 区块的落地页（Hero、特性、定价、评价、FAQ、CTA、页脚等），把返工也算进去：
输出 token：约 60,000 输入 token：约 30,000（每轮把已有代码读回上下文）按 Claude Sonnet 的价格（输入 $3/M、输出 $15/M）算，接近 $1 一个页面。
问题不在于 AI 不够聪明，而在于输出 token 的单价大约是输入的 5 倍。让 AI「写」东西，永远比让它「找」东西贵得多。
这篇文章讲的就是怎么把「写」换成「找」，以及怎么用 MCP 协议把这件事做进你现有的 AI 编程工具里。
现有方案解决了一半
市面上已经有不少 AI 网站提示词库——Motionsites、Jiro 这类，积累了大量经过设计的页面提示词。它们解决了素材从哪来的问题：不用自己想设计，挑一条现成的就行。
但它们没解决素材怎么进项目的问题。典型工作流仍然是：
打开网页 → 搜索 → 预览 → 复制提示词 → 切回 IDE → 粘贴给 AI → 等它生成这里有三个隐性成本：
- 上下文切换：浏览器和 IDE 来回跳，一个页面切十几次
- 仍然在「生成」：提示词只是描述，AI 拿到后还是要从零写代码，那 60K 输出 token 一分没省
- AI 不知道库里有什么：你得自己去搜、自己判断哪条合适
第 2 点是关键。提示词库降低的是设计成本，不是 token 成本。
MCP 是什么，为什么适合这件事
Model Context Protocol（MCP）是一个开放协议，让 AI 客户端能调用外部工具和数据源。它现在被主流工具广泛支持：
Claude Code · Claude Desktop · ChatGPT · Cursor · VS Code（Copilot）· Windsurf · Cline · Zed
MCP 的价值在这个场景里非常直接：AI 可以自己搜索素材库，不需要你切浏览器。
但真正让成本降下来的，是另一个设计——让代码绕过上下文。
关键设计：代码不进 context
一个 React 组件平均 1 万字符 TSX。如果 MCP 工具直接把代码返回给 AI，那这 1 万字符就要进上下文，token 照烧不误，只是从「输出」变成了「输入」，省了 5 倍单价，但没省掉体积。
更好的做法是：MCP 只返回下载地址，让 AI 用curl把文件直接写到磁盘。
fetch_blocks({ slugs: ["hero-x", "pricing-y"] }) → { blocks: [{ files: [{ filename: "Hero.tsx", bytes: 13206, url: "https://..." }] }], dependenciesUnion: ["framer-motion", "lucide-react"] }我们实测过这组数字：
两个组件的真实代码：21,773 字节 MCP 响应体： 1,166 字符约 18 倍的压缩。代码全程没进模型的上下文，AI 只是执行了两条curl命令。
这一步之后，成本对比变成：
| 输入 | 输出 | 约合成本 | |
|---|---|---|---|
| 从零生成（含约 2.5 轮返工） | 30K | 60K | $0.99 |
| 走 MCP 取现成组件 | 13K | 7.5K | $0.15 |
差距约6 倍。原理很朴素：把最贵的输出 token，换成最便宜的输入 token，其中一部分连输入都不花。
实战：怎么接
我们把这套东西做成了开源插件，仓库在
github.com/kvalen-code/Motionsites-Dev，
连接的素材库是 motionsites.dev（1600+ 条提示词与组件）。
Claude Code
/plugin marketplaceaddkvalen-code/Motionsites-Dev /plugininstallryai装的时候会问 API Key，可以先留空——搜索完全免费，不需要账号。
Cursor / Windsurf / VS Code / Codex / Zed
这些工具不认 Claude Code 的 skill 格式，但都支持 MCP。在设置里加这个端点：
https://motionsites.dev/api/mcp然后把仓库里的AGENTS.md复制到你的项目根目录。AGENTS.md
是一个开放格式，目前有 23 个工具支持（Codex、Cursor、Windsurf、Zed、Gemini CLI、
Devin、Junie、Aider、goose、VS Code 等），60k+ 开源项目在用。它承载的是「怎么规划、
怎么施工」的指导逻辑，跟 MCP 工具配合使用。
四个工具
| 工具 | 鉴权 | 返回 |
|---|---|---|
search_prompts | 无需 | 匹配的区块：标题、描述、预览图、是否带代码 |
get_prompt | API Key | 单条提示词正文（给没有现成代码的区块） |
fetch_blocks | API Key | 每个文件一个签名下载地址 + 依赖清单 |
get_scaffold | API Key | 完整脚手架模板的 git clone 地址 |
注意get_prompt和fetch_blocks的分工——这两条路不能混用：
- 带现成代码的区块，走
fetch_blocks下载到磁盘 - 没有代码的区块，走
get_prompt拿提示词让 AI 生成
服务端对此做了硬性拦截：如果你对一个带代码的区块调get_prompt，会被直接拒绝并提示改用fetch_blocks。因为放行就意味着把 1 万字符塞进上下文，这不是偏好问题，是数量级差别。
一个容易被忽略的坑
fetch_blocks把文件下载到磁盘后，AI 会本能地想读回来确认。
这一读，前面省下的上下文全回来了。所以工具的返回描述里必须显式抑制这个行为：
Do NOT read the files back afterwards. They are already correct on disk.
Read one only if a build actually fails.
这是提示工程，不是代码——但漏了它，整个设计就白做。如果你自己实现类似的 MCP 工具，这一点值得记住。
从「说需求」到「出页面」
素材和接入都解决之后，还剩一个问题：不懂技术的人不知道自己要什么。
「我想做个卖课的网站」——然后就没了。不知道要哪些页面，不知道页面里该有哪些区块。
我们的处理是一套引导逻辑，最多问五个问题，一句技术黑话都没有：
| 问什么 | 不问什么 |
|---|---|
| 需要用户登录、保存数据吗？ | |
| 想要什么感觉？（给四个选项配示例图） | |
| 现在有项目了吗？空文件夹 / 已有项目 |
技术栈是替他决定的，不是问出来的。问完输出一份PROJECT.md：
# 卖课网站 技术栈：Next.js + Tailwind ## 首页 - [ ] hero — coffee-shop-header-laounge (code) - [ ] features — bento-grid-stats (code) - [ ] pricing — nimbus-pricing (prompt)(code)和(prompt)就是上面说的两条路线的标记。
这里有个硬约束值得说：方案里每个 slug 必须来自search_prompts的真实结果，不许 AI 编。编出来的 slug 在下载阶段必然失败，而那时候用户已经等了半天了。
什么情况下不适合
说点反面的：
- 已有成熟设计系统的团队：你们的组件库比任何通用库都合适，用不上这个
- 高度定制的交互：现成区块解决的是常见结构（Hero、定价、FAQ），不是你独有的业务界面
- 纯后端项目：完全无关
它真正适合的是：从零起一个站、要做落地页、需要快速出可用界面的场景。
小结
三个可以单独拿走的结论：
- AI 写前端贵在输出 token，输出单价约为输入的 5 倍，能复用就别生成
- MCP 返回下载地址而不是内容，可以让大体积产物完全绕过上下文，实测 18 倍压缩
- AGENTS.md 让指导逻辑跨工具复用，不用为每个 IDE 写一份
