最近，一些看起来并不算复杂的工作，AI 交付结果却常常需要几分钟甚至几十分钟。这让我不禁产生疑问：难道随着模型能力不断增强，它的响应速度只能越来越慢？
实际上，真正的原因更多在于使用者自身。虽然 Agent 提供了模型和思考强度的调整选项，但为了省事，也为了追求更高的成功率，越来越多的开发者习惯把原本并不复杂的任务直接交给高级模型处理。与此同时，如今的 Agent 也不会像过去那样只关注被要求修改的那一小块代码，而是会主动扩大搜索范围，分析改动是否会影响整个项目，并尝试提前发现潜在问题。模型虽然变得更强了，但完成一次任务所承担的工作量也明显更多了。
除此之外，随着对模型能力的信任不断提高，交给它的任务粒度也在悄然变化。从最初修改一个函数、优化一个页面，到实现一个功能、完成一个模块，甚至直接开发一个完整产品，不知不觉间，AI Agent 已经被当成了一位真正的协作者。模型速度的提升，已经跟不上使用方式变化的速度。
换句话说，开发者追求的不再只是"更快地写代码"，而是借助 AI"更慢地写出更好的代码"。
从问答式到交付式，只用了短短一年时间。当开发者开始习惯一觉醒来接收成果时，真正的瓶颈也悄然发生了变化。过去，大家关心的是模型能不能完成任务；现在，更重要的问题变成了如何定义一个清晰、可验证的目标，以及如何降低实现目标的成本。模型越来越像团队成员，而高质量地组织和拆解工作，也正在成为新的效率竞争力。
用现代并发技术开发蓝牙应用
Delegate 仍是很多开发者在 Swift Concurrency 推出数年后不得不面对的问题：不仅代码组织繁琐，在 Swift 6 的严格并发检查下，也越来越难与现代并发代码自然协作。利用 Swift 6.2 的 Custom Executor，可以将 CoreBluetooth 的回调队列与 Actor 的执行上下文绑定，使 Delegate 回调天然运行在 Actor 隔离环境中，无需额外的锁、线程切换或同步逻辑。
Custom Executor 可以让 Actor 中的任务运行在指定的执行器上，是连接传统回调 API 与 Swift Concurrency 的一项重要能力。如果面临类似的迁移或封装问题，不妨参考这一实现思路。
CI 环境下的 Xcode 管理实践
随着越来越多开发者采用自建 macOS Runner 或云端 CI，稳定地管理 Xcode、Simulator Runtime 与签名环境，已成为工程维护的重要组成部分。围绕 Xcode CLI 在 CI 中的使用，有不少值得参考的经验：使用 DEVELOPER_DIR 替代 xcode-select 管理多版本 Xcode、自动安装与清理 Simulator Runtime 和 Metal Toolchain，以及利用 Compilation Caching 减少分支切换带来的重复编译。
榨干 GitHub Actions 的最后一点价值
GitHub Actions 的优化，未必意味着更激进的缓存、更复杂的 Workflow，或更多的条件判断。一个值得借鉴的思路是：让每一次 CI 执行都与实际风险相匹配。从一次看似普通的 Flaky Test 排查开始，逐步讨论了如何用确定性测试消除无意义的重跑、将可移植的检查迁移到 Linux、仅把真正依赖 Xcode 的验证留给 macOS，以及根据变更风险动态选择 Build、Test 或 Build for Testing，避免昂贵的 Runner 执行不必要的工作。
CI 的目标不是"跑得更多"，而是"回答正确的问题"。每一次昂贵的 macOS 构建，都应该验证一个更便宜的 Runner 无法验证的风险；每一次失败，也都应该提供足以推动修复的信息。
在 SwiftUI 中构建自适应非模态面板
从 WWDC 26 开始，iPhone-only 应用在通过 iPhone Mirroring 显示到 Mac，或在 iPad 上运行时，将进入可变尺寸环境。这意味着仅依赖 horizontalSizeClass 判断布局形态已经越来越不可靠。通过 onGeometryChange 在场景根部记录窗口尺寸与 Safe Area，根据真实可用宽度决定面板显示在底部还是侧边，是一种实用的解决方案。其中，在拖动期间保留已经解析的布局缓存，避免自适应内容因重复测量而出现尺寸跳变，是一个相当实用的技巧。
如果应用是 iPhone-only，并且仍有用户会在 iPad 或 macOS 上使用它，那么从今年开始就需要特别关注布局的适配。可变画布从某种意义上来说，不再保证开发者对界面布局拥有绝对控制权，而是将更多的选择权交到了用户手中。
SwiftUI @ContentBuilder：大幅提升 Xcode 27 编译效率
Xcode 27 引入了新的 @ContentBuilder。虽然它目前仍只是 ViewBuilder 的类型别名，但 Apple 已开始在新的 SwiftUI API 中推荐使用这一名称。对大多数应用来说，并没有必要立即将所有 @ViewBuilder 替换成 @ContentBuilder，已有代码在 Xcode 27 下同样能够受益于编译器的改进。
在之前的开发中，无论是 Table 还是 Charts，当将不同的 Builder 内容混写到 ViewBuilder 中时，Xcode 的类型推导和代码补全都会明显变慢。如果 Xcode 27 确实改善了这类场景，那么这次调整的意义就远不止一个新的 Builder 名称。
工具推荐
tswift: 用 Rust 构建轻量 Swift 运行时
无需 Swift 工具链、LLVM、代码生成或 C 依赖，即可解析、语义分析并执行 Swift 源码。tswift 以纯 Rust 实现了 Swift 前端，完成词法、语法与语义分析，再通过树遍历运行时实现 Swift 的语言语义与标准库行为。
除语言运行时外，项目也在探索框架层面的支持：SwiftUI 已具备基础渲染能力，Charts 支持覆盖 58/60 个范围成员，可输出 Web SVG，并可下沉到 iOS 原生 Charts。
无论是 C 编写的 miniSwift、Swift 编译器近期展现出的自举迹象，还是以 Rust 构建的 tswift，都展现出 Swift 生态正朝着更加开放、多元的实现方向发展。越来越丰富的实现路径，也让 Swift 的跨平台潜力呈现出超出预期的可能性。