这两个月开始，工作变得繁忙了，加上天气变凉，在独立开发中投入时间也少了许多。好在还是写完了一个网站工具。随着对独立开发流程的持续维护，我的基础项目数量也到达了 10 个，是时候进行下一个领域的探索了。
最近，我开始意识到工具页的局限性，如果开发完成没有人去使用，就代表这个产品已经死亡了。
于是我开始思考，既然大多数产品的结果必然是沉没，那有没有能够让沉没的工具接力到下一个产品呢？也许，你会说可以建立一个快速启动的项目模板。
我的确有在逐步建立这些东西，但是这也仅仅只是停留在代码层面上的接力，如果要在不同项目让功能接力下去，复制黏贴绝对是最吃力不讨好的一件事。
在思考途中，我想起了自己的 Meta Thief产品。这个工具在原有功能的基础上，还保留了 API 的访问方式，也因比我能顺利的把这个功能扩展到提供给 AI 的 MCP 服务里
所有的产品，都是基础建设，每个产品都能被另一个产品所使用，并且保持最小的侵入性。能做到这一点的，最合适的就是 API 服务了，甚至这在现在 AI 产品的形态下十分常见。
与其做一个可能无人问津的工具，不如让产品同时成为一个更灵活和可能性更多的 API 服务。所以，这之后我在构建的产品时，会开始有意识的预留一个 API 接口。
我的大多数项目主要以链接检查为主，实际上用户传入的只有一个链接，只要我提供一个入口将输入携带在另一个网站跳转链接的查询参数中，两个网站工具就能建立一层单向的跳转关系。
想到这里，我就着手给相似的网站工具增加跳转，把各自独立的工具串联起来，形成一个半封闭的流量循环。
这样的好处是，你不需要为用户提供一个杂乱的网站清单，而是无意识的点击，如果用户不需要随时可以回退到上一页。这或许比在网站的页脚放置一个相关工具，易用性来的可靠的多，因为这是隐式的，没有太多干扰。
如果能借助高访问量的网站带动低访问的网站，这也是个不错的方式。
现在想起来，最开始做的几个工具，没几乎没有一点联系，做到预想的完整功能后，我就没怎么去修改和维护了。
最开始我还只是照着 AI 生成的项目，逐步调整成我想要的结构，慢慢的我发现这些 AI 工具实际上也是从 CLI 中构建完成的项目。那么，我完全可以自己维护一个 next 开发的项目模板，让它拉取项目后在这个结构的基础上进行项目生成，这应该会比我不断对话调整来的好的多。
其实，最开始我有考虑过开源项目的一些模板项目，但是因为这些项目集成了很多东西，使用起来复杂度很高。虽然这对 AI 大模型来说并不是什么问题，但是心智负担还是会回到我这个代码审查者身上。
现在我自己创建一个模板项目，按照需要集成一些简单的功能，就没有前面的担忧了。总之，还是需要对已有项目的代码进行一定程度上的萃取，这样下一个项目维护起来也会轻松一些。
在工作的这段时间，我发现一些需求下，业务因为有 DDL，所以对插件有很大的依赖性，甚至愿意付费去使用一些插件。作为一个前端开发，平时就需要从 uniapp 的插件市场中寻找一些可用的插件来缩短开发复杂度。
值得一提的是，大多数情况下使用这些插件都需要观看广告，或者付费使用，作为开发者的一种激励。
这种形态下的市场，比我想象中的稳定，特别是在某种功能被某个插件独占的情况下，只能选择付费。于是，我开始学习着将工作中的一些功能编写成插件的形式，并开启广告激励，这样我既能够在以后的工作中得到加速，也能完成一部分转化。
实际测试下来，这是有效的，我只是发布了 6 个插件，每月的广告收益显示就有一块左右。也许你会说，这还不如支付宝微信的利息，但是如果发布上百个，也是挺可观的。比起自己琢磨尚未产生收益的产品，另辟蹊径也是一种选择。
不过，uniapp 插件市场的提现限制是 100 元，收益仅保持两年，并会收取一部分提现手续费。所以这种收益应该不能作为收入的一部分，只不过赚一些微信小程序的认证门票费应该是足够的。
既然自己没法马上从零建立起自己的产品，退一步依附在已有产品的生态，之后在扩展出来也是一种不错的选择。
大多数开发者都会经历多个产品的试错过程，在这个过程中很多产品都会被丢弃，包括我也是一样，但这样其实有点可惜，试错的产品本应该成为其他产品的有形资产，不应该只留下开发经验和产品过程这样简单，死去的产品不应该成为故事。
每个大型项目的雏形，最初都源于一个微小的功能需求。虽然原型开发速度很快，但一旦投入时间进行维护和迭代，就需要对产品功能长期规划。
更多的时候，每次开发新产品时，应该像制作零件一样。单个零件本身并不重要，关键是怎么让它在整个设施中开始运作。这可以是项目的 API，也可以一个插件，更可以是独立的 SaaS 服务。
