我把公司内部的AI工具拆出来对外卖，第一天就发现三个坎

先交代背景，我们公司不是做软件的。

做的是连锁服务业，全国三十多家门店，每家店都有一堆重复动作要做：给客户发体检套餐介绍、跟进没来的客户、把客户的体检异常结果整理成能看懂的话、给新入职的店长做培训。

这些活以前靠人，做得慢，做得还不一样。

去年我们把这些活一个一个交给了 AI。我原本以为这就是「内部提效」，做完就算完了。

后来业务部门问了一句：「这套东西能不能给外面的同行用？」

我心里咯噔一下。技术上好像能，卖的话好像也有点价值。但仔细一想，中间横着三道坎，我原来根本没意识到。

这三个月我们真的试了一下，不是全卖，是找了三家同行做试点。这篇写那三道坎，以及我在每个坎上摔的跟头。

一、第一道坎：内部「能用」不等于外部「愿意用」

这是最容易低估的一道。

我们内部那套工具，日活最高的一个功能是异常结果解读。医生看完体检报告，写一段给客户看的话，哪些指标要注意、要不要复查、饮食怎么调。这段话由 AI 生成初稿，医生改完发出去。

内部用得非常好。医生们一开始抵触，用了两个月之后变成「不看初稿反而奇怪」。

我们把这个功能放到试点客户那，第一周就发现问题了：对方医生根本不看初稿，直接从空白开始写。

原因我一开始没搞明白，直到对方负责人跟我说了一句：「你们这个是给我们的医生用还是给我们的客户用？」

这一句点醒我了。

我们内部的场景，AI 生成的是给客户看的东西，所以医生是「审核者」，他关心的是准确和不准确。我们对外推的时候，场景变成了 AI 直接产出给医生参考用，那医生就从审核者变成了使用者。用户角色变了，评价标准就完全变了。

内部那道「医生改完再发」的流程，放在外部场景里就是纯粹的成本。我后来把功能改成了先给医生三个选项让他选，AI 的活儿从「写一整段」变成「给三个方向」，采纳率立刻从零变成了六成左右。

这一坎的解法我总结成一句：先问清楚谁是使用者，再问 AI 该干什么。我一开始的错就是把「谁用这个功能」和「谁看这个功能的输出」当成了同一件事。

二、第二道坎：技术能复用，但服务没法复用

第二道坎更疼。

我们内部那套东西底层是几个模块：客户信息整理、内容生成、多轮追问、数据统计。技术上拆出来给别人用，代码一行没改。

但服务改不动。

我们内部出问题，随口在群里喊一声「系统抽风了」，IT 半小时就到。外部客户出问题，要走工单，要签 SLA，要跨时区，要有人能接电话。

举个具体的例子。我们有一个功能是根据客户的体检历史推荐套餐。内部用的时候，销售直接改参数就行了。给外部客户开放之后，客户问了三个问题：

1. 这个推荐依据是什么，能不能解释；
2. 万一推荐错了，责任在谁；
3. 能不能按他们自己的规则改。

第一个问题我们答得出来。第二个问题我答不出来。第三个问题做不了，因为我们的规则引擎写死了。

当时我们才明白：内部工具的「灵活」来自我们自己有权限改代码。外部客户要的是「可配置」，那是完全不同的工程量。

我把这道坎的解法写成了一张表，做试点之前必须逐条确认：

| 要确认的事 | 我们踩的坑 |

| --- | --- |

| 输出谁署名、谁担责 | 默认我方署名，对方不接受 |

| 哪些参数能开放给客户配 | 全部写死，对方要改就得等我们排期 |

| 出问题找谁、多久响应 | 没写，对方按行业标准理解，我们做不到 |

| 数据能不能留在客户那边 | 含糊其辞，对方安全评审直接卡住 |

这张表现在是我们对外输出任何东西之前的必过项。说实话，这四条里我们第一次做的时候一条都没写对。

三、第三道坎：最值钱的不是技术，是那个「没人愿意干」的活

这道坎是我最没想到的，也是最后才明白的。

我们挑试点客户的时候，本以为卖点是「这套东西很强、很智能」。结果客户问得最多的一句话是：「你们当初是怎么想到做这个的？」

这个问题我一开始答得很顺，说「我们内部有需求所以做了」。答完对方没什么反应。

后来有家客户聊得深一点，他们的技术负责人说了句话：「这个东西我们内部也想过，一直没做，因为不知道怎么立项，不知道算谁的活。」

这句话我记到现在。

我们内部立项这件事，靠的是「这个活特别烦、特别耗时、大家都躲着做」。这个理由在我们公司成立，但在客户那边不成立。因为在他们眼里，一个「没人愿意干的活」要么该被砍掉，要么该有人干，总之不像是一个值得花钱买的东西。

