京东：一份销售计划怎样接上SOP、查询、计算与任务更新

“为电脑部门生成11月销售计划”，是一项经营要求，不是一项能直接执行的计算。京东作者的论文把它接成了几次具体交接：检索部门已有做法，形成任务清单，查询数据并分析，再把观察放回编排上下文，决定下一步。最后的计划能否成立，要逐个检查这些交接，而不能只看文字是否完整。

论文正文描述框架，附录用一段说明性演示给出输入输出。下面沿这项原例展开；它不是公开生产日志，也没有完整展示最终目标的预测计算。可直接学习的是方法、数据、工具和任务状态怎样连接。

SOP进入提示词，决定先研究什么

电脑部门的销售规划标准作业程序，也就是 SOP，要求比较往年同期与近期的销售、流量、用户增长，辨认季节、促销及外部事件，再形成下一时期计划。它给出分析方法，并不提供本期销量。

附录明确说，检索到的 SOP 被放入任务规划提示词，替换对应占位内容。组织做法因此参与生成工作清单，而不只是作为答案末尾的参考链接。系统识别这是计划生成请求，列出三项任务：部门自身分析、市场与行业分析、最终计划；先执行部门分析。论文v2附录，PDF第32–33页

知识链与事实链在这里分开。论文图3描述先分析文档格式与内容，分块及问答预处理后构造稠密、稀疏表示；查询经过混合检索、合并与重排，相关内容进入模型上下文。附录只披露本次取到了部门 SOP，没有给命中文档版本、分数和具体检索轨迹。因此这条知识链能解释方法来源，不能代替销售数据库。

基础模型还使用短期上下文保持当前对话和执行结果，长期记忆保留偏好、历史决定与已有结果；领域知识及微调提供专业支持。论文没有给出可复现的模型权重、训练集和各角色部署配置。能确认的是职责怎样相接，不能由角色数推断必须部署同样多的模型服务。论文§3.2、图2–3

先把业务范围接到正确的维度和查询

论文在查询前区分两项语义工作：切分和过滤原话中的实体、动作；再将信息归到品牌、品类、时间等槽位。数据获取部分进一步把槽位表示与业务维度匹配：维度向量库支持相似词与字段的关联，API数据库保存调用所需的参数和接口信息；生成式模型辅助提出缺失或低置信度槽位的候选值。

这一步容易被一句“自然语言转SQL”掩盖。原文用销售词与收入字段的关联说明语义匹配，但词语相近并不保证企业指标可互换。部门、时期、金额或数量的口径一旦错了，后续查询可以合法执行，回答的却是另一个问题。

图4还有一处可见的例图不一致：问题包含两个不同品牌及“昨天”，结构化输出却重复了同一品牌，且没有显示时间字段。这是论文例图中的问题，不是已证实的生产事故；它提醒我们检查用户范围是否完整传递，而不只检查结构有没有生成。论文§3.3、§3.5.1、图4

当前任务怎样交给SQL，再交给数据分析

数据获取角色收到的不是整项月度规划，而是第一项部门历史与近期分析。附录查询按年、月汇总销售、页面浏览和用户计数，来源表是销售表，并包含下面的条件节选：

WHERE order_date >= sysdate(-730)
AND dept_id = 'Computer'

这是论文第33页原查询的条件部分，仅把排版弯引号还原为代码单引号，不是一段可独立执行的完整查询。部门条件对应请求中的电脑部门，日期条件提供历史窗口，年、月分组决定分析粒度。查询结果整理为 pandas DataFrame，也就是供程序处理的表格对象，再交给分析角色。附录数据获取输入输出

这暴露了一个真正的工程接口：下游获得的是有字段和粒度的结构化数据，不只是“数据库查完了”的文字。附录未展示实际数据行、SQL方言和查询截至时间。用户计数能否跨行相加，还取决于源表粒度和去重定义；仅凭字段名不能推断已经具备留存分析数据。

四种原子操作与专业算法各做什么

分析角色并非始终自由生成整段程序。论文图6公开的提示词提供输入表描述，要求围绕筛选行、变换列、分组、排序四种原子操作逐步生成代码，每次形成一个步骤，最后声明结果表。图6明确把输入表命名为 df，把最终输出表命名为 result_df；这是分析步骤接收和交付数据的合同，而不是让每个步骤随意另起一套输入输出。原图使用的操作名为 Filter Rows、Transform Columns、Groupby、Sort。

这种设计把“分析”拆到了能检查中间产物的位置：范围错可以查筛选条件，聚合错可以查分组粒度，派生指标错可以查列变换，最终文字错则查结果转述。这里是对其模块关系的解释；附录没有公开这项11月计划逐步执行了哪组操作或完整中间表，不能补成一次实际运行轨迹。

