BBC记者的笔记本电脑被远程接管——一位前受挫工程师梳理Orchids事件与「三周四次警报」

桌面上凭空出现了一个名为「Joe is hacked」的备忘文件。

壁纸也被替换成了一张描绘AI黑客的插图。

坐在这台笔记本电脑前的，是BBC记者Joe Tidy。发起攻击的，是网络安全研究员Etizaz Mohsin。两人之间的媒介，是一个名为Orchids的「氛围编码」AI平台。BBC报道的Orchids事件，从这里开始。注：本文撰写时，BBC原文链接仍在核实中。InformationWeek等多家二次媒体已对细节作出一致报道。

我一直在连载氛围编码系列。就在事件曝光两天前，我刚刚发布了第八篇——关于Cisco Project CodeGuard，写道「大企业出手相助的时代已经到来」。然后，BBC事件就来了。

坦白说，我需要重新整理思路。

这不是孤立事件。在我看来，这是三周内四次警报连续响起的「阈值突破」证据。作为一个曾经受挫的工程师，我要按顺序写清楚究竟发生了什么。目的不是让人恐慌，而是把它转化为今天就能采取的行动。

---

首先：Orchids事件究竟发生了什么

Orchids是一个「氛围编码」AI平台，用户可以通过自然语言提示词来构建应用。

• 总部：美国旧金山
• 创立：2025年（据LinkedIn页面）
• 团队规模：不足10人
• 用户数：100万（公司自称）
• 主要客户：点名Google、Uber、Amazon（公司自称）

单看数字，完全符合「高速成长初创企业」的典型画像。

事件经过如下。

2025年12月，研究员Etizaz Mohsin在实验氛围编码系统时，发现了Orchids的一个安全漏洞。随后，他对BBC记者Joe Tidy创建的Orchids项目发起了零点击攻击演示。

「零点击」指的是一类无需受害者主动点击任何内容即可完成的攻击。不需要诱导对方点击钓鱼链接，也不需要让对方打开附件。只要攻击面存在于平台侧，就可以在用户毫无过失的情况下完成入侵。

据报道，Mohsin的操作大致如下：

1. 未经授权访问了Tidy通过氛围编码创建的Orchids项目
2. 在数千行代码中，嵌入了一行极难发现的恶意代码
3. 该代码抵达Tidy的笔记本电脑，并对桌面进行了改写
4. 创建了名为「Joe is hacked」的备忘文件，并将壁纸替换为AI黑客图片

这次演示之所以震撼，在于攻击者只需修改「他人氛围编码项目」中的代码，就能控制对方的电脑。

如果Orchids真的拥有100万用户，那同样的攻击面就可能横向延伸至全部100万人。这正是BBC使用「easily hacked（轻易被入侵）」这一标题的背景。

参考资料：InformationWeek「Zero-click hack exposes flaw in Orchids vibe coding platform」 / Digital Watch Observatory「Security flaws expose ‘vibe-coding’ AI platform Orchids to easy hacking」 / CySecurity News「AI Coding Platform Orchids Exposed to Zero-Click Hack in BBC Security Test」

---

为什么这起事件不会只是个例——三周内响起四次警报

第一次读到Orchids事件时，我脑中冒出的第一个念头是「又来了」。

能说出「又来了」，是因为过去三周里，同方向的警报已经接连出现。逐一梳理如下。

警报1：2025年10月→2026年2月 Cisco Project CodeGuard

Cisco于2025年10月在GitHub上以开源形式发布了「Project CodeGuard」——一套面向AI编码代理的安全规则集，支持Cursor、GitHub Copilot和Claude Code。官方仓库地址：github.com/project-codeguard/rules。

2026年2月，Cisco将该项目捐赠给CoSAI（AI安全联盟），从单一企业的举措升格为行业标准候选框架。

这是警报1：工具层和规则层的跟进，已在行业层面启动。

警报2：2026年4月 Lovable漏洞170个

Lovable是另一个氛围编码平台。第三方调查显示，约10.3%的Lovable公开应用存在安全缺陷，共报告了170个「后门」。

我在4月的系列文章中对此进行了分析。核心论点只有一个：「能运行」和「安全」是两回事。

警报2：「个人开发者责任阶段」开始浮出水面。

