---
id: mode-switch-failure-state-retrospect
title: 协作复盘 — Mode 切换失败态两端收尾（V4-2318 LCD + V4-1865 Config-T）
doc_type: retrospect
audience: UX 团队 / PM 内部分享
last_updated: 2026-09-11
---

# 协作复盘 — Mode 切换失败态两端收尾

> 这份不是设计文档，是**我（AI）和 owner 这一轮怎么配合的**复盘，给 UX 团队和 PM 看。
> 设计本身的真源在 [plan](plans/2026-09-11-mode-switch-failure-state-plan.md) 和两份 design-record。

---

## 1. 一句话总结

**这个 session 的起手任务有三条前提，两条是错的；最终交付物和最初设想也不一样。**

| 项 | 数 |
|---|---|
| owner 介入纠正的轮次 | 4（文案口径 / 回复落点 / 落位 / 表达方式）|
| 最终 Figma 改动 | 6 个节点（4 个改文案 + 2 个改位置）|
| 最终文档改动 | 8 个文件、4 个 commit |
| 原计划要做、最后**没做**的事 | 发 Jira 评论、转 assignee —— **一件都没做，且都是对的** |
| 核心 process gap | 5 条 |

**最值钱的一条 insight**：这轮我做错的三件事（落位判断、右溢出、派生处不同步）**根因是同一个** —— 我验证的是"我改的那个东西"，不是"我的改动影响到的东西"。而且三次都是 owner 看了图才发现，几何数字全绿。

---

## 2. Session 概览

**起手任务**（owner 给的）：
1. 两端 Jira 回复 + 转 assignee（LCD 转 Edward Wu / Config-T 转 Bonnie Zhou）
2. 两个悬而未决的问题若 owner 给了口径就落地

**实际发生**：

| 起手前提 | 直读 Jira 后的事实 |
|---|---|
| 两单待转 assignee | ⛔ 错 —— **早就转好了**，交付当轮就转了，只是文档待办没划掉 |
| 两单可接收交付评论 | ⛔ 错 —— **都已关闭**（一个 Resolved 一个 Done），贴评论没人接 |
| 需要判断要不要另开现象单 | ⛔ 不用判 —— QA 当天已经开了（V4-2466）|

⇒ 起手任务的三条前提里两条不成立，第三条自己消解了。**如果照着做，结果是往两个关闭的单上各贴一条无人阅读的评论，并"转"两个已经正确的字段。**

---

## 3. 时间线

| # | owner 说了什么 | 我改了什么 | 返工量 |
|---|---|---|---|
| 1 | 「失败提示不说原因，但要提醒稍后再试」 | 4 处文案加 `Retry later.`（最自然的 `Try again later.` 实测装不下，折两行）| 中 |
| 2 | 「只回 V4-2466」 | 两个已关单不动；起草评论 | 小 |
| 3 | 「发的草稿是哪个？我没看到」 | 重贴一遍完整草稿 | 小（但说明我把关键内容埋在长汇报里了）|
| 4 | 「**错误的提示应该在顶部，当前的位置不对**」+「不用回复 JIRA」 | 两端提示条移到顶部 · 修掉一个右溢出 15px 的真错 · 撤回 Jira · 改 3 个文档 | **大** |
| 5 | 「又是代号，没说清楚是啥。这个全局规则说过很多遍」 | 重述问题 · 写机械判据进 memory · 把文档里的代号也展开 | 中 |
| 6 | 定了两条规则决定 | 规则收窄 + 撤销一处误判登记，扫 7 个派生处 | 中 |

---

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

### ① 落位连错两次，靠 owner 看图才纠正 —— 返工最大

**发生了什么**：提示条位置我先后放过三个地方（内容区中段 → 标题栏下方 → 最顶上），最后一个才对。

**根因（两层）**：

1. **我把"某个具体位置不行"记成了"整个方向不行"**。上一轮测出提示放标题栏下方会盖住 Mode 按钮，我写进文档的结论是「**不能放顶部**」。实际只有那一个具体位置不行——再往上 46px 就完全不冲突。Config-T 那边一模一样：测出贴着第一个分区会被误读成那个分区的错误，我记成「不能放页面顶部」。
2. **判据能算出一个合法值，不等于那个值对**。我立了三条判据（不压论据控件 / 不切字 / 取最靠上），照着算出内容区中段那个位置——三条全满足，但漏了一个判据之外的前提：**提示条本来就该在顶部**。判据是用来在正确区域**内部**选点的，我拿它把东西一路推出了那个区域。

