Text2SQL已经不新鲜，让AI真正会搭数仓才是关键

配置连接

cz-cli setup

启动cz-cli agent

cz-agent //或者 cz-cli agent

想了解更多安装细节和配置选项，可以前往 cz-cli 说明文档。

https://www.yunqi.tech/documents/cz-cli

从一个业务场景说起

假设你在一家连锁零售公司，业务团队每天都要看门店经营数据：订单金额、会员复购、商品库存、门店小时级销售趋势。原始数据分散在订单系统、库存系统、会员系统里，每天都在持续变化。

传统做法通常是这样的：数据工程师先建 ODS 原始层，再清洗到 DWD 明细层，最后加工 ADS 指标层；中间还要考虑增量同步、字段标准化、调度任务、失败重试、质量校验。业务方一句“我想看门店小时级经营看板”，落到工程上可能就是几天工作。

现在换一种方式。你只需要把需求说清楚：

帮我搭建一个门店经营分析数仓。订单数据持续写入，要求按标准 ODS/DWD/ADS 三层设计。ODS 保留原始订单，DWD 清洗出门店、商品、会员、支付时间等字段，ADS 输出门店小时级销售额、订单数、客单价、会员复购指标。链路要支持增量更新，避免每天全量刷新，并配置定时调度和基础校验。

这个需求既可以在 Cursor、Claude Code、Codex 里交给 AI，也可以直接交给 cz-cli 自带的 Agent：

cz-cli agent run "帮我搭建一个门店经营分析数仓。订单数据持续写入，按 ODS/DWD/ADS 三层设计，ADS 输出门店小时级销售额、订单数、客单价和会员复购指标，链路要支持增量更新，并配置定时调度和基础校验。"

接下来，Agent 会通过 cz-cli 直接操作 Lakehouse：创建 schema、建表、写 ETL SQL、配置任务、执行验证查询。它不是凭空生成一段“看起来像 SQL”的文本，而是在真实环境中一步步执行，并根据返回结果继续修正。

更关键的是，它知道该怎么做增量。

对于持续写入的订单数据，AI 可以判断是否适合使用 CDC、Table Stream 或 Dynamic Table。比如 ODS 层开启变更追踪，用 Table Stream 捕获新增订单，驱动 DWD 层增量清洗；ADS 层用 Dynamic Table 维护门店小时级聚合，让指标随底层数据变化持续更新。

这和“让 AI 写一段 SQL”完全不是一回事。这里的 AI 做的是工程决策：哪些表需要保留原始数据，哪些字段需要标准化，哪里适合增量消费，哪里应该做聚合刷新，任务跑完后如何验证结果是否合理。

CZ-CLI 的价值，不只是命令行

很多数仓 CLI 的价值，是把 UI 操作搬到终端。cz-cli 更进一步：它的设计目标是让 AI 能可靠地操作数仓，而且不限定 AI 来自哪里。

如果你已经在用 Cursor、Claude Code、Codex，cz-cli 可以成为它们的数据工程工具箱；如果你不想切换到外部 AI IDE，cz-cli agent 本身就是一个专业的数据开发 coding agent。你可以把它理解成一个“随叫随到的数据工程搭档”：它既懂 Lakehouse 命令，也懂数仓任务应该按什么步骤建设。

首先，它有 AI 友好的输出。cz-cli 默认返回结构化结果，错误信息也会带上清晰的上下文和修正提示。对人来说，这是更容易排查；对 AI 来说，这是能否自动纠错的关键。

其次，它覆盖了数仓开发的完整生命周期：SQL 执行、schema/table 管理、任务创建、调度发布、运行记录、attempt 日志、job 详情、profile 多环境管理。AI 不需要在 Web UI、SQL 客户端、调度系统之间来回跳转，而是可以通过统一入口完成端到端操作。

最重要的是专业场景能力。cz-cli的数仓skills让外部 AI coding agent 获得批量同步、CDC 实时同步、Kafka 接入、OSS 导入、动态表、Table Stream、数据恢复、权限管理、性能分析、知识库构建等技能；而cz-cli agent则把这些能力直接内置到 cz-cli 自己的对话式开发体验里。它们不是零散命令，而是一套“知道该按什么步骤做”的工作流。

很多数仓 CLI 的价值，是把 UI 操作搬到终端。cz-cli 更进一步：它的设计目标是让 AI 能可靠地操作数仓，而且不限定 AI 来自哪里。

如果你已经在用 Cursor、Claude Code、Codex，cz-cli 可以成为它们的数据工程工具箱；如果你不想切换到外部 AI IDE，cz-cli agent 本身就是一个专业的数据开发 coding agent。你可以把它理解成一个“随叫随到的数据工程搭档”：它既懂 Lakehouse 命令，也懂数仓任务应该按什么步骤建设。

