StreamSparkAI

核心概览

这期访谈围绕 Pencil 的一次实时演示展开。Pencil CEO Tom 向 Peter Yang 展示了：用户给出一句设计需求后，6 个 AI 智能体（agent）可以在同一块画布上并行设计应用界面，并通过可见光标把原本隐藏的生成过程变成可观察、可理解的操作过程。Tom 将 Pencil 明确定位为编码前的“可视化规划模式”：先在画布上探索方向、比较方案、沉淀设计，再决定是否把它转换成代码。

Pencil 的关键不只是“生成 UI”，而是围绕 .pen 文件建立了一层中间表示：它本质上是一个基于 JSON 的、面向智能体读写的设计格式，既能在独立应用中编辑，也能在 Cursor、VS Code、Windsurf 等编辑器里以可视化方式打开，还能与 Claude Code、Codex 以及用户自带的 agent / CLI 工具配合工作。基于这层格式，Pencil 将视觉探索、设计系统、Git 中的版本协作、以及多平台代码生成串了起来。

访谈中还明确了它当前的边界：多人实时协作尚未上线；代码改动不会自动实时回写到设计文件，需要再让大模型去同步设计；普通人虽已更容易做出应用，但生成结果未必直接达到生产级、未必足够安全。

详细摘要

1. Pencil 的产品形态：独立应用 + 编辑器插件 + 可接入现有 agent 工作流

Tom 一开始先交代了 Pencil 的基本形态。它不是只存在于某一个编辑器里的小插件，而是同时具备几层产品形态：

• 有独立应用，可运行在 Windows、Linux、Mac；
• 也有编辑器插件，可用于 VS Code、Cursor、Windsurf 等基于 VS Code 的环境；
• 能与现有的 agent 编码工具配合，包括 Claude Code、Codex；
• 也支持用户“自带 agent”，接入自己常用的 CLI 工作流，Tom 提到有人甚至拿它去配合 OpenCode 以及各种他此前都没听过的 CLI 工具使用。

这个定位非常重要：Pencil 不是想取代现有编码工具，而是成为这些工具前后的视觉中间层。用户可以把它当作设计工具单独使用，也可以把它嵌入已经熟悉的开发环境中，把“设计—代码”的切换尽量压缩到同一个工作流里。

2. 实时演示：6 个 AI 智能体共同设计一个旅行应用

Peter 请 Tom 现场演示 Pencil，需求是做一个移动端旅行应用，方向大致包括：

• 记录旅行足迹；
• 带一点预订相关能力；
• 使用漂亮的城市图片；
• 视觉风格参考大洋洲城市。

Tom 随后开启了 Pencil 的群体协作模式（swarm）。他说明，既可以只让一个智能体完成设计，也可以同时启用多个智能体并行工作。这次演示里，他选择了 6 个智能体，并采用了一个直观的拆分方式：

• 总共设计 3 个页面；
• 每个页面由 2 个智能体协作处理。

系统随后会自动完成几件事：

• 分析用户请求；
• 生成待办清单；
• 自动挑选合适的风格指南；
• 把任务分发给多个子智能体；
• 让这些智能体彼此沟通并开始在画布上设计。

Tom 还提到，图像部分并不是固定绑定某一个模型。Pencil 可以接入多种图像生成器，团队会持续替换成当前效果更好的方案。这也说明它的架构本身是开放式的，而不是被某一个图像模型锁死。

3. 这套并行方式的关键：不是“多开几个 agent”，而是同类能力并行拆分

访谈里一个很关键的技术点是，Tom 明确区分了两种“并行”：

一种是很多平台现在常见的做法：给不同智能体分配不同角色，例如一个写代码、一个测、一个查文档、一个做别的任务。
而 Pencil 更强调另一种方式：让同类能力的智能体围绕同一个设计任务做非冲突拆分。

Tom 的意思是，Pencil 追求的不是简单“多开几个窗口”，而是让多个具备相似设计能力的智能体，在同一画布任务里各自处理不同区域或不同部分，既避免互相冲突，又保持模型能力本身不被削弱，同时把速度提上来。

这也解释了为什么 Pencil 特别强调画布、任务拆分和可视化过程：
它要解决的不只是“让多个 agent 同时跑”，而是“让并行工作对人来说可见、可理解，而且确实是在一个统一设计任务里协同推进”。

