⚡ 核心产品扩展

从单项目工作台
到全栈系统描述平台

我们已经能支持单个项目的原型-后台-建模-文档生成。但大型项目是云-数据中台-微服务-子系统这样的复杂架构，本设计将工作台扩展为双形态项目的统一管理平台，覆盖从基础设施到业务系统的全栈。

🎬

⭐ 强烈推荐 · 先看动线

用户体验动线

22 步 · 8 幕 · 涵盖架构师 + 开发者双角色
包含新功能 + 现有工作台，完整感受产品升级后的最终形态

📅 2026-09-04 📐 v1.5 ⏱️ 4.5 - 5.5 个月 🎯 5 个 Phase

设计哲学

"工作台不只是界面原型工具，
它是系统全栈的描述工具。"

—— v1.2.1 的核心转向

💡 关键洞察

原有工作台假设"项目 = 有界面的可交互系统"，因此所有功能（页面原型、跳转图、后台生成）都建立在有页面这一前提上。但在企业级集群中，云基础设施、微服务、数据中台这些底层系统可能没有 UI，只有服务能力。

三个核心立场

🖥️

双形态项目

有界面项目（page-based）继续走原有工作台；无界面项目（service-only）走新的"服务详情页"。两种形态在集群视角下统一管理。

🤝

能力契约

跨层关系不是"模块直连"，而是下层暴露能力、上层消费能力。能力是稳定契约，模块是变化实现。

🎯

双重定位

基础项目面向极简用户（5 分钟生成原型）；项目集群面向架构师用户（系统治理、影响分析）。功能分层，复杂度可选。

概览

核心洞察：项目形态二分

在企业级集群中，项目分为两种本质不同的形态：

🖥️

有界面项目 (page-based)

有 HTML 页面原型
有 C端/管理后台等端
有跳转图、流程图、时序图
可生成 amis 后台
文档含截图

→ 现有项目（旅行票根、邻里换物）

⚙️

无界面项目 (service-only)

无页面，只有服务能力
有 capabilities（能力契约）
有 apiContract（OpenAPI）
有 runtime（运行时配置）
可被其他项目消费

→ 新增形态（用户中心、MySQL、K8s）

典型集群示例

L4 · 应用系统层

🖥️ 订单系统

🖥️ 客服系统

🖥️ 营销系统

↕ 跨层依赖

L3 · 微应用层

⚙️ 用户中心

⚙️ 支付中心

⚙️ 消息中心

↕ 跨层依赖

L2 · 数据中台

⚙️ 用户画像

⚙️ 交易数据

⚙️ 日志平台

↕ 跨层依赖

L1 · 云基础设施

⚙️ MySQL

⚙️ Redis

⚙️ K8s 集群

核心概念

概念	定义	示例
项目集群 (Cluster)	一组共享技术底座和数据的关联项目集合	"企业级业务平台"
架构层 (Layer)	集群内的逻辑分层，代表不同的技术/职责层级	云基础设施 / 数据中台 / 微应用层 / 应用系统层
能力 (Capability)	下层项目对外暴露的服务/功能单元	"用户认证能力"、"支付能力"
能力依赖 (Dependency)	上层项目消费下层能力的关联关系	订单系统 → 用户认证能力
共享实体 (Shared Entity)	集群级别共享的数据模型	User, Order, Product
能力版本 (Capability Version)	能力的某个发布版本，支持多版本共存	用户认证 v1.0, v2.0-beta
集群模板 (ClusterTemplate)	预定义的架构层结构模板	"微服务标准架构", "数据中台架构"
自动依赖检测 (Auto Dependency)	从数据模型引用自动推断跨层依赖	检测到 Order → User → 用户认证

目标用户分层

基于复核意见，本方案明确采用 双重定位、分阶段推进 的产品策略：

🧑‍💻 极简用户

小班/工作室/产品经理/独立开发者

核心诉求：5 分钟生成原型，快速验证想法
对应功能：基础项目（已有）

🏗️ 架构师用户

企业架构师/技术负责人/系统规划者

核心诉求：复杂系统分层、能力治理、影响分析
对应功能：项目集群（本次扩展）

📐 功能边界

