摘要

本文从 Google Stitch 热度切入,对比“AI 画布式 UI 生成”与“代码内 UI 生成”两种路径,系统拆解如何用 Claude 4.6 + 前端设计规则,在真实代码库中迭代出可上线的 UI。附完整 Python API 调用示例与提示词模板,并结合多模型平台薛定猫 AI 的接入方式,帮助前端/全栈开发者把 AI UI 生成直接融入开发流水线。


一、背景:从“好看截图”到“可上线 UI”

当前 AI UI 方向大致两类路径:

  1. 画布式设计工具
    代表:Google Stitch 等
    核心能力:

    • 文本/图片提示生成界面草图
    • 支持简单原型、用户流程
    • 可导出到 Figma 等继续设计
  2. 代码内 UI 生成
    代表:以 Claude 4.6 这类强模型为核心,配合 IDE / 代理框架(如 Verdant、CLI Agent、Cloud IDE 等)
    核心能力:

    • 在真实代码库中改造前端界面
    • 理解项目结构、组件体系、产品约束
    • 输出可直接运行/上线的前端代码

视频的核心观点非常明确:

“如果你的目标不是一张好看的截图,而是能真正上线的高质量 UI,你不一定需要 Stitch,用 Claude Opus 4.6 + 合理的前端设计工作流就足够。”

因此本文重点不在“怎么用 Stitch 画图”,而是:
如何在代码层把 Claude 4.6 当成一个前端设计 + 实现协同的“强力 Coding Agent”。


二、核心原理:用模型做“艺术指导 + 工程实现”而不是“生成一张图”

2.1 好的 UI 不等于“给我做个仪表盘”

视频中对 UI 的定义非常工程化,值得摘出来当 checklist:

  • 层次(Hierarchy):信息优先级、视觉权重分配
  • 间距(Spacing):节奏感、留白、模块间关系
  • 排版(Typography):字体选择、字号体系、行高、对齐
  • 响应行为(Responsive behavior):不同屏幕断点的布局策略
  • 视觉节制(Visual restraint):不过度装饰,不过度动效
  • 动效一致性(Motion consistency):多屏间动画逻辑统一
  • 产品适配(Fit the product):风格与业务定位、品牌语调匹配,而不是“AI 拼贴感”

画布工具生成的是“孤立画面”;
而代码内生成可以直接考虑:

  • 现有组件库(如:Button、Card、Layout)
  • 路由结构、状态管理
  • 设计系统 Token(colors, spacing, radius…)
  • 真实数据结构

这就是“生成一段可运行的 UI” vs “生成一个好看的图层”的本质差异。

2.2 “前端设计 Skill”= 一层可执行的 Art Direction

视频里提到在 Verdant 中安装一个「Front-end Design Skill」,本质上就是一份稳定可复用的设计规则集 + Prompt 模板,用于给 Claude 4.6 清晰的约束和方向。

一个好的前端设计 Skill,至少要包含三类信息:

  1. 视觉论点(Visual Thesis)
    明确 UI 要传递的气质:

    • premium editorial / technical / playful / calm / dense / sparse
      示例:

    “深色金属风格 + 一处暖色点缀,整体偏冷静、专业”

  2. 内容规划(Content Plan)
    不是说“做一个 landing page”,而是拆到结构:

    • Hero 区(首屏视觉区域)
    • 支持证明区(Testimonials / Logos)
    • 流程/功能细节区
    • 仪表盘 / 设置面板
    • 最终 CTA 区(Call-to-Action)
  3. 交互论点(Interaction Thesis)
    明确 2~3 个定义整体体验的关键动效:

    • 分步进场(staggered hero reveal)
    • sticky scroll 区域
    • 悬停高亮交互意图的 hover 动效
      并明确“只要少量、有意义的动效,而不是十几个无用小动画”。

加上通用规则(后文会总结成一份“基础规则清单”),模型真正拿到的是一个可执行的设计系统,而不是一句“make it look better”。


三、实战:用 Claude 4.6 + 设计规则改造前端页面(Python + API 示例)

视频中操作的是 Verdant / Kilo CLI / Cloud IDE。为了便于普通团队复用,我们用一个更通用的方式:
通过 OpenAI 兼容 API(xuedingmao.com)远程调用 Claude 4.6,对现有 React 代码进行“带设计规则的重构”。

3.1 场景设定

  • 技术栈:React + Tailwind(示例)
  • 需求:为“AI 编码应用”的 landing page 设计 UI
  • 目标:
    • 按视频中的三要素定义:视觉论点 + 内容规划 + 交互论点
    • 按基础规则约束视觉风格
    • 输出可直接替换到项目中的 React 组件代码

3.2 Python 调用示例(基于OpenAI 兼容)

import os
import requests
import textwrap

# 1. 环境配置:替换为你在 xuedingmao.com 获取的 API Key
XDM_API_KEY = os.getenv("XDM_API_KEY")  # 或直接写死字符串,但不推荐
BASE_URL = "https://xuedingmao.com/v1"  # OpenAI 兼容 Endpoint
MODEL = "claude-sonnet-4-6"            # 默认使用 Claude 4.6 对标模型

