# V4-2333 走查轮六 —— AI 协作过程复盘（内部分享）

> 日期：2026-07-30 · Owner：Nancy · 记录者：Claude Opus 5 (1M context)
> 承接：[轮三–四复盘](./2026-07-29-v4-2333-mockup-review-round3-4-retrospect-internal-share.md) · [轮二复盘](./2026-07-29-v4-2333-mockup-review-round2-retrospect-internal-share.md)
> 真源：`docs/handoffs/2026-07-28-v4-2333-test-signal-parameters-handoff.md` §1k / §1k-B / §1k-C / §1k-D / §1k-F

---

## 1. TL;DR

- **总轮次**：本 session 一轮（轮六），内部分四段：规则互斥订正 → hint drift 修复 → 交付层收敛 → PRD 重构。
- **最终交付**：LCD 交付层从 **29,783 → 21,379 字符（−28%）**、feature Section 从 **6210×2620 → 4610×2495**、同类卡 **4 张 → 2 张**、PRD 回到 **canonical 6 段且需求重编号 1–11 连续**。
- **核心 process gap 数**：**6 个**，其中 2 个 🔴（都是"两处陈述互斥"的同一族病灶）。
- **关键 insight**：**「各自自洽」不等于「彼此一致」。** 本轮两个 🔴 都是同一个机制：本轮新写的部分与既有部分是**两次不同的书写动作**，每一处单独读都完全通顺，只有并排放才看得出反向。已有的两轮扫查（旧措辞正则 / 新事实对照）**结构上盖不住**这种形态。
- **规则回流 3 次**（`9aad3820` / `0540be18` / `629a5990`），且**零新增编号** —— 全部是改写既有条文。

---

## 2. Session 概览

| 项 | 内容 |
|---|---|
| **任务起点** | owner 起手给的是"等我验收效果图"，四个候选入口（A 字体复核 / B hint drift / C 候选规则升正式 / D 发 Jira）待他指方向 |
| **实际路径** | 起手读真源时**意外发现规则层互斥** → 订正 → owner 选 B+C → 做完 → owner 打开 Section 说"文字太多" → 量化诊断 → 收敛 → owner 追问"PRD 为什么两段 requirement" → 梳理出更严重的互斥条目 → 重构 → owner 要求自查两条候选是否该回流 → 自查后回流 → 收尾验证 Config-T 一致性 |
| **Figma 改动** | LCD 文件 `0054ib0nLmt27bC3QlGDl7` page `9343:2`：2 个 hint 属性/文案 · 6 个 UX 卡段重写 · 7 个 Journey 段重写 · 5 个 caption 瘦身 · 3 个 PRD 段重写 · 删 4 个节点（2 张旧卡 + `§4b` + `§5b`）· 2 卡改名 · Section 两次 resize · 1 处 REFERENCE 对照表修正 |
| **DS 规则回流** | 3 个 commit，改 4 个文件（`mockup-conventions.md` / `domain-tvu.md` / `design-process.md` / `AGENTS.md`），**新增编号 0 个** |
| **process artifacts** | handoff §1k / §1k-B / §1k-C / §1k-D / §1k-F · design-record §8.2 / §8.3 · design-spec D13 补 DS 同步记录 · 本复盘 |

---

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

