不包含业务逻辑，仅用于组件使用

它包含的通用交互逻辑

模板和规范通常会覆盖：

  • 查询与重置；

  • 分页与排序；

  • 批量选择；

  • 表单校验；

  • 分步提交；

  • 编辑、删除等操作入口；

  • Loading、成功提示和基础异常提示。

这些属于通用的中后台交互模式，也就是换家公司大概率还能复用的部分。

可以这样理解：银行系统里都有“提交、取消、确认”，但每家银行的授信、风控和审批政策不会因为按钮长得一样就自动同步。

垂直业务逻辑需要补充

这套 Skill 不会自动知道：

  • 有哪些用户角色；

  • 谁能查看或修改哪些数据；

  • 对象有哪些业务状态；

  • 状态如何流转；

  • 什么条件下允许删除、审批或撤回；

  • 金额、库存或指标如何计算；

  • 数据来自哪些接口；

  • 操作失败后如何补偿；

  • 企业特有的验收标准。

这些内容总得有人告诉它，来源可以是：

  • PRD；

  • 需求说明、任务描述或其他团队文档；

  • 接口文档；

  • 数据库和领域模型；

  • 现有代码；

  • 用户或领域专家的描述。

明确分工

参与者

主要职责

人或 PRD

明确目标、用户、业务规则、权限、状态、接口与限制

AI

阅读需求与工程、进行推断、实现代码并运行验证

Ant Design Skill

提供页面选型、设计规则、代码模板和验收基线

所以更合理的分工是：人把业务意图和关键边界讲明白，但没必要连每个按钮离表格多少像素都亲自指定；后半段正是 Skill 该发挥的地方。

思考反思

Ant Design Skill 接管了页面选型、模板复用、通用交互和视觉一致性等重复劳动。再加上 Codex 一类 Agent，PM、设计师和工程师现在都可能直接生成、修改并运行代码。乍看之下，三种角色像是要合并成一个叫“都会一点的人”的新工种；但共同使用代码，并不意味着专业能力可以互相替代。

OpenAI Codex App 的产品与工程负责人 Andrew Ambrosino 在 Lenny’s Podcast 中也专门提醒过这一点：角色之间的禁区可以减少，设计师可以写代码、工程师可以参与设计、PM 也可以直接交付原型；但如果因此取消角色，就会连同每个专业积累的知识、方法和最佳实践一起丢掉。会使用 Excel 不等于能承担财务工作，同样，能生成代码也不等于已经具备产品、设计或工程判断。观看原访谈的相关段落（24:29）；主持人 Lenny Rachitsky 的要点整理

AI 时代真正松动的是“这不是你的工具，所以你别碰”的边界，不是专业责任本身。代码正在从工程师专属的最终交付物，变成产品、设计和工程都能使用的共同表达媒介。大家开始说同一种语言，不等于大家开始负责同一种问题。

同样是一段可以运行的代码，不同角色实际上在用它回答不同的问题：

角色

写代码或制作原型时，主要在验证什么

最终需要守住的成立条件

PM

用户问题是否真实、方案是否有价值、范围与优先级是否正确

值得做、做什么、先做什么

设计师

用户能否理解当前状态、完成操作、获得反馈并从错误中恢复

看得懂、用得对、出错后回得来

工程师

方案能否接入真实数据与权限，并在异常和规模化使用下稳定运行

可靠、安全、可维护

差异不再主要体现在“谁交 PRD、谁交 Figma、谁交代码”，而在于：面对同一个能运行的结果，各自拿什么标准打分，又在出问题时对哪类失败负责。

PM：从描述页面，转向定义业务成立条件

过去的需求可能直接写成“这里放一个表格，右上角放新建按钮”，仿佛按钮摆对位置，业务就已经成立。现在 PM 也能借助 Agent 做出可运行原型，但原型只是验证业务假设的媒介。PM 更应该明确：

  • 为什么需要这个功能；

  • 服务哪些用户和角色；

  • 哪些场景优先；

  • 对象有哪些状态；

  • 谁可以执行什么操作；

  • 什么结果算业务成功；

  • 时间、成本和风险如何取舍。

