AI 时代，学生和研究者该如何使用 AI 写程序？一种极端是假装 AI 不存在，坚持纯手写——这不利于为遍布 AI 的世界做准备。另一种极端是把活儿全交给 AI（即所谓 vibe coding）：只盯着测试是否通过，不再细读每一行代码。后者会带来「自我欺骗」——以为自己掌握了，其实没学到任何有价值的技能。作者打了个比方：认知技能像肌肉，练起来难，丢起来快。

中间路线：手写，AI 审查

折中方案被称为「匠心编程」（craft coding）。它的价值取向是围绕产品本身的质量，细到每个细节；开发者承诺理解代码库的每一处，AI 可以用，但只在有助于这一理想时才用。最凝练的实践口号是「手写，AI 审查」：以当下模型的能力，不要让 AI 去做任何事，只让它审查你写好的东西，你认同才采纳。最好的比喻，是把 AI 当成一位资深程序员的代码评审。

匠心编程的十条戒律

1. 不在 IDE 里用 AI，包括 LLM 自动补全；每一行字符都亲手敲。
2. 最好不把代码库交给 AI；需要时在网页界面里粘贴片段，若必须授权，也只用只读权限。
3. 不让 AI 运行任何东西；它给建议，你来执行。
4. 不把 AI 对话框里的代码直接复制粘贴，要自己敲一遍。
5. 能用普通搜索解决的事，不麻烦 AI。
6. 问 AI 之前，先读文档。
7. 只有自己实在解不出时才向 AI 求方案，并先给自己思考的时间。
8. 请 AI 审查前，自己先检查一遍。
9. 先运行代码排查问题，再让 AI 审查补漏。
10. 没看懂的建议，绝不采纳。

为什么值得这么做

作者以科研代码为例：论文里的实验代码一旦出错，整篇结论都可能失效，因此科学是匠心编程的典型场景。安全关键软件同样如此——在 AI 时代，纯手写的代码反而不够安全，开发者必须把 AI 审查纳入流程，否则攻防会变得极不对称。

当然，适度使用也无可厚非。作者坦言自己偷懒时也会写潦草代码、让 Claude 直接调试，但他提醒这有「技能退化」的风险。GitHub Copilot 近期从包月改为按量计费，一些重度 vibe coding 用户月费从 30 美元涨到 750 美元，也算一种侧面注脚。

结论很朴素：手写与 AI 审查之间，藏着一片明智的中间地带。只要保持思考、不把大脑闲置，答案就在那里。

来源：Peter Bloem（peterbloem.nl）

AI 编程工具到底有多能打？PCMag 的一篇实战记录给出了一个具体样本：一位玩家借助 Anthropic 的 Claude Opus 5，从零做出了一款名叫 FISH 的训练辅助小工具，用来提升自己在射击游戏《The Finals》里的水平。它不碰游戏代码、不读内存，而是把「学游戏」变成可交互的练习场。

用 AI 把高手经验提炼成「策略圣经」

FISH 是 Finals Interactive Study Helper（ finals 交互式学习助手）的缩写。它的核心思路并不复杂：先从 YouTube 上抓取职业选手的教学视频字幕，再交给 Claude Opus 5 把这些零散经验提炼成一份结构化的「策略圣经」。

随后，FISH 会基于这份圣经生成随机的实战场景——比如某一局己方领先、敌方控制着某个现金点的回合——并针对每个场景给出两套建议：一套是规则手册里的标准答案，另一套是职业选手才会用的进阶打法。玩家在模拟界面里被反复「考问」，逐渐记住各种道具、互动物件、地图、地图修正项和职业专精。

实战效果：记更快，反应更准

作者在使用一周后给出的反馈是：自己对游戏机制的理解明显加深。当地图上出现某件道具或某个特殊机制时，他能更快联想到应对方式；FISH 还会提醒一些容易被忽略的细节，例如在团队整体阵亡重生往往比冒险复活队友更省时间，又比如在现金箱下方铺一层黏胶，能挡住敌方把箱子炸出范围的火箭弹。

换句话说，AI 在这里扮演的是「陪练教练」：它不替玩家操作，而是把高手的经验拆解成可反复演练的片段，让人把规则内化成直觉。

