全栈构建者是融合开发团队的演变，通过AI理解业务语言，使业务专家能用自然语言修改应用。这需要重新架构应用，并对AI集成、自然语言处理有更高要求。尽管有挑战，但它代表了技术能力的民主化，模糊了业务和技术角色之间的界限。
译自：Microsoft and the Rise of the Full-Stack Builder
作者：Darryl K. Taft
就在几年前，“融合开发团队”的概念还是微软战略的关键部分，旨在赋能所有专业水平的开发者进行协作以构建应用。
这个概念很简单：将业务领域专家与专业开发者结合起来，创建能够解决实际业务问题的应用。融合开发团队成员可以使用诸如微软的低代码/无代码 Power Platform之类的工具，以及Visual Studio和Visual Studio Code等专业代码工具。
这种愿景已经进化。Amanda Silver是微软开发者部门的产品企业副总裁 (CVP)，她告诉 The New Stack，她正在见证一些不同的东西的出现。她称之为“全栈构建者”——一种新的范式，业务专家可以直接使用自然语言修改应用程序，而无需学习技术平台或编程概念。
Silver 说：“随着这些代理能力的全面引入，这种愿景正在不断演变。我们现在看到的更多是一种模式，当您考虑即将构建的新应用程序时，您必须考虑构建应用程序的 AI 时代之前的方式，以及 AI 时代之后的方式。更进一步，还有构建应用程序的代理方式。”
传统融合团队的局限性
对于融合开发团队，这种模式是让业务用户自己构建应用程序，因为他们比任何人都更了解需求。
微软 Power Platform 的 CVP Ryan Cunningham 描述了融合团队试图解决的核心问题：“这有点像传统上将所有专业知识从财务运营人员或人力资源人员的头脑中取出，然后放入软件工程师的头脑中，并希望能够得到正确的结果。另一方面，这是一个缓慢且昂贵的过程。”
这种方法具有明显的优势。融合团队可以减少业务和 IT 之间的沟通障碍，加快简单应用程序的开发周期，并让专业开发人员可以专注于更复杂的问题。
但也有一些局限性，包括当业务需求变得复杂时，平台会受到约束，并且与现有系统集成、高级业务逻辑和交付定制用户体验通常需要专业开发。
此外，正如业务用户成为“「公民开发者」”一样，他们也被困在特定平台的约束中，限制了他们的能力和技能的可转移性，Silver 说道。
全栈构建者登场
AI 代理的出现从根本上改变了这种局面。AI 系统无需培训业务用户像开发人员一样思考，而是可以理解业务语言并将其转化为技术实现。
“我们开始思考这个问题，并称之为更像是一种全栈构建者，”Silver 解释说。“如果你正确地架构工程系统和应用程序，那么实际上可以让那些可能不太以代码为中心，而更像是业务领域或应用程序使用方面的专家的人，实际参与进来，并向诸如 GitHub Copilot之类的工具描述他们希望如何更改应用程序或更改用户界面。”
在之前对 The New Stack 的采访中，Cunningham 对融合开发团队的描述表明，全栈构建者范式基本上是融合团队原则的延续，但具有增强的能力。“我们很多最成功的客户实际上是将技术人员嵌入到业务人员中。并且使用 Power Platform，因为它是一个他们都可以工作并在同一个工具包中保持高效的地方，”他解释道。
关键的区别在于，全栈构建者方法不是限制业务用户在平台限制内工作，而是要求工程团队创建能够理解和响应自然语言业务需求的系统。
“基于工程系统以及我们作为 AI 上下文提供的关于应用程序构建方式的各种维度，我们实际上可以在对应用程序的这些类型的更改上更快地取得进展，”Silver 说道。
但真正的突破在于它如何解决核心融合团队的挑战。“很难教会一个商人如何构建可扩展、安全的企软件。很难教会一个软件开发人员如何运营一个企业，但如果我可以将他们放在同一个工具包上，他们就可以一起做令人惊叹的、神奇的事情，”Cunningham 说道。
微软全栈项目经理 Amit Gupte 在一篇题为“全栈产品构建者的崛起：人工智能对未来工作的蓝图”的博文中写道：“在我自己的工作中，我看到了人工智能是如何打破角色之间的壁垒的。产品经理、工程师和数据科学家不再孤立地工作。借助人工智能，一个人现在可以构思、制作原型和验证——这些任务曾经需要一个完整的跨职能团队。这不是一种威胁——而是一种机遇。”
与此同时，Elevation Capital 的人工智能合伙人 Krishna Mehra 也在一篇博文中写道：“这种范式转变的核心是一种新的原型：全栈构建者。这些人对项目进行端到端的掌控，利用人工智能从想法无缝过渡到执行，而无需等待移交。”
他补充说：“全栈构建者的崛起证明，使用人工智能的聪明问题解决者可以覆盖过去需要多个专家才能完成的工作——而且没有摩擦。新浪潮更加精简、快速且更具适应性。”
技术基础：面向业务用户的架构
全栈构建者模型需要在 Silver 称之为“工程系统和上下文”方面进行大量前期投资。这不仅仅是将 AI 添加到现有应用程序——它需要重新思考如何架构应用程序以支持自然语言修改。
应用程序必须经过设计，以便 AI 代理可以安全地修改组件，而不会破坏系统的其他部分。这需要明确的边界、定义明确的接口和全面的测试框架。代理还需要了解做出某些决策的原因，而不仅仅是如何在代码中实现它们。
动态工作流取代静态流程
全栈构建者模型中最显著的变化之一是，新模型支持可以适应业务需求的动态、AI 驱动的工作流程。
Silver 说：“现在，借助代理能力，创建这些东西要容易得多。即使只是创建工作流程应用程序也更容易使用代理能力进行建模，而且，过去需要人工干预的工作流程的某些方面现在可以使用代理能力来完成。”
这意味着业务专家可以用他们自己的术语以自然语言描述流程，而 AI 代理可以处理以前需要简化的工作流程或开发人员干预的复杂逻辑。
实际应用
Silver 强调，全栈构建者模型可以跨越不同级别的应用程序复杂性进行扩展。
她说：“当您考虑正在构建的这些新型应用程序时，这些不同类型的应用程序的复杂程度各不相同。有些只需要简单的提示。有些需要更复杂的代理应用程序编写才能完成功能。”
Silver 的团队已经在内部实施了这种方法。她说，他们构建了“代理应用程序，使我们能够去收听所有这些不同的渠道，并进行聚合，从而更好地了解我们引入的这些类型的功能的反应”。
她说，这表明业务需求（例如了解客户情绪）如何可以直接转化为技术实现，而无需业务用户学习开发技能。
传统 IT 之外的民主化
其影响范围超出了传统的企业 IT 部门。Silver 认为，全栈构建者模型代表了技术能力的民主化。
她解释说：“我们正在吸引更多可能没有正式技术背景的人，并使他们更有能力构建各种不同的解决方案。然后，它发展的另一种方式是，我们正在真正地发展工程系统以及我们在应用程序描述方式中建立的上下文，这使我们能够使用更自然的语言提示来随着时间的推移对应用程序进行更改。”
Cunningham 表示，这有助于扩大软件开发机会。
“只是有很多软件，特别是在公司和组织内部，在过去的几十年里，我们只是没有投入精力。比如，让一个传统的全栈开发团队来开发一个内部发票工具，这根本没有意义……现在有可能对那些以前没有被软件工程师服务到的长尾场景进行真正专业的软件开发和创新，并且真正地让那些真正了解他们需要什么的人来做。”
这意味着业务和技术角色之间的界限将变得模糊，但方式与传统的融合团队尝试的方式不同。全栈构建者模型不是让业务用户像开发人员一样思考，而是让技术系统理解业务语言。
挑战和实施注意事项
尽管有前景，但实施全栈构建者模型并非没有挑战。其中之一是，构建能够安全响应自然语言业务需求的系统比传统的应用程序开发更复杂。工程团队需要 AI 集成、自然语言处理和上下文管理方面的新技能。
其他挑战包括确保应用程序的质量和一致性，以及治理和控制，因为传统的 IT 治理模型假设技术变更要经过开发人员审查流程。全栈构建者模型需要新的治理框架，该框架可以在保持控制的同时实现业务用户的自主性。还有变更管理和安全方面的考虑因素。
Cunningham 说：“为更多人提供更好的工具将孕育更多的创造力，将孕育更多的创造。毫无疑问，它会带来一系列新的挑战，但我认为现在真的是一个对技术充满乐观的时代。而且我认为，如果我们做得对，我们可以以一种好的方式邀请更多的人参与进来。”
展望未来：业务-开发者协作的未来
Silver 表示，她设想全栈构建者模型是软件构建方式更广泛转型的一部分。它不是取代开发人员，而是改变了开发人员的工作性质，并扩大了可以为应用程序开发做出贡献的人员范围。
从融合团队到全栈构建者的演变不仅仅代表着技术转变。通过使系统理解业务语言，而不是要求业务用户学习技术语言，组织打破了传统开发流程的约束。
然而，专业开发人员将需要 AI 系统设计、自然语言处理和上下文管理方面的新技能，因为他们的角色将从编写应用程序代码转变为设计可以根据业务需求生成和修改代码的系统。
融合开发团队的概念承诺弥合业务和技术之间的差距。全栈构建者模型通过完全消除差距来实现这一承诺。
