吴恩达讲 AI原生软件工程团队

亲爱的朋友们，

AI 原生软件工程团队与传统团队运作方式差异很大。明显区别在于 AI 原生团队使用编码代理更快地构建产品，但这导致我们运作方式发生许多其他变化。例如，一些优秀工程师现在承担比单纯写代码更广泛的职责。他们部分是产品经理、设计师，有时还是营销人员。此外，在同一办公室工作的团队，能够面对面交流，可以极其迅速地推进工作。

因为我们现在可以快速构建，所以必须花费更多的时间来决定要构建什么。为了应对这个项目管理瓶颈 ，一些团队正在将工程师：产品经理（PM）的比例从 8:1 向下调整到尽可能低的 1:1。但我们可以做得更好：如果我们有一个 PM 决定要构建什么，以及一个工程师来构建它，他们之间的沟通就会成为瓶颈。这就是为什么我看到的最快发展的团队往往有懂得一些产品工作的工程师（并且，可选地，一些懂得一些工程工作的 PM）。当工程师了解用户，能够直接决定要构建什么并直接构建时，他们可以执行得非常快。

我见过工程师成功扩展他们的角色，包括参与产品决策，也见过产品经理扩展他们的角色，包括构建软件。科技行业工程师的数量多于产品经理，但两者都是充满前景的路径。如果你是一名工程师，学习一些产品管理技能会很有用；如果你是一名产品经理，请学习构建软件！

除了产品管理瓶颈之外，我还看到了设计、营销、法律合规等方面的瓶颈。当我们让编码速度提升10倍或100倍时，其他所有事情相比之下都变得缓慢。例如，我的部分团队快速开发出了许多优秀功能，以至于营销组织不得不手忙脚乱地思考如何向用户传达这些功能——这是一个营销瓶颈。或者当一个团队能在一天内完成软件开发，而法务部门却需要一周时间进行审核时，这就是一个法律合规瓶颈。通过这种方式，自主式编码不仅改变了软件工程的工作流程，也改变了其

周围的所有团队。

当规模较小的 AI 赋能团队能完成更多工作时，通才会表现出色。传统公司需要整合来自多个专业领域的人员——工程、产品管理、设计、营销、法律等——来执行项目并创造价值。这导致了由众多专家组成的大型团队协同工作。但如果一个由 2 人组成的团队需要完成需要 5 个不同专业领域的工作，那么其中一些人必须承担超出单一专业领域的角色。在一些小型团队中，个人确实有深厚的专业领域。例如，一个人可能是优秀的工程师，另一个人可能是出色的产品经理。但他们也理解推动项目前进所需的其他关键职能，并且可以根据需要跳入思考其他类型的问题。当然，熟练使用 AI 工具会非常有帮助，因为它能帮助我们思考涉及不同角色的复杂问题。

即使在两人团队中，若要快速推进，沟通瓶颈也必须最小化。这就是我重视同地办公团队的原因。远程团队也能表现良好，但最高效率是通过让所有人都在场，能够即时沟通解决问题来实现的。

这封信主要关注由 2-10 人组成的 AI 原生团队，但并非所有事情都能由小团队完成。我将在未来探讨大型团队的协调问题。

我意识到这些职业角色的转变对许多人来说很难应对。与此同时，我也很鼓励那些愿意学习相关技能的个人和小团队，现在能够完成比以前更多的事情。这是学习和建设的黄金时代！

Keep building

安德鲁

原文链接：

https://www.deeplearning.ai/the-batch/issue-349/