企业官网建设流程全解析

• AI 应用
• 媒体生成
• 后端
• 前端

本文以 economics-provider-collection 技能文档 为主体，讲解 Pollinations 平台如何系统化地收集供应商（provider）余额、月度用量与发票凭证：从provider-registry.json这个"唯一供应商清单"出发，按 API → CLI → MCP → 仪表盘的优先级取证，把金额事实与过程证据严格分离，并按 append-only 规范写入economics_*系列 Tinybird 数据源。读完后你能掌握一套可复现的"供应商月度结账（monthly close）"操作框架，以及 Pollinations Economics 应用的台账字段约定、时间覆盖语义与证据归档标准。

适用场景与整体思路

该技能定义在 .claude/skills/economics-provider-collection/SKILL.md，用于以下用户请求：

• 刷新（refresh）某个供应商的数据；
• 检查供应商账户状态；
• 准备月度结账（monthly close）；
• 将供应商成本与 Pollen（内部计费单位）对账。

文档给出的核心思路是先注册、后收集、再入账：所有出现在银行流水、供应商台账或 Runway 行中的对手方，都必须先在供应商注册表中登记身份（别名、账户、连接器、业务类别），然后才允许对其现金流或用量进行分类。这避免了"凭相似名字猜测别名、账户、模型或资金来源"这类最常见的对账错误来源。

单一事实源：provider-registry.json

技能规定第一步必须读取 operations/economics/provider-registry.json。这份注册表是所有供应商操作的身份权威，其实际结构可以从文件内容直接印证：

• version：当前为30，注册表整体带版本号演进；
• providers[]：每个供应商一条记录，包含id（规范 vendor ID）、label、category（业务类别：compute、infrastructure、development、operations、revenue_share、office、admin、payroll）、meteringBasis（计量口径，如direct、mixed、internal、not_applicable）、aliases、connector（指向连接器指南文件名）、monthlyReview、balanceTracking、collectionMethod、accounts[]（含id/label/aliases/loginEmail/activeFrom/activeTo）与access[]（含workspace/url/accountId/loginEmail）。

注册表还承载几类特殊配置，均直接服务于技能文档中的规则：

• cashRules：针对"同一供应商的银行描述可能对应不同用途"的混合供应商，给出银行描述匹配规则。例如anthropic条目配置了match: ["subscription"]、equals: ["claude"]时归类为development，即银行流水中订阅类扣款会被区分于推理消费；
• runwayLine：把商户折叠进某一条 Runway 行的映射（如amazon→"Furniture & equipment"）；
• canonicalModelRenames：旧模型 ID 到规范模型 ID 的改名表（如gptimage→openai/gpt-image-1-mini）；
• retiredModels：已从共享注册表下线但历史记录仍然有效的模型 ID 列表；
• pollenVendorOverrides：有界、有证据的供应商归因改写。文件中现存的唯一一条把gptimage在 2026-01 至 2026-04 期间从pointsflyer改归到azure，并在evidence字段写明依据——这正是技能文档"仅通过有界且有证据的pollenVendorOverrides条目重新归因"的落地形态；
• modelLabels（挂在各供应商条目下）：把供应商账单侧的模型标签映射到 Pollen 模型 ID。例如alibaba条目中qwen3-tts-flash→qwen-tts、wan2.6-t2v→wan；assemblyai条目则把Universal-2等标签映射到universal-2，并把无 Pollen 对应模型的标签显式置null——与技能文档"没有 Pollen 模型时记null"的约定一一对应。

技能文档对注册表使用给出三条硬性约束：

1. 活跃供应商才有monthlyReview: true，正常月度运行只刷新这些供应商；不活跃供应商保留可见以维持历史，仅当用户明确要求或刻意重新激活时才检查。
2. 绝不从相似名字推断别名、账户、模型或资金来源。
3. 新供应商出现在银行账单中时，必须先补注册表条目，才能对其现金做分类。

