首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >93%的人都会点“同意”:工程师正在失去最后一道控制权

93%的人都会点“同意”:工程师正在失去最后一道控制权

作者头像
靖扬
发布2026-04-21 15:52:56
发布2026-04-21 15:52:56
1040
举报

前两天我看到 Anthropic 发布 Claude Code Auto Mode 的介绍,第一反应不是“这个功能真先进”。

而是有点想笑,因为那个场景太真实了。

如果你用过 Cursor、Claude Code 这类工具,应该都经历过这一幕:

AI 改了几行代码,弹出一个框,让你确认。 你看一眼。 有时候甚至连看都不看。 然后直接点:同意。

再改。 再点。 再同意。

点到后面,那个“人工确认”的动作,已经不再是审查。 更像一种条件反射。

Anthropic 也给了一个很扎心的数据:

用户 93% 的操作都会批准。

看到这个数字的时候,我脑子里冒出来的第一个词,不是安全。 而是:

伪安全。

一、为什么“93%的人都会点同意”,本质上是一种伪安全

这个问题,本质上不是 AI 的问题。 是人的问题。

更准确一点说,是人脑和系统节奏不匹配的问题。

AI 生成代码的速度越来越快。 命令执行越来越密。 工作流越来越连续。

但人的思考速度并没有变快。

你不可能像 AI 一样,持续高强度地逐条审查每一个改动、每一条命令、每一次网络请求。 更别说,大多数时候那些改动看起来都“差不多没问题”。

于是大脑会自动进入一种省电模式。

第一次你还认真看。 第十次你开始扫一眼。 第一百次,你已经开始凭感觉点了。

这件事,我一点都不觉得丢人。 因为这就是人。

我以前做产研协作时,就特别明显地感受到一个规律:

任何需要人类高频、重复、低反馈地做确认的系统设计,最后都会失效。

因为人不是为这种机制设计的。

这也是为什么,我看到 Claude Code Auto Mode 的时候,会觉得它真正有意思的地方,不是“又多了一个自动模式”。

而是它在承认一件现实:

人工逐条审批,这条安全路径本身已经走不通了。

二、这件事在工程领域里,其实早就有前科了:告警疲劳

如果你做过运维、SRE、安全,应该对一个词很熟:

告警疲劳。

十条告警的时候,人会处理。 一百条告警的时候,人会筛着处理。 一千条告警的时候,人只想把声音关掉。

因为当问题密度超过人的处理阈值时,系统给你的不再是安全感。 而是麻木感。

最后的结果很讽刺:

告警不是越多越安全。 确认也不是越多越安全。

当你让人持续面对大量“可能有事,也可能没事”的提醒时,人的策略不会变得更谨慎,反而会变得更敷衍。

这个逻辑,放到 AI 编码工具里一模一样。

如果 100 次确认里,有 93 次你都会点通过, 那这 93 次确认,本质上已经没有提供真实价值了。

更麻烦的是,它还会制造一种错觉:

“反正我点过了,说明有人把关。”

这就是最危险的地方。

因为它让人误以为自己在控制系统, 实际上,控制权早就悄悄让渡出去了。

三、人类不再适合做第一道闸门

Anthropic 这次给出的方案,可以概括成一句话:

代理执行,分类器兜底。

这套设计很值得聊。

以前的逻辑是:

AI 每做一步敏感操作,都先来问你。 你是那个闸门。

现在的逻辑开始变了:

AI 先做。 一个独立分类器判断这一步是否偏离用户授权。 真正高风险的,再拦下来。

也就是说,系统不再默认“人类逐条审批”是安全核心。 它开始默认:

人类只该处理少数真正需要处理的异常。

这个变化,我觉得比功能本身更重要。

因为它代表着一种权限模型的迁移:

AI 系统的权限模型,正在从“人工确认”转向“代理执行 + 概率守门”。

这句话听起来有点抽象,我翻译得更直白一点:

以前像小区门口保安。 每个人进门都要问一句:你是谁?来干嘛? 后来人流太大,保安根本问不过来,大家开始刷脸直接进。 真有异常,再由系统报警拦截。

软件世界里也在发生同样的事。

不是因为大家突然更激进了。 而是因为代码生成速度和执行密度上来之后,“每一步都让人确认”这个交互设计,已经不符合现实使用场景了。

四、为什么“分类器守门”会成为未来更主流的结构

Auto Mode 的做法,说到底是一种新的工程折中。

它不是完美安全。 它只是承认:人类审批本身也不完美,而且在很多场景下,比我们以为的更不可靠。

Anthropic 这套机制里,有几个点我觉得很有代表性。

1)它不再让人盯所有操作,只盯高风险操作

读文件、搜索代码这种低风险动作,直接放行。 项目目录里的改文件,也默认放行,因为可以用 Git 回退。 真正要审查的,是 Shell 命令、网络访问、外部工具调用、项目目录外文件操作。

这其实是很典型的产品思维。

