AI 将如何颠覆传统软件开发团队

软件行业正在经历自云计算以来最重大的变革。AI 正在从根本上改变我们构建、运营和与软件交互的方式。作为一名长期观察并撰写了关于行业重大变革的作者，我见证了从面向服务架构（SOA）到微服务 的转变，再到容器化和无服务器架构的演变。现在， AI 正在推动一场更深刻的变化。这不仅仅是关于自动化编码任务或在应用程序中添加聊天机器人，我们正在见证新的开发范式、运营实践和用户交互模型的出现，这些将重塑团队的结构和软件的消费方式。

本文将探讨五个已经对软件团队产生影响并将在未来几年内变得越来越有影响力的趋势。对于每个趋势，我们将探讨其变化所在、现实世界的例子，并讨论不同角色——从开发者到架构师，再到产品经理——如何适应并在这个新的环境中茁壮成长。让我们从最根本的变化开始：我们编写代码的方式。

生成式软件开发

软件开发已经经历了从劳动密集型的打孔编程到多层抽象编程的演变。

这段旅程从需要深厚技术专长的汇编语言开始，随后发展到系统级语言如 C 和 C++，再到具有托管运行时的 Java 和 JavaScript，再进一步发展到高级脚本语言，如 Python——每一步都使开发变得更加容易，同时以牺牲对底层的控制为代价。AI 原生开发（已知还有多种名称）代表了这一演变的最新阶段。

生成式 AI （GenAI）和大语言模型（LLM）正在减少对手动编码的需求。开发者不再需要逐行编写代码，而是指导 AI 系统执行代码编辑、生成应用程序框架，甚至创建完整的软件组件。

在某些领域和受控的环境中，例如 Web 应用程序， AI 甚至能够通过自然语言指令（文本或语音）和图像来创建和运行全栈应用程序。这不仅延续了软件开发向更容易、更抽象的方向发展的历史趋势，而且正在改变传统的开发流程。

图片

图 1：AI 编码辅助工具一览（来源：GenerativeProgrammer.com）

当前的 AI 辅助开发工具正朝着两个方向演变：

• AI 增强型 IDE 和代码助手：如 GitHub Copilot、Cursor 和 Windsurf，通过提供智能代码补全和生成来增强传统开发流程。这些助手会分析项目上下文、依赖关系和模式，提供相关代码片段建议并补全函数——所有这些都在开发者熟悉的环境中完成。还有一些工具可以帮助进行代码评审和现代化遗留应用程序。所有这些工具都提供了一条低风险、增量式的路径，让开发者在保持现有编码实践和流程的同时将 AI 整合到他们的工作流中。
• 自主编码智能体：如 Devin、Bolt、v0、Replit 和 Lovable，它们超越了仅提供建议的范畴。它们在受控环境和受限领域（例如 UI 和 JavaScript）中运行，解释高层次需求，提出架构，生成整个应用程序，甚至可以部署和运行。这些平台将软件构建扩展到了开发者之外，让非传统开发者和半技术用户能够进行“氛围编码”——通过自然语言进行原型设计，设计草图，并进行迭代，直至它们变得可用。然而，生成式软件开发仍处于早期阶段，难以可靠地复制，并且尚未很好地与现有的迭代和增量软件工程实践相结合。尽管像验收测试和行为规范这样的概念在提高一致性方面显示出潜力，但该领域仍在发展，许多问题仍有待解答。

AI 正在改变代码的编写方式，开发者必须适应这一变化。那些能够从“专家代码打字员”转变为 AI 合作者的开发者，通过提供清晰的上下文、将需求细化为提示词并引导 AI 提供期望的结果，将能够节省很多时间并专注于更高价值的任务。尽管 AI 可以生成代码，但它仍然缺乏对可扩展性、安全性、风险分析的判断能力，特别是在特定的业务背景下。生成式软件开发仍处于起步阶段，通常不太可靠，也难以整合到现有的流程中。最有价值的工程师将是那些能够理解架构、系统设计、完整软件技术栈、端到端软件开发生命周期（SDLC）、业务优先级和非功能性需求（NFR）的人。他们还会进行各种权衡，并确保 AI 生成的代码与这些考量因素保持一致。

