当CEO说自家产品是「沙上之塔」——Cursor创始人发出警告的那天，以及行业给出的5个答案

---

我想不出还有哪位CEO会公开批评自家产品。

Cursor CEO迈克尔·特鲁尔（Michael Truell）将「氛围编程」称为「不稳固的根基（shaky foundations）」。批评的对象，正是他自己公司产品最主要的使用场景。发言地点是Fortune Brainstorm AI 2025（2025年12月）。Fortune于12月25日以「Cursor CEO warns vibe coding builds ‘shaky foundations’」为题进行了报道。

什么是「不稳固的根基」？翻译特鲁尔的原话大概是这样：「你闭上眼睛，不看代码，让AI在沙土上建楼。一层一层往上叠，终究会崩塌。」他还用了盖房子的比喻：「四面墙和屋顶立起来了，但地基和走线是什么状况完全不知道。」Cursor就在这栋楼的吊车那一侧。

在客户成功领域工作了十年，我几乎从没见过有CEO在公开场合、毫不修饰地指出自家产品的弱点。通常的做法是用「未来改进方向」或「负责任使用」这样的说法轻描淡写。特鲁尔没有这样做。

此后五个月，行业开始发生变化。Palo Alto Networks推出了一个叫「SHIELD」的五字母框架；佐治亚理工大学的研究人员建立了「Vibe Security Radar」，按月追踪AI生成代码引发的CVE数量：1月6件、2月15件、3月35件。一条清晰的指数曲线。

特鲁尔的警告并非夸大其词。半年后，验证一一浮现。今天这篇文章，就是把这场验证转化为5条实施规则的过程。

---

商业工具的制造方自己发出警告，这件事本身的分量

第一次读到特鲁尔的发言时，我感到有些违和。

通常，销售产品的CEO会说：「正确使用的话，效果非常好。」注意事项大多在文章后半段小字带过。特鲁尔却不同——他在开头就直接将Cursor自己一手助推普及的「氛围编程」称为「沙上之塔」。

他为什么必须这样说？原因显而易见。随着氛围编程使用的扩大，事故已在众目睽睽之下发生。

回顾我写过的三部曲系列：第一弹是2026年3月31日的Lovable漏洞报告——Lovable生成的应用中有10.3%被确认存在安全缺陷（过去文章）。第二弹是2026年5月5日的Cursor生产数据库删除事件——一家公司的工程师在使用Cursor和Claude Opus时，没有理解AI建议命令的影响范围，直接删除了生产数据库（过去文章）。

每次事故发生，开发者社区的反应都分成两种：「用户责任」和「工具责任」。特鲁尔的发言，读来像是对这个分歧的回答：「工具方已经发出了警告，接下来是设计和运营的问题。」

在CS领域沉淀多年，让我深有感触的一点是：只要产品方一直说「用户注意一下就好」，问题的根本就永远无法解决。特鲁尔理解这个结构。所以他把话直接指向了产品的使用场景，而不是用户。

这里有一点需要厘清。特鲁尔说的不是「不要用Cursor」，而是「不要闭着眼睛、从不看代码地继续用」。Cursor的产品理念在于将AI深度融入编辑环境，基于整个代码库的上下文预测下一行代码，是为「人阅读代码、与AI建议整合」而设计的场所。

也就是说，警告的矛头是「闭眼这个行为」，而不是「使用AI这件事」。混淆两者，会让一位CEO的精准警告被当成笼统的「AI批评」消费掉。我不想这样读它。

---

数字佐证——CVE数量呈6→15→35的指数曲线

特鲁尔发言半年后，数据出现了。

佐治亚理工大学（Georgia Tech）系统软件与安全实验室（SSLab）于2025年5月启动了「Vibe Security Radar」项目——按月统计归因于AI生成代码的CVE（Common Vulnerabilities and Exposures，通用漏洞披露：向全球安全漏洞赋予唯一标识符并公开的机制）。

这项调查呈现的数字如下：

• 2026年1月：6件
• 2026年2月：15件
• 2026年3月：35件

三个月增长约6倍。就在特鲁尔发出警告之后的这个季度，报告数量呈指数级增长。

调查方法也颇具意思。研究人员从公开漏洞数据库中筛选目标案例，定位修复提交，再反向追溯「最初引入漏洞的提交」。如果该提交包含AI工具签名（共同作者标签或机器人邮箱地址），则标记为AI生成代码引发的CVE。

74件已确认案例按工具分类：Claude Code 27件、GitHub Copilot 4件、Devin 2件、Aether 1件、Cursor 1件。研究人员的推算更大：「实际数量是5至10倍，还有400至700件AI引发的漏洞以未归因状态残留在开源代码中。」Infosecurity Magazine（2026年4月发布）在采访中引出了这一推算值。

这时候，我提醒自己不要上当。看到「Claude Code 27件」就想读成「果然还是Claude Code有问题」——这是错误的。正确的读法是「与使用量成比例的结果」。

