InchStack 与 dbt 的边界

dbt 的核心价值，是把数据仓库里的 SQL 转换工作变成可版本化、可测试、可文档化的工程资产。它让 Analytics Engineer 用代码定义模型、写测试断言、生成文档和血缘关系，从而减少"一个 SQL 谁也说不清来源"的混乱。

dbt 解决的是"转换本身怎么管理"，但很多数据工作卡在转换之前和之后。在转换之前，业务方提出的指标口径可能还没定稿，需要讨论时间窗口、口径范围、异常处理规则；不同部门对同一指标的理解可能冲突。在转换之后，结果需要被解释、被审批、被组织成业务方能接受的交付材料。

InchStack 不应该被理解为另一个 dbt。它更适合放在 dbt 转换链路的上下游：上游承接业务问题、口径讨论和 AI 生成的候选口径草案；下游把转换结果、测试报告和样例数据组织成一次可复查的交付记录，并保留审批和回执。

这种分工可以避免重复造轮子。企业已经用 dbt 治理了转换层，就没有必要让 InchStack 再实现一套转换引擎。更现实的方式是让 InchStack 引用 dbt 的模型名、测试结果、运行日志作为交付证据的一部分，把"为什么这么算、谁确认过、风险是什么"沉淀下来。

一个常见误区是希望 dbt 承担全部数据治理。dbt 的测试主要验证数据层面的规则（非空、唯一、值域），但业务层面的口径对错（这个指标该不该这么算、是否符合合同条款、是否满足监管口径）需要人来判断。InchStack 把这类判断过程显式化，避免"测试都过了但业务说算错了"的尴尬。

对交付团队来说，这个边界也更容易落地。客户不需要在"换不换 dbt"上纠结，只需要把 InchStack 作为交付控制面，用来连接 dbt 产出的可信模型和业务方的确认环节。这样既尊重已有的转换工程，也让 AI 的价值落在沟通和判断这些真正耗时的工作上。

因此，判断是否需要 InchStack 的关键不是"我有没有 dbt"，而是"我的转换之外的工作是否经常卡在口径不清、AI 建议无人确认、交付材料每次重做、项目经验无法复用"。如果这些问题存在，dbt 和 InchStack 反而是互补关系。