AWS 把 6,544 个没修好的问题摆上了 GitHub

AWS 把一款没人审过代码的模拟器交给了开发者，替人工审查作保的是一份公开的缺陷清单。清单里记着这样一幕：一个只被允许问「我是谁」的角色，新建 IAM 用户的调用成功了。这条问题是智能体自己 10 月 22 日在 AWS Emulator 的 GitHub 仓库里立的，至今没修。

AWS 11 月 11 日发布这款本地模拟器时说，代码全部由智能体编写，团队一行没写、一行没审。它替人把功能测试做成了一大半。

无人审查能成立，靠的是 AWS 把它放在了出错代价低的位置。它不是智能体的代码可以免审进入生产的证据。

三队智能体修掉了 12,708 个问题

据 Matthew Goldberg 在 Amazon 官网的发布文章，这个项目始于一个周末实验：他给 Kiro 一段三步提示词，15 分钟后拿到了一个勉强能用的消息队列模拟。

正式版由三队智能体分工完成：

• 第一队按公开的接口模型写测试，先在真实 AWS 上跑通，记录真实行为；
• 第二队拿这些测试去跑模拟器，按根因把失败归并成问题；
• 第三队一个智能体认领一个问题去修，改动要过一道合并关卡，关卡里有检查编码规范和安全的智能体。

Goldberg 称有数百个智能体同时工作，每天修掉数千个问题。这句没有第三方核对，但修完的记录是公开的。编辑按仓库目录统计，「已修好」的问题文件有 12,708 个，「还不能用」的有 6,544 个，其中 934 个文件名带 stub，指接口还只是空壳。

43% 的测试没过，权限一块整体留白

结果交给打分文件说话。编辑下载了 v1.0.322 发版附带的 scores.json，按原文计算：

项目	数量
测试总数	42,937
与真实 AWS 一致	24,243
不一致	18,614

一致的比例是 56.5%，也就是四成多的测试场景里，模拟器的回应和真实 AWS 不一样。常用服务好一些，按服务拆开，消息队列和 DynamoDB 都在 68% 上下。

最大的空白在权限上。开头那条问题标为高严重度，原文写明后果：每一条最小权限测试都会悄悄通过，生产环境里配错的角色，在模拟器里看起来是对的。

编辑按文件名统计，未修清单里同时带 iam 和 authoriz 字样的问题有 37 个。从 S3 读文件到 SNS 发消息，多数写的都是没有做权限检查。

AWS 没有藏这件事。AWS 的安全文档第一条就是不要用它测安全，列出 IAM 策略、存储桶策略、密钥策略等五类不要测的东西。文档还写明，模拟器从不拒绝用它自己密钥签名的请求。

据 GeekWire 的报道，IDC 分析师 Devin Pratt 对 InfoWorld 指出，它也还不模拟限流、故障和各区域的服务差异。

人没审代码，人划了边界

有人会说，合并关卡里有多名安全智能体做对抗审查，人不读代码不等于没有审查。这一点我们接受：每天数千个修复靠人读本来就读不过来，关卡加公开打分比抽查几行代码更能说明质量。

但关卡守的是「改动有没有让测试变差」，守不了「这款工具该用在哪里」。决定这款工具只用于功能测试、权限不归它管、真实凭证和真实数据不许放进来的，是写安全文档的人。这是分析推断，依据是上面那份文档把五类安全测试整体划了出去，而权限问题在缺陷清单里已经挂了三周。

所以 AWS Emulator 证明的事情很具体：给智能体一份写清楚的规格、一个可以随时对答案的真实系统，它能在无人审代码的情况下造出一个每天都在变好的测试替身。

它证明不了的，是同样的流水线可以把代码直接送进生产。在模拟器里，错了只是一次测试变红；在生产里，错了是一个本该被拒绝的请求被放行。

回到开头那个只能问「我是谁」却建成了用户的角色。智能体写出了让它成功的代码，智能体也写出了指出这是错的问题报告，真正挡住它的是人写下的那句「不要用它测安全」。