AI 想放弃了人没有最近Linus Torvalds 在调试一个 Intel Xe GPU 驱动问题时经历了一场被他自己称为“debug session from hell”的漫长排查。最终的修复简单得有些不可思议把一处round_up()改成round_down()。但为了找到这一行代码他前后添加了 24 个调试 patch启动了 18 次 kernel。其中大量繁琐工作都是在 AI 的帮助下完成的。这个故事最有意思的地方并不是“AI 帮 Linus 修复了 Linux Kernel Bug”而是 AI 在过程中数次想要放弃。它曾明确告诉 Linus这个问题“impossible and unsolvable”建议停止继续调查。Linus 没有接受这个判断。在他的坚持下AI 虽然数次认为问题已经无法解决却仍然忠实地执行新的任务最终和他一起找到了那个只需要修改一行代码的原因。这其实很好地展现了现阶段人与 AI 之间一种颇为微妙的关系。随着 Agent 能力不断增强我们已经可以把越来越完整的工作交给 AI阅读代码、提出假设、编写调试工具、执行验证甚至根据新的结果不断调整下一步行动。过去需要开发者亲自完成的大量重复劳动正在被压缩人也因此逐渐从具体的执行过程中抽离出来。但这并不意味着人的作用正在以同样的速度缩小。恰恰相反当 AI 开始参与分析、提出建议甚至给出“这个问题无法解决”这样的判断时人真正需要承担的职责反而变得更加清晰决定什么值得做判断什么时候应该相信 AI又在什么时候拒绝它的结论。尽管并非所有人类的坚持都会获得类似本次的圆满结果但有时候再坚持一下的理由至少不应该被 AI 的一句“不可能”轻易抹去。本期内容 | 前一期内容 | 全部周报列表原创从使用 AI 到委托 AI我的一些思考当一项工作已经有明确目标、边界和验收要求时怎样把它真正交给 AIAgent 能完成的工作越复杂这个问题就越突出。模型的输出存在波动上下文变长后目标和规则可能逐渐淡化拆进多个上下文又会带来信息损失和交接偏移。让另一个模型复核也不意味着结果一定会自然收敛。这些问题最终指向同一个词可委托性。本文是我对 AI 可委托性的一些思考执行范围是否稳定结果能否被信任投入是否可以预期以及什么时候需要人介入。相比追求某一次执行的最好结果我更关心如何通过明确边界、验收标准、外置的权威记录以及合理的人机分工让 Agent 在更长、更复杂的任务中保持稳定并让失败能够被发现和纠正。文章最后也结合我目前使用的 Task-Driven 工作流展示这些原则如何落实到实际的 AI 开发过程中。近期推荐认识 Swift 包注册表 (What is a package registry?)Swift Package Index 加入 Apple 后双方宣布将共同建设一个面向 Swift 社区的 package registry。但 package registry 与我们已经使用多年的 SwiftPM以及用于发现和评估包的 Package Index究竟有什么区别Dave Verwer 从 SwiftPM 当前基于 Git 的依赖方式讲起传统依赖需要从 Git 仓库获取源码并 checkout 对应版本而 registry 可以通过 package ID 直接分发已经发布的源码 archive无需携带 Git history同时发布后的版本也具有不可变性。不过registry 的意义并不只是让 package 下载变得更轻量。更重要的是registry 还引入了一套正式的 package publishing 模型并进一步涉及开发者身份、package scope 所有权、版本发布以及软件供应链安全等问题。这篇文章既是一篇对 Package Registry 工作方式的简明介绍也为理解 Apple 与 Swift Package Index 接下来准备建设的 Swift 包生态基础设施提供了很好的背景。如何正确处理 CoreBluetooth 超时与 Task Cancellation用withCheckedThrowingContinuation将 CoreBluetooth 的 delegate API 封装成 async/await 并不困难真正麻烦的是之后的异常路径如果 callback 迟迟没有返回怎么办Task 被取消后底层蓝牙操作是否仍在继续当正常结果、超时和取消几乎同时发生时又该由谁来 resume continuationilawsonlu 围绕这些实际问题介绍了如何为 CoreBluetooth 的异步封装建立更完整的 timeout 与 cancellation 机制并明确区分「取消 Swift Task」与「取消底层操作」同时通过开源库 ArcBLEKit 展示了将传统 delegate API 封装成更健壮的 Swift Concurrency API 的思路。详解 CloudKitApple 生态的后端服务 (What Is CloudKit? Apple’s Backend Explained)CloudKit 是 Apple 生态中非常重要、却常常被低估的一块基础设施。从简单的跨设备数据同步到共享数据和公共数据库它让开发者无需自行搭建服务器就能依托 iCloud 为 App 提供一套与 Apple 平台深度集成的后端能力。尤其随着 SwiftData 和 Core Data 都能够直接接入 CloudKit许多开发者实际上已经在使用它只是不一定需要直接面对 CloudKit API。Sean Allen 从 backend 的基本需求出发系统介绍了 CloudKit 的 private、shared 和 public database以及 Container、Record、Schema 等核心概念并比较了 SwiftData、Core Data 和直接使用 CloudKit API 三种接入方式。文章并没有回避它的边界包括对 Apple 生态和 iCloud 的依赖、schema migration、跨平台能力以及复杂服务端逻辑的限制。重新认识 OCR它是空间地图而非纯文本 (OCR Doesn’t Give You Text. It Gives You a Map)Vision OCR 返回的并不是一段已经组织好的文本而是一组带有 bounding box 的 observations数组顺序不代表阅读顺序、单词边界并不存在字段之间的关系也不能简单通过前后位置判断。Wesley Matlock 在开发唱片封套扫描功能时一天内连续遇到了四个看似不同、实则来自同一错误假设的 Bug。本文通过这些真实案例展示了如何利用坐标计算阅读顺序、根据间距恢复单词边界并通过空间邻近关系关联字段。更值得借鉴的是作者的测试方式将真实图片暴露出的 bounding box 保存为 fixture用纯几何数据固定每一项布局假设同时保留真实照片作为端到端测试。正如标题所说OCR 给你的不是文本而是一张「地图」真正的文本结构需要从空间关系中重新构建。独立应用零成本推广的 6 个策略 (6 ways to promote your app without spending a penny)对于独立开发者来说写完 App 往往只是第一步如何让更多人知道它可能更加困难。由 Paul Hudson 创建的 Kickstart 在这篇文章中整理了六种几乎不需要资金投入的推广方式向 Indie App Showcase 等渠道投稿、通过 Kickstart Exchange 与其他独立开发者交叉推广、参与目标用户所在的社区、建立自己的邮件列表、Build in Public以及持续优化 App Store 产品页面。另外MacStories 的 Federico Viticci 正在为年度 iOS 27 Review 寻找值得关注的新 App 和 App 更新。如果你正在准备 iOS 27 版本可以通过 DM 或邮件viticcimacstories.net向他推荐自己的作品。 工具Amethyst Vein跨平台、SwiftData 风格 API 的开源本地持久化框架由 Mia Koring 开发的 Amethyst Vein 是一个本地优先的 Swift ORM采用 SQLite 与 SQLCipher 作为存储基础API 则明显借鉴了 SwiftData。它试图把 SwiftData 风格的 Model、Query、关系和迁移 API 带到 Apple、Linux、Android 与 Windows。项目采用显式版本化迁移、Identity Map 和字段级同步并同时支持 SwiftUI 与 SwiftCrossUI。DynamicNotch帮助开发者为 macOS 构建精致的刘海与屏幕边缘交互由 Govi 开发的 DynamicNotch 是一个专为开发者打造的 macOS Swift Package用于创建贴附于屏幕边缘的 SwiftUI 界面可呈现录音状态、媒体控制、构建进度、操作确认以及类似 Dynamic Island 的紧凑视图。它能妥善处理安全区域、多显示器和 MacBook 实体刘海支持上下左右四个方向也可以在紧凑与展开状态之间切换。DynamicNotch 的实现比较克制只负责几何、裁剪、定位与窗口呈现并未将手势、通知、状态管理等产品逻辑强加给使用者。SwiftTUI用 SwiftUI 的方式构建终端界面由 Adam Zethraeus 开发的 SwiftTUI 是一个面向 Swift 开发者的终端用户界面框架。它将 SwiftUI 的声明式编程模型带进终端开发者可以使用View、State、Observable、布局容器、焦点、手势与动画构建交互界面由框架负责布局、输入处理和局部刷新。SwiftTUI 的有趣之处不只是“用 Swift 写 TUI”。同一套视图代码还可以运行于 macOS、Linux 和 Windows 终端并进一步部署到浏览器、WASI以及原生 SwiftUI 容器官网提供的计数器就是一个真实的 SwiftTUI 应用经 WebAssembly 编译后直接运行在网页中。往期内容越来越慢的 App Review拦住了谁 - #149Apple Intelligence 已通过审核即将在中国提供服务 - #148热茶还是冰咖啡 - #147不是模型变慢了是任务变大了 - #146 支持与反馈如果本期周报对你有帮助请点赞- 让更多开发者看到评论- 分享你的看法或问题转发- 帮助同行共同成长拓展 Swift 视野 邮件订阅| weekly.fatbobman.com 获取独家技术洞察 开发者社区| Discord 实时交流开发经验 原创教程| fatbobman.com 学习 Swift/SwiftUI 最佳实践 AI 想放弃了，人没有 -- 肘子的 Swift 周报 #150
AI 想放弃了人没有最近Linus Torvalds 在调试一个 Intel Xe GPU 驱动问题时经历了一场被他自己称为“debug session from hell”的漫长排查。最终的修复简单得有些不可思议把一处round_up()改成round_down()。但为了找到这一行代码他前后添加了 24 个调试 patch启动了 18 次 kernel。其中大量繁琐工作都是在 AI 的帮助下完成的。这个故事最有意思的地方并不是“AI 帮 Linus 修复了 Linux Kernel Bug”而是 AI 在过程中数次想要放弃。它曾明确告诉 Linus这个问题“impossible and unsolvable”建议停止继续调查。Linus 没有接受这个判断。在他的坚持下AI 虽然数次认为问题已经无法解决却仍然忠实地执行新的任务最终和他一起找到了那个只需要修改一行代码的原因。这其实很好地展现了现阶段人与 AI 之间一种颇为微妙的关系。随着 Agent 能力不断增强我们已经可以把越来越完整的工作交给 AI阅读代码、提出假设、编写调试工具、执行验证甚至根据新的结果不断调整下一步行动。过去需要开发者亲自完成的大量重复劳动正在被压缩人也因此逐渐从具体的执行过程中抽离出来。但这并不意味着人的作用正在以同样的速度缩小。恰恰相反当 AI 开始参与分析、提出建议甚至给出“这个问题无法解决”这样的判断时人真正需要承担的职责反而变得更加清晰决定什么值得做判断什么时候应该相信 AI又在什么时候拒绝它的结论。尽管并非所有人类的坚持都会获得类似本次的圆满结果但有时候再坚持一下的理由至少不应该被 AI 的一句“不可能”轻易抹去。本期内容 | 前一期内容 | 全部周报列表原创从使用 AI 到委托 AI我的一些思考当一项工作已经有明确目标、边界和验收要求时怎样把它真正交给 AIAgent 能完成的工作越复杂这个问题就越突出。模型的输出存在波动上下文变长后目标和规则可能逐渐淡化拆进多个上下文又会带来信息损失和交接偏移。让另一个模型复核也不意味着结果一定会自然收敛。这些问题最终指向同一个词可委托性。本文是我对 AI 可委托性的一些思考执行范围是否稳定结果能否被信任投入是否可以预期以及什么时候需要人介入。相比追求某一次执行的最好结果我更关心如何通过明确边界、验收标准、外置的权威记录以及合理的人机分工让 Agent 在更长、更复杂的任务中保持稳定并让失败能够被发现和纠正。文章最后也结合我目前使用的 Task-Driven 工作流展示这些原则如何落实到实际的 AI 开发过程中。近期推荐认识 Swift 包注册表 (What is a package registry?)Swift Package Index 加入 Apple 后双方宣布将共同建设一个面向 Swift 社区的 package registry。但 package registry 与我们已经使用多年的 SwiftPM以及用于发现和评估包的 Package Index究竟有什么区别Dave Verwer 从 SwiftPM 当前基于 Git 的依赖方式讲起传统依赖需要从 Git 仓库获取源码并 checkout 对应版本而 registry 可以通过 package ID 直接分发已经发布的源码 archive无需携带 Git history同时发布后的版本也具有不可变性。不过registry 的意义并不只是让 package 下载变得更轻量。更重要的是registry 还引入了一套正式的 package publishing 模型并进一步涉及开发者身份、package scope 所有权、版本发布以及软件供应链安全等问题。这篇文章既是一篇对 Package Registry 工作方式的简明介绍也为理解 Apple 与 Swift Package Index 接下来准备建设的 Swift 包生态基础设施提供了很好的背景。如何正确处理 CoreBluetooth 超时与 Task Cancellation用withCheckedThrowingContinuation将 CoreBluetooth 的 delegate API 封装成 async/await 并不困难真正麻烦的是之后的异常路径如果 callback 迟迟没有返回怎么办Task 被取消后底层蓝牙操作是否仍在继续当正常结果、超时和取消几乎同时发生时又该由谁来 resume continuationilawsonlu 围绕这些实际问题介绍了如何为 CoreBluetooth 的异步封装建立更完整的 timeout 与 cancellation 机制并明确区分「取消 Swift Task」与「取消底层操作」同时通过开源库 ArcBLEKit 展示了将传统 delegate API 封装成更健壮的 Swift Concurrency API 的思路。详解 CloudKitApple 生态的后端服务 (What Is CloudKit? Apple’s Backend Explained)CloudKit 是 Apple 生态中非常重要、却常常被低估的一块基础设施。从简单的跨设备数据同步到共享数据和公共数据库它让开发者无需自行搭建服务器就能依托 iCloud 为 App 提供一套与 Apple 平台深度集成的后端能力。尤其随着 SwiftData 和 Core Data 都能够直接接入 CloudKit许多开发者实际上已经在使用它只是不一定需要直接面对 CloudKit API。Sean Allen 从 backend 的基本需求出发系统介绍了 CloudKit 的 private、shared 和 public database以及 Container、Record、Schema 等核心概念并比较了 SwiftData、Core Data 和直接使用 CloudKit API 三种接入方式。文章并没有回避它的边界包括对 Apple 生态和 iCloud 的依赖、schema migration、跨平台能力以及复杂服务端逻辑的限制。重新认识 OCR它是空间地图而非纯文本 (OCR Doesn’t Give You Text. It Gives You a Map)Vision OCR 返回的并不是一段已经组织好的文本而是一组带有 bounding box 的 observations数组顺序不代表阅读顺序、单词边界并不存在字段之间的关系也不能简单通过前后位置判断。Wesley Matlock 在开发唱片封套扫描功能时一天内连续遇到了四个看似不同、实则来自同一错误假设的 Bug。本文通过这些真实案例展示了如何利用坐标计算阅读顺序、根据间距恢复单词边界并通过空间邻近关系关联字段。更值得借鉴的是作者的测试方式将真实图片暴露出的 bounding box 保存为 fixture用纯几何数据固定每一项布局假设同时保留真实照片作为端到端测试。正如标题所说OCR 给你的不是文本而是一张「地图」真正的文本结构需要从空间关系中重新构建。独立应用零成本推广的 6 个策略 (6 ways to promote your app without spending a penny)对于独立开发者来说写完 App 往往只是第一步如何让更多人知道它可能更加困难。由 Paul Hudson 创建的 Kickstart 在这篇文章中整理了六种几乎不需要资金投入的推广方式向 Indie App Showcase 等渠道投稿、通过 Kickstart Exchange 与其他独立开发者交叉推广、参与目标用户所在的社区、建立自己的邮件列表、Build in Public以及持续优化 App Store 产品页面。另外MacStories 的 Federico Viticci 正在为年度 iOS 27 Review 寻找值得关注的新 App 和 App 更新。如果你正在准备 iOS 27 版本可以通过 DM 或邮件viticcimacstories.net向他推荐自己的作品。 工具Amethyst Vein跨平台、SwiftData 风格 API 的开源本地持久化框架由 Mia Koring 开发的 Amethyst Vein 是一个本地优先的 Swift ORM采用 SQLite 与 SQLCipher 作为存储基础API 则明显借鉴了 SwiftData。它试图把 SwiftData 风格的 Model、Query、关系和迁移 API 带到 Apple、Linux、Android 与 Windows。项目采用显式版本化迁移、Identity Map 和字段级同步并同时支持 SwiftUI 与 SwiftCrossUI。DynamicNotch帮助开发者为 macOS 构建精致的刘海与屏幕边缘交互由 Govi 开发的 DynamicNotch 是一个专为开发者打造的 macOS Swift Package用于创建贴附于屏幕边缘的 SwiftUI 界面可呈现录音状态、媒体控制、构建进度、操作确认以及类似 Dynamic Island 的紧凑视图。它能妥善处理安全区域、多显示器和 MacBook 实体刘海支持上下左右四个方向也可以在紧凑与展开状态之间切换。DynamicNotch 的实现比较克制只负责几何、裁剪、定位与窗口呈现并未将手势、通知、状态管理等产品逻辑强加给使用者。SwiftTUI用 SwiftUI 的方式构建终端界面由 Adam Zethraeus 开发的 SwiftTUI 是一个面向 Swift 开发者的终端用户界面框架。它将 SwiftUI 的声明式编程模型带进终端开发者可以使用View、State、Observable、布局容器、焦点、手势与动画构建交互界面由框架负责布局、输入处理和局部刷新。SwiftTUI 的有趣之处不只是“用 Swift 写 TUI”。同一套视图代码还可以运行于 macOS、Linux 和 Windows 终端并进一步部署到浏览器、WASI以及原生 SwiftUI 容器官网提供的计数器就是一个真实的 SwiftTUI 应用经 WebAssembly 编译后直接运行在网页中。往期内容越来越慢的 App Review拦住了谁 - #149Apple Intelligence 已通过审核即将在中国提供服务 - #148热茶还是冰咖啡 - #147不是模型变慢了是任务变大了 - #146 支持与反馈如果本期周报对你有帮助请点赞- 让更多开发者看到评论- 分享你的看法或问题转发- 帮助同行共同成长拓展 Swift 视野 邮件订阅| weekly.fatbobman.com 获取独家技术洞察 开发者社区| Discord 实时交流开发经验 原创教程| fatbobman.com 学习 Swift/SwiftUI 最佳实践