最近，我看了很多遍 Cursor 首席设计师 Ryo Lu 的访谈。Ryo 曾是 Notion 的首席设计师，今年跳槽到了 Cursor。
Ryo 不是那种传统意义上只关注界面设计的设计师，尤其是加入 Cursor 之后，他已经开始通过 Vibe Coding 写代码，参与产品原型的开发。
我觉得这才是新一代设计师、产品经理该有的样子。
这期访谈里面有很多值得反复讨论的细节，Ryo 他的视角讨论了 Cursor 是什么，AI 产的设计原则，新一代创作者的设计方式等话题。我们团队做了精编翻译。
#01 多种形态下的 Cursor 体验
主持人：我今年早些时候看到你发的一条推文，你提到了一些在 AI 时代设计工具的建议。其中有一句是要以系统思维为主，而不是只关注单个功能。
所以我们先退一步，从更底层的原则层面聊聊，你是怎么一步步把 Cursor 背后的概念和思维模型简化下来的？
Ryo Lu：我的一般思路是，要完全理解整个系统。我想尽可能多地了解每部分的信息，不管是来自外部，比如用户、Bug 报告、反馈，还是来自内部团队，当然也包括代码里实际是怎么实现的。
然后尽可能想出更好的做事方式，比如把事情简化，当然这不是说把某些东西简单删除，而是把它们统一起来。也就是说，用户原本做的那些事、用的那些功能都还在，但我们把它们重新组织起来，让它们变得更简单一些。
比如说，原来是五个概念，现在只用一个。就好像是在给同一个东西做分层。对大多数用户来说，他们用 Cursor 的默认 Agent 模式就够了，什么都不用改，理想状态下就应该能直接用。
但我们其实是想服务所有人，既包括那些很资深、想要手动控制一切的工程师，也包括那种更注重感觉的用户，他们喜欢让 Agent 全权处理；当然还有介于两者之间的各种配置、用法、行为模式。
我们希望每个人都能根据自己的需求和习惯，找到到最适合自己的用法。
当然有时候我们也会判断错，这时候我们要设计一些机制，让用户可以自己慢慢往一边或另一边调整。不能一刀切，比如直接把 Agent 设为默认，让所有人都只能用这个，然后不留后路，把其它东西都删了。
否则用户就会懵了，我原来用的那个功能去哪儿了？怎么一下子过渡到新系统了？这样用户完全找不到连续性，也不知道怎么从现在走到下一个阶段。
我们不是要把五个独立的小东西变成一个圈，变成只有这一个，而是我其实还是有办法做那五个不同的事情，只不过是用一种新的、更统一的方式来做。这其实就跟现实生活中的很多事情变化差不多。
但我可以说说现在的情况。现在每个进 Cursor 的用户，看到的都是三个按钮，但很多人其实不知道这些按钮是什么意思。
比如有 Open project，需要先在我们的文件系统里建个包含代码的文件夹；还有 Clone repo，可很多人会懵，什么是 repo？还有 Connect via SSH 这样的选项，那 SSH 又是什么？
其实编程圈以外的人几乎没人懂这些概念。其实不光是工具本身，整个做软件这件事，围绕软件开发的那些角色，比如设计师、产品经理、数据相关的人，大家最终做的其实就是影响最后写出来的代码。
我们其实都在参与这个代码怎么写出来的游戏。软件开发中，什么东西该做成什么样，怎么做？一旦 AI 能帮我们把这些东西转化为代码，这就变成了协作，是人与 AI 的配合，是团队的事情。
不是 AI 替代了创作者，而是 AI 覆盖掉他们不擅长的那部分，甚至让大家能力大幅提升。比如本来能力一般的工程师能变成 10x 工程师，10x 工程师能变成 1000x，设计师也能像十个工程师一样做事情。
人们可能一开始只是随便 Vibe Coding，后来好奇这到底是啥，于是就开始学，比如 React、Next.js、Tailwind CSS，然后能做的东西越来越多，作品也越来越好。
我不希望工具变成给设计师用的 Cursor，或者给产品经理用的 Cursor，我只想让 Cursor 还是那个 Cursor，只是 Agent 的体验可能会因人而异。
主持人：那我们再多聊一点，因为到现在，打开 Cursor 还是感觉像个 IDE，你们也确实利用了这种熟悉感。
但现在产品其实被两股力量拉扯着，一边是新兴的 Vibe Coding 和那些根本不知道 IDE 应该是什么样的人，另一边则是越来越强的 Agent 世界，越来越多的事情可以并行处理，未来软件创作可能更多是把人放在关键节点参与，而不是全程写代码。
你能聊聊，怎么平衡这种 IDE 的熟悉感和保持一个可以无限扩展的系统？比如说，未来的 Cursor for X 其实就还是 Cursor，用户可以在电脑上干任何事。
Ryo Lu：对，IDE 只是 Cursor 的一种形态。我们一开始选择这个形态，不是我定的，其实大家选的是 VS Code，因为它是最流行的代码编辑器，程序员都知道它。然后我把最新的 AI 能力深度融合进去，出一些全新工具，能很契合这种工作流。
从一开始手动写代码，到代码自动补全，再到可以编辑局部代码，到现在可以针对整个文件、整个代码库提问，现在的 Agent 已经能主动做事了，比如发起两次调用、自动修改、自己搜索等等。
有的操作可以在一个线程里做，有的能同时在前台开三个线程，这就像我们的 Tab 功能。再到后来，后台 Agent 一下能做十件事，甚至是并行、串行地同时进行，这其实也是一个逐步演进的过程。
但 Cursor 到今天其实早就不限于 IDE 了。我们上线了 Slack 集成，有网页版 Agent，还能在手机和各种浏览器上用。你可以感受到，这其实只是同一个东西的不同形态。
不同的人、甚至在同一个工作流的不同阶段，可能会喜欢用不同的形态。比如程序员最喜欢手动输入，觉得那才有掌控感，其实每个人的需求和习惯都不一样。
有的人甚至不会用 IDE 版的 Cursor，只用网页，甚至都不碰代码，只是在高层做一些规划，比如看板，但本质上还是在用 Cursor，还是同一个东西。
有时候我们打开电脑，打开 Cursor，所有东西都还在。我可以一键切换不同分支，合并、尝试不同方案，可以随时随地开始一个东西，途中随时切换设备，最后在电脑上收尾。其实一切都取决于我是谁、我正在做什么。
#02 多 Agent 管理背后的思考
主持人：我很想聊聊你自己具体的工作方式，但在此之前，我得先问问你对于软件创作未来的看法。
你刚刚描述的现实是，你可能完全看不到代码，可以随时随地用 Cursor，有无数个 Agent 同时帮你做事。你肯定比大多数人都想得多。那你现在脑子里都在思考些什么？
Ryo Lu：要实现这些，得先解决一些非常难的、很深层的 AI 技术难题。可能是建模相关，也可能是把整个系统做得更好来支撑这些场景。
然后如果 Cursor 对每个人、每种需求来说都是不一样的，那它到底算什么？
我们还是得回到系统层面去想，有哪些核心步骤是永远不会变的，可以支撑所有这些可能性？人们会喜欢哪种形态？我该给大家，或者给某些群体什么样的默认选项？我们到底最关心哪些用户，最先从哪里切入？
有了这些思路，才能看清事情会往哪里发展。
主持人：那在你把产品推进到多 Agent 并行和多列表这种方向时，有没有遇到什么具体的设计难题，是你花了很多时间去琢磨的？能不能聊聊这个过程？
Ryo Lu：我这个月基本都在想这个问题：怎么启动多个 Agent 并且管理它们，怎么看到每个 Agent 在干嘛，等它们做完了之后要怎么处理它们的成果，怎么规划好流程。
大多数人还是喜欢一次只做一件事，但也有些人会想提前把很多事情都规划好。有的任务是顺序执行的，互相有依赖；有些任务可以并行，比如有十个 bug 想修复，就全都交给 Agent 一起搞，看看结果。
整个流程其实是：有些任务被提前规划好，有些正在执行，有些可能不是我们在做，而是 Agent 在做，但我们要负责任；等 Agent 做完了，得检查这些改动，要决定哪些部分要保留，哪些不要，还得决定怎么合并和发布。
然后我就发现，这其实就是又要重来一遍了。我已经无数次遇到这种循环，每次最后都回到一个 to do list，不管是给 Agent 还是给人，是列表视图、表格视图还是看板视图，本质都是一样。
主持人：对，我们可以打开看板视图、看下 Rebecca 的情况。
Ryo Lu：对啊，其实都是一样的。唯一的区别可能就是，这些任务现在可能是 Agent 在做。就这么简单。
主持人：你是多快想明白这个方案的？你不是说你一个月都在研究这个问题吗，能不能讲讲你在探索过程中都考虑过哪些可能？
Ryo Lu：我当时的想法是，或许可以换个思路、绕开一下，比如让每个 Chat 聊天窗口都变成一个任务，或者是一对一的关系。但后来发现，大家的用法完全不一样。
有的人会有一个很长、一直开着的大 Chat，把所有事都放进来；有的人会针对特定的修改或者代码区块开不同的 Chat。我们其实最推荐的方式，是每做一件事就新建一个 Chat。
主持人：这种方式其实很有吸引力，因为它确实可以大大简化流程。从系统思维的角度来说……
Ryo Lu：对，如果大家都这么做，每个 Chat 就是一个任务，就不需要再搞别的概念了，任务都是围绕 Chat 组织的。但现实是，有的人喜欢在一个 Chat 里做五件事，有的人只做一件。
我们还是得有机制帮 Agent 管理这些任务。再加上 Agent 有上下文窗口限制，它需要同时装下所有文件上下文和聊天历史，越往后它就越遗忘，模型一开始表现特别好，过几轮后就变笨了。
所以我们还得有个机制，记录一些高层次的事项，记录它现在在思考哪个任务，任务之间的关系，接下来要做什么。Agent 也需要这样，才能处理跨度更长、更多样的任务。
我觉得最有意思的是，这不仅仅是给 Agent 或一个 Chat 做 to do list，而是把整个软件开发过程拆成一堆任务，这些任务和 prompt、Chat 关联起来。因为这种概念非常通用，所以界面也不必搞得很复杂。
任何见过列表视图的人都能上手。这也是我们为什么把这些功能做在 IDE 之外。
我们可以直接在 cursor.com/agents 上看到 Agent 的列表视图，随便点点就能看它们在做什么。不想看代码也没关系，可以看 Chat，有按钮点一下就能合并代码，搞定。
#03 产品决策的日常节奏
主持人：我明白为什么这种方式是个有价值的底层能力，因为这能帮那些根本不想进 IDE 的人也能了解项目进展，或者哪怕只是想跟进一下。
Ryo Lu：这其实就是现实世界正在发生的事情。现在人们规划和做软件的时候，Jira 看板或者 Linear，其实本质上是一样的。
但如果把 AI 和 Agent 融合进去，协作体验就更强了。大家用的还是同一套代码库、同样的上下文，知道发生了什么、正在计划什么，Agent 能力变强，人类的效率也能提升。
主持人：我想往回倒一步，把背景再交代一下，其实我早该这么做，但我们聊得太有意思了。所以我想再多了解下设计，也就是你自己在公司是怎么工作的，你的角色具体是什么，你是怎么决定要做什么的。
能不能聊聊，比如你作为 Cursor 设计师，每周都在做些什么？
Ryo Lu：每周我都会定一些自己想做、想探索的具体问题。比如这周是让我们的定价更清晰、把后台 Agent、Web 和移动端的发布流程优化、清理一下让体验更好。
但同时我也会尽量从各个渠道收集信息，保持对整体情况的了解，知道外界怎么看 Cursor。我会自己做一些小项目，这样能深入了解整个过程，也能发现 AI 的机会点和我们遇到的问题。
然后就是动手玩、边做边学。比如我们用 Cursor 开发 Cursor，有时候会顺便用 Cursor 做个原型练练手。
有时候我只是为了好玩，做点乱七八糟的小东西，但其实我是在试探边界，看哪些事情到底能不能实现，哪些容易做，哪些不容易，现在做 Rios 的话到底怎么做更好。
我现在甚至很少加新功能，更多是优化已经做过的东西，或者重构 Agent、系统，把它们做得更好，同时也能学到新东西。
比如 o3 哪方面更强、Gemini 哪方面表现好，然后把这些经验带回公司，不断改进工具，让它越来越好，循环往复。
主持人：我很好奇你怎么判断哪些反馈值得关注、哪些可以忽略。因为现在有很多人给你提建议，比如我翻回你早期的移动端设计截图，光评论就有 772 条，太夸张了。你是怎么处理这些反馈的？
Ryo Lu：我会看所有 Twitter 上的内容、Slack 里的讨论、用户报告和各种反馈。我会尽量全都吸收进来，这感觉就像在训练一个模型，不断喂数据给它，培养自己的直觉。看得越多，优先级判断就越准确，感知力也会越来越强。
主持人：那如果我们反向推理一下，你会怎么写你自己的系统提示词（system prompt）来判断哪些反馈要采纳、哪些应该忽略？不断进化你这个系统提示词，让它能理解哪些反馈其实不该被采纳，因为它不符合你的战略方向？
Ryo Lu：我一直说，其实绝大多数的单独小决定本身都不重要，但如果你把这些小事全都加起来，其实都挺重要的。说到底，方向、概念、想法，比怎么实现这些细节要重要得多。
我会试着搞明白用户到底想要什么、为什么给我这些反馈，然后对他们给的解决方案本身我有时根本不在意，有的我也会直接忽略。因为这些细节其实对我来说都不重要，我不会花太多时间在这些事上。
我看的反馈越多，处理起来就越自然，几乎像是我自己内置了一个处理器，能自动筛选掉噪音并培养直觉。而且这个过程是动态变化的，可能这周大家说 XYZ 更好、下周又说 XYZ 不行了，总是在变。
主持人：但现在各种需求、时间线都在打架。我的经验是，经常会收到一些很合理的功能建议，可这就像老生常谈的造更快的马，我们很难判断哪些请求值得做，哪些要坚持自己的路线，因为我们其实是在追求完全不同的未来。
Ryo Lu：是的，要全部接收进来。你说得对，优先级是不断变化的，这其实更像是一种动态排序。也不仅仅是外部反馈，还有公司内部的、技术资源限制、当前和未来的矛盾，还有我们自己、工程师、设计师的视角，还有多手动还是多自动。
如果我们只盯着某一边很容易卡死自己，其实把所有东西都摆在一起，然后当下做出一个决定，之后再调整反而更容易。
#04 创作流程与未来界面的畅想
主持人：那我们聊聊你自己的工作流程吧。你一直在各种探索，看起来你有很大的自主权。你平时什么时候会用 Cursor？和你脑海里对想法的清晰度有关系吗？比如用 Cursor 还是别的工具，有什么差异？
Ryo Lu：其实只要是在做软件，而代码是主要材料的时候，至少现在，Cursor 还是最适合的地方。不管是和代码互动，还是围绕代码做其它事，都没什么限制，想干嘛都行。
随着我们的代码库越来越复杂，Cursor 的功能也能逐步覆盖各种需求，从简单的东西到复杂的大项目都能搞定。你看现在有的人用 Cursor 只是写文档，有的人做市场调研、写报告，什么都有。
其实代码就是我们做软件时最基础的东西。当然，比代码更底层的还有汇编语言或者机器码，但一般来说，代码这一层已经足够我们做绝大多数事情了
我们从这一层起步，再围绕怎么用 AI 管理代码库、解决各种软件工程难题来搭系统，让 Agent 能写更复杂的软件、能自己检查错误、越用越聪明，那往上构建更复杂的产品也会容易很多。
比如一些新手 coder 看到报错就卡住了，但如果 Agent 能帮他自动修复，这种阻碍就不存在了。或者给他们一个更适合的界面，不一定要传统的侧边栏/文件/编辑器/聊天视图，可以是任何形式。
主持人：明白，那我想再往前倒一倒，聊聊你探索 to do list 作为 Agent 底层能力之前，你都在用什么方式思考、记录这些想法？你会在文档里写，还是用 Cursor 搭界面，还是其它什么方式？
Ryo Lu：用什么都行，看问题需要哪种深度。有时候我会在办公室溜达的时候，用 Notion 把想到的东西随手写成清单或者用点列出来。那些想法可能很概念化。
回去后，如果遇到视觉相关问题，就需要在 2D 空间里动手、精确摆像素、快速切换不同布局什么的，因为现在的工具还不能很方便地用代码或者 AI 快速做出原型，所以我还是会用 Figma。
这方面 Figma 做原型其实挺难的，但如果要真做出来、感受实际效果，我就直接用 Cursor 把它实现出来，体验一下。
比如我们今天或明天要上线的 Stop 和 Queue 交互，就是我先用 Cursor 做个原型，给大家看了看，大家觉得不错就做成了真功能。
多 Agent 相关的功能也是一样，先做原型，因为做这类 AI 交互的时候，输入、输出、上下文、响应，这些都很重要，完全靠假想画图是不行的。
主持人：你刚才用了感受这个词。的确，Stop 和 Queue 交互最关键的就是手感，我还在评论区和别人吵过这事。
有人不理解为啥要写代码，我就说如果你做的是需要持续 AI 输出、哪怕有点像聊天的产品，光在 Figma 里是根本没法做出真正效果的。
Ryo Lu： 没错。我觉得界面以后一定会越来越动态化，几乎每个人理想的界面都会不一样。
主持人：那我们就来聊聊这个吧。你发过一条我很喜欢的推文，讲的是未来 AI 游戏的流动性。分享下你这方面的想法，咱们从这出发聊聊。
Ryo Lu：对，现在根本没法只靠静态原型图去设计产品了。静态图只是某个状态、某个理想状态，让每个人都能理解，这根本不现实。
我们做设计师可能会想简化一切，把一切都做到最通用、大家都能看懂，结果反而把产品做平庸了，原本的神奇体验也没了。
有时候如果你强行让所有用户都去适应同一种布局、同一种模式、同一个系统，结果反而会不符合实际需求，让用户体验变得更糟。
就像 macOS 之前从 Liquid Glass 换成现在扁平风，结果大家都被迫适应新模式，但其实未必适合，比如鼠标、触控、视觉焦点其实都不一样。
界面之所以不同是有原因的，比如 iPhone 的按钮都高度是 44 像素，Mac 上也许才 28。每个人想事情的方式、表达方式、喜欢和外界互动的方式、做事方式其实都不一样。
我和很多工程师一起工作，他们都很不一样。有的完全沉浸在 Agent 世界里，有的还喜欢手动写代码，有的纯键盘党，有的用 Emacs，还有人就只爱点鼠标。
就像我昨天在 Twitter 上还看到个推，说 Bun 项目的一个顶级极客 Jared 认为 GitHub Desktop 才是最佳工具，这就很说明问题。
主持人：哇，作为工程师公开这么说也太大胆了吧。
Ryo Lu：对，太疯狂了。
主持人：我一下感觉自己安心多了。
Ryo Lu：对啊，所以我其实不想把我的偏好强加给别人，我想让所有人都觉得这个产品适合他们。理想情况下我们可能要砍掉一部分内容，但更理想的状态是，大多数人一进来就能觉得这个产品是为他们而做的。
但要做到这一点，界面就必须变化，必须让大家可以用各种各样的方式来用它，所以我们得设计一个底层架构，可以兼容这些不同的配置和定制。我们要考虑到底要给不同的人哪些选择，不同人进来时应该默认是什么样的。
#05 多样性与个性化
主持人：我记不得是什么时候了，但你之前聊过，产品要跨越不同规模阶段，必须经历些什么。一旦产品做到所有人都必须用的程度，就会丢掉一点灵魂。
所以在你看来，个性化就是破解这个问题的方法？是不是现在的 AI 模型能帮我们让产品在覆盖十亿用户的同时，依然有灵魂和工匠精神？
想实现这个目标，需要发生什么？作为推动产品方向的人，你觉得现在离目标还有多远？设计师在以个性化为终极目标时，要怎么跨越这个鸿沟？
Ryo Lu：我们其实还完全没开始做这件事。就像我说的，现在打开 Cursor 只看到三个按钮。我们设计师现在做的事情，其实都是把设计往更高一层抽象。
不是在具体设计这个 UI 每个按钮的排列和位置，而是在设计一个容器。这些容器其实是整个系统的模式，然后它们可以相互转化。
比如在 Cursor 里，我选中文本、按 command+K，会弹出个小输入框，旁边有个 Chat 聊天窗口，这个 Chat 也可以变成完整的编辑器，变成一个独立窗口。
类似的东西，可能还会出现在网站的后台 Agent 或移动端。其实它们本质上是一样的，只是根据我们用的场景，会有不同形态。关键是，整个系统有哪些最本质的模式和想法，还有这些模式可以组合成哪些配置。
主持人：那你作为这个未来 Cursor 的设计师，会不会提前列出所有这些最基础的功能模块，然后让它们以后可以随意组合，去适应各种不同的用户和需求？
等个性化做到底，是不是其实就是排列组合问题？还是你觉得动态生成界面、AI 实时出新 UI，也会成为一个重要因素？
Ryo Lu：是有可能，但我觉得如果 UI 是完全随机生成的，连工具的创造者自己都无法掌控或者预测，那其实只会带来更多混乱。
但比如说，我打开 Cursor，不再只看到那三个按钮，而是根据对我的项目类型、偏好的了解，AI 自动把整个 Cursor 为我重新配置。
也许整个界面倒过来了，也许我看到的是一个画布，可以直接画东西，然后 AI 把我的想法直接变成可用的组件。或者我是个纯代码党，进来只看到命令行窗口，那也没问题。
本质上我还是在用 Cursor，只是用的是不同的形态，它底层真正核心的功能其实并不多。尤其是给 AI 用的话，如果抽象层次搞得太多，反而很麻烦，因为很多抽象其实不适用。只有那些永远不会变的东西才值得抽象出来。
主持人：这个思路很好。你有 Notion 的背景真是太适合做这个了。你怎么看未来的数字工具？AI 会在每个人用的形态里发挥多大作用？
而且现在，AI 模型能从每个用户那里获取的背景信息会比以前多很多。为每个用户动态地组合出最适合他的功能模块，可能比以往任何时候都更关键，你说对吗？
Ryo Lu：对，不过其实我们日常用的交互形态这些年变化也没那么大，人们处理信息的方式可以是视觉化的、列表式的、卡片式的、表格式的，什么都行，关键在于你是谁、你在干什么。
#06 新一代创作者的工作方式
主持人：我不能在结束谈话前不给你机会聊聊 Rios（Ryo Lu 开发的一个小型操作系统项目），大家在 Twitter 上都超喜欢它。我自己在这次播客前也玩了好一阵，玩各种聊天、iPod 功能。
你说过做自己的操作系统是种 dogfood（自用测试），但肯定还有更深的动机吧？你为啥凌晨三点还要做自己的小 Slack？
Ryo Lu：其实这事完全是个意外。一开始我做的第一个 App 是个 Soundboard 应用。你打开会发现里面有我自己提前录的几段声音。
主持人：那是你自己录的？就是你在里面乱叫？
Ryo Lu：对，就是我自己发的声音。因为我要离开 Notion 了，想让团队还能听到我的声音。
这个项目最早是个用 React 做的，很通用的 App 框架，最初界面特别丑，我就让 Agent 给它加点怀旧元素，然后它随便从 Google 拉了个像素字体，还是很丑，但你大致能看出这玩意能干嘛。
然后我说把它放到窗口里，它就随便放到了一个很糟糕的窗口界面。接着我说做个菜单栏，它就真的做了个菜单栏，然后我突然想：为什么这个操作系统只有一个 App？它看着像 OS，却只有一个应用。
于是我又做了第二个 App，Internet Explorer，实际上就是个浏览器。有个输入框，就是小窗口，我也叫它 App。做到这里，我几乎就是让 Agent 重新帮我设计了整个操作系统的架构。
比如：怎么管理多个应用，怎么管理多个窗口，前台/后台切换，哪个窗口激活、哪个没激活，拖动、缩放窗口，怎么统一管理所有 App 的状态，怎么把状态存到 localStorage 里，这样你关掉网站再打开，所有状态都能保留。
接着我又加了个文本编辑器，因为我之前在做 Notion，所以我也加了/命令。然后我又想到，要是 Chat 能直接写到编辑器里会怎么样？其实根本没规划，纯靠感觉乱搞。
主持人：你觉得你之所以能做这些，是因为你行动特别快吗？我刚才在 Twitter 上发了条内容，下面评论很多人在问你的灵感来源。
Ryo Lu：你说得对。
主持人：其实很多听众未必比你差在哪里，区别可能是你从有想法到动手产出之间的时间特别短，然后事情就顺其自然发展下去了。
Ryo Lu：对，这也是我加入 Cursor 的原因之一，就是想让从想法到变成现实这条路越来越短。在 Cursor，我真的能做到这一点。现在我能做的事情，比过去任何人都要多得多。
即使作为工程师，大部分 Rios 的代码都是我自己写的，可能花了一个多月，现在已经有十三万多行代码了。
我还问过 GPT，一个普通工程团队做这个得多久，它说要好几个月甚至几年，几十个人才能搞定，但我一个人在旁边随便 Vibe Coding，想到啥就做啥，就能搞出这么多东西。
主持人：我们现在在为 Inflight 招人，今天下午还和一位工程师聊这个话题，讨论未来一年核心团队的策略。Cursor 真的是彻底改变了我们招人的思路。
因为我们有两个设计师，就等于有两个前端工程师了。我们甚至不需要招那些特别懂前端的人，因为我自己就可以把任何功能做完，这感觉太棒了。
Ryo Lu：我觉得未来会有越来越多人体验到这种变化。过去十年里那种极度细分的分工，现在基本已经没意义了。
因为只要我们懂得怎么和 AI 协作，大家其实又站回同一起跑线了。我看到很多 17 岁的年轻人用 AI Vibe Coding，做出来的东西比大厂的工程师们还要牛。
他们现在都在用 AI 尝试新东西，不断探索，知道这些工具是什么、怎么用。而且现在工具也越来越快，所以他们进步很快。如果你还在想我们是不是得每周开计划会、站会、坐在办公室吃午饭、啥都不做，那祝你好运。
#07 团队协作新范式
主持人：我们刚刚聊到 Cursor 在创意和实验阶段扮演的角色，你能不能讲讲你和 Cursor 的工程师是怎么协作的？你平时会参与实际代码开发吗？具体怎么分工，这一块流程是怎样的？
Ryo Lu：举个例子，其实不是我自己。我们有个设计师叫 Ricky，他也是从 Notion 来的。他很擅长设计系统，喜欢在 Figma 里做各种组件、颜色 Token、样式、嵌套组件、各种不同状态。
他来了以后也是先用老习惯，想着把一切都理顺，做出视觉完美的原型。我觉得这当然也重要，但这种事其实只需要做一次。他把所有设置页面和后台都在 Figma 里重新做了一遍，大概花了两周。
我就问他：你在干嘛？为啥不直接 Vibe Coding 试试？
主持人：那工程师们怎么看？他们喜欢你们这种方式吗？
Ryo Lu：很喜欢。他们现在把我们也当自己人了。我其实最早就是啥都不管，自己把东西做出来，脑子里有想法就直接设计、编码，然后顺便就成了设计师。
我觉得设计师画图，工程师实现这种分工很不合理。明明是同一个问题，同一个拼图，只不过大家关注的抽象层级不同。如果我们强行切分，最后产品也会变得奇怪。其实 Cursor 在我来之前没有专职设计师，大家都是为自己而做。
每个人都为自己做设计，这也挺好，这就是 Cursor 为什么能做成最适合程序员的 AI 工具。我们团队很强，我们现在几乎是在打造一套最强的 AI 工作流，还把所有需要手动操作的环节都融合进去了。
但那只是起点。我们想服务更多人，就必须让系统支持更多工作方式、更多可视化、更多抽象层。
主持人： 你说的很对，这其实也说明了设计师的价值。大家为自己做没问题，但设计师能把复杂问题梳理清楚，让产品变得能服务更多人。
Ryo Lu：完全同意。我们有很多很棒的工程师，但有时候他们也会有些迷糊，能把最难的东西做出来，却忘了修好入口、理顺流程。
比如应该做一个统一的系统而不是五个分散的小系统。设计师或软件架构师，其实就是在设计边界、设计概念怎么组合，而不是一层层往下拆分。
以前那套做法，先定战略，写一堆文档，产品经理再写需求拆任务，然后工程师做，最后像打流水线一样实现，这些流程其实已经不再适用。
我们现在都是创作者，有想法就一起做。有人偏视觉，有人偏数据结构，有人懂机器学习，有人不懂，但大家拼成一张完整的拼图。谁写代码、什么头衔已经没那么重要了。
#08 设计师的价值与人机交互的畅想
主持人：刚刚聊了系统思维。那在人人都能写代码贡献想法的世界里，你觉得设计师真正的长期价值还有哪些？
Ryo Lu：我觉得最高层次其实是，怎么理解这个世界，怎么看手头的东西和概念。
每个人都不一样，有的人极度擅长细节，没那么擅长整体把控；有的人战略上特别厉害，动手能力一般；还有人很会写底层代码，但 UI 设计就会随便乱加按钮，让用户懵圈。
但最终我们的目标，是把这些人的优势都汇集起来，做出优雅好用的软件。过去大家只能用很老套的办法沟通协作，角色分工太强其实反而增加障碍。
每种角色、专业其实都有自己的思维方式，比如我们设计师聊视觉、排版、间距、色彩，工程师聊后端，但最终还是要让后端信息以像素形式展现出来。
未来也许有脑机接口，但怎么思考问题、怎么拆解重组，把 AI 和人协作结合起来，这些本质没变。有的人觉得做一个专用、极致单一的产品很棒，但我的想法不一样。每个人有偏好、有做事方式，这种多样性才有价值。
主持人：你对 HCI（人机交互）未来有什么疯狂但依然坚信的观点？
Ryo Lu：界面会变得更接近人的思维，甚至不再通过外部设备操作。比如我是个视觉型思考者，未来也许可以不用看电脑或手机屏幕，自己的想法和视觉内容就能直接在大脑里呈现出来。
主持人：那真是太超现实了。
Ryo Lu：你看过新的 Neuralink 演示吗？
主持人：看过。
Ryo Lu：他们已经能用上千个电极直接在我们的视野里画东西了，真的很疯狂。
主持人：到那时候，设计师的定义都要变了，什么才算设计师？
Ryo Lu：对，到那时，还是会有人负责提出概念、命名一切。
主持人：甚至语言本身的意义也变了，对吧？
Ryo Lu：对，这其实就是我现在工作很重要的一部分，把概念和想法梳理清楚，提炼成最基础、不会变的表达。
