Cursor + Agent 从 0 到 1：把数仓「教」给 AI 的实操手册

像豆芽一样优秀

403人浏览 · 2026-08-20 16:47:39

像豆芽一样优秀 · 2026-08-20 16:47:39 发布

姊妹篇《给数仓装一个「长期记忆」》讲的是：Skill / Reference / SQL 各自是什么、怎么分工。
本稿只讲一件事：从空目录到第一套可用知识资产，你要按什么顺序做、怎么验收、覆盖哪些面。
文中示例均为虚构通用名（如 dwd_order、dim_store），不绑定具体公司；可套用到 Hive / Spark / MaxCompute / Snowflake / BigQuery 等。

0. 先说清：这篇和「体系篇」有什么不同

	体系篇（长期记忆）	本篇（从 0 到 1）
读者状态	已决定要建知识库	还没动手 / 刚动手
核心问题	资产如何分层、写什么	第一周先做哪几步
写法	说明书 + 模板	路径 + 示例 + 验收
你会带走	架构共识	可复制片段与 checklist

若两篇都读：先跟本篇落地，再回体系篇把文档写厚。

1. 从 0 到 1 的成功标准（先立靶）

不要以「文档写了多少字」为目标。七天后只要同时满足下面四条，就算成功：

工程不翻车：分区过滤、调度参数、幂等写入成为默认习惯
口径不瞎猜：至少有一张「场景 → 表 → 时间字段 → 过滤」矩阵
关联不发散：默认 JOIN 键、禁用/慎用路径写清楚
有闭环样板：至少一个业务主题的 SQL + README 落在仓库里

AI 负责快，人负责对；从 0 到 1 的产物是「能审的初稿」，不是「零修改终稿」。

2. Day 0：搭骨架（2 小时内完成）

2.1 推荐目录（通用）

dw-ai-knowledge/
├── .cursor/
│   ├── skills/
│   │   └── data-warehouse/
│   │       ├── SKILL.md         # 短：规则、速查、反模式
│   │       └── reference.md     # 长：字典、枚举、模板
│   └── rules/                   # 可选：全局短规则
├── sql/
│   └── order_gmv_daily/         # 示例主题名，按你们业务改
│       ├── README.md
│       └── dws_trd_store_gmv_d.sql
├── tools/
└── docs/

2.2 Skill 触发词示例（description）

---
name: data-warehouse
description: >-
  公司数仓开发规范。适用于写/改离线 SQL、分层建模、调度作业。
  触发词：dwd_ dws_ dm_ dim_ ods_ 分区 ds 业务日期 bizdate
  订单 支付 退款 GMV 门店 会员。
---

触发词太虚（只写「大数据」）→ Agent 经常不加载；写上分层前缀和业务黑话更稳。

2.3 Day 0 验收

随口提：「帮我写一条门店日 GMV 汇总」。若 Agent 开始读 SKILL.md，骨架就算通了。

3. Day 1：工程铁律（让 Agent「不乱写」）

3.1 可直接粘贴的 Skill 片段

## 环境
- 开发库：dw_dev；生产库：dw_prod
- INSERT 目标表不加库前缀；DDL 如需可写两套

## 分区与调度
- 分区字段：ds，格式 yyyyMMdd
- 必须：WHERE ds = '${bizdate}'
- 禁止：WHERE ds = '20240101'

## 写入
- 日作业默认 INSERT OVERWRITE ... PARTITION (ds='${bizdate}')
- INSERT 必须显式列清单，禁止 SELECT *

## 金额与比率
- 明细贴源常见最小货币单位（分）；入 DWS/DM 转为元，DECIMAL(18,2)
- 比率 DECIMAL(18,4)

## 反模式
- 分区大表不滤 ds
- 用统计合并键替代默认业务键（未确认时）
- 跨环境项目名写死在 SQL 里

3.2 示例：同一需求，Agent 改前 / 改后

需求：「把昨日订单写入 DWD 分区。」

改前（典型翻车）：

INSERT INTO dw_prod.dwd_order
SELECT * FROM ods_order
WHERE create_time >= '2024-01-01';

问题：串环境、无分区覆盖语义、SELECT *、硬编码日期、时间字段可能也不对。

改后（符合铁律）：