为了为未来做好准备，开发者需要加深对 AI 的理解，掌握提示词工程（了解 AI 擅长的领域和盲点在哪里），并学习新的工具和实践。工程师必须通过专注于系统设计、架构、领域专业知识和批判性思维技能来适应变化。AI 工具可以自动化某些编码任务，但理解复杂系统、确保安全性和将业务需求转化为技术解决方案的能力仍然是人类独有的，对于维持职业的持久性来说至关重要。软件工程的未来在于那些能够将人类解决问题的能力与 AI 功能相结合的人，他们能够提供更快更好的解决方案，而不仅仅是生成更多的代码。

AI 驱动的运维

现代分布式系统的规模和复杂性已经超出了人类对传统监控、故障排除、安全和运营的能力。随着 AI 辅助代码生成加快开发速度，未来应用程序的规模和复杂性只会随之增加。传统可观察性方法——手动检查日志、基于阈值的警报和静态仪表盘——正变得越来越不起作用。监控和维护 AI 生成应用程序的唯一可行途径将是使用 AI 驱动的工具，这些工具能够实现与可观察性数据的自然语言交互、预测性问题检测与模拟、自动化根本原因分析，以及在需要最少监督的情况下进行总结和补救。

主要的可观察性供应商，如 New Relic、Splunk 和 DataDog，已经将 AI 整合到他们的应用性能监控（APM）工具中。这些增强功能使得从海量遥测数据中提取可操作的见解成为可能，减轻了认知负担并加快了事件解决速度。传统机器学习和 GenAI 在现代可观察性和 安全性 领域的常见应用包括：

• 预测性分析：这种方法通过分析过去的攻击数据来发现复杂模式并识别潜在威胁。AI 可以使用真实和合成数据集模拟攻击场景。
• 行为分析：与预测性分析（检查历史趋势）不同，行为分析侧重于实时用户活动。AI 可以检测可能表明凭证被泄露或存在内部威胁的模式，而传统的安全工具通常会忽略这些模式。
• 异常检测：AI 持续监控网络流量、系统日志和 API 交互数据，以便发现与既定规范的意外偏差。AI 通过生成合成异常、对检测模型进行压力测试和加强针对零日攻击和新兴威胁模式的防御来增强这一过程。
• 根本原因分析：传统根本原因分析通常涉及筛选海量日志、关联指标、阅读非结构化文档和手动识别模式——这是一个缓慢且容易出错的过程。AI 驱动的平台（如 Resolve.ai）通过聚合整个操作堆栈的数据——从基础设施指标和应用追踪到部署历史和文档——来自动化这一过程。

图片

自动化根本原因分析（示例：Resolve.ai）

对于运维团队而言，AI 将可观察性从认知密集型的信号匹配转变为自动化、可操作的洞见。AI 可以处理来自维基和聊天对话的非结构化数据，将遥测数据与代码变更联系起来，生成动态的事件仪表盘，并提出具体的解决方案，包括逐步的说明。例如，如果某个服务出现延迟峰值，AI 可以立即将这些峰值与最近的部署、基础设施变更以及过去类似的事件相关联。此外，AI 能够确定根本原因，并在一个自动生成的仪表盘上展示调查结果，同时在公司的 Slack 频道中请求恢复确认。这种程度的自动化减少了平均解决时间（MTTR），将运维从被动式的救火转变为主动式的问题预防。最重要的是，它捕获了记忆，将每个事件变成未来可参考的教训。

要在这个新的环境中生存下来并蓬勃发展，运维团队必须积累使用 AI 驱动的运维工具的专业知识，从编写长查询、解析日志和手动编写自动化脚本转变为设计全面的可观察性策略，引导 AI 系统做出我们所期望的行为。尽管 AI 可以处理大量的运维数据并提出解决方案，但运维人员需要理解系统架构、业务背景和影响分析策略，以便评估这些建议并做出明智的决策。

