我最近在做 ClipKnow 这个产品

原来 ClipKnow 有两大核心功能，一个是剪藏，一个是知识库。当时我直接让 AI 帮我把这两大功能都写完了，速度确实很快。

但是，等我真正上线、试用和部署的时候，就发现问题其实挺多的。

从我这次开发的感受来看，现在大模型写代码，纯技术层面的错误已经没有以前那么多了。很多功能你告诉它以后，它确实能做出来，也能正常运行。

但“能运行”和“真的好用”，其实还是两回事。

AI 能把功能做出来，但不一定符合你的想法

很多问题并不是代码写错了，而是功能细节和交互体验跟我想的不太一样。

因为交互体验这个东西，有时候很难完全描述清楚。甚至我们自己在开发之前，也不一定知道自己到底想要什么。可能只是有一个大概的方向，然后一边使用，一边才会发现这里不对、那里不顺手。

你自己都表达不清楚的需求，AI 当然也很难一次性帮你做好。

而且 AI 一下子写出大量代码以后，如果我想再去细化这些功能，把整个体验做好，工作量和难度其实都会变大。

有些代码我也不知道放在哪里，需要一点点去找。整个产品就相当于变成了一个黑盒，你不知道碰到哪个地方它会崩溃，崩溃以后，也不知道问题到底出在哪里。

我花了一个晚上，才找到网页切片的问题

这里可以讲一个我自己遇到的例子。

ClipKnow 需要把整段网页内容进行切片，处理文章的章节、段落这些内容。

一开始，我只是告诉 AI，我需要实现网页切片这个功能。但是我没有明确告诉它要使用什么成熟的组件，因为当时我自己也不知道市场上有哪些切片的组件，或者说什么方案比较好。

AI 最后确实把功能做出来了。

但是它没有使用目前市场上比较成熟的组件，而是直接用原生的方式，自己写了一整套切片逻辑。

这样就产生了两个问题。

第一个是切片效果没有那么好。

第二个是整个切片逻辑变得非常复杂。因为它需要自己去处理文章的章节、段落和各种内容结构，代码也会越来越多。

发现这个问题以后，我花了一个晚上的时间去理解和寻找它整个切片的逻辑。

我当时就在想，像网页切片这种比较通用的功能，市场上应该会有成熟的组件吧？然后我就去问 AI，有没有已经比较成熟的切片组件。

AI 告诉我，确实有。

于是我让它把原来自己写的那部分逻辑全部推翻，不要再自己处理。我在服务器上部署了一套 Python 项目，专门用来做切片，ClipKnow 直接调用服务器上的 API 就可以了。

其实真正修改代码的时候，AI 改得也挺快。

最麻烦的并不是让 AI 重写，而是我要先发现这里有问题，再去理解原来的逻辑，然后找到更合适的解决方案。

这中间我就在想，像这样的问题，可能还有很多。只是有一些问题我已经发现了，还有一些可能是我现在不知道的。

所以，我们还要不要看 AI 写的代码？

我觉得还是要看。

但这里说的“看代码”，并不是说要逐行读懂 AI 写的所有代码。我现在也不可能再回到以前那种完全手写代码的方式。

我觉得至少要看懂大概的项目结构、关键功能和核心调用链。整个产品在技术上是怎么运行的，主要逻辑放在哪里，这些东西还是需要有一个大概的掌控感。

以前程序员自己写代码，基本上都是心中有数的。

代码是自己一点点写出来的，哪里有什么功能，为什么这么设计，出了问题大概应该去哪里找，自己都是知道的。这其实是一种掌控感。

但是现在 AI 一次性写出大量代码以后，这种掌控感很容易消失。

如果我们完全不去理解项目结构和技术逻辑，只是不断告诉 AI“这里改一下”“那里再加一个功能”，项目可能就会越改越乱。

随着项目越来越大，AI 每次要处理的东西也会越来越多。它最后改出来的结果，可能就不会像你想的那样。后续迭代也可能越来越难，效率越来越低。

