# 团队 AI 提效需要工程化的创作者

上一篇文章最后提到：AI 让个人更容易产出东西，不等于个人真正变强，而即使个人真的变强了也不一定能让团队变强。组织提效不能从“每个人都用 AI”开始（尤其是不能搞token消耗排名），而要反过来倒推。先弄清楚组织到底需要什么结果，再看支撑这个结果的流程、数据和权限，最后才轮到个人应该怎么配合这些明确的任务。

那么我们需要什么样的人来把这件事做成呢？我姑且给他们命名为“工程化的创作者”。

这听起来有点像在给程序员找一个新的名字，但它其实指向一个更宽泛的角色。工程化的创作者不一定有程序员头衔，也不一定每天写很多代码。他的核心能力是把一个真实业务目标变成可运行并且能被验证和复用的工作流。谁能把 AI 从个人工具变成团队流程的一部分，谁就拿到了组织 AI 提效的门票。

## 编码门槛下降以后，工程化会更重要

写代码几乎是程序员的最显性工作内容，而且过去很长时间里，它是进入数字世界的主要门槛。但程序员在现实系统里承担的工作，从来不只是把代码写出来。一个系统要长期运行，需要有人理解目标，拆解状态，处理异常，并且在出问题时知道怎么恢复。AI 会让写代码变得更便捷，但不会让这些工程化责任消失。相反，当更多人能写出“看起来能跑”的东西以后，真正稀缺的会变成让它长期跑下去的能力。

这件事并不新鲜。移动互联网兴起的年代我在团队内率先用 Python 代替 C++ 写网站后台时，就有过类似感受。C++ 的字符串处理、内存管理和展开后让编译器爆炸的模板，对很多上层业务开发来说是一道很高的门槛。Python和PHP等抽象程度更高的编程语言把门槛降了下来，更多人可以更快地写业务逻辑，也能把注意力放到产品和流程上。值得一提的是，当时也流传着“以后每个人都可以做自己的App”的都市传说。

但门槛下降以后，工程化问题没有消失。上层逻辑变复杂了，过去被语言门槛挡住的问题，开始转移到架构、协作、测试和长期维护上。会写代码的人变多了，真正能把系统维护好的人反而更重要了。

AI 现在带来的变化也很像是这样，它让更多人有机会越过编码门槛。产品经理可以写脚本，运营同学可以搭小工具，销售团队也可以让 AI 整理线索和生成摘要。这当然是新一轮的“技术平权”的美好叙事。但问题是，只要进入真实场景阻力很快就会出现。数据要稳定可取，权限要收得住，结果要能验证，失败后还要恢复，成本也不能失控，这些要求都会把问题重新拉回工程化能力上。

所以具备良好工程素养的程序员不会因为”写代码变得更简单“就失去价值，被削弱的是仅靠语法糖和吃苦耐劳搬砖而存活的“力工型”程序员。同样的，虽然”每个人都可以做自己的App“并没有实现，但也有很多非程序员逐渐掌握了工程化的能力，把自己在特定领域的丰富经验和深刻洞察以产品的方式复制到更多用户。

## 工程化的创作者把AI封装成系统给更多人使用

前面的文章我提过绝大多数人并不会需要OpenClaw这样的通用Agent，即使是在它描绘了一个极其美好的愿景的情况下，人们还是会逐渐离开，继续保持应用消费者的状态。

放到团队里也是一样，团队不需要也很难指望每个成员都变成工程化的创作者。大多数人更合理的位置，是使用被团队包装好的 AI 工作流。他们看到的是问题分流和建议回复这类业务界面，而不是背后的模型选择、上下文管理和调用成本。

这并不会降低普通成员的重要性。一个好的团队系统应该让人把注意力放回自己的判断和业务责任上，而不是把每个人都训练成小型系统管理员。组织如果要求所有人直接操作 AI，最后很容易得到一堆互不相通的个人工具。看起来每个人都很先进，团队却很难吸收这些成果。