def call_claude_for_ui_refactor(existing_code: str) -> str:
    """
    调用 Claude 4.6,对现有 React Landing Page 组件进行 UI 设计重构。
    重点演示:如何把“前端设计规则 + 视觉/交互论点”编码进 Prompt。
    """
    system_prompt = textwrap.dedent("""
    你是一名资深前端设计工程师(Design Engineer),
    擅长用 React + Tailwind 实现高质量、可上线的产品界面。
    你的目标:在不破坏业务逻辑的前提下,通过结构调整、排版、颜色和动效,
    提升页面的视觉质量与可用性,而不是简单加装饰。
    
    输出要求:
    - 仅输出完整、可运行的 React 组件代码(含 import),不要解释说明
    - 使用函数式组件
    - 保持传入 props 和数据结构不变
    - 样式以 Tailwind 为主,不额外引入 UI 库
    """)

    # 视觉论点 / 内容规划 / 交互论点 + 基础规则
    user_prompt = textwrap.dedent(f"""
    这是当前的 Landing Page 组件代码,请在其基础上进行 UI 设计与实现重构:

    ```tsx
    {existing_code}
    ```

    设计任务:这是一个「AI Coding App」的产品落地页。

    一、视觉论点(Visual Thesis)
    - 风格:cinematic editorial,偏高级技术感
    - 色彩:深色钢质质感背景 + 一处暖色点缀(如 amber/orange),整体冷静克制
    - 首屏:类似电影海报的强视觉感,而不是文档式排版

    二、内容规划(Content Plan)
    请按照如下结构组织页面(可以在现有内容基础上调整):
    1. Hero 区(全屏或视觉占比极高)
       - 核心标题:一句话清晰说明产品价值
       - 子标题:解释核心能力,如「在真实代码库中重构前端 UI」
       - 主 CTA + 次 CTA
       - 一个体现产品形态的视觉锚点(可以是代码片段、UI 截图框架、终端面板等)
    2. 支持证明区(Support / Proof)
       - 简短的信任背书:如「被哪些角色/团队采用」「关键指标提升」
       - 可以用简化的 logo 列表 / 数字摘要
    3. 流程细节区(Workflow Detail)
       - 用 3~4 步说明工作流:如「接入仓库 → 定义设计规则 → 并行探索 → 合并最优方案」
       - 每步配一段说明文字,视觉上形成清晰的步骤结构
    4. 最终 CTA 区(Final CTA)
       - 再次强调产品价值,给出明确行动:如「接入你的 Git 仓库」「开始 7 天试用」

    三、交互论点(Interaction Thesis)
    - Hero 区内容采用轻微的渐进式进场(可以用 Tailwind + 简单的 CSS 动画类名来表达结构,不必写复杂 JS)
    - Workflow 区支持「sticky」式滚动视觉(用布局结构体现出 sticky 容器,留出实现空间)
    - 重要可交互元素(按钮、卡片)在 hover 时通过阴影/边框/背景变化强化可点击性

    四、基础设计规则(非常重要,请严格遵守)
    - 不要使用「通用 SaaS 卡片网格」作为首屏第一印象
    - 首屏 Hero 要么 full-bleed(全宽全高),要么在视觉上远大于其它区域
    - 字体家族用两种以内(用 Tailwind 的字体类名协助表达)
    - 颜色:除非代码中已经有成熟 design token,否则控制在 1 个主色 + 1 个强调色 + 中性灰度
    - 首屏首个 viewport 要有「海报感」:强对比、大标题、明确视觉锚点
    - 每个 section 只负责一件事:标题 + 简短说明 + 结构化内容
    - 仅使用有意义的视觉锚点,不要堆砌装饰性渐变
    - 全局动效控制在 2~3 个类型以内,避免大量无意义 micro-animation
    - 文案风格:产品语言 + 工程语境,避免「营销式 fluff」

    输出形式:
    - 给出一个优化后的 React 组件,文件名可以为 `LandingPage.tsx`
    - 可以适度拆分为内部小组件,但全部写在同一个文件中
    - 确保语法完整、可以直接在 React + Tailwind 项目中编译通过
    """)

    url = f"{BASE_URL}/chat/completions"
    headers = {
        "Authorization": f"Bearer {XDM_API_KEY}",
        "Content-Type": "application/json",
    }
    payload = {
        "model": MODEL,
        "messages": [
            {"role": "system", "content": system_prompt},
            {"role": "user", "content": user_prompt},
        ],
        "temperature": 0.7,
    }

    resp = requests.post(url, headers=headers, json=payload, timeout=120)
    resp.raise_for_status()
    data = resp.json()

    # OpenAI 兼容格式:choices[0].message.content
    return data["choices"][0]["message"]["content"]

