스크립트
00:00:00Eyal Blam：大家下午好，我叫埃亚尔·布拉姆（Eyal Blam），是 Figma 的一名软件工程师，
00:00:17在今天的演讲中，我们将探讨如何在保持代码库高品质的同时，
00:00:25将 AI 智能体适配或正在适配到 Figma 的工作流程中。
00:00:32大家可能知道，Figma 是一个基于浏览器的编辑器，设计、工程以及现在的
00:00:40AI 智能体在这里协同合作，共同交付代码。
00:00:44Figma 已经从传统工具转型为坚定的 AI 优先工具，
00:00:52但在今天的演讲中，我不会过多讨论我们的产品，而是更多地谈谈我们的
00:00:55内部组织，以及工程团队是如何适应 AI 智能体的。
00:01:04我们内部发现，无论是组织、公司还是个人，在 AI 采纳过程中
00:01:11都经历着一种“三幕式”的历程。
00:01:16你从上手某样东西开始，在座的许多人可能也一样，
00:01:21他们对 AI 非常狂热，使用 AI 已经有一段时间了，他们上手某个工具，
00:01:27把一些简单的事情做得非常好，效率提升了 10 倍。
00:01:30然后，当你开始将这些相同的做法应用到更大的问题时，AI 的表现就会变得相当糟糕，给出低质量的结果，
00:01:40带来大量漏洞。
00:01:41你原本建立的信任随之崩塌，而从那个点开始，你才真正开始培养真正的技能，那就是
00:01:50学习如何正确使用 AI，设置正确的护栏、正确的提示词、正确的
00:01:55上下文，以及我们今天整天在各个演讲中讨论的所有内容，从而真正掌握这项技能。
00:02:02而在内部发生的一个现象是，无论是团队还是个人，这种采纳的进度都是不均衡的。
00:02:12我们有些团队对 AI 非常积极，已经彻底转型了整个工作流程；但也有一些团队仍处于早期的探索阶段，或者失去了信心，而他们必须协同工作才能交付我们的产品。
00:02:28因此，他们需要在组织中共存，我们需要找到一种方法来支持他们，同时带领所有人共同踏上这段旅程，让每个人都进入故事的第三幕。
00:02:44除了这个主要的摩擦点之外，我们在采纳 AI 的过程中还注意到其他一些摩擦点。
00:02:54我们从开发者那里听到很多、且管理者也注意到的一点是，开发者自主性的降低导致工程师失去了部分工作满意度。
00:03:04过去，许多人从编写代码和进入心流状态中获得极大的自豪感和乐趣，而许多人觉得这种体验已经丢失了，或者正在失去很大一部分，转而陷入了一种提示词循环，他们只是等待 AI 的输出，然后与 AI 对话，这远不如过去那么有趣。
00:03:22我们注意到的另一个有趣现象是，我们最优秀的工程师实际上想要将所有上下文都装在脑子里，结果却背上了沉重的负担。最终发生的情况是，他们知道所有陷阱在哪里，他们用精神上的“胶带”把所有 AI 运行不佳的地方勉强粘合在一起，阻止所有真正糟糕的东西进入，或者他们掌握了所有从未
00:03:52被写下来、只存在于他们脑海中的机构上下文。他们承担了如此沉重的负担，成为了瓶颈，感到非常沮丧，因此他们反而成了最慢采纳 AI 的人，因为他们亲眼看到了所有问题。
00:04:04这是我们看到的另一个大问题，我确信在座的所有人都会深有同感：突然之间，所有的设计文档、Slack 消息和电子邮件都变成了原来的三到四倍长，邮件数量也变成了原来的两三倍，但它们表达的信息其实和以前差不多。
00:04:28因此，沟通变得相当低效，而且要分辨什么是高质量、重要的东西，什么是不那么高质量的东西，也变得充满挑战。
00:04:40所以我打算花接下来的几分钟时间，谈谈我们学到的一些经验教训以及我们是如何尝试应用它们的。
00:04:50这是一段旅程，我们还没有走到终点，但在许多方面我们已经看到了非常有趣的进展。
00:04:57我认为这里的许多演讲者都提到过这一点：投资于验证可能是我们在代码库中能做的价值最高的事情。
00:05:11任何时候，我们都可以将工作流程中的某些环节左移，从需要人类去做变成由智能体来进行验证。
00:05:19例如，当 Playwright MCP 发布时，智能体可以直接探索代码，而不需要人类去浏览代码，这对我们许多团队的生产力来说是一个巨大的突破。
00:05:33这对我们来说始终是一个巨大的胜利。
00:05:37更好的是，当你发现智能体觉得有用的东西时，花点时间把它提取并编码成一个确定的流程。
00:05:51一个可以轻松重复的确定性流程，既能节省 Token 又能节省时间，同时也确保你只在 LLM 需要进行推理时才使用它。
00:06:01但是，当你有一些已知的东西、基本上可以编码到测试中时，花时间去做总是能带来丰厚的回报。
00:06:11另一个小贴士是，如果你告诉你的技能或智能体去编写你正在编写的代码，并采用从红到绿的 TDD（测试驱动开发）风格，它几乎总是能给你带来更好的结果。
00:06:26因为你设定了一个目标，然后告诉智能体朝着这个目标努力。
00:06:30这在编写代码以及随后编写测试时，几乎总是能给你带来更好的结果，因为这样它会根据代码来调整测试，而不是为了通过验证标准而去拼凑代码。
00:06:42这就是测试金字塔，来自前文的经典测试金字塔，当你思考测试本身时，你有端到端测试、集成测试以及单元测试。
00:06:54这是一个非常类似的转变：尽可能多地将工作下移到确定性分析中，比如静态检查（linting）、编译器以及单元测试本身，任何可以轻松覆盖的内容，你都可以让智能体根据标准进行审查。
00:07:12以及已经制定的架构标准。
00:07:15以及那些可以轻松编码到代码库中的架构标准，你可以将其移交给智能体。
00:07:19然后只有在最顶层，你才需要某种人工审核，通常围绕着功能性以及“这是否是正确构建的东西”，只把人类留给真正需要人类参与的事情。
00:07:31另一个非常重要的事情是规划与提示词的区别，这与将自主权交还给开发者、寻找编写代码这门手艺的替代品息息相关。
00:07:50因此，花大量时间编写计划，然后将其发送给智能体作为可以自动完成的实现方案，我们发现这确实能将构建的乐趣重新带回流程中。
00:08:07所以，花上一周时间编写非常详细的计划、做出所有决策、将细节敲定、反复迭代并发送给队友审阅，这并不是什么罕见的事。
00:08:17然后，只有当计划准备就绪、所有决策都已敲定后，你才将其发送给智能体，智能体在实现后会把它交回给你。
00:08:26这种方式在加速开发以及恢复开发过程中的一些乐趣方面取得了巨大成功。
00:08:36那么，是什么构成了一个好计划呢？在顶部从“为什么（Why）”开始非常重要。
00:08:43如果你有一个像编写设计文档时那样醒目的大段落，它真的非常有助于防止智能体偏离方向。
00:08:49你希望为智能体提供执行摘要，否则它们随着时间的推移会开始跑偏，并且要确保智能体不会因为自己觉得想这么做就回过头去擅自修改它。
00:08:58因此，我们从“为什么”开始，确保计划可以被拆解为各个小部分，并且每个部分都可以独立验证。
00:09:08我个人判断什么样的大小才算合适的方法是：我会思考对应那部分的 PR（拉取请求）是否会大到让我不想在一次坐下来看完。
00:09:18这有点像这样的测试：我在阅读之前需要先去喝杯咖啡。
00:09:22这意味着它太大了，我需要把它拆成碎片。
00:09:26然后我确保每个部分都可以独立验证，因为我最不愿看到的是：有五个阶段，结果第一阶段写完了但没有经过验证，然后后面的所有内容都建立在未经验证的假设之上。
00:09:41因此，为每个阶段设置验证关卡或异常标准，真的有助于让计划具备抗漂移能力。
00:09:51此外，还有各种关于如何管理上下文以及在此之上构建软件工厂的技术方法。
00:09:58但一旦你有了计划，你就可以使用任何你想要的循环或工作流程来将其实现。
00:10:05这是我随手截取的一个计划截图，但这就是我通常寻找的东西。
00:10:12顶部是执行摘要。
00:10:14将阶段拆分，然后对每一个阶段深入探讨细节，以便我可以将其直接塞给子智能体。
00:10:20这样子智能体就可以独立地对其进行工作，而不必为此操心。
00:10:24当然还有其他行之有效的工作流程或计划结构。
00:10:29我发现 AI 工作流的伟大之处在于，每个人都可以建立最适合自己的方案。
00:10:41不用了，谢谢。
00:10:43每个人都可以非常轻松地建立完全适合自己的工作流程。
00:10:47因此，试图把所有人的东西都集中到同一个模式上是收效甚微的。
00:10:51但只要它适合他们的流程，并且其他人能够与他们进行迭代，我发现这通常效果非常好。
00:10:58这只是一个例子，用来“炫耀”一下由计划产出的成果。
00:11:04这里大概有 20 个 PR。
00:11:07其中一些可能是 10 行代码，另一些可能是 100 行，但大概没有比这更大的了。
00:11:12这让我们能够——在 AI 出现之前的世界里，这个计划我可能需要花上一周时间来做。
00:11:19我还要花另外一周时间跟其他三个团队就此进行对齐，然后我才会把它交个智能体在夜间实现。
00:11:26它返回了结果——这可能是两个计划的成果，而不是一个——但它基本上把相当于 6 周的编码工作直接——只花了一周时间就完成了。
00:11:36这就是我所说的 5 倍提速的由来。
00:11:40当然，别忘了你总是需要把最后的审查周期计算在内。
00:11:45从规划继续往前，回到我们之前遇到的关于怀疑论者以及那些承担最多工作的人的问题。
00:11:53确保把他们拉进来，并非常认真地对待他们的反馈。
00:11:59他们之所以持怀疑态度，是因为他们看到了你们缺乏验证的地方，看到了你们的工具失效的地方。
00:12:05因此，他们的反馈基本上就是如何改进智能体以及如何与代码库交互路线图。
00:12:12只要确保把他们纳进来，而不是绞尽脑汁去想怎么强迫他们使用 AI。
00:12:19让他们来负责让 AI 在你们组织中变得安全的路线图。
00:12:25一旦他们看到自己做出的改进确实让生活变得更美好了，他们就会欣然加入。
00:12:33正如你所见，他们在告诉你需要修复什么时也绝不会含糊。
00:12:37这是跟一群人坐在一起不到一个小时的时间。
00:12:40这就是头脑风暴的结果。
00:12:45对我的团队特别有帮助、并且我们正努力在更广泛的组织中采纳的另一件事是，
00:12:53确保实现“注意力感知型沟通”。
00:12:58在 AI 时代，人类的注意力是一种稀缺资源。
00:13:01我想我在多场演讲中都听到过这个观点，许多人都得出了相同的结论。
00:13:06你无法凭空变出更多人类的注意力。
00:13:08所以你把时间花在哪里、在读什么就变得非常重要.
00:13:13因此，既然这是如此稀缺的资源，明确区分哪些是由人工智能生成、哪些是由人工编写的，将非常有有助于了解你需要花多少时间来阅读,
00:13:24以及在这部分沟通中你可以期待看到多少含金量.
00:13:31这有点像是围绕这种沟通风格建立一种新的文化.
00:13:35这真的很有帮助.
00:13:36比方说，和我一起工作的团队，我们决定——每一个PR说明都会以类似这样的内容开头.
00:13:45我亲手写的内容可以用非常简短的篇幅来描述这是在做什么，然后AI生成的描述会在那之后出现.
00:13:54这只是——我可能会去读它.
00:13:55我可能会编辑它以删除一些错误的内容，但这里并非每一行都是他们写的.
00:14:00所以他们应该保持更多戒心，更关注我在顶部写的内容，并且应该覆盖它.
00:14:05诸如此类的事情，在Slack中、在电子邮件中，顺应每个人都知道你在用AI来撰写沟通内容这一事实,
00:14:15但大方地告诉他们什么该读、什么可以少花点注意力就行了.
00:14:21我还记得早期的时候，大概是今年早些时候，我试图——我们组织里有一些资深工程师，他们基本上是非常坚定的AI怀疑论者,
00:14:35我试图联系他们，看看问题出在哪里，发生了什么，我说我试着对你写过的一些PR评论运行一次分析,
00:14:42很显然我用AI来做这件事.
00:14:45然后我没有非常清楚地区分哪些是我写的，哪些是AI生成的，他们变得非常生气.
00:14:54他们说，你为什么要发——我没有料到我如此尊重的人会给我发一些明显这么粗制滥造的东西.
00:15:02然后，我就——向他们道了歉.
00:15:05我意识到我应该明确标注出来并表明我的意图.
00:15:08比如，这是我写的.
00:15:10这是AI写的，我需要你对此给出反馈，因为我没有上下文来判断它是否粗糙.
00:15:15而这正是我向你求助的原因.
00:15:17所以，这样的经验教训以及改变文化，和我们所面临的一些工程挑战同样重要.
00:15:28关于普及的另一件非常有用事情是，随着你不断推进应用，我们已经实施了许多非常华丽的工具和非常高级的工作流程.
00:15:41但真正有效的方法之一，其实是让人们在他们习惯的地方使用AI.
00:15:47因此，这确实有助于将日常任务中使用AI的行为常态化，并有助于减少阻力.
00:15:54真的，最强大的功能之一就是能够在Slack消息中和某人一起标记一个智能体，然后说，你能帮我做这个吗？
00:16:02并让智能体在线程中闭环处理？
00:16:07这种事情真的非常强大.
00:16:09在此基础之上，你还可以实现这一切的自动化，并搞出各种花哨的东西.
00:16:14但如果你在与一个并未完全接受的人交谈，而且你可以用一种非被动攻击的方式来标记它，你可以标记它并说，让我们试一试，看看这次智能体能不能搞定.
00:16:26如果它们完成了闭环，而且体验不错，那真的会很有帮助，能让大家在其他情况下也亲自尝试.
00:16:33我们的征程仍在继续.
00:16:37我们仍在学习，尽管我们正在向外部交付AI产品、推进我们的AI普及，并且一直在试验各种各样的事情，但我们的自动化之路尚未完全成型.
00:16:50鉴于我们某些构建系统存在诸多依赖关系，我们仍在摸索何时应该使用、以及如何才能有效地使用Cloud Agent.
00:16:58因此我们仍在不断学习.
00:17:01这是一场文化变革.
00:17:02这是一场工程变革.
00:17:03我不知道你们怎么想，但我过去15年一直在硅谷工作，就文化和技术而言，这是我见过的数量级最大的改变.
00:17:16所以我们都在这里，我们都在共同摸索.
00:17:19这就是我今天想和大家谈的内容.
00:17:22谢谢大家.
00:17:28谢谢.
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기