Vibe Coding 场景与核心难题专题

不适合 Vibe Coding 的场景与核心难题

1. 大型项目、复杂架构（最显著的技术挑战）

问题：长上下文中模型注意力分散，复杂项目理解困难，Context engineering 是挑战。

具体表现：在大型项目中，AI 生成的代码逻辑混乱、出现冗长注释、存在性能问题，导致累积技术债务和隐形成本增长。

案例分析：曾经看过一个开源的自称全程 Vibe Coding 的产品，但是打开代码仓库，发现：逻辑混乱、动辄几百行的冗长注释。这产品未来花在修补上的时间，将远超过开发它的时间。对于 MVP 或小项目，vibe coding 看似是福音。但归根结底，将面临三大隐患：

• 对工具的过度依赖
• 累积的技术债务
• 不断增长的隐形成本

对于非专业人士的 "AI 编程 "，如果是预期未来长期维护的内容，本质上是在为未来埋雷（下面详细说下原因）

解决方案：一个编程问题新开一个会话，避免过长 Context，同时 Vibe Coding 的产品，尽量少的去添加需求、修改代码。

2. Canvas UI 相关（UI 还原挑战的延伸）

问题：画布需求特异化程度强，细节还原困难。

具体表现：修改图形中 Text 的位置和对齐问题时，AI 缺乏大局观，修改方案局部化，需要开发者进一步指导和明确修改方案。

案例分析：在资源管理的一个图表需求上，大模型虽然能够快速生成 "DEMO", 但是在最后 UI 还原的提交过程中，比普通的需求更加难调教和处理。

设计稿如下：

在一些细节上，比如修改的图中 Text 的位置和对齐问题：

• 优势：
  • 可以帮你实现机械劳动（比如下面的一些属性、内容，你知道肯定有，但是一个个修改低效）
  • 能提供修改思路和方法，如果有些属性值不知道，不用传统方法 google
• 劣势：
  • 上下文问题，导致缺少大局观，修改是局部，甚至无法给出正确方案
  • 需要开发者进一步指导和明确修改方案

进一步指导：

最后还是自己编程解决，在这类 UI 问题上，大模型还是无法很好的完成，而且在修改过程中，随着上下文越来越多，大模型注意力分散，可能出现：

• 将已有的、正确的代码修改，导致原本正常功能失去；
• 无法兼顾原有架构，将你代码改成 " 屎山 "，基本实现了需求；

根本原因：视觉生成是 " 涌现 "，UI 还原是 " 约束求解 "，AI 在理解整体 UI 需求方面存在局限。

相关技术细节：类似的问题也出现在生成式需求场景中，如 hover 效果等动态交互，AI 在处理这类 UI 问题时会遇到以下挑战：

1. JSON 是结构化数据，UI 视觉是空间 + 时序 + 感知的综合表达 AI 读取 JSON 本质上是模式匹配，字段、类型、结构相对固定，逻辑可枚举。但 UI 中的 " 阴影效果 "" 动态交互 " 是非结构化视觉语言——阴影不只是 box-shadow: x y blur color;。AI 没有真实的 " 视觉感知系统 "，它只是在学习像素或样式标记的统计规律，难以逆向还原出设计意图。
2. " 还原度高 " 局限于组件级别，系统级视觉一致性需要设计思维 有人做过实验：让 AI 生成一个按钮，准确率可达 90%；但生成一组按钮 + 卡片 + 导航栏，并保持间距、色调、投影风格一致，准确率骤降至 30% 以下 ¹。 原因在于：AI 缺乏全局设计系统意识。它不会自动推演 " 如果主按钮阴影是 8px/透明度 20%，那么卡片阴影应该是多少？" 这类关联规则。
3. 技术瓶颈本质：视觉生成是 " 涌现 "，UI 还原是 " 约束求解 " 当前 AI 擅长基于大规模数据涌现新内容，但 UI 还原是强约束问题——每一个像素都可能被设计规范约束。 这更像是一个逆问题（inverse problem）：从有限的语言描述反推精确参数，本就病态且多解。人类设计师靠的是视觉经验与设计系统知识，而 AI 目前还缺乏这类可推理的视觉常识库。

3. 复杂逻辑修改（最高风险场景）

问题：容易出错，需要持续指导。

具体表现：即使对于简单的逻辑抽离和复用，AI 也可能会错误地修改原逻辑。

案例分析：即使对于一些简单的逻辑，也要非常小心 review。比如让 AI 帮我做简单的方法抽离和复用，他的做法如下图：

乍一看似乎很漂亮，但是犯了致命的错误： 修改了原逻辑

AI 在 handleSendMessage 中，先调用了 plusSessionContent 将用户消息添加到会话中，然后再调用 chat 函数，最后才调用 autoRenameSession。这样在 autoRenameSession 中判断会话内容时，已经包含了新添加的用户消息。但是原始逻辑是应该先判断的。

