StreamSparkAI

核心概览

这段访谈围绕 Pencil 的一次实时演示展开：Pencil CEO Tom 展示了 6 个 AI 代理 如何在同一画布上并行设计一个旅行记录与预订应用，并通过可见光标把原本隐藏的 agent 工作过程变得直观、可调试，也更像有人在协作。产品的核心不只是生成界面，而是以 .pen 的 JSON 设计格式 作为中间层，把视觉探索、组件系统、Git 协作和代码生成连接起来：用户可在 Cursor 等编辑器中直接打开设计文件、修改界面，再生成 React、Next.js、Swift、Kotlin 等代码。Tom 将 Pencil 定位为编码前的可视化规划模式，强调先探索多个方向、再收敛到最终方案。访谈还涉及其增长情况、用户类型、创始背景与未来方向；同时也明确提到，多人实时协作 与 代码修改自动回写设计 目前仍未完成。

关键议题与详细总结

1. 实时演示：6 个 AI 代理共同设计旅行应用

• 主持人 Peter Yang 请 Tom 现场演示 Pencil，目标是设计一个移动端旅行应用，需求包括：
  • 记录旅行足迹；
  • 带有预订相关功能；
  • 使用漂亮的城市图片；
  • 画面风格以大洋洲城市为灵感。
• Tom 先说明，Pencil 既可以让单个代理设计，也可以启用 swarm 模式 进行并行协作。
• 本次演示中，他选择了 6 个代理，并说明策略是：
  • 共设计 3 个页面；
  • 每个页面由 2 个代理协作。
• 系统会自动完成几步：
  • 解析用户请求；
  • 生成待办清单；
  • 自动挑选风格指南；
  • 将任务分发给多个子代理；
  • 让代理彼此沟通并并行工作。
• 演示中最打动 Peter 的，不只是生成速度，而是多个光标在画布上同时移动，让整个过程变得可见。

“这些光标让 AI 第一次显得像有人在场。”("Those cursors... it's the first time I have seen AI humanized. It feels like there's someone there.")

• Tom 解释，最初加入光标的动机其实是为了调试并行任务，方便看清哪个代理在改哪个区域；但做出来后，他发现这种可视化会让 AI 的行为更容易被理解，也更具存在感。
• Peter 的反馈是，这种细节设计显著提升了产品震撼力。他认为如果没有这些光标，只看到后台生成内容，体验会弱很多。

“工艺和用心仍然重要；如果没有这些光标，我不会同样震撼。”("craft and care still matter... I would not be as blown away if those cursors were not on the screen.")

2. 产品定位：不是直接写代码，而是先做视觉规划

• Tom 明确提出，Pencil 不是单纯替代设计师或开发者的工具，而是一种更靠前的工作流：
  • 在真正开始编码之前；
  • 先把想法以视觉方式探索出来；
  • 比较多种方案；
  • 再决定是否继续构建。
• 他把 Pencil 类比为 Cursor、Claude Code 等工具里的 plan mode，但强调这里是可视化的 plan mode。

“把 Pencil 看成一种可视化规划模式。”("think of pencil as this like visual planning mode")

• Tom 认为，很多人如今会过快进入代码生成阶段，但其实他们往往还不知道自己到底想做什么。
• Peter 补充说，真实的设计工作不是一次就定稿，而是先发散出多种可能，再收敛到更好的方案。
• Tom 完全认同这一点，并批评很多代码生成平台过于线性、串行：
  • 做一个版本；
  • 再改下一步；
  • 很难并排比较大量方案。
• 他指出，设计文件天然就是探索性的，设计师会复制、分叉、并排比较很多版本；Pencil 想把这种真实设计过程带回 AI 工作流中。

3. 为什么 .pen 文件是核心：一种为 AI 代理设计的中间格式

