金融系统出bug和出资损，是两个完全不同的量级。功能写错了，改过来就是；页面丑了，迭代一轮就行；但钱算错了，那是客诉、是赔付、是监管约谈，严重的时候直接停业整改。

我观察到一个很普遍的反应模式：出了资损，先加测试用例；又出一次，加人肉对账；再出一次，加发版审批。每一步都在做加法，每一步都离根本原因更远。因为大部分人把资损当成了一种"严重的bug"，用防bug的思路来防资损。这个认知偏差才是资损反复出现的根源。

资损不是bug的严重版

普通bug和资损的核心区别在于：bug是你功能做错了，资损是你的功能没做错，但钱错了。

一个理财产品页面，把年化收益率3.5%展示成3.8%，这是bug。但用户基于3.8%做了购买决策，实际到账按3.5%结算，用户体验上的落差就是资损——即使从功能角度看，展示模块和计算模块各自都"按逻辑运行"。

更典型的场景：用户申购一笔理财，网络超时，前端重试了一次，后端处理了两笔。这两笔处理的每一笔单独看都没"错"——接口接收请求、参数校验通过、数据库写入成功。但因为缺少幂等约束，结果就是资损。

上周清理日历的时候顺手做了个统计——我所在的技术团队，10个人，一周62个会议。人均每周6.2个，平均每天1.2个。如果按每个会议40分钟算，将近四小时。还没算上会前准备和会后消化，还没算上那些"5分钟碰一下"的临时通话。

这不是个别现象。我跟同行聊过，金融科技领域尤其严重——合规对齐要开会，风险评审要开会，跨团队排期要开会。一个需求的开发周期里，真正写代码的时间可能还不到一半。

很多团队的第一反应是"减会"——砍掉每日站会，缩短周会，设立无会议日。然后呢？信息断了，对齐塌了，出问题的概率反而上升。砍完的会议像野草一样换个形式长回来。

我后来想明白了这件事：会议不是问题，会议是症状。就像发烧不是病，是身体在对抗感染。你把体温压下去，不等于治好了。

每个砍不掉的会，都在替系统还债

技术团队里的会议，大致可以分几类。每一类背后都藏着不同的问题。你不可能一刀切地减掉它们，因为砍掉会议后露出来的那个洞，可能比会议本身更危险。

同步会：你的模块边界画错了

两个子系统需要"定期同步"，这是最常见的一种会。前端和后端每周对齐，A团队和B团队双周同步。听起来很合理，但仔细想想——如果两个模块之间需要定期人工同步，说明什么？

DRY——Don't Repeat Yourself。这四个字母可能是软件工程里被引用最多、被误解最深的原则。

每个程序员入行第一天就被告知：重复代码是邪恶的，看到重复就要提取，看到提取就要抽象，看到抽象就要泛化。于是我们疯狂地消灭重复——公共函数、工具类、基础库、共享模块......代码库越来越"干净"，重复率越来越低，CI里没有任何duplicate code的警告。

然后某一天，一个业务需求来了——需要改动某个"公共"逻辑。你打开那个被47个地方引用的utils函数，改了一行，跑了一下测试——绿了。上线，结果三个业务线同时报警。你突然发现，那三个业务线依赖的是同一个函数的三种不同行为，被那个"公共"函数强制统一了。

你消灭了重复代码，但你制造了耦合。而耦合，是比重复贵十倍的技术债。

重复代码不是问题，问题是不知道为什么重复

所有关于DRY的讨论，都默认了一个前提：重复等于坏。但这个前提本身就是幻觉。

重复代码至少有三种完全不同的面目。

第一种是意外重复——两个开发者不知道对方写了同样的功能，造了两个轮子。这种重复才是真正需要消灭的，因为它意味着信息浪费和潜在的不一致。

前端的现状有点荒诞：我们嘴上说自己在写 UI，实际上大部分时间在跟数据较劲。Redux、Zustand、React Query、SWR、Dva、Pinia——每出一个新方案，大家就觉得"这次终于对了"。但如果你把所有这些方案放在一起，去掉它们的外壳看本质，会发现一个尴尬的事实：它们解决的问题，数据库几十年前就解决了，而且解决得更好。

我们不是在做状态管理，我们是在重新发明数据库。只是发明得很差。

一个 Redux Store 就是一个简化版数据库

Redux 可能是最明显的例子。你写一个 Redux store 的时候，本质上在做什么？

定义一个全局的数据结构——这叫 Schema。写 reducer 处理 action——这叫事务（Transaction），action 本身就是 WAL 日志。写 selector 查询数据——这叫查询引擎。写 middleware 拦截 action——这叫触发器（Trigger）。用 normalize 归一化数据——这不就是数据库范式吗？