Claude Code 工程一号位亲自给 Agent 热潮降温：狂烧 Token 时代已过，现在该算ROI了 - InfoQ

InfoQ 中文 2026-06-25T09:11:19.395918

Claude Code 工程一号位亲自给 Agent 热潮降温：狂烧 Token 时代已过，现在该算ROI了 - InfoQ

当 AI 将代码交付量提升至 8 倍后，软件工程的瓶颈已从编码转移到验证质量、管理异步 Agent 和衡量真实产出。Anthropic Claude Code 团队负责人 Fiona Fung 分享了团队如何从追求 Token 消耗最大化转向计算 ROI，以及管理者必须亲自开发才能真正理解产品问题。

瓶颈转移：当代码交付量增长 8 倍之后

在 AI 编程的讨论中，外界最常关注模型生成代码的能力、工程师效率的提升幅度，以及 AI 是否终将替代程序员。但 Anthropic Claude Code 与 Cowork 团队负责人 Fiona Fung 认为，真正的变革已经越过了“代码生成”本身。

在 Lenny's Podcast 的对话中，Fiona 提供了一个罕见的内部视角：当工程团队的代码交付量在一年内被 AI 拉升到原本的 8 倍之后，软件工程的瓶颈并未消失，而是转移到了别处。写代码不再是最稀缺的能力，取而代之的是验证质量、判断优先级、衡量真实产出、管理异步 agent，以及保持团队文化。

Fiona 领导 Claude Code 和 Cowork 背后的团队，并监管 Boris Cherny 以及整个工程和 PM 团队。在加入 Anthropic 之前，她曾在 Microsoft 参与 Visual Studio 和 TypeScript 相关工作，后来加入 Meta，创立 Facebook Marketplace 团队，参与智能眼镜、AR 眼镜以及 Instagram 基础设施、增长、安全等团队建设。超过 25 年的工程经历，让她亲历了从 Vim 到 IDE、从 CD 发版到在线发布的软件工程变迁，也正在亲身经历 AI 对工程组织的重塑。

![][1]

从 Vim 到 IDE 再到 AI：一位资深工程师的视角

Lenny： 你作为经历了 25 年工程周期的人，能否回顾一下哪些关键时刻改变了你对工程工作的理解，也塑造了今天的工作方式？

Fiona： 最早我在 IBM 做 DB2，在操作系统服务团队。当时我的想法很简单：越靠近底层、越靠近操作系统，就越“硬核”，也能学到更多东西。所以我很庆幸能进入 IBM 实习。

从 IBM 到 Microsoft，对我来说是一次巨大的变化。在 IBM 时我主要用 Vim，没有真正使用 IDE。当时虽然有 Eclipse 授权，但大多数人不常用，更多是在终端里调试。2000 年互联网泡沫破裂后，很多公司冻结招聘，我能拿到 Microsoft offer 非常幸运。当时他们通知我去 Visual Studio 团队，但我其实并不知道 Visual Studio 是什么——我来自偏 Unix 的学校，听到这个名字甚至以为是不是更好的画图软件。经理当时的表情说明了一切。

但 Visual Studio 成了我职业生涯前 11 年里最重要的部分。那是我第一次真正使用 IDE，第一次看到调试器、断点、多线程调试等能力，那种体验对我来说非常震撼。在 Visual Studio 编辑器团队，我用 Visual Studio editor 来构建 Visual Studio editor，也正从那里开始，我真正喜欢上了 dogfooding——自己深度使用自己团队做的产品。我们希望先为自己和队友创造非常好的开发体验。

那个年代没有今天的社交媒体反馈机制，工程师很难快速听到客户反馈。虽有用户研究和客户拜访，但没有即时反馈。幸运的是，在 Visual Studio 团队，我们自己就是重度用户，团队内部就能形成非常快的反馈循环。