能力版本管理、自动依赖检测、集群模板等功能列为可选，通过开关控制。核心功能（集群 CRUD、分层架构、跨层关系可视化）优先实现，不强制所有用户面对企业级复杂度。

数据模型

集群核心结构

// Cluster 数据模型核心
{
  id: 'cluster-xxx',
  name: '企业级业务平台',
  type: 'cluster',
  desc: '描述...',

  // 架构层
  layers: [
    { id: 'L1', name: '云基础设施', order: 0 },
    { id: 'L2', name: '数据中台',   order: 1 },
    { id: 'L3', name: '微应用层',   order: 2 },
    { id: 'L4', name: '应用系统层', order: 3 }
  ],

  // 项目归属（含形态）
  projectLayers: [
    { projectId: 'p-user',  layerId: 'L3', projectType: 'service-only' },
    { projectId: 'p-order', layerId: 'L4', projectType: 'page-based' }
  ],

  // 共享数据模型
  sharedEntities: [
    { name: 'User', label: '用户', fields: [...] }
  ],

  // 能力注册表
  capabilities: [
    {
      id: 'cap-user-auth',
      name: '用户认证',
      provider: { projectId: 'p-user', moduleId: 'm-auth' },
      currentVersion: '2.0',
      versions: [
        { version: '1.0', status: 'deprecated' },
        { version: '2.0', status: 'stable' }
      ]
    }
  ],

  // 能力依赖关系
  dependencies: [
    {
      consumer: { projectId: 'p-order' },
      capabilityId: 'cap-user-auth',
      capabilityVersion: '2.0',
      detectedBy: 'manual'
    }
  ]
}

Project 扩展（双形态）

{
  id: 'p-user-service',
  name: '用户中心服务',
  clusterId: 'cluster-xxx',
  layerId: 'L3',
  projectType: 'service-only',  // 关键字段

  // 有界面项目
  pages: [...],
  ends: [...],
  diagram: {...},

  // 无界面项目（v1.2 新增）
  capabilities: [...],   // 能力列表
  apiContract: {...},     // OpenAPI
  runtime: {
    type: 'microservice',
    framework: 'Spring Boot',
    port: 8080
  }
}

实体关系图

Cluster ──1:N──→ Layer Cluster ──1:N──→ SharedEntity Cluster ──1:N──→ Capability ──1:N──→ CapabilityVersion Cluster ──1:N──→ Dependency Cluster ──1:0──→ ClusterTemplate (created from) Project ──N:1──→ Cluster Project ──N:1──→ Layer Project ──1:N──→ Capability (as provider) SharedEntity ──N:N──→ Project (referenced by) Dependency.consumer ──N:1──→ Module (上层) Dependency.capabilityId ──N:1──→ Capability (下层)

用户交互

工作台导航

集群管理页面是工作台的新顶层入口，与现有"项目库"并列：

工作台

📁

项目库 （现有）

└ 平面列表 + 分组

🏢

集群列表 新增

└ 集群卡片网格

集群工作台（核心形态）

企业级业务平台 · 集群工作台

[总览] [分层架构] [能力依赖] [共享实体] [文档]

架构层

项目（双形态）

能力

跨层依赖

分层摘要

🖥️ L4 订单系统（8 页面）· 客服系统（5 页面）· 营销系统（6 页面）

⚙️ L3 用户中心（5 能力）· 支付中心（3 能力）· 消息中心（2 能力）

⚙️ L2 用户画像· 交易数据· 日志平台

⚙️ L1 MySQL· Redis· K8s 集群

创建流程

点击「新建项目」 │ ├── 选择项目类型 │ ├── ○ 单一项目 │ └── ● 项目集群 │ ├── 选择创建方式 │ │ ├── ○ 从模板创建 │ │ │ └── 🏗️ 微服务标准架构 (4 层) │ │ │ 📊 数据中台架构 (3 层) │ │ │ 🌐 全栈应用架构 (3 层) │ │ │ 📱 移动端架构 (3 层) │ │ │ 📋 我的模板 (自定义) │ │ └── ● 自定义创建 │ │ └── 架构层数 [4] 层 │ ├── 输入集群名称 │ └── 创建集群 → 进入集群工作台

服务详情页（无界面项目新形态）

