今日要点
- 高盛 — 高盛据报收回了银行家和交易员的 Claude Code 权限，把编码代理的使用收拢回工程团队。
- Willison — Simon Willison 说，他在普通的 Claude Chat 里，让 Claude Opus 5.5 Medium 把他在同一段对话中先写好的一个 Three.js 3D 演示，移植成原生 JavaScript 加 WebGL 的版本。
这里是由Robin为你带来的咸话咸说之每日AI乱炖。
高盛据报道收回银行家和交易员的 Claude Code 权限，工具只留给约 1.2 万名工程师
高盛据报收回了银行家和交易员的 Claude Code 权限，把编码代理的使用收拢回工程团队。
据报道，高盛正在收回银行家和交易员的 Claude Code 访问权限，Anthropic 的这套编码代理在这家投行的部署被明显收紧。报道提到的高盛关注点包括安全、合规、治理和成本控制。需要说清的是，这条消息来自二手报道，没有高盛的一手公告，所以收回的确切范围、生效日期，以及是否有运维事故触发了这次调整，都无法从现有材料确认。即便如此，一家受严格监管的金融机构收紧编码代理的使用权限，本身就是值得注意的信号。
Claude Code 和 GitHub Copilot 这类工具并不只是在聊天窗口里返回文本，它们能在工作台上生成并执行代码。放进银行里用，就意味着要管住执行权限、数据访问、账号授权、审计轨迹和审批流程。高盛此前把这些工具扩展到了软件工程之外，银行家和交易员用它做市场模型和客户资金流方面的工作；据报，10 月发出的内部指引把访问范围收窄到约 1.2 万名工程师，从大范围试验转向更紧的治理。
据报道，结果就是：高盛的银行家和交易员失去 Claude Code 与 GitHub Copilot 的权限，这两类先进工具只留给约 1.2 万名工程师，同时降低了在安全、合规、授权和账单上的敞口。
评论区的关注集中在风险上：半无人值守的 agent 跑在金融从业者的机器上，同时能触达敏感数据、邮件、互联网和内网。有机构表示，限制 Claude 的原因是反复出现的账单超额，并且更倾向 Gemini 那种更可预测的计费和限流方式。其他人提到银行对授权、审计轨迹、审批链、隐私的要求，以及法律和监管层面的暴露。也有人猜测是否存在运维损失，或高盛的时机与 Anthropic 的 IPO 有关，但没有提供证据。
把这条放进当下的企业 AI 图景里看，它问的不是哪家模型更强，而是编码代理进到受监管的业务现场之后，谁能说清它在什么地方、用什么权限、动了哪些数据。报道没有说明这次收权是否与某次具体事件有关，也没有给出重新开放的条件；而同一批讨论里，计费和限流这种运营层面的差别，同样能决定一套工具在金融机构里活多久。
这条如果属实，关键不在禁用本身，而在企业对代理工具的边界重新划线。能在本地执行命令、碰触系统环境的编码代理，和只在网页框里生成文本的问答助手，治理难度完全不同；先把前者圈回工程团队，是受严格监管机构降低未知风险最省成本的防御动作。顺带也说明此前向业务岗位的铺开更像压力测试而非定案。接下来要看高盛何时有一手确认，以及其他大型金融机构会不会跟进同样的收口。
Kimi-K3.1-Pro-Coder 实验性混合精度量化把 1.77TB 压到 775GB
开源社区公布了一次量化实验，把 2.8 万亿参数的 Kimi-K3.1-Pro-Coder 从 1.77TB 压到了 775GB。
一位作者公布了对 2.8 万亿参数的 Kimi-K3.1-Pro-Coder 做的实验性混合精度量化：体积从 1.77TB 降到 775GB，减少 56%。做法是把路由的 MoE 专家分成三档精度存储，共享专家、attention 和 embedding 仍保留在 BF16 或 F32。三档分别是 2.81、2.56 和 1.44 bpw，平均约 1.92 bpw，而基座模型大约 4.0 bpw。
配套的还有 Strata，一个按 GPU 显存、pinned 内存和 NVMe 三层的卸载引擎，用 router lookahead 做预取；另外还有 dr-triton 的融合反量化 kernel。测试跑在一张 Colab 的 NVIDIA RTX PRO 6000 Blackwell 上，显存 96/102GB、内存 176GB，覆盖全部 93 层加 lm_head：AIME 2025 与 LiveCodeBench 都是 29/30，也就是 96.67%；token 一致率 top-1 为 95.20%、top-5 为 99.92%；吞吐是 batch 36.8 TPS、单流 10.8 TPS。perplexity 的变化分别是 AIME 上升 1.01%、hard LiveCodeBench 上升 2.02%、LiveCodeBench 整体上升 2.67%。
这套方案和原版 llama.cpp 或 vLLM 不兼容，因为它用了自定义的打包张量布局。用户可以按自己的显存、内存、NVMe 配比去配置 Strata，也可以把独立的反量化模块接进自己写的 PyTorch 或 Triton runner。
Kimi K3.1 Pro 是 Moonshot AI 的 2.8 万亿参数开源权重 MoE 模型，从 Kimi K3 后训练而来，上下文窗口 100 万 token。每个 token 只激活一部分路由专家，但全量专家仍然要存下来，推理时还可能需要在设备之间搬运。混合位宽量化就是给不同专家分配不同精度来压存储，分层卸载则把热的权重放显存、温的放内存、冷的放 NVMe，再用预取盖住传输延迟。
作者把这次结果定位成实验性压力测试，而不是面向大众的部署方案：775GB 的下载量和硬件门槛仍然挡在前面，数据也全部是自报的。
这也是为什么它的价值更接近一次可行性验证：三档位宽把可接受的质量损失量化出来，分层卸载把显存不够这件事变成工程调参问题，但代价是整条工具链要跟着换。想把这份权重真正跑起来，除了存储和内存，还得接受一套只有少数 runner 认识的权重布局。
这项实验的价值在于作者把压缩付出的精度与速度代价做成了完整台账，而不是单喊体积降幅，给后续复现留下了参照系。不过由于它依赖自定义张量布局和专用卸载引擎，现成推理框架无法开箱即用，可复现性很大程度上绑在作者个人的配套脚本上。接下来值得关注的是主流推理框架是否会吸收这种分层量化思路，以及那套反量化模块能否独立沉淀为标准组件。
社区开发者把 Windows AI 训练栈移植到 Kepler 到 Turing 老卡，原生 CUDA Mamba-1 可用
一位开发者把一套 Windows AI 训练栈移植到英伟达老显卡上，让十年前的 Tesla K40c 也能跑起原生 CUDA 版 Mamba-1。
一位社区开发者把一套 Windows 上的 AI 训练栈移植到了 NVIDIA 从 Kepler 到 Turing（SM 3.5 到 SM 7.5）的显卡上。这套东西包括用 CUDA 11.8 编译、保留 legacy SASS 的自定义 PyTorch 2.7.1 wheel，也带上了 causal-conv1d 1.7.0、原生 CUDA 的 Mamba-1，以及 Windows 上的 NCCL，可以在 Kepler 卡之间做分布式数据并行训练。
开发者报告说，纯 CUDA 实现的 Mamba-1 在目标架构上可以工作；在一张 2013 年的 Tesla K40c 上，相对 PyTorch 参考实现的最大绝对误差是 3.8e-06。Mamba-2 和 Mamba-3 目前仍只支持 Turing（SM 7.5）及更新的架构，因为它们依赖 Triton 和 TileLang；在更老的卡上，这些模块不可用时会自动回落到 Mamba-1。
项目方希望有更多人在 Maxwell 和 Pascal 上测试，因为本地验证只做到了 Kepler，也没有提供更大范围的基准或性能数据。作为一条自报的公告，超出 K40c 这一张卡的可用性，以及声称的性能，都还需要社区验证。
从机制上说，Mamba 是面向语言建模这类信息密集负载设计的状态空间序列模型，靠硬件感知的 kernel 提效。原生 CUDA 的 Mamba-1 绕开了新版路径对 Triton 和 TileLang 的依赖，因此能跑在很多现代 AI 栈已经不再支持的 Kepler 到 Turing 显卡上。这套移植把 legacy SASS 的 PyTorch 2.7.1 与 CUDA 11.8 的 Windows 构建，和 causal-conv1d、NCCL 这些组件拼在了一起。
换句话说，这条路线的意义不在跑分，而在于让一批被主流工具链丢下的卡重新进入训练流程：Windows 上缺的 wheel、缺的 kernel、缺的通信库，都被单独补齐并声明了适用边界。至于这些机器在实际训练里能不能撑住吞吐，作者没有给数据，也没有声称跨卡型通用。
这次移植反向说明了一个现实：许多老旧计算卡之所以被现代训练框架淘汰，往往是软件工具链的选择性放弃，而非硅片本身彻底丧失了计算能力。用手写纯 CUDA 绕开现代编译器依赖确实打通了老卡生路，但这更像极客式的可行性探索而非稳妥的生产方案。对于手头保有老旧算力资产的实验室，这提供了一条低成本尝试的备选路径；后续关键看社区在其他架构上的实测反馈能否支撑起稳定性。
Simon Willison 让 Claude 把一个 3D 演示移植成原生 JavaScript 与 WebGL
Simon Willison 开展了一次公开测试，让 Claude 把此前写好的 Three.js 3D 演示改写成原生 JavaScript 与 WebGL。
Simon Willison 说，他在普通的 Claude Chat 里，让 Claude Opus 5.5 Medium 把他在同一段对话中先写好的一个 Three.js 3D 演示，移植成原生 JavaScript 加 WebGL 的版本。他把三样东西都公开了：原始 77KB 的 Three.js 版本、98KB 的移植版，还有那段对话的记录。两边输出并不完全一样，Willison 说自己也不完全明白差在哪里。
他做了一次非正式的对比，觉得 Three.js 那一版代码稍微更好读一些；不过他也说明，这类项目的代码他本来就很少去看，所以这更像一次个人演示，不是系统性基准。
成对的、可以直接打开的产物加上对话记录，让这件事成了一个能自己动手检查的 AI 辅助移植案例。原始材料并不能证明结果可复现、输出一致，也不能证明开发流程因此发生了更广泛的变化。
值得留意的是他记录差异的方式：不是一句「模型很强」，而是把两个版本和过程一起摊开，让人自己判断哪一版更好读、差异出现在哪里。这种可检查的姿势，比任何一句评测结论都更能说明当下的模型能替人做到哪一步、又在哪里说不清。
这起案例的核心价值在于全过程的坦诚呈现，对话上下文与成对产物全部公开，给质疑者提供了少有的完整复核线索。作者自己坦承并非该技术栈专家且两端输出并不完全对齐，这就清晰界定了演示的边界，它只是单次探索样本而非生产力承诺。接下来更值得跟踪的是，社区其他开发者沿着完全一致的提示词与流程，能否在跨图形栈移植中得到一致的输出。
Willison 把 agent 写的 PR 说明折叠起来，只在上面留一段人写的引子
面对编码代理生成的冗长 PR 说明，Simon Willison 开始用折叠标签把机器详述收拢在人工摘要之下。
Claude Code、Codex 这类编码 agent 现在替 Simon Willison 开掉了不少 PR：把 commit 打包好、记录决策、写下验证过程。这些描述准确也够详尽，但密度读起来像机器生成的注水文字，连他自己都不想读，于是就需要一层由人来策展的导览，同时不丢掉有用的细节。
他的做法是把 agent 写的完整说明放进 GitHub 支持的 details 与 summary 元素里，渲染出来就是一个可以按需展开的折叠标题；在它上面，他挑一段或改一段简短的引入，说清这次改动的目的和为什么值得看一眼，有时再加一张截图，用最快的办法把新功能讲明白。详细描述原样留在折叠区里，而 summary 上会标明模型，有时还标出 effort 级别，比如 Claude Opus 5.5 Medium，让这段文字的来路清清楚楚。
近期几个例子都用这个套路：重新设计的表格行页面、更清楚的翻页、按需加载的编辑脚本、一个插件 hook，以及管理 OpenAI 兼容端点的命令。
这套办法并不丢弃 AI 生成的细节，而是把 PR 重新围绕一段经人确认的摘要来组织，既保住完整性，又让页面更好扫读，不像一整面读不下去的生成文字。
更值得记住的是他对工具的态度：agent 负责把过程写全，人负责决定读者先看到什么。评审者打开 PR 的第一屏由人写，往下才是机器留下的全部证据，责任和可追溯性没有被折叠掉。
这项技巧非常务实地解决了代理生成文本过载的问题，它不强求模型缩减必要细节，而是用人工导览加折叠标签重新找回了人类的审阅节奏。更具启发性的是在折叠标签中保留模型版本与思考强度的做法，等于为机器生成内容建立了轻量级的水印与溯源机制。值得观察的是，随着多代理协作在团队研发中普及，这种显式标注责任主体的习惯会不会演进成通行的协同规范。
今天这五条动态，一边是高度监管机构重新丈量编码代理的权限边界与治理成本，另一边是开发者把大模型极限压缩、让老硬件重获训练能力，以及在日常中探索人机协作的边界。技术在下沉，工程在务实。
🎧 本期已同步制作为播客节目，点击收听《每日AI乱炖 · 2026-11-09》。