第 3.10.3 节：把详情页、评价总结与导购写成可校验、可复用的工程契约
详情页、评价总结与导购不能只停留在口头约定，还需要落实为字段、校验和失败处理。完成本节后，你应该能够把详情页、评价总结与导购落成字段表、校验规则、错误处理和验收样例。
实现步骤或决策流程
推荐技术流及原因
本章推荐的技术流是“资料治理 + RAG（检索增强生成）+ Structured Output（结构化输出）+ Guardrail（护栏）+ Human-in-the-loop（人工参与闭环）+ Trace ID（追踪编号）”。
选择这条技术流的原因很直接：电商和门店项目不能让模型凭空发挥，必须让每个回答和建议回到商品资料、规则、评价样本或经营数据上。
- 资料治理：先把商品、价格口径、售后规则、门店数据和禁用表述整理成统一字段。没有这一步，后面的生成结果很难验收。
- RAG：用户提问时先检索相关商品、规则和评价，再让模型回答。它能降低编造概率，也方便回答时引用依据。
- Structured Output（结构化输出）：让 Agent（智能体）输出固定栏目，例如“推荐商品、推荐理由、风险提示、需人工确认项”。固定结构比自由聊天更适合交付验收。
- Guardrail（护栏）：设置禁止承诺、敏感词拦截、价格过期提示、库存未知提示和高风险转人工规则。
- Human-in-the-loop（人工参与闭环）：详情页发布、活动价格解释、强功效表达、投诉处理和高价值订单推荐，都应由人工确认。
- Trace ID（追踪编号）：每次回答、推荐、生成草稿和经营建议都要有追踪编号，便于复盘“用了哪些资料、谁确认、结果如何”。
如果客户只想做轻量版本，可以先做表格资料加人工审核的半自动流程；如果客户已有系统接口，再考虑 API（应用程序接口）或 Webhook（事件回调）接入。
字段契约表
字段契约是交付中的关键文档。它不是技术炫技，而是用来约束“Agent 可以依据什么生成内容”。
| 字段 | 含义 | 来源 | 是否必填 | 更新频率 | 风险说明 |
|---|---|---|---|---|---|
| item_id | 商品或服务项目唯一编号 | 商品表或门店系统 | 必填 | 商品变更时 | 没有唯一编号会导致推荐错商品 |
| item_name | 商品或服务名称 | 商品资料 | 必填 | 商品变更时 | 名称要与平台展示一致 |
| category | 类目，例如女装、餐饮套餐、美容项目 | 商品资料 | 必填 | 低频 | 影响检索和推荐范围 |
| specs | 规格、尺码、容量、套餐内容 | 商品详情 | 必填 | 中频 | 规格缺失会造成客服误答 |
| price_policy | 价格口径和活动说明 | 后台或人工表格 | 条件必填 | 高频 | 必须带更新时间，不能承诺永久有效 |
| inventory_status | 库存状态或可预约状态 | 库存系统或门店确认 | 条件必填 | 高频 | 不确定时只能提示确认 |
| after_sales_rule | 退换、预约、核销、退款规则 | 售后文档 | 必填 | 中频 | 售后回答必须引用该字段 |
| selling_points | 已审核卖点 | 品牌或运营 | 必填 | 中频 | 未审核卖点不能直接发布 |
| banned_claims | 禁用表述和敏感承诺 | 法务、平台规则、运营 | 必填 | 中频 | 用于护栏拦截 |
| review_samples | 评价样本与时间范围 | 平台评价导出 | 条件必填 | 周期性 | 总结必须标注样本范围 |
| store_metrics | 销售、客流、转化、客单价等指标 | POS（销售终端系统）或门店表格 | 条件必填 | 日或周 | 口径不一致会影响分析 |
| human_owner | 负责确认的人 | 客户组织表 | 必填 | 人员变化时 | 高风险内容必须找到责任人 |
| trace_id（追踪编号） | 本次输出追踪编号 | 系统生成 | 必填 | 每次输出 | 用于追溯和复盘 |
数据准备
电商、本地生活和门店项目的数据准备要贴近真实经营，而不是只准备商品介绍。一个能用于作品集/面试复盘的数据包，建议至少包含六类资料。
第一，商品或服务主数据。每个 SKU（库存量单位）或服务项目要有编号、名称、类目、规格、价格口径、库存或预约状态、售后规则、适用人群、不适合人群、更新时间和负责人。价格、库存、活动这些高频变化字段要单独维护，不能埋在长文案里。
第二，已审核内容资料。包括品牌卖点、详情页历史版本、平台标题规则、广告法风险词、禁用承诺、客服标准话术和门店服务说明。智能体只能基于已审核资料生成草稿，不能自创功效或承诺。
第三，真实咨询样本。准备 50 到 100 条历史客服问题，覆盖参数、价格、库存、售后、搭配、投诉、活动和转人工场景。每条样本要标注正确回答依据、是否需要人工确认、原客服处理结果。
第四，评价样本。评价要标注平台、时间范围、样本数量、评分、关键词、好评点、差评原因和异常样本。样本量不足时，只能做描述性总结，不能下强结论。
第五，门店经营数据。至少包含销售额、客流、转化率、客单价、活动、库存、退款、评价和天气或节假日说明。门店分析要把指标口径写清楚，否则很容易把相关性说成因果。
第六，验收标注表。把历史问题标成“可自动回答、需人工确认、禁止回答、资料缺失、规则冲突”。这张表能直接用于模拟验收，也能在面试中证明你不是只做了一个聊天入口。
制作步骤
1. 选定首批业务场景
不要一上来覆盖全部商品和全部门店。首批建议选择一个高频、边界清楚、资料较完整的场景，例如“20 个主推商品的售前问答”“某个门店的周报分析”“某个平台评价的差评总结”。范围越清楚，越容易验收。
选场景时看三件事：问题是否高频，资料是否可获得，结果是否有人使用。只有这三件事同时成立，项目才容易做出价值。
2. 整理商品与规则资料
把商品资料从“给人看的文档”改成“Agent 能可靠引用的资料”。重点不是排版漂亮，而是字段稳定。商品名称、规格、价格口径、库存口径、售后规则、卖点、禁用表述、更新时间必须分开。
对于本地生活门店，还要整理预约规则、核销规则、门店地址、营业时间、服务限制、退款规则和节假日变化。很多错误回答不是模型能力问题，而是资料本身没有写清楚。
整理完成后，要给每类资料指定维护人。商品运营维护卖点和价格口径，客服负责人维护售后话术，店长维护门店营业与预约规则，数据负责人维护经营指标。没有维护人，系统上线后很快会失真。
3. 建立问答与内容任务分类
把用户问题分成几类：商品参数类、价格库存类、售后规则类、搭配推荐类、投诉风险类、平台规则类。不同类别走不同流程。
参数类可以直接引用资料回答；价格库存类必须带更新时间；售后类必须引用规则；搭配推荐类要给出适用条件和备选方案；投诉风险类应转人工；涉及夸大功效、医疗、金融、法律承诺的内容应禁止自动回答。
4. 设计结构化输出
对每类任务设计固定结果。比如商品问答可以输出“直接回答、依据资料、更新时间、需确认项、转人工建议”。详情页优化可以输出“标题建议、核心卖点、用户痛点、禁用风险、人工审核项”。门店分析可以输出“异常指标、可能原因、建议动作、需要补充的数据”。
结构化输出的好处是客户能验收，团队能复盘，后续也能把结果接入客服系统、运营表格或管理看板。
5. 加入护栏与人工确认
护栏不能只靠一句提示词。要把禁用表述、价格过期、库存未知、低置信度、投诉风险、敏感类目、平台规则等情况列成明确规则。
例如，库存字段为空时，Agent 不能说“有货”，只能说“当前资料未确认库存，请以门店或客服确认为准”。评价样本少于约定数量时，Agent 不能给出强结论，只能提示“样本不足，建议补充更多评价后再判断”。
6. 做模拟验收
用真实业务问题做模拟验收，不要只看演示问题。可以准备 50 到 100 条历史客服咨询、20 条差评、7 天门店销售数据和几条活动规则，让 Agent 逐条输出，再由客户标注“正确、部分正确、错误、需人工”。
模拟验收要记录错误类型：资料缺失、检索错误、回答夸大、规则冲突、格式不符合、需要转人工但没有转。这些错误会直接决定后续优化方向。
作品集里可以把模拟验收做成一张小表：样本总数、自动正确、需人工、错误类型、修复动作和复测结果。面试官问“你怎么证明有效”时，这比展示几条漂亮回答更有力度。
7. 小范围试运行
试运行期间不要直接把所有回答开放给用户。建议先让客服、运营或店长内部使用，把 Agent 当作“草稿助手”和“分析助手”。当错误率、采纳率、转人工率达到约定标准后，再扩大范围。
对门店经营分析尤其要谨慎。Agent 可以提出线索，例如“周三晚间客流下降可能与活动曝光不足有关”，但不应该替代店长的经营判断。
8. 建立复盘机制
每周复盘三类内容：错误回答、被人工修改的草稿、未被采纳的建议。复盘不是为了证明模型差，而是为了找到资料、规则、流程和场景边界的问题。
如果错误主要来自资料过期，就先改资料更新流程；如果错误主要来自规则冲突，就明确优先级；如果错误来自用户问题太开放，就改意图识别和转人工策略。