无界面项目不再套用现有项目工作台，而是新形态：

用户中心服务 ⚙️ service-only · L3 微应用层

[总览] [能力] [API契约] [运行时] [依赖] [文档]

服务描述

提供统一用户认证、用户画像、权限校验

技术栈

Spring Boot 3.x + PostgreSQL

健康度

🟢 Healthy · Uptime 99.9% · 平均延迟 50ms

能力列表

用户认证 v2.0

用户画像 v1.0

权限校验 v1.0

运行时

Type: microservice
Framework: Spring Boot 3.2
Port: 8080
Health: GET /health
Image: registry.example.com/user-service:1.2.0
Replicas: 3
Resources: cpu 500m, memory 1Gi

可视化设计

集群视角的图表体系

现有图表（architecture/flowchart/sequence/swimlane）都假设"有页面"。集群视角需要新的图表体系：

图表类型	有界面项目	无界面项目	适用场景
分层架构图	✅	✅	集群全局概览
能力依赖矩阵	✅	✅	跨层依赖分析
服务依赖图	△	✅	微服务调用关系
部署拓扑图	△	✅	K8s 部署视图
数据流图	✅	✅	共享实体流向
现有 architecture 图	✅	❌	单项目内页面关系
现有 flowchart 图	✅	❌	单项目流程

分层架构图（适配双形态）

L4 · 应用系统层

🖥️ 订单系统 · 8页 / 3能力

🖥️ 客服系统 · 5页 / 1能力

🖥️ 营销系统 · 6页 / 2能力

↕ 跨层依赖（实线：同步调用，虚线：异步事件）

L3 · 微应用层

⚙️ 用户中心 · 5能力

⚙️ 支付中心 · 3能力

⚙️ 消息中心 · 2能力

↕ 跨层依赖

L2 · 数据中台

⚙️ 用户画像 · 3能力

⚙️ 交易数据 · 2能力

⚙️ 日志平台 · 1能力

↕ 跨层依赖

L1 · 云基础设施

⚙️ MySQL

⚙️ Redis

⚙️ K8s 集群

能力版本管理

支持多版本共存，每个能力有版本时间线：

// 能力版本管理
{
  id: 'cap-user-auth',
  name: '用户认证',
  currentVersion: '2.0',
  versions: [
    { version: '1.0', status: 'deprecated', releasedAt: '2025-01-15' },
    { version: '2.0', status: 'stable',     releasedAt: '2026-06-01' },
    { version: '2.1-beta', status: 'beta',  releasedAt: '2026-09-01' }
  ]
}

// 依赖绑定到特定版本
{
  consumer: { projectId: 'p-order' },
  capabilityId: 'cap-user-auth',
  capabilityVersion: '2.0'  // 绑定具体版本
}

技术方案

存储方案（明确本地局限）

⚠️ v1.2 调整

本方案明确限于本地原型阶段（基于 DSH 插件模型），不预设商业化多租户场景。商业化路径确定后，存储方案需整体重构。

集群数据与现有项目数据统一存储在 proto-projects.json 中：

{
  projects: [
    // 现有项目
    { id: 'pmtffk0vccbkh', name: '旅行票根', type: 'single', ... },

    // 集群项目（type = cluster）
    {
      id: 'cluster-xxx',
      name: '企业级业务平台',
      type: 'cluster',
      layers: [...],
      projectLayers: [...],
      capabilities: [...],
      dependencies: [...]
    }
  ]
}

适用范围：✅ 本地原型阶段、个人/小团队、单设备

不适用：❌ 多租户 SaaS、团队协作、版本控制、权限隔离

可视化技术

视图	技术方案	说明	v1.2 状态
分层架构图	自定义 SVG/Canvas	类似 swimlane，适配双形态	已适配
服务依赖图	ECharts Graph	服务调用关系	新增
部署拓扑图	自定义 SVG	K8s 风格	新增
数据流图	ECharts Sankey	共享实体流向	新增
Sankey 图	ECharts Sankey	能力依赖	保留
矩阵图	自定义表格	依赖矩阵	保留

RPC 接口清单

// 集群核心 RPC
proto_cluster_create          // 创建集群
proto_cluster_update          // 更新集群
proto_cluster_add_project      // 添加项目（指定形态）
proto_cluster_apply_template   // 应用模板创建

