12000 名工程师的高盛，只用四个月就收回了交易员的 AI 编程权限

十月的一个交易日早上，高盛一名交易员像往常一样打开终端，准备让 Claude Code 帮他改一段盯盘用的小脚本。这一次，工具没有响应他的账号。没有全员邮件，没有培训通知，权限就是在某个晚上被悄悄关掉的。

四个月前，画风完全相反。七月，高盛 CIO Marco Argenti 还在公开表扬非工程师员工的 vibe coding，鼓励交易员和银行家用 AI 把想法直接做成工具，再交给工程师打磨，绕开排队等开发的老流程。从全行鼓励到收回权限，只用了一个夏天。

这不是一条产品新闻，而是一条工程新闻。被收回的不是某个软件的账号，是一整类从来没有被工程流程接住的代码。

出事的从来不是 AI，是没人 review 的代码

很多人看到这条新闻的第一反应是，AI 写的代码果然不靠谱。这个判断说对了一半。真正出问题的不是代码由谁写，而是这些代码绕开了所有本该接住它的流程。工程师写的代码也会出错，但工程师的错有层层网兜接着，交易员的脚本什么网都没有。

高盛内部担心的场景很具体。交易员写脚本不是为了好玩，是为了盯客户交易流、建模市场仓位、生成日报。这些脚本一旦写好，就会每天跑在处理客户信息的电脑上，成为业务流程的一部分。一个没有被任何人看过的程序，从此天天碰客户数据。

AI 让这件事的规模彻底变了。过去一个交易员想自动化点什么，得先会写代码，这道门槛天然限制了数量。现在门槛没了，几千名没有受过工程训练的员工都能让 AI 替自己写程序，而且写出来就能跑。能力下放的速度远远超过了管控下放的速度。

没有 review 意味着没有人知道脚本里写了什么。没有测试意味着改一行就可能算错仓位。没有审计意味着出了问题之后，连是谁的脚本、哪天改的、碰过什么数据都查不出来。没有回滚意味着出错只能人肉止损。这四个没有叠加在一起，才是高盛真正害怕的东西。

所以这件事的本质不是 AI 信任危机，而是工程管控缺位。同样的模型、同样的工具，装进有审查有测试的流水线里是生产力，装进没有护栏的员工电脑里就是风险源。高盛收回权限，收回的不是对 AI 的信任，是对失控状态的容忍。

看清楚这一层，后面的讨论才有意义。争论 AI 写的代码到底好不好，是在回答一个错误的问题。正确的问题是，你的流程有没有能力消化任何来源的代码，包括 AI 写的，包括实习生写的，包括外包写的。流程对了，来源是中性的。流程缺位，来源再可靠也接不住。

工程师的代码为什么敢上生产

同样是人写的代码，为什么工程师的版本敢部署到生产环境？不是因为工程师不出错，而是因为工程师的代码从写完到上线，要穿过一排闸门。每一道闸门都替业务回答一个具体的问题。

第一道闸门是代码审查。至少一个旁观者通读改动，问出作者自己想不到的问题。这一步拦下的不只是 bug，还有设计层面的弯路。第二道是自动化测试，改动合并前必须跑过既有的测试集，保证旧功能没被碰坏。第三道是持续集成里的各种静态检查，代码风格、安全扫描、依赖审计都在这一层。

第四道是分阶段发布。先上预发环境，再小流量灰度，最后全量。第五道是监控和回滚，线上指标异常时能在几分钟内退回上一个版本。这五道闸门串起来，构成了一条信任链，业务方不需要相信某个程序员，只需要相信这条链。

关键洞察是，这条信任链根本不在乎代码是谁写的。AI 生成的代码只要穿过同样的五道闸门，获得的信任等级和工程师手写的一模一样。反过来，工程师手写的代码如果绕过闸门直接上线，风险和交易员的脚本没有任何区别。信任的来源是流程，不是作者身份。

高盛自己的内部 AI 平台就是按这个思路建的。平台内置了管控，员工在平台上用 AI，数据边界、权限、审计都在设计之内。问题出在平台之外，交易员用 Claude Code 这类工具直接在本机生成 agent 和脚本，这些产物天生不在平台的管控半径里。

