# V4-2333 走查轮十 · AI-用户协作过程复盘（内部分享）

> 日期：2026-07-31 · Owner：Nancy · 受众：UX 团队 / PM
> 任务：V4-2333 衍生轮 **owner 4 条修订意见的落地轮**（轮九登记入口、本轮全部交付）
> 真源：`docs/handoffs/2026-07-28-v4-2333-test-signal-parameters-handoff.md` §1k-K · `docs/specs/2026-07-28-v4-2333-test-signal-parameters-design.md` D14 / D15 / D16

---

## 1. TL;DR

| 项 | 值 |
|---|---|
| 本轮轮次 | 走查轮十（同一 feature 第 10 轮，第一个「双端同时大改」的落地轮）|
| 派单 | 4 项：① Background 事实更正 ② 未选 R 改 Go Live 引导 ③ Config-T 补 Receiver ④ 补必要状态 |
| 实际交付 | 派单 4 项全做，**其中 2 项的执行前提被实测推翻或补足** + 1 项派单外的互斥自查命中 |
| 核心 process gap | **1 个 🔴**（派单转述里的机制描述被当成一手事实）+ 2 个 🟡 |
| 改动量 | 新增 11 个顶层节点 · 改写 **21 个文本节点**（全走 M47.2）· 14 处几何重排 · 3 份文档回写 · DS repo **零写入** |
| 关键 insight | **owner 说「参考 X 的流程」时，X 的机制必须 probe X 的界面本体拿一手 —— 派单里对 X 的转述是二手的，而且这次它是错的**。实测发现 Go Live **根本不存在提示环节**，未选 R 时点 Live 是直接导航到选择页；若照派单字面「不再用 prompt 提示，改为引导」去做，最可能的产物是"一个更友好的提示弹窗"，方向就整个偏了 |

---

## 2. Session 概览

**起点**：轮九 owner 看完 mockup 给出 4 条修订意见，当时明确「以上这些都在新的 Session 中继续」，轮九只做入口登记（handoff §1k-J：owner 原话逐字 + 定位实测 + 逐条执行清单）。本轮从该入口接手落地。

**终点**：4 条全部落地，回填为 design-spec **D14 / D15 / D16**；两端 in-file 机检全绿；mockup 仍未定稿故 Jira 未发。

**process artifacts**：handoff §1k-K（含 §2a 三轮与机检原文）· design-spec 顶部指针从「D1–D13 不再是决策全集 / 尚未落地」改为「4 条已落地 · 决策全集 D1–D16」· §3.1 三列布局与 §3.2 Receiver 组回写 · memory 进度条 · work-log。

---

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

| # | 阶段 | 触发 | 改动量 |
|---|---|---|---|
| 1 | 起手协议 + 读三份真源 | 派单指定按序读 | 0（只读）|
| 2 | 三处并行 probe（LCD 交付层 / Go Live 参考帧 / Config-T 帧本体）| §2a ③ 轮跨 surface 强制 probe | 0（只读）—— **本轮价值最高的一段，见 G1** |
| 3 | 落地 1：删被推翻前提 | owner 意见 1 | 2 个文本节点（比派单登记多 1 处）|
| 4 | **停下来问 owner 粒度** | 派单要求「先列候选清单请 owner 确认」 | 0 —— 见 4b①，省掉 3 帧返工 |
| 5 | 落地 2：LCD 线 C 两帧 + caption + 分叉连线 | owner 意见 2 | 11 节点 + Section 两列扩三列 |
| 6 | 落地 2c：两端交付层 prompt 口径全改 | §M-DISCIPLINE.SYNC | 8 个文本节点 |
| 7 | 落地 3：Config-T 三帧补 Receiver 行 | owner 意见 3 | 6 节点 + 浮层连带位移 + Section 重排 |
| 8 | 落地 4：四状态进两端 PRD/UX/Journey | owner 意见 4（按步骤 4 的粒度）| 11 个文本节点 |
| 9 | §2a 三轮 + 两端机检 + 截图亲验 | 收尾 gate | 1 处分隔符范式回修（见 G3）|

