切勿将辅助驾驶宣传成智能驾驶 -- 肘子的 Swift 周报 #78

不久前，某个造成三人死亡的交通事故因为涉及某新锐电动汽车品牌再度引发了人们对“智能驾驶”功能的质疑。在目前披露的有限资料中，至少可以确认的是，“智能驾驶”系统未能在相当长的一段行驶距离中判断出当前的路段正在施工（沿途有施工警示标志），只在撞击前2-3秒前给予了警示。这意味着，在系统报警后，驾驶者只有极短的反应时间。

从当前的法规角度来说，无论是否启用“智能驾驶”功能，对于事故所造成的后果在没有其他汽车机械结构问题的情况下，仍主要由驾驶人本人来承担。但随着越来越多事故与“智能驾驶”相关联，我们不得不质疑：这难道真的和这些汽车厂商对于“智能驾驶”的过分夸大宣传无关吗？

最近一两年出现了一个值得关注的现象：许多非科技行业的普通消费者了解 AI 概念和相关专业术语的渠道，很大程度上竟然来自于提供“智能驾驶”功能的汽车厂商的发布会和销售宣传。从“端到端”到 TOPS，似乎一夜之间，主要作为交通工具的车辆成为了高科技的最佳载体，“智能驾驶”功能成为了消费者购买车辆的重要参考因素。

事实上，无论是从当前的科技发展水平还是各个地区的法律准备来看，即使发展到了 L5 阶段（现阶段大多数车型仍处在 L2 至 L3 之间），所谓的“智能驾驶”仍应被定义为“辅助驾驶”。这不仅关乎系统能力的局限性，更涉及最终责任划分的法律问题。各个车厂很清楚这一点，因此你可以在它们提供的各种说明、手册、宣传资料（角落中，用小字标注）看到它们给出的警示。但在更广泛的宣传渠道上，“辅助驾驶”一词早已被“智能驾驶”所代替。

随着各种对“智驾”的持续宣传，消费者在不知不觉中就丧失了对驾驶安全的责任感，产生了“智驾”更好、更安全的错觉。即使某些“智能系统”确实有着不错的辅助功能，但它们远未达到可以完全替代人类驾驶员判断的程度，尤其是在复杂、非常规的交通环境中。

尤其值得警惕的是，许多厂商在宣传“智能驾驶”能力时，只展示高端配置下的最佳表现，却忽视了中低端车型在算力、摄像头、传感器等方面的减配情况。更严重的是，有些厂商并未针对不同配置对算法进行差异化适配，导致低配车型的“智能系统”极易出现计算失误和决策延迟的问题，这直接加剧了交通事故风险。

实际上，“智能”、“自动”本身就是极易产生误解的模糊概念。当这些模糊的营销词汇已明显误导消费者的驾驶安全认知时，必须尽快出台明确的法律规范，限制相关用语的宣传范围与频率，并对夸大宣传进行严厉处罚。只要法律明确最终责任人仍是驾驶者本人，那么所有驾驶系统无论如何宣传，都应被严格限定在“辅助驾驶”的范畴之内。同时，消费者也应明确认识到，现阶段没有车厂会为所谓“智能系统”的问题承担法律责任。更何况，普通消费者根本不具备就“智能系统”的缺陷进行有效举证的能力。

切勿将辅助驾驶宣传成智能驾驶！

原创

远离 dismiss，拥抱状态驱动

在 SwiftUI 开发中，环境值 dismiss 因其灵活、自适应的特性备受开发者青睐。它能够根据当前视图的上下文智能执行关闭操作，让许多开发者将它作为首选工具。然而，便捷的背后往往隐藏着风险。频繁使用 dismiss 可能在应用程序中埋下隐患，引发测试难题乃至难以追踪的稳定性问题。本文将分析我们为何应谨慎对待 dismiss，并介绍更加健壮可靠的状态管理方案。

近期推荐

Swift 6.1 发布

Swift 6.1 正式发布！Holly Borla 在本文中介绍了多个令人期待的新特性。本次更新在语言层面带来了更广泛的 nonisolated 支持、更智能的 withTaskGroup 类型推导，以及更便捷的 @objc @implementation，进一步强化与 Objective-C 的互操作能力。在语法便利性方面，尾随逗号现已支持用于函数参数、泛型定义、闭包捕获列表等结构，简化了代码生成与维护流程。

