Function Calling：商品筛选与只读工具调用｜课前预习
课程名称：Function Calling：商品筛选与只读工具调用｜项目任务：基于商品事实的客服回答｜编号：W04-D04
第一部分：业务知识
在一个国内电商平台搜索同一品类商品，记录页面如何处理：
- 在售与下架；
- 价格筛选；
- 默认排序；
- 无结果；
- 商品事实和营销话术的区别。
再写一条客服回复，明确标出哪些词来自商品事实，哪些只是解释或建议。
第二部分：技术相关
带着一个协议问题进课堂：模型返回 get_order 和订单号，是否已经查过数据库？两条工具结果先后回来时，程序靠什么知道它们各自对应哪个调用？如果第一轮参数坏了，还应继续请求第二轮解释吗？先画你认为的消息顺序，课堂“两轮协议”中核对。
一位用户想找 500 元以内的通勤耳机；另一位想查询订单 O20260825001。模型可以理解语言并提出动作，但价格、库存、候选、可信 customer_id 和执行许可都不能由模型决定。
先判断
- Function Calling（函数调用） 返回工具名和参数，是否代表 Python 函数已经执行？
- Tool（工具） Schema（数据结构约束） 已 strict，为什么仍要程序白名单与 effect（副作用类型） 检查？
- 商品候选为什么必须由程序硬筛选，而不是让模型“推荐最适合的”？
- API（应用程序接口） 返回顺序改变，最终候选顺序应改变吗？
- 模型参数中出现
customer_id=C9999，应忽略还是拒绝？ - TrustedCustomerContext（可信模拟客户上下文） 从哪里来，为什么它不等于真实登录或鉴权？
- 订单属于 C1001，但 Host（宿主应用） 上下文是 C1002，哪些信息可以返回？
- 未知工具、退款、发货和额外参数应在哪个时刻阻断？
- 怎样用调用前后状态证明“零副作用”？
- 模型解释候选时，哪些事实必须能回指 API？
保留原始判断。课堂会用工具轨迹、状态前后对照和真实/Fixture API 逐项复验。
入口
带进课堂的问题：工具参数的形状和类型都要核对
业务思考：模型输出带有 order_id，但它的值是一个列表。应该交给订单服务试一试，还是在哪里停止？
技术准备：画出“读取输入 → 校验 → 处理 → 报错或提交”的顺序，标出你认为最早应停止的位置。占用原有预习讨论时间，不需要提前完成项目。
课堂讲解后，可用本课预习问题解答核对自己的判断。
带着一个业务判断进入课堂
参数格式完全正确，为什么仍可能查不到订单？把 customer_id 放在模型参数里，能证明归属吗？
写下你的判断和理由；课上讲机制、做反例实验时会对照核对。先不要调用付费模型。
带着一个问题进课堂
员工已登录为什么不能证明可以替任意客户创建工单？
只写自己的判断与不确定点；课堂用项目证据验证，不要求预习时实现。