一个反直觉的现象
最近和不少做金融ToB的朋友聊，发现一个很有意思的现象：大家都开始用Cursor、Codex写代码了，产出速度确实快了不少，但交付速度并没有等比例提升。有些团队甚至觉得更慢了——代码改得多了，回归测试跟不上，线上问题反而变多了。
这个现象反直觉，但并不难解释。
AI加速的是“写”，但交付瓶颈从来不在“写”。 交付瓶颈在于：你改了A模块，B模块会不会炸？你加了个新功能，权限有没有漏洞？你重构了一段逻辑，账务会不会算错？
说白了，AI是一台马力很大的引擎，但你的系统是一条坑坑洼洼的路。引擎越猛，你翻车越快。
所以今天我想聊的不是AI工具怎么用——那些技巧层面的东西你自己摸索就行。我想聊的是：在AI编程时代，你的系统需要什么样的架构基底，才能让AI的速度安全落地。
这件事对金融ToB场景尤其重要，因为金融系统不允许“快而不准”。
架构的本质：控制变更成本曲线
很多人对“架构”有误解，觉得架构就是画框图、选中间件、搞微服务。这些都是手段，不是目的。
架构的本质是什么？是一组关于系统结构的决策，这些决策决定了你未来每次变更的成本。
如果架构好，系统越做越顺，每次改动的范围可控、可验证、可回滚。如果架构差，系统越做越慢，每次改动都像在拆炸弹。
对于“小团队+金融ToB”的场景，架构要解决的核心问题就两类：
第一类：边界决策。 哪些东西必须隔离？租户隔离、权限隔离、账务与业务隔离、对外接口与内部实现隔离。边界清晰了，AI才能在一个模块里放心地写代码，而不会牵一发动全身。
第二类：护栏决策。 哪些东西必须可验证？幂等、对账、审计、回滚、测试、可观测性。护栏到位了，AI产出的代码才能被你快速验证，而不是写完之后你还得逐行审查。
当边界清晰、护栏到位时，AI才能在“可控范围”里高速产出。否则，AI只是帮你更快地制造技术债。
金融ToB的质量属性排序
不同系统的架构优先级完全不同。做社交的可以先跑起来再说，做游戏的可以容忍偶尔的数据不一致。但金融ToB不行。
我认为金融ToB管理后台的质量属性优先级应该是这样的：
1. 正确性与可审计性。 钱和权限必须算得清、查得到、追得回。这是底线，没有商量余地。
2. 安全与合规。 身份、权限、数据访问、密钥管理、操作留痕。金融监管越来越严，这个不是可选项。
3. 可维护性。 需求频繁变、人员有限，必须靠结构降低理解成本。这一点直接决定你的交付速度。
4. 交付效率。 自动化测试、灰度发布、快速回滚、环境一致性。
5. 可靠性与可用性。 故障隔离、降级、恢复、告警。
6. 性能与成本。 不是不重要，而是在结构正确之后更容易优化。
你会发现，大多数团队喊“成本高、交付慢”，根源都在第3、第4项：可维护性差导致每次改动都要全局理解，回归范围大，交付自然慢，人力成本自然高。
所以你最先要补的，不是什么高并发、分布式，而是“模块化+工程化交付”这条链路。
模块化单体：小团队最务实的选择
大厂喜欢上来就搞微服务，但我一直觉得这对小团队是灾难。
微服务的分布式成本是真实的：服务发现、链路追踪、分布式事务、独立部署流水线、网络延迟、运维复杂度。这些东西每一项都需要人力和基础设施来支撑。一个5到10人的团队去搞微服务，大概率的结果是把80%的精力花在运维和联调上，真正写业务的时间反而更少了。
我推荐小团队用模块化单体（Modulith）。
什么意思？在一个代码仓里，把系统按业务边界划分成独立的模块，模块之间通过显式接口通信，不允许互相直接访问数据库表。像微服务一样有边界，但不承担微服务的分布式成本。
你可以把系统分成四层，但重点不在分层，在于依赖方向：
Interface层：Controller、RPC、MQ Consumer、Job Handler。接收外部请求。
Application层：用例编排。事务边界、权限检查、调用顺序、DTO转换。
Domain层：领域模型与规则。状态机、金额计算、风控规则、权限策略。
Infrastructure层：DB、Cache、MQ、第三方支付、对象存储。
关键原则是：依赖方向向内，Domain层不依赖DB和MQ。 IO和业务规则必须分离。AI写代码时最容易把IO和业务搅在一起，你要用结构纠正它。
当你未来真的遇到独立伸缩或团队扩张的需求时，再把某个模块“自然地”拆成服务。这比一开始就搞微服务然后到处踩坑要高效得多。
模块边界怎么划
金融ToB系统的模块划分，我推荐三种方式混合使用。
按业务能力划分
这是最常见的方式：Tenant（租户）、Identity（认证）、Permission（权限）、Order（订单）、Ledger（账本）、Settlement（清结算）、Risk（风控）、Reporting（报表）、Integration（对外接口）。
按数据归属划分
这在金融系统里特别重要。谁拥有数据、谁能写、谁能改规则，边界就在哪里。
举个例子：Order模块拥有订单表的写权限，Ledger模块拥有流水分录表的写权限，Reporting模块只读。如果Reporting模块能改交易表，边界就崩了。
按变化频率划分
高变化：运营规则、活动配置、报表、流程编排。低变化：账务规则、权限模型、核心状态机。
把高变化的东西隔离出来，你会明显感觉“改起来更轻”，AI也更容易在高变化模块里安全产出。
金融系统的六块硬骨头
做金融ToB管理后台，有六件事处理不好就会反复拖慢你的交付。
多租户隔离
小团队从逻辑隔离起步没问题，但要把它做“硬”：每张业务表都有tenant_id，所有查询默认带tenant_id（在ORM层做拦截），管理员跨租户访问要显式标记并进入审计。
这三条是底线，不做到位后面全是坑。
权限模型
RBAC打底，ABAC兜底。权限检查集中在Application层，不要散落在Controller里到处if。所有敏感操作引入maker-checker（四眼原则）——提交人和审批人必须分离。
权限策略要写成可测试的函数，不要搞一堆注解魔法。AI能帮你写测试，但前提是你的权限逻辑是可测试的。
审计日志
金融系统的审计不是记个“谁点了什么按钮”就完事。你要能回答：谁、在什么时间、对哪个租户、做了什么操作、操作对象是什么、操作前后的差异是什么、操作依据是什么。
建议把审计当成独立模块，事件不可变（append-only），与业务写入解耦。
幂等
幂等不是加个唯一索引那么简单。你至少要定义：幂等的粒度（接口级还是业务动作级）、幂等key（谁生成、如何传递）、重复请求的返回策略。
实用做法：每个外部请求带request_id，维护一张idempotency_record表，先insert利用唯一键判重，冲突了就返回已存在的结果。这样你可以抵抗重试、超时、消息重复投递。
对账
对账的本质是：在两个或多个系统之间，基于同一批事实，重复计算并比较差异。
架构要点：保留原始回执，记录对账批次和差异项，差异处理走审批流程并可追溯。绝对不允许“手工改账本”，只能通过冲正或补录形成新的事实。
状态机
金融流程一旦复杂（支付、退款、清结算、额度变更），状态机是最有效的治理手段。明确状态集合、事件集合、每个转换的前置条件与副作用，每次状态变化记录事件日志。
状态机的好处在AI时代特别明显：当你有清晰的状态机定义时，AI生成代码更不容易“漏一个分支”，你也更容易验证AI的产出是否正确。
一致性：别和CAP辩论，先把工程问题拆清楚
小团队的ToB项目不是超大规模分布式系统，但你依然会遇到MQ重复消费、第三方超时回调乱序、跨模块一致性、报表最终一致这些问题。
我的建议是：统一你的可靠性语义。 把几类常见动作统一成可复用的模式，减少每个业务都重新发明轮子。
超时：每个外部调用都必须有超时，没有例外。
重试：只对幂等动作重试，指数退避，有最大次数。
去重：消费者基于幂等key去重。
补偿：失败后有可执行的补偿流程。
当你需要“写DB+发消息”保持一致时，用Outbox模式：在同一个本地事务里写业务表和outbox表，用后台任务把outbox发到MQ。简单、可靠、可追溯，是小团队做最终一致的性价比之王。
当你确实跨多个步骤时，用SAGA。小团队建议用编排式SAGA（中央流程编排器），比协同式更易理解和排错。
让AI真正提效的关键：把项目改造成“AI友好型”
你已经在用AI工具了，这是好事。但大多数人只是用AI来“写代码”，我认为这浪费了AI80%的能力。
AI真正能帮你做的事情远不止写代码：需求分析、方案比较、测试生成、代码审查、文档维护、重构规划。但前提是你的项目结构能让AI“理解”你的系统。
三个前提条件，缺一不可：
稳定的项目结构。 目录、命名、模块边界清晰。AI需要从结构中理解上下文。
可运行的自动化。 最少要有一键测试、一键启动。AI产出的代码必须能被自动验证。
清晰的契约与规范。 接口契约、错误码、日志字段、DTO规则。AI需要这些来保持一致性。
这三点是AI提效的放大器。否则AI会把耦合与混乱也加速放大。
当你把这些基础设施建好之后，你可以让AI做更多事情：写ADR草案、生成测试用例、做Code Review、规划重构路径。每一件事都能节省你大量的时间和精力。
写在最后
我一直认为，架构能力不是一种“高级技能”，而是一种工程纪律。它不需要你读多少论文、用多少新技术，而是需要你对“边界”和“护栏”有清醒的认识，并且有纪律地执行。
在AI编程时代，这种纪律变得更重要了。因为AI给了你前所未有的产出速度，而速度在没有结构约束的情况下，只会加速制造混乱。
对于金融ToB的小团队，我的建议很简单：不要追求架构的“全面”，追求架构的“准确”。 把模块边界画清楚，把自动化护栏建到位，把AI工具用对地方。用两到六周的时间，把项目改造成一个“模块边界清晰、自动化护栏到位、可灰度可回滚”的AI友好型系统。
当你做到这一点，你会发现：需求更敢接、重构更敢做、上线更敢频繁、成本开始下降。
这不是什么宏大的架构蓝图。这就是工程纪律。
注：本文风格参考陈皓（左耳朵耗子）的技术写作风格。