企业官网建设流程全解析

1. 项目概述：当 Copilot 不再是“助手”，而成了“收银员”

最近在几家连锁便利店、社区生鲜店和本地药房做数字化巡检时，我反复听到一句让我后背发凉的话：“现在顾客一进门就喊‘小助理’，结果我们后台系统弹出来的不是商品推荐，是结账二维码。”这不是段子，是真实发生的场景——微软 Copilot 正在被商家“降维使用”：本该理解用户意图、串联库存、促销、会员、物流的智能体，眼下正被硬生生塞进收银台的窄缝里，干着扫码、查价、开票的活儿。标题里说它“沦为收银台”，其实没夸张；更扎心的是后半句：“商家该建 AI 可读懂数字货架”——不是 Copilot 不行，是货架本身没准备好被 AI 看懂。

这个标题背后藏着一个正在加速裂变的现实断层：一边是大厂把 Copilot 做成通用接口，开放给所有企业调用；另一边是90%以上的中小实体商家，连商品主数据都还在用 Excel 表格维护，SKU 编码规则五花八门，同一款酸奶在系统里可能叫“安慕希原味”“安慕希450g”“安慕希_原味_450ml_常温”，而图片里还带着手写价签、反光贴纸、模糊阴影。AI 想“看懂”，先得认出这是同一瓶奶；想“理解”，还得知道它今天是否临期、是否参与满减、是否被隔壁店抢了库存。这些，Copilot 自己不会猜，它只认结构化、语义清晰、上下文自洽的数据输入。

所以这根本不是 Copilot 的问题，而是数字货架的“失语症”。所谓“AI 可读懂数字货架”，不是让货架长出眼睛，而是让货架会“说话”：用机器能解析的语法描述商品身份、状态、关系与意图。它需要的不是更高算力，而是更干净的命名、更一致的属性、更及时的状态同步、更合理的上下文封装。这篇文章，就是从一线实操角度，拆解怎么把一个杂乱无章的线下货架，改造成 Copilot（或任何 LLM 接口）真正愿意“搭理”的数字伙伴。适合正在接入 Copilot 的零售 IT 人员、连锁品牌数字化负责人、以及想用 AI 做私域导购的店主——你不需要会写 prompt，但必须知道你的货架，到底在对 AI 说什么。

2. 数字货架的本质：不是拍照上传，而是构建可推理的数据图谱

2.1 为什么 Copilot 在货架前“卡壳”？三个典型现场还原

我上周蹲点一家社区母婴店，店主刚装好带 Copilot 插件的 POS 系统，兴奋地让我试：“你问它‘宝宝拉肚子该买什么’，它应该推蒙脱石散吧？”我照做，Copilot 回复：“已为您找到 3 款蒙脱石散，请选择：① 思密达 3g×10 袋（处方药）；② 博福-益生菌复合粉（非药品）；③ 康恩贝儿童腹泻贴（外用）。”问题来了：第一款需药师审核，第二款实际是益生菌，第三款根本没在店内上架——系统里只是历史 SKU 未清理。Copilot 没错，它忠实返回了数据库里所有含“蒙脱石散”关键词的商品，但它完全不知道“这款药今天没货”“这款药不能直接卖”“这个贴剂根本不在母婴区”。

再看另一家烘焙坊：顾客问“有没有低糖的蛋糕”，Copilot 列出 5 款，其中 3 款标注“低糖”，但原料表里蔗糖含量分别是 12g/100g、8g/100g、15g/100g——系统里“低糖”字段是人工打的勾，没关联真实营养数据。AI 把“打勾”当事实，把“人工判断”当标准。

第三个案例更隐蔽：某连锁药房上线 Copilot 后，顾客问“高血压吃什么药”，系统优先推送了门店销量最高的氨氯地平片，而非医生开具频次最高的缬沙坦胶囊。原因？销量字段权重被设为 100，而“处方匹配度”字段权重为 0，且未接入电子处方系统。Copilot 在按“最热”排序，而不是按“最准”响应。