4. 为什么可见光标会让体验发生质变

演示过程中，Peter 最震撼的不是“AI 在生成界面”这件事本身，而是多个光标同时出现在画布上、各自移动。他反复强调，正是这些光标，让整个过程第一次显得像“真的有人在这里工作”。

Tom 解释说，最初加入光标的动机其实非常务实：
因为系统内部已经有并行机制了，但他自己调试时也看不清“到底是谁在改哪里”，于是先加了光标来帮助排查问题。结果一做出来，他发现这个细节的作用远超调试本身。

它带来的变化有几层：

• 可观察性：用户能直接看到哪个智能体正在处理哪个区域；
• 可理解性：并行工作不再是黑箱，用户能大致跟上系统在做什么；
• 存在感：AI 不再只是后台“吐结果”，而像是在眼前操作画布；
• 信任感：即使底层本质上仍然是在写 .pen JSON，视觉层把这个过程翻译成了人可理解的动作。

Peter 的评价也很直接：如果没有这些光标，他不会同样震撼。
换句话说，这不是一个无关紧要的 UI 小细节，而是把 AI 从“后台执行器”变成“前台协作者”的关键界面设计。

5. Pencil 的核心定位：编码前的可视化规划模式

Tom 对 Pencil 的定位说得很明确：
它是编码前的“可视化规划模式（plan mode）”。

他认为，很多人现在拿到一个想法后，会很快冲进 Claude Code、Cursor 这类工具里直接开始生成代码，但当时他们往往还不知道：

• 这个东西是不是真的值得做；
• 它长什么样才合理；
• 哪种方向更好；
• 有没有另一套方案更适合。

Pencil 解决的是前面这一步：
先在画布里把想法做出来，快速看见它，分叉出多个版本，比较不同方向，等确定“这就是我要的东西”之后，再去要求 agent 把它变成代码。

Peter 也补充了一点很贴近真实设计流程的观察：真正的设计师不会只做一个版本，而是会先发散探索很多可能，再收敛到一个更优解。Tom 对此非常认同，并指出不少 AI 编码平台的问题在于工作流太线性：

• 做一个版本；
• 改一点；
• 再做下一个；
• 很难并排看很多方案。

而设计本身天然就是探索式的。Tom 提到，设计文件往往本来就很“乱”，因为设计师会不停复制、对比、偏移、尝试，这恰恰是思考发生的地方。Pencil 想保留的，就是这种探索先行、收敛随后的过程。

6. .pen 文件为什么是产品中枢：一种为智能体设计的中间格式

Tom 反复强调，Pencil 的关键不只是画布，也不只是代码生成，而是中间这层 .pen 文件。

它的几个核心特征是：

• 本质上是 JSON；
• 描述的是完整设计，而不是某一种具体平台代码；
• 从一开始就是按“智能体可读、可写”来设计的；
• 可以作为设计源文件进入 Git；
• 能被不同工具读取、转换、生成不同目标代码。

Tom 解释，之所以不直接把设计生成成 HTML/CSS，是因为这不符合实际场景。一个设计最后可能要变成：

• iOS 的 Swift；
• Android 的 Kotlin；
• React Native；
• Web 的 React / Next.js。

既然最终平台可能不同，那么前面这层设计文件就应该是平台无关的描述。.pen 正是承担这个角色。

Tom 还用了一个形象的比喻：如果 PDF 是在今天这个 AI 智能体时代被重新发明出来的，一种更适合被 agent 处理的设计文件，大概就会长得像 .pen 这样。

围绕 .pen，Pencil 也已经形成了初步生态：

• 官方公开了格式文档；
• 外部开发者已经开始写转换插件；
• Tom 提到已经看到了把 .pen 转到 Figma 以及其他格式的插件。

因此，.pen 不是单纯的内部存储格式，而是 Pencil 想建立的工作流中枢：画布上的设计、组件系统、Git 中的协作、代码生成，都是围绕它展开。

7. 在 Cursor 里直接打开设计文件：把设计工具嵌进代码环境

接下来，Tom 演示了 Pencil 与 Cursor 的结合方式。

