devgo.cn想象你经营一个图标画廊站，为了能让访客按颜色浏览，你这些年手动给一部分图标打了颜色标签：这个偏蓝、那个偏橙。功能很酷——点一下就能看到一整墙同色图标
——但你心里清楚，还有大量漏标的图标。真要人工从 2000+ 个 PNG 里把漏掉的橙色找出来，想想就劝退。
这活儿看起来正适合丢给 LLM（大语言模型）。但直接说“帮我把所有漏标颜色补上”然后盲信输出，不行——颜色判断有主观成分，你得保留最终决定权。所以真正需要的不是让 LLM 替你干完，而是让它帮你造一个工具：计算机快速筛出候选，你来做视觉确认。
这位站长把这个想法跟 LLM 来回聊了几轮。一开始以为要上图像模型，结果 LLM 给了一个更朴素的方案：不要用深度学习，直接做色相直方图（统计图片里各色相区间像素占比的分布）。具体做法是：遍历每个 PNG，跳过透明像素，跳过低饱和度的灰色像素，把剩下的像素从 RGB 转到 HSV 色彩空间（H 是色相，S 是饱和度，V 是明度），然后统计有多少比例的像素落在目标颜色的色相区间里。比如橙色大致对应 15° 到 45° 的色相带。按这个比例给所有没打 `colorId: orange` 的图标排序，就能得到“疑似橙色”的候选列表。
这个思路聪明在：它不追求完美识别，只求把真正需要人看的图标缩小到一个可检查的范围。颜色是连续光谱，边界本来就模糊，与其训练一个模型，不如用可解释的规则先粗筛，再把主观判断交给人类。
于是工具被做成了一个独立的 HTML 页面：左侧列出所有颜色分类，点一个颜色，右侧分成两栏——左边是已经标过这个颜色的图标，右边是计算机认为“可能属于这个颜色但还没标”的候选。页面直接引用 CDN（内容分发网络，这里就是图片存放的远程服务器）上的图片，不需要构建、不需要转译、不需要起本地服务器，双击 HTML 文件用 `file://` URL（浏览器直接打开本地 HTML 文件的地址）就能跑。
最妙的是加了一个阈值滑杆。你可以实时调整匹配的严格程度：滑低一点，候选变多，可能捞出之前漏掉的；滑高一点，候选变少，也会暴露出计算机的误判——“这哪里是黄色？”这种交互让工具真正变成了一个由人做最终判断的筛选器。
是工具运行时的截图，左边是已标注的橙色图标，右边是疑似漏标的候选，一眼就能对比。
确认完之后，选中那些确实漏标的图标，点 Copy 复制 ID，回到聊天窗口粘贴给 LLM，让它批量更新元数据。整个过程不需要写一行“正式”代码，工具用完即弃，真正沉淀下来的是修正后的颜色元数据。
这件事给我几个启发。LLM 写一次性代码的能力被低估了：这种代码不需要生产级健壮性，不需要测试和抽象，只要能在当前任务上跑出结果就行。LLM 也特别适合生成单页 HTML 工具：没有依赖、没有构建步骤，打开即用，对于个人数据整理类任务非常顺手。最值得带走的一点是：与其让 LLM 直接替你决策，不如让它帮你造一个能放大你判断力的工具。人对颜色、审美这类主观标准有最终发言权，计算机负责把候选范围缩到人能轻松看完的大小。
这个思路可以迁移到很多场景：给文章打标签、给图片分类、审核内容、整理本地文件——凡是“机器能粗筛、但需要人做最终判断”的任务，都可以用这个模式：让 LLM 生成一个带交互界面的小工具，把候选摆在你面前，你只做确认和修正。注意别让工具本身变得复杂，保持单文件、零依赖，才能让“用完就扔”的成本足够低。
内容与图片版权归原作者所有 · 原文: https://blog.jim-nielsen.com/2026/use-llm-to-add-color-metadata/