提笔写下这篇总结的时候，窗外的银杏叶已经落得差不多了，天气也倏忽之间就冷了下来。东京的秋天走得安静，只留下满地金黄，但冬天却来得急躁，提醒人们时间确实在向前流动。 按照往年的惯例，我大概会用“懒癌发作”或者“没什么进取心”作为开场白：一方面习惯性自嘲，另一方面也给自己留点退路，装作好像只要态度足够散淡，变化就追不上来的样子。但回望 2025 年，我发现这些词突然变得不太合适了。并不是我变得勤奋了，而是这个世界的变化速度，已经快到了即使你选择“躺平”，也能清楚地感觉到身下的地板在带着你呼呼向前移动。 如果说前几年我们还在讨论 AI 能不能做事、会不会做事，那么到了 2025 年，这个问题几乎已经失去了继续讨论的意义。我们不再站在岸边观察潮水，而是已经身处浪潮之中。无论情愿与否，这一年，几乎没有人还能置身事外，所有人都成为了这场巨变的直接参与者。 今年的总结，我想试着从几个贯穿全年的主题出发，聊聊在这个智能骤然丰裕的时代拐点上，我的一些观察、困惑、犹豫，以及尚未成型的浅薄思考。 智能膨胀与元学习 两个娃一天天长大，也都进入了小学，姐姐更是为了准备初中考试开始了补习班生涯。她...

最近科技界一扫前些年死气沉沉的阴霾，各种新东西乘着 AI 的东风纷至沓来。我自己分享欲也有点爆表，所以闲暇时 vibe coding 了两个小项目，想要尝试拓展一下自己表达的边界和形式。这篇文章先简单介绍一下两个项目，然后谈谈（作为一个“资深”程序员）在开发过程中的一些体会和感受。 项目简介 Magpie 首先是驱动我个人链接收藏页面的 Magpie (喜鹊，没错我就是很喜欢用鸟来给项目命名的人)，它是一个轻量级的链接收藏，后端接入 AI 模型，可以从链接 URL 中获取内容，自动提取标签以及合适的分类，甚至按需求写一些短评。你可以把它想成上个世代的各种 Read it later 服务的 AI 加强版，并且配套的管理后台、快捷指令和 Chrome 插件也都齐备了。 AI 贼船 其次是一个更简单一些的静态页面「上了AI的贼船」。我会不定期在这个页面分享我在使用 AI 工具进行日常开发，生活和娱乐等方面的心得以及实际的使用案例。在 build 时，我使用中文书写的内容会通过 LLM 自动翻译成其他支持的语言；当然，深浅颜色切换，feed 订阅这些基本要素也都完备。 ...

六月中旬某个闷热的夜晚，在初浅尝试使用 API Key 帮我迅速完成了一个任务后，我毫不犹豫地点下了 Claude Max 的订阅按钮。作为一个“买断制”时代的遗老，每月一两百美金的订阅对当时的我来说还是太超前了。但是在一个半月之后回头望去，看着那些按照 API 计价的被我烧掉的价值 3000 多美金的 token，我似乎捡到了一个超大便宜？不过最近 Anthropic 宣布了新的 weekly 限制，想来大概针对的就是我这种“重度”用户吧。所以近几天来我也在研究有没有其他替代方案，可以让我从这种限制中解脱出来。不过尝试了一圈下来（包括 CC 接其他 API，也包括像 Codex/Gemini/Qwen/Crush/Amp/AugmentCode 等等），似乎一时半会儿在这个领域 Claude Code (后文用 CC 指代) 还是没有竞争对手。既然还得续费，那不如阶段性地做一个总结，来记录下这一个半月使用 CC 的一些感受吧。 Vibe Coding 的迭代速度 说到 vibe coding，最让我震撼的其实不是模型有多智能或者是能完成什么尖端任务，而是由它带来的产品迭...

WWDC 2025 上，苹果公布了设备端的 Foundation Models 框架，可以让开发者们使用离线模型完成一些基本的 AI 任务。虽然各个 session 已经详细介绍了基本用法，但作为开发者，我们更关心的往往是：这个框架的边界在哪里？什么情况下会出现问题？实际性能如何？ 经过近一周的测试和探索，我有了一些有趣的发现。这些发现可能对你在实际项目中使用 Foundation Models 有所帮助。 重要提醒：本文所有结论基于 macOS/iOS/Xcode 26 Beta 1，实际发布版本可能会有变化。苹果在 lab 中也明确表示，模型会随着 iOS 版本更新而持续改进。 结论先行 Foundation Models 已经可以用于生产环境了吗？ 我的答案是比较乐观：虽然还是 beta 1，但框架的稳定性出人意料地好。Apple 一改往年 beta 约等于 alpha 的特性，这次端出了大体能用的东西，让人喜出望外。不过，你还是需要了解它的边界和限制。 核心发现汇总： 内存消耗：总运行时内存约 1.0-1.5GB（模型权重 750MB + KV c...

