# 协作复盘 — LCD 提示文案总表（从一条 Slack bug 线到设计系统回流）

> 面向 UX / PM 内部分享。记录 2026-08-27 → 08-31 这条线里 AI 与 owner 的协作过程：哪些返工可以避免、哪些做法验证有效、哪些规则已经沉淀。
> 交付物本身的真源在 [`docs/specs/lcd-message-strings.md`](specs/lcd-message-strings.md)，本文只谈过程。

---

## 1. TL;DR

- **总轮次**：跨 3 天、约 25 轮对话。文案讨论 8 轮 → Figma 建页 6 轮 → **owner 走查返工 5 轮** → DS 回流 4 轮。
- **最终交付**：Slack 定稿回帖 · Figma 常驻页 `LCD Message & Toast Strings 20260831`（page `10166:2`）· consumer 真源 `lcd-message-strings.md` · DS 两条新规则（§M53 + 触发器 T）。
- **核心 process gap：4 个**，返工最贵的一个（整页 IA 重构）根因是**我自己写下的产物性质没有约束住我自己选的结构**。
- **关键 insight**：这条线上 **5 轮返工没有一轮是规则违例** —— 机检从头到尾零新增 findings。返工全部发生在「规则管不到的地方」：信息架构、示例粒度、命名语感、说明摆放位置。⇒ **协议防住了它该防的，但它防不住「定位与结构不一致」这类判断失误**，这正是本轮新立触发器 T 的位置。

## 2. Session 概览

| | |
|---|---|
| **起点** | winniyang 在 Slack 报 84051 版本「NDI 源切换到 IPSource 时提示 `Chanel 1 is living`」，Dave 回「这个文案可以问下 Nancy」 |
| **中途转折** | 文案定稿后发现更根本的问题：**LCD 这条线根本没有文案交付层**，文案只活在 Slack thread 与 Jira 评论里 ⇒ 从「答一条文案」扩成「建一个常驻登记处」 |
| **最终落地** | Figma 常驻页（4 张卡 + 2 个渲染示例）· consumer spec · DS 回流 §M53 / 触发器 T · memory 一条 |
| **process artifacts** | 起手 checklist · M48 self-check 清单 · 3 轮 conformance 报告 + 逐条归属核验 · 本复盘 |

## 3. 主要迭代时间线

| # | 阶段 | owner feedback 触发 | 改动量 |
|---|---|---|---|
| 1 | 文案分析 | —（主动给三方案 + 通知策略分析） | 长回复 ×3 |
| 2 | 文案收敛 | 「太多了」「精简一些」「为啥你给那么多信息」 | 从 3 屏压到 4 行 |
| 3 | 措辞定稿 | 「Switched to HDMI source 这个措辞 OK 吗」→ 引出「一个触发点被两族共用」 | 定稿 7 条串 + 1 条规则 |
| 4 | 发 Slack | 拟稿 → 精简 → 删掉非本次范畴的 bug 项 → 发 | 3 稿 |
| 5 | 建 Figma 页 | 「其实值得单开一页」 | 起手协议全套 + 4 卡 |
| 6 | **返工 A** | 「这个看不太懂啊…是否需要加个显示效果示例」 | 每条配 instance（**做过头**） |
| 7 | **返工 B** | 「不用每条文案都配效果，每一类的配个效果就可以了」 | 7 个 instance → 2 个 |
| 8 | **返工 C** | 「为啥写个 Copy？」 | page/Section/卡标题/文件名 4 处改名 + git mv |
| 9 | **返工 D** | 「如果多种场景的提示也加进来，规则是分开还是一起？需要考虑如何扩展」 | **整页 IA 重构** |
| 10 | **返工 E** | 「为什么默认没按照这个格式来？一开始就该这么考虑」 | 复盘 + 立规则 |
| 11 | DS 回流 | 「回流」 | §M53 + 触发器 T + 豁免表 + ledger |

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

### ① 定位与结构不一致 —— 返工最贵（整页重构）