这也是很多公司的现状。官方平台有护栏，但员工实际爱用的是护栏之外的工具，因为官方平台的迭代永远追不上模型厂商的发版速度。管控和体验之间的时间差，就是风险滋生的空间。

理解了闸门的价值，就能看懂高盛这次调整的真正含义。它不是一道禁令，而是一次收口，把散在护栏之外的代码重新拉回流水线。问题只剩一个，收口的代价谁来承担。

高盛这次到底改了什么

先把事实摆清楚。据彭博社报道，高盛在十月修订了内部指引，把 Anthropic 的 Claude Code 和微软 GitHub 的 AI 编程工具的访问权限收回到工程师群体。修订之前，高盛做了一次生产力和风险两方面的评估，评估的结论是收紧。

失去权限的是大多数交易员。他们之前用这些工具做的事情非常实在，盯客户交易流向，给市场走势和仓位建模，生成日常报告。这些都是离业务最近的需求，也正是七月 vibe coding 政策鼓励的方向。四个月后，同一批行为被划到了红线另一侧。

促使转变的核心还是安全。工程师写的代码在部署前要经过审查和测试，交易员为盯客户交易而写的代码却可能不经任何保障措施就天天使用。几千名没有开发训练的员工，在处理客户信息的电脑上写代码、跑代码。高盛的内部 AI 平台设计时就带这些管控，但交易员用外部工具做出来的 agent 不在管控之内。

高盛新政策里真正有含金量的是三个问题。谁在用 AI，用什么数据，在什么协议之下。这三个问题没有任何技术含量，却是大多数公司从来没写清楚过的。高盛作为一家有一万两千名工程师的机构，也是在四个月之内就完成了从放开到收紧的掉头，说明这三个问题答案的变化可以非常快。

还有一个戏剧性的细节。高盛恰好是 Anthropic 本月纳斯达克上市的牵头承销商。接下来的几周里，高盛的银行家们要卖力推销一家公司的股票，而他们的大多数人刚刚失去了使用这家公司旗舰编程工具的权限。商业利益和内部安全策略在同一家公司里并行不悖。

把这次改动读成高盛反对 AI 是误读。它没有禁止 AI，内部平台还在，工程师的权限还在。它禁止的是无管控的 AI 使用方式。这个区分对后面所有讨论都至关重要。

不是只有高盛在收紧

高盛不是孤例，公开说话的人已经不少。编程工具初创公司 Replit 的 CEO Amjad Masad 近期就在社交媒体上把话挑明了，跑在员工个人电脑上的 AI agent 对企业和政府构成系统性安全风险，一些机构已经开始限制 Claude Code 这类工具，高盛只是其中之一。

系统性风险这个词用得很重，但准确。单个脚本出事是点状问题，几千个无人审查的脚本同时跑在几千台电脑上，就是面状问题。面状问题没有单一的爆炸点，它体现为数据泄露概率的整体抬升，体现为合规审计时解释不清的灰色地带。

亚洲市场同样在为这件事纠结。韩国投资行业的现状被媒体一并报道了出来。越来越多的投资评审人员用 AI 做尽职调查，用 AI 分析投资合同和投委会会议纪要。需求是真实的，一个评审同时管几十家被投企业和多笔交易，靠人肉整理海量材料根本不现实，还需要 AI 从存量项目里筛早期风险信号。

但韩国的机构也没有解决信任问题。一位 VC 从业者的话说得很直白，内部禁止员工把个人 AI 用于工作，公司支持签企业级的 AI 合同，可即便如此，一定程度的数据泄露也被认为难以完全避免。禁止个人版、采购企业版，这是目前多数机构能拿出的全部答案。

这个答案的局限很明显。企业版合同解决的是法律和数据归属问题，解决不了代码本身的工程管控问题。合同规定数据不能出境，却管不住员工让 AI 写一段没有测试的脚本去碰生产数据。法律护栏和工程护栏是两层东西，大多数公司只建了第一层。

中小型资产管理公司的处境更难。它们大多没有专职安全团队，没有内部平台，连写一份 AI 使用政策的人手都紧张。连一万两千名工程师的高盛都要用四个月才能掉头，资源更少的机构面对同样的风险时，反应只会更慢。

