Webflow将AI全面融入工程部门，为工程师提供AI工具包，优化开发流程。AI应用于代码审查、测试等环节，但关键决策仍依赖人工。Webflow还在其平台中集成AI，提升用户体验，如AI网站构建和内容生成。内部使用MCP，连接工作流程。尽管存在阻力，但AI采用率持续增长。

译自：How Webflow Got 89% of Its Engineers To Use AI Daily作者：Richard MacManus

将 AI 技术集成到 IT 部门的呼声非常强烈，但对于科技行业的公司来说，这种需求必然更为迫切，尤其是在他们自己的产品中已经充斥着 AI 的情况下。

因此，当最大的网站构建平台之一 Webflow(译者注：链接为英文网站)联系我，讨论他们如何将 AI 完全集成到自己的工程部门时，我感到非常好奇。我与 Webflow 首席技术官 Allan Leinwand(译者注：链接为英文网站) 谈论了该公司在 AI 开发方面的“全力以赴”的理念。

Webflow 约有 300 名工程员工，在最近的一篇博客文章(译者注：链接为英文网站)中，Leinwand 解释说：“我们已做出公司范围内的承诺，将 AI 引入每位工程师的日常工作流程中。” Webflow 为其每位工程师提供“完整的 AI 工具包”，其中包括 ChatGPT Enterprise 许可证、Cursor 和 Augment Code 的访问权限、GitHub 中的 AI 工作流程等等。

AI 工具包中的编码工具是根据 Webflow 工程师最常使用的工具选择的。在这些工具中具有一定的灵活性，但如果小型团队正在处理单个项目，Webflow 是否更希望每个团队成员都使用相同的 AI 编码工具？

“我认为这并不重要，”Leinwand 回答说。“从我们的角度来看，我们并不认为 AI 必须是规定性的。我们希望让开发人员找到最适合他们的工具。而且你知道，对我来说，真正重要的是输出，对吧？所以我关注的是诸如我们的 PR 率是否提高了？我们的变更失败率是上升还是下降了？我们是否看到了从编写第一个 Jira 工单到部署的周期时间？”

在软件开发周期中使用 AI

在 DevOps 方面，除了 Jira 之外，Webflow 还使用 GitHub，但未使用 Copilot。

“我们在 AI 方面不使用 GitHub Copilot，”Leinwand 说，“但我们使用了大量嵌入在 GitHub 内部的其他 [AI] 功能。”

在他的博客文章中，Leinwand 解释说，他们使用“一个可选的 AI 驱动的 PR [pull request，拉取请求] 代码检查工具，工程师可以通过在 GitHub 上使用 ai-linter 标记 PR 来触发它。”（代码检查是指运行一个程序来分析代码中潜在的错误。）

“它的作用是，”他解释说，“它基本上运行一个 webhook，告诉 Claude Code 去实际读取 PR，读取代码更改，并生成一个 PR 描述并将其直接放入 PR 中——这非常酷。”

Leinwand 补充说，他们花了很多时间思考如何采用开发人员的工作流程（从编码到部署），并“确保我们可以在整个周期中尽可能好地使用 AI。”

“通过 CI/CD 流程，该测试基础设施正在通过 AI 进行大量增强。”– Allan Leinwand, Webflow CTO

也就是说，他指出周期的构建和部署部分没有使用太多 AI。该公司使用 Buildkite 作为其构建工具，并在 AWS 上进行部署。

“因此，我们基本上是在 Kubernetes 之上使用 Docker 容器进行部署，”他补充说。“其中没有太多 AI。它更像是自动化，它拾取容器，然后在我们的全球基础设施中进行部署。”

另一方面，对于软件测试，Webflow 广泛使用 AI。

“工程师可以使用 AI 快速验证假设，”Leinwand 说，“他们可以编写单元测试，他们可以编写功能测试，他们可以生成端到端和冒烟测试。[…] 通过 CI/CD 流程，该测试基础设施正在通过 AI 进行大量增强。”

环路中的人

Leinwand 在他的博客文章中写道，尽管 AI 越来越成为他们开发过程的一部分，但他们“在重要的地方继续依赖人类的判断”。他提到了代码审查作为一个具体的例子：“每一次更改，无论是人编写的还是由 AI 生成的，都由工程师进行审查。” 我请他详细说明 Webflow 是如何做到这一点的。

“是的，自从我写了那篇文章以来，我们实际上已经增强了该 [流程]，”他回答说。“我们现在实际上有一个工具会检查每个即将提交的 PR，试图合并到主 [分支] 中，我们会评估其风险：低、中和高。”