这一点与 operations/economics/README.md 相互印证：该 README 明确"operations/economics/provider-registry.json是单一供应商清单"，并说明类别词汇表本身由 operations/economics/web/src/lib/categories.ts 中的CATEGORY_IDS定义（revenue、compute、infrastructure、development、operations、revenue_share、office、admin、payroll、balance_sheet），而"哪个供应商属于哪个类别"只存在于注册表中。

供应商连接器指南：按需加载单份文档

确定供应商后，技能要求只读取该供应商对应的一份指南，路径规则为.claude/skills/economics-provider-collection/references/providers/<connector>.md，文件名直接取自注册表条目的connector字段（vendor ID 中的点在注册表注明时写作连字符）。

当前仓库中该目录包含 43 份指南，覆盖 azure.md、stripe.md、openai.md、wise.md、fal.md 等供应商。以 azure.md 为例，一份完整指南记录了：验证日期、可用的认证方式与 API 端点、必需的凭据变量名（AZURE_TENANT_ID、AZURE_CLIENT_ID、AZURE_CLIENT_SECRET、AZURE_BILLING_ACCOUNT、AZURE_BILLING_PROFILE、AZURE_SUBSCRIPTION_ID）、client-credentials token 获取与发票端点查询的完整curl命令、账户路由约束（"只用以thomas@myceli.ai登录的浏览器窗口打开 Azure"），以及"已知陷阱"清单（例如creditAmount是退款/冲销而非赞助积分、发票期应覆盖完整日历月、进行中的月份没有完整发票等）。

指南的职责边界很清晰：只记录"如何到达这个数字"——路由、URL、命令、看哪一列、用哪个约定——绝不记录数字本身。金额一律留在台账行里（详见"证据与台账"一节）。

收集顺序：API → CLI → MCP → 仪表盘

技能规定了取数源的优先级：选择第一个能提供权威、且粒度足够的数据的来源：

1. 供应商支持的官方 API；
2. 支持的 CLI；
3. 可用的 MCP 或已认证的连接器；
4. 供应商仪表盘（dashboard）。

同时明确了一条反过度工程原则：不要为一次有界的月度任务构建永久性的供应商集成——运行文档中已有的命令，或直接使用仪表盘即可。

选择仪表盘收集时，还有具体的浏览器安全规程：

• 按注册表access条目的workspace字段分组（注册表中实际出现的 workspace 包括myceli.ai、pollinations.ai、neoglyph.ai、pixelmarket.ai以及形如thomas@myceli.ai的账号级标识）；
• 同一 workspace 的所有 URL 一起打开；先枚举当前浏览器窗口，然后只使用可见邮箱与组织都与注册表目标匹配的那个窗口；匹配有歧义时立即停止；
• 绝不存储浏览器窗口 ID，绝不复制 cookie、密码、会话令牌或任何凭证揭示型 URL。

凭据使用同样受约束：只使用已存在的授权凭据。创建、轮换、同步或部署凭据属于"凭据变更"，不在收集范围内，需要仓库单独的 secret 变更流程和显式的限定范围审批。

月度结果：每个活跃供应商、每个活跃账户要拿到什么

技能为"一次月度结账"定义了三类必须收集的数据，且对每类的语义都有精确约束：

1. 余额快照（当balanceTracking: true）

收集现金/预付余额与促销积分（promotional credit）余额。规则要点：

• 每个规范账户存一条余额快照；多个积分批次（grant lots）使用相同的核验时间戳和不同的资源 ID（current-balance-lot），而不是新增一条账户总额行；
• 在当前日历月内收集的快照用于关闭上一个月份，同一结账周期内不要求反复核查；
• 账户别名只合并注册表中显式列出的 ID。

2. 用量（usage）

取"上一个已完成的 UTC 日历月"的用量，粒度取数据源支持的最深一级，回退顺序为：模型（model）→ GPU 实例/工作负载 → 服务/SKU → 供应商总额。关键语义约定：