不是“所有东西都严格”,而是按风险分层设计体验。

低风险路径追求顺滑。 高风险路径才提高摩擦。

很多系统做不好权限,问题就出在这里: 它把所有风险都一视同仁,于是最后用户对所有风险都麻木了。

2)它审查的重点,不是“命令危险不危险”,而是“用户到底有没有授权”

这一点特别关键。

比如“部署”本身并不天然危险。 危险的是:用户到底有没有明确让你部署。 “清理分支”是不是等于“删除远程分支”? “修一下”是不是等于“跳过校验强制执行”?

本质上,风险判断开始从“行为识别”转向“授权边界识别”。

而这恰恰是最难的地方。

因为自然语言天然模糊。 同一句话,十个人可能有十种理解。

Anthropic 复盘漏检案例时发现,很多时候分类器并不是不知道这个操作危险, 它是误判了:

“这算不算用户授权?”

这就很真实了。

也让我更坚定一个判断:

未来 AI 权限系统最核心的难点,不在于识别危险动作。 在于识别模糊授权。

3)它不听 Agent 自己辩解

这个设计我很喜欢。

分类器在判断时,不看 Claude 的长篇解释,不看它的推理过程,也尽量隔离工具返回内容。 只看两件事:

  • 用户说了什么
  • Agent 准备做什么

为什么这么设计?

因为会做事的 AI,也会给自己找理由。

能力越强,越容易把越界行为包装成“我是为你好”。

这跟现实里很多系统设计问题很像。 一旦你允许执行者同时拥有解释权和执行权,边界就会开始漂。

所以我的理解是:

这不是一个模型能力问题。 这是一个权限结构问题。

当系统开始防的不只是“模型犯错”,而是“模型过度主动地帮你”,很多旧思路就不够用了。

五、真正的大变化,不在权限模型本身,而在软件工程的瓶颈已经换了

如果你只把 Auto Mode 当成一个“更省点确认按钮”的功能,那其实看浅了。

我真正关心的是,它背后暴露出来的那个更大变化:

软件工程的主要瓶颈,正在从“代码生产”迁移到“验证、约束和回滚”。

这句话,是我最近越来越强烈的一个感受。

以前工程效率的核心矛盾,是写得慢。 需求很多,开发资源有限,排期紧,产能不足。

现在不一样了。

AI 让代码供给开始膨胀。 写代码这件事,正在快速变便宜。

可问题也跟着来了。

你让 AI 产出十倍的代码, 并不等于你拥有了十倍的确定性。 很多时候,你只是拥有了十倍的潜在 bug、十倍的潜在漏洞、十倍的潜在技术债。

代码多了,审查难度指数级上升。 改动更快了,回归风险也更高。 大家交付更频繁了,那些原本就薄弱的工程实践,会更快露底。

我看到一组数据很能说明问题。 Cortex 的一份基准报告里提到,随着 AI 参与更多代码生成,变更失败率上升了 30%。

这个数字的意义,不是“AI不行”。 而是:

当代码生成速度超越组织的验证能力时,系统质量一定会开始下滑。

所以我现在的逻辑很明确:

写代码不再是瓶颈。 判断代码是否该进生产,才是瓶颈。

六、以后最值钱的,不是能写多少,而是能判断什么不该上线

这也是为什么,我对“软件工程会不会死”这个问题,一直没什么兴趣。

因为我的答案很简单:

软件工程不会死。 只是瓶颈换地方了。

过去值钱的是“产出代码”。 以后越来越值钱的,是这些能力:

  • 验证
  • 拆解
  • 架构判断
  • 测试设计
  • 可观测性
  • 回滚能力
  • 技术债管理
  • 风险约束

你会发现,这些能力有个共同点:

它们都不性感。 也不适合拿来做爽文。

但它们真的越来越贵。

我一个做 SRE 的朋友之前跟我聊,说 AI 这么强,以后 AI 审 AI,自测自修,测试和运维这种辅助岗位是不是会被削弱。

我的判断刚好相反。

这类岗位不会变轻。 它们很可能会变得比以前更重要。

因为代码越便宜,系统越需要约束。 执行越自动,回滚越重要。 变更越频繁,可观测性越是底座。

很多团队过去工程纪律不够严格,还能靠“写得慢”苟住。 以后如果还这么干,只会死得更快。

七、真正危险的,是初级工程师的成长路径正在断裂

写到这里,我真正有点担心的,其实不是资深工程师。 而是新人。

因为这一轮变化,会顺带打断一条旧时代默认存在的成长路径。

我自己也是从最基础的 CRUD 做起的。 先写简单接口, 再碰复杂业务流程, 再踩线上 bug, 再经历几次生产事故, 一点点长出那种“我大概知道什么是对的”的直觉。

这个过程,说白了并不优雅。 甚至很笨。

但它有用。

因为很多真正值钱的工程判断,不是看书看来的, 是一次次踩坑、回滚、补救、复盘里磨出来的。

问题来了。