INSERT OVERWRITE TABLE dwd_order PARTITION (ds = '${bizdate}')
SELECT
    order_id
    ,store_id
    ,user_id
    ,CAST(pay_amount / 100.0 AS DECIMAL(18, 2)) AS pay_amount
    ,pay_time
    ,is_test
FROM ods_order
WHERE ds = '${bizdate}'
  AND order_id IS NOT NULL
;

验收： 再让 Agent 写一条类似加载，看它是否自觉带上 ds、显式列、参数化日期。

4. Day 2：主数据与关联（附 Reference 示例）

4.1 维表条目示例（写「决策信息」，别抄全量 DDL）

## dim_store — 门店维度

- 粒度：1 店 1 行 / 日全量（ds）
- 默认 JOIN：store_id
- 报表对外编码：store_code（勿用内部自增 id 对外）
- 组织：region_id / region_name，company_id / company_name（行上冗余）
- 常用过滤：status = 1 AND is_deleted = false
- 慎用：stat_store_id 仅统计合并场景；默认不要拿它替 store_id

## dim_date — 日期维度

- 无分区；用 ds 或 date_key 关联
- 提供月/周/年起始日字段，供 MTD/YTD 窗口

4.2 发散 JOIN 示例（务必写进「禁止/慎用」）

错误（一对多放大 GMV）：

-- dim_store_sku_hist 一个 store 对应多行历史
SELECT s.store_id, SUM(f.gmv) AS gmv
FROM dws_store_gmv_d f
JOIN dim_store_sku_hist s
  ON f.store_id = s.store_id   -- 未限定生效区间 / 未去重
WHERE f.ds = '${bizdate}'
GROUP BY s.store_id
;

正确思路（示例）： 先对维表按业务键去重或限定有效期，再关联；或改用当前有效维表。

WITH store_one AS (
    SELECT store_id, store_code, region_id
    FROM dim_store
    WHERE ds = '${bizdate}'
      AND status = 1
    -- 若仍可能重复，加 QUALIFY / ROW_NUMBER 去重
)
SELECT ...
FROM dws_store_gmv_d f
JOIN store_one s ON f.store_id = s.store_id
WHERE f.ds = '${bizdate}'
;

验收： 让 Agent 做「门店 × 销售」，抽查行数是否被维表放大。

5. Day 3：第一个主题闭环（README + SQL 示例）

假设主题：sql/order_gmv_daily/（门店日 GMV）。

5.1 README 示例

# 主题：门店日 GMV

## 粒度
- store_id × ds

## 链路
ods_order_pay → dwd_order → dws_trd_store_gmv_d

## 窗口
- 日快照：事件时间 ∈ [bizdate, bizdate+1)

## 口径（定稿）
- 金额：支付净额（已支付 − 已退），入表单位元
- 剔除：is_test = true
- 时间字段：pay_time（不用 create_time）

## 已知差异
- 与经营看板差异：看板含未支付意向单，本链路不含（待对齐）

5.2 窗口 + 汇总 SQL 示例（示意）

-- dws_trd_store_gmv_d | 门店日 GMV | 上游 dwd_order
WITH date_bound AS (
    SELECT
        TO_DATE('${bizdate}', 'yyyyMMdd') AS start_cal
        ,DATEADD(TO_DATE('${bizdate}', 'yyyyMMdd'), 1, 'dd') AS end_cal
)
INSERT OVERWRITE TABLE dws_trd_store_gmv_d PARTITION (ds = '${bizdate}')
SELECT  /*+ MAPJOIN(db) */
    o.store_id
    ,CAST(SUM(o.pay_amount - o.refund_amount) AS DECIMAL(18, 2)) AS gmv
    ,COUNT(DISTINCT o.order_id) AS order_cnt
FROM dwd_order o
CROSS JOIN date_bound db
WHERE o.ds = '${bizdate}'   -- 或按你们明细分区策略调整
  AND o.pay_time >= db.start_cal
  AND o.pay_time <  db.end_cal
  AND COALESCE(o.is_test, false) = false
GROUP BY o.store_id
;

半开区间 [start, end) 能避免末日边界重复计数，建议在 Skill 里写死这一种。

验收： 只改 ${bizdate}，逻辑无需改；同事只看 README 能复述口径。

