Barclays今年在AI这件事上干了一票大的与Anthropic签下多年协议把Claude全面部署到行内数万名员工的日常工作中软件研发是其中投入最重、也最值得琢磨的一块。作为在金融科技和软件工程交叉地带泡了十几年的老工程师我看到这条消息的第一反应不是“银行也开始用AI了”这种泛泛之论而是注意到一个更本质的变化——当Claude这类能独立写代码、跑测试、修bug的AI编码助手进入受监管行业整个软件工程体系里“谁对什么负责”的边界正在被重新划分。这篇文章想聊的就是这件事Barclays到底部署了什么受监管软件工程和普通研发有什么区别以及AI进场之后责任重分配到底怎么落。先说清楚这文章适合谁看。如果你在银行、保险、证券、医疗或任何有强合规要求的行业做软件研发或工程管理这文章对你直接有用如果你只是在个人项目中玩Claude Code也可以从中理解为什么企业级部署和自己装个环境完全是两码事。全文不涉及任何内部消息所有结论都来自公开信息加上一线工程实践的推演。1. 事件拆解Barclays这笔Deal到底做了什么Barclays和Anthropic的合作是分步走的。最初是试点性质的PoC验证Claude在银行内部场景的可用性后来的扩约把覆盖范围拉到了数万名员工涉及内部运营、客户服务、风险合规文本处理以及软件工程。在研发侧核心载体是Claude Code——一个能直接跑在终端和IDE里的AI编码Agent能读代码库、改代码、跑测试、修bug甚至可以执行多步开发任务。和普通聊天式AI不同Claude Code被定位成一个“能动手的工程师助手”这也是它进入受监管环境后引发责任问题的主要原因。这件事值得关注的原因不只是“规模大”。第一Barclays不是第一家试用AI编码助手的银行但它是第一批把数万人规模使用作为正式战略目标的大型系统性银行。这意味着它们已经不再把AI当“工具”看待而是把AI提升到了“基础设施”的层面。基础设施出了问题影响的是全局所以配套的治理体系必须跟上。第二研发侧的部署并不是让大家在网页上问问题而是把Claude Code对接进了内部的代码仓库、CI流水线和工单系统。换句话说AI开始触碰生产代码了。在一个连普通代码变更都要走审批流、投产窗口都要排期的行业里这一步跨得比外界想象的大。它意味着AI生成的内容已经进入正式工程流程和人类工程师的代码享受同等待遇——包括同等的评审义务和同等的审计责任。第三也是最重要的Barclays的处理方式会成为整个行业的参照系。受监管机构通常不会争当第一个吃螃蟹的人但一旦头部机构走通了后面的银行、保险公司会把这套经验当作“合规路径”来参考。我们现在看到的不是一家公司的新奇尝试而是一次典型的技术扩散开端从实验室到核心系统的路径被一家机构用真金白银试出来了。我自己的习惯是看这类新闻时不盯官方公告里那些“提升效率”“赋能业务”的词而是看实际的调用场景和配套治理措施。这次公开信息里能看到的关键词包括内部部署、数据隔离、人员培训、治理框架。这些全部指向同一个结论——Barclays不是在“试用AI”而是在“为AI建立新的工程责任体系”。搞清楚这一点后面的责任重分配讨论才有立足点。2. 受监管软件工程和普通研发到底差在哪要理解责任重分配得先理解受监管软件工程的底子。普通互联网公司写代码追求的是迭代速度、用户体验、业务增长受监管行业的软件工程师写代码头顶永远悬着三把剑记录、追溯、证明。这三件事贯穿软件生命周期始终决定了日常工作的节奏和方式。先说记录。监管语境下的需求不是一句“做个转账功能”就完了而是要从业务规则追溯到合规义务这条规则对应哪项内部风控要求为什么有这个字段为什么这个金额上限是这个数。每一行生产代码最终都要能映射到一个经过审批的需求条目上。这是个巨大的文档负担但恰恰是它保证了系统的可解释性——任何一环说不清楚审计和检查就可能卡住。再说追溯。普通研发出问题拉个会、查个日志、改一行代码就完事受监管行业出问题第一反应是“谁改的、什么时候改的、为什么改、有没有评审记录、有没有测试证据”。代码变更的可追溯性不是管理喜好而是监管检查时的硬通货。所以受监管行业普遍有环境隔离开发环境、测试环境、生产环境严格分开生产变更要有变更单、有审批人、有回滚方案。最后说证明。你的系统不能说“我觉得没问题”你得拿出测试覆盖报告、安全扫描结果、投产审批单、运行监控数据来证明系统确实符合要求。这种“证明文化”决定了工程流程的每一步都要留痕。你做得合规不重要重要的是你能证明你做得合规。这三个底色叠加起来受监管软件工程的日常工作就是一套严密的防错体系代码评审是双人甚至多人制的生产变更要过变更委员会测试要分级分层投产窗口是固定的回滚方案是强制预留的。在这种体系下工程师的“责任”边界是清晰的开发者为代码质量负责评审者为变更正确性负责发布者为投产安全负责合规为整体风险兜底。责任链条是线性、可追踪的——每一行代码都能找到具体的人来背书。问题来了AI编码助手进入这个体系之后这条责任链还成立吗答案是成立但链上的节点变了。AI不是责任链上的一环因为AI没有“负责”的能力。它更像一个突然出现的、效率极高的“外部供应商”而供应商出了质量问题买方要负责验收。这就是下一节要展开的核心。3. 责任重分配AI写码谁背锅这是整篇文章的核心。AI编码助手最大的特点不是“写得快”而是“它没有责任能力”。法律上、制度上、道德上AI都不承担任何后果。这意味着AI每输出一段代码这段代码背后的责任并不会消失而是会即刻转移到人身上——具体转移到谁身上取决于你的工程体系怎么设计。我把它总结成一句话AI不会承担责任但AI会让责任的边界移动。具体来说责任向三个方向移动。第一个方向是“向上移”。以前一线开发写出有问题的代码责任在写代码的人。现在代码可能是AI生成的一线开发变成“AI输出的验收者”。但你不可能甩锅给AI——当你点击“接受这段代码”或者“提交这个PR”的那一刻你就完成了责任的转移AI的责任能力为零所以全部风险落到你头上。你可能没写这行代码但你认可了它。在责任链条上你比从前更重而不是更轻。这一点很多团队在引入AI后没过问直到线上出事故、复盘要定责时才发现AI帮不了任何人背锅。第二个方向是“向需求侧移动”。以前大部分责任在“怎么实现”现在越来越多责任在“怎么说清楚”。AI是按你给的上下文和指令生成代码的指令含糊代码就含糊指令遗漏代码就遗漏。于是产品需求文档、验收标准、用例描述这些“软件工程前端”的东西从辅助性文档变成了责任锚点。你定义不清楚AI输出自然出问题而这个“不清楚”的责任在定义需求的人。我见过太多案例需求文档写“支持多币种转账”AI生成的代码确实支持了但没支持节假日汇率失效的场景——因为需求和用例里根本没提这个约束。第三个方向是“向评审侧移动”。为避免AI那种“自信幻觉”——它生成的代码看起来结构完整、注释齐全、风格统一但可能含边界处理漏洞——评审者需要比从前更仔细地核对逻辑而不是像以前那样扫一眼格式和风格。资深工程师的评审负担显著增加。这是许多团队在部署AI编码助手后没有预见到的结果AI没有让评审变少只是把评审的焦点从“风格行不行”变成了“逻辑到底对不对”。难点在于AI生成代码的结构化程度太高容易让评审者产生“这代码质量真好”的错觉注意力自然松懈。结果评审反而更容易漏掉关键缺陷。一个具体的例子在银行转账系统里涉及利息计算、截止时间、汇率折算这类规则密集的业务AI代码可能在常规路径下全对但碰到闰年、节假日、多币种叠加时就漏了分支。功能测试查不出来只有规则级测试和评审者的人工推演能发现。这正是受监管软件工程新旧责任体系最容易踩坑的地方。那么新的责任分配结构应该长什么样我的建议是四层模型。第一层代码所有权仍在工程师。无论代码是不是AI写的签字的只能是人类工程师这一点没有商量余地。第二层提示词进入审计范围。你给AI的指令属于工程产物应该和代码一样受版本管理、评审和审计。谁写了这段提示词谁就要对提示词的质量负责。第三层验收动作就是责任动作。每一次“接受AI输出”都应该被记录和追踪验收者要意识到这是整个责任链条里最关键的一环。第四层治理框架先行。在放开AI能力之前先定义清楚AI能做什么、不能做什么、谁有权验收。这不是流程负担而是让AI进入受监管体系的前提条件。4. 部署形态与工具链Claude Code怎么装、怎么连、怎么控聊完责任分配的理念回到操作层面。企业要部署Claude这类AI编码助手首先面对的问题就是形态选择。目前主流的部署形态有三种厂商SaaS服务、企业私有化API通道、本地模型。三者的合规风险和工程改造量差别很大。厂商SaaS服务就是直接用Anthropic官方提供的Claude服务包括Claude Desktop、网页版以及Claude Code直连云端。这种方式体验最好、模型能力最新但对受监管行业来说有个绕不开的问题数据要离开企业环境。客户信息、内部交易数据、未公开的代码片段一旦进入外部公共AI服务合规上基本是踩红线的。所以受监管机构要么走企业私有的API网关把数据边界划在内部要么干脆本地部署开源或私有化大模型。很多银行实际采取的是“多云混合”策略非敏感场景走厂商服务敏感场景走私有化通道。第二种是企业私有化API通道。Claude Code本身支持通过环境变量和配置文件指定API端点也就是你能把它的推理请求指向企业自己部署的网关或中转服务。这样既保留Claude Code这个成熟工具链又把数据管控权拿回自己手里。实现上要注意几个细节网络出口控制要验证确保没有旁路流量API密钥管理要走企业的密钥系统不能硬编码在开发机里调用日志要进入统一的审计平台。据我了解Barclays这类机构的内部部署走的就是类似的路径。第三种是本地模型。因为“本地部署大语言模型”的热度不少企业会尝试用Ollama这类工具在内部服务器跑开源模型替代商业API。但作为一线实操者我得诚实说一句开源本地模型在代码生成质量和工具调用能力上和Claude这种前沿闭源模型差距仍然明显。本地模型更适合处理那些“能力要求不高但数据敏感”的辅助任务比如脱敏后的注释生成、测试数据构造、内部知识库问答。把本地模型当成生产代码的主力生成工具现阶段效果大概率会让你失望。受监管行业比较务实的做法是敏感数据场景用私有化部署的模型核心生产代码用Claude Code但走企业内部API通道两边按数据等级分流。工具链环节Claude Code本身的安装和使用有几个容易踩的坑。安装上用npm全局安装即可但国内网络环境下经常出现二进制下载失败的问题Windows环境还容易报“requires the virtual machine platform on Windows”这种虚拟机平台相关错误。这些都属于环境问题排查思路是先确认Node版本、再检查网络代理设置、最后看安装日志里具体卡在哪一步。配置层面VSCode下使用Claude Code需要安装官方扩展并做登录授权连接内部API时要在配置文件里指定端点。还有一个值得关注的是MCPModel Context Protocol服务配置。在企业场景里你会想让AI能读内部代码仓库、查工单系统、触发CI这些都是通过配置MCP servers实现的比如npx方式启动的MCP服务。但要注意每接一个MCP服务就多一个数据出口和权限面所以在受监管环境里MCP服务列表必须经过安全评审。最后是权限控制。受监管环境下AI工具的权限要遵循最小授权原则默认只读按角色逐步开放绝不能因为图省事把生产库写权限配给AI工具。我见过有团队为了方便让AI自动修数据给了DML权限结果AI在测试环境按错误逻辑批量更新了数据。这种事一旦发生在生产环境就不是“删库跑路”梗而是真正的责任事故。5. 落地实操在合规优先环境里部署AI编码助手的完整路径前面把形态和工具讲清楚了这一节给出一条完整的落地路径。整个过程分六个阶段每一阶段都有明确目标和检查项可以直接抄作业。第一阶段划定边界。先别急着让AI写生产代码。开通范围从“非生产环境的代码生成、文档撰写、测试用例编写”开始。边界要落到纸面上哪些代码库AI可以读哪些不可以哪些变更AI可以提交建议哪些必须由人类从头手写。我的经验是边界划定得越细后面的治理越轻松。模糊的边界会在运行一段时间后变成责任真空每个人都可以说“我以为AI可以做”。第二阶段数据隔离。企业大模型私有化部署或内部API通道在这里是硬要求。不能把客户信息、内部交易数据、未公开的代码片段发送到外部公共AI服务。这个环节要做的检查项包括网络出口控制、数据脱敏规则、日志不落外部存储的验证。说句实在话很多团队在这一步就劝退了但这恰恰是受监管行业的入场券。数据隔离做不好后面所有的效率收益都会被合规风险抵消掉。第三阶段工具链集成。在IDE和终端里配置Claude Code并把它接入公司内部的代码仓库、CI流水线。这里的关键配置有三个一是给AI只读权限时要做最小授权别顺手给了生产库的写权限二是把AI的调用记录接入统一的审计日志平台三是设置“禁止直接合入主分支”的硬性门槛AI生成的代码只能走PR流程。这三个配置缺一个后面的责任链条就会断。特别是第三个如果允许AI直接提交到主分支那责任体系就完全失控了——既没有评审节点也没有验收记录。第四阶段评审管线改造。这是最容易被忽视的环节。AI介入后代码评审的规则必须更新要求AI生成代码不得通过“批量确认”合入必须逐条人工评审评审清单里增加一类检查项叫“边界与异常路径核对”专门针对AI容易漏掉的场景。评审者要对AI代码承担和人类代码同等的确认责任——最好在评审工具里直接把“AI生成”标注出来让评审者意识到自己在审什么。这个标识不是形式它是在提醒每个评审者你正在承担一次关键的验收责任。提示评审AI代码时强制要求先看异常分支和边界条件再回看主流程。这和人类的阅读习惯相反但恰好能对抗AI代码“表面完美”带来的麻痹感。第五阶段效果度量。不要只看速度指标。我建议跟踪五类指标AI生成代码的缺陷密度、评审通过率、返工率、提示词版本的迭代次数以及“AI代码引发生产事故”的数量。特别是最后一项必须作为红线指标来监控。如果AI代码缺陷密度高于人工代码说明提示词或评审流程有问题要回到第三、四阶段调整。如果红线指标上升要果断降级AI的使用范围这不是能力问题是责任体系还没建好。第六阶段培训与权责下沉。所有使用AI编码助手的工程师必须接受专项培训内容不只是“怎么用”而是“责任的边界在哪”。培训考核通过后才发放AI工具权限。这听起来繁琐但对受监管行业来说这是把“AI责任重分配”落实到每个个体身上的关键动作。培训材料里应该包含典型事故案例哪些错误是AI代码引起的、哪些是提示词引起的、哪些是评审漏过的。让每个工程师直观理解责任最终落在谁身上。部署完成之后日常运营里还有几件事要持续做。一是建立“提示词资产库”。团队里沉淀下来的高质量提示词应该像代码一样被管理和复用而不是散落在各人的聊天记录里。二是定期做“AI代码专项评审”。每个迭代抽一批AI生成的代码由独立团队不参与该模块开发的人做一次深挖式审查专门查规则边界、数据合规、异常处理。三是事故复盘流程里增加“AIFactor”标签。每次生产事故都在根因分析里回答一个问题AI在本事故中扮演了什么角色是生成错误代码、是评审漏过了AI错误、还是提示词定义不当。这个标签会积累出宝贵的数据告诉你责任重分配的实施效果。6. 常见问题与排查技巧实录最后分享一些实际踩过的坑按问题频率排个序整理成一张速查表。高频问题根因分析解决思路AI代码看着都对评审也过了还是线上出事评审者用人工代码经验审AI代码被结构化假象麻痹强制“反着读代码”先推演异常分支和边界场景工程师过度信任AI直接合入生产责任意识没建立AI代码“看起来太专业”合入权限不放开评审工具中强制标注“AI生成”标识负责人抱怨AI降低了代码质量提示词写得含糊上下文给得不全用“需求背景实现目标约束条件验收标准”四段式重写提示词合规部门担心AI引入审计风险流程上没有把AI产物纳入既有审计体系提示词入库、输出留痕、验收记录归档形成完整证据链资深工程师抵制新人过度依赖AI能力没变成团队公共能力各干各的统一提示词模板、统一评审标准、统一合入门槛第一个问题最高频值得多说两句。AI生成的代码通常注释规范、命名整洁、结构层次分明这和“代码质量好”并不等价。真实缺陷藏在哪里藏在特殊日期处理、空值路径、并发冲突、权限校验这些容易被“通读逻辑”跳过去的地方。所以我们内部定了一条规矩评审AI代码时先打开测试用例文件对着用例逐条反推实现逻辑再回到异常分支上去看有没有遗漏。这条规矩救过我们不止一次。第二个问题的本质是权力和责任脱节。新人看到AI生成的PR自带详细说明和完整测试很容易判断“比我写得好肯定没问题”。但你仔细想代码“看起来好”和“在受监管环境里正确”是两码事——它符合业务规则吗符合合规约束吗异常路径有兜底吗这些都需要人来确认。所以合入门槛绝对不能因为AI的加入而降低反而应该更严。第三个问题排查下来十有八九是提示词的问题。AI编码助手不是搜索引擎你把一句“写个转账接口”丢给它它只能按通用理解去写注定满足不了银行的特殊规则。我建议的提示词结构是四段式先给需求背景这个接口服务于什么业务再给实现目标输出什么结果、调用什么上游然后给约束条件金额上限、截止时间、不允许的行为最后给验收标准自动化的测试命令或检查点。上下文给足之后AI代码的质量会明显上一个台阶缺陷密度能降一个量级。第四个问题其实是个流程认知问题。我在和合规团队协作时发现他们真正在意的不是“AI是否被用了”而是“AI用了之后还能不能说明白谁负责”。只要你把AI纳入既有审计体系——提示词版本化、输出留痕、验收记录归档——合规团队反而可能变成AI落地的支持方。因为AI实际上让留痕更完整了每次生成和验收都有日志比人工操作的可追溯性更强。还有一个经常被忽略的问题是老工程师的抵触。资深工程师觉得AI输出的代码“不够味道”拒绝使用与此同时新人快速依赖AI。结果就是两拨人各写各的代码风格分叉评审标准混乱。解决办法是把AI能力变成团队公共能力而不是个人选择统一提示词模板、统一评审标准、统一合入门槛。让AI成为团队的工具而不是某几个人的效率外挂。技术上强制推行远比说服每个人更有效。我个人在实际跟进这类项目的体会是受监管软件工程部署AI最难的从来不是技术而是让每个人接受“责任边界变了”这件事。工程师不再只是写代码的人更是AI产物的验收者需求方不再只是提需求的人更是定义上下文的责任人评审者不再只是看风格的人更是规则边界的第一道防线。Barclays把Claude推进到这个深度本质上是用一场大规模实践回答了行业中的一个核心疑问AI时代受监管软件工程的责任体系能不能既守住合规底线又拿到效率增益。目前实践给出的是肯定答案但前提是——每个人都清楚地知道自己肩膀上那部分责任到底变重在哪里。