VersionAI Tmall - AI Friendly Design System for GenAI

Human-AI Co-design Product Interfaces as An Emerging Mode of Work

In the daily workflow of design teams, output targets generally fall into three categories: modules, single pages, and multi-page flows. Correspondingly, design approaches can be grouped into three modes: assembling existing components, modifying existing components, and creating new components. Among these, modifications to existing components can be further broken down into information adjustments, layout adjustments, and style adjustments.

When mapped to the five major demand scenarios—core user journeys, content discovery channels, interactive products, marketing events, and B-end experience—a year-round analysis reveals a consistent pattern: within core journeys, discovery channels, and B-end experience, design tasks involving assembling or modifying existing components at the module or single-page level account for nearly 48% of all requests.

This substantial volume of repetitive and structurally similar design work urgently calls for automated, AI-driven design-generation methods to significantly improve both efficiency and output quality. For enterprise design teams, the primary goal is to generate product interfaces that faithfully adhere to internal design standards, and this requires the same essential task: clarifying and constructing an AI-friendly design-knowledge system that can be connected to design tools or large models.

Introducing VersionAI Tmall

By constructing the Design System Specification Knowledge Base and the Interface Generation Multi-Agents Workflow, an integrated, AI-friendly enterprise design system is formed. The system can be flexibly applied in IDE-based environments and agent-mode design tools via MCP or context injection. This comprehensive set of theory and practice offers broad applicability and can be adopted by enterprise teams across industries. VersionAI Tmall has already been implemented in real-world projects, resulting in significant improvements in interface design efficiency.

Building Design System Knowledge for AI Understanding and Utilization

Interface generation is essentially a domain-specific intelligent system composed of multiple task-specific agents, operating within an enterprise-aligned design workflow, and driven by contextual reasoning and retrieval over Design System Specification Knowledge. These agents are organized into four primary task agents: intent recognition, knowledge retrieval, design synthesis and code generation.

Design System Specification Knowledge acts as externally retrieved factual knowledge: through a Design-to-Code (D2C) transformation, design assets are converted into rule-based semantic facts, code-level symbolic facts, and the structured mappings between them, forming a structured Design Knowledge Base that the model can read, retrieve, and extract from.

Design System Specification Knowledge

Design System Specification Knowledge is composed of two categories of knowledge objects and three file types. The two categories of knowledge objects are Styles and Cases, where styles are further subdivided into four types: Elements, Layouts, Components, and Assets. Each category of knowledge object is associated with three file types: Semantic rules, Mapping schemas, and Code implementations.

Semantic rules consist of textual descriptions covering an object's definition, styles, variables, usage, and constraints. They represent the foundational intellectual property that gives rise to experiential differentiation and are authored in Markdown format. Code implementations translate objects into executable and deployable symbolic facts, using the appropriate programming language as the representation format.

Mapping schemas act as the central connective layer between semantic rules and code implementations. Rather than duplicating either, they provide object ID anchoring, constraint definitions, and precise code references. Within the workflow, they guide knowledge retrieval, solution construction, and code generation, enabling large language models to avoid traversing the entire knowledge corpus and reducing computational overhead.

1. Element knowledge is divided into four irreducible units: color, typography, corner radius, and motion, which serve as the foundational dependencies for all design styles.
2. Its semantic rules consist of element definitions, style composition, attribute variables (design tokens), mandatory rules, and functional usage.
3. The mapping schema is composed of ID symbols, semantics (including name, definition, and description), rules_refs, implementations_refs, and constraints (such as usage scenarios, mandatory prohibitions, and other restrictions). This schema is automatically generated by AI in accordance with Schema-based prompting rules.
4. Code implementations take the form of global styles (SCSS); these are automatically reconstructed from design artifacts and generated as code by IDE tooling through calls to the design software's MCP services.

1. Component knowledge is composed of units such as avatars, badges, asset slots, buttons, content streams, countdowns, coupons, filters, beacons, onboarding guides, carousels, inputs, messages, floating windows, dialogs, prices, product cards, progress bars, red packets, selectors, overlays, floating bars, switches, tab bars, tabs, text streams, tooltips, bubbles, and top bars. These components serve as critical reusable units for interface generation.
2. The semantic rules for components consist of component definitions, style composition, attribute variables, component states (interaction and visual), mandatory rules, and functional usage.
3. Building upon the existing mapping schema structure, component mapping schemas additionally introduce a properties schema (props schema), which corresponds to the attributes required by each component in the page-level component structure schema generated during the solution design stage.
4. Code implementations are realized as component structures (TSX) and component styles (SCSS) within a React-based technology stack.

