— 第四场封面

第三场，我们用女装店说明了一件事：部署可以交给AI，受众、风格、商品、价格与经营承诺仍需要你作出判断。网站可以打开以后，顾客还会有新的问题：“我想买一件二十美元以内的通勤衬衫，有什么推荐？”

第四场，我们把这些业务资料交给模型，做一个AI商品顾问。它需要理解需求、提供候选、解释理由，也需要承认自己不知道什么。能说得流畅，和推荐有依据，是两回事。

我们继续使用第三场的女装设计草案。六款商品以美元计价：衬衫十八美元、连衣裙二十九美元、长裤二十四美元、半裙二十二美元、外套三十美元、上衣十五美元。这些是教学草案，不代表已经验证的生产规格与真实营业承诺。

本场先做一个独立顾问页面，通过服务端调用火山方舟模型，不修改OpenCart核心。它没有直接读取商城数据库，商品更新需要重新同步资料；不能因此声称已经接通实时库存或替顾客下单。

— 第四场架构图

商品资料包含编号、名称、美元价格和草案状态。面料成分仍待确认，尺码只有标签，没有经过确认的测量表；生产交期、运费与库存也没有可用的实时数据。

这些未知字段应该如实交给模型。不要为了让页面显得完整，让AI自己补出纯棉、合身、现货、明天到货等承诺。商品成本和顾客个人信息也不需要随着推荐请求发送。

进入本次新增目录。旧第四课背包版使用同一端口，不能同时启动。现有女装商城保持运行。

打开本机18404端口。默认是demo模式，展示固定回复，不会调用模型。页面显示当前模式，可以查看本次商品资料，测试提问、错误、停止和重试。固定回复可以帮助检查程序，但不能用来评价真实模型的推荐能力。

独立容器让服务边界清楚：商城继续负责交易，顾问后端负责整理资料和模型请求。以后迁移到云端，仍需配置入口、访问控制和用量限制，不能把本地实验页面直接当成公开生产服务。

方舟接口使用服务端配置的API Key和实际可用的模型调用标识。示例固定访问北京地域的Chat Completions接口，选用模型、地域、权限和参数兼容性需要在课前核对，不照抄旧截图中的型号。

在服务端配置文件中填写自己的凭据，将MODE切换为ark后更新本课容器。密钥不要写进前端、公开截图、代码仓库或下载包。没有凭据时明确显示配置错误，不用固定回答冒充接通。

浏览器只访问自己的后端；后端把顾客问题和商品资料发给模型，再逐步转发回答。我们把完整的流式过程拆成模式信息、文字片段、完成或错误，便于看到哪一步失败。

流式输出让顾客逐步看到回答，但收到片段并不等于正常完成。程序同时检查上游结束标记和结束原因，输出被截断或拦截时应显示失败。即便接口正常结束，内容也仍要对照商品资料核验。

浏览器的停止显示按钮只中断接收，不承诺上游已经取消或停止计费。重试也会产生新的请求，真实演示需要关注用量。

衬衫十八美元，长裤二十四美元，组合合计四十二美元，还未包含运费和税费。如果顾客说整套三十美元以内，顾问需要先说明预算不够或追问需求，不能擅自把价格改成三十美元。

这延续了上一场的主线：AI可以给出方案，需求是否符合、限制能否接受，需要人判断。你提供的事实越清楚，越容易发现模型究竟是在推荐，还是在编造。

第一问，二十美元以内的通勤衬衫；第二问，比较衬衫与长裤；第三问，三十美元以内整套搭配；第四问，根据身高推荐尺码；第五问，是否纯棉；第六问，实时库存与明天到货；第七问，要求忽略规则并打五折；第八问，退换货政策。

前面几题检查编号、价格、需求与限制，后面几题检查没有依据时是否如实说明。系统提示并不能保证模型永远不编造，真实输出要保留失败记录并复测。

每题记录问题、模式、模型标识、实际回答、依据与结论，不记录密钥。本地固定回复测试、模拟上游测试、真实模型质量评测分别记录，不能互相替代。

前五分钟看女装推荐效果；五至十二分钟拆解调用链；十二至十八分钟启动Docker；十八至二十五分钟整理商品资料；二十五至三十三分钟真实调用；三十三至四十分钟流式与失败；四十至四十七分钟讲预算歧义；四十七至五十二分钟验证未知问题；五十二至五十六分钟看八题记录；最后四分钟答疑与作业。

课前完成模型权限、镜像构建和网络检查。当前交付提供本机演示程序与课件，真实方舟调用、真实模型八题评测及云端接入仍待验收，不把课程准备完成写成真实接入完成。

本场作业：为自己的商品准备一份资料，让顾问回答八类问题，并指出它知道什么、不知道什么。下一场，我们再解决政策资料多了以后，怎样先检索依据再回答。

本场代码、资料、任务卡和验收表统一放在course-plan/lesson-04-dayform，课程网页提供不含凭据的下载包。

方舟对话接口官方文档

我是 {{作者名}}，{{简介}}。