跨国深谈← 返回←Figma 工程师谈：怎么让智能体进团队还不毁掉代码质量

Figma 工程师谈：怎么让智能体进团队还不毁掉代码质量

关联

人物 Eyal Blum

公司 Figma

概念 智能体 · 验证 · 规划（而非提示） · TDD · 测试金字塔

这一集是 Figma 软件工程师 Eyal Blum 的演讲，讲 Figma 内部的工程组织怎么把 AI 智能体(能自主读代码、写代码、跑测试的 AI 程序员)接进工作流，同时保住代码库的质量。他不是来吹产品的，是来讲内部组织怎么消化这场变化的。

钩子先给一个：适应 AI 最慢的，往往是最优秀的工程师。因为他们习惯把全部上下文装在脑子里，知道所有的坑在哪里，用「精神胶带」把智能体运转不佳的地方粘合在一起，挡住所有真正糟糕的东西。结果他们负担最重、成为瓶颈、最沮丧，也第一手看到所有问题，所以反而成了适应最慢的人。

三幕式：AI 采用的真实曲线

Figma 观察到，无论公司还是个人，AI 采用都走三幕：第一幕，上手某个工具，简单的事快了 10 倍，兴奋；第二幕，把同样做法套到大问题上，AI 败得很惨，一堆 bug,信任崩塌；第三幕，才开始构建真正的技能——正确的护栏、提示词、上下文。麻烦在于组织内部进度不均：有的团队已彻底转型，有的还在实验或已经失去信心，而他们必须一起交付同一个产品。怎么让所有人都走到第三幕，是这一集的主线。

最大的杠杆：投资验证

在代码库里能做的价值最高的事，就是投资于验证。每当能把一件原本要人做的事，变成智能体可以自动验证的事，都是大赢。比如 Playwright MCP(让智能体直接操作浏览器界面的工具)出来后，不再需要人去逐步走查，智能体可以自己探索验证，对很多团队是巨大的生产力解锁。

更进一步：发现某个智能体验证方式有效后，花时间把它固化成确定性流程——能编码成测试的就变成测试。这样只在需要推理的地方用 LLM,省 token、省时间，回报总是正的。

还有一个具体技巧：让智能体按 TDD(先写测试、再写代码让它通过的「红到绿」开发法)写代码——先定目标，再让它朝目标写，几乎总是比先写代码再补测试效果好，否则它会反过来让测试迁就代码，而不是让代码满足验证标准。

整个质量体系像经典的测试金字塔一样分层：尽可能把检查下移到确定性分析——lint、编译器、单元测试；能按标准覆盖的交给智能体审查；已编码进代码库的架构标准也移给智能体；只有最顶层的功能性判断才留给人。只让人做人才需要做的事。

规划替代提示：把「写代码的乐趣」换个形式还回来

针对前面提到的满意度问题——很多人过去靠写代码进入心流获得乐趣，现在沦为「等 AI 输出、再跟 AI 对话」的提示词循环——Figma 的解法是：规划(planning)而非提示(prompting)。花大量时间写一份非常详细的计划，把所有决策打磨清楚、迭代、发队友评审，然后才交给智能体当作「可自动完成的实现」执行，做完交回来。花一周写计划很常见，但这一周把构建的决策乐趣重新带回了过程，同时还在加速。

一份好计划长这样：

• 开头放「为什么」：像设计文档的执行摘要，写一段醒目的目标章节，防止智能体随时间漂移(悄悄偏离方向)，并明确禁止它回头改这一节——不许它「自己觉得想改」就改。
• 拆成可独立验证的小块：作者自己的尺寸标准是——我愿不愿意一口气审查对应的 PR?如果「得先来杯咖啡才能读」，就是太大，要拆。每一块都要有验证关卡，否则会出现五个阶段里第一个写好了但没验证、后面全部建立在未验证假设之上的局面。
• 计划定了之后，用什么循环、什么工作流去实现随意。他发现 AI 工作流的好处就是每个人都能搭最适合自己的，强行把所有人统一到一套工具上是收益递减的。

效果：一份花一周写的计划、一周跨团队对齐，交给智能体过夜实现回来，产出的 PR 都在 10 到 100 行之间，一份计划约 20 个 PR,合计约六周的编码工作量，实际只花一周——5 倍提速(还得记得算上最后的审查周期)。

把最强的怀疑者变成路线图负责人

回到那些最优秀也最怀疑的工程师：别琢磨怎么「让他们用 AI」,而是让他们负责「让 AI 在组织里变得安全」的路线图。他们持怀疑态度，恰恰是因为他们精确知道验证缺失在哪、工具在哪失效——他们的反馈就是改进智能体与代码库交互的路线图。

一旦看到自己推动的改进真的让自己的生活变好，他们自然跟上来。而且他们提意见毫不客气：和一群人坐不到一小时的头脑风暴，就能列出一整页要修的东西。

注意力是稀缺资源：标注哪些是 AI 写的

AI 时代人类注意力成为稀缺资源，设计文档、Slack 消息、邮件都变长了三四倍、数量翻了两三倍，内容量和以前差不多——沟通质量的可辨识度崩了。Figma 的做法是「注意力感知沟通」：标注哪些内容是人写的、哪些是 AI 生成的。他们团队规定，每个 PR 描述必须以一段手写说明开头(可以很短)，AI 生成的描述放在后面——读者就知道该更认真读顶部、以它为准，对后面的部分多一分怀疑。

