构建像组织一样定制的成本归属
您正在引导一个人（以及，如果组织中有的话，一个财务伙伴）完成一个构建，该构建主要是标准模式（FOCUS）与无服务器运行时之间的粘合剂。模式是固定的；形状是他们的。您的任务是在他们的数据中找到他们的形状，将其写下来，然后将模式应用到它上面——永远不要安装一个通用产品。
文章解释了为什么每种模式都是正确的： https://mooracle.io/blog/build-custom-finops-tool/（第 1–7 部分）。当用户问“为什么”时，指向相应部分；让会话保持在“如何做”上。
不变原则
这些原则不随配置文件而变。在展示生成的代码之前，对照它们进行检查。
- 每个拆分都保持其总额。 每个成本列的
SUM(out) == SUM(in)。拆分器移动资金；它们从不创造或销毁资金。 - 在查询时分配。 组织分类通过视图和查找表附加。永远不要将
team写入数据仓库行。 - 使用
EffectiveCost进行成本回收。BilledCost用于核对发票，ListCost用于衡量节省。永远不要混合使用。 - 重建整个月。 每个
(billing_period, provider)分区在每次交付时都会被清除并从原始数据重写。没有增量，没有合并。 - 截止到昨天。 日期在今天或之后的数据不会进入数据仓库。
- 每个拆分是一次扇出。 一个拆分的行在常规加载中连接其权重，并变成每个权重一行；一个键的权重之和为 1.0。公平份额、Kubernetes 和供应商拆分都通过这一方式工作，共用一个
split_weights表。没有数据被排除在加载之外再稍后添加，因此不会忘记排除，也不会重复计算。 - 每次运行都验证其数字。 原始数据精确包含供应商 manifest 列出的文件，一个阻塞性的总额检查将账单与两个基础表进行比较，并在不一致时使运行失败（并清除它写入的内容）。一旦视图存在，每次运行和每次结账还会检查
services_monthly是否精确服务于base_monthly（视图检查，失败不会清除任何内容）。 - 永远不要丢失成本；路由可能会失败。 当无法安全进行拆分时，成本保持完整，留在其原始计费位置。跳过的拆分是可见的；丢失的成本是无声的。
- 原始数据读取精确到月。
WHERE billing_period = 'YYYY-MM'，并启用引擎的扫描上限（Athena 上的工作组字节上限）。仅允许对base_monthly（兆字节级）进行全历史读取。 - 对共享列进行一次分类，放在视图中。
x_namespace同时保存 Kubernetes 和 SaaS 工作空间；split_by说明是哪一个。永远不要从值的形状推断。
您保存在用户仓库中的文件
在第 0 阶段创建 finops/，或按用户要求创建。将路径记录为第一个 D-001；以下 finops/ 指代该路径。
-
finops/profile.yaml— 组织的形状。从assets/profile.template.yaml开始。每个阶段都读取它；没有其他内容持有组织特定的决策。 -
finops/DECISIONS.md— 仅追加的日志。永远不要编辑条目；用新条目取代它。## D-007 企业支持是共享的 (2026-10-17) 来源：2026-09 的 D5；<user> 回答的 Q-S1 决策：按同月第一方支出分摊，每个付款人 取代：—发现结果、答案、假设、批准和负面决策（“尝试了每日权重表；因为月内组合没有变化而回滚；不要再提”）都放在这里。配置文件中的
evidence字段指向这些 id。 -
finops/STATUS.md— 每个阶段一行：状态、带有数字的门控结果、门控通过时的提交 SHA，以及该阶段依赖的配置字段。| 阶段 | 状态 | 门控 | 在 | 依赖项 | | 3 基础表 | 已通过 | 2026-09 账单 120,000.00 = 月度 120,000.00 | a1b2c3d | providers, dimensions, routing.key, finance, period_charges, shared_costs |
运行循环
进入
finops/STATUS.md存在 → 恢复：读取 STATUS、DECISIONS 和配置文件。对于每个已通过的阶段，git diff <其SHA> -- finops/profile.yaml；如果它所依赖的字段发生了更改，则重新开放该阶段以及它之后读取其输出的每个阶段（1 → 2 → 3；3 → 4, A, B, 5；4 → 5）。针对当前数据重新运行最后一个通过的门控（数据也在移动）。从第一个未通过的阶段继续。- 用户报告了变更（重组、新账户系列、新供应商、新集群）→ 刷新：重新运行匹配的发现查询，与配置文件进行差异比较，仅重新询问变动的内容，重新检查，重新开放依赖的阶段。
- 用户想先看看效果，或者暂时不愿提供账单访问权限 → 试用 (
references/trial.md)：在 DuckDB 上使用合成月份数据，无需凭证，对照答案键进行检查。其中的任何内容都不会带入实际构建。 - 否则 → 从下面开始。
1. 询问前先发现
在构建存在之前，读取 references/discovery.md 并在最后一个已关闭月份上运行其查询，针对已经存在的导出（一个表覆盖其文件，如果没有引擎，则在 DuckDB 上处理一个下载的交付）。显示每个结果。将每个结果记录为 D-NNN。发现只读取；它不改变账户中的任何内容，甚至不激活标签。
还没有导出 → 引导路径：打开导出 (references/focus-export.md)，运行非数据阶段的访谈（组织、运行时、分类、财务），针对预期的布局构建技术栈，并在下一个会话中一旦第一次交付落地就运行发现。在等待期间提供试用 (references/trial.md)。
2. 针对缺口进行访谈
读取 references/intake.md。停止或假设的规则：
- 答案涉及资金或所有权 → 保持为
null；组件保持 BLOCKED 状态； - 答案是一个名称、位置或工具 → 使用默认值，添加一个
assumptions:条目和一个D-NNN，继续。
永远不要用合理的猜测、固定值或示例中的值来填充事实。
3. 检查并同意计划
将 references/plan.md 中描述的检查器写入 finops/（一次，每个规则一个测试）并针对配置文件运行它。它会为每个组件打印一个裁决以及准备构建的内容（在其依赖链中全部 READY）。展示它。对于每个 BLOCKED 行，指出谁可以回答以及确切的问题。对于每个 NOT_A_FIT，大声说出更简单的替代方案——包括“不要构建这个”，如果组织规则这样说。获得计划的明确批准；将其记录为 D-NNN。
4. 按阶段构建
对于下面映射中的每个阶段，按顺序（在第 4 阶段之后的可选轨道 A 和 B，仅当 READY 时）：
- 入口检查。 检查器带有
--entering <phase>退出码为 0，并且它所依赖的每个阶段都在 STATUS.md 中标记为已通过。 - 读取其规范 (
references/<file>，阶段映射的“规范”列)：合同、不变原则以及临时实现时容易出错的边界情况。 - 在他们技术栈中编写。 在用户的引擎和语言（Athena、BigQuery、Snowflake、Databricks、dbt 等）以及他们的仓库风格中构建该阶段的组件，根据他们的配置文件进行定制：来自
providers.md的每个提供商的适配器，仅配置文件需要的拆分，仅它路由所依据的列。规范说明必须保持什么，情况说明必须输出什么；代码由您编写。在错误是无声的地方（权重、跨天数分布、总额检查、货币保护）要格外小心。 - 移植适用黄金案例（
cases/*.yaml；如何操作请参考references/testing.md）到该阶段构建的内容，并为每个组织特定的适配添加一个案例。一个阶段直到其案例通过才算构建完成。 - 部署并运行门控，针对他们的真实数据。门控是 SQL，健康时返回零行。显示数字。
- 在 STATUS.md 中记录结果、SHA 和依赖项。
每次门控报告：
门控 3（基础表），2026-09，aws: 已通过
账单 120,000.00 · 月度 120,000.00 · 每日 120,000.00 · 漂移 0.00
支持：1 行 → 12 个账户，权重总和 1.000000
失败的门控会停止构建。使用规范的失败表（每个检查的问题名称在 reconciliation-ops.md 的“故障模式”中）进行调试，修复，重新运行。
阶段映射
| 阶段 | 构建内容 | 配置文件字段 | 规范 | 案例 | 门控 |
|---|---|---|---|---|---|
| 0 | 发现、访谈、检查器、计划 | 全部 | discovery.md, intake.md, plan.md | — | 计划已批准 (D-NNN) |
| 1 | FOCUS 导出 | providers | focus-export.md | — | 完整月份可查询 (D0) |
| 2 | 存储布局、引擎、表以及填充原始数据的交付（复制或轮询器、暂存、ETL 的发布步骤） | runtime, providers | stack.md, data-model.md, pipeline.md (“交付”) | — | 已发布月份与其 manifest 匹配；原始数据月度查询扫描该月文件的一小部分 |
| 3 | 适配器、带按比例分摊和共享成本拆分的基础表、ETL 的重建 | providers, dimensions, routing.key, finance, period_charges, shared_costs | providers.md, data-model.md, splitters.md, pipeline.md | adapters, load, share, checks | 在已关闭月份上，每个付款人的 bill == monthly == daily |
| 4 | 规则、查找表、视图 | categories, routing | rules-engine.md | rules, views | 分类出现；Unallocated 已报告 |
| A | SaaS 拆分 | saas.vendors | saas.md | vendor | 供应商显示 split；总额保持不变 |
| B | Kubernetes 命名空间 | kubernetes | kubernetes.md | k8s | 权重干净；覆盖率≥目标 |
| 5 | 对账、运维、结账 | finance, org.finance_partner | reconciliation-ops.md, testing.md | checks | 在组织输入发票总额的地方 (Q-F5)，已关闭月份对每个提供商通过发票检查，其结果随月份存储；故意损坏的拆分会在开发副本上导致运行失败；与财务伙伴（如果没有则为负责人）一起检查数字 |
references/pipeline.md 包含了这些片段在运行时运行的执行顺序。
自由度
- 固定（无论引擎如何）：不变原则，以及案例指定必须输出的内容（
adapters.yaml除外：它显示了配置文件对导出原始形状的一种选择）：按比例分摊规则，权重之和为 1.0 的扇出，生产者的门控（每个付款人、正支出、整月供应商数据），检查及其停止条件，运行顺序和失败时的清除，拒绝未填充的查询参数。 - 属于他们（可以自由编写以匹配他们的代码库）：引擎和语言、文件布局、基础设施即代码、打包、调度、仪表板、CI，以及文件、函数和基础设施的名称（案例使用的表、列和问题名称是固定的）。
当您不确定某个变更属于哪一边时，它就是固定的。
当用户反驳时
references/pushback.md 包含了常见的反驳（“在 ETL 中分配”、“100% 映射”、“每个供应商一个框架”、“每个 Pod 精度”），并附有答案以及文章对此的论述。
完成条件
- 每个已关闭月份通过每个提供商的总额检查，贯穿每个拆分，并且在组织输入发票总额的地方通过发票检查。
- 报告成本的人（财务伙伴，如果没有则为负责人）能够从视图中回答“上个月 X 团队的成本是多少？”，而无需编写新的 SQL。
- 规则变更是一个拉取请求：CI 扩展，评审者看到什么移动了，合并后无需重建即可重新分类所有历史数据。
- Unallocated 作为金额被监控，以其货币单位表示，并呈下降趋势。
- 运行成本很小且可衡量（在参考技术栈上，每月约 10 美元，用于 S3、Athena 和 Lambda 处理 1500 万行账单；Athena 的份额在工作组的扫描指标中）。
- STATUS.md 显示计划构建的每个阶段都已通过并带有 SHA；DECISIONS.md 解释每个新来者可能会质疑的选择。