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