Lenny： 大家现在讨论工程师角色变化时，常常只关注最近两年 AI 带来的冲击，但其实软件工程历史上也经历过很多重要变化，比如 Visual Studio 等 IDE 的出现。

Fiona： 是的。我在 Visual Studio 工作时，我们还会把软件刻在 CD 上发布。那时有非常硬的 deadline，必须按时准备好交给制造环节，再刻录到 CD，最后放到货架上销售。后来软件可以在线发布，这又是一次变化。过去工程时间是非常稀缺的资源，同时有印刷 CD 这样的硬截止日期，所以大家会做大量规划，确保在有限时间里尽量把事情做好。

现在在 Claude Code 和 Cowork 上，我们看到另一种变化：Coding 不再是瓶颈。你刚才提到的 8 倍交付量增长图也说明了这一点。问题变成了：瓶颈转移到了哪里？现在不只是工程师在提交代码，Claude Code 团队里的设计师、PM，几乎所有人都在 check in code。提交代码的人更多，角色更混合，吞吐量也变得非常高。因此新的问题是：我们如何做 verification？如何确认这些高速生成和提交的东西是正确的、高质量的？

2026 年，一个被 AI “浸透”了的软件团队

Lenny： 很多人都在想，未来的软件工程、工程管理、产品团队管理到底会是什么样子。你现在其实正在亲身经历这一切。你提到 Verification 需求更强了，即当代码量增长 8 倍时，团队必须更关注质量和正确性。到 2026 年，一个真正 AI-pilled 的软件团队会是什么样？

Fiona： 角色边界正在变得模糊，越来越多人会成为 builder。我最近做的一个变化是，我设置了一个 Claude Code remote session，让它接入我们所有 repo，这样我可以全面看到团队正在做什么。这个实例也能访问我们的 Slack 频道，以及我们追踪的各种指标。

每个月，我会和团队一起回顾。我们会打开 Claude Code，一起看过去一个月的重点工作、哪些产品发布了、效果如何、反馈频道里出现了什么。以前我可能只是用这些 session 来生成 PR 或修 bug，但现在我也用它来帮助我和团队成员展开对话。

Lenny： 也就是说，这已经变成了一种管理方法——不是只帮助大家 ship，而是帮助你了解 ship 出来的东西有没有影响、质量怎么样。你用 Claude 跟踪团队交付的内容，然后把这些信息变成和团队成员的讨论？

Fiona： 对。重点不只是“有没有发出去”，而是它上线后的表现如何。有没有引入 bug？如果出了问题也没关系，我常说：make new mistakes。犯错可以，但要犯新的错误，这样团队才是在学习。如果你的目标是完全不犯错，那可能说明你移动得不够快，或者太谨慎了。

通过 Claude，我们可以回看一些 incident，分析它们之间是否有共同主题。比如在质量方面，是否能看出某些热点区域，是否说明下一个投资方向应该放在这里。过去这会是一个非常手工的过程。回到一年前，我不认为自己能用 Claude 获得这些洞察。

管理者如何跟上 8 倍交付量

Lenny： 一部分原因也是以前大家没有 ship 这么多东西。过去可能简单列一下：“这个季度我做了这些 feature。”但现在交付量太大了，你需要新的方式来掌握团队成员到底在做什么。除了用 Claude 分析，还有什么方法能帮助你保持质量、跟上所有正在发布的东西？

Fiona： 反馈渠道对我们非常重要。以前我的早晨习惯是：拿一杯咖啡，然后看各种反馈频道，从里面找一些我能帮忙处理的点。如果我有 maker time，就会看看有哪些问题我可以直接帮忙，或者哪里存在明显 gap。

这种习惯不仅适用于个人开发，也适用于管理视角。当代码量激增，管理者必须亲自“吃自己的狗粮”（dogfooding），甚至先做 IC（个人贡献者）的工作，才能不被 dashboard 和会议汇报隔离在真实产品之外。写代码不再是稀缺资源，但判断力、优先级排序、质量管理，成为新的稀缺资源。