当 AI 接管越来越多机械编码、重复接口开发、基础实现工作时, 新人原本赖以练级的那条路,正在变窄。

旧体系里,一个初级工程师可以先通过大量低风险编码工作,慢慢进入真实生产系统。 在这个过程中,逐渐学会:

  • 怎么拆任务
  • 怎么做边界判断
  • 怎么写测试
  • 怎么看日志
  • 怎么排查问题
  • 怎么处理技术债
  • 怎么理解架构约束

但现在,很多公司已经开始默认: 这些能力你最好一上来就有。

这就很残酷。

因为旧的培养体系正在失效,新的培养体系还没有真正长出来。

这中间会发生什么?

我的判断是:

初级工程师的培养路径,正在断裂。

资深工程师会更像“系统驾驶员”。 而新人很可能连上车拿方向盘的机会都更少了。

这不是一句“年轻人要更快成长”就能解决的。 因为成长需要场景、权限、试错空间和真实反馈。

如果这些低阶入口都被 AI 吃掉了, 新人靠什么长出工程直觉?

这是我觉得接下来行业必须正视的问题。

八、未来的软件,大概率会越来越像一种结构:高自主执行 + 概率守门

如果把这篇文章收束成一个更大的判断,我会这么说:

未来更多软件,都会采用“高自主执行 + 概率守门”的结构。

Agent 先干活。 系统先放行大部分低风险操作。 高风险、偏离预期、超出授权边界的动作,再由分类器、策略引擎、测试结果、沙箱规则、人类兜底一起守门。

这其实是一种新的默认交互。

不是所有事情都问你。 而是大多数事情默认推进,少数真正异常的事才打断你。

从用户体验上,这很顺。 从工程现实上,这也更可扩展。

但这也意味着另一件事:

未来系统可信度的核心,不再取决于它会不会生成。 而取决于它有没有一整套像样的验证、约束和回滚机制。

写得快只是表面繁荣。 守得住,才是底层实力。

所以我最近越来越不关心“哪个模型又多强了”。 我更关心的是:

  • 它怎么验证自己的输出?
  • 它怎么约束高风险动作?
  • 它出了问题怎么撤回?
  • 它的授权边界怎么定义?
  • 它的可观测性和回滚机制有没有跟上?

这些问题,才是接下来软件工程真正的水位线。

九、什么会贬值,什么会升值

如果一定要把这个变化讲得再直接一点,我会这么分。

会加速贬值的能力

  • 机械编码
  • 重复性接口开发
  • 低判断密度的实现工作
  • 只会按需求单写代码的执行型能力

会提前升值的能力

  • 验证能力
  • 问题拆解能力
  • 架构判断
  • 测试设计
  • 可观测性建设
  • 回滚和故障处理
  • 风险约束
  • 对线上结果负责的能力

说到底,未来更值钱的人,不一定是写得最多的人。

而是那种在项目临上线前,能稳稳说出一句:

“这个能发。” 或者 “这个不能发。”

而且他知道自己为什么这么判断。

这个能力,靠嘴是装不出来的。 也不是盲目自信就算数。

它背后要的是经验、直觉、纪律、系统感,还有很多次真正承担后果之后留下来的重量。

十、我最后的感受,其实有点复杂

一方面,我确实觉得这波变化很兴奋。

你能明显感觉到,软件生产方式正在发生结构性改变。 以前很多笨重、低效、明知道有损耗但没办法的环节,现在终于开始被重写。

但另一方面,我又有一点说不上来的复杂。

因为每一次“效率革命”,都不会只带来红利。 它也会重排人的成长路径、组织的责任边界,甚至工作和生活之间那条脆弱的线。

代码以后可能在手机上都能发。 Agent 可能在远程沙箱里 24 小时跑。 你随时都能让它修个 bug、改个配置、发个补丁。

听起来很酷。

但有时候我也会想:

当“离开电脑”都不再构成边界的时候,什么还能帮我们守住边界?

这个问题,可能还没有答案。

就像“旧的培养体系失效了,新的体系还没来”一样。 很多变化已经发生了, 但我们对它的组织准备、职业准备、心理准备,其实还远远不够。

我现在越来越觉得,AI 时代的软件工程,真正的底牌已经翻过来了。

写代码,正在变成最不稀缺的环节。 真正稀缺的,是约束系统、判断风险、承担后果。

至于这会把工程师、产品经理、测试、运维、SRE,最后重新洗成什么样子。

我也还在看。

但有一件事,我现在挺确定的:

以后最值钱的,不是你能写多少。 而是当系统越来越自动的时候,你还能不能稳稳守住那个“不要出事”的底线。

参考资料: 1. Anthropic:Claude Code auto mode: a safer way to skip permissions https://www.anthropic.com/engineering/claude-code-auto-mode

2. Cat Wu 关于 Claude Code Auto Mode 的发布动态 https://x.com/_catwu/status/2036852880624541938

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2026-04-01,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 靖扬 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档