跳到主要内容

第 3.7.3 节：把库存预警与驾驶舱解读写成可校验、可复用的工程契约

库存预警与驾驶舱解读不能只停留在口头约定，还需要落实为字段、校验和失败处理。完成本节后，你应该能够把库存预警与驾驶舱解读落成字段表、校验规则、错误处理和验收样例。

实现步骤或决策流程​

推荐技术流及原因​

推荐技术流不是“让模型读表格后回答”，而是“数据先结构化，指标先计算，模型再解释”。这能把模型的不确定性限制在文字表达和归因假设上，把关键数字交给可复核的系统逻辑。

  1. 数据接入与清洗
    从表格、数据库、BI（商业智能）或业务系统读取数据，统一字段名称、时间格式、单位、币种和维度层级。这里可以使用 ETL（抽取转换加载）的思想：先抽取数据，再转换成统一口径，最后加载到分析层。

  2. 指标计算层
    销售额、毛利率、客单价、转化率、库存周转天数、目标达成率等指标由系统计算，不交给模型临时推算。原因是指标必须可复核、可重复、可追溯。

  3. 规则与异常检测层
    把同比、环比、目标偏差、阈值、排名变化、结构占比变化写成规则。智能体可以解释异常，但异常是否触发应由规则和数据共同决定。

  4. RAG（检索增强生成）知识层
    把指标字典、业务口径、历史复盘、经营策略和部门说明纳入检索。模型回答时先查资料，再生成解释，避免凭常识胡编。

  5. 智能体编排层
    Agent（智能体）负责任务拆解：识别用户问题、选择指标、调用查询、读取规则、生成摘要、列出证据、给出下一步排查建议。

  6. 审计与反馈层
    每次输出记录 Trace ID（追踪编号）、数据时间、使用的指标口径、触发的规则和人工反馈。后续复盘时可以知道错在哪里：是数据错、口径错、规则错，还是表达错。

选择这条技术流的原因：它降低模型自由发挥空间，让客户能相信数字，也让项目可以被验收。

字段契约表​

字段契约是数据类项目的底座。没有字段契约，智能体就无法稳定知道某个数字来自哪里、代表什么、是否能用于建议。

字段含义来源校验规则输出要求
metric_id指标编号指标字典必须唯一，不能随意改名输出时可隐藏，但留在审计记录
metric_name指标名称指标字典必须有中文业务解释用户可见
metric_formula指标公式指标字典必须由业务负责人确认解释结论时引用口径摘要
dimension分析维度区域、门店、商品、渠道、客户等必须来自允许维度列表不能生成不存在的维度
time_range统计周期用户问题或默认报表周期必须包含开始与结束日期输出中必须显示
refresh_time数据刷新时间数据接入层不得为空延迟较大时必须提醒
current_value当前值指标计算层必须带单位可用于摘要和异常判断
compare_value对比值指标计算层同比、环比或目标值必须标明不得混用对比口径
variance差异值指标计算层正负方向必须符合业务定义用于说明变化幅度
anomaly_level异常等级规则层建议使用正常、关注、预警、严重高等级必须提示人工确认
evidence证据清单数据查询与规则层每条证据可追溯到数据或规则输出时至少列出关键证据
suggested_action建议动作模型生成后经规则约束不得直接替客户执行高风险动作必须写明假设和确认人
owner_role建议责任角色业务流程必须来自角色表用于后续派单或会议跟进
trace_id（追踪编号）追踪编号系统生成每次输出唯一用于复盘和审计

数据准备​

数据准备要按“指标能复核、异常能回放、建议能解释”的标准来做，而不是只准备一张漂亮表格。一个适合作品集展示的最小数据包，建议包含四类材料。

第一类是指标字典。每个指标要有名称、业务解释、公式、统计周期、单位、维度、负责人、口径争议说明和示例。比如“销售额”要写清是否含税、是否扣退款、是否按下单时间统计；“库存周转天数”要写清库存取期初、期末还是平均库存。

第二类是业务数据样本。至少准备 8 到 12 个报表周期，覆盖正常周期、促销周期、节假日、库存异常、退款异常和数据缺失。样本不需要追求大而全，关键是每条样本能对应到指标字典和异常规则。

第三类是历史复盘材料。收集过去日报、周报、经营会纪要、异常处理记录和负责人批注。它们用来校准模型的表达方式：哪些结论管理层关心，哪些建议太泛，哪些原因必须写成“假设”而不是“定论”。

第四类是验收标注表。把历史报表中的关键异常提前标注出来，包括异常发生时间、异常指标、涉及维度、人工判断原因、当时采取的动作和事后结果。没有这张表，项目验收很容易变成“感觉像不像分析师”。

制作步骤​

1. 选定一个明确的业务切口​

不要一开始就做“企业经营大脑”。更稳的切口是“销售日报解读”“库存预警摘要”“费用异常复盘”“门店经营周报”。切口越清楚，指标、权限、验收样本越容易确定。

作品集里建议选择一个能讲清前后链路的切口，例如“门店销售周报解读”。它既有经营指标，也有异常判断和建议边界，面试官可以追问数据、规则、风险和业务动作。

2. 建指标字典​

指标字典至少包含指标名称、业务解释、计算公式、统计周期、维度、单位、负责人和注意事项。比如“销售额”要说明是否含税、是否扣退款、是否按下单时间还是支付时间统计。

3. 建数据样本和历史案例​

准备几类样本：正常报表、轻微异常、明显异常、数据缺失、口径冲突。历史案例越真实，越能训练智能体输出客户认可的解释风格。

4. 拆分分析任务​

把“分析报表”拆成固定动作：读取数据、计算指标、判断变化、查找异常维度、引用历史说明、生成结论、给出下一步排查问题。每一步都要能单独验收。

5. 设计输出模板​

数据类输出建议固定为六段：结论摘要、关键数字、变化原因假设、证据、风险等级、建议动作。模板固定后，客户才容易把它放进日报、周报和经营会材料。

每段都要限制写法。结论摘要只能引用已计算指标；变化原因必须标注“证据支持”“需要排查”或“资料不足”；建议动作必须写出责任角色和确认条件。这样面试时能说明：你不是让 AI（人工智能）自由写经营建议，而是把建议放进可复核模板。

6. 加权限与敏感信息控制​

区域经理只能看本区域，门店负责人只能看本门店，管理层才能看全局。涉及客户、员工、供应商等敏感字段时，默认只展示汇总，不展示明细。

7. 加失败兜底和人工确认​

数据为空、字段缺失、指标口径冲突、刷新延迟、异常等级过高时，智能体不能硬写结论。它应该说明无法判断的原因，并给出需要补充的信息。

8. 用历史报表验收​

拿过去几个月的真实报表回放，让智能体输出解读，再与人工复盘比较。重点看数字是否准确、异常是否漏报、建议是否越界、表达是否符合管理层阅读习惯。

继续学习​