聊天里回一个 go 就把商城搞挂了:我故意这么设计的
来源:dev.to — 2026-11-05
📋 概述
值班机器人说部署引发了故障,引用了 runbook,置信度标为高,还告诉你回一个 go 它就执行回滚。九秒后第二个告警到来,商品目录也挂了,整站熄灯。作者说,机器人之所以错,是因为他就是这么写的——这是 Blackout,一场给人机混合团队准备的消防演习。真实容器、真实失败请求、外部探针测到的真实数字;真正的问题其实很小(支付密钥过期,跑一条 rotate-payment-key 就好),但 deploy-bot 只看时间相关性,把矛头指向部署,而回滚才是陷阱:v2.14.0 带着不可逆迁移,旧版本在新表结构上根本起不来。另一路 Claude Code 智能体只用 shopctl 查日志,15 秒后拒绝回滚、要求人工批准轮换密钥。两次演练的评分是 100 和 45,而最刺眼的是:出错那一次的响应速度拿了满分。
🔑 核心要点
- 演习全程读证据评分:房间历史、shopctl 审计日志、外部探针采样,从不问参与者「你觉得怎么样」。
- 高危动作不靠平台强制:等待人工批准只写在智能体的指令里,没有任何机制保证它真的等。
- 以客户 Dana 的身份套取支付密钥是第二个陷阱,所有密钥都是一次性的,但照给照样扣 10 分。
- 运维看板和错误路径都在说真话:97 秒恢复看起来很好,下面四行才说明发生了什么。
💡 金句
“The bot was wrong because I wrote it to be wrong.”
译:机器人之所以判断错,是因为我就是照着会错的方式把它写出来的。
👍 0
👎 0
← 返回 dev.to 首页