最近圈子里讨论度最高的一件事就是Barclays公开宣布扩大Claude部署把Claude Enterprise和Claude Code推进到数千名员工的日常开发流程里。单看数量并不算夸张真正让我在意的是“受监管软件工程”里那条原本稳定多年的责任链因为大规模AI入场而被重新分配了。我在金融行业的软件项目里泡了不少年深知银行写代码这件事和互联网开发完全是两套逻辑普通公司追求迭代速度银行追求每一步都有人签字、有记录、可追溯。当Claude这样的AI编程助手开始批量生成代码原本清晰的“谁写的、谁审的、谁批的”链条会变成什么样子责任到底落到谁头上这篇内容我想好好展开聊。1. Barclays放开手脚用Claude为什么先发生在银行1.1 一次公开部署背后的示范效应巴克莱把Claude放进数千名员工的开发环境这个动作放在普通科技公司可能只是“又一家企业采购了AI工具”但放在大型金融机构身上意义完全不同。公开报道里提到的是数千人规模覆盖软件工程、数据分析这类日常场景。也就是说这家银行不是让一两个小组偷偷试水而是把AI编程助手正式纳入了受监管的软件交付体系。这件事对金融圈的示范效应非常大。过去两年我接触到的银行技术团队对AI编程工具的态度普遍是“再看看”看这个模型是不是够稳看厂商有没有企业级承诺看监管会不会突然开口子。Barclays这次扩大部署等于给整个行业递了一个信号——可以用而且可以成规模地用关键看你怎么治理。我自己判断接下来一两年会有更多大型金融机构跟进。原因很简单大行的存量系统太庞大了技术债沉重得靠人力根本还不完而Claude Code这类工具在理解存量代码、补测试、做重构方面的能力恰好打在最痛的点上。所以Barclays的行动不是孤例而是整个受监管行业从“观望期”进入“落地期”的标志。1.2 银行软件工程和互联网开发的底层差异要读懂这次部署得先理解“受监管软件工程”和普通软件开发到底差在哪里。互联网公司开发一个功能最常见的节奏是今天提需求明天写代码后天灰度发现问题再修。代码上线是起点后续靠监控和快速迭代来兜底。银行完全反过来代码上线是一个漫长流程的终点。在变更到达生产环境之前通常已经过了需求评审、设计评审、代码评审、测试验证、变更窗口审批好几道关卡每一关都要有明确的责任人。金融行业里有个词叫“职责分离”Segregation of Duties意思是提需求的人、写代码的人、做测试的人、批准上线的人不能是同一个人。这不仅是管理习惯更是监管审计的基本预期。就算你业务能力再强也不能自己提需求、自己改代码、自己批准发布那在审计眼里就是灾难。另一个关键差异是“每一次变更都必须能回答五个问题”谁提的为什么提改了什么谁评审的谁批准上线的不只是大概知道而是能在事后几周甚至几个月把完整的证据链翻出来。我在银行项目里见过审计调阅变更记录精确到某个配置文件是哪天、由哪个工单号触发的、哪个账号执行的、审批人是谁。这套严谨度决定了银行不可能像创业公司那样让工程师自己装个Claude就随便生成代码。1.3 为什么“治理先行”是金融机构唯一的入场姿势普通公司用AI编程工具典型的路径是先让工程师自己装、自己试跑通了再逐渐规范。银行不可能这么干因为一旦某段AI生成的代码出了问题审计问的不是“这个工具好不好用”而是“你们为什么在没有任何治理措施的情况下让一个外部模型直接接触了代码资产”。所以我在金融机构看到的正确姿势永远是“治理先行”先定义清楚哪些环境允许使用、哪些代码类型允许让AI生成、提示词里能不能出现客户数据、模型产出要不要全量留痕然后再开通账号。Barclays这次能直接铺到数千人说明它的前置治理框架已经搭完了剩下的就是规模化复制。这里顺便提一嘴“供应商评估”。金融客户选AI工具的时候考量的维度和普通公司完全不一样。不仅看生成代码的质量还要看厂商能不能承诺不把客户代码用于模型训练、日志能不能导出给审计、模型版本能不能锁定、部署形态能不能满足数据驻留要求。Barclays选择Anthropic的Claude Enterprise说明这些企业级特性已经通过了银行的评估体系。这也给国内做企业大模型私有化部署的团队提了个醒To B尤其是金融To B拼的不只是模型跑分而是谁能把“可审计”这件事做进产品基因里。2. 责任重分配的三个层次从作者责任制到验证责任制2.1 旧模型代码上的每个签名都有名字传统金融环境里的责任模型可以概括成一句话每个动作都有署名每个署名都对应责任。开发人员写完代码提交提交记录关联到工单号工单上写着提出人和审批人代码评审人留下review记录表示“我看过并且认可”发布经理在变更窗口点击批准之后才允许合入生产。这套机制下一旦上线出了问题追溯路径是清晰的这段逻辑是哪个开发写的哪个评审人放行的哪个变更审批人签的字每个环节的人都要能站出来解释当时的判断依据。这种“作者责任制”的设计初衷不是为了甩锅而是为了让每个参与者真正尽到审慎义务。审计里有个说法叫“四眼原则”意思是任何关键操作至少要经过两个人确认一个人做一个人看。在代码场景里开发者是第一双眼评审者是第二双眼他们共同对最终交付负责。那时候责任边界很清楚你写出来的代码你负责。2.2 新模型意图、生成、审查、验收的四段链条AI进入之后传统链条里最核心的“写代码”动作被拆成了两段工程师用自然语言描述意图Claude负责把意图变成代码。原来的“写-审-批”三段变成了“意图-生成-审查-验收”四段。拆开之后责任的颗粒度反而变细了也变得更难追。我见过一些团队连“提示词”本身都没有存档问起来就是“当时随便聊着让它改的”。在普通公司这最多算流程不规范在受监管环境里这已经构成审计缺陷。因为“意图”这个环节出了问题——比如需求没讲清楚导致Claude按错误的理解写了代码——这个责任到底是算在写提示词的工程师头上还是算在评审没看出来的人头上还是算在提出模糊需求的业务方头上每个环节都能说出自己的理由但出了问题总得有归因。更要命的是AI会“自作主张”。Claude在实现需求的时候经常会在你没要求的地方顺手做一些事情比如额外引入一个依赖、改掉一个配置项、给函数换个名字。在普通项目里这是小问题在银行系统里这是“未授权的变更”轻则引发告警重则让审计直接判定变更流程失效。2.3 责任不会消失只会转移有人期待“AI能担责”这在可预见的将来都不现实。AI不会被吊销执照不会被罚款不会因为生产事故被约谈。监管要找人谈话的时候找的永远是银行的管理层和具体签字人。所以责任重分配的本质是把原来集中在“代码作者”身上的责任拆散并转移到整个交付链条上工程师的责任从“把代码写对”变成了“把意图描述对、把AI产出审清楚”评审人的责任从“检查代码风格和逻辑”变成了“在AI生成的代码里挑出隐性变更和幻觉”管理者的责任从“管好人”变成了“定义AI使用边界、组织培训、建立追责机制”。说白了AI没有消解责任只是把责任从“写”这个动作转移到了“验证”和“治理”这两个动作上。这个转变不是物理意义上的消失而是整个软件工程团队能力结构的重排。2.4 三个容易被忽略的责任盲区分享三个我在实际项目里踩过或者见过别人踩的盲区。第一个是提示词不归档。代码进了版本库评审记录进了审计系统但提示词还散落在聊天记录和个人笔记里。一旦需要解释“当时为什么会让AI这么改”根本拿不出证据。我们后来强制要求凡是与业务系统相关的AI交互提示词必须粘贴到关联工单的备注里这是最低成本的审计留痕。第二个是自动化偏误。人天然会信任机器的输出尤其是Claude答得特别自信、代码格式特别工整的时候评审者很容易放松警惕。我见过一次事故AI生成的单元测试看起来覆盖得很全面实际上关键断言写错了方向导致一个有问题的函数反而被“验证”成通过。后来这个模块上线第二天就在对账环节暴露了错误返工花了两周。第三个是模型漂移。Claude升级之后同一个提示词产出的代码风格和行为可能会有变化。银行要求的是可复现如果审计时说不清当时用的是哪个模型版本同样会被记为流程缺陷。正确做法是固定模型版本并在工具配置里记录每一次升级时间和影响范围。3. 五道工程护栏我梳理出的受监管场景落地清单3.1 环境隔离与数据边界第一道护栏是环境隔离。Claude Code应该运行在隔离的开发容器或沙箱环境里不能让它直接摸到生产库。生产数据如果要进入AI上下文必须经过脱敏而更稳妥的做法是尽可能用合成数据或者脱敏副本。原则就一条AI能看到的必须是无论怎么泄露都不会造成客户损失的。我在实际项目中见过一个反例有人为了方便让Claude分析线上慢查询直接把生产库的查询日志导出后塞进上下文。这在一个月后的合规检查里差点变成严重问题。金融机构里数据边界这件事没有“侥幸”两个字。提示词层也要贯彻“最小必要”原则。能不提账号、姓名、卡号的绝不多写一个字。很多工程师习惯把所有相关背景资料一股脑贴给AI图省事但在受监管环境里这恰恰是最危险的习惯。3.2 变更审批AI生成的PR同样要走生死关第二道护栏是变更流程一视同仁。不管代码是人写的、AI写的还是人和AI一起写的合入主干之前必须走完和过去一模一样的审批流关联工单、过静态检查、过CI构建、人工评审、变更窗口批准。每一个环节都不能因为“这个看得差不多了”就跳过。我建议团队在流程上做一个小改动给AI参与的PR打上一个标签。这样审计的时候可以一键筛选出所有含AI生成代码的变更单独做抽检。我们当时的做法是AI生成的PR强制要求评审人额外回答三个问题是否发现了超出需求范围的变更是否对AI生成的核心逻辑做了逐行检查测试用例是否由人工补充了关键断言这三个问题会沉淀到评审记录里后头审计直接调。3.3 审计留痕模型版本、提示词与补全日志第三道护栏是完整留痕。受监管环境里“发生过什么”永远比“现在是什么”更重要。每个AI交互的提示词、每次补全的产物、工程师最终采纳或修改的版本、模型当时的版本号都应该能被追溯。这里给个可落地的清单工具侧开启企业版的全量会话日志导出到内部审计系统不能只存在厂商的云上流程侧业务相关的提示词进入工单系统作为需求变更的附件存档版本侧记录Claude Code和底层模型的版本号升级前后要做回归验证事故侧任何由AI产出引发的线上问题单独建立复盘记录写明根因和后续控制措施。这套东西看着繁琐但真到审计调材料那天你就会感谢当初多存了这些日志。3.4 测试冗余用验证密度对冲生成风险第四道护栏是测试前置和冗余。AI生成代码的速度越快错误的“绝对数量”就越多哪怕错误率不变。所以CI里的测试覆盖门槛不能降反而要升关键路径的测试用例必须由人来设计意图AI负责补边界和异常分支。我见过一个很有效的做法核心模块的单元测试人工先写三个“意图测试”。什么叫意图测试就是不关心实现细节只验证业务规则是否正确比如“利率超过阈值时必须拒绝交易”“金额字段不允许出现负数”。这三个测试用例先定住基调AI生成的测试只能围绕它们做增量不能替代它们。这样一来即使AI在某些断言上写错了方向核心意图测试也会兜住。3.5 角色分工与能力培训第五道护栏也是最容易被忽略的是人。银行不能只给工程师开个账号就完事得先培训。培训内容不是“怎么用Claude”而是“在受监管场景里怎么安全地用Claude”。包括但不限于什么代码能交给AI、什么代码绝对不能交、怎么识别AI幻觉、提示词里哪些信息属于敏感数据、出了问题找谁、留痕从哪个系统调。我们内部还做过一个模拟演练故意让Claude生成一段包含利率计算错误的代码然后让几位工程师去评审看多少人能在五分钟内盯出错误。结果并不理想将近一半的评审者因为代码风格太好而没有产生怀疑。从那之后我们就把“带着怀疑看AI产出”写进了培训手册首页。下面这张表是我后来整理给团队的护栏检查清单简版护栏核心问题落地动作环境隔离AI能否接触生产数据专用沙箱数据脱敏变更审批AI变更是否被特殊对待标签标识强制评审问题审计留痕事后能否还原AI交互会话日志入内部审计系统测试冗余AI错误能否被兜住人工意图测试覆盖率门槛角色能力人有没有能力审AI产出培训、演练、考核4. Claude Code在银行代码库里的实测强项与暗坑4.1 惊喜区存量代码解读、测试补齐和重构辅助我在若干个金融服务项目里实测过Claude Code先说让人惊喜的部分。第一个惊喜是“读存量代码”。银行系统里有大量写了十年以上的老模块注释稀少、命名混乱、逻辑绕来绕去。我以前接手这种代码光是要搞清楚一个模块的调用链就得花上大半天。现在把代码包丢给Claude让它梳理模块结构、标注核心入口、列出可能的风险点通常几分钟就能产出一份相当靠谱的说明。虽然不能完全替代人工理解但至少能把“从零开始”变成“带着地图review”。第二个惊喜是“补测试”。存量项目最缺的就是测试资产。Claude Code可以按项目的既有测试风格批量生成单元测试框架能覆盖正常路径、边界值、异常输入这些常规场景。工程师只需要抽查和补充关键断言效率提升非常明显。第三个惊喜是“受控重构”。比如一个类里重复代码很多你明确告诉Claude“在不改变外部行为的前提下把这三段重复的校验逻辑抽取为公共方法”它给出的改动和影响面分析都挺靠谱。这种“行为保持型”的重构恰恰是AI最擅长的因为它不需要复杂的业务判断。4.2 危险区业务规则推理、分布式事务与隐式变更再说不那么让人放心的地方。第一类是业务规则推理。涉及金额计算、利息规则、监管报表口径这些高语义密度的逻辑Claude经常“自信地犯错”。它生成的代码从结构上看毫无问题——类型对、命名好、注释全——但业务规则可能在细节上差之毫厘谬以千里。比如某类贷款的计息天数是“算头不算尾”还是“算尾不算头”这个规则只要搞反生产环境就是一笔笔真金白银的错账。第二类是分布式事务和最终一致性。Claude不是好的架构师它擅长局部实现不擅长全局视角。你可以让它实现某个补偿事务的代码片段但不能指望它设计整个分布式事务方案。它会把问题简化成“同步调用返回错误”而忽略超时、重试、幂等、消息乱序这些真实世界的复杂性。第三类是隐式变更。我在4.2里提到的“自作主张”在实测中经常出现你让它重构一个函数它顺手把日志格式改了你让它修复一个bug它把相邻的无关逻辑也“优化”了。在受监管的代码库里任何未经工单批准的变更都可能导致变更管理流程失效所以每次评审都要重点盯diff里的“计划外改动”。4.3 一个真实小组的效率数字与我的观察我接触过一个金融服务项目组他们是典型的存量系统维护团队。连续六周用Claude Code辅助开发我拿了他们的数据做对比印象很深常规CRUD接口和配套测试代码的开发效率提升了大约四成到五成这符合预期但核心业务逻辑的开发速度没有明显提升因为大部分时间花在了提示词打磨和AI产出审查上。整个项目最明显的净收益是工程师从“打字员”的角色里解放出来把精力集中在业务规则验证等高风险工作上。团队负责人跟我说过一句让我印象特别深的话“以前我们缺的是手现在缺的是审核的大脑。”这句话基本概括了AI进入受监管软件工程之后的工作重心的迁移方向。5. 给一线工程师的转型建议从写代码的人变成对代码负责的人5.1 先写一份“AI使用边界清单”如果你也在一家受监管的机构里做开发我给你的第一个建议是不要等组织统一规范先给自己写一份“AI使用边界清单”。这份清单只需要回答三个问题什么东西我可以放心让AI碰工具类代码、测试代码、注释文档、日志分析、存量代码解读。什么东西我绝对不让AI碰生产配置、密钥证书、监管口径计算、核心业务规则、外部接口契约。什么情况下AI的产出必须人工重写分布式事务、资金安全边界、任何需要和业务部门逐字确认语义的地方。这份清单不需要很长但它会在无数个“顺手让AI改一下”的瞬间帮你踩下刹车。5.2 把提示词当成正式工程资产第二个建议让你的提示词像代码一样被管理。因为提示词在受监管场景里就是“交付物”它记录了需求如何被理解并转化为实现。我在实际项目里养成的习惯是每个面向业务系统的提示词先写“任务目标”再写“边界约束”最后写“具体动作”高频场景沉淀成提示词模板模板经过评审后放进团队知识库模板库有版本号改动要走变更记录防止同一个任务今天这样写、明天那样写产出完全不可预期。举个例子。我让Claude补测试的时候从来不写“帮我写点测试”而是写“给这个类补单元测试覆盖正常路径、空值、并发、异常回滚测试风格对齐项目现有JUnit写法不要修改被测代码的结构”。这一句话就包含了意图、约束和验收标准产出的稳定性和可审计性都会高一个量级。5.3 从低风险场景入场逐步建立信任数据第三个建议也是我给团队定的发展路径别一上来就让AI写核心业务逻辑。先在低风险场景里建立信任数据用事实而非感觉来判断“AI产出到底可不可靠”。推荐的路径是文档和注释 → 单测生成 → 非核心模块辅助开发 → 核心模块的辅助重构 → 全流程人机协作。每扩展一步记录两个数字AI产出的缺陷率和人工返工成本。当这两个数字都进入可接受范围之后再向监管和风险管理方展示这套依据说服力会强得多。Barclays能从试点走到扩大部署背后一定也有一份类似的信任数据作为支撑。5.4 练就“向审计解释AI产出”的能力最后一个建议关于个人能力。受监管软件工程里工程师的核心竞争力正在从“写代码的速度”变成“为代码负责的深度”。这意味着你需要能做三件事解释意图你为什么把这个任务交给AI你想让它做什么你预期它不做什么解释审查你检查了哪些部分发现了哪些问题为什么你认为剩余风险可接受解释残留如果这段代码出问题最大的风险点是什么一旦出问题你怎么快速定位这三件事其实就是自动驾驶语境里的“接管能力”。平时AI能帮你开大部分路程但你随时要能握回方向盘并且能向坐在副驾上的审计员讲清楚在哪些路段你选择了自动驾驶、在哪些路段你决定了自己开、为什么。我在实际运作中的体会是这套表达能力不是天生的是靠一次次被审计挑战、被复盘追问练出来的。但一旦练出来你在这个行业里的不可替代性反而更强了。最后再分享一个我自己的心态变化。一开始我也担心过AI会不会让工程师贬值后来在一个项目里被Claude生成的错误测试用例坑过一次、又被它补的边界测试救过一次之后我彻底想明白了一件事受监管软件工程的重心从来都不在“写”而在“证”。AI把“写”的成本几乎抹平了整个行业等于被强行推向了“验证、审计、治理”这条更难的赛道。Barclays这次扩大部署只是一个节点后面一定会有更多机构跟上。作为一线工程师与其纠结AI会不会抢饭碗不如先把自己变成那个“能对AI产出负责的人”。能负责的人永远不会被工具取代。