指标字典该用 YAML/JSON Schema 还是 Markdown 表格维护？

背景 我在帮一个 30 人规模的数据团队做指标字典（metric dictionary）落地，团队有 40+ 个核心指标散落在 BI 看板、临时 SQL 和 Wiki 里。想把它收敛成一份单一事实源，让指标定义既能给人读、又能被工具消费（自动生成看板、做血缘校验、做命名 lint）。

现象 / 卡点 我在两种方案之间反复横跳，拿不准：

1. YAML/JSON Schema 结构化：每个指标一个文件，字段固定（name、alias、definition_sql、owner、tags、caliber、deprecated_at…），好处是可 lint、可 CI、可被脚本读；坏处是业务方写起来门槛高，改个口径描述也要走 MR，容易变成"只读文档"。
2. Markdown 表格 / 单页文档：业务方熟悉、改动成本低，但字段不统一，"口径"这一列经常出现"按惯例""同 XX"这类模糊表述，脚本根本没法解析。

已尝试

• 拉了 5 个指标的样本，用 JSON Schema 描述 + JSON Schema Validator 做校验，跑通了命名 lint 和 SQL 字段存在性检查（对着 DDL 查列名）；
• 用 Markdown + 固定列模板让业务方试写 3 个指标，2 个口径字段写成了自然语言，1 个 owner 填成了部门名。

期望得到的答案形态

• 你们团队现在实际用的是哪种？文件粒度是"一指标一文件"还是"全量一个大文件"？
• 如果是结构化方案，schema 里你们保留了哪些必备字段、砍掉了哪些"看着有用但没人填"的字段？
• 怎么降低业务方的书写成本（模板？CLI？PR 模板？AI 辅助？）？
• 有没有踩过"指标字典写完就没人更新"的坑，你们靠什么机制让它活着？

欢迎贴 schema 片段或表格模板，越具体越好。