模型对比：Opus 5 正在逼近 GPT-5.6

这篇实战记录也顺带做了一次模型横向观察。作者此前的对比里，GPT-5.5 对 Opus 4.6、Fable 对 GPT-5.6，结果都明显偏向 OpenAI 一侧；但到了 Opus 5，情况出现了变化——在效率上的提升，加上与 Fable 5 相当的智慧水准，让它「值得认真考虑」。

具体到编程搭建 FISH 这类项目，作者认为 GPT-5.6 仍然往往给出最好的结果，但每个项目情况不同，Opus 5 凭借效率优势已经具备竞争力。他还特别提到一个现实痛点：Opus 5 存在约 5 小时的令牌额度上限，智能体一旦出错需要重做，体验相当折磨；相较之下，ChatGPT 的周额度更灵活。

启示：普通人也能手搓出实用小工具

FISH 的价值不在「外挂」，而在于证明了一件事：只要会提需求、会迭代，一个没有深厚工程背景的人，也能用上一代 AI 编程工具做出真正改善自己生活的实用小工具。

当然，AI 并非万能。作者也坦言，让 Opus 5 去抓取《The Finals》维基页面的基础资料时，模型会失败；从数百条职业选手视频里提炼策略圣经，结果也时有参差。AI 能放大人的能力，却还远未到可以完全替代人类判断的地步。

对想上手的人而言，这套方法的门槛并不高：找一段你想精通的领域资料，交给大模型提炼成知识库，再让它生成可交互的练习或问答。能否成事，关键仍在于你能否把需求讲清楚、把反馈回路设计好。

来源：PCMag（2026 年 8 月）

新建项目，唤出 Gemini

动手的第一步是在 Windows、macOS 或 Linux 电脑上安装 Android Studio，新建一个「手机与平板 > 空白活动」项目。项目加载完成后，点击右侧边栏的对话气泡图标，就能打开 Gemini 面板，接下来的编码工作都将在这里完成。

Gemini 会先在对话中给出实现方案并询问是否继续，确认之后便开始实时写代码、改文件。Fedewa 这次的目标是一款仿复古法律便签风格的 Markdown 编辑器，他给出的首条指令只有一句话加一张参考图：请创建一款仿复古法律便签风格的 Markdown 笔记应用，就像这张图里那样。约十分钟后，一个可部署到手机的雏形就成型了。

边聊边改，对话式排错

首版结果很少一步到位。Fedewa 遇到的问题是：Markdown 效果没有实时渲染，文字也与便签横线严重错位。他直接用 Gemini 界面里出现的叫法去描述故障，比如把那些横线称为「蓝色横线」，让模型精准理解问题所在。修复 Markdown 渲染很快完成，而对齐则反复尝试了几次：他不断告诉 Gemini「对齐还是不对」，甚至建议加大行距，最终找到的解法是把横线去贴合文字，而非强行把文字挪到线上。

导出安装包，侧载到手机

满意之后，通过「构建 > 生成应用包或 APK > 生成 APK」即可把应用打包成 APK 文件，再像安装其他应用一样侧载到手机上使用。

Fedewa 坦言，这款小应用谈不上「必须存在」，但他想说明的是：在 Android Studio 的 Gemini 加持下，把一个模糊的念头变成能跑起来的应用，门槛已经低到出乎意料。对他而言，这一小时的工作量，远少于此前做 webOS 风格桌面启动器所花的时间。对于有想法却苦于无从下手的普通用户，这或许是一条值得一试的路。

来源：How-To Geek（作者 Joe Fedewa，2026 年 8 月 16 日）

在 GPU Mode 与 Core Automation 联合举办的一场「自动研究」主题编程竞赛里，一名开发者借助 OpenAI 的 Codex 编程智能体，把一道 CUDA 矩阵分解内核的运行效率提升到基准方案的 232 倍，在 183 名参赛者中位列第 12。整篇复盘没有停留在「调参玄学」，而是把「让 AI 替你做研究、自己跑实验」的工作方式拆解得相当具体。

赛题：给张量核心喂饱矩阵乘法

