我用 Claude Code + Pencil.dev 跑了一遍 AI 设计工作流：从一句需求到可用 UI 原型
最近我尝试了一套很有意思的工作流：
不先开 Figma，不先手写页面代码，而是直接让 Claude Code 配合 Pencil.dev，在设计画布里把 UI 原型做出来。
刚开始我对这件事的预期并不高。
因为现在“AI 生成页面”已经不算新鲜了，很多工具都能做到“给你一张图”或者“直接吐一段代码”。
但真正让我觉得这套方案有价值的，不是它能不能一次性生成一个页面，而是：
它把“想法 → 设计稿 → 后续开发”的连接方式，变得更顺滑了。
这篇文章我想分享的是：
- Pencil.dev 到底适合拿来做什么
- Claude Code 为什么能“操作设计工具”
- MCP 在这里扮演了什么角色
- 以及这套方式更适合哪些人、哪些场景
先说结论：为什么我没有直接让 Claude 写页面代码？
如果目标只是“尽快把页面跑起来”，那么让 Claude 直接生成前端代码完全没问题。
但我在实际使用里越来越明显地感受到一个问题：
页面能生成，不代表设计已经想清楚。
很多时候 AI 直接写出来的是一个“能跑的界面”，但不一定是一个“可延展的设计方案”。
常见问题包括：
- 单个页面看起来还行，但多个页面风格不一致
- 设计细节和实现代码耦合在一起，后面不好改
- 你很难在编码阶段系统地调整视觉层级、间距、组件风格
所以我这次更关注的是另一条路径：
先让 AI 产出一版可以讨论、可以修改的设计稿，再基于它进入开发。
这也是 Pencil.dev 真正让我觉得有意思的地方。
Pencil.dev 是什么？它更像 AI 的“设计操作台”
如果只从表面看，Pencil.dev 可能会被误解成“又一个设计工具”。
但我实际体验下来，它更像是一个：
- 本地优先的设计环境
- 面向画布操作的原型工具
- 可以通过 MCP 被 Claude Code 调用的设计宿主
也就是说，这里并不是简单地“AI 帮你生成一张图”。
而是：
- 你提出页面需求
- Claude 理解需求并规划结构
- Pencil 负责承载这些设计操作
- 整个过程能被持续修改和迭代
这一点和很多“只会一次性生成结果”的 AI 工具有本质区别。
MCP 在这里到底是干什么的？
如果你第一次接触这个组合，最容易疑惑的一点就是：
Claude Code 为什么能去“操作” Pencil？
答案就是 MCP（Model Context Protocol）。
你可以把它简单理解为 Claude 和外部工具之间的通信协议。
在这套工作流里，它的作用就是：
- 让 Claude 知道 Pencil 能做什么
- 让 Claude 把自己的意图转成具体操作
- 让设计结果还能反过来被 Claude 读取和继续处理
比如一个简单页面生成流程，背后可能包含这些动作：
- 打开或创建设计文件
- 在画布上建立页面结构
- 插入按钮、输入框、卡片等元素
- 调整间距、圆角、颜色和层级
- 截图检查结果，继续修正
所以它并不是“Claude 空想一个页面”，而是它真的在控制一个设计环境工作。
环境怎么搭？我实际是这样跑通的
如果你也想试试，这部分可能会用得上。
1. 安装 Pencil.dev
先安装 Pencil.dev 桌面应用。
不同系统路径可能略有差异，但大方向一样。
2. 配置 Claude Code 的 MCP
我这边是通过手动配置 MCP 跑通的。
先确保 Claude Code 支持 MCP，然后创建配置文件：
touch ~/.claude/.mcp.json
配置内容类似这样：
<JSON>
{
"mcpServers": {
"pencil": {
"command": "/Applications/Pencil.app/Contents/Resources/app.asar.unpacked/out/mcp-server-darwin-arm64",
"args": []
}
}
}
如果是其他系统或架构，需要按实际安装路径调整。
3. 验证是否连接成功
打开 Pencil 后，重启 Claude Code，然后执行：
<BASH>
/mcp
如果配置正确，你应该能看到 Pencil 对应的 MCP 服务已经可用。
它不是“一句话出图”，更像“AI 在画布里干活”
这是我体验下来最想纠正的一个误区。
很多人会把这种能力理解成：
“我说一句需求，AI 就直接生成一个页面。”
但实际更准确的描述应该是：
AI 在设计画布里分步骤完成搭建，并且过程中还会自检和调整。
通常它会做这些事：
- 读取当前文档或画布状态
- 根据需求规划页面布局
- 创建模块和元素
- 进行局部优化
- 截图查看最终效果
- 如果结果不够好，再继续修改
这种工作方式更像一个“会干活的设计助理”，而不是一个只会一次性吐结果的生成器。
我尝试了一个不同于常见示例的使用案例：做一个读书类 App 的“发现页”
为了避免只验证登录页、注册页这种标准模板，我这次专门换了一个更偏内容型的页面场景：
设计一个移动端读书类 App 的“发现页”原型。
我给 Claude 的要求大概是：
- 设备尺寸按常见 iPhone 屏幕来
- 页面主题偏阅读和内容推荐
- 风格简洁、安静、留白多一点
- 主色调用低饱和橙色 + 米白背景
- 页面包含顶部搜索、推荐书单、分类入口、近期热门、底部导航
这个案例和常见的“登录 / 注册 / 首页”不同，它更容易暴露两个问题：
- 内容型页面的信息层级是否清晰
- 多模块组合时页面会不会显得拥挤
生成过程里的几个观察点
实际跑下来，我发现它不是把整个页面一口气砸出来，而是比较像这样分块处理：
- 先搭整体页面框架
- 再加顶部区域和搜索框
- 接着补推荐书单卡片
- 再往下补分类入口和内容模块
- 最后才做底部导航和整体调整
这个过程很接近真实做原型的顺序，所以成品的结构感会更稳定一些。
这个案例给我的直观感受
优点有几个：
- 页面框架成型很快
- 信息区块之间有基本节奏
- 视觉风格不会乱到完全不可用
- 很适合作为“第一版方向稿”
但也有明显限制：
- 某些卡片内容的排版细节还需要手动调
- 字体层级虽然有，但不一定每次都合理
- 如果提示词太模糊，内容模块容易堆叠得比较平
所以我的结论是：
它很适合快速产出“可讨论的原型”，但还不适合完全替代人工做最终视觉稿。
我总结了一套更实用的 Prompt 写法
如果你真的打算在这套流程里提高生成稳定性，千万不要只写：
<TEXT>
帮我设计一个好看的页面
这种提示词过于抽象，结果通常会很随机。
更好的方式是，把需求拆清楚：
- 页面类型
- 设备尺寸
- 风格关键词
- 主色调
- 页面模块
- 视觉限制
- 是否需要自动检查
比如下面这个模板，我觉得很适合直接改着用：
<TEXT>
请帮我在 Pencil 中设计一个移动端页面原型，尺寸为 390 × 844。
页面类型：读书类 App 的发现页
风格要求：简洁、温和、有留白，偏内容阅读产品
主色调：低饱和橙色 + 米白背景
目标用户：日常阅读用户，年龄 20-35
页面需要包含：
1. 顶部标题区域
2. 搜索框
3. 推荐书单横向卡片区
4. 分类入口
5. 热门内容列表
6. 底部导航栏
设计要求：
- 不要过度装饰
- 保持卡片之间的呼吸感
- 字体层级清晰
- 颜色不要太杂
- 尽量符合真实 App 的使用习惯
生成完成后，请检查页面的布局、对齐和信息层级是否合理，并输出预览结果。
你会发现，当你把约束讲清楚之后，结果稳定性会明显提升。
这套工作流更适合谁？
从我的体验来看，它并不是面向所有人都 equally useful。
更适合的是这些场景：
1. 独立开发者
一个人要同时兼顾产品、设计、开发时，这套方式非常省时间。
2. 前端 / 客户端工程师
你可能有实现能力，但不一定每次都能快速定下页面视觉方向。
这时候先出一版原型，效率会高很多。
3. 做 MVP 的小团队
你们不一定缺代码能力，更多时候缺的是一版可以快速讨论的界面稿。
4. 需要高频验证想法的人
比如做小程序、工具产品、内容产品时，快速看见“页面长什么样”很重要。
哪些场景下，不要对它抱太高期待？
也要说点现实的。
这套方案虽然有用，但它并不是万能的。
下面这些情况，我觉得就不适合把它当成主工作流：
1. 强品牌视觉项目
如果项目特别强调品牌调性、视觉创意和细节控制，它给你的更多只能是一个起点。
2. 复杂设计系统团队
多人协作、规范严格、组件库深度绑定的团队，还是成熟设计工具链更稳。
3. 营销型页面
重插画、重动效、重视觉冲击的页面，不是它最擅长的方向。
4. 需要高精度交付的正式设计稿
它更适合原型、方向稿、低成本试错，不是拿来一步到位交付的。
我踩过的几个坑，也顺手提醒一下
不要把所有页面都塞进一个文件
页面多了以后，管理会非常混乱。
按功能或模块拆开会清楚很多。
提示词一定要具体
如果你只是说“现代一点、高级一点”，AI 很容易自由发挥过头。
第一版别期待完美
它最大的价值是帮你快速启动，而不是一步到位。
最好把它当成“AI 协作设计”
而不是“AI 全自动设计”。
你还是需要对布局、审美和交互做判断。
我的真实判断：它不会取代设计师，但确实改变了开发者做原型的方式
完整跑下来之后，我现在对这套组合的看法很明确：
它不会取代成熟设计工具，也不会让每个开发者立刻变成专业设计师。
但它改变了一件非常重要的事：
开发者第一次拥有了一种更自然的方式，把“需求描述”快速变成“可用原型”。
以前很多项目从想法到落地，中间卡住的不是开发本身，而是：
- 没有设计稿
- 没有明确页面方向
- 只能边写边猜，边改边返工
而现在至少多了一种可能：
- 先说清楚页面要什么
- 让 AI 在画布里做出第一版
- 再围绕这版设计继续调整和开发
如果你本身就是开发者，我觉得这件事值得试一次。
最后：如果你准备上手，可以按这个顺序来
<TEXT>
1. 安装 Pencil.dev
2. 配置 Claude Code 的 MCP
3. 确认 Pencil 服务已连接
4. 从一个具体页面开始试，而不是一整个产品
5. 提示词里写清楚页面类型、风格、模块和约束
6. 先接受“第一版原型”，再逐步细化
7. 满意后再让 Claude 基于设计稿继续生成代码
写在最后
这次体验最大的感受是：
AI 对设计这件事，正在从“给建议”变成“能动手”。
它未必每次都做得足够精细，但只要能把最开始那版原型更快地搭出来，就已经足够改变很多人的工作方式了。
如果你也在折腾 Claude Code、MCP 或者 AI 辅助设计，欢迎交流。
我也准备继续试试：
- 多页面连续设计
- 从设计稿反推前端代码
- 更复杂的信息型页面生成效果