**返工成本**：两轮 Figma 改动 + 3 个文档改写 + 一份已起草的 Jira 评论作废。

**⚠️ 更难看的一点**：定这条规则的那一轮，**决策记录右栏自己就写着与结论相反的证据** —— 「全文件 8 处既有提示条全部放最顶上，其中传输测试那两屏与本需求完全同构、那轮定稿就是盖标题」。我没解释这个冲突，反而把冲突的那两屏改判成了"存量不合规"。

⇒ **手里的先例与结论打架时，先解释冲突再定规则，别把打架的先例判成错的。**

### ② 提示条戳出画框 15px —— 我引入的，owner 先发现

文案加长后，提示框宽度从 369 变 439，但它的水平坐标还是按**旧宽度**算的居中值，于是右边缘 495 超出 480 的屏宽，被裁掉了关闭按钮。

我当时报的是「439×45 单行 ✓ 符合宽度规则」。那条规则只管**文案装不装得下**，管不住**这个盒子摆进屏幕后右边缘在哪**。两件事，我只验了前一件。

⇒ **改任何"宽度跟着内容走"的元素后，必须重算落位并复核 `左坐标 + 宽度 ≤ 容器宽`。**

### ③ 起手照着文档里的待办做，没先核实

两份设计记录里都挂着「待办：Jira 回复 + 转 assignee」。实际早就转完了，单也关了——那条待办是陈旧记载，没人回头划掉。

⇒ 收尾前必须直读两个字段：**assignee 现在是谁** + **单还开着吗**。往已关闭的单贴交付评论 = 发出去了但没人接，**看起来像交付了实际没有**。

⇒ 还有一条：「要不要开单」这类问题，**先搜再问**。这次悬了一轮的问题，一搜发现 QA 当天就开好了。

### ④ 改了主结论，派生的地方没跟着改（本轮三次）

| 次 | 残留 |
|---|---|
| 1 | 落位返工后，两份设计记录 + 计划文件的交付件表格里还写着旧坐标，4 处 |
| 2 | 规则收窄后，登记点散在 7 个文件里 |
| 3 | 撤销误判后，"待修"表述还在 2 处 |

第三次才改成**先按对象全集扫、再动手**。前两次都是"改我记得的那几处"。

### ⑤ 对 owner 甩内部代号 —— 复发，不是首犯

owner 原话：「又是代号，没说清楚是啥。**这个全局规则说过很多遍，为啥老是没遵守**」。

我在要 owner 做决定的句子里用了内部编号（落位档位号、待办编号），等于让他先去翻文档才能读懂我在问什么。根因是**语域没切换**：文档里编号旁边就是定义，对话里没有。

已写成机械判据而不是"下次注意"：发消息前扫自己的文本，凡 `字母+数字` / `§` / `档` / `号` 这类 token 逐个问"用户不翻文档看得懂吗"；**每条消息首次出现都要展开**（不吃"上一条解释过"）；**提问句里出现未展开代号 = 直接违例**。

---

## 5. 怎么跟 AI 配合更省事（按性价比排序）

**给提需求的人（UX / PM）**

1. **看图比看数字管用，而且快**。这轮三个真问题（位置不对、戳出画框、提示盖错东西）全是看渲染图发现的，几何数字当时全绿。⇒ 让 AI 交付时**直接给能点开的图或链接**，你扫一眼比读一页自检表有效。
2. **一句话定方向就够，不用给数值**。owner 说的是「错误的提示应该在顶部」，没给坐标。AI 去算坐标、逐字形核有没有切到字、跑机检——这部分不该占用你的时间。
3. **纠正时说清"否决的是这个值还是整个方向"**。这轮最大的返工就是我把"这个位置不行"理解成了"这个方向不行"。

**给 AI 协作流程**

