<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
<title>Aaron Lau（韩栖） · 开发日志与一周短评</title>
<link>https://aaronlau.me/tags/devlog/</link>
<atom:link href="https://aaronlau.me/tags/devlog/feed.xml" rel="self" type="application/rss+xml"/>
<description>Aaron Lau（韩栖） 带 #开发日志与一周短评 标签的推送。</description>
<language>zh-Hans</language>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<lastBuildDate>Fri, 16 Oct 2026 00:00:00 GMT</lastBuildDate>
<item>
<title>HomeView 就是墙上的 CarPlay —— 小组件终于有了实体</title>
<link>https://aaronlau.me/2026/10/16/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/10/16/</guid>
<pubDate>Fri, 16 Oct 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>智能家居</category><category>开发日志与一周短评</category>
<description><![CDATA[HomeView 等于把 CarPlay 搬上墙、把 Apple Watch 放大；CarPlay 正变得像 AirPlay 一样随处可得。]]></description>
<content:encoded><![CDATA[<p>#智能家居 #开发日志与一周短评</p>
<p>我给 HomeView 的定义是一个等式：「HomeView = 把 CarPlay 搬到墙上或者桌上 = 把 Apple Watch 放大放大再放大」。这种东西有家谱，「widgets 实体化的话题，可以追溯到微软的 SideShow」，苹果这次把它做成了客厅里的设备。</p>
<p>CarPlay 本身也在走出车外。9 月底有人把无线 CarPlay 做到任意安卓设备上，「很快 CarPlay 就将像 AirPlay 一样容易取得了」；我自己也在动手，「我最近也在 vibe 一个 CarPlay on Mac 的 app」。HomeView 给它添了个方向：「或许能够 vibe 一个 HomeView 的桌宠作为 PiP 的小窗」。墙上那块屏买不到，就先放在 Mac 角落。</p>]]></content:encoded>
</item>
<item>
<title>Claude 的价格阶梯整体上移 —— Haiku 还会有 5.5 吗</title>
<link>https://aaronlau.me/2026/10/10/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/10/10/</guid>
<pubDate>Sat, 10 Oct 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>AI</category><category>开发日志与一周短评</category>
<description><![CDATA[从价格阶梯看，Fable 取代了曾经 Opus 的位置，Opus 取代了 Sonnet，Sonnet 取代了 Haiku；最小的那一档反而没人提了。]]></description>
<content:encoded><![CDATA[<p>#AI #开发日志与一周短评</p>
<p>「说到这里，Haiku 还会有 5.5 吗」。问题是从价格表冒出来的：「感觉现在 Fable 取代了曾经 Opus 的地位，Opus 取代了曾经 Sonnet 的地位，Sonnet 取代了曾经 Haiku 的地位」。整条梯子上移一格，我的日常组合是两个中间档，「Sonnet 5.5 + Opus 5.5 太神了」，最下面那格反而空了。</p>
<p>梯子挪了，毛病没全消失。AI 犯明显的错时我想，「不过考虑到现实生活中也会遇到这样的同事，所以说就还好」。上个月我也说过，算上偶尔犯错，「AI 似乎比大部分真人都要靠谱」。梯子怎么排都行，能稳定干活的那一档才是我天天用的。</p>]]></content:encoded>
</item>
<item>
<title>两年前的快捷指令 —— 让 Codex 帮我接上逻辑</title>
<link>https://aaronlau.me/2026/10/06/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/10/06/</guid>
<pubDate>Tue, 06 Oct 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>开发日志与一周短评</category><category>Shortcuts</category><category>AI</category>
<description><![CDATA[2024 年写的 AirPods Max 快捷指令我都快忘了逻辑，借 Shortcuts Playground 的 skills，Codex 很快就接上了。]]></description>
<content:encoded><![CDATA[<p>#开发日志与一周短评 #Shortcuts #AI</p>
<p>快捷指令最难的不是写，是两年后再打开。「比如这个 AirPods Max 快捷指令最初是在 2024 年写的，我都快忘记逻辑了，但是 Codex 搭配上面这个 skills 很快就能接上」，skills 来自 MacStories 主编的 Shortcuts Playground。2024 年做它时，循环和随机播放我都没加，「但我不想额外增加维护的复杂性了」。</p>
<p>现在维护有了帮手，记录麦当劳热量的那个指令，「我用 Codex 更新到了 2025 年的数据」。但对把一切交给自动化的文章我仍有保留，「因为该文作者的方法论建立在快捷指令的每个自动化都能成功的基础之上」。接上逻辑是一回事，每次触发都成功是另一回事。</p>]]></content:encoded>
</item>
<item>
<title>刘海不碍眼了 —— 把它当成窗口的收纳区</title>
<link>https://aaronlau.me/2026/10/04/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/10/04/</guid>
<pubDate>Sun, 04 Oct 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>开发日志与一周短评</category><category>macOS</category><category>设计与界面</category>
<description><![CDATA[WindowShade 下一版把刘海当作隐藏窗口的收纳区，再加 Slide Over 和甩标题栏分屏，提前适应触摸屏 MacBook。]]></description>
<content:encoded><![CDATA[<p>#开发日志与一周短评 #macOS #设计与界面</p>
<p>今天的新演示视频叫「我再也不会觉得 MacBook 上的刘海碍眼了」。WindowShade 下一版的思路，是把窗口「最小化」到刘海里，「把灵动岛（刘海）作为被隐藏的窗口的收纳区」。再加上 Slide Over 和甩标题栏分屏，「我打算在 macOS 上重现 iPadOS-style 的多任务交互，就当作提前适应一下触摸屏 MacBook」。</p>
<p>这块地盘我四年前就惦记过。猜刘海 iPad Pro 时我写：「2.0 利用刘海的地盘搞一个菜单栏，甚至开放 app 在菜单栏常驻图标」。那台 iPad 没来，Mac 的刘海倒留下了，当年想让系统去用的那块黑色，现在我自己用上了。</p>]]></content:encoded>
</item>
<item>
<title>明文 Plaintext 开发日志 —— 一次 oneshot 的 H5 文字游戏</title>
<link>https://aaronlau.me/2026/10/03/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/10/03/</guid>
<pubDate>Sat, 03 Oct 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>开发日志与一周短评</category><category>AI</category><category>兴趣笔记</category>
<description><![CDATA[我用 Ultracode 一次生成了 H5 文字游戏《明文·Plaintext》，代价是又一次用完了 20x 订阅的额度。]]></description>
<content:encoded><![CDATA[<p>#开发日志与一周短评 #AI #兴趣笔记</p>
<p>国庆假期的新项目：《明文·Plaintext》，一款跑在浏览器里的文字游戏，地址是 plaintext.aaronlau.me。Claude 刚把 Ultracode 单独拿出来，我就拿它实测：「我用它 oneshot 了一款 H5 的文字游戏」。一次把要求讲清楚，让它从头交出能玩的版本，而不是一段段地喂。</p>
<p>代价也直接：「再次用完 20x 的订阅，看来以后要少用 Fable，克制住开 Ultracode 的冲动」。大招好用，但不是每个项目都配得上开一次。游戏还配了支预告片，类型我定为视觉轻小说，内容不剧透，去玩就知道。</p>]]></content:encoded>
</item>
<item>
<title>GPT-6.1 Sol 为什么这么慢 —— 以时间换空间</title>
<link>https://aaronlau.me/2026/10/02/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/10/02/</guid>
<pubDate>Fri, 02 Oct 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>AI</category><category>开发日志与一周短评</category>
<description><![CDATA[GPT-6.1 Sol 号称以 Sol 的价格提供接近 Astra 的智能，代价是慢；Sonnet 5.5 的速度是它的 8 倍。我担心这招会被其他家学去。]]></description>
<content:encoded><![CDATA[<p>#AI #开发日志与一周短评</p>
<p>「GPT-6.1 Sol 号称以 Sol 的价格提供接近 Astra 的智能，但是速度慢很多」，开 1.5 倍速，价格又回到原处。慢到「以至于 Sonnet 5.5 是 6.1 Sol 的 8 倍速度」，省下的钱换成了八倍的等待。</p>
<p>前几天我还纳闷，「话说为什么 Astra 即使用 Medium 用量消耗都很快」。旗舰烧额度，中档烧时间，横竖都要付点什么。所以我担心：「为什么 6.1 Sol 这么慢……我怕 Anthorpic 也学会 OpenAI 这招，以时间换空间」。上个月我把 subagent 比作超线程，想的是怎么拆任务；现在才发现，模型本身的速度也能拿来定价。</p>]]></content:encoded>
</item>
<item>
<title>给 Live Photo 做 4K 放大 —— 一个剪 vlog 用的 skill</title>
<link>https://aaronlau.me/2026/09/29/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/09/29/</guid>
<pubDate>Tue, 29 Sep 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>开发日志与一周短评</category><category>Photography</category><category>AI</category>
<description><![CDATA[我让 Claude 写了一个把 Live Photo 动态部分放大的 skill，用来剪 vlog；AI 能写工具，剪辑本身还不如剪映。]]></description>
<content:encoded><![CDATA[<p>#开发日志与一周短评 #Photography #AI</p>
<p>想把攒的 Live Photo 放进 4K 时间线，可动态那几秒的分辨率比静态照片低得多。于是「我让 Claude 做了一个将 Live Photo 的动态部分 upscaling 的 skill，可以用在视频剪辑」。问起来我只能说：「自制的，希望不会触发 safeguard fallback」。素材很多是两年前拍的，「懒癌如我，拖到现在才剪」。</p>
<p>也试了让 AI 直接剪片，结论很诚实：「Opus 5.5 剪的 vlog，感觉不如剪映」。节奏和取舍还得自己来。AI 负责把素材修好，剪刀留在我手里。</p>]]></content:encoded>
</item>
<item>
<title>Opus 5.5 用 medium 就够了 —— 「普惠」型模型</title>
<link>https://aaronlau.me/2026/09/27/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/09/27/</guid>
<pubDate>Sun, 27 Sep 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>开发日志与一周短评</category><category>AI</category>
<description><![CDATA[Opus 5.5 用 medium effort 就有以往 Fable 5 的水平；除了聪明，额度耐用和长任务不跑偏同样重要。]]></description>
<content:encoded><![CDATA[<p>#开发日志与一周短评 #AI</p>
<p>这几周的评价：「Opus 5.5 用 medium 的 effort 就能做到以往 Fable 5 的智能，我能夸他是「普惠」型模型吗」。连界面都替它说话，「以至于选 Fable 5.1 它会让你再考虑一下 Opus 5.5」。</p>
<p>智能只是一半，另一半是额度和稳定。同样 5x 档，「怎么感觉 Claude 的 Max 5x 比 Codex 的 Pro 5x 耐瞪多了」；而「像 DeepSeek 在 Codex 上运行的话，往往做到最后会跟一开始设想的偏差很大」。月初我还在琢磨并发和速度，现在更在意中档设置能不能稳定把活干完。这周 AI System 6 的官网，就是 Opus 5.5 帮我翻新的。</p>]]></content:encoded>
</item>
<item>
<title>WindowShade 发布 —— 把 1994 年的双击做回 Mac</title>
<link>https://aaronlau.me/2026/09/25/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/09/25/</guid>
<pubDate>Fri, 25 Sep 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>开发日志与一周短评</category><category>macOS</category>
<description><![CDATA[6 月说要复刻的 WindowShade 今天开源发布：双击标题栏收成卷帘条、窗口置顶、Dock 窗口浏览，名字来自当年，代码从头写。]]></description>
<content:encoded><![CDATA[<p>#开发日志与一周短评 #macOS</p>
<p>6 月我说「我打算弄一个在 Tahoe 和 Golden Gate 上能用的」，今天 WindowShade 开源发布了。「名字和想法来自当年，代码是从头写的」，核心动作和三十年前一样：「双击标题栏，窗口收成一条卷帘条，留在原处；再双击，原样展开，和 1994 年一样」。窗口没离开桌面，回来时不用去 Dock 里认。</p>
<p>当年没有的也补了几样，比如「把窗口置顶，边写边看参考」，还有 Dock 上的窗口浏览。它要求 macOS 14 以上的 Apple Silicon Mac，画面只在本机处理，安装包还没公证，官网都写明了。演示视频的标题我起得直白：Mac 丢了 25 年的功能，我把它做回来了。</p>]]></content:encoded>
</item>
<item>
<title>One More Tune —— 听一段旋律，猜一款苹果产品</title>
<link>https://aaronlau.me/2026/09/20/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/09/20/</guid>
<pubDate>Sun, 20 Sep 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>开发日志与一周短评</category><category>AI System 6</category><category>兴趣笔记</category>
<description><![CDATA[我做了一个听音识苹果产品的小测验 One More Tune，最麻烦的不是出题，而是找到合法又不泄题的音源。]]></description>
<content:encoded><![CDATA[<p>#开发日志与一周短评 #AISystem6 #兴趣笔记</p>
<p>「受到这个小游戏的启发，我打算做一个听音识苹果产品的 quiz」：听一段发布会或广告里的配乐，猜是哪款产品。出题最简单，难在音源。「没有合法的铃声来源，像 YouTube 不能隐藏播放器，那不是泄题了吗」，想让 AI 帮忙抓音频，「主要是 Codex 和 Claude Code 都不让我弄，说有版权问题」。</p>
<p>最后两条路并存：能直接播的「一般是 iTunes Store 的试听链接」，其余只能嵌 YouTube，所以手机上有的题没声音，这是上线后才反应过来的。说是「检验果粉浓度」，出题人的记忆也在被检验：有首曲子我确定在 Heard in Apple Ads 里听过，搜出来却不是。</p>]]></content:encoded>
</item>
<item>
<title>iPhone 18 Pro 配色 —— 没有段落感的背板</title>
<link>https://aaronlau.me/2026/09/18/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/09/18/</guid>
<pubDate>Fri, 18 Sep 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>iPhone</category><category>设计与界面</category><category>开发日志与一周短评</category>
<description><![CDATA[今年 iPhone 18 Pro 四个颜色都养眼，背板摸起来也没有段落感；个性化我更想交给配件，于是做了个 DIY iPhone 的小工具。]]></description>
<content:encoded><![CDATA[<p>#iPhone #设计与界面 #开发日志与一周短评</p>
<p>「今年难得四个颜色都养眼」。以前的问题是两头不靠：「过往的 iPhone 配色很容易严肃，不显得活泼，或者很容易活泼，不显得堂正」，这一代算是兼顾了。渲染图看不出质感，我担心背板「不知道摸起来会不会有段落感」，今天拿到真机，「竟然是没有段落感的」。</p>
<p>配色再好，我也不希望 Apple 往机身上加更多颜色：「其实我个人想法是重现 iPhone 12 的那个 Studio，通过配件来达成个性化，而不是折腾机器本身」。Apple 不做，我就在 AI System 6 里做了个 CMF Studio 让大家 DIY。至于我自己这台，还是黑色。</p>]]></content:encoded>
</item>
<item>
<title>HIG 出了 Markdown 版 —— 一份 md 搞定 Duo 适配</title>
<link>https://aaronlau.me/2026/09/13/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/09/13/</guid>
<pubDate>Sun, 13 Sep 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>开发日志与一周短评</category><category>预言账本</category><category>iPhone</category>
<description><![CDATA[苹果为 iPhone Duo 发布 Markdown 版设计指南，应验了我 8 月说的官方需求文档；我的 app 靠啃 HIG 做出 60 分手机版。]]></description>
<content:encoded><![CDATA[<p>#开发日志与一周短评 #预言账本 #iPhone</p>
<p>苹果为 iPhone Duo 发了一份设计指南，文件名是 designing-for-iphone-duo.md，一份 Markdown，9 月 9 日发布会当天就上线了。我的第一句话是「还真被我言中了」。8 月 macOS 27 换红绿灯的时候，我说过「所以以后有什么新规范、新要求都能够迅速适配了，官方提供一份需求文档」。不到一个月，HIG 真的有了 md 版，对象还是一台全新形态的手机。</p>
<p>这条路我自己走过：「比如我之前 vibe 的 app 本来是没有手机版本的，让它啃了一遍 HIG，能交出 60 分的东西」。60 分不算好，但从没有到能用，只花了让模型读一遍文档的工夫。</p>
<p>所以「以后有 md 文件就能解决一切适配难题，当然了，token 自备」。</p>]]></content:encoded>
</item>
<item>
<title>给 WindowShade 加 Duo 开盖动画 —— ScreenCapture API 的妙用</title>
<link>https://aaronlau.me/2026/09/11/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/09/11/</guid>
<pubDate>Fri, 11 Sep 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>开发日志与一周短评</category><category>macOS</category>
<description><![CDATA[发布会后我给 WindowShade 加了类似 iPhone Duo 的开盖动画，用 ScreenCapture API 实现；改锁屏要开 SIP，只能作罢。]]></description>
<content:encoded><![CDATA[<p>#开发日志与一周短评 #macOS</p>
<p>发布会第二天，我给 WindowShade 发了 v1.0.10：「加了个开盖动画，类似 iPhone Duo 的」。做法比想象中省事，「Mac 版的我加到 WindowShade 里，正好用上了 ScreenCapture API」：先拿到当前屏幕的画面，再让它像 Duo 展开那样动起来。提示词也不复杂：「提示词挺简单的，把Apple官网交给AI去借鉴就好了，然后告诉它用ScreenCapture API」。</p>
<p>有一处做不到：「可惜改锁屏要打开 SIP」。锁屏归系统完整性保护管，不关 SIP 就动不了，动画只能出现在解锁之后。</p>
<p>WindowShade 6 月诞生的时候，只是想把 90 年代 Mac OS 卷起窗口的手感搬到 Golden Gate 上；三个月后，它开始追新品发布会的动画了。我也清楚「vibe 了一个 Mac 版 iPhone Duo 开盖动画的 app，虽然 GitHub 上一箩筐啦」，多我一个不多。</p>]]></content:encoded>
</item>
<item>
<title>Subagent 是超线程 —— Excel 吃的是主模型的单核</title>
<link>https://aaronlau.me/2026/09/05/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/09/05/</guid>
<pubDate>Sat, 05 Sep 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>开发日志与一周短评</category><category>AI</category>
<description><![CDATA[比较 AI 快慢要看任务能不能并发：subagent 像 CPU 的超线程，Excel 这类串行任务吃的是主模型本身的能力。]]></description>
<content:encoded><![CDATA[<p>#开发日志与一周短评 #AI</p>
<p>比较几个模型干活的快慢，我觉得常被漏掉的是这个变量：「还有一个影响速度的因素是任务本身能不能被并发，是可以多线程的还是只能串行的（在这个例子中可以把 subagent 理解成 CPU 领域的超线程）」。</p>
<p>能拆开的任务，派几个 subagent 分头做，跑得就快；只能一步接一步的任务，subagent 再多也帮不上。表格是后一种：「我们知道 Excel 吃单核性能，所以它在 AI 领域其实也是吃主模型的能力」。公式一环扣一环，前面一格算错，后面跟着错。还有一个变量是时间：「所以可能还要加一个变量是模型的上线时间，还有harness距今有多久」。</p>
<p>月中我说过先把 Excel 转成 Markdown 再交给 AI。格式这一关过掉之后，剩下的就是主模型单核的硬功夫。</p>]]></content:encoded>
</item>
<item>
<title>限时 +50% 变永久 +25% —— AI 订阅的数字游戏</title>
<link>https://aaronlau.me/2026/08/31/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/08/31/</guid>
<pubDate>Mon, 31 Aug 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>开发日志与一周短评</category><category>AI</category>
<description><![CDATA[Claude Code 额度从限时 +50% 回落到永久 +25%，和 DeepSeek 调到原价 25% 一样是数字游戏；原先的 quota 是情分还是本分？]]></description>
<content:encoded><![CDATA[<p>#开发日志与一周短评 #AI</p>
<p>「Claude Code 要从限时 + 50% 回落到永久 +25% 了」，9 月 14 日生效。听起来像是永久多送四分之一，实际上比这个月少了一截。这种说法我不陌生：「上一次听到这种数字游戏还是在 DeepSeek 在 5 月调整为原定价的 25%」。降价、加量、限时、永久，几个词排列组合一下，用户得拿计算器才知道自己是赚了还是亏了。</p>
<p>订阅档位也是一样。我月中算过一笔：「所以 200 美元的 plan 相对于 100 美元的 plan 是 4 倍的 5h limit 和 2 倍的 weekly limit」。价格翻倍，五小时额度给四倍，周额度只给两倍。</p>
<p>更根本的问题，月中我就觉得「好问题：原先的 quota 是情分还是本分」。如果是情分，回落就是收回人情；如果是本分，回落就是变相涨价。用惯了加量的人，只剩一句「由奢入俭难啊」。</p>]]></content:encoded>
</item>
<item>
<title>AI 写代码，原生开发回来了 —— 受益最大的是 iPadOS</title>
<link>https://aaronlau.me/2026/08/29/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/08/29/</guid>
<pubDate>Sat, 29 Aug 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>开发日志与一周短评</category><category>iPadOS</category><category>visionOS</category><category>预言账本</category>
<description><![CDATA[AI 写代码让每个平台各写一遍变便宜，统一框架的理由变弱；最大受益者可能是没人认真适配的 iPadOS 和 visionOS。]]></description>
<content:encoded><![CDATA[<p>#开发日志与一周短评 #iPadOS #visionOS #预言账本</p>
<p>AI 写代码之后，我对跨平台框架的看法变了：「AI code时代希望软件不要再用统一框架，在每个平台使用原生开发不是能最大化发挥平台优势吗」。2024 年我的感叹还是「毕竟现在的桌面端应用程序，万物都是 Electron，万物都是 Chromium」。那时候大家用一套代码打天下，是因为每个平台各写一遍太贵；现在最贵的那一部分，写代码本身，便宜下来了。</p>
<p>顺着推下去，「似乎 agentic coding 最大的受益者是 iPadOS 或 visionOS」。人不愿意为小平台单独花时间，agent 不挑活。</p>
<p>平台方能做的事也变简单了。系统每年改圆角、改红绿灯，与其指望开发者一份份读文档，不如把规范写成 agent 读得懂的样子：「所以以后有什么新规范、新要求都能够迅速适配了，官方提供一份需求文档」。这两条我先记在账上，看林檎什么时候接招。</p>]]></content:encoded>
</item>
<item>
<title>给 AI 爬虫投毒 —— 网站的反击与误伤</title>
<link>https://aaronlau.me/2026/08/25/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/08/25/</guid>
<pubDate>Tue, 25 Aug 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>社会观察</category><category>AI</category><category>开发日志与一周短评</category>
<description><![CDATA[TCRF 对 AI 爬虫旗帜鲜明，逻辑和澳洲拒绝 Google News 一样；但毒药不长眼，自部署模型和中转站最难追责。]]></description>
<content:encoded><![CDATA[<p>#社会观察 #AI #开发日志与一周短评</p>
<p>The Cutting Room Floor（TCRF）是专门挖游戏里被删减内容的维基，最近它对 AI 爬虫的做法，我只能说「The Cutting Room Floor 好旗帜鲜明的态度」：不只是拒绝，据 8 月初的一份第三方记录，它还会向特定 AI agent 返回带提示注入的页面。我能理解网站方，「但是站在对方的角度，其实跟澳洲曾经拒绝过 Google News 的逻辑如出一辙」。</p>
<p>麻烦在于毒药不长眼。「Claude 倒是聪明，可以绕过，但是假如没有做这方面侦测的模型厂商怎么办」。再往下一层：「比方说像使用大公司模型的不会受伤，而自己部署的，或者中转站的，有可能造成严重后果，而且溯源和追责困难」。最后吃亏的，是拿模型干活却不知道它吃过什么的人。</p>
<p>所以我转了一个 Anubis 的 PR，算是「一种折中的办法」。Anubis 靠工作量证明拦爬虫，不靠投毒。</p>]]></content:encoded>
</item>
<item>
<title>让 AI 说人话 —— 先限缩它的词汇</title>
<link>https://aaronlau.me/2026/08/24/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/08/24/</guid>
<pubDate>Mon, 24 Aug 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>开发日志与一周短评</category><category>AI</category><category>写作</category>
<description><![CDATA[让 AI 说人话的办法：要求它说 Simple English，或者把 r/explainlikeimfive 的版规做成 skill，用外部约束管住措辞。]]></description>
<content:encoded><![CDATA[<p>#开发日志与一周短评 #AI #写作</p>
<p>让 AI 说人话，我目前觉得管用的办法是少给它几个词：「有一种让 AI 说人话的方法是限缩它的词汇，比如要求它说 Simple English」。词汇表一收窄，模型就没法拿术语和修饰把一句话填满，只能把意思说直。</p>
<p>另一套现成的规矩来自 Reddit 的 r/explainlikeimfive。版名是“像对五岁小孩一样解释”，版规本来是写给人看的，要求回答让外行看得懂。我的做法是照搬：「不过按照这个 subreddit 的原则，把他做成 skill，AI 暂时能够说一点人话」。</p>
<p>这两个办法是同一个思路：不在提示词里写一句“请通俗易懂”了事，而是给它一套外部的、写死的约束。至于「暂时」两个字，是因为模型一换代，这套规矩管不管用就得重新试一遍。</p>]]></content:encoded>
</item>
<item>
<title>人脑要是能 /compact 就好了 —— AI 的毛病像人</title>
<link>https://aaronlau.me/2026/08/23/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/08/23/</guid>
<pubDate>Sun, 23 Aug 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>开发日志与一周短评</category><category>AI</category>
<description><![CDATA[用脑过度对应上下文过载，子代理对应摇人，continue 就是在吗；AI 的这些毛病，会不会本来就是从人类身上学来的？]]></description>
<content:encoded><![CDATA[<p>#开发日志与一周短评 #AI</p>
<p>用 Claude Code 久了，我养成一个习惯：「当你用 Claude Code 的时候，时不时 /compact 和 /clear 是好文明」。后来我发现这套说法放到人身上也成立：「用脑过度 则可以对应到 上下文过载，反映到 长对话变慢 而且 注意力稀释」。</p>
<p>于是我列了一张对照表：「假如人脑可以像 AI 那样 /compact 和 /clear 就好了，然后 子代理 可以对应到 摇人，continue 就是“在吗？”」。列着列着，我又把问题反过来问：「刚不小心扯远了，其实我想聊的是，会不会 AI 的这些特征，是从人类本身习来的呢」。</p>
<p>不过对照表里有一个指令，人类始终用不了：「但是现实世界没有 rewind 这个选项，在时间旅行实现之前」。模型可以退回上一个检查点，说出口的话和做过的决定不行。</p>]]></content:encoded>
</item>
<item>
<title>Agent 不用按指纹 —— Touch ID 该重新设计了</title>
<link>https://aaronlau.me/2026/08/19/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/08/19/</guid>
<pubDate>Wed, 19 Aug 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>开发日志与一周短评</category><category>AI</category><category>macOS</category>
<description><![CDATA[Claude 自己从系统钥匙串找出密码、完成整套操作，连 Touch ID 都没按。agent 成常态后，生物认证得重新设计。]]></description>
<content:encoded><![CDATA[<p>#开发日志与一周短评 #AI #macOS</p>
<p>最近让我愣住的一幕：「为什么我都没有自己登录，也没有告诉他用户名和密码，他就能从系统钥匙串自己找，自己完成整套动作，甚至都不需要按 Touch ID」。在 Mac 上，按一下指纹的意思是“人在场，人同意”，agent 接手之后，这个前提悄悄失效了。「但是 Claude 本身不像 Elpass 之类的密码管理器那样有密码锁呀」。</p>
<p>所以我的判断是：「假如成为常态了的话，似乎 Touch ID 和 Face ID 之类的认证方式要重新设计」。难处在于两头都得顾：「但是未来需不需要发展到检测屏幕面前是不是那个人，同时不能像 UAC 一样频繁弹窗」。</p>
<p>6 月我拿 Vista 的 UAC 吐槽 agent 提权太烦，那时我站在要一路点“允许”的那一边。现在 agent 连“允许”都不用点了，我反而开始担心那颗指纹按钮形同虚设。</p>]]></content:encoded>
</item>
<item>
<title>让 AI 读 Excel —— 先把表格变成 Markdown</title>
<link>https://aaronlau.me/2026/08/17/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/08/17/</guid>
<pubDate>Mon, 17 Aug 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>开发日志与一周短评</category><category>AI</category>
<description><![CDATA[AI System 6 导入 Excel 和 Numbers 的做法：先转成 Markdown；算数交给工具，就像高考可以带计算器。]]></description>
<content:encoded><![CDATA[<p>#开发日志与一周短评 #AI</p>
<p>让 AI 处理表格，我的办法是先绕开表格。「我当时在 AI System 6 做了一个功能是导入 Excel 和 Numbers」，思路很朴素：「那么只要想办法把 Excel 转换成 Markdown 就行」。表格文件里有公式、数据类型，还有各家软件自己的约定，转成 Markdown 之后，模型面对的只是一行一行的文本和竖线，读得懂，也写不坏。</p>
<p>算数这件事，我更愿意交给工具。「通俗的比喻是，高考考场可以带计算器，也就是可以调用工具才解决的」。数字之所以要较真，是因为「出错了担当不起，假如我是领导旁边的小秘书的话，也会仔细核对数字」。</p>
<p>为什么不干脆等一个什么都擅长的模型？我的感觉是「好像是强化一项能力，就需要在另一项能力作出让步，不存在六边形战士」。与其等六边形战士，不如先把格式这一关替它过掉。</p>]]></content:encoded>
</item>
<item>
<title>一周刷爆三家额度 —— AI System 6 的 token 账</title>
<link>https://aaronlau.me/2026/08/16/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/08/16/</guid>
<pubDate>Sun, 16 Aug 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>开发日志与一周短评</category><category>AI</category><category>AI System 6</category>
<description><![CDATA[为做 AI System 6，一周刷爆 Claude Max 与 ChatGPT Pro，DeepSeek 用掉 100 亿 token，还赶上峰谷定价。]]></description>
<content:encoded><![CDATA[<p>#开发日志与一周短评 #AI #AISystem6</p>
<p>做 AI System 6 的这一周，我交出一份不太体面的账单：「我已经把这周的 Claude Max 以及 ChatGPT Pro 订阅刷爆了，还有 DeepSeek 用了 100 亿 token」。AI System 6 是我在做的一张 AI 桌面，口号是 A working AI desktop, not a chat window，从 System 6 一路做到 Liquid Glass，在浏览器里开机。两家的周额度先见底，剩下的活就落到 DeepSeek 身上。</p>
<p>便宜的那一家也在变。第二天我看到「今天是实施峰谷定价的第一天」，平峰价是高峰价的一半，高峰为周一到周五 UTC 01:00-04:00 和 06:00-10:00，什么时候跑任务从此也算进成本。工具链还有一个坑：「哦对，DeepSeek V4 Pro 在 Codex 里暂时用不了子代理（？）」，想让它分头干活，得换个壳子。</p>
<p>三家额度一起见底，说明这种规模的项目，一个订阅已经兜不住。</p>]]></content:encoded>
</item>
<item>
<title>HyperCard 与 AI coding —— 像在哪里，不像在哪里</title>
<link>https://aaronlau.me/2026/08/14/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/08/14/</guid>
<pubDate>Fri, 14 Aug 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>AI</category><category>开发日志与一周短评</category><category>旧机考古</category>
<description><![CDATA[HyperCard 降低了写程序的门槛，AI 则替人完成实现；软件书在衰落，很多内容更像一个要长期维护的项目。]]></description>
<content:encoded><![CDATA[<p>#AI #开发日志与一周短评 #旧机考古</p>
<p>最近翻 HyperCard 的资料，我觉得它跟现在的 AI coding 有点像：都让不是程序员的人，也能做出别人能用的小软件。这段想法我先写了草稿，再让 AI 润色过，核心的判断是我自己的。像的地方很明显，不像的地方更重要：「以前 HyperCard 是降低了写程序的门槛，你还是需要理解自己做的东西；现在 AI 更多是在帮你完成实现，有时候甚至连中间过程都省掉了」。</p>
<p>同一时间我看到微软出版社裁员的新闻，想到的是软件书的命运。以前一本软件书能卖好几年，现在「你花半年写一本教程，可能刚出版，里面的截图、步骤、功能都已经过时」。</p>
<p>这也让我反思自己写东西的方式：「以前我们努力做一个“完成品”，比如一本书、一篇文章；现在很多东西更像一个长期维护的项目，需要不断成长」。HyperCard 的 stack、AI 写出来的 app、一篇会过时的分析，到最后都是同一个问题：做出来以后，还有没有人继续维护。</p>]]></content:encoded>
</item>
<item>
<title>让 AI 画 Liquid Glass，它画出了 Vista</title>
<link>https://aaronlau.me/2026/08/12/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/08/12/</guid>
<pubDate>Wed, 12 Aug 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>开发日志与一周短评</category><category>设计与界面</category><category>Liquid Glass</category>
<description><![CDATA[给 AI System 6 生成 Liquid Glass 风格图标，出来的是 Vista；扩展更多年代主题，是受了 AI Desktop XP 的刺激。]]></description>
<content:encoded><![CDATA[<p>#开发日志与一周短评 #设计与界面 #LiquidGlass</p>
<p>给 AI System 6 做 Liquid Glass 主题时，我偷了个懒：「让它用 Image Gen 技能逐个生成 Liquid Glass 风格的图标，但是出来的是 Vista」。这个结果有点好笑，去年夏天我自己就说过「macOS Tahoe 是 Vista」，现在连模型都站到了我这边。</p>
<p>做这么多年代的主题，起因是「主要是受了 AI Desktop 98 开发者近日推出 AI Desktop XP 的刺激」，「心想他可以，那我也拓展一下吧，AI System 9、10.2、10.6、10.10 和 26」。代价是 token，这几天的进度我的总结是「主要是 DeepSeek 那边烧了 100 亿 token 还没把事情办好」。Liquid Glass 图标最后还得自己一张张盯着做，Vista 那一版，就当作给 Tahoe 的旧账补一个注脚。</p>]]></content:encoded>
</item>
<item>
<title>AI System 6 要横跨几个年代 —— 先收口再说</title>
<link>https://aaronlau.me/2026/08/09/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/08/09/</guid>
<pubDate>Sun, 09 Aug 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>开发日志与一周短评</category><category>设计与界面</category><category>macOS</category>
<description><![CDATA[AI System 6 想涵盖六个年代的主题，可 Mac OS X 那几代要画 512 x 512 的图标，我得先收口。]]></description>
<content:encoded><![CDATA[<p>#开发日志与一周短评 #设计与界面 #macOS</p>
<p>AI System 6 原本只有一个年代，现在我想让它多住几个：「所以我也打算涵盖多一点主题，AI System 6、9、10.2、10.6、10.10 和 26」。难度不是平均分布的，坑在中间：「中间 Mac OS X 的，得认真设计，512 x 512 的图标诶」。Aqua 那几代的图标走写实路线，尺寸一下子大了很多，没法糊弄。</p>
<p>所以我得先给自己设一条线：「我觉得我需要先收口，假如今天还是想不到办法的话，停在 Mac OS 9 的 Platinum 算了」。两天后，对外的说法也定了：「假如明天要发布的话，只能提供 Classic、Platinum 和 Liquid Glass，其他几个还需要更多时间」。首尾两端加一个中间点，先把能交付的交出去，Aqua 那几代慢慢画。</p>]]></content:encoded>
</item>
<item>
<title>额度用完之后去哪 —— 从蹭 Wi-Fi 到蹭 token</title>
<link>https://aaronlau.me/2026/08/08/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/08/08/</guid>
<pubDate>Sat, 08 Aug 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>AI</category><category>开发日志与一周短评</category>
<description><![CDATA[GPT 和 Claude 的额度都用完之后，我会跑到 Kagi；我曾经抵触搜索引擎加 AI，直到自己也做了一个。]]></description>
<content:encoded><![CDATA[<p>#AI #开发日志与一周短评</p>
<p>我现在的工作流有一个固定的第三站：「我现在是 GPT 和 Claude 的额度都用完之后就会跑到 Kagi」。两家订阅轮着用，用到见底，就去一个带 AI 的搜索引擎接着查。</p>
<p>这在一年前是我想不到的。「我之前对搜索引擎 + AI 是比较抵触的，直到我自己也做了一个」。也是在那时，我才知道 Kagi 有 MCP。</p>
<p>几家里面，我更倚重的是 Claude：「以至于下个月我想开 Claude 的 Max 而不是 GPT 的」。额度这件事，也让我对一个新现象很有感触：「从蹭 Wi-Fi 到蹭 token」。这周有人提到 DeepSeek 也要涨价，我算了算自己烧掉的量，第一反应是「这要是换成 Opus 4.8 或者 GPT-5.6 Sol 得花多少钱呀」。</p>]]></content:encoded>
</item>
<item>
<title>Codex 爱测试，DeepSeek 省 token —— 两个 agent 的习性</title>
<link>https://aaronlau.me/2026/08/06/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/08/06/</guid>
<pubDate>Thu, 06 Aug 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>开发日志与一周短评</category><category>AI</category>
<description><![CDATA[Codex 太爱写测试、默认截图验证，工作文件夹攒了 10.27GB 垃圾；DeepSeek 不支持多模态，反而意外省 token。]]></description>
<content:encoded><![CDATA[<p>#开发日志与一周短评 #AI</p>
<p>DeepSeek 接入 Codex 这件事变简单了。「之前很麻烦，需要常驻第三方工具，现在直接提供脚本了」。用了几天，我发现一个没想到的好处：「然后由于 DeepSeek 不支持多模态，意外地省 token」。</p>
<p>省在哪里，要看另一边。很多 agent 验证自己的成果时喜欢截图，改完一个表格、一个页面，先拍一张再看。「Codex 默认也是，所以我工作文件夹累积了 10.27GB 的垃圾」。截图一多，既占硬盘，也占上下文；DeepSeek 看不了图，只能老老实实读文本，反而少烧了一大截。</p>
<p>Codex 还有一个习性：「Codex 确实太喜欢测试了，功能都没做出来」。测试是好习惯，可它常常先把测试脚手架搭得很完整，真正要做的功能还停在半路。</p>]]></content:encoded>
</item>
<item>
<title>面向 AI 的写作软件 —— 不是 Word，是 Photoshop</title>
<link>https://aaronlau.me/2026/08/05/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/08/05/</guid>
<pubDate>Wed, 05 Aug 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>AI</category><category>设计与界面</category><category>开发日志与一周短评</category>
<description><![CDATA[如果 LLM 是有损压缩，文字就能像图像一样处理；所以 AI 时代的写作软件，形态应该更接近 Photoshop 而不是 Word。]]></description>
<content:encoded><![CDATA[<p>#AI #设计与界面 #开发日志与一周短评</p>
<p>「打个比方，假如说 LLM 是有损压缩的话，那文字可以像图像一样处理」。图像压缩之后，我们不会逐像素去修，而是调整一个区域的亮度、换一块背景；文字交给 LLM 以后也是这样，它成了一块可以整体调整的材料，这一段语气软一点，那一段删掉一半。</p>
<p>我的结论是「所以面向 AI 的写作软件不是 Word 的形态而是 Photoshop 的形态」。Word 的核心是光标，你在哪里，字就在哪里长出来；Photoshop 的核心是图层和选区，先圈出一块，再决定对它做什么。顺着这个比喻我又想到人脑：「似乎人脑也是这样运作的，图片虽然记忆快，忘得也快，文字可以记很久」。</p>]]></content:encoded>
</item>
<item>
<title>shiftscreen 与 Lok Board —— 我也在做同样的蠢事</title>
<link>https://aaronlau.me/2026/07/31/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/07/31/</guid>
<pubDate>Fri, 31 Jul 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>macOS</category><category>设计与界面</category><category>开发日志与一周短评</category>
<description><![CDATA[两个台前调度替代品早就做出来了，大众仍不肯拿来 daily drive；提起它们，我才意识到自己复刻 WindowShade 也是同一件事。]]></description>
<content:encoded><![CDATA[<p>#macOS #设计与界面 #开发日志与一周短评</p>
<p>聊到窗口管理的新点子时，我先问了一句：「你还记得 shiftscreen 和 Lok Board 吗，两个 Stage Manager 替代品」。</p>
<p>它们都做出来了，也都能用。问题在后面：「虽然这已经成为现实了，但是大众还是不愿意把它纳入 daily drive，这件事情本身可以说明一些问题」。一个替代品能跑起来，和一个人愿意每天开机就用它，中间隔着很长的距离。</p>
<p>说完我自己愣了一下：「之所以提起这两个应用，我意识到我也在做同样的蠢事」。6 月我开始复刻经典 Mac OS 的 WindowShade，初衷是「我个人对 WindowShade 的想法是可以隐藏掉 Dock 栏，节省笔记本电脑的纵向空间」。想法我到现在都觉得没错，可它跟 shiftscreen、Lok Board 面对的是同一道门槛：做得出来，不等于有人愿意换。</p>]]></content:encoded>
</item>
<item>
<title>5 小时防沉迷又要回来了 —— 额度焦虑的日常</title>
<link>https://aaronlau.me/2026/07/30/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/07/30/</guid>
<pubDate>Thu, 30 Jul 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>开发日志与一周短评</category><category>AI</category>
<description><![CDATA[昨天 reset 的额度昨天用完，今天 reset 的今天用完；Codex 要恢复 5 小时限制，我叫它防沉迷。]]></description>
<content:encoded><![CDATA[<p>#开发日志与一周短评 #AI</p>
<p>这周我的状态可以用一句话概括：「快点 reset 啊啊啊啊」。额度按周期重置，我却按天烧完，「昨天 reset 的昨天已经用完了，今天 reset 的今天也已经用完了，所以才开的 Pro 5x」。升级后看了一眼仪表：「诶，我发现升级到 5x 之后刚好剩 80% 用量，也就是说今天用了 Plus 的 20% 用量」。换算回去，原来的 Plus 一天就见底。</p>
<p>然后坏消息来了：「5 小时防沉迷又要回来了」。我叫它防沉迷，因为它跟游戏里那套机制一样，玩到一定时长就强制下线。第二天看到 r/ClaudeCode 上的讨论，我只说了一句「怪不得 Codex 要恢复 5h limit」。接下来能做的，只有等 reset。</p>]]></content:encoded>
</item>
<item>
<title>AI 订阅的价格阶梯 —— 5x 为什么不是 5 倍价</title>
<link>https://aaronlau.me/2026/07/28/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/07/28/</guid>
<pubDate>Tue, 28 Jul 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>AI</category><category>社会观察</category><category>开发日志与一周短评</category>
<description><![CDATA[Claude 的 5x 是 1x 的 6.25 倍价，ChatGPT 的 Pro 20x 只要 Plus 的 10 倍价；价格阶梯在把人推向 200 美元档。]]></description>
<content:encoded><![CDATA[<p>#AI #社会观察 #开发日志与一周短评</p>
<p>今天升级订阅时我算了一笔账。「但是 Claude 的 5x 是 1x 的 6.25x 价格，想不通」，而「但是 ChatGPT 的 Pro 5x 是 Plus 的 5x 价格」。用量也说明问题：「假如一天就能用完 Plus 的用量，那么 5x 似乎也只是确保能用一周」。重度使用的人，5x 不是奢侈，只是够用。</p>
<p>两天后我又发现另一头：「等等，我才意识到 Pro 5x 是 Plus 的 5x 价格，但是 Pro 20x 仅是 Plus 的 10x 价格」。中间档按倍数收钱，最高档反而打对折，答案很明显：「所以官方的这个价格阶梯是鼓励大家买 200 美元的 tier 吗」。</p>
<p>林檎早就玩熟了这一套，「怪不得 iCloud 是 50GB、200GB 下一级就是 2TB」，我顺手给它编了新名字：iCloud+、iCloud Pro、iCloud Max 5x 和 iCloud Max 10x。2022 年我说 MacBook Air 的容量定价时也讲过，「或者说，8+256 充当了锚，星巴克里面的依云矿泉水，实际上真正的入门款是 8+512」。AI 订阅的 5x，就是这一轮的依云矿泉水。</p>]]></content:encoded>
</item>
<item>
<title>我的 Surge 规则交给 Codex 了 —— 一种虚无感</title>
<link>https://aaronlau.me/2026/07/23/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/07/23/</guid>
<pubDate>Thu, 23 Jul 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>开发日志与一周短评</category><category>AI</category>
<description><![CDATA[长年累积的 Surge 规则现在靠 Codex 维护，连我忘了怎么维护的服务器，也是它帮我完成迁移。]]></description>
<content:encoded><![CDATA[<p>#开发日志与一周短评 #AI</p>
<p>「感受到了一种虚无，长年累月累积下来的 Surge 规则，现在靠 Codex 来维护」。那些规则是我一条条攒起来的，哪条为哪个服务加、哪条后来失效，我曾经都记得；现在只要描述想要的结果，剩下的交给 agent。更让我服气的是，「重点是这台服务器由于太久没登录，自己已经忘记怎么维护了，它能帮我完成迁移」。</p>
<p>虚无感就来自这里：以前这些知识是我的，现在它们变成 agent 每次重新读出来的东西。同一天晚上，我给准备公开的项目加了一层防护：「这里用 Cloudflare 做了下防护，我觉得具备向公众开放的条件了」。维护交出去了，开不开门还是我自己决定。</p>]]></content:encoded>
</item>
<item>
<title>AI System 6 的路线图 —— 先 web，再 native，最后上 iPad</title>
<link>https://aaronlau.me/2026/07/17/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/07/17/</guid>
<pubDate>Fri, 17 Jul 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>开发日志与一周短评</category><category>AI</category>
<description><![CDATA[AI System 6 要不要部署到服务器、要不要做 native 版？我当初的路线是先做 web 版，再做 native 版，最后上 iPad。]]></description>
<content:encoded><![CDATA[<p>#开发日志与一周短评 #AI</p>
<p>AI System 6 走到一个岔路口：「我在想说要不要把 AI System 6 部署到服务器上或者做成 native 版」。</p>
<p>这个问题其实我一开始就想过：「我当时的想法是先做 web 版然后做 native 版最后上 iPad」。回头看这几个月，路线并没有走得那么直。5 月底我在备忘录里给自己列过一张修 bug 的清单，最后一句是「然后所有这些功能，用 0.8B 还有 4B 的模型测试一遍，然后加新功能」。也就是说，它得在很小的本地模型上也跑得动。6 月我又岔出去了一段：「上个月我不是在做 AI System 6 嘛，做着做着对 WindowShade 着了魔」。</p>
<p>按我当初定的顺序，web 版这一站还没走完，部署出去让别人用，应该排在 native 版前面。</p>]]></content:encoded>
</item>
<item>
<title>Feedback Assistant 里的八百年 —— 沾上战略就一夜支持</title>
<link>https://aaronlau.me/2026/07/15/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/07/15/</guid>
<pubDate>Wed, 15 Jul 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>社会观察</category><category>开发日志与一周短评</category>
<description><![CDATA[在 Feedback Assistant 上报的问题常常没人理，可一旦跟林檎的战略沾边，比如游戏，就可能一夜间完全支持。]]></description>
<content:encoded><![CDATA[<p>#社会观察 #开发日志与一周短评</p>
<p>「以前在 feedback assistant 上报都没人理的」。这句话我一个月里说了两次。上一次是在 6 月：「从前躺在 Feedback Assistant 八百年都没人理的」。</p>
<p>功能还是那个功能，用户也早就提过，变的是林檎自己需不需要它。我的观察是：「假如跟他们未来的策略沾边的话，比如 Apple Arcade+ 或者游戏什么的，他们可以在一夜间完全支持」。沾上战略的需求，不用排队；不沾边的，写得再详细，也只是 Feedback Assistant 里的又一个编号。</p>
<p>所以与其猜一个反馈会不会被处理，不如看它和林檎接下来想推的东西离得多远。</p>]]></content:encoded>
</item>
<item>
<title>不把鸡蛋放在一个篮子里 —— AI 对话的备份问题</title>
<link>https://aaronlau.me/2026/07/13/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/07/13/</guid>
<pubDate>Mon, 13 Jul 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>开发日志与一周短评</category><category>AI</category>
<description><![CDATA[Code 的会话存在本地还好，Chat 和 Work 没有备份；导出数据也导不全，所以我现在 GPT 和 Claude 轮流用。]]></description>
<content:encoded><![CDATA[<p>#开发日志与一周短评 #AI</p>
<p>「Code 还好点，保存在本地，但是 Work 和 Chat 没有备份啊」。代码会话落在自己硬盘上，聊天和协作对话全在服务商那边。我就遇过，之前跟 Claude 聊过的普通聊天一夜间消失了。</p>
<p>导出也兜不住：「而且它那个 export your data，似乎不会导出完整的对话记录」。</p>
<p>所以我的做法很朴素：「目前是 GPT 和 Claude 轮流用，不想把鸡蛋放在一个篮子里」。Claude 集成在一个 app 里，ChatGPT 要装两个，各有不便，但任何一边出事，另一边还在。</p>]]></content:encoded>
</item>
<item>
<title>林檎的温和 AI 路线 —— Core ML 改名 Core AI 之后</title>
<link>https://aaronlau.me/2026/07/08/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/07/08/</guid>
<pubDate>Wed, 08 Jul 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>AI</category><category>Apple</category><category>开发日志与一周短评</category>
<description><![CDATA[重读 2020 年林檎讲机器学习的旧文，开始理解它的温和路线；Core ML 改名 Core AI，也许笑到最后的是它。]]></description>
<content:encoded><![CDATA[<p>#AI #Apple #开发日志与一周短评</p>
<p>翻到 2020 年 Ars Technica 一篇林檎讲机器学习的采访，忍不住想：「另一个时间线，假如整个 2020 年代是这种温和的 AI 进展，没有所谓 LLM 的话」。那篇文章里没有聊天机器人，而「文章里列举的工作最终都做进了 iOS 系统里」。</p>
<p>林檎并非没碰语言模型，2023 年 iOS 17 的键盘预测就基于 GPT-2，今天的 AFM 3 Core Advanced 也是 Transformer。另一篇两年前的文章这次再读，感受变了：「开始能理解 Apple 的想法了，特别是 Core ML 改名 Core AI，会不会他们才是能笑到最后的」。先记一笔。</p>]]></content:encoded>
</item>
<item>
<title>让 agent 改系统设置 —— 方便，但是黑箱</title>
<link>https://aaronlau.me/2026/07/03/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/07/03/</guid>
<pubDate>Fri, 03 Jul 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>开发日志与一周短评</category><category>macOS</category><category>AI</category>
<description><![CDATA[2024 年我希望用 LLM 驱动的 Siri 取代设置 app；现在 agent 真的能改任何设置了，问题变成用户不知道它改了什么。]]></description>
<content:encoded><![CDATA[<p>#开发日志与一周短评 #macOS #AI</p>
<p>「虽然时至今日 agent 可以修改任何系统设置，但是对用户是黑箱的，不够透明」。它跑几条 defaults 命令就办完事，你不知道它碰了哪些键，也不知道怎么改回去。</p>
<p>办法是记账，「听起来很像 Total Uninstall 那种在软件安装过程中就开始介入的模式」。可「如果这个问题连第一方都处理不好的话，我在想第三方的机会在哪里」，我最近确实想做一个 defaults 相关的 app。macOS 27 的圆角和侧边栏，在 26 上改几个 defaults 就能提前实现，一条命令就能改掉界面。</p>
<p>2024 年我还说「最好是官宣取消 Settings app，以后用 LLM 驱动的 Siri 来更改系统设置」。两年后自然语言改设置成真了，来的不是 Siri 而是 agent；我也从希望它取代设置界面，变成希望它留下一份看得懂的记录。</p>]]></content:encoded>
</item>
<item>
<title>便笺的「浮动于上方」 —— macOS 唯一会置顶的第一方 app</title>
<link>https://aaronlau.me/2026/07/02/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/07/02/</guid>
<pubDate>Thu, 02 Jul 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>macOS</category><category>开发日志与一周短评</category><category>旧机考古</category>
<description><![CDATA[Stickies 是 macOS 里唯一能让窗口置顶的第一方 app，这是经典 Mac OS 留下的传统；我把这个功能做进了 WindowShade。]]></description>
<content:encoded><![CDATA[<p>#macOS #开发日志与一周短评 #旧机考古</p>
<p>「如果我没记错的话，Stickies 是整个 macOS 中唯一具有窗口置顶能力的第一方 app，因为继承经典 Mac OS 的传统」。便笺菜单里有一项“浮动于上方”，勾上就盖在所有窗口上。</p>
<p>复刻 WindowShade 时我把置顶也做了进去。Windows 有 PowerToys 的 Always On Top，macOS 却没有。我最常用它钉住 iPhone Mirroring 和 Apple Music 迷你播放器，「打个不恰当的比方，Excel 的冻结窗格」。</p>
<p>2021 年我说过「说起来 Stickies app 的 UI 二十年来始终如一」。五年后再看，它连经典 Mac OS 的置顶能力也一起留了下来。</p>]]></content:encoded>
</item>
<item>
<title>回不去古法编程 —— ChatGPT 规划，Codex 动手</title>
<link>https://aaronlau.me/2026/07/01/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/07/01/</guid>
<pubDate>Wed, 01 Jul 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>开发日志与一周短评</category><category>AI</category>
<description><![CDATA[大家习惯了 AI 带来的产出量，回到古法编程就赶不上约定时间；我目前的分工是让 ChatGPT 做规划、Codex 改代码。]]></description>
<content:encoded><![CDATA[<p>#开发日志与一周短评 #AI</p>
<p>「主要是大家习惯了更多的产出，如果没了 AI 回到古法编程，在约定时间内根本完成不了」。交付标准已经按有 AI 的速度定好，单靠人手追不上。</p>
<p>既然离不开，就得分配额度。一个 MCP 能打通 Codex 和 ChatGPT，「平时亦可用 ChatGPT 为 Codex 项目做规划以节省用量」。实测下来分工很清楚：「让 ChatGPT 为 Codex 项目做规划可以，但是让 ChatGPT 直接改代码好像要烧掉不少时间」。规划交给 ChatGPT，动手还是 Codex。</p>]]></content:encoded>
</item>
<item>
<title>iPhone Mirroring 的圆角 —— 唯一对不上的窗口</title>
<link>https://aaronlau.me/2026/06/28/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/06/28/</guid>
<pubDate>Sun, 28 Jun 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>macOS</category><category>开发日志与一周短评</category><category>设计与界面</category>
<description><![CDATA[开发折叠标题栏的 app 时发现，iPhone Mirroring 的窗口上下圆角不一致，和 iPhone 机身圆角也没关系。]]></description>
<content:encoded><![CDATA[<p>#macOS #开发日志与一周短评 #设计与界面</p>
<p>「说到 R 角的问题，iPhone Mirroring 这个不能自圆其说」。</p>
<p>我在开发折叠标题栏的 app，发现它是特例：「因为其他窗口四个角都是 R 角一致的，但 iPhone Mirroring 不是，他甚至跟 iPhone 机身的圆角没有关联，你会觉得很割裂」。顶部和底部的圆角不一样，只能单独处理。macOS 27 刚统一了窗口圆角，原以为剩下的只有标题栏，没想到还有这个漏网之鱼。</p>
<p>2024 年它刚出来时，我看重的是能省掉几个 app 版本，Things 3 我买了三份。两年后自己写窗口工具，才看到它的四个角没按 Mac 的规矩来。</p>]]></content:encoded>
</item>
<item>
<title>Dock 不再领先 —— 最小化的窗口该留在原地</title>
<link>https://aaronlau.me/2026/06/18/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/06/18/</guid>
<pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>macOS</category><category>开发日志与一周短评</category><category>设计与界面</category>
<description><![CDATA[屏幕变大之后，从 Dock 里找最小化的窗口反而绕远路；我在 15 寸 MacBook Air 上隐藏 Dock，让窗口卷起留在原位。]]></description>
<content:encoded><![CDATA[<p>#macOS #开发日志与一周短评 #设计与界面</p>
<p>「曾经 Dock 栏或者说任务栏是一个领先的设计，但是现在屏幕普遍比之前大」。外接大屏上，鼠标从屏幕中间拖到 Dock，要走很长一段路。</p>
<p>最小化更别扭：「而且最小化的窗口从 Dock 栏找，还不如从它被最小化之前的位置找」。所以我复刻 WindowShade，在 15 寸 Air 上隐藏 Dock，让窗口卷成一条标题栏留在原地，双击还能看到后面的内容。</p>
<p>还没定的是预览怎么触发：「hover 也做过，但是 timeout 不好控制，我还没掌握到 hover 的诀窍」。停太短会误触，停太长又像没反应。</p>]]></content:encoded>
</item>
<item>
<title>AirPods Max 的线控 —— 一个操作按钮快捷指令</title>
<link>https://aaronlau.me/2026/06/17/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/06/17/</guid>
<pubDate>Wed, 17 Jun 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>开发日志与一周短评</category><category>Shortcuts</category><category>AirPods</category>
<description><![CDATA[把 iPhone 操作按钮和音量键组合成 iPod nano 7 式的线控，给 AirPods Max 切通透、切歌，不用抬手摸耳机。]]></description>
<content:encoded><![CDATA[<p>#开发日志与一周短评 #Shortcuts #AirPods</p>
<p>我做了个 AirPods Max companion 快捷指令，灵感来自 iPod nano 7 和 EarPods 线控：单按 iPhone 操作按钮，暂停音乐、切到通透；再按一下恢复播放、切回降噪。按住等振动再按音量键，就能切歌。</p>
<p>其他有降噪的 AirPods 也能用，「不过对 AirPods Max 最实用，因为摘下来会破坏发型嘛」。「虽然 2 代有自适应降噪和对话感知，但我还是觉得这个快捷指令有其存在的价值」。</p>
<p>最麻烦的是记住当前状态。Shortcuts 到 iOS 27 才有官方的持久化存储，以前只能把状态塞进 iCloud、提醒事项或备忘录，麻烦又脆弱。</p>]]></content:encoded>
</item>
<item>
<title>复刻 WindowShade —— 卷起窗口，藏起 Dock</title>
<link>https://aaronlau.me/2026/06/14/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/06/14/</guid>
<pubDate>Sun, 14 Jun 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>开发日志与一周短评</category><category>macOS</category><category>兴趣笔记</category>
<description><![CDATA[WindowMizer 只支持到 Ventura，我打算在新版 macOS 上复刻经典 Mac OS 的 WindowShade，用来替代 Dock。]]></description>
<content:encoded><![CDATA[<p>#开发日志与一周短评 #macOS #兴趣笔记</p>
<p>WindowMizer 这个 app 只支持到 Ventura，所以「我打算弄一个在 Tahoe 和 Golden Gate 上能用的」WindowShade。「我个人对 WindowShade 的想法是可以隐藏掉 Dock 栏，节省笔记本电脑的纵向空间」，反正还可以用 command + tab 切换应用；接外接显示器时，在原地卷起、展开窗口，指针不用大老远移到 Dock 栏。</p>
<p>难点在标题栏。WindowShade 的原意是把窗口卷到只剩标题栏，可 Liquid Glass 的标题栏和控件融成了一体，我还在想是不是要自己画一个单独的标题栏。WindowShade 一开始也是第三方软件，「而且 Bartender 今年被彻底 sherlocked 了，当年 System 7.5 至少还会把 SuperClock! 给买下来」。</p>
<p>2022 年我嫌「Stage Manager 把多任务变成了一种负担，一种仪式，一种折磨」。四年后我给自己找的窗口管理方案，来自一个还没有 Dock 的年代。</p>]]></content:encoded>
</item>
<item>
<title>Mac Catalyst 绕的一大圈 —— 触屏 MacBook 的阳谋</title>
<link>https://aaronlau.me/2026/06/11/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/06/11/</guid>
<pubDate>Thu, 11 Jun 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>Mac</category><category>开发日志与一周短评</category><category>iPadOS</category><category>预言账本</category>
<description><![CDATA[触摸屏 MacBook Pro 的意义，可能是运行 iPadOS 上触摸优先的 app，弥补 Mac Catalyst 没实现的愿景。]]></description>
<content:encoded><![CDATA[<p>#Mac #开发日志与一周短评 #iPadOS #预言账本</p>
<p>Mark Gurman 说，MacBook Pro 加触摸屏是为了多提供一种交互方式，而不是替代。但他没回答：MacBook Pro 为什么需要触摸屏？我能想到的理由只有一个，在 MacBook Pro 上运行 iPadOS 那些触摸优先的 app。</p>
<p>我在想这是不是一个阳谋。2019 年的 Mac Catalyst，和 2020 年 M1 Mac 直接运行 iPadOS app，总感觉是一路铺过来的。可 Catalyst 的愿景似乎从未实现，移动端的 app 数量优势没有转移到桌面端，开发者反而用 opt-out Mac App Store 的方式抵制。时过境迁，缺 app 的反而成了 Intel Mac，macOS 27 只支持 M1 起的 Mac，Universal Binary 2 也快退出历史舞台。「假如 Mac Catalyst 出道即成功，那就不需要绕这么一大圈」。「现在变成你需要有一台 iPhone 才能运行 iPhone apps」。WWDC26 那篇给 Sidecar 适配触摸手势的 Technote，在我看来醉翁之意不在酒：「触屏 MacBook 应该是成定局的，就看有哪些交互问题可以被提前发现并解决，不然还要等下一年才会改」。</p>
<p>2022 年我说「与其指望 iPad Pro 搭载 macOS，不如指望 MacBook Air 搭载 iPadOS」；2024 年 iPhone Mirroring 出来，我担心它让桌面端 app 更加荒芜。如今的答案是 MacBook 长出了触摸屏，离当年那句话不算远。</p>]]></content:encoded>
</item>
<item>
<title>WWDC26 重头戏在 PSOTU —— 大写的 Code Intelligence</title>
<link>https://aaronlau.me/2026/06/06/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/06/06/</guid>
<pubDate>Sat, 06 Jun 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>开发日志与一周短评</category><category>WWDC</category><category>预言账本</category>
<description><![CDATA[WWDC26 开幕前，我把今年的重头戏押在 Platforms State of the Union，而不是面向消费者的 Keynote。]]></description>
<content:encoded><![CDATA[<p>#开发日志与一周短评 #WWDC #预言账本</p>
<p>「我觉得今年的重头戏应该是在 Platforms State of the Union」。北京时间凌晨 1 点的 Keynote 可以看个热闹，凌晨 4 点那场才是正餐。理由有两条。第一条是我前几天的判断：AI 管道化，林檎今年还是指望开发者多用它的 Foundation Models，真正的干货就该讲给开发者听。第二条是措辞：「过去也有“code intelligence”的提法，但是这次是大写」。同一个词，以前是一句描述，今年在预告里成了专名。</p>
<p>这让我想起另一种 WWDC：「那一年有许多引擎盖下的更新，包括说 Grand Central Dispatch」。用户层面看不出多少花样，开发者却拿到了一整套新工具。</p>
<p>iOS 27 消费者那一侧的传闻越单薄，我越倾向于相信，今年会是那样的一年。</p>]]></content:encoded>
</item>
<item>
<title>给 Agent 提权，人最慢 —— 比 Vista UAC 还烦</title>
<link>https://aaronlau.me/2026/06/03/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/06/03/</guid>
<pubDate>Wed, 03 Jun 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>AI</category><category>开发日志与一周短评</category>
<description><![CDATA[用 Codex 时大家都把权限给够，因为每一步提权都让人确认，会比 Windows Vista 的 UAC 还烦。]]></description>
<content:encoded><![CDATA[<p>#AI #开发日志与一周短评</p>
<p>现在大家用 Codex，基本都是把权限给够。原因我想得很清楚：</p>
<blockquote><p>给 agent 权限这件事情本身，人类的效率是最低的，假如每一项提权操作都需要人来确认，那会比 Vista 的 UAC 还要烦</p></blockquote>
<p>假如每一步都停下来等人确认，人就成了整条链路里最慢的那一环。这个比喻我不是第一次用。2023 年 iOS 16 加了剪贴板弹窗，我就问过它「会不会让你想起 Windows Vista 的用户账户控制」；再早一年，我担心的是提示一开，用户拒绝剪贴板反而成了不正当的事，最后被骂的是 iPhone，而不是滥用剪贴板的开发者。</p>
<p>那时我站在被弹窗打扰的用户这边，替用户嫌烦；现在我自己就是那个要一路给 agent 点「允许」的人，结论没变，只是嫌烦的人换成了我。</p>]]></content:encoded>
</item>
<item>
<title>新功能叠不上去 —— AI System 6 的第一道坎</title>
<link>https://aaronlau.me/2026/05/31/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/05/31/</guid>
<pubDate>Sun, 31 May 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>AI System 6</category><category>开发日志与一周短评</category>
<description><![CDATA[AI System 6 做了两周，很难再往上叠新功能，会打破已经实现好的功能；我给自己定了先修、再测、后加的顺序。]]></description>
<content:encoded><![CDATA[<p>#AISystem6 #开发日志与一周短评</p>
<p>AI System 6 做了两周，我撞上了第一道坎：「现在遇到一个烦恼是，很难再往上叠新功能，会把已经实现好的功能打破」。AI 写得很快，可每加一个功能，它都可能顺手动到旁边已经调好的地方。</p>
<p>所以我在备忘录里给自己排了顺序：先修 bug，再测，最后才加功能。「然后所有这些功能，用 0.8B 还有 4B 的模型测试一遍，然后加新功能」。小模型能跑通，心里才有底。调好的 CSS 也要写成文档，下一个接手的 AI 才知道哪些不能乱动。</p>
<p>上下文也是硬约束：「刚好我在 vibe 的 app 没个 128K 上下文，无法保证日常功能」。我做这套桌面隐喻是为了治上下文爆炸，开发它的时候，最先撞上的也还是上下文。</p>]]></content:encoded>
</item>
<item>
<title>AI 额度用完之后 —— 偷偷降级，还是另给一份老模型</title>
<link>https://aaronlau.me/2026/05/30/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/05/30/</guid>
<pubDate>Sat, 30 May 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>AI</category><category>开发日志与一周短评</category>
<description><![CDATA[Gemini CLI 以前额度用完就偷偷降级，Codex 则把 GPT-5.3-Codex-Spark 这个老模型的额度单独拿出来。]]></description>
<content:encoded><![CDATA[<p>#AI #开发日志与一周短评</p>
<p>写代码的 AI 都有额度，额度用完之后怎么办，各家做法不一样。我的理解是：「我记得 Gemini CLI 以前的策略是自动调整模型，让你一直可以写代码，都是偷偷降级，然后 Codex 是将 GPT-5.3-Codex-Spark 这个老模型的额度给独立出来」。</p>
<p>前一天看用量时我就注意到，「似乎可以理解为 GPT-5.3-Codex-Spark 这个模型的用量是独立的」，OpenAI 的说明也是研究预览期间它有单独的限额。主力模型的额度用完，还有一份老模型的额度可以接着用，用户知道自己换了模型。</p>
<p>偷偷降级的麻烦在于，你不知道此刻在跟哪个模型说话，写出来的东西突然变差，也不知道该怪谁。</p>]]></content:encoded>
</item>
<item>
<title>用 Marp 做演示文稿 —— 既然大模型爱写 Markdown</title>
<link>https://aaronlau.me/2026/05/29/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/05/29/</guid>
<pubDate>Fri, 29 May 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>AI</category><category>开发日志与一周短评</category>
<description><![CDATA[大模型喜欢输出 Markdown，我在研究用 Marp 做演示文稿；难点是风格怎么变化，理论上可以让大模型做模板。]]></description>
<content:encoded><![CDATA[<p>#AI #开发日志与一周短评</p>
<p>「最近在研究用 Marp 做演示文稿，既然大模型喜欢输出 markdown 的话」。Marp 把一份 Markdown 文件按分隔线切成一页页幻灯片，可以导出成 HTML、PDF 或 PPTX。大模型最顺手的输出格式，直接就能变成演示文稿。这样做的好处是，内容就是一份文本，改一句话不用点开 Keynote 找文本框，交给 AI 改也不会把排版弄乱。</p>
<p>难点在视觉。「但是风格要如何多变化，这是一个问题，理论上可以让大模型来制作模板」。Marp 的主题是 CSS 写的，样式和内容分开放，内容让模型写，主题也可以让模型写。</p>
<p>只是模型做出来的模板会不会千篇一律，我还得多试几套才知道。</p>]]></content:encoded>
</item>
<item>
<title>自动拉起 LM Studio —— 让本地模型开箱即用</title>
<link>https://aaronlau.me/2026/05/27/</link>
<guid isPermaLink="true">https://aaronlau.me/2026/05/27/</guid>
<pubDate>Wed, 27 May 2026 00:00:00 GMT</pubDate>
<author>Aaron Lau（韩栖）</author>
<dc:creator>Aaron Lau（韩栖）</dc:creator>
<category>AI</category><category>本地模型</category><category>开发日志与一周短评</category>
<description><![CDATA[给 app 做了自动拉起 LM Studio 的功能，下载过模型就能直接用，默认 qwen3.5-4b-mlx；主要代码不到 1.44MB。]]></description>
<content:encoded><![CDATA[<p>#AI #本地模型 #开发日志与一周短评</p>
<p>这几天给我的 app 加了一个功能：「我做了自动拉起 LM Studio 的功能，如果之前有下载过模型，应该就可以直接用了，默认是 qwen3.5-4b-mlx，也可以用其他模型」。用户不用自己开 LM Studio、再去开本地服务器，点开 app 就能和本地模型说话。安装包看着不小，但「node.js 打包可能显得文件体积很大，但是主要的代码只有 1.44MB 不到」，大头是运行时。</p>
<p>帮助文档也不必另开网页：「可以直接在 ClioTalk 里问他是干嘛的，我内置了三份帮助文件进去」。交给模型，让它来答。</p>
<p>三年前我说苹果要作出区隔，只能选本地 AI 的赛道。如今轮到我自己，在 Mac 上把本地模型接进一个 app。</p>]]></content:encoded>
</item>
</channel>
</rss>
