文档教程Vibe Coding示例工程【免费下载链接】vibe-vibeThe First Systematic Vibe Coding Open-Source Tutorial | From Zero to Full-Stack, Empowering Everyone to Build Products with AI | Live at: www.vibevibe.cn 首个系统化 Vibe Coding 开源教程 | 零基础到全栈实战让人人都能用 AI 开发产品 | 在线地址www.vibevibe.cn项目地址https://gitcode.com/datawhalechina/vibe-vibe点击查看免费下载本文是 vibe-vibe 开源教程《Vibe Coding 的能与不能》系列中关于局限性的核心章节。文章围绕 AI 生成代码的实测数据、70% 问题与80% 墙两大概念系统拆解 Vibe Coding 不擅长的五大场景并结合仓库中demo-01-todo、demo-02-todo-auth、demo-03-social-schema三个实战示例用源码证据说明AI 是工具而非魔法边界之外需要人类把守。读完你将建立对 AI 协作的正确预期知道在什么场景该信任 AI、什么场景必须亲自把关以及遇到墙时该如何决策。先看数据AI 生成的代码并不完美在讨论 Vibe Coding 的局限性之前先看一组 2025 年的真实数据。这组数据不是为了吓唬你而是帮你建立正确预期——知道 AI 代码的真实质量水平才能在协作中不盲目、不恐慌数据来源含义45%的 AI 生成代码未通过安全测试Veracode 2025将近一半的代码有安全隐患46%的开发者不完全信任 AI 生成的代码Index.dev 2025专业开发者也保持谨慎过度依赖 AI 导致 bug 增加41%Index.dev 2025不检查就用会出问题使用 AI 工具的开发者实际完成任务慢了19%METR 2025 研究但他们感觉快了 20%最后一条数据特别值得玩味开发者觉得自己变快了但实际上变慢了。这说明 AI 带来的流畅感可能是一种错觉——它打字快、不卡顿、从不抱怨但这些并不能替代代码是否正确、是否安全、是否真的解决了问题的最终判断。这不是说 AI 没用而是说AI 是工具不是魔法。需要你来把关。从仓库的实测工程也能看到这种需要把关的痕迹。例如 demo-01 的待办清单应用里新增待办的数据校验是显式写在代码里的——title非空、最长 200 字、category只能取inbox/work/personal三个枚举值见 validation.ts。这些校验规则不是 AI 凭空感觉出来的而是人类把业务约束写清楚之后AI 才能照此实现。若没有这层把关用户输入任意非法数据时应用的行为就不可预期了。70% 问题AI 能做 70%剩下 30% 要你来Google 工程师 Addy Osmani 在 2025 年提出了一个广为流传的观察AI 可以轻松完成一个项目的 70%——生成样板代码、实现标准功能、处理常规逻辑。但剩下的 30% 才是真正的挑战复杂的业务逻辑、边界情况处理、系统架构决策、性能优化。AI 擅长的 70%需要人类的 30%生成样板代码设计系统架构实现标准功能处理复杂业务逻辑写基础的增删改查优化性能瓶颈套用常见模式处理边界情况快速出原型确保代码安全对照仓库里的示例能非常直观地看到这70% / 30%的分界落在 70% 范围demo-01 的待办清单。它的数据模型只有一张todos表id、title、completed、category、dueDate、order、createdAt见 schema.ts增删改查是标准的 CRUD前端用 TanStack Query 做乐观更新见 queries.ts——这类标准功能正是 AI 最擅长生成的。落在 30% 范围demo-03 的社交网络数据模型。它包含用户、帖子、评论、点赞、关注、标签、帖子-标签多对多关系共 7 张表且点赞表和关注表都依赖联合唯一约束来防止重复数据见 schema.ts。像一个用户对同一篇帖子只能点赞一次这种业务规则AI 很可能想不起来主动加uniqueIndex——这正是需要人类业务判断的地方。对于基础版学习者来说好消息是你做的项目大部分在70%的范围内。待办清单、个人工具、简单网站——这些正是 AI 最擅长的。80% 墙项目做到 80% 后每一步都变难另一个常见现象是80% 墙用 AI 快速做出一个项目的初版很容易但当你想添加更多功能时会发现每增加一个功能都比上一个更难。到了大约 80% 的时候项目会撞上一堵墙。为什么会这样阶段AI 的表现原因0-50%很顺利需求简单代码量少AI 能完整理解50-80%开始吃力代码变复杂AI 开始忘记之前的上下文80%非常困难新功能会影响旧功能AI 难以把握全局这不是你的问题。这是 AI 工具本身的限制——它的记忆上下文窗口是有限的无法像人类一样理解整个项目的来龙去脉。仓库中两个待办应用的对比恰好印证了这一点。demo-01 的 todo 应用源码结构清晰可控1 张表、3 个 API 路由、约 15 个组件见 demos/demo-01-todo 目录结构AI 很容易完整把握。而 demo-02 在加入用户系统后源码规模明显膨胀user、session、account、verification四张认证表加上业务表todos同时todos表通过userId外键与user表关联见 schema.ts。从源码结构看当项目文件数从十几个增长到几十个、表之间出现关联约束时单次对话里的 AI 就越来越难同时看到所有改动点——这正是80% 墙在工程层面的直接体现。Vibe Coding 不擅长的五大场景场景一复杂业务逻辑为什么困难AI 不理解你的业务背景。它能写出看起来正确的代码但逻辑可能是错的。真实例子你让 AI 写一个会员积分系统AI 生成了代码看起来能运行但它不知道你们公司的积分规则有特殊情况满 100 积分送 10 积分、生日当天双倍积分、积分有效期 1 年...结果代码能跑但业务逻辑全错这类隐式业务规则在仓库的社交示例里同样存在demo-03 的帖子统计用子查询一次性算出每个用户的帖子数、评论数、点赞数见 advanced-queries.ts。这类查询本身不难难的是什么算一个有效赞、一个帖子要不要包含被删除评论的计数、关注关系能否双向重复这类需要业务拍板的语义。AI 能写出可执行的 SQL但规则是否正确只有懂业务的人能回答。场景二大型项目为什么困难AI 的上下文窗口是有限的。当项目有几十个文件、几千行代码时AI 无法同时看到所有内容。项目规模文件数AI 的表现小型待办清单1-3 个很好中型个人博客5-10 个还行大型电商网站50 个力不从心会发生什么代码重复AI 忘记你已经写过类似功能命名不一致同一个概念用不同的名字结构混乱没有统一的组织方式仓库中两个 demo 的演进可以作为规模化的参照demo-01 的 API 层只有todos、[id]、reorder三个路由文件而 demo-02 在此基础上扩展出登录、注册、dashboard、profile 等多个页面与认证相关的 API 路由。从目录结构看当项目规模增长到 demo-02 的程度代码组织就必然依赖清晰的目录约定与人工维护的规范而不是指望 AI 每次都能自动保持一致。场景三安全关键功能为什么困难安全漏洞往往藏在细节里AI 倾向于生成能用的代码而不是安全的代码。根据 Veracode 2025 报告86%的 AI 生成代码未能防御跨站脚本攻击88%的 AI 生成代码未能防御日志注入攻击典型问题没有验证用户输入没有正确处理敏感数据使用了有已知漏洞的库仓库对这个场景给出了非常具体的人类把关范例。demo-01 用 zod 为输入建立白名单校验标题必填且不超过 200 字、分类限定枚举值见 validation.ts——信任但验证的第一步就是让非法输入根本进不了业务层。而 demo-02 没有自己手写密码存储逻辑而是引入 better-auth 并挂载 Drizzle 适配器见 auth.ts认证所需的user、session、account表结构也由该框架约定见 schema.ts。从源码结构可以推断在认证这类安全敏感功能上与其让 AI 从零发明一套方案不如让 AI 帮你接入经过大量实战检验的成熟框架——这也正是教程 5.3 安全 强调密钥不要直接写进代码仓库、上线前检查环境变量的原因AI 在这方面需要你来把关。场景四性能优化为什么困难AI 倾向于选择最简单的实现方式而不是最高效的。真实例子你让 AI 写一个搜索功能AI 用最简单的方式实现遍历所有数据逐个比较数据少的时候没问题数据多了比如 10 万条就会变得很慢会发生什么小数据量测试时一切正常上线后用户变多系统变慢你不知道慢在哪里因为代码看起来没问题仓库的 demo-03 专门演示了性能优化的典型决策场景分页策略。同一个取帖子列表需求有两种实现方式——Offset 分页LIMIT 2 OFFSET 0简单直观但大偏移量时性能差、数据变动时可能重复或遗漏Cursor 分页WHERE id cursor LIMIT 2性能稳定、不受数据变动影响但不支持跳页见 pagination.ts。AI 往往默认给出最简单的 Offset 版本而当数据量涨到几十万条时该选哪种策略这类权衡恰恰是需要人类根据业务场景拍板的 30%。场景五调试复杂 bug为什么困难AI 只能看到你给它的信息无法像人类一样追根溯源。简单 bugAI 能帮忙语法错误能明显的逻辑错误能报错信息清晰的问题能复杂 bugAI 很难帮间歇性出现的问题难涉及多个文件的问题难需要理解业务上下文的问题难修了这里坏了那里的问题难仓库里的测试代码展示了复杂 bug 需要系统化排查的正确姿势demo-01 的测试用 vitest 模拟mock数据库模块把路由层的输入输出与真实数据库解耦从而能稳定地复现和验证创建待办返回 201、按分类过滤等行为见 todos.test.ts。从这些测试写法可以推断对付间歇性 bug和跨文件 bug的根本手段是先把问题用测试固定下来、把不确定性抹掉再让 AI 在可控范围内修复——而不是反复追问 AI为什么又坏了。一个形象的比喻Vibe Coding 就像有了翻译软件去国外旅游场景翻译软件表现Vibe Coding 对应点餐、问路完全够用做个人工具、简单网站日常聊天基本够用实现标准功能深入讨论专业话题力不从心处理复杂业务逻辑谈判、演讲几乎不行大型项目、高安全要求翻译软件能让你的旅行更轻松但如果你想在那个国家长期生活、工作还是需要学习语言本身。Vibe Coding 也是如此它能让你快速做出东西但如果你想做更复杂的项目可能需要学习更多编程知识——这正是教程下一节 5.5.3 什么信号告诉你需要学习更多 要讨论的内容。知道局限性不是坏事建立正确预期了解边界是为了在边界内玩得更好。Vibe Coding 的局限性和它的能力一样都是客观存在的事实正确预期AI 生成的代码并非完美45% 存在安全隐患、46% 的专业开发者不完全信任它——这不是新闻而是协作的默认前提不自我怀疑撞上80% 墙时首先要意识到这是工具上下文窗口的物理限制而不是你没天赋明确分工70% 的样板与常规逻辑交给 AI30% 的业务规则、安全把关、性能权衡与全局架构留给自己提前规划当项目从 demo-01 的小体量走向 demo-02 / demo-03 的多表、多文件规模时尽早引入目录约定、数据校验、测试用例与成熟框架为墙的到来做好准备。::: tip 好消息 基础版教程涵盖的内容大部分在 Vibe Coding 的舒适区内。你做的待办清单、个人工具、简单网站正是 AI 最擅长的领域对应能力篇详见 5.5.1 Vibe Coding 能做什么。遇到局限性时不是你不行是工具有边界。这时候要么简化需求要么准备学习更多。 :::本节要点AI 生成的代码并不完美45% 有安全隐患46% 的专业开发者不完全信任70% 问题AI 能完成 70%剩下 30% 需要人类智慧——业务规则、边界情况、架构决策、性能优化80% 墙项目做到 80% 后每增加一个功能都变难根源是 AI 上下文窗口有限五大不擅长场景复杂业务逻辑、大型项目、安全关键功能、性能优化、复杂 bug 调试仓库源码印证demo-01 的校验与测试、demo-02 的认证框架接入、demo-03 的分页与多表业务规则都是人类把关的具体落点知道局限性不是坏事——它帮你建立正确预期在遇到困难时不自我怀疑→ 继续阅读 5.5.3 什么信号告诉你需要学习更多赞分享文档教程Vibe Coding示例工程【免费下载链接】vibe-vibeThe First Systematic Vibe Coding Open-Source Tutorial | From Zero to Full-Stack, Empowering Everyone to Build Products with AI | Live at: www.vibevibe.cn 首个系统化 Vibe Coding 开源教程 | 零基础到全栈实战让人人都能用 AI 开发产品 | 在线地址www.vibevibe.cn项目地址https://gitcode.com/datawhalechina/vibe-vibe点击查看免费下载相关推荐vibe-vibe Vibe Coding 教程不同人群的问题发现指南从痛点观察到五维评分与 MVP 定义vibe vibe Vibe Coding 教程不同人群的问题发现指南从痛点观察到五维评分与 MVP 定义 本篇基于 vibe vibeDatawhale文档教程Vibe Coding示例工程easy-vibe 深度指南从 Vibe Coding 到 Spec Coding让规范文档成为 AI 编程的新代码easy vibe 深度指南从 Vibe Coding 到 Spec Coding让规范文档成为 AI 编程的新代码 Code is a lossy pr教程文档人工智能Vibe CodingVibe Coding革命还是鲁莽放纵——Vibe Vibe 教程视角下的 AI 编程边界与工程纪律Vibe Coding革命还是鲁莽放纵——Vibe Vibe 教程视角下的 AI 编程边界与工程纪律 本文以 Datawhale 开源项目 vibe vib文档教程Vibe Coding示例工程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考