关键要点

图片: ![][1]

本文节选自对 Anthropic 工程负责人的深度访谈，重点探讨了 AI 代码助手如何重构开发工作流、代码审查的进化、招人标准的变化，以及 AI 时代工程师需要具备的心态。通过实际案例，展示了从 routine 自动化到 TDD 重生的新实践，并强调了 growth mindset 在技术变革中的关键作用。

工作流的自动化革命：从手动写 Prompt 到 Routine

大约一两个月前，Anthropic 推出了 routines 功能，这彻底改变了团队的工作方式。以前可能需要手动编写 prompt，现在通过设置 routine，就能让 agent 自动生成 prompt、甚至生成 Pull Request。例如，我可以让 Claude 持续监控某个反馈频道，自动总结出现的主题。第二天醒来，就能看到结构清晰的摘要，甚至还有一些已生成的 PR 等待 review。这些反馈来源非常广泛：包括内部员工反馈、邮件渠道、Slack 中收到的来自朋友、LinkedIn 或社交平台的消息，以及合作伙伴的反馈。信息量巨大，而 Claude 帮我保持了高效的跟踪。

AI 代码审查：瓶颈变自动化

代码审查一直是团队交付速度的瓶颈。去年还没有 Claude Code 审查功能时，人工 reviewer 常常积压大量工作。现在，虽然对于需要深度专业知识的关键区域仍需合适的人类审查，但很多常规检查可以自动化。关键在于将“什么是好的”定义框架化——如果你有 spec 或某种质量标准，就把它存入 repo，并确保与代码保持同步。Claude 擅长根据这些框架进行验证，例如我们最近把 content design 做成一个 skill，Claude Code review 就能自动检查代码是否符合这些标准。

这实际上是测试驱动开发（TDD）的一种进化。TDD 在 2000 年代曾非常流行：先写测试，让测试失败，再写代码使其通过。原则很好，但很多人觉得写测试像“先吃西兰花”——先要付出成本，而真正兴奋的是搭建产品。现在，我在 Claude Code 上修的第一个 bug 就让它帮我做 TDD：先写测试、确保测试失败、然后修复、最后通过。过去测试生成是一种必须支付的成本，现在可以被自动化。很多老原则重新发挥价值，因为模型能帮你完成更多执行工作。

招人标准：创造性构建者与深度系统专家

在招聘时，我发现两类画像特别重要。一类是有产品感的创造性构建者（creative builders），他们热爱产品、有自己的想法、能快速做出原型、持续收集反馈并迭代，端到端拥有产品体验。另一类是能解决高难度问题的深度系统专家（deep systems experts）。例如，我加入 Claude Code 时团队有很强的产品通才，但缺少系统和分布式系统背景的人，于是补强了这方面的人才。深度专业知识仍然不可或缺，模型虽强，但许多地方仍需信任但验证。只要某个领域需要深度专业能力，这类人才就值得投入。

AI 时代的工程师心态：成长心态与恐惧应对

最近观察到一个明显变化：过去工程师遇到新功能请求，第一反应是“这太难了，太复杂了”，现在变成了“这完全可能，让 Claude Code 去做”。关键不再是事情是否太难，而是你能想得多大、多有野心。理论上很多事情都能做，限制变成想象力和野心。一位非移动端工程师，借助 Claude 作为合作伙伴，可以顺利推进移动端功能。这确实抬高了每个人能做的事情的上限。

那些适应 AI 很好的工程师，与感到沮丧、抵触的人之间，最关键的差异是成长心态（growth mindset）。成长心态意味着你一直学习，并且意识到：过去帮助你走到今天的做事方式，未必还能帮你走到下一阶段。这很难，因为每个人都是靠原有方式获得成功，当被告知需要改变时，自然会有抵触。而适应 AI 较好的人，通常更愿意带着好奇心进入新变化，持续学习。

