| name | table-design-advisor |
| description | Use when designing or reviewing a data warehouse table schema. Advises on warehouse layer, table grain, fact or dimension modeling, fields, primary key, partitioning, update strategy, lifecycle, naming, downstream usage, and data quality checks. |
Table Design Advisor
目标
设计或审查一张数据表，使它的业务粒度、字段结构、更新策略和下游使用方式清晰可靠。
这个 Skill 适用于数仓建模和数据开发中的表设计。它不强制某一种公司规范，但会显式说明设计假设。
使用场景
使用这个 Skill，当用户需要：
- 新建 ODS、DWD、DWS、ADS 表
- 设计事实表、维表、明细表、汇总表或宽表
- 审查已有表结构是否合理
- 判断表粒度、主键、分区、更新方式
- 为看板、指标、推荐、风控、运营分析等场景设计数据集
- 将临时 SQL 产出沉淀成可维护的数据表
典型输入：
我要做一张用户首购转化明细表，给渠道看板使用。
帮我审查这张订单宽表设计是否合理。
不适用场景
不要用这个 Skill 直接完成：
- 模糊需求澄清，请使用
data-requirement-clarifier
- 指标口径审查，请使用
metric-definition-reviewer
- SQL 审查，请使用
sql-reviewer
- 数据质量规则生成，请使用
data-quality-rule-generator
如果业务口径尚未明确，先输出设计假设和待确认问题，不要直接生成确定方案。
输入信息
最少输入：
可选输入：
- 指标口径
- 查询场景
- 上游表
- 下游看板或任务
- 数据量级
- 更新频率
- 数据延迟要求
- 保留周期
- 执行引擎
- 公司命名规范
上下文建议
推荐使用 表设计上下文模板。
最有价值的上下文是：表服务的业务场景、数据粒度、上游数据、下游查询、更新频率、数据量级和保留周期。表粒度不清楚时，必须先澄清“一行代表什么”。
设计框架
逐项设计：
- 表定位：ODS、DWD、DWS、ADS 或应用层数据集。
- 表类型：事实表、维表、明细表、汇总表、宽表、快照表、拉链表。
- 业务粒度：一行代表什么，这是表设计的核心。
- 主键或唯一键：如何唯一识别一行。
- 时间字段：业务发生时间、状态更新时间、入仓时间、分区时间。
- 分区策略：按日期、小时、组织、区域或其他字段分区。
- 更新策略：增量、全量、快照、拉链、覆盖、追加。
- 字段设计：维度字段、指标字段、状态字段、审计字段。
- 命名建议：表名、字段名、注释要表达业务含义。
- 下游使用：查询路径、常见过滤条件、聚合维度。
- 数据质量：非空、唯一、枚举、波动、关联完整性等。
- 生命周期：保留周期、归档策略、重刷成本。
输出格式
## 表设计建议
### 1. 设计结论
### 2. 表定位
| 项目 | 建议 |
| --- | --- |
| 数仓层级 | |
| 表类型 | |
| 表粒度 | |
| 主键/唯一键 | |
| 分区字段 | |
| 更新策略 | |
| 更新频率 | |
| 保留周期 | |
### 3. 表命名建议
### 4. 字段设计
| 字段名 | 类型建议 | 含义 | 是否必填 | 备注 |
| --- | --- | --- | --- | --- |
### 5. 关键口径与设计假设
### 6. 上下游关系
### 7. 数据质量规则建议
### 8. 风险点
### 9. 待确认问题
质量标准
输出必须：
- 优先明确表粒度
- 明确表的服务对象和下游查询场景
- 给出主键、分区和更新策略建议
- 不凭空确认不存在的上游表
- 对不确定的业务规则列为假设或待确认
- 避免过度设计
示例 Prompt
请用 table-design-advisor 设计一张表：
场景：渠道投放看板要看新用户注册、首购、7 日转化。
粒度：希望能按天、渠道、活动查看。
更新：T+1。
引擎：Hive/Spark。
