jd-double-column-card

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 周	扩展全场景 + 积累变体案例库
持续迭代	双周	跟规范版本更新，反哺规则