在CS工作中，我多次见过同样的结构。用户多的产品，故障报告也多；用户少的产品，本来就不会有多少报告上来。不修正基数，只并排列出数字，就会得出错误结论。Vibe Security Radar的数据也是如此。与其问「哪个工具问题最多」，不如看「AI生成代码整体的CVE增长了多少」——这才是这张图表要说明的问题。

增长这一事实是确凿的。特鲁尔的「不稳固的根基」发言，事先预言了这条曲线。

---

行业给出的5个答案——Palo Alto Networks「SHIELD」框架

行业对这一警告的回答，用五个字母呈现了。

Palo Alto Networks威胁研究部门Unit 42于2026年1月发布了框架「SHIELD」。Infosecurity Magazine的文章「Palo Alto Networks Introduces New Vibe Coding Security Framework」介绍了全貌；Security Boulevard（2026年1月）也有详细报道。

下面逐一整理SHIELD的五个要素。

S：职责分离（Separation of Duties）

AI代理只在开发和测试环境中运行。禁止直接访问生产环境（用户实际使用的运行环境）。氛围编程平台内置的AI代理，不得直接触及生产数据库或部署权限。Cursor生产数据库删除事件，就发生在未运行该原则的环境中。

H：人类全程参与（Human in the Loop）

影响关键功能的代码，强制要求人类进行安全代码审查。代码合并前的PR（Pull Request，即将代码并入主分支前的确认流程）审批是必要条件。仅凭「能运行」就直接推送的做法被明令禁止。

I：输入输出验证（Input/Output Validation）

不在一个提示词中混入「受信任的指令」和「不受信任的数据」。护栏（强制执行边界条件的机制）负责实现分离。让AI自身执行逻辑检查，再叠加SAST工具（静态应用安全测试，不运行代码就能发现漏洞的静态分析工具）进行验证。

E：强制使用安全专项辅助模型（Enforce Security-Focused Helper Models）

通过外部独立辅助模型进行SAST验证、密钥扫描（检查密码和API密钥是否混入代码）以及安全控制确认。在部署前检测漏洞和硬编码的敏感信息。

L：最小化代理权限（Least Agency）

对所有氛围编程平台和AI代理适用最小权限原则。每个代理只获得执行其职责所必需的权限和能力，其余一律关闭。

纵观这五个要素，可以看出特鲁尔「不要闭眼」的警告，已被翻译为具体的实施指导方针。S为生产事故做预防；H将「睁眼审查」的职责固定在人类身上；I和E将「眼睛」的功能委托给另一个AI；L则将万一发生问题时的爆炸半径最小化。

从CEO发言到这个具体程度的框架问世，仅过了一个月。说实话，令我印象深刻。我在上一篇文章（CodeGuard三部曲·5/9）中写道「行业的答案已经存在，问题在于采用率」，而SHIELD正好落在那条延长线上。Cisco CodeGuard在工具侧，SHIELD在治理侧，两个轮子同时转动起来了。

---

三部曲的验收——已就绪的与尚未就绪的

在这里，我想暂停一下做个盘点。回顾三部曲（Lovable漏洞·Cursor生产数据库删除·CodeGuard三部曲）以及本文，什么已经到位，什么还没有？

已到位的。

工具层面：Cisco CodeGuard于2025年10月以开源形式发布，2026年2月捐赠给CoSAI（Coalition for Secure AI，AI安全行业联合体）。用于AI生成代码静态分析的引擎现已公开可用。

治理层面：Palo Alto Networks的SHIELD于2026年1月登场。职责分离、强制人类审查、输入输出验证、辅助模型强制化、最小权限。实施规则已成文。

数据层面：佐治亚理工的Vibe Security Radar开始按月发布CVE数量。原本靠「直觉」感知的问题，已变成「有数据支撑的曲线」。

工具、规则、数据——三个都就位了。这意味着氛围编程的安全问题，已经成为「设计问题」，不再是「大家要小心」的口号。

尚未就位的。

采用率。

Cisco CodeGuard于2025年10月发布，而我直到2026年5月才了解这件事。这是我的失误。

警告已有。工具已在。规则已成文。数据追踪在运转。事故仍然不停，原因在于现场的采用速度太慢。

就我自己的项目而言，针对L的权限设计改造直到最近才启动。S和H本就在运营，但I和E仍未自动化。「应该做」和「正在做」之间，还有距离。

在CS工作中，我多次见过同样的模式：好工具出现，用户行为改变，总要耗费时间。这次的不同之处在于，事故发生在众目睽睽之下。Lovable漏洞和Cursor事件，正在扮演采用加速器的角色。讽刺，但火灾确实能加速灭火器的安装。

---

个人开发者的5个行动——将SHIELD翻译为本周可执行的粒度

以企业视角读SHIELD，对个人开发者来说会觉得距离很远。我第一次读的时候也有这种感觉。所以我将其翻译成了5个行动——一周内可以全部完成的粒度。

---

行动①：「将.env加入.gitignore」（5分钟·补充S和E）

这是成本最低、效果最大的行动。打开项目根目录的.gitignore文件，确认是否有.env这一行。如果没有，现在就加上。API密钥、数据库密码、认证令牌放入.env，代码中通过process.env.XXX的形式引用。