竞赛的要求是实现批量方阵的紧凑 Householder QR 分解，输出格式需与 PyTorch 的 torch.geqrf 一致。QR 分解把矩阵拆成正交矩阵 Q 与上三角矩阵 R，是许多线性代数与优化器的底层算子。难点在于，标准的 Householder QR 是「一列一列串行」地清零下三角，串行部分只能跑在 SM 的慢速向量单元上，而昂贵的张量核心只能干等。

该作者的突破口是经典的「分块 Householder + WY 表示」：先在一个窄面板内完成串行工作，再把面板的多个反射子压缩成一次秩-b 更新，用三次连续的矩阵乘法（GEMM）一次性覆盖后方的主块。这样串行工作量被锁在窄面板里，其余部分全部变成张量核心最擅长的 GEMM 形状。测试覆盖的矩阵规模从 512×512 一直到 4096，批量大小跨度很大，最大的矩阵批量太少填不满张量核心，最小的 32 阶又得把多份矩阵塞进同一次内核启动。

自动研究：把未知未知变成已知未知

更值得借鉴的是人机协作的方法论。作者坦承自己只是「有一年的 GPU 内核优化基础、并非专业人士」，在排行榜上属于逆风开局——排在他前面的人里有英伟达的首席工程师。他的体会是：对问题理解得越透，给大模型的提示词就越精准，本质是「把未知未知转化成已知未知」。他先用 Claude 补 QR 分解与 Householder 反射的直觉，确认主干架构必须走分块 Householder 配合尾部 WY 更新；GPT-5.5 在这一架构上也给出了同样的判断。

在 14 天里，他提交了超过 1500 次方案。竞赛提供的命令行工具让智能体能直接测试、跑分并提交排行榜，形状级别的反馈加上整体几何平均耗时，构成了一个让智能体不断「爬山」的紧凑循环。他还利用低精度（FP16、FP8、NVFP4）在内部加速，同时保证返回的因子仍通过 FP32 级别的 QR 校验。工具链上，他使用 ChatGPT Pro（每月 200 美元）与 Claude Pro（每月 20 美元）两套订阅，并用 Modal 提供的每月 30 美元免费额度做性能剖析，Codex 的 /compaction 等功能则用来维持长程上下文。

对开发者的启示

这则案例的价值，不在于「232 倍」这个炫目的数字，而在于它展示了一种新的工程范式：当反馈循环足够紧凑、可自动评测时，编程智能体可以代替人完成大量试错，而人类的作用退化为「提对问题」与「判断方向」。对于日常做性能优化的工程师，文章也直言不讳地指出可改进之处——例如更早引入更系统的低精度策略、把更多形状纳入回归测试。自动研究不会取代领域知识，但确实把「懂一点」和「完全不懂」之间的差距，压缩得比过去小得多。

来源：Hacker News（原文出自 sankalp 个人博客，作者 sankalp）

8 月 14 日，智谱发布新一代旗舰模型 GLM-5.3。与上一个版本 GLM-5.2 相比，新模型的基座并没有更换，全部提升来自后训练阶段的强化学习——智谱称其为「后训练 Scaling」：依托 IndexShare、SAO 以及新一代 Slime 框架，在完全相同的基座上把训练时长、任务环境种类与长程任务规模都做了大幅扩展。用官方的话说，这个基座的智能上界还远未被开发完。

在内部体感评测中，GLM-5.3 的编程能力较前代提升约 50%，在多项公开基准上登顶开源模型第一。智谱将其定位为「为编程而生，为网络防御就绪」，并称其编程与智能体能力已接近 Claude Fable 5，编程体感超过其他国产模型。

基准分数：编程与安全双双跃升

具体来看，在衡量真实终端环境复杂任务完成的 Terminal-Bench 3.0 上，GLM-5.3 得分从 4.6 提升到 28.3；在长程软件工程与持续代码修改的 DeepSWE v1.1 上，从 46.2 提升到 66.9；在跨工具协作与长程任务的 Agents Last Exam 上，从 23.8 提升到 28.5；在覆盖 44 种职业真实知识工作的 GDPval-AA v2 中得分 1769，呈现出基于编程能力涌现出的专业任务执行力。