if __name__ == "__main__":
    # 示例:从本地读取当前 Landing Page 源码,然后让 Claude 重构
    with open("src/pages/LandingPage.tsx", "r", encoding="utf-8") as f:
        original_code = f.read()

    new_code = call_claude_for_ui_refactor(original_code)

    # 将生成的代码保存到新文件,人工 Review 后再替换使用
    output_path = "src/pages/LandingPage.ai.refactored.tsx"
    with open(output_path, "w", encoding="utf-8") as f:
        f.write(new_code)

    print(f"AI 重构后的 UI 已输出到:{output_path}")

这个例子就是把视频里强调的三件事(视觉论点 / 内容规划 / 交互论点)+ 设计基础规则,显式编码进了 Prompt,
然后通过一个 OpenAI 兼容接口调用 Claude 4.6,让它直接生成“准生产级”的 React UI。


四、注意事项:想要“可上线”,要把这几件事做到刚性

4.1 稳定规则要长期复用,而不是临时想起临时写

视频里作者每次都会给模型一套稳定不变的基础规则,这一点非常关键。可以抽象成一份 frontend_design_rules.md,在各种工具里复用:

  • 不用通用 SaaS 卡片网格做首屏
  • Hero full-bleed / 视觉占比最大
  • 字体 ≤ 2 种
  • 色彩控制在小而明确的调色板
  • 每 section 一件事
  • 只用有意义的视觉锚点
  • 动效种类控制在 2~3 个
  • 文案风格与场景一致(产品页面 vs 仪表盘文案区分)

不管你是在:

  • Verdant Skills Marketplace
  • Kilo CLI + 规则文件
  • Cloud IDE(例如 VS Code + AI 插件)
  • 还是本文这种 API 调用

都建议把这份规则当“设计系统的核心文档”,而不是每次想到什么写点什么。

4.2 Prompt 不是越抽象越好,要给“具体约束”

“make it look better” 典型失败原因是:模型只能输出平均水平的模板 UI
要避免这一点,至少写清楚:

  • 产品类型 + 用户画像(开发者工具 vs 消费端 App)
  • 核心场景(Landing、Dashboard、Settings…)
  • 预期情绪(冷静/活泼、严肃/创意)
  • 内容结构(以 section 列表方式说明)
  • 交互重点(选择 2~3 种动效,而不是“做很多动画”)

4.3 并行探索 + 人工合并,是当前最实用的工作流

视频中一个高价值细节:

  • 在 Verdant 中用“Plan First + 并行工作区”
  • 让模型基于同一规则生成多个方向
  • 人工比较差异,保留最好的部分,人工或再让模型 Merge

⇒ 这个思路在 API/CLI 里也一样可做:

  • 同一代码 + 不同视觉论点(偏冷静 vs 偏戏剧化)跑两次
  • Review 代码,挑选你喜欢的 layout / 动效实现
  • 手动 or 再次调用模型进行合并与精简

五、技术资源与工具选型

5.1 (xuedingmao.com)在这类场景的优势

对于需要长期做“多模型、多方向 UI 迭代”的团队,一个关键问题是:模型选型 & 接入稳定性

以本文示例使用的xuedingmao.com为例,它在这类需求上有几个实际好处:

  1. 聚合 500+ 主流大模型

    • 包括 GPT-5.4、Claude 4.6 / Sonnet、Gemini 3 Pro 等
    • 不同模型对代码理解、视觉描述理解的偏好不同,UI 相关任务可以快速 AB Test
  2. 新模型实时首发

    • UI 生成这一类任务受多模态/代码能力影响很大,新版本模型通常表现更好
    • 平台会较快接入新模型,避免你自己维护多家厂商的 API
  3. 统一 OpenAI 兼容接口

    • 正如上面的 Python 示例:只需换 BASE_URL + model 名称即可切换模型
    • 适合集成到现有的 AI Agent、CLI 工具、后端服务,不需要额外重写 SDK
  4. 适合做“流水线式” UI 迭代

    • 可以用同一 API 做:文案生成 → 组件结构规划 → 代码重构 → 单测辅助
    • 把 UI 设计/实现过程真正融入 CI/CD 或内部工具中

从纯技术选型角度看,如果你团队计划长期在“代码级 UI 生成 / 重构”上发力,一类聚合式平台能显著降低接入和迭代成本。


六、总结

  • 画布式工具(如 Google Stitch)非常适合快速视觉探索,但往往停留在“截图层面”。
  • 真正可上线的 UI,更需要:
    • 对代码库/组件/产品约束的理解
    • 稳定、可执行的设计规则体系
    • 并行方案探索 + 人工审查与合并
  • 利用 Claude 4.6 这类强编码模型 + 前端设计 Skill(规则集),可以在真实代码中完成 UI 设计与实现一体化:
    • 在 Verdant / CLI / Cloud IDE 里作为 Coding Agent 使用
    • 或通过 OpenAI 兼容 API(如薛定猫 AI)集成到自有工具链
  • 核心不是“让 AI 画界面”,而是“把 AI 变成懂设计的前端工程师”,用严格的设计规则和清晰的 Prompt,把输出质量拉到“可上线”级别。

#AI #大模型 #Python #机器学习 #技术实战

Logo

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。

更多推荐