企业AI客服外包报25万，我报12万还有75%利润：差的是这张分工表
前阵子一个做传统生意的朋友给我打电话，说朋友那边想上一套 AI 客服，问我多少钱能做。
我报了 12 万。
电话那头没还价，直接问什么时候能开工。挂完之后我坐在工位上愣了半天，第一反应不是高兴，是慌。因为我当时压根算不出来，这 12 万的项目我自己要投多少天、成本卡在哪、AI 员工能替掉多少活。
这笔账我后来才算明白。真正拉开报价差距的，不是我会不会用 AI 写代码，是我手上有一张分工表。
一、第一次报价，我其实是照着预算猜的
我做 ToC 的 AI 就业陪跑两年多，累计带了 1000 多个学员拿到 offer，那条线现在也一直在招生。企业单是我在原来这条线之外新开的第二条线，两边的逻辑完全不是一回事。
ToC 这边，一个人报名之后，流程是聊两小时、给方案、稳住心态，然后陪着跑三个月。收多少钱，取决于对方愿意为什么样的安全感付费。
企业单不一样。老板关心的只有三件事：系统什么时候上线、数据是不是落在自己手里、能不能替掉 2 到 3 个客服岗。价格是围绕这三件事倒推出来的，跟我投入多少辛苦关系不大。
所以我第一次报价 12 万，本质上是照着朋友说的十几万预算猜的。签完才意识到真正的风险在后面：做不出来是小事，投进去发现是亏的才是大事。
二、把成本摊开，才看懂为什么能报这么低
我拿这个 AI 客服项目把账拆了一遍，两种模式的对比大概是这样。价格是我这个项目的真实口径，外包的人力单价按市场上常见的 2 万每人每月估：
| 项 | 传统外包 | 我这边 |
|---|---|---|
| 人力配置 | 2 后端 + 1 前端 + 1 测试 | 1 人 + 3 个 AI 员工 |
| 周期 | 2 个月 | 3 周 |
| 人力成本 | 4 人 × 2 月 × 2 万 = 16 万 | 10 天，不按人天计价 |
| 总成本 | 加管理和办公成本，至少 20 万 | 2 到 3 万 |
| 报 12 万的结果 | 亏 8 万；至少要报 20 万才保本，外包还要加利润，报上来就是 25 万上下 | 利润 9 到 10 万，利润率 75% 以上 |
这张表最关键的一行不是「16 万 vs 2 到 3 万」，是「2 个月 vs 3 周」。
工期压下来，甲方付得起的门槛就不是同一个级别了。这里顺便交代一句：利润 9 到 10 万是按 12 万收入减掉 2 到 3 万的现金支出算的，我自己的 10 天没有摊进成本，所以利润率看起来高得有点吓人。
三个企业项目都是在 3 个月内交付完的，营收 50 万出头，利润率 75% 以上。营收比 3 单 × 12 万多出来的那部分，是两单交付后又追加了运维和第二个场景。这一块才是企业单真正的甜头，也是我一开始完全没预料到的。
三、成本结构换在哪了
复盘下来，真正省钱的地方有三个，都不是「AI 帮我写代码更快」这种空话。
第一个，书面产出不再按人天计价。
需求文档、业务流程图、接口方案、风险清单，这些以前是项目里最贵的部分之一，一个项目经理带着写三五天很正常。现在启动会录个屏，把录音丢给 AI 员工出初稿，我审一遍再发客户确认，一天收工。这块从 3 到 5 天压到 1 天，一个项目直接省出三四个工作日。
第二个，CRUD 类代码从人天变成了 token 成本。
用户管理、客服后台页面、数据统计报表、测试用例，这些占了项目代码量的大头，同时也是最不值钱的部分。它们不再按「一个后台页面半天」来算，改成按接口调用算钱，一个模块的成本从几百块掉到几毛钱。
第三个，交付快才有复购。
这是我最晚想通的一点。传统报价必须往高了报，因为单个项目的风险要一次性兜住。我这边把交付压到 3 周，客户验证得快、资金占用小，项目做完自然会有运维、升级、新场景的第二次第三次合作。ToC 是一个学员服务完就结束，企业这边是往后越做越轻。
这里要说清楚，我能报得低不是靠压低人力单价。同一个后端在市场上值多少钱，跟我给自己开多少钱没有关系，账不是这么省的。
四、这张分工表才是护城河
到这一步都不是重点。真正值钱的是下面这张表，它回答的是：哪些东西绝对不许 AI 员工写。
我吃过亏。第一个项目里我把「知识库管理」整个模块丢给了 AI 员工，它写得很完整，也很顺手把删除接口写成了没有二次确认。那次是集成测试阶段翻出来的，如果它当时已经在线上，客户的一批知识可能被一次误触清空。
从那以后我把它固化成了规则，每个模块开工前必须先填 owner：
| 模块类型 | 谁写 | 理由 |
|---|---|---|
| 大模型对接、RAG 检索、对话管理 | 我写 | 写错了查不出来，而且正是甲方验收的核心 |
| 权限判定、删除、支付、外发消息 | 我写 | 不可逆写操作，一次事故吃掉全部利润 |
| 客服后台页面、数据统计报表 | AI 写，我 review | 量大、重复、错了我一眼能看出来 |
| 用户和角色的增删改查 | AI 写，我 review | 骨架统一，出问题可回滚 |
| 单元与集成测试 | AI 生成，我定验收信号 | 生成的用例偏乐观，标准必须我来定 |
一句话概括：AI 能写到哪一层不重要，重要的是我知道哪些地方它不许碰。
这个判断能力，是你在 ToC 赛道练不出来的。它来自你见过线上事故、知道哪个环节错了连日志都查不出来。这也解释了为什么后端做企业级 Agent 落地，护城河在工程纪律这一层，而不是会用哪个模型的 API。
五、靠自觉没用，我把它做成了 CI 门禁
分工表写在文档里，两周之后一定有模块忘记填。所以我把这张表变成了一段可执行的校验，放在 CI 里跑，任务清单不对就别想进下一步。
编译用 go build -o deliver main.go，CI 里执行 ./deliver，看退出码决定要不要继续。
package main
import (
"encoding/json"
"fmt"
"os"
)
type Task struct {
Name string `json:"name"`
Owner string `json:"owner"` // human / ai
Accept string `json:"accept"` // 验收信号，必须能被外部观测
WriteOp bool `json:"write_op"` // 是否涉及删除、支付、外发消息这类不可逆写操作
}
func main() {
raw, err := os.ReadFile("tasks.json")
if err != nil {
fmt.Println("读取任务清单失败:", err)
os.Exit(2)
}
var tasks []Task
if err := json.Unmarshal(raw, &tasks); err != nil {
fmt.Println("任务清单格式不对:", err)
os.Exit(2)
}
if len(tasks) == 0 {
fmt.Println("任务清单是空的，门禁不通过")
os.Exit(1)
}
bad := 0
for _, t := range tasks {
switch {
case t.Name == "":
fmt.Println("[FAIL] 有一个任务没写名字")
bad++
case t.Owner != "human" && t.Owner != "ai":
fmt.Printf("[FAIL] %s: owner 只能是 human 或 ai，现在是 %q\n", t.Name, t.Owner)
bad++
case t.Accept == "":
fmt.Printf("[FAIL] %s: 没写验收信号，做完了也不知道算不算完\n", t.Name)
bad++
case t.WriteOp && t.Owner == "ai":
fmt.Printf("[FAIL] %s: 涉及不可逆写操作，owner 必须是 human\n", t.Name)
bad++
default:
fmt.Printf("[OK] %s: owner=%s\n", t.Name, t.Owner)
}
}
if bad > 0 {
fmt.Printf("\n门禁不通过，%d 个任务要改\n", bad)
os.Exit(1)
}
fmt.Printf("\n门禁通过，%d 个任务全部可交付\n", len(tasks))
}
配套的任务清单长这样：
[
{"name": "RAG 检索链路", "owner": "human", "accept": "召回率为 0 时不返回兜底话术", "write_op": false},
{"name": "知识库删除接口", "owner": "human", "accept": "二次确认后才执行，且软删除保留 30 天", "write_op": true},
{"name": "客服会话后台", "owner": "ai", "accept": "分页、搜索、按会话筛选可用", "write_op": false},
{"name": "批量删除会话", "owner": "ai", "accept": "单次上限 200 条，超出需分批", "write_op": true},
{"name": "会话检索接口测试", "owner": "ai", "accept": "覆盖空结果、超长 query、权限越界三种入参", "write_op": false}
]
第四行是真实项目里最容易犯的错：批量删除会话是后来从客服后台里拆出来的子任务，拆的时候顺手继承了 owner=ai，没人意识到它已经越过了那条线。跑一遍的结果是这样：
[OK] RAG 检索链路: owner=human
[OK] 知识库删除接口: owner=human
[OK] 客服会话后台: owner=ai
[FAIL] 批量删除会话: 涉及不可逆写操作，owner 必须是 human
[OK] 会话检索接口测试: owner=ai
门禁不通过，1 个任务要改
把它的 owner 改成 human，退出码变回 0：
[OK] RAG 检索链路: owner=human
[OK] 知识库删除接口: owner=human
[OK] 客服会话后台: owner=ai
[OK] 批量删除会话: owner=human
[OK] 会话检索接口测试: owner=ai
门禁通过，5 个任务全部可交付
还有一种情况我一开始漏掉了：如果 tasks.json 被清空或者路径指错，for 循环一次都不进，程序会愉快地打印「门禁通过，0 个任务全部可交付」并且退出码 0。一个防「忘记填 owner」的门禁，恰恰在最该拦的场景放行，所以上面那段 len(tasks) == 0 的判断不能省。
六、回到那天挂完电话的慌
现在再接到类似的需求，我心里是有底的。我的报价公式大概是这样：
先是自己的投入折算成 10 天人天，加上模型和工具的 API 费用，再加一块不许砍的安全垫。安全垫这一块我从不压缩，因为项目里一定会冒出来计划外的联调和第三方对接。
做了 12 年技术，我发现一件挺有意思的事：同样是写代码，给个人学员写一个练手项目，收一万，要陪三个月；给企业写一套能上线的 AI 系统，收十二万，三周交完，后面还有复购。差别不在代码难度，在于你把产出定义成了什么。
你现在手上有正在推进的 AI 项目吗？里面有没有哪个模块是「AI 写错了你大概率发现不了」的？评论区说说，我挑典型的单独写一篇。
