让 Coding Agent 写普通 Web 代码已经不新鲜了。难的是让它进入一个复杂数据平台：Spark、Unity Catalog、Jobs、MLflow、Model Serving、权限、表结构、流水线规范全都在场。
Databricks AI Dev Kit 解决的是这个问题：给 Claude Code、Cursor、Windsurf 等编码助手一套更可信的 Databricks 上下文和工具。
仓库地址：databricks-solutions/ai-dev-kit（https://github.com/databricks-solutions/ai-dev-kit）
数据平台不能靠模型记忆
模型也许见过 Spark 教程，但它不一定知道你们公司的 catalog、job 规范、权限边界、数据质量要求。让它凭记忆写数据工程代码，很容易生成看似正确、实际跑不通的东西。
AI Dev Kit 的价值，是把平台相关知识、文档、工具和示例放到 Agent 能读取的位置。这样它写 pipeline、dashboard、RAG assistant 或 MLflow 实验时，不必完全靠幻觉。
适合哪些任务
它适合从这些低风险任务开始：
- 根据现有表结构草拟 Spark SQL；
- 生成 Databricks Jobs 配置草案；
- 给 notebook 补注释和测试思路；
- 根据 MLflow 实验结果写复盘；
- 帮新人理解 Unity Catalog 和权限结构。
不建议一开始就让 Agent 独立改生产 ETL。数据平台的错误，通常不是一个单元测试能兜住的。
上手时先准备上下文
真正影响效果的不是 prompt 多漂亮，而是上下文是否干净。建议先整理：项目目录、常用表、命名规范、权限说明、部署方式、测试数据和失败案例。
请先阅读项目规范和现有 Job 示例。
只生成草案，不要直接提交。
每个 SQL 或 pipeline 需要说明依赖表、输出表和数据质量假设。把这些要求写进 Agent 指南，比每次临时提醒更可靠。
数据 Agent 最需要审计
Web 项目出错，通常是页面坏；数据任务出错，可能是指标错、报表错、模型训练错。让 Agent 参与数据平台开发，必须留下执行记录：它读了什么、改了什么、基于什么假设生成。
Databricks AI Dev Kit 值得看的地方，是它承认数据平台有自己的复杂上下文。AI 编程要进入这类场景，不能只靠通用模型能力，还得把平台知识变成 Agent 可用的工程资产。