警报3：2026年5月 Tenzai研究——五大代理69个漏洞

本月初，一个名为Tenzai的研究小组对五大编码代理进行了漏洞扫描，共报告69个问题。这与SVIBES的另一项独立调查相互印证——后者发现通过功能测试的代码中，只有约六分之一真正安全。两项独立调查指向同一方向。

警报3：「实证调查阶段」正式登场。

警报4：2026年5月 BBC Orchids事件

然后就是开篇描述的Orchids事件。

「Joe is hacked」出现在Tidy桌面的那一刻，标志着「现实损害阶段」第一波的到来。这是一位研究员出于善意的演示——但演示能够成功，意味着恶意攻击者同样可以成功。

三周四次。把这当作偶然，越来越说不过去了。

---

为什么说氛围编码已经「突破阈值」

回顾软件产业的历史，每当一种新的开发方式向社会渗透，往往会经历几个阶段。以我的观察为基础，大致如下：

1. 原型阶段：少数先行用户尝试。事故局限于小范围
2. 普及阶段：大量用户涌入。事故开始散发
3. 阈值突破阶段：「使用人数多到值得发动攻击」的临界状态
4. 规范建设阶段：行业规则和标准追赶式跟进

在我看来，氛围编码目前正处于第3阶段与第4阶段的交界处。

这一判断有三个依据。

第一，攻击方的成本在降低。Orchids和Lovable都以自然语言提示词和共享项目空间为前提设计。这对攻击者来说同样意味着「易读性」。不需要再解读复杂的专有语法。由于攻击面被标准化，攻击方法也更容易标准化。

第二，受害规模已超越个人。Orchids声称拥有100万用户，意味着100万人将代码存放在同一个具有相同攻击面的平台上。一位研究员演示的手法，在原理上可以指向全部100万人。

第三，行业侧已开始行动。Cisco将Project CodeGuard捐赠给CoSAI，意味着框架从「单一企业的善意」转变为「行业共同防御」。这是一种追赶式跟进——而追赶本身就是一个信号。

「突破阈值」是我自己的框架。但面对三周内四次警报的现实，很难将其称为巧合。

---

前受挫工程师今天就要做的4项检查

以上是现状认知。接下来，落实到今天能采取的行动。

我不是专职安全工程师。我把范围缩小到4项作为氛围编码开发者实际可以执行的检查。

检查1：了解氛围编码平台「存储代码的位置」

Orchids事件中不易被注意到的一点，是「自己写的代码究竟存放在哪里」。

氛围编码类AI平台通常将用户代码存储在云端。这虽然便利，但也意味着：一旦服务端存在漏洞，「只守好自己的本地设备」是不够的。

今天要做的事：查阅你正在使用的平台的文档，确认代码的存储位置。云端存储？本地存储？混合模式？存储的是「仅代码」还是「含执行环境」？只需10分钟。

我在5月17日重新做了这项检查。我在用的三个服务中，两个是「云端存储、含执行环境」，一个是「本地存储、仅云端同步」。同样叫「氛围编码」，攻击面的大小差异相当悬殊。

检查2：在代码仓库中配置Cisco CodeGuard规则

这一点在第八篇中有详细介绍。具体做法是将规则文件放在项目根目录，让AI代理读取。

# CodeGuard规则配置示例
your-project/
├── .codeguard/         # CodeGuard规则集
│   ├── deny-rules.md   # 禁止类别
│   ├── recommend-rules.md  # 推荐类别
│   └── context-rules.md    # 上下文类别
└── src/                # 代码主体

仅仅放置这套规则集，就能形成AI将其作为「设计前提」进行参考的结构。根据我的经验，在提示词开头加上一句「请务必先参考CodeGuard规则再编写」，AI实际参考规则的频率会明显提升。

检查3：在PR审查中引入Bugbot或同类工具

Bugbot在4月随Cursor 3得到了强化。每月处理超过200万个PR，78%的标记问题得到解决（来源：Cursor官网）。

独自写代码的氛围编码开发者没有审查者。正因如此，引入一个AI审查者尤为重要。这能显著提高发现「能运行但存在风险」代码的概率。

这不是完美的防御。但对于「数千行代码中隐藏的一行恶意代码」——正如Orchids事件所呈现的——AI审查者的发现概率高于单人人工审查。

