DECA
设计工程化范式与生态蓝图DECA
Blueprint for the Design-Engineering Paradigm & Ecosystem

DECA 不是又一个设计系统或低代码工具，而是一套协议化的体验生产基础设施。它的护城河不在单一功能，而在五层相互加强的结构性优势：DECA is not another design system or low-code tool, but a protocolized experience-production infrastructure. Its moat is not a single feature, but five mutually reinforcing structural advantages:

1.1 重新定义"设计"1.1 Redefining "design"

这里的"设计"不是"界面视觉设计"，而是体验工程（Experience Engineering）——像工程学科一样对待体验：有指标、有约束、有可量化的成功标准。Here "design" is not "interface visual design" but experience engineering — treating experience like an engineering discipline: metrics, constraints, quantifiable success criteria.

1.2 扩大的设计编辑用户群1.2 A wider design-editing user base

设计工程化的核心目的，是扩大"体验设计编辑"的用户群。传统的体验设计几乎被设计师垄断。AI 时代，研发同学成为最大的增量用户：他们理解功能逻辑，AI 让他们能直接完成体验决策 + 原型生成，不需要等设计师。The core aim of design engineering is to widen the "experience-design editing" user base. Traditional experience design was almost monopolized by designers. In the AI era, engineers become the largest incremental user: they grasp functional logic, and AI lets them make experience decisions and generate prototypes directly, without waiting for a designer.

1.3 趋势四层模型1.3 A four-layer trend model

设计工程化的趋势可以从四个层次理解：角色融合（研发向设计扩展）、工作场景革命（走查环节消失）、通用交付物（DECA-HTML）、分层隔离（纯视觉资产独立）。The trend of design engineering is read in four layers: role fusion (engineers expand toward design), the work-scene revolution (the review step disappears), the universal artifact (DECA-HTML), and layered isolation (pure-visual assets stay separate).

第 1 层：角色融合——方向是研发向设计扩展Layer 1: Role fusion — engineers expand toward design

第 2 层：工作场景革命Layer 2: The work-scene revolution

传统链路里 PM、设计师、研发是三个割裂角色，设计决策锁在设计师脑子里。AI 路径下，三者的综合能力收束为一个新核心角色——Codesigner（共创设计师）。其名源自 code + design，天然含两层含义：一是共创（co-create），与人、设计系统、智能体协同定义体验；二是交付（deliver），从产品洞察直接构建并落地可运行的 DECA-HTML。它既能承接洞察、定义体验工程，又能贯通后续协同与迭代；不是一个被替代的"单人"，而是 PM + 设计师 + 研发能力融合后的角色载体，可在真人与智能体之间无缝切换（见"协作席位"）。In the traditional chain PM, designer and engineer are three siloed roles, with design decisions locked in the designer's head. Under the AI path, their combined capability converges into one new core role — the Codesigner. Its name comes from code + design, carrying two layers by nature: first, co-create, collaborating with people, design systems, and agents to define experience; second, deliver, building and shipping runnable DECA-HTML directly from product insight. It takes insight and defines experience engineering, carrying through collaboration and iteration; it is not a "single person" being replaced, but the role vehicle after PM + designer + engineer capabilities fuse, switching seamlessly between human and agent (see "Collaboration Seats").

第 3 层：通用交付物——DECA-HTMLLayer 3: The universal artifact — DECA-HTML

DECA-HTML（Design-Context-Embedded HTML）= HTML + 六层语义指针：DECA-HTML (Design-Context-Embedded HTML) = HTML + six semantic pointer layers:

第 4 层：分层隔离——纯视觉设计师的边界Layer 4: Layered isolation — the pure-visual designer's boundary

不是所有设计元素都该被代码化。纯视觉设计师（平面/动效/三维/可交互视觉）的价值无可替代，设计工程化的责任是把他们的视觉资产有效融合进代码工程。Not every design element should be coded. Pure-visual designers (graphic / motion / 3D / interactive) are irreplaceable; design engineering's job is to fuse their visual assets effectively into the code base.

3.1 DECA Context Service：语义中枢3.1 DECA Context Service: the semantic hub

DECA-HTML 是视图层，Context Service 是数据层。HTML 只放指针，完整语义存在中间服务，各端通过 API 拉取和回写。DECA-HTML is the view layer; Context Service is the data layer. HTML holds only pointers; full semantics live in the intermediate service, pulled and written back by each end via API.

核心能力：上下文拉取、资产存储、实时协同、版本管理、MCP 接入、多设计系统 adapter 注册。Core abilities: context pull, asset storage, real-time collaboration, versioning, MCP access, multi-design-system adapter registration.