这三个现场，暴露了同一个底层缺陷：数字货架不是商品信息的陈列橱窗，而是 AI 进行因果推理的原材料仓库。它必须同时满足三重可读性：

• 语法可读：字段命名统一（如统一用product_sugar_content_g_per_100g，而非混用sugar_level、low_sugar_flag、sweetness_tag）；
• 语义可读：每个字段值有明确定义（如stock_status必须是in_stock/low_stock/out_of_stock/pre_order_only四选一，不能是“快没了”“差不多”“问问仓管”）；
• 关系可读：商品之间存在可计算的逻辑链（如 A 商品是 B 商品的替代品 →substitute_for: [B_sku_id]；C 商品与 D 商品常被一起购买 →frequently_bought_with: [D_sku_id]）。

没有这三层，Copilot 就是拿着一本缺页、涂改、无索引的词典去翻译莎士比亚——它很努力，但输出注定荒诞。

2.2 数字货架 ≠ 商品主数据管理（MDM），而是 MDM 的“AI 就绪态”升级

很多企业以为上了 MDM 系统就万事大吉。我见过某快消品牌花了 300 万做的 MDM，字段齐全：品名、规格、条码、分类、供应商、保质期……但当我让 Copilot 查询“保质期剩余少于7天的进口酸奶”，它返回空集。查原因，发现shelf_life_remaining_days字段是空的——因为 MDM 里只存“生产日期”和“保质期天数”，而“剩余天数”需要实时计算并写回。MDM 管静态定义，不负责动态状态；而 AI 需要的是“此刻”的状态快照。

真正的 AI 可读货架，是在 MDM 基础上叠加三层能力：

1. 状态引擎层：自动计算并刷新关键动态字段。例如：

   • stock_status=IF(current_stock < safety_stock, "low_stock", IF(current_stock = 0, "out_of_stock", "in_stock"))
   • promotion_eligibility=IF(today BETWEEN promotion_start AND promotion_end AND stock_status = "in_stock", true, false)
   • ai_relevance_score=0.3 * sales_velocity_7d + 0.4 * inventory_turnover_rate + 0.3 * customer_review_rating

2. 关系图谱层：用图数据库（如 Neo4j）或带关系字段的宽表，显式存储商品间逻辑。比如：

   • 蒙脱石散 →has_contraindication_with: [布洛芬缓释胶囊]
   • 有机燕麦片 →is_compatible_with: [植物奶、奇亚籽、蓝莓]
   • 儿童钙片 →age_group_target: ["3-6岁", "7-12岁"]

3. 上下文封装层：为每次 AI 请求预加载相关环境变量。例如顾客问“宝宝拉肚子”，系统自动注入：

   • 当前时间（判断是否夜间，触发药师值班提醒）
   • 顾客会员等级（决定是否推送高毛利替代品）
   • 门店库存水位（过滤掉仅剩1盒的商品）
   • 最近3次购药记录（排除已购未取的订单）

这三层加起来，才构成 Copilot 能“读懂”的货架。它不是把 Excel 表格搬上云，而是重建一套为 AI 决策服务的数据操作系统。

2.3 构建成本真相：90% 的投入在“清洗”，而非“搭建”

很多人问我：“建一个 AI 可读货架，要多少预算？”我的回答永远是：“先算你有多少 Excel 表、微信聊天记录、手写单据、拍照存档的价签。”——这些才是真正的成本黑洞。

以一家中型连锁超市为例（12 家门店，SKU 约 8000 个）：