团队需要的是少数人承担这部分复杂性。他们不一定是程序员出身，但他们把 AI 能力包装成流程，把不稳定的个人技巧变成可复用的团队能力。普通成员使用这个流程，工程化的创作者维护这个流程，组织才有机会获得稳定的 AI 提效。

组织目标通常不会天然变成系统。它一开始往往是一句业务语言：比如提高客服效率或提高销售转化。这些无法直接被 AI 理解，所谓工程化工作，就是把业务目标压进一个可运行的闭环。以客服系统为例，工程化的创作者会把这件事设计成一个流程：用户问题进入系统后，AI 先做分类和摘要，再根据已有知识给出建议；客服在关键位置确认或修正，无法处理的问题进入升级队列，最后处理结果重新沉淀进知识库。这段流程里，AI 不是一个坐在旁边的“新同事”，它更像系统里的一个高效率节点。

这就是工程化创作者和普通 AI 重度用户的区别。普通用户更关心这次生成得好不好，工程化创作者更关心同样的能力下次是否还能稳定发生。前者追求一次产出，后者设计一个可持续的工作系统。

## 团队提效具体动作要从已被认可的流程开始

团队从核心目标出发去寻找最重要的业务流程，这些被团队认可的流程适合作为具体AI提效动作的起点。AI 介入以后，验收是直接而具体的：速度、错误、状态、返工和成本，都会回到团队共同关心的结果上。

这也是为什么我更相信渐近优化，而不是一上来就用 AI 重构组织。上一篇提到过，用 AI 直接重构组织，是用设计论对抗进化论，简单来说，从目的上看进化论一般很难获得最好的结果，但它也一般不容易陷入最差的结果。保守且务实一点来看，工程化的创作者先在一个局部流程里建立闭环，把触发方式、决策点、确认边界和数据流跑顺。等团队真的吸收了，再扩大 AI 的权限或连接新的流程。一个 loop 跑稳，再接下一个 loop；多个小 loop 连接起来，才可能形成更大的智能系统。

从 human in the loop 到 human on the loop，人在一开始需要逐项确认，后来开始监督系统运行，再后来把更多现实信息映射回系统，并决定权限继续让渡给 AI 的节奏。这个过程比AGI叙事枯燥得多，但它更接近现阶段可落地的团队 AI 提效。

顺便说一下，只有当 AI 进入团队工作流以后，现在企业经营者所关注的“token成本治理”才有可能（这个话题也可以开个系列专栏来讲，本文只做简单陈述）。一次模型调用属于哪个流程，服务什么目标，减少了多少人工处理，带来了多少返工或误判，都可以和流程结果放在一起审查。它用得好不好，应该如何选择合适成本的模型，都是回到系统的输出结果来评判。

这也是工程化的意义。AI 一旦成为系统中的一部分，它就不再只是一个神奇工具，而是一个有成本和边界，也留下日志并对应产出的生产环节。它可以被优化，也可以被替换；可以扩大使用，也可以在某些环节被收回。组织终于能像管理其他生产系统一样管理 AI，而不是靠一堆个人经验和感受来反复折腾。

## 如何成为工程化的创作者

所以，团队 AI 提效的关键，在于组织里出现足够多工程化的创作者，而不是让每个人都变成 AI 专家。而且，工程化的创作者不一定是来自于程序员背景，一部分人会从非程序员群体里长出来。他们大多可能是原来业务领域的专家，同时有良好的动手意愿，AI 降低了技术表达的门槛以后，他们开始学会把问题和流程变成结构化的可复用流程。程序员背景的成员也有很大的优势，他们本身已经具备了良好的工程化经验，通过FDE的方式去理解业务，是从另外一个方向变成工程化的创作者。工程化的创作者能创造新的工作方式，也有能力让这种工作方式稳定运行，AI在这里面发挥了最适合它的部分，它让有意愿的团队成员可以迸发出以前无法想象的力量。

这类人会成为团队最重要的财富。因为他们真正解决的，是团队持续吸收 AI 能力这件事。一个人用 AI 做出东西，仍然可能只是产出物幻觉；团队能稳定吸收这些能力，才会变成组织能力。