在我们关于 n8n 的 n8n 系列第一篇文章中，内部 AI 与自动化负责人 Romina da Costa 解释了服务台模式在哪里触到极限。她还分享了她的团队如今遵循的四条原则，用来帮助 n8n 的每个团队自行搭建并拥有自己的自动化。

自动化团队的成功该是什么样子？上线了多少工作流、关掉了多少工单、清空了多少积压？TLDR：这些其实都不是让自动化团队成功的关键。

每个集中式自动化团队都在解决一个真实的业务问题：把日常任务自动化、腾出时间，并承接那些其实不需要人来判断的工作。但恰恰是因为这件事做得太好，组织里其他人才会一直依赖你来继续解决，而不是把这种能力建进组织实际运转的方式里。你并没有消除瓶颈，你只是把瓶颈推到了下游。

这并不是 n8n 独有的错误，而且我根本不觉得这算是个错误。大多数组织，尤其是企业级组织，最终都会得出某种版本的同一个认识。你组建一个集中式自动化团队，清掉积压的活，把人从日常事务里解放出来。这些确实都管用，但只管用一阵子。之后你手里剩下的，是一个没人做过预算的问题：你刚建起来的这一切，到底由谁来维护？而解决了第一个问题的那支团队，能不能无限期地扛下第二个问题？

这背后还有一层更大的变化正在发生。搭建、工作流、智能体、内部工具，对非工程师的人来说正变得前所未有地容易上手。你可能会觉得，这让集中式自动化团队变得没那么必要了。我反倒认为，这让这份工作更重要了，只是变成了另一种工作。稀缺的技能不再是「你能不能把它做出来」，而是「这东西该不该做、你怎么知道它跑通了、哪个工具才真正合适、以及它出问题时归谁负责」。搭建变容易了，判断的分量反而更重了。它并没有让判断变得不再必要。

所以，以下才是我真正认为属于自动化团队该干的活，也是我来到这里头几个月一直在努力改变我团队对「成功」的定义的原因。

自动化团队一直在干活。但模型已经触到了它的天花板。

自动化团队早在我来之前就已组建，为的是解决一个真实存在的问题。n8n 旗下的各个团队当时都淹没在手工活里，而整个组织里没有谁能够横向拉通、系统性地解决这件事。于是公司招了工程师来搭工作流：把工具连起来、干掉重复性任务、把人解放出来去做更有价值的事。放在公司当时的处境下，这是正确的决定，团队也完全按着要求去做，而且做得相当出色。

今年早些时候我加入公司、接手这块职能时，发现这个团队自身的成功和公司的增长，已经悄悄把这个模式的天花板暴露了出来。我们手上有超过 12,000 条内部工作流，而没有任何一个团队，无论多强，能把这些全都搭起来并维护好。如果岗位描述还停留在「多搭自动化」上，那我就是在亲手运营那个挡在公司和我真正被招来推动的结果之间的东西。

这就是我想提醒任何接手类似岗位的人要警惕的陷阱。这不是上一支团队或上一代模型的失败，只是这项职能如果任其自然发展，最终就会走到这一步。这没什么问题，甚至可以说是意料之中。但到了某个节点，打断它就变成了负责 AI 与自动化的人的分内事——必须主动、刻意地在它走得太远之前出手。如果你真正想建的是一个高度自动化、AI 优先、能适应工作方式变化的组织，这一点就尤其成立。

换个说法：从搭建自动化，到培育自动化文化。

我一直在琢磨的问题不是「我们怎么搭建更多自动化？」，而是「我怎么建起一家公司，让每个团队都能像自动化工程师那样思考和行动？」这两个问题听起来差不多，但对我们怎么开展工作、以及这项工作实际长什么样，影响完全不同。