// 能力 RPC
proto_capability_create
proto_capability_create_version     // 创建能力版本
proto_capability_publish_version    // 发布版本
proto_capability_deprecate_version  // 弃用版本

// 依赖 RPC
proto_dependency_create
proto_dependency_auto_detect        // 触发自动检测
proto_dependency_review_suggestion  // 采纳/忽略建议

// 服务-only 项目 RPC（v1.2 新增）
proto_service_update_runtime        // 更新运行时
proto_service_update_api_contract    // 更新 API 契约
proto_service_list_deployments      // 列出部署

// 可视化 RPC
proto_dataflow_visualize           // 共享实体数据流
proto_topology_visualize           // 服务依赖拓扑

分阶段实施总览

真实周期估算：4.5 - 5.5 个月（17-22 周），分 5 个阶段。每个阶段有独立的目标、任务和完成标准：

Phase 1 · 基础骨架

4-5 周 · 工作台侧边栏 · 集群 CRUD · 双形态 · 服务详情页

工作台侧边栏集群入口 · 集群卡片网格 · 集群工作台多 Tab 框架 · 分层架构图（适配双形态） · 项目-层归属（含形态选择） · 服务详情页（无界面项目新形态）

Phase 2 · 能力契约

5-6 周 · 能力注册 · 依赖建模 · 三类新图

能力注册 · 依赖编辑器 · 分层架构图（含依赖线） · 服务依赖图 / 部署拓扑图 / 数据流图 · Sankey 矩阵视图 · 项目内跨层上下文

Phase 3 · 共享实体 & 高级能力

3-4 周 · 共享实体 · 影响分析 · 版本管理

共享实体定义 · 数据模型引用共享实体 · 影响分析 · 能力版本管理（可选） · 集群级文档导出

Phase 4 · 数据就绪 & 模板

3-4 周 · 数据迁移 · 模板系统

现有项目数据模型结构化迁移工具 · 引导用户声明 sharedEntityRefs · 自动依赖检测引擎（数据就绪后启用） · 集群模板系统 · 4 个内置模板

Phase 5 · 打磨 & 优化

2-3 周 · 性能 · 体验 · 高级功能

交互动画 · 大数据量性能优化 · 导入/导出集群配置 · 高级版本管理 · 跨集群关系（可选）

📅 排期演进

v1.0 排期 10-15 周 → v1.2 排期 15-20 周（4-5 个月）→ v1.2.1 排期 17-22 周（4.5-5.5 个月）。每次调整都更贴近真实工作量，避免过度承诺。

01 基础骨架工作台侧边栏 · 集群 CRUD · 双形态 · 服务详情页 · 4-5 周

▼

核心目标

💡 本阶段的核心交付

用户能创建集群、把现有项目加入集群指定层、能创建不同形态的项目（page-based / service-only）、能看到分层架构图。能力编辑、依赖建模、共享实体等更高级功能留给 Phase 2-4。

📁 双库导航

工作台侧边栏新增"集群列表"，与"项目库"并列。用户能在两个库之间切换。

🏗️ 集群 CRUD

完整的集群生命周期：创建（含层定义）、编辑、删除、查询。

🖥️⚙️ 双形态

page-based 项目进入现有工作台，service-only 项目进入新的服务详情页。

📊 分层架构图

静态展示集群的层结构和项目分布，跨层依赖线先预留（Phase 2 动态）。

🔧 服务详情页

无界面项目的新形态：服务描述、技术栈、API 契约、运行时配置。

📦 测试数据

1 个测试集群（4 层、6 项目），包含 2 个真实项目和 4 个 mock 服务项目。

明确边界：本阶段不做

⚠️ 范围控制

为了避免 Phase 1 失控，以下功能明确推迟到后续阶段：

不做的事	原因	推迟到
能力编辑 UI	依赖 apiContract 派生能力的设计验证	Phase 2
依赖建模	需要先有"能力"概念作为依赖目标	Phase 2
共享实体定义	需要先有项目归属基础	Phase 3
能力版本管理	v1.2 列为可选功能	Phase 3（可选）
集群模板	需要在有真实使用数据后设计	Phase 4
自动依赖检测	现有 ref: 仅 3 处，数据基础不足	Phase 5+
跨层依赖线（动态）	需要先有依赖数据	Phase 2
服务依赖图、部署拓扑图	需要先稳定服务详情页形态	Phase 2