• Tom 解释，Pencil 不直接把设计锁死在 HTML/CSS 中，而是先生成一种平台无关的描述文件。
• 这个格式叫 .pen，本质上是 基于 JSON 的设计描述格式。
• 之所以这么设计，是因为：
  • 同一个视觉设计，可能最终要输出为 iOS 的 Swift；
  • 或 Android 的 Kotlin；
  • 或 React Native；
  • 或 Web 端的 React / Next.js；
  • 因此一开始就生成某一种前端代码，不一定合理。
• Tom 强调，.pen 是从一开始就按照 agent 可读、可写 的思路设计的：
  • 代理能读取它；
  • 代理能修改它；
  • 它可以进入 Git；
  • 团队成员可以围绕它协作；
  • 企业可以围绕它维护组件库和设计系统。
• 他把这个格式类比为一个适合 AI 时代的设计文件载体，甚至用接近概念化的话来形容它像一个面向 agent 的设计文档格式。
• 访谈中还提到：
  • 官方已公开该格式文档；
  • 外部开发者已经开始围绕 .pen 做插件；
  • 已出现把 .pen 转为 Figma 及其他格式的插件；
  • 个别目标格式名称在转录中不够清晰，[内容不完整]。

4. 与 Cursor 的整合：在代码编辑器里直接做视觉设计

• Tom 演示了 Pencil 与 Cursor 的联动方式：
  • 在 Cursor 中打开一个 .pen 文件；
  • 文件会直接以可视化编辑器形式打开，而不是纯文本。
• Peter 对此反应很强烈，因为这意味着设计能力被直接嵌进了编码环境。
• Tom 解释，这其实是 Pencil 很早的起点之一：先做 Cursor 内的自定义编辑器，再逐步发展成独立应用和多平台工具。
• 用户使用方式相对简单：
  • 在编辑器扩展商店安装 Pencil；
  • 打开 .pen 文件；
  • 即可在编辑器里直接进行视觉编辑。
• Tom 还展示了在 Cursor 中混用不同模型：
  • 用较快的模型去做局部设计调整，例如把某个页面改成浅色模式；
  • 再用另一模型把视觉设计转换为代码。
• 演示中，他将一个咖啡店页面从设计文件直接生成：
  • React；
  • Tailwind；
  • Next.js；
  • 并让它运行在浏览器的指定端口。
• 生成结果成功跑起来后，Peter 追问了一个关键问题：如果改了代码，设计文件会不会自动同步？
• Tom 的回答是：目前不会自动双向联动。如果在代码侧改动，需要再让 LLM 去更新设计文件。
• 这表明 Pencil 当前更像是：
  • 以设计文件为核心源头；
  • 再驱动代码生成；
  • 而不是完整实时双向同步系统。

5. 设计系统、变量和提示节点：让团队更容易统一规则

• Tom 展示了几个面向团队协作的机制：
  • 变量系统：类似 CSS 变量，可在文档中复用；
  • 组件库：内置大量设计组件；
  • 设计系统接入：可在企业场景中沉淀统一规范；
  • 提示节点：像贴纸或便签一样，把常用 prompt 存到文档中。
• 他特别提到，提示节点可以帮助团队形成一致的设计规则：
  • 方便为同事准备固定指令；
  • 让 PM、设计师等角色基于同一套方法工作；
  • 让代理在已有组件和规则内生成界面。
• 演示里，代理会先读取需要的组件，再在画布上组合出页面。
• Peter 对此再次表示震撼，认为这不仅是自动生成界面，而是在已有设计系统约束下做更可控的生成。

6. 工作流上的关键差异：人和 AI 可同时在画布中工作

• Tom 认为，Pencil 与很多常见的 vibe coding 产品相比，最大的差异之一是：
  • 代理在生成时，用户仍然可以继续手动编辑画布；
  • 不需要等 AI 完成后才能操作。
• 他认为这会显著改善创作流畅度：
  • 传统聊天式生成工具常常要不断等待；
  • 用户若只想改一点文本、挪一下按钮，也得再写 prompt；
  • 这会打断思路。