3.2 清洗与回溯：穿脱机制3.2 Strip & Restore: the wear-off mechanism

DECA 语义是协同阶段的"脚手架"，不是生产代码的"承重墙"。上线时清洗，迭代时回溯。DECA semantics are "scaffolding" in the collaboration phase, not "load-bearing walls" of production code. Strip at launch, restore at iteration.

• 清洗三模式：soft（继续协同）/ hard（归档备用）/ purge（彻底丢弃）Three strip modes: soft (keep collaborating) / hard (archive) / purge (discard fully)
• 回溯三级策略：锚点匹配 → 结构指纹 → AI 辅助推断Three restore tiers: anchor match → structural fingerprint → AI-assisted inference
• 完整生命周期：穿语义（协同修改）→ 脱语义（清洗上线）→ 穿回语义（回溯迭代）→ 再脱 → ...Full lifecycle: wear semantics (collab edit) → strip (clean launch) → re-wear (restore iterate) → strip again → ...

如果"用工程化中间表示弥合设计与代码"是对的，为什么 Figma、Google、Vercel 没有把它做成完整范式？答案不是"他们没看到"，而是"他们各自只做了一段，且结构上没有动力做完整方案"。这四条逻辑指向一个结论：完整范式需要一个不受单段商业锁定束缚的承载者——这正是 DECA 的定位。If "bridging design and code via an engineering intermediate representation" is right, why haven't Figma, Google, or Vercel made it a complete paradigm? Not that they didn't see it, but each did only one segment, with no structural incentive to do the whole. The four logics converge: a complete paradigm needs a carrier free from any single commercial lock-in — that is DECA's positioning.

6.1 综合判断：结构性空白6.1 Synthesis: the structural gap

7.1 战略价值跃迁（范式视角）7.1 Strategic value leap (paradigm view)