所以我们最后改了卖法。

我们不再说「我们有个 AI 工具」，改成说「你们公司这个岗位的这些人，每个月在这件事上花掉多少时间，我们已经把它压到了多少」。

这句话有具体数字支撑。我们内部的那个岗位，30 家店，每店两个人做这些事，每人每天大概 3 小时。这道坎我们跨过去一半的方式是：把这件事从「我们有个工具」变成「我们有一份可以给你的测算」。

这份测算表是我自己写的，写了 11 个版本才定下来，核心就是三行：

• 现在这件事一年花掉多少人力（用他们自己的排班表算，不用我们的估算）；
• 换成工具之后能省掉多少（按实测转化率打折，打八折再说）；
• 前 3 个月切换成本多少（培训、数据准备、试点范围）。

这三行是决定试点能不能谈成的东西。技术演示是敲门砖，测算表才是签字的那张纸。

四、我算过的账，和算错的地方

既然聊钱，我把这三个月真实的数说几个。

内部成本这一侧比较好算。研发这块投入了大概 3 个人 2 个月的工时，加上底层几个模块的复用，这部分是沉没成本不用再摊。

真正的成本全在服务侧。我原以为最费的是写文档，实际最费的是处理「这能不能改」。试点三个月，我收到的大大小小「能不能加个功能」的请求有 40 多个，其中大概 8 个是真需求，其他是「感觉这里不太对」。光是区分这 8 个，就花掉我一个完整的人月。

第二个坑是试点和卖的成本完全不是一回事。我们给两家试点客户是完全免费 + 驻场陪跑的，成本高得离谱。真到做报价的时候我才发现，一份看起来很简单的报价单，我改了 6 天。

第三个坑是维护成本被严重低估了。我们内部的工具三个月改了大大小小 15 个版本，都是自己人用，改坏了改回来没人投诉。给外部客户用之后，同样的改动要发通知、要等窗口期、要写变更说明。这部分工作量我完全没算进去。

还有一个坑：别把免费试点做太久。第一家试点我们陪跑了 5 周，第 4 周的时候对方开始提各种「顺手加一下」的要求，第 5 周结束的时候我们已经分不清是在做产品还是在做外包。

后来我把试点期压到 3 周，第 3 周必须给出结论。做不成就明确说不做。

五、如果你们的公司也在想这件事

我给一个我自己用的顺序，不是通用方法论，就是我们这三个月踩出来的路径。

第一步，先挑「烦但没人抢」的活。不要挑最重要的、最有战略价值的。挑那种又烦又没人愿意认领的，因为这种活在对方那边立项最难，而它恰好是最容易出效果的地方。

第二步，先写测算表，再写产品介绍。顺序反过来会死。技术演示可以很惊艳，但对方签字的依据是钱和时间。

第三步，把「谁署名谁担责」写在最前面。这个不谈，后面全是白干。我们第一轮就是漏了这条，第二轮又漏了「数据能不能留在客户那边」，第三轮才谈拢。

第四步，试点的目的不是卖，是搞清楚哪三个问题答不上来。我们三周试点问出来的问题比三个月做产品的都多。

第五步，早点说不。第一家试点最后没成，这事对我打击挺大。但复盘下来，那个不成的决定反而帮我们把产品改对了。如果当时为了成单硬接下来，后面会砸得更狠。

写在最后

这三个月我最大的认知变化，是把「把 AI 能力对外输出」这件事看简单了。

我以为的技术活是怎么把功能封装出去。实际的技术活只占三成，剩下七成是：怎么把内部的使用者角色翻译给外部、怎么把「我们能改代码」变成「客户能配置」、怎么把一个说不清立项理由的活，换成一个能被写进预算的理由。

这三个问题一个比一个难，而且都不是技术问题。

所以如果你问我，内部 AI 工具能不能对外卖，我的答案是：能，但要先回答三个跟技术无关的问题：谁用、谁担责、对方为什么要买。

前两个问题答不上来，做出来也卖不动。第三个问题答不上来，做得再好也只是个演示。

你们公司内部有没有已经做出来了、但一直只在自己这儿用的 AI 工具？我挺想看看这类东西最后都是怎么卖出去的。评论区说说，我看到会挑典型的展开聊，尤其是「内部跑得好好的，外部为什么就是不买」这类问题。

关于文中数据：文中提到的人力成本测算、试点次数、功能版本数、请求数量等数字，来自我自己项目的真实记录，非官方统计。文中关于「内部能力外化需补齐服务与责任体系」「用户角色变化会改变评价标准」「价值主张需落到成本测算」等判断，来自公开行业分析与实践观察，属于行业推测与经验整理，非官方结论。文中未提及任何具体公司、品牌或产品名称，所有业务场景均做了泛化处理，不同企业的实际情况差异很大。