SwiftPM 引入 Package Traits，支持根据运行环境（如 Embedded 或 WebAssembly）配置不同的 API 和依赖，进一步增强跨平台能力。同时，SourceKit-LSP 现已默认开启后台索引，显著提升开发期间的响应速度与智能感知表现。

在测试方面，Swift Testing 推出了 Test Scoping Traits，使测试前后的上下文共享更加灵活易控；Swift-DocC 也改进了重载函数链接的歧义处理机制，提升文档的可维护性与可读性。

Swift 6.1 可通过 Xcode 16.3 获取，也可使用 swiftly 工具在 macOS 与 Linux 上独立安装。

Swift 的跨平台编译 (Cross Compiling Swift)

提升跨平台编译能力，是 Swift 向全平台生态迈进的重要一步。Khan Winter 在开发 Discord Bot 和 Bluesky Bot 的过程中，深入探索了将 Swift 应用从 macOS 编译部署至 Gentoo Linux 的两种路径：一是借助 Static Linux SDK 与 Swiftly 工具实现的本地交叉编译，二是使用 Docker 容器完成传统的跨平台构建。文章不仅展示了详细的工具链配置与部署脚本，也指出了当前 toolchain 与 SDK 配置上的不一致和易混淆问题。

Swift 中的现代 URL 构造方式 (Modern URL Construction in Swift)

在 Swift 中构造 URL 时避免处理 Optional 一直是开发者关注的问题。John Sundell 在这篇久违的回归文章中，分享了静态与动态 URL 构造的现代实践：对于静态 URL，可通过扩展 URL.init(staticString:) 简化强制解包流程，结合 Swift 5.9 引入的宏功能，还可实现编译期校验的 #staticURL(...)；对于动态 URL，则推荐使用 iOS 16 起提供的 appending(component:) 和 appending(queryItems:) 等 API，替代传统字符串拼接方式，提升代码的安全性与可读性。这些改进让我们能以更简洁、可靠的方式构造 URL，适用于网络请求与文件路径等场景。

在 SwiftUI 中应用 Inspector 组件 (Presenting an Inspector with SwiftUI)

Inspector 是 iOS 17、iPadOS 17 与 macOS 14 中引入的 SwiftUI 组件，常用于展示与选中内容相关的详细信息。它会根据平台与上下文以不同形式呈现，这是其灵活性的体现，也为开发者带来了额外的理解成本。在本文中，Antonella Giugliano 通过多个代码示例，详细演示了 Inspector 在各种使用场景下的表现，并介绍了如何通过 InspectorCommands 实现快捷键控制其显示。

将地图视图保存成图片 (Creating an Image from an MKMapView)

虽然 SwiftUI 提供了 ImageRenderer API 用于将视图转换为图片，但在某些场景下并不能满足需求。Patrick McConnell 在尝试导出 MapView 时就遇到了这个问题。本文分享了他在 macOS 项目中，通过 NSViewRepresentable 嵌入 MKMapView，并借助视图层级探索，找到一种可行方案，最终成功生成包含路径、图层与标注的完整地图图像。文章不仅解释了为何标注无法直接渲染成图像，还提供了对 NSView 与 MKMapView 的扩展代码，实现了当前地图状态的稳定导出。

支持 MCP 的七个 AI 框架 (The Top 7 MCP-Supported AI Frameworks)

Model Context Protocol（MCP）正逐步成为连接 LLM 与外部工具的行业标准，提供了一种统一、高效的上下文注入方式。在本文中，Amos Gyamfi 系统梳理了七个支持 MCP 的主流 AI 框架，包括 OpenAI Agents SDK、LangChain、Chainlit、Agno、Upsonic、Mastra 等，并通过详实的示例代码演示了如何将 MCP 工具集成进代理式（agentic）工作流，显著提升 AI 应用的扩展性与可维护性。尽管示例代码基于 Python 与 TypeScript，仍为苹果生态开发者提供了参考思路。