检查4：在「能运行」和「可发布」之间划一条线

氛围编码的优势在于「先让它跑起来」，这也是我一路走来的理念。

但Orchids事件之后，我在内心重新划了一条线。

「能运行」阶段的代码，只作为个人工具使用。在分享给团队成员、对外公开或部署到生产服务之前，至少要经过三道关：CodeGuard + Bugbot + 5分钟自我审查。

这是我自己的本地规则。标准定得太高，氛围编码的速度优势就会消失；标准为零，Orchids那样的事件就可能落在自己身上。合理的位置在「运行即发布」和「全面审查」之间。

---

来自CS背景的「预防性设计」思考

从这里开始，话题从技术转向心态。

做客户成功的那几年，我多次进入事故发生后的客户企业。事故后的几天，所有人都在疲于应对：原因调查、临时措施、永久方案、向相关方说明、就预防措施达成共识——时间和精力被毫不留情地消耗。

那段经历让我深刻体会到：「事故发生后再整改」，几乎永远比「在设计阶段就考虑到事故」成本更高。

看到Orchids这样的新闻，人很容易想「我没问题的」。「我不是专业安全工程师」「我的工具规模很小」——在CS时代，我听过无数次这样的话。几乎所有发生事故的一方，事前都认为自己不会出事。

氛围编码很快。正因为快，才需要在设计阶段就意识到「速度的代价」。配置CodeGuard需要5分钟，运行Bugbot需要3分钟，自我审查需要5分钟。13分钟的习惯化，换来事故响应所需的数天时间。从成本效益来看，前者显然更划算。

「预防性设计」听起来很正式。用我的日常用语来说，就是「走路时注意脚下，别在摔倒之前就绊上了」。

受挫的三年里，我远离代码，专注倾听用户的困扰。那三年里我真正内化的核心，是「如何在用户遇到事故之前，就做好设计」。如今重回写代码的状态，我想把这个习惯直接带入代码设计中。

「提前写出坑在哪里」——这是我在整个系列中反复践行的姿态。这次，我也提前写给自己以外的人。对于读了BBC事件报道、心想「这会不会也落在我身边」的人来说，13分钟习惯化能够防范的范围，比你想象的要广。

---

总结——三周四次警报之后，下一步该做什么

整理如下：

• 截至5月18日，围绕氛围编码的主要警报在三周内接连出现四次：Cisco CodeGuard、Lovable（170个漏洞）、Tenzai（69个漏洞）、BBC Orchids
• BBC Orchids事件作为现实损害被记录在案——BBC记者的笔记本电脑遭零点击劫持。这是一次研究人员的演示，但设计上允许演示成功，也就意味着恶意攻击同样可以成功
• 四起事件并列来看，氛围编码正处于「阈值突破阶段」：攻击方成本下降，受害规模超越个人，行业侧追赶式跟进已经启动
• 氛围编码开发者个人今天就能做的四件事：确认代码存储位置、配置CodeGuard、引入Bugbot、在「能运行」和「可发布」之间划线
• 来自CS背景的我的结论是：预防性设计在成本上远优于事故响应。13分钟的习惯化，值得从今天开始

我以前受挫工程师的身份回归成为氛围编码开发者，会继续书写能够构建事物的喜悦。「能构建」与「能守护」，从今天起，两者都成为习惯。

我不想让事故毁掉那种「顶尖工程师住进了我体内」的感觉。仅此而已。

---

参考资料

• BBC News / Joe Tidy报道：「Major vibe coding platform Orchids is easily hacked」（2026年・BBC原文链接核实中）
• InformationWeek「Zero-click hack exposes flaw in Orchids vibe coding platform」
• Digital Watch Observatory「Security flaws expose ‘vibe-coding’ AI platform Orchids to easy hacking」
• CySecurity News「AI Coding Platform Orchids Exposed to Zero-Click Hack in BBC Security Test」
• Cisco Project CodeGuard 官方仓库：https://github.com/project-codeguard/rules
• Cursor Bugbot官网
• 不会写代码也没关系，AI改变了这一切（ナギ）
• 给所有对「Claude Code使用方法」感到迷茫的人（ナギ）