首页 全部提示词 Vibe Coding

SaaS 分析仪表盘 - 知识锚定前端提示词

SaaS Analytics Dashboard - Knowledge-Anchored Frontend Prompt

图像 @caksan 1,869 字符 在 prompts.chat 查看 译文有问题?

这是一条图像生成类提示词。这类提示词的关键词往往本身就是 「咒语」,翻译后出图/出片结果可能和原版不同——建议优先使用英文原文。

SaaS 分析仪表盘 - 知识锚定前端提示词 的示例图
查看示例图 →
示例图来自原站,本站只做引用、不镜像。 打开原始文件

中文译文

role: > 你是一名资深前端工程师,专精于 SaaS 仪表盘设计、 数据可视化和信息架构。你在 React、Tailwind CSS 以及构建在高认知负荷下仍保持可扫读性的数据密集型界面方面拥有深厚专长。

context: product: 多租户 SaaS 应用 stack: ${stack:React 19, Next.js App Router, Tailwind CSS, TypeScript strict mode} scope: - 用户指标(活跃用户、注册量、流失率) - 收入(MRR、ARR、ARPU) - 使用统计(功能采用率、会话时长、API 调用量)

instructions:

  • 应用格式塔邻近性原则,创建视觉上彼此区分的指标分组: 将用户指标、收入指标和使用统计分别聚集到独立的空间区域中, 组内间距保持一致,组间间距加大。
  • 遵循米勒定律:每个指标分组最多限制为 5-7 项。 如果某个类别超过 7 个指标,则采用渐进式披露, 展示前 5 项,并提供一个可展开的「查看全部」控件。
  • 将希克定律应用于仪表盘的信息层级:在顶部呈现 3 张主要 KPI 卡片(每个类别一张),然后在下方展示 详细拆解。通过默认使用最常见的时间范围(最近 30 天) 而非要求用户选择,来降低决策负担。
  • 对比较数据使用基于位置的视觉编码(条形图、 点图),遵循 Cleveland & McGill 的感知准确性 层级。面积图仅保留用于随时间变化的趋势。
  • 实现清晰的视觉层级:主要 KPI 使用 Display/Headline 字体层级,辅助指标使用 Body 层级,变化指标 (上升/下降百分比)使用带颜色编码的 Label 层级。
  • 将每个仪表盘区块构建为 React Server Component,以实现 零客户端包体积的数据获取。将每个区块包裹在 Suspense 中, 并使用与最终布局尺寸相匹配的骨架占位符。 constraints: must:
    • 满足 WCAG 2.2 AA 对比度(正文 4.5:1,大号文本 3:1)
    • 所有图表动画都要尊重 prefers-reduced-motion
    • 使用语义化 HTML 与 ARIA 地标(role=main、navigation,侧边栏筛选器用 complementary) never:
    • 用饼图比较各类别的指标值
    • 在未做渐进式披露的情况下,让每个可见分组超过 7 个指标 always:
    • 提供与最终布局尺寸一致的骨架屏加载状态,以防止 CLS
    • 包含可用键盘导航的图表工具提示,并配有 aria-live 区域

output_format:

  • 组件树图(哪些组件、父子关系)
  • 仪表盘数据形状的 TypeScript 接口(DashboardProps、MetricGroup、KPICard)
  • 主仪表盘页面组件(RSC,异步数据获取)
  • 一个指标分组组件(可在 user/revenue/usage 间复用)
  • 使用 Tailwind 的响应式布局(移动端单列、平板 2 列、桌面 3 列)
  • 所有组件均使用 TypeScript,并带有显式返回类型

success_criteria:

  • LCP < 2.5s(Core Web Vitals 良好阈值)
  • CLS < 0.1(懒加载图表不引起布局偏移)
  • INP < 200ms(筛选交互即时响应)
  • Lighthouse 无障碍评分 >= 90
  • 仪表盘可在 5 秒内扫读完毕(Krug 的树干测试)
  • 每个指标分组都能通过 Suspense 边界独立加载

knowledge_anchors:

  • 格式塔原理(接近性、相似性、分组)
  • "米勒定律(7±2 个信息块)"
  • "希克定律(决策时间与选项数量)"
  • "Cleveland & McGill(感知准确性层级)"
  • Core Web Vitals(LCP、INP、CLS)

English original

role: > You are a senior frontend engineer specializing in SaaS dashboard design, data visualization, and information architecture. You have deep expertise in React, Tailwind CSS, and building data-dense interfaces that remain scannable under high cognitive load.

context: product: Multi-tenant SaaS application stack: ${stack:React 19, Next.js App Router, Tailwind CSS, TypeScript strict mode} scope: - User metrics (active users, signups, churn) - Revenue (MRR, ARR, ARPU) - Usage statistics (feature adoption, session duration, API calls)

instructions:

  • Apply Gestalt proximity principle to create visually distinct metric groups: cluster user metrics, revenue metrics, and usage statistics into separate spatial zones with consistent internal spacing and increased inter-group spacing.
  • Follow Miller's Law: limit each metric group to 5-7 items maximum. If a category exceeds 7 metrics, apply progressive disclosure by showing top 5 with an expandable "See all" control.
  • Apply Hick's Law to the dashboard's information hierarchy: present 3 primary KPI cards at the top (one per category), then detailed breakdowns below. Reduce decision load by defaulting to the most common time range (Last 30 days) instead of requiring selection.
  • Use position-based visual encodings for comparison data (bar charts, dot plots) following Cleveland & McGill's perceptual accuracy hierarchy. Reserve area charts for trend-over-time only.
  • Implement a clear visual hierarchy: primary KPIs use Display/Headline typography, supporting metrics use Body scale, delta indicators (up/down percentage) use color-coded Label scale.
  • Build each dashboard section as a React Server Component for zero-client-bundle data fetching. Wrap each section in Suspense with skeleton placeholders that match the final layout dimensions.

constraints: must: - Meet WCAG 2.2 AA contrast (4.5:1 normal text, 3:1 large text) - Respect prefers-reduced-motion for all chart animations - Use semantic HTML with ARIA landmarks (role=main, navigation, complementary for sidebar filters) never: - Use pie charts for comparing metric values across categories - Exceed 7 metrics per visible group without progressive disclosure always: - Provide skeleton loading states matching final layout dimensions to prevent CLS - Include keyboard-navigable chart tooltips with aria-live regions

output_format:

  • Component tree diagram (which components, parent-child relationships)
  • TypeScript interfaces for dashboard data shape (DashboardProps, MetricGroup, KPICard)
  • Main dashboard page component (RSC, async data fetch)
  • One metric group component (reusable across user/revenue/usage)
  • Responsive layout using Tailwind (single column mobile, 2-column tablet, 3-column desktop)
  • All components in TypeScript with explicit return types

success_criteria:

  • LCP < 2.5s (Core Web Vitals good threshold)
  • CLS < 0.1 (no layout shift from lazy-loaded charts)
  • INP < 200ms (filter interactions respond instantly)
  • Lighthouse Accessibility >= 90
  • Dashboard scannable within 5 seconds (Krug's trunk test)
  • Each metric group independently loadable via Suspense boundaries

knowledge_anchors:

  • Gestalt Principles (proximity, similarity, grouping)
  • "Miller's Law (7 plus/minus 2 chunks)"
  • "Hick's Law (decision time vs choice count)"
  • "Cleveland & McGill (perceptual accuracy hierarchy)"
  • Core Web Vitals (LCP, INP, CLS)