WorkBuddy
eee042c855
原型（执行会话/目标-…-d85687/ui/mcn-workbench.html） - 功能入口卡改三段纵向（图标／标题／描述各一行），68 → 111.19px，对齐 mcn-work-shop 参考卡（同视口 1249×1277 实测 133px），补 --sh-L1 投影；主因是排布不是字号 - 左侧导航重建：由「纯图标 ＋ 悬停提示」改为 64px 药丸浮栏，图标 24 在上、名字常驻在下 （名字一律 2 字，说明走 data-tip）；真值取自 tiaoyue 源站实测 （栏 64／内衬 3／圆角 100／项 56×78／字 12px-500-行高 16） - 密度 A 方案：≤1000 卡最小宽 200→160、≤820 统计条最小宽 132→96 （两处 auto-fit 只在真装不下时才缩）⇒ 768／700／560 三处转绿，其余 10 个视口未动 - 移动档隐藏导航条横向滚动轨（16px 轨道曾吃掉 52px 条高的三成，还白吃 16px 主区） 取证通道 - _tools/cap.py 改为「只连不起」：只连 9223 常驻实例，视口走 Emulation.setDeviceMetricsOverride， 不再自起 headless Chrome（顺带解除 500px 视口下限，390×844 可测） - _tools/check_js.py 新增第 5 道门禁（node --check ＋ 模板内注释反引号扫描） 文档 - 复盘-为什么第一版做得很差.md（新建）：13 轮时间轴／四类反作用／三重归因／已修与仍欠 - 3d-审查报告.md：更正 §九 那条假 ✓（把「§5.5 五条逐条过完」记成机核，实际零覆盖， 正是「五道闸门全绿却难看」的开关），补 §十二 功能入口卡高差、§十三 tiaoyue 导航逐条对照 - 3b-实测记录.md／DESIGN.md／3c-GPT 参考版与会诊／布局排版参考 ×2 机制与记忆 - .workbuddy/collab/collabctl.py：off --ws 不再全机扫描（原先一次杀掉他区＋看板共 5 个进程） - .workbuddy/memory/：本轮纪律与实测真值 - .gitignore：补排运行时噪音（ui/_scratch／__pycache__／浏览器取证临时目录／*.bak-*／一次性脚本） 闸门：语法全过／骨架八页 39 板块／变异对照 15-15／逐视口 14 绿（500×844 唯一红，缺口待拍板）／命名 2060-0-27
87 lines
7.1 KiB
Markdown
87 lines
7.1 KiB
Markdown
# 骨架优化方案 v2（②③分段 · 按各自权责）
|
||
|
||
> 取代 v1：`骨架优化方案-v1-作废-形态误归②段.md`（v1 把「形态」整层划给了②段，口径错了，已留档作废）。
|
||
> v1 错在哪：②段《界面布局》里「账号矩阵列表 —— **一行一个账号**」这类**形态描述**本就不该由②段写；
|
||
> 而形态判定的权威工具 `layouts-tooling.md` 文首**明写「⛔ 本文件是 `stage-delivery` 自己的东西」**，§0 就是「**先判形态，再挑骨架**」⇒ 形态归③段。
|
||
> 写于：2026-10-08 08:5x，主会话。用户口径：「制定骨架是 2、3 步技能交叉知识，必须用 3 步骤技能，而且第 3 步可以往更好的体验修改」。
|
||
|
||
---
|
||
|
||
## 〇、骨架分两层，各归各段（判据：②段 SKILL.md §②—③ 交接口）
|
||
|
||
| 层 | 归谁 | 具体是什么 |
|
||
|---|---|---|
|
||
| **块级骨架** | **②段定死** | 有哪几页 / 每页几个板块、板块怎么排 / 跨页关系 / 每页主操作 / 每条信息在哪一档 |
|
||
| **形态与版式** | **③段** | 判形态（列表型／详情型／侧区型…）、挑版式骨架、每个板块的视觉实现与交互行为、状态与空态、响应式 |
|
||
|
||
- ②段口径原文：「骨架是判断基准，必须在②段定死」「③段不许新增／移动／删除板块，缺板块要回②段改」⇒ **冻结的是块级，不是形态**。
|
||
- ③段口径原文（`layouts-tooling.md`）：「⛔ 本文件是 `stage-delivery` 自己的东西」「工具型页面的版式在本项目只有这一份来源」⇒ **形态是③段的地盘**，且③段**有裁量权把它往更好的体验改**。
|
||
- ⇒ v1 的错误：把「P1 做成矩阵」「P5 做成对照」这类**形态决策**当成块级改动推给②段，方向反了。
|
||
|
||
---
|
||
|
||
## 一、归②段的改动（块级，只这几处）
|
||
|
||
### 1.1 删掉越界的形态措辞（⛔ ②段写了形态 ＝ 侵了③段的地盘）
|
||
|
||
- P1 板块 2 原写「账号矩阵列表 —— **一行一个账号**，行内三件事」⇒ 删掉「一行一个账号」与「行内」，只留块名与承载内容。
|
||
- P2 板块 2「对标内容列表」、P3 板块 2「条目列表」、P7 板块 1「待复盘列表」、P8 板块 1「发布记录列表」⇒ 块名里的「列表」同样是形态词，改成中性块名（如「对标内容」「资产条目」「待复盘项」「发布记录」）。
|
||
- 理由：块名一写「列表」，③段就被迫画列表 —— 这正是「像后台」的源头之一。
|
||
|
||
### 1.2 给 AI 产出补块位（功能已有，落位缺失）
|
||
|
||
- `2a` 里 AI 相关功能都有状态流转（如 `idle → 抓取中 → 已出候选 → 已采纳／忽略`、AI 调用失败可重试、重复生成不覆盖），但 `2b` 的 P4 板块清单里**没有一个块承载它**。
|
||
- ⇒ P4 增加一块：**AI 产出与采纳**（承载当前环节的 AI 产出、采纳／驳回／改后再用）。⛔ 这不是加功能，是把 `2a` 已有的功能落到位。
|
||
- P7 同理：现有「归因结论区 —— 由人确认」把两件事混在一块，拆成 **归因结论**（可编辑）与 **确认与改判** 两块。
|
||
- P2 的「评论区洞察区」承载的是 F3 的 AI 候选选题，块名补一句「含 AI 候选」即可，不必加块。
|
||
|
||
### 1.3 板块分档要跟着改的
|
||
|
||
- P4 新增的「AI 产出与采纳」档位＝**主屏常驻**（判据：删掉它，当前环节的产出没地方看也没法采纳，主操作「推进到下一环节」做不成）。
|
||
- P7 拆出的「确认与改判」档位＝**主屏常驻**；「归因结论」同样**主屏常驻**。
|
||
- P1 的「异常值提示」若③段决定把异常标进矩阵格子，档位从「可点入」降为**并入主视觉** ⇒ 回②段改档，⛔ ③段不能自己改档。
|
||
|
||
---
|
||
|
||
## 二、归③段的改动（形态与体验，③段自己定、自己负责改好）
|
||
|
||
### 2.1 逐页判形态（用 `layouts-tooling.md` §0 的「先判形态，再挑骨架」）
|
||
|
||
- P1：页面上能数出「并列的同类记录」（账号）⇒ 判**列表型**；但列表型里 §1 行式列表与 §2 表格式清单都不等于「一行一条」——**矩阵是表格式清单的一种排布**（轴转置：账号做行、日期做列），③段可以这么画，⛔ 不需要②段改块名。
|
||
- P2：并列同类记录（对标内容）⇒ 列表型；主视觉要不要带缩略图卡，是③段的视觉实现范畴。
|
||
- P3：并列条目 ＋ 单条详情 ⇒ **侧区型**（§4 主从侧区：列表↔详情两个工作面来回）。
|
||
- P4：围绕**单个对象**（一条内容）展开 ⇒ **详情型**（§3 详情面板）；七个环节轨道属于交互实现，归③段。
|
||
- P5：一稿多版并列 ⇒ 列表型（版本之间要对照，§2 表格式清单的高密度变体适用）。
|
||
- P6：单对象（一个账号）＋ 记忆流水 ⇒ 详情型 ＋ 时间线（时间线是③段的呈现选择）。
|
||
- P7：单条内容的表现与归因 ⇒ 详情型；表现数据做成数据主视觉是③段的视觉实现。
|
||
- P8：并列记录 ＋ 三样对账 ⇒ 列表型 ＋ 对照区。
|
||
|
||
### 2.2 ③段要补的版式档（现有 §0 只有三类，不够用）
|
||
|
||
`layouts-tooling.md` §0 现有形态只有 **列表型／详情型／侧区型** 三类，本产品至少要再补四类：
|
||
|
||
1. **矩阵型**（两个维度交叉的网格：账号 × 日期）—— P1 用。
|
||
2. **对照型**（同一母体的多个版本并排比较）—— P5、P8 用。
|
||
3. **流水线型**（多环节轨道 ＋ 当前环节工作区，可回退）—— P4 用。
|
||
4. **时间线型**（只追加、不覆盖的流水记录）—— P6 记忆条目用。
|
||
|
||
⛔ 补档要落在 `layouts-tooling.md`（③段自己的工具库），⛔ 不是回②段改。
|
||
⚠️ 它是**全局技能包**里的文件 ⇒ 改它会影响到别的工作区，动之前要由用户拍板（见主会话转出的待拍板项）。
|
||
|
||
### 2.3 体验上③段可以（也应当）主动改的
|
||
|
||
- 数据密度：现在是每块包成 24px 圆角白卡 ＋ 大留白，评审判定为「没认出品类」；③段有权把主视觉换成数据本身（紧凑行／列右对齐／颜色只用于涨跌与异常），⛔ 不需要②段批准。
|
||
- AI 生成中态：P4 新增的 AI 产出块，生成中显示进度与可中断、失败可重试，是交互行为范畴 ⇒ ③段定。
|
||
- 状态与空态：每一块的空态长什么样、加载中什么样，全部归③段。
|
||
- 响应式：窄屏怎么变，归③段（现有 B-15 那一条窄屏装不满 6 行，也属③段自己的账）。
|
||
|
||
---
|
||
|
||
## 三、执行顺序（按权责分头走）
|
||
|
||
1. **②段**（本方案 §一）：删形态措辞 → 给 AI 产出补块位 → 改相应分档。
|
||
2. **③段**（本方案 §二）：按新块名重判形态 → 补 `layouts-tooling.md` 的四个档 → 重做原型视觉与交互。
|
||
3. **机检基线同步**：`ui/_tools/check_skeleton.py` 现在拿旧骨架当权威，②段改完块名后必须同步，否则逐位比对会误报。
|
||
|
||
⛔ 顺序要点：**形态问题在③段解决，块级问题才回②段**。v1 把两件事都推给②段，是这次最大的偏差。
|