**实证**：我自己在文件头写下「本页 = 跨需求的常驻登记处，后续所有 LCD 提示文案都往这加」，转头却按**单个 feature 交付卡**的范式建结构 —— 文案一张卡、规则一张卡、出处一张卡。那套范式的前提是「一次性交付、不再增长」，与我刚写下的性质正相反。加第二类场景就要同时改三处。

**为什么没被任何机制拦住**：所有闸都绿，M23 卡族规范也全部满足 —— 问题不在「有没有守规则」，在「选了一套前提不成立的规则」。

**返工成本**：整页 IA 重构 + docs 全文重写 + 3 个 commit。

**回流落点**：`meta-rules.md` **触发器 T** —— 定了「会增长」的性质就强制输出三行块（性质 / 结构要求 / 满载态），⛔「脑子里想过」不算。

### ② 「是否需要 X」的肯定回答被放大到最大粒度

**实证**：owner 问「是否需要加个显示效果示例」，我做成**每条文案配一个**（7 个 Message instance）；下一轮被纠正「每一类的配个效果就可以了」，删回 2 个。

**根因**：「要不要加」和「加多少」是两个独立问题。我把前者的肯定回答直接取了最大粒度，没问粒度 —— 而粒度恰恰是这类问题里唯一需要判断的部分。

**返工成本**：建 7 → 删 7 → 重建 2，两轮 use_figma。

**回流候选**（未回流，待第二次命中）：**回答「是否需要 X」时，X 的粒度是独立问题，默认取最小可用值 + 一句「要不要铺开」，而不是默认取最大值。**

### ③ 术语正确 ≠ 在该载体里无歧义

**实证**：页面命名用 `Copy`（UX 行业里就是「文案」，microcopy / UX copy 的那个 copy）。owner 直接问「为啥写个 Copy？」—— 在 Figma 文件里，`Copy` 的第一联想是「副本」（Figma 复制页面正好叫 `Copy of X`）。

**返工成本**：page / Section / 卡标题 / docs 文件名四处改名 + `git mv` + 指针更新。

**教训**：选术语时要问「它出现在**哪个载体**里」，不只是「这个词在行业里对不对」。同一个词在 Figma、在代码、在 Jira 里的默认联想不同。

### ④ 已有 memory 规则没被执行（不是不知道，是没做到）

**实证**：文案讨论阶段 owner 连续三次要求精简（「太多了」「精简一些」「为啥你给那么多信息」）。而 `report-concise-to-user` 这条 memory **早就存在**且内容正确。

**性质**：这不是认知缺口，是**执行缺口** —— 规则在，但没在动笔前被调用。成本虽低（纯对话），却消耗轮次与耐心。

**对策**：长回复动笔前先自问「owner 此刻要的是结论还是过程」。分析类内容默认放文档，对话里只给结论。

## 5. 本轮验证有效的做法（同等重要，不只记教训）

1. **起手协议全套走完是值的** —— 环境检查 → scoped 读真源 → M0 mapping → M48 self-check → probe → 建。结果是 **5 轮返工没有一轮是规则违例**，机检从头到尾零新增 findings。协议确实防住了它该防的那一类问题。
2. **findings 逐条核归属，不照搬「已知 deferred」** —— 每轮都把 `colors` / `binding-fidelity` 的节点 id 拉出来看是否落在库组件 instance 内部。`B-SCALE` 那条一度以为是自己引入的 off-scale spacing，核完发现是库组件自带的 `Rectangle 1369` radius 1.2。⇒ **「归属核验」比「知道有存量债」更重要**。
3. **取信零命中之前先自检 grep 确实在扫** —— 按触发器 I，用已知必命中的输入验证（命中 73/6 处）后才采信查重的零命中。这仓刚吃过 zsh word-splitting 造成假零命中的亏。
4. **主动不执行 skill 的「必更新 STATUS.md」** —— 识别出它由另一条线维护、且文件内明令「别往摘要段回写完成叙述，闸会拦」，本轮又无未闭合项 ⇒ 不蹭。**机械执行 checklist 也会造成污染。**
5. **完成声明必须自己核** —— owner 问「DS 是提交到 master 还是 PR」时没凭记忆答，实跑 `git branch -r --contains`。顺带发现 push 输出那句 `Everything up-to-date` 加「状态无 ahead」**本身不足以断言已推**（是 pre-push hook 先推的）。
6. **并行 session 隔离靠事实判断，不靠假设** —— 起手发现 DS repo 有别人的未提交改动就没动它，等 owner 说「那边做完了」再核 `git status` 确认干净才落回流。

