n8n 自动化团队为何要超越服务台模式

在我们的 n8n on n8n 系列的第一篇文章中，内部 AI 与自动化负责人 Romina da Costa 解释了服务台模式的局限所在。她还分享了团队如今遵循的四项原则，以帮助 n8n 的每个团队构建并掌控自己的自动化流程。

对于一个自动化团队来说，成功是什么样的？交付了多少工作流、关闭了多少工单、清空了多少待办事项？简而言之：这些都不是自动化团队成功的真正标准。

每个集中式自动化团队都在解决一个真实的业务问题：自动化日常任务、释放时间，并承担那些实际上不需要人类判断的工作。但恰恰是把这件事做好，才让组织的其他部门可以依赖你继续解决这类问题，而不是把这种能力真正融入组织的运作方式中。你并没有解决瓶颈，只是把瓶颈转移到了下游。

这并不是 n8n 独有的错误，而且我并不认为这真的算是一个错误。大多数组织，尤其是企业级组织，最终都会意识到类似的问题。你组建了一个集中式自动化团队，清理了待办事项，让人们摆脱了日常工作。这些做法确实有效，而且在一段时间内效果很好。但之后你会面对一个没人为之预留预算的问题：究竟由谁来维护你刚刚构建的一切，以及解决了第一个问题的团队是否能够无限期地承担第二个问题。

与此同时，底层还在发生更大的转变。构建流程、工作流、代理和内部工具，对于非工程师而言正变得极其容易。你可能会认为，这会让中央自动化团队变得不那么必要。但我认为，这反而让这项工作变得更加重要，只是工作内容发生了变化。稀缺技能不再是“你能不能构建它”，而是“是否应该构建它、你如何确认它有效、究竟哪种工具最合适，以及它出现故障时由谁负责”。构建变得更容易，提高了判断力的重要性，并没有消除对判断力的需求。

所以，下面是我对自动化团队真正职责的看法，也正因如此，我入职后的头几个月一直在努力改变团队衡量成功的方式。

自动化团队的运作是有效的。但这种模式已经触及上限。

早在我加入之前，自动化团队就已经被组建起来，用来妥善解决一个真实的问题。n8n 的各个团队被大量手工工作压得喘不过气来，而整个组织没有任何团队能够进行足够协同，从系统层面解决这个问题。因此，公司聘请工程师来构建工作流：连接工具、消除重复性任务，让人们腾出时间去做更高价值的工作。对于当时的公司状况而言，这是正确的决定；团队也确实完成了被要求完成的工作，而且完成得非常出色。

今年早些时候我加入并负责这一职能时，发现团队自身的成功以及公司的发展，已经悄然暴露出其既有模式的局限。我们内部大约有 12,000 多个工作流，无论团队多么优秀，都不可能构建并维护所有这些工作流。如果“构建更多自动化流程”仍然是职位描述，那么我领导的恰恰会是阻碍公司实现我受聘加速实现的目标的事物。

这是我想提醒任何接手类似我这样职位的人的陷阱。这并不是前任团队或前任模型的失败。如果任由这个职能自然发展，它最终走到这里是很正常的，甚至是意料之中的。不过，在某个时候，负责 AI 和自动化的人就有责任介入，在事情发展得太远之前有意识地打断这一进程。如果你真正想打造的是一个高度自动化、AI 优先、能够适应工作方式变化的组织，这一点尤其如此。

重新定义：从构建自动化转向建设自动化文化。

我一直在思考的问题并不是“我们该如何构建更多自动化？”而是“我该如何打造一家公司，让每个团队都能像自动化工程师一样思考和行动？”这两个问题听起来相似，但它们会对我们开展工作的方式，以及这项工作实际呈现的样子，产生完全不同的影响。

