人工智能曾想放弃，但人类没有——Fatbobman的Swift周刊第150期
人工智能想要放弃。人类没有。
最近，在调试Intel Xe GPU驱动的一个问题时，Linus Torvalds经历了他自己所称的“”地狱调试会话.”最终的解决办法几乎简单得离谱：改变一个round_up()转给round_down().但找到那条线路花了24次调试补丁和18次内核启动。一路上许多繁琐的工作都是靠AI完成的。
然而，故事中最有趣的部分并不是“AI帮助Linus修复了Linux内核的漏洞”。而是AI在过程中多次试图放弃。有一次，它明确告诉Linus这个问题“不可能解决”，并建议结束调查。莱纳斯拒绝了这个结论。在他的坚持下，AI尽管多次得出问题无法解决的结论，仍忠实地执行新任务，最终他们追踪到只需修改一行代码就能找到原因。
这揭示了当今人类与人工智能之间相当微妙的关系。随着智能体能力的提升，我们可以将越来越完整的工作委托给他们：阅读代码、构建假设、编写调试工具、运行验证，甚至根据新证据调整下一步。许多曾经需要开发者自行完成的重复工作被压缩，逐渐将人类从执行细节中拉开。
但这并不意味着人类的角色会以同样的速度缩小。恰恰相反。随着人工智能开始参与分析、提出建议，甚至做出诸如“这个问题无法解决”这样的判断，人类肩负的责任变得更加清晰：决定什么值得追求，知道何时信任人工智能，以及何时拒绝其结论。
并非每一次人类坚持的表现都会像这次一样圆满结束。但有时候，继续坚持一会儿的理由不应该被AI说“不可能”轻易抹去。
📢赞助商：Fatbobman's Swift Weekly
向Swift和iOS开发者推广你的产品：
- 博客：50,000+ 月访客
- 通讯：4,000+ 订阅者，53开启率
非常适合开发者工具、课程和服务。
原版
从使用人工智能到将工作委托给人工智能：一些想法
当一项任务已经有明确的目标、界限和接受标准时，我们如何真正把它交给人工智能？代理人能处理的工作越复杂，这个问题就越重要。模型输出可能有所不同;随着上下文的延长，目标和规则可能逐渐淡化;将工作分散到多个情境中会导致信息丢失和交接漂移。让另一个模型审查结果并不一定意味着一切自然会趋同。所有这些问题归根结底指向同一个概念：可委托性。
本文阐述了我对人工智能可委托性的一些看法：执行范围是否稳定，结果是否可信，所需投资是否可预测，以及何时需要人工干预。我更关注的是明确的界限、验收标准、外部化的权威记录以及合理的人机分工，如何帮助代理在更长时间和更复杂的任务中保持稳定，同时确保故障能够被检测和纠正。文章最后介绍了我目前使用的任务驱动工作流程，展示了这些原则如何应用于实际的人工智能辅助开发。
近期建议
什么是包注册表？
之后Swift Package Index加入苹果两人宣布将合作为Swift社区构建一个包注册表。那么，包注册表与我们多年来使用的SwiftPM以及帮助我们发现和评估包的包索引有何不同？戴夫·维尔起始于 SwiftPM 当前基于 Git 的依赖模型：传统依赖需要从 Git 仓库获取源代码并检查相应版本，而注册表则可以通过包 ID 直接分发已发布的源代码归档，无需携带 Git 历史，同时使已发布版本不可变。
但注册表的重要性不仅仅是让软件包下载更轻便。更重要的是，它引入了正式的包发布模型，并引发了关于开发者身份、包范围所有权、版本发布和软件供应链安全性等更广泛的问题。本文不仅简明介绍了包注册表的工作原理，还提供了理解苹果和Swift包指数准备构建的Swift包基础设施的有用背景。
正确处理 CoreBluetooth 超时和任务取消
将 CoreTBluetooth 的代理 API 以异步/等待方式包裹withCheckedThrowingContinuation并不特别难。真正的问题在于那些特殊的路径：如果回归从未到来会怎样？任务被取消后，底层的蓝牙操作还会继续运行吗？当正常结果、超时和取消几乎同时发生时，应该继续哪一个？
伊劳森探讨了这些实际问题，并解释了如何为异步Core蓝牙封装器构建更完整的超时和取消机制。文章明确区分了取消Swift任务和取消底层操作，而开源库则是ArcBLEKit演示了一种将传统代理API包裹为更强大的Swift并发API的方法。
什么是CloudKit？苹果后端解析
CloudKit 是苹果生态系统中一个重要但常被低估的基础设施。从简单的跨设备数据同步到共享数据和公共数据库，它让开发者能够为应用提供深度集成于苹果平台的后端功能，而无需自行构建和维护服务器。由于SwiftData和Core Data都能直接集成到CloudKit，许多开发者已经在使用CloudKit，而不必直接与CloudKit API本身交互。
从后端的基本需求出发，肖恩·艾伦系统性介绍了 CloudKit 的私有、共享和公共数据库，以及容器、记录和模式等核心概念，并比较三种方法：SwiftData、Core Data 以及直接使用 CloudKit API。文章并未回避CloudKit的局限性，包括其对苹果生态系统和iCloud的依赖、架构迁移、跨平台支持以及复杂服务器端逻辑的限制。
OCR不会给你文字。它给你一张地图
Vision OCR不会返回整齐有序的文本块。相反，它给出一组带有边界框的观察：数组顺序不代表阅读顺序，词边界本身不存在，字段之间的关系不能仅凭前后推断。在开发唱片套扫描功能时，韦斯利·马特洛克一天内遇到了四个看似不同的虫子，但都源于同一个错误的假设。通过这些真实案例，文章展示了如何利用坐标确定阅读顺序，通过间距重建词界，并通过空间接近度关联字段。更具启发性的是作者的测试方法：将真实图像曝光的包围框保存为夹具，利用纯几何数据锁定每个布局假设，同时保留原始照片供端到端测试。正如标题所说，OCR不会给你文字——它给你一张“地图”。文本结构必须从空间关系中重建。
6种无需花钱推广应用的方法
对于独立开发者来说，完成一款应用往往只是第一步。让更多人发现它更难。Kickstart，由保罗·哈德森本文列出了六种几乎不需投入资金的推广策略：向Indie App Showcase等渠道投稿、通过Kickstart Exchange与其他独立开发者交叉推广、参与目标用户聚集的社区、建立自己的邮件列表、公开发布，以及持续优化你的App Store产品页面。
此外，MacStories的费德里科·维蒂奇正在寻找值得关注的新应用和应用更新，以备他年度 iOS 27 评测。如果你正在准备 iOS 27 版本发布，可以通过私信或电子邮件向他推荐你的应用，地址为viticci@macstories.net.
工具
Amethyst Vein：一个开源、跨平台的本地持久化框架，支持SwiftData风格的API。
开发者米娅·科林Amethyst Vein 是一款基于 SQLite 和 SQLCipher 构建的本地优先 Swift ORM，API 明显受 SwiftData 启发。它旨在将类似 SwiftData 的 @Model、@Query、关系和迁移 API 带到 Apple 平台、Linux、Android 和 Windows 平台。该项目采用显式版本迁移、身份映射和现场级同步，同时支持 SwiftUI 和 SwiftCrossUI。
DynamicNotch：为macOS构建精致的刘海和屏幕边缘交互
开发者戈维， DynamicNotch 是 macOS 上的一个 Swift 软件包，专为开发者创建附着在屏幕边缘的 SwiftUI 接口而设计。它可以显示录制状态、媒体控制、构建进度、动作确认以及类似动态岛的紧凑视图。
它能正确处理安全区域、多显示器和MacBook上的物理刘海，支持四个屏幕边缘，并且能在紧凑和扩展状态间切换。DynamicNotch 的实现非常专注：它处理几何体、裁剪、定位和窗口展示，而不强加产品级逻辑，如手势、通知或状态管理。
SwiftTUI：以SwiftUI方式构建终端接口
开发者亚当·泽斯雷乌斯SwiftTUI 是一个面向 Swift 开发者的终端用户界面框架。它将 SwiftUI 的声明式编程模型带入终端：开发者可以通过以下方式构建交互式界面View,@State,@Observable， 布局容器、焦点、手势和动画，而框架则负责布局、输入处理和部分更新。
SwiftTUI 有趣的不仅仅是它让你“用 Swift 写 TUI”。相同的视图代码可以在macOS、Linux和Windows终端中运行，也可以部署到浏览器、WASI和原生SwiftUI容器中。计数器官方网站本身是一个真正的SwiftTUI应用程序，已编译成WebAssembly并直接在浏览器中运行。
感谢阅读Fatbobman的《Swift Weekly》！这篇帖子是公开的，欢迎大家分享。
AI 想放弃了，人没有
最近，Linus Torvalds 在调试一个 Intel Xe GPU 驱动问题时，经历了一场被他自己称为“地狱调试会话”的漫长排查。 最终的修复简单得有些不可思议：把一处 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：我的一些思考
当一项工作已经有明确目标、边界和验收要求时，怎样把它真正交给 AI？ Agent 能完成的工作越复杂，这个问题就越突出。 模型的输出存在波动； 上下文变长后，目标和规则可能逐渐淡化； 拆进多个上下文，又会带来信息损失和交接偏移。 让另一个模型复核，也不意味着结果一定会自然收敛。 这些问题最终指向同一个词：可委托性。
本文是我对 AI 可委托性的一些思考：执行范围是否稳定，结果能否被信任，投入是否可以预期，以及什么时候需要人介入。 相比追求某一次执行的最好结果，我更关心如何通过明确边界、验收标准、外置的权威记录以及合理的人机分工，让 Agent 在更长、更复杂的任务中保持稳定，并让失败能够被发现和纠正。 文章最后也结合我目前使用的 Task-Driven 工作流，展示这些原则如何落实到实际的 AI 开发过程中。
近期推荐
认识 Swift 包注册表（什么是包裹注册表？）
Swift Package Index 加入 Apple 后，双方宣布将共同建设一个面向 Swift 社区的 package registry。 但 package registry 与我们已经使用多年的 SwiftPM，以及用于发现和评估包的 Package Index，究竟有什么区别？ 戴夫·维尔 从 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 continuation？
伊劳森 围绕这些实际问题，介绍了如何为 CoreBluetooth 的异步封装建立更完整的 timeout 与 cancellation 机制，并明确区分「取消 Swift Task」与「取消底层操作」，同时通过开源库 ArcBLEKit 展示了将传统 delegate API 封装成更健壮的 Swift Concurrency API 的思路。
详解 CloudKit：Apple 生态的后端服务（什么是 CloudKit？苹果后端解析）
CloudKit 是 Apple 生态中非常重要、却常常被低估的一块基础设施。 从简单的跨设备数据同步，到共享数据和公共数据库，它让开发者无需自行搭建服务器，就能依托 iCloud 为 App 提供一套与 Apple 平台深度集成的后端能力。 尤其随着 SwiftData 和 Core Data 都能够直接接入 CloudKit，许多开发者实际上已经在使用它，只是不一定需要直接面对 CloudKit API。
肖恩·艾伦 从 backend 的基本需求出发，系统介绍了 CloudKit 的 private、shared 和 public database，以及 Container、Record、Schema 等核心概念，并比较了 SwiftData、Core Data 和直接使用 CloudKit API 三种接入方式。 文章并没有回避它的边界，包括对 Apple 生态和 iCloud 的依赖、schema migration、跨平台能力以及复杂服务端逻辑的限制。
重新认识 OCR：它是空间地图，而非纯文本 （OCR 不会给你文字。它会给你一张地图）
Vision OCR 返回的并不是一段已经组织好的文本，而是一组带有 bounding box 的 observations：数组顺序不代表阅读顺序、单词边界并不存在，字段之间的关系也不能简单通过前后位置判断。 韦斯利·马特洛克 在开发唱片封套扫描功能时，一天内连续遇到了四个看似不同、实则来自同一错误假设的 Bug。 本文通过这些真实案例展示了如何利用坐标计算阅读顺序、根据间距恢复单词边界，并通过空间邻近关系关联字段。 更值得借鉴的是作者的测试方式：将真实图片暴露出的 bounding box 保存为 fixture，用纯几何数据固定每一项布局假设，同时保留真实照片作为端到端测试。 正如标题所说，OCR 给你的不是文本，而是一张「地图」，真正的文本结构需要从空间关系中重新构建。
独立应用零成本推广的 6 个策略（6 种无需花钱推广应用的方法）
对于独立开发者来说，写完 App 往往只是第一步，如何让更多人知道它可能更加困难。 由 保罗·哈德森 创建的 Kickstart 在这篇文章中整理了六种几乎不需要资金投入的推广方式：向 Indie App Showcase 等渠道投稿、通过 Kickstart Exchange 与其他独立开发者交叉推广、参与目标用户所在的社区、建立自己的邮件列表、Build in Public，以及持续优化 App Store 产品页面。
另外，MacStories 的 费德里科·维蒂奇 正在为年度 iOS 27 Review 寻找值得关注的新 App 和 App 更新。 如果你正在准备 iOS 27 版本，可以通过 DM 或邮件 viticci@macstories.net 向他推荐自己的作品。
工具
Amethyst Vein：跨平台、SwiftData 风格 API 的开源本地持久化框架
由 米娅·科林 开发的 Amethyst Vein 是一个本地优先的 Swift ORM，采用 SQLite 与 SQLCipher 作为存储基础，API 则明显借鉴了 SwiftData。 它试图把 SwiftData 风格的 @Model、@Query、关系和迁移 API 带到 Apple、Linux、Android 与 Windows。 项目采用显式版本化迁移、Identity Map 和字段级同步，并同时支持 SwiftUI 与 SwiftCrossUI。
DynamicNotch：帮助开发者为 macOS 构建精致的刘海与屏幕边缘交互
由 戈维 开发的 DynamicNotch 是一个专为开发者打造的 macOS Swift Package，用于创建贴附于屏幕边缘的 SwiftUI 界面，可呈现录音状态、媒体控制、构建进度、操作确认，以及类似 Dynamic Island 的紧凑视图。
它能妥善处理安全区域、多显示器和 MacBook 实体刘海，支持上下左右四个方向，也可以在紧凑与展开状态之间切换。 DynamicNotch 的实现比较克制，只负责几何、裁剪、定位与窗口呈现，并未将手势、通知、状态管理等产品逻辑强加给使用者。
SwiftTUI：用 SwiftUI 的方式构建终端界面
由 亚当·泽斯雷乌斯 开发的 SwiftTUI 是一个面向 Swift 开发者的终端用户界面框架。 它将 SwiftUI 的声明式编程模型带进终端：开发者可以使用 View、@State、@Observable、布局容器、焦点、手势与动画构建交互界面，由框架负责布局、输入处理和局部刷新。
SwiftTUI 的有趣之处，不只是“用 Swift 写 TUI”。 同一套视图代码还可以运行于 macOS、Linux 和 Windows 终端，并进一步部署到浏览器、WASI，以及原生 SwiftUI 容器；官网提供的计数器就是一个真实的 SwiftTUI 应用，经 WebAssembly 编译后直接运行在网页中。
点赞
收藏
点踩
分享