# RPSV3-134 第三日复盘 —— 一句「图标已经更新了」，牵出四份同一个符号

> **面向**：UX 团队 / PM 内部分享
> **日期**：2026-09-02（下半场）· **任务**：RPS Link (New) 电源控制的图标来源收口
> **配套**：[design-record §19](../specs/2026-08-31-rpsv3-134-design-record.md) · [首日复盘](./2026-08-31-rpsv3-134-mockup-retrospect-internal-share.md) · [第二日复盘](./2026-09-01-rpsv3-134-layout-and-backflow-retrospect-internal-share.md)

---

## 1. TL;DR

- **总轮次**：一次 owner 通报 + 两次 owner 裁定，AI 侧 3 个 RPS commit + 2 个 DS commit
- **最终交付**：Figma 10 个图标 instance 换源 + 2 处交付层文案同步；DS code 侧电源图标收口；跨库依赖清零
- **核心 process gap 数**：**4**（其中 3 个的形态完全相同）
- **关键 insight**：**这一整天的返工，根因是同一个动作重复了四次 —— 把「没找到」当成「不存在」写进了文档。** 而每一次，写的人都用了和实测结论一样的语气。

一句话概括事故：设计系统里**一直有**那个电源图标，它叫 `Switch`；找的人搜的是 `power`。因为这一个名字，产生了一次跨产品库依赖、一张 review queue 单、一个新造的 code 图标，最后同一个符号在四个地方各存了一份。

---

## 2. Session 概览

**起点**：owner 一句话 ——「Reboot 的图标已经在 DS 里面更新了，你可以引用，我已经手动修改了一张」。

**这句话里有两处必须靠实测澄清的歧义**，而它们的答案决定了完全不同的工作：
- 「在 DS 里面」= code 侧还是 Figma 库侧？（当天 DS 文档明确写着「Figma 侧仍然没有这两个图标」）
- 「手动修改了一张」= 哪一张？（实测是**两张**，同一帧里的 Reboot 和 Power Off）

**最终落地**：
| 面 | 产出 |
|---|---|
| Figma | 5 帧 × 2 = 10 个图标 instance 换成 DS 库组件；UX Delivery 卡与 REFERENCE 卡各一句文案改写 |
| RPS repo | `PRODUCT_INTRODUCTION` §3.4 整节重写 · `design-record` §19（含 8 个子节） |
| DS repo | `figma-component-catalog` 整节订正 · icon registry 去重 · 测试块重写 · divergence 条目关闭 |

---

## 3. 时间线 / 主要迭代

| # | 阶段 | 触发 | 改动量 |
|---|---|---|---|
| 1 | 实况勘察 | owner 通报 | 只读探查，推翻 DS 两条记载 |
| 2 | 摆出后果并提问 | 发现两个图标只差一个小圆点 | 1 次 AskUserQuestion（owner 知情后维持原决定） |
| 3 | Figma 侧执行 | owner 裁定 | 10 个 swap + 2 处文案 + 1 处自引入缺陷修复 |
| 4 | 文档回流 | 硬约束 | RPS `66f4bea` + DS `b36a5769` |
| 5 | code 侧收口 | owner 第二、三条裁定 | DS `098a2d2f`（含与并行线 rebase） |
| 6 | 订正预测 | 并行线实测证伪 | RPS `049e0c5` |

---

## 4. Top 4 process gap（按返工成本排序）

### G1 🔴 把「没找到」写成「不存在」——同一形态出现四次

| # | 断言 | 实况 | 代价 |
|---|---|---|---|
| 1 | 「DS 库没有电源开关符号」（644 icon 全量枚举） | `icon/Setting/Switch` 早在 2025-07-28 就在 | 整条跨库依赖 + review queue #13 |
| 2 | 「Figma 侧仍然没有这两个图标」 | 写下时图标已入库 3 小时 | 差点让本轮走错方向 |
| 3 | 「所以要在 code 层定义一个」 | code 侧已有两份 | 多造了第四份 |
| 4 | 「等下次 sync 就能补上 nodeId」 | 实测跑绿也补不上（管线自指） | 留下一条错误指引 |

**共同点**：四条都是**推断**，却都被排版成和实测结论一样的语气。**没有一条在写下时被标记为"未验证"。**

### G2 🔴 全量枚举挡不住「名字与语义无关」

DS 文档早就写着「关键词搜索会漏 ⇒ 必须枚举发布目录全集」。这次**枚举了 644 个，仍然漏**。

机制：枚举产出的是**名字列表** → 候选靠**看名字联想语义**挑 → `Switch` 联想不到电源 → 它进不了候选池 → 而渲染核实**只作用于候选池**。

⇒ **枚举解决的是取数范围，解决不了名字与语义无关，这是两个独立的失败面。**

### G3 ⚠️ 自己设计的对照，取样取在了不会变的那一段上