在第一个问题下，成功意味着吞吐量。在第二个问题下，成功体现为有多少团队最终完全不再需要我们。我在最初的这几个月里一直努力让第二种答案成为现实。这意味着要弄清楚究竟需要付出什么才能实现这一目标：不仅要改变我的团队开展工作的方式，还要改变别人对我们的看法，以及其他团队最初选择如何与我们互动。这在纸面上听起来只是一个小小的转变，但它几乎改变了我们如何度过某一周的全部方式。

实际上，这最终归结为四项原则。

1. 培养构建者，而不只是交付成果

我团队所做的、杠杆效应最高的工作，并不是他们本周交付的工作流，而是让某个团队下次遇到类似情况时不再需要我们的赋能工作。这会发生在几个不同层面。

在个人层面，这意味着我的一名工程师本季度花时间做的，不是替某位利益相关者编写自动化，而是陪着她调试自己编写的自动化：一起检查它为什么失败，向她展示应该改什么以及为什么要这样改。无论如何，工作流都得到了修复。区别在于，她下次不需要我们了。

在团队或部门层面，这意味着开展培训课程，提供其他团队可以直接起步使用的可复用工作流，而不是让他们在毫无头绪的情况下从头构建；设立办公时间，让人们带着真实问题来，我们与他们一起构建；以及建立技术骨干网络：每个部门安排一名人员，充分了解其团队的流程，能够清晰地描述这些流程，并负责该团队日常实际使用的工具。他们不需要是工程师。他们需要成为那个能告诉你某个流程为什么会以这种方式运作的人，而事实证明，这是一项更难找到的技能。

每个部门安排一名骨干是真正的起点，而不是最终状态。它的价值也不止于赋能：当一个部门还没有明确的骨干时，这会向我们传达一些信息，既告诉我们下一步该把重点放在哪里，也告诉我们究竟应该招聘什么样的人。坦率地说，我们的目标比每个团队安排一名人员更大。在理想情况下，大多数人都应当能够成为自己职能领域的骨干。我们还没有达到这个程度。但我们必须从某处开始，而每个部门指定一名明确的负责人，是一个合理的起点。

在公司层面，这意味着开展类似我们正在创建的 AI 素养框架这样的工作：建立共享标准和共同的判断基线，用于负责任地使用 AI，而且这些标准和基线不依赖任何单个团队来维持。

从外部看，为某人构建和与某人一起构建可能看起来完全相同，尤其是如果你统计的只有已交付的工作流数量。然而，它们是完全不同的工作。让我的团队和利益相关者真正理解这一差异，是我在最初几个月里大部分时间所做的工作。

2. 在开始构建之前，要求先建立基线

这一点源于我亲眼目睹的一次错误。我们的一个 AI 代理生成了一个确实令人印象深刻的结果：一个月内为销售管道带来了六位数的金额。在我问出那个真正重要的问题之前，这看起来显然是一次胜利。和什么相比？

并不是说我们没有可供比较的数据。我们有关于人工 SDR 产出情况的真实数据。复杂之处在于，这种比较本身并不公平。代理全天候运行，从不休息，而当时我们的人工 SDR 主要负责处理那些代理已经替他们筛选出来的、更困难、更需要升级处理的工作。把代理的原始销售管道数字与人工 SDR 的数字直接比较，实际上并不是在比较同类对象；而要弄清楚公平的比较究竟应该是什么样子，也需要付出实际的工作。

从那以后，我把这定为团队的一项硬性要求。在任何新的自动化项目开始之前，我们都会询问提出请求的团队：目前的实际情况是什么——这项工作多久发生一次、需要多长时间、会有多少人参与、目前能产生什么结果，以及什么才算得上有意义的改进，即使这些答案只能是猜测。猜测仍然比什么都没有更有用，而提出这个问题往往是大家第一次真正思考这件事。

3. 根据问题选择工具，而不是选择你熟悉的工具