排期总览

22 个任务分 4 周完成，每周五天工作日，外加 2 天缓冲用于联调与意外处理。

📅 Week 1

基础设施
数据模型 · 集群 CRUD · 侧边栏重构

📅 Week 2

集群工作台
多 Tab 框架 · 分层架构图 · 服务详情页

📅 Week 3

服务形态 + 测试
运行时配置 · 新建对话框 · 测试数据

📅 Week 4

联调 & 打磨
端到端测试 · UI 打磨 · 文档

线框图（8 张）

1️⃣ 新建项目对话框（类型选择）

用户点击"新建项目"后的第一个对话框，选择项目类型（单一项目 / 项目集群）。

新建项目对话框 · 类型选择

任务 9.1-9.3Day 13-14

2️⃣ 集群创建向导（层结构）

用户选择"项目集群"后进入的向导，定义层数和每层名称。

集群创建向导 · 层结构定义

任务 2.1-2.2Day 2-3

3️⃣ 集群列表页

工作台侧边栏切换到"集群列表"后的页面，显示所有集群卡片。

集群列表页

任务 4.1-4.4Day 4-5

导航

📁 项目库

🏢 集群列表

⚙️ 设置

+ 新建集群

集群列表

3 个集群

🏢 企业级业务平台

4 层 · 12 项目 · 28 能力 · 45 依赖

应用系统层 ████ ████ ████
微应用层 ████ ████ ████
数据中台 ████ ████ ████
云基础设施 ████ ████ ████

最后更新：3 天前

🏢 __test_测试集群

4 层 · 6 项目 · 0 能力 · 0 依赖

L4 应用系统层 ████ ████
L3 微应用层 ████ ████
L2 数据中台 ████
L1 云基础设施 ████

⚠️ 测试数据

4️⃣ 集群工作台（总览 Tab）

点击集群卡片进入的工作台，显示统计和分层摘要。

集群工作台 · 总览 Tab

任务 5.1-5.2Day 6-7

企业级业务平台 · 集群工作台

[← 返回集群列表]

总览

分层架构

能力依赖

共享实体

文档

架构层

项目

能力

依赖

分层摘要

🖥️ L4订单系统（8 页面）· 客服系统（5 页面）· 营销系统（6 页面）

⚙️ L3用户中心（5 能力）· 支付中心（3 能力）· 消息中心（2 能力）

⚙️ L2用户画像 · 交易数据 · 日志平台

⚙️ L1MySQL · Redis · K8s 集群

5️⃣ 分层架构图（静态）

集群工作台的"分层架构" Tab，按层展示项目分布（双形态）。

分层架构图 · 静态展示

任务 6.1-6.3Day 8-9

L4 · 应用系统层

🖥️ 订单系统 · 8页/3能力

🖥️ 客服系统 · 5页/1能力

🖥️ 营销系统 · 6页/2能力

↕ 跨层依赖（实线：同步调用，虚线：异步事件）

L3 · 微应用层

⚙️ 用户中心 · 5能力

⚙️ 支付中心 · 3能力

⚙️ 消息中心 · 2能力

↕ 跨层依赖（Phase 2 动态）

L2 · 数据中台

⚙️ 用户画像 · 3能力

⚙️ 交易数据 · 2能力

⚙️ 日志平台 · 1能力

↕ 跨层依赖（Phase 2 动态）

L1 · 云基础设施

⚙️ MySQL

⚙️ Redis

⚙️ K8s 集群

💡 Phase 1 静态展示。Phase 2 将添加动态跨层依赖线（贝塞尔曲线连接具体项目）

6️⃣ 服务详情页（service-only 项目）

无界面项目的新工作台形态。

服务详情页 · 用户中心服务

任务 7.1-7.3Day 10

⚙️

用户中心服务

service-only · L3 微应用层

总览

能力

API 契约

运行时

依赖

文档

服务描述

提供统一用户认证、用户画像、权限校验

