从内部工具到 SaaS：自动化银行对账单下载
我们写了一个自动下载 Wise 银行对账单的脚本，一个下午就能完成。更值得讨论的问题是：它能否服务其他有同样需求的企业，以及如何负责任地完成这种转变。回答这个问题花了长得多的时间。从开发者笔记本上的 CLI 脚本，到带邮件通知的容器化服务，这个过程暴露了一系列值得记录的决策，尤其适合正在评估是否将内部自动化工具做成产品的团队参考。
最初的问题
Wise 提供账户数据 API，但多数财务团队的标准流程仍是在每月底登录网页，手动下载 CSV 对账单。单账户、单币种只需两分钟；涉及多个 Wise 账户和币种时，就成了必须有人记得执行、始终按同一流程操作并正确归档的重复工作。对于在不同区域开展支付业务的企业，这种情况很常见。
Wise API 提供了所需的端点：列出账户资料、获取各币种余额，以及按任意日期范围导出 CSV 或 PDF 对账单。身份验证使用在 Wise 开发者控制台生成的个人访问令牌。正确限定权限后，令牌只能读取账户数据，因此可以存储和使用它，而不必承担可发起转账的令牌所带来的风险。
最初的实现约有 80 行 Python 代码。它从环境变量读取凭据，遍历账户资料和各币种余额，构建上个月的对账单请求，并将输出文件写入本地目录。脚本手动运行，已经足够满足当时的需求。
从脚本到定时服务
从“手动运行”到“自动运行”，会出现另一类问题。手动运行的脚本即使静默失败，也会立即被发现；每月第一天定时运行的脚本若静默失败，可能数月都无人察觉，直到审计时才发现对账单归档存在缺口。
我们将脚本放进 Docker 容器，使用简单的入口脚本，并增加包装层，在任务完成后发送邮件，无论成功还是失败。邮件汇总处理的账户和币种、下载的文件数与大小；失败时附带错误输出。这是很小的一笔可观测性投入，却改变了运维约定：即使任务无人值守，也仍有人监督。
调度由 GitHub Actions 承担，而非容器内的 cron。我们使用工作流的 schedule 触发器，让它在每月月初运行；仅靠 cron 调度无法指定工作日，因此要跳过周末和节假日，需要在工作流中增加日期检查。工作流检出仓库，在 Docker 镜像发生变化时构建镜像，将 GitHub Secrets 中的机密注入容器后运行，并将输出文件上传为工作流产物。产物保留 90 天，形成独立于本地文件存储的可检索归档。
相比服务器上的 cron 任务，GitHub Actions 的实际优势是执行过程可见。工作流运行历史显示每次执行、耗时、退出码及生成的产物。服务器上的 cron 日志容易被忽略，任务还依赖服务器可用性。对于月度任务，版本受控的工作流定义和可审计的执行历史，值得付出少量工作流配置成本。
“多租户”究竟需要什么
容器化版本稳定运行数月后，其他企业的同事询问能否使用。问题听起来很简单：其他人能否运行您的工具？实际上，“其他人运行您的工具”涵盖了多种运营模式，其影响截然不同。
最简单的模式是共享仓库与文档，由用户在自己的 GitHub Actions 或 Docker 环境中运行，不提供支持。这是开源分发，而非 SaaS 产品。运维责任完全由用户承担。
下一步是由您托管工具，用户通过配置界面提供自己的 Wise API 令牌。此时，您就掌握了凭据。这会立即带来与个人自动化在性质上不同的安全和合规义务。您必须回答：凭据如何存储、谁能访问、存储遭入侵后如何处理，以及用户的 Wise 账户通过您的平台被访问时，您承担什么责任？
再往后，还涉及计费、支持、服务等级承诺，以及为多个用户运行基础设施的运维开销。这些问题都不是无法解决，但每一项都需要决定愿意投入多少工程工作，以及承担多少持续运维成本。
SaaS 评估
我们列出最低可行多租户版本的要求，并如实估算每项成本。仅凭据管理——安全存储 Wise API 令牌、提供管理界面，以及通过访问控制阻止跨租户访问——就需要一周工程工作，还没涉及实际的对账单下载功能。加上用户身份验证、计费、支持退订处理的邮件投递服务，以及逐租户任务失败监控，就成了需要持续投入才能安全维护的产品。
这类工具的市场也有限。规模大到需要自动下载对账单的企业，往往也已足够大，采用了直接集成 Wise 的会计软件，或由财务团队通过自己的方式解决了问题。可服务的市场是中间群体：已经感受到这项工作的负担，却尚未采用集成会计系统的企业。
我们的结论是：现阶段，这个工具不适合由我们的团队作为 SaaS 推出。收入潜力不足以支撑工程和运维投入。开源分发能够满足实际需求，也不会带来我们无法持续承担的义务。
保留下来的功能与后续改进
内部工具仍在运行。后来我们增加了 CSV 之外的 PDF 输出、将对账单文件直接发送到邮箱而不必下载工作流产物，以及可配置的日期范围。这样既能手动触发临时对账单请求，又不影响每月定时任务。
GitHub Actions 工作流成为标准部署方式。我们在仓库 README 中详细说明用途和操作方法，确保半年没接触工具的人也能理解。这种做法适用于任何内部自动化：按照将来要交接给他人的标准维护内部工具，因为迟早会有这一天。
这个项目最持久的经验，是“对我们有效”与“对别人有效”之间的差距。内部工具适配的是自身约束：凭据管理方式、文件存储约定和邮件基础设施。让工具足够通用，能够供其他人使用，远不止增加一个配置文件。需要抽离那些原本没意识到的假设，而这些假设往往要等别人实际使用并碰到问题后才会暴露。