上下文感知的交互式文档

对于软件的采用来说，好的软件文档一直是至关重要的，无论是开源项目还是商业 SaaS 产品。软件 文档 包括：面向初学者的教程、针对特定任务的指南、提供详细信息的参考指南以及用于帮助人们进行深入理解的解释性内容。尽管这种结构仍然还有价值，但随着软件的演变速度越来越快，保持文档的准确性和相关性变得越来越具有挑战性。

基础 AI 模型的一个主要限制在于知识的陈旧和过时。但随着检索增强生成（RAG）的兴起，LLM 可以通过直接从代码库、API 规范和文档存储库中提取数据来提供实时且最新的响应。凭借这种能力，AI 正在改变文档的编写方式和开发者与文档的互动方式。CrewAI 的 “与文档聊天” 功能让开发者不再需要手动搜索大量文档或 StackOverFlow 网页，而是使用 AI 驱动的聊天界面来获取相关答案。在新的软件项目中，开发者越来越多地利用 LLM 的实时代码生成和执行能力，通过编码来了解项目。文档领域的最新发展包括：

• 文档创建：许多 工具 通过分析源代码、API 和开发者讨论建议内容来简化文档编写工作。AI 可以生成结构化文档、代码片段和常见问题解答，从而减轻技术作者的手动工作量。
• 通过嵌入式聊天阅读文档：一些工具，如 Kapa.ai 和 Inkeep 直接集成到文档门户、产品界面甚至是营销网站中，让开发者可以用对话的方式查询文档。还有一些工具，如 DevDocs，通过模型上下文协议（MCP）将交互式文档访问集成到命令行界面（CLI）和集成开发环境（IDE）中。这些 AI 驱动的文档工具通过提供即时、相关的响应来减少支持工作量，改善了开发者体验。
• 自动化的知识捕获与支持整合：一些工具，如 Pylon，通过引入 Copilot 来分析开发者问题、支持工单和事件报告，动态地丰富了文档。它们不再依赖于预先定义的手册，而是根据与实际用户的互动来创建基于现实世界的常见问题解答、最佳实践和故障排除指南。

这些 AI 驱动的工具不仅能搜索文档，当被集成到用户流程中时，它们还能够理解产品上下文，读取错误堆栈跟踪信息，从多个来源编译相关信息，并以与用户专业知识水平相匹配的对话格式提供答案。

对于技术写手和文档团队来说，工具正在发生翻天覆地的变化。如果你还在手动编写和更新文档，而没有利用 AI ，你可能会很快被自动化工具所取代。只是编写传统的文档或复制粘贴 AI 生成的内容已经不够了，成功的关键在于要将 AI 作为生成和消费文档的力量倍增器。专注于更高价值的活动，例如：捕获动态内容（如用户问题）、积累最佳实践、记录事件教训、分析文档使用模式、识别缺失的知识，并在正确的时间和场合提供这些信息。文档的未来不再是静态文本，而是对话式的、上下文感知的，并深度集成到用户的工作流程和工具中。那些能够适应这种变化的人将成为不可或缺的人，而那些无法适应的人将难以跟上时代的步伐。

上下文感知的 “AI 助手即 SaaS” 接口

无服务器架构和许多以开发者为中心的 SaaS 的原始承诺是引人注目的：让开发者专注于业务逻辑，而平台处理基础设施配置、扩展、安全性和可观察性。虽然这一理论在理论上很好，但无服务器复杂性的现实带来了新的挑战。开发者不得不应对大量的服务、API 和配置。文档负担呈指数级增长。跟上最佳实践成为了一份全职工作。随着无服务器服务变得更加强大和细粒度，所需的配置量也越来越多，使得开发者难以保持生产力。