他在 Cursor 中打开一个 .pen 文件后，这个文件不会只以纯文本 JSON 的方式出现，而是会直接进入 Pencil 提供的可视化编辑器。Peter 当场就抓住了这个点，因为这意味着：

• 设计文件并没有脱离开发环境；
• “看设计”和“写代码”不再是两个完全分离的地方；
• 开发者可以直接在自己熟悉的 IDE 里进行视觉编辑。

Tom 也提到，这其实是 Pencil 最早的起点之一：先在 Cursor 里做出了自定义编辑器，之后才逐渐扩展成独立应用和更完整的产品。

实际使用方式也不复杂：

• 到扩展商店安装 Pencil；
• 打开 .pen 文件；
• 文件就会在编辑器里以视觉方式呈现出来。

这里能看到 Pencil 很鲜明的路线：
不是把设计师拉进代码编辑器，而是把设计能力嵌进开发者已经常驻的工作环境。

8. 从设计到代码：同一个文件既能视觉编辑，也能驱动代码生成

在 Cursor 演示里，Tom 展示了一个非常完整的流程。

首先，他用 Cursor 里的 agent 对已有的 .pen 设计做快速修改，例如把选中的页面改成浅色模式。随后，他又切换模型，要求系统把某个画框直接生成代码，并指定：

• 目标技术栈是 React + Tailwind + Next.js；
• 跑在浏览器指定端口。

系统随后会读取 .pen 文件中的结构、样式、组件描述，分析后生成前端代码，并直接把页面跑起来。Tom 展示出来的结果，就是从一个咖啡店首页设计，直接生成了可运行的网站。

这里有两个重要信息：

1. 不同模型可以混用
   在 Cursor 这样的环境里，用户可以根据任务性质切换模型：快的模型做局部调整，强的模型做代码生成。

2. .pen 是源头文件
   设计改动优先发生在 .pen 这一层，然后再由它驱动代码生成。

Peter 随后问了一个很关键的问题：
如果用户直接改代码，这个变化会不会自动同步回 .pen？

Tom 的回答很明确：目前不会实时双向同步。
如果代码变了，需要再让 LLM 根据代码调整设计文件。也就是说，当前更准确的理解是：

• .pen 是设计真源；
• 代码可以由它生成；
• 但代码侧的修改不会自动无缝回流到设计侧。

9. 变量、组件库与提示节点：把团队规则放进设计文件里

除了单次生成，Tom 还展示了 Pencil 用来维持一致性的几类机制：

变量系统

可以定义类似 CSS 变量的内容，在整个文档中复用。
这意味着颜色、间距、主题等规则，不是散落在每个元素上，而是能形成一致的设计约束。

组件库与设计系统

Tom 展示了一批现成组件，包括较复杂的表格类组件，还提到它们支持不同模式与色调切换。
这让 Pencil 不只是“自由生成”，而是能在已有设计系统框架内工作。

提示节点（prompt nodes）

这是访谈里一个很有意思的能力。Tom 说它们像是贴在画布里的便签，可以把常用 prompt 预先存进文档。这样做有几个用途：

• 给同事准备标准化的生成指令；
• 让 PM、设计师等不同角色基于同一套规则工作；
• 让 agent 在读取组件和约束之后，再去生成符合团队规范的页面。

演示中，Tom 点击运行后，智能体会先读取需要使用的组件，再把这些组件组合到画布中。
这表明 Pencil 想做的不只是“AI 随机出图”，而是在团队规则与设计系统约束下的可控生成。

10. 工作流上的关键差异：人在画布里始终可以接管和继续编辑

Tom 认为，Pencil 与很多“聊天式生成界面”的最大差别之一，是人在 AI 工作时仍然可以直接操作画布。

他的意思是，很多常见的 AI 应用构建工具有这样的问题：

• 你下一个 prompt；
• 系统开始生成；
• 你得等它结束；
• 如果只想改一行字、挪一个按钮，也得再回到对话框里重新说。

这会不断打断思路。

而在 Pencil 里，用户可以：

• 自己先画出一个方向；
• 让智能体继续补完；
• 在智能体还在工作时直接上手改页面；
• 一边看结果，一边继续调。

Tom 认为，这种“画布工作流”最大的价值，是保持创作流不断掉。
它不是让人完全退出操作，而是让人和智能体在同一个可视空间里接力。

