后续拓展

D20 Vibe Designing Playbook 提供了一副更大的骨架：声明负责讲清“什么算对”，Skill 负责安排怎么做，Evaluator 负责查作业，没过就退回对应环节重做。Ant Design Skill 现有的规范和模板，正好可以放进这条链路里继续长。

在 Vibe Designing Playbook 的“设计声明与执行契约”章节 中：

spec.md 是功能定义声明
skill 是调度契约

spec.md 负责定义功能为谁服务、流程和状态如何成立、什么算验收通过；skill 负责决定这些声明在什么时机、以什么顺序进入生成过程；evaluator 再负责检查结果是否达标。

D20 将生成过程拆成：

规划
→ 搭骨架
→ 填充
→ 细化
→ 评估

所以，spec.md 在这里不是突然插进来抢戏的新主角。它只属于 D20 扩展框架，不是 Ant Design Skill 当前仓库里的必备文件。

能力分析

D20 能力

Ant Design Skill 当前对应物

完整程度

spec.md

无固定对应；依赖对话、PRD 或项目上下文

缺少统一解析步骤

domain.md

少量通用中后台语义

缺少具体业务领域声明

craft.md

布局、间距、视觉禁止项

已有较多内容，但与其他规范混合

design.md

global-style.css、Token 接入规则

较完整

components

references/components_*.md

较完整

template

scripts/**/*.tsx 和模板预览

较完整

skill

SKILL.md 的触发、选型和执行流程

已形成主体

evaluator

输出规则和验收清单

有基础，缺少独立执行和证据协议

这张表是为了帮我们理解结构，不是两边官方盖章的“一一对应表”，别拿它去做血缘鉴定。

理想形态

用户需求 / PRD / 任务单 / 现有代码
                  ↓
上下文解析器
提取角色、对象、状态、操作、验收与交付边界
                  ↓
若有关键歧义
在聊天中显示结构化选择或可视化表单
                  ↓
设计声明层
spec / domain / craft / design / components / template
                  ↓
Ant Design Skill 调度层
选择布局、规范、模板和 Token
                  ↓
生成与工程接入
React + Ant Design + 用户项目
                  ↓
Evaluator
类型检查、浏览器 QA、截图、规则评分、业务验收
                  ↓
通过 → 交付
失败 → 返回规划 / 骨架 / 填充 / 细化阶段

操作案例

用户说：做一个客户管理。

第一步不该是热情洋溢地生成 SideLayout，而是先低头看看现场：

是否已有 src/layouts？
是否已有路由？
是否已有 ConfigProvider？
用户是否说“从零”“现有项目”或“只要组件”？

如果仍无法确定，Agent 在聊天中展示：

这次希望我交付哪一种？

○ 现有后台中的客户管理页
○ 一套新的客户管理后台
○ 一个独立的客户表格 Demo

用户选择后，系统再形成任务声明：

delivery_scope: existing_application_page
reuse:
  layout: true
  router: true
  theme: true
generate:
  app_shell: false
  content_page: true

用户选完，Ant Design Skill 再进入模板选择。这样“问一句”就不是 AI 卡住以后临时求救，而是规划阶段本来就该有的步骤。

优化建议

当前 skill 优化

  • 增加交付边界澄清协议；

  • 在生成前检查现有页面 baseline、权限、工具和依赖版本；

  • 增加版本与兼容性清单；

  • 修复模板与 Token 规则的不一致；

  • 为全部模板增加构建、类型和样式检查；

  • 扩展模板预览覆盖面。

优化用户输入

  • 允许从对话、PRD、接口和现有代码提取功能成立条件；

  • 建立可选的 spec 与 domain 结构，但不强制固定文件名；

  • 将 craft、design、components、template 的职责进一步分离；

  • 为每一类声明增加机器可读索引。

引入标准 Evaluator 评估机制

  • 浏览器运行检查；

  • 桌面端和窄屏截图；

  • TypeScript、ESLint、Stylelint；

  • Token 与硬编码检查；

  • 页面类型对应的设计评分；

  • 阻断问题和放行结论；

  • 将失败项返回具体生成阶段。

补充沉淀新规则

  • 将反复出现的问题沉淀成新规则；

  • 将人工评审意见转换为可重复检查项；

  • 将已确认的视觉变化加入基准截图；

  • 记录哪个模板、规则或声明导致问题；

  • 新版本发布前自动重跑全部模板和 Evaluator。

愿景展望

完成上述演进后，Ant Design Skill 将从：

规范文档 + 模板 + Agent 操作手册

升级为：

业务上下文解析
+ 设计声明
+ Skill 调度
+ 模板生成
+ 工程验证
+ Evaluator
+ 失败回流
+ 规则持续维护

D20 Playbook 最有价值的启发，不是催着仓库再塞二十个页面模板，而是把现有模板和规范串成一条能提问、能执行、能验收、做错还能退回重来的生产链路。模板数量解决“有没有”，闭环解决“做得对不对”。

结论

优势和参考价值

  • 将设计规范转化为 AI 可执行的工作流程；

  • 提供经过筛选的企业级中后台组件组合；

  • 通过模板减少结构漂移；

  • 通过 Token 保持跨页面视觉一致；

  • 用禁止项和验收清单降低常见生成式 UI 问题；

  • 可作为企业构建自有 Design Skill 的参考框架。

不足和局限

  • 不负责定义具体业务；

  • 不是 Ant Design 全量组件文档的替代品；

  • 主要适用于中后台，不是通用视觉设计 Skill；

  • 需要 AI 正确加载并遵循规则；

  • 仍需要运行测试、视觉验收和业务验收；

  • 针对较新的 React 与 Ant Design 版本，旧项目需要处理兼容性。

总结

绕了一大圈，最后可以把最初的问题回答得很直白：

Ant Design Skill 不是“把旧模板打包给 AI 看”，而是把 Ant Design 的中后台设计经验，整理成一套 AI 能读、能照做、做完还能对照检查的生产流程。

它通过：

触发规则
+ 决策流程
+ 详细规范
+ TSX 模板
+ Design Token
+ 禁止项
+ 验收清单

来规范 AI 如何实现企业级中后台页面。

不过，它负责的是“怎样把业务正确地呈现和实现”，不是“你们公司的业务究竟该怎么运转”。要得到真正可用的产品，仍然得给 AI 足够的业务上下文：对话、PRD、任务描述、接口文档和现有代码都可以。团队如果采用 D20 的完整 Vibe Designing 方法，还可以进一步把功能成立条件沉淀为 spec.md。

如果一定要给它贴一张最准确的标签，我会写：Ant Design Skill 是业务需求、AI Agent 与 Ant Design 设计系统之间的实施层：上接“到底要做什么”，下接“页面具体怎么做”。

如果进一步放进 D20 框架，它还能从“规范与模板能力包”，长成完整生产链路里的 Ant Design 界面执行器：

业务与领域声明
→ Ant Design Skill 生成
→ Evaluator 验证
→ 不达标回流

到那时，它才不只是一个很会照手册施工的 AI 工具包，而是一套知道何时该问、按什么标准做、做错以后回哪一步重来的设计生产系统。