挫败感背后往往是恐惧。恐惧是自然的进化保护机制。面对恐惧时，我的建议是：靠上去（lean in），靠近它，然后问自己“我能做什么？什么在我控制范围内？”很多沮丧来自“所有变化发生在我身上，而我无能为力”。如果能换个角度：“这件事是否也可能是为我而发生”，然后找出一件你能采取的行动，情况会好很多。

我儿时的经历印证了这一点。我原本想做视觉艺术家，高中九年级接触电脑和 HTML 编程后，发现编程也能像艺术一样创造、表达和讲故事。但我当时非常担心能否负担大学学费。后来我看到加拿大国家银行招聘高中暑期实习做银行柜员，尽管我最讨厌会计课，还是报名了。这份工作成了我的“生命线”：暑假工作攒钱，后来周末也做，靠这份收入支付学校开销。在 2000 年互联网泡沫破裂后，很多公司不招实习生，我继续做了两年银行柜员。这就是当时我能采取的、在自己控制范围内的行动，用来对抗“可能负担不起上学”的恐惧。

所以，面对焦虑和恐惧时，先问有没有一个你能控制的行动。有两句话对我影响很深：“如果你不害怕，你会做什么？” 以及“偶尔做一些让你害怕的事。” 当你已经非常擅长某件事情时，往往处在熟练度高点。继续成长的方法，就是去做一些以前没做过、让你有点害怕的事情。这个过程必然会有能力下滑期，因为需要重新学习，但这也是成长的方式。

帮助中小企业跨越 AI 鸿沟

现在正在形成一种差距：一部分人积极拥抱 AI，表现越来越好；另一部分人没有跟上，可能被新的世界甩在后面。帮助小企业使用 AI 工具是我非常在意的事。我从小从香港搬到加拿大，不会说英语，父母忙于工作，奶奶和我不懂英语。我通过上学和同学交流学会了英语，但对奶奶来说，在一个新的国家生活是很孤立的。

关键要点

通过小企业的真实使用场景，Fiona 展示了 AI 工具如何解决非技术用户的痛点，并强调了传播这些工具的价值在于分享具体案例。她进一步剖析了 Anthropic 团队发现潜在需求（latent demand）的方法，并展望了工程工作向异步协作（async collaboration）和智能体舰队（agent fleets）演进的方向。

从社区到社区：小企业里的真实需求

后来有一年夏天，我们偶然发现一家小毛线店，店主也会说粤语。于是那个夏天，我和奶奶每周都会去。奶奶在那里找到了属于自己的编织圈子（knitting circle），而我也学了一些手工，比如 macramé（编绳艺术）。那家小店让我看到，即使是一个微小的企业，也能创造出强大的社区感。这也激发了我后来对小企业的关注。

之后，我用 Cowork 处理商务差旅报销。我一直不喜欢做这件事，但 Cowork 能帮我完成这些琐碎的工作。于是我想：如果它能帮我处理这些小额的商务报销，那对小企业主而言价值更大。我有很多小企业朋友，他们工作非常辛苦，利润率有时很低。我见过朋友坐在吧台前，面对堆积如山的账单，只是在做发票和报销。没有人真正喜欢做这些事。

我开始帮几个朋友上手 Cowork，这个过程让我很受触动。一方面，他们在 onboarding 流程中遇到了一些“优秀”的 bug，帮助我们发现了产品问题；另一方面，他们使用 Cowork 的方式超出了我原本的想象。

比如，我原本关注的是 Cowork 处理 PDF、发票的能力。但有一位开两家餐厅的朋友说，她的文件夹就像厨房里的杂物抽屉，堆满了文件和下载内容，她知道里面有几份菜单，但找不到。于是我们让 Cowork 访问目录，它帮她找到了菜单。

