[FR]: NutUI-React 面向 AI Coding 的能力调研与落地方案

> 调研 Ant Design 面向 AI Coding 构建的能力，拆解每项能力"是什么、解决什么问题、怎么实现"；再结合 NutUI-React 当前代码库的真实现状，给出一版可落地的方案。

---

## 一、背景与问题

大模型的训练数据有截止时间，而组件库的 API、约定、目录结构会持续演进。当 AI Coding Agent（Copilot / Cursor / Claude Code 等）基于"记忆"生成代码时，会出现三类典型问题：

1. **API 幻觉**：编造不存在的 Prop、用错枚举值、调用已废弃的写法；
2. **版本错配**：用旧版本 API 写新版本代码；
3. **约定缺失**：不了解项目特有的命名规范、Design Token 体系、H5/Taro 双端同构架构。

Ant Design 的解法不是"训练一个更好的模型"，而是**给 Agent 提供一套权威、离线、可程序化查询的事实源（Single Source of Truth）**，把"猜"变成"查"。这套能力对正在做多端、多版本演进的 NutUI-React 同样高度适用。

---

## 二、Ant Design AI Coding 能力调研

Ant Design 把面向 Agent 的能力组织成"一段入口 Prompt + 五类能力载体"。入口 Prompt（`for-agents.zh-CN.md`）的核心是一句话：**写任何代码前，先读文档、留意弃用提示、按说明使用**，并引导安装 Skill。下面拆解五类能力载体。

### 2.1 `@ant-design/cli` —— 离线知识库 + 项目工具（核心）

**是什么**：一个全局安装的命令行工具，**把 antd v3/v4/v5/v6 每个版本的 Prop、Token、Demo、Changelog 元数据随 npm 包一起打包**（覆盖 55+ 小版本快照）。

**作用 / 解决的问题**：
- **完全离线、毫秒级、无需 API Key**——Agent 在本地就能拿到精确到某个小版本的 API，从根源消除"猜 API"；
- **版本自动检测**：`--version` 参数 → `node_modules/antd` → `package.json` 依赖 → 默认回退，保证查询结果与用户项目版本对齐；
- **既是"知识查询器"也是"项目体检器"**。

**命令分四类（共 18 条）**：

| 类别 | 命令 | 作用 |
| --- | --- | --- |
| 知识查询 | `antd list` | 所有组件（双语名、分类、引入版本） |
| | `antd info <C>` | Props 表（类型、默认值、引入版本、废弃状态） |
| | `antd doc <C>` | 完整 Markdown 文档（`--lang zh`） |
| | `antd demo <C> [name]` | 可运行 Demo 源码（TSX） |
| | `antd token [C]` | 全局 / 组件级 Design Token（v5+） |
| | `antd semantic <C>` | `classNames` / `styles` 语义结构 |
| | `antd design.md` | 设计语言文档 |
| | `antd changelog [v1] [v2] [C]` | Changelog / 跨版本 API diff |
| 项目分析 | `antd doctor` | 10 项配置诊断（React 兼容、重复安装、SSR、babel 插件…） |
| | `antd env` | 收集环境信息用于 bug 报告 |
| | `antd usage ./src` | 分析项目中的 antd 导入与子组件分布 |
| | `antd lint ./src` | 检查废弃 API / a11y / 性能 / 最佳实践 |
| | `antd migrate <from> <to>` | 迁移清单，`--apply ./src` 生成迁移提示 |
| 问题反馈 | `antd bug` / `antd bug-cli` | 预览→确认→提交 bug 到对应仓库 |
| CLI 管理 | `antd mcp` | 启动 MCP 服务（8 工具 + 2 prompts） |
| | `antd setup --client claude` | 一键为 Claude/Cursor/VS Code/Codex 接入 |
| | `antd upgrade` | 升级 CLI |