技术栈

Spring Boot 3.x + PostgreSQL

健康度

🟢 Healthy · Uptime 99.9% · 50ms

能力列表

👤 用户认证

🏷️ 用户画像

🔐 权限校验

API 端点数

5 个（Phase 1 从 apiContract 读取）

7️⃣ 服务运行时配置（编辑）

服务运行时配置

任务 8.3Day 11-12

8️⃣ 项目迁移到集群的确认弹窗

项目迁移确认

任务 3.2Day 3

任务清单（22 项）

📅 Week 1 · 基础设施（Day 1-5）

#	任务	Day	工作	依赖
1.1	schema 扩展（type 字段）	D1 上	0.5 天	无
1.2	Project 字段扩展	D1 下	0.5 天	1.1
2.1	proto_cluster_create	D2 上	0.5 天	1.2
2.2	cluster CRUD RPCs	D2 下-D3 上	1 天	2.1
3.1	proto_project_set_type	D3 下	0.5 天	1.2
3.2	project_set/remove_cluster	D3 下	1 天	2.1
4.1	侧边栏集群入口	D4 上	0.5 天	2.2
4.2	集群列表页 UI	D4 下	1 天	2.2
4.3	集群卡片缩略图	D5 上	0.5 天	4.2
4.4	返回导航	D5 下	0.5 天	4.1

📅 Week 2 · 集群工作台（Day 6-10）

#	任务	Day	工作	依赖
5.1	集群工作台多 Tab 框架	D6	1 天	4.2
5.2	总览 Tab（统计+分层摘要）	D7	1 天	5.1
6.1	分层架构图基础渲染	D8	1 天	5.2
6.2	项目卡片双形态样式	D9 上	0.5 天	6.1
6.3	跨层依赖线（静态）	D9 下	0.5 天	6.1
7.1	服务详情页主框架	D10 上	0.5 天	5.1
7.2	总览 Tab	D10 中	0.5 天	7.1
7.3	API 契约 Tab	D10 下	0.5 天	7.1

📅 Week 3 · 服务形态 + 测试数据（Day 11-15）

#	任务	Day	工作	依赖
8.1	proto_service_update_runtime	D11 上	0.5 天	1.2
8.2	proto_service_update_api_contract	D11 下	0.5 天	1.2
8.3	服务运行时 Tab UI	D12	1 天	8.1
9.1	新建项目对话框：类型选择	D13 上	0.5 天	2.1
9.2	"单一项目"流程	D13 中	0.5 天	9.1
9.3	"项目集群"流程	D14	1 天	9.1
10.1	创建测试集群	D15 上	0.5 天	全部
10.2	添加旅行票根到 L4	D15 中	0.5 天	10.1
10.3	创建 service-only mock 项目	D15 下	0.5 天	10.2

📅 Week 4 · 联调 & 打磨（Day 16-20）

#	任务	Day	工作	依赖
11.1	端到端测试	D16	1 天	10.3
11.2	修复问题	D17	1 天	11.1
12.1	视觉一致性	D18 上	0.5 天	11.2
12.2	交互动画	D18 下	0.5 天	11.2
12.3	响应式适配	D19	1 天	11.2
13.1	用户文档	D20 上	0.5 天	12.3
13.2	内部演示	D20 下	0.5 天	13.1

完成标准（Definition of Done）

✅ Phase 1 完成时，以下必须全部满足

#	验收项	验证方式
1	工作台侧边栏有两个 Tab：📁 项目库、🏢 集群列表	UI 检查
2	能创建集群并定义层结构	创建测试集群
3	能把现有项目加入集群指定层	旅行票根→L4
4	能创建新项目时选择加入集群	新建项目→加入 L3
5	page-based 项目进入现有工作台	点击旅行票根
6	service-only 项目进入服务详情页	点击用户中心服务
7	集群工作台多 Tab 框架正常	UI 检查
8	分层架构图渲染正确（4 层 + 项目卡片）	UI 检查
9	项目卡片区分 page-based（🖥️ 蓝）vs service-only（⚙️ 橙）	UI 检查
10	服务详情页 API 契约 Tab 能显示现有 endpoints	旅行票根 20 个
11	至少 1 个测试集群数据可演示	__test_ 测试集群
12	用户文档完成	docs/cluster-user-guide.md
13	无 P0/P1 Bug 残留	端到端测试
14	所有 RPC 测试通过	单元测试

