毛利率下降，别只写“产品结构影响”：用 SQL、Python 和 AI 建一套订单利润诊断系统

月度经营会上，销售收入增长了，毛利率却从 20% 降到 12%。财务报告写着“产品结构影响”，业务说是原材料涨价，采购认为主要是销售折扣，生产又指出小批量订单增加。每个人都说了一部分事实，但没有人能证明各因素究竟影响了多少。

传统做法是继续拉 Excel、开会问原因。更进一步的做法，是把这件事做成一套订单利润诊断系统：SQL 负责建立可追溯的利润事实，Python 负责完成可复算的差异拆解，AI 负责在受控数据上组织追问、证据与行动。

这套系统必须同时通过两张成绩单：财务指标说明利润发生了什么，技术指标证明这份结论值得相信。

一、先定一条规则：技术指标不过关，财务结论不发布

毛利率精确到小数点后两位，不代表结论准确。如果订单与成本只匹配了 87%，或者总账收入与分析底表差了 300 万，AI 写得再流畅也不能发布原因判断。因此我会把经营指标和工程质量指标放到同一张验收表。

这里的阈值不是通用标准，而是一个可讨论的起点。关键是把“数据还行”“大致能对上”改成可测量的发布条件。红灯亮起时，系统输出的是数据待办，而不是经营原因。

二、财务指标先分层，避免一个“毛利”讲三件事

订单诊断至少保留三层利润。第一层是会计毛利，用于和总账勾稽；第二层是贡献利润，用于判断多卖一笔订单是否继续创造价值；第三层是订单利润，用于观察客户和渠道承担分摊费用后的完整贡献。

同时保留毛利率、贡献利润率、负毛利订单占比、低于价格底线订单占比和利润前后 20 名客户集中度。这样既能看总结果，也能看利润质量。分摊费用必须保存规则版本，不能把管理规则伪装成原始交易事实。

三、SQL 不只是取数，要建立可追溯的利润语义层

订单、收入、成本和费用通常来自不同系统。第一项技术工作不是让 AI 自由写 SQL，而是先用 SQL 建一张稳定的订单利润视图。下面是一个简化结构，实际项目需要根据数据库方言和成本核算方式调整。

CREATE VIEW mart_order_profit AS
WITH revenue AS (
    SELECT
        order_line_id,
        customer_id,
        product_id,
        sales_date,
        MAX(data_updated_at) AS data_updated_at,
        SUM(gross_amount - discount_amount
            - return_amount - rebate_amount) AS net_revenue
    FROM dwd_order_line
    GROUP BY order_line_id, customer_id, product_id, sales_date
),
cost AS (
    SELECT
        order_line_id,
        SUM(CASE WHEN cost_type = 'material' THEN amount ELSE 0 END) AS material_cost,
        SUM(CASE WHEN cost_type = 'labor' THEN amount ELSE 0 END) AS labor_cost,
        SUM(CASE WHEN cost_type = 'manufacturing' THEN amount ELSE 0 END) AS manufacturing_cost,
        SUM(CASE WHEN cost_type = 'logistics' THEN amount ELSE 0 END) AS logistics_cost,
        SUM(CASE WHEN cost_type = 'commission' THEN amount ELSE 0 END) AS commission_cost,
        SUM(CASE WHEN cost_type = 'allocated' THEN amount ELSE 0 END) AS allocated_cost
    FROM dwd_order_cost
    GROUP BY order_line_id
)
SELECT
    r.*,
    c.*,
    r.net_revenue
      - COALESCE(c.material_cost, 0)
      - COALESCE(c.labor_cost, 0)
      - COALESCE(c.manufacturing_cost, 0) AS accounting_gross_profit,
    r.net_revenue
      - COALESCE(c.material_cost, 0)
      - COALESCE(c.labor_cost, 0)
      - COALESCE(c.manufacturing_cost, 0)
      - COALESCE(c.logistics_cost, 0)
      - COALESCE(c.commission_cost, 0) AS contribution_profit
FROM revenue r
LEFT JOIN cost c ON r.order_line_id = c.order_line_id;

视图里必须保留订单行号、客户、产品、组织、业务日期、源系统和数据批次。用户点击“材料成本影响 260 万”时，系统应该能继续返回构成这笔金额的订单、领料单和采购记录。

四、再写一组 SQL，专门证明底表能不能用

业务查询和质量查询应该分开。前者回答利润问题，后者回答“这份利润数据能否进入分析”。每天刷新后先跑质量门禁，再决定是否更新看板和触发 AI。

SELECT
    COUNT(*) AS order_line_count,
    SUM(CASE WHEN material_cost IS NULL THEN 1 ELSE 0 END) AS unmatched_cost_lines,
    SUM(CASE WHEN net_revenue IS NULL THEN 1 ELSE 0 END) AS missing_revenue_lines,
    COUNT(DISTINCT order_line_id) AS distinct_order_lines,
    MAX(data_updated_at) AS latest_data_time
FROM mart_order_profit;

-- 勾稽结果必须单独落表，保留批次和运行时间
SELECT
    analysis_month,
    mart_revenue,
    gl_revenue,
    ABS(mart_revenue - gl_revenue) / NULLIF(gl_revenue, 0) AS revenue_diff_rate,
    mart_cost,
    gl_cost,
    ABS(mart_cost - gl_cost) / NULLIF(gl_cost, 0) AS cost_diff_rate
FROM audit_profit_reconciliation;

技术看板至少显示：收入和成本勾稽差异率、订单成本匹配率、重复主键数、数据新鲜度、SQL 执行时间以及规则版本。只有这些指标为绿灯，后续的利润桥才有意义。

五、Python 负责量化价格、销量结构和成本影响

