既然 AI 能写诗，我就让它写出 Rembg Pro 的“成都生活方式”。这话听起来像是我在跟 GPT-4 赌气，但事实是，我确实在跟它较劲。我引以为傲的爬虫、自动化脚本，在它面前突然显得笨拙而臃肿。它三行代码能搞定的事，我以前得写一个下午，还得处理各种反爬和异常。这种降维打击带来的不是兴奋，是恐慌。我得让它干点“脏活”，证明我还能驾驭它，而不是被它取代。
这个博客项目，就是我给自己找的“脏活”。不是什么宏大叙事，就是一个记录我如何用 AI 工具解决具体问题的流水账。Rembg Pro 是个背景抠图工具，我想用它批量处理一批产品图，但它的 API 调用有频率限制，而且本地部署版本对显存要求高。我的需求很简单：搞一个能排队、能重试、能自动把结果分类归档的自动化流程。听起来像是我2018年最擅长的那种脚本活儿，但现在，我想用全新的、AI 加持的方式重做一遍。
第一步，数据怎么存？以前我可能直接扔 MySQL 里，建个表记录文件路径和状态就完事了。但现在不行，我得考虑未来可能用到的语义搜索。比如，我处理完一批“咖啡杯”的图片，未来我可能想找“所有白色背景的陶瓷杯”，光靠文件名和标签不够。所以，我决定上向量数据库。我选了 ChromaDB，轻量，够用。
我设计的表结构核心就三块。第一块是 `documents` 表，存元数据：`id`（UUID）、`file_path`（原始文件路径）、`processed_path`（处理后路径）、`status`（pending, processing, success, failed）、`created_at`、`finished_at`。这是基础，跟以前没区别。
关键是第二块，`embeddings` 表。`id`（关联 document id）、`vector`（1536 维的 float 数组，我用 OpenAI 的 text-embedding-ada-002 模型把图片描述文本向量化）、`source_text`（原始描述文本，比如“一个白色陶瓷咖啡杯放在木桌上，背景已移除”）。这个描述文本怎么来？我让 GPT-4 看图片生成，prompt 里严格限制它只做客观描述，禁止任何抒情形容词。这一步消耗 token，但值得。
第三块是 `tags` 表，多对多关系。`id`、`tag_name`（比如“陶瓷”、“咖啡杯”、“白色”、“俯拍”）。标签一部分从描述文本里用规则提取，另一部分我打算后期手动补充，或者训练一个简单的分类模型来打标。这三块数据通过 `id` 关联，查询的时候，既可以按标签筛选，也可以用自然语言描述去向量库里做相似度搜索，找“看起来像”的图片。
设计完这个结构，我坐在电脑前有点恍惚。2016年我死磕 SEO 的时候，脑子里全是关键词密度和外链；2020年带团队，脑子里全是人效和客户投诉；现在，我脑子里是 1536 维的向量空间和 embedding 的余弦相似度。技术栈彻底换血了，但焦虑一点没少。以前焦虑流量不来，现在焦虑学得不够快，怕一觉醒来又有新东西把我这套刚搭好的架子给掀了。
但这就是我的“成都生活方式”吗？不是喝茶打麻将，而是深夜对着 API 文档和数据库 schema，用新工具解决老问题，同时为下一个未知问题埋下伏笔。我把这套结构写进了项目笔记，这就是我们现在这个项目的起源。一个由技能恐慌驱动，用向量数据库和 AI 描述来给图片抠图流程增加“未来可能性”的，极其务实的开端。