他也提到，这其实正是产品最初的灵感来源：
与其花大量精力用语言解释按钮的 padding、颜色、层级和风格，不如直接画出来，让 agent 去理解和完成。因为很多时候，人并不是一开始就知道自己要什么，而是先看到，再调整，最后才确认。

11. 用户群体比预期更广：设计师、工程师、PM、营销、企业团队都在用

Peter 问到 Pencil 的用户主要是谁，Tom 说，实际情况比他原先想的更广。

他观察到，传统岗位边界正在变得模糊：

• 设计师在向设计工程方向靠近；
• 工程师开始承担更多项目完整性工作；
• PM 也因为这些工具而更有创造力；
• 甚至不少原本不写代码的人，也开始借助这些工具搭建自己的东西。

Tom 提到一个很具体的例子：
他的一个做营销的朋友，使用 Pencil 配合 Claude Code 桌面版，重做了：

• 网站；
• 营销素材；
• 广告；
• PDF；
• 销售使用的技术说明材料。

这让 Tom 意识到，Pencil 并不只服务某一个职业，而更像是一块AI 设计画布。不同角色都可以把它纳入自己的工作流，只是各自接法不同。

企业侧也已有比较明确的使用方式：
把公司的设计系统转换成 .pen 格式，纳入 Git，把它作为团队的统一源文件，再围绕它生成界面和代码。

12. 当前的协作方式：以 Git 为主，多人实时协作尚未上线

Peter 追问，Pencil 是否已经支持像在线设计工具那样的多人实时协作。

Tom 的回答非常明确：还没有。

也就是说，当前不能把 Pencil 理解成已经具备 Figma 式的多人同屏编辑能力。
现阶段更现实的协作方式是：

• 把 .pen 文件放进 Git；
• 团队成员围绕它做版本管理；
• 设计通过 .pen 与组件系统沉淀下来；
• 开发者再在此基础上接手实现。

Tom 还提到，从不少设计师的反馈看，这种方式也很适合做交接：
设计文件不再只是静态稿，而是可被智能体读取和生成代码的中间层。

13. 产品起源与增长：从“为什么不能直接画出来”开始

Tom 回顾了 Pencil 的起源。

项目开始于去年年初。当时他自己也在使用 Cursor、Claude Code 这类工具做其他项目，过程中越来越强烈地感受到：
单靠聊天去描述 UI 太费力了。

他不断需要向 agent 解释：

• 页面应该长什么样；
• 按钮的风格是什么；
• 颜色和层级怎么处理；
• 交互应该是什么感觉。

于是他产生了一个很直接的念头：
既然设计本来就是视觉性的，为什么不能直接画出来？

他去 VS Code 市场里找类似工具，没找到满意的，于是自己快速做了一个原型。这个原型发布后，在 LinkedIn 和 X 上累计拿到了大约 100 万次观看，让他意识到这个问题并不是个人痛点，而是很多人都碰到的共性需求。

随后团队进入了 a16z Speedrun。
Tom 还提到：

• 产品完整 GA 大约是 8 周前；
• 现在已经有 10 万用户。

这些数字说明，Pencil 并不是只有演示效果吸引人，而是已经在较早期就获得了明确的市场反馈。

14. Tom 的背景如何塑造了 Pencil 的方向

Tom 的个人经历和 Pencil 的路线高度一致。

他此前做过的视频会议产品 Around 在疫情期间很受欢迎，后来被 Miro 收购；更早以前，他还做过 3D Avatar 方向的创业项目；再往前，他在 Adobe 工作了大约十年，也长期接触设计工具相关工作。

他还提到自己的成长背景：父母开设计公司，所以他从小就在设计师的环境里长大，很早就开始接触 Photoshop、CorelDRAW、Illustrator、InDesign 等工具。

后来他从传统平面设计逐步转向网页与交互，并特别提到自己对 Flash 的认同。原因是，在他看来，Flash 是少数真正让设计和编码在同一个地方发生的工具之一。此后很多年，这种体验并没有被很好继承下来。现在，随着 AI 智能体能力变强，这种“设计与编码重新合流”的机会又回来了。