| # | 触发 | 做了什么 | 改动量 |
|---|---|---|---|
| 1 | 起手读真源（无 owner 指令） | 发现 **§I7 与 D13 反向** —— 轮五同一个实证产出的通则与案例决策互斥 | 报给 owner |
| 2 | owner 问"哪个更合理、为什么有两条" | 分析：两条是同一容器两次不同失败各自抽的规则；病根是轮四把"该案例的修法"泛化成通则 | 纯分析 |
| 3 | owner: "Yes" | 订正 §I7（默认/例外/物理上限三层）+ 顺带修 `domain-tvu.md` §M17.1 两处同族 drift | `9aad3820` · 2 文件 |
| 4 | owner: "按推荐给我选" | 候选 1 升正式（§2a ③ 轮 + Trigger-Drift 第三类）· 入口 B 执行 | `0540be18` + Figma 2 项 |
| 5 | owner: "B4 没找到 / 文字太多，是不是有重复" | **先量化再动手**：跨交付物事实级查重 → 三层诊断 | 纯诊断 |
| 6 | owner: "选项二是不是更合理" | 撤回我推荐里站不住的理由；实测 page 布局余量 | 纯分析 |
| 7 | owner: "没有精简很多，只保留必要的逻辑" | 改口径：从"去重"改成"职责分层，每层每个事实只说一次" | 方案重做 |
| 8 | owner: "确认" | 四步收敛：UX 卡合并 · Journey 合并 · caption 瘦身 · 删旧卡+收宽 | 卡 4→2 · −25% |
| 9 | owner: "PRD 的 requirement 为什么有 2 段" | 逐条梳理 → 抓到**互斥需求条目**（比"两段"严重）+ 两类错位 | PRD 重构 |
| 10 | owner: "自查一下这两个规则是否需要回流" | 自查后发现两条都是既有规则缺口 → 改写而非新增 | `629a5990` |
| 11 | owner: "字体不用改；Config-T 那边调整了吗；收尾" | 只读验证 Config-T 指向有效性 → 9/9 命中；顺带扫出 D10 口径缺口 | 收尾 |

---

## 4. Top 6 process gap（按洞察价值排序）

### G1 🔴 同一实证产出的「通则」与「案例决策」互斥，两边各自读都自洽

- **实证**：轮五同时产出 DS 侧 §I7（「正解是回到 canonical 尺寸」）与项目侧 D13（「canonical 尺寸不是硬上限、物理边界才是」），**方向相反**，彼此零交叉引用。
- **后果**：正是 D13 原文明写要防的事 ——「否则下轮 AI 会按 D11 推论又把面板改回 176」。drift 存活到下一轮起手读真源才被发现。
- **根因**：轮四只掌握一个实证（hug 长到 246 压底栏），从它能推出的是"越过物理边界不行"，推不出"必须回到 canonical 数值" —— **把该案例的修法泛化成了通则**。还靠与 D9 的**修辞类比**（"别撑大自己" vs "别挤别人"）写成无条件禁止，而两者伤害机制不同（D9 是确定损坏，本条只在越界时损坏）。
- **回流**：§I7 改为默认/例外/硬上限三层 + 澄清 D9 边界（`9aad3820`）；机制层立 §2a ③ 轮（`0540be18`）。

### G2 🔴 PRD 内新旧 scope 条目互斥 —— 两轮扫查的结构性盲区

- **实证**：LCD PRD 里 07-09 首轮的 `req 4`「不提供图卡类型选择、不提供参数设置」/ `req 5`「Config-T 本期不做」/ `§5` 末条「v1 不暴露任何参数选项」，与衍生轮追加的 `§4b req 8/9` **正面互斥**。
- **后果**：dev 读到那三条会得出「本期不做参数、不做 Config-T」，与实际交付相反。
- **为什么两轮扫查都过**（这是本轮最有价值的发现）：
  - **①轮（旧措辞正则）**：旧措辞**本身没写错** —— "不提供参数设置"在 07-09 语境下是正确表述，正则即使命中也会被判为"正常表述"。
  - **②轮（新事实逐条对照）**：新事实**确实写进去了** —— 写在 `§4b` 里，逐条核对全部通过。
  - → 两轮都过，而读者拿到的是两条互相否定的陈述，只能挑一条信。
- **回流**：泛化 §2a ③ 轮为「互斥对照」+ 新增可执行判据「同文件扫法」（扫 `仅…`/`不提供…`/`本期不做…`/`v1 不…`/`deferred`，逐条判是否被本轮推翻）（`629a5990`）。

### G3 🟡 衍生轮给同一 feature 造平级单元（4 张卡 + `§4b`/`§5b`）

