F3.11.1organizational emphasis accumulation设计
多个团队各自为其功能争取强调会累积成全局强调
别名: 强调累积 · 多团队抢注意 · tragedy of the attention commons
概念解释
增长要角标，市场要顶栏活动，运营要红点，法务要黄条声明，客服要把「联系我们」做成第二条主色按钮。每一项单独拿出来都合理：那一队的指标确实靠「被看见」。拼到同一首页上，一年后首屏有四条色带、三枚角标、两个动效。全局强调是分队决策加总出来的，不是某一屏的作者把所有字加粗。单作者通胀发生在一次排版里；这里的账本跨季度、跨团队，每一笔入账时页面都「只多了一点」。
机制
注意是公共池，强调权在组织里却是私有的：各队只优化自己功能的曝光，不承担池子被抽干的成本。每一次评审只看新增这一块「够不够显眼」，不看这一块进场之后全页还剩多少对比。局部理性加总成全局饱和。和单屏把旋钮拧到头不同，这里甚至可能没有一个「拧过头」的人，每个人都只拧了一点。累积的可见形式是手段种类变多（角标+色条+动效+第二条主色），而不是同一手段被同一作者用在每个块上。要看见它，得按时间轴数「谁在哪个月加过强调」，而不是盯着当前这一帧的审美。
边界
新功能上线当周的临时强调（新功能提示）如果有自动撤下的日期，不算累积。没有撤下日期的「临时」才会留下。平台级系统状态（全站故障条）有权打断，不跟产品功能抢同一预算——但产品功能不得冒充系统状态。只有一两个作者的小产品几乎走不到这条组织机制，那里的满屏响更可能是单屏通胀。
怎么落地
- 给首页、工作台这类公共页建强调台账：日期、提出团队、手段、承诺撤下日。没有台账就无法证明「不是我加的那一条」在加总。
- 新需求只许回答「进场时让哪一条已有强调退场」，不许只回答「我们这块怎么更显眼」。
- 季度回顾不是看新功能多不多，是看台账上仍在场的强调条数是否单调上升。
- 验证：从版本记录或设计文件里列出过去两季在该页新增的角标、色条、动效、主色按钮，按团队着色。若三条以上来自不同团队且没有对应的撤下，判定为累积。拿台账开会，当场删或降级其中一半，发一版「只减不增」的页面，比这一版的首次注意集中度；集中度不升，再查是不是减错了对象，而不是把删掉的加回去并再发明一种新手段。