AINDF

本地服务

github.com开发工具282 周前更新

代码仓库访问官网

关于 AINDF

AINDF 是面向符合 AINDF 规范的设计系统工具包，供设计系统维护者和屏幕作者检查、打包设计系统并构建屏幕。其只读 MCP 服务可查询设计系统能力并验证屏幕规格。

主要功能

01检查设计系统规范与绑定
02生成不可变设计系统包
03构建并检查 Next.js 页面
04验证屏幕规格
05读取组件、预设与插槽信息

适用场景

01检查设计系统是否符合 AINDF
02为屏幕固定设计系统版本
03生成并检查 Next.js 页面
04验证屏幕组件与插槽配置

MCP 相关

提供 stdio MCP 服务，也可通过 createDsMcp 与 mcpFetchHandler 在边缘运行时提供相同服务。只读端点提供设计系统查询和屏幕验证等工具。

配置

本地服务的配置在各客户端中通用，复制后粘贴到客户端的 MCP 配置文件即可。

mcp.json · 通用配置

{
  "mcpServers": {
    "0design-aindf": {
      "command": "npx",
      "args": [
        "-y",
        "@ai-native-design-framework/kit"
      ]
    }
  }
}

启动命令npx -y @ai-native-design-framework/kit

本地服务需要在你的电脑上安装运行环境（如 Node.js 18+）。各客户端的配置文件位置不同，请参考客户端文档。

安装包

npm@ai-native-design-framework/kit0.2.1stdio

工具

还没有获取到工具列表

本地服务需要在你的电脑上运行后才能读取工具，维护者暂未提供工具列表。

详细介绍

@ai-native-design-framework/kit — AINDF 0.2 套件

一个无依赖的包，适用于任何符合 AINDF（conformsTo: "[email protected]"）的设计系统：

命令	角色	作用
`aindf check <aindf.config.json>`	DS 维护者	一致性校验：源文件须通过固定的 AINDF 0.1 schema（`schema/0.1`、SHA256SUMS）以及 v0.2 新增内容（`schema/0.2`）的验证，无悬空的 slot/modifier/preset 边，符合层级规则，token 仅允许向下引用，props 封闭（不含 className/style/children/handlers），bindings 可解析。
`aindf bundle <config> --out <file>`	DS 维护者	不可变、内容寻址的 DS 修订版本（`bundleSha256`）。Screen 固定引用它；MCP 提供它。
`aindf build <config> --screens <dir> --app <dir> [--check]`	受信任的构建者	接受每个 `*.screen.json`，生成 Next.js App Router 页面（`// @generated`），`--check` 在手动编辑、过期规格、DS 变更和孤儿文件时失败；仅写入 `built` 回执。
`aindf mcp <bundle.json>`	Screen 作者	stdio MCP；`createDsMcp` + `mcpFetchHandler` 在边缘运行时上运行同一服务。

v0.2 对公开 AINDF 0.1 契约图的新增内容：components（封闭的 prop/slot/state 契约、模板）、 bindings（由 DS 实现的命名数据/操作适配器）、screen（唯一的作者产物）、receipt、config。 MCP 接口：AINDF 0.1 的 list-by-facet、slot-accepts、applicable-modifiers、get-preset，外加 get-ds、 get-component、validate-screen、submit-screen 和 request-extension。后两者仅由带有 staging 的端点提供（例如托管的 DS-MCP），需要作者令牌，且仅暂存未被接受的草稿；诸如 aindf mcp 之类的只读端点列出 7 个工具，Agent 会向用户报告需求或已验证的 ScreenSpec。每个工具都带有 title 和 MCP 提示（readOnlyHint、destructiveHint、idempotentHint、openWorldHint）。

该套件不包含任何设计系统；其测试针对仓库中保留的一个小型 fixture 设计系统运行。限制：构建者回执不是签名；verified/accepted/released 永远不会由该套件写入；作者主体的隔离来自部署权限，而非此包。

干净安装：仓库的 packages/aindf-kit/scripts/clean-install.mjs（源代码）会打包此包，将 tarball 安装到空项目中，并仅以使用者的方式使用它 —— aindf bin （check、bundle、build、--check）、包导出以及基于 stdio 的 MCP —— 每一步都附带一个反向用例。CI 在 Node 20 和 22 上运行它，并打印它所检查的 tarball sha256 和套件版本。

Core 上的 Instance（`ds.core` + `ds.coreBundle` + `ds.coreBundleSha256`，0.2.0）

扩展 Core 的 Instance 会在 aindf.config.json 中以三种方式固定它：ds.core（id@version）、ds.coreBundle （指向该 Core 的 AINDF bundle 的路径）和 ds.coreBundleSha256（bundle 的内容哈希；具有相同 id@version 但包含其他 contract 的自洽 bundle 会被拒绝）。生成的页面只从一个模块导入——即 Instance 的 implementation.module——因此页面所需的 Core 角色（Input、DialogPanel……）由 Instance 在相同的 contract 名称下提供，并以 Instance 的外观实现。然后 aindf check 将该 contract 与 Core 的 contract 对照：它必须接受 Core contract 接受的每个 prop 值——

每个 Core prop 都保留，其类型不变，必填性与 Core 要求完全一致；
每个枚举值、允许的绑定、富文本标记和内联组件都保留（Instance 可以增加更多）；
限制不能更严格：maxLength、minItems/maxItems、minimum/maximum；链接 pattern 必须是 Core 的那个；
每个 Core slot prop 都保留；Core 角色没有的 prop 是可选的；
角色在页面中保持其位置：Core 模板仍是模板，不添加 routeParams，taxonomy 层是 Core 的那一层，每个 Core slot 都存在且基数不更严格；Core 角色没有的 slot 是可选的（min 0）；
每个 Core 组件都在 Instance 中存在（contract 和 taxonomy），每个 Core 绑定按名称存在；params 或 data 绑定保持其种类（页面将其用作 $.params / $.meta），action 绑定可以改变种类（由 prop 指定）。

这保证了什么：为 Core 编写的页面——它的组件、prop、它们所处的位置、它们填充哪些 slot 以及有多少子项、它的绑定——无需修改即可通过 Instance 的准入，只有一个刻意的例外：slot 接受什么由 Instance 自己的 slotset 判定（它们接受的组件是 Instance 组件），因此更窄的 accepts 仍可能以 SLOT_REJECTS 拒绝一个 Core 页面。这一点在此处不检查。

coreConformance(config, components, core, { taxonomy, slots, bindings })：prop、slotProps、template、routeParams 和 Core 组件列表仅根据 components 检查；taxonomy 层以及存在性、slot 和绑定仅在传入该来源时才检查。 checkDs 会传入所有这些。

代码：当 bundle 不是被固定的那个时，为 CORE_PIN（AINDF-DS-29）；针对每个被收窄的 prop、被移动的角色、被收窄或新增的必填 slot、缺失的组件或绑定，为 CORE_CONFORMANCE（AINDF-DS-30）。没有 ds.coreBundle 时什么都不会改变。

支持 Markdown

登录后评论