把这些信号放在一起看，趋势很清楚。粗放普及期正在结束，接下来是管控补课期。

谁的补课成本低，谁就能继续享受工具红利。这就是工程手段要解决的问题。

把 AI 代码纳入管控的最小工程动作

好消息是，管控 AI 代码不需要发明任何新东西，把既有的工程闸门对 AI 代码一视同仁就够了。最难的第一步甚至不是技术动作，而是一个规定，所有要被执行的代码必须先进入版本库，本机散装脚本一律不算数。代码进了版本库，后面的闸门才有附着点。

我自己就有切身体会。我维护的一个自动化发布技能仓库，最近五十条提交里有四十一条是 AI 代理产出的，我特意去翻过 git log 确认这个比例。这些提交能进主干，靠的不是信任模型，而是每一条都先过脚本自检再过人工过目，流程对手写代码和 AI 代码一视同仁。

落到工具上，第一个值得装的是 pre-commit 钩子。它在每次提交前自动跑检查，装一次长期有效。安装本身只要两条命令，先装工具再装进仓库。

pip install pre-commit
pre-commit install

装好之后，在仓库根目录放一个 .pre-commit-config.yaml，把密钥扫描挂进去。下面这份配置做了两件事，gitleaks 负责扫提交内容里有没有密钥、令牌、私钥，pre-commit-hooks 里的 detect-private-key 再兜一层私钥检测。rev 字段写你配置时对应仓库 release 页的最新 tag。

repos:
- repo: https://github.com/gitleaks/gitleaks
  rev: v8.28.0
  hooks:
  - id: gitleaks
- repo: https://github.com/pre-commit/pre-commit-hooks
  rev: v5.0.0
  hooks:
  - id: detect-private-key

为什么密钥扫描排第一？因为 AI 生成代码时最常见的坏习惯就是把示例密钥、接口地址硬编码在源码里。模型在训练数据里见过无数带密钥的示例，它不知道哪一串是你真实的生产密钥。人工 review 时一眼扫过去也容易漏，钩子在提交前拦截，成本几乎为零。

配置完成后跑一次全量扫描，命令是 pre-commit run --all-files。第一次跑通常会扫出历史遗留问题，把报告导出，逐个确认是真密钥还是误报，真密钥立即吊销轮换。这一步做完，你的仓库就有了对 AI 代码的第一道防线。

这道防线的意义超出安全本身。它向团队传递了一个信号，AI 写的代码不是法外之地，它要过和人写代码一样的关。信号一旦确立，AI 产出的质量会跟着要求水涨船高，因为生成环节就会开始规避已知的拦截规则。

再给 AI 代码加一道静态扫描

钩子管住提交入口，第二道防线是静态扫描，盯住代码逻辑本身。这里推荐 semgrep，一个开源的静态分析工具，规则可以按语言和框架选。安装同样是一条命令的事，Python 环境直接装。

pip install semgrep
semgrep scan --config=auto .

--config=auto 的含义是让 semgrep 根据仓库里检测到的语言自动拉取对应规则集，什么都不用配就能得到一份基线报告。想更精确，可以显式指定规则集，比如 Python 项目用 --config=p/python，安全专项用 --config=p/security-audit。这些规则集由社区和厂商持续维护，比自己写规则靠谱得多。

为什么 AI 代码特别需要静态扫描？因为模型有自己的统计偏好，而这些偏好里混着大量不安全的写法。让它写网络请求，它可能顺手关掉证书校验。让它写文件处理，它可能用权限过宽的默认参数。让它写命令执行，它可能把外部输入直接拼进 shell 字符串。这些写法能跑，能过review时人眼的快速扫读，但过不掉规则。

静态扫描的另一个价值是把隐性知识显性化。团队里老手看一眼就知道有问题的写法，新手和 AI 都不知道。把老手的经验固化成规则，AI 生成的每一行代码都会被这些规则过一遍，等于让团队最谨慎的那个成员不知疲倦地审查每一次提交。

扫描结果怎么处理也有讲究。直接全员报警的结果是报警疲劳，三天之后没人再看。可行的做法是分级，高危规则立即拦截合并，中低危规则只出报告不拦截，每周固定时间集中清理。这样安全防线既有牙齿，又不会把开发节奏拖垮。

