我之前写过一篇《一个人做产品：提出想法》，里面说到一个很具体的问题：我买书买重了。

那时候我的想法很朴素，我想做一个个人图书管理应用。不是为了证明自己有多会做产品，也不是为了追什么新概念，就是我真的遇到了这个麻烦：我不知道家里到底有多少书，不知道哪本书放在哪里，也不知道某本书是不是早就买过。

现在回头看，那篇文章像是一个开头，但后面很久都没有真的把东西做出来。

原因也不复杂。我虽然会一些前端，也做过产品和设计，但要从零做一个真正能用的应用，事情还是比写几页界面麻烦得多。要有数据，要有本地存储，要考虑导入导出，要处理搜索，要处理书架位置，还要考虑发布之后别人能不能用。

如果放在当时，我大概会花很长时间去补后端、数据库、部署这些知识。不是学不会，而是一个人做的时候，每多一个坑，都会让进度慢下来。慢到最后，这件事就很容易变成“我有一个想法”，然后一直停在想法那里。

所以后来我选择了一种更简单的形态。

我当时想的是，先做一个偏 Local First 的东西，也就是本地优先。数据先存在浏览器本地，不急着做账号、服务器和云同步。这个选择对我来说比较省事，因为它把复杂度往后推了。

但现在想想，这个选择未必就一定对。

对用户来说，最先想解决的问题可能不是“数据是不是本地优先”，而是“我怎么最快知道这本书在不在我家里”“它放在哪个格子里”“我会不会又买重”。用户关心的是自己的麻烦有没有被解决，不关心我实现起来是不是比较轻松。

这也是一个人做产品时很容易犯的错：我会下意识选择自己比较容易做的路，然后把它解释成用户也需要。听起来合理，但其实里面有一点自欺欺人。

好在这次，我终于把它做出来了。

现在这个应用已经发布在 shelf.tortorse.com，名字叫「我的书橱」。

它不是什么大产品，也没有多少人用。按之前看到的数据，访问量很少，少到基本可以当成我自己的小工具。但这件事对我来说仍然很重要，因为它从“我想做一个东西”，变成了“我真的做出了一个可以打开、可以录入、可以使用的东西”。

这中间最大的变化，是我开始用 AI 帮我写代码、查问题、补测试、改部署。

如果没有 AI，我应该也能做，但会慢很多。很多过去要靠我一点一点查文档、试错、改代码的事情，现在可以让 AI 先给出方案，我再判断对不对。尤其是一些我没那么熟的部分，比如 Nuxt 的细节、浏览器本地数据库、Cloudflare Pages 的配置，AI 确实省了很多时间。

但这件事也让我更确认另一点：AI 不是你随便丢一句话过去，它就能把应用做好。

如果我不说清楚这个应用到底要解决什么问题，它会自己编一个看起来挺完整的方向。如果我不说清楚代码应该怎么组织，它会写出一堆当下能跑、以后不好改的东西。如果我不告诉它哪些地方不能乱动，它很可能把原来已经能用的代码改坏。

所以我后来越来越不把这件事看成“让 AI 写代码”，而是看成“我带着 AI 一起做一个项目”。

我得先想清楚我要什么。
我得告诉它这个应用是给谁用的。
我得说明哪些地方必须简单，哪些地方可以以后再补。
我还得在它写完之后检查结果，发现不对就拉回来重改。

这和我之前写的那篇 AI 文章里说的东西是一回事。真正重要的不是提示词写得多漂亮，而是我有没有判断标准。没有判断标准，AI 写得越快，我越容易被它带偏。

「我的书橱」这个项目很小，但它对我来说算是一个分界点。

它是我把以前自己写的代码、自己做产品的想法，以及现在 AI 帮我写代码这几件事真正放到一起的第一个项目。它没有完美，但它能用了。

我现在也越来越相信，发布比完美重要。

完美这件事很容易让人拖着不动。总觉得还差一点，还能再改一点，还可以再想清楚一点。可一个应用如果一直不发布，它就永远只是我电脑里的一个文件夹。

发布之后就不一样了。哪怕没人用，它也在那里。哪怕只有我自己用，它也能帮我解决一个真实问题。更重要的是，它会逼着我看到那些真正的问题：哪里不好用，哪里太复杂，哪里其实没人关心。

这比在脑子里反复想有用得多。

所以这篇文章也算是给 2021 年那篇《一个人做产品》补一个后续：我当时说要做一个个人图书管理产品，现在它终于有了一个能打开的版本。

不宏大，也不厉害。

但它是真的。