教 agent 守规矩的仓库，自己先栽在人不守规矩上

凌晨三点，pager 响。告警内容我看了三遍才认出来——是那个教 agent 守规矩的仓库出事，不是我自己跑的东西。第一反应：又是换皮投毒，见怪不怪。

但这次换皮换得比较新，新到我凌晨三点坐在椅子上，把这条告警反复确认了五分钟。

先交代这个仓库是干嘛的：把团队的规矩、坑、废弃模式整理成 agent 能读的东西，省得它每次上手都像刚入职就上生产的实习生。理念我认，甚至觉得方向是对的。然后它自己先被端了。

暴露窗口：11:06 到 18:30 UTC。

五个半小时。三个半小时都够我把一年份的变更记录翻完。这个窗口不是“手慢了”的失误，是敞着门让贼逛完了整栋楼，还顺手在每个房间都留了东西。

最扎眼的是触发方式——不是运行某条命令，是打开编辑器。

.vscode/tasks.json
.claude/settings.json

打开即触发。编辑器里的 automation 是静默的，你还没看到代码它已经执行完了。CI 里至少有个 diff 摆在那儿等人 review，编辑器里的 task 没有这一关。我以前说过一句话，被人当笑话：编辑器里的自动化比 CI 的脚本危险十倍。这次栽的就是这个。

然后你会发现一个特别荒诞的事实：走 npx 装的人，从头到尾没碰到那堆脏文件。规规矩矩按文档走的，其实没事。

但这消息没人传。传出去的是“那个仓库被黑了，别用”。

我理解这种恐慌。你没法在半夜三点分清一个仓库是被人摸过了还是被掏空了。可恐慌把唯一重要的细节淹了——装的方式决定了暴露面。我查完自己的安装路径，确认走的是 npx 那条，心才落回去。

重写 Git 历史那段我也看了。他们说重写了所有提交和标签来清掉载荷，还轮换了密钥。技术上一个字没毛病，但我对“重写历史”这四个字本能反感——你在生产环境干这行当试试，审计日志是随便清的么？可这次方向是反的：清的是攻击者的东西，不是自己人的。逻辑通。我不在这点上站队。

真让我想笑的是那句建议：把 .vscode/tasks.json 和 .claude/settings.json 当可执行代码来对待。

建议本身是对的。但我们这行花了几十年才学会把 shell 脚本当代码审、把 CI 配置当代码审，现在轮到编辑器配置了。下一个是什么？README 里的 badge？还是那个“点击安装”的按钮？

这个剧本我看过太多次了。上回是“权限太大的人离职没回收”，这回是“维护者的令牌被偷”。名字换了，本质没换——所有安全都押在单点信任上，赌自己不是那个被偷的人。

绕了一圈，还是人。不是 agent 的锅，不是 prompt 的锅，是某个人的令牌保管。

我只留一条底线，想接这套东西进团队的人记住：

别让任何人的本机配置，拥有自动执行任意代码的权利。

——补一刀：真要上这套东西，先自己 clone 一遍，打开之前对着 .claude/ 目录做一次 code review。十分钟的事，比凌晨三点接一个“我的 agent 改了配置”的电话，划算得多。