| name | jd-double-column-card |
| description | 京东站内双列卡片「体验观察」Skill。输入「页面截图 + business_line（人工声明）」，输出「差异观察报告 + 体验设计视角评价」。不做纠错判决，做观察与讨论的抓手。面向 AI agent 执行。触发词：「双列卡审查」「双列卡体验观察」「双列卡差异分析」「页面级双列卡审查」「跨场景同物种识别」 |
| version | 0.5.2 |
| owner | Shaka |
| created | 2026-04-14T00:00:00.000Z |
| updated | 2026-04-14T00:00:00.000Z |
| status | WIP |
| entry_for_agents | prompts/page-level-review.md |
京东站内双列卡片 - 体验观察 Skill
一、定位
京东 App 是多业务线共生的超级平台。多业务线各自做双列卡变体，导致站内体验割裂。本 Skill 帮助设计团队发现"哪些地方不一样"，并从体验设计视角理解这种不一样的代价。
定位（v0.3 后锁定）：观察 / 评价 — 不是 审查 / 纠错。
| 旧定位 | 新定位 |
|---|
| 列违规项，判 P0/P1/P2 | 列差异观察 + 体验视角评价 |
| "你错了请修复" | "这里不一样；可能有 X 问题，也可能有 Y 业务合理性——请讨论" |
| 审查员 | 观察者 + 顾问 |
| 输出 = 判决 | 输出 = 讨论的抓手 |
二、核心架构
2.1 五大家族体系
京东双列卡分五大家族，家族身份由底部不变量锚定（L1-5 核心规约）。
| 家族 | 心理锚点 | 底部 DNA |
|---|
| 内容 | UGC 信任 + 社交证明 | 头像 + 昵称 + 互动 |
| 商品 | 商家背书 + 销量证明 | 店铺 logo + 店铺名 + 销售数据 |
| 圈子 | 集体归属感 | 圈子图标 + 圈子名（无作者无互动） |
| 点评 | UGC + 决策证明 | 头像 + 昵称 + 互动 + 标题下种草数 |
| 新品 | 事件 / 活动 / 趋势驱动 | 按子类型变化（CTA / 事件胶囊 / 挂载 / 话题） |
详见 references/business-baselines.md 第一节。
2.2 规则分层：L1（大规范）+ L2（家族专属）
所有卡都走 L1；按 card_type 的家族再走对应 L2。
L1 大规范（9 条跨家族规约）
源于 references/layout.md 第二节和 references/business-baselines.md 第二节。所有双列卡必须走，无差别：
- L1-1 左上角 = 卡片属性表达位
- L1-2 右上角 = 辅助信号位（可为空）
- L1-3 标题下方 = 关于"内容"的元信息位
- L1-4 商品挂载浮条位置 = 反映叙事方向
- L1-5 底部不变量 = 家族 DNA 锚定（最核心）
- L1-6 内容卡右下互动信号位可切换
- L1-7 封面浮层 = 决策信息前置位（描述性）
- L1-8 梯度叠加封面 = 封面结构类型（描述性）
- L1-9 昵称旁 = 关于"人"的元信息位
L2 家族专属（按家族分支）
| 家族 | L2 规则源 |
|---|
| 内容 | component.md 第二/三/四/六节 |
| 点评 | component.md 基础 + business-baselines.md 第 3.4 节 |
| 圈子 | business-baselines.md 第 3.3 节 |
| 商品 | L2 待补（当前只走 L1） |
| 新品 | business-baselines.md 第 3.5 节（按子类型分） |
2.3 双标签协议
business_line（页面 / 流级）= 人工显式声明（调用方给）
- 枚举：
推荐 | 点评 | 圈子 | 新品 | 个人中心 | 直播
card_type（单卡级）= Skill 视觉识别（VLM 的天职，不依赖 tab 或 URL）
为什么分两层：页面内 tab 命名会变（JoyAI、求真官等都是易变命名），用可变信号做业务分类不稳定。把易变环节交给人工输入，让 Skill 保持稳定。
三、核心原则
原则 1：家族识别先于规则比对 ★ v0.5 新增
Skill 必须先识别家族，再套规则。按"底部 → 封面 → 左上角"顺序识别。同一条规则应用到不同家族可能是不同的合法值（比如"头像"在内容/点评家族必选，在圈子/商品/新品家族不展示）。
原则 2：偏离即差异观察（不是违规判决）
对照规约识别差异。不说"违规"，说"差异"+"体验代价"。每个差异配：
- 差异描述
- 体验视角评价（从维度工具箱选 1 个最贴切的讲透）
- 可能的业务合理理由
- 讨论建议
原则 3：跨场景同物种识别 ★ 变体评价核心
一张双列卡从场景 A 搬到场景 B，用户能否在 0.5 秒内无障碍识别它是同一物种？
- 能 → 通过（即便有差异）
- 不能 → 认知负担，需讨论
变体评价的一票否决标准。详见 references/variant-evaluation.md。
原则 4：创新的举证责任倒置
标准卡默认通过。创新卡 / 变体需要举证它创造了对等以上的用户价值。
原则 5：流级信息类型一致性
同一流的所有卡最好属于同一信息类型家族。视觉合规只是底线，叙事一致性才是体验。
原则 6：识别深度匹配规范深度
Skill 不做比规范更细的判定。业务方没规范的地方（梯度叠加每层、明星同款的具体趋势元素等），Skill 不下钻。
原则 7：结构优先、内容无涉 ★ v0.5.2 新增
Skill 只观察设计师规范可控的结构性元素，不观察用户/运营上传的内容层。
观察范围（Structure）：
- 框体尺寸、圆角、间距、栅格
- 字号、字重、颜色 token
- 组件有无（头像、标签、互动数据等）
- 元素位置（左上/右上/标题下/底部）
- 层级结构
不观察（Content）：
- 封面图具体内容、构图、比例偏向（偏横/偏方都不判定为差异）
- 标题具体文案（只看字数合规性，不评价写得好不好）
- 头像具体图像
- 运营配图色彩倾向
- 用户/运营上传的任何内容层表达
理由：
- 用户上传/运营配图是设计师无法强控制的内容层
- 规范只能约束"框"的维度，不能约束"画里的内容"
- 如果把内容层也纳入观察，报告会充斥"这张图比例偏横"这种无法修复的伪差异
例外：图片比例明显超出规范值域（比如 1:2 极端比例，属于规范违规）要报；同一值域内不同选择（3:4 vs 4:3）不属于差异。
原则 8：动态数据不作家族识别硬条件 ★ v0.5.2 新增
Skill 识别家族时，不能把"运行时数据"当成"结构标识"。
典型反例（v0.5.2 前的错误）：
- 错：把"标题下方有种草数"当成点评家族的必要条件
- 对：种草数是动态数据（0 人种草就不显示），不是结构标识
正确逻辑：
- 家族识别靠结构不变量（固定元素的存在与位置）
- 动态数据（种草数、观看量等）作为激活信号记录，不参与家族判定
详见 prompts/page-level-review.md Step 2a 决策树。
四、使用方式（三种工作流）
| 场景 | 典型触发语 | 执行模板 | 主要输入 |
|---|
| 页面级审查（生产主流） | "帮我审查这个页面的双列卡" | prompts/page-level-review.md | 1 张页面截图 + business_line |
| 单卡快检 | "这张截图有什么问题" | prompts/review-screenshots.md | 1~多张单卡截图 + business_line |
| 变体评估 | "这个新变体做同物种判定" | prompts/evaluate-variant.md | 变体截图 + 业务背景 |
如果 agent 只能读一个文件
读 prompts/page-level-review.md（自包含执行契约，Step 0-6 完整算法 + 家族决策树 + 报告模板）。
输入协议（所有工作流共用）
business_line: <enum>
page_screenshot/screenshots:
page_name: <string>
version: <string>
focus: <string>
缺失 business_line 或截图 → 拒绝执行，不推断。
五、目录导览
jd-double-column-card/
├── SKILL.md # 本文件：定位 + 架构 + 原则 + 工作流入口
├── references/
│ ├── business-baselines.md # ★ 真相源：五大家族 + 22 基线 + 9 条 L1 规约 + 家族决策树
│ ├── layout.md # L1 基础栅格与跨家族规约
│ ├── component.md # L2 内容家族结构规范
│ ├── variant-evaluation.md # 变体评估协议（100 分制 + 豁免流程）
│ ├── site-map.md # business_line + card_type 双标签体系 + 家族决策树
│ ├── competitors.md # 竞品对比（小红书/抖音/INS/大众点评/美团/淘宝逛逛）
│ ├── jd-15-spec.md # 15.0 内部规范（空壳，待注入）
│ └── changelog.md # 完整变更史（v0.1 → v0.5）
├── prompts/
│ ├── page-level-review.md # ★ 页面级审查执行契约（agent 主入口）
│ ├── review-screenshots.md # 单卡快检模板
│ └── evaluate-variant.md # 变体评估模板
└── reports/ # 历史审查报告留痕
└── 2026-04-14-first-review.md
冲突处理
- 数值冲突：以
jd-15-spec.md 为准（注入后），其他文件相应更新
- 原则冲突：以本文件为准，细则服从原则
- 每次规范变更：在
changelog.md 留痕
六、执行边界（诚实标注）
本 Skill 能做
- 家族识别（视觉识别家族 + 子类型 + 媒介属性）
- L1 跨家族规约差异观察
- L2 家族专属规则观察（内容/点评/圈子/新品家族）
- 变体模式发现 + 跨场景同物种识别
- 流级信息类型一致性观察
- 规范反哺建议
本 Skill 不做
- 业务判断：该不该加引导、流程该几步、页面该不该上双列
- 动态行为：加载态、错误态、空态、操作反馈（静态截图看不到）
- 真实用户数据：CTR、停留时长、转化率（需业务数据团队）
- L2 规范不覆盖的家族细则：商品家族 L2 待补，目前只走 L1
- 官方权威裁决：本 Skill 是辅助，最终裁决权在设计系统 owner / 评审委员会
七、专项阶段与本 Skill
| 阶段 | 周期 | 本 Skill 角色 |
|---|
| P0 规范制定 | 第 1-4 周 | 承载规范 + 提供查询/审查接口 |
| P1 试点落地 | 第 5-8 周 | 半自动审查 + 验证规则准确性 |
| P2 全量推广 | 第 9-16 周 | 扩展全场景 + 积累变体案例库 |
| 持续迭代 | 双周 | 跟规范版本更新，反哺规则 |
