做AI提效探索，是我婚前最后的倔强
上周五晚上十点半，我一边在Mac上调试一个动画卡顿的Bug，一边用手机刷着婚礼策划群里的消息。婚纱照拍完了，酒店也定了，就剩请柬还没做——而我脑子里却还在想着怎么把Prompt工程和Embedding搞明白，好让团队的智能客服系统别再“答非所问”了。
没错，我是那个在前端组干了快两年的程序媛，日常写React、玩Framer Motion，偶尔被产品经理拉去讨论“能不能让这个按钮有呼吸感”。Windows？只有测试兼容性时才会打开，还得配个虚拟机，不然我的终端会哭。
但最近半年，我开始疯狂接触AI相关技术，不是因为要转行，而是——我们真的被重复劳动压得喘不过气了。
一场“离谱”的需求引发的AI实验
事情得从上个月说起。产品老大在站会上轻描淡写地说：“咱们能不能做个智能FAQ系统？用户输入问题，自动匹配最相关的帮助文档，不用每次都找人工客服。”
我心想：这不就是语义搜索吗？简单！结果一查现有方案，要么是关键词匹配（根本不管“怎么重置密码”和“忘记密码怎么办”其实是同一个意思），要么是直接调大模型API——贵得离谱，而且响应慢到用户以为页面卡了。
更糟的是，我们的帮助文档有上千篇，分散在Confluence、Notion、内部Wiki，格式乱得像我试婚纱那天的化妆台。
当时我真的想砸电脑。但转念一想：既然都要加班，不如加点有技术含量的班。于是我跟组长说：“给我两周，我试试用Embedding+向量检索搞个低成本方案。”
他眼睛一亮：“你还会这个？”
我说：“不会，但我会学，而且……我婚假前得留点作品。”
实战经验：从“Prompt乱写”到“Prompt工程化”
一开始，我天真地以为只要把用户问题丢给大模型，让它“总结一下相关文档”就行。结果第一次测试，模型回了我一句：“根据公司政策，建议您联系客服。”
纯纯的废话文学。
后来才知道，这叫“Prompt没对齐任务目标”。于是开始研究Prompt工程——不是随便写几句提示词，而是结构化地引导模型行为。
比如，我最终用的Prompt模板长这样：
你是一个技术支持助手，请根据以下参考文档回答用户问题。
仅使用提供的文档内容，不要编造信息。
如果文档中没有相关信息，请回答“暂无相关帮助”。
参考文档：
{retrieved_chunks}
用户问题：
{user_query}
关键点在于：
- 明确角色（技术支持助手）
- 限制输出范围（仅使用提供内容）
- 定义兜底策略（无信息时统一回复）
这比最初那句“帮用户找答案”有效十倍。好的Prompt不是魔法咒语，而是任务说明书。
Embedding：让机器“理解”语义的钥匙
但光有Prompt还不够。如果检索不到相关文档，再好的Prompt也巧妇难炊。
于是引入了Embedding。简单说，就是把文本（比如一篇帮助文档）转换成一个高维向量，语义相近的文本在向量空间里距离更近。
我们选了开源的text-embedding-ada-002（虽然现在有更小更快的，但当时图省事），用它把所有帮助文档预处理成向量，存进Pinecone（一个向量数据库）。
流程大概是：
- 爬取所有帮助文档（写了Python脚本，连Notion API都啃下来了）
- 分块（每块300字左右，避免信息过载）
- 用Embedding模型生成向量
- 存入向量库，建立索引
线上查询时：
- 用户输入问题 → 生成Embedding → 向量库相似度搜索 → 返回Top 3相关片段 → 拼进Prompt → 调大模型生成答案
整个过程不到800ms，成本比直接调GPT-4低两个数量级。
踩坑实录：那些让我凌晨三点想删库跑路的瞬间
当然，过程没那么顺利。分享几个血泪教训：
坑1：文档分块太粗，关键信息被切碎
第一次分块按段落切，结果有些FAQ只有两句话，被单独成块后语义不完整。后来改成滑动窗口+重叠分块，保证上下文连贯。
坑2：Embedding模型对中文支持一般
text-embedding-ada-002虽然是多语言，但中文效果不如英文。后来试了国产的bge-large-zh，效果提升明显，尤其对“密码重置”“账户冻结”这类专业术语。
坑3：Prompt没加“禁止编造”，模型开始胡说八道
有一次用户问“能退款吗”，模型结合某篇不相关的促销文档，硬说“可以无条件退款7天”——差点引发客诉。必须在Prompt里明确禁止幻觉。
坑4：向量库没做缓存，QPS一高就崩
初期每次查询都实时算Embedding+查库，高峰期延迟飙到3秒。后来加了Redis缓存用户问题的向量和结果，命中率70%+，压力骤降。
效果对比：AI提效不是口号，是数据
上线两周后，我们拉了数据：
| 指标 | 上线前 | 上线后 | 提升 |
|---|---|---|---|
| 人工客服咨询量 | 1200/天 | 780/天 | ↓35% |
| 平均响应时间 | 2.1s | 0.75s | ↓64% |
| 用户满意度 | 82% | 91% | ↑9% |
| 月度API成本 | ¥8400 | ¥1200 | ↓86% |
最让我骄傲的是，产品经理居然在周会上说：“这个功能做得比预期好，辛苦了！”——要知道，他上次夸我还是因为我修好了他打不开的Chrome插件。
为什么我坚持做技术探索？因为不想只做“人肉组件”
很多人觉得，前端嘛，切页面、调动画、怼兼容性，够用了。但我不甘心。
技术探索不是为了炫技，而是为了把人从重复劳动中解放出来。
我可以用一天时间手动处理100个用户问题，也可以花一周时间写个系统，让它自动处理10000个。
而且，当你真正深入一个问题，会发现很多“理所当然”的方案其实漏洞百出。比如我们之前用的关键词匹配，连“登不进去”和“登录失败”都识别不出是同义——这哪是智能，这是人工智障。
通过这次实践，我不仅学会了Embedding、向量检索、Prompt工程，还顺手优化了前端的数据加载逻辑（用Web Worker预加载向量结果，避免主线程阻塞）。技术是相通的，探索的过程本身就在提效。
写在婚前：代码和爱情，都要亲手构建
现在，我的智能客服系统已经稳定运行一个月，团队也开始用类似思路做内部知识库问答。而我，终于可以把精力放回请柬设计上了——虽然我还是忍不住用Framer Motion给电子请柬加了个微交互动画。
有人说，程序员结婚后就该“稳重”点，少折腾新技术。但我觉得，保持对技术的好奇，和对生活的热爱，从来就不冲突。
下周我就要休婚假了。临走前，我把整个方案写成了内部文档，标题就叫《如何用AI让客服少加班》。希望回来的时候，团队已经基于它做了更多好玩的东西。
毕竟，技术探索的意义，从来不是为了证明自己多厉害，而是——让明天的工作，比今天轻松一点。
而我，只想在婚礼那天，安心当个新娘，而不是半夜爬起来修线上Bug的新娘。
评论 0