---

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

### G1 🔴 派单对「参考物」的转述被当成一手事实 —— 而这次转述里的机制是错的

**实证**：owner 原话是「未选 Receiver 时，流程参考 Go Live 的流程，引导用户去选择接收机后再发起测试」，并给了参考链接。轮九的派单（§1k-J）把它整理成执行清单一行：*「未选 Receiver 时**不再用 prompt 提示**，改为**参考 Go Live 流程**：引导用户先去选接收机、再发起测试」*。

这行转述读起来完全合理，且**隐含了一个前提：Go Live 那边也是某种"引导提示"**。真实情况是 —— probe `8062:8070` 后实测：Go Live 未选 R 时，home 屏 Receiver 行显示 `- - -` + 排序箭头，**点 Live 按钮直接跳转**到「Please select a Receiver」整页（连线注释原文写死了 `home button --> Please select a Receiver`），全程**没有任何提示 UI**。底栏还按进入场景分了两形态：未选态只给 `Go Live`（选完即发起）、已选态给 `OK` + `Go Live`（可只改目标不开测）。

**代价**：本轮 0（probe 走在动手之前）。**若跳过 probe**，最可能的产物是「把旧 prompt 换成一个措辞更好的提示弹窗」——交付物看起来响应了意见，方向却是反的，且这种错要等 owner 下一轮看图才能发现，返工成本 = 一整轮。

**为什么这次躲过了**：不是因为警觉，是因为 **§2a ③ 轮的跨 surface 判据 d 把「必须 probe 目标 surface 界面本体」写成了硬约束**，派单也照抄了这条。规则替人挡了一次。

**回流落点**：判据 d 当前的措辞是「**把一个 surface 的口径复用到另一个 surface** 时须 probe」。本例严格说不是"复用口径"，而是"**参考另一个已交付流程的交互机制**"——同族但不同形态。建议把触发条件扩一句：**凡 owner/派单出现「参考 X」「照 X 的做法」且 X 是已交付物，落笔前 probe X 本体**，理由与判据 d 完全一致（转述与界面本体是两次不同的书写动作，没有机制保证一致）。→ 待 owner 拍板是否升为 §2a ③ 轮的第四种形态。

---

### G2 🔴 owner 点名的位置 ≠ 对象全集（SCOPE 病灶第 N 次复发，这次是机器扫查救的场）

**实证**：owner 意见 1 指向「Background 第二条」。轮九派单据此实测并写明：*「错误表述**只在** Figma 的 LCD PRD 卡 §2 Background 第二条」*（本地 docs grep 0 命中，结论本身没错）。本轮按 §2a ① 轮跑正则（`固定图卡|fixed pattern|one fixed|neither be inspected|看不到也改不了`）扫 LCD page 全部 523 个 TEXT，命中 **2 处**——除 PRD 外，**UX 卡 Why 段 ② `9597:216` 带着同一个被推翻的前提**。

**代价**：本轮 0（① 轮在动手前跑）。若只改 owner 点名那一处，dev/QA 读 UX 卡仍会拿到已作废的痛点陈述。

**与前几轮的关系**：轮六 G1、轮七 G1 是同一病灶（scope 由「对象全集」推导，而非由「用户指摘了什么」推导），已沉淀为 §M-DISCIPLINE.SCOPE。**本轮的新信息是：这条病灶靠"下次记得"治不好，靠"每轮无条件跑 ① 轮正则"治得好**——派单已经明确写了"只在一处"，人的注意力不会再去怀疑它，是机器扫查逆着派单结论抓出来的。

**建议**：① 轮正则**不因派单已定位而跳过**。把「派单说只有一处」当成待验证假设，不当成 scope。

---

