Tributo —— 为自雇者带来税务清晰

问题所在

乌拉圭自雇者的税务既零散又充满焦虑。一个 unipersonal(个体经营者)一年中要应对大量义务, 这些义务横跨两个机构——DGI(国家税务局)与 BPS(社会保障局)——它们的日期和金额取决于 所属税制、义务类型,有时还取决于纳税人自己的数据。人们只能靠会计、PDF、记忆和 WhatsApp 消息勉强应付,而一旦出错,代价是实打实的:错过截止日、罚款、每日滞纳金,以及每个到期日 之前那种揪心的恐惧。

现有的本地工具大多只解决交易层面的问题——e-invoice 开具、记账服务、ERP。没有一个解决 理解 本身。Tributo 正是为此而生,围绕一个具体的问题:

我需要交什么,什么时候到期,该准备多少钱?

产品做什么

只需回答几个关于你处境的大白话问题——不用挑税制,不用学税法条文——Tributo 就能构建一份 个性化的年度税务日历:跨 DGI 与 BPS 的每一项义务,附上到期日、估算金额、下一笔付款,以及 一个风险状态,再加上每个截止日之前的 email 提醒。

它的核心原则是诚实。每一个数字都属于三类之一,并始终标注清楚:exact(它有把握的固定 数值)、estimated(根据你的开票额算出的,会以"~"标记),或 reminder only(没有金额, 因为算它所需的数据不存在)。那条红线是:当它无法精确计算某个情形时,它会如实说明,而不是 编一个数字出来。而且每一个金额都能展开,显示逐步的计算过程,以及通往 DGI 或 BPS 官方来源的 链接——信任靠展示建立,而非靠隐藏。

它为两个世界而造:本地自由职业者(monotributistas、个体经营者、小店主),他们为简单的事 多花了钱,还要追着每一个到期日跑;以及外籍人士,他们尚未理解本地的体系、语言,或自己的 税务居民身份的含义。它从第一天起就是多语言的——Spanish、English、Russian 和 Portuguese。

我构建了什么

这个产品,是我独立通过指挥 AI 代理完成的。 产品立意、架构、税务领域模型,以及审查都是 我的;实现则由 AI 代理依据一份分阶段的规格来产出——每个阶段都端到端地构建,带单元、集成和 e2e 测试,并在下一阶段开始之前先写出一份报告。

一个税务引擎,而非一个内容网站。 核心把一份最小化的税务画像转化成一份具体的日历: 哪些义务适用、每一项何时到期、该准备多少——它被建模为显式的领域类型和 value objects, 所以一个日期或一笔金额永远不会是一个松散的字符串。三层金额模型(exact / estimated / reminder-only)是一个一等的领域概念,而不是 UI 上的装饰。

诚实是一项工程约束。 "从不凭空捏造数字"是在领域里强制执行的:一项义务要么有一个可计算 且可追溯推导的金额,要么它携带一个日期和一个提醒,压根没有数字。用户看到的每一个金额都能 展开,显示它的计算步骤和它所依据的官方来源。

提醒与作业。 到期日提醒运行在一个真正的 job runner(Trigger.dev)上,带调度、重试和 可观测性,并通过 email(Resend)发出——这样"我们会及时提醒你"的承诺就是可运行的,而不是 口号。

从一开始就具备生产姿态。 用 Better Auth 管理账户,用 PostgreSQL 作为记录系统(Prisma 只用作持久化 adapter,被挡在领域之外),用 tRPC + Zod 为 web 应用和未来的移动客户端提供 带类型的契约,用 PostHog 和 Sentry 做分析与错误追踪,用 Railway 做托管和数据库,还有一套 完整的测试栈——Vitest、React Testing Library、Playwright,以及用于 Postgres 支撑的集成 测试的 Testcontainers。

架构选择

clean architecture,按国家塑形。 Tributo 是一个模块化单体,税务领域居于中心,基础设施 位于边缘。关键在于,国家逻辑——税务日历、规则、知识,以及政府 adapter——都活在按国家划分的 模块里,藏在稳定的接口之后。乌拉圭是第一个模块;阿根廷以及 LATAM 的其余国家都能在不重写 核心的前提下加进来。这个产品从第一行起就是为扩张而设计的。

是智能层,而不是 ERP。 Tributo 在 v1 里刻意不去做会计事务所、ERP,或认证的 e-invoicing 提供商。它处于用户、政府系统、银行,以及现有开票工具之间,作为那一层去解释、规划、提醒和 引导。正是这样的范围界定,才让一个人能够快速交付出真正有用的东西。

mobile-first,因为用户就在那里。 这个 MVP 是一个响应式 web 应用,优先为手机而设计—— 税务焦虑发生的那一刻是在手机上,所以日历、下一笔付款,以及提醒,都先于其他一切为那个视口 而构建。

AI-native 的交付方式。 有意思的地方不在于代码是 AI 写的——而在于那个循环:一份分阶段的 规格、代理为每个阶段带着测试去实现、每个阶段一份英文的实现报告,以及由我来掌管产品、税务 模型和审查。这和我其余项目是同一个论点:工程师的工作正在从敲代码,转向定规格、做审查和 拿决定。

当前状态

Tributo 已上线 beta,地址是 tributoclaro.com,多语言 (es/en/ru/pt),以面向乌拉圭 unipersonales 的 mobile-first 税务日历作为第一个界面。 MVP 之后的路线图包括一个 AI 助手(Tribi)、一个税务优化器、一个注册向导、一个外籍人士模式, 以及 Domicilio Electrónico 监控——而在结构上,还有下一个国家。它被当作一个真实的产品来对待: 带类型的契约、一个真正的 job runner 来发提醒、便于审计的数据,以及那条把诚实规则接进领域、 而非螺在 UI 上的红线。