分阶段实施总览

本方案分 5 个阶段实施，真实周期估算 4.5 - 5.5 个月（17-22 周）。每个阶段有独立的方案文档，点击下方链接查看详情：

📋 Phase 1 · 基础骨架

工作台侧边栏集群入口 · 集群 CRUD · 双形态项目 · 服务详情页 · 分层架构图（静态）

✅ 方案已完成 · 4-5 周

🔗 Phase 2 · 能力契约

能力注册表 · 依赖编辑器 · 服务依赖图 · 部署拓扑图 · 数据流图 · Sankey 矩阵

✅ 方案已完成 · 5-6 周

📦 Phase 3 · 共享实体

共享实体定义 · 影响分析 · 能力版本管理

数据迁移 · 自动检测 · 模板系统

性能优化 · 交互动画 · 导入导出

📅 排期演进

v1.0 排期 10-15 周 → v1.2 排期 15-20 周（4-5 个月）→ v1.5 排期 17-22 周（4.5-5.5 个月）。每次调整都更贴近真实工作量，避免过度承诺。

关键设计决策

🤝 能力契约 vs 模块直连

能力是契约，模块是实现。能力更稳定，模块可能变化。一个能力被多个上层消费，模块直连会导致 N×N 复杂度。

📦 为什么共享实体

数据一致性，避免重复定义。修改共享实体时快速定位影响范围。共享实体对应共享数据库表。

🎯 双重定位

基础项目面向极简用户（5 分钟生成原型）；项目集群面向架构师用户（系统治理）。功能分层，复杂度可选。

🔄 多版本共存

老消费者不受影响，新消费者用新版本。已发布版本 schema 不可变。渐进迁移引导消费者升级。

🤖 自动依赖检测

降低维护成本。数据驱动，最可靠的依赖信号。即时反馈，修改数据模型后立即看到依赖建议。

📋 集群模板

快速启动，最佳实践。团队统一风格。知识沉淀，自定义模板将团队经验固化为可复用资产。

风险 & 缓解

风险	概率	影响	缓解措施
自动检测"无米下锅"（数据未结构化）	高	高	Phase 4 先做数据就绪迁移工具
后台生成过度承诺	中	高	v1.2 已移除，列为远期探索
存储不可扩展至多租户	高	高	明确限于本地阶段，商业化前重构
与独立化路径冲突	高	高	暂限于本地，独立化拍板后调整
能力契约的"模块"假设未被验证	中	中	Phase 1 抽样验证现有项目数据模型
版本管理过度设计	中	中	改为可选功能（开关控制）
跨层关系维护成本高	高	中	自动检测 + 手动维护 + 默认建议
可视化性能问题	中	中	虚拟滚动 + 懒加载 + 分层聚合
排期失控（Phase 过密）	中	中	v1.2 重新估算为 4.5-5.5 个月

开放问题

已解决（v1.2.1）

✅ 能力版本管理（v1.2 改为可选功能）
✅ 自动依赖检测（v1.2 明确前置条件）
✅ 集群模板（v1.2 按需实现）
✅ 目标用户定位（双重定位）
✅ 存储范围（明确为本地原型阶段）
✅ 后台生成承诺（从方案中移除）
✅ 项目形态双形态（v1.2.1 核心新增）

待解决

能力契约的"模块"假设 — 需在 Phase 1 抽样验证数据模型
数据模型结构化迁移 — 现有实体多为空数组
能力版本管理的开关粒度 — 全局 vs 按能力
DSH-RPC 耦合风险 — 独立化路径若选解耦需重写 §5.1/§5.3

可行性复核附录

📋 复核意见（v1.2 已回应）

本附录为独立复核意见。v1.2 已针对关键质疑做出回应： §1.5 目标用户分层、 §3.0 服务详情页、 §5.1 存储本地局限、 §5.4 移除后台生成、 §6 排期 4.5-5.5 个月、 §8 风险矩阵 9 项。原文保留作为复核记录。

一句话结论

