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

团队想靠 AI 提效，迟早会落到一个很具体的问题上：谁来把这件事做成。

让每个人都装一个 Agent，听起来很热闹，但很快会变成各自为战。有人用它写周报，有人用它跑数据，有人让它整理客户摘要。个人体验可能都不错，团队层面却很难复用，也很难治理成本。

组织需要的是一类工程化的创作者。

这个词不一定对应一个固定岗位。它描述的是一种能力结构：懂业务目标，能拆工作流，愿意处理权限、数据、异常、成本和维护这些麻烦事，还能把 AI 能力包装成团队成员愿意长期使用的工具。

第三篇里讲到，个人变强只是材料。工程化创作者要做的，就是把这些材料做成团队能吸收的东西。

## 普通用户不必懂工程，团队里必须有人懂

对普通用户来说，AI 最好的形态应该是轻的。写邮件、查资料、整理账单、规划旅行，这些任务不值得用户先理解 API key、token、权限边界和日志。

团队生产不是这样。

只要 AI 进入实际业务，它马上会碰到一堆不体面的细节。数据从哪里来，字段含义谁确认，模型输出错了谁发现，自动动作要不要人工确认，任务失败后怎么恢复，成本算到哪个项目里。

没有人处理这些细节，AI 就会停在个人桌面上。它可以帮某个人写得更快、想得更多，但很难变成组织能力。

这也是程序员不会简单消失的原因。AI 会写代码，甚至会写得越来越好。但实际工作里，代码只是其中一段。服务要能跑，配置要能查，数据要能追溯，权限不能乱放。出了事故以后，团队还得知道从哪里回滚、从哪里补偿。

AI 把写代码这件事变便宜以后，工程化反而更贵了。

## 编码门槛下降后，脏活会浮上来

我大概十五年前用 Python 代替 C++ 写网站后台时，有过类似感受。

C++ 很强，但对很多上层业务开发来说，字符串处理、内存管理和各种底层细节会消耗大量注意力。Python 把这些门槛降下来以后，更多人可以直接写业务逻辑。那种感觉很爽，像是突然少背了一个很重的包。

但问题没有消失，只是换了位置。

业务状态变多了，接口变多了，异常路径变多了。过去被语言门槛挡住的人进来了，系统规模也跟着长大。于是测试、部署、监控、数据一致性、团队协作这些事变得更重要。会写代码的人变多了，能把系统长期维护好的人反而更稀缺。

AI 现在也在做类似的事。

它让产品经理能写脚本，让运营能搭小工具，让销售能批量整理线索。这些变化很好。但工具一旦被团队使用，问题会立刻从“能不能生成”变成“能不能长期跑”。

一个销售线索摘要脚本，刚开始只要能把客户聊天记录总结出来就很有用。过一段时间，团队会问更多问题：哪些聊天记录能读，哪些不能读；客户要求删除数据时怎么办；模型把客户预算理解错了，谁来发现；摘要写回 CRM 以后，原始记录还保不保留；月底成本为什么突然涨了。

这些问题没有任何一个靠更会写 prompt 就能解决。

## 工程化创作者会从两边长出来

一边是业务里长出来的人。

他们原本更靠近客户、运营和流程，知道哪里最麻烦，也知道哪些动作每天都在重复。AI 降低了技术表达门槛后，这些人开始学会把问题拆成步骤，把经验写成规则，把重复动作沉淀成小工具。

他们未必每天写很多代码，但会开始关心数据结构、权限边界、异常处理和成本。

另一边是程序员往业务前端走。

过去很多程序员主要面对需求文档和代码仓库。AI 让实现层变便宜以后，只停在“把需求翻译成代码”会越来越被动。更有价值的位置，是直接理解一线流程，判断哪些工作值得自动化，哪些数据还没有进入系统，哪些权限设计会在三个月后变成坑。

这两类人会在同一个地方汇合：既能创造新的工作方式，也能让它跑得住。

只会提想法不够，只会写代码也不够。团队需要的是能把想法、工具和责任绑在一起的人。

## 从已经被认可的流程开始

团队 AI 提效最好别从“大家都去学提示词”开始，也别从“给每个人配一个 Agent”开始。

更稳的做法，是找一个团队已经认可的核心工作流。

所谓认可，指的是它已经和结果绑定，有人愿意为它负责。客服工单分流、销售线索跟进、研发 issue triage、财务异常复核，都属于这类工作。它们不一定优雅，但结果可以看，责任也能找。

工程化创作者可以沿着这个流程往下拆：

1. 输入是什么，来自哪里。
2. 哪些判断过去靠人脑经验完成。
3. AI 先给建议，还是可以直接执行。
4. 哪些步骤必须有人确认。
5. 结果写回哪里，失败后谁来处理。
6. 成本怎么记账，收益怎么验证。

这个列表看起来很土，但它比“我们要全面拥抱 AI”有用得多。

拿客服分流举例，第一步未必是让 AI 直接回复用户。更可能是先让它判断问题类型，给出相似历史工单，并提示是否需要升级到人工。跑一段时间以后，看分流准确率、升级次数、用户二次咨询比例和人工修改记录。确认这段稳定，再让它处理更靠后的动作。

一步一步扩大边界，比一次性重构组织更慢，也更不容易翻车。

## 大部分成员只需要用结果

组织讨论 AI 时，常常默认每个成员都要直接操作模型。这个假设可以放一放。

很多成员会像普通用户一样，使用被包装好的工作流。客服看到的是建议回复和升级按钮，销售看到的是线索状态和下一步动作，财务看到的是异常提醒和待确认事项。他们不用知道背后调用了哪个模型，也不用自己管理 token。

这样反而更健康。

个人式 AI 使用很难治理。一个人说自己省了两个小时，另一个人说自己多写了三份报告，管理者很难判断价值，也很难解释成本。

工程化工作流里的 AI 调用更容易算账。这个流程每月调用多少次模型，花了多少钱，减少了多少人工复核，错分率有没有下降，返工有没有变少，都可以放在一起看。

这时 AI 才从个人技巧变成管理对象。

## 企业最该珍惜这种复合能力

工程化创作者不会只坐在研发部门。

他可能是一个懂数据的运营，也可能是一个愿意跑客户现场的程序员，或者是一个能把销售流程拆清楚的产品经理。共同点是：他们能把业务语言翻译成系统语言，也能把 AI 能力包装成别人不用理解底层就能使用的工作方式。

这类人要同时具备几种能力：业务理解，工程意识，产品判断，数据治理，对 AI 边界的手感。

听起来要求很高。确实很高。

但团队 AI 提效本来就不是装几个工具的问题。它要求有人把目标、工作流、数据和责任重新接起来。没有这样的人，个人用 AI 再熟练，也只是桌面上的局部繁荣。

下一篇谈未来 AI 人才时，核心也会落回这里：最值得培养的未必是更会写 prompt 的人，而是能把具体问题做成可运行智能系统的人。