文章
SemanticFlow 只是一个提醒，
不是产品本身
为什么数据智能体应该先统一语义，再调用工具，最后把证据和结论放在一起。
很多 AI 产品还在把分析理解成一个聊天问题。
问一句，答一句，然后结束。
这对演示足够了。但一旦进入真实的分析工作，这种方式很快就会暴露边界。
因为真实工作里的问题，往往不是“能不能回答”，而是“能不能持续回答、反复回答、并且经得起复查”。
SemanticFlow 作为一个开源工具，值得关注的地方，不是它有多神奇，而是它提醒了我们一条更完整的路径：
- 先统一语义
- 再调用工具
- 最后把证据和结论连在一起
这条路径听起来很顺，但很多系统实际上会漏掉其中至少一步。
先统一语义
如果系统还不知道一个指标、维度、实体或者业务概念到底是什么意思，那它其实还没开始分析，只是在根据 prompt 和上下文猜。
这种猜法，做一次临时问答问题不大。
但如果同一个问题要在不同时间、不同场景、不同团队里反复被回答，语义不统一就会很快出问题。
语义层的作用，就是在任何工具动作发生之前，把歧义先处理掉。
语义一旦稳定，系统就不需要每次重新猜：
- GMV 到底是含税还是不含税
- 渠道到底按来源、归因还是投放来定义
- “活跃用户”到底是按登录、访问还是交易计算
重点不是让系统显得更聪明。
重点是让问题本身先稳定下来。
再让工具做窄而明确的事情
工具调用当然重要，但前提是语义已经站稳了。
没有语义，工具调用就是试错。
有了语义，工具调用才会变成有边界的动作。
这时不同工具的职责才会清楚：
- 数据库负责验证事实
- 文件或表格负责补充局部上下文
- 数据仓库负责更大范围的探查
- 语义目录负责解释定义
模型不应该因为“工具可用”就随便挑一个。
它应该因为当前语义问题需要它，才去调用它。
这也是数据智能体真正开始有用的地方，而不是只会显得很会说话。
结论要带着证据一起出来
AI 分析最常见的问题，不一定是结论错，而是结论太轻。
它给你一句话，却不告诉你：
- 用了哪些数据
- 排除了哪些数据
- 中间做了什么转换
- 还有哪些前提没被完全解决
这种答案看起来完整，实际上很难复查，也很难复用。
所以，好的分析路径应该把证据留在结果旁边，而不是藏在内部实现里。
如果证据不够，系统应该直接说限制。
如果语义没统一，系统应该直接说不确定。
如果结论只是基于推断，系统也应该说明它是推断。
这不是保守。
这是分析工作最基本的要求。
这对 Tukun 的意义
对 Tukun 来说，我们更在意的是这条顺序：
- 语义先发布、先复用
- 工具在语义清楚后再调用
- 结论和证据绑定在一起
- 限制条件要显式暴露
我们并不认为数据智能体应该替人做所有判断。
我们更希望它先把那些最脏、最容易出错、最容易被忽略的部分处理掉：
- 语义不清
- 证据分散
- 手工探查重复
- 结论无法追溯
这件事听起来没有那么炫。
但它更接近真实工作，也更能留下来。