本方案是 proto-workspace 的产品功能扩展，概念自洽、体验设计成熟，但其全部能力通过新增 DSH RPC 实现、数据落在既有的 proto-projects.json，完全绑定在当前 DSH 插件模型上。它能否按原样落地，取决于上一轮《ProtoWork 独立化方案》最终选定的"独立化路径"。

已核实事实

✅ proto-projects.json 与既有 RPC 确实存在
⚠️ 自动依赖检测的前提不成立：现有项目 dataModel.entities 多为空数组，不存在 sharedEntityRefs 与集群级 sharedEntities
⚠️ "能力契约"假设了理想化的"模块"：proto-workspace 的真实"模块"是页面/图工件，并非强类型服务模块

建议的落地姿态

先决条件：启动本方案前，先锁定独立化路径
首轮范围收敛：先做高价值低风险的集群 + 分层 + 能力注册表 + 分层架构图
验证数据就绪：押注自动检测前，先抽样验证数据模型
存储升级前置：商业化要 SaaS 多租户，持久化应早期规划

版本历史

v1.0 2026-09-04 · 初版：集群、跨层关系、共享实体、双视图

v1.1 2026-09-04 · 新增：能力版本管理、自动依赖检测、集群模板

v1.2 2026-09-04 · 回应可行性复核附录：明确目标用户分层（双重定位）、收敛承诺（移除后台生成）、调整排期（4-5 个月）、补充关键风险

v1.2.1 2026-09-04 · 项目形态双形态：page-based 与 service-only 分类；服务详情页；分层架构图适配双形态；排期重新估算为 4.5-5.5 个月

v1.3 2026-09-05 · 融合 Phase 1 实施方案：合并 Phase1-方案.html 到设计文档；新增 8 张线框图（新建对话框、集群创建向导、集群列表页、集群工作台、分层架构图、服务详情页、运行时配置、迁移确认弹窗）；新增 22 项任务清单（4 周甘特图）；新增 Phase 2-5 占位章节

v1.5 2026-09-05 · 新增完整用户体验动线：独立 HTML 文件（22 步 / 8 幕 / 双角色），从启动→项目归位→能力注册→源码分析→依赖可视化→现有工作台功能→版本模板→日常运维完整动线；主文档顶部导航 + Hero 区域加醒目入口（橙色 CTA）

从单项目工作台到全栈系统描述平台

设计哲学

三个核心立场

概览

核心洞察：项目形态二分

典型集群示例

核心概念

目标用户分层

数据模型

集群核心结构

Project 扩展（双形态）

实体关系图

用户交互

工作台导航

集群工作台（核心形态）

分层摘要

创建流程

服务详情页（无界面项目新形态）

服务描述

技术栈

健康度

能力列表

运行时

可视化设计

集群视角的图表体系

分层架构图（适配双形态）

能力版本管理

技术方案

存储方案（明确本地局限）

可视化技术

RPC 接口清单

分阶段实施总览

01 基础骨架 工作台侧边栏 · 集群 CRUD · 双形态 · 服务详情页 · 4-5 周

核心目标

明确边界：本阶段不做

排期总览

线框图（8 张）

1️⃣ 新建项目对话框（类型选择）

2️⃣ 集群创建向导（层结构）

3️⃣ 集群列表页

集群列表

4️⃣ 集群工作台（总览 Tab）

5️⃣ 分层架构图（静态）

6️⃣ 服务详情页（service-only 项目）

7️⃣ 服务运行时配置（编辑）

8️⃣ 项目迁移到集群的确认弹窗

任务清单（22 项）

📅 Week 1 · 基础设施（Day 1-5）

📅 Week 2 · 集群工作台（Day 6-10）

📅 Week 3 · 服务形态 + 测试数据（Day 11-15）

📅 Week 4 · 联调 & 打磨（Day 16-20）

完成标准（Definition of Done）

分阶段实施总览

关键设计决策

风险 & 缓解

开放问题

已解决（v1.2.1）

待解决

可行性复核附录

一句话结论

已核实事实

建议的落地姿态

版本历史

从单项目工作台
到全栈系统描述平台

01 基础骨架工作台侧边栏 · 集群 CRUD · 双形态 · 服务详情页 · 4-5 周