원클릭으로 Manus에서 모든 스킬 실행

data-architecture-spec

스타2

포크0

업데이트2026년 5월 16일 23:13

当需要设计数据架构时使用。数据架构设计规范产出，从PRD和API契约自动设计业务数据字典、ER模型、表结构、索引策略、缓存方案和数据迁移方案。内建业务数据字典提取确保数据标准统一。产出经人类审查后，交由data-architecture-impl生成代码。关键词：数据模型、ER图、表结构、索引、缓存策略、数据迁移、数据字典、建表、数据库设计。

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

LuckyOneTwoThree

LuckyOneTwoThree/vibe-skill-study

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

数据架构设计规范

核心原则

业务数据标准先行：从PRD提取业务数据字典，确保数据定义统一
范式与反范式平衡：写密集场景遵循3NF，读密集场景适度反范式
缓存有据：每个缓存项有明确的命中率目标和失效策略
迁移可回滚：每个迁移必须有对应的回滚脚本

交互模式

🤖→👤 AI建议人类审批

输入

输入项	类型	必填	来源	说明
PRD	markdown	是	output/pm-design/design-prd/prd.md	业务实体和关系需求
PRD结构化数据	JSON	是	output/pm-design/design-prd/prd.json	PRD机器可消费版本，包含entities[]/features[]，供数据模型设计编程式消费
API契约	YAML/JSON	是	output/backend-api-design/api-design-spec/openapi.yaml	接口数据结构定义
database_type	string	是	用户提供	数据库类型（PostgreSQL/MySQL/MongoDB/SQLite）
数据量预估	JSON	○	用户提供	核心表数据量级和增长速度
并发量预估	JSON	○	用户提供	QPS/TPS峰值和均值
当前Schema	SQL/JSON	○	用户提供	现有数据库表结构（增量项目必填）

执行步骤

Step 1: 业务数据字典提取

从PRD中提取业务数据实体定义，建立产品数据标准：

识别核心业务实体和属性
定义数据类型、约束和业务规则
建立实体间关系和引用完整性
生成业务数据字典（供下游消费）

阶段卡口：核心业务实体100%有数据字典定义

Step 2: 实体识别与关系建模

从PRD、API契约和数据字典中提取数据实体：

识别核心业务实体（名词提取）
确定实体间关系（1:1 / 1:N / N:M）
标注关系的基数和可选性
生成ER图

关系映射规则：

1:1 → 主表加外键 + UNIQUE约束
1:N → 子表加外键
N:M → 创建关联表

Step 3: 表结构与索引设计

为每个实体设计表结构（主键、外键、时间戳、软删除、状态字段等通用字段规范），设计索引策略和分库分表方案。

阶段卡口：ER图+DDL+数据字典完整

Step 4: 缓存策略设计

识别需要缓存的数据访问模式，设计多级缓存架构、一致性策略和穿透/击穿/雪崩防护。

阶段卡口：穿透/击穿/雪崩防护全覆盖

Step 5: 数据迁移方案

对比当前Schema和目标Schema，生成迁移脚本+回滚脚本+校验方案。新项目跳过此步骤。

阶段卡口：100%变更有回滚脚本，数据模型人类已确认

输出

元数据输出：output/backend-data-architecture/data-architecture-spec/

输出文件：

data_dictionary.json — 业务数据字典
er_model.json — ER模型+DDL+索引策略
cache_strategy.json — 缓存方案
migration_plan.json — 迁移方案（增量项目）
data-coverage.json — API对齐覆盖报告

决策规则

条件	决策
写密集场景	遵循3NF
读密集场景	适度反范式
读写比>10:1	高缓存价值
热点数据	多级缓存+预热
大表迁移	在线DDL或双写策略
多租户+租户数>100	共享数据库+tenant_id

质量检查

核心业务实体100%有数据字典定义
每个实体有完整的表结构设计
索引有明确的查询场景支撑
穿透/击穿/雪崩防护全覆盖
迁移脚本100%有回滚脚本
API数据需求100%有Model字段覆盖

降级策略

