AI 应用媒体生成后端前端【免费下载链接】pollinationsYour Friendly Open-Source Gen-AI Platform项目地址https://gitcode.com/gh_mirrors/po/pollinations点击查看免费下载本篇技术文章基于 Pollinations 开源仓库中economics-provider-collection技能的 Wise 连接器参考文档 wise.md 展开系统讲解如何用 Wise 官方 API 拉取银行流水与余额、如何以 statement 为准做月度采集与对账、以及期初余额opening balance锚点如何支撑 Runway 现金流测算。读完后你可以掌握一套“API 采集 → 证据归档 → 账本写入 → 对账验证”的完整银行流水处理方案并理解其中分页、跨月结算、多币种锚点等关键设计的原因与约束。1. 文档定位供应商采集技能中的一个连接器指南在 Pollinations 的私有运营体系中operations/economics是一套管理现金流、Runway、供应商成本、信用额度与单位经济学的内部应用详见 operations/economics/README.md。围绕它仓库维护了一个 Claude 技能 economics-provider-collection用于刷新供应商数据、检查账户、准备月度关账以及对账。该技能的工作方式是先读取单一供应商列表 operations/economics/provider-registry.json它拥有规范 vendor ID、别名、账户生命周期、月度评审状态、余额追踪决策与访问 URL再只读取所需供应商对应的连接器指南references/providers/connector.md由注册表的connector字段给出文件名按“API → CLI → MCP/认证连接器 → 仪表盘”的顺序选择第一个能提供权威且足够细粒度数据的来源。Wise 指南 wise.md 正是这套机制中针对银行端cash 侧的连接器文档其规范 vendor ID 为wise文档头部标注了验证状态Verified 2026-08-22profile、balance 与有界boundedactivity API 均可用全年 activity 分页、稳定资源 ID 与金额解析已对照 2026 年有效银行账本核验历史 card/direct-debit 行可以精确对账仅 statement 独有的拆分行作为显式例外保留。一个重要的边界约定Wise 指南只记录“如何拿到一个数字”路由、URL、命令、哪一列、哪种口径而数字本身存放在账本行中并携带证据链接。技能文档明确禁止把余额、发票总额、支出或发票编号连同金额粘贴进references/目录因为这个仓库是公开的——这解释了为何本文只能描述方法而看不到具体金额。2. Wise 在供应商注册表中的登记在 provider-registry.json 中wise的登记内容很有代表性——它不是计算类供应商而是一个行政admin类别的现金通道{ id: wise, label: Wise, category: admin, cashRules: [ { match: [cashback], inflow: true, category: revenue, cashOnly: true } ], meteringBasis: not_applicable, aliases: [], connector: null, monthlyReview: false, balanceTracking: false, collectionMethod: null }从源码结构看几个字段的含义是category: adminmeteringBasis: not_applicableWise 不产生 usage 事实因此没有计量基础也不参与常规月度评审monthlyReview: false、balanceTracking: false、collectionMethod: null。它的作用是作为“银行事实”的来源而不是“使用事实”的来源——这与 Wise 指南第一条已知陷阱“Wise is cash truth, not usage truth”完全一致cashRules当银行描述中出现cashback时识别为revenue类别的现金流入cashOnly: true表示只走现金流、不进供应商账本。这是注册表为“混合用途供应商”提供的银行描述规则机制账本中出现的任何新供应商必须先有注册表条目其现金才能被归类。3. 证据来源层级与官方 API 端点Wise 指南列出了采集时使用的证据来源优先级从高到低为API activityGET /v1/profiles/{profileId}/activities—— 有界时间范围内的流水API balancesGET /v4/profiles/{profileId}/balances?typesSTANDARD—— 当前时点的 STANDARD 类型余额API balance statements当 activities 不够细时对已知 balance ID 使用有界 statement 端点仪表盘/导出Wise Activities 导出、每个余额的 statement CSVBalances → statement这是包含完整结算真相含手续费与 running balance的数据同时也是 statement API 的 SCA key 尚未注册期间的变通方案本地文件已放入collection-dir/evidence/的 Wise CSV/JSON/截图交易上下文economics_bank_ledger账本本身。collection-dir是技能定义的“私有、任务专属、位于 Git 之外”的目录临时原始文件统一放在其evidence/子目录下截图作为证据时必须能显示已加载的数值、账户和所选期间加载页或他人账户页面不构成证据。凭证管理凭证以 SOPS 加密形式存放在secrets/env.json共三个键WISE_API_TOKENAPI 访问令牌WISE_BUSINESS_PROFILE_ID业务 profile IDWISE_BUSINESS_EUR_BALANCE_IDEUR 余额 ID。指南对凭证的使用有严格约束只在内存中解密任何情况下不得打印 token、profile、balance、account 或银行详情也不得在账本条目的 notes 中暴露账户令牌或个人银行信息。技能的总纲SKILL.md进一步规定只允许使用既有授权凭证创建、轮换、同步或部署凭证属于“secret-mutation”范畴需要仓库单独的密钥变更计划与显式范围授权。4. 采集流程六步操作与关键参数指南定义了 6 步采集流程每一步都有明确的行为约束4.1 优先复用已有账本首选现有economics_bank_ledger只要它已覆盖请求期间就不要再拉取。该账本就是“由 Wise 衍生的 Economics 现金账本”重复采集只会引入重复事实。4.2 拉取缺失或实时期间显式边界 游标分页 35 天重叠对缺失或实时期间请求 Wise activities 时必须满足三个参数条件显式 ISO 8601 的since与until边界size100沿cursor以nextCursor持续翻页直到其为 null。其中“回读前 35 天”是一个容易被忽略但至关重要的细节一条在月初边界之前创建为 pending 的活动可能结算到请求月内。也就是说活动创建时间与结算月份并不总是一致——statement 的结算日期settlement date才决定它记入哪个月。因此仅按日历月拉取活动会造成跨月漏记35 天的重叠窗口是为 pending→settled 的跨月结算留出的安全余量。4.3 现金余额即时验证对“cash-now”验证列出STANDARD类型余额并用显式带日期的 FX 来源把每个余额折算到所选报告币种。约束是不持久化该快照余额是“当前状态”而非“历史燃烧率”且除非用户要求不包含 JarsWise 的储蓄容器。4.4 证据归档当结果会成为持久证据时把原始 API/导出 JSON、CSV 或截图保存到collection-dir/evidence/。4.5 条目生成与对账导出交易证据需要变成账本条目时使用本技能对账时同时比对发票条目与economics_bank_ledger。5. 月度拉取的操作规则指南对“月度拉取”给出了更细的运行时纪律这些规则与技能总纲的“证据与账本”一节互相印证任务级进程不写永久脚本在任务级task-scoped进程中使用既有加密凭证直接调用 Wise 官方 API明确“不要为有界的月度任务添加永久性 Wise ingest 脚本”。总纲同样要求账本写入保持任务级、不新增永久 ingest 代码翻页与过滤跟随每一个 activity 游标与前月重叠 35 天跳过 cancelled 与 card-check 活动遇到“真正的新商家”时停下来因为新商家必须先登记进注册表才能归类以 statement 为结算事实每一条拟写入的kind: transaction银行变动都必须使用 statement 的日期、金额、币种与手续费仅有 activity 的金额不构成结算现金证据activity 是“发生了什么”statement 是“结算成了多少”先展示后写入在任何账本写入之前展示确切的拟议行与合计。这与总纲要求一致——写入前先查询有效数据源、保存并验证完整本地备份、展示确切拟议行且需对指定批次与环境获得显式批准后才追加写入后重新查询每个 ID 并保存验证后的 after-snapshotstaging 与 production 分别审批。银行账本的数据模型economics_bank_ledger的有效端点定义在 economics_bank_ledger_api.pipe它对原始数据源按entry_id分组用argMax(..., recorded_at)取每个键最新的一条完整事实暴露entry_id, kind, source, date, vendor, category, amount, currency, description, evidence, recorded_at字段。也就是说纠错不是更新而是以同一entry_id、更新的recorded_at重新追加旧版本在原始数据源中永久保留。行类型kind的合法取值由前端管道契约固定见 pipeContracts.tseconomics_bank_ledger_api: { strings: [entry_id, kind, source, date, vendor, category, currency, description, evidence, recorded_at], numbers: [amount], enums: { kind: [transaction, opening_balance] }, },只有两种 kindtransaction银行流水与opening_balance期初锚点。6. Runway 期初锚点每种非零币种一行且共享同一天Wise 指南中最“数学化”的规则是 Runway 锚点Runway 需要每个非零 statement 币种各一行kind: opening_balance全部落在同一个“每月 1 日”锚点日期上。这些锚点只能从 statement 的 running balance 推导绝不能来自当前 API 快照也不能靠反推仪表盘合计得出。这条规则在 Runway 计算源码中有直接对应。runway.ts 中的实现会过滤出全部kind opening_balance行收集其日期并去重排序——若没有任何 opening 行直接标记 “No opening bank balance; cash balance and runway are unavailable.”若存在多个不同日期则标记 “keep one statement-backed anchor before calculating cash”要求保留一个 statement 支撑的单一锚点若锚点日期的“日”不是01openingBalanceDate.slice(8, 10) ! 01标记 “Opening balance ... is not the first day of a month”。这解释了指南为什么要求“同一月初锚点 每币种一行”多币种如 EUR、GBP各有 running balance但 Runway 计算要求它们在时间上对齐为同一个锚点日而“只从 statement running balance 推导”对应了端点对 running balance 的依赖——API 余额快照是即时的、易变的不能作为历史现金起点。operations/economics/README.md 也确认Runway 是从economics_bank_ledger_api、economics_vendor_ledger_api、受检余额与已评审的计算规则推导出来的不存在独立的 forecast 或 runway 账本。7. 证据类型与账本写入的证据约定技能总纲对economics_bank_ledger中的证据字段有具体约定Wise 采集时应当遵守新/已复核的证据以evidence_typesupplier_document或evidence_typepayment_statement前缀命名statement 证明的是付款不是供应商发票——两者不可互相替代仅当把某个事实作为“仅付款”例如 cashback/payout复核过之后才添加evidence_requirementpayment跨币种付款时发票应与 Wise 的原始/兑换金额匹配而不是月度 FX 估算银行扣款及其手续费都要保留一笔跨币种的卡支付可能对应多条 Bank 行但只对应一张供应商发票。8. 已知陷阱清单Known Traps指南最后列出了 10 条陷阱是月度采集时最容易踩错的地方值得完整保留#陷阱要点1Wise 是现金事实不是使用事实cash truth ≠ usage truth不能拿银行流水当供应商用量2结算币种常是 EUR即使发票是 USD对账时匹配 Wise 原始/兑换金额而非月度汇率估算3退款可能冲销先前扣款不应计为新支出4部分交易需要供应商别名或拆分逻辑依赖注册表中的aliases/cashRules/runwayLine5Activities API 的primaryAmount是展示文本不是数值金额必须使用活动资源或 statement 中的结构化结算金额6Activities 是游标分页前 100 行不代表完整期间必须跟完nextCursor7当月区间是“部分月”不能用作整月预测基线8余额响应只是当前验证快照不持久化且不能替代有界 activities、statements 或期初锚点作为历史现金证据9合并说明活动创建月 ≠ 结算月用 statement settlement date 记账重叠 35 天防漏记10不得暴露账户令牌或个人银行信息条目 notes 中不出现 token、profile、bank detail第 9 条是第 4.2 节“35 天重叠”规则的陷阱面表述与原文档第 4 步及第 76–77 行的“当月部分区间”约束同属一条纪律。9. 小结把银行流水变成可信账本的三根支柱回顾整套 Wise 采集方案其设计可以归纳为三根支柱来源分层优先复用economics_bank_ledger拉取时以“显式 ISO 8601 边界 size100 完整游标跟随 35 天重叠”保证期间完整性金额、日期、币种、手续费一律以 statement 为结算口径证据纪律原始文件归档到任务级evidence/目录并打上evidence_type前缀指南只写“怎么拿到数字”数字与证据链接留在账本行凭证 SOPS 加密、内存解密、永不打印账本契约kind只有transaction与opening_balance两种纠错以稳定entry_id追加新recorded_atappend-onlyRunway 锚点必须是“单一月初日期 × 每非零币种一行”且只能来自 statement running balance——这些约束在 pipe 定义、管道契约 与 runway.ts 中均有可验证的实现对应。如果你希望继续深入建议依次查看 技能总纲了解月度关账与账本写入审批流、Wise 指南原文、注册表vendor 身份与 cashRules以及 Economics 应用 READMERunway 推导与 append-only 纠错机制它们共同构成了这套银行流水采集—对账体系的完整上下文。赞分享AI 应用媒体生成后端前端【免费下载链接】pollinationsYour Friendly Open-Source Gen-AI Platform项目地址https://gitcode.com/gh_mirrors/po/pollinations点击查看免费下载相关推荐Pollinations Economics 供应商采集Regolo.ai 仪表盘连接器指南与月度对账实践Pollinations Economics 供应商采集Regolo.ai 仪表盘连接器指南与月度对账实践 Pollinations 仓库中的 operatiAI 应用媒体生成后端前端Pollinations Economics 中的 Stripe 采集指南从 Payouts API 到 PL 对账的完整实践Pollinations Economics 中的 Stripe 采集指南从 Payouts API 到 PL 对账的完整实践 本篇围绕 PollinatiAI 应用媒体生成后端前端Pollinations Economics 供应商对账实战Scaleway 账单、消费与折扣凭证采集指南Pollinations Economics 供应商对账实战Scaleway 账单、消费与折扣凭证采集指南 本文基于 Pollinations 仓库中的 ScAI 应用媒体生成后端前端上一篇RustGPT完整部署教程从源码到生产环境的简单步骤下一篇小米相机功能增强终极指南解锁MIUI隐藏摄影能力创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考