所以我看代码，并不是为了自己重新手写，而是为了让我更好地告诉 AI 应该怎么写、应该改哪里。

AI 可以完成 Demo，但商业产品不只是一个 Demo

我现在越来越明显地感觉到，Vibe Coding 一次性完成一个 Demo，基本上没有什么问题。

但是要一次性做出一个可以发布、可以长期使用的商业化产品，还是有难度的。

一个 Demo 在演示的时候，只要能体现主要功能，基本上就可以了。

但是一个商业化产品是真的要给用户使用的。

首先要考虑的是数据安全，然后是稳定性。整个产品要能够完完整整、稳定地运行起来。后续能不能持续迭代，代码能不能维护，这些也都要考虑。

还有一个问题是，AI现在很强，思考问题非常严谨。

严谨当然是好事，但是它有时候也会把功能写得过于完善、过于复杂。为了处理各种可能出现的情况，它会增加很多逻辑和兜底方案。

最后可能功能确实更加完善了，但是整个交互体验反而变复杂了。

所以完善的功能和交互体验之间，其实也要寻找一个平衡点。不是功能越多、逻辑越完整，产品就一定越好用。

我把已经做好的知识库功能删掉了

我现在其实已经在重构 ClipKnow 了，而且我把原来已经做好的知识库功能也删掉了。

主要有两个原因。

第一个是成本。

我在开发环境中试用的时候，发现知识库需要调用一些云端大模型和向量模型。当一个网页剪藏的时候会产生上千个切片的时候，向量模型的成本也不低。

第二个是知识库这个功能其实比较深入。

如果真的想把它做好，需要花大量时间去打磨。这样就很容易出现一种情况：产品一直在开发、一直在完善，但就是发布不出来。

所以我现在想的是，先把最简单的功能做好。

ClipKnow 第一阶段就先把网页剪藏做好。用户可以把网页剪藏进来，高质量地转换成 Markdown，然后可以正常阅读，再加上标签、收藏夹、笔记这些最基础的功能。

先把这些最简单的功能做好，把交互和体验做好，然后尽可能早地发布。

至于后面是自己构建知识库，还是直接同步到其他比较成熟的知识库软件，我觉得还需要更多时间去思考。

一个粗糙的开始，就是最完美的开始

对于独立开发者而言，我一直比较相信一句话：

一个粗糙的开始，就是最完美的开始。

我们做产品的时候，往往只是先想好了一个大的方向，但是很多细节其实没有完全想好。

像 PRD、原型这些东西，独立开发者一般也不会一开始就做得特别细。很多东西还是要在真正开发和使用的过程中，一点点想清楚。

所以我现在更愿意从一个最小、最简单的功能开始，然后一点点往上增加。

在增加功能的过程中，我其实也在不断思考整个产品。哪些功能真的有用，哪些功能没有必要，交互体验应该怎么做，这些东西会慢慢变得清楚。

这样做，整个过程中心智上的压力也会轻松一些。

而且我觉得，最好自己就是产品的用户，或者你能够直接接触到产品的用户。

只有真正去使用，才能得到最直接的反馈。然后一边使用，一边迭代和优化。

还有一点就是，尽可能早地发布，小步快走。

不能花特别长的时间去做一个一直发布不出来的产品。因为越做到后面，整个效率会越来越低。人做事情还是需要一些正反馈，有了反馈以后，做事的效率也会更高。

所以，我现在对 Vibe Coding 的理解是：

AI 可以帮我们代替很多基础的代码编写工作，但是整个产品逻辑、技术架构和交互体验，还是要自己认真思考。

我们不一定要逐行读懂 AI 写的所有代码，但也不能让整个产品彻底变成一个自己看不懂的黑盒。

AI 可以很快地帮我们完成一个 Demo。

但是从 Demo 到一个真正可以发布、可以稳定使用、可以持续迭代的商业化产品，中间其实还有很长的一段路。

大家现在还会去看 AI 写的代码吗？

或者说，你们使用 Vibe Coding 做产品的时候，有没有遇到过类似的问题？

欢迎在评论区留言。