首先，它有 AI 友好的输出。cz-cli 默认返回结构化结果，错误信息也会带上清晰的上下文和修正提示。对人来说，这是更容易排查；对 AI 来说，这是能否自动纠错的关键。

其次，它覆盖了数仓开发的完整生命周期：SQL 执行、schema/table 管理、任务创建、调度发布、运行记录、attempt 日志、job 详情、profile 多环境管理。AI 不需要在 Web UI、SQL 客户端、调度系统之间来回跳转，而是可以通过统一入口完成端到端操作。

最重要的是专业场景能力。cz-cli的数仓skills让外部 AI coding agent 获得批量同步、CDC 实时同步、Kafka 接入、OSS 导入、动态表、Table Stream、数据恢复、权限管理、性能分析、知识库构建等技能；而cz-cli agent则把这些能力直接内置到 cz-cli 自己的对话式开发体验里。它们不是零散命令，而是一套“知道该按什么步骤做”的工作流。

所以，当你让 AI “把 MySQL 订单库同步到 Lakehouse”，它不应该只生成一段建表 SQL，而应该继续判断：这是单表同步还是整库同步？要全量加增量，还是只做增量？目标表是否存在？字段类型怎么映射？任务是否需要调度？是否会影响生产链路？

cz-cli 的核心价值就在这里：让 AI 从“代码补全工具”变成“懂数仓的工程搭档”。这个搭档可以运行在你熟悉的 AI IDE 里，也可以直接运行在 cz-cli 自带的 Agent 里。

对数据工程师：少踩坑，少返工

数据工程师最怕的不是写 SQL，而是那些重复但容易出错的细节：字段注释漏了，分区没按规范建，增量 offset 语义理解错了，调度配了但没验证，开发环境和生产环境 profile 搞混。

cz-cli 可以把这些动作标准化。你仍然负责业务建模和工程判断，但大量执行层细节可以交给 AI：编写任务、执行、验证、修正。尤其在 CDC、Table Stream、Dynamic Table 这类有平台特定语法和语义的场景里，价值会非常明显。

它也不是鼓励“无脑让 AI 上生产”。恰恰相反，cz-cli 的 profile、结构化错误、写操作控制、任务发布流程，都是为了让 AI 操作有边界、有反馈、有审计路径。

其他场景也能自然延展

除了数据工程师搭 pipeline，cz-cli 对数据分析师也很有用。分析师可以用 cz-cli 查询数仓，再让 AI 基于查询结果生成 HTML 分析报告或可视化页面，把“取数到交付”的链路缩短。

对业务用户来说，cz-cli agent run 这类自然语言入口，可以把一些日常探索变得更直接：查看某个 schema 的表、统计核心指标、生成一次数据质量巡检报告。业务不用等待完整 BI 数据集排期，也能先把问题问出来。对于没有安装 Cursor 或 Claude Code 的团队，这一点尤其重要：只要有 cz-cli，就已经有了一个可用的数据开发 Agent。

对运维场景，cz-cli 还可以查看任务运行记录、attempt 日志、job 执行详情，辅助做失败诊断、性能分析和回填操作。

AI 时代的数据工具，不应该只问“能不能生成 SQL”，而应该问“能不能把一条数据链路正确、安全、规范地搭起来”，让 AI 真正懂数据工程。

cz-cli既能把 ClickZetta Lakehouse 的能力开放给 Cursor、Claude Code、Codex 等外部 AI coding agent，也能通过 cz-cli agent 直接提供一个开箱即用的数据开发 Agent。再加上专业 skills 对复杂场景的沉淀，AI 不再只是帮你写 SQL，而是能参与完整的数据工程流程。

当业务需求从“帮我写个查询”升级为“帮我搭一条近实时数仓链路”，cz-cli 的价值就会变得非常具体：少手写，少踩坑，把时间还给真正重要的业务指标、数据模型和工程质量。

现在就开始使用cz-cli吧

访问cz-cli网站了解更多信息：https://cz-cli.ai/

安装 cz-cli：

curl -fsSL https://cz-cli.ai/install.sh | bash

配置连接并验证：

cz-cli setup

获取cz-cli安装文档请访问：

https://www.yunqi.tech/documents/setup_cz_cli

更多cz-cli使用技巧，请点击预约今晚19：30直播！

云器科技官网 - 改变数据的使用方式
更多内容，欢迎关注「云器科技」官网！
云器科技-多云及一体化数据平台提供