1. Asset knowledge consists of units such as images, icons, logos, and tags, serving as the primary material sources for page content population.
2. The semantic rules for assets include asset definitions, attribute variables, mandatory rules, and functional usage.
3. The mapping schema for assets follows the same template as that used for elements. Depending on the specific asset type, asset knowledge may or may not require code implementations. For example, icons do require code implementations, whereas images typically do not.
4. In such cases, the implementations take the form of source asset files (e.g., SVG or PNG) with naming conventions consistent with those defined in the semantic rules.

1. Page semantic rules consist of page definition, target users, naming conventions, structural hierarchy, page states (interaction and visual), mandatory rules, and functional usage. Page knowledge does not require code implementations; instead, it is composed by the LLM through combining component, asset, and element code.
2. The mapping schema consists of ID symbols, semantics (name, definition, description), rules, structure, and constraints (usage scenarios, mandatory prohibitions, and others).

Multi-agent Workflow

Next, the workflow for interface design and generation is engineeried. A multi-agent, upstream-to-downstream collaborative process is, in essence, the definition and configuration of each sub-agent and its chaining logic.

In this project, the workflow and agents are built within an IDE-based tool. The base model and memory use default settings; tools are either defaulted or require no configuration; the remaining items are defined explicitly. The prompt Markdown files include (but are not limited to) role definitions, task definitions, built-in workflow steps, input/output requirements, access and routing, and constraints.

1. Agent template: Each agent includes upstream inputs, a base model, memory, system prompts (role and task), a knowledge base (or database), tools (MCP, plugins), and downstream outputs. It is critical to ensure that access paths, object naming, and input/output contracts referenced in sub-agent prompts remain coherent and consistent.
2. The intent recognition agent takes the user's query string as input (e.g., “Generate a new-product shopping-guide channel”). It outputs a knowledge retrieval requirements checklist, such as “requirement type (compositional reuse of existing modules), page type (Shopping Guide page), information structure (product cards), interaction constraints (filterable or not), content requirements (benefit/offer information), etc.”, and routes it to the next agent.
3. The knowledge retrieval agent takes the requirements checklist file as input. It queries, filters, and retrieves the corresponding content from the Design System Specification Knowledge Base, and outputs a knowledge outline—i.e., it fills in the knowledge items referenced in the checklist—then routes to the next agent.
4. The design synthesis agent takes the knowledge outline file as input. It makes design decisions and produces outline instructions for page structure, component types and properties, style elements, interaction patterns, and data/content requirements. It outputs a solution design schema/outline and routes to the next agent.

1. Design synthesis output (excerpt)
2. The code generation agent takes the solution design outline as input. It maps to the outline files in the knowledge base and invokes the corresponding code, producing interface code files as output; users can preview the generated results.
3. Final interface code generation output (excerpt)
4. An integrated system package—combining a Design System Specification Knowledge Base with an interface generation workflow engineering pipeline—completes the construction of AI-friendly enterprise internal interface design knowledge. It can be flexibly applied to IDE-based generation environments and agent-mode environments in design tools, via MCP or via context injection.

Interface generation in practice via the VersionAI Tmall website

VersionAI Tmall is an AI-oriented design specification website. It contains all the design knowledge described above and helps users generate user interfaces that conform to the Tmall design specification, conduct design reviews, and resolve Q&A. The site’s page structure is consistent with the design system knowledge structure, organized as a tree navigation of styles, cases, and their sub-unit knowledge modules.

Each knowledge module page can switch between rules for humans and rules for AI, and supports copying or downloading knowledge snippets. A deployment page guides users on how to invoke the specification for interface generation.

1. Website homepage
2. Sidebar consistent with the design system knowledge structure
3. Knowledge modules
4. Switch to AI-facing rules
5. Human-friendly semantic rules
6. AI-friendly semantic rules

This website provides two ways for users to invoke the Tmall design specification within AI tools: an MCP Server and context injection. By one-click configuring the MCP server in an IDE tool, the system automatically depends on the Tmall design knowledge base. The MCP-wrapped APIs perform automated processing and return results based on the user’s natural-language instructions; supported capabilities include (but are not limited to) Search and running workflows (runWorkflow).

Alternatively, users can click Copy or Download on a specific knowledge module page to obtain a snippet package containing semantic rules, mapping schema, and code implementations, and paste it directly into the instruction input box for local edits and generation.

1. Configure the tmall-design MCP in the IDE
2. Enter interface-generation instructions in natural language
3. Copy or download a knowledge unit
4. Inject the unit into context