Skill 可以决定筛选区和表格怎么组织，Agent 也能把它写成代码，却不能替 PM 判断“已成交客户是否允许重新分配”。更不能因为按钮点得动，就宣布这个功能值得做——烤面包机也能联网，不代表它必须有朋友圈。

设计师：从逐页生产，转向建立和演进体验判断

设计师同样可以直接修改代码，但目的不是转职成另一个工程师，而是缩短设计意图与真实体验之间的距离：不用停在静态图上猜“动起来应该没问题”，可以亲手验证交互、状态变化和视觉结果。其职责会更多集中在：

  • 判断用户能否理解当前状态；

  • 设计操作路径、反馈、空态、错误态和恢复机制；

  • 为尚未解决的新问题创造高质量范例；

  • 将经过验证的范例沉淀为组件、模板和规则；

  • 诊断 AI 的错误来自业务表达、组件语义、页面骨架还是视觉工艺；

  • 维护产品的视觉语言、体验一致性和审美方向；

  • 将人工评审意见转化为可执行的 Evaluator 检查项。

例如，“已成交客户不能删除”是业务规则；按钮应该隐藏还是禁用、是否解释原因、批量选择时如何处理混合状态，则属于体验设计判断。

如果设计师只维护旧规范、不再探索新问题，Skill 会非常稳定地产出一批“没犯错，也没什么可说”的页面。因此设计师仍要亲自探索和实现未知场景，再把成熟答案沉淀回系统。此时写代码，是让设计判断变得可体验、可检验，不是戴上工程师工牌完成角色变身。

工程师：从手工翻译页面，转向保障执行系统

当 PM 和设计师也能生成代码时，工程师的价值就更不能按键盘敲击次数结算。工程师要判断一段“我电脑上能跑”的原型，是否真的有资格进入生产系统，并负责：

  • 将 Skill 生成结果接入现有路由、权限、数据和状态管理；

  • 保证类型、安全、性能和可维护性；

  • 建立模板构建、Lint、测试和视觉回归；

  • 检查 Skill 与依赖版本是否兼容；

  • 将验收规则变成可以自动执行的工具；

  • 确保失败、重试、回滚和监控机制真实可用。

AI 可以生成“批量下线”按钮，PM 或设计师也能让演示流程跑通；但权限、并发、审计、部分失败、重试和回滚都处理好以后，它才是一项生产能力。否则它只是一个气势很足的按钮。

AI：从辅助工具，转向受约束的执行者

AI 在这套分工中主要负责：

  • 读取业务与工程上下文；

  • 调用 Skill 完成页面和组件选型；

  • 复制并改造模板；

  • 生成代码；

  • 运行基础检查；

  • 根据明确反馈进行迭代。

AI 可以规模化执行已经说清楚的判断，但遇到关键业务、体验或安全条件缺失时，不该现场编一个答案再若无其事地继续。

从“串行交接”变为“围绕同一份可运行产物协作”

过去：
PRD → 设计稿 → 工程代码
角色主要通过不同文件串行交接

现在：
              ┌─ PM：验证业务成立
共同代码 / 原型 ├─ 设计师：验证体验成立
              └─ 工程师：验证系统成立
                       ↓
               AI 按 Skill 反复执行

角色可以更深地重叠：PM 可以改交互，设计师可以提交组件，工程师可以调整产品方案。所谓“负责”，指的是首要判断视角和最终责任，不是给工位画三八线。

因此，Skill 带来的真正变化，不是“设计师变成写规范的人”，也不是“大家都会写代码，所以 PM、设计师和工程师可以互相替代”，而是实现工具开始共享，交付边界开始重叠，但专业判断仍然不同。PM、设计师和工程师可以共同操作同一份代码，却分别对业务、体验和系统是否成立负责；AI 与 Skill 则把这些判断转化为可以反复执行、检查和演进的生产过程。

问题与拓展

Ant Design Skill 已经给中后台设计铺出了一条相当完整的轨道，但现在主要还是靠文档指令约束 AI。文档写得再认真，也不等于每次都有人把每条规则执行到位。下面的问题都来自源码和使用流程检查；哪些是事实、哪些是改进建议，会分开说，避免把“我觉得可以更好”写成“仓库已经有 bug”。