**关键设计点（可直接借鉴）**：
- 所有命令支持 `--format json`，让 Agent **解析结构化数据而非正则抓文本**；
- 基于 Levenshtein 距离做拼写纠错（`Buttn` → `Button`）；
- 数据从文档/源码**反向抽取**生成，而非手工维护两份。

### 2.2 `llms.txt` —— LLM 结构化文档入口

**是什么**：遵循 [llmstxt.org](https://llmstxt.org) 社区标准的纯文本导航文件，放在站点根路径 `/llms.txt`。

**格式结构**（实测）：
```
# Ant Design - Enterprise-class React UI library

- Ant Design, developed by Ant Group, is a React UI library...   ← 一句话摘要

## Navigation
- [Design Language (DESIGN.md)](./design.md)
- [Full Documentation (EN)](./llms-full.txt)
- [Full Documentation (CN)](./llms-full-cn.txt)

## Component Docs (CN)
- [button](https://ant.design/components/button.md)
- [alert Semantic](https://ant.design/components/alert/semantic.md)
...
```
即 **H1 项目名 → 摘要 → 多个 H2 章节 → Markdown 链接列表**，中英文成对组织（CN 版带 `-cn` 后缀）。

**配套的三个文件**：

| 文件 | 说明 |
| --- | --- |
| `llms.txt` | 导航索引，列出所有文档/组件的 `.md` 链接 |
| `llms-full.txt` / `llms-full-cn.txt` | 把全部组件文档拼成一个大文件，可整体注入上下文 |
| `https://ant.design/components/<name>.md` | 单组件文档，按需精确拉取 |

**作用**：给"能联网但没装 CLI"的 Agent 一个标准入口。Agent 读 `llms.txt` 知道有哪些组件、去哪取每个组件的纯净 Markdown（无站点 HTML 噪音），按需或整体注入上下文。

### 2.3 `design.md` —— 设计语言上下文

**是什么**：一份面向 **AI 设计工具**的 Markdown，描述 Ant Design 默认 Light 主题的视觉语言、组件范式、主题 Token。

**作用**：CLI 查询解决"组件 API 怎么写"，`design.md` 解决"设计层面该用什么颜色/间距/圆角/范式"，让 AI 生成的界面符合设计系统而非随意取色。是 `llms.txt` Navigation 区的首位入口。

### 2.4 MCP Server —— IDE 深度集成

**是什么**：`@ant-design/cli` 可作为 [MCP](https://modelcontextprotocol.io)（Model Context Protocol）服务器运行（`antd mcp`），对外暴露 **8 个工具 + 2 个提示词**。配置方式：
```json
{ "mcpServers": { "antd": { "command": "npx", "args": ["-y", "@ant-design/cli", "mcp"] } } }
```

**作用 / 与 CLI 的区别**：
- CLI 是"Agent 主动敲命令"；MCP 是"把能力注册成 IDE 原生工具"，Claude Code / Cursor / VS Code 可在对话中**自动按需调用**，无需 Agent 拼命令行字符串；
- 复用 CLI 同一份离线元数据，等于给同一个知识库套了两种调用协议（CLI 给脚本/终端，MCP 给 IDE）。

### 2.5 Skill (`SKILL.md`) —— 给 Agent 的"使用说明书"

**是什么**：遵循 Anthropic Agent Skills 规范的 Markdown（`---\nname/description/allowed-tools\n---` frontmatter + 正文）。通过 `npx skills add ant-design/ant-design-cli` 安装。

**内容结构**（实测）：
- **frontmatter**：`name: antd`、`description`（定义触发场景）、`allowed-tools`（限定可执行的命令白名单）；
- **12 个使用场景**：编写代码 / 查文档 / 调试 / 版本迁移 / 用法分析 / 查 changelog / 探索组件 / 收集环境 / 上报 bug / 升级 / 作为 MCP；
- **典型工作流**：`antd info → 理解 props → antd demo → 拿可运行示例 → 写代码`；
- **7 条核心规则**：查询先于编写、匹配用户版本、用 JSON 格式、迁移前先检查、改动后 lint…

**作用**：CLI/MCP 是"能力"，Skill 是"什么时候、按什么顺序用这些能力"的元指令。它把"先查再写、改完要 lint"这类最佳实践固化进 Agent 的行为。

### 2.6 小结：五类能力的协作关系

```
                 ┌─ 入口 Prompt (for-agents.md)：先读文档、按说明用
                 │
   一份离线元数据 ─┼─ CLI ────────► 终端 / 脚本 Agent 主动查
  (Prop/Token/    │
   Demo/Changelog)├─ MCP Server ─► IDE 自动调用（同一份数据，换协议）
                 │
   文档纯文本 ────┼─ llms.txt ───► 联网 Agent 的标准入口
                 │
   设计语言 ─────┼─ design.md ──► AI 设计工具
                 │
   行为规范 ─────└─ SKILL.md ───► 约束 Agent "何时、按何顺序"用上面的能力
```
**最关键的认知**：这些能力**共享同一份从文档/源码反向抽取的元数据**，靠工程链路保证"文档即数据、数据多协议分发"，而非手工维护多份。

---

## 三、NutUI-React 现状评估

结论先行：NutUI-React **尚无任何一项 Ant Design 式的标准产物**（无 `llms.txt`、无 `design.md`、无官方 CLI 包、无官方 MCP Server），但**底层数据基建已相当完备**，落地这些能力主要是"接线"而非"从零造数据"。同时，当前已有一批探索性 AI 产物可作为起点（见 3.3）。

### 3.1 已具备的数据抓手（落地的地基，均已核验真实存在）

| 抓手 | 路径 | 现状 | 价值 |
| --- | --- | --- | --- |
| **组件清单（事实上的 components.json）** | `src/config.json`（42KB） | 8 个分类、每组件含 `name`/`cName`/`version`/`taro`/`v15`/`v16`/`author` 等元字段 | `llms.txt`/CLI 的组件遍历入口 |
| **组件 API 结构化数据** | `scripts/properties.json`（246KB，**930 条**） | 由 `scripts/create-properties.js` 解析所有 `doc.md` 的 Props/Ref 表格生成；字段为 `组件名/版本号/表格名/第一~四列` | CLI `info` / MCP / llms 的 API 数据源 |
| **四语言/端文档** | `src/packages/<comp>/doc{,.en-US,.zh-TW,.taro}.md` | 89 组件 × 4 份，结构统一（引入 / `:::demo` 示例 / Props 表 / 样式变量表） | `llms.txt` 的 `.md` 链接目标 |
| **集中式 Props 类型** | `src/types/spec/<comp>/{base,h5,taro}.ts` + `src/types/index.ts` | base/h5/taro 三层分离的强类型 | 类型校验、`info` 增强 |
| **独立 Demo 源码** | `src/packages/<comp>/demos/{h5,taro}/demoN.tsx` | 文档用 `<CodeBlock src='h5/demoN.tsx'>` 引用 | CLI `demo` 的数据源 |
| **Design Token** | `src/styles/variables.scss` | `var(--nutui-*)` 体系 | `token` 命令 / `design.md` 数据源 |
| **已打通的"元数据→AI 上下文"链路** | `scripts/build-copilot-ctx.mjs` | 读 `properties.json` + `variables.scss` → 生成 78KB `instructions.md` | **直接可改造为 llms.txt 生成器** |

### 3.2 关键差距

1. **数据是"为人/为站点"组织，不是"为 Agent"组织**：
   - 文档→站点靠 `src/sites/sites-react/doc/docs.ts` 里**手写的巨型静态 import 清单**（每组件 4 行 `import ... from '...?raw'`），没有对外的纯 `.md` 寻址入口（无 `/components/<name>.md`）；
   - `properties.json` 字段名是中文位置式（`第一列/第二列`），语义不自描述，不利于程序消费；
   - 缺少标准入口文件（`llms.txt`）和设计语言文件（`design.md`）。
2. **无版本化 API 快照**：antd CLI 的杀手锏是"任意历史版本精确查询"。NutUI 当前只有"当前工作区"一份数据。在 `v4 beta` 演进期，**跨版本 diff（v3 用法 → v4 用法）是高频刚需但暂缺**。
3. **无统一分发载体**：现有产物（copilot 指令、cursor skills、claude commands）散落，无 CLI / MCP 统一封装，业务方接入靠"手动拷文件"。

### 3.3 当前已有的探索性 AI 产物（可复用的起点）

| 产物 | 路径 | 评估 |
| --- | --- | --- |
| **Copilot 知识增强包** | `scripts/copilot/instructions.md`（78KB）+ `build-copilot-ctx.mjs` + `README.md` | **最像 llms.txt 的现成产物**，已打通"API+Token → 单文件 AI 上下文"，且标注 `DO NOT manual edit`（自动生成）。是落地 llms.txt 的直接基础 |
| **Claude Code 斜杠命令** | `.claude/commands/nutui-{analyze,plan,execute,review}.md` | 把 NutUI 组件开发拆成"分析→计划→执行→评审"四阶段工作流，体现对跨端架构的深度理解。等价于 antd 的"场景化工作流" |
| **Cursor Skills** | `.cursor/skills/{nutui-build-local-verify,nutui-proportional-scaling,nutui-taro-weapp-wxss}/SKILL.md` | 标准 frontmatter，含本地构建校验、等比缩放、小程序 wxss 适配等专项规范 |
| **通用 agent skills** | `.agents/skills-a11y.md`、`.agents/skills/performance_audit/SKILL.md` | 无障碍 / 性能审计技能，配套 `scripts/a11y-governance.mjs` |
| **AI 自动修 issue** | `.github/workflows/auto-fix-issue.yml` + `scripts/agents/*.py` | 打标签触发，自动建分支开 PR（基于 Gemini） |
| **组件标准白皮书** | `NutUI-React_组件标准白皮书.md`（33KB） | 人类可读规范，可作为 `design.md` 的内容输入 |

---

## 四、落地方案

### 4.1 设计原则

1. **单一事实源，多协议分发**（照搬 antd 的核心思想）：所有 AI 能力共享同一份从 `config.json` + `properties.json` + `doc.md` + `variables.scss` 反向抽取的元数据，杜绝手工维护多份；
2. **复用已有链路**：以 `build-copilot-ctx.mjs` 为种子扩展，而非另起炉灶；
3. **贴合 NutUI 差异化特性**：H5/Taro/Harmony 多端、`nut-` 扁平 BEM、`v4 beta` 版本演进——这些是 NutUI 相对 antd 必须额外处理的维度，也是差异化价值点；
4. **分阶段、可独立交付**：每个阶段产出独立可用，不强依赖后续阶段。

### 4.2 第一步：统一元数据层（地基，1 份脚本）

把分散的数据归一成一份"自描述、机器友好"的中间产物 `meta/components.json`：

- **新增 `scripts/build-meta.mjs`**：以 `src/config.json` 的 `nav` 为遍历入口，对每个组件聚合：
  - 基本信息（`name`/`cName`/`version`/`taro`/分类）← `config.json`
  - Props 表（把 `第一~四列` **重命名为 `prop/desc/type/default`**，按 `表格名` 分组）← `properties.json`
  - Demo 列表（扫描 `demos/{h5,taro}/*.tsx` 文件名）← 文件系统
  - 关联 Token ← `variables.scss`
- 输出 `meta/components.json`（机器可读）+ 保留对 `doc.md` 路径的引用。
- **价值**：后续 llms.txt、CLI、MCP **全部读这一份**，改一处全链路生效。

> 这一步本质是把现有 `build-copilot-ctx.mjs` 里"分组+解析"的逻辑抽出来、字段语义化、补上 demo/分类维度。工作量小、收益最大。

### 4.3 第二步：产出 `llms.txt` + 纯 `.md` 寻址（联网 Agent 入口，性价比最高）

| 产物 | 做法 |
| --- | --- |
| `llms.txt` | 仿 antd 格式：H1（`# NutUI React - 京东多端组件库`）→ 摘要 → `## Navigation`（design.md、白皮书、full 链接）→ `## 组件文档（中文）/（English）/（Taro）` 列出每组件 `.md` 链接。生成器读 `meta/components.json` |
| `llms-full-cn.txt` / `llms-full.txt` | 把所有 `doc.md` / `doc.en-US.md` 拼接为单文件 |
| 单组件 `.md` 路由 | 在文档站（`vite.config.site.mts`）增加静态路由，使 `nutui.jd.com/components/button.md` 直接返回 `doc.md` 原文（已有 `?raw` 导入，改造成本低） |

落地后：业务方 Agent 只需被告知 `读 https://<nutui-host>/llms.txt`，即可自助发现并精确拉取任意组件文档。**这是投入产出比最高的一步，应优先做。**

### 4.4 第三步：`design.md`（设计语言上下文）

以 `NutUI-React_组件标准白皮书.md` 为内容底稿，提炼成面向 AI 设计工具的 `design.md`：
- 主题 Token 体系（颜色/间距/圆角/字体，从 `variables.scss` 提取）；
- `nut-` 扁平 BEM 命名范式（`.nut-{block}-{suffix}`，**禁用双下划线**——这是 NutUI 区别于标准 BEM 的关键，必须明确写出，避免 AI 套用 antd/标准 BEM 习惯）；
- 多端范式说明（H5 用 DOM、Taro 用 `<View>`）。
挂到 `llms.txt` 的 Navigation 首位。

### 4.5 第四步：CLI（`@nutui/cli`，离线知识 + 项目工具）

新建 workspace 子包 `packages/nutui-cli`（仓库已是 pnpm monorepo，天然支持），打包时把 `meta/components.json` 一并 bundle：

**第一批命令（知识查询，直接读 meta）**：
```
nutui list                    # 所有组件（中英名、分类、是否支持 Taro）
nutui info Button             # Props 表（--format json）
nutui doc Button [--lang zh|en|tw|taro]   # 完整文档
nutui demo Button [name]      # Demo 源码
nutui token [Button]          # Design Token
```
**第二批命令（项目工具）**：
```
nutui usage ./src             # 分析项目 NutUI 导入
nutui lint ./src              # 检查废弃 API / nut- 规范 / 硬编码颜色
nutui migrate v3 v4           # 版本迁移指南（需配合第六步的版本快照）
```
**强制约定**：所有命令支持 `--format json`；版本检测顺序对齐 antd（`--version` → `node_modules/@nutui/nutui-react` → `package.json`）。

### 4.6 第五步：MCP Server + Skill（IDE 集成与行为约束）

- **MCP**：在 `nutui-cli` 内实现 `nutui mcp` 子命令，把第四步的查询命令注册为 MCP 工具，复用同一份 meta。提供 `npx -y @nutui/cli mcp` 的标准配置片段。
- **Skill**：把现有 `.claude/commands/nutui-*.md` 四阶段工作流 + `.cursor/skills/*` 整合成一份标准 `SKILL.md`（`name: nutui` + `allowed-tools` 白名单 + 场景 + 核心规则），核心规则纳入：
  1. **查询先于编写**（先 `nutui info` 再写）；
  2. **匹配用户版本**（v4 beta API 与 v3 差异大）；
  3. **改完跑 `nutui lint`**（查 `nut-` 规范、硬编码色、废弃 API）；
  4. **多端一致性**（改 `x.tsx` 同步评估 `x.taro.tsx`）。
- **入口 Prompt**：仿 `for-agents.zh-CN.md` 写一份 NutUI 版，作为文档站「For Agents」页。

### 4.7 第六步（进阶）：版本化 API 快照

利用 git tag，对每个发布版本运行 `build-meta.mjs` 存档 `meta/<version>/components.json`，使 `nutui info Button --version 3.0.0` 与 `nutui migrate v3 v4` 可精确 diff。**这是 NutUI 在 v4 演进期的高价值能力**，但依赖前五步地基，故放在最后。

### 4.8 阶段规划与优先级

| 阶段 | 交付物 | 依赖 | 优先级 | 说明 |
| --- | --- | --- | --- | --- |
| P0 | `build-meta.mjs` + `meta/components.json` | 无 | ⭐⭐⭐ | 一切的地基，工作量小 |
| P0 | `llms.txt` + 单组件 `.md` 路由 | P0 meta | ⭐⭐⭐ | 性价比最高，立即可用 |
| P1 | `design.md` | 白皮书 | ⭐⭐ | 内容已有底稿 |
| P1 | `@nutui/cli`（知识查询命令） | P0 meta | ⭐⭐ | 离线、可程序化 |
| P2 | MCP Server + 统一 `SKILL.md` | CLI | ⭐⭐ | 整合现有探索物 |
| P2 | `nutui lint` / `usage` / `migrate` | CLI | ⭐ | 项目体检 |
| P3 | 版本化 API 快照 | 全部 | ⭐ | v4 演进期高价值 |

### 4.9 风险与注意事项

- **数据质量依赖文档**：`properties.json` 来自手写 `doc.md` 表格，若文档有错/缺列，AI 会被误导。后续在 `build-meta.mjs` 增加校验（必填列、类型格式），并接入 CI。
- **多端差异表达**：H5 与 Taro 的 Props 可能有差异，meta 需保留 `h5/taro` 维度而非合并，否则 AI 在小程序端会用错 API。
- **维护成本**：所有产物必须自动生成、纳入发布流程（`prepublish` 或 CI），避免重蹈"手工维护两份"覆辙。现有 `instructions.md` 已用 `DO NOT manual edit` 标注，延续此约定。
- **避免过度建设**：P0+P1 即可覆盖 80% 的"消除 API 幻觉"价值；MCP/版本快照按团队投入和实际需求推进，不一次到位。


抓手	路径	现状	价值
组件清单（事实上的 components.json）	`src/config.json`（42KB）	8 个分类、每组件含 `name`/`cName`/`version`/`taro`/`v15`/`v16`/`author` 等元字段	`llms.txt`/CLI 的组件遍历入口
组件 API 结构化数据	`scripts/properties.json`（246KB，930 条）	由 `scripts/create-properties.js` 解析所有 `doc.md` 的 Props/Ref 表格生成；字段为 `组件名/版本号/表格名/第一~四列`	CLI `info` / MCP / llms 的 API 数据源
四语言/端文档	`src/packages/<comp>/doc{,.en-US,.zh-TW,.taro}.md`	89 组件 × 4 份，结构统一（引入 / `:::demo` 示例 / Props 表 / 样式变量表）	`llms.txt` 的 `.md` 链接目标
集中式 Props 类型	`src/types/spec/<comp>/{base,h5,taro}.ts` + `src/types/index.ts`	base/h5/taro 三层分离的强类型	类型校验、`info` 增强
独立 Demo 源码	`src/packages/<comp>/demos/{h5,taro}/demoN.tsx`	文档用 `<CodeBlock src='h5/demoN.tsx'>` 引用	CLI `demo` 的数据源
Design Token	`src/styles/variables.scss`	`var(--nutui-*)` 体系	`token` 命令 / `design.md` 数据源
已打通的"元数据→AI 上下文"链路	`scripts/build-copilot-ctx.mjs`	读 `properties.json` + `variables.scss` → 生成 78KB `instructions.md`	直接可改造为 llms.txt 生成器

产物	路径	评估
Copilot 知识增强包	`scripts/copilot/instructions.md`（78KB）+ `build-copilot-ctx.mjs` + `README.md`	最像 llms.txt 的现成产物，已打通"API+Token → 单文件 AI 上下文"，且标注 `DO NOT manual edit`（自动生成）。是落地 llms.txt 的直接基础
Claude Code 斜杠命令	`.claude/commands/nutui-{analyze,plan,execute,review}.md`	把 NutUI 组件开发拆成"分析→计划→执行→评审"四阶段工作流，体现对跨端架构的深度理解。等价于 antd 的"场景化工作流"
Cursor Skills	`.cursor/skills/{nutui-build-local-verify,nutui-proportional-scaling,nutui-taro-weapp-wxss}/SKILL.md`	标准 frontmatter，含本地构建校验、等比缩放、小程序 wxss 适配等专项规范
通用 agent skills	`.agents/skills-a11y.md`、`.agents/skills/performance_audit/SKILL.md`	无障碍 / 性能审计技能，配套 `scripts/a11y-governance.mjs`
AI 自动修 issue	`.github/workflows/auto-fix-issue.yml` + `scripts/agents/*.py`	打标签触发，自动建分支开 PR（基于 Gemini）
组件标准白皮书	`NutUI-React_组件标准白皮书.md`（33KB）	人类可读规范，可作为 `design.md` 的内容输入

产物	做法
`llms.txt`	仿 antd 格式：H1（`# NutUI React - 京东多端组件库`）→ 摘要 → `## Navigation`（design.md、白皮书、full 链接）→ `## 组件文档（中文）/（English）/（Taro）` 列出每组件 `.md` 链接。生成器读 `meta/components.json`
`llms-full-cn.txt` / `llms-full.txt`	把所有 `doc.md` / `doc.en-US.md` 拼接为单文件
单组件 `.md` 路由	在文档站（`vite.config.site.mts`）增加静态路由，使 `nutui.jd.com/components/button.md` 直接返回 `doc.md` 原文（已有 `?raw` 导入，改造成本低）

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[FR]: NutUI-React 面向 AI Coding 的能力调研与落地方案 #3494

一、背景与问题

二、Ant Design AI Coding 能力调研

2.1 `@ant-design/cli` —— 离线知识库 + 项目工具（核心）

2.2 `llms.txt` —— LLM 结构化文档入口

2.3 `design.md` —— 设计语言上下文

2.4 MCP Server —— IDE 深度集成

2.5 Skill (`SKILL.md`) —— 给 Agent 的"使用说明书"

2.6 小结：五类能力的协作关系

三、NutUI-React 现状评估

3.1 已具备的数据抓手（落地的地基，均已核验真实存在）

3.2 关键差距

3.3 当前已有的探索性 AI 产物（可复用的起点）

四、落地方案

4.1 设计原则

4.2 第一步：统一元数据层（地基，1 份脚本）

4.3 第二步：产出 `llms.txt` + 纯 `.md` 寻址（联网 Agent 入口，性价比最高）

4.4 第三步：`design.md`（设计语言上下文）

4.5 第四步：CLI（`@nutui/cli`，离线知识 + 项目工具）

4.6 第五步：MCP Server + Skill（IDE 集成与行为约束）

4.7 第六步（进阶）：版本化 API 快照

4.8 阶段规划与优先级

4.9 风险与注意事项

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

类别	命令	作用
知识查询	`antd list`	所有组件（双语名、分类、引入版本）
	`antd info <C>`	Props 表（类型、默认值、引入版本、废弃状态）
	`antd doc <C>`	完整 Markdown 文档（`--lang zh`）
	`antd demo <C> [name]`	可运行 Demo 源码（TSX）
	`antd token [C]`	全局 / 组件级 Design Token（v5+）
	`antd semantic <C>`	`classNames` / `styles` 语义结构
	`antd design.md`	设计语言文档
	`antd changelog [v1] [v2] [C]`	Changelog / 跨版本 API diff
项目分析	`antd doctor`	10 项配置诊断（React 兼容、重复安装、SSR、babel 插件…）
	`antd env`	收集环境信息用于 bug 报告
	`antd usage ./src`	分析项目中的 antd 导入与子组件分布
	`antd lint ./src`	检查废弃 API / a11y / 性能 / 最佳实践
	`antd migrate <from> <to>`	迁移清单，`--apply ./src` 生成迁移提示
问题反馈	`antd bug` / `antd bug-cli`	预览→确认→提交 bug 到对应仓库
CLI 管理	`antd mcp`	启动 MCP 服务（8 工具 + 2 prompts）
	`antd setup --client claude`	一键为 Claude/Cursor/VS Code/Codex 接入
	`antd upgrade`	升级 CLI

文件	说明
`llms.txt`	导航索引，列出所有文档/组件的 `.md` 链接
`llms-full.txt` / `llms-full-cn.txt`	把全部组件文档拼成一个大文件，可整体注入上下文
`https://ant.design/components/<name>.md`	单组件文档，按需精确拉取

阶段	交付物	依赖	优先级	说明
P0	`build-meta.mjs` + `meta/components.json`	无	⭐⭐⭐	一切的地基，工作量小
P0	`llms.txt` + 单组件 `.md` 路由	P0 meta	⭐⭐⭐	性价比最高，立即可用
P1	`design.md`	白皮书	⭐⭐	内容已有底稿
P1	`@nutui/cli`（知识查询命令）	P0 meta	⭐⭐	离线、可程序化
P2	MCP Server + 统一 `SKILL.md`	CLI	⭐⭐	整合现有探索物
P2	`nutui lint` / `usage` / `migrate`	CLI	⭐	项目体检
P3	版本化 API 快照	全部	⭐	v4 演进期高价值

Uh oh!

[FR]: NutUI-React 面向 AI Coding 的能力调研与落地方案 #3494

Description

一、背景与问题

二、Ant Design AI Coding 能力调研

2.1 @ant-design/cli —— 离线知识库 + 项目工具（核心）

2.2 llms.txt —— LLM 结构化文档入口

2.3 design.md —— 设计语言上下文

2.4 MCP Server —— IDE 深度集成

2.5 Skill (SKILL.md) —— 给 Agent 的"使用说明书"

2.6 小结：五类能力的协作关系

三、NutUI-React 现状评估

3.1 已具备的数据抓手（落地的地基，均已核验真实存在）

3.2 关键差距

3.3 当前已有的探索性 AI 产物（可复用的起点）

四、落地方案

4.1 设计原则

4.2 第一步：统一元数据层（地基，1 份脚本）

4.3 第二步：产出 llms.txt + 纯 .md 寻址（联网 Agent 入口，性价比最高）

4.4 第三步：design.md（设计语言上下文）

4.5 第四步：CLI（@nutui/cli，离线知识 + 项目工具）

4.6 第五步：MCP Server + Skill（IDE 集成与行为约束）

4.7 第六步（进阶）：版本化 API 快照

4.8 阶段规划与优先级

4.9 风险与注意事项

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

2.1 `@ant-design/cli` —— 离线知识库 + 项目工具（核心）

2.2 `llms.txt` —— LLM 结构化文档入口

2.3 `design.md` —— 设计语言上下文

2.5 Skill (`SKILL.md`) —— 给 Agent 的"使用说明书"

4.3 第二步：产出 `llms.txt` + 纯 `.md` 寻址（联网 Agent 入口，性价比最高）

4.4 第三步：`design.md`（设计语言上下文）

4.5 第四步：CLI（`@nutui/cli`，离线知识 + 项目工具）