Basedash AI Sources：让 AI 答案可追溯，却把“改数据”单独亮出来
Basedash AI Sources 把答案背后的上下文、SQL 和返回行做成按需打开的证据层，再用独立动作卡片标出会改变数据或配置的操作。
Basedash 是一款面向团队的 AI 原生商业智能平台。用户可以用自然语言询问业务数据，生成图表、仪表盘和报告；产品把数据库、指标定义和团队权限放进同一个分析工作区。Basedash 官方首页把产品定位为“AI analyst”，并强调答案可以回到受治理的指标定义和 SQL。1
2026 年 9 月 2 日，Basedash 发布 AI Sources。用户照常在聊天里提问，回答完成后，分析过程会折叠成一行“Analyzed for…”摘要；用户打开回答下方的 Sources，就能查看生成结论时使用的上下文和查询。2
AI Sources 值得看的地方，在于 Basedash 把“答案是否可信”拆成了两个连续动作：先读懂答案，再按需要回看证据。Basedash 还把会改变数据或配置的动作单独放到另一种界面对象里。两个细节共同组成了一条更短的复核路径。
亮点一：证据层按需打开
很多 AI 分析工具会把思考过程、工具调用和最终答案全部堆在聊天记录里。读者要么逐行翻找，要么接受一段难以回看的过程。Basedash AI Sources 采用了相反的阅读顺序：回答先保持完整，证据入口贴在回答旁边，详细过程在用户需要时才展开。官方发布文明确写到，完成后的思考和工具调用会收缩成简短的耗时摘要，Sources 则保留真正有用的来源和查询。2
这个顺序解决的是分析场景里的注意力分配。用户第一次阅读时通常只想知道“结论是什么”；用户准备把结论带进周会、预算或产品决策时，才需要追问“数字来自哪张表、采用了哪个口径、查询返回了哪些记录”。Basedash 把两种阅读深度放进同一个回答里，让证据距离结论只有一次点击。
Sources 的对象范围也比一张“参考链接”列表更具体。Basedash 会在同一个面板里列出连接数据库和数据仓库里的表、定义与 SQL 模型、回答引用过的图表、数据源、只读 MCP 连接，以及研究时使用的网页。每个对象先以紧凑的 context chip 出现，用户可以先判断分析涉及哪些材料，再选择需要展开的项目。2
更关键的复核入口在查询层。用户展开某条查询后，可以同时看到 SQL 和返回行的预览，再检查时间范围、分组方式和具体记录。Basedash 官方示例把问题写得很实用：某个数字来自哪张表，查询使用了哪个期间，哪些记录推动了变化，计算是否按预期分组。2
这里的设计取舍很明确：Basedash 没有强迫每个人都阅读 SQL，也没有把 SQL 藏到另一个页面。业务用户可以停留在答案层；产品经理、数据分析师和工程师可以在同一条对话里继续核对查询。证据层因此承担了分层阅读的职责，界面把“看答案”和“查依据”连接起来。
证据层仍然把判断责任留给用户。SQL 能说明系统执行了什么，SQL 仍然需要结合业务口径、时间范围和权限范围阅读。读者看到 Sources 后，应该优先检查指标定义和查询期间，再判断结论是否适合进入正式决策。
亮点二：把读取和改变做成两种对象
AI 分析经常在同一段对话里混合两类工作：一类工作读取数据并给出结论，另一类工作会创建定义、修改自动化或更新 AI 上下文。两类工作的后果不同，用户需要的确认方式也不同。
Basedash AI Sources 为两类工作安排了不同的视觉位置。读取分析完成后，长篇思考会折叠成简短摘要；当助手运行会改变数据的查询、创建定义或自动化、更新 AI 上下文时，Basedash 会在回答下方显示一张清晰的动作卡片，用户可以打开卡片查看细节。2
动作卡片的价值在于，它让用户先识别“系统发生了什么变化”，再决定是否深入查看细节。用户在分析阶段关心表、定义、查询和返回行；用户在执行阶段关心对象、范围和结果。Basedash 把两种问题分到两个界面对象里，减少了用户把“AI 找到一个事实”和“AI 改了一个配置”混为一谈的机会。
这个安排也把人工接管点放到了更合适的位置。用户查看答案时，可以先完成事实核对；用户看到变更卡片时，可以把注意力切换到影响范围和后续处理。卡片提供了可见入口，权限、业务规则和最终批准仍然属于团队自己的工作流程。
用一个低风险问题复核
读者可以在一组测试数据或只读连接上完成一次最小验证。验证目标是观察答案、证据和变化三个层次是否彼此对应。
- 先问一个范围清楚的问题。 例如询问某个指标在最近几个月的变化，并在问题里写明指标名称、时间范围和分组方式。问题越具体，读者越容易检查 SQL 是否遵循了原始意图。
- 先读答案，再打开 Sources。 先记录答案里的结论，再查看 Context 中出现了哪些表、定义、图表或连接。读者可以先检查指标定义，再判断答案是否使用了预期口径。
- 展开一条查询。 对照 SQL、时间范围和返回行预览，检查数字与结论之间的对应关系。读者可以把这一步当作一次小型数据评审。
- 单独观察动作卡片。 在测试环境里尝试创建定义或更新 AI 上下文，观察系统是否把变化放到回答下方的独立卡片里。读者需要把卡片当作接管入口，结合团队权限和业务流程完成确认。
这条路径的重点不是让所有用户都学会 SQL，而是让每个用户都能决定自己需要看到哪一层证据。业务用户可以停留在答案层，专业用户可以深入查询层，负责治理的人则能优先定位变更卡片。
Basedash AI Sources 的设计判断可以收束成三个层次：答案负责交付结论，Sources 负责交付依据，动作卡片负责标出变化。 这套分层适合迁移到任何会调用数据和工具的 AI 工作台。产品设计者可以用三个问题检查自己的界面：用户能否在不阅读全部过程的情况下拿到答案；用户能否从答案回到具体查询和返回记录；系统发生变化时，用户能否一眼识别对象、范围和接管入口。
References
- 1
- 2
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.