缺失的上游输入	降级方案	输出影响
API契约缺失	从PRD推导数据结构	数据模型可能不完整
PRD缺失	无法设计数据架构	输出为空
当前Schema缺失	仅设计新表结构，不生成迁移脚本	无迁移方案
并发量预估缺失	按中等并发设计缓存	缓存方案可能不足或过度
database_type未指定	默认PostgreSQL	SQL方言可能不兼容

上游变更响应

上游变更	影响范围	响应策略
PRD实体增删	数据模型+数据字典	标注受影响的实体，生成变更清单
API契约变更	表结构和索引	标注受影响的字段，评估迁移需求

이 저장소의 다른 Skills

같은 저장소

acquisition-orchestrator

LuckyOneTwoThree/vibe-skill-study

当需要评估获客渠道或优化获客漏斗时使用。用户获取指挥官，调度 acquisition-analysis（获客分析一体化），实现从渠道评估到漏斗优化的闭环。关键词：用户获取、获客渠道、漏斗优化、渠道评估、获客策略、acquisition-analysis、拉新、获客。

2026-05-162

activation-aha

LuckyOneTwoThree/vibe-skill-study

当需要识别和工程化Aha Moment时使用。Aha Moment自动工程化Pipeline，分析留存数据和行为数据，自动识别Aha Moment候选，测量到达率，识别最短路径，输出Onboarding优化建议。关键词：Aha Moment、激活时刻、用户激活、到达率、Onboarding优化、什么时候觉得好用、体验核心价值、爽点在哪。

2026-05-162

activation-onboarding

LuckyOneTwoThree/vibe-skill-study

当需要优化用户Onboarding流程时使用。Onboarding自动优化Pipeline，分析Onboarding数据和用户分群，自动生成个性化引导策略，设计A/B测试方案。关键词：Onboarding、新用户引导、引导优化、个性化引导、用户激活、新手引导、上手快、引导太长。

2026-05-162

activation-orchestrator

LuckyOneTwoThree/vibe-skill-study

当需要识别Aha Moment或设计Onboarding流程时使用。用户激活指挥官，调度activation-aha/onboarding。关键词：用户激活、Aha Moment、Onboarding、新用户引导、新手引导、激活率。

2026-05-162

agile-orchestrator

LuckyOneTwoThree/vibe-skill-study

当需要管理Sprint周期或追踪敏捷执行时使用。敏捷执行指挥官，调度 agile-sprint-planning、agile-daily-sync、agile-review 子Skill执行。agile-review 已合并 retrospective-auto 的自动回顾能力。关键词：敏捷执行、Sprint规划、每日站会、Sprint评审、敏捷管理、Sprint复盘、迭代复盘、敏捷开发、复盘报告、自动回顾。

2026-05-162

agile-review

LuckyOneTwoThree/vibe-skill-study

当需要自动化Sprint评审和复盘报告时使用。Sprint评审与复盘报告一体化，Step 1完成Sprint评审（产出清单整理、Demo准备清单、反馈收集分类、数据收集、问题识别、改进建议生成），Step 2生成完整复盘报告（Sprint目标达成分析、交付质量评估、团队速率趋势、改进行动项、下一Sprint建议），Step 3完成上线复盘（效果复盘、工程质量复盘、过程复盘、改进行动项生成）。关键词：Sprint Review、Sprint Retro、迭代评审、迭代回顾、敏捷复盘、评审会、复盘报告、Sprint复盘、改进行动项、做得怎么样、上线复盘、发布复盘、效果评估、持续改进。

2026-05-162

name	data-architecture-spec
description	当需要设计数据架构时使用。数据架构设计规范产出，从PRD和API契约自动设计业务数据字典、ER模型、表结构、索引策略、缓存方案和数据迁移方案。内建业务数据字典提取确保数据标准统一。产出经人类审查后，交由data-architecture-impl生成代码。关键词：数据模型、ER图、表结构、索引、缓存策略、数据迁移、数据字典、建表、数据库设计。
metadata	{"module":"后端架构与开发","sub-module":"数据架构","type":"pipeline","version":"4.0","domain_tags":["电商","金融","SaaS","通用"],"trigger_examples":["设计数据库表","建表和索引","系统响应慢怎么加缓存","Redis缓存怎么设计","改表结构","数据库升级"],"interaction_mode":"ai_suggest_human_approve"}