“……我们有人工参与来确定有多少人需要审查该代码，然后才能将其推送到生产环境中。”– Leinwand

它在实践中如何运作是，AI 工具将读取代码，确定其对整个代码库的影响，然后评估其风险级别。

“并且基于低、中、高 [风险]，我们有人工参与来确定有多少人需要审查该代码，然后才能将其推送到生产环境中，”他解释说。

虽然人类工程师仍然是 Webflow IT 部门的核心，但该公司正在使用 AI 代理(译者注：链接为英文网站)。Leinwand 指出，它已经在 Cursor 和 Augment Code 中启用了代理。但他小心地补充说，这些代理所承担的任务非常具体。他谈到让“一系列远程代理查看特定的代码行并开始做自己的工作”。

“我们还没有像你开始在行业中听到的那样拥有大量的代理群，”他继续说，“但我们绝对有能力获取一段代码，将其放入 Augment Code 中，并说：去处理这个特定的问题，然后回来 [...] 并告诉我最终结果。”

他说，代理通常会提出 PR 更改建议。然后，人类工程师会评估该建议，如果更改被接受，他们会“将其合并到他们的 diff 中，将该 diff 放入构建系统中并运行测试，并查看他们是否要将其推送到生产环境。”

Webflow 中的 MCP 用法

除了代理之外，模型上下文协议(MCP)(译者注：链接为英文网站) 可能是目前 AI 中最热门的话题。Webflow 正在内部使用 MCP，并将其作为客户产品的一部分。

“Webflow 作为产品提供了一个 MCP 服务器，与 Cloudflare 合作。因此，Cloudflare 托管并验证我们的 MCP 服务器，这使我们的客户可以使用 LLM 与他们的网站、他们的 CMS、他们的设计系统进行对话。”

在内部，Webflow 工程师使用 MCP 通过那些产品提供的 MCP 服务器与 Jira 和 GitHub 等产品进行对话。

MCP 是“工程内部工作流程的缝合线”。– Leinwand

“如果我在 Cursor 中并且在 Augment Code 中，我使用 MCP 与 Jira 对话，我使用 MCP 与 GitHub 对话，我使用 MCP 与我们代码库的各个部分对话。”

Leinwand 将内部 MCP 的使用描述为就像“工程内部工作流程的缝合线”。

AI 阻力

看起来 Webflow 的工程部门确实从 AI 中获得了很大的价值——但我们都知道 一部分开发人员反对 AI(译者注：链接为英文网站)。我问 Leinwand，对于那些典型的爱抱怨的传统工程师（在任何大型 IT 部门中总是至少有几个）来说，他们对 AI 工具包的反应是什么？

“我们面临的更大挑战之一是对 [AI] 的自然抵触，你知道，有点像‘谁动了我的奶酪’之类的事情，”他承认。

但根据其内部指标，现在大约 89% 的工程人员每天都在使用 AI 工具。

“这比我们在一季度看到的还要高出 17%，因此我们在采用功能和工具方面看到了相当不错的增长，”Leinwand 说。

他补充说，随着 AI 模型的不断发展，并且这些工具“变得更容易放入人们的工作流程中”，采用率也随之提高。

Webflow 平台中的 AI

我在本文开头提到，AI 似乎已集成到 Webflow 的整个平台中——其中包括设计工具、CMS、构建工具、托管、安全等等。该公司现在将自己描述为“网站体验平台”，并且主页声明 AI “嵌入在整个 Webflow 平台中”。

我问 Leinwand，其内部工程对 AI 的使用如何融入到它为客户提供的平台中？

“因此，我们的客户使用的产品在整个过程中都贯穿着 AI，”他回答说。“我们不将 AI 视为一项功能，而是将其视为贯穿整个产品的线索。”

“我们不将 AI 视为一项功能，而是将其视为贯穿整个 [Webflow] 产品的线索。”– Leinwand

举几个例子，他说他们提供了一个 AI 网站构建器——“你可以描述你希望你的网站看起来像什么，我们会为你生成网站上的页面”——并且你还可以使用 AI 在 CMS 产品中生成项目。

Webflow 最初在 2012 年只是一个简单的网站构建器，但现在它已经成为一个功能齐全的平台，拥有许多花哨的功能。最近添加的功能包括优化功能（例如，A/B 测试）和本地化。

“其中也有一些 AI，”Leinwand 补充说，关于优化。“因此，你可以使用 AI 自动生成着陆页、按钮或行动号召的各种变体。”

简而言之，AI 遍布 Webflow 的产品中。但根据 Leinwand 告诉我的情况，该公司还通过广泛地在内部使用 AI 工具来践行其所宣传的内容。