交付边界不明确时，缺少明确的暂停与询问机制

当前规则写明：

0 到 1 新建中后台时，默认生成导航布局与主内容区；
已有项目新增页面时，复用现有 Layout / 导航 / 路由壳。

来源：SKILL.md 第 210–223 行

问题是：用户只说“做一个客户管理”，工作区又看不出这是空项目、旧项目还是单页演示时，AI 可能把“不确定”翻译成“那我就按最大的做”，一口气生成导航和工程外壳。用户本来点了份盖饭，端上来一桌婚宴。

更稳妥的判断流程应为：

先检查用户表述
        ↓
再检查现有 Layout、路由和主题
        ↓
证据充分 → 自动判断
        ↓
证据冲突或仍然不足 → 暂停创建并询问

在支持聊天内结构化选择或可视化表单的 Agent 宿主中，可以直接显示：

请选择本次交付范围：

○ 在现有后台增加页面
  复用现有导航、路由和主题，只实现内容区

○ 从零创建完整管理后台
  创建导航、路由、主题和首批业务页面

○ 只创建单页或局部组件
  不生成应用外壳

推荐改进：

  1. 先做只读工程检查，不急于写文件；

  2. 有明确证据时自动选择，并在回复中说明依据；

  3. 无法确定时使用 Codex、Claude Code 等宿主提供的结构化提问或可视化选项；

  4. 用户未回答前，不执行会扩大交付范围的工程创建；

  5. 将最终选择记录为本次任务的“交付边界”，供后续步骤复用。

这里的原则是：

小细节可以合理推断；交付范围这种大事拿不准，就问。不能因为不知道用户要什么，默认给他最贵、最大、最难撤回的那个。

缺少“当前版本是否仍然适用”的验证协议

仓库当前 CHANGELOG.md 只有 v1.0.0 初始版本记录，而 SKILL.md 声明了 React 19、Ant Design 6 和 ProComponents 2.7 等目标版本。查看 CHANGELOG

版本号写在纸面上，不等于每个模板刚刚都跑过一遍。仅凭当前声明，AI 还无法确定：

  • 模板是否已适配依赖的最新小版本；

  • 某个组件 API 是否发生变化；

  • 当前用户项目是否应该升级或保持旧版本；

  • 仓库模板是否经过最近一次真实构建验证。

建议增加一个机器可读的版本清单，例如：

skill_version: 1.0.0
source_commit: a792078...
verified_dependencies:
  react: "^19.0.0"
  antd: "^6.0.0"
  pro_components: "^2.7.0"
last_build_verified_at: "<由 CI 写入>"
last_visual_review_at: "<由评审流程写入>"

同时把决策流程改为：

读取项目实际版本
        ↓
与 Skill 已验证版本比较
        ↓
兼容 → 使用模板
不兼容但可迁移 → 明示迁移范围
无法确认 → 询问用户选择

拿不准时，不要擅自把项目升级到最新版本，也别用自信语气假装一定兼容。可以老老实实把选择交给用户：

当前无法确认模板与项目版本完全兼容，请选择：

○ 保持项目现有版本并做适配
○ 按 Skill 基准版本新建
○ 先只生成设计与代码方案，不修改依赖

规则与部分模板之间存在可验证的不一致

总规则要求：

颜色、间距、圆角、阴影使用 CSS 变量，禁止硬编码色值

来源：SKILL.md 第 410–414 行

但批量表格模板仍包含：

style={{
  background: '#fafafa',
  borderRadius: 6,
  padding: '8px 12px',
}}

来源：04-BatchTable.tsx 第 121–128 行

这几行不一定会让页面当场爆炸，但场面略显尴尬：规则正在门口禁止硬编码，模板本人从后门带了几个进来。这说明“模板是否遵守自己的规范”目前仍主要依赖人工维护。

建议：

  • 增加 Stylelint 或自定义脚本，检测模板中的硬编码颜色；

  • 检测重复出现的固定间距和圆角；

  • 对允许写具体 Hex 色值的场景建立白名单，例如 ConfigProvider；

  • 每次修改规则后，自动扫描全部模板是否与新规则冲突；

  • 把检测结果作为发布新版本前的阻断条件。

