القائمة
京东站内双列卡片「体验观察」Skill。输入「页面截图 + business_line（人工声明）」，输出「差异观察报告 + 体验设计视角评价」。不做纠错判决，做观察与讨论的抓手。面向 AI agent 执行。触发词：「双列卡审查」「双列卡体验观察」「双列卡差异分析」「页面级双列卡审查」「跨场景同物种识别」
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| 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 |
京东 App 是多业务线共生的超级平台。多业务线各自做双列卡变体，导致站内体验割裂。本 Skill 帮助设计团队发现"哪些地方不一样"，并从体验设计视角理解这种不一样的代价。
定位（v0.3 后锁定）：观察 / 评价 — 不是 审查 / 纠错。
| 旧定位 | 新定位 |
|---|---|
| 列违规项，判 P0/P1/P2 | 列差异观察 + 体验视角评价 |
| "你错了请修复" | "这里不一样；可能有 X 问题，也可能有 Y 业务合理性——请讨论" |
| 审查员 | 观察者 + 顾问 |
| 输出 = 判决 | 输出 = 讨论的抓手 |
京东双列卡分五大家族，家族身份由底部不变量锚定（L1-5 核心规约）。
| 家族 | 心理锚点 | 底部 DNA |
|---|---|---|
| 内容 | UGC 信任 + 社交证明 | 头像 + 昵称 + 互动 |
| 商品 | 商家背书 + 销量证明 | 店铺 logo + 店铺名 + 销售数据 |
| 圈子 | 集体归属感 | 圈子图标 + 圈子名（无作者无互动） |
| 点评 | UGC + 决策证明 | 头像 + 昵称 + 互动 + 标题下种草数 |
| 新品 | 事件 / 活动 / 趋势驱动 | 按子类型变化（CTA / 事件胶囊 / 挂载 / 话题） |
详见 references/business-baselines.md 第一节。
所有卡都走 L1；按 card_type 的家族再走对应 L2。
源于 references/layout.md 第二节和 references/business-baselines.md 第二节。所有双列卡必须走，无差别：
| 家族 | L2 规则源 |
|---|---|
| 内容 | component.md 第二/三/四/六节 |
| 点评 | component.md 基础 + business-baselines.md 第 3.4 节 |
| 圈子 | business-baselines.md 第 3.3 节 |
| 商品 | L2 待补（当前只走 L1） |
| 新品 | business-baselines.md 第 3.5 节（按子类型分） |
business_line（页面 / 流级）= 人工显式声明（调用方给）
推荐 | 点评 | 圈子 | 新品 | 个人中心 | 直播card_type（单卡级）= Skill 视觉识别（VLM 的天职，不依赖 tab 或 URL）为什么分两层：页面内 tab 命名会变（JoyAI、求真官等都是易变命名），用可变信号做业务分类不稳定。把易变环节交给人工输入，让 Skill 保持稳定。
Skill 必须先识别家族，再套规则。按"底部 → 封面 → 左上角"顺序识别。同一条规则应用到不同家族可能是不同的合法值（比如"头像"在内容/点评家族必选，在圈子/商品/新品家族不展示）。
对照规约识别差异。不说"违规"，说"差异"+"体验代价"。每个差异配：
一张双列卡从场景 A 搬到场景 B，用户能否在 0.5 秒内无障碍识别它是同一物种？
- 能 → 通过（即便有差异）
- 不能 → 认知负担，需讨论
变体评价的一票否决标准。详见 references/variant-evaluation.md。
标准卡默认通过。创新卡 / 变体需要举证它创造了对等以上的用户价值。
同一流的所有卡最好属于同一信息类型家族。视觉合规只是底线，叙事一致性才是体验。
Skill 不做比规范更细的判定。业务方没规范的地方（梯度叠加每层、明星同款的具体趋势元素等），Skill 不下钻。
Skill 只观察设计师规范可控的结构性元素，不观察用户/运营上传的内容层。
观察范围（Structure）：
不观察（Content）：
理由：
例外：图片比例明显超出规范值域（比如 1:2 极端比例，属于规范违规）要报；同一值域内不同选择（3:4 vs 4:3）不属于差异。
Skill 识别家族时，不能把"运行时数据"当成"结构标识"。
典型反例（v0.5.2 前的错误）：
正确逻辑：
详见 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 | 变体截图 + 业务背景 |
读 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 角色 |
|---|---|---|
| P0 规范制定 | 第 1-4 周 | 承载规范 + 提供查询/审查接口 |
| P1 试点落地 | 第 5-8 周 | 半自动审查 + 验证规则准确性 |
| P2 全量推广 | 第 9-16 周 | 扩展全场景 + 积累变体案例库 |
| 持续迭代 | 双周 | 跟规范版本更新，反哺规则 |