全表 · 不需要填任何东西就能看

银行核心系统里
哪些活能交给 AI,哪些不能

27 个场景,每个给一个红、黄或绿的结论,并说清为什么。 不是 27 个演示例子,是 27 件我真干过的活。

2006 年入行 · 2009 年起专做银行核心系统 · 服务过城商行与全国性股份制银行

判断标准只有一条

AI 输出的错误,能不能在上线前被查得出来出来?

查得出,就大胆用。查不出,就别让它碰。

下面 27 个结论,全是这一句话推出来的。再往下推一层还能更简单: AI 用在写代码的时候,不用在跑生产的时候。 写的时候出错,有测试、有评审、有新旧比对兜着,重写一遍就完了。 跑生产的时候出错,那是资金差错、客户投诉、监管罚单,而且它错得不可复现。

这条线是按后果画的,不是按模型能力画的。 模型再强一个量级,记账口径错了照样不报错,监管数字报出去照样撒不回。

红灯 · 7 项 · 绝不让 AI 碰

这 7 件事,我绝不让 AI 碰

共同点:错误不会在上线前暴露,且错了赔不回来。不是因为 AI 不够强,是因为错了以后你查不出来、也撤不回。

01资金交易的最终记账逻辑红灯

为什么是这个结论
记账错误不会报错,只会让账平不了。而账不平是往前追一整天的批量,不是改一行代码。
那该怎么办
让 AI 写这段逻辑的测试用例对账校验脚本,用它来验证人写的记账代码。

相关叫法:记账、入账、分录、总账、科目、借贷、过账、账务处理、资金划转、转账逻辑

02利息、费率的最终计算口径红灯

为什么是这个结论
少算一分钱,乘以百万账户就是监管问题。而口径对不对,测试用例测不出来——它取决于合同和监管文件怎么写。
那该怎么办
口径由人从制度文件里定,AI 负责把定好的口径翻译成代码,再写边界测试。

相关叫法:计息、利息、利率、费率、手续费、罚息、复利、年化、计费、结息

03生产数据的直接读取和处理红灯

为什么是这个结论
把生产数据贴进对话框那一刻,它就离开了你的机构。这不是技术问题,是数据出境和信息安全事件。
那该怎么办
让 AI 写脱敏工具,用脱敏后的数据做开发。工具本身可以让 AI 写,数据不能给它看。

相关叫法:生产数据、生产库、真实数据、客户信息、身份证、客户号、生产环境、线上数据、客户敏感

04运行期的自动决策红灯

为什么是这个结论
写代码的时候出错有测试兜底,跑生产的时候出错直接是客户投诉、资金损失和监管问询。而且它错得不可复现,你连是哪儿错的都查不出来。
那该怎么办
AI 用在写代码的时候。真正跑生产用写死的规则引擎,规则本身可以让 AI 帮你整理。

相关叫法:自动审批、自动放款、自动决策、实时风控、自动拒绝、智能审批、自动授信、在线决策

05监管报送的最终数据出口红灯

为什么是这个结论
报送数字错了是要被通报和罚款的,而且报出去就撤不回。取数逻辑对不对,只有懂制度的人能判断。
那该怎么办
让 AI 生成取数 SQL 的初稿和跨表校验逻辑,最终口径必须人对着监管制度逐项核。

相关叫法:监管报送、1104、报送、监管报表、人民银行、监管数据、统计报表、报送口径、监管指标

06加密、密钥和认证的实现红灯

为什么是这个结论
这类代码「跑通了」和「安全」是两件完全不同的事。AI 写出来能跑,但它可能用了不该用的模式或写死了随机数种子,而这些漏洞测试全绿。
那该怎么办
用机构已有的、经过审计的安全组件。AI 只负责调用它,不负责实现它。

相关叫法:加密、密钥、加签、验签、证书、认证、口令、password、token、国密、报文加密

07生产变更的直接执行红灯

为什么是这个结论
AI 生成一条 update 少写一个 where,等着你的是恢复备份加一次生产事故报告。这类操作没有「撤销」。
那该怎么办
AI 可以帮你写脚本并解释它做了什么,但执行前必须人读一遍、先在影子库跑、且带回滚方案。

相关叫法:数据修复、改数据、订正、跑批调度、生产变更、补数据、刷数据、执行脚本、上线操作、紧急修复

黄灯 · 8 项 · AI 写初稿,人必须签字

这 8 件事,AI 可以写,但签字的必须是人

共同点:逻辑能被测试验证,但边界情况多,而且业务上错不起。AI 会给一个看起来合理、但和你们行制度不一致的答案。

08复式记账的借贷平衡校验黄灯

为什么是这个结论
逻辑本身能测,但「什么情况下允许不平」这种例外情况只在老员工脑子里。
那该怎么办
AI 出代码 + 用例,你补例外场景。

相关叫法:借贷平衡、复式记账、平衡校验、试算平衡、轧账

09按日计息、分段计息的边界处理黄灯

为什么是这个结论
起息日算不算、月末怎么处理、闰年怎么办——AI 会给一个看起来合理但和你行制度不一致的答案。
那该怎么办
边界规则由人给定,AI 实现并生成边界用例矩阵。

相关叫法:按日计息、分段计息、跨月、跨年、闰年、计息天数、起息日、到期日

10账户状态机黄灯

为什么是这个结论
状态和操作的组合有几十种,AI 容易漏掉「冻结账户能不能收款」这类真实存在的例外。
那该怎么办
让 AI 生成完整状态对照表,人逐格确认,再据此写代码。

相关叫法:账户状态、状态机、冻结、销户、只收不付、开户、状态流转、睡眠户

11交易幂等与重复交易识别黄灯