• start/end记录实际的 UTC 覆盖区间，end不含端点；绝不能用账单周期日期替换日历月边界，也不能用收集时间充当覆盖区间；
• 模型或 GPU 明细不可得时，原样保留供应商总额并声明缺失的粒度；绝不允许用内部模型名或未记录的配比去分摊总额。

3. 发票/对账单/收据/供应商导出

必须收集能证明已计费用量义务（billed obligation）或确认本期无需付款的凭证。azure.md 中的已知陷阱是这一要求的实例：Azure 发票"期"与"出账日"必须分开记录，billedAmount.value才是发票总额，totalAmount.value/amountDue.value用于应付金额，payments[].amount.value才是现金支付证据。

此外还有三个专门约定：

• 信用快照的end字段：填已核验的到期日；留空表示"未知"，不表示"无限期"。只有核验过"不过期"条款时才可使用resource_sku: current-balance-no-expiry；被省略或变更的条款要重新核验，绝不悄悄延长旧积分。用户批准的预测例外使用current-balance-expiry-assumed、空end，并把限定范围的审批记录在证据中——它不等于已核验条款；
• Stripe 专项：每个账户-月份必须记录coverage_end与expected_accounts；部分导出不允许在滚动（rollover）时变成"已完成的预测基线"。stripe.md 进一步要求：按 Unix 时间戳限定期间、禁止跨 Stripe 账户合并分页、每个账户一份导出并记录认证账号 ID；
• 三个事实必须分开存放：供应商用量、供应商余额、银行付款是三个独立事实。充值不是用量；发票日期不自动等于用量月份；余额快照是"当前状态"而非"历史消耗"。

证据与台账：金额与过程彻底分离

这是技能文档信息密度最高的部分，核心原则一句话概括：这个仓库是公开的，所以references/指南里绝不出现数字；数字连同证据链接只存在于台账行中。

收集目录与原始证据

• <collection-dir>指Git 之外的私有、任务专用目录；临时原始文件放在其下evidence/子目录，不复用ingest/data；
• 删除草稿前，源文件必须保留在 Drive 并留有可续传的上载清单；
• 截图类证据必须显示已加载的数值、账户和所选期间；加载中画面或其他账户的页面不算证据。

发票归档到 Google Drive

每张新发票/导出在下载后立即上传到记账 Google Drive，并在继续下一个供应商之前确认 Drive 中可见。目录结构、文件命名（YYYY-MM-DD__Vendor__Number.pdf，日期取发票日期而非邮件/付款日期）、月份文件夹 ID 表与覆盖性检查（coverage check：对账前先列目录、与供应商发票清单比对、补传缺失文件）都定义在 references/drive-archive.md。

四张台账的字段语义

技能逐一约定了各数据源的职责。这些 Tinybird 数据源的规范定义位于 enter.pollinations.ai/observability/（由 operations/economics/README.md 指明），端点行为可从管道定义印证，例如 economics_vendor_ledger_api.pipe 展示了"同一entry_id按recorded_at取最新版本、墓碑记录隐藏"的有效视图逻辑。