模板具备交互骨架，但没有业务成立条件

批量表格模板已经有选择、取消和批量按钮，但按钮还没接真实处理函数。这个边界本身没问题——模板本来就不该替企业发明业务。问题在于，当前 Skill 也没有一个正式的业务输入步骤，确保 AI 开工前补齐：

  • 操作权限；

  • 状态限制；

  • 数量上限；

  • 审批条件；

  • 部分失败；

  • 重试与回滚；

  • 业务验收标准。

建议不要强制所有项目都创建某个固定文件，而是增加一个“业务上下文解析步骤”：

读取对话、PRD、任务单、接口和现有代码
        ↓
整理出角色、对象、状态、操作和验收
        ↓
缺少关键条件时向用户提问
        ↓
再进入 Ant Design 模板选择

整理结果可以保留在当前任务上下文中，也可以按团队现有的产品、领域或工程文档方式沉淀；Ant Design Skill 本身不应强制一种额外文件格式。

验收清单较多，但还不是完整的 Evaluator

当前 Skill 已经要求检查渲染、控制台错误、硬编码色值、TypeScript any、页面标题和间距，这是个不错的起点。只是现在更像老师在黑板上写了“交卷前请检查”，还没有真的逐题判卷。

不足在于，这些检查大多仍是文字指令，没有统一产出：

  • 实际浏览器证据；

  • 截图；

  • 自动测试结果；

  • 每条规则的通过或失败状态；

  • 阻断问题；

  • 是否允许交付的最终判断；

  • 失败后应返回哪个生成环节。

建议将验收清单升级为结构化结果：

result: blocked
checks:
  - id: token.no-hardcoded-color
    status: failed
    evidence: "04-BatchTable.tsx:125"
  - id: table.operation-column
    status: passed
  - id: runtime.console-error
    status: passed
blocking_issues:
  - "存在未进入 Token 系统的硬编码颜色"
return_to: "细化"

这样评估结果不只是给人看的一份体检报告，下一轮 Agent 也能直接知道哪里不合格、该回哪一步返工。

内容规模较大，分段阅读仍可能发生上下文漂移

当前源码基准下：

  • SKILL.md 约 486 行；

  • references/ 约 7,089 行；

  • global-style.css 约 2,484 行；

  • SideLayout.tsx 约 833 行；

  • TSX 模板共 32 个。

SKILL.md 已经要求按任务选读，方向没错。但规则仍散在长文档和大模板里：AI 可能记住了总则，却漏掉组件例外；也可能模板抄得很完整，唯独忘了接 Token。像开卷考试，资料全在桌上，不代表一定翻到了正确那一页。

建议增加机器可读索引：

task: batch_table
read:
  - references/components_Table.md#批量操作
  - references/global-style.css#table
copy:
  - scripts/table/04-BatchTable.tsx
validate:
  - token.no-hardcoded-color
  - table.batch-selection
  - table.operation-column

它可以让 Agent 精确读取必要区域，而不是依赖对整份文档的自然语言检索。

可视化预览覆盖的是代表性页面，不是全部模板回归

当前本地预览展示 7 个代表性场景，能够很好地帮助人理解模板，但仓库实际有 32 个 TSX 模板。

建议把预览演进成自动生成的模板画廊：

  • 每个模板拥有独立预览入口；

  • 固定桌面和窄屏截图；

  • 记录当前 Skill 和依赖版本；

  • 每次提交自动比较视觉差异；

  • 规则或 Token 更新后，所有模板统一重新渲染；

  • 视觉变化需要明确接受或驳回。

这样，预览就不只是给人参观的样板间，也能兼职做视觉回归测试：谁动了墙、谁换了颜色，提交以后都能看出来。

总结分析

这些不足不意味着 Skill 不能用。它现在更像一套训练有素的施工队加详细手册，而不是一座能全自动接单、施工、验收、返工的无人生产线：一套高质量的设计规范、模板和 Agent 操作手册。

距离完整的企业级 AI 设计生产系统，还需要补充：

歧义澄清
+ 版本与兼容性验证
+ 规则自动检查
+ 业务上下文解析
+ 可追溯 Evaluator
+ 浏览器与视觉证据
+ 失败回流