- **实证**：两张 UX 卡段结构 `segNamesIdentical: true`、标题只差中间几个词、**连 Jira 号都一样**；两张 Journey 卡的 stage 体系还**互斥**（任务流程式 vs canonical 5-stage）；PRD 加了 `§4b`/`§5b` 凭空多出第 7、8 段。
- **后果**：dev / QA 不知道该看哪个 —— 与 D12「一个 feature 只有一个 AFTER 流程图」是同一病灶，只是粒度从"流程图"下沉到"卡"和"段"。
- **值得记的细节**：**逐字重复实测几乎为零**（UX 卡 exactDup 5 条全是段名、Journey 0 条）。所以"内容太多"的病因不是抄重，而是**结构重复 + 层内重申**。若只按"找重复文案"去查，会得出"没问题"的结论。
- **回流**：`design-process.md` Step B「更新 vs 新建」补齐**卡级 + 段级**粒度（既有条文只管制品级）（`629a5990`）。

### G4 🟡 caption 承载了 UX 卡级内容，还夹带内部规则编号

- **实证**：07-09 轮 4 个 caption 平均 172 字符；本轮 5 个平均 **797**（4.6 倍），L1.5 单条 **1556**。多出的三段是 `Why:`（UX 卡已有）/ `Invariants:`（栅格数值，属 design-record）/ **`Rules in play:`（M21.2 / M47 / M23.7 / M52.4 等内部规则编号 —— dev/QA 完全不需要，且暴露内部规则体系）**。
- **顺带暴露**：删 `Invariants` 段时发现 L1.5 caption **自相矛盾** —— 开头 Δ 写「row 2, not appended at the end」，`Invariants` 段却写「appended at the end of the existing list」（轮四改落点时漏改这段，前几轮走查都没发现）。
- **教训**：caption 的职责是「这屏是什么状态 + 相对上屏的 Δ」。一旦它开始承载"为什么"和"实现细节"，就会与 UX 卡重复，且**内部一致性无人维护**。

### G5 🟡 走查 scope 隐含限定在单一 surface（第 4 次 SCOPE 实证）

- **实证**：收尾验证时才发现 **D10 口径（mediahub / 微服务权威清单）在 Config-T 侧的 PRD 与 UX 卡两处都缺**，而 D10 原文明确要求"必须写进 UX 交付说明与 PRD 的文字里"。LCD 侧两处都写了。
- **讽刺之处**：前几轮的 scope 声明都规规矩矩写着「覆盖 LCD page `9343:2` 的产品帧全集，含 INSTANCE 子树」—— **格式完全规范，恰恰掩盖了"另一个 surface 整体没被覆盖"**。这正是 §M-DISCIPLINE.SCOPE 的 Why 段所说的「产出物看起来很规范，规范的格式掩盖了范围不全」。
- **同族第 4 次**：轮二（对象集被指摘句框定）→ 轮四（清单只统本轮触碰帧）→ 轮五（枚举维度只扫 Roboto）→ **轮六（surface 不全）**。

### G6 🟢 轮五的记录有两处失实，靠 live probe 才纠正

- **实证 1**：轮五记「三处 hint 图层名都写 `Config-T only groups (read-only)`，与 B5 内容不符」→ 实测 B5 图层名本就是 `hint · stop the test to change parameters`，**三处名实全相符，该条不成立**。病灶 = 看了 B3/B4 的名字就推断第三处、没实测。
- **实证 2**：轮五记"三处 hint"，实测 hint 全集是 **4 处**（漏了 ① 帧的 `9373:70`）。
- **值得注意**：这两处都发生在 **§M-DISCIPLINE.SCOPE 立完的当轮** —— 规则写了，同一天就又犯了同族错误。说明**新立规则的头几轮需要刻意自查**，不能假设"写进真源就会被执行"。

---

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