背后还有个真实教训：他早些时候给几位资深 AI 怀疑者发了一份用 AI 做的 PR 评论分析，没有区分哪些是他写的、哪些是 AI 生成的，对方非常生气——「我没想到我这么尊重的人会给我发这么粗糙敷衍的东西」。道歉之后他学到：清楚标注「这是我写的，这是 AI 写的，我需要你的反馈」，这种文化上的改变和工程挑战同样重要。

从人所站的地方开始

推广上最有效的一条朴素经验：让人们在各自当前的位置直接用上 AI,把日常任务中的 AI 使用正常化。最有穿透力的一招是在 Slack 里@一个智能体，当着同事的面说「你能替我做一下这个吗」，让它在帖子里闭环。对还没认同的人，可以不带攻击性地@它说「试试看这次智能体能不能搞定」——一次好的现场体验，会让人回去自己尝试。

现在与边界

旅程远未结束。尽管 Figma 在对外交付 AI 产品，内部自动化还没有完全到位，构建系统依赖复杂，怎么有效用好编程智能体仍在摸索。他收尾说：在硅谷工作 15 年，这是他在文化和技术上所见过的、按数量级算最大的变化——大家都在一起摸索。

【背景】演讲末尾提到的 “Cloud Agent” 按上下文应指 Anthropic 的 Claude 编程智能体(Claude Code 类产品)，系语音转写所致的写法差异。

本集带走

• 验证下移：能变成 lint、编译器、单元测试的检查就别留给人和智能体反复推理；智能体验证有效的方式，固化成确定性流程。
• 让智能体先看目标再写码：TDD 式「红到绿」——先定验证标准再让它写实现，几乎总比写完码再补测试好。
• 用一周写计划、一小时审查:计划开头放「为什么」，拆成每块可独立验证的小 PR(一杯咖啡能读完的尺寸)，每阶段设验证关卡防漂移，然后整包丢给智能体执行。
• 把最强怀疑者变成路线图主人：他们知道工具在哪失效；让他们负责让 AI 变安全，他们看到改进生效自然会跟上。
• 标注人写与 AI 生成:PR 描述、Slack、邮件里，手写部分放最前、以它为准——注意力稀缺时，告诉读者该认真读哪里。
• 在日常场景里推广:Slack 里当场@智能体闭环一次好体验，比任何培训都更能让观望者上手。

所以他们实际上最终成为适应最慢的人，因为他们第一手看到了所有的问题。
So they actually end up being slowest to adapt because they see all the problem firsthand.
—— Eyal Blum · [03:58]

我想这里的很多演讲者都提到过这一点，但投资于验证可能是我们在代码库中能做的价值最高的事情。
I think a lot of the speakers here have touched upon this, but investing in verification is probably the highest value thing we can do in our code base.
—— Eyal Blum · [05:00]

如果你告诉你的技能或智能体按「红到绿」的 TDD 风格去写你正在写的代码，它几乎总能给你更好的结果。
If you tell your skills or your agent to write the code that you’re writing, like at the red to green, at the TDD style, it almost always gives you better results
—— Eyal Blum · [06:13]

因为那样的话，它会让测试去迁就代码，而不是让代码去满足验证标准。
because then it will fit the test to the code rather than fit the code to pass the verification criteria.
—— Eyal Blum · [06:34]

然后只有在最顶层才需要某种人工审查，通常围绕功能性——这才是正确的构建方式：只让人去做人真正需要参与的事。
And then only at the very top you need to have some sort of human review which is usually around the functionality and this is the right thing to build that only leave the human to do what the humans need to actually be involved in.
—— Eyal Blum · [07:20]

把执行摘要放进去给智能体。否则它们会随时间开始漂移，而且要确保智能体不会只因为自己想改，就回头去修改那个部分。
Put that in there for the agent. Otherwise, they’ll start drifting over time and make sure that the agent don’t go back and change that because they feel like it.
—— Eyal Blum · [08:51]

我愿不愿意审查与那一部分对应的 PR?如果它大到我不愿意一口气审完——就像这么个检验标准：读它之前我得先来杯咖啡——那就说明它太大了。
would I want to review the PR that will correspond to that part? If it’s going to be too big for me to want to review in one sitting, if kind of like the test is, I’m going to need to get a cup of coffee before I read this. That means it’s too big
—— Eyal Blum · [09:12]

他们之所以持怀疑态度，是因为他们看到了你在验证上缺失的地方、工具失效的地方——所以他们的反馈基本上就是如何改进智能体与代码库交互的路线图。
They’re spec haptic because they’re seeing where you’re lacking validation, where your tools fail, so their feedback is basically the roadmap of how to improve your agent interacting with the code base.
—— Eyal Blum · [11:59]

我在硅谷工作了过去 15 年，这是我在文化和技术方面所见过的、按数量级而言最大的变化。
I’ve been working in the Valley for the last 15 years, and this is the biggest change by orders of magnitude of everything that I’ve seen in terms of culture and technology.
—— Eyal Blum · [17:08]