<feed xmlns="http://www.w3.org/2005/Atom"> <id>https://onevcat.com</id><title>OneV's Den</title><subtitle>上善若水，人淡如菊。这里是王巍 (onevcat) 的博客，用来记录一些技术和想法，主要专注于 Swift 和 iOS 开发。</subtitle> <updated>2026-01-04T17:16:10+09:00</updated> <author> <name>王巍 (onevcat)</name> <uri>https://onevcat.com</uri> </author><link href="/feed.xml" rel="self" type="application/atom+xml" /><link href="https://onevcat.com" rel="alternate" type="text/html" /> <generator uri="https://jekyllrb.com/" version="4.4.1">Jekyll</generator> <rights> © 2026 王巍 (onevcat) </rights> <icon>/assets/img/favicons/favicon.ico</icon> <logo>/assets/img/favicons/favicon-96x96.png</logo> <entry><title>十倍性能优化！一次终端语法高亮库的 AI 折腾与收获</title><link href="https://onevcat.com/2026/01/chroma/" rel="alternate" type="text/html" title="十倍性能优化！一次终端语法高亮库的 AI 折腾与收获" /><published>2026-01-04T16:39:00+09:00</published> <updated>2026-01-04T17:16:10+09:00</updated> <id>https://onevcat.com/2026/01/chroma/</id> <content src="https://onevcat.com/2026/01/chroma/" /> <author> <name>王巍 (onevcat)</name> </author> <category term="能工巧匠集" /> <summary> 我最近写了一个小框架 Chroma，用 Swift 在终端里做代码高亮；顺手还以它为基底做了一个（实验性的）cat 替代品 ca，能以带高亮的方式在终端里显示代码文本内容 (几乎和 bat 一样，只是又一个“I can, why not”的项目)。这篇文章想做三件事：先简单宣传一下（真的很短），然后重点聊聊这次实践中的主要收获：在 AI 驱动的迭代方式下，把性能优化这件事做“到底”变得前所未有地容易；最后再补一些在做 ca 期间学到的命令行设计和主题生态方面的东西。 Chroma / ca：一个很小的 promotion Chroma 的目标非常朴素：给它一段代码和一个语言标识，它就返回一段可以直接 print 的 ANSI 彩色字符串。 语法高亮这种东西其实早就被写烂了：Rust 有 syntect，Python 有 Pygments，前端世界里更是 highlight.js 一类的工具满天飞。但我在 Swift 生态里一直没找到一个足够顺手、又能对终端输出细节（diff / 行号 / 行背景 / 缩进）有足够掌控力的选择，于是干脆自己（准确地说：靠 AI）糊了一个。... </summary> </entry> <entry><title>2025 年终总结</title><link href="https://onevcat.com/2025/12/2025-final/" rel="alternate" type="text/html" title="2025 年终总结" /><published>2025-12-15T10:20:00+09:00</published> <updated>2026-01-04T17:16:10+09:00</updated> <id>https://onevcat.com/2025/12/2025-final/</id> <content src="https://onevcat.com/2025/12/2025-final/" /> <author> <name>王巍 (onevcat)</name> </author> <category term="一得之愚集" /> <summary> 提笔写下这篇总结的时候，窗外的银杏叶已经落得差不多了，天气也倏忽之间就冷了下来。东京的秋天走得安静，只留下满地金黄，但冬天却来得急躁，提醒人们时间确实在向前流动。 按照往年的惯例，我大概会用“懒癌发作”或者“没什么进取心”作为开场白：一方面习惯性自嘲，另一方面也给自己留点退路，装作好像只要态度足够散淡，变化就追不上来的样子。但回望 2025 年，我发现这些词突然变得不太合适了。并不是我变得勤奋了，而是这个世界的变化速度，已经快到了即使你选择“躺平”，也能清楚地感觉到身下的地板在带着你呼呼向前移动。 如果说前几年我们还在讨论 AI 能不能做事、会不会做事，那么到了 2025 年，这个问题几乎已经失去了继续讨论的意义。我们不再站在岸边观察潮水，而是已经身处浪潮之中。无论情愿与否，这一年，几乎没有人还能置身事外，所有人都成为了这场巨变的直接参与者。 今年的总结，我想试着从几个贯穿全年的主题出发，聊聊在这个智能骤然丰裕的时代拐点上，我的一些观察、困惑、犹豫，以及尚未成型的浅薄思考。 智能膨胀与元学习 两个娃一天天长大，也都进入了小学，姐姐更是为了准备初中考试开始了补习班生涯。她... </summary> </entry> <entry><title>Magpie 和 「AI 贼船」- 再谈 vibe coding，当代码变得廉价时...</title><link href="https://onevcat.com/2025/10/magpie-and-ai-ship/" rel="alternate" type="text/html" title="Magpie 和 「AI 贼船」- 再谈 vibe coding，当代码变得廉价时..." /><published>2025-10-14T00:10:00+09:00</published> <updated>2026-01-04T17:16:10+09:00</updated> <id>https://onevcat.com/2025/10/magpie-and-ai-ship/</id> <content src="https://onevcat.com/2025/10/magpie-and-ai-ship/" /> <author> <name>王巍 (onevcat)</name> </author> <category term="能工巧匠集" /> <summary> 最近科技界一扫前些年死气沉沉的阴霾，各种新东西乘着 AI 的东风纷至沓来。我自己分享欲也有点爆表，所以闲暇时 vibe coding 了两个小项目，想要尝试拓展一下自己表达的边界和形式。这篇文章先简单介绍一下两个项目，然后谈谈（作为一个“资深”程序员）在开发过程中的一些体会和感受。 项目简介 Magpie 首先是驱动我个人链接收藏页面的 Magpie (喜鹊，没错我就是很喜欢用鸟来给项目命名的人)，它是一个轻量级的链接收藏，后端接入 AI 模型，可以从链接 URL 中获取内容，自动提取标签以及合适的分类，甚至按需求写一些短评。你可以把它想成上个世代的各种 Read it later 服务的 AI 加强版，并且配套的管理后台、快捷指令和 Chrome 插件也都齐备了。 AI 贼船 其次是一个更简单一些的静态页面「上了AI的贼船」。我会不定期在这个页面分享我在使用 AI 工具进行日常开发，生活和娱乐等方面的心得以及实际的使用案例。在 build 时，我使用中文书写的内容会通过 LLM 自动翻译成其他支持的语言；当然，深浅颜色切换，feed 订阅这些基本要素也都完备。 ... </summary> </entry> <entry><title>一个半月高强度 Claude Code 使用后感受</title><link href="https://onevcat.com/2025/08/claude-code/" rel="alternate" type="text/html" title="一个半月高强度 Claude Code 使用后感受" /><published>2025-08-03T18:00:00+09:00</published> <updated>2026-01-04T17:16:10+09:00</updated> <id>https://onevcat.com/2025/08/claude-code/</id> <content src="https://onevcat.com/2025/08/claude-code/" /> <author> <name>王巍 (onevcat)</name> </author> <category term="一得之愚集" /> <summary> 六月中旬某个闷热的夜晚，在初浅尝试使用 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，最让我震撼的其实不是模型有多智能或者是能完成什么尖端任务，而是由它带来的产品迭... </summary> </entry> <entry><title>Foundation Models：苹果设备端模型的边界探索</title><link href="https://onevcat.com/2025/06/foundation-models/" rel="alternate" type="text/html" title="Foundation Models：苹果设备端模型的边界探索" /><published>2025-06-17T21:00:00+09:00</published> <updated>2026-01-04T17:16:10+09:00</updated> <id>https://onevcat.com/2025/06/foundation-models/</id> <content src="https://onevcat.com/2025/06/foundation-models/" /> <author> <name>王巍 (onevcat)</name> </author> <category term="能工巧匠集" /> <category term="AI" /> <summary> 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... </summary> </entry> </feed>