• 数据源盘点耗时 3 周：发现 7 类数据源：ERP 系统（主数据）、WMS 仓管系统（库存）、POS 收银系统（销量）、企微客服对话（顾客咨询高频问题）、抖音小店后台（促销活动）、采购合同扫描件（供应商资质）、门店巡检 App（临期商品照片）。
• 字段对齐耗时 5 周：光是“商品状态”就有 5 种定义：ERP 用status_code（1=上架，2=下架，3=停售），WMS 用inventory_status（"available"/"reserved"/"damaged"），POS 用sale_flag（Y/N），客服对话里是“没货了”“刚补完”“等明天到货”，巡检 App 里是手写“临期3天”。要把它们映射到统一的ai_stock_status，需要业务、IT、门店三方坐在一起，逐条确认每种状态的实际业务含义。
• 清洗与校验耗时 8 周：发现 23% 的 SKU 缺少 GTIN 条码；41% 的商品图片分辨率低于 800×800，AI 无法识别包装细节；17% 的保质期字段格式混乱（“2024.05.30”“24/05/30”“May 30, 2024”混用）；还有 3 个 SKU 因供应商更名，在 ERP 和 WMS 中用了不同编码，导致库存无法合并。

最终，他们花了 16 周、不到 20 万元，完成了基础货架改造。钱主要花在：1 名数据治理顾问（驻场）、1 名熟悉零售业务的 Python 工程师（写清洗脚本）、3 次跨部门对齐会（提供茶歇和误工补贴）。硬件零投入，云服务用现有 Azure 订阅即可。真正的门槛从来不是技术，而是敢不敢直面自己数据的“脏”与“乱”。

提示：别指望一次清洗永久解决。我们建议设置“数据健康度看板”，每日监控 5 项核心指标：

• sku_completeness_rate（必填字段完整率）
• image_resolution_pass_rate（图片分辨率达标率）
• date_format_consistency（日期格式统一率）
• stock_status_sync_latency（库存状态同步延迟，目标 < 5 分钟）
• ai_query_success_rate（Copilot 查询成功率，目标 > 95%）
  这些指标比任何 PPT 都更能反映货架是否真的“可读”。

3. 实操落地：从 0 到 1 搭建 Copilot 友好数字货架的 4 个关键环节

3.1 环节一：定义 AI 可读的最小可行字段集（MVF）

别一上来就搞“全量字段”。AI 不需要知道每款牙膏的氟化钠浓度，它只需要知道“是否含氟”“适用年龄”“是否电动牙刷专用”。我们基于 12 家零售客户的实测反馈，提炼出 Copilot 在 90% 场景下真正依赖的12 个核心字段，称为 MVF（Minimum Viable Fields）。它们分三类，全部强制要求：

注意：age_group_target和substitute_sku_ids这类数组字段，必须用标准 JSON 格式存储，且值必须是已存在的sku_id。我们曾发现某系统把substitute_sku_ids存成"MILK-YOG-MENGNIU-450ML-2024,MILK-YOG-YILI-450ML-2024"（逗号分隔字符串），导致 Copilot 解析失败。务必用["id1","id2"]格式。

这 12 个字段，就是你的数字货架“脊椎”。其他字段（如详细成分、供应商地址、物流单号）可以后续扩展，但脊椎必须先立住。实测表明，只要这 12 个字段准确率 >98%，Copilot 的基础问答准确率就能从 42% 提升到 89%。

3.2 环节二：设计动态状态计算引擎，让货架“活”起来

静态字段只能回答“是什么”，动态引擎才能回答“现在怎样”。我们不推荐直接修改 ERP 或 WMS 的核心逻辑（风险高、周期长），而是采用“轻量中间层”方案：用 Azure Functions（或国内可用的阿里云函数计算）搭建一个独立的状态计算服务。

以stock_status为例，它的计算逻辑不是简单查库存表，而是融合多源信号：

