为什么我暂时放弃“Genres”，转而押注 AI

Source: Dev.to

Introduction

我最近坐下来为我的图书馆应用构建一个标准功能：分类和流派。这看起来是显而易见的——每个图书馆应用都有流派，对吧？我想能够对我的书籍进行分类，这样搜索“教材”、“计算机科学”或“编程”时就能返回所有相关内容。目标是分类——将属性相似的书籍归为一组，以便更容易找到。

但当我开始绘制逻辑时，遇到了瓶颈。我意识到自己在解决一个根本不存在的问题。

The Problem with Specificity

我跑通了真实场景。假设我的图书馆里有 300 本书，而因为我是软件工程师，几乎所有书都与编程有关。如果我实现一个“编程”流派，然后搜索它，会弹出 500 本书。这样有用吗？这只是噪音。

组织学中有一个原则：组织越多，生产力越低。你可以把分类推到极限，导致混乱或纯粹的繁琐工作。如果我必须手动给每本书打上“Java”或“软件”标签，我真的在让自己的生活更轻松吗？还是仅仅为了做事而做事？

Defining the Real Use Case

我必须停下来问自己：我到底是怎么使用我的图书馆的？

我意识到我并不会“浏览”实体图书馆来获取信息。如果我需要了解 Rust 数据类型，我不会走到书架前去挑选一本看起来合适的书脊。我会去 Google 或询问 AI，找到最合适的外部资源。

一旦我知道需要哪本书，我的问题就非常具体：

• “我有这本书吗？”
• “它在哪里？”

我的主要用例是库存管理，而不是发现新书。

场景： 我在亚马逊或书店看到一本书。
问题： “我已经拥有这本书了吗？”
操作： 搜索 ISBN 或标题。
结果： 是/否以及书架位置。

对于这种工作流，流派毫无关联。我不需要一个“非虚构”标签来判断我是否拥有《Clean Code》。

The Pivot: Organization vs. Search

有一个领域分类是有意义的：实体书架。
现在，我的图书馆是一团乱——一本生物学教材旁边是一本自助书，靠着一本 Java 手册。我最终想要在家里拥有一种“巴诺书店”式的体验——传记放这里，历史放那里，数学放那边。

这就是功能集转变的地方。我不需要为搜索应用提供分类；我需要为整理房间提供分类。即便如此，手动分类仍显得陈旧。为什么我要手动给一本书打上“算法”或“谜题”标签？

The Future: AI‑Driven Shelf Organization

我想用 AI 来进行语义聚类，而不是手动流派。

• 扫描一本书 → AI 根据我当前图书馆的拓扑结构建议它的归属位置。
• 如果我买了一本关于谜题的书，我不想为一本书创建一个全新的“游戏”区。
• AI 可以分析内容并说：“嘿，谜题在概念上与算法相似。你应该把它放在算法书架上。”

这种动态、智能的组织方式正是我所追求的。

The Roadmap Change

所以，我现在需要分类或流派吗？不需要。

然而，我不能在没有组织系统的情况下直接把书籍导入数据库。现在一次性加载 300 本书意味着以后要把它们全部从书架上取下来重新组织，以配合 AI 功能——这是一倍的工作，我想避免。

新计划：

• 暂停大规模数据录入。
• 构建AI 书架组织功能。
• 在把书籍录入系统的同时，让 AI 帮助组织实体书籍。

这已经是一个与我最初设想不同的问题，但它是一个更有价值的解决方案。