登录春晚、机器人、AI 与 LLM -- 肘子的 Swift 周报 #124
春晚、机器人、AI 与 LLM
作为一个观众数量超十亿的电视节目，央视春晚无疑是极佳的展示平台。今年春晚中，多家中国机器人厂商在不同节目中展示了其产品，其中讨论度最高的当属宇树（Unitree）的人形机器人。在表演环节，多款型号的人形机器人完成了大量较为复杂的武术与动态动作展示。与去年偏静态、偏站桩式的呈现相比，今年的动作复杂度与稳定性确实有明显提升，这一点也得到了全球媒体的关注与报道。
春晚之后，社交媒体上的讨论呈现出明显分化。除了对技术进步的惊叹之外，“预编程”、“没有 AI”、“缺乏实用性”等质疑声音同样不少。这在一定程度上反映了公众对机器人技术复杂度的低估——尤其是对运动控制、实时反馈系统和系统级整合难度的认知不足。
需要澄清的一点是：预训练并不等于“录制-回放”。当前人形机器人在此类表演中的确采用了高度规划的动作流程，这与人类舞者、运动员的训练逻辑有相通之处——大量的离线训练与调试构成了动作的基础，但在实际执行过程中，身体仍需依赖动态平衡与即时修正来应对真实环境的扰动。正是这种容错与实时修复能力，才让人形机器人这个天然不稳定的双足系统得以完成高动态的连续动作。
与此同时，近年来大语言模型（LLM）的爆发，让不少人将 LLM 与 AI 等同起来。事实上，AI 作为一个已有数十年发展的领域，远远不止语言理解这一分支。尤其是面对真实的物理世界时，视觉识别、路径规划、运动控制、强化学习等专用模型在工业与实体系统中的使用量，依然远高于 LLM。在机器人领域，真正决定能力上限的往往是感知系统、控制系统以及低延迟反馈算法，而不是语言推理能力。
即便未来为人形机器人引入更强的"认知能力"，更适合的路径也未必是直接接入 LLM，而可能是构建能理解物理规律的世界模型（World Models）与具备低延迟响应能力的控制系统——这两点恰恰是 LLM 的固有短板。具身智能（Embodied AI）的挑战，与纯文本推理存在本质差异。
至于“实用性”的问题，功夫或舞蹈确实难以直接对应现实工作场景。但恰恰是这些对平衡性、协调性与动态响应要求极高的动作，为人形机器人这种高度复杂且不稳定的系统提供了极佳的验证场景。它们更像是工程能力的压力测试，展示的是机械设计、电子控制与算法系统整合的成熟度，而非短期商业落地能力。
我个人对于人形机器人未来的市场规模仍然持审慎态度。技术进步与商业普及之间往往存在不小的鸿沟。但从今年春晚所呈现的进步幅度来看，可以合理判断：在未来十年内，机器人或智能机器以某种形式融入日常工作与生活场景，已不再是科幻想象。无论你是否喜欢“机器人”，技术演进的趋势已经十分明确，我们终将需要与它们共存。
至于“机器人奴役人类”的情景，我暂时并不担心。我更现实的担忧是：如果它们在工作中出现 Bug，给我一拳，我真的挨不住。
🚀 《肘子的 Swift 周报》
每周为你精选最值得关注的 Swift、SwiftUI 技术动态
- 📮 立即订阅 | weekly.fatbobman.com 获取完整内容
- 👥 加入社区 | Discord 与 2000+ 开发者交流
- 📚 深度教程 | fatbobman.com 探索 200+ 原创文章
近期推荐
如何在不破坏 App 的前提下迁移到 @Observable (How to Migrate to @Observable Without Breaking Your App)
随着越来越多的应用将最低系统版本提升至 iOS 17，@Observable 正在取代 ObservableObject 成为新的状态管理基础设施，但当项目已经深度依赖 ObservableObject + @Published 时，迁移远非简单替换宏即可完成。Pawel Kozielecki 结合一次真实的迁移踩坑经历，从底层机制差异出发，系统梳理了新体系下属性包装器的正确使用方式——用 @State 管理生命周期、用 @Bindable 处理双向绑定、只读场景直接使用普通属性，并特别指出了 @ObservationIgnored、计算属性追踪盲点等容易被忽视的细节。迁移的难点从来不在语法层面，而在于真正厘清“谁拥有 view model 的生命周期”这一根本问题。
验证多个回调按顺序触发 (Testing with Event Streams)
尽管 Swift Testing 提供了丰富的断言 API，但在实际使用中你会发现，并没有一个工具能够完全对应 XCTest 中“验证多个回调按顺序触发”（fulfillment + enforceOrder）的能力。confirmation 既需要嵌套使用，也无法直接校验触发顺序。对此，Matt Massicotte 提出了一种更符合 Swift 并发模型的思路：使用 AsyncStream 收集事件，并封装为一个轻量级的 EventStream 类型——当回调触发时 yield 事件标识，测试结束后通过 collect 获取完整事件序列，再与预期数组进行对比。对于“为什么不直接使用数组”这一疑问，Matt 也给出了充分理由：在存在 @Sendable 约束或 actor 隔离不一致的场景下，直接写入数组会触发并发安全问题，而基于 AsyncStream 的方案则天然符合并发模型的约束。
务必为 SwiftData 模型显式声明 Schema 版本 (If You’re Not Versioning Your SwiftData Schema, You’re Gambling)
SwiftData 的声明式写法与自动迁移能力很容易让人产生“框架会替我处理一切”的错觉，但现实是，一旦模型结构发生变化（字段新增、重命名、关系调整），如果没有显式的 schema version 与 migration plan，就只能依赖隐式推断。一旦推断失败，结果往往不是优雅的迁移，而是崩溃、数据丢失，甚至导致应用无法启动。Mohammad Azam 的建议直接而务实：显式声明 Schema 版本；为未来的结构变化预留迁移路径；将“迁移设计”视为模型设计的一部分，而不是事后补救。
本文的观点同样适用于 Core Data。即便模型完全兼容轻量迁移，为每个发行版本创建对应的模型版本文件（只要发生结构修改），不仅有助于追踪模型演化轨迹，也能在出现问题时实现清晰而可控的回滚。用明确的版本机制约束模型演进，本质上是在为长期维护建立安全边界。
用 Swift 开发 CLI 工具 (How to build a simple CLI tool using Swift)
一个有趣的现象是，在 AI Coding 时代，CLI 正在重焕青春——越来越多的开发者通过构建 CLI 工具来承载自己的 MCP 与 Agent 工作流。Natascha Fadeeva 介绍了如何用 Swift Package Manager 和 Apple 官方的 ArgumentParser 库构建结构化的命令行工具：定义主命令与子命令、处理异步网络请求、最终编译为可独立分发的二进制文件。对于已经熟悉 Swift 的 iOS 开发者来说，这条路径比维护一套 bash/Python 脚本更自然，也更容易随项目一起演进。
在 AI 编程时保持方向感 (Navigation Notes – Agentic coding)
作为一个拥有丰富经验的开发者，Joseph Heck 认为当 AI 能够主动执行任务、生成代码甚至推动改动时，开发者的角色从“逐行实现者”转变为“路径规划者”。真正稀缺的能力不再是写代码的速度，而在“导航”——也就是开发者在复杂代码与多代理环境中如何保持方向感。Joseph 给出了几条建议，例如：在提示词中始终加入"对任何模糊之处向我提问"；先让 Agent 制定计划并获得确认，再开始实施；提供确定性的反馈回路（单元测试、编译器错误），让 Agent 能够自我修正；以及将反复使用的指令集沉淀为 Skill 文件等。
Heck 并没有过度渲染“AI 颠覆开发者”的叙事，而是强调一种更冷静的现实：agentic coding 会放大已有的工程能力。如果你本来就善于模块划分与抽象设计，AI 会加速你；如果边界感模糊，AI 只会更快制造混乱。
为 Agent 驱动的 iOS 项目构建可靠交付管线 (Setting up a delivery pipeline for your agentic iOS projects)
当代码的生成、修改与重构开始由 Agent 驱动时，传统的 CI/CD 流程是否仍然足够？Donny Wals 以一次真实经历展开：健身时应用崩溃，他将 Crash Report 交给 Agent 分析，训练结束后 PR 已经准备就绪，合并后 TestFlight 构建随即落地。围绕这一实践，他系统梳理了如何为“agentic iOS 项目”构建一条可靠的交付管线（delivery pipeline），确保自动化改动依然可控、可验证、可发布。
文章的重点并不在某个具体工具，而在流程设计本身。Donny 强调，Agent 生成的代码本质上仍属于“未经人工逐行审查的改动”，因此更需要明确的边界与质量闸口：自动化测试、持续集成与发布流程必须承担最终的交付责任。Agent 可以显著提升实现速度，但工程纪律不能随之放松——速度提升之后，控制机制反而更为关键。
实时掌握 Foundation Models 的上下文消耗 (Tracking Token Usage in Foundation Models)
Apple 的 Foundation Models 运行在设备端，上下文窗口仅 4096 个 token，一旦超出便无法继续对话。iOS 26.4 新增了 token 用量追踪 API，帮助开发者实时掌握上下文消耗情况。Artem Novichkov 系统介绍了四个关键指标：模型上下文总容量（contextSize）、Instructions 的 token 消耗、单条 Prompt 的消耗，以及完整对话记录（Transcript）的累计用量。文章还揭示了一个容易被忽视的细节：当引入 Tool 时，其名称、描述与参数 Schema 会被序列化并计入 token，同一段 Instructions 在附加 Tool 后 token 数从 16 跃升至 79。对于设备端模型而言，token 的可观测性将成为优化体验的基础设施。
工具
App Store Connect CLI
App Store Connect CLI 是由 Rudrank Riyam 开发的非官方 App Store Connect 命令行工具，功能覆盖 TestFlight 管理、构建上传、代码签名、截图自动化、本地化同步、应用审核提交、notarization，以及财务报告下载等完整发布链路。它从设计阶段就强调 Agent 场景，并提供了面向 Agent 的实践文档。若你的发布流程重心在 TestFlight、元数据、提审、签名与 CI 自动化，ASC 可以作为 fastlane 的轻量替代方案之一。
GRDB 7.10.0: 新增 Android、Linux、Windows 支持
GRDB 7.10.0 是一个具有里程碑意义的版本更新：本次正式引入对 Android、Linux、Windows 的支持，并新增通过 Swift Package Manager 使用 SQLCipher（加密数据库）的能力——这两项功能都长期受到社区期待。这意味着这个 Swift 生态中最成熟的 SQLite 封装库，正在从 Apple 平台工具演进为真正的跨平台数据层解决方案。
Gwendal Roué 在 版本公告 中也特别说明，由于 Xcode 尚未支持 package traits，SwiftPM 目前仍会下载未实际使用的依赖；在相关问题解决之前，SQLCipher 支持将以 fork 形式长期维护。
Swift System Metrics
Swift System Metrics 为 Swift 应用（尤其是服务端项目）提供了统一的系统级指标采集能力，例如 CPU 使用率、内存占用、文件描述符数量等，并通过标准化的 Metrics 接口对外暴露，便于接入 Prometheus 等现有监控体系。它并非一个独立的监控系统，而是由 Swift Server Work Group 推动的基础设施组件，旨在与 Swift Metrics 生态对齐，使系统资源指标与应用级指标纳入同一可观测体系。1.0 的发布意味着 API 已趋于稳定，具备生产环境使用条件。对正在构建 Swift 后端服务、或持续完善 Swift 可观测性能力的团队来说，这是一个基础设施层面的关键拼图。
往期内容
💝 支持与反馈
如果本期周报对你有帮助，请：
- 👍 点赞 - 让更多开发者看到
- 💬 评论 - 分享你的看法或问题
- 🔄 转发 - 帮助同行共同成长
🚀 拓展 Swift 视野
- 📮 邮件订阅 | weekly.fatbobman.com 获取独家技术洞察
- 👥 开发者社区 | Discord 实时交流开发经验
- 📚 原创教程 | fatbobman.com 学习 Swift/SwiftUI 最佳实践