接着她提出了一个特别的问题：她想让本地居民和游客都觉得价格合理，于是让 Claude 查看当地同类型菜系的价格，以判断她的菜单价格是否可比。Claude 给出了类似市场分析的结果，还提到了一些当地餐厅。她看到后说：“我前阵子刚去过西雅图那家餐厅，确实不错。”每次从这些使用场景中，我都能学到东西，并获得很多反馈。

播种：如何让更多人拥抱 AI

*Lenny：如何把这些能力传播给更多人？很多人会说“我没时间学这个”“我讨厌 AI”“我想忽略它”。解决方法是多分享案例吗？尤其是我的听众里很多人已经非常 AI-pilled（深度拥抱 AI）。

Fiona： 我建议从你自己真实感受到的变化开始。想想 AI 工具在哪件事上真正改变了你的生活或工作，然后把它作为与身边人对话的入口。

对我来说，AI 是一种工具。我也完全理解它有令人沮丧的一面，但我一直认为知识就是力量。你必须学会使用这些工具，因为它可能是“光明与黑暗”之中的光明部分。

所以我希望大家做一件事：如果你的社区、家庭或你喜欢的小企业里，有人可能还没接触 AI，试着问问他们：“你有没有想过 AI 也许能帮你做这件事？”一开始可能会有些尴尬。我第一次联系朋友时也很不自然，因为我平时不太和他们聊工作。我会说：“我在做 AI，能不能给你演示一下 Cowork 能做什么？”但后来我们都玩得很开心。

我希望这样的对话能更多发生。我们需要继续分享知识，让这些工具更公平地被更多人使用。否则我担心，人与人之间的差距会越来越大。

*Lenny：我也有同感。分享具体 use case 非常有力量。比如我前几天用 Cowork 填写儿子的夏令营表格，然后在 Twitter 上分享，很多人反应是：“哦，我从来没想过可以这么用。”很多时候就是这些很小的场景，人们没意识到 Cowork 和 Claude 可以帮上忙。

关注潜在需求：Anthropic 如何发现机会

*Lenny：Anthropic 似乎很早就能发现巨大机会。比如 Coding，你们很早就意识到这是一个巨大的市场。Cowork 也是类似，你们很早就进入知识工作领域，像是在说：为什么不把整个知识工作都解决掉？另外，Anthropic 很早就重视模型的 personality（个性），不只是体验问题，也影响智能和成功。你们做了什么不一样的事，使你们能比其他实验室更早发现这些机会，并敢于大规模投入？

Fiona： 我没有在其他实验室工作过，不太确定它们怎么运作。但在 Claude Code 和 Cowork 团队，我们确实会关注 latent demand（潜在需求）。

编码这个 use case 很幸运，因为很多 Anthropic 员工自己就是第一批用户，所以能非常快地获得反馈。但 latent demand 这个概念很重要。例如 Cowork 的例子中，很多并非程序员的人也在使用 Claude Code。我们就会问：能否让这种体验变得更好？

这种观察方式不仅在 Anthropic 有用，在我过去做的其他产品里也很有帮助。我之前拜访了一些小企业，后来我们推出了 Claude for Small Business。这一点不是我推动的，所以不是抢功，但我也注意到了同样的现象。

我和小企业主一起使用产品时，他们会问：“它有没有这个插件？有没有那个插件？”我会说：“我觉得有吧。”然后我们还要去找。后来 Claude Business 相关能力把这一切打包起来，在 Cowork 里有一个小 toggle。另一个团队一直在和小企业做 Cowork sessions，可能他们也发现了提升效率和改善体验的机会。

所以关键是：不仅要持续的听反馈、迭代，努力做出令人愉悦、可靠、高质量的体验，同时也要观察有没有新的使用场景正在涌现，我们能否让这些场景变得更好。

在软件行业，我学到一件事：用户会用你没预料到的方式使用你的产品，无论好坏。所以最好的方法就是持续迭代、持续学习，并且与反馈保持很近的距离。