两道防线配齐之后，一个普通仓库就拥有了消化 AI 代码的基本能力。密钥不进库，危险写法不过闸，所有改动有记录。这套组合的部署成本是一个人一下午的工作量，维护成本接近零。

对比一下成本收益。高盛为了管控风险，付出的成本是收回几千人的生产力工具。中小团队用上面这套方案，付出的成本是两条安装命令加一份配置文件。同样是管控，工程手段的代价小得多。

有管控和没管控，差在哪

把前面讨论的内容压缩成一张对照表，差距一目了然。左边是高盛交易员脚本的典型状态，右边是走完工程闸门的 AI 代码应有的状态。

维度	无管控的 vibe coding	纳入工程管控的 AI 代码
代码审查	写完即用，无人过目	至少一名工程师通读后合并
测试保障	没有测试，出错靠肉眼	CI 自动跑单测和静态检查
密钥管理	可能硬编码在源码里	提交前密钥扫描强制拦截
运行环境	员工个人电脑，贴着客户数据	隔离环境或服务端沙箱运行
数据边界	想发什么就发给外部 API	数据分级授权，边界写进协议
出事之后	无日志无回滚，责任难追	有审计记录，可回滚可定位

表里最容易被低估的是最后一行。无管控状态下出事，第一时间的场面一定是混乱的，谁的脚本，改了什么，碰过哪些数据，全都没有记录。有管控状态下，git log 加审计日志能在几分钟内回答这三个问题，止损动作可以立刻开始。

中间几行其实是一道选择题。公司可以花大价钱建内部平台，也可以用开源工具拼出等效的管控。pre-commit 加 semgrep 解决审查和扫描，版本库天然解决审计，剩下的运行环境和数据边界更多是制度设计而不是技术采购。

还有一个表里没有列出的维度，是员工心态。无管控环境下，员工用 AI 时心里其实没底，不知道哪天会踩雷。管控清晰之后，边界内的使用反而更大胆，因为大家知道红线在哪。清晰的管控不是压抑使用，是给使用划出安全区。

这张表也可以直接当自查清单用。对着自己团队的现状逐行打勾，哪一行还在左边，哪一行就是本周要补的课。补课顺序建议从上往下，先补审查和密钥，再补环境和边界。

小团队抄得动的作业

没有一万两千名工程师，也没有专职安全团队，小团队能做什么？其实高盛新政策里最有价值的部分恰恰是免费的，就是那三个问题。谁在用 AI，用什么数据，在什么协议之下。把这三个问题的答案写成一页纸文档，大多数小团队的风险就降了一半。

第一个问题划人。哪些岗位可以用 AI 编程工具，哪些岗位只能用内部平台。划人的依据不是职位高低，是这个岗位碰什么数据。碰生产数据和客户信息的岗位，管控等级自动上调。第二个问题划数据。把团队的数据分成能出域和不能出域两类，不能出域的数据禁止进入任何外部 AI 对话框。第三个问题划协议。个人版工具和企业版合同的数据条款完全不同，工作场景只走企业协议。

先划人，再划数据，最后划协议。

三个问题写完，再叠加前面讲的两道工程防线，一个小团队的管控骨架就齐了。整个方案的物料成本几乎为零，需要的是有人花一两天把它真正落地。相比之下，一刀切收回权限看似省事，代价却是把 AI 红利也让给了别人。

说实话，收回权限是所有答案里最懒的一个。它用放弃生产力的方式回避了管控建设，而管控建设早晚绕不开。AI 编程工具的渗透不会停下，今天收回 Claude Code，明天还会有新的工具从别的缝隙钻进来。没有工程闸门，禁令只是把时间往后推。

我的建议很具体。别等公司长出安全部门再动手，本周就去做三件事，把本机散装脚本收进版本库，装上提交前的密钥扫描，写清那三个问题的答案。这三件事任何一个小团队都负担得起，做完之后，你就拥有了高盛用四个月和几千人的权限才换来的东西，一套能放心用 AI 的工程环境。

工具会越来越强，管控只会越来越值。先把闸门装好的一方，才能在下一波工具升级里放心地快。这份作业不难抄，难的是今天就动笔。