用Xcode智能体创建UI原型：从一体需求到批量生成

用 Xcode 智能体创建 UI 原型说到底是把“写 SwiftUI 代码”这一环从纯手动变成“你提需求、智能体生成代码、你在预览里看效果、不行再打回重来”的循环。它解决的不是“我会不会写 Swift”的问题而是“想法变成可点击原型”这件事的速度问题。适合三类人不熟 SwiftUI 但想快速验证 iOS 界面想法的开发者需要快速出原型来对齐需求的产品或设计人员以及想把重复页面搭建交给工具的独立开发者。先说我的结论这类用法最值得关注的能力不是让智能体一口气生成整个 App而是能不能用最短路径跑通一个页面、一次跳转、一个状态切换。能跑通这三个基础动作后续的多页面原型、批量页面生成、组件复用才谈得上。下面按一个更接近现实的工作流展开先确认它解决什么问题再准备环境然后从最小原型一路做到多页面和批量生成最后补上验证、排查和边界。这里先限定一下“智能体”的范围避免误解。我讲的是具备多步任务规划能力、能读写工程文件、能执行构建或预览这一类操作的 AI 编程智能体。它可以是 Xcode 内建的相关能力也可能是通过命令行或第三方工具接入 Xcode 工程的方式。不同方案在具体命令和界面上存在差异但判断工作流是否健康的标准是一样的能不能稳定地生成代码、能不能在预览里看到结果、能不能把反馈再传回给智能体。你的环境里具体是哪种落地之前先确认清楚。1. 先搞清楚智能体在 Xcode 里到底帮你做什么1.1 智能体的真实价值把原型从“画图”变成“可运行代码”传统原型流程里Axure 和 Figma 是主流选择。它们擅长画静态页面和连线适合表达信息架构和交互路径。但有一个问题它们产出的结果离真实 iOS 运行环境很远。开发要照着设计稿重新写一遍 SwiftUI过程中的间距、字号、状态缺失很容易在传递中变形。用 Xcode 智能体创建 UI 原型的思路不一样。它直接生成 SwiftUI 代码原型跑在模拟器或真机上。你得到的不只是“看起来像 App 的图片”而是一个能点击、能跳转、能展示状态的运行中程序。对开发团队来说这种方式让“需求设计”和“技术验证”之间的间隙变短了对独立开发者来说它能快速验证一个界面想法在 iOS 上到底好不好看、顺不顺手。这种价值在处理“答题类界面”“信息录入页”“列表详情页”这类常见移动端页面时特别明显。框架结构是通用的但每个项目的间距、颜色、按钮位置都不同。智能体能根据你的描述直接生成对应代码你只需要在预览里看结果然后针对性提修改意见。1.2 和 Axure / Figma 流程相比差异在哪里用 Axure 画原型核心动作是拖拽组件、连页面跳转线。优点是快速、视觉可控、非技术人员也能上手。缺点是离代码远交互表达有限复杂状态很难模拟。用 Xcode 智能体生成 UI 原型核心动作是写自然语言需求、看预览、提反馈。优点是产物就是真实 iOS 代码交互和动效有机会直接验证缺点是门槛稍高至少要能操作 Xcode并对 SwiftUI 的基本概念有概念。两类流程不是互相替代而是适用阶段不同。如果边界是“给客户或领导看一个大概的布局”Axure 或 Figma 仍然高效如果边界是“在模拟器里点几下确认这个流程能不能走通”Xcode 智能体更合适。我个人的经验是快速探索布局时用拖拽类工具进入界面实现和交互验证阶段后尽快切到 Xcode 智能体。切换越早返工越少。1.3 什么场景最适合先上 Xcode 智能体我归纳了三个比较清晰的场景。第一个场景是技术验证型。不确定某个界面在 iOS 上能不能做、性能能不能接受直接用智能体生成一小段原型跑一下就知道。第二个场景是多版本比较。同一个首页想要两套布局、三套配色。让智能体各生成一版放在不同分支或不同文件目录里真机上看效果比口头讨论具体得多。第三个场景是前端不熟 SwiftUI但需要交付 iOS 原型。用自然语言描述页面结构智能体负责生成代码只要懂基本的预览操作就能推进。这不代表可以完全不懂技术但确实把门槛从“会写 SwiftUI”降到了“能描述清楚交互逻辑”。2. 搭建环境时不要先看功能列表先把最小链路跑通2.1 硬件和软件条件Xcode 的安装体积不小运行起来也吃内存和磁盘。用 Xcode 智能体创建 UI 原型硬件条件不用到顶配但也不能太勉强。建议至少满足这些条件Mac 能安装并运行当前版本的 Xcode系统版本按 Xcode 安装要求准备。硬盘剩余空间建议留出至少 30GB 到 50GB。Xcode、模拟器运行时、依赖缓存都会占空间。内存建议 16GB 以上。8GB 也能跑简单工程但打开 Xcode 再跑模拟器容易卡顿。网络环境要稳定。智能体的模型请求、依赖拉取、模拟器组件下载都需要网络。如果你的机器配置比较接近这个水平重点不是继续纠结硬件而是先跑一个空工程看看流畅度。Xcode 打开慢、索引久、模拟器启动慢都会影响你迭代原型的效率。但这些问题一般不影响最终产出只是需要多一点耐心。2.2 创建最小 SwiftUI 工程第一次测试不要直接拿现有 App 项目试也不要让智能体从零生成一个复杂工程。先在 Xcode 里创建一个新的 SwiftUI 工程选 iOS App 模板确认界面模板是 SwiftUI然后保存到本地。这一步的意义有两个一是确认你的 Xcode 环境本身能创建工程、能编译二是给智能体一个干净的工作目录。工程创建好后默认会有一个ContentView.swift里面是一个简单的文本视图。先编译一次确认开发环境没问题再让智能体介入。我一般会在工程里新建一个Prototypes目录把智能体生成的原型页面文件统一放进去避免和正式业务代码混在一起。等原型验证结束再手动挑出值得保留的代码挪到正式模块里。不要指望智能体生成的原型文件能直接当生产代码用至少先隔离管理。2.3 Preview 和模拟器的区别Xcode 的 SwiftUI 预览Canvas Preview和模拟器是两个不同层级的验证手段。预览更快适合看当前页面的布局和静态状态。你会发现修改代码后预览几乎秒级刷新。但预览不覆盖所有情况比如某些系统弹窗、键盘弹出、图片加载、路由跳转必须在模拟器里才能真正看到效果。模拟器更接近真机运行环境适合验证点击跳转、Tab 切换、列表滚动、键盘处理这类交互行为。缺点是每次启动有等待时间调试反馈比预览慢。做 UI 原型时这两者要配合用。智能体生成一个新页面后第一眼先看预览等几个页面串成了完整流程再整体在模拟器里走一遍。如果你发现预览里显示正常、模拟器里却表现不一样优先检查是不是有代码在预览环境下被跳过或者某些系统状态只在运行时才触发。2.4 两个常见的环境卡点第一个卡点是 Xcode 安装或升级后提示组件缺失。常见表现是模拟器无法启动、iOS 平台组件显示未安装、编译报找不到基础库。这类问题一般不复杂打开 Xcode 的设置页进入 Components 或 Platforms 管理界面把对应版本的模拟器运行时下载补齐即可。第二个卡点是用 Xcode 打开共享文件夹里的项目特别卡。很多人会把工程放在网盘同步目录或共享磁盘里结果索引慢、编译慢、文件锁冲突还不断。做原型阶段工程目录尽量放在 Mac 本地磁盘。尤其是智能体需要频繁读写文件时放到共享目录会产生大量同步事件严重拖慢响应速度。如果你已经遇到这个问题把工程复制到本地重新打开一次通常立刻缓解。注意第一次跑最小链路时不要开太多后台任务。Xcode 首轮索引、模拟器首次启动都会占用大量资源。等这轮跑顺了再恢复正常工作环境。3. 从一句话需求到第一个可点击原型3.1 给智能体一个能落地的任务描述智能体能不能生成好原型一半取决于模型能力一半取决于你给的任务描述。任务描述不是越短越好也不是越长越好。关键是让智能体理解页面结构、交互路径和视觉约束。我建议先给需求背景再给页面元素再给交互逻辑。比如在这个 SwiftUI 工程中创建一个登录页原型。 页面要求 1. 顶部显示 App 名称字体大一点加粗。 2. 中间是邮箱输入框和密码输入框带边框圆角。 3. 下方一个主按钮文字是“登录”。 4. 登录按钮下方一个次要文字链接文字是“忘记密码”。 交互要求 1. 点击登录按钮时如果邮箱和密码都不为空跳转到首页 TabView。 2. 如果为空显示简单提示文字。 3. 点击“忘记密码”弹出系统 Alert。这种描述的好处是明确可执行。页面结构、交互逻辑、判定条件都写清楚了智能体生成的代码不用大改就能跑。反之如果只说“做一个登录页”生成结果能用但大概率要反复调整布局和样式。热词里有人提到“给 codex 变成专业产品原型的提示词”。这说明很多人已经开始把大模型当成原型生成器用但最容易犯的错误是需求写得太泛。一个专业级提示词核心不是堆砌形容词而是把“有什么、点击后怎么办、空状态长什么样”写清楚。3.2 生成第一个登录页任务描述准备好之后让智能体在刚才创建的 SwiftUI 工程里创建代码。生成完成后先看预览。登录页这种常见页面智能体生成的结果通常可以运行。此时你要检查的点有三个布局是否合理。比如输入框和按钮的间距是否贴近真实 App 的感觉。状态是否完整。提示文字、按钮禁用状态、键盘弹出时的表现。代码是否干净。如果智能体生成了一堆无用注释或重复代码先让它清理不要带着一堆垃圾继续迭代。看一个简单的参考结构这是示例不是完整运行代码struct LoginView: View { State private var email State private var password State private var showAlert false State private var navigateToHome false var body: some View { NavigationStack { VStack(spacing: 16) { Text(DemoApp) .font(.largeTitle) .fontWeight(.bold) TextField(邮箱, text: $email) .textFieldStyle(.roundedBorder) .autocapitalization(.none) SecureField(密码, text: $password) .textFieldStyle(.roundedBorder) Button(登录) { if email.isEmpty || password.isEmpty { showAlert true } else { navigateToHome true } } .buttonStyle(.borderedProminent) .frame(maxWidth: .infinity) Button(忘记密码) { showAlert true } .font(.footnote) } .padding() .navigationDestination(isPresented: $navigateToHome) { HomeTabView() } .alert(提示, isPresented: $showAlert) { Button(确定, role: .cancel) {} } message: { Text(请输入邮箱和密码) } } } }这种页面本身不复杂。真正有价值的是让智能体在你加了新需求时能基于已有代码继续改而不是每次推倒重来。如果它推倒重来说明你对文件范围的约束不够后面会讲到。3.3 从单页到多页NavigationStack 和 TabView单页跑通后下一步是多页面串联。这是原型从“模板”走向“产品”的关键一步。多页原型通常围绕两个容器展开NavigationStack 负责页面层级跳转TabView 负责平级模块切换。你可以在需求里明确让智能体使用这两个容器。例如登录成功后进入首页首页底部有三个 Tab工作台、消息、我的。消息页面点击某一行后进入详情页。这个结构足够覆盖大多数移动端基础原型。按我的习惯我会让智能体先只生成容器和占位页面所有子页面先放一个简单的文本标题。这样跑起来很快结构也清楚。等容器稳定了再逐个页面填充具体内容。如果一次性把所有页面内容都让智能体生成任务太长、上下文太杂生成质量会明显下降还容易出现文件引用错误。3.4 状态与反馈可点击原型和静态原型最大的区别就是有状态和反馈。至少要实现以下几种表单校验提示。按钮点击后的反馈。加载状态的显示比如一个转圈或进度条。空数据时的页面。跳转动画是否自然。这些状态不需要全部做得很精细但至少要有一个能演示的状态入口。比如列表页没有数据时不能让页面一片空白而是要显示“暂无数据”。这种细节在需求评审时很有说服力也容易暴露交互逻辑漏洞。4. 控制生成质量的几个关键参数4.1 上下文和文件范围智能体生成效果差很多时候不是模型不行而是它没有理解工程上下文。它不知道当前工程里有哪些文件、哪些组件、哪些命名风格。所以你让它生成一个新的首页时它可能自己新建一个文件而不是引用你已有的组件。解决方法是明确限定文件范围。如果是在同一个工程目录操作要求智能体先读取现有文件结构再修改指定文件如果要新建文件明确给出文件名。例如“在 Prototypes 目录下新建 HomeView.swift里面定义 HomeView 结构体不要修改其他文件。”上下文长度也有影响。任务描述越复杂、历史对话越长智能体越容易丢掉前面的内容。我的习惯是一个原型页面一个会话不要在同一会话里堆十几个页面的任务。这能有效减少生成结果跑偏的情况。4.2 显式约束生成 UI 原型时我会在提示词里加一组显式约束避免智能体自由发挥原生控件尽量使用系统原生组件。不引入第三方库原型阶段不要额外加入复杂的依赖。布局方式用 SwiftUI 标准布局不像写 UIKit 那样手动设 frame。适配操作要求避免出现横屏时布局崩坏的情况。这些约束看起来简单作用很大。缺少它们时智能体可能会生成依赖某个第三方库的代码你编译时才发现要额外引入包原型迭代节奏就被打断了。一个通用提示词片段可以这样组织技术约束 - 使用 SwiftUI不使用 UIKit。 - 不引入额外第三方依赖。 - 使用 NavigationStack 管理页面跳转。 - 所有文本和颜色先用系统默认值后续再统一调整。4.3 拆分任务把一个大的原型需求拆成小任务是提升生成质量最直接的手段。比如一个包含首页、消息、我的、详情页的 App 原型不要一口气让智能体生成全部。我会拆成四轮第一轮创建 TabView 容器三个 Tab 都放占位文本。 第二轮实现首页内容。 第三轮实现消息列表和详情页跳转。 第四轮实现“我的”页面添加头像、菜单列表等元素。每轮结束都编译一次、预览一次、确认通过后再进入下一轮。这样做即使某一步出问题也能很快定位是哪个文件、哪次改动导致的。4.4 预览配置如果你需要给非技术人员看效果预览本身也可以有一些配置技巧。比如固定 Preview 设备为 iPhone 15 Pro 或者当前主流机型避免显示在一个奇怪的设备尺寸里影响判断。还要注意 Preview 默认数据。页面里用到列表时如果数据源为空预览会看到一个空白列表容易给人一种“功能没实现”的错觉。让智能体在 Preview Provider 里创建少量示例数据演示效果会好很多。5. 批量生成页面和沉淀可复用组件5.1 批量任务的正确打开方式原型做大了以后批量生成多个页面是刚需。比如一个后台管理系统有十个数据列表页一个电商应用有商品列表、订单列表、优惠券列表。如果每页都手动让智能体重新生成一遍效率并不高。更合理的做法是先把其中一个列表页做到满意然后以它为样板要求智能体按相同结构生成其他页面。提示词可以这样写参照 Prototypes 目录下的 ProductListView.swift 的结构 新建 OrderListView.swift 数据模型为 Order字段包括 - id: String - status: String - amount: Double - createdAt: Date 页面字段和交互逻辑要保持一致只替换数据字段名称。这里的关键是“样板 差异描述”不是重新描述整个页面需求。样板负责定义结构差异描述负责定义新页面的特殊点。5.2 命名和目录规划批量生成以后文件命名直接决定你能不能快速找到并维护它们。我建议统一命名规则页面类型前缀 业务名称。比如LoginView、HomeView、OrderListView、OrderDetailView。目录可以按业务模块分也可以在原型阶段统一放在Prototypes目录下。如果你发现智能体生成的页面对外跳转时写死了路径比如直接用HomeView()要注意它可能没考虑页面之间的参数传递。先记下来原型阶段可以接受到了正式开发阶段必须改成更规范的路由方式。5.3 沉淀组件库批量生成页面后你会发现很多视觉元素是重复的。比如统一的卡片背景、统一的列表行、统一的空状态视图。这些重复代码如果散落在各个文件里维护成本会越来越高。正确的做法是把它们抽成可复用组件放进独立文件里然后要求智能体在后续生成页面时优先引用现有组件。这有点像前端里维护一套自己的通用组件集。比如前端有 Element UI 这类成熟组件库可以套用iOS 侧没有完全等价的东西但你可以沉淀自己的 SwiftUI 组件目录。原型的价值在这里体现得很明显它不是一次性产物而是下一轮正式开发的代码素材。5.4 把任务变成固定工作流如果你所在的团队经常要出 iOS 原型可以把这套流程固定下来。比如在智能体平台或团队内部搭建一个固定的“iOS 原型生成”工作流输入产品需求文档输出 SwiftUI 原型文件。网上经常有人讨论各类智能体平台和框架但工具具体叫什么并不是重点。重点是工作流里要包含几个固定环节需求清洗、页面拆解、代码生成、预览验证、反馈回填。任何智能体平台只要支持调用模型并读写文件都可以按这个链路搭建。6. 验证原型不要只看“能编译”6.1 编译通过不等于可用Xcode 里编译通过只是说明代码没有语法错误。它不代表页面布局合理、交互逻辑正确、不同尺寸下显示正常。一个典型的反例按钮在预览机型上显示正常换到小屏机型后超出屏幕边界。原型阶段如果只看编译结果这类问题一定发现不了。所以验证原型要有明确标准。我的基本要求是能在预览里正常显示。能在模拟器里完成主要点击流程。任意一个主要页面切换时应用不崩溃。文本在正常字号下不会明显溢出。列表滚动时没有明显卡顿。达到这五条原型就算基本合格。不要在这个阶段去抠动画曲线、阴影细节和真实字体那是正式视觉设计的范围。6.2 按交互路径走查每次让智能体改了原型之后我建议按交互路径走一遍而不是随机乱点。比如登录流程完整的路径是输入邮箱密码 - 点击登录 - 进入首页 - 点击消息 Tab - 点击某个消息 - 进入详情页 - 返回上一页 - 退出登录或切换账号。每一步都要走通。不要小看这种基础走查。智能体生成的跳转逻辑经常会出现返回按钮丢失、Tab 切换后状态被重置、详情页没有返回入口这类问题。只有完整走一遍流程才能发现它们。把走查结果作为文本反馈给智能体。比如“从消息详情页返回后列表滚动位置回到了顶部能不能保持原来的位置”大部分情况下智能体能基于反馈做出合理修复。6.3 真机验证与对外展示模拟器验证通过后如果条件允许建议在真机上跑一遍。真机能看出模拟器里不容易发现的问题比如键盘弹起挡住输入框、相机或相册权限弹窗、实际字体渲染效果。对外展示原型时我更推荐用真机而不是一直截屏。真机演示最大的优势是信任感强对方能直接体验点击反馈和跳转动画而不是看着一张静态图想象交互。不过真机调试需要处理签名和设备信任问题这些都属于常规流程不用太紧张。注意原型阶段验证通过不代表可以拿同一份代码直接打包发布。打包发布涉及签名、证书、App 图标、启动屏、版本号、隐私权限声明等一系列配置。网上讨论 Xcode 打包发布 iOS 应用时提到的流程通常在原型阶段还用不到。先专注把原型验证好再考虑发布流程。7. 常见问题排查链路7.1 先看现象再动手原型用智能体生成时出问题的概率不低。遇到问题我的排查顺序是固定的看现象是编译失败、预览空白、运行崩溃还是生成结果不符合预期。看输入你给智能体的任务描述是否清楚文件路径是否正确。看环境Xcode 版本、模拟器状态、磁盘空间、网络是否正常。看改动这轮生成之前代码是好的这轮改了哪些地方。看日志Xcode 控制台和编译日志里的具体报错信息。很多人一遇到生成代码编译失败第一反应是自己手动改代码。我更建议先把报错信息原样贴回给智能体让它修复。大多数简单错误智能体自己就能处理。7.2 生成代码编译失败编译失败是最高频的问题。常见原因有三类。第一类是符号缺失。比如智能体在某个文件里使用了HomeTabView()但这个类型还没有定义。解决方法是让智能体先创建缺失的文件或者改成指向现有页面的占位结构。第二类是 API 使用错误。比如某个NavigationLink的用法在新版本 SDK 中被废弃了。这类错误需要看编译日志里的具体提示然后让智能体按当前 SDK 的推荐写法修改。第三类是文件重复定义。同一个结构体在多个文件里声明了。这通常发生在多个会话让智能体重复生成同一个页面时。删除多余文件保留一个版本即可。7.3 预览空白或卡住预览空白先不要急着怀疑智能体生成的代码有问题。优先级更高的是先看 Preview 窗口左上角有没有正在编译的提示或者有没有报错信息。很多时候只是编译没有完成等几十秒就好。如果编译完成仍然空白再查代码本身。最常见的两个原因页面主体没有设置背景色导致在深色模式下显示异常或者页面依赖的某个数据初始化失败运行时直接卡住了。让智能体在代码里加一个简单的占位数据通常就能解决。预览一直卡住时可以试这些操作停止预览、退出并重新打开 Xcode、删除工程的DerivedData缓存。这些操作不改变业务逻辑但能解决大量注意力放在“代码错误”上其实并不是代码问题的场景。7.4 生成结果不符合预期生成结果不符合预期本质上是任务描述和实际输出之间存在偏差。比如你想要的“弹窗提示”智能体实现成了“页面底部的一条文字”。这种偏差不要直接怪智能体而是把偏差描述清楚继续提需求。我看到热词里有人问“请问原型还需要用 Axure 来设计吗直接可以用 AI 来生成了吗”。这里面的关键不是工具谁替代谁而是你对结果的判断标准是否明确。明确之后AI 生成原型完全可行不明确时用任何工具都会反复返工。要让反馈更有效可以采用这个格式当前的问题 - 点击“确认”按钮后页面没有任何反馈。 - 我希望点击后弹出 Alert并显示“保存成功”。 涉及文件 - Prototypes/OrderEditView.swift问题、期望结果、涉及文件三个信息都给到智能体的修复成功率会高很多。7.5 Xcode 本身卡顿和文件访问问题Xcode 卡顿可能由多种原因引起。最常见的是首轮索引、模拟器同时启动、后台有大量进程抢资源。如果你的工程放在共享文件夹或云同步目录里打开和编辑都可能明显变慢。尤其是智能体频繁读写文件时同步工具会不断触发冲突检测和上传任务CPU 和磁盘的负担会叠加。这类问题的解决方式最简单把工程移到本地目录等当前原型任务完成后再同步回共享目录。还有一个容易被忽略的问题是 Xcode 升级后智能体生成的代码使用了一些本地环境中不存在的 API。这时不一定是你写错了而可能是 SDK 版本不同。处理方法是把报错信息带上 SDK 版本一起反馈给智能体它才能针对你的实际环境调整代码。8. 哪些场景不要指望 Xcode 智能体8.1 高保真品牌视觉稿Xcode 智能体适合生成应用结构、页面流程和基础交互但不适合做精细的品牌视觉稿。它可以生成一个“看起来还不错的详情页”但很难精确还原一套需要严格对齐间距、字重、色彩变量的设计系统。需要高保真品牌稿时主战场仍然在专业设计工具里。设计师先在 Figma 或 Sketch 里确定视觉规范再把关键页面交给智能体实现或参考这才是更合理的工作路径。8.2 复杂动画和自定义手势动画和手势是智能体的弱项。原型阶段跑通基础交互没问题但涉及复杂转场动画、拖拽排序、多指手势、物理效果模拟时智能体生成的代码往往是“能看”而不是“能用”。遇到这类需求我的建议是先明确交互逻辑再手动写核心动画代码最后让智能体辅助处理周边页面。不要指望靠生成一步到位。8.3 跨平台快速分享的轻量原型如果需求的受众主要在 Windows 电脑上查看或者完全不关心 iOS 运行效果只想快速看一个页面流转Xcode 智能体其实不是最优选择。因为 Xcode 本身只能跑苹果生态的原型对方还得有一台 Mac 才能完整预览。这种轻量场景直接继续用网页原型工具或跨平台工具更省事。Xcode 智能体的优势在于贴近真实 iOS 环境代价是调试和查看都需要 Mac。8.4 离上线打包还很远热词里有不少关于 Xcode 打包发布 iOS 的讨论。如果原型还在快速迭代阶段不要提前进入签名、证书、版本管理、权限声明这些发布流程。这些配置会分散你对界面和交互的注意力而且原型阶段频繁改动代码后也不会考虑包体积和性能优化。建议是跑原型时只用模拟器验证或者用开发者签名跑真机就够了。等到功能稳定再花时间整理配置进入正式开发流程。踩过几次之后我发现用智能体做 UI 原型真正决定效率的往往不是模型多聪明而是你的需求描述是否干净、文件目录是否清晰、验证流程是否固定。先把单页面跑稳再上多页面再谈批量和组件沉淀。这套顺序不乱Xcode 智能体就能变成一个非常顺手的原型工具顺序乱了它就只是一个昂贵的代码生成器。