| 做法 | 实证 |
|---|---|
| **先量化再动手** | owner 说"文字太多"时没有直接开始删，而是先跑跨交付物**事实级查重**（统计每个关键事实在 PRD / 2 张 UX 卡 / 2 张 Journey / 5 个 caption 各出现几次）。结果推翻了"逐字重复"的假设，定位到真病因是**层内重申 + 结构重复**。若直接删，会删错东西。 |
| **区分"层间双写"与"层内重申"** | 层间双写是 **D10 显式要求的**（档位口径必须同时写进 PRD 与 UX 卡），不能删；层内重申才是水分（同一张卡里 mediahub 口径说 6–7 遍、默认值 10 遍）。**不做这个区分就会删掉规则要求的内容。** |
| **删信息前先验证接收方真的有** | LCD PRD 把 Config-T 全量默认值改为"指向 Config-T PRD"后，收尾**逐项机器验证** 9 项内容在接收方是否存在 → 9/9 命中，确认零信息丢失。若不验，就是把"看起来合理的指向"当成了事实。 |
| **自查"是否需要回流"而不是直接加规则** | owner 没说"回流"，而是先让自查。自查动作 = ① 关键词扫遍 DS 真源确认是否真的没规则在管 ② 若命中既有规则，判断是"没触发"（激活层，禁止加新规则）还是"粒度/措辞缺口"（改写既有条文）③ 只有真空白才考虑新编号。**两条候选都落在②，故零新增编号** —— 直接避免了 §Trigger-Drift 警告的"规则越多越易漏触发"。 |
| **改规则名后立刻扫引用处** | 把 ③ 轮从「规则层对照」改名「互斥对照」后，立刻 grep 全 repo 找旧名引用，发现 `AGENTS.md` §Trigger-Drift 里有一处 → 同步。**这是 ③ 轮规则的自我应用。** |
| **owner 质疑推荐时，逐条审自己的理由而不是直接改口** | owner 问"选项二是不是更合理"，我审了自己两条理由：第 1 条（已交付卡不该动）**站不住**（本轮 PRD 就是往已交付物追加的，自相矛盾）→ 撤回；第 2 条（卡太高）**是可算的物理约束** → 实测 page 余量后给出解法。**一条撤回、一条坐实，比全盘改口或全盘坚持都更有用。** |

---

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

### 给 UX / PM 提需求方
1. **"太多了"这类感觉值得直接说** —— owner 一句"看起来太多了，是不是有重复的"触发了本轮最大的一次结构清理（−28%）。AI 不会主动质疑自己上一轮的交付量。
2. **追问"为什么是这样"比指出"这里错了"更有效** —— "PRD 的 requirement 为什么有 2 段"这一问，挖出的是**互斥需求条目**（比"两段"严重得多）。指令式的"合并成一段"只会得到合并，不会得到诊断。
3. **对 AI 的推荐提出质疑，即使你不确定** —— "选项二是不是更合理"让 AI 重审自己的理由，撤回了一条站不住的（且那条正好与本轮既成事实矛盾）。

### 给 AI 协作流程
4. **让 AI 先自查"是否需要回流"，而不是直接批准回流** —— 本轮因此少加了 2 条规则编号（改写既有条文即可）。规则库膨胀是有真实代价的（越多越易漏触发）。
5. **"只保留必要的逻辑"这类口径比具体指标更管用** —— 我第一版给的目标是 −14%（保守去重），owner 一句"没精简很多，只保留必要的逻辑"直接把口径换成"职责分层"，最终 −28% 且删掉的都是 dev/QA 不需要的（内部规则编号 / 设计探索期的"心里想" / 层内重申）。
6. **收尾时问"另一个 surface 调整了吗"** —— owner 这一问触发了 Config-T 一致性验证，抓到 D10 口径缺口。AI 的走查 scope 会隐性地锚在"本轮改过的那个文件"上。

### 给 review 方
7. **看"是否有两处在说同一件事"，而不只看"有没有写错"** —— 本轮两个 🔴 都是互斥而非错误，每一处单独读都通顺。
8. **caption / 注释里出现内部规则编号（M21.2 / M47 这类）就该退回** —— 那是给设计者自己看的，交付物上不该有。