第一个问题下，成功看的是吞吐量。第二个问题下，成功看的是有多少团队最终不再需要我们。这几个月我一直在努力让第二个答案变成现实。这意味着要搞清楚真正赢得它需要付出什么：不只是改变我团队的工作方式，还要改变别人怎么看我们，以及其他团队一开始为什么会选择跟我们打交道。纸面上看这像是个小转变，但它几乎改变了我们一周里怎么花时间的一切。

落到实操上，这变成了四条原则。

1. 培养能造东西的人，而不只是造出东西

我们团队做的杠杆最高的事，不是这周交付的那个工作流。真正有价值的是赋能，让团队下次遇到类似问题时不再需要我们。这种赋能体现在几个不同层面。

从个人层面看，这更像是我的一个工程师这季度没有替某位业务方写自动化，而是坐在她旁边陪她调试自己写的那个：一起看为什么失败，告诉她该改哪里、为什么这么改。工作流两种方式最后都修好了。区别在于，下次她不用再找我们了。

在团队或部门层面，这看起来像是培训课、其他团队可以直接拿来起步而不是从零瞎搭的可复用工作流、有人带着真实问题来、我们陪着一起搭的答疑时间，以及一张技术骨干网络：每个部门一个人，他足够了解本团队的流程，能把它讲清楚，并且负责这个团队日常真正在用的那些工具。这些人不必是工程师。他们得是那种能告诉你某个流程为什么是这样运转的人，而这恰恰是更难找的能力。

每个部门配一个骨干，这只是个真实的起点，不是终点状态。它还有一层用处，超出了赋能本身：当某个部门还没有明显的骨干人选时，这本身就说明了问题，既告诉我们下一步该往哪儿使劲，也告诉我们实际该招什么样的人。老实说，目标比每个团队一个人要大。理想情况下，大多数人都能像自己职能的骨干那样行事。我们还没到那一步。但总得有个开始，每个部门有一个明确的负责人，是个合理的起点。

放到公司层面看，它就像我们正在搭建的 AI 熟练度框架这类东西：一套共享的标准，以及关于负责任地使用 AI 的通用判断基准，而且不依赖任何一个团队单独撑着。

从外面看，为别人做东西和跟别人一起做东西，看起来可能一模一样，尤其是如果你只数上线了多少个工作流的话。但这两者是完全不同的活儿。让我团队和我们的利益相关方真正理解这个区别，是我头几个月里的大部分工作。

2. 动手之前，先要一个基线

这件事源于我亲眼看着发生的一个错误。我们的一个 AI 智能体做出了一个确实亮眼的成果：一个月内管道里进了六位数的金额。当时看起来是稳赢，直到我问了那个真正关键的问题：跟什么比？

问题不在于我们手上没有可对比的东西。我们有人工 SDR 产出的真实数字。麻烦的地方在于，这个对比本身并不干净。智能体全天候运行、从不休息，而到那个时候，我们的人工 SDR 主要在处理那些更难的、已经升级上来的活儿，这些活儿是智能体先筛过一遍才落到他们手上的。拿智能体原始的管道数字去和人工 SDR 的数字硬碰，其实并不是同类相比，而要弄清楚一个公平的对比到底该长什么样，本身就得下真功夫。

从那以后，我就把这件事定成了团队的一条硬性要求。任何新的自动化项目启动之前，我们都会先问提出需求的团队：现在这项工作实际是什么样子——多久发生一次、要花多长时间、有多少人经手、目前产出什么，以及什么才算得上真正有意义的改进，哪怕他们的回答只是猜的。猜也比什么都没有强，而且光是问出这个问题，往往就是所有人第一次认真去想这件事。

3. 选工具要看问题需要什么，而不是你用得顺手的那个

