我给 AI 写了一套“规矩“：数仓开发骨架 Ware-Smith 的设计思考（前言）

29人浏览 · 2026-07-07 18:32:41

· 2026-07-07 18:32:41 发布

Ware-Smith

AI-Native Data Modeling Skeleton — 让 AI 像老师傅一样做数仓开发

不是又一个 Text-to-SQL 工具，而是一套让 AI Agent 遵守工程纪律、积累领域经验、安全可控地完成数仓全生命周期开发的知识骨架。

一句话定位

Ware-Smith 是一套基于 AI IDE Skill 体系的开源数据建模骨架（Skeleton），把数仓需求开发的六个阶段（PRD → 探查 → 建模 → SQL → 校验 → 上线）封装为可插拔、可独立使用、共享同一套规范的 AI Skill 流水线。

它不生产 AI 模型，不绑定特定 LLM——它解决的是：当你把数据开发交给 AI 时，如何保证它不乱来。

为什么需要它

行业现状	Ware-Smith 的回答
Text-to-SQL 只管"写出来"，不管"写得对"	全链路闸门（G0→G3），否决项不可跳过
AI 生成的表名/字段名随心所欲	词根词典 + 命名规范强制约束，未匹配的标记"待审批"
一个 Prompt 塞所有规范，超长且脆弱	知识分层
需求到上线的中间环节全靠人盯	状态管理 + 断点恢复
AI 不理解你的业务（什么是"良率"？什么是"工单"？）	团队能力包(领域知识)
改一个字段，下游炸了谁负责？	破坏性变更强制安全评估，配 ROLLBACK + 影响通知

设计哲学

1. 知识即约束（Knowledge as Guardrails）

AI 不需要"更聪明"，它需要"更有纪律"。

Ware-Smith 的核心信念：把规范编码为可执行的知识文件，而非依赖 Prompt Engineering 的口头约定。词根词典、闸门规则、安全红线——这些不是"建议"，是硬约束。

2. 分层治理（Layered Governance）

3. 意图路由（Intent-Driven Routing）

AI 不是被动等指令，而是主动识别用户意图，自动匹配最合适的执行路径：

用户输入
    │
    ▼ 意图分类（skill-router）
    ├─ 明确动作（"设计这张表"）    → 精确匹配 → 单能力 Skill
    ├─ 业务概念（"OEE 怎么算"）    → 模糊匹配 → 判断指标是否已有 → 路由
    ├─ 完整需求（"从头开始做"）    → 全流程 Pipeline
    └─ 歧义不明                    → 主动追问，禁止降级猜测

核心原则：涉及新建表、新建指标、变更口径的任务，不允许走直接对话——必须激活 Skill。歧义时问而不是降级。

4. 语义本地化，技术走 API（Semantics Local, Tech via API）

本地知识 = AI 的"大脑"（理解口径、消歧、经验）
平台 API = AI 的"眼睛"（表结构、血缘、数据量）

不把整个元数据库搬进 Context——只存 API 给不了的语义知识（指标口径、聚合规则、编码对齐坑）。

5. 安全前置（Shift-Left Safety）

破坏性变更（改口径 / 改粒度 / 删有引用字段）在设计阶段就被拦截，而非上线时才发现。change-safety-guard 自动触发，产出影响范围 + ROLLBACK 策略 + Owner 通知清单。

核心架构

与业界方案的对比

维度	Text-to-SQL 工具	AI Copilot 插件	DataOps 平台 AI 模块	Ware-Smith
覆盖范围	写 SQL	代码补全/解释	端到端但锁定在平台内（离开平台即失效）	全生命周期（PRD→上线，IDE 原生不锁平台）
规范保障	无/弱 Prompt	无	规则由平台定义，团队只能配不能改底层逻辑	知识文件 + 闸门双保险（团队完全自主）
领域知识	依赖上下文窗口	依赖上下文窗口	平台提供通用模板，深度定制要等厂商排期	可插拔能力包（团队自维护，即时生效）
安全机制	无	无	依赖审批流，设计错误到提交时才暴露	设计阶段拦截 + 强制评估（Shift-Left）
可扩展性	改 Prompt	改 Prompt	平台闭源，扩展受限于厂商 API 开放节奏	开放骨架：加文件即生效
状态管理	无	无	平台内闭环，换工具链状态不可迁移	JSON 状态机 + 断点恢复（纯文件可 Git）
与 LLM 耦合	高	高	绑定平台内置模型，换模型成本高	零耦合（纯知识文件，模型随换随用）