AI 将通过在 SaaS 产品中集成上下文感知助手来提升用户体验。开发者不再需要在文档中搜索、安装定制的命令行界面，或者通过 curl 来理解 API 调用。相反， AI 驱动的界面将提供实时、上下文感知的指导。更重要的是，这些界面能够根据自然语言指令执行操作，自动化常规任务。随着 MCP 等新兴标准的出现， AI 解读用户上下文并在外部资源上执行操作的能力正在迅速增强。不久的将来，用户不仅能获得分步指导，还能在聊天界面中直接完成任务，将 AI 从被动助手转变为主动的问题解决者。

图片

SaaS AI 助手模型：嵌入式、扩展式和外部式。

现在有多种方式可以集成 AI 助手：

• 深度集成到 SaaS 中的上下文感知 AI 助手
• 作为服务扩展（通常是入口点或服务的部分能力）的 AI 助手
• 完全独立的第三方 / 外部 AI 助手服务

以 Supabase AI Assistant 为例，这是 Supabase UI 中深度集成的 AI 助手。它不只是一个文档聊天机器人或搜索工具，还是一个上下文感知助手，它能够理解产品领域知识（Supabase）、用户当前状态（拥有哪些服务和访问权限），并直接与平台的 API 交互。例如，当开发者在查询数据库遇到困难时，这些助手不仅可以向开发者解释相关概念，还可以生成正确的查询，分析潜在的性能影响，甚至在开发者请求时直接执行查询。这些助手结合了实时辅助和采取行动的能力，在促进用户更好地使用平台方面发挥了很大的作用。

另一个例子是 Vercel 的 v0.dev，它独立于 Vercel 运营，旨在吸引想要创建网站并最终在 Vercel 或其他平台托管的新用户。通过独立托管，这项服务不会将 Vercel 的所有功能和复杂性暴露给可能只想要创建简单网站的非技术用户，但会逐渐引导他们成为 Vercel 的用户。尽管是独立运营，这些 AI 入口点最终将更紧密地集成到主要 SaaS 平台中，实现用户在 AI 功能与传统 SaaS 功能之间的无缝切换。

在最后一个类别中，我们可以看到像 Lovable.dev、Bolt.new、Replit 这样的 AI 原生 SaaS 服务。这些服务正在探索新的应用场景，作为传统 SaaS 的第三方前端，吸引非技术用户和半技术用户。例如，Lovable 能够与 Supabase 这样的目标部署平台实现无缝集成。同样，Bolt 也与 Netlify 和 Github 等平台有着类似的集成。

这一转变将对所有 SaaS 产品产生影响。自然语言正逐渐成为用户交互的必备界面，尤其是在复杂技术产品的入门阶段。它将成为产品主导增长（PLG）的新动力，让新用户和不太技术的用户快速上手，直观地探索功能，并更快地实现价值。但在前进的道路上，不仅仅是添加一个聊天机器人那么简单，还需要重新思考如何以 AI 增强的方式为用户提供最有价值的东西。如果你是一家数据存储供应商，这可能意味着通过提示词而非始终依赖 SQL 客户端来创建架构、查询数据和生成测试数据。如果你提供的是一个可观测性平台，这可能意味着可以通过一个提示词来检查日志和分析使用模式，等等。现有的 SaaS 供应商如果没有积极计划整合 AI 助手，可能会被具有更高效用户体验的 AI 原生初创公司所颠覆。

如果你是一家 SaaS 公司的产品体验负责人，你必须保持领先地位：

• 亲自使用 AI ——尝试使用 AI Copilot 和助手，深入了解它们的功能。
• 在公司内部启动一个 AI 项目——培训团队成员，寻找机会。
• 识别产品使用中出现的问题，并利用自然语言界面（聊天）解决这些问题。
• 寻找真正的价值——不只是添加一个聊天界面那么简单，还需要确定 AI 将如何提升你的价值主张。
• AI 是一个新的能力推动器。探索 AI 如何为你的产品开辟全新的应用场景或用户群体。

智能体系统的兴起

