一、 创业背景：被“计算器”绑架的店主

在闲鱼上有这样一类“快递代下单”的店主，他们的生意逻辑很简单：利用信息差和协议价帮用户下单。但他们每天最痛苦的事不是没流量，而是**“算账”**。

看看这些真实的用户咨询：

“四川广安到广东揭阳，泡沫地垫，5公斤，体积 60×60×18cm 多少钱？”

“上海发郑州，不到1公斤，盒子 40×25×45 厘米。”

“你好，三套直播灯具 106×29×26cm，5kg，汕尾发上海最便宜多少？”

店主必须手动计算：

1. 体积重：

   $$V = \frac{L \times W \times H}{8000}$$

2. 计费重： $max(\text{实重}, \text{体积重})$（且需向上取整）。

3. 查表： 在巨大的 Excel 表里匹配始发地、目的地和三家快递公司的首续重价格。

痛点： 这种活儿，人工回一个要 2 分钟，回 100 个就是 3 小时。一旦回慢了，客户就去下一家了。

---

二、 技术演进：从“人工智障”到“专业代办”

作为一名 AI 开发者，我最开始的想法很简单：把价格表扔给大模型，让它直接算。 ### 1.0 翻车现场：大模型的“数学老师”请假了

大模型（即使是 GPT-4 或 Claude）在处理复杂数学和长表格时，极易产生“幻觉”。

• 错误案例： 模型会一本正经地告诉我 $56 \times 42 \times 24 / 8000 = 14.1kg$，但实际上是 $7.056kg$。

• 后果： 报高了客户走，报低了店主亏。在生意面前，1% 的错误率就是 100% 的事故。

2.0 效率瓶颈：传统的 Agent 模式太慢

我尝试了标准的 LLM -> Function Calling -> LLM 链路：

1. 模型识别意图，调用算价工具。

2. 工具算出结果返回给模型。

3. 模型组织语言回复客户。

问题： 两次大模型调用加上 Token 消耗，回复时间往往超过 15 秒。在闲鱼这种快节奏场景下，“慢”就等于“死”。

---

三、 终极方案：参数提取 + 逻辑闭环回复

为了追求极致的**“准”和“快”**，我优化了系统架构：

核心逻辑：

1. 意图识别与参数提取： 利用 LLM 强大的语义理解能力，从杂乱的咨询中提取：出发省份、目的省份、重量、长/宽/高。

2. 硬编码逻辑计算： 提取出的参数直接传给我写的 Python 算价工具。数学的事，交给代码；语义的事，交给 AI。

3. 跳过二次生成： 为了节省时间和 Token，我直接在工具层根据预设模板（message_template）生成最终回复。

现在的回复效果（5-8 秒内）：

运费来喽，四川 → 广东 8.1kg

总价: 23.35 极兔 (续2.45/kg) 总价: 25.79 韵达 (续2.85/kg) 总价: 26.13 申通 (续2.8/kg)

按照【极兔】计算运费，领券后直接在小程序下单，补差19.85元。

---

四、 工程实践：模型选型的心路历程

在实现过程中，我对比了市面上的主流大模型：

• DeepSeek： 价格真香，但在高峰期响应延迟会跳到 15 秒以上，对于这种“掐秒表”的客服场景，稳定性略逊。

• 通义千问 Qwen-Max： 逻辑极强，但回复太“重”，开销大。

• 通义千问 Qwen-Turbo： 速度极快，但对工具调用的参数提取偶尔会漏掉“长宽高”中的一个。

最终选择：通义千问 Qwen-Plus。

它在参数提取的准确率和首字响应速度（TTFT）之间达到了完美的平衡。配合我的 冰石机器人 Windows 客户端，实现了本地高并发处理。

---

五、 写在最后

AI 创业不一定要追求“改变世界”的大叙事。帮一个闲鱼店主解决每天 3 小时的机械劳动，让他能腾出时间去陪陪家人或者挖掘新产品，这就是 AI 落地最真实的价值。

目前，冰石机器人 已经不仅支持快递计费，还支持汽配报价、多模态 OCR 识别查表等深度定制场景。

如果你也深受重复客服之苦，或者想看看 AI 如何真正落地私域，欢迎在淘宝或闲鱼搜索“冰石机器人客服”进行交流。有需要提示词的可以私信我。