6. Day 4～5：选用矩阵（带「错误示范」）

6.1 矩阵示例（请替换成你们真实表名）

分析意图	用表	时间字段	默认过滤
订单量 / 订单金额	`dwd_order`	`first_pay_time`	`is_test = false`
商品 / SKU 销售	`dwd_order_item`	`item_pay_time`	同上
支付退款净额	`dwd_pay_refund_flow`	`trade_time`	同上；看板口径另议
活动归因订单	`dwd_mkt_campaign_order`	`trade_time`	按活动有效期

6.2 错误示范：一张表打天下

用户：「看上周销售净额。」
Agent（未教矩阵时）常见写法： 用订单表的 create_time 汇总 pay_amount。

可能错在：

时间该用流水 trade_time，不是下单时间
净额该用支付退款事实，不是订单应付
未剔测试单

教过矩阵之后的提示词可以很短：

按选用矩阵：销售净额 → 支付退款流水 + trade_time + 剔测试。

验收： 分别说「订单量 / 商品件数 / 净额」三个需求，Agent 应换三套表与时间字段。

7. Day 6：口径治理示例（定稿 / 待定 / 禁止）

7.1 Reference 三区示例

## 定稿
- GMV = 已支付金额 − 已退款金额；单位元
- 统计时间：pay_time；窗口半开区间

## 待确认
- 是否包含虚拟门店（is_virtual = true）？当前临时：排除，待业务确认

## 禁止 / 已知坑
- 禁止用 create_time 替代 pay_time 做支付统计
- 禁止未去重的「门店-商品历史维」直接 JOIN 事实（会放大）
- 与财务应收口径不一致：本链路是支付净额，不是开票金额

7.2 枚举表示例（减少幻觉）

## order_status
| 值 | 含义 |
|----|------|
| 1 | 待支付 |
| 2 | 已支付 |
| 3 | 已取消 |
| 4 | 已完成 |

未在表中的状态：不要猜测，先标「待确认」。

规则： 争论结束当天改这三区；只改聊天 = 没沉淀。

8. Day 7：对比验收示例 + 扩展面

8.1 同一需求的 A/B 记录（建议你们也建一张）

需求原文：「统计 ${bizdate} 当日各门店 GMV 与订单数，剔测试。」

检查项	无 Skill 初稿	有 Skill 初稿
滤分区	常无	有
时间字段	create_time	pay_time
金额单位	常忘 /100	有 CAST 到元
剔测试	常漏	有
人工修改	大段重写	对一下样本即可

把「无 Skill 时仍错的点」追加进反模式，文档就产生复利。

8.2 扩展面示例（第一周后）

面	小例子
血缘热度	下游依赖最多的 20 张表，优先写进 Reference
质量	「同一 ds 下 order_id 唯一」「分区行数不为 0」
报表映射	表头「门店名称」↔ `store_name`，「统计月份」↔ `SUBSTR(ds,5,2)`
回归集	固定 5 条需求，每月跑一次看 Skill 是否被改坏

9. 全覆盖检查清单（贴墙上用）

从 0 到 1 至少勾掉加粗项：

工程与规范

环境 / 分层 / 命名 / 分区 / 调度参数
写入幂等与反模式
代码评审清单、发布注意事项

数据语义

核心维表 JOIN 与慎用路径
至少一张跨域选用矩阵
主要枚举值表
金额 / 比率 / 时间口径专章

资产形态

Skill（短）+ Reference（长）
至少一个主题 SQL + README
多主题样板
工具脚本与质量规则

协作机制

口径回写约定
定期回归需求集
新人只读路径（先读哪三份文件）

10. 五个坑（配一句反例）

第一周抄全库 DDL → 写不完；先写「选用矩阵 + 10 张高频表决策信息」
Skill 写成小作文 → Agent 抓不住；改成表格 / 禁止清单
口径只存在聊天里 → 新会话继续错；必须进 Git
有 SQL 无 README → 三个月后连自己都忘窗口是否含期末
和体系篇重复讲概念 → 读者觉得两篇一样；本篇专注步骤与示例

11. 今晚 90 分钟最小闭环（按分钟执行）