*Lenny：Latent demand 这个词在这里很贴切。意思是说要非常仔细地观察那些你没有预料到、但正在出现的用户行为。一旦看到这种信号，就投入进去，探索它，做出很棒的东西。当你看到用户为了让某件事可行而“绕很多弯子”时，你能不能把它变成一个更顺滑、更好的体验。

异步协作：下一个前沿

*Lenny：你们处在能力边界的最前沿，工程角色的工作方式已经发生了很大变化。你觉得工程工作方式的下一个前沿是什么？是大量的 agent 并行吗？还是其他东西？

Fiona： 我们会更多转向 async（异步工作）。提到 agent fleets，这也是 routines 有意思的原因。过去我可能同步写一个 prompt，等待结果；后来我可以异步启动几个 prompt。但现在，我可以设置一个 routine，让它替我生成这些 prompts。抽象层级又往上抬了一层。

我没有水晶球，不知道一年后会变成什么样，但我觉得一年后我们可以再回头看这个问题，这会很有意思。

*Lenny：routines 到底是什么？从同步工作变成异步工作，具体是什么意思？是写一个 prompt，然后它不会立刻完成，而是之后运行吗？

Fiona： 比如我以前每天早上会喝咖啡，然后让 Claude 帮我看某个 Slack 频道。现在我可以设置一个 routine，每天早上固定时间运行。它不只是帮我看信息，还可以代表我启动 agents。过去如果要自动化，你可能会做一个 cron job。但现在是：它会看这些反馈，如果发现某些 bug 或一些可做的 polish fixes，它就可以启动 agent 去处理。等我醒来时，可能已经有一些 PR 可以 review。

以前即使我有不同的 agents，我还要自己想：拿到这些信息后，我下一步该做什么？现在是更高一层的抽象：我可以写一个 routine，让它替我生成 prompts，并派生出不同的 agents。所以我认为我们会越来越走向这种异步工作方式。

*Lenny：这很有意思。作为管理者，你每天会做很多固定动作：检查项目进展、看哪里落后、看谁被卡住、看哪些地方需要修补。你现在说的是，可以把这些日常管理动作写成 prompts，让 Claude 替你执行，然后告诉你：这是我正在做的，这是你需要 review 的。甚至到某个阶段，如果验证机制足够可靠，就可以直接让它“go for it”。

Fiona： 是的，可以给它一点自由，让它做更多事情。

*Lenny：这让我想到 agency 的概念。很多人说，表现最好的人是最主动、最 proactive、最有 agency 的人。这个话题会让你想到什么？

Fiona： 我很喜欢 agency 这个词。Claude Code 和 Cowork 团队也非常重视这一点。但有意思的是，我们通常会和另一个东西放在一起讲。对我们来说，重要的是：如果这里有一个问题，团队里的每个人都可以有自己的想法，去思考怎么解决它。这就是 high agency。

关键要点

本文探讨了在AI辅助编程狂潮下，工程管理者应如何平衡自主权与问责制，避免将“堆Token”等同于生产力。作者强调，衡量产出应聚焦于最终成果（outcome），而非动作量（motion），并分享了通过深度使用产品（dogfooding）保持产品脉搏的实践，以及当前行业面临的三个未解难题。

权衡：自主权与问责制

然而，需要注意的是，“高度自主（high agency）”必须对应“高度问责（high accountability）”。允许团队自由发挥与尝试的同时，必须明确责任：你试图解决什么问题？你的假设是什么？自主与问责如同一枚硬币的两面，这一平衡对我们的团队运作至关重要。

从Token消耗到ROI衡量

问题： 行业风向正在转变。过去大家倾向于“token maxing”——尽可能多地使用Token，先看看能做出什么。但现在开始追问：我们究竟得到了什么？花了多少钱？ROI是多少？

Fiona的观点： 工程生产力是一个极具争议的话题。最初，人们用代码行数（lines of code）衡量吞吐量，但很快发现：一个工程师写了大量代码，可能只是将某个库迁移过来。于是有人提议只看“有效代码行数（significant lines of code）”，可一旦更新框架生成更少代码、输出结果不变，又该如何度量？接着又转向PR落地时间。