以"用户权限管理页"为例：第零步 Codesigner 把产品洞察结构化为 Experience Contract，写入 DECA-HTML 的 JSON-LD 头部；第一步 Codesigner 在 AI IDE 输入需求 + 契约，AI 直接生成可在浏览器运行的 DECA-HTML 原型（adapter 在本地/CI 阶段把 @ds/* 解析为真实组件）；第二/三步 Codesigner 用 data-dc-interaction 声明设计意图，智能设计协作席并行接管视觉——Figma agent 与 DECA Inspector（IDE 插件或同类能力）随构建同步打磨，真人与智能体按需无缝切换；第四/五步 CI 自动校验 + 清洗上线。Take a "user-permission page": Step 0 the Codesigner structures product insight into an Experience Contract in the DECA-HTML JSON-LD head; Step 1 the Codesigner inputs requirements + contract in the AI IDE, and AI generates a runnable DECA-HTML prototype (the adapter resolves @ds/* to real components at local/CI stage); Steps 2/3 the Codesigner declares intent via data-dc-interaction, and the Intelligent Design Seat polishes visuals in parallel — Figma agent and DECA Inspector (IDE plugin or equivalent) refine alongside the build, with human and agent switching seamlessly on demand; Steps 4/5 CI auto-verifies and strips for launch.

关键价值：体验目标结构化、关键功能决策写进契约被 AI 直接消费、CI 可自动验证性能、上线后真实数据回写契约。从需求到上线，原来 1-2 周，现在 1-2 天——收益来自语义层直改与自动化，而非特定组件库（此流程对任何设计系统成立）。Key value: structured experience goals, key decisions in the contract consumed by AI, CI-verified performance, real data rewritten post-launch. From requirement to launch, 1-2 weeks becomes 1-2 days — the gain comes from direct semantic editing and automation, not a specific library (this flow holds for any design system).

13.1 游戏场景扩展：终极验证场13.1 Game-scenario extension: the ultimate validation ground

游戏是 DECA 的终极验证场。它与 Web 有五个结构性差异：映射目标从唯一浏览器变为 N 个引擎（Cocos/Unity/UE）；资产走多级加工（切片→图集→骨骼→LOD）；状态模型是 60fps 帧驱动、服务端/客户端分离；有 Draw Call / 纹理内存 / 图集合批等硬性能约束；结构语义从 DOM 树变成场景图（空间变换 + 渲染顺序 + 生命周期）。Games are the ultimate validation ground for DECA. They differ from Web in five structural ways: the map target shifts from one browser to N engines (Cocos/Unity/UE); assets go through multi-stage processing (slice → atlas → skin → LOD); the state model is 60fps frame-driven with server/client split; hard perf budgets (draw call / texture memory / atlas batching) apply; and structural semantics move from the DOM tree to a scene graph (transform + render order + lifecycle).

必要能力清单（待建）Required capabilities (to build)

<div data-dc-asset-type="atlas"
     data-dc-contract='{
       "maxTextureSize": 2048, "format": "RGBA4444",
       "drawCallBudget": 1, "memoryBudget": "8MB"
     }'>

13.2 行业机会点：来自 Figma 用户侧的结构性诉求13.2 Industry opportunity: structural asks from Figma users

Figma 用户侧有八类结构性诉求，精确映射到 DECA 体系补全方向：不要同质化 AI 生图工具（DECA-HTML 是"生成物→工程产物"管道）；更好的设计-代码连接产物（DECA-HTML + 预览 + IDE Inspector + Context Service）；企业自带 AI 模型与私有化部署（接入混元/DeepSeek）；企业应用接入内部审批流（Context Service 开放 API + MCP）；外包灵活权限（节点级/临时/只读授权）；设计工具嵌入 AI IDE（DECA Inspector 作为 AI IDE 原生面板，最高优先级）；更便宜的独立贡献者版（核心工具开源可本地跑）；覆盖早期设计思考（data-dc-intent 表达"为什么这样设计"）。Figma users show eight structural asks that map precisely to DECA's completion directions: no同质化 AI image tools (DECA-HTML is a "generation → artifact" pipeline); a better design-code bridge (DECA-HTML + preview + IDE Inspector + Context Service); bring-your-own AI models and private deploy (Hunyuan/DeepSeek); enterprise apps with internal approval flows (Context Service open API + MCP); flexible outsourcer rights (node/temp/read-only grants); embed design tooling in the AI IDE (DECA Inspector as a native AI-IDE panel — top priority); a cheaper solo version (open-source core, local run); and covering early design thinking (data-dc-intent expresses "why this design").

最高优先级机会：DECA Inspector in AI IDETop priority: DECA Inspector in AI IDE

DECA-HTML + Context Service 本质上是在用户工程之外提供一种 协议层 + 存储层 服务：协议层定义语义结构（Token / Asset / Component / Intent / Contract / ChangeLog），存储层托管这些语义数据。用户的工程代码只持有指针，真正的语义数据外托在中间服务上。DECA-HTML + Context Service is essentially a protocol layer + storage layer service outside the user's project: the protocol layer defines semantic structure (Token / Asset / Component / Intent / Contract / ChangeLog), the storage layer hosts that semantic data. The user's code holds only pointers; the real semantics are entrusted to the intermediate service.

这带来两个对立判断：体验门槛（用户需把语义数据外托，是否构成采用阻力？）与 商业护城河（语义数据沉淀后是否形成切换壁垒？）。Two opposing judgements follow: the adoption threshold (does entrusting semantics outward deter adoption?) and the commercial moat (do accumulated semantics form a switching barrier?).

市场已有范式Existing market paradigms

这不是新模式，而是已被多类产品验证的成熟商业模型：This is not new — a mature model validated by many product categories:

三个数据敏感度层级Three data-sensitivity tiers

护城河构建路径How to build the moat

纯存储层无护城河——任何云存储都能放 JSON。护城河必须叠加在存储之上：Pure storage has no moat — any cloud can hold JSON. The moat must sit on top of storage:

17.1 协作席位：真人与智能体的兼容模型17.1 Collaboration seats: a compatible model for humans and agents

在这套工作流里，"一个人把活干完"往往是价值最高的状态——因为机制本身已经在每个环节给个人做了聪明化补充。所以协作席位不是 Figma 式的真人实时协同，而是系统按角色智能分配的协作伙伴。正确的模型是：席位是结构，坐的是真人还是智能体，看在场情况。In this workflow, having one person finish the work is often the highest-value state—because the system already augments the individual at every step. So a collaboration seat is not Figma-style real-time human co-editing. It is a partner the system assigns by role. The right model: a seat is structure; whether a human or an agent sits in it depends on presence.

兼容模型Compatible Model

关键：席位的角色职责是稳定的（智能设计协作席负责视觉判断、合约师席负责合规校验），变的是谁来履行这个职责——真人或智能体，无缝切换。Key: a seat's role duties are stable (the Intelligent Design Seat owns visual judgment, the contract seat owns compliance checks). What changes is who fulfills them—human or agent, switched seamlessly.

席位分配示例Seat Allocation Example

有些席位天生就是智能体常驻（合约校验、清洗穿脱），有些席位是真人为主、智能体兜底（智能设计协作席、资产师）。Some seats are agent-resident by nature (contract checks, wash on/off); some are human-led with agent backup (Intelligent Design Seat, asset).

为什么兼容比纯智能更对Why Compatibility Beats Pure Automation