一旦你真正搞清楚自己想改进什么，下一个问题就更容易回答了：这件事该用什么工具？我们不会为了做而做，而且很多时候，我们会倾向于选择买现成的，而不是自己造。这一点常常让人意外，毕竟我们就是 n8n。按一般经验，如果一个成熟、专门针对某个需求的工具已经在市场上存在一年以上，那通常比自己内部造更划算，而且理由不只是哪个方案当下更好用。自己造意味着要无限期地承担维护负担和安全面，而专门的厂商团队会按自己的路线图持续迭代，我们自己的 V1 却跟不上。用 SaaS 工具是有持续成本的；自己造只是把这项成本换成了另一种更不显眼的成本：我们自己团队的时间，用来做维护、保养和改进，只要这东西还存在就得一直做下去。真正的问题不只是哪个方案现在更好用，而是几年之后，我们到底愿意为什么东西负责维护和改进。

同样的原则也适用于 agent 与工作流之间的取舍。不是每个流程都需要把 LLM 放进循环里。我见过一些自动化需求落到我们团队头上，而实际任务从功能上说就是「把这封邮件转发给 James」，却被包装成了一个 agent，其实一个普通的邮件过滤器就能搞定，而且完全没有出错的可能。这种原则不是要避开 agent，而是拒绝为了图省事或追风口，去伸手拿一个 agent，而明明已经有更简单、更可预测的工具能解决这个问题。

4. 让我们做出来的东西具备韧性

我们团队上线的每一个工作流都是一份承诺，不是一次性的帮忙。它需要有负责人、有文档、有错误处理，还得想清楚一件事：当初搭它的人转去做别的了，后面该怎么办——因为这一天迟早会来。一个当时很聪明、半年后却没人看得懂的自动化，就成了负债。

这部分目前还只是设想。我们还没有一套全团队都遵循的统一文档标准，所以一个工程师写的笔记跟另一个人的完全对不上，而一旦有人要接手不属于自己的工作，这就是实打实的代价。我们正在做一份共享的文档模板，让每个工作流都对照它来衡量，目标是未来几周内落地。更难的部分不是写出这套标准，而是真正把它执行下去，确保每个工作流都按同一个标准来写文档，而不是只写那些有人碰巧挤出时间做的。

把我们的模型改造好，才能改造整个组织

我不想让我的团队变成一个服务台，一个接需求、按需交付产出的团队。我希望我们去解决对的问题，用对的方式。有时候这意味着亲手做点东西出来。有时候意味着教会一个团队自己去做。有时候则意味着告诉业务方，他们描述的问题其实还谈不上是自动化问题。

这就是目标。我们还没完全做到。实际干起来，我的团队还是更像一个服务台，比我期望的频率要高，而原因其实不在流程上。真正的原因是文化转变很慢，而且对一家快速变化的公司里的人来说，要挤出时间去学怎么自己搭建和负责自动化，确实很难。我的团队多说几次「不」，单靠这一点解决不了问题。这需要领导层和其他职能部门的真正认同：把 AI 熟练度纳入对人的评估方式，设定明确到每个职能怎么用 AI 和自动化的目标，并建立一种文化，让每个团队都预期自己要承担其中一部分，而不是只向我们提需求。这部分不是我一个人能解决的，但我正在跨部门推动它。

职责的转变

这些都不意味着，等所有人都能更轻松地搭建自动化之后，中央自动化团队就变得毫无意义。它改变的是我们介入的时机和原因。我的团队仍然应该负责那些复杂、有风险或全公司共担的问题，也就是那种你不想让十几个部门各用十几套不同办法去解决的问题。在其他地方，我们的工作是打好基础、定好标准、建立判断力，让其他团队在没有我们直接参与的情况下也能负责任地自行搭建。

让人人都有能力动手搭建，这件事正变得越来越简单。包括我们自家产品在内的每一款工具，都在以超出大多数人预期的速度让这一点成真。更难的那部分，也正是我们的岗位正在演变的方向，是打造这样一个组织：它清楚什么值得做、怎样把它做好，以及在做成之后如何把它管起来。

Romina da Costa 负责 n8n 的内部 AI 与自动化业务。自加入以来，她一直在重构这一职能，把它从一个负责搭建工作流的团队，转变为一台赋能引擎。