组织开始越来越多地采用 自主 AI 智能体，这些智能体可以协调、规划和执行复杂业务任务，几乎不需要人工干预。AutoGPT、AutoGen、Dapr Agents 和 LangGraph 等项目是构建智能体的流行框架的早期代表，而更完整的软件技术栈正在迅速增长。这些智能体系统不再是由孤立的 AI 模型执行单一任务，而是正在演变为 AI 服务网络。这些网络需要具备分布式系统功能，包括工作流编排、异步消息传递、状态管理、可靠性、安全性和可观察性，这些功能远远超出了简单的 API 集成。

这一转变将以类似互联网、微服务、云和无服务器架构影响组织的方式影响每一种技术角色：

• 开发者必须掌握 智能体设计模式、与 LLM 的对话式 API 和智能体编排技术，以便能够高效地连接和协调智能体。
• 架构师需要设计出生产就绪且具备成本效益的 AI 解决方案，将智能体系统与现有的云和 SaaS 平台集成起来。
• 运维团队必须部署新的 LLM 监控、可观察性和追踪 工具，用于 LLM 驱动的应用程序，因为这些应用程序的行为与传统软件不同。此外，这些新的工作负载和工具需要与现有的工具和运维实践集成。例如，我介绍了 Dapr 项目如何将它的 Conversation API 与现有的可观察性和安全工具集成。
• 平台工程师需要创建更好的框架，以便更容易地开发、部署和管理 AI 智能体。
• 产品经理必须了解 评估技术，以便精准衡量 AI 接口的行为表现与有效性，尤其是在以提示词和响应为核心交互方式的场景中。

好消息是，目前有不断增长的开源工具和无尽的免费学习资源可供那些愿意深入研究的人使用。在这个快速发展的领域，组织有两个选择：提升团队在智能体系统开发方面的技能，或者招聘已经具备必要专业知识的人才。AI 驱动的智能体系统并非一种短暂趋势，而是软件自动化的下一个重大演变。

AI 行动计划

AI 的快速发展要求我们采取一种有意识和有计划的方法来构建强大的 LLM 基础知识基础，了解它们的工作原理、能力以及局限性。掌握提示词工程的基础知识，并熟悉那些可能长期存在的成熟工具。这些知识将使你能够与同事就 AI 进行富有成效的讨论，并为跟踪其发展动态以及寻找相关机会打下坚实的基础。

你的下一步行动应与你在软件开发领域中所扮演的角色保持一致：

• 对于开发者来说，使用 Cursor 和 GitHub Copilot 等编码助手是基本要求。使用 CodeRabbit 等工具进行自动化代码评审也是一个容易实现的目标。将这些工具集成到日常工作中，找到它们适用的低风险场景。如果你的雇主不允许使用这些工具，可以在开源项目或个人副项目中进行实践，并与同事分享它们的优缺点。
• 运维团队应该探索如何让 AI 自动化更多任务，减少人工干预。然后为运维 AI 工作负载做好准备，无论是仅涉及对外部 LLM 的少量调用，还是运行完整的智能体系统。
• 架构师应该专注于了解端到端的 LLM 驱动架构以及如何将智能体系统融入企业环境。这不仅涉及单个 AI 组件，还包括如何设计可靠、安全 的系统，同时利用 AI 能力，保持企业级质量。重点应放在识别组织内的战略机会上，无论是利用 AI 的能力来现代化遗留应用程序，还是从头开始设计新的原生 AI 系统。
• 技术写手需要将 AI 工具作为新的文字编辑器，尝试各种工具、模型和提示词，专注于自动化写作流程。未来的内容将是对话式的。
• 产品经理需要关注 AI 发展趋势及其对产品战略的潜在影响，研究 AI 原生产品，了解自然语言界面和 AI 辅助功能如何提升用户体验。

设计、运维和我们过去所熟知的编程方式将继续发生演变，但掌握这些基础技能能够让你为这些演变做好准备，以应对接下来发生的一切。现在就开始吧，因为这一趋势将在未来十年内持续存在。

查看英文原文：

https://www.infoq.com/articles/ai-trends-disrupting-software-teams/

声明：本文由 InfoQ 翻译，未经许可禁止转载。