Vibe-Spec-Coding——从“写代码”到“表达意图”
哈喽大家好久不见了看了一下上一篇博客的日期居然已经是N月之前的事了……这一年多确实挺忙的工作上各种事情学习上也懈怠了博客就一直没顾上更新。最近稍微缓过来一点又开始捡起一些东西在学如今编程方式不说大家也能知道纯自己手工敲的应该不多了所以还是想学学AI相关的一些知识来顺应潮流。先说一下背景哈我对AI底层的原理其实也不太懂平时就是会使用下Claude这个工具属于“会用但不懂原理”的那种。所以这篇文章不会涉及什么深度学习那些硬核内容主要就是聊聊我最近接触到的一个新概念——Vibe Coding和Spec-Coding。当然接下来计划是学习一些关于ai底层的原理【得先调整心态一步一个脚印踏实的学才行】以应对未来千变万化的ai世界万变不离其宗上张关于AI概念的图先说说我以前的认知以前写安卓嘛就是老老实实敲代码。Java忘了加分号要报错少个大括号要报错NullPointerException更是家常便饭。写个布局文件id写错了、findViewById类型不对应运行直接崩。Gradle配置半天依赖冲突调一上午……我花了好几年才把这些东西记住结果现在AI出来了跟我说“你不用写代码了跟它聊天就行”。说实话一开始我是有点懵的甚至有点抗拒。心想我好不容易学会了这些你现在跟我说都不用写了但工具这东西吧由不得你抗拒。周围越来越多人在用我也试了试发现确实跟我想的不太一样。Vibe Coding是个啥这个概念是2025年提出来的提出来的人是前特斯拉AI总监、OpenAI联合创始人Andrej Karpathy。他管这个叫Vibe Coding中文有人翻译成“氛围编程”或“感觉编程”。核心思想其实很简单用自然语言写代码。贴一张网络的“梗图”这里没有Java、Kotlin、C、C只有人类的语言。。以前我们写代码用的是Java、Kotlin、C这种编程语言必须严格遵守语法规则。现在你直接跟AI说人话它帮你生成代码。举个栗子以前我要写一个数组的求和// 以前得老老实实这样敲 int total 0; int[] nums {1, 2, 3, 4, 5}; for (int num : nums) { total num; } Log.d(TAG, total total);现在我只需要说“帮我算一下1到5的总和”AI就直接把上面的代码生成出来了。再比如写个RecyclerView以前要写Adapter、ViewHolder、布局文件一套下来没个把小时搞不定。现在你跟AI说“帮我写一个RecyclerView的Adapter列表项显示标题和描述”它直接给你生成一套完整的代码。虽然有时候还得自己调一下但大部分样板代码都不用自己敲了。而且它还有一个特点就是你可以用很“模糊”的语言来描述需求。比如你让它“配色不要太俗”、“界面要简洁大气”它能理解这种“感觉”。刚开始我觉得这有点玄但试了几次之后发现确实可以。Karpathy原话是这么说的“这是一种完全屈服于感觉甚至忘记代码本身存在的编程状态。”这个描述挺准确的你确实可以不太管代码本身专注在想实现什么功能上。下面用表格对比一下这两种编程方式为什么以前没有这种编程方式其实原因很简单以前的计算机听不懂人话。你对着编译器说“帮我写个登录页面”它只会给你报错。它只能理解精确的指令比如“定义一个EditTextid是username类型是String……”但现在的AI大模型不一样了它能理解你说的那句话背后的意图。你一说“登录功能注意安全”它会自己推理登录需要用户名密码 → 需要输入框密码不能明文传输 → 要加密防止暴力破解 → 限制尝试次数用户信息要存下来 → 需要本地数据库或后台接口这些不是别人教它的是它自己从你说的那句话里推理出来的。如果它不确定用Room还是SQLite它还会主动问你“用本地数据库还是走网络接口”这就是大模型带来的变化。Vibe Coding能成立背后靠的就是这个。而且它跟以前的“低代码平台”还不一样。低代码平台是在一堆预设好的组件里拖拖拽拽能干什么是被固定死的。但Vibe Coding里的AI是真正理解你想要什么然后自己琢磨怎么实现——一个是“选积木搭房子”一个是“你给我描述个房子我来帮你盖”。它也不是万能的说完好的再说说让我不太放心的地方。我还了解到一个挺有意思的问题——AI 写的代码AI 自己可能测不出问题。逻辑是这样的AI 按某种思路生成了一段代码然后它又自己生成测试用例来验证。但测试用例往往会顺着同样的逻辑走很难发现真正的 Bug。并发问题、边界情况、内存泄漏表面上看都好好的实际上可能藏着雷。有人把这种情况叫“监守自盗”我觉得形容得挺到位的。虽然我目前还没遇到过这种情况毕竟用 AI 写代码的时间还不算长但从它的工作原理来看AI 的“理解”本质上是一种概率预测确实存在逻辑盲区这个提醒对我来说还挺值得留意的。而且虽然写代码的工作量确实减少了但别的事情变多了你得把需求描述清楚这需要你对业务有理解你得把握整体架构不然 AI 生成的东西会乱你得审 AI 生成的代码看它有没有问题你还得自己想测试方案不能依赖 AI 自己测自己所以我的理解是Vibe Coding 没让编程变简单只是把“会写代码”的要求换成了“会想清楚自己要什么”。我目前虽然体会还没那么深但逻辑上我觉得是对的。大型项目怎么办Spec-CodingVibe Coding 还有一个挺明显的问题聊着聊着 AI 就把之前的约定忘了。比如前面跟它说“用Retrofit做网络请求”聊了十轮之后它可能就换成OkHttp直接写了代码风格前后不一致。这在个人项目里还好多人协作的话会很麻烦大家各聊各的最后代码风格不统一标准也不一样。所以有一种升级版的做法叫Spec-Coding规格驱动编程。跟纯聊天式的Vibe Coding相比多了一个“设计文档”的环节。文档写好了AI就不容易跑偏团队之间也有了一致的标准后面改需求的时候直接改文档让AI重新生成就行。其实我们程序员都知道文档重要但以前就是懒得写。现在文档成了生成代码的“原材料”不写不行反而把这个老毛病给治了。还有一个例子我觉得挺有启发的——API 接口文档自动生成网络请求代码。平时我们安卓开发跟后端对接后端会给一份接口文档里面写了 url、请求参数、返回格式。以前我们要自己手写 Retrofit 的 Service 接口、写数据 Bean 类、写网络请求逻辑……一套下来又是大几十行代码。用 Spec-Coding 的思路是这样的先把接口文档喂给 AI让 AI 理解清楚然后直接生成完整的 Retrofit 代码包括数据类、Service 接口、网络请求的实现。后面接口加了新字段只需要更新文档AI 重新生成就行不用自己一个个去改。这个逻辑跟“写设计文档 → AI 生成代码”是一样的——文档即代码。我理解这两种模式的关系是这样的Vibe Coding适合快速验证想法、个人项目、原型阶段Spec-Coding适合多人协作、长期维护的商业项目实际开发中两者也不是非此即彼可以混合使用——先Vibe快速验证再Spec规范开发。这种混合方式就叫Vibe-Spec-Coding。总结这篇文章没有谈怎么用某个具体工具因为我也不太会每个人用的工具也不一样。我觉得更值得聊的是这个编程范式的变化——从写代码到表达意图这个转变还是挺大的。Vibe Coding也好Spec-Coding也好它们本质上都是AI能力的外在表现。真正让这一切成为可能的是底层大模型的自然语言理解和推理能力。所以后面如果有时间我打算接着往下学主要是从基础原理来一步步走进大模型实战的世界加油