### G3 🟡 「补东西」会反向推翻既有的「不做」声明 —— 这个方向的互斥不在改动清单里

**实证**：本轮按 owner 意见 4 补了「R 离线」「发起失败」两个状态的文字描述。而 LCD Journey `9598:221` 里原本写着 🔴 *「not designed this release: link failure / all receivers offline · 本期未设计：链路失败 / 接收端全离线」*。这两条**正是本轮刚补的东西**——旧声明当场失效。

**难点在于它不在任何改动清单里**：本轮的 to-do 是「补状态」，不是「改 Journey State coverage」。§2a ③ 轮判据 b 平时的触发方向是「我写的新话推翻了旧话」，而这里是「**owner 要求补的东西，让旧的『本期不做』声明失效**」——同一条判据的反方向，容易漏。

**处置**：已删除该 🔴 行，内容改列为 🟡「仅文字描述、无独立效果图」。

**可执行判据（建议纳入 ③ 轮同文件扫法）**：凡本轮**补了任何此前声明"不做/未设计/deferred"的东西**，回头扫同一交付物的全部 `🔴 / not designed / 本期未设计 / deferred` 行，逐条判是否已被本轮补掉。

---

### G4 🟡 往既有长文本追加条目前，先实测既有条目的分隔符范式

**实证**：给 Config-T PRD 追加需求 10/11 时，脚本探到末三段样式为 `[?, EN, ZH]` 且 `fontSize=12`（不是 LCD 那边的 8px 空行段），于是判 `hasGap=false`、不插空行。事后核验发现：**§4 既有条目之间用 `\n\n`（空行分隔），§5 用 `\n`（无空行）** —— 同一张卡里两段的范式不同。新加的条目在 §4 里就与上一条紧贴了。

**代价**：一次回修（1 个节点）。**若不核验**，交付图上会出现「前 9 条有间隔、后 2 条挤在一起」的排版瑕疵，且这类瑕疵截图上不明显、机检也不报。

**可复用做法**：追加前用正则把既有条目边界的分隔符全打出来（`[...c.matchAll(/\n+(\d+)\.\s/g)]` → 逐条看是 `\n` 还是 `\n\n`），照抄多数派。**别假设同一张卡内各段范式一致。**

---

## 4b. 本轮验证有效的做法（与教训同等重要，建议直接复用）

### ① owner 给了一句模糊要求时，列候选清单 + 附实测依据让他选，而不是先猜一版画出来

owner 意见 4 全文只有一句「补充必要的状态」。本轮没有自行拍板画几个状态，而是列了 4 个候选（未选 R / R 离线 / 发起失败 / 无信号源），**每个候选都附上实测依据**（例如「R 离线一项已有既定逻辑真源 —— 同文件 `9257:2` 卡实测：preset 在线→用；离线→回退 lastliveR；都无→空+置灰」），同时把「画到什么粒度」也一并问了。

owner 的回答是我**没有预设过**的一个选项：*「这几个状态用文字描述，顶多补充选项一那个，这样既可以了解交互流程又能有效果图示意」*——四态全要，但只有一个配效果图。

**收益**：省掉 3 个多余帧的绘制 + 后续每轮的维护成本；也避免了另一个极端（只画一个、被问"其它状态呢"）。**判据：owner 的要求里出现「必要的 / 合适的 / 相关的」这类需要判断粒度的词，就该问，且问的时候要带实测依据，让他在具体选项上做决定，而不是回答一个抽象问题。**

### ② 改多段样式文本：样式对象从原节点取 + 按「相对末段索引」定位 + probe 回显自证

本轮改了 21 个多段双语文本节点，零样式回归。做法固定为：

```js
const orig = n.getStyledTextSegments([...KEYS]);      // 样式对象从原节点取，零硬编码
const L = orig.length;
const EN = orig[L-2].style, ZH = orig[L-1].style, GAP = orig[L-3].style;   // 相对末段索引
// 整段 setRangeFontName 覆盖 → 赋 characters → 逐段重设（M47.2）
return { probe: { L, gapText: JSON.stringify(...), gapSize: GAP.fontSize, enSize: EN.fontSize, zhFam: ZH.fontName.family } };
```