0–20：建目录；粘贴第 3 节 Skill 片段；改环境名
20–40：写 dim_store / 日期维两条 Reference（照第 4 节）
40–60：填 3 行选用矩阵（订单 / 明细 / 流水）
60–80：建 sql/order_gmv_daily/，粘贴 README + SQL 骨架并改成你们表名
80–90：对 Agent 说需求，对比是否滤 ds、是否用对时间字段；把错点写进反模式

结语

从 0 到 1 的本质，不是让模型变聪明，而是：

把「怎么才算写对数仓 SQL」变成可加载、可 diff、可验收的团队资产。

体系篇回答「房子怎么设计」；
本篇回答「第一周先打哪几根桩」——并给了可抄的桩基示例。

桩打稳了，再往 Reference 里填砖，才不会盖成纸糊的百科全书。

系列建议：① 本篇（落地路径 + 示例）→ ② 体系篇（长期记忆）→ ③ 用血缘/热度反哺高频对象 → ④ 单主题 Agent 协作实录。

Cursor + Agent 从 0 到 1：把数仓「教」给 AI 的实操手册

像豆芽一样优秀

0. 先说清：这篇和「体系篇」有什么不同

1. 从 0 到 1 的成功标准（先立靶）

2. Day 0：搭骨架（2 小时内完成）

2.1 推荐目录（通用）

2.2 Skill 触发词示例（description）

2.3 Day 0 验收

3. Day 1：工程铁律（让 Agent「不乱写」）

3.1 可直接粘贴的 Skill 片段

3.2 示例：同一需求，Agent 改前 / 改后

4. Day 2：主数据与关联（附 Reference 示例）

4.1 维表条目示例（写「决策信息」，别抄全量 DDL）

4.2 发散 JOIN 示例（务必写进「禁止/慎用」）

5. Day 3：第一个主题闭环（README + SQL 示例）

5.1 README 示例

5.2 窗口 + 汇总 SQL 示例（示意）

6. Day 4～5：选用矩阵（带「错误示范」）

6.1 矩阵示例（请替换成你们真实表名）

6.2 错误示范：一张表打天下

7. Day 6：口径治理示例（定稿 / 待定 / 禁止）

7.1 Reference 三区示例

7.2 枚举表示例（减少幻觉）

8. Day 7：对比验收示例 + 扩展面

8.1 同一需求的 A/B 记录（建议你们也建一张）

8.2 扩展面示例（第一周后）

9. 全覆盖检查清单（贴墙上用）

10. 五个坑（配一句反例）

11. 今晚 90 分钟最小闭环（按分钟执行）

结语

相关内容

所有评论(0)

像豆芽一样优秀

Cursor + Agent 从 0 到 1：把数仓「教」给 AI 的实操手册

像豆芽一样优秀

0. 先说清：这篇和「体系篇」有什么不同

1. 从 0 到 1 的成功标准（先立靶）

2. Day 0：搭骨架（2 小时内完成）

2.1 推荐目录（通用）

2.2 Skill 触发词示例（description）

2.3 Day 0 验收

3. Day 1：工程铁律（让 Agent「不乱写」）

3.1 可直接粘贴的 Skill 片段

3.2 示例：同一需求，Agent 改前 / 改后

4. Day 2：主数据与关联（附 Reference 示例）

4.1 维表条目示例（写「决策信息」，别抄全量 DDL）

4.2 发散 JOIN 示例（务必写进「禁止/慎用」）

5. Day 3：第一个主题闭环（README + SQL 示例）

5.1 README 示例

5.2 窗口 + 汇总 SQL 示例（示意）

6. Day 4～5：选用矩阵（带「错误示范」）

6.1 矩阵示例（请替换成你们真实表名）

6.2 错误示范：一张表打天下

7. Day 6：口径治理示例（定稿 / 待定 / 禁止）

7.1 Reference 三区示例

7.2 枚举表示例（减少幻觉）

8. Day 7：对比验收示例 + 扩展面

8.1 同一需求的 A/B 记录（建议你们也建一张）

8.2 扩展面示例（第一周后）

9. 全覆盖检查清单（贴墙上用）

10. 五个坑（配一句反例）

11. 今晚 90 分钟最小闭环（按分钟执行）

结语

相关内容

所有评论(0)

温馨提示：您尚未绑定手机号

像豆芽一样优秀