二手书定价一开始就翻车了 - 先讲我把智能定价做砸的三种方式
一个反例开场
去年有位独立开发者朋友找我复盘他的校园二手书交易平台。功能很简单：学生把自己用过的教材挂上去卖，买方砍价成交。他决定加一个「智能定价建议」——系统自动给出建议售价，帮卖家快速定价。
听起来很小的一个功能，他前后返工了三次。他的失败路径很有代表性，我把它拆开讲，然后再给出正确的做法。
三种典型的失败做法
失败做法一：直接调通用大模型，提示词写死
第一版他直接调某家大模型的 API，提示词大概是：
> 你是一个二手书估价专家，请根据书名、成色、出版年份给出建议价格。
结果上线第一周就出问题：同一本《高等数学（第七版）》，成色九成新，模型有时建议 25 元，有时建议 45 元，波动极大。更糟的是，模型偶尔会一本正经地编造「该书新版售价 128 元」——实际上新版定价是 59 元。
通用大模型没有校园二手市场的真实成交数据，它的「估价」本质上是幻觉加猜测。卖家看到建议价，挂出去两周无人问津，转头就怪平台不靠谱。
失败做法二：纯规则引擎，维护到怀疑人生
第二版他换了思路：写规则。按原价打折、按出版年份衰减、按成色系数调整。规则从最初的 12 条膨胀到 60 多条——考研书要单独处理、绝版书要溢价、专业书和公共课书系数不同、教材改版后旧版暴跌……
每所学校、每个学院的情况都不一样，规则永远追不上现实。三个月后，他自己都不敢改规则了，因为牵一发动全身。
失败做法三：多模型混着调，代码里埋满雷
第三版他想「取长补短」：定价用 A 模型、成色描述理解用 B 模型、对话还用 C 模型。三个 SDK、三套鉴权、三份错误处理代码。A 模型限流了要写重试，B 模型改版了要改参数解析，C 模型的计费账单和前两个对不上。
一个人维护三套模型接入，光处理 API 层的杂事就占掉一半开发时间，定价算法本身反而没精力迭代。
正确路径：数据打底、模型分层、统一网关
复盘之后，我们重新设计。核心原则是：大模型不负责「知道价格」，只负责「理解和推理」；价格知识来自结构化数据；所有模型调用走一个统一入口。
架构设计
整体分四层：
- 数据层：平台自身的成交记录（脱敏后）+ 爬取整理的新书定价参考表 + 用户上传时的结构化字段（ISBN、成色自评、笔记多少）。新书定价是确定事实，不靠模型猜。
- 定价引擎层：一个轻量的基准价计算逻辑——按 ISBN 查新书价，套用成色系数和改版折价系数，得到基准区间。这一步不涉及大模型，结果可解释、可回归测试。
- 大模型增强层：大模型做三件事——解析卖家随手拍的图书照片提取 ISBN 和成色线索；结合「该书下学期是否还在用、是否改版」等上下文对基准区间做微调说明；生成给卖家看的定价理由文案。模型输出的是区间和理由，不是一个拍脑袋的数字。
- 统一 AI 网关层：所有模型调用（不同厂商、不同用途）都走同一个 API 网关，应用代码只面对一套接口。
为什么统一网关能显著降低维护成本
这是我朋友三番返工后感触最深的一点。统一 AI 网关的价值不在「能调模型」，而在于把模型相关的脏活收拢到一处：
- 一套鉴权、一套 SDK。三个模型厂商三套接入代码，收拢成一套。换模型、加模型，应用代码不动，改网关配置就行。
- 统一的错误码和重试策略。以前每家限流规则不同、报错格式不同，各自写补丁；现在网关统一处理 429 重试、超时降级，应用层只管业务逻辑。
- 统一计费和用量看板。定价建议每天调多少次、哪个环节烧钱最多，一目了然。对学生产品来说，成本失控比性能问题更致命。
- 灵活的模型路由。解析 ISBN 这种简单任务路由到便宜的小模型，定价理由生成这种需要表达力的任务路由到强模型——不用在代码里写死，配置即可调整。
对独立开发者而言，这等于把「维护 N 个模型接入」压缩成「维护 1 个网关配置」，省下的时间全砸在定价算法本身上。
关键实现步骤（流程清单）
1. 建立图书基础数据库
├─ ISBN → 新书定价 → 学期使用情况（是否在用书单）
└─ 改版历史表（第几版 → 前几版折价系数）
2. 实现基准定价函数（纯逻辑，无 AI）
├─ 基准价 = 新书价 × 成色系数 × 改版系数 × 在用系数
└─ 输出区间而非单价，并写单元测试锁定行为
3. 接入统一 AI 网关，注册各任务路由
├─ 小模型路由：照片解析（ISBN/成色提取）
└─ 强模型路由：定价理由生成、卖家沟通话术
4. 提示词约束模型职责
├─ 明确告知基准区间，模型只做微调与解释
├─ 要求输出 JSON（建议区间 + 理由），网关侧做格式校验
└─ 拒答场景兜底：解析失败则引导用户手动填写 ISBN
5. 建立反馈闭环
├─ 记录「建议价 vs 实际成交价」偏差
├─ 每周用偏差数据回调成色/改版系数
└─ 偏差持续收窄即智能定价的可信度证明一个示意代码片段
基准定价核心逻辑，刻意保持简单：
def base_price_suggest(new_price, condition, edition_gap, in_use):
condition_factor = {"全新": 0.75, "九成新": 0.55,
"有笔记": 0.40, "明显磨损": 0.25}[condition]
edition_factor = max(0.3, 1 - 0.35 * edition_gap) # 每落后一代降35%
in_use_factor = 1.0 if in_use else 0.6 # 不在用书单再打折
base = new_price * condition_factor * edition_factor * in_use_factor
return round(base * 0.9, 1), round(base * 1.15, 1) # 给区间不给单价大模型拿到这个区间后，负责补充一句「这本书下学期还会用，建议挂区间上沿」之类的解释，而不是自己发明价格。
结果与收尾
这套方案跑起来后，建议价与实际成交价的偏差逐步收窄，卖家挂单速度明显变快——定价建议真正成了「帮用户做决定」，而不是「替用户瞎猜」。
回头看，三次失败的本质是同一个误区：把大模型当成全知全能的黑盒，把工程问题外包给运气。 智能定价的正确姿势是数据给骨架、模型给血肉、网关管好所有模型出入口。
如果你也在做类似的独立产品，准备接入多个模型又不想被三套 SDK 拖垮，可以先从统一 AI 网关开始，把模型层的维护成本一次性收拢：https://api.thistoken.ai/register
---
不想折腾多家供应商的接入差异？在 https://api.thistoken.ai/register 注册，用一个 base_url 调用所有模型。