不过 Tom 也保持了边界感。他明确说，虽然现在普通人几乎也能做出一个移动应用了，但这并不意味着：

• 它一定是最好的应用；
• 一定能直接上线；
• 一定具备足够安全性。

也就是说，“能做出来”与“达到生产级”仍然是两回事。

15. 关于未来：让 AI 更透明、更有人格，但目前更多仍是探索方向

访谈最后一段更接近开放讨论。Tom 说，swarm 功能上线后，他感觉新的产品空间突然被打开了。对他来说，真正让人兴奋的，不只是“多个智能体并行工作”，而是：

• 如何把它们做得更透明；
• 如何让用户更清楚每个智能体在干什么；
• 如何赋予这些智能体更多“在场感”。

在这个话题上，Tom 和 Peter 聊到了一些未来可能性，包括：

• 给智能体自定义命名；
• 为不同智能体加入更鲜明的个性；
• 甚至让它们“说话”；
• 做出更拟人化的表现，例如彼此互动、击掌之类的动画。

其中，智能体重命名是 Tom 明确说正在考虑推进的功能；其余更多是访谈中的设想与讨论，而不是已经确定的正式路线图。

Tom 最后也邀请用户去 pencil.dev 下载产品、加入 Discord 社区反馈问题和想法。社区里已经有大量用户在分享设计、交流需求和报告 bug。

16. 插播内容

访谈中有一段赞助插播，Peter 介绍了 Linear 与 Cursor、Codex 等 agent 编码工具的集成能力，强调其价值在于让团队看见某个 agent 正在处理什么任务、由谁分配。
这段内容属于广告，与 Pencil 的具体功能无直接关系，但它与本期主题在“AI 工作过程的可见性”上形成了呼应。

关键信息汇总

• Pencil 的定位：编码前的可视化规划模式，先探索视觉方案，再决定是否进入代码实现。
• 核心演示：6 个 AI 智能体在同一画布上并行设计 3 个页面，每个页面由 2 个智能体协作。
• 并行方式的特点：不是简单多开 agent，而是让同类能力的智能体做非冲突拆分，提升速度和可观察性。
• 最强辨识度体验：多个光标实时出现在画布上，让智能体工作过程变得可见，也显著增强了“在场感”。
• 核心技术中枢：.pen 是基于 JSON、面向智能体读写的设计格式，承担设计、组件、Git 协作和代码生成之间的中间层作用。
• 生态位置：Pencil 同时支持 Windows / Linux / Mac，并可在 VS Code、Cursor、Windsurf 等环境中使用，也能与 Claude Code、Codex 及用户自带 agent / CLI 配合。
• 代码生成能力：可从 .pen 生成 React、Next.js、Swift、Kotlin、React Native 等目标形式。
• 开放架构：图像生成可接入多种模型；.pen 也已出现外部转换插件。
• 当前增长：原型传播量约 100 万次观看；完整 GA 约 8 周；用户规模约 10 万。

当前限制

• 多人实时协作尚未上线，当前团队协作主要依赖 Git 与文件交接。
• 代码改动不会自动实时回写到 .pen，需要再通过大模型去同步设计。
• 虽然现在更多非技术用户也能做出应用，但生成结果未必达到生产级，也未必天然安全。
• 转录中部分插件或项目名存在机器识别误差，个别细节名称无法完全确认，但不影响整体逻辑。

讨论中的未来可能性

• 给不同智能体自定义命名；
• 提升智能体行为的可见性和人格化表达；
• 增加语音、互动或更强的“协作感”表现；
• 继续把 AI 从后台黑箱执行器，变成前台可观察的工作伙伴。

总结

这期内容最重要的结论，不是“AI 又能自动做一个 App 了”，而是 Pencil 展示了另一种更完整的路径：

先把想法放到可视画布上，用多个智能体并行探索；再用 .pen 这样的中间格式把设计沉淀下来；最后根据目标平台生成代码。

相比把一切都塞进聊天框，Pencil 强调的是：

• 过程可见
• 设计先行
• 中间层明确
• 与现有开发环境和 agent 工作流兼容

在当前阶段，更准确的理解是：Pencil 已经把“视觉探索 + 智能体并行 + 代码生成”连成了一条链，但实时多人协作与设计/代码双向自动同步仍未完成。