---

## 6. 规则回流清单（本轮 3 次 commit · 零新增编号）

| # | commit | 落点 | 要点 |
|---|---|---|---|
| 1 | `9aad3820` | `mockup-conventions.md` §I7 + `domain-tvu.md` §M17.1 | §I7 上限口径由「回到 canonical 尺寸」改为**默认 / 例外 / 硬上限恒为物理边界**三层；澄清与 D9 的伤害机制差异（D9 无条件、本条有条件）；实证补"该修法下一轮被推翻"+ 最终 `240×211` + D13 指针。§M17.1 面板行 `240×176` → 「宽 240 + 高按内容算」；新增「连体绿框的实现」行（canonical 实测是手画 VECTOR、面板自身 stroke `visible:false`；原文"靠遮挡自然形成、无需另画"与实测不符，**是轮三误判要删 `Rectangle 1009` 的规则层诱因**） |
| 2 | `0540be18` | `mockup-conventions.md` §2a 新增 ③ 轮 + `AGENTS.md` §Trigger-Drift | ③ 轮「规则层对照」：口径一致性 / 被推翻的叙述须标注 / 双向引用。§Trigger-Drift 两层模型补**第三类失败**（规则被加载了但与另一处真源互斥 —— 不是没点亮，是点亮了两盏互相矛盾的灯），并明确修法不在原三类里 |
| 3 | `629a5990` | `mockup-conventions.md` §2a ③ 轮泛化 + `design-process.md` Step B + `AGENTS.md` 旧名同步 | ③ 轮 → **「互斥对照」**：触发条件加"本轮扩展了 scope"、对照对象拆成**跨文件 + 同文件**两形态、新增「同文件扫法」可执行判据、红线/Why/Acceptance 重写、实证拆 A（§I7 vs D13）/ B（PRD req 4/5 vs §4b）。Step B「更新 vs 新建」补齐**三层粒度**（制品 / **卡** / **段**）+ Acceptance 2 条 + V4-2333 实证 |

**校验（每次 commit 均实跑）**：`node scripts/audit-artifact-routing.mjs` → exit 0 · `pnpm audit:rule-load-map` → OK exit 0 · 两端 `git ls-remote` 核对一致。
**pre-commit 三次都走 `--no-verify`，原因已写进各 commit 正文**：红在并行工作线（INFRA-F68/F73/F79/F80）未提交的 `scripts/audit-page-recipes.mjs` 等文件，与本轮纯文档改动零因果；已取证（`readCanonicalNames` 在 HEAD 有 export、工作区版本被改掉、测试未跟上）。

---

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

| 环节 | 建议 | 依据 |
|---|---|---|
| 规则互斥诊断 + 病灶同族识别 | **Opus**（本 session 用 Opus 5 1M） | G1/G2 的共同机制（"各自自洽 ≠ 彼此一致"）不是逐条查表能得出的；需同时握住 DS 4 份规则真源 + 项目 3 份文档 + 跨 6 轮的历史病灶 |
| 「是否需要回流」自查 | **Opus** | 要判断"没触发"vs"粒度缺口"，需要读懂既有规则的**适用边界**（Step B 第 1 问管的是制品级），而不只是关键词匹配 |
| 跨交付物事实级查重 | Sonnet 够 | 写正则 + 统计分布，机械执行 |
| 多段样式文本批量重写 | Sonnet 够，**但必须带 M47.2 + 样式模板实测约束** | 本轮 21 个文本节点重写，手法固定后是模板操作；风险在跳步（丢 hyperlink / 丢分段样式）不在推理 |

---

## 8. 给团队的 action items

