新品有流量，为什么就是卖不好？

新品有流量，为什么转化仍然落后？

任务要求先建立可比指标，再调查不同解释，交付可以由他人重新计算的结果。没有预先指定“库存就是根因”，也没有要求先做一个应用。

SQLite 数据集包含四个月上市的 600 个合成新品，每个产品上市后 30 天累计共 662,528 次曝光、27,763 个订单；另一张表提供 24 个合成基准组。基准属于测试数据，不是经审核的真实竞品表现。

Polaris 通过真实模型循环读取资料、选择重算方法、生成分析、运行检查，再交给单独的模型会话复核。最终完成记录为 43 次模型调用，没有获得生产实施授权。

分母和匹配条件一样重要。

公司整体转化率用订单总数除以曝光总数。直接平均各产品转化率，会让低流量商品和高流量商品占相同权重，回答的是另一个问题。

每个产品按上市月份、品类、价格带匹配基准，再以该产品曝光量加权。这样保留公司的流量结构，只替换对应组的转化水平。

公司转化率 = SUM(30天订单) / SUM(30天曝光)
匹配基准 = SUM(30天曝光 × 对应基准率) / SUM(30天曝光)
差距（百分点）= 100 ×（公司转化率 − 匹配基准）

直接重算数据库得到公司转化率 4.1904644%，匹配基准 5.6662463%，差距 −1.4757819 个百分点。这些是业务转化率，不是 AI 准确率。

四个月份都存在差距，且逐月扩大。这个计算缩小了调查范围，还没有证明原因。

缺货值得先查，但还不能直接归因。

进一步比较缺货 0–2 天与缺货至少 9 天的商品。低缺货组有 315 个产品、346,806 次曝光、19,757 个订单；高缺货组有 285 个产品、315,722 次曝光、8,006 个订单。

产品组合、配送承诺、价格和内容质量仍可能影响结果。整体基准的公平匹配，不等于这次缺货分组对比也排除了所有混杂因素。产物明确记录 causal_claim: false，保留其他解释。

下一步是用获准使用的真实交易记录重复分析，控制这些因素，再设计受控实验。这是建议继续做的验证，不是本轮已经取得的成果。

分组差距很大，但不能拿来预测增长。

低缺货组的转化率是高缺货组的两倍多，但我们没有把这个比值写成销售预测。“补齐库存就能翻倍”暗含一个前提：两组除了库存之外完全一样。资料没有支持这个前提。

基准匹配和缺货分组也不是同一项计算。匹配月份、品类和价格带，让整体竞品比较更公平，却不会自动让两个缺货组可互换。配送承诺和内容质量仍然可能影响结果。

真要建议补货策略，还得继续问：缺货是否恰好发生在需求高峰？缺货时曝光是否仍然累计？订单和曝光是否来自同一个渠道？这些是具体的后续调查问题，不是汇总夹具已经给出的事实。

因此交付把库存可用性列为优先验证的假设，没有直接要求改补货政策，也没有宣称收入已经恢复。业务负责人既能看到信号，也能看到花钱之前还缺什么证据。

模型说通过，宿主仍然可以退回。

更早的一轮还暴露过夹具错误：验收入口依赖缺失的辅助文件。那次运行停止，没有伪报完成；修复夹具后用新目录重跑，没有把失败记录改写成成功。

实测后，可执行产物的门槛进一步收紧：成功命令必须明确引用交付的可执行文件，不能拿任意一次命令成功代替。这是实验后的工程改进，不追认成原实验已经验证的能力。

结论后面，留下一条可执行的证据链。

交付包括报告、结构化分析和 Python 重算脚本。脚本读取原始表，匹配基准，输出汇总与分组计算；结构化结果保留数据指纹、计算方法、逐月统计、局限和下一步验证。

验收检查保存在模型可写工作区之外。另一个模型会话检查候选产物，由宿主判断证据是否齐备。这种分离有助于阻止无证据的完成声明，但不等于第三方审计或独立人工认证。

运行还发现了兼容接口的问题：旧工具把验证方法记成代码原型，实际交付却是指标重算。新任务现已使用通用的验证规划与执行工具；旧接口只保留给历史状态恢复。

本轮完成的是跨业务场景的可恢复调查和可复算交付，没有验证真实收入增长、行业领先或生产上线效果。实施授权仍为 false。下方公开证据只保留汇总结果；整理本文时再次直接查询了原始数据库，核对关键数字。