小结

即使是简单的逻辑修改，也需要非常小心地审查 AI 的修改，防止意外改变原有的业务逻辑。所以现阶段，无论使用多么先进的 AI 工具，我们还是必须对代码 Review, 才是对项目和自己的代码负责。

适合 Vibe Coding 的场景

从前端开发的角度来看，Vibe Coding 在实际应用中存在明确的适用边界，这与 AI 模型的技术限制密切相关，所以要合理利用 AI，在一些场景 Vibe Coding 的确是可以明显提效的。

适合的场景与挑战

1. 生成式需求（AI 更擅长 " 涌现 " 类创作而非 " 约束求解 "）

适用：文档网站生成、Demo 或快速验证网站、小型 SaaS 应用

场景解释：前面已经说过，AI 很擅长 Generate，所以对于一些 Demo、MVP(Minimum Viable Product)、小型 SaaS 工具等等，都是利器，可以在几分钟内搭建完成一个兼顾前、后端的 App 或 SaaS。但从前端开发的角度来讲，它生成的内容一般只能完成 80%，细节和 UI 的调整如前面所说，在多次修改后，除了不一定能达到预期外，还可能让原本正常的代码受到影响。如果不考虑对设计稿的还原，不扣细节和 UI,Vibe Coding 在基础功能实现和基本框架搭建上，无可挑剔。

以下是我使用 AI 生成的实际应用案例：

1. 可视化数学网站

一个用于数学概念可视化演示的交互式网站

2. 数学教学工具

为小学数学教学开发的交互式练习工具

和倍问题练习器

几何平移演示器

3. Clear Sky 天气应用

一个简洁美观的天气预报应用

4. 深夜指南 App

一个帮助用户规划深夜活动的生活工具应用

对于这类内容，Vibe Coding (Cursor) 开发速度非常快，效果非常好，是传统开发效率的 10 倍不止！

5. 明确的、固定算法需求

适用案例：小鲸的需求：日期档位功能修改（如：昨天/3 天/5 天/1 周前）

场景解释：对于这类场景，挑战主要在于需求的明确性，AI 在明确要求下表现良好，对于相对固定的日期、事件、算法、排序等，完成的相当好，可以直接修改 Cursor 完成。

6. 常规漏洞、依赖、API 处理

适用：Monaco Editor 语言支持实现、XSS 攻击防护、依赖问题解决

优势分析：在处理公共库 API、安全漏洞和依赖相关问题时，AI 的知识范围可能比普通程序员更广泛，能够显著节省查阅 API 文档或通用解决方案的时间和精力，从而实现更高效的问题解决。AI 在这些领域具有以下特点：

• 知识广度：AI 训练数据包含了大量开源项目和文档，对各种库的 API 用法有全面了解
• 经验积累：AI 学习了无数开发者解决类似问题的方案，能够提供经过验证的解决方法
• 快速检索：无需手动查阅文档，AI 能快速定位正确的 API 用法和最佳实践

例如在实现 Monaco Editor 语言支持时，AI 能：

• 快速识别所需的配置参数和 API 调用
• 提供完整的语言定义和语法高亮设置
• 避免常见配置错误和兼容性问题

技术挑战：需确保 AI 修复方案的正确性和安全性，避免引入新问题。尽管 AI 具有广泛的知识，但有时可能提供过时的 API 用法或存在安全隐患的解决方案，需要仔细验证。

总结

从前端开发者的实践角度来看，Vibe Coding（如 Cursor）并非万能解决方案，但在特定场景下确实能显著提升开发效率。

优势明显的场景

Cursor 的 Tab 补全能力和项目分析功能在代码生成方面表现出色，特别是在生成式需求、算法实现和 API 处理等场景下，能带来 10 倍以上的开发效率提升。

存在明显局限的场景

受 LLM 自身技术特性限制，在以下几个方面存在明显不足：

1. UI 精确还原 - 视觉设计属于 " 约束求解 " 问题，AI 难以处理复杂的视觉细节和交互逻辑
2. 复杂项目架构 - 长上下文导致注意力分散，容易产生逻辑混乱和技术债务
3. 细节优化阶段 - 从 80% 到 100% 的最后冲刺往往需要大量人工干预

实际应用的思考

虽然可以通过 Agent 设计和工具链来加强 AI 能力，但目前还没有工具能完全解决上述问题。在 " 约束求解 " 类任务中，AI 完成前 80% 的工作后，人工优化剩余 20% 所花费的精力，往往不比直接手工开发低多少。

因此，关键在于理解这些工具的边界，在合适的场景使用合适的工具，而不是指望 AI 能解决一切问题。

Footnotes

1. 参考来源：X.com 上的相关讨论 ↩