作为示例，本站也开始提供 llms.txt 和 llms-full.txt 的支持，可以参看下面的链接获取相关文件。 llms.txt llms-full.txt 什么是 llms.txt 大型语言模型（LLMs）是截止至训练日期时的人类知识的总集。而如果想要精确地解决更加实时的问题（比如在进行代码生成、研究辅助等任务中），我们可以通过搜索最新知识，依赖网络信息，来极大提升模型的准确性。然而，标准的 HTML 内容通常包含导航元素、JavaScript、CSS 和其他对于 LLMs 而言非必要的信息。这些冗余信息会在对话中占据 LLMs 有限的上下文窗口，也会干扰和降低处理效率。此外，LLMs 直接抓取和解析完整的 HTML 页面效率也很低下。为了应对这些挑战，llms.txt 应运而生，它是一个正在讨论的标准（参见 llms-txt.org），旨在为 LLMs 提供一个简洁、专业的网站内容概述，以单一且易于访问的 Markdown 文件格式呈现。llms.txt 就像一个网站的“指南”，引导 AI 系统找到站点上的关键信息，并以易于阅读和分析的结构化格式...

MCP (Model Context Protocol，模型上下文协议) 是由 Anthropic 在 2024 年底推出的一种开放协议，它通过提供一种标准化的接口，旨在通过标准化的接口实现大语言模型 (LLM) 与外部数据源及工具的无缝集成。 最初推出时，仅有 Claude 的桌面应用支持，市场反响平平，且不乏质疑之声。但近期，随着诸多 AI 编辑器 (如 Cursor、Windsurf，甚至 Cline 等插件) 纷纷加入对 MCP 的支持，其热度逐渐攀升，已然展现出成为事实标准的潜力。本文将帮助你快速了解 MCP 是什么、它的功能，以及笔者对未来的预测与展望。 三分钟看懂 MCP LLM 的模型参数蕴含丰富的通用知识，但通常无法掌握以下两类信息： LLM 无法访问你的专属内容，例如文件系统中的文件、数据库里的订单，或私有 wiki 和笔记中的文本。 若无法联网，LLM 也无法获取实时信息，例如当前股价、最新财报、明日天气预报或前沿科技新闻。 此外，LLM 的核心功能是生成 token 和提供答案，因此它无法直接执行一些精细且需操作的具体任务，这也不是当...

DeepSeek 给国内带来的 AI 普及和升级还在持续，虽然对于 AI 从业者和一些一直关注前沿的科技工作者来说，不论是传统 LLM 还是推理模型都不是什么太新鲜的概念了，但是对于行业外的长辈和小辈，或者是专注点刚被吸引到 AI 的业内人士来说，DeepSeek，特别是 DeepSeek-R1 的出现和爆火，可能是他们第一次真正在生活和工作里认真地接触和使用 AI。 可最近在和很多朋友交流的过程中，我也发现了大家 (其实有时候也包括我自己) 对推理式模型存在着一些常见的误解。本来其实这些疑问也可以通过询问 AI 得到解答，但是我还是把它们整理汇总一下放在这里，一方面为新接触 AI 的小伙伴们提供参考，另一方面也算是为给这个世界提供一些语料。 对比推理模型和通用模型 最常见的一个现象，就是大家都倾向于无脑点上“深度思考 (R1)”。其实这个行为有待商榷。 推理式模型一定比通用模型好吗？ 不一定。它们有各自擅长的方向，无脑使用推理模型并不可取。 比如 OpenAI o1 和 DeepSeek-R1 这样的推理模型，在数学、逻辑、代码等可以明确定义正确与否的领域，表现远超...