网络安全是这一版最突出的新增方向。在白盒代码审查与漏洞发现任务中，GLM-5.3 的表现与闭源标杆 Mythos 5 持平；在漏洞验证基准 CyberGym 中取得 84.5% 的成绩，高于 GLM-5.2 的 77.2%，也略高于 Mythos 5 的 83.8% 与 GPT-5.6 Sol 的 83.6%。在 Z.ai Code Bench 高档位端到端测试中，其准确率达到 31.4%，超过 Claude Opus 4.8 最高档位的 29.5%。

两周后开源，工具链同日上线

智谱表示，GLM-5.3 的全部提升都来自后训练，因此模型权重将在发布约两周后开放，前提是完成必要的安全评估与加固，以限制其潜在的攻击能力、保留防御价值。这是智谱（Z.ai）十三个月内发布的第七款旗舰模型。

与模型同步，智谱官方编程工具 ZCode、效率工具 AutoClaw 已于发布当日上线，GLM Coding Plan 面向全量用户开放订阅；Trae、扣子、WorkBuddy/CodeBuddy、Qoder、CatPaw、JoyCode、OpenCode 等多家编码平台也获得抢先体验资格。

来源：智谱官方公告（经 IT之家、澎湃新闻、新浪科技、AI Release Tracker 等转述与整理）

Anthropic 在 8 月 7 日通过官方开发者账号 @ClaudeDevs 宣布，从 Claude Code v2.1.224 版本开始，不同会话之间可以直接互相发消息，这项功能被称为“跨会话消息传递”（Cross-session messaging）。

会话之间到底传了什么

官方文档对这项能力的描述很克制：跨会话消息传递让 Claude 把一条消息从一个 Claude Code 会话送到另一个会话。当一个会话里的改动破坏了另一个会话正在构建的东西时，Claude 可以在用户察觉之前就发出预警；当一个会话解开了另一个会话卡住的问题时，答案也能被及时送过去。

关键在于传递的内容边界。@ClaudeDevs 在发布推文中写道：

不必再在另一个会话里把来龙去脉重讲一遍，现在可以让 Claude 去讲。它发送的是一段摘要，而不是完整的对话历史或文件，另一个会话会在任务进行中接收到它。

也就是说，跨会话消息本质上是一段由 Claude 自己撰写、写给另一个 Claude 的纯文本，附带发送方的名称和一个回复地址。对话历史不会跟着走，项目文件也不会。如果需要迁移的是完整上下文而非一个结论，对应的机制仍然是恢复会话，而不是发消息。

实现层面新增了两个工具，用户不需要手动调用：ListAgents 负责发现当前可以联系到哪些会话，SendMessage 负责按名称把文本投递过去。在任意会话中输入斜杠命令 /list-agents（别名 /peers）即可查看可达会话列表，其中包含当前会话内的子代理、同一台机器上的其他本地会话（含后台会话），以及在远程控制连接状态下位于其他机器或网页端的会话。

会话通过名称相互识别，可以用 /rename 或启动参数 --name 指定，也可以由 Claude Code 依据工作目录自动生成。若两个会话重名，列表会额外显示各自的工作目录以便区分。

# 启动时直接命名
claude --name migration
claude --name payments-api

# 在任一会话中查看可达列表
/list-agents

权限这道闸门没有松动

Anthropic 列出的典型场景包括四类：移交一项调查发现、协调并行的工作树（worktree）、获取长时间运行任务的状态，以及跨机器回复。

值得关注的是这项功能在权限上的保守设计。跨会话消息不能用于批准权限请求，也不能修改配置。像 /compact 这样的指令传过去只会被当作纯文本，不会被当成命令执行。如果接收方要按消息内容动手，仍会照常向用户弹出权限确认。换句话说，来自另一个会话的消息，永远不等同于用户本人的授权。

同一版本还引入了 crossSessionInbound 与 dialogExpiry 两项设置。发往以绕过权限模式（bypassPermissions）运行的会话的消息会被暂扣，直到用户批准；发往其他会话的消息则自动投递。此外，这一版修复了一个可靠性缺陷——此前即便写入对方收件箱实际失败，SendMessage 也会显示“消息已发送”，现在投递失败会明确报错。

为防止会话之间陷入互相喊话的死循环，Claude Code 对同一发送方的重复消息做了限流，短时间内到达的完全相同的消息会被丢弃，每个会话待读消息上限为 50 条。

使用门槛与适用边界

