配资是一种为投资者提供杠杆资金的金融服务！
编译 | Tina
在 AI 工具席卷开发圈之后，一批技术老兵的工作方式悄然发生变化。Superhuman （原生 AI 邮件应用）工程负责人 Loic Houssier 正是这场转型的亲历者之一。
这位出身数学背景、拥有密码学工程经验的 VP，曾带领团队经历了从大型 B2C 到核心底层架构的复杂挑战。而当 ChatGPT、Claude Code 等工具走进日常，他选择放弃流程控制权，把实验权交还给一线工程师——预算公司全包，工具随便试，甚至不设“推荐清单”。
“AI 时代没有黄金路径，”他说，“你得自己摸索自己的节奏。”
在这篇深度对谈中，我们将看到：
流程重构：“过去我们靠标准化工具（如统一 IDE 和 CI/CD）提供‘黄金路径’来提升效率，但现在工具每周都在变，这条路径本身已不稳定。”
绩效评估新法：没有单一 KPI 来衡量 AI 带来的真实效率提升，“如果我们能找到一个衡量一切的指标，我们就都可以退休了，也不需要什么工程领导”。
观望代价在变大：“我们那时可以花一年去慢慢学 jQuery，没关系。但现在你等得太久，再找工作可能就困难了。”
展开剩余94%AI 是加速器不是方向盘：AI 不能代替领导力，也无法绕过“产品判断和用户调研。”
1工具随便试、预算全兜底
主持人：我想从一个简单的问题开始：你们是怎么进入软件和科技行业的？
但到了大学，我爱上了数学。我并不是计算机科学出身，我一路念的是数学，一直到硕士阶段。在硕士期间，我开始尝试把数学应用到安全领域，做了很多密码学方面的东西——你既要理解算法和理论，也要能在真实世界中验证它是否可行。那是我第一次深入理解诸如 C 语言、指针、算法优化、内存管理等等。
你提到职业起伏，我也一样经历了很多高低起伏，甚至可以说是左右横跳（笑）。虽然我大部分时间都在科技行业，但也幸运地在软件行业之外工作了两年。那段经历让我从领导力方面学到很多，可能我们后面可以聊聊这个。
Ben Matthews（Stack Overflow 的工程高级总监）：我一直很喜欢听别人分享自己是如何进入科技行业的。每个人的路径都不一样，特别是那些从别的行业转行进入科技的人，他们会带来很多独特的视角和背景。那么你是如何让拥有不同背景的工程师们，统一对“成功”的认知呢？你有哪些方法促使他们达成共识？
Loic Houssier：我自己的背景是数学，而数学的核心是发现模式，试图对现实进行建模，用模型近似现实。我觉得作为一个技术领导者，其实工作本质上是一样的：帮助人们退一步看问题。你今天面临的状况，可能和几年前经历过的事情并没有本质不同。
我的职责之一就是帮助大家建立这种连接：原来这之间是有模式的，也许我在做一些事情时不是最优方式，但只要我退一步思考、从别人的经验中学习，我就能改进自己。我曾在 B2C、B2E 领域工作，也做过核心技术工作，但回头看，很多问题其实是相似的。所以我认为，我工作中很大一部分是在帮助团队成员跳出当下，避免陷入太多眼前的具体细节，而是能够看到更广的背景、更高的视角。
Ben Matthews：我特别认同这种观点。每个人背景不同，从彼此身上学习，才是最重要的。也不是非要让大家统一看法，而是通过融合不同方法论，构建新的共同理解。我很好奇，你是如何创造这种“面对面沟通、一起创新”的机会的？
Loic Houssier：首先，你得刻意去创造这种机会。这并不容易。我们节奏很快，面临市场压力、竞争压力、业务压力，执行是第一优先级。在这种高压之下，往往很难抽出时间去建立人与人之间的联系。Superhuman 是一个完全远程、分布式的公司。我们的员工从旧金山到阿根廷的巴塔哥尼亚、加拿大的新斯科舍省的哈利法克斯，甚至还有人在伦敦。时区跨度非常大。如果我们只专注执行，就会错失那种人际联系、关系的建立。
所以我们会定期组织线下团建，比如组织各级管理者的线下聚会。你需要为此刻意创造空间，真正有意识地去做，尤其是在初创公司这种节奏中，信息的流动方式和信任的建立方式都不同于线下办公。这就要求我们更有“刻意性”（intentionality）。
我们在某次“管理者团建”中做了一些战略对齐的工作：统一对公司目标的认知、统一我们的价值观和工作方式。因为一旦这些达成一致，团队就可以有更大的自主权，每个人都知道公司的方向、我们作为领导者的定位、我们希望怎么传达这些给组织的其他成员。当对齐完成后，团队就能基于这种共识快速行动。我们称之为“对齐中的自治”（aligned autonomy）。通过线下团建建立连接和信任，然后形成一致性，最终加快组织节奏。
Ben Matthews：我完全同意面对面聚会的价值。我们在 Stack 做线下团建时，也诞生了很多好点子，甚至场地的改变都能激发创新，不是因为换了场所，而是换了人与人互动的方式。你刚刚提到“对齐中的自治”，有没有一些具体的例子，能说明这个策略如何推动团队加速前进？
Loic Houssier：一个很好的例子，就是 AI 的落地。
我刚加入 Superhuman 的时候，正值我们开始谈论 ChatGPT、Claude Code 等各种 AI 工具陆续出现。Superhuman 的团队中有不少是经验丰富的老员工，所以我们已经形成了一些习惯、一些默认的工作方式，包括预算使用、引入新工具的流程等等。
在 Superhuman，我们做了一件事是：我们意识到这是一个全新的时代。我们还不知道最佳实践是什么，也不知道将来会用上哪些工具，但我们知道这一定会带来某种程度上的颠覆。那么我们能做什么？
这就回到“对齐式自治”（aligned autonomy）的概念。我们开始思考：对一个身在巴西的工程师来说，来自高层的哪些信息和资源能真正帮助他更快地适应并使用这些新工具？我们得出的答案归结为两个方面：
第一，是要移除繁文缛节。我们要明确告诉大家：“你想尝试什么都可以。”这是我们的首要原则。不要太担心合规性，我们会简化流程，承诺在 24 小时内完成合规审查。不管你提交的是 SOC 2 Type 2 或其他合规相关事项，交给我们。我们会扫清这些障碍，让你可以轻松尝试各种工具。
这就是我们第一个对齐点：我们会尽一切努力让你们可以轻松地尝试任何你想试的工具。没有任何限制，也没有所谓的“优先厂商”。你只要觉得有意义就可以试。
有时候你可能会犹豫：“这个工具看起来不错，但有点贵，而且我已经在用 Copilot 了，或者我们公司已经用了其他工具，感觉可能会多此一举。”所以我才特别强调我们团队中有很多“老兵”，有些习惯已经根深蒂固，不太会主动去质疑和挑战它们。
所以我们主动设定了新的对齐方式：这是一个全新的世界，规则已经变了。大胆一点，疯狂一点，你完全有资格去尝试新东西。
这也带来了一些有趣的现象。比如在最初的一两个季度里，我们看到各种零散的尝试，大家各自采用不同工具，有些使用 ChatGPT，有些在试新 IDE，我们没有强行干预，也不限定平台或工具。虽然并非所有尝试都可控，但我们营造出一种紧迫感和“被赋能感”。
结果是，几乎每个人都开始使用一些新东西。有人用 ChatGPT，有人尝试新的 IDE，各种不同的方式。我在这不点具体工具名称，但总之是百花齐放。
而一旦我们成功创造出这样一个开放、自由、积极尝试的环境，接下来就是时候重新强调“对齐”了：你们已经拥有了充分的自主，现在我们要开始建立共识，形成统一方向。
2AI 时代，没有黄金路径，节奏自己找
Ben Matthews：我特别想听听，这些 AI 工具是如何改变你们的日常开发流程的？现在的 AI 工具层出不穷，有点像“西部蛮荒时代”，你们如何在其中找到新常态，提升工程效率？
Loic Houssier：这确实是一种全新的范式，不只是给一线工程师（IC）带来了新工具，对于我们这些管理者来说也是一样。
过去我们提升团队效率的方式，是通过一定程度上的标准化，比如为大家提供一条“黄金路径”（golden path），这样大家可以在类似的流程和工具中优化自己的开发方式。比如将 IDE、 CI/CD 平台进行适度标准化，然后围绕这些标准化工具建立相应的开发者支持系统。
但现在的问题是，这些工具几乎每周都在发生变化，你说的没错，而且你提到一个很重要的现象是——有些新工具只是嵌入到现有流程中的补充，比如它可能集成在你正在使用的 VS Code 中，那么体验上是延续的，流程也大致不变。
还有些人可能主要是通过终端开发，或其他工具，把它们整合进自己的开发流程。
但越来越多的情况是：整个流程本身都在发生变化。比如说，OpenAI 的 Codex 就代表了一种全新的工作方式。你会给这个 Agentic 框架发一个请求，然后它返回一个 PR。你甚至不需要打开 GitHub，只要发出一句话：“嘿，我发现某个区域有内存管理问题，帮我修一下。”它就会返回一个修复 PR。
我们现在确实有一些开发者就是这么干的。他们早上会发出一堆请求，完全异步处理，然后专心去做自己核心项目的开发。到了中午或某个时间点，他们再回来看 agentic 框架生成的 PR，这时他们更多是在做 review，而不是亲自写代码。
工作流程变了，思维方式变了，连日常的时间安排都变了。
而现在我们还处于一个太早期的阶段，还不足以确定哪种新流程会真正成为“新常态”。所以我们目前的做法，是先去捕捉当前的最佳实践。
所以我们成立了一个 AI 公会（AI Guild），参考 Spotify 的公会模式。
我们以前就有前端公会、后端公会，确保各技术栈的一致性。现在 AI 公会由各个平台代表组成，因为不是每个工具都适用于所有人，比如 iOS 工程师的需求就很不同。
Ben Matthews：我们在 Stack 也有 AI 公会，遇到的挑战和好处都非常类似。来自不同岗位的人不断分享新工具，也有人跳出来唱反调，说“我们绝不该用这些工具”。
Loic Houssier：对（笑）。
Ben Matthews：但这其实是个很好的平衡。每个人都有自己判断的标准，比如这个场景可以用 AI，那个场景暂时别碰。但希望未来我们能继续发展这些工具，逐步形成更系统的工作模式。如何获取数据、如何不断改进它、以及如何在内容生成与内容交付之间形成一个循环反馈机制。
不过我真的很喜欢“AI 小组”这个设定。我们在 Stack 也很幸运地得到了高层的支持，鼓励大家去尝试、去实验、重新组合已有的方式，看看新的可能性。我们鼓励大家跳出舒适区，探索 AI 可以在哪些地方真正帮上忙。
像文档处理、测试生成这些地方，我们发现 AI 有一些显著的“快速胜利”。现在我们正继续探索其他代码区域，看看哪些地方可以稳定、可靠地交给 AI 去重写，同时也在权衡人类上下文理解的不可替代性。某些地方 AI 确实给出了新颖的解法，整个过程很有意思，也很像是在探索一片技术的新边疆。
Loic Houssier：确实有意思。AI 另一个真正带来帮助的地方，是我们以前一直想做、却总没有时间做的“边角项目”。这些项目通常不是直接面向生产环境或客户的，而是一些辅助脚本、数据处理器——你一直想着“要是有空写个脚本多好”，但总是抽不出时间。而现在你可以把它当作一个副项目快速搞定。我们在这类繁琐工作上收获了不少“快感”。
Ben Matthews：而且不只是工程师才能用 AI，现在很多非工程背景的同事也可以用 AI 快速搭个小应用来辅助他们的工作。这真的是打开了一扇门，大大缩短了学习曲线。
Loic Houssier：是的。在 Superhuman，我们非常注重设计体验。我们花了很多时间去思考用户流程和交互细节，因为我们希望产品用起来“感觉对”。而这种“对的感觉”，光靠 Figma 等工具是体验不出来的。你需要真的去“用”这个功能才知道是否顺畅。比如 v0 这样的工具，让产品经理和设计师可以快速生成一个能运行的交互版本，你可以马上知道：“啊，这个用起来卡卡的，虽然图上看不错，但实际不顺畅。”而这些工具能做出非常像样的 POC（原型），让你提前试用，这是对我们帮助非常大的一个领域。
3AI 浪潮下的绩效革命与高层汇报新战场
Ben Matthews：我也很喜欢这种“原型”的使用方式，它真的能帮你解释清楚某个功能。我们在 Stack 最近准备推出一个新功能，其实一开始并不是工程师团队提出来的，而是别的同事有了个想法。他们一开始很难用语言解释清楚，但通过 AI 工具快速搭了个 demo，虽然不是完整功能，也没准备好上线面对数百万用户，但这个交互原型一下子让我们都懂了：“噢，原来你是这个意思！”这比起单纯讲解要有说服力得多。
Loic Houssier：确实如此。在设计师、产品经理、工程经理或者技术负责人之间的协作中，AI 工具极大地加速了沟通和试验。
这也带来了另一个变化：CEO 和董事会开始期待，“嘿，你们是不是可以把速度提升一倍？”于是整个行业的期待值也在上升。
你看到很多 CEO 在外面宣称他们有 95% 的代码是用 AI 生成的——我对这些说法持保留态度，但这种“吹”的风气无形中制造了同行间的压力，让你也不得不评估自己团队的 AI 应用成效。
我很好奇你们在 Stack 是如何面对这些压力的？
Ben Matthews：我们在 Stack 引入了很多 AI 工具，我自己一直坚持的一点是：任何要上线的东西都必须有人类把关。有些工具我们用来做内部的事情，比如数据整理、分类、排序等，生产压力不大，我们就不强求人工介入。
但 我们把 AI 看作是加速工程师，而不是取代他们。特别是那些重复性高、枯燥的任务，比如排序或操作执行几十次，AI 非常适合帮忙。而人类依然在负责 Pull Request 检查、构建流程监控等关键环节。
AI 帮我们很大的一点，是提升了监控与可观测性的响应速度。例如，我们可以更快地被 alert 通知某些代码变化或异常，甚至还能帮助我们合并重复逻辑。它确实帮某些项目大大缩短了开发时间，尤其是那些以前要花很多时间写“基础支撑逻辑”的场景，现在能用 AI 快速完成，交付效率和稳定性都提升了不少。
Loic Houssier：我们还有一个明显的变化是新人的入职体验变得更好。比如新工程师加入一个他们不熟悉的代码模块，可能涉及一堆 API，不是他们擅长的语言，还有很多依赖关系。以前他们需要花很多时间搞清楚“地图”。但现在通过 Claude Code、Copilot 等工具，他们可以像请教一个懂代码的同事那样直接提问：“这个模块怎么工作的？”“这个库和那个库之间有什么联系？”工具会一步步引导他们，像个贴身导师一样。
我有个工程师在评审中就说到这一点：“过去我可能得花两三天才能理解这个模块的来龙去脉，现在只要用对了工具、问对了问题，一个小时就搞清楚了。”这真的很让人震撼。
Ben Matthews：换个话题，我们聊聊 AI 背景下的一些“传统问题”。比如，如何衡量工程团队的绩效？AI 是否改变了你对“高绩效团队”的判断标准？
Loic Houssier：我觉得，评估生产力永远都会涉及定量和定性两个方面。我真希望有人能发明出一个唯一的定量 KPI，让我一看就知道——对，就是这个指标能告诉我真实情况。
但现实是，我现在还主要依赖一个特定的汇总性 KPI，它更多是用来看趋势，而不是看绝对值。这个指标就是“每位工程师每周的 PR 数量”。
我们当然也用 DORA 指标、SPACE 模型这些通用框架，但我发现这个 PR 数量的指标更像是一个带宽吞吐量的参考。它仅代表带宽，不会影响结果。这个指标是可以被“玩弄”的，比如说你可以故意拆分成一堆小 PR 来灌水。但只要你明确告诉团队：“这个指标不是用来考核你们的，不要作弊，它只是用来发现哪些团队遇到了阻力。”比如某个团队 PR 数突然下降，可能是他们的技术栈比较复杂，也可能是正在重构大模块。那你就要深入去了解原因，而不是一味要求数字好看。
对我来说，这个指标一直很好用。它能帮我了解每位工程师每周提交多少 PR，我们会按团队人数进行归一化，这样即使团队人数变多，仍能衡量整体的吞吐量。从定性的角度来说，你回头看，有时你会感觉，“哇，这个月他们效率爆表”，你可以把这种感觉和实际数据联系起来。
我觉得这是一个挺有意思的指标。而且自从我们引入 AI 之后，这个数字确实变高了。换句话说，从纯粹的吞吐量来看，AI 让我们的效率更高了。但这不意味着最终交付给用户的成果质量也变好了。这方面我们得通过其他方法去衡量。所以我们也补充了一些定性分析。比如我们每个月会做一次员工问卷调查，问大家：“AI 对你有没有帮助？”“你每天都在用 AI 吗？”“使用体验如何？”
我们确实看到一些很明显的变化：九个月前，大家还带着怀疑态度；但现在，绝大多数人都会说，“AI 是我日常工作的一部分了。”根据我们最近在四月份做的一次调查，大家主观反馈是，AI 帮他们节省了大约 20% 的时间，也就是生产力提升了 20%。这还是个比较保守的估计。
有些人在项目的特定阶段能达到 40% 的提升。特别是你刚加入一个新项目、还在接触阶段，有这些 AI 工具辅助时，成长速度就会越来越快。
所以，从总体来看，在我们这种以资深工程师为主的团队里，大家对 AI 的接受度和理解度已经很高了。保守估计，AI 至少提升了 20% 的生产力，实际可能比这还要高。
Ben Matthews：你刚才说的内容我太有共鸣了，尤其是那种“如果我们能找到一个衡量一切的指标，我们就都可以退休了，也不需要什么工程领导”——太对了。我也同意数字很重要，但它们只是指标，是一些变量，帮助你判断团队的运行状态。
不管是开发速度还是 PR 提交数，经典那句话怎么说来着：“你告诉我怎么衡量我，我就能告诉你我会怎么行为。”这正是问题所在。而当我在团队里尝试缓解这种担忧时，我也会强调，“这个数字只是帮助我们发现一些模式。”
比如说我们用开发速度（velocity）作为例子，有时候某个团队的故事点（story points）突然下降了，我们就会看看到底是故事本身变了，还是有人请病假了？我们会去看能不能从数据中读出什么信号。或者某个团队数据突然暴涨，那我们也会问，是不是他们在某个领域特别擅长？是不是我们做了什么事，真正提升了他们的效率？
所以我们更倾向于把这些指标看成“值得深入观察”的线索。
Loic Houssier：对我来说，这些指标是非常好的“对话起点”。当某个 KPI 出现上升或下降趋势时，我就拿它出来和团队对话，比如说：“大家，上周我们的数据有点下降，能不能帮我解释一下情况？”这种交流不是为了责备谁，而是为了了解背景。
可能团队会说，“我们刚刚从 Coffee 迁移到另一个技术栈，重构量特别大，每个 PR 都很庞大。所以我这周只提了一个 PR。”这时候你就知道了，他们没有问题，只是背景不同而已。
但与此同时，当你要跟董事会汇报，或者向 CEO 汇报团队的进展时，你总得给他们一些指标，来帮助他们理解团队的演进状态，在面对 AI 的冲击时：到底团队在变好，还是在原地踏步？
Ben Matthews：我觉得现在很多公司也在试图用这些指标来弥补其他方面的短板。就像你说的，AI 可以加速工程师的效率，但它解决不了所有问题。
我看到有些领导常犯的一个错误就是，把 AI 当成救命稻草，比如产品没找到真正的市场匹配点（product-market fit），或者没能真正理解客户的真实需求。于是他们就说，“那我们用 AI 吧，这样我们可以更快地构建产品。”但方向错了，再快也没用，甚至可能把问题放大。
所以 AI 无法解决那些本质上的领导力问题或产品定位问题。很多人现在对 AI 的期望是：“我们给工程师配上 AI，就能解决一切问题。”但其实，AI 是一个极其有价值的工具，是工具箱中的一个新工具，但你仍然需要为工程师提供正确的方向、正确的思路，以及足够的支持，才能让他们构建出真正有价值、真正契合市场需求的产品。
4AI 范式转型，观望者的代价有多大？
Loic Houssier：是的，而且你需要合适的人员和资历来把控这些事。你需要足够资深的人来高效使用 AI。比如说，当你有数百万用户，或者每秒有海量交易时，你肯定不希望某个 AI 生成的“魔法 PR”只是被一个初级工程师草草审核就直接上线了——绝对不行，完全不行。我们现在还远远没到那个阶段。
当然，将来可能可以做到，但目前还不行。尽管如此，AI 已经在深刻改变我们的工作方式了。
那么，我们要如何适应它？作为工程师，你有 10 年经验，但这些工具不是你一出生就会用的。我之前提到，我最早接触的是 Amstrad CPC 6128，从那会儿到我研究生毕业，技术的变化虽然持续，但更像是线性推进，并不是范式的断崖式变化。
是的，那些早期的教程让你更深入地理解底层，比如底层处理器原理等等，但它们没有改变我整个思考问题的方式。而现在我们所处的是一个真正的“范式转变时代”。
你怎么适应这种变化？你得想清楚对自己的职业意味着什么，而这真的很难。
我上周还和一个朋友聊到这个，我们谈到了刚从大学毕业的那批工程师。他们基本上从大一进校到大二，就已经置身于完全不同的世界了，因为这个范式转换在他们学习过程中就发生了。
他们经历了 AI 从“很酷”变成“可以用了”的整个过程。他们见证了 ChatGPT 能够迅速回答各种问题，然后意识到：“天啊，我们现在可以用 LLMs 来构建产品了。”接着又是：“天啊，现在还有智能体（Agents）。”再之后是：“天啊，现在又有 MCP 了。”
每一次都是一次范式转变。
所以他们的大脑可塑性（brain plasticity）是把这种剧变当作日常的。而我们这一代人，是在一种“你总有时间慢慢学习”的假设下成长的。因为那个时代的技术变革并没有现在这么剧烈。比如我们从纯 Java 过渡到 jQuery，再到 Angular，再到 React，说实话如果你回头看看，那其实算不上什么“巨变”。而且这个过程花了将近 20 年才走到今天。
Ben Matthews：你说得没错，特别是从 Java 到 jQuery，当时大家都惊叹：“哇，现在我可以不用写那么多 JS 就能实现这些交互了！”那确实是个进步。
Loic Houssier：它只是一个抽象层的提升。对我来说，虽然它更简单，但不是范式转变。你怎么看？
Ben Matthews：我觉得，（jQuery 的）真正范式转变点在于，它让更多新人更容易进入网页交互的世界。虽然功能层面没变，比如 DOM 操作机制还是一样，但以前你必须写复杂的 Java，还得兼容 IE6，各方都麻烦。所以我认为，就我们在 Web 上做的事情而言，它没有改变，但从多少人可以在 Web 开发商更快地完成任务，我确实认为这里发生了很大的转变。
Loic Houssier：没错，我的意思其实是，从个人能力成长的角度看，像 jQuery 这种技术出现后，你不需要马上去学也没事。现在不一样了，如果你对 AI 工具的演进保持观望态度，哪怕只是等一个季度不学习，就可能被甩在后面。
这就是“脑部可塑性”越来越重要的原因。我们那时可以花一年去慢慢学 jQuery，没关系。但现在你等得太久，再找工作可能就困难了。
我相信 Stack 也在思考如何将“AI 熟练度”引入面试流程。因为现在我们越来越倾向于寻找那些能熟练使用 AI 工具、提高效率的人。这将成为面试的一部分。
Ben Matthews：这些问题非常有价值。那么，Superhuman 接下来有什么计划？你们最期待什么？
Loic Houssier：我们接下来想解决的核心问题是：如何维持产品的“感知质量”。我们一直非常注重质量，我们的用户对产品的感觉是：一切都很棒，一切都很快，一切都运转良好。这种愉悦和信任的感受，就是我们在用户与产品之间营造的“品质感”，就像你使用苹果设备的那种感觉——“它就是好用”。
但随着 AI 和大语言模型的引入，我们从一个完全可控、可 QA 的质量标准，进入了一个用户输入会显著影响输出质量的世界。你输入的提示词如果很烂，那结果也只会更烂。垃圾输入就会导致垃圾输出。
我们允许用户在 Superhuman 中搜索邮件、提问并获得上下文相关的回答，但如果他们提问方式很糟糕，那结果也会很差。于是我们要思考：如何保证用户不会因为“输入垃圾”而怪我们“输出垃圾”？怎么提升输入质量，确保最终体验不受影响？这是一项我非常投入的工作，更偏向 UX 设计，而不是传统 AI KPI 如精准率、召回率等。
这个问题其实是交互设计问题：我们如何引导用户提问更聪明、表达更清晰？
发布于：北京市和兴网提示：文章来自网络，不代表本站观点。