**两个关键点**：
- **绝对索引会数错**。本轮第一版手数成 `s[31]/s[32]/s[30]`，实际是 34 段 → 报错。`use_figma` 脚本是**原子**的，报错等于零改动、可安全重试；改用 `L-1/L-2/L-3` 后一次过。
- **返回 probe 字段自证索引猜对了**（`gapSize:8` / `enSize:13` / `zhFam:"Noto Sans SC"`）——不是"跑完没报错就算对"，是**让脚本把它认定的段语义打印出来给人核**。

### ③ 几何连带用「不变量守恒」验证，不用"看起来对"

三处连带位移都定义了一个应当守恒的量，并在返回值里断言：

| 场景 | 守恒量 | 实测 |
|---|---|---|
| C3 下拉浮层随 Resolution 行下移 | 浮层顶 − 行底 | 4px → 4px（`gapPreserved: true`）|
| 三个 caption 增高后补偿 y | caption 底 − 帧顶 | 20 / 20 / 20 |
| ①→C1 分叉连线两端 | dot 中心 vs 帧顶边中点 | Δ0 / Δ0 |

### ④ overlap 不满足于报数，要逐对量化归因

末轮机检 AFTER Section 报 `overlap: 9`。没有停在这个数字上，而是逐对算侵入深度并分类：结果 9 对**全部**是连线端点 Δ3px 锚定（y 侵入深度恒为 3），`nonAnchorCount: 0`。

**为什么重要**：这个数字既可能被当成"9 个新 bug"而去做无意义的返工，也可能被当成"跟上轮差不多"而放过真问题。**报数不构成结论，归因才构成结论。**

---

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

### 给 UX / PM 提需求方

1. **说「参考 X」时，尽量说清参考的是 X 的哪一层**（视觉范式 / 交互机制 / 组件来源）。本轮 owner 说"参考 Go Live 流程"，实际要参考的是**交互机制**（导航替代提示）+ **底栏形态**，而不是视觉。轮三还踩过反例：范式帧只该给布局语汇，它的底栏组件不该连来源一起 clone。
2. **模糊粒度的要求可以直接说"你先列几个选项我来挑"** —— 本轮意见 4 就是这样收敛的，一轮定案。
3. **推翻既有陈述时，如果记得它还写在别处，顺手说一句**；记不得也没关系，机器扫查会兜底（本轮 ① 轮就多抓了一处）。

### 给 AI 协作流程

4. **「参考 X」= probe X 本体的硬触发**，转述不算数（G1）。
5. **① 轮正则不因派单已定位而跳过**，派单结论当假设不当 scope（G2）。
6. **补了任何"此前声明不做"的东西，回头扫全部 🔴 / deferred 行**（G3）。
7. **追加条目前实测既有分隔符范式，别假设同卡内一致**（G4）。
8. **动手顺序：零歧义的先做，需拍板的攒一起问一次** —— 本轮先落地了意见 1（owner 原话逐字给了、零歧义），再问粒度，问完连着做 2/3/4，全程只打断 owner 一次。

### 给 review 方

9. **看图时可留意「同一页面的两个变体」有没有被区分开** —— 本轮 C1/C2 是同一张选择页的两种进入场景，靠"字段行 `---` vs 绿字当前值"+"底栏 `Test Signal` vs `OK`+`Test Signal`"区分，caption 里写明了触发场景。若这类区分不明显，值得当场指出。

---

## 6. 规则回流清单（本轮 DS commit 0 · 新增编号 0）