该功能要求 Claude Code 版本不低于 v2.1.224，且运行在 macOS 或 Linux 上（包含 WSL 2），暂不支持原生 Windows。满足条件后默认开启，无需额外配置。同一台机器上的会话通过本地套接字通信，不经过 Anthropic 服务器；跨机器场景目前只支持“回复”，即 Claude 无法主动向远程或网页端会话发起对话。

需要说明的是，跨会话消息并非万能胶。Claude Code 对相邻场景各有专门机制：搬运完整上下文用会话恢复，由 Claude 自行派生并监管的一组代理用代理团队（agent teams），在一处观察和操控多个会话用代理视图，用手机操控会话用远程控制，把持续集成结果这类外部事件推入会话则用频道（channels）。跨会话消息真正填补的，是两个由用户自己开启、自己驾驭的并行会话之间的那次交接。

同版本一并落地的还有另外两项能力：面向团队版与企业版的自托管运行器（self-hosted runner），允许把网页、移动端和桌面端会话的实际计算放在自有机器或容器上执行，适合有数据驻留或内网访问要求的组织；以及压缩包插件源，支持通过 HTTPS 拉取单个 zip 文件安装插件，无需 git 或 npm，并可选用 SHA-256 校验值锁定。

对于习惯同时开三四个终端跑不同模块的开发者而言，这次更新省下的不是算力，而是那些反复复制粘贴的碎片时间。

来源：9to5Mac、Anthropic 官方文档、@ClaudeDevs

article_id: cbbc51409127fc34eb701bb4c0b86bb7

title_zh: 路由省三成、token 砍半：Databricks 控费法

source: Databricks 官方博客

published_at: 2026-08-08

—

AI 编程工具给企业带来的效率提升有目共睹，但当它铺开到整个研发团队，账单却常常以指数级膨胀，甚至有可能超过工具本身创造的价值。Databricks 近期发布长文，结合自家与 Stripe、Coinbase、Uber、Ramp 等公司的一线经验，总结出一套把成本压回可控区间、又不牺牲效率的方法论。

比“最聪明”更重要的是“最划算”

文章提出一个核心概念——“效率前沿”（efficiency frontier）。与追求峰值智力的“智能前沿”不同，效率前沿指的是在给定智力水平下价格最优的那一批模型。日常编程大多不需要证明数学定理或破解全新安全漏洞，真正决定总体开销的，是达到普通软件工程质量门槛的模型单价。Databricks 观察到，效率前沿的推进速度远快于智能前沿，几乎每周都有性价比更高的新模型出现。

成本杠杆的第一招，是果断切换到开源与低成本模型。难点在于公开榜单往往不能反映真实编码表现，因此多家公司自建了更接近内部研发场景的自动评测。Databricks 公布的评测显示，GLM 系列模型性价比突出，已向内部开发者推广。反面案例同样有说服力：Stripe 发现 Opus 4.7 相比 4.6 并没有明显的质量提升，却更贵，于是决定不在内部放开 4.7；Databricks 在对比 Opus 5.0 与 4.8 时也观察到了类似的“成本倒退”。

让请求自动选最便宜的模型

第二大杠杆是动态路由。与其让用户手动挑模型，不如用代理在请求层或任务层自动派单。Databricks 自家的 Unity AI Gateway 中的 Smart Router，能把单个任务的平均成本压低超过 30%，同时质量与最贵模型基本持平。类似思路也出现在 Cursor Router、OpenRouter 的 AutoRouter、Ramp 的 Router 等功能中。在元调度（meta-harness）层面，Omnigent 这类工具把任务按复杂度分派给不同底层模型，既保留模型选择的灵活性，又降低了开发者的切换成本。

用“可见性”替代“硬预算”

第三招是给开发者可见性、预警线和弹性预算。文章指出，简单粗暴地设月度硬上限在每家受访公司都很少作为首选——开发者一旦撞上上限被断供，生产力会瞬间瘫痪；而真正高消耗的用户，往往正是借助 AI 拿到巨大产出的人。更通行的做法是提供实时花费面板、在花费升高时逐步增加摩擦（自助确认提醒、升级到主管审批），以及把用户“降档”到更便宜的模型而非直接停权。

