Apple Watch 语音助手开发实战：从 watchOS 独立应用到开源落地

手表上的语音助手最难的部分不是某段录音代码而是搞清楚整个链路里哪些环节可以依赖系统、哪些环节必须自己做。Kuma Voice 是一个在 Hacker News 上展示的开源 Apple Watch 语音助手项目它最吸引人的卖点是不依赖 iPhone 就能完成语音交互。这个方向看起来是“做一个类似 Siri 的 App”实际落下去会同时碰到 watchOS 的应用形态、音频会话、网络能力、后台限制和开源合规问题。这篇文章以这类项目为背景从工程视角拆解一个不需要 iPhone 的 Apple Watch 语音助手应该怎么设计、怎么实现、怎么验证以及发布成开源项目时要注意哪些 OSS 细节。1. 重新理解一个不需要 iPhone 的 Apple Watch 语音助手1.1 为什么语音助手在手表上比手机上难做手机上的语音助手崩溃了可以随时重开网络不好可以静默降级屏幕也足够展示候选文本。Apple Watch 不一样它的处理器性能有限、电池容量小、屏幕只够显示几行文字而且大多数系统服务默认依赖 iPhone 的转发能力。一个完整的语音助手链路通常包含四段声音捕捉、语音转写、意图理解、回答生成与朗读。手机可以轻松承担这四段里的任意一段但手表不行。它的麦克风需要靠音频会话管理转写要么走系统语音识别框架要么把原始音频送到自己的服务器意图理解如果交给大模型网络请求和内存开销很容易让手表直接变烫最后回答还需要在极小的屏幕上处理文本展示和声音反馈。所以在手表上做语音助手不是把 iOS 的代码复制一遍而是要先把链路拆开决定每一段放在手表本地、系统服务器还是自建后端。1.2 “不需要 iPhone”不意味着手表完全脱离 iPhone先说清楚一个边界目前任何 Apple Watch 的初始配对、应用安装和系统更新都绕不开 iPhone。所谓“不需要 iPhone”在工程上的准确含义是语音助手在运行时录音、识别、联网、回答展示这些链路都不依赖旁边那台手机。这意味着两件事。第一手表必须能独立访问 Wi-Fi 或蜂窝网络。如果手表只能通过蓝牙连接 iPhone 上网那语音请求最终还是借了手机的网络这不算真正的独立。第二watchOS App 必须做成独立应用形态也就是 watch-only app。具体到 Xcode 工程里就是一个不依赖 iOS companion app 的 WatchKit App target。理解了这个边界之后再去设计语音链路思路会清楚很多先把“独立联网”作为硬性前提再把“不依赖 iPhone 资源”作为架构约束。1.3 这类开源项目带来的工程参考价值Kuma Voice 这类项目最有价值的不是它能不能打败 Siri而是它把一条完整的语音链路压缩进了一个系统限制极多的手表应用里。开源之后其他人可以复用它的权限处理、音频会话配置、识别请求封装、网络请求和开源合规清单。对多数开发者来说更实际的参考点是一个功能要做到什么程度才配得上叫“助手”。如果只是按下按钮、录音、显示一段转写文字那叫录音转文字工具。真正的助手需要把转写结果转成命令再触发某个动作比如查天气、设置计时器、控制家庭设备、播放媒体。后面的章节按照这个目标用最小可运行的方式一步步实现。2. 构建独立语音助手前要确定的四个技术前提2.1 开发环境与硬件要求开发 watchOS 语音应用前先确认工具链和测试设备。Xcode 的版本、watchOS 的最低部署目标、真机型号会影响可用的 API。项目推荐要求说明Xcode保持较新版本旧版本可能缺少新的 watchOS 模拟器和 Swift 并发支持watchOS 最低版本按实际需求设置要使用较新的系统语音识别能力时最低版本不能压得太低真机Apple Watch Series 及更新型号模拟器只能验证 UI 和部分逻辑麦克风与音频链路必须真机测试开发者账号免费账号可跑真机但有限制设备注册、描述文件、能力开启都依赖开发者账号网络手表需要 Wi-Fi 或蜂窝网络走系统语音识别或自建后端时联网是识别成功的前提有一点要提前说明不同 watchOS 版本对语音识别和后台任务的支持差异很大。正式开发前要在开发者文档里确认目标版本是否包含需要的 API不要只看网上旧代码。2.2 独立 WatchKit App 的项目结构独立 watchOS 应用至少包含两个 targetWatchKit App和WatchKit Extension。前者承载 storyboard 和静态资源后者承载实际逻辑。一個典型的目录结构如下KumaVoiceWatch/ ├── KumaVoiceWatchApp/ │ ├── Info.plist │ ├── Interface.storyboard │ └── Assets.xcassets └── KumaVoiceWatchExtension/ ├── Info.plist ├── ExtensionDelegate.swift ├── InterfaceController.swift ├── Audio/ │ ├── VoiceRecorder.swift │ └── AudioSessionManager.swift ├── ASR/ │ ├── SpeechRecognizerService.swift │ └── ASRBackend.swift └── Intent/ ├── IntentParser.swift └── CommandExecutor.swift单独建立Audio、ASR、Intent几个目录是为了后续可以替换实现。同一个AudioSessionManager可以让系统语音识别和自建后端的录音共用ASRBackend可以是一个协议协议下分别放系统 Speech 框架实现和 WebSocket 后端实现。如果直接在 InterfaceController 里堆录音和识别代码项目一旦增加离线命令、自定义唤醒词、多后端识别整个控制器会迅速变得无法维护。2.3 识别方案系统 Speech 框架还是自定义后端选用识别方案是语音助手最核心的架构决策。这里有两条主流路线。方案优点缺点适合场景系统SFSpeechRecognizer集成简单系统负责录音缓冲和音频转换代码量少多数语言依赖系统网络服务离线能力有限准确性受 Apple 服务影响快速验证原型演示中小规模单词与短句自建 ASR 后端可控制模型、语言、隐私和时延可替换成开源模型需要自己搭服务、处理认证、上传音频、管理并发长期产品特殊语言需要离线与私有化对 Kuma Voice 这类项目来说第一版用SFSpeechRecognizer最合理因为它能快速打通“录音—识别—显示”这个最小闭环。但要注意SFSpeechRecognizer在多数情况下依赖 Apple 的服务器手表必须先连上 Wi-Fi 或蜂窝网络。如果网络不可用isAvailable会变成false识别请求会报错。2.4 权限设计与隐私提示Apple Watch 上的语音助手至少需要两类权限麦克风权限和语音识别权限。两者缺一不可而且都是敏感权限。用户拒绝之后App 必须在界面上给出可理解的说明否则用户会认为“录音按钮坏了”。一开始的设计里就应该把权限状态作为一个预检步骤而不是在录音失败之后才被动提示。权限Info.plist Key用途麦克风NSMicrophoneUsageDescription录音时需要语音识别NSSpeechRecognitionUsageDescription使用系统识别框架时需要网络一般不需要额外声明若请求 http 资源涉及 ATS 配置在 info-list 的 XML 里示例keyNSMicrophoneUsageDescription/key string用于录制您的语音并完成语音指令/string keyNSSpeechRecognitionUsageDescription/key string用于将您的语音转换成文字并理解指令/string这两个描述要写清楚用途。不要写“用于改进模型”这类模糊话术用户在 watch 的隐私设置里能看到这段文字不明确的描述会降低信任度。3. 实现一个最小可用的“按下讲话”助手3.1 WatchKit 界面与交互结构先做一个最简单的界面一个按钮和一个文本标签。用户点击按钮开始录音再次点击结束录音并显示识别结果。在Interface.storyboard里放置button title开始/button label等待指令.../label控制器里建立对应的 Outlet 和 Actionimport WatchKit import Foundation import Speech import AVFoundation final class InterfaceController: WKInterfaceController { IBOutlet weak var resultLabel: WKInterfaceLabel! IBOutlet weak var actionButton: WKInterfaceButton! private let audioEngine AVAudioEngine() private var recognizer: SFSpeechRecognizer? private var recognitionRequest: SFSpeechAudioBufferRecognitionRequest? private var recognitionTask: SFSpeechRecognitionTask? private var isRecording false override func awake(withContext context: Any?) { super.awake(withContext: context) // 先使用中文识别实际项目可做成用户可配置 recognizer SFSpeechRecognizer(locale: Locale(identifier: zh-CN)) } IBAction func didTapActionButton() { if isRecording { stopRecording() } else { startRecording() } } }这个控制器只负责界面事件。录音、识别、命令解析不要全放进来但作为最小 Demo放在控制器里便于理解完整顺序。3.2 权限检查和音频会话配置点击开始之后第一步是检查权限。如果权限还没确定就去请求如果已经被拒绝就不要继续启动录音。private func checkPermissions(completion: escaping (Bool) - Void) { let micStatus AVAudioSession.sharedInstance().recordPermission switch micStatus { case .granted: checkSpeechPermission(completion: completion) case .denied: completion(false) case .undetermined: AVAudioSession.sharedInstance().requestRecordPermission { granted in DispatchQueue.main.async { if granted { self.checkSpeechPermission(completion: completion) } else { completion(false) } } } unknown default: completion(false) } } private func checkSpeechPermission(completion: escaping (Bool) - Void) { switch SFSpeechRecognizer.authorizationStatus() { case .authorized: completion(true) case .denied: completion(false) case .notDetermined: SFSpeechRecognizer.requestAuthorization { status in DispatchQueue.main.async { completion(status .authorized) } } case .restricted: completion(false) unknown default: completion(false) } }注意系统语音识别框架有两种使用方式。一种是在应用层直接实现SFSpeechRecognizerDelegate来监听availabilityDidChange另一种是请求时判断isAvailable。两者都应该写。如果用户在飞行模式下打开 AppisAvailable会返回false代码要在此之前给出提示。3.3 配置音频会话启动语音识别权限通过之后先配置AVAudioSession。语音识别对采样率和声道有要求。虽然SFSpeechAudioBufferRecognitionRequest能处理多种格式但把采样率设置为 16 kHz 单声道是更稳妥的做法因为它更接近语音识别模型常见的输入格式也减少带宽占用。private func configureAudioSession() throws { let session AVAudioSession.sharedInstance() try session.setCategory(.playAndRecord, mode: .measurement, options: [.allowBluetooth, .defaultToSpeaker]) try session.setPreferredSampleRate(16000) try session.setPreferredInputNumberOfChannels(1) try session.setActive(true, options: .notifyOthersOnDeactivation) }上面的配置里mode: .measurement会关闭系统对音频的额外处理保留比较原始的信号适合语音识别。实际项目中如果发现录音声音偏小或识别率偏低可以尝试把mode换成.voiceChat或.videoRecording观察差异。启动录音和识别的主流程如下private func startRecording() { guard let recognizer recognizer, recognizer.isAvailable else { resultLabel.setText(识别服务不可用请检查网络或系统语言设置。) return } checkPermissions { [weak self] granted in guard let self self, granted else { self?.resultLabel.setText(缺少麦克风或语音识别权限。) return } do { try self.configureAudioSession() try self.startAudioRecognizer() self.isRecording true self.actionButton.setTitle(结束) self.resultLabel.setText(正在倾听…) } catch { self.resultLabel.setText(启动失败\(error.localizedDescription)) } } } private func startAudioRecognizer() throws { let request SFSpeechAudioBufferRecognitionRequest() request.shouldReportPartialResults true recognitionRequest request recognitionTask recognizer?.recognitionTask(with: request) { [weak self] result, error in if let result result { let text result.bestTranscription.formattedString DispatchQueue.main.async { self?.resultLabel.setText(text) } } if error ! nil { self?.stopRecording() } } let inputNode audioEngine.inputNode let format inputNode.outputFormat(forBus: 0) inputNode.installTap(onBus: 0, bufferSize: 1024, format: format) { buffer, _ in request.append(buffer) } audioEngine.prepare() try audioEngine.start() }这段代码里有几个重要决策。shouldReportPartialResults true让用户能在说话过程中看到实时转写体验会好很多。代价是识别框架会频繁回调手表的 CPU 和网络消耗会上升。installTap的format参数不要写死应该使用inputNode.outputFormat(forBus: 0)。因为手表麦克风实际输出的格式由硬件决定直接写死采样率会导致音频数据格式不匹配轻则杂音重则直接崩溃。3.4 停止录音并输出结果停止录音不是直接销毁所有对象而是按顺序做三件事先停止音频引擎再移除 tap最后结束识别请求。private func stopRecording() { audioEngine.stop() audioEngine.inputNode.removeTap(onBus: 0) recognitionRequest?.endAudio() recognitionRequest nil recognitionTask?.cancel() recognitionTask nil isRecording false actionButton.setTitle(开始) }这里容易踩的一个坑是顺序。如果先把recognitionTask取消再调用endAudio()最终回调可能永远不会触发导致最后一次识别结果丢失。更好的做法是调用endAudio()让识别框架正常结束然后在回调或超时机制里清理状态。识别结果可能是一段连续更新的文本。真实场景里用户说完话之后需要等 0.5 到 2 秒让最终结果稳定。只显示formattedString的当前值会在句子中间出现“我想查天”这类半截内容。可以加一个简单规则当用户停止说话超过 1.5 秒就认为输入结束取最后一个结果作为最终指令。3.5 为什么不能把原始音频直接丢给自建后端如果后续要换成自建 ASR 后端很多人的第一想法是直接从AVAudioEngine拿原始音频编码成 WAV 上传到服务器。这本身没有错但要注意两个问题。第一AVAudioEngine输出的数据是 Float32 的 PCM而大多数 WebSocket 接口要求单声道 16 kHz 16-bit PCM 或者压缩格式。手表端不做重采样和位深转换上传的数据就会很大识别服务端还得自己处理格式。第二长段原始音频上传会显著增加耗电。一次 10 秒的录音如果是 48 kHz Float32数据量会非常大。所以生产级实现需要在手表端做预处理重采样到 16 kHz、转成 16-bit PCM、再按固定帧长切块发送。如果没用自建服务器第一版就用系统识别框架分担这个负担不要提前造重采样轮子。3.6 校验点模拟器能运行不代表真机可用开发到这里应该先在模拟器上跑一次再上真机。模拟器会用 Mac 的麦克风和音频设备逻辑上更容易跑通但它掩盖了真机最关键的干扰因素手表麦克风权限弹窗、音频会话被后台打断、网络切换成蓝牙时识别失败。一个初步的验证清单首次点击按钮确认麦克风和语音识别权限都出现过。拒绝权限后再次点击确认不会闪退并有文案提示。在安静环境说一句“设置一个五分钟计时器”确认转写文本完整。连续录音结束后确认audioEngine的 tap 被移除不会重复启动。把手表设为飞行模式再试确认识别服务不可用提示出现。4. 从“识别出文字”到“真助手”的后续设计4.1 用轻量意图解析取代会话理解识别出文字之后下一步是理解用户要做什么。手表算力有限不可能常驻一个大模型。第一版应该用规则或有限命令词表。例如支持“设置计时器”和“查询天气”两个命令enum VoiceIntent { case setTimer(duration: TimeInterval) case queryWeather(location: String?) case unknown } struct IntentParser { static func parse(_ text: String) - VoiceIntent { let trimmed text.trimmingCharacters(in: .whitespacesAndNewlines) if trimmed.contains(计时器) || trimmed.contains(定时) { let duration extractDuration(from: trimmed) ?? 0 if duration 0 { return .setTimer(duration: duration) } } if trimmed.contains(天气) { let location extractLocation(from: trimmed) return .queryWeather(location: location) } return .unknown } private static func extractDuration(from text: String) - TimeInterval? { // 解析 5分钟 三十秒 之类文本 return nil } private static func extractLocation(from text: String) - String? { // 从“北京天气”中提取“北京” return nil } }这段代码没有完成具体解析逻辑但它演示了一个关键原则意图解析是可以完全本地化的。不要为每一次“帮我设置 xxx”都建立一条服务器规则先把能本地完成的高频指令收敛到本地。4.2 从手表发出独立网络请求当意图需要外部数据时比如查天气手表需要发起自己的网络请求。这里的数据也要独立于 iPhone直接用URLSession。func queryWeather(location: String, completion: escaping (ResultString, Error) - Void) { let service WeatherService() service.fetch(location: location) { result in switch result { case .success(let weather): completion(.success(\(location) 现在是 \(weather.temperature) 度)) case .failure(let error): completion(.failure(error)) } } }注意watchOS 的URLSession是独立运行的开发者不需要把它经过 iPhone 转发。不过手表网络状态变化频繁Wi-Fi 和蓝牙切换时请求可能超时。请求要设置较短的超时时长比如 10 秒避免用户对着手表等很久。生产环境不要把手表端请求直接打到公网 API应该在自建服务前面加一层 API Gateway做鉴权、限流和日志。4.3 回答文本与声音反馈识别完成、命令执行后要把结果反馈给用户。小屏幕上的反馈必须简短尽量在四五个词以内。例如let answer 5分钟计时器已启动如果使用语音合成可以尝试AVSpeechSynthesizer但要在真机上确认音频接口的稳定性。Apple Watch 的音频输出能力比 iPhone 弱播放长句会显得很奇怪。更稳妥的反馈组合是文本展示 触觉反馈。WKInterfaceDevice.current().play(.success)触觉反馈不需要额外权限也不会被环境噪音掩盖在小屏幕上体验反而更好。4.4 断网和降级策略真正不需要 iPhone 的语音助手必然要面对断网场景。手表可以脱离 iPhone 但连不上 Wi-Fi或者蜂窝信号很弱。设计一个简单的降级策略场景行为网络不可用且识别框架不可用提示“无法连接网络”并列出本地可用的命令词网络不可用但系统支持设备端识别尝试设备端识别只识别离线命令词网络可用识别成功意图不匹配显示“暂不支持这个指令”网络可用识别成功意图匹配执行命令并反馈这里要强调的是不要把“网络不可用”包装成“语音助手坏了”。用户会理解手表在离线状态下能力受限但不会接受一个毫无反馈的 App。5. 运行验证、性能取舍与典型问题排查5.1 验证的重点从“能启动”转移到“链路正确”很多人在开发 watchOS App 时只验证到“能启动、按钮能点”。对语音助手来说这是远远不够的。必须验证整条链路而链路中最容易出错的是音频格式、权限状态和网络切换。建议用真机做下面的链路验证按下按钮确认录音权限弹窗和识别权限弹窗顺序正确。开始说话观察resultLabel是否出现实时转写。停止说话确认最终文本稳定。执行命令确认文本反馈和触觉反馈同时出现。打开飞行模式再次按下按钮确认“无法连接网络”提示出现且不闪退。连续录音十次检查是否出现内存增长或音频引擎无法重启。5.2 常见问题与排查链路问题现象可能原因检查方式处理建议权限弹窗不出现Info.plist 未声明权限或权限之前被拒绝查看 target 的 Info.plist检查权限状态补权限描述删除重装后重新授权点击录音后没有反应recognizer.isAvailable为 false在代码中输出 recognizer 状态和网络状态恢复网络检查系统支持语言识别结果秒出但内容为空麦克风采样率或声道与识别请求不匹配打印inputNode.outputFormat使用系统识别的默认格式不强行改采样率结束录音后最后一句丢失提前cancel()识别任务检查停止流程是否先endAudio先结束请求等待最终回调后台录音被挂起watchOS 对后台任务限制严格查看系统日志确认 App 是否进入后台尽量前台使用不要求长期后台监听手表连上网但识别仍失败SFSpeechRecognizer服务需要访问 Apple 服务用手机热点对比测试切换到稳定 Wi-Fi做网络代理测试5.3 功耗与资源观察语音识别是 CPU 和网络密集型操作手表电池容量小必须控制单次录音长度和整体使用频率。建议单次录音控制在 30 秒以内超时自动结束。在识别开始和结束时清晰停止audioEngine不要保持后台活跃。用 Xcode 的 Instruments 里的 Energy Log 检查耗电异常。不要在recognitionTask里做大量字符串处理避免主线程卡顿。对自建后端请求设置超时和重试上限避免用户反复点击后产生多个并行请求。6. 开源发布与 OSS 合规细节6.1 一个开源 watchOS 项目应该包含哪些文件开源的“开”不只是把源码推到公开仓库。Kuma Voice这类项目如果要让别人能快速跑起来仓库内容要做到自解释。基础文件清单文件作用README.md项目简介、环境要求、编译方法、使用说明LICENSE明确开源许可证Apache-2.0、MIT、BSD 等都行但必须存在CONTRIBUTING说明如何提交 issue、提 PR、运行测试CHANGELOG记录版本变化方便用户判断升级风险.gitignore排除xcuserdata、DerivedData、密钥文件THIRD_PARTY_NOTICES列出所有第三方依赖及其许可证很多新项目只放 README 和代码忽略 LICENSE。没有许可证的代码在法律上默认是“保留所有权利”使用者反而不敢用。开源发布第一步就是把许可证写清楚。6.2 依赖扫描与许可证冲突检查语音助手项目几乎不可能完全从零写。你可能会用第三方网络库、JSON 解析库、音频处理库甚至把某个开源 ASR 模型打包进后端。开源软件合规排查不是把依赖列一张清单就结束。一般团队会先用 Black Duck 或 FOSSA 这类工具做自动扫描扫描结果会自动提示某个依赖引入了什么许可证、是否存在传染性风险。在 CI 里加入扫描任务可以让每次升级依赖时自动产出提示。许可证特点常见场景需要注意的风险MIT宽松允许商用很多 Swift 库采用必须保留版权声明Apache-2.0宽松含专利授权后端服务和 SDK修改文件需要声明变更BSD宽松变种较多学术和系统库不同版本限制不同GPL-3.0强传染部分自研模型和工具如果被静态链接源码可能被要求公开AGPL-3.0更强的网络传染网络服务类软件通过 Web 提供服务也可能触发源码公开义务这里并不是说 GPL 不能用而是要在选型前评估。同一个库以动态库方式调用和以源码方式集成合规义务可能不同。对这个问题的准确判断必须结合具体项目和法务意见不能只靠下意识。6.3 第三方资源同样需要合规开源合规不只针对代码。项目里的图标、字体、动画资源、语音示例文件都可能来自第三方。处理原则是每一份资源都要有来源记录。如果你的团队使用对象存储来托管项目里的截图或音频样例例如云厂商的 OSS还要注意 URL 的访问权限不要把私密文件或 API 密钥录进仓库历史。尤其是语音助手项目很容易引入“唤醒词音效”“提示音”这类资源。免费音效不一定意味着可自由商用发布前要核对授权条款。最稳妥的做法是使用自己录制的资源并注明录制日期和作者。7. 生产化与下一步演进7.1 从技术 Demo 到产品级应用还缺什么一个能“按下说话并显示文字”的 Demo离生产级语音助手还有很长的距离。生产环境至少要补齐下面几层稳定的日志系统能在手表端记录识别事件、网络耗时、错误码。远程配置让识别后端地址、超时时间、功能开关可以不发版调整。鉴权与防滥用自建后端不能暴露给所有人随便调用。隐私策略录音数据是否上传、保留多久、如何删除要在产品层面写清楚。错误上报把NSSpeechRecognitionUsageDescription授权失败、网络超时等关键事件汇聚起来。对个人开发者来说这些工作量大但要做一个“真正的助手”而不是“技术演示”这些都是绕不开的。7.2 后续可以扩展的方向第一个扩展方向是设备端小模型。如果目标系统版本支持recognizer.supportsOnDeviceRecognition可以把高频命令切到设备端识别降低延迟和隐私风险。不过离线模型对语言、命令词、精度都有限制需要单独做测试矩阵。第二个扩展方向是本地快捷指令。Apple Watch 上有些系统能力比如设置计时器、开始体能训练、打开系统开关如果能用系统 API 在本地执行就不需要每次都走网络体验会明显提升。第三个方向是轻量自建后端。使用开源 ASR 模型自建服务让手表端上传音频、服务端返回结构化意图。这样做的好处是语言和命令词完全可控代价是要维护服务器、处理并发和扩容问题。7.3 给长期维护开源项目作者的建议维护一个开源 watchOS 项目最容易被忽视的是可测试性。语音识别和网络请求都依赖外部服务很难在 CI 里自动跑通。建议在代码里增加 Mock 层让ASRBackend在测试时返回固定文本这样核心意图解析、命令执行逻辑可以被单元测试覆盖。其次要保留一个清晰的错误码体系。Apple Watch 上的日志很难抓取用户不会帮你从控制台复制日志。可以在 App 内增加一个隐藏的诊断页面把识别器状态、授权状态、最近错误都显示出来用户截图反馈就够了。从 Kuma Voice 这个方向出发真正值得学习的是如何在高约束环境下做一个完整产品。watchOS 的独立语音助手涉及录音、识别、网络、命令处理、开源合规每一环都不复杂但组合起来很考验系统设计能力。对于想练手 watchOS 的开发者先把“按下说话并显示文字”跑通再把离线命令和降级策略补上这个过程中的收获会远远超过看懂一段示例代码。