• Pencil 的画布工作流则允许：
  • 自己先画；
  • 再让代理接着做；
  • 或在代理做的同时手动干预。
• Tom 还回顾了产品最初的念头：与其不断向 agent 解释按钮间距、颜色、风格，不如直接画出来再让 agent 接手。
• 这也是他坚持视觉优先的根本原因：很多时候，人需要先看到，才知道自己真正想要什么。

7. 用户是谁：不只是设计师，也不只是工程师

• Peter 问到 Pencil 的核心用户群体时，Tom 的回答是：实际用户比他预想得更广。
• 他观察到，不同岗位的边界正在松动，越来越多人开始朝“能独立做事的人”靠拢。
• 访谈中被明确提到的用户类型包括：
  • 设计师；
  • 工程师；
  • 产品经理；
  • 营销人员；
  • 企业团队。
• 一个具体案例是：
  • Tom 的一位从事营销工作的朋友，用 Pencil 配合 Claude Code 的桌面版；
  • 重做了网站、营销素材、广告、PDF、销售技术说明等内容。
• Tom 认为，Pencil 在这些人中起到的是一个AI 设计画布的作用，让原本不擅长代码的人也敢开始动手。
• 在企业场景下，Tom 提到已有公司会把自己的设计系统转成 .pen 格式，放进 Git，作为团队共同维护的源文件。

8. 协作现状：多人实时协作还没有，但 Git 已经在发挥作用

• Peter 追问能否像在线设计工具那样多人同时协作。
• Tom 明确表示：
  • 目前还没有真正的多人实时协作功能；
  • 这项能力“还没上线”。
• 但他也说明，当前很多团队是这样协作的：
  • 把 .pen 文件放进 Git；
  • 围绕它做版本管理；
  • 再交接给开发者落地。
• 这说明 Pencil 当前更偏向代码仓库式协作，而不是在线实时协同画布。

9. 产品发展历程与增长情况

• Tom 介绍了产品起源：
  • 开始于去年年初；
  • 当时他在使用 Cursor、Claude Code 等工具做别的项目；
  • 逐渐觉得仅靠聊天描述 UI 太费力；
  • 于是产生了“为什么不能直接画出来”的想法。
• 他曾在 VS Code 等扩展市场寻找类似工具，但没有找到合适产品，于是快速做出原型。
• 原型发布后的反馈很强：
  • 在 LinkedIn 和 X 上累计获得约 100 万次观看；
  • 让他意识到，很多人都有相同痛点。
• 随后团队进入一个名为 Speedrun 的创业项目，项目所属机构在转录中表述不清晰，疑似 a16z Speedrun，但原文机器转录存在误差，[不确定]。
• Tom 还提到：
  • 产品全量上线约 8 周；
  • 当前已有 10 万用户。
• 对他来说，这些数据说明问题真实存在，且需求广泛。

10. Tom 的背景与产品理念形成

• Tom 的职业经历与 Pencil 的方向高度一致：
  • 曾做过视频会议产品 Around，后被 Miro 收购；
  • 更早之前做过 3D Avatar 方向创业；
  • 曾在 Adobe 工作约十年；
  • 更早还从事过创意软件相关推广与设计工具工作。
• 他从小在父母的设计公司环境中长大，接触 Photoshop、CorelDRAW、Illustrator、InDesign 等工具。
• 后来他逐渐从平面设计转向网页与交互，并提到自己对 Flash 很有感情。
• Tom 的一个核心判断是：
  • Flash 曾经让“设计”和“编码”在同一处发生；
  • 此后很多年，这种一体化体验并没有真正被延续；
  • 如今随着 AI 代理变强，设计与编码重新融合的机会又出现了。
• 他也补充提醒：普通人现在确实更容易做出应用，但这不等于生成结果天然就是生产级、安全、可直接发布的产品。

11. 对未来的设想：让 AI 更透明、更有个性

