为什么先治理语义，而不是直接做 NL2SQL？
选择： 先确定指标口径、版本、物理绑定和受治理关系；查询先解析为明确计划，再交给受限执行适配器。
取舍： 表选对不等于业务含义正确。让模型自由猜口径会把歧义带入结果；这一选择牺牲了任意问题即时作答的覆盖面，但让无法确定的查询可以被解释、澄清或拒绝。
个人项目 · 开放预览 · 官网已上线
Semlia · 企业语义资产与指标治理平台
统一业务概念、指标口径与数据关系，为人和 AI 提供可信定义
面向企业数据团队，集中管理散落在 SQL、报表和文档中的业务定义。例如“净收入怎么算、有效订单如何认定”，都能找到口径、来源证据与发布版本，让业务人员和 AI 使用同一套可信定义。
我的工作：产品定义 · 语义与治理模型 · 全栈实现与验证
交付与验证
围绕指标口径、关系证据、不可变发布和消费契约设计企业语义资产平台；推进目录、治理发布、固定版本解析与受限只读查询的真实服务链路。
- 治理到消费的真实本地链路
- 发布版本、语义计划、受限只读执行已有实现
- 多入口复用同一服务
- REST、MCP、CLI、SDK 与 Ask，不各自维护一套语义
官网开放预览，案例证据来自本地实现与验证。
官网以 Pre-alpha 开放预览。2026-09-05 本地 Beta 候选记录覆盖治理发布、不可变快照、JoinContract、语义计划和只读 PostgreSQL 执行；其中真实 Chat/Embedding、外部连接与托管恢复未纳入验证。官网上线不等于这些产品链路已通过正式验收。
项目与验证边界
个人研发项目，不是通用 ChatBI 或新的查询引擎。截图来自本地验收数据；Ask 使用确定性 Chat 测试提供方、真实语义服务和只读 PostgreSQL，不表示真实大模型端到端或客户数据验收。
关键产品决策
为什么发布版本不能随编辑一起变化？
选择： 草稿与发布事实分离；消费者绑定明确版本，变更通过审核与新的发布记录生效。
取舍： 同一句业务问题不应在上游编辑后悄悄改变答案。版本绑定提高了维护成本，却使定义变化、消费影响和回滚可以检查。
项目背景与实现范围
业务问题
企业有大量表和报表，却仍会对“净收入”“有效订单”等概念产生分歧。Semlia 管理定义、证据、关系和消费版本，让已有数据经验能够成为人和 Agent 共同使用的资产，而不只是一段 Prompt。