数据架构设计规范

核心原则

业务数据标准先行：从PRD提取业务数据字典，确保数据定义统一
范式与反范式平衡：写密集场景遵循3NF，读密集场景适度反范式
缓存有据：每个缓存项有明确的命中率目标和失效策略
迁移可回滚：每个迁移必须有对应的回滚脚本

交互模式

🤖→👤 AI建议人类审批

输入

输入项	类型	必填	来源	说明
PRD	markdown	是	output/pm-design/design-prd/prd.md	业务实体和关系需求
PRD结构化数据	JSON	是	output/pm-design/design-prd/prd.json	PRD机器可消费版本，包含entities[]/features[]，供数据模型设计编程式消费
API契约	YAML/JSON	是	output/backend-api-design/api-design-spec/openapi.yaml	接口数据结构定义
database_type	string	是	用户提供	数据库类型（PostgreSQL/MySQL/MongoDB/SQLite）
数据量预估	JSON	○	用户提供	核心表数据量级和增长速度
并发量预估	JSON	○	用户提供	QPS/TPS峰值和均值
当前Schema	SQL/JSON	○	用户提供	现有数据库表结构（增量项目必填）

执行步骤

Step 1: 业务数据字典提取

从PRD中提取业务数据实体定义，建立产品数据标准：

识别核心业务实体和属性
定义数据类型、约束和业务规则
建立实体间关系和引用完整性
生成业务数据字典（供下游消费）

阶段卡口：核心业务实体100%有数据字典定义

Step 2: 实体识别与关系建模

从PRD、API契约和数据字典中提取数据实体：

识别核心业务实体（名词提取）
确定实体间关系（1:1 / 1:N / N:M）
标注关系的基数和可选性
生成ER图

关系映射规则：

1:1 → 主表加外键 + UNIQUE约束
1:N → 子表加外键
N:M → 创建关联表

Step 3: 表结构与索引设计

为每个实体设计表结构（主键、外键、时间戳、软删除、状态字段等通用字段规范），设计索引策略和分库分表方案。

阶段卡口：ER图+DDL+数据字典完整

Step 4: 缓存策略设计

识别需要缓存的数据访问模式，设计多级缓存架构、一致性策略和穿透/击穿/雪崩防护。

阶段卡口：穿透/击穿/雪崩防护全覆盖

Step 5: 数据迁移方案

对比当前Schema和目标Schema，生成迁移脚本+回滚脚本+校验方案。新项目跳过此步骤。

阶段卡口：100%变更有回滚脚本，数据模型人类已确认

输出

元数据输出：output/backend-data-architecture/data-architecture-spec/

输出文件：

data_dictionary.json — 业务数据字典
er_model.json — ER模型+DDL+索引策略
cache_strategy.json — 缓存方案
migration_plan.json — 迁移方案（增量项目）
data-coverage.json — API对齐覆盖报告

决策规则

条件	决策
写密集场景	遵循3NF
读密集场景	适度反范式
读写比>10:1	高缓存价值
热点数据	多级缓存+预热
大表迁移	在线DDL或双写策略
多租户+租户数>100	共享数据库+tenant_id

质量检查

核心业务实体100%有数据字典定义
每个实体有完整的表结构设计
索引有明确的查询场景支撑
穿透/击穿/雪崩防护全覆盖
迁移脚本100%有回滚脚本
API数据需求100%有Model字段覆盖

降级策略

缺失的上游输入	降级方案	输出影响
API契约缺失	从PRD推导数据结构	数据模型可能不完整
PRD缺失	无法设计数据架构	输出为空
当前Schema缺失	仅设计新表结构，不生成迁移脚本	无迁移方案
并发量预估缺失	按中等并发设计缓存	缓存方案可能不足或过度
database_type未指定	默认PostgreSQL	SQL方言可能不兼容

上游变更响应

上游变更	影响范围	响应策略
PRD实体增删	数据模型+数据字典	标注受影响的实体，生成变更清单
API契约变更	表结构和索引	标注受影响的字段，评估迁移需求