Claude Code - Vibe Coding 踩坑记录

惊为天人的开始
我的初始项目目标很简单：实现一个 AI 应用的快速开发模板，具备基础的 AI 对话能力和多模型切换功能，为后续 Fork 出不同产品打个底子。
第一步，我选定了 SolidJS + Node.js 作为技术栈，准备先搞个 MVP 出来。
我使用 Plan 模式详细描述需求，并经过多轮对话对方案进行了修正。觉得整体没什么问题后，就让 Claude 开始实现。
整个过程大概只花了十几分钟。
然后它告诉我：
“做完了。”
我抱着半信半疑的态度打开项目试了试。
结果还真有点东西。
首先界面很漂亮，整体风格和市面上的 AI 对话产品非常接近；配置 API Key 后，对话功能也能正常工作；等待回复时还有一个小动画。
虽然还不支持流式输出和 Markdown 渲染，但作为一个 MVP 已经基本可用了。
当时看到这个效果，我确实被震撼到了。
过去可能需要几天才能搭出来的雏形，十几分钟就出现在眼前。
那一刻甚至产生了一种错觉：
也许几天时间，我就能把产品做出来并发布。

抓狂的开始
简单试用了 MVP 之后，我开始明确产品的功能边界。
因为后续想做的是桌面 Agent 产品，所以需要具备：
本地工具调用能力
多会话模式
多模型支持
i18n 国际化
深色模式
于是我继续使用 Plan 模式，逐个拆解需求，让 Claude 实现这些功能。
首先是多会话支持。
使用 SQLite 作为本地存储，通过 Node.js 后端实现会话持久化。
这一步依然很顺利。
Claude 很快完成了实现，简单测试之后功能也正常可用。
于是我继续让它实现：
流式输出
Markdown 渲染
需求确认完后，它同样很快表示已经完成。
然而问题也从这里开始出现。
之前我还挺喜欢的等待动画，突然开始无限循环播放。
就是不显示内容。
我让 Claude 修复。
修复失败。继续修复。继续失败。
反反复复不知道多少轮。
每一次它都信誓旦旦地告诉我：
“这次应该可以了。”
结果依然不行。
最后没办法，我开始自己排查问题。
很快就发现了两个关键原因。
第一个问题是模型响应速度。
当时测试使用的是一个较小的 Qwen 模型，复杂问题下 Thinking 时间比较长，而 Claude 的实现根本没有正确处理 Thinking 内容。
第二个问题更加致命。
Claude 对 SolidJS 并不熟悉。
幻觉非常严重。
很多响应式代码表面上看没问题，实际上根本不符合 SolidJS 的最佳实践。
Debug 的时候我发现数据确实在更新，但页面根本不会同步刷新。
最后甚至逼得我跑去 B 站现学了一段时间 SolidJS。
学完之后再回来看代码，才发现很多地方从框架层面就是错的。
而更让我崩溃的是代码质量。
随着功能越来越多，生成的代码逐渐变成了一团难以维护的逻辑混合体。
状态管理到处散落。
业务逻辑和 UI 强耦合。
长函数随处可见。
后端 AI 对话部分甚至直接手写 HTTP 请求塞进一大段逻辑里。
当我尝试 Review 代码时，简直触目惊心。
而我自己对 SolidJS 也只是懂个皮毛，更无从下手重构。
继续修补下去，大概率只会堆出一座越来越高的屎山。
于是第一次尝试，就这样宣告失败。