def calculate_stock_status(sku_id): # 1. 获取实时库存（来自 WMS API） wms_stock = get_wms_stock(sku_id) # 2. 获取安全库存阈值（来自 ERP 配置表） safety_stock = get_safety_stock(sku_id) # 3. 获取在途库存（来自 TMS 系统，判断是否 24 小时内可达） in_transit_stock = get_in_transit_stock(sku_id, within_hours=24) # 4. 获取预售锁定量（来自 POS 系统，防止超卖） reserved_stock = get_reserved_stock(sku_id) # 5. 综合计算有效可用库存 effective_stock = max(0, wms_stock + in_transit_stock - reserved_stock) # 6. 输出状态枚举 if effective_stock == 0: return "out_of_stock" elif effective_stock < safety_stock * 0.5: return "critical_low_stock" # 比 low_stock 更紧急 elif effective_stock < safety_stock: return "low_stock" else: return "in_stock"

这个函数每 5 分钟触发一次，批量处理当日活跃 SKU（销量 Top 500），并将结果写入一个轻量级 Redis 缓存（键：stock_status:{sku_id}，过期时间 10 分钟）。Copilot 查询时，优先读缓存；缓存未命中，再走实时计算。这样既保证时效性（延迟 < 10 秒），又避免对核心系统造成压力。

同理，ai_relevance_score的计算更体现业务智慧：

def calculate_ai_relevance_score(sku_id): # 权重可配置，由运营后台调整 weights = { "sales_velocity_7d": 0.3, "inventory_turnover_rate": 0.4, "customer_review_rating": 0.2, "margin_rate": 0.1 } score = ( normalize_to_01(get_sales_velocity_7d(sku_id)) * weights["sales_velocity_7d"] + normalize_to_01(get_inventory_turnover_rate(sku_id)) * weights["inventory_turnover_rate"] + normalize_to_01(get_customer_review_rating(sku_id)) * weights["customer_review_rating"] + normalize_to_01(get_margin_rate(sku_id)) * weights["margin_rate"] ) return round(score, 2) # 保留两位小数，便于 Copilot 理解

这里的关键是normalize_to_01()函数——它把不同量纲的指标（如销量是 1000 件，毛利是 35%）统一映射到 0-1 区间。我们用的是分位数归一化：取全品类数据，将第 1 百分位设为 0，第 99 百分位设为 1，中间线性插值。这样避免了异常值干扰（比如某爆款销量是其他商品的 100 倍，直接除最大值会压扁其他商品得分）。

实操心得：状态引擎上线后，一定要做“影子模式”验证。即新引擎计算结果不直接写入生产库，而是写入影子表；同时记录 Copilot 每次查询的原始请求和两个引擎（旧 vs 新）的返回结果。跑一周后对比差异，重点分析“新引擎认为 out_of_stock，但旧引擎显示 in_stock”的 case——往往暴露出临期、调拨、退货未同步等隐藏问题。我们帮一家药店发现，23% 的“假缺货”源于退货商品未从销售库存中扣减，这个漏洞在影子模式里被精准捕获。

3.3 环节三：构建商品关系图谱，让 AI 理解“为什么”

Copilot 的强项是推理，但推理需要前提。当顾客问“宝宝拉肚子该买什么”，它需要知道：

• 蒙脱石散是止泻药（has_function: "anti_diarrheal"）
• 但 3 岁以下禁用（contraindicated_age_group: ["0-3岁"]）
• 且与布洛芬同服会降低药效（has_interaction_with: ["IBU-001"]）
• 而店里正好有儿童专用益生菌（is_child_formulation: true），且库存充足

这些不是孤立字段，而是节点与边的关系网络。我们推荐用 Neo4j 图数据库（Azure 上有托管服务），因为它天然支持“查找所有与 A 有 X 关系且满足 Y 条件的 B”这类查询。

建模核心是三个节点类型和四类关系：

• 节点类型：

  • Product（商品）：含sku_id,name,category等属性
  • Attribute（属性）：如age_group,function,ingredient
  • Context（上下文）：如time_of_day,customer_profile,store_location