无论采用什么指标，最关键的问题是：产出（output）是否真正导向了成果（outcome）？也就是说，你产出的东西是否服务于最终目标？

Token maxing就像过去的代码行数——看起来动作很多，但我更关心的是：我们到底要解决什么问题？我十分赞同这句话：不要把运动（motion）误认为进步（progress）。如果你只衡量工具使用率，你衡量的只是行动（action），但它是否让最终结果变得更好？这才是核心。

因此，我会先退后一步（zoom out），问清楚：要解决的问题是什么？衡量该问题是否解决的最佳方法是什么？然后围绕这个去执行，而非仅仅盯着生产力指标。

除了指标，我建议团队领导者，尤其是在更多人开始采用AI工具时，做一次“倾听之旅（listening tour）”。特别要听取资深工程师的反馈：哪些有效、哪些无效、如何改善。因为他们能帮助经验在工程团队中放大和扩散。有时，这些对话比仪表盘更能激发新想法，带来共同学习的机会。

当然，指标本身也有价值。一个好的指标应该能让你持续“爬坡（hill climb）”——即围绕它不断优化。但你必须始终问自己：这个指标还在服务你的目标吗？它是否仍然服务于你最初想要达成的成果？

我在Facebook Marketplace早期有一个实例。当时我们按地区上线，希望先确保产品体验足够好，再扩展。早期我们看“卖家数量”这个指标。上线第一个地区后，我发现某个地区卖家数量不高，但用户其实能找到想要的物品——而这才是我们的真正目标：帮助人们找到所需。后来我意识到，那个地区虽然卖家数量少，但有一些高活跃、高供给能力的“超级卖家（power sellers）”。

工程经理的新基线期望

问题： 除了“团队交付更快”，工程经理现在对团队还有什么新的基线期望？还有其他变化吗？

Fiona： 首先，现在大多数提交（commit）都是Claude辅助完成的，这是一个巨大变化。其次，我们有Slack反馈频道和各种仪表盘，这些也会交给Claude处理。我认为，工程师需要继续强化自己的产品感（product sense），这会让他们成为更有主见、更强的产品工程师。

另外，过去一些传统上不属于工程师的事情，现在工程师也能做了。以前你可能会被卡住，因为要等待某个跨职能伙伴（产品、设计等）。现在这种阻塞会少一些，因为模型能增强工程师原本不具备的能力。

所以变化是双向的：工程师变得更有产品意识，也更直接对产品质量和产品成功负责；与此同时，其他角色也越来越像工程师——边界正在模糊。

经典观察： 现在“角色”是什么？也许就是你日常工作中占比最高的那部分——你做什么最多，那就是什么角色。

深度使用产品（Dogfooding）的重要性

问题： 你非常执着于“living and breathing the product”——持续使用自己正在构建的产品。为什么如此重视dogfooding？为什么也会把这件事灌输给团队？

Fiona： 对我来说，dogfooding是保持产品脉搏（product pulse）的方式。每当你构建一个产品时，背后都有一个梦想：你希望启用某种体验，或者让某种体验变得更好。亲自使用产品，能让我始终贴近这个脉搏。

我对dogfooding的热爱很大程度上来自Visual Studio，但这个习惯在后来的产品里一直有用。例如在Facebook Marketplace，即使我离开团队后，有一次我想卖一台MacBook Air，便尝试用Marketplace发布。结果刚挂上去，就有买家/卖家试图用我之前没发现的新诈骗方式行骗。这再次证明：用户会以你意想不到的方式使用你的产品，无论好坏。

所以，对于领导者或团队任何人而言，每个人都有不同的生活场景，能发现不同问题。例如我支持VR/AR团队时，不知道为什么，我用VR时总能复现一些奇怪的地面高度问题——这后来成为我的贡献方式，因为我能稳定复现某些体验问题。

