技术沉淀

验收现场的顺序和开发时相反：客户不先点你讲了半小时的下单流程，而是拿出自己的 Excel 导一遍，再导出一张报表，最后打一张单。主流程决定系统能不能用，这三件事决定客户明天能不能上班；它们没有技术难度，只有工作量，报价里不写，后面就是免费加班。

演示阶段准备二十个问题，答对十九个不难；接进业务系统之后，真正会出事的是它把另一个租户的制度答了出来，语气还很确定。RAG 的工程难点不在模型，在检索前的权限过滤、文档版本和删除的同步、一套从真实工单里长出来的评测集；Agent 再往前走一步，写操作必须停下来等人确认。

凌晨一点半，客服在群里说“系统很卡”，这句话没法直接动手。要先把它拆成谁慢、哪个接口慢、从几点开始，才谈得上排查。200 QPS 的系统用不上重型 APM，但 traceId、四组指标和每条告警对应的 Runbook 缺一不可；这三样没有，监控大盘只是挂在墙上的屏保。

迁移项目开工第一天，客户发来一个压缩包，说数据都在里面。导进去只用了一个下午，财务发现上个月的应收少了一万二千七百八十八，用了三个星期才问明白差在哪。迁移的验收，说了算的是客户财务签字确认的金额、总量和权限范围；Excel 的合并单元格、期初余额、旧单号、离职员工，每一件都能让这个签字拖到下周。

内网机器不给出网，最小化镜像里没有 CA 证书和中文字体，jar 里的 native 库只带 x86_64，镜像 tag 写成 latest 到了离线环境就是一个陌生的镜像名。“在我机器上跑通了”这句话在客户机房里不值钱，介质、环境检查、库结构、密钥、升级和回滚，每缺一样都能让安装卡在当场。

只比渠道账单和我方订单，抓不到手续费漏记和分账记错。对账要能回答“错在哪一层”：渠道流水、业务订单、账户分录各对一次。下载地址 30 秒就失效、微信账单只给三个月、账单里的退款行出账后状态不再更新，而对账系统自己的失效方式是任务返回成功。

余额字段一旦能被 update，账就只能靠人工对平。账户管谁是主体、流水管动了多少、凭证管为什么动，三张表各管一件事。分账规则要带生效区间，退款要按原分录反向冲销，可用和冻结别做成一行两列。代收再结算算不算二次清算，这条线绕不开。

支付回调出错时不会报错。验签过了不等于认对了这一单，接口回了成功不等于账落了，退款受理不等于退成功，对账脚本解析出零行也照样返回成功。这些错全靠表结构和幂等键挡住。

订单状态那一列管得住“现在是什么”，管不住“谁把它改成的”“当时能不能改”“同一件事收到两次会怎样”。把 updateStatus(id, 3) 换成事件加守卫，改动量就是那十几处调用各自想清楚自己发的是哪个事件。

隔离模型选对了，租户条件仍然会从别的地方漏掉。缓存 key 少一段前缀，线程池里的上下文随着工作线程复用飘走，定时任务不带租户跑全表，搜索索引查询忘了 filter。八处的共同点不是层级深浅，是它们都绕开了你写好的那一层租户拦截器。按爆炸时间从上线第一天排到第一次月结。