• 核心关系：

  • HAS_ATTRIBUTE：Product-[HAS_ATTRIBUTE]->Attribute（例：蒙脱石散 -[HAS_ATTRIBUTE]-> “止泻”）
  • SUBSTITUTE_FOR：Product-[SUBSTITUTE_FOR]->Product（例：A 酸奶 -[SUBSTITUTE_FOR]-> B 酸奶）
  • FREQUENTLY_BOUGHT_WITH：Product-[FREQUENTLY_BOUGHT_WITH]->Product
  • CONTEXTUAL_CONSTRAINT：Product-[CONTEXTUAL_CONSTRAINT]->Context（例：儿童钙片 -[CONTEXTUAL_CONSTRAINT]-> “适用年龄：3-12岁”）

当 Copilot 收到请求，它不再简单检索关键词，而是发起图查询：

// 查找所有适用于 2 岁宝宝、有止泻功能、且库存充足的非处方药 MATCH (p:Product)-[:HAS_ATTRIBUTE]->(a1:Attribute {value: "anti_diarrheal"}) MATCH (p)-[:HAS_ATTRIBUTE]->(a2:Attribute {value: "otc"}) MATCH (p)-[:CONTEXTUAL_CONSTRAINT]->(c:Context {key: "age_group", value: "2岁"}) WHERE p.stock_status = "in_stock" RETURN p.sku_id, p.name, p.ai_relevance_score ORDER BY p.ai_relevance_score DESC LIMIT 3

这个查询能在毫秒级返回结果，且逻辑清晰可审计。相比在 SQL 里写一堆 JOIN 和 WHERE，图查询更贴近人类思维：“找什么→有什么特征→在什么条件下有效”。

注意：关系图谱不是一步到位的。我们建议从最高频的 3 类关系起步：SUBSTITUTE_FOR（缺货兜底）、FREQUENTLY_BOUGHT_WITH（关联销售）、HAS_ATTRIBUTE（基础属性）。其他关系（如药物相互作用）可后续由药师团队人工标注补充。初期用 CSV 批量导入即可，无需复杂 ETL。

3.4 环节四：封装上下文，让每次交互都有“人味”

Copilot 最怕“裸聊”。顾客说“给我推荐一款咖啡”，如果系统只返回sku_id，它可能推一款 500 元的冷萃礼盒——而顾客只是想买杯提神的速溶。问题不在 AI，而在输入太“干”。

我们必须为每次请求，预加载 5 层上下文：

1. 时空上下文：当前时间（判断是否早餐时段）、门店 GPS 坐标（决定是否推附近自提点商品）、天气（雨天推热饮）
2. 用户画像上下文：会员等级（决定是否推高毛利新品）、历史购买频次（高频用户推尝鲜款，低频用户推经典款）、最近 3 次搜索词（判断当前意图是“找替代品”还是“比价格”）
3. 设备与渠道上下文：是 POS 机语音输入（需简洁回复）、企微文字咨询（可附链接）、还是小程序扫码（需跳转详情页）
4. 业务策略上下文：今日主推品类（由运营后台配置）、清仓商品池（临期 7 天内）、新员工培训重点（推易介绍商品）
5. 对话历史上下文：本次会话前 2 轮交互（避免重复推荐，或承接“不要太甜的”这类约束）

这些上下文不直接塞给 Copilot，而是通过 Prompt Engineering 封装成结构化指令：

你是一名资深药店导购，正在为一位 35 岁女性会员（VIP 金卡，过去半年购买过 12 次维生素）提供服务。她当前在朝阳区建国路店（GPS: 116.45,39.92），时间为工作日 15:30，天气晴朗。她刚刚询问：“宝宝拉肚子怎么办？”，你已推荐蒙脱石散，但她追问：“有没有更温和的？”请基于以下商品池，推荐 1 款最符合“温和”“儿童适用”“库存充足”的替代品，并用不超过 20 字说明理由。