DeepSeek R1 的横空出世，如同在人工智能竞赛场中引爆了一颗中子弹，其冲击波正重塑着全球 AI 产业的权力版图。近期全球科技界围绕这一事件的讨论持续升温：从冯骥在社交媒体上将 R1 定义为 “国运级别的科技成果” 的激情宣言，到 OpenAI 与微软联合指控数据违规的博弈；从 nature 盛赞其“重新定义AI普惠化可能”的技术突破，到 Anthropic CEO 亲自撰文贬损其技术价值并鼓吹硬件禁运。这场多维度的攻防战，早已超越了单纯的技术讨论，而演变为一场围绕科技话语权的战略博弈。 在这场 AI “登月竞赛”中，DeepSeek 通过开源策略完成了一次漂亮的战略突围。当 R1 不仅开源还开放了包含思考链的模型蒸馏权限时，实质上是将 AI 时代的“技术火种”播撒给了整个生态。这种“普罗米修斯式”的技术民主化，正在引发链式反应：昔日垄断巨头从容尽失地被迫从技术神殿走下，转而诉诸地缘政治与贸易管制等非技术手段。这种战略转向本身，恰是中国 AI 产业突破技术封锁的生动注脚。历史总是惊人地循环往复：六十年前，美苏太空竞赛最终以阿波罗计划改写人类文明史收场，甚至开启了苏联解体的...

去年因懒癌发作，没能写年终总结。事后回想，错失了一次宝贵的记录机会，实在懊悔。于是今年决定提早起笔，希望能趁着头脑中的理性还没被假期的欢愉冲散之前，能把一些有印象有意义的内容刻印下来，也方便今后某天心血来潮时能够回顾。 随意聊几个今年生活里遇到的话题吧，包含的内容可能比较杂乱，想法也比较主观，但是都算是当下这个时间点从自己角度展开的一些观察和想法。当然，最后再照惯例列一列书评游戏番剧推荐啥的，以供参考… 总结 关于职业和未来发展 在职场摸爬滚打也已经十多个年头了。我自己一向自认是没什么进取心，得过且过的类型。正好这几年也遇上疫情，长期在家工作，不幸养成了只要能划水就坚决不努力的糟糕特质，所以不管在职级上还是实际的成果上，其实这两年都没取得什么太大进步。很多时候也就只能用“我取得了绝佳的 work life balance”来自我安慰。 要说感悟的话，相比于以前，自己做事的风格显然改变了许多：以前更多的是追求快速，而现在更喜欢追求全盘考虑和稳重。我曾自己调侃过，十年前一晚上能解三个 issue，而现在三晚上能搞定一个 issue 就不错了。一方面可能是随着年纪增长，普...