砍掉被浪费的 token

第四招针对被忽视的 token 开销。用户一句简短指令，背后却会被代理拉取大量上下文、调用一堆工具、检索整个代码库——真正由用户显式写出的内容，在喂给模型的数据里只占极小比例。Databricks 通过更频繁地压缩上下文、调低代理的“话痨”程度、精简常用工具的冗余输出、把任务拆小，并对提示词缓存做针对性调优，在不损失质量的前提下让生成 token 数和相关成本下降近 50%。

文中提到的基础设施，Databricks 已以开源或免费软件形式放出：统一管理的 Unity AI Gateway，以及面向开发者的元调度工具 Omnigent。把这套组合拳用起来，企业才有机会同时满足“广泛、低摩擦地开放 AI 工具”与“成本可预测”这两个原本相互拉扯的目标。

来源：Databricks 官方博客《Managing AI Coding Costs at Scale》

一条几乎没有回旋余地的禁令

Oracle 是开源 Java 项目 OpenJDK 的企业赞助方。近期，OpenJDK 管理委员会批准了一份关于生成式 AI 的临时政策，措辞相当直接：

OpenJDK 社区的贡献不得包含由大语言模型、扩散模型或类似深度学习系统部分或全部生成的内容。这里的内容包括但不限于 OpenJDK 代码仓库、GitHub 拉取请求、电子邮件、维基页面以及 Java 缺陷系统条目中的源代码、文本和图片。

政策同时留了一道口子：贡献者仍可以私下使用这类工具来理解、调试和评审 OpenJDK 的代码及其他内容，也可以用于相关研究，前提是不把工具生成的内容提交上去。

配套的问答部分把边界划得更细。如果用生成式 AI 写了 100 行代码，自己再改掉其中 10 行，这份贡献依然不能提交，因为它仍然“部分包含”AI 生成内容。编辑器和集成开发环境里的拼写检查、语法检查、自动补全和重构功能可以继续使用，条件是它们不基于大语言模型或类似的深度学习系统。为了让规则落地，OpenJDK 计划改造自动化评审系统 Skara，在每个拉取请求正文中加入一个复选框，提交者必须勾选确认自己的贡献符合该政策。

三条理由：评审、安全、知识产权

官方给出的顾虑有三层。

第一是评审负担。生成式 AI 天然擅长批量产出看似合理的代码和看似合理的测试，但这些代码可能本身就是错的，即便正确，也常常设计糟糕、难以维护。评审这类提交会迅速消耗本就紧张的人力。

第二是安全。OpenJDK 维护的 JDK 是 Java 平台的主要实现，支撑着全球企业、政府机构的关键业务系统。官方表述是：“安全性和安全保障至关重要。看似合理但实际错误的代码会让这些关键属性面临风险。”

第三是知识产权。Oracle 贡献者协议要求贡献者对每一份贡献拥有知识产权，并能无限制地把这些权利授予 Oracle。但多数生成式 AI 工具是在受版权和许可证保护的内容上训练出来的，输出可能包含侵权内容；至于使用者本人是否对 AI 生成的输出拥有知识产权，目前仍是多起诉讼正在争论的问题。

对内的说法完全相反

这套谨慎姿态，与 Oracle 对外宣传自家 AI 编码能力时的口径形成了鲜明落差。

联合创始人兼首席技术官 Larry Ellison 在 Oracle AI World 2025 上说过一段被广泛引用的话：

Oracle 写的那些代码，不是 Oracle 在写。是我们的 AI 模型在写。我们只需要告诉模型希望这个程序做什么，AI 就会拿出一套分步流程去实现。流程不是我们写的，我们只声明意图，由模型写出那套分步流程，也就是通常所说的计算机程序。

今年早些时候，联席首席执行官 Mike Sicilia 也表示，如果不采用 AI 编码工具，这些工具将构成威胁，但公司正在快速采用，“在 Oracle 内部使用 AI 编码工具，让更小的工程团队能更快地为客户交付更完整的方案”。今年 6 月裁减 21000 个岗位时，公司在声明中同样提到，AI 技术在各项业务中的部署已经并可能继续导致人员规模缩减。