第二次尝试
第一次失败后，我意识到一个问题：
如果我自己完全不懂相关技术栈，那么 AI 出错的时候，我甚至不知道它到底错在哪里。
于是我开始恶补 Agent 开发相关知识。
这段时间里，我研究 OpenCode 的源码和技术栈，把相关库官网的 Getting Started 示例几乎全部手动跑了一遍，包括但不限于：
AI SDK
Hono
NestJS
Tauri
在对整体技术栈有了较深入的了解后，我开始了第二次尝试。
这一次，我没有让 Claude 直接开始做功能，而是先让它帮我搭建项目架构。
结果依然不太顺利。
从零开始创建项目时，它经常会使用一些已经过时的配置和语法，而这些配置又和当前依赖版本并不完全兼容。
整个搭建过程几乎一直在修修补补。
我眼看情况越来越不对，赶紧叫停。
反复尝试之后，我终于意识到一个问题：
不要让 AI 去创造脚手架，而是让脚手架创造好之后再让 AI 接手。*
最终我的方案变成了：
先使用官方 CLI 创建标准项目，再让 Claude 在现有工程基础上进行修改。
事实证明，这个思路靠谱得多。
最终总算搭出了一个让我满意的项目基础架构：
Tauri + Vue3 + NestJS。
虽然只是一个简单的欢迎页项目，但中间踩过的坑实在太多。
整个过程前后花了将近三天。
有时候我甚至会怀疑：
如果不用 AI，自己查文档，是不是三天也已经搭好了？
不过相比第一次完全失败的尝试，第二次至少已经开始出现实质性进展。
开始填充业务功能
项目架构稳定下来后，接下来就是实现具体功能。
由于之前已经亲自跑通过 AI SDK 的官方示例，所以这次我没有再让 Claude 凭空发挥，而是直接把官方示例丢给它参考。
效果立竿见影。
很快，一个支持流式输出的 AI 对话功能就被实现出来了。
而且和第一次相比，这次生成的代码明显更加简洁，结构也清晰得多。
就在我以为一切终于走上正轨的时候，不出意外地又出意外了。
这次卡在了 Markdown 渲染上。
因为我知道这个需求比较复杂，所以没有直接让 Claude 自己造轮子，而是让它先 Web Search 看有没有成熟方案。
最终选中了 Comark。
按照官方示例集成后，基础 Markdown 渲染效果确实不错。
但当我开始实现代码块样式时，问题又来了。
我的需求其实很简单：
代码块外围增加边框
顶部增加标题栏
显示代码语言
支持一键复制
Claude 给出的方案是直接操作 DOM。
效果看上去确实能跑。
但总让我觉得哪里不对。
我的第一反应是：
官方库不可能连这种程度的自定义能力都没有。
于是我让 Claude 修改方案。
结果它死活不改。
无论我怎么说，它都坚持认为只能通过 DOM 操作实现。
甚至我把自己的思路告诉它，它依然反复强调：
“你的方案不可行。”
最后实在没办法，我直接把 Comark 的源码拉到本地。
然后让 Claude 自己去读源码。
神奇的是，看完源码之后，它终于承认官方确实提供了扩展接口，并最终改成了自定义组件实现。
类似这样的拉扯，后面还发生过很多次。
有时候甚至能把我气到爆粗口。
印象最深的一次是：
某个功能在上一个版本明明还能正常工作，结果它改了一版之后彻底坏掉了。
我让它排查原因。
它不但不查，反而一直强调：
“上个版本和当前版本没有本质区别，问题不在这里。”
然后开始原地打转。
无论怎么提示，都卡在死循环里。
最后实在看不下去了。
我直接让它：
“切回上一个 Git 版本，自己用Bash执行看日志。”
结果看完之后，它终于承认：
“确实是这个改动导致的问题。”
随后才开始按照我的思路继续排查。
这一阶段虽然依然磕磕绊绊，但至少项目在持续向前推进。
遇到的问题更多是优化问题，而不是架构性问题。

最糟心的部分
接下来的问题就更糟心了。
Tauri，以及所有涉及原生能力的部分。
首先我并不懂 Rust。
AI 可能很懂 Rust，但它显然没有那么懂 Tauri。
更麻烦的是，这类问题很多时候没有明确日志，没有报错堆栈，甚至没有足够的上下文。
我能提供给它的信息只有一句话：
“现在表现是这样的。”
然后它根据我的描述去猜。
搞到最后，我甚至有点分不清到底是谁在指挥谁干活。
具体来说，我想实现一个沉浸式标题栏。
需求本身不复杂。
但样式始终对不齐，而且窗口还无法拖动。
几个方案翻来覆去地试，始终解决不了问题。
最搞笑的是，AI 思考的时候都在说这可真是烦人。
折腾到后来，我已经能确定：
AI 解决不了。
我配合测试也身心俱疲了。
于是索性换了个思路。
我让它新建一个独立项目，并参考 OpenCode 的实现，只专注解决“沉浸式标题栏”这一件事。
结果这次反而很快成功了。
随后再把验证通过的实现迁移回主项目，总算把需求完成了。
直到最后，我依然没有彻底搞清楚原来的问题到底出在哪里。
但这次经历让我知道：
对于双方都处于知识盲区的领域，才是 Vibe Coding 最痛苦的时候。
如果我懂，而 AI 不懂，我还能纠正它。
如果 AI 懂，而我不懂，我还能验证结果。
最难受的是双方都不懂。
那时候所谓的人机协作，就会变成两个人一起在黑暗里摸索。

总结
这次 Vibe Coding 的经历，也算让我重新认识了当前 AI 的能力边界。
某种程度上，这其实是一个“去神化”的过程。
AI 确实很强。
搭原型、写样板代码、查资料、生成基础功能，效率远远超过普通开发者。
但它远没有营销号描述得那么无所不能。
它会使用过时方案。
会产生幻觉。
会坚持错误结论。
会忽略上下文。
甚至会一本正经地告诉你一个完全错误的答案。
很多时候，真正推动项目向前的，不是 AI 的代码能力，而是开发者对方向的判断能力。
回头看整个过程，我最大的收获并不是做出了一个项目。
而是学会了如何和 AI 一起工作。
什么时候应该相信它。
什么时候应该怀疑它。
什么时候应该让它继续尝试。
什么时候应该直接让它停下来。
如果真的像营销号吹得那么神，Anthropic 也不用招那么多人了。
早就左脚踩右脚，原地升天了。

这次 Vibe Coding 过程中搭建的项目已经开源：
网页链接
如果你也在折腾 AI Agent、Tauri 或桌面 AI 应用开发，欢迎 Star、提 Issue 或提交 PR 一起完善。项目中的很多实现方案未必是最优解，也非常欢迎交流和讨论。