当 Cursor 开始疯狂执行 “echo .”：我们真的准备好把商业软件交给 AI Vibe Coding 吗？

今天早上发生了一件让我警觉的事情。

我在用 Cursor 做 vibe coding。
写完一段功能后，我让 Cursor 帮我总结一下上午完成的代码，并生成一份文档。

本来只是一个再普通不过的需求。

结果——

Cursor 开始不断请求执行一个命令：

echo .

而且不是一次，是连续多次。

我强制停止了几次，它依然“顽强”地继续发出执行 echo . 的请求。

那一刻，我突然意识到：

我们是不是正在把商业软件的控制权，交给一个我们并不完全理解的系统？

---

一、这不是 bug，而是信号

很多人可能会说：

“这就是个小问题。”
“AI 有点卡住了。”
“再重启一下就好了。”

但真正值得思考的不是这个现象本身。

而是：

• 为什么模型会陷入循环？

• 为什么它会持续执行无意义命令？

• 如果不是 echo，而是删除文件呢？

• 如果是在生产环境呢？

当 AI 具备执行命令、修改代码、操作文件系统的能力时，它已经不是“辅助工具”，而是“半自动执行代理”。

而我们是否真的建立了足够的边界？

---

二、Vibe Coding 的风险被严重低估

现在一个很流行的趋势叫：

vibe coding —— 跟着感觉写代码，快速迭代，让 AI 帮你完成大部分逻辑。

确实很爽。

效率爆炸。

但问题是：

AI 生成代码的速度，远远大于人类审查的速度。

这意味着：

• 代码产出是指数级增长

• 审查能力是线性增长

• 风险积累是隐性的

当一个团队的 KPI 开始是：

每日 token 消耗量

那就更危险了。

如果“消耗 token”成为效率指标，
而不是“通过测试的稳定交付”成为指标，

那软件工程就会失衡。

---

三、责任如何界定？

这是一个非常现实的问题。

假设：

• AI 写的代码上线后导致数据损坏

• 造成用户隐私泄露

• 或金融计算错误

责任归谁？

AI吗？

显然不可能。法律上 AI 不是责任主体。最终责任永远是：

• 发布产品的公司

• 审批上线的人

• 技术负责人

所以问题变成：

你是否建立了审计和测试机制？

如果没有，那不是 AI 的问题，是治理的问题。

---

四、AI 写代码 ≠ 可以跳过工程纪律

在传统软件工程中，我们强调：

• Code Review

• 单元测试

• 集成测试

• 安全扫描

• 发布审批

但在 AI 时代，很多团队正在无意识地做一件事：

用“效率”替代“纪律”。

当代码 70% 是 AI 生成时，

你还在逐行审吗？

还是默认“看起来差不多”就合并？

今天的 echo . 只是一个无害循环。

但它提醒我：

AI 并没有理解你在做什么，它只是在概率空间里预测。

当它陷入某种状态时，它不会有“意识”停止。

它不会担心磁盘空间。
不会担心系统稳定。
不会担心你的生产环境。

---

五、AI 时代，审计和测试必须升级

在 AI 大规模参与开发后，审计逻辑必须改变。

不能再依赖：

人工逐行 review

必须转向：

• 自动化 Gate

• 强制安全扫描

• 风险分级机制

• 强制测试覆盖率门槛

• 高风险模块审批签字

尤其当 KPI 是 token 消耗时，

更要有：

代码质量 KPI

否则就是：

生成速度越快，风险累积越快。

---

六、真正的问题不是 Cursor

我并不是要批评 Cursor。

Cursor 很强大。

但工具的能力增强，意味着：

失控风险同步增强。

当 AI 拥有：

• 修改文件权限

• 执行 shell 命令权限

• 重构整个项目权限

它就不再是“IDE 插件”。

它是一个自动代理。

而自动代理必须有：

• 明确的权限边界

• 行为审计

• 执行日志

• 可回滚机制

否则，一次异常行为，
就可能带来不可逆后果。

---

七、商业软件可以交给 AI 吗？

答案是：

可以。

但前提是：

AI 必须处于受控的审计体系之内。

而不是：

“感觉对就上线。”

企业必须回答三个问题：

1. 是否记录 AI 参与比例？

2. 是否对高风险模块进行强制双人审？

3. 是否对 AI 生成代码有自动化安全扫描？

如果没有，

那不是在用 AI 提升效率，

而是在用 AI 放大风险。

---

八、最后的思考

今天看到 Cursor 不停执行 echo . 时，我突然意识到：

AI 不会疲惫。
不会犹豫。
不会怀疑。

但我们必须怀疑。在 AI 时代，真正稀缺的能力，不再是“写代码”。而是：

建立治理结构的能力。

否则，当软件公司把 KPI 设为“每日 token 消耗量”时，也许真正被消耗的，不是 token，而是软件工程的底层秩序。

---

如果你正在使用 AI 进行开发，我真心建议：不要只追求生成速度。先建立审计机制。否则，下一个“echo .”，可能就不是 echo 了。