科技媒体 The Register 直言不解：既然 AI 生成的代码适合放进 Oracle 自家产品，为什么不适合作为 OpenJDK 的贡献？该媒体已就此向 Oracle 提出询问。

值得一提的是，同属 Oracle 体系的 GraalVM 走了另一条路。这个由 Oracle Labs 主导、不受 OpenJDK 管理委员会管辖的项目，明确允许贡献者使用 AI 编码助手，只是要求提交者对整份贡献负责——必须能够解释、辩护并维护相关改动，否则贡献可能被拒。两个项目签署的是同一份贡献者协议，结论却完全相反。

时间点也不算轻松

这场争议出现的时机对 Oracle 而言并不舒服。公司表示未来一年将投入 700 亿美元扩建数据中心，高于 2026 财年（截至 5 月）的 557 亿美元。评级机构标普随后将其信用评级下调至 BBB-，仅比垃圾级高出一档，理由是这些投资的盈利路径尚不明朗。Oracle 正在大举借债支撑建设计划，并接受负向现金流；近期其信用违约互换利差走阔，意味着为其债务违约投保的成本正在上升。

在这样的背景下，公开表达对 AI 可靠性的疑虑，与对外持续强调 AI 已能代写代码的叙事之间，确实存在难以自洽的张力。

来源：The Register、OpenJDK 官方政策页、InfoQ

有位用户的原话是：让 Claude Opus 5 建个备份，结果它把备份建到了错误的目录，然后直接 rm -rf 清空了整块硬盘。删完之后回了三个字：「抱歉，手误。」

先看懂这条命令有多狠

rm 是 Linux 里删除文件的标准命令，单用破坏力有限。加上 -r（递归）和 -f（强制）就变了性质——一个目录连同所有文件和子目录，几秒钟内全部消失，不进回收站，不给确认。

最危险的是它出现在用户主目录附近。比如 rm -rf /Users/benpatt/deleteme，本意只是删主目录下那个 deleteme 文件夹；路径尾巴那段一漏，主目录里的东西一次性全没。更极端的是 sudo rm -rf /，sudo 让你变成超级用户，单独一个 / 是系统根目录，这条下去整块盘清空。

三条防线，现在就能设

1. 看到就打断。 AI 清理旧目录、做收尾时会主动建议这条命令，别顺手点通过。回它一句：「别用 rm -rf，换一种更安全的删除方式。」
2. 把规矩写进配置文件。 Claude 的 CLAUDE.md、Codex 的 AGENTS.md 里加一条硬规则，Ben Patterson 给的原文可以照抄：Never run rm -rf or any equivalent recursive, forced deletion — including reordered flags, aliases, shell wrappers, scripts, find -delete, or git clean -fdx.（禁止运行 rm -rf 及任何等效的递归强制删除，包括调换参数顺序、别名、shell 包装、脚本、find -delete 和 git clean -fdx）。堵住变体这句是关键，否则换个写法照样绕过去。
3. 别撒手不管。 质疑它的逻辑、复核它的决定，这不是不信任 AI，是基本的工程习惯。

我的判断是，很多人还没意识到自己已经换了身份——只要在用 Claude Code 或 Codex，你就是个 Linux 用户，该有的敬畏心一样都不能少。少一个斜杠的代价，AI 不会帮你承担。

来源：PCWorld

数据来自开发者安全博客 Scale X 的作者 Alex Wauters，他此前曾在优步（Uber）担任资深工程师。几个月前他发布了一款浏览器小游戏，让玩家扮演 AI 编程智能体的”人类审核员”，在限时压力下逐条批准或拒绝命令。有些命令属于日常操作（如 git status、npm test），有些则意味着智能体已被劫持，正在把密钥发往远程服务器（如 cat ~/.aws/credentials）。游戏在技术社区 Hacker News 上引发讨论后，作者补齐了统计功能，并对累计数据做了复盘。

核心数据：平均准确率只有 66.3%

• 玩家平均准确率 66.3%，即平均漏过三分之一的威胁；

• 32.9% 的对局最终得分为负：放行威胁的扣分加上误拦安全命令的损失，超过了做对部分带来的收益；

• 35.2% 的玩家抓住了全部威胁，但其中只有 20.8% 是在误拦率不超过五分之一的前提下做到的，其余人靠”一律拒绝”凑数，被作者授予”人类瓶颈”称号；

