- 网店商品越多，客户反而越难决定，因为没有人帮他们把范围缩小到几件。
- 好的销售助手先问预算、用途和限制条件，再挑两三件推荐给客户并说明理由，用不着把全部商品都摆出来。
- 前提是商品数据准确、完整。如果系统里的价格或库存对不上，推荐也会出错。
传统网站和应用做不到的地方
客户走进实体店时，能干的店员会问几个问题，然后拿两三件给客户挑。到了网页上，我们却把上百件商品连同一个搜索框一起丢给客户。东西越多，客户越拿不定主意，最后干脆关掉页面。
商品目录变大，客户并不会因此更容易做决定。传统的筛选器要求客户懂商品术语、自己动手比较，而价格、库存、评价和购买条件又分散在好几个地方。
传统的搜索和筛选功能，在买家知道商品名称、了解规格时很好用。但很多客户是从想要的结果出发的，比如想开一家小店、商品必须能和现有系统配合使用，或者场地有限。于是他们选错筛选条件，比较时抓错重点，最后可能买下看着不错、却不符合实际条件的商品。
新一代 AI 电商应用应该先把客户的说法转换成需求（Requirement）和约束条件（Constraint），再去找商品。系统的任务不能只有推销利润最高的商品，还要排除用不了的选项，讲清其中的取舍（Trade-off），并保存决策的上下文，让客户换页面、换设备时不用从头开始，也能把这些信息转交给销售人员。
| 传统模式 | 新一代 AI 产品模式 |
|---|---|
| 根据点击记录推荐，展示热销商品，用聊天窗口回答常见问题（FAQ） | 私人导购（Personal Shopper）接收客户用日常语言提出的需求，生成候选清单（Shortlist），讲清取舍，检查库存和配送范围，并准备好购物车等客户确认 |
负责任的推荐系统，要把 AI 与商品目录规则和实时数据结合起来。AI 负责理解人说的话，约束引擎（Constraint Engine）排除用不了的选项，API 在商品加入购物车之前再确认一次价格、库存和购买条件。
企业可以用上的新能力
所以，比起更聪明的搜索框，好的选品助手更像一位店员：先问商品拿来做什么、预算多少、有哪些限制，再把范围缩小到几件，并说明为什么挑这几件。
项目形态
私人导购的购物体验从客户要解决的问题开始，客户用不着先知道 SKU。用户可以和系统对话、上传场地照片、选择预算，然后在对比界面上查看候选清单。系统应该允许客户修改约束条件，并立刻看到选项为什么变了，不要把推荐背后的逻辑藏起来。
主要功能
功能可以包括引导式提问、兼容性检查、组合搭配、替代品查找、对比和解释，并根据当前数据告知库存、价格、促销、配送和退货政策。如果商品缺货，系统应该推荐替代品，同时说明哪些规格相当、客户需要在哪些方面让步。
技术与数据
比模型更重要的基础，是商品信息管理（Product Information Management）：商品编码、属性、计量单位和商品之间的关系都要保持一致。在此基础上，混合检索（Hybrid Search）、约束引擎和排序模型协同工作，通过 API 连接库存、定价、促销和购物车；需要记住的偏好数据，要先取得客户的同意（Consent）。
业务价值
客户找商品的时间更短，又因为看得到理由而更有信心。企业买错类型的订单少了，重复咨询少了，优秀销售人员的经验也能全天候为客户服务。客户说出的约束条件，还能暴露商品线的空白，以及传统搜索关键词看不到的需求。
- 依据结构化数据比较，不编造规格
- 在取得同意的前提下记住偏好，并允许客户修改
- 按预算和用途搭配组合，不一味推销贵的商品
- 做好售后，比如提供说明书、处理保修申请，以及按正确型号再次购买
模拟案例
实际使用场景
一家办公用品店让客户填写人数、场地面积、预算和采购制度。AI 智能体（AI Agent）推荐三套方案并附上理由，检查库存后生成待审批清单，但在有权限的人确认之前不会付款。
再看另一个模拟案例：一家咖啡店要选购咖啡机，受用电功率、每小时出杯量、吧台空间和预算的限制。系统只问会影响结果的信息，排除电力条件带不动的型号，再搭配磨豆机、滤芯和保养周期，组成一套方案。
最合适的型号缺货时，系统不会无缘无故改推更贵的型号。它会比较新的选项，指出哪些规格降低了，再让客户选择：等货、接受替代型号，还是和店员谈。所有决策信息都会一并转交。
可解释的候选清单
每件推荐商品都要回答：为什么合适，什么情况下不合适，数据从哪里来。
如果说不出理由，系统应该继续提问，不要去猜。
范围、风险与效果评估
衡量指标应包括推荐采纳率、因不兼容导致的退货、店员对推荐的修改，以及投诉，不能只看转化率。提高了销售额、却让退货增多并失去客户信任的系统，就是失败的。如果推荐受到赞助或利润率的影响，必须公开说明，而且不得绕过兼容性规则。
数据不完整或销售指标，都可能让排序（Ranking）出现偏差。要把真正对客户有用的推荐和促销分开，并允许客户修改自己的偏好。
写给开发团队 · 技术指标
应跟踪的指标：Shortlist-to-Cart、Return Rate、Assisted Conversion、Margin Guardrail 和 Recommendation Override
- Discover：跟进实际工作，收集常规情况和例外情况的样本
- Assist：让 AI 起草或给出建议，由人保持控制
- Act：测试集通过后，一次只开放一个工具
- Scale：监控、后备方案（Fallback）、成本和负责人都到位后，再扩大范围
如果推荐带来的点击增加了，退货、人工改写推荐或投诉也跟着上升，或者团队仍然说不清是哪条规则把某个型号排除掉的，就应该放慢扩展的步伐。这说明排序已经跑在商品数据准确性的前面了。
BUSINESS & PRODUCT READINESS
商品数据要准备到什么程度，才能让 AI 代替销售人员做推荐？
写给开发团队 · 技术细节
只有当商品数据采用同一套结构时，私人导购才值得信赖。名称、型号、价格、单位、库存、兼容性（Compatibility）和限制条件，都要有编码和负责人。如果官网写的是一回事，电商平台（Marketplace）上是另一回事，PDF 里还是旧价格，智能体就只能在相互矛盾的数据中做选择。所以企业应该先做商品数据就绪度（Product Data Readiness）评估，再去调优模型。
写给开发团队 · 技术细节
另一个问题是系统的激励方向。如果目标只有转化率，系统可能会推贵的商品，或者隐藏缺点。应该把退货率（Return Rate）、投诉量和 Recommendation Override 设为护栏指标（Guardrail），同时把普通推荐和促销（Promotion）分开，让客户看得到理由、能够比较，也能修改偏好。
可以先为一个品类建立属性字典（Attribute Dictionary），规定每个属性的单位、含义、允许的取值和负责人。例如“适合重度使用”这样的说法，必须转换成可以检查的条件。数据不完整的商品应该做上标记，不能让 AI 凭猜测补上规格。
逻辑要明确分成硬性约束（Hard Constraint）和偏好（Preference）两层。兼容性、安全和法规要求是 AI 不得违反的规则；颜色、风格和偏好顺序则可以借助模型来排序。把这两层分开，团队才能解释推荐结果，也才能真正测试。
把销售人员的经验，变成可以规模化的选品体验
DNA Maker 帮助产品、商品企划、销售和服务团队，把优秀员工挑选商品的方法整理成产品决策图（Product Decision Map）。我们会问：每项规格对哪些人有影响，哪些选项不能搭配使用，哪些情况必须提醒客户。这样 AI 依据的是真正的商品逻辑，不会只学到销售话术。
接着，产品设计团队搭建询问需求、候选清单、对比、组合搭配和解释推荐理由的体验，交给客户试用。我们会衡量：问题是否够短，客户能否修改限制条件，解释是真正帮助了决策，还是只多了几段文字。
DNA Maker 帮助设计让推荐理由一目了然的界面，从需求摘要、候选清单、并排对比、组合搭配，一直到购物车和转交给销售人员。我们在架构上把商品数据、规则和内容与提示词（Prompt）分开，这样客户团队修改属性或条件时，不必推倒重建对话系统。
试行可以从影子模式（Shadow Mode）开始：系统生成候选清单，与店员的推荐对比，但暂时不展示给客户；之后再在一个小品类上线。我们帮助用真实问题建立评测用例，衡量兼容性、推荐理由、退货和决策时间，然后再决定是否扩展到更复杂的品类。
工程方面，我们可以开发电商网站或应用、商品信息层、AI 私人导购、库存和定价 API、购物车与审批功能，以及售后助手，并记录每条推荐用了哪些数据。管理员可以修改规则，审查有风险的推荐。
如果您的商品选项很多，店员要先问客户好几个问题才能推荐型号，可以先从一个品类开始。我们帮助评估数据、制作候选清单原型，并在接入结账流程之前，先用真实对话测试。
SOFTWARE ENGINEERING GLOSSARY
软件工程术语表
下面这些术语涵盖商品数据、排序和审批。可以借这些术语问清楚：系统从哪里得知限制条件，怎样解释推荐，商品目录数据不完整时由谁负责。
| 术语 | 是什么 | 通俗示例 | 高管应问开发团队的问题 |
|---|---|---|---|
| Product Feed | 提供给系统使用的商品数据。好的数据源（Feed）包含编码、属性、单位、价格、库存，并且定期更新，让所有渠道引用同一套数据。 | 价格、库存、规格和商品编码 | 谁负责让数据保持最新？ |
| Recommendation | 根据情境给选项排序。推荐需要有排除不可用选项的规则和排序理由，不应只依赖语言上的相似度。 | 按使用人数和预算选择机器 | 这条标准是为客户着想，还是为了销售额？ |
| Preference | 用户的喜好或限制条件。偏好会随情况变化，不应当作硬性规定处理，所以系统必须让用户能查看、修改和清除它记住的内容。 | 不要需要永久安装的商品 | 客户能否查看并删除自己的偏好？ |
| Structured Output | 格式固定的 AI 输出结果。固定格式让程序能检查缺失的字段并把数据往下传，降低从自由文本中提取事实的风险。 | 以独立字段返回 SKU 列表和理由 | 数据不完整时，系统怎么处理？ |
| Approval Flow | 交易前的审批路径。流程必须按金额、风险或例外情况指定审批人，并记录每次决定的理由和时间，以备日后核查。 | 主管确认公司采购的购物车 | 多大金额需要谁审批？ |
延伸阅读（原始文档）：https://ai.google.dev/gemini-api/docs/function-calling