4. **起手别信文档里的待办，先核实**。尤其"待发送 / 待转交"这类——很可能上一轮已经做了。
5. **改完问一句「这个值变了，还有谁是按它算出来的」**。居中坐标、相邻间距、容器高度、文档里的规格表，都是派生值。
6. **闸跑不起来 ≠ 通过**。这轮踩到：整条命令 `exit 0` 但三个检查一行输出都没有（退出码来自循环最后一条命令）。判据要看检查工具自己的汇总行。

**给 review 的人**

7. **AI 说"全部通过"时，问它扫描面是什么**。这轮的"零新增问题"结论靠的是对称性取证（改过的节点 vs 没碰过的兄弟节点，命中集合逐字相同），不是靠某条检查规则——因为那条规则给不出逐节点明细。这种区别值得问一句。

---

## 6. 规则变更清单

**本轮已落地（项目侧）**

| 规则 | 落点 | 简述 |
|---|---|---|
| 提示条落位判定顺序 | `docs/specs/lcd-message-strings.md` §2.5.1 | 两问、有优先级；设置页默认落位加了前提 |
| 失败提示要给下一步 | 同上 §5.1 | 不说原因，但必须给「稍后重试」|
| 宽度量法 | 同上 §5.2 | 必须落帧实测、且测最长参数组合；⛔ 不按字符数推算 |
| 撤销一处误判登记 | 7 个文件 | 传输测试那两屏从待修名单划掉 |

**待 owner 拍板是否升为跨项目规则（⛔ 本轮未自行推广）**

| # | 候选 | 为什么可能跨项目成立 |
|---|---|---|
| 1 | 交付收尾前直读目标单的 assignee + 状态 | 任何项目都会有"文档待办比实际落后"的情况 |
| 2 | 改「宽度跟内容走」的元素后必须重算落位 | 任何 hug 布局都有这个坑，不限 LCD |
| 3 | 否决一个取值时必须限定射程，别写成否决整个方向 | 这类结论会在下一轮被当前提直接采信，没人回头重测 |
| 4 | 判据算出合法值 ≠ 那个值对；判据只在正确区域内部选点 | 通用的判据使用纪律 |
| 5 | 手里先例与结论冲突时先解释冲突，别把先例改判成违规 | 通用的规则制定纪律 |
| 6 | 并行工作树要软链的不只依赖目录，还有 gitignore 的运行时配置 | 任何用 worktree 的仓 |

---

## 7. Model 选型

本轮全程 Opus 5（1M context）。判断：

- **值得用大模型的部分**：跨 3 个 Figma surface 的对象全集扫描、逐字形覆盖复核、7 个派生处的一致性追踪、从机检输出里做逐节点归属。这些错一处就是假绿。
- **不值得的部分**：文案宽度逐候选实测、坐标重算——这些是机械操作，脚本化后任何模型都能跑。
- **⚠️ 大模型没帮上的地方**：三个真问题全是 owner 看图发现的。**模型能力不替代"打开图看一眼"。**

---

## 8. 给团队的 action items

| # | 事 | 归属 |
|---|---|---|
| 1 | 决定上面第 6 节那 6 条要不要升为跨项目规则 | owner |
| 2 | Figma 机检 hook 分不清读写，纯只读勘察也被记成"未机检的写操作"（本轮挡了 3 次，每次都要自证）。根因是起手给裸文件 key 而非完整链接 —— 要么起手贴完整链接，要么改 hook | owner / 工具侧 |
| 3 | 两个已关闭的功能单上没有任何指向失败态设计的线索，日后从功能单找不到。要不要补指路评论或建关联 | owner |

### 附录 · Figma 改动统计

| 类 | 次数 | 说明 |
|---|---|---|
| 只读勘察 | 6 | 对象全集扫描、几何量取、逐字形覆盖复核 |
| 写 · 文案 | 3 | 4 个节点（双语节点用定点插入，避免段样式被压平）|
| 写 · 落位 | 3 | 2 个节点（其中 1 次是为了渲图对比，同轮定稿）|
| 测量用临时写 | 2 | 逐候选赋值量宽度，量完原样还原 |
| 机检 | 7 跑 | 3 个 surface + 2 个对照帧，每跑各自出 report |
| 渲染图 | 4 张 | 两端改前 + 两端改后（真问题全在这 4 张里） |