搭一个 AI 员工，不用写代码：怎么让全公司都能参与

我见过太多公司卡在同一个地方：AI 项目永远是 IT 部门的事，业务部门只会提需求，等排期，再等上线。结果一个 Agent 从提需求到用上，走了三个月。

但有一家 1100 人的公司，一个月内让非技术员工自己搭出了 50 多个 Agent——财务、市场、运营，没有一个人是软件工程师。他们不是招了一批程序员，而是把「搭 Agent」这件事，从「写代码」降级成了「填配置 + 说清楚要它干什么」。

这件事对货代、对中小企业，比任何大厂案例都值得抄。因为你们没有专门的 AI 团队，更缺不起三个月的排期。

一、搭 Agent 不是写程序，是写岗位职责

很多老板一听「让业务自己搭 Agent」就摇头：他们又不会写代码。

问题就出在这个想法上。搭 Agent 根本不需要写代码。一个 Agent 是什么？说白了就是三样东西：

• 一段提示词：告诉它「你是谁、要干什么、按什么规矩办事」
• 一份配置：告诉它「能用哪些工具、能碰哪些数据、什么时候干活」
• 一套运行时：平台负责让它在云端跑起来，不用你管服务器

前两样是业务的事，只有最后一样是技术的事，而且现在平台都帮你兜底了。

打个比方：你让一个新来的业务员干活，不需要教他编程，只需要告诉他岗位职责、给他开系统权限、把公司的规矩讲清楚。搭 Agent 一模一样——你在写一份给 AI 的岗位说明书。

二、为什么是「全员参与」，不是「IT 代劳」

有人会问：那让 IT 部门搭不就行了？为什么非要业务自己来？

因为只有干活的人才知道活怎么干。财务知道对账的坑在哪，运营知道催单的节点在哪，业务知道客户哪些话是客套、哪些是真需求。你让 IT 去问，问三遍也问不出那些藏在日常里的细节。

更实际的是速度。需求经过「业务 → IT → 排期 → 开发 → 测试」这条链路，一个 Agent 少说一个月。而业务自己搭，从描述需求到跑起来，可能就一两个小时。

全员参与还有一层好处：Agent 的维护有人管了。谁搭的谁知道它该干什么，出了偏差自己就能改，不用每次都找 IT 救火。

三、让全员都能参与，需要三个前提

光喊「大家都来搭」没用，得把条件备齐。我从实战里总结了三件事：

第一，把模板准备好。 别让大家从白纸开始。给两套现成模板：一套给「事件来了就干活」的 Agent（比如新订单到了就自动查舱），一套给「到点就干活」的 Agent（比如每天早上自动汇总船期）。业务员复制模板、改改提示词，就是自己的 Agent 了。

第二，先让种子用户跑通。 别指望全员一起学会。先从每个部门挑一两个最愿意折腾的人，让他们搭出真能用的东西，回去教本部门的人。有活生生的例子在，比任何培训都管用。

第三，把「评审」变成习惯。 大家自己搭没问题，但改动要有人看、要留记录。不是卡流程，是保护大家——Agent 接进真实业务后，改坏了得有办法回退。

四、门槛在「敢不敢」，不在「会不会」

说到底，让全员参与最难的不是工具，是心理门槛。很多人一听说「配置」「提示词」就觉得自己不行，一听说「git」「版本」就想退回去。

所以真正要紧的是把话说清楚：你不需要成为程序员，你只需要成为这个岗位最熟的人。工具再难也是人做的，业务的门道只有你知道。

先把「搭 Agent = 写岗位说明书」这个观念传出去，再谈模板、种子用户和评审。观念对了，后面都是水到渠成。

五、适用边界

这套打法的前提是：你的业务里已经有值得自动化的重复活，而且你愿意花一两周让种子用户先跑起来。如果公司连最基础的重复工作都没梳理过，先别急着全员铺开，先让一个人把第一个 Agent 跑通。

我还没看到完整答案的问题是：全员参与铺开后，Agent 的质量谁来把关、会不会出现一批没人维护的「僵尸 Agent」。目前我的答案是靠「每个 Agent 有名字、有 owner、只干一件事」这个纪律兜底，但样本还不够。

继续读：怎么像有开发团队一样去提需求、去建设 Agent？；生产环境稳定运行的 Agent，怎么通过 PR 把历史版本维护好？；先给 Agent 定岗再谈其他，见给 AI 定岗：先写岗位说明书。