SQL 适合清洗、关联和汇总，Python 更适合批量计算基期与本期的因素影响、处理新旧产品集合，并对分解结果做自动复算。下面的示例按产品建立一座利润桥，把销量与结构放在同一影响项中。

import pandas as pd

base = pd.read_parquet("order_profit_2026_07.parquet")
curr = pd.read_parquet("order_profit_2026_08.parquet")

def summarize(df, prefix):
    result = (
        df.groupby("product_id", as_index=False)
          .agg(qty=("quantity", "sum"),
               revenue=("net_revenue", "sum"),
               cost=("controllable_cost", "sum"),
               profit=("contribution_profit", "sum"))
    )
    result["price"] = result["revenue"] / result["qty"].where(result["qty"].ne(0))
    result["unit_cost"] = result["cost"] / result["qty"].where(result["qty"].ne(0))
    return result.add_prefix(f"{prefix}_").rename(
        columns={f"{prefix}_product_id": "product_id"}
    )

bridge = summarize(base, "base").merge(
    summarize(curr, "curr"), on="product_id", how="outer"
).fillna(0)

bridge["price_effect"] = (
    bridge["curr_price"] - bridge["base_price"]
) * bridge["curr_qty"]

bridge["volume_mix_effect"] = (
    bridge["curr_qty"] - bridge["base_qty"]
) * (bridge["base_price"] - bridge["base_unit_cost"])

bridge["cost_effect"] = -(
    bridge["curr_unit_cost"] - bridge["base_unit_cost"]
) * bridge["curr_qty"]

actual_change = curr["contribution_profit"].sum() - base["contribution_profit"].sum()
known_change = bridge[["price_effect", "volume_mix_effect", "cost_effect"]].sum().sum()
other_effect = actual_change - known_change

assert abs(actual_change - known_change - other_effect) < 0.01

最后一行不是装饰。每次运行都要验证各影响项与实际利润变化相等，未解释差异单独进入 other_effect，不能悄悄摊进“结构影响”。继续拆材料、人工、物流和返利时，也沿用同样的复算规则。

六、AI 不负责算利润，它负责选择工具和整理证据

这套系统里，AI 不直接读取生产库，也不对几十万行明细心算。它只能访问白名单视图和固定工具：指标 API 返回已审核指标，SQL 工具下钻具体订单，Python 工具运行利润桥，文档检索读取合同与价格审批。

问题：本月毛利率为什么从 20% 降到 12%？

AI 执行顺序：
1. 读取 metric_version=gross_margin_v3 的本期、基期结果；
2. 检查 reconciliation_status，非 PASS 时立即停止；
3. 调用 profit_bridge.py，取得价格、结构和成本影响；
4. 对影响最大的订单调用只读 SQL 下钻；
5. 读取合同、报价审批、采购价和工时记录；
6. 只把有 evidence_id 的原因标记为“已验证”；
7. 输出责任角色、待确认问题和复盘日期。

AI 的正式输出也不应只有一段文字，而要遵守结构化协议。至少包含指标版本、数据批次、影响金额、影响百分点、订单列表、证据编号、验证状态、责任角色和未解释差异。缺少证据的内容只能叫“待验证假设”。

七、财务指标与技术指标，应该出现在同一张诊断单上

假设本月毛利率从 20% 降至 12%，利润桥将 80 万元负向影响拆成：价格 18 万、产品与客户结构 15 万、材料成本 26 万、人工效率 12 万、物流佣金 6 万、退货及其他 3 万。

这还不是一份可以发布的结论。系统同时给出第二组数字：

两组指标同时通过后，系统才发布原因。继续下钻发现，前 18 笔订单贡献了负向影响的 61%：其中续约折扣越权、核心材料采购价上涨、小批量急单的单位运费增加是三个已验证原因。相比一句“产品结构影响”，这份诊断已经可以直接进入业务动作。

八、用 SQL 把异常变成每天运行的监控任务

月末分析完成后，不应等到下个月再看同一问题。把已经验证的规则固化成异常 SQL，每天只把例外订单推给负责人。

SELECT
    order_line_id,
    p.customer_id,
    p.product_id,
    p.net_revenue,
    p.contribution_profit,
    p.contribution_profit / NULLIF(p.net_revenue, 0) AS contribution_margin
FROM mart_order_profit p
JOIN dim_product_profit_rule r
  ON p.product_id = r.product_id
WHERE p.sales_date >= CURRENT_DATE - INTERVAL '7 day'
  AND (
       p.contribution_profit < 0
       OR p.contribution_profit / NULLIF(p.net_revenue, 0) < r.approved_margin_floor
       OR p.material_cost / NULLIF(p.net_revenue, 0) > r.material_cost_rate_p90
  )
ORDER BY p.contribution_profit ASC;

财务监控低价订单占比、材料成本率、单位工时和单票运费；技术侧同时监控任务成功率、数据延迟、SQL 耗时、异常数量突变和通知送达率。业务指标变坏要找经营原因，技术指标变坏要先修分析链路，两者不能混为一谈。

九、四周落地，交付物不是一张看板

最终交付应该包含指标字典、SQL 语义视图、数据质量门禁、Python 拆解脚本、AI 输出协议、异常任务表和监控看板。看板只是观察窗口，真正的系统在它背后运行。

十、最后

财务分析最容易被低估的技术含量，不是会不会写一条 SQL，而是能不能把会计口径、业务主键、计算逻辑、数据质量和管理动作连起来。SQL 让每个数字能回到订单，Python 让每项影响能够复算，AI 让复杂的查询与证据更容易被业务使用。

下一次再看到“毛利率下降，主要受产品结构影响”，不妨继续追问两组问题：究竟影响了多少、落在哪些订单；数据匹配率是多少、分解结果能不能复算。两组问题都有答案，才是一份经得住追问的订单利润诊断。