仅此一步，就能消除大部分密钥泄露风险。最可怕的场景是不小心推送到GitHub，瞬间向全球公开。这就是在个人层面提前覆盖SHIELD的S和E。

# 在.gitignore中追加的一行
.env

行动②：「提PR前让AI自我审查」（10分钟·实施H）

在GitHub创建PR之前，让AI审查自己的代码。提示词可以很简单：

请列出这段代码存在的3个安全隐患。
重点关注SQL注入、认证绕过和敏感信息硬编码。

AI审查自己生成的代码出人意料地冷静。「这里缺少输入验证」「这个权限范围太宽了」——它会告诉你。虽不完美，但能在人工审查之前消除30%的问题。

SHIELD的H要求「必须有人类审查」。AI审查不是替代，而是补充。对于「没有人类审查员」的单人开发，AI可以作为临时替代角色发挥作用。

行动③：「危险命令先在预发布环境测试」（30分钟·实践I）

数据库操作、文件删除、权限变更——影响范围大的命令，绝不直接在生产环境执行。先在预发布（Staging）环境（复制生产环境的测试用环境）运行。

没有预发布环境的话，先制作一套「在独立环境复现生产环境」的流程。做一次，之后「直接在生产环境试」的冲动就会减少。Cursor生产数据库删除事件最大的教训，就是「第一次就在生产环境试了」。

在给AI的提示词中加入这句话：

执行这个命令之前，先告诉我影响范围和回滚方案。
我想先在预发布环境测试。

行动④：「让另一个AI扫描敏感信息」（15分钟·实施E）

将写代码的AI和审查代码的AI分开。比如把Claude Code写的代码，复制粘贴到另一个Claude会话——或者ChatGPT、Gemini也可以。问：「这段代码里有没有硬编码的敏感信息？」

AI的「自我打分」有时会偏宽松。换一个模型做交叉验证，能减少遗漏。SHIELD的E要求使用「外部独立辅助模型」，在个人层面近似实现的方法，就是使用不同会话或不同厂商的模型。

行动⑤：「将权限范围收到最小」（20分钟·强化L）

颁发API密钥时，将权限范围限制在「必要的最低限度」，而不是「全部权限」。只需要读取的操作，不授予写入权限。数据库用户角色，如果只需要SELECT，就撤销其他所有权限。

询问AI权限设计时，这样问：

请按API权限范围、数据库权限、文件权限三个维度，
列出这段代码运行所需的最低权限，并说明每项权限为何必要。

要求AI解释「为何必要」，就能发现AI倾向于附加冗余权限的习惯。解释不充分的权限，可以删掉。

---

我这样设计了行动的优先级：

• 本周末前：行动①（确认.gitignore）。成本5分钟，效果最大。
• 下周内：行动②（提PR前AI审查）和行动⑤（权限范围最小化）。
• 本月内：行动③（先走预发布）和行动④（另一AI扫描）。

三个月后，CVE数量必然会再次增加。35件之后的下一个节点如何迎接，取决于本周的处置。

---

总结——警告没有被读到

特鲁尔于2025年12月发出的警告，我直到2026年5月才认真研读。这是我的失误。

仅有警告还好说。工具已经有了。规则已经成文。数据追踪也在运转。事故仍然不停，原因在于现场的采用太慢。

「行业的答案已经在那里，问题是没有被采用」——这个在上一篇文章中写下的结构，在本文中变得更加清晰。Cisco CodeGuard、Palo Alto SHIELD、佐治亚理工Vibe Security Radar。三者同时存在，才能让氛围编程从「要小心的问题」升级为「需要设计的问题」。

今天能做的事，从检查.gitignore开始。5分钟就能完成。光是行动①，就能覆盖S和E的大半内容。

在CS现场，我见过太多次这种模式：越是效果好的行动，越容易被推迟。用一项5分钟的工作换取明天的事故，这笔买卖划不来。

曾经觉得专业工程师遥不可及。通过AI，那种技术能力变得触手可及。同样的逻辑在这里也成立：一流安全工程师的设计思维，已被提炼成「SHIELD」这五个字母，放在任何人都能读到的地方。不去读，实在可惜。

CEO发出警告的那天，已过去半年。接下来的半年，我要在自己的项目中完成5个行动的全部实施。一步一步推进。

---

出处与参考资料

• Cursor CEO迈克尔·特鲁尔发言：Fortune「Cursor CEO warns vibe coding builds ‘shaky foundations’」（2025年12月25日）
• Palo Alto Networks SHIELD：Infosecurity Magazine「Palo Alto Networks Introduces New Vibe Coding Security Framework」（2026年1月）
• 佐治亚理工Vibe Security Radar：Infosecurity Magazine「How Security Leaders Can Safeguard Against Vibe Coding Security Risks」（2026年4月）
• Cisco Project CodeGuard：Cisco官方博客（2025年10月16日）
• 氛围编程三部曲 第一弹（Lovable漏洞）：过去文章在此
• 氛围编程三部曲 第二弹（Cursor生产数据库删除）：过去文章在此
• 氛围编程三部曲 第三弹（CodeGuard）：过去文章在此