那个搞出200万事故的AI项目，今天突然收到了尾款，甲方还想合作？
叶小钗约 9 分钟手里有些AI岗位；想找工作的同学可联系，急缺高级产品经理
关注公众号，回复1，与我交个朋友吧
久旱逢甘霖，最近终于迎来了好消息：之前欠我尾款的公司，给了一部分欠款，并期待更进一步合作！
这个故事比较曲折，还是去年的时候，当时本来说好的一个价钱，被一个事故给冲没了，虽然我有所不满，但也没太好的办法，有兴趣同学可以先看这篇文章：
这里问题也就来了：
这个老板良心发现了吗，居然愿意主动给钱了？ 如果是良心发现，为什么又只给一部分呢？
答案当然不可能是良心发现，而是首先要从这里找答案：《国务院关于深入实施“人工智能+”行动的意见》
其次是之前给他们做的那套AI客服系统着实好用，他们几乎要把客服开完了，节约了大量的成本。
然后老板看到了甜头，最近有些新的想法，比如加点知识库、做点用户画像分析撒的。
但是他们自己的技术做的效果很差，甚至把老系统搞得老出BUG，于是“良心发现”再次找到了我，只能说真不愧是“资本家”啊，每一分钱都算得很细！
只不过，这件事对我来说却有点小冲击：
说来也可笑，我本身很看得起的AI项目不愠不火，一个我不太看得起的AI客服系统，居然还让一个公司恋恋不忘了？
是否我以为好的和市场要的其实一直都不是一个事，我觉得Low的东西，大家都在做的，也许正是人家需要的，并且要不到的？
所以，我们今天不得不来一起审视一下这个我认为很Low的AI客服项目：
项目概述
首先，从定位来说这个AI客服项目是个外包项目，用的技术也很常见，所以我这边对他是比较轻视的；
其次，从项目目标来说分为两个大块，一个是薅平台流量、一个是AI客服侧的降本增效，全景图如下：
他的具体形式就是帮一个公司做短视频、文档等内容，然后在不同的平台投放，最后获取流量，整个客服就上场做转化：
比如，我是卖化妆品的，我会在小红书上保有100个账号，每天只写一篇文章，然后再按各种维度、标题，用AI生成100篇文章，目的也很简单：大力出奇迹，我要用户一搜关键词就能找到我。
只不过现在各个平台对这种AI灰产打击是非常严重的，所以这套策略的核心除了技术之外还有账号，你得真的能搞到这么多账号
现在各大平台只要涉及商品属性的内容，往往都是一台PC控制多个AI，在全网乱刷数据，你看到的所有信息可能都被操纵过：
所有的流量投放最终目的都是留资，将公域流量变成私域流量，随后就会有一连串的销售行为，这里又会涉及到AI提效的地方：
整个全案设计难度不在技术而在业务梳理，这里简单举两个AI提效的小例子：
第一，有个模块是用户会上传自己的身份证，然后之前是由客服手动誊抄，而这块用OCR+AI能很快解决，这里至少节约了2个人力；
第二，电销体系的线索分配逻辑很复杂，他们可能会将线索直接给销冠，按销售效果分配；他们也可能将线索直接发群里，谁先抢到给谁；
因为线索量太大（数千）原来是有个5人天天做线索分配，而后这个板块完全由AI处理了，节约了5个人力。
以上就是留资后整个公司业务流转的真实情况（AI客服只占其中一部分），大家也看出来了，如果只说工作流AI的话，AI也就占了他不到20%的部分，而这可能就是AI在企业应用中真实的占比。
最后，我们将AI客服单拎出来，重点讨论下他们自己技术做不好的部分：
AI客服
AI客服大幅提升了客服团队效率，50人的团队能完成200人的工作：
这里先吐槽一句：AI客服系统本身价值是巨大的，只不过后面的故事大家都知道了，AI被引导到了裁员，可以说是无奈但又不可避免的事...
说回正题，一旦提到客服机器人，大家的第一反应马上就来了：提示词，RAG、向量库...
甲方团队确实也是这样玩的：一股脑的将文档丢进去，然后再写一坨粗暴的提示词，最后效果一团糟，向上无法交差时，于是开始抱怨，模型能力怎么这么垃圾...
这里借鉴训练营学员某产品负责人的吐槽比较贴切：
我终于知道，为什么搞不懂公司那批程序员在做什么了，他们在做技术架构的时候采用的是AI Max思路：
一个开源技术不行就换一个，单智能体不行就换多智能体，全部试过以后就说AI的上限就是这样，没有优化空间了，等新的技术开源了就再来一遍。
我有时候确实好奇，忍不住要问一他们怎么量化上限、有没有过程方法论？这批程序员就说量化不了、沉淀不了，都是别人的东西跑一下就好了。
我总觉得哪里不对，但因为不懂也说不出个所以然，只能听之任之，现在好了，确实不行，老子来给他们设计技术路径！
RAG又不是万能的春药，他的使用也要分场景的，首先得了解业务，其次要梳理SOP，然后要设计数据框架，最后才是上线跑效果拿反馈；
不同的场景会有不同的SOP以及与之匹配的数据结构，如果仅仅想依靠粗暴的技术解决所有的业务问题，这不是傲慢这是傻。
而当我们去着手解决的时候，程序员们又开始抱怨：公司在这个板块历史上根本没撒数据积累啊？这里可能需要简单展开说说了：
抓典型，做实现
事实上公司是有数据积累的，只不过比较分散，常见的处理方法是抓典型，比如找到公司销冠，就一比一对照实现销冠的数字分身，这里包括两点：
销冠工作习惯需要形成SOP，这里所谓的SOP就是他具体与客户交流的策略； 整理数据，比如销冠的话术，这个数据最后要与SOP映射；
有了这套标准SOP，那么整体框架也就形成，随后可以匹配这套框架组织更多的SOP以及话术模板即可。
这里为保护客户的技术隐私，我们用昨天聊到过的PageIndex给大家重现下案例：PageIndex案例，向量库已死、RAG永存：模型进步再次干死过时技术
首先是整理出来的销冠内容：
文档：销售SOP手册.pdf
第2章 核心价值要点（p12）
- 降本：同类替代品平均减少人工 25%（测算方法见附录）
- 提效：典型流程时长从 3 小时缩短到 45 分钟
- 风险：提供操作留痕与可回溯审计
- 上手：1 小时完成基础配置
第3章 异议处理（p18）
3.1 价格太贵（p19）
目标：把“价格抗性”转为“价值/风险下降/上手简单”
触发：贵/太高/预算/折扣/再看看
禁忌：承诺具体收益天数；贬损竞品
模板 T-3.1-A（标准版）：
1) 共情（理解谨慎）
2) 价值要点对齐（引用第2章 p12 的要点）
3) 风险降低与上手门槛（同样引用 p12）
4) A/B 收尾（A：先体验；B：我发一页价值清单）
3.2 我再考虑一下（p21）
模板 T-3.2-B：
1) 错失焦虑（非价格型：时间/精力成本）
2) 二选一（A：15 分钟演示；B：明早前发体验指引）
3) 软担保（支持试用/可回退到基础方案）
第4章 成交与跟进（p28）
4.2 逼单子树（p29）
路径：异议→松动→试用/演示→收尾（付款方式/排期）
第7章 售后与保障（p30）
- 7.1 支持试用与配置回滚
- 7.2 技术支持 SLA：工单 4 小时内响应
- 7.3 交付可回退（基础版不丢数据）
其次是PageIndex解析后的内容：
{
"doc_id": "SOP-2025",
"title": "销售SOP手册",
"nodes": [
{"title":"第2章 核心价值要点","node_id":"2","page_index":12},
{
"title":"第3章 异议处理","node_id":"3","page_index":18,
"nodes":[
{
"title":"3.1 价格太贵","node_id":"3.1","page_index":19,
"intent_tags":["价格异议"],
"triggers":["贵","太高","预算","再看看","折扣"],
"forbidden":["承诺具体收益天数","贬损竞品"],
"template_id":"T-3.1-A",
"evidence":[{"doc":"SOP-2025","pages":[12,19,30]}]
},
{
"title":"3.2 我再考虑一下","node_id":"3.2","page_index":21,
"template_id":"T-3.2-B",
"evidence":[{"doc":"SOP-2025","pages":[21,30]}]
}
]
},
{"title":"第4章 成交与跟进","node_id":"4","page_index":28,
"nodes":[{"title":"4.2 逼单子树","node_id":"4.2","page_index":29}]},
{"title":"第7章 售后与保障","node_id":"7","page_index":30}
]
}
然后是意图归一：
输入：太贵了，我再看看吧。
输出：
{
"phase": "异议处理",
"strategy": "价格太贵",
"search_hints": ["价格","再看看","价值","上手","保障"],
"must_tags": ["价格异议"],
"forbidden": ["承诺具体收益天数","贬损竞品"]
}
然后是检索模块：
{
"retrieved_nodes": [
{
"doc_id":"SOP-2025",
"node_id":"3.1",
"node_path":["第3章 异议处理","3.1 价格太贵"],
"evidence":[{"doc":"SOP-2025","pages":[12,19,30]}],
"snippet":"共情→引用 p12 价值→风险/上手→A/B 收尾"
}
],
"trajectory":[
{"from":"root","to":"第3章 异议处理","reason":"命中‘价格/再看看’"},
{"from":"第3章 异议处理","to":"3.1 价格太贵","reason":"must_tags=价格异议"}
]
}
可以有一些合规性否定处理：
{
"checks":{
"forbidden":["承诺具体收益天数","贬损竞品"],
"citations_required": true,
"docs_allowed":["SOP-2025"]
},
"decision":"allow_with_citations"
}
......
在这个基础下就可以形成完整的一次对话来回了：
用户：太贵了，我再看看吧。
AI：
理解您谨慎，投入前把账算清是对的。就我们落地最常见的几件事来说：流程从 3 小时缩到 45 分钟、支持可回溯审计、基础上手约 1 小时。
为了不占用您太多时间，我给两个选项：
A. 安排一个 15 分钟在线演示，您现场感受下是否值；
B. 我把 一页版价值清单发您，您空了再看也行。
另外，支持试用与配置回滚、工单 4 小时内响应。
您更倾向哪个？
用户：先演示吧。
AI：
好的，我这边按15 分钟演示流程走，稍后发您日程邀请与演示入口。演示后如果不合适，我们也支持配置回滚。
最后献上不完整的提示词：
意图归一
你是“售前意图归一化器”。输入用户原话，输出 JSON：
{phase, strategy, search_hints, must_tags, forbidden}
phase ∈ [开场, 需求澄清, 方案, 异议处理, 逼单, 成交]
strategy ∈ [价格太贵, 我再考虑一下, 问家人, 售后疑虑, …]
forbidden 固定为 ["承诺具体收益天数","贬损竞品"]
禁止回答，只输出 JSON。
PageIndex 检索器调用参数
输入：{search_hints, must_tags}
输出：{retrieved_nodes[], trajectory[]}
要求：优先返回 doc_id="SOP-2025" 的节点；附带 pages 与 node_path。
话术装配器
输入：{intent, nodes, citations_required=true}
规则：
- 只能引用 doc_id="SOP-2025" 的内容，且带页码（p12/p19/p21/p30）
- 结构：共情 → 价值要点（p12）→ 风险/上手（p12）→ 保障（p30）→ A/B 收尾
- 禁止新增未在手册出现的承诺或数字
输出：最终回答（中文）
综上，着就是一个AI客服的典型案例，粗略地展示了一套从方法论到技术实现的链路，大家重点关注思路即可，因为实现是残缺的。
上述案例离可上线的产品级还差几步，最大的坑主要在一致性、稳定性和合规边界等几个方面，大家可以自己进一步探索。
结语
曾被我轻视的AI客服项目，最终却成为客户“恋恋不忘”的关键工具，其价值其实就在“50人团队能完成200人的工作”，他击中了企业降本增效的刚需。
只不过，我之前在用有色眼光看待他，觉得这个技术不难，大家都会，没有壁垒，事实上这是一种认知偏差，我认为简单的东西，可能对于其他团队很难...
这里其实也衍生出很多其他问题，比如：现在大家太关注AI项目的短期效果，往往忽略其长期稳定性，一旦出问题，往往措手不及，比如之前的3小时事故造成的累计损失200多万！
没做容灾处理，直接打了我们一个措手不及，只不过只从尾款来说，我估计当时没出事故，他们也不会给我...
其实，这些爆发的问题与事故也许是好事，老板们是需要一些教育的，他们需要完成从“AI什么都能做”到“AI什么都不能做”，再到“换个方式也许能做”的这种转换，老板们对AI项目的认知越客观，反而投入和预期更合理，这样也会更容易成功一些。
最后强调一句：AI应用的终极挑战并非技术本身，而是工程落地的稳定性、业务理解的深度与系统管理的成熟度，希望这篇文章对大家有用...
点击上方卡片关注叶小钗公众号，查看下方二维码，添加我个人微信：