| 规则 | 真源文件 | 状态 |
|---|---|---|
| §2a ③ 轮触发条件扩「参考另一已交付流程的交互机制」（G1）| `mockup-conventions.md` §M-DISCIPLINE.SYNC | **待 owner 拍板**（第 1 次命中，未擅自改 DS）|
| ① 轮正则不因派单已定位而跳过（G2）| 同上 §2a ① 轮红线 | **待 owner 拍板**（属既有红线「0 命中不构成通过」的邻接补充）|
| ③ 轮同文件扫法增「补了 deferred 项 → 回扫全部 🔴 行」（G3）| 同上 ③ 轮可执行判据 | **待 owner 拍板**（第 1 次命中）|
| 追加条目前实测既有分隔符范式（G4）| 候选 → M47.2 邻接 | 建议先观察是否复发再定 |

**本轮 DS repo 零写入**（design-spec §7 条 4：纯项目 mockup 轮不改 DS）。上述四条均记为候选，累积到 owner 拍板或第 2 次命中再回流 —— 沿用 [[consumer-product-conventions]] #7 的口径。

---

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

| 环节 | 推荐 | 理由 |
|---|---|---|
| 跨文件 probe + 从界面本体反推交互机制（G1 那段）| **Opus** | 需要把「连线注释文字 + 底栏按钮差异 + 两个变体帧」拼成一个完整机制判断，且要意识到它与派单转述冲突 |
| 21 个多段双语文本的样式保真改写 | **Opus** | 段索引/样式对象/分隔符范式三层约束同时成立，错一层就是隐性样式回归 |
| 几何连带重排 + 守恒量验证 | Sonnet 够用 | 规则明确、可机器断言 |
| §2a 三轮机器扫查 | Sonnet 够用 | 正则 + 清单逐条核 |
| 整轮串起来（本轮实际）| **Opus** | 4 条修订跨 2 个 surface × 4 个交付层，中途有 2 次前提推翻需要即时改变执行方向 |

---

## 8. 给团队的 action items

1. **owner**：拍板 §6 的三条候选规则是否回流 DS（尤其 G1 —— 它这次实打实挡住了一个方向性错误）。
2. **owner**：mockup 定稿后走 Jira 精简格式回复（`UX Design updated.` + 短锚文本 Figma 链接 + @Trevor + cc Edward/Dave），发前贴全文确认。
3. **UX/AI**：下轮若 owner 认可三列布局，考虑给线 C 补一条「选定后回到 ① / 进入 LIVE」的回流连线（本轮由 caption 文字交代）。
4. **全员**：`FIGMA_PERSONAL_ACCESS_TOKEN` 仍缺 → REST 总闸 9/9 could-not-run 已持续多轮，自检长期靠 in-file 机检替代（合法性依据见 design-spec §7 条 2 的 F62-a 例外段，DS backlog [[INFRA-F62]] 下已有子项）。拿到 token 后应批量补跑 `--report` 并回填引用行。

---

### 附录：本 session 改动统计

| 项 | 数 |
|---|---|
| `use_figma` 调用 | 约 41 次（含 2 次报错重来 —— 脚本原子，零副作用）|
| `get_screenshot` 亲验 | 6 张（Go Live 源帧 3 + 新建 C1/C2 + 三列全貌 + Config-T C1/C2/C3）|
| 新增顶层节点 | 11（LCD：2 帧 + 2 caption + 1 连线 group；Config-T：3×(row + divider)）|
| 改写文本节点 | 21（LCD 10 + Config-T 11，全走 M47.2）|
| 几何重排 | 14 处（两端 Section resize ×4 + 卡/帧位移 ×10）|
| 文档回写 | 3 份（handoff §1k-K · design-spec D14–D16 + 顶部指针 + §3.1/§3.2 · memory）|
| DS repo 写入 | **0** |
| 机检结论 | 两端全绿：非锚定 overlap 0 / overflow 0 / childOverflow 0 / glyph 0 / 连线 9-9 正交 / 双语行距 22-22 pass / palette 与注释字体违例 0 / Config-T instance 151 全 remote |