企业应用大模型，最常见的问题不是模型能力不足，而是上下文工程没做够。B2B电商商家的店铺诊断场景，恰好是观察这一问题的典型样本：数据在后台齐备，判断依赖经验，动作缺乏标准。本文以一套已在商家群体中跑通的AI诊断方法为例，拆解其从数据投喂到行动清单的完整链路。
一、问题重构：诊断是翻译问题，不是分析问题
多数商家把店铺诊断理解为「看数据」，这是误判。后台的展现量、点击率、询盘数、支付转化率、流量结构，数据获取零门槛；真正的稀缺环节，是把数据放到业务上下文里翻译成动作——流量下滑归因于标题还是价格，询盘减少归因于详情页还是响应时效。这套翻译能力过去长在第三方服务商和老运营身上，成本高、难沉淀。
该方法的底层认知清晰：诊断的本质是把数据翻译成可执行动作，AI缺的从来不是分析能力，而是完整的上下文。这实际上是上下文工程问题在商业运营侧的映射。
二、工具分层：事实层与分析层解耦
链路设计上，工具被分为两层。平台内置AI生意助手作为事实层，直接读取店铺后台数据，完成商品表现、流量概况、指标汇总等基础盘点；通用AI助手配合平台插件作为分析层，结合运营知识完成问题拆解、方案输出与计划生成。
这种解耦设计对应数据治理的基本原则：事实与推理分离，各自用最合适的工具。跳过事实层直接让通用AI猜测业务数据，输出必然失真；止步于事实层不做推理，则得到的是报表而非诊断。
三、提示词四层公式：上下文的结构化封装
诊断提示词由四层组成，本质是把业务上下文结构化地封装进单次请求：
定角色——设定「十年经验店铺诊断专家」身份，约束知识范围与输出风格；喂数据——完整注入展现量、点击率、询盘数、支付转化率、流量占比、回头率、履约率等指标，遵循宁多勿猜原则；划维度——限定流量结构、商品结构、详情转化、价格竞争力、服务履约五个维度，收敛输出范围；定输出——要求按问题、数据依据、改进动作、优先级四列输出，将散文式回答转为可执行任务表。
另有一条防幻觉约束：仅基于给定数据诊断，数据不足时先列出补充清单，禁止编造结论。
四、追问机制：从诊断报告到行动清单
首轮输出的是问题清单，距离执行还差三步追问：确定优先前三事项及完成标准；将首项展开为按天拆解的一周执行计划；针对单维度深挖出可在后台验证的自查方法。三轮追问完成后，诊断报告即转化为可排期、可验收的行动清单。
五、闭环与沉淀：复诊节奏是长期价值所在
落地环节设置三道人工把关：关键指标回后台复核；超出人力与预算的动作暂缓；每周固定时间以最新数据复诊，对比两周变化验证有效性。诊断结论持续沉淀为自有运营清单，逐步形成贴合自身业务的诊断体系。
对企业而言，这套方法的可复制性不在提示词本身，而在其流程思想：把领域专家的隐性经验，显式化为角色、数据、维度、格式四类上下文约束，再以固定节奏闭环迭代。这一框架可以平移到选品、竞品分析、客服质检等更多运营场景。
一句话公式：AI店铺诊断 = 定角色 × 喂数据 × 划维度 × 定输出。