需要既定数学精度时，任务执行器还可通过函数调用转向预先验证的算法工具，例如时间序列预测、库存优化。模型负责组织分析和调用，专业算法处理数值问题；四种表格操作并不承担全部预测与优化。

论文主张原子步骤改善可审计性、生成负担和可靠性，但没有提供这些架构收益的独立消融实验。提示词列出允许操作，也不能替代执行沙箱、权限和资源限制；这些生产控制的源码及参数尚未公开。论文§3.5.2、图6

观察必须改变剩下的工作，而不只进入最终摘要

公开的编排提示词同时保留原问题、初始任务清单、下一任务、观察和最终答案。执行结果回到观察位置后，模型重新判断剩下做什么；这些输入输出构成任务内的控制协议。

附录展示了一次具体更新。第一轮部门分析输出销售季节性、近期流量、用户变化及潜在驱动等观察。更新时同时输入原始问题、原三项清单、刚执行的部门分析及新观察；输出删去第一项，留下市场/行业分析和最终计划，下一项转向市场/行业分析。论文图5；附录第34–35页

正文允许删减、重排或增加任务；这次附录实际展示的是删去已完成项。循环以任务全部完成为终点，但每项的形式化完成判据、空数据怎样表达、查询失败怎样保留、重试上限与接管规则没有完整公开。

这会影响迁移验收：如果把“工具返回一段文字”当完成信号，错误分析也可能被删出任务清单。应另外要求执行结果能区分已有依据、资料不足和运行失败；这是本文给迁移团队的接口建议。

还要检查观察本身的证据。附录给出“老用户留存较强”和竞品等销售驱动的分析输出，但展示的查询只有月度销售、流量和用户计数，未展示用户群组、留存计算或外部驱动识别。因此这些结论确实出现在演示里，结论所需的全部证据却尚未展示。

可横向查看，点击打开原尺寸 ↗

据论文 v2 附录及图5、图6重绘；附录任务是示意，原子工具属于公开框架，不能据此补出最终销售目标的计算。

形成目标之后，还有另一种纠偏

附录最终给出约1.2亿元月度目标、约15%增长预期和促销预算增加150%的建议。这是可以交给规划人员讨论的目标与行动提案；公开演示没有展示市场分析的完整输出、促销响应模型或三个数字的完整推导，也没有展示预算获批或写入业务系统。

正文另描述方案实施后的计划纠偏：持续比较实际每日销售等指标与计划，识别流量、促销表现或市场变化造成的偏离，再提出更新建议。它与前面的任务更新不同：前者发生在形成方案期间，观察分析工作做到哪；后者发生在方案实施之后，观察业务是否按计划发生。论文没有公布这份1.2亿元计划的后续日销售、预警阈值、修改版本和恢复结果。论文§3.6–3.7及附录最终输出

生产证据要和附录演示分开判断

作者报告框架自2023年12月部署并持续迭代，实证样本来自粮油、母婴、小家电三个单元的七万多个商品。电脑部门是讲机制的演示对象，不是这批业务评估样本。

2024年5—6月与前一年同期比较中，作者称“基于周末库存值、偏差低于5%的计划占比”提高22%；活跃商品—配送中心组合中日终库存为正的比例高于历史人工基线约2%。论文未明确这些增幅是相对变化还是百分点；库存比例也不是订单履约率。购物节约200万元GMV增量属于作者估计，缺可重算的归因过程。

时间结果能支持准备工作发生变化，但不能直接得出完整规划周期节省95.8%：人工基线120分钟包含取数20、处理40、分析60分钟；新流程五分钟是描述需求，分析仍转为交互会话。同比对照还不能排除促销、品类和其他库存政策的影响。论文§4，第25–26页

迁移前，沿一个数字和一次更新检查

适合的起点是企业已有稳定规划方法、数据定义和可调用算法，缺少的是把它们接成可讨论的工作。如果只是每月按固定公式更新报表，参数化报表可能更易验收；需要反复加入市场假设、比较情景并解释差异时，动态编排才有额外空间。

用一项已做过且获准使用的计划，保留当时请求、SOP版本、数据快照、查询、分析结果和最终方案。业务负责人核目标与预算，数据人员核范围、粒度及口径，算法人员核模型和约束，应用团队核任务更新与错误传递。

重点追两件事：计划中的一个数字能否回到认可的查询或计算；一次资料不足或计算失败会不会在清单更新中被错误标成完成。再分别计取数、分析、审阅和返工时间。先证明助手帮助形成了可用计划，随后才讨论批准后的业务集成和实际收益。