为什么是这个结论
AI 通常只考虑正常重试,不考虑跨日重发、渠道补发、对账文件重复导入。
那该怎么办
AI 写主体逻辑,人补全「重复」的定义边界。

相关叫法:幂等、重复交易、重复提交、去重、流水号、唯一键、防重

12冲正与撤销的逻辑差异黄灯

为什么是这个结论
冲正和撤销在账务上完全不同,AI 经常混用。混用的后果是账面对但明细错。
那该怎么办
先由人写清两者定义,再让 AI 实现。

相关叫法:冲正、撤销、反交易、红冲、退款、撤单

13信贷审批规则引擎(开发期)黄灯

为什么是这个结论
规则的实现能测,但规则本身的合规性和商业合理性不能靠 AI 判断。
那该怎么办
规则清单人定,AI 负责实现和生成回归测试。注意:运行期自动决策见红线第 4 条。

相关叫法:审批规则、规则引擎、信贷审批、准入规则、评分卡、风控规则

14授信额度模型与回归测试黄灯

为什么是这个结论
额度占用和释放的时序问题极易出并发漏洞,AI 给的方案通常不考虑并发。
那该怎么办
AI 出实现和用例,人重点审并发与时序。

相关叫法:授信、额度、额度模型、敞口、额度占用、额度释放

15监管新规的影响面分析黄灯

为什么是这个结论
AI 能列出可能受影响的模块,但一定会漏掉你们行特有的历史包袱。
那该怎么办
把 AI 的清单当起点而不是结论,人补机构特有部分。

相关叫法:新规、影响面、监管要求、合规改造、政策解读、制度变更

绿灯 · 12 项 · 可以放心用

这 12 件事,我天天让 AI 干

共同点:错误当场可见、验证不花钱、不接触生产环境。这类活不用 AI 才是浪费时间。

16生产数据脱敏工具绿灯

为什么是这个结论
工具错了当场看得出来,而且它本身就是为了让你不用碰生产数据。

相关叫法:脱敏、数据脱敏、造数、测试数据、假数据、mock数据、数据生成

17读懂并重写老代码绿灯

为什么是这个结论
AI 读几千行存储过程比人快得多,而且它读错了,你跑一遍新旧比对就知道。

相关叫法:cobol、存储过程、老系统、遗留系统、重构、老代码、祖传代码、pl/sql、改造、迁移

18改造项目的回归测试用例生成绿灯

为什么是这个结论
这是 AI 在金融系统里投入产出比最高的一件事。用例写错了,跑一遍就暴露。

相关叫法:回归测试、测试用例、单元测试、测试覆盖、用例生成、自动化测试

19新旧系统并行期数据比对绿灯

为什么是这个结论
比对逻辑的对错由数据说话,不需要靠人判断。

相关叫法:并行、新旧比对、数据比对、一致性校验、双轨、灰度比对

20多格式对账文件解析绿灯

为什么是这个结论
每家渠道格式都不一样,AI 写解析器极快,而且解析错了第一条记录就报错。

相关叫法:对账、对账文件、文件解析、定长、报文解析、清算文件、渠道对账

21支付报文解析器绿灯

为什么是这个结论
格式有明确规范,属于翻译工作,AI 做得又快又准。

相关叫法:报文、iso8583、8583、swift、cips、网联、银联报文、报文组装

22需求文档转接口定义与 mock绿灯

为什么是这个结论
纯结构转换,错了对方联调第一天就发现。

相关叫法:接口文档、api文档、swagger、openapi、mock、接口定义、需求转代码、联调

23金融业务逻辑的评审辅助绿灯

为什么是这个结论
让 AI 找「这段代码在跨月场景下会怎样」,它经常能提出人漏掉的问题。它提的问题由人来判断。

相关叫法:代码评审、code review、评审、逻辑漏洞、review、审代码

24财报与公告 PDF 结构化绿灯

为什么是这个结论
抽错了对着原文一眼能看出来,验证成本几乎为零。

相关叫法:财报、pdf、年报、公告、结构化、提取表格、数据提取、爬取

25客户分层标签 SQL 生成绿灯

为什么是这个结论
跑一遍看结果分布就知道对不对。注意:在脱敏库或数仓上做。

相关叫法:客户分层、标签、画像、分群、sql生成、取数、客群

26存贷款结构分析看板绿灯

为什么是这个结论
展示层出错立刻可见,且不进核心账务链路。

相关叫法:看板、报表开发、可视化、bi、dashboard、存贷款、经营分析

27监管报表取数逻辑初稿绿灯

为什么是这个结论
初稿能省大量时间。但请注意:最终报送口径见红线第 5 条,必须人核。

相关叫法:取数逻辑、取数sql、报表取数、指标口径、数据血缘

不在这 27 条里的活,怎么自己判

回到那一条标准,问自己三个问题:

  1. 它写错了,会不会报错?不报错的——往红灯靠。记账错了不报错,只是账平不了。
  2. 验证它要花多少钱?跑一遍测试就能确认的,往绿灯靠。要拉三个部门开两周会才能确认口径的,往红灯靠。
  3. 错了以后能不能重来?重写一遍就行的,大胆用。资金差错、监管罚单、客户信任——这些赔不回来,别赌。

三个问题里有一个答不上来,就当红灯处理。 在金融系统里,“不确定”就是“不行”

用自测工具试一下你手上的活 →

为什么你可以不信我,但可以自己查

上面每一条的“为什么”,都能回到公开可查的制度和标准里核。常用的几个一手源:

注:本站所有代码示例用虚构银行、虚构数据从零重写, 不含任何机构的真实实现。这是职业底线,也是我敢公开讲这些的前提。