# AI 编程红绿灯全表：银行核心系统 27 个场景逐条给结论 > 最后更新 2026-08-09 · 来源 https://shede.site/lights.html 本文回答一个问题：**银行核心系统里，哪些活能交给 AI 写，哪些不能？** 作者 2006 年入行金融，2009 年起专做银行核心系统，服务过多家城商行与全国性股份制银行。 ## 判断标准（只有一条） > **AI 输出的错误，能不能在上线前被查得出来出来？** > 查得出，就大胆用。查不出，就别让它碰。 说白了：**AI 用在写代码的时候，不用在跑生产的时候。** 下面 27 条全是这一句话推出来的。这条线按**后果**画，不按**模型能力**画——模型再强一个量级，记账口径错了照样不报错。 --- ## 绝不让 AI 碰（红灯，7 项） 共同点：**错误不会在上线前暴露，且错了赔不回来。**不是因为 AI 不够强，是因为错了以后你查不出来、也撤不回。 ### 1. 资金交易的最终记账逻辑 **结论：绝不让 AI 碰（红灯）** 为什么：记账错误不会报错，只会让账平不了。而账不平是往前追一整天的批量，不是改一行代码。 那该怎么办：让 AI 写这段逻辑的**测试用例**和**对账校验脚本**，用它来验证人写的记账代码。 相关叫法：记账、入账、分录、总账、科目、借贷、过账、账务处理、资金划转、转账逻辑 ### 2. 利息、费率的最终计算口径 **结论：绝不让 AI 碰（红灯）** 为什么：少算一分钱，乘以百万账户就是监管问题。而口径对不对，测试用例测不出来——它取决于合同和监管文件怎么写。 那该怎么办：口径由人从制度文件里定，AI 负责把定好的口径翻译成代码，再写边界测试。 相关叫法：计息、利息、利率、费率、手续费、罚息、复利、年化、计费、结息 ### 3. 生产数据的直接读取和处理 **结论：绝不让 AI 碰（红灯）** 为什么：把生产数据贴进对话框那一刻，它就离开了你的机构。这不是技术问题，是数据出境和信息安全事件。 那该怎么办：让 AI 写脱敏工具，用脱敏后的数据做开发。工具本身可以让 AI 写，数据不能给它看。 相关叫法：生产数据、生产库、真实数据、客户信息、身份证、客户号、生产环境、线上数据、客户敏感 ### 4. 运行期的自动决策 **结论：绝不让 AI 碰（红灯）** 为什么：写代码的时候出错有测试兜底，跑生产的时候出错直接是客户投诉、资金损失和监管问询。而且它错得不可复现，你连是哪儿错的都查不出来。 那该怎么办：AI 用在写代码的时候。真正跑生产用写死的规则引擎，规则本身可以让 AI 帮你整理。 相关叫法：自动审批、自动放款、自动决策、实时风控、自动拒绝、智能审批、自动授信、在线决策 ### 5. 监管报送的最终数据出口 **结论：绝不让 AI 碰（红灯）** 为什么：报送数字错了是要被通报和罚款的，而且报出去就撤不回。取数逻辑对不对，只有懂制度的人能判断。 那该怎么办：让 AI 生成取数 SQL 的初稿和跨表校验逻辑，最终口径必须人对着监管制度逐项核。 相关叫法：监管报送、1104、报送、监管报表、人民银行、监管数据、统计报表、报送口径、监管指标 ### 6. 加密、密钥和认证的实现 **结论：绝不让 AI 碰（红灯）** 为什么：这类代码「跑通了」和「安全」是两件完全不同的事。AI 写出来能跑，但它可能用了不该用的模式或写死了随机数种子，而这些漏洞测试全绿。 那该怎么办：用机构已有的、经过审计的安全组件。AI 只负责调用它，不负责实现它。 相关叫法：加密、密钥、加签、验签、证书、认证、口令、password、token、国密、报文加密 ### 7. 生产变更的直接执行 **结论：绝不让 AI 碰（红灯）** 为什么：AI 生成一条 update 少写一个 where，等着你的是恢复备份加一次生产事故报告。这类操作没有「撤销」。 那该怎么办：AI 可以帮你写脚本并解释它做了什么，但执行前必须人读一遍、先在影子库跑、且带回滚方案。 相关叫法：数据修复、改数据、订正、跑批调度、生产变更、补数据、刷数据、执行脚本、上线操作、紧急修复 --- ## AI 写初稿，人必须签字（黄灯，8 项） 共同点：**逻辑能被测试验证，但边界情况多，而且业务上错不起。**AI 会给一个看起来合理、但和你们行制度不一致的答案。 ### 8. 复式记账的借贷平衡校验 **结论：AI 写初稿，人必须签字（黄灯）** 为什么：逻辑本身能测，但「什么情况下允许不平」这种例外情况只在老员工脑子里。 那该怎么办：AI 出代码 + 用例，你补例外场景。 相关叫法：借贷平衡、复式记账、平衡校验、试算平衡、轧账 ### 9. 按日计息、分段计息的边界处理 **结论：AI 写初稿，人必须签字（黄灯）** 为什么：起息日算不算、月末怎么处理、闰年怎么办——AI 会给一个看起来合理但和你行制度不一致的答案。 那该怎么办：边界规则由人给定，AI 实现并生成边界用例矩阵。 相关叫法：按日计息、分段计息、跨月、跨年、闰年、计息天数、起息日、到期日 ### 10. 账户状态机 **结论：AI 写初稿，人必须签字（黄灯）** 为什么：状态和操作的组合有几十种，AI 容易漏掉「冻结账户能不能收款」这类真实存在的例外。 那该怎么办：让 AI 生成完整状态对照表，人逐格确认，再据此写代码。 相关叫法：账户状态、状态机、冻结、销户、只收不付、开户、状态流转、睡眠户 ### 11. 交易幂等与重复交易识别 **结论：AI 写初稿，人必须签字（黄灯）** 为什么：AI 通常只考虑正常重试，不考虑跨日重发、渠道补发、对账文件重复导入。 那该怎么办：AI 写主体逻辑，人补全「重复」的定义边界。 相关叫法：幂等、重复交易、重复提交、去重、流水号、唯一键、防重 ### 12. 冲正与撤销的逻辑差异 **结论：AI 写初稿，人必须签字（黄灯）** 为什么：冲正和撤销在账务上完全不同，AI 经常混用。混用的后果是账面对但明细错。 那该怎么办：先由人写清两者定义，再让 AI 实现。 相关叫法：冲正、撤销、反交易、红冲、退款、撤单 ### 13. 信贷审批规则引擎（开发期） **结论：AI 写初稿，人必须签字（黄灯）** 为什么：规则的实现能测，但规则本身的合规性和商业合理性不能靠 AI 判断。 那该怎么办：规则清单人定，AI 负责实现和生成回归测试。注意：运行期自动决策见红线第 4 条。 相关叫法：审批规则、规则引擎、信贷审批、准入规则、评分卡、风控规则 ### 14. 授信额度模型与回归测试 **结论：AI 写初稿，人必须签字（黄灯）** 为什么：额度占用和释放的时序问题极易出并发漏洞，AI 给的方案通常不考虑并发。 那该怎么办：AI 出实现和用例，人重点审并发与时序。 相关叫法：授信、额度、额度模型、敞口、额度占用、额度释放 ### 15. 监管新规的影响面分析 **结论：AI 写初稿，人必须签字（黄灯）** 为什么：AI 能列出可能受影响的模块，但一定会漏掉你们行特有的历史包袱。 那该怎么办：把 AI 的清单当起点而不是结论，人补机构特有部分。 相关叫法：新规、影响面、监管要求、合规改造、政策解读、制度变更 --- ## 可以放心用（绿灯，12 项） 共同点：**错误当场可见、验证不花钱、不接触生产环境。**这类活不用 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. **错了以后能不能重来？** 重写一遍就行的大胆用；资金差错、监管罚单、客户信任赔不回来，别赌。 三个问题有一个答不上来，就当红灯处理。在金融系统里，**“不确定”就是“不行”**。 ## 参考的一手源 - [人民银行金融标准全文公开系统](https://www.pbc.gov.cn/tiaofasi/144941/index.html) - [国家金融监督管理总局 · 法规制度](https://www.nfra.gov.cn/cn/view/pages/index/zhengcefagui.html) - [ISO 8583 金融交易报文标准](https://www.iso.org/standard/31628.html) - [ISO 20022 金融业通用报文方案](https://www.iso20022.org/) - [NIST 密码标准与指南](https://csrc.nist.gov/publications/sp) ## 声明 本站所有代码示例用**虚构银行、虚构数据**从零重写，不含任何机构的真实实现。