这个指令里，时空、用户、业务、对话历史全部嵌入，Copilot 的输出质量立刻不同。我们测试过：同样问“宝宝拉肚子”，无上下文时推荐 3 款药；加入上下文后，它精准锁定一款儿童益生菌，并说：“这款含双歧杆菌，温和调理肠道，门店有货。”

实操技巧：上下文封装不要写死在代码里。我们用 Azure App Configuration 服务，按store_id+user_segment+time_window动态加载配置模板。例如context_template:pharmacy:gold_member:afternoon对应一个 JSON 模板，里面定义了该场景下要注入哪些字段、如何格式化。运营人员可在后台随时调整，无需开发介入。

4. 常见问题与排查技巧实录：那些踩过的坑，比教程更有价值

4.1 问题一：Copilot 推荐了已下架商品，但系统显示“in_stock”

现象：顾客问“有没有 XX 牙膏”，Copilot 返回一款 SKU，点击查看详情却提示“该商品已下架”。后台查stock_status字段确实是in_stock。

排查路径：

1. 检查stock_status字段来源：是来自 WMS 实时库存，还是 ERP 的静态配置？我们发现该 SKU 在 WMS 中库存为 0，但 ERP 里status_code仍为 1（上架），且未同步。
2. 检查状态计算引擎的日志：发现该 SKU 的calculate_stock_status函数在过去 24 小时内从未执行——原因是其sales_velocity_7d为 0，被引擎判定为“非活跃商品”，跳过计算。
3. 检查字段更新机制：stock_status是只读缓存，但status_code（ERP 下架状态）是另一个字段，Copilot 查询时未关联。

根因：状态引擎只覆盖了“库存驱动”的状态，但忽略了“业务驱动”的状态（如下架、停售、清仓）。stock_status和business_status是两个维度，必须同时存在并联合判断。

解决方案：

• 在 MVF 字段集中增加business_status（枚举：active/discontinued/clearance_only/temporarily_unavailable）
• 修改状态计算逻辑：final_status = IF(business_status != "active", business_status, stock_status)
• 在 Copilot 查询时，强制校验final_status，而非单一字段

教训：不要假设“库存有”就等于“能卖”。下架、法律禁售、供应商断供，都是独立于库存的业务状态。我们后来在所有客户项目中，强制要求business_status字段必须由 ERP 主动推送，且与stock_status解耦。

4.2 问题二：图片识别失败，Copilot 无法根据包装图推荐商品

现象：顾客用手机拍了一张模糊的奶粉罐，问“这是什么牌子？”，Copilot 返回“未识别”，但人工一眼看出是美素佳儿。

排查路径：

1. 检查图片预处理：Copilot 调用的是 Azure Computer Vision API，但传入图片尺寸为 3000×4000 像素，远超 API 推荐的 1024×1024。
2. 检查图片内容：原图有强烈反光、手写价签遮挡 LOGO、背景杂乱（货架其他商品）。
3. 检查 fallback 机制：API 失败后，系统未触发文本 OCR（识别罐体文字）或条码扫描。

根因：过度依赖单一识别通道，且未做图片质量前置校验。

解决方案：

• 前端拦截：APP 端拍照后，用 OpenCV 快速检测：
  • blur_score < 100（模糊度）
  • glare_ratio > 0.3（反光面积占比）
  • logo_coverage < 0.2（LOGO 区域被遮挡比例） 若任一超标，提示用户“请对准LOGO，避免反光”并重新拍摄。
• 多通道识别：

  def identify_by_image(image_bytes): # 通道1：高清图送 CV API if image_quality_ok(image_bytes): result = cv_api.analyze(image_bytes) if result.confidence > 0.8: return result # 通道2：OCR 文字识别 ocr_text = ocr_api.extract_text(image_bytes) if "美素佳儿" in ocr_text or "Friso" in ocr_text: return search_by_brand("美素佳儿") # 通道3：条码扫描（若图片含清晰条码区域） barcode = barcode_api.scan(image_bytes) if barcode: return search_by_gtin(barcode) return {"error": "无法识别，请尝试文字描述"}

