DuckLocal
10 月 8 日，Anthropic 发布了 Claude Dashboards。用户连接数据源后，只需用自然语言描述需求，Claude 就能编写 SQL、生成可视化，并创建可以继续更新的仪表盘。
看到这个功能时，我的第一反应是：这和我正在开发的 DuckLocal 有很多相似的地方。
DuckLocal 是我基于 DuckDB 和 GPUI 构建的一款本地优先桌面数据分析工具。除了 SQL 查询和文件分析，我一直在尝试通过声明式仪表盘，让 AI 智能体参与数据分析与可视化。
因此，Claude Dashboards 的发布对我不只是一个值得关注的新功能，也让我重新思考了 DuckLocal 的产品方向。
1. Claude Dashboards 在做什么？
过去创建仪表盘，通常需要连接数据库、理解数据结构、编写 SQL、选择图表、配置筛选条件，最后调整布局并发布。熟悉 SQL 和 BI 工具的用户能够完成这些步骤，但普通业务用户仍然面临不小的门槛。
Claude Dashboards 尝试把这些操作整合进一次自然语言交互。例如，用户可以直接提出：
帮我分析最近六个月的收入趋势，按地区拆分，并展示增长最快的业务。
Claude 根据已经连接的数据源生成 SQL 和图表。它可以使用 Snowflake、BigQuery、Redshift、Databricks、ClickHouse 等数据平台，也能通过连接器访问 Salesforce 等业务系统。
其中有两个设计尤其值得关注。
仪表盘成为可以持续迭代的分析对象
仪表盘不再只是最终的展示结果。用户可以继续通过对话修改图表、增加筛选条件或调整分析维度，而不必重新手工配置整个页面。
图表背后的 SQL 可以检查
用户不仅能看到分析结果，还能查看结果是如何计算出来的。AI 可以降低数据分析门槛，但不能因此让分析过程变成无法检查的黑盒。
2. Claude Dashboards 验证了什么？
开发 DuckLocal 时，我一直有一个想法：
仪表盘不应该只是 BI 工具中的静态页面，而应该成为人与 AI 智能体共同分析数据的工作空间。
传统 BI 往往由分析人员创建仪表盘，再交给业务人员查看。业务人员对某个指标产生疑问后，需要重新联系分析人员，修改 SQL 或增加图表。
AI 智能体让这个过程有机会发生变化：用户提出问题，智能体分析数据并创建仪表盘；用户在查看过程中发现新问题，可以继续要求智能体调整查询或深入调查。
仪表盘因而从单向的信息展示逐渐变成双向的分析交互。Claude Dashboards 的发布让我更加确信，这个方向值得继续探索。
当然，大公司的入场不等于市场需求已经完成商业验证。但至少说明，自然语言驱动的数据分析和仪表盘，已经成为 AI 产品重点投入的方向之一。用户需要的也许不是更多图表，而是更快地从数据中找到可信答案。
3. 从 Claude Dashboards 获得的两个启发
在刚刚发布的 DuckLocal v0.2.1 中，我增加了两个与这个方向相关的能力。
让人与 AI 智能体围绕图表协作
第一个功能是仪表盘评论。用户可以直接在 DuckLocal 图表上留下问题，例如：
为什么这个时间段的错误率突然上升？帮我检查一下。
智能体通过 DuckLocal CLI 读取评论、分析问题并回复。用户可以继续讨论，或者在问题解决后把评论标记为已解决。评论保存在仪表盘对应的 .dash.comments.json 文件中，整个过程不依赖云端协作服务。
.dash 文件旁；智能体可以通过 ducklocal comments 读取和回复。我希望借此建立一种新的协作方式：
人负责提出问题和做出判断，智能体负责执行分析，仪表盘则是双方共享的上下文。
真正有价值的分析通常不是一次完成的，而是在提出问题、验证假设和修正结果的过程中逐渐形成。
让 SQL 成为可以检查的分析依据
第二个功能是查看图表 SQL。DuckLocal v0.2.1 支持直接查看仪表盘中每个图表最近一次执行的 SQL，其中的数据源和当前筛选条件都已展开。用户可以复制 SQL，也可以在查询编辑器中打开并继续修改。
AI 生成的图表看起来正确，不代表计算逻辑一定正确。收入增长率可能用了错误的时间范围，也可能漏掉部分业务数据。如果只展示最终结果，用户很难发现这些问题。
将 SQL 暴露出来，可以让分析过程更加透明。对财务、审计和安全分析等场景而言，结果不仅要容易理解，也应该可以检查和复现。
相关文档：用评论审阅仪表盘 · 通过 CLI 读取和回复评论
4. Claude Dashboards 与 DuckLocal 有什么不同？
两者都在降低数据分析门槛，也都试图让仪表盘成为可以持续探索、检查和修改的分析界面。不过，它们的产品定位和适用场景并不相同。
| 维度 | Claude Dashboards | DuckLocal |
|---|---|---|
| 产品定位 | AI 驱动的数据分析与仪表盘 | 本地优先的数据分析桌面应用 |
| 运行环境 | Claude 云端产品 | 本地桌面应用 |
| 数据处理 | 通过连接器访问数据平台和业务系统 | 基于本地 DuckDB 执行，也可显式连接外部数据 |
| 仪表盘 | 自然语言生成和修改 | 声明式配置，支持 CLI 与智能体工作流 |
| AI 协作 | 主要通过 Claude 对话 | 通过 CLI 和图表评论协作 |
| SQL 透明度 | 可以查看图表 SQL | 可以查看、复制并打开实际执行的 SQL |
| 开源 | 闭源商业产品 | Apache-2.0 开源 |
| 隐私与控制 | 依赖云服务及连接器的权限机制 | 支持本地执行，用户明确控制存储与网络访问 |
DuckLocal 不需要在每个功能上与 Claude Dashboards 竞争。Claude 的优势在于模型能力，以及与企业数据源和其他工具的整合；对已经采用 Claude 和云数据平台的企业来说，这种体验十分自然。
但也存在另一类需求：并不是所有数据都适合上传到 AI 服务，也不是所有分析都需要云端平台。
分析本地 CSV、审计导出的财务数据、排查包含敏感信息的安全日志，很多时候只需要本地分析环境。DuckLocal 选择本地优先，是希望让用户在自己的设备上完成这些工作。
本地软件并不自动满足所有合规要求，但它让用户能够更明确地控制数据存储、查询执行和网络访问。
隐私应落实为具体的产品行为
在 v0.2.1 中，我调整了 DuckDB 扩展的安装行为。此前，部分查询可能触发 DuckDB 自动从网络下载扩展；现在 DuckLocal 默认不再这样做，用户需要主动前往 Extensions 页面安装。自动检查更新也默认关闭。
对一个主打本地优先的产品来说，隐私不能只是 README 里的一句承诺，还应该落实到默认行为中。
开源同样是 DuckLocal 的重要区别。用户可以查看代码、审查数据处理逻辑，也可以根据自己的业务需求修改和扩展。对数据安全与隐私要求较高的场景，这种可检查、可控制的能力会是 DuckLocal 的长期优势。
5. 下一步：让仪表盘真正成为人与智能体的协作空间
目前 DuckLocal 仪表盘已具备声明式配置、SQL 查询、可视化和图表评论等基础能力。但距离我期待的人与智能体协作的数据分析工具，还有一段距离。
接下来我更关注的不是增加多少种图表，而是如何把分析过程连接起来：
- 用户在图表上提出问题，智能体能理解图表对应的数据和 SQL，并继续调查。
- 智能体不仅回复评论，也能根据分析结果提出仪表盘修改建议。
- 用户可以检查智能体的 SQL、分析过程和修改内容，再决定是否接受。
- 仪表盘不只展示最终结果，也能记录分析中的问题、结论与决策。
我希望未来的 DuckLocal 不只是 DuckDB GUI，也不只是 BI 工具，而是一个基于 DuckDB 的本地数据工作空间，让用户和 AI 智能体围绕同一份数据持续协作。
6. 写在最后
Claude Dashboards 的发布，让我看到了自然语言、SQL 和数据可视化进一步融合的趋势。
AI 生成仪表盘只是第一步，让人与 AI 围绕数据持续协作，才是更值得探索的问题。
Claude 正在从 AI 助手向数据分析工作空间扩展，而 DuckLocal 从本地数据工具出发，逐步引入智能体协作能力。两者的起点和路径不同，但在一些核心问题上正在逐渐接近。
对于 DuckLocal，我仍然希望坚持三个方向：
本地优先开源人与智能体协作
数据应该由用户控制，分析过程应该透明，而 AI 应该成为用户分析数据的协作者，而不是无法检查的黑盒。这也是我继续开发 DuckLocal 的原因。