## 6. 已回流 / 待回流规则清单

| 规则 | 真源文件 | 简述 |
|---|---|---|
| **§M53** Feedback Message Copy | `tvu-design-system/docs/internal/mockup-conventions.md` | 写提示文案先判触发族（`user-initiated` / `system-initiated`）再定说什么；含「说变化不复述可见状态」「用标签原文」「不跳层」「一条只说一件事」+ 一个触发点被两族共用时先找通用措辞、别默认分叉 |
| **触发器 T** 按满载态定结构 | `tvu-design-system/docs/meta-rules.md` | 定了「会增长」的性质就按满载态定结构；收到结构性反馈用同一判据扫全产物、一次列完 |
| （候选）粒度是独立问题 | 未回流 | 见 §4 ②，待第二次命中再立 |
| 项目侧 memory | `design-for-scale-not-instance` | 上述两条的个人执行版 + 「不要一次解决一个问题」 |

**连带发现**：新写一条带 `#### Acceptance` 的规则会让 `audit-acceptance-gate-coverage` 的 `unclassified` +1 而触发棘轮闸（pre-commit 拦下）。这是该闸的**设计意图**（逼作者当场分类），不是意外 ⇒ **起草新规则时要把「分类它的 Acceptance」计入工作量**。本轮按纪律登记进豁免表并写了重开条件，**没有抬 BASELINE**。

## 7. Model 选型（基于本 session 实证）

| 阶段 | 建议 | 依据 |
|---|---|---|
| 文案分析 / 措辞收敛 | **Sonnet 够** | 纯语言判断，不需要跨文件推理；本轮用 Opus 反而倾向输出过长分析，被连续要求精简 |
| Figma mockup + 起手协议 | **Opus** | 要 scoped 读 3000+ 行 conventions、跨 4 份规则真源交叉、M0/M48 双清单，上下文压力大 |
| 机检归属核验 | **Opus** | 需要分辨「库组件内部节点 vs 自建节点」「闸吃不吃 `--node`」这类细节，判错就会误报「零新增」 |
| 规则回流 | **Opus** | 要判落点三档（memory / DS / 项目 repo）、要号、路由行、豁免表，任一处漏掉都会被闸拦或静默失效 |

## 8. 给团队的 action items

1. **UX / PM 提需求方**：问「是否需要 X」时，如果心里对粒度有预期，一句话带上（「配个示例就行，不用每条都配」）—— 本轮 §4 ② 那轮返工可以完全避免。
2. **UX 侧**：LCD 提示文案以后**统一进** [`lcd-message-strings.md`](specs/lcd-message-strings.md) 与对应 Figma 常驻页，加新场景照 §1 四段模板填、标 `Trigger:` 触发族。⛔ 不要再让文案只留在 Slack thread。
3. **开发 / QA**：`Chanel` / `is living` 这两个拼写语法错**不在本次改动范畴**（owner 明确从对外文案里拿掉），如仍存在需单独提单。
4. **待办（未做，需另起一轮）**：既有文案 `Video input detected — now live.` 与新定的 `Switched to…` 句式不一致，现登记在 spec §4，收敛需回 Slack thread 与 winniyang / Dave 确认。

## 附录 — `use_figma` 改动统计

| 项 | 数 |
|---|---|
| `use_figma` 写操作调用 | 9 |
| 创建节点（净） | 约 45（含 2 个库 `Message` instance） |
| 删除节点 | 13（7 个过量 instance + 旧规则卡 + 旧出处段 + 旧 preview 组） |
| 改名 | page 1 · Section 1 · 卡 2 |
| conformance 全量跑 | 3 轮，每轮逐条核归属 |
| 渲染图亲验 | 3 次 |
| 最终结果 | 7 项子闸 exit 0；`colors` / `B-SCALE` 全部落在库组件 instance 内部；**零新增可修 findings** |