• 人工兜底：所有失败请求，自动创建工单，推送至门店企微群，附带原图和 OCR 文本，由店员 5 分钟内人工确认。

实操心得：我们给一家母婴连锁做的图片识别优化，把首图识别成功率从 54% 提升到 89%。关键不是换更贵的 API，而是用“前端质检 + 多通道 + 人工闭环”组合拳。店员反馈：“以前要翻半天系统找 SKU，现在拍一下，AI 报出名字，我核对下就行，省了 80% 时间。”

4.3 问题三：Copilot 推荐结果忽高忽低，同一问题两次回答不一致

现象：顾客连续两次问“推荐一款低糖酸奶”，第一次推了 0 蔗糖的，第二次推了 5g/100g 的。

排查路径：

1. 检查ai_relevance_score计算：发现sales_velocity_7d每小时更新，而inventory_turnover_rate每日更新。两次查询间隔 3 小时，前者波动导致得分排序变化。
2. 检查 Prompt 中的随机性：Copilot 默认开启 temperature=0.7（引入随机），导致相同输入可能有不同输出。
3. 检查缓存机制：Redis 缓存未设置 TTL，导致旧分数长期生效。

根因：AI 推荐需要“确定性”与“时效性”的平衡。纯随机输出不可控，纯静态分数又脱离实际。

解决方案：

• 固定随机种子：在调用 Copilot API 时，设置temperature=0，确保相同输入必得相同输出。
• 分数缓存分级：
  • ai_relevance_score缓存 1 小时（高频变动字段）
  • category_path、substitute_sku_ids等静态关系缓存 7 天
• 引入“稳定性锚点”：在排序算法中，加入一个固定权重的稳定因子：

  # 最终排序分 = 0.7 * ai_relevance_score + 0.3 * sku_stability_score # sku_stability_score = 1 / (1 + log10(days_since_first_listed)) # 新上架商品稳定性低，老商品稳定性高，避免新爆款短期冲榜挤掉经典款

注意：不要追求 100% 一致。我们允许 5% 以内的合理波动（如库存从 10 降到 9，不影响推荐），但禁止“从推 A 到推 B”的跳跃。上线后，我们用 A/B 测试验证：对照组（原逻辑）推荐一致性 62%，实验组（新逻辑）达 93%。

4.4 问题四：商家想自己写 Prompt，但效果极差，越调越乱

现象：某店主自学 prompt engineering，给 Copilot 写：“你是一个很厉害的导购，请推荐好喝的酸奶，要便宜，要健康，要小朋友喜欢。” 结果 Copilot 开始写散文：“酸奶，这古老的发酵艺术……”

根因：Prompt 不是“对 AI 讲话”，而是“给 AI 下指令”。自然语言描述意图，不如结构化指令明确。

正确写法（我们给店主的速查表）：

我们甚至给店主做了“Prompt 生成器”网页：他只需勾选“品类”“价格档”“适用人群”“特殊要求”，页面自动生成结构化 JSON，复制粘贴即可。店主反馈：“以前调三天没效果，现在点三下就能用。”

最后分享一个小技巧：所有给 Copilot 的指令，末尾必须加一句“请用中文，用不超过 20 字回答，不要解释原因。”这能强制它输出简洁结果，避免陷入“创作欲”。实测下来，这条指令让有效信息密度提升 300%。

5. 从收银台到决策台：数字货架的下一步，是成为生意的“神经中枢”

我在一家社区药房看到过最触动的一幕：一位老人用方言问 Copilot：“我老头子吃的那个红药片，一天吃几粒？”Copilot 听不清，但系统自动调取了他的会员档案（绑定过家属手机号），发现他上周购买过硝苯地平控释片，且处方单上写着“每日1次，每次1片”。于是它没纠结发音，