去年这个时候，有两家合肥企业几乎同时找到我们，想做办公智能体。

两家规模接近，都是百人左右；预算接近，都在十几万的量级；需求也接近，都想把内部那些重复的表格和问答先理顺。说起来就像一对双胞胎。

一年过去，结果却像两家人：一家现在有七个场景在跑，员工主动提需求；另一家上线三个月后就没人用了，系统还挂着，成了个摆设。

价格一样，技术方案也差不太多，差距从哪来的？我把这中间的过程拆开复盘，发现至少分岔了五次。每一次，都不是技术选择，而是管理选择。

第一次分岔：第一件事做哪个

A公司的老板姓陈，第一次沟通时他讲了四十多分钟，讲的全是"客服部每天要翻三个系统查设备记录，一通电话平均要等两分钟"。他没有讲"AI很酷"，只讲了一件每天都在发生的麻烦事。

B公司的林总也很热情，但他想做的第一件事是——做一个"企业AI门户"，员工打开就能对话，看起来很像未来。功能很全，画面很炫，就是没有一个具体的痛点指向它。

结果：A公司第一版上线，客服部当场就用起来了，因为痛点在哪、谁在用、省了多少，全都清清楚楚。B公司的门户做得很漂亮，上线之后员工点开看了两次，发现"没什么非用它不可的理由"，慢慢就没人打开了。

这一岔的教训：办公智能体的第一个场景，应该是"最痛的那件事"，不是"最能展示的那件事"。展示价值给外人看，落地价值给人用——两件事最好分开。

第二次分岔：谁来出人整理资料

知识库是智能体的原料，这件事谁都知道。但知道不等于有人干。

A公司做了什么？陈总指定了行政主管牵头，拉上各部门对接人，用三周时间把制度、手册、常见问题文档集中起来，还专门开会讨论了"同一个问题如果说法不一致，以哪份为准"。中间挺折腾。

B公司呢？林总说"资料都在员工电脑里，你们自己去收集吧"。开发团队挨个部门要文件，很多同事并不配合——"我凭什么要把我的资料交出去"。最后收上来的资料，版本老旧、互相矛盾，知识库一开工就是先天不足。

这一岔的教训：知识库建设不是技术活，是组织活。企业出一个牵头人，比开发方多派两个工程师有用得多。凡是资料准备阶段"甩给供应商"的企业，后面基本都要返工。

第三次分岔：试点的范围铺多大

A公司的做法偏保守：只在客服部试点，两个月。其他部门想用？排队。

B公司的做法很"大气"：第一天就全公司开通，所有部门都能用。

看上去B公司更先进，实际上这正是它失败的伏笔。全公司铺开意味着：一句话要同时满足财务、销售、行政的所有期待；出了问题无法定位是哪个场景的锅；反馈太多太杂，开发团队疲于奔命，哪个都没做好。

而A公司只盯一个部门，客服的每一条反馈都很具体——"这句话答错了""这里应该先问订单号"。两个月后，客服场景的准确率从六成爬到了八成五。有了一个成功的样板，再推广到第二个部门时，说服成本几乎为零。

这一岔的教训：智能体项目里，"少即是多"不是口号，是纪律。范围小，反馈才能精准；反馈精准，迭代才能有效。

第四次分岔：上线第三周怎么评价它

这是最关键，也最容易被忽略的一岔。

两家的智能体都在第三周遇到了同样的情况——效果看起来一般：有些问题答不准，员工还是习惯问人，有人开始说"这东西还不如不用"。

B公司的林总在这时做了个决定：把项目暂停，重新评估。他是这样说的："效果不明显，说明这条路可能不对。"

A公司的陈总也动摇过，但他换了个角度。他把客服主管叫来问了一句："这一个星期，比上星期少打了几个找人问的电话？"客服主管翻了记录，说少了一百多个。

陈总说："那就继续弄，把答不准的那些先挑出来，一个个改。"

这一岔的教训：智能体的成长曲线不是直线的，通常是先平后陡。前几周的"平庸感"是必经阶段，判断标准不该是"它现在好不好用"，而是"它比上周好了一点吗"。用第一印象下结论的企业，会在爬坡前就把项目砍掉。

第五次分岔：上线之后谁来管它

A公司在项目接近尾声时，做了件很多企业不做的事：把客服主管指定为"智能体的日常责任人"，每周看一下答错的问题，把新出现的场景补进知识库。

B公司没有这个安排。系统交付完，开发团队撤场，企业内部没人觉得"这事归我管"。答错的问题没人反馈，新政策上线系统不知道，慢慢地，员工发现"问它还不如问同事"，于是彻底弃用。

这一岔的教训：智能体不是一次性的交付物，是需要养护的工具。交付完成只是开始，企业内部必须有人接手"喂养"它——这个角色不需要懂技术，只需要懂业务、肯较真。而这件事，从一开始就该写进项目计划里。

一年之后，两家企业的样子

A公司现在有七个场景在跑：客服问答、会议纪要、新人答疑、报销初审、数据汇总……而最让陈总意外的是，需求大半不是他提的，是员工自己提的——"能不能让它顺便把这个也做了？"

B公司的那套系统还在服务器上，偶尔有人点开，很快又关掉。

同样十几万的投入，一个变成了全员依赖的工具，一个变成了沉默的成本。

五次分岔背后，其实是同一个问题

把五次分岔叠在一起看，你会发现它们指向同一条分岔线：

企业到底把智能体当成一个"项目"来验收，还是当成一个"能力"来养成？

当成项目，就会追求"上线即完工"：范围铺得越全越好、效果要求立竿见影、交付完就撒手。这条路，几乎注定走向闲置。

当成能力，就会容忍它先平庸、再变好：从小范围切入、留出爬坡时间、安排人持续养护。这条路，慢，但走得到终点。

好牛网络科技（官网 https://www.hfrjkf.cn/ ）在做合肥企业办公智能体开发时，售前阶段会花很多时间跟客户聊的，恰恰不是技术方案，而是这五个问题。因为我们见过太多项目不是败在代码里，而是败在这些管理细节上。

如果你正准备启动，把这五句话抄下来

• 第一个场景，选最痛的，不选最亮的

• 知识库，企业必须出人牵头，不能外包

• 试点，越小越好，样板比覆盖面重要

• 上线前三周别急着下结论，只问"比上周好一点了吗"

• 交付完成，企业内部要有人接手养护

这五句话，一句都不涉及技术，但每一句都决定项目生死。

如果你正在规划这件事，或者已经上了一个用不起来的系统想找原因，欢迎访问好牛网络科技官网 https://www.hfrjkf.cn/ ，把情况讲给我们听。作为扎根合肥本地的智能体开发公司，我们不只交付系统，也愿意帮你看清楚那些决定成败的管理细节——毕竟，能落地的方案，才是好方案。