在“n8n 谈 n8n”系列的第一篇文章中，我们的内部 AI 与自动化负责人 Romina da Costa 解释了服务台模式在哪里触及极限。她还分享了她的团队如今遵循的四项原则，以帮助 n8n 的每个团队构建并拥有自己的自动化。
对自动化团队来说，成功是什么样子？上线的工作流数量、关闭的工单、清空的积压？TLDR：这些其实都不是让自动化团队成功的关键。
每个集中式自动化团队都在解决一个真实的业务问题：自动化日常任务、释放时间，并承接那些其实不需要人类判断的工作。但恰恰是因为解决得好，组织其他部分才会依赖你继续解决，而不是把这种能力内建到组织实际运作的方式中。你并没有消除瓶颈，你只是把它转移到了下游。
这并不是 n8n 独有的错误，我也不认为这真的算是个错误。大多数组织，尤其是在企业层面，最终都会以某种形式得出同样的认识。你建立一个集中式自动化团队，清空积压，把人从日常工作中解放出来。所有这些确实有效，能维持一段时间。但之后你手里留下的是一个没人做过预算的问题：究竟谁来维护你刚刚构建的这一切，以及解决第一个问题的团队能否无限期地承担第二个问题。
在这之下还发生着更大的转变。构建——工作流、智能体、内部工具——对非工程师来说正变得极其容易上手。你可能会以为这让中央自动化团队变得不那么必要。我认为这反而让这份工作更重要，只是变成了另一种工作。稀缺技能不再是“你能不能构建这个”，而是“这个该不该构建、你怎么知道它奏效了、哪个工具真正合适，以及它坏掉时谁来负责”。构建变得更容易，反而提高了判断力的重要性。它并没有消除对判断力的需求。
所以，以下是我真正认为自动化团队的职责所在，以及为什么我在入职的头几个月里一直试图改变我团队对成功的定义。
自动化团队当时运转良好。但这个模式已经触及天花板。
自动化团队是为了解决一个真实问题而建立的，早在我到来之前。n8n 的各团队当时淹没在手工工作中，而组织内没有人能足够协同地系统解决它。于是公司招聘工程师来构建工作流：连接工具、消除重复性任务、把人解放出来做更高价值的工作。对当时的公司处境来说，这是正确的决定，团队也完全按照要求去做了，而且做得非常出色。
今年早些时候我加入并领导这个职能时，我发现这个团队自身的成功和公司的增长已经悄然暴露出它所基于的模式的局限。我们有超过 12,000 个内部工作流，没有任何团队，无论多优秀，能够构建并维护所有这些。如果“构建更多自动化”仍然是岗位描述，那我就是在运营那个恰恰阻碍公司实现我真正被招来加速的目标的东西。
这就是我想提醒任何接手类似岗位的人的陷阱。这不是前任团队或前任模式的失败。这只是这个职能如果任其自然发展最终会走到的地方。这没关系，甚至在意料之中。但到了某个节点，领导 AI 与自动化的人就有责任介入，有意识地打断它，趁它还没走得太远。如果你真正想构建的是一个高度自动化、AI 优先、为工作方式变化做好准备的组织，这一点尤其重要。
重新定义：从构建自动化，到构建自动化文化。
我一直在思考的问题不是“我们如何构建更多自动化？”，而是“我如何打造一家每个团队都能像自动化工程师一样思考和行动的公司？”它们听起来相似，但对我们的工作方式以及工作本身的样子有着完全不同的影响。
在第一个问题下，成功看起来像吞吐量。在第二个问题下，成功看起来像有多少团队不再需要我们。我在最初这几个月里一直努力让第二个答案成为现实。这意味着弄清楚真正赢得它需要什么：不只是改变我的团队的工作方式，还要改变我们被看待的方式，以及其他团队一开始选择如何与我们互动。纸面上看这像是个小转变，但它几乎改变了我们如何度过每一周的一切。
在实践中，这转化为四项原则。
1. 培养构建者，而不只是构建
我的团队所做的杠杆率最高的工作，不是他们这周上线的工作流。而是那种赋能，让某个团队下次遇到类似事情时不再需要我们。这发生在几个不同层面。
在个人层面，它表现为我的一名工程师本季度花时间不是为某位利益相关者编写自动化，而是坐在她旁边，看她调试自己的自动化：回顾它为什么失败，向她展示该改什么以及为什么。无论哪种方式，工作流都修好了。区别在于，她下次不再需要我们。
在团队或部门层面，它表现为培训课程、其他团队可以拿来作为起点的可复用工作流（而不是盲目构建）、办公时间（人们带着真实问题来，我们一起构建），以及一个技术 champion 网络：每个部门有一个人，足够了解本团队的流程，能清楚地描述它们，并负责该团队日常实际使用的工具。他们不需要是工程师。他们需要是那个能告诉你某个流程 为什么 这样运作的人，而这恰恰是更难找到的技能。
每个部门有一名 champion 是一个真正的起点，而不是终点。它的用处还超越了赋能本身：当某个部门还没有明显的 champion 时，这本身就传递了信息，既告诉我们下一步该聚焦哪里，也告诉我们实际应该招聘什么样的人。诚实的目标比每个团队一个人更大。在理想世界里，大多数人都能像自己职能的 champion 一样行事。我们还没到那一步。但总得从某处开始，而每个部门有一个明确的负责人是一个合理的起点。
在公司层面，它看起来像我们正在创建的 AI 素养框架这样的努力：共享的标准，以及对负责任使用 AI 的共同判断基线，这些都不依赖任何单一团队来支撑。
从外部看，为某人构建和与某人一起构建可能看起来一模一样，尤其是如果你只统计上线的工作流数量。然而它们是截然不同的工作。让我的团队以及我们的利益相关者真正理解这一区别，占据了我最初这几个月的大部分工作。
2. 在构建之前先要求一个基线
这一条来自我实时目睹的一次错误。我们的一个 AI agent 产出了确实令人印象深刻的结果：一个月内六位数的销售管道。这看起来像是明显的胜利，直到我问了那个真正重要的问题。跟什么相比？
并不是我们没有可比较的对象。我们有关于人类 SDR 产出的真实数字。复杂之处在于比较本身并不干净。这个 agent 全天候运行、从不休息，而到那时，我们的人类 SDR 主要在处理 agent 已经为他们过滤掉的更难的升级工作。把 agent 的原始管道数字与人类 SDR 的数字直接对比，实际上并不是同类比较，而弄清楚公平的比较究竟该是什么样子，需要真正下功夫。
此后我把它定为团队的一条硬性要求。在任何新的自动化项目开始之前，我们会问提出请求的团队今天实际是什么样子：这项工作多久发生一次、需要多长时间、有多少人参与、目前产出什么，以及什么才算是有意义的改进，即使答案只是猜测。猜测仍然比什么都没有更有用，而提出这个问题往往是第一次有人真正思考它。
3. 为问题选择工具，而不是为你熟悉的工具
一旦你真正知道自己想改进什么，下一个问题就更容易回答了：什么才是适合这件事的工具？我们不为构建而构建，而且很多时候，我们会推动做出购买决策，而不是自己构建。这一点让人意外，因为我们就是 n8n。作为一般经验法则，如果市场上已经存在一个经过验证的特定工具一年或更久，通常比内部构建更好的选择，而且理由不止是哪个选项今天效果更好。自己构建意味着无限期承担维护负担和安全面，而专门的供应商团队会按照自己的路线图持续交付，而我们的 V1 却停止跟上。SaaS 工具带来持续成本；自己构建只是把它换成了另一种更不显眼的成本：我们自己团队的时间，用于维护、保养和改进，只要这个东西还存在。真正的问题不只是哪个选项现在效果更好。而是我们实际希望在未来多年里负责维护和改进什么。
同样的纪律也适用于 agent 与工作流之争。并非每个流程都需要 LLM 参与。我见过自动化请求落到我的团队，而实际任务在功能上就是“把这封邮件转发给 James”，却被包装成一个 agent，而一个普通的邮件过滤器就能完成这项工作，且零出错可能。这种纪律不是避免 agent。而是拒绝出于便利或炒作去伸手拿一个 agent，而一个更简单、更可预测的工具已经解决了问题。
4. 让我们构建的东西具有韧性
我的团队上线的每个工作流都是一项承诺，而不是一次性的帮忙。它需要负责人、文档、错误处理，以及一个计划：当构建它的人转去做别的事时该怎么办，因为最终他们会的。一个六个月后没人理解的巧妙自动化会变成负债。
这部分仍然只是愿景。我们还没有一个全团队遵循的统一文档标准，所以一个工程师的笔记和另一个人的完全不一样，而当有人不得不接手不属于自己的工作那天，这就是实实在在的成本。我们现在正在制定一个共享的文档模板，每个工作流都要对照它来衡量，我们的目标是在未来几周内落实到位。更难的部分不会是写标准。而是真正执行它，确保每个工作流都达到同样的标准，而不是只有那些有人碰巧挤出时间做的才达标。
转变我们的模式，以转变组织
我不希望我的团队成为一个服务台，一个接受请求并按需交付产出的团队。我希望我们以正确的方式解决正确的问题。有时这意味着构建某个东西。有时这意味着教一个团队自己构建它。有时这意味着告诉利益相关者，他们所描述的东西实际上还不是一个自动化问题。
这就是我们的目标。我们还没有完全做到。实际上，我的团队仍然比我期望的更频繁地像服务台一样运作，而原因其实并不在于流程。问题在于文化转变很慢，而且对于一家快速发展的公司里的员工来说，要抽出时间学习如何自行构建和负责自动化，确实很难。我的团队更频繁地说“不”本身并不能解决这个问题。这需要领导层和其他职能部门的真正支持：把 AI 素养纳入员工考核方式，设定明确各职能部门如何使用 AI 和自动化的目标，并建立一种文化，让每个团队都期望自己负责其中一部分，而不是只向我们提需求。这部分不是我一个人能解决的，但我正在跨部门推动影响它。
职责的转变
当构建对每个人来说都变得更容易时，这一切并不会让一个中央自动化团队变得毫无意义。它改变的是我们何时介入以及为何介入。我的团队仍然应该负责那些复杂、有风险或全公司共享的问题，也就是那种你不想让十几个部门用十几种不同方式去解决的问题。在其他方面，我们的工作是建立基础、标准和判断力，让其他团队在没有我们直接参与的情况下也能负责任地构建。
赋予人们构建能力正在成为容易的部分。每一个工具，包括我们的工具，都在以超出我们大多数人预期的速度让这一点成真。更难的部分，也是我们的工作正在演变的方向，是建立一个知道什么值得构建、如何构建得好，以及构建完成后如何负责的组织。
Romina da Costa 领导 n8n 的内部 AI 与自动化部门。自加入以来，她一直在将该职能从一个构建工作流的团队重组为一个赋能引擎。
与我们分享
n8n 用户来自各种不同的背景、经验水平和兴趣领域。我们一直希望在博客文章中介绍不同的用户及其项目。如果你正在使用 n8n 并愿意激励社区， 请联系我们 💌
分享