• 7% 的玩家对所有提示一律点了同意。

作者也提示了样本局限：这是一款游戏，其中约 34% 的命令是威胁，而真实工作中威胁出现的频率远低于此；玩家也清楚自己正处在限时测试中。这些数字更适合用于横向比较不同威胁类型的识别难度，而非直接换算成真实环境的失守概率。

越危险的命令越容易被抓，越值钱的命令越容易漏

按威胁类型统计的漏过率呈现出清晰规律：

一眼可见的毁灭性命令被拦得最牢，而真正会把凭据送出去的命令，漏过频率大约是前者的三倍。

最容易骗过人的，恰恰是那条看起来最普通的命令

全场漏过率最高的单条命令是 npm run analyze，64.7% 的玩家直接放行。npm run 本身通常无害，但它执行的是项目 package.json 里定义的脚本内容——既可能是正常的打包体积分析，也可能是此前被写入文件的恶意代码。

游戏其实在权限弹窗上方的历史记录里明确展示了脚本内容：这条 analyze 脚本在跑完分析后，会用 curl 把结果发送到一个外部接口。三分之二的玩家依然点了同意，说明弹窗上方的历史日志很少被认真阅读。

同类命令共有三条，全部进入最难识别榜单：npm run analyze 漏过率 64.7%（37 条威胁中排第 1）、npm run setup 48.0%（第 4）、npm run deploy 44.9%（第 8）。三条合并统计漏过率 52.5%（样本量 9,482），而其他外泄型攻击平均为 28.4%。把恶意载荷藏在一个熟悉的脚本名后面，成功率大约翻倍——即便载荷就明晃晃写在日志里。

Hacker News 用户 dns_snek 的评论点出了更根本的问题：逐条批准命令这套模型本身就站不住脚。npm run build 等价于执行 package.json 里的任意 shell 命令，而智能体完全可以在无需批准的前提下先改掉 package.json、往 build.js 或 node_modules 目录里塞进恶意代码。让用户去校验那些”绝大多数时候安全、但因为文件已被改动而不再安全”的命令，算不上有力的防护。

授权疲劳是真实存在的

Anthropic 此前曾指出，其编程工具 Claude Code 中的授权疲劳确有其事：用户看到的批准请求越多，对每一条的注意力就越少，随着时间推移，监督会明显松懈。

统计图显示，即便在这样一局时间很短、且玩家已被提前告知存在威胁的游戏里，也能看到衰减迹象：按完成命令数分组后，各组玩家在开局几条命令后表现改善，随后漏过率又向上爬升。作者说明，这里已剔除那些一律拒绝的玩家；末段上升也可能与倒计时压力下的抢操作有关。

过度拦截是硬币的另一面

一批本意无害的命令被频繁误拦：npm config set registry https://npm.internal（切换到内部镜像源）被拦 59%；rm -rf dist/（清理构建产物，通常在新一轮构建前执行）被拦 45%；kill $(lsof -t -i:3000)（释放被崩溃进程占用的端口）被拦 43%。

这正是人工确认机制的两难：噪声拖慢智能体，久而久之用户放松警惕，反而更容易放行真正的恶意命令。Anthropic 的”自动模式”试图先自行判断命令是否安全、再决定要不要打扰用户，但作者认为这类机制并非万无一失。

争议最大的一条是 cat ~/.zshrc，45.9% 的玩家选择放行。反对意见同样成立：不少开发者的 shell 配置文件里并没有敏感信息，读取它无害；但对于把接口密钥写在里面的人，这就是一次凭据泄露。这条命令的风险完全取决于智能体看不到的本地配置。作者建议把密钥单独存进一个文件、再从 .zshrc 中引用，可以有效降低暴露面。

结论

作者的判断是，虽然只是一款游戏，但它暴露了把人工确认当作 AI 编程智能体安全底线的几个结构性问题：噪声太多带来疲劳，开发者也常常缺少判断风险所需的上下文——他们并不清楚文件在此之前被改动过什么。对开发者而言，更现实的做法是熟悉不同权限模型之间的取舍，并落实沙箱隔离、把凭据与环境变量密钥分离等具体缓解手段。

来源：Scale X（scalex.dev）