第一点：dogfooding能让你保持对产品的真实触感，不至于只迷失在指标、仪表盘或演示文稿里。

重要补充： 这体现了“个案证据（anecdotal evidence）”与数据的关系。作为产品或工程负责人，从具体个案、亲自作为用户遇到的小问题中获取的信息，往往比单纯盯着数据更有价值。有时，这正是我最有效帮助团队的方式。例如在领导VR团队时，我没有往代码库提交代码（怕搞坏操作系统），但团队在做许多体验打磨（polish fixes）。我就把自己的dogfooding时间用来检查体验——这样我仍然能有意义地帮助团队把住质量标准。团队成员通常也会很感激，因为leader真正在使用产品，大家会感觉leader是投入的，不是高高在上。

这也和前面提到的“工程师要更有产品感”相关。工程师需要变得更像PM，PM也需要变得更像工程师。对工程师来说，培养产品感的一种方式就是持续使用产品——作为用户使用，就能知道产品缺什么。

如果你的团队做的产品很难被你自己使用，那就去见客户。无论如何，你需要建立接近用户的渠道。

每次客户拜访都会学到新东西。例如Facebook Marketplace进入拉美市场时，在智利测试效果不如其他地区。我们带着一堆Android手机做一个很小的研究行程。刚落地，我一打开这些手机，就发现当地LTE连接比美国慢很多。Marketplace feed在低速LTE下加载得很差——这是一个极大的增长阻碍，因为用户连feed都加载不出来。这就是为什么听客户反馈、建立快速反馈循环如此重要。

Jeff Bezos曾说过： 如果数据和一个具体个案发生冲突，要更相信个案。这是一个很好的佐证。

三个尚未解决的难题

在近期的一次演讲结尾，我列出了三个当时尚未想明白的问题。如今虽然变化很快，但这些问题依然存在：

  1. 我们是否仍然需要分开的iOS和Android组织？
  2. 完全自动化代码审查能推进到什么程度？
  3. 在角色边界越来越模糊的情况下，如何确保每个人都同样高效？

这三个问题仍是我们必须面对并需要继续探索的方向。

关键要点

本文探讨了在 AI 辅助开发背景下，移动端组织架构如何平衡深度专业性与跨领域灵活性，以及自动化审查面临的核心挑战——如何定义并验证“好的体验”。Fiona 指出，专业领域知识依然不可或缺，但组织形态需要更灵活；同时，自动化审查的难点在于将专家经验转化为可量化的验证机制。

移动端组织架构：寻求专业性与灵活性的平衡

关于 iOS 与 Android 团队的组织问题，Fiona 表示仍在探索中。她强调，深度专业知识依然至关重要，因此 Android 和 iOS 专家仍需保留。然而，由于工程师现在可以跨领域灵活工作，过去那种规模庞大、完全独立的移动端组织可能不再必要。关键在于找到平衡点：我们是否拥有正确且足够的专业能力？这个问题仍在持续摸索。

自动化审查：定义“好的体验”仍是核心难题

Lenny 问道：完全自动化审查能推进到什么程度？

Fiona 回应：这是一个很有趣的方向。例如我们已经实现了内容设计的自动检查。更大的问题是：如何定义“好的体验”？验证（verification）仍然存在巨大机会。我们需要判断专家经验在哪些环节仍不可替代，同时不断追问：能否利用这些专家经验，将一部分事务自动化？

Fiona 进一步指出，应当审视完整的端到端体验，而非仅从工程角度出发。体验、内容设计等其他领域也不容忽视。

Lenny 总结：也就是说，核心问题是如何建立一种验证机制，确保最终体验符合预期？

Fiona 确认：正是这样，而且这依然困难。你提到的评估中既有准确性问题，也有体验问题——体验是否令人满意、是否符合预期，这是我们仍在思考的难题。

关键要点

查看原文