Sigma AI Columns 的巧思：把提示词放进表格，而不是聊天框

多数 AI 工具把自然语言放在一个聊天输入框里，Sigma AI Columns 选择了另一条路：把 prompt 变成表格的一列。用户选择一张表，引用其中一列或几列，写下要完成的任务，模型就为每一行返回文字或结构化 JSON。这个功能于 2026 年 6 月 29 日以 beta 形式面向 Snowflake 和 Databricks 客户推出。1

这个决定看起来像是把聊天框换了个位置，实际改变的是 AI 结果的身份：它不再是一段需要复制粘贴的回答，而是一个可以继续筛选、聚合和写回数据平台的字段。Sigma 在 7 月 31 日的产品更新里仍把 AI Columns 放在「用自然语言丰富、分类和总结数据」的主线中。2

Sigma 解决的是一个很具体的断点：客户工单、销售通话转写和 CRM 备注里有大量可用信息，但这些信息是自由文本，不能直接按主题、行业或风险做统计。过去常见的路径是导出数据、粘进聊天机器人，或者写一段 Python，再把结果导回数据平台。Sigma 对这个痛点的描述很直接：AI Column 让 prompt 在数据平台的 AI 函数里执行，结果再写回原来的数据平台。1

用户从一张表的列菜单进入「Add column via > AI column」，给新列命名，选择模型，在 prompt 里引用已有列。系统要求 prompt 至少引用一列现有数据；输出可以是普通文本，也可以打开 Response format，把结果约束成带字段名和类型的 JSON。3

这一步的设计价值，不在于少写几行代码，而在于保留了表格原本的后续动作。文本摘要可以继续被筛选，分类结果可以参与聚合，结构化字段可以进入下一个报表或应用。AI 输出成为数据模型的一部分，而不是聊天记录里的孤立文本。

代价也跟着转移了。聊天回答错了，用户通常只需要丢掉这一轮；写回表格的错误会被后续查询、图表和业务判断继续使用。Sigma 因而不能只提供一个看起来能用的生成按钮，还要让用户在提交整张表之前看到足够多的结果，并且让权限和数据位置保持清楚。

AI Column 最值得借鉴的地方，是它没有把「对每一行调用模型」藏成一个不可见的后台动作。用户先看前 100 行的预览，修改 prompt，确认输出形式，再把配置应用到整张表。官方文档把这个流程写成明确的 Preview → Create 两步，而不是让用户提交后才发现分类规则不合适。3

这个预览不是质量证明。前 100 行可能没有覆盖长文本、异常值和边界案例，模型在样本里表现稳定，也不代表全表都能正确分类。但它把一次昂贵且难撤回的全量调用，改成了一个可以先审查的局部实验。对产品经理和分析师来说，真正新增的是「提交前有机会发现 prompt 不够具体」这一层控制。

Sigma 又把计算成本绑定到数据变化上：AI Column 的结果会被缓存，只有行的输入发生变化时，模型才会重新运行；管理员还可以为每个连接设置 token 上限，默认上限是每个连接每月 1000 万 tokens。13

缓存和 token 上限解决的是两个不同问题。缓存减少重复计算，token 上限限制最坏情况下的账单；二者都不能替用户判断结果是否值得信任。Sigma 的官方文档还列出了一组硬边界：AI Column 目前只支持 Snowflake 和 Databricks，prompt 不能引用另一条 AI Column，AI Column 不能用于 actions 或 input tables；如果更换表的数据源，需要重新创建这条 AI Column。尚未完成的行在工作簿物化时还可能返回 Null。3

前置条件同样说明了这不是一个脱离数据治理的聊天插件：组织要先配置 AI provider，用户需要创建 AI Column 的权限和工作簿编辑权限，连接必须开启写入权限；Snowflake 和 Databricks 还各自有 AI 函数、运行时或区域要求。3 结果落在数据平台里，意味着治理边界更连续，也意味着错误结果、权限配置和写入状态必须由数据团队一起负责。

Sigma AI Columns 的巧思不是「让模型替你填表」，而是把 AI 生成重新包装成一种有输入、有输出、有权限、有成本边界的数据操作。prompt 不再是一次性的提问，模型结果也不再停在聊天窗口；二者被放进了分析师已经熟悉的列、行和查询关系里。

这套设计可以迁移到其他 AI 产品：当生成结果会进入后续工作流时，产品应先给用户一个能覆盖边界情况的预览，再提供明确的写回位置、重复计算策略和预算上限。否则，AI 只是把人工搬运省掉了，却把错误搬进了数据系统。