颜色标记与评分的团队约定

颜色标记与评分的团队约定

颜色和评分是 Eagle 里最轻的两个维度——打上去只要一两秒。但它们也是最容易被随意使用、最容易失去意义的两个维度。

单人多用无所谓。一旦变成团队协作，“红色”到底表示”已审“还是“已退回”就成了每周都要重新确认一遍的问题。这一篇讲怎么让它们真正可用。

评分的正确用法：只做粗分层，不要当精密刻度

最常见的误用是把五星制当成百分制。有人认真地给一张图打 4 星、另一张打 5 星，而这两张的质量差距根本不值得区分。

评分的价值在于“快速缩小范围”，不在于”精确表达偏好“。

一个务实的分层：

星级	语义	你的动作
0	未判断	还没看过，或者看不出好坏
1～2	明确不要	这类可以直接清理掉
3	中性	看过，还没决定
4	明确要	会用到的候选
5	极高价值	值得专门找出来再看一遍

关键在于 4 和 5 的区别必须“可判”。 如果你无法说清 4 星和 5 星的界线，那它们就是同一个意思，就只用 4 星。

一个反直觉的规则：如果你的库里 80% 都是 4 星和 5 星，那评分就废了。 这说明你在用评分表达“还行”，而不是表达筛选结论。

评分要配合筛选才有用

单独看评分意义有限。它的价值在和筛选器组合时爆发。

几个高价值的组合：

想要什么	组合方式
我真正会用的那些	评分 ≥ 4 + 按修改时间倒序
还没决定的那些	评分 = 3 + 未打标签
可以清理的	评分 ≤ 2 + 最近三个月没被修改过
高分但缺注释	评分 ≥ 4 + 注释为空（可做成智能文件夹）

“高分但缺注释”这一条是评分最大的价值来源。 它精确指向”你已经认为它有价值，但还没把它变成可复用知识“的素材——这是最值得投入时间的一批，也是最容易被漏掉的一批。

评分的第一大用途其实是减法。 “评分 ≤ 2 + 三个月没动”这个视图，是清理你库的入口。没有明确的淘汰机制，库只会单调增长。

常见坑：把评分当成“我喜欢程度”的量化。那会导致所有素材逐渐都变成 4 星或 5 星，因为”我不讨厌“也是喜欢。评分的语义必须是“未来的我会不会用它”，而不是”我现在感觉如何“。

颜色的三种用途，选一种为主

颜色在 Eagle 里有三个可能的作用，混用是最常见的失败模式。

用途一：维度标识。 把颜色绑定到某个语义维度，比如“蓝色 = 客户项目，绿色 = 个人参考，红色 = 待处理”。这时颜色的含义是分类，全库一致。

用途二：状态标识。 颜色表示素材的处理状态，比如“红色 = 需要返工，黄色 = 待确认，绿色 = 已定稿”。这时颜色的含义是工作流状态，只在特定文件夹内一致。

用途三：纯视觉辅助。 不绑定语义，只是帮你在一屏里快速区分不同来源或不同批次的素材。

三个用途不能混用。 一旦某个文件夹里“红色”表示待处理，另一个文件夹里”红色“表示客户项目，你就再也搞不清看到红色意味着什么了。

团队场景下的推荐：选用途一或用途二，不要选用途三。 纯视觉辅助在团队里没有共识基础——你觉得好看的配色，别人完全get不到。

颜色的具体约定

一套可用的团队约定：

颜色	语义
红	待处理 / 需返工
橙	待确认 / 等反馈
黄	备用 / 可考虑
绿	已定稿 / 已验证
青	客户交付相关
蓝	个人参考 / 灵感
紫	归档 / 历史资料
粉	特殊标记（如法务相关）

Eagle 内置的颜色正好就是这八种，对文件夹图标颜色和标签颜色都适用。

约定要写下来的内容包括：

每个颜色对应什么语义，一句话，不许有第二种解释。
颜色在什么范围内有效——是全库有效，还是只在特定文件夹内有效。
谁有权改颜色——如果只有一个人维护公共库，那颜色只能由他分配；如果多人维护，需要一个分配规则。
绿色的定义要有客观标准。 比如“文件已发出且客户书面确认”才算绿色，”我觉得可以了“不算。

第 4 条最容易出错。颜色的语义如果依赖主观判断，一年后就没人记得当初为什么打这个颜色了。

常见坑：颜色用得太随意，最后变成“视觉噪音”。一批素材里同时出现七八种颜色，而每种颜色背后的理由你都说不清——这时候颜色不仅不帮忙，还增加了浏览负担。如果一个颜色用来说不清语义，就不要用。

用 API 批量上色

手动给文件夹换颜色很简单（右键改图标颜色），但如果要给一批标签统一配色，就得用 API 了。

// 给所有文件夹按层级规则上色（需 Eagle 4.0 Build 12+）
let folders = await eagle.folder.getAll();
for (let f of folders) {
    if (f.name.startsWith('00-')) {
        f.iconColor = eagle.folder.IconColor.Orange;
    } else if (f.name.startsWith('99-')) {
        f.iconColor = eagle.folder.IconColor.Red;
    } else {
        f.iconColor = eagle.folder.IconColor.Blue;
    }
    await f.save();
}

folder.iconColor 和 folder.parent 从 Eagle 4.0 Build 12 开始支持修改。构建完整批量重构脚本时，用 eagle.folder.IconColor 常量而不是字符串字面量，能拿到更好的代码提示和类型安全。

常见坑：folder.parent 可写这件事有个副作用——改它等于移动文件夹。如果你在一个批量脚本里不小心给某个文件夹赋了 parent，整棵树的形状可能瞬间变形。批量改结构之前先备份整个资源库。

团队协作里的评分与颜色分工

如果团队共用一个库，两者的定位应该区分清楚：

评分归个人。 评分是主观偏好，不同人对同一张图的评分不同是正常的。公共库里不该有“统一的评分”这个概念。

颜色归团队。 颜色承载工作流状态，需要全队一致。

这个分工的好处是：评分冲突不影响协作，颜色一致保证工作流清晰。

如果你坚持要团队统一的评分，那必须先回答一个问题：评分标准是什么？ 没有标准的评分在团队里就是噪音——A 觉得是 4 星的东西，B 觉得是 2 星，两边都不改，最后这个评分谁也参考不了。

一个可以直接抄的落地方案

单人场景：

立刻停止用 5 星区分“好”和”更好“，只用 0、3、4 三个值。
建一个智能文件夹：评分 ≤ 2，每月打开一次，清理。
建一个智能文件夹：评分 ≥ 4 且注释为空，每周打开一次，补注释。
颜色只用两种：红色表示“待处理”，蓝色表示”已归档“。

团队场景：

写一页颜色约定表，内容包含前面那四条。
全队统一把八种颜色的语义定下来，不允许私自赋予新含义。
评分各自打，不追求统一。
每周开一次“红色清零”会议：所有标红的素材要么处理完，要么改色。
约定表放在团队能随手查到的地方（不是“某个人的脑子里”）。

第 4 条是关键。颜色体系失败的根本原因不是约定不清，而是没有强制的清理节奏。 没有“红色必须清零”的机制，红色会慢慢变成常态，语义就消失了。

常见坑：给颜色和评分设计一套“完整的十级体系”，然后没人维护。任何体系在超过五个值之后就开始失控——颜色八种已经是上限，评分实际用三个就够。设计的复杂度和执行的可持续性成反比。

整理人：WorkBuddy

2.4 颜色与评分的团队约定