• 访谈最后，Tom 说 swarm 功能上线后，他感觉新的产品空间突然被打开了。
• 对他来说，真正令人兴奋的，不只是多代理本身，而是如何把 AI 的行为呈现出来。
• 他和 Peter 提到的未来方向包括：
  • 支持给代理自定义名字；
  • 赋予代理更多个性；
  • 甚至加入语音、对话、动画效果；
  • 让代理之间看起来像真的在协作。
• 这些设想并非都已落实，但反映出 Tom 的方向感：AI 产品不应只在后台默默产出结果，还应让人看见过程、理解分工，并感到它有“在场感”。
• 访谈结尾，Tom 邀请用户前往 Pencil 官网下载产品、加入 Discord 社区，并欢迎反馈需求与问题。

12. 插播内容

• 访谈中有一段赞助插播，Peter 介绍了 Linear：
  • 它可与 Cursor、Codex 等 agent coding 工具集成；
  • 让团队看到代理正在处理什么任务、由谁分配；
  • 目的在于提高 AI 协作中的可见性。
• 这段内容属于广告信息，与 Pencil 产品本身无直接功能关系。

数据与统计信息汇总

• 并行代理数：6 个——用于同时设计 3 个页面。
• 产品原型传播：约 100 万次观看——验证了早期需求。
• 全量上线时间：约 8 周前——产品仍处于较早阶段。
• 用户规模：约 10 万用户——说明已有明显市场反馈。
• 协作现状：多人实时协作未上线——当前主要依赖 Git。

决策与建议

已明确的产品方向与动作

• Tom 表示正在推进代理重命名功能，回应用户希望为不同代理赋予身份的需求。
• Pencil 当前推荐的工作流已经比较明确：
  • 先在画布中做视觉探索；
  • 确定方向后再生成代码；
  • 把 .pen 文件作为核心设计源文件管理。
• 企业使用场景下，Tom 已明确支持把设计系统转成 .pen 格式并纳入 Git，作为统一源头。
• 官方已给出用户行动入口：
  • 到官网下载安装；
  • 加入 Discord 社区；
  • 反馈功能需求和 bug。

访谈中提出的建议

• Peter 建议进一步增强代理之间的互动感和人格化表现，例如让它们互相交流、争论，甚至拥有更明显的角色差异。
• 双方都认为，未来值得继续加强两类能力：
  • 过程透明度：让用户更清楚每个代理在做什么；
  • 情感与个性表达：让 AI 协作更像真实团队协作。
• 从实际使用角度看，访谈隐含给出的操作建议是：
  • 当需求还不明确时，先用 Pencil 发散多个视觉方案；
  • 当方案稳定后，再交给代码代理实现；
  • 若代码已改动，需要再显式要求 LLM 同步回设计。

不确定性与待确认点

• 代码到设计的自动回写目前并不存在。Tom 明确表示，如果代码改了，需要再让 LLM 去调整设计文件。
• 多人实时协作尚未上线，当前协作主要依赖 Git；后续是否会推出原生多人模式，原文未明确说明。
• 若干工具或项目名称在机器转录中不够清晰，例如某些插件名称、以及 Speedrun 所属机构名称，相关细节应视为 [不确定]。
• 图片生成底层模型并未详细列出，Tom 只表示可以接入多种图片生成器，并持续选择效果更好的方案。
• Tom 提到普通人现在更容易做出应用，但同时承认其结果未必适合直接上线、未必足够安全；具体如何解决生产级质量问题，原文未展开。
• 商业模式、定价、团队规模、融资情况等信息，转录文本中未提及。

结论回顾

• Pencil 的关键创新不只在多代理生成，而在于把 AI 设计过程可视化、可编辑、可协作，尤其是通过光标显著提升了理解与信任感。
• .pen JSON 文件是产品中枢：它连接了设计探索、设计系统、Git 协作与多平台代码生成。
• Tom 试图推动的不是单一设计工具，而是一种设计与编码重新合流的工作方式；但实时多人协作与双向同步仍是当前明显短板。