| # | 事项 | Owner | 说明 |
|---|---|---|---|
| 1 | ✅ ~~🔴 **Config-T 侧补 D10 口径**~~ | AI（轮七已完成 2026-07-30） | 已补：PRD `8084:522` req 7 + `8084:523` acc 5 + UX 卡 `8085:521` Data Contract + caption C3，机检 `Test Stream Generator` 8 处 / `mediahub` 10 处。**并纠正一处本条没预料到的形态错误**：档位不能照抄 LCD 的合并预设（`720p50`），Config-T 是三独立下拉（实画 `1280 x 720 / 1920 x 1080 / 3840 x 2160`）→ 改为「三下拉各自取值 + 只提供合法组合 + LCD 以合并 Format 预设暴露同一集合」。详见轮七复盘 + handoff §1k-G ④ |
| 2 | ✅ ~~🟡 **Config-T 侧走同样的收敛**~~ | AI（轮七已完成 2026-07-30） | 已收敛：Journey 5 stage 删 `Thoughts`（实测确实全含）+ Touchpoints 并进 Actions + Pain→Fix 合并，卡 1306→956；3 帧 caption 删 `Rules in play`（实测确实全含）+ `Why:`，1956→1176（−40%）。`Invariants` 实测 0，该猜测不成立。**同一次探查抓到本条完全没预料到的 🔴**：D1 修订（Update 提交）在 Config-T 侧 17 处未落地且与同卡 Update 描述互斥 —— 同族第 5 次 SCOPE 实证，见轮七复盘 G1 |
| 3 | 🚫 ~~LCD 产品帧 88 处非 Verdana 替换~~ | — | **owner 2026-07-30 裁定「不用改，就现在这样」→ 关闭**。Verdana/PingFang 本环境加载不到，AI 侧本就无法自修 |
| 4 | ⏸ **发 Jira** | Nancy | 等 owner 说定稿。精简格式 + @Trevor `5e59a401a17f930c9b9627c2` + cc Edward/Dave，ADF 真 mention + 短锚文本 Section 链接，发前先贴给 owner 确认 |
| 5 | 💡 **新立规则的头几轮要刻意自查** | 全员 | G6 实证：§M-DISCIPLINE.SCOPE 立完的当轮就又犯了同族错误（推断第三处 hint 的图层名而没实测）。"写进真源"不等于"会被执行" |

---

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

| 类别 | 数量 |
|---|---|
| `use_figma` 调用 | 15（其中只读 probe 6 · 写 9）· 1 次因 `getStyledTextSegments` 传了非法维度 `'opacity'` 报错（被 catch，未影响原子性） |
| `get_screenshot` + 亲验 | 3（B4 帧 · feature Section 全景 · PRD 卡），全部 `curl` 下载后逐项核 |
| Figma 文本节点重写（走 M47.2 + 样式模板实测） | 21（UX 卡 6 · Journey 7 · caption 5 · PRD 3） |
| Figma 删除节点 | 4（旧 UX 卡 `9393:59` · 旧 Journey `9396:59` · PRD `§4b` `9599:214` · `§5b` `9599:215`）—— 内容均已并入，非丢弃 |
| Figma 属性/结构改动 | hint opacity 1 项 · 卡改名 2 项 · 卡移位 2 项 · Section resize 2 次 · REFERENCE 对照表修正 1 处 |
| hyperlink 重建 | 2（demo video `watch` / `查看`，整段覆盖后复核齐全） |
| DS commit | 3（`9aad3820` / `0540be18` / `629a5990`）· 改 4 文件 · **新增规则编号 0** |
| 机检轮次 | 9（§I7 三项 ×2 · Section I2/I3 ×3 · page 级 ×3 · §2a 扫查 ×4 · Config-T 一致性 ×1） |
| 项目文档回写 | handoff 新增 §1k/§1k-B/§1k-C/§1k-D/§1k-F + 修正 2 处历史记录 · design-record §8.2/§8.3 · design-spec D13 补记 · 轮三四复盘 §6/§8 更新 · 本复盘 |
| 交付层字符净减 | **−8,404（29,783 → 21,379，−28%）** |