• economics_vendor_ledger（供应商余额与用量）：用量记为负的paid/credit；计费退款记为正paid；积分（grants）与余额快照为正数、不是用量。source字段命名收集方式（api、cli、export、invoice、dashboard），而不是账单门户名。修正分类时保留带符号的金额。
• economics_bank_ledger（Wise 现金流水）：新增/复核过的证据以evidence_type=supplier_document或evidence_type=payment_statement为前缀。对账单证明的是"付款"而非供应商发票；只有把该事实作为"仅付款"（如返现/派付）复核后才加evidence_requirement=payment；文件夹和表单不是文档。跨币种付款要把发票对到 Wise 的原始/兑换金额，而不是月度汇率估算；分币种卡支付对应多条 Bank 行、但只有一张供应商发票。
• economics_stripe_sales（Stripe 销售事实）：存复核过的 Stripe 账户-月份-币种粒度的销售、退款、冲销、费用、stream 与覆盖度；绝不存客户或支付载荷。
• economics_pollen_usage（内部 Pollen 消耗）：存 Paid 与 Quest 的内部消耗，按供应商-月份粒度对账。该数据源定义见 economics_pollen_usage.datasource，从generation_event_v2直接物化出month, vendor, model粒度上的cost_paid/cost_quests/price_*/requests_*等聚合。Pollen 模型 ID 是记账身份：当期注册表别名绝不事后合并历史 ID；供应商标签只有等于该月 Pollen ID、或经注册表复核过的modelLabels表映射时才与 Pollen 模型连接；一个标签对多个 ID 分别开行时，键要限定为label | sku或label | line item；同一标签在不同时期指向不同 ID 时，使用带日期的规则（{ "until": "2026-05", "model": ... }）。无法连接的用量保持"待映射/共享上游/缺失明细"的可见状态，绝不摊派到各模型上。

另外两条身份约定：

• D1user是创作者 GitHub 用户名与当前余额的权威来源。Paid 与 Quest Pollen 属于非现金化的用量敞口（Paid 可调用全目录，Quest 只能调用合格目录），不得归类为 Revenue Share，也不得从现金 Runway 中按面值扣除；暂存快照只保留 user ID、GitHub 用户名、两种余额与同步时间，姓名/邮箱字段留空。
• creator_payout是一次性的 Revenue Share 结算与运营费用。

写入纪律：任务范围、备份与双重审批

台账写入必须"任务限定"，不新增永久性 ingest 代码。技能规定写入前的完整流程：

1. 先查询有效数据源（effective datasource）；
2. 保存并核验一份完整的本地备份；
3. 展示精确的拟写入行与合计；
4. 对既有entry_id的修正必须包含当前基础版本、使用更晚的recorded_at，并保留不可变身份字段；修正事实时复用原有的确定性entry_id，绝不为同一事实创建第二个身份；
5. 只有在获得"具名批次 + 环境"的显式批准后追加写入，然后回查每一条已写入的 ID，保存核验过的写入后快照；
6. 先验证 staging，production 需要另行审批。

Staging 验证使用 operations/economics/secrets/web.dev.json 中的TINYBIRD_ECONOMICS_READ_TOKEN；明确禁止用已弃用的TINYBIRD_OPS_READ_TOKEN验证 Economics staging 应用——它可能解析到另一个工作区。限定范围的 ingest token 只用于原始数据源备份/读取与已批准的追加写入。

这一 append-only 语义与 operations/economics/README.md 的说明一致：银行台账与供应商台账的修正均通过复用稳定entry_id并带更新recorded_at追加实现；供应商墓碑使用显式source=tombstone标记，原始台账中保留、有效端点中隐藏。

当前月始终按"不完整"（partial）处理，不做补全推测。

完成标准：三个条件缺一不可

技能对"某供应商-月份已完成"给出闭合定义：账户覆盖（account coverage）、供应商用量、以及所需的发票/对账单证据三者全部落实。缺失的数据源要直接报告，不用估算或回退值掩盖。

对照本文梳理的完整链路——注册表定身份（provider-registry.json的category/cashRules/runwayLine/modelLabels/retiredModels/pollenVendorOverrides）、单份连接器指南定取数路径（API → CLI → MCP → 仪表盘）、月度结果定数据语义（余额/用量/发票三分离、UTC 覆盖与到期核验）、references/与台账的公私分离、以及带备份与双审批的 append-only 写入——可以看出该工作流本质上是一套可审计的供应商成本数据管道：每个进入 operations/economics Economics 应用（其 Runway 由economics_bank_ledger_api、economics_vendor_ledger_api与已核验余额按 operations/economics/web/src/lib/forecastTerms.ts 中的规则数学推导）的数字，都能沿台账行的证据链接回溯到一张已归档在 Drive 的具体凭证。

• AI 应用
• 媒体生成
• 后端
• 前端