在程序的开发和运行过程中，人往往是最不可靠的环节：一个不小心，逻辑错误（也就是 bug！）可能会悄然保留下来并进入最终的产品。与此相对，编译器要可靠得多。如果程序中存在错误，编译器通常会直接阻止生成产品。Swift 拥有非常强大的类型系统，通过它，我们可以尝试将一些运行时的逻辑“封装”到类型系统中，从而在编译期提前发现潜在的问题和错误。这种依靠类型系统来“保存”逻辑的设计方式可以称为类型状态。 一个简单例子：端到端加密 定义和使用 这个例子源自实际工作的需求。假设我们需要设计一个客户端之间的消息系统，并支持端到端加密：也就是说，这些消息可能包含用户的隐私敏感内容。在用户设备上，这些消息可以以明文形式显示，但一旦需要离开用户设备、发送到服务端（并进一步传递到另一个目标客户端），则必须加密。如果错误地将未加密的信息发送出去，可能会带来安全隐患，甚至损害用户的信任。 一个“简洁”的设计思路是设计一个带有状态的 Message，它包含文本并用一个状态来表示是否已加密： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 struct Message { e...

在 Rust 中，绝对安全和高效的内存使用得益于其独特的所有权（ownership）设计。七年前，Swift 团队发布了《所有权宣言》，以前瞻性的方式介绍了 Swift 中关于值的内存管理变化的一系列愿景。Swift 5.9 中（以和宣言里略微不同的语法）实现了这一愿景，引入了不可复制类型的标记 ~Copyable（non-copyable），以与 Rust 截然不同的（打补丁的）方式实现了更精确的所有权控制。在今年的 Swift 6 中，之前类型扩展（extension）和泛型（generic）不支持 ~Copyable 的不足也得到了解决，~Copyable 的可用性得到了提升。回顾 ~Copyable 及其设计，它为 Swift 引入了一种全新的设计思路：以往的协议是“为类型增加功能”，而 ~Copyable 则是“为类型解除限制”。本文尝试解释 ~Copyable 的设计和工作方式，以帮助读者更好地理解并利用这个特性。 ~Copyable 的工作方式 首先需要强调的是，即使目前完全不了解 Copyable 和 ~Copyable，以及相关的 consuming 和 b...

最近对手上的两三个项目进行了 Swift 6 的迁移，整体过程并不算顺利，颇有一种梦回 Swift 3 的感觉。不过，最终还是有所收获和心得。趁着记忆还新鲜，我想稍微总结一下。此外，针对目前社区里的一些声音，以及自己这些年的感受，我会在文章后半部分对 Swift 生态进行一些不太重要的小唠叨。 Swift 6 迁移 Swift 6 的最大“卖点”当然是并发编程和编译时就能保证的完全线程安全，这也是在进行 Swift 6 迁移时开发者工作量最大的来源。通过引入一系列语言工具 (主要是 actor 隔离和 Sendable 标注)，Swift 6 在开启完全的严格并发检查 (也就是-strict-concurrency=complete) 时，理想状态下可以完全确保在编译阶段就将数据竞争 (data race) 和线程问题排除掉。 关于 Swift 并发编程，我之前写过一些关于并发初步以及结构化并发的文章。对于 actor、Sendable 的概念及其如何确保数据竞争不再发生，我在《Swift 异步和并发》中也有所介绍。近几年的 WWDC 上，Apple 通过若干 sessio...

如果你还在用 NSLog 或者 print 打 log，那也许这篇文章正适合你，可以帮你转型到新的 log 方式。如果你已经在使用 OSLog 的相关功能，那也许本文可以帮助你加深理解，以及找到一些“进阶”用法。 选择：SwiftLog 和 OSLog 的区别 两者都是 Swift 中与 log 有关的框架。在进行选择时，我们的首要任务就是理清它们的区别。“SwiftLog 和 OSLog 我应该选哪个”，也是我在参加一个聚会时经常听到的问题。 SwiftLog 是前端 SwiftLog 首次发布于 2019 年，是一个 Swift server 主导的项目。它的目的是提供一个统一的日志记录接口，让包括服务器 app、命令行工具以及 iOS 和 macOS app 等各种使用 Swift 语言的场合下 (但主要是 server！)，能使用同样的方法记录日志。SwiftLog 本身是一个 log 前端框架，这意味着它需要搭配后端使用：例如将日志输出到控制台、文件、数据库或远程日志收集服务。SwiftLog 注重模块化，允许开发者通过更换后端来灵活调整日志记录的行为。 OS...

SwiftUI 遵循 Single Source of Truth 的原则，只有修改 View 所订阅的状态，才能改变 view tree 并触发对 body 的重新求值，进而刷新 UI。最初发布时，SwiftUI 提供了 @State、@ObservedObject 和 @EnvironmentObject 等属性包装器进行状态管理。在 iOS 14 中，Apple 添加了 @StateObject，它补全了 View 中持有引用类型实例的情况，使得 SwiftUI 的状态管理更加完善。 在订阅引用类型时，ObservableObject 扮演着 Model 类型的角色，但它存在一个严重的问题，即无法提供属性粒度的订阅。在 SwiftUI 的 View 中，对 ObservableObject 的订阅是基于整个实例的。只要 ObservableObject 上的任何一个 @Published 属性发生改变，都会触发整个实例的 objectWillChange 发布者发出变化，进而导致所有订阅了这个对象的 View 进行重新求值。在复杂的 SwiftUI 应用中，这可能会导致严...

最近接手了一些陈旧项目的维护工作，需要把一部分质量很烂的代码进行重构甚至重写。在这个过程期间，我也有机会对一些开发中比较重要的而且通用的知识进行了一点重新的思考和整理，在这里想把它们用个两三篇文章，以杂谈的方式记录一下。这些内容在我刚入门程序开发的时候困扰过我一段时间，所以虽然可能对于已经有多年经验的大佬们用处不大，但是希望新入行的同学们能通过这些话题得到一些启发，如果能减少走弯路的时间，那就更好了。 今天的第一个话题是有关测试的。在以前，我也写过一些关于测试的文章，不过更多的还是对某个特定框架的使用。我自己本身也在很长一段时间内保持了给包括框架和 app 写测试的习惯，并来回倒腾过不少不同风格的测试。在这篇短文里，我想对一些基本的问题和想法的变化进行解释。 为什么要写测试？你会给项目和代码写测试吗？ 这是一个每次我去参加各种技术分享会，在结束后的自由交流环节经常会被问到的问题。 我很理解由于工期紧张、需求变动频繁等原因，导致的对测试有意无意的忽视。但在这里，我还是想给出一个关于写测试的理由的答案。如果整篇文章只有一句话值得被记住，那就是： 合理的测试保证了开发者的生活...

其实随着年龄增长，总感觉最近每年都很平淡，也几乎没有什么肉眼可见的进步。再加上疫情到了第三年，自己又长期在宅工作，无形中少了许多和这个世界接触的机会，更让自己的思想越来越僵化死板。不知道是不是因为长年在日本这种国度的关系，从感觉上来说似乎这个世界固化住了。一种即视感萦绕在周围，自己却没有什么新思路，也找不到突破的方式。如何才能在这种情况下继续前进，想来应该会成为今后重要的课题。 这篇年终总结一下笔，居然发现自己整一年都脑袋空空，实在是很不应该。既然没有什么特别想要写的，那就还是先按照每个月挑选一张照片配上说明，来简单回顾一下这一整年吧。一是抒发一下心绪，二来也算是一种见证。最后阶段会依照惯例补充一些今年的书籍、动漫和游戏。 如果硬要说自己对比去年有什么不同的话，大概两鬓新增的白发在寒风中所诉说的故事就是一切了。 图说 一月 姐妹两人操作香菱，帮助爸爸在璃月大地上做任务打工升级。 电子游戏早已是成熟的第九艺术，顶级的游戏必然有着顶级的图像、音乐以及故事。游戏早已是我人生中无法抹掉的印记。相比于用一些冰冷的法律法规，设置重重阻碍来限制她们的游戏时间，还不如多多引导，主...

Swift 5.7 中引入了正则表达式的语法支持，整理一下相关的一些话题、方法和示例，以备今后自己能够速查。 总览 Swift 正则由标准库中的 Regex 类型驱动，需要 iOS 16.0 或 macOS 13.0，早期的 deploy 版本无法使用。 构建一个正则表达式的方式，分为传统的正则字面量构建，以及通过 Regex Builder DSL 的更加易读的方式。后者可以内嵌使用前者，以及其他一些已有的 parser，在可读性和功能上要强力很多。实践中，推荐结合使用字面量和 Builder API 在简洁和易读之间获取平衡。 常见字面量 和其他各语言正则表达式的字面量没有显著不同。 直接将字面量包裹在 /.../ 中使用，Swift 将把类似的声明转换为 Regex 类型的实例： 1 let bitcoinAddress_v1 = /([13][a-km-zA-HJ-NP-Z0-9]{26,33})/ 一些常用的字面量表达以及示例。更多非常用的例子，可以参考这里的 Cheat Sheet。 字符集 表达式 ...

TL;DR 当前，在 Xcode 中使用 Swift Package Manager 的包时，SPM 在编译 package 时将参照 Build Configuration 的名字，自动选择使用 debug 还是 release 来编译，这决定了像是 DEBUG 这样的编译 flag 以及最终的二进制产品的架构。在 Xcode 中使用默认的 “Debug” 和 “Release” 之外的自定义的 Build Configuration 时，这个自动选择可能会造成问题。 现在 (2022 年 10 月) 还并没有特别好的方式将 Xcode 中 Build Configuration 映射到 SPM 的编译环境中去。希望未来版本的 Xcode 和 SPM 能有所改善。 关于文中的一些例子，可以在这里找到源码。 Xcode 和 SPM 中的编译条件 默认的 DEBUG 编译条件 在 Xcode 中，创建项目时我们会自动得到两个 Build Configuration：Debug 和 Release。 在 SWIFT_ACTIVE_COMPILATION_CONDIT...

这是一系列关于 TCA 文章的最后一篇。在系列中前面的几篇里，我们简述了 TCA 的最小 Feature 核心思想，并研究了绑定和环境值的处理，以及 Effect 角色和 Feature 组合的方式等话题。作为贯穿整个系列的示例 app，现在应该已经拥有一个可用的猜数字游戏了。这篇文章会综合运用之前的内容，来看看和 UI 以及日常操作更贴近的一些话题，比如如何用 TCA 的方式展示 List 并让结果可以被删除，如何处理导航以及 alert 弹窗等。 如果你想要跟做，可以直接使用上一篇文章完成练习后最后的状态，或者从这里获取到起始代码。 展示结果 List 在前一篇文章最后的练习中，我们使用了 var results: [GameResult] 来存放结果并显示已完成的状态数字。现在我们的 app 还只有一个单一页面，我们打算为 app 添加一个展示所有已猜测结果，并且可以对结果进行删除的新页面。 使用 IdentifiedArray 进行改造 在实际开始之前，来对 results 数组进行一些改造：使用 TCA 中定义的 IdentifiedArray 来代替...