一旦你真正知道想要改进什么，接下来的问题就更容易回答了：什么工具才适合解决这个问题？我们不会为了构建而构建，而且很多时候，我们会推动购买现成方案，而不是自己构建。考虑到我们是 n8n，这一点往往会让人感到意外。一般来说，如果市场上已经存在某个经过验证的专用工具，并且已有一年或更长时间，那么相比内部构建，它通常是更好的选择；其中的理由不只是看今天哪个选项效果更好。自己构建意味着要无限期地承担维护负担和安全风险面，而专门的供应商团队会继续根据自己的路线图交付新功能；与此同时，我们的 V1 会逐渐跟不上。SaaS 工具会带来持续成本；自己构建只是把这项成本换成了另一种不那么显眼的成本：只要这个东西存在，我们自己的团队就要持续投入时间进行维护、保养和改进。真正的问题不只是哪个选项现在效果更好，而是多年以后，我们真正希望负责维护和改进什么。

同样的原则也适用于代理和工作流。并不是每个流程都需要让 LLM 参与其中。我见过一些自动化请求交到我的团队手上，但实际任务从功能上说只是“把这封邮件转发给 James”，却被包装成了一个代理；而普通的邮件过滤器就能完成这项工作，并且完全没有出错的可能。这种原则并不是要避免使用代理，而是当一个更简单、更可预测的工具已经能够解决问题时，拒绝因为方便或炒作而顺手使用代理。

4. 让我们构建的东西具备韧性

我们团队交付的每个工作流都是一项承诺，而不是一次性的帮忙。它需要负责人、文档、错误处理机制，以及一套应对构建者转而负责其他事务的方案，因为这件事最终一定会发生。一个六个月后没人理解的聪明自动化方案，会变成一项负担。

这一部分目前仍停留在愿景层面。我们还没有一套全团队统一遵循的文档标准，因此一名工程师的笔记可能与另一名工程师的完全不同，而当有人不得不接手并非自己负责的工作时，这会带来真实的成本。我们现在正在制定共享文档模板，让每个工作流都按照同一套标准接受衡量，并计划在未来几周内落实。更难的部分不会是编写标准，而是真正执行标准，确保每个工作流都按照相同的要求完成文档，而不是只有那些恰好有人抽出时间处理的工作流才有文档。

转变我们的模型，以转变组织

我不希望我的团队成为服务台，成为一个接收请求并按需交付成果的团队。我希望我们解决正确的问题，并采用正确的方式。有时，这意味着构建某些东西。有时，这意味着教会一个团队自行构建。有时，这意味着告诉利益相关者，他们描述的问题实际上还不是一个自动化问题。

这就是我们的目标。我们还没有完全做到。在实践中，我的团队仍然比我希望的更常充当服务台，而原因其实并不在流程。问题在于，文化转变需要时间，而且对于一家快速发展的公司来说，让各个团队抽出时间学习如何自行构建和负责自动化，确实很难。仅仅让我的团队更经常地说“不”，并不能自行解决这个问题。这需要领导层和其他职能部门真正支持：将 AI 素养纳入人员评估方式，制定明确说明各职能部门如何使用 AI 和自动化的目标，并建立一种文化，让每个团队都期待自己负责其中一部分，而不是只向我们提出请求。这部分不是我一个人能够解决的，但我正在跨职能地推动和影响这件事。

职责范围的转变

一旦每个人都更容易进行构建，这并不意味着中央自动化团队就失去了意义。它改变的是我们何时介入，以及为何介入。我的团队仍应负责那些复杂、有风险或涉及整个公司的问题，也就是你不希望十几个部门用十几种不同方式分别解决的问题。在其他地方，我们的职责是构建基础、标准和判断力，让其他团队能够在没有我们直接介入的情况下负责任地进行构建。

赋予人们构建能力正逐渐成为容易的部分。每一种工具，包括我们的工具，都在以超出大多数人预期的速度推动这一点实现。更难的部分，也是我们的工作正在转向的方向，是构建一个知道什么值得构建、如何高质量地构建，以及构建完成后如何负责的组织。

Romina da Costa 负责 n8n 的内部 AI 与自动化工作。加入公司后，她一直在将该职能从工作流构建团队重组为赋能引擎。