改双语文案时，我改前做了 snapshot、改后做了比对 —— 但 snapshot 只取了 `segs[0]`（英文段），而丢失的是 ZH 段的 fill opacity。**对照因此结构上恒等，看不出任何异常**，最后是闸抓到的。

而且闸只报了 1 处，**实际中了 2 处** —— 第二处在闸的扫描面之外。

### G4 ⚠️ 并行线的「待 owner 拍」文字，在裁定落地那一刻变成错误指引

并行 session 写下「⛔ 不要用 `setting/power-off`，用 `setting/switch`」——当时完全正确。owner 裁定后，`power-off` 恰恰变成了正确写法。**谁拿到裁定，谁负责把那些文字一起改掉**，不能只改自己动过的文件。

---

## 5. 高效对话建议（按 ROI 排序）

**给 UX / PM 提需求方**

1. **通报改动时给出范围，别给数量** ——「我改了一张」实际是两个图标。AI 必须靠全量扫描才能得出真实待办面；如果它信了口述数量，就会漏。说「我改了默认态那一帧的图标」比说「我改了一张」有用得多。
2. **「已经更新了」要说清楚更新在哪一层** —— 设计系统同时有 Figma 库和 code 库两条链，同一句话在两条链上意味着完全不同的工作。

**给 AI 协作流程**

3. **允许 AI 在执行前把后果摆出来，但别让它替你决定** —— 本轮 AI 发现两个图标在 16px 下几乎无法区分，附 SVG 证据 + 可区分备选后提问；owner 知情后维持原决定。这条被记为「已知代价的设计决定」，下一轮就不会有人再把它当 bug 去"修"。**知情后的决定，和没人发现的疏漏，代价完全不同。**
4. **让 AI 报告「我自己引入又抓到的问题」** —— 本轮有一条（ZH 段透明度丢失）。这类自曝比一份全绿报告更能说明验证是真的在跑。

**给 review 方**

5. **看到「全量枚举过了」不要当成穷尽** —— 问一句「候选是怎么挑的」。这次的漏，漏在挑候选那一步，不在枚举那一步。

---

## 6. 已回流的规则

| 规则 | 真源 | 简述 |
|---|---|---|
| 判「库里有没有某语义的图标」要比 **path 指纹**，不比名字 | DS `figma-component-catalog.md` | 对 643 个 icon 常量算长度+校验和，几秒暴露重复 |
| 「全量枚举」与「名字↔语义」是两个独立失败面 | DS `figma-component-catalog.md` | 补了前者不等于补了后者 |
| 电源图标的正确取法（Figma / code 两侧） | DS catalog + RPS `PRODUCT_INTRODUCTION` §3.4 | 含已知代价的形状决定 |
| 「等 X 之后就会 Y」是预测不是结论 | RPS `design-record` §19.8 | 要么当场测，要么显式标注未验证 |
| 跨进程双侧自证（Figma 侧算校验和 → 落盘侧重算） | RPS `design-record` §19.8.1 | 挡的是「从工具输出手抄进代码」这一步，无闸覆盖 |

**⏳ 仍待 owner 决定（已登记，不在本轮范围）**：手工层与派生层各留一份同一个 ⏻（4 → 2）；`Figma → code` 自动通道对**新增**是关闭的（DS INFRA-F145）。

---

## 7. Model 选型

本轮全程 Opus 5。判断依据：任务表面是"换个图标"（看起来像 Haiku 级别），实际需要在**四份重复资产**里判断哪份是权威、识别并行线推荐与其自身约束的冲突、并在 rebase 时决定保留谁的叙述。**这类"表面简单、判断密集"的任务，是最容易被错误降级的一类。**

---

## 8. 给团队的 action items

1. **DS 库的图标命名**：`Setting/Switch` 是电源符号、`Setting/Standby` 是月亮+Z（睡眠）、`load/refresh` 是循环箭头 —— **三个名字都不会让人联想到实际语义**。建议下次库维护时给这类图标补语义别名或 tags，否则同样的漏还会发生。
2. **消费产品侧**：要电源图标就用 `setting/power-off`（code）或上表两个组件（Figma），⛔ 不要再订阅 `Config T ( Local UI )`。
3. **PM/dev 交接**：Reboot 图标的形状已从循环箭头改为 ⏻+小圆点，与 mockup 一致 —— 这是 owner 知情后的决定，dev 按 mockup 实现即可。

### 附录 · use_figma 改动统计

| 类型 | 次数 |
|---|---|
| 只读探查（结构 / 属性 / SVG 导出 / 变量解析） | 6 |
| 写操作（`swapComponent` ×10、文案 ×2、fill 修复 ×2） | 3 |
| 截图亲验 | 9 |
| 机检（conformance 全文件 / Section / 按钮级 / 规则级） | 7 |