少数派 -- Matrix

1个人、1个月、上线 7 天 1000+ 次下载：我用 AI 做了个App，结果用户只想滑卡

ArkLab — Mon, 20 Jul 2026 00:39:43 GMT

大家好，我是 Ark。一晃来少数派已经 11 年多了，这也是我第一次在这里发文。

过去两个月，利用工作之外的时间，一个人借助 Codex 和 Claude Code，完成了 ArkFlow 长流APP的设计、开发和上架。上线 7 天后，它获得了 1000 次下载。

不过，这篇文章并不主要想讨论 AI 如何帮我写代码。

我更想分享一件出乎我意料的事：我原本花了最多时间，设计了一套关于资产和人生自由度的系统；产品上线后，几乎没有人讨论它，大家反而更喜欢滑银行卡。

这也让我重新认识了自己做出来的产品。

我目前大约有 50+ 需要管理的账户。

其中包括 10 多张储蓄卡、20 多张信用卡、几张海外银行卡，以及股票、基金、电子钱包等账户。

账户多了以后，真正麻烦的并不是计算总资产。

麻烦的是，我经常记不清某张信用卡的还款日，不确定一张很少使用的卡是否还要收年费；临时需要某个账户时，还要在不同银行 App 之间反复寻找。至于股票、基金和外币账户，则散落在另外几个不同的券商平台里。

我试过用记账软件，也试过用表格整理。

但传统记账软件更关心“今天花了多少钱”，表格则需要持续维护。它们都很实用，只是解决的并不是我最想解决的问题：

我不想记录每一杯咖啡，我只是想知道自己有哪些账户、钱放在哪里，以及接下来有哪些事情不能忘。

于是，我开始做 ArkFlow。

最开始，我以为它会是一款比较常规的资产管理 App。直到产品上线后，我才发现，用户真正感兴趣的东西，和我最初设想的完全不同。

卡包堆叠模式

卡包聚焦模式

卡面墙

卡包模式

卡面墙

银行卡不只是一串余额

整理银行卡时，我发现一个很奇怪的现象。

有些卡其实已经很久没有使用了，我却一直舍不得删除。

第一张工资卡、刚工作时办理的信用卡、出国时申请的visa和运通银行卡，以及某个阶段为了积分、权益或者卡面专门办理的卡。它们的实际用途可能已经消失，但看到卡面的那一刻，我还是能够想起当时的生活。

我们习惯收藏照片、车票、电影票和旧手机，却很少把银行卡看成一种值得保存的东西。

但对很多人来说，银行卡其实也在记录人生。

一张卡可能对应第一份工作，一张卡可能是第一次独自旅行，还有一张卡可能只是因为卡面很好看，明明用不上，却一直没有舍得注销。

这也是为什么，在设计 ArkFlow 时，我没有把账户简单做成传统的表格列表，而是希望它首先看起来像一个真正的卡包。

每一个账户都可以使用银行 Logo，也可以上传自己喜欢的真实卡面。银行卡按照接近真实卡片的比例展示，可以堆叠、滑动、展开，也可以整理成一面卡墙。

金额和账户信息仍然存在，但卡本身不再只是数据的容器。

它也可以是一件值得把玩的东西。

我原本以为，用户最需要的是资产分析

ArkFlow 最初的定位是一个“人生自由度资产系统”。

我不只想告诉用户“现在有多少钱”，还想回答一个更难的问题：

这些资产，究竟能为一个人带来多大的生活选择权？

同样是一笔存款，对一个没有负债、生活成本很低的人，和一个承担房贷、家庭支出的人，意义可能完全不同。相比单独展示资产数字，我更希望用户能看见，自己的财务状态正在怎样改变生活。

因此，我专门设计了一套“自由度画像”系统。

自由度画像

它会综合资产、负债、收入、支出和目标完成情况，计算用户当前的自由度阶段。为了不让结果只是一条冰冷的进度条，我又设计了 60 个成长阶段，并为男性和女性分别制作了一套人物形象。

从被账单和工作推着走，到逐渐拥有缓冲空间；从可以暂时停下来休息，到真正拥有重新选择工作和生活方式的能力。

我在这套系统上花了很多时间。

除了测算逻辑，还需要反复调整分数变化、阶段划分、人物状态和对应文案。我既不希望它变成简单的财富排名，也不希望用户因为资产不够多而感到被评判。

在产品上线前，我一直认为，这会是 ArkFlow 最重要、也最容易引起讨论的功能。

结果上线之后，几乎没有人讨论它。

很少有人问自由度分数是怎么计算的，也几乎没有人分享自己到达了哪个人物阶段。

用户反馈最多的反而是：

能不能上传自己的真实卡面？

卡片可不可以增加更多堆叠方式？

能不能把首页和分析页隐藏，只留下卡包？

能不能做一面墙，专门展示收藏的银行卡？

卡片抽出来以后，返回时能不能飞回原来的位置？

有用户甚至直接告诉我，他根本不在意资产分析，只想用它收藏卡面。

这对我来说是一个很强烈的信号。

开发者很容易认为，自己花费时间最多、逻辑最复杂的功能，也应该是用户最在意的功能。

但用户不会按照开发成本评价产品。

自由度画像需要用户先理解一套概念，而银行卡卡包几乎不需要解释。用户看到自己的银行卡在屏幕里堆叠、滑动和展开，立刻就能判断自己喜不喜欢。

对 ArkFlow 来说，用户最先记住的并不是“它可以计算资产自由度”，而是：

银行卡原来还可以这样玩。

于是，我开始重新调整产品。

资产管理依然是底层能力，自由度画像也没有被删除，但卡包逐渐成为产品最重要的入口。用户不是先看到一堆数字，再进入账户列表；而是先看到自己的卡，再从卡片进入余额、额度、还款日和账户详情。

我依然相信，资产最终应该服务于人的选择自由。

但我也开始明白，一个宏大的产品理念，不一定适合作为用户进入产品的第一步。

这不仅是视觉顺序的变化，也是我对产品定位的一次重新理解。

为了让滑动“有感觉”，我做了三种卡片堆叠

卡片交互看起来并不复杂：上下滑动、点击展开、长按排序。

但真正实现后，我发现，卡片“能滑”和“滑起来舒服”完全是两件事。

如果所有卡片平均排列，账户一多，屏幕会显得非常拥挤；如果堆叠得太紧，用户又无法判断下面还有多少张卡。卡片抽出时如果速度太快，会显得生硬；返回时如果直接消失，又会破坏卡片原本存在于卡包中的感觉。

我陆续尝试了三种排列方式。

卡包堆叠模式

卡包聚焦模式

卡面墙

第一种是比较传统的层叠方式，每张卡露出一部分，可以快速浏览多个账户。并且精心设计了卡片之间重叠区域上下露出的间距和字段，确保用户在各种场景下可以一眼看清每个卡片的账户名称和金额：这个卡是哪个银行，欠款或者余额具体是多少。

第二种会把当前卡片作为视觉焦点，其他卡片在后方收拢，更适合慢慢查看卡面，也更规整和有序。

第三种则更接近 Apple Wallet 的体验。卡片平时紧凑地堆在一起，点击后展开，选中的卡片从堆叠中抽出，关闭详情时再返回原位。这个也是几乎按照Apple的效果进行的还原，我原本不想做这个效果，但是用户反馈的需要的人特别多，都希望加上，并且我的创新的交互也要我1:1去还原Apple，大家都说的是，习惯了Apple的交互，懒得修改了。于是我被迫走上了”抄袭“，也算一种对Apple的致敬。

为了让卡片返回时看起来更自然，我反复调整了遮罩、位移、缩放和动画触发的顺序。

有时候只是几十毫秒的差异，最终的感受却会完全不同。

动画太快，像界面跳转；太慢，又会阻碍操作。卡片移动距离太小，没有被真正“抽出”的感觉；移动距离太大，又像从另一个页面飞进来。

这可能是整个开发过程中，最不符合投入产出比的一部分。

它没有增加新的资产类别，也没有让计算结果更加精确。但很多用户第一次看到 ArkFlow 时，恰恰会因为这段滑动停下来。

我后来逐渐接受了一件事：

对工具类产品来说，愉悦感本身也可以是一种功能。

它不会替用户完成任务，却会决定用户是否愿意再次打开这个工具。

好看之后，它仍然需要解决实际问题

当然，我并不希望 ArkFlow 最终只是一个银行卡展示架。

当账户数量超过十几个以后，管理问题仍然真实存在。

因此，每张卡片背后都可以记录余额、信用额度、账单日、还款日、年费信息、币种和备注。股票、基金、现金和其他类型的账户，也可以放进同一个系统中。

我没有把它做成一款需要记录每笔消费的记账软件。

ArkFlow 更关心的是“现在”。

现在一共有多少资产和负债，分别放在哪些账户；信用卡还有多少额度，哪几张即将还款；不同币种的资产换算后大约是多少；哪些账户正在使用，哪些只是暂时保留。

这种模式不一定适合所有人。

如果只有一两张银行卡，打开银行 App 可能已经足够。只有当账户逐渐增多，或者开始同时管理信用卡、投资和外币资产时，把它们集中起来才会产生明显价值。

这也是 ArkFlow 比较明确的目标用户：拥有多个账户，同时在意隐私、效率和视觉体验的人。

信用卡还款提醒日历

财务 App 最重要的能力，可能是“不知道你有多少钱”

在制作 ArkFlow 时，我一直不太愿意接入银行账户。

自动同步听起来很方便，但也意味着用户需要交出更多敏感信息。对于一个个人开发者产品来说，我不认为自己应该要求用户承担这种信任成本。

因此，ArkFlow 目前更接近一个由用户主动维护的私人资产卡包。

账户和资产数据保存在用户自己的设备中，并可以通过个人 iCloud 在设备之间同步。它不要求注册一个 ArkFlow 账户，也不需要提供网银账号，更不会读取银行流水。

用户可以使用 Face ID 保护 App，也可以在切换到后台时自动隐藏金额。数据还能通过本地备份导出，避免把恢复能力完全依赖于某一个在线服务。

这种选择当然有代价。

没有银行直连，余额不会凭空自动更新；没有完整流水，也无法提供特别复杂的消费分析。

但它让我能够清楚地回答一个问题：

作为开发者，我并不知道用户具体有多少钱。

对于一款管理财务信息的 App，我认为“不知道”反而是一种重要的产品能力。

资产一目了然

用 AI 一个月做出 App，真正困难的仍然不是写代码

ArkFlow 也是我第一次如此深入地使用 AI 辅助完成一个完整的 iOS 产品。

我主要使用 SwiftUI 开发，并让 Codex 和 Claude Code 参与代码编写、界面实现、问题排查和回归检查。

这套工作方式确实大幅缩短了从想法到上线的距离。

过去，一个复杂动画可能需要先阅读大量资料，再反复尝试不同实现；现在我可以先描述想要的效果，让 AI 给出基础方案，然后直接在真机上判断，再继续修改。

但实际做下来，我并不认为 AI 已经把独立开发变成了一件容易的事。

AI 很擅长实现一个明确的要求，却不擅长替产品做最终判断。

它可以帮我快速增加十个功能，却不会主动告诉我，其中八个可能根本不应该出现；它可以生成一套看起来完整的资产看板，却无法通过代码判断，用户真正喜欢的其实是那几张可以滑动的银行卡。

在制作卡片动画时，AI 可以给出弹簧参数和位移逻辑，但“这个动作看起来是否舒服”，仍然需要一遍遍在手机上操作。

我也遇到过不少典型问题：

代码表面上可以运行，但修改一个动画后破坏了另一个交互；不同功能分别完成，组合起来却出现状态冲突；AI 为了解决局部问题，引入了不必要的复杂结构。

后来，我开始把不同任务拆到独立的 Git 分支和 worktree 中，让不同模型分别负责实现、审查和回归，再由我决定是否合并。

AI 提供的是生产速度。

但产品方向、功能取舍、交互审美和发布责任，仍然需要开发者自己承担。

如果没有这些判断，更快的开发速度只会让产品更快地变得臃肿。

上线以后，我才开始真正理解这个产品

ArkFlow 上线后的第一个月，我几乎每天都在根据反馈修改产品。

一开始，我会认真向用户介绍资产分析、自由度目标和多币种管理。后来我发现，很多人只是看到一段卡片滑动的视频，便主动询问这是什么 App。

也有人下载后觉得它没有必要。

这其实很正常。对于账户很少、也不在意卡面的人来说，ArkFlow 很可能就是一个过度设计的账户列表。

但另一部分用户会花很长时间寻找银行卡卡面，调整卡片顺序，把已经停用的卡重新添加回来。他们关心的不只是账户余额，还会讨论一张卡应该使用哪个年份的设计、是否应该保留旧版卡面，以及卡片在屏幕里怎样排列才更好看。

这让我意识到，ArkFlow 可能没有必要成为一个覆盖所有财务场景的“大而全”产品。

市场上并不缺少专业记账软件、投资工具和资产管理平台。一个个人开发者也很难在每个领域都做到最好。

但我可以把一个很窄的问题做得更认真：

当一个人拥有很多账户时，能不能让管理它们这件事不再像整理表格，而更像整理自己的收藏？

这也是我现在更愿意继续探索的方向。

上线一个月后，这个小众需求比我想象中更真实

ArkFlow 于 2026 年 6 月 14 日上线，上线后的第 7 天累计获得约 1000 次下载。

截止当前，App 累计获得了约1700次下载，75笔付费，内购和订阅收入约为700美元。

某书发布的一个展示银行卡堆叠和滑动效果的视频，获得了超过80000次浏览，新建的APP社媒账号粉丝新增约700+。

这些数字和成熟产品相比并不算大，但对一个刚上线、由个人维护的独立 App 来说，已经超过了我最初的预期。

更重要的是，传播效果最好的内容并不是资产分析、自由度测算或者多币种管理，而是最直观的卡片滑动和卡面墙。

这也进一步验证了用户反馈：很多人最初并不是因为需要一套完整的资产系统而下载 ArkFlow，而是先被一张熟悉的银行卡、一个顺手的动画，或者“银行卡也可以被收藏”这个想法吸引。

他们进入产品后，才逐渐开始使用余额、额度、还款提醒和资产管理功能。

这些结果并不能说明 ArkFlow 已经找到了最终答案，但至少说明，这个看起来有些小众的需求，确实存在。

AI 降低了开发门槛，但并不意味着零成本

在开始开发后，我也专门统计了一下 ArkFlow 到目前为止产生的现金开销。

其中，Codex、Claude 等 AI 工具的订阅和调用费用两个月约为 900 美元；Apple Developer 会员约为 100 美元；域名、备案和服务器等支出约为 50 美元。合计大约 1050 美元。

这里没有计算我原本已经拥有的 Mac、iPhone 等设备，也没有计算自己的时间成本。部分 AI 订阅同时用于日常工作，因此这也不是一份特别严格的项目财务报表。

但它至少说明了一件事：AI 确实让一个人完成产品设计、开发和上架成为可能，却没有让开发变成一件免费的事。

更大的成本依然是时间。

过去两个月里，我大量的晚上和周末都用在功能设计、真机测试、审核修改、用户反馈和版本迭代上。AI 可以显著缩短写代码的时间，但代码完成以后，还有大量工作无法被自动完成。开玩笑的说，随着继续迭代，回本的预期只会越来越低，因为当前的收入模型是不足以支持每个月450美元的Codex和Claude的订阅费用的。

最后

制作 ArkFlow 之前，我认为自己是在解决一个资产管理问题。

制作一个月后，我发现它同时也是一个关于收藏、记忆和数字物品的问题。

银行卡正在逐渐变成手机里的数字凭证，实体卡的使用频率越来越低。但越是如此，那些曾经陪伴过我们的卡面，反而越容易从生活里消失。

我不知道未来大家是否还会保留这么多实体银行卡。

但至少现在，我希望可以给它们留下一面墙。

ArkFlow 目前已经在 App Store 上架，支持 iPhone 和 iPad，以及ARM版本的Mac和vision Pro。目前也覆盖了简体中文、繁体中文、英语、日语、韩语、德语等语言。

它还有很多不完整的地方。卡片交互仍然在继续调整，资产管理能力也需要慢慢补充。

如果你也拥有很多银行卡，或者曾经有一张已经不用、却舍不得删除的卡，我很想知道：

你会把它当成一个金融账户，还是一件属于自己人生的收藏品？

ArkFlow 长流 iOS下载体验链接

受不了B站的低画质，我决定把弹幕打包带走

Belcheck — Tue, 14 Jul 2026 16:17:18 GMT

弹幕大概是少数几种会让人留念 B 站的东西。

有些视频，我更愿意在原作者的 YouTube 频道或自己的高清媒体库里观看：画面更清楚，压缩更少，也可能保留了更完整的内容。但少了 B 站同一时间点飘过的一句吐槽，观看体验似乎也跟着少了一块。

有时候，真正让我笑出来的并不完全是视频本身，而是画面和弹幕共同完成的：某句似曾相识的台词、一个固定出场的道具，或者创作者刚挖完坑，观众已经提前在屏幕上报出了答案。

画面可以换一个地方看，这种共同观看的感觉却很难一起带走。

于是我做了「弹来弹去」：粘贴一个 B 站视频链接，它只获取弹幕，不下载、也不播放视频，再通过一层透明置顶窗口，把弹幕覆盖到 YouTube、Infuse、IINA、QuickTime 等播放器上。

现在它已经支持 macOS 和 Windows，并在 GitHub 开源。

画质和弹幕，为什么非要二选一？

从数据上看，视频和弹幕本来就是两套相对独立的内容。

视频负责画面与声音；弹幕只需要知道两件事：应该显示什么，以及应该在第几秒出现。既然如此，弹幕并不一定非得被锁在某个网页或某个播放器里。

只要在视频窗口上方放置一层透明、置顶的弹幕窗口，底下播放的是浏览器里的 YouTube、Infuse 中的个人媒体库，还是 IINA、QuickTime 里的本地文件，在窗口化播放场景里都没有本质区别。

我最初以为，这是一个应该早就被解决的问题。

后来搜索才发现，类似方案并非没有：弹弹play 在 Windows 上支持把弹幕覆盖到 PotPlayer、mpv、MPC 等指定播放器；Danmaku Anywhere 可以给网页视频加载弹幕；IINA 和 mpv 也有各自的弹幕插件。

但我的需求刚好落在这些方案之间：

不想为了看弹幕更换自己习惯的播放器；

不希望工具接管或重新播放视频；

既要覆盖浏览器，也要覆盖 Infuse、QuickTime 等原生应用；

既然现成方案没有完全落在这个交集里，我决定自己做一个。

一个只负责弹幕的 App

「弹来弹去」的使用流程只有四步：

粘贴 B 站视频链接，支持 BV、av、分 P 和 b23.tv 短链；

获取对应视频的弹幕；

打开透明弹幕层，并把它放到视频画面上方；

在任意播放器中打开对应的视频，完成一次时间同步。

它不读取视频内容，也不知道弹幕窗口下面正在播放什么。你可以用 Infuse 播放自己的媒体库，在 IINA 里打开本地文件，也可以直接在浏览器里观看 YouTube。只要两边是内容和时间轴大致对应的同一段视频，就能把它们组合起来。

这种设计的好处是通用：我不需要为每个播放器分别实现一套视频加载逻辑，更不会碰到画质、字幕、HDR、音轨、网盘协议或播放权限等问题。

它只做弹幕，其余事情继续交给用户已经选择好的播放器。

但这种通用性也带来了整个项目最麻烦的问题。

它怎么知道视频播放到哪里了？

答案是：它不知道。

因为「弹来弹去」不读取下方播放器的状态，所以无法自动知道视频正在播放、暂停，或者已经快进到了第几秒。

最理想的体验当然是自动同步：播放器暂停，弹幕也暂停；播放器跳转，弹幕跟着跳转；播放速度改变，两条时间轴始终保持一致。

但如果要实现这种体验，就需要分别适配浏览器、Infuse、IINA、QuickTime 以及其他播放器。有些可以通过脚本或辅助功能获取状态，有些只能间接猜测，还有些系统级全屏场景根本不允许外部窗口覆盖。

对于一个只为了解决个人观看需求的小工具来说，这很容易变成一项永远做不完的工程。

我最后选择了一个更朴素的办法：让弹幕使用自己的时间轴，再通过一次手动操作和视频完成同步。

加载弹幕后，点击「5 秒后从 0 同步」，弹幕层中央会出现倒计时。我只需要把鼠标放到播放器的播放按钮上，在倒计时归零时开始播放视频即可，这一个设计可以让用户在使用时不用受忙脚乱地去对齐进度。

如果两边相差一点，还可以使用 ±1 秒、±5 秒按钮或直接输入精确偏移进行微调。在我自己的使用中，只要两个版本没有明显的片头或剪辑差异，通常十秒左右就能对齐。

完成同步后，App 会保存这个视频的播放位置和时间偏移。下次从历史记录打开时，可以直接从上次的位置继续，不需要重新从头校准。

它没有自动同步那么优雅，但足够简单，也足够可靠。

当然，这个方案也有明确边界：如果两个版本的片头不同，可以用偏移解决；如果中间存在删减或重新剪辑，后半段仍可能再次错位。通用性并不是免费的，它只是把“适配每个播放器”的复杂度，换成了用户偶尔进行一次手动校准。

真正好用的工具，应该尽量“消失”

弹幕层位于播放器上方，但平时不应该妨碍播放器操作。

因此我加入了「鼠标穿透」：开启后，点击、拖动进度条、切换全屏等操作都会直接落到下面的播放器上；需要调整弹幕层的位置和尺寸时，再暂时关闭穿透，窗口边缘会出现提示边框，可以直接拖动和缩放。

主窗口也被压缩成两个主要步骤：第一页选择弹幕来源，可以粘贴链接或从历史记录继续观看；第二页只保留播放、暂停、进度、同步和微调。倍速、清屏、鼠标穿透和导入导出等低频操作，都收进二级菜单。

观影时，我通常不会再切回主窗口，而是使用全局快捷键控制弹幕：

播放或暂停弹幕；

前后微调 1 秒或 5 秒；

从当前时刻重新同步；

显示或隐藏弹幕层。

这看起来只是一些很小的功能，却直接决定了一个 App 是只能演示一次，还是愿意在下次看视频时重新打开。

从“能运行”到“愿意一直用”

最早的版本只完成了四件事：解析链接、获取弹幕、渲染弹幕，以及让弹幕开始或暂停。

剩下的功能，几乎都来自实际使用中的不满。

拖动进度条时，时间数字没有同步变化；点击播放后，按钮图标没有变成暂停；主窗口信息太多；开启鼠标穿透后，很难再把控制窗口找回来；长时间观看后，两边的时间轴可能产生轻微偏差。

这些问题单独看都不严重，但它们决定了一个“能运行的 Demo”能否变成真正愿意反复打开的工具。

因此，我补上了播放状态、历史记录、进度保存、全局快捷键、偏移微调、窗口位置记忆、显示区域、密度控制和过滤功能。时间轴与窗口状态也做了自动测试，避免修复一个问题时又破坏另一个使用场景。

工具类产品最容易忽略的，往往不是核心功能，而是核心功能前后的十几个小动作。

macOS 的 Liquid Glass，以及后来的 Windows 版

macOS 版采用原生 AppKit 开发，并使用了 macOS 26 Tahoe 的 Liquid Glass 界面。主控制窗口使用玻璃材质卡片和按钮，深色模式下则选择了偏粉色的强调色，希望它看起来像一个系统工具，而不是套着网页外壳的播放器。

使用新系统 API 的代价也很直接：目前 macOS 版要求 macOS 26 或更高版本。为了兼容更旧的系统重新实现整套界面，会让这个个人项目多出不少维护成本，因此第一阶段我选择先把体验做好。

后来我又做了 Windows 10/11 x64 原生版本。它采用 .NET 8 和 WPF，同样包含透明置顶弹幕层、鼠标穿透、分 P、时间轴同步、过滤、历史记录和全局快捷键。安装包是自包含版本，用户不需要额外安装 .NET Runtime。

两个版本没有追求界面上的完全一致，但核心工作方式相同：视频由原来的播放器负责，弹幕由一层独立窗口负责。

弹幕也可以不挡住画面

一位朋友试用后，向我提到了另一个起初没有想到的使用场景。

看经典电影，或者摄影、作画特别出色的动画时，人会更想好好欣赏完整的构图、光影和细节。弹幕依然有趣，但让文字从人物面前和精心设计的画面上不断飘过，有时也会破坏观看体验。

在站内播放器里，弹幕终究与视频共用同一块画面。即使可以调整透明度和显示区域，想在关键镜头完全不受遮挡，往往还是需要手动打开和关闭弹幕。

但「弹来弹去」的弹幕层本身就是一个可以自由移动、缩放的独立窗口，你想调整成任何比例，放在任何位置都可以，因此弹幕并不一定要盖在视频上。

只有一块屏幕时，可以把视频窗口放在屏幕上半部分，把弹幕层放在下半部分：上面只保留完整画面，下面继续显示观众在同一时间点留下的反应，两边互不遮挡。

如果有两块显示器，还可以把视频放在主屏，把弹幕层单独放到副屏。主屏用来专心看电影，副屏则像一条与影片同步的观众席——想看时转一下视线，不想看时也不会干扰画面。

这也是独立窗口带来的另一个价值：它不只是把 B 站弹幕带到其他播放器，也让画面和弹幕可以在空间上彼此分离。弹幕既可以覆盖在视频上，也可以退到画面之外，成为一条独立的观看层。

像播客类的节目，本身画面就不重要，你甚至可以一边开着弹幕一边查阅其他资料，比如这样：

下载、限制与边界

「弹来弹去」目前已经在 GitHub 开源，采用 GPL-3.0 许可证：

查看源代码与完整使用说明

目前有几项限制需要提前说明：

macOS 版要求 macOS 26 Tahoe 或更高版本；Windows 版支持 Windows 10/11 x64；

工具仅使用无需登录即可访问的公开接口，不携带 Cookie，因此获取到的是当前公开弹幕池，不一定包含全部历史弹幕；

当前支持 BV、av、分 P 和 b23.tv 短链，暂不支持番剧 ep/ss 链接与互动视频；

工具不下载视频，也不会绕过视频平台的播放权限；

独立弹幕层在系统原生独占全屏下可能无法显示，可改用窗口最大化，或导出 ASS 字幕作为兜底；

视频版本存在中途删减或重新剪辑时，弹幕可能需要再次校准。

这是一个独立第三方开源工具，与哔哩哔哩没有关联、授权或合作关系。弹幕内容的权利归原发送用户及平台所有，请仅用于个人观看辅助，不要用于批量抓取或商业用途。

还想继续做什么

现在的版本已经解决了我最初的问题：在 Infuse 中播放自己的高清媒体库，或者在 YouTube 上观看创作者发布的版本时，仍然能够保留 B 站弹幕。

但还有一些方向值得继续尝试。

比如把弹幕密度显示成时间轴热力图。弹幕数量往往能反映视频的情绪高点，即使不读取具体内容，也可以提前知道接下来哪里可能发生有趣的事情。

我也考虑过制作一个浏览器扩展，用来读取 YouTube 等网页播放器的当前进度，再与桌面 App 通过本地连接自动同步。它会让网页观看体验更加完整，不过也意味着需要针对不同网站持续适配。

至少在现在，我仍然更愿意先保持这个工具的简单：

视频归播放器管，弹幕归「弹来弹去」管。

我们早已习惯把视频、字幕和音轨自由组合。也许弹幕同样不应该永远被锁在某一个网站里。

有些视频值得用最好的画质观看，而有些梗，确实需要大家一起笑才完整。

“移动的奢华：索尼VGN-TZ”乔布斯眼中MacBook Air面世前最好的轻薄本

随便好啦 — Tue, 14 Jul 2026 13:59:36 GMT

2007年，索尼发布了全新的VAIO T系列笔记本：VGN-TZ series。正逢索尼初代笔记本505系列发布10周年，TZ系列被官方定义为“移动的奢华”，505系列笔记本设计理念的继承者。

要弄清楚TZ系列的由来，就必定要提起两个关键系列：PCG-505和PCG-TR。

VAIO PCG-505：索尼发布于1997年11月的轻薄笔记本，机身采用了亮眼的金属和紫色，打破了那个年代人们对于笔记本呆板的印象，也为后来的505系列家族以及索尼Z、T、S系列的笔记本打下了基础。

PCG-TR：索尼T系列的首款机器，发布于2003年，搭载了极其便携的10.6英寸屏幕，搭配CD光驱，整机重量只有1.41千克。而T系列所使用的设计语言很多都是从当年的505系列上延续下来的。

回到2007年，索尼看着发布于2005年的第二代T系列“TX”搭载的老奔腾处理器平台，以及被部分消费者认为设计缺乏新意的外观，决定研发TX系列的下一代产品。

但中途出现了一个插曲。几乎同一时间，苹果对外宣称要打造出世界上最薄的笔记本产品（也就是后来2008年发布的MacBook Air）。坊间一直有说法，索尼听到这个消息，立刻加快下一代T系列轻薄本的研发，绝不能让“最薄笔记本”的称号被苹果夺去。

于是2007年6月，号称最轻薄笔记本、索尼笔记本10周年纪念之作的VAIO VGN-TZ系列诞生了。

碰巧，我最近也在机缘巧合下收到了一款当年国内发行的VGN-TZ121。就让我们一起回到2007年，看看这台笔记本到底有何惊艳之处？

首先是外观：一眼看过去棱角分明，尤其是转轴部分的圆形电池十分亮眼。机器采用镁铝合金和碳纤维，整机重量被压缩在1.2kg左右。这个设计语言和TZ的前代TX完全不同，TX更偏向圆润，其设计语言被索尼认为“T系列是为女性用户打造的”。

而到了TZ系列，索尼沿用了发布于2004年的X505同款设计语言。在索尼官方的采访中是这样说的：“TZ系列延续了X505的外观和独特的圆形转轴电池。”

那X505是什么？这台发布于2004年的机器是索尼的另一个设计巅峰：一台可以正常运行Windows的笔记本，整机重量被压缩在900g以内，最薄处仅9.7毫米。而X505正是505系列的最终之作。时隔三年，索尼在TZ系列上又将当年505的设计理念和精神重新带了回来。

说完外观，再看看内在：TZ发布时正值英特尔平台换代的关键时期：原先的老奔腾处理器平台，被最新的酷睿2双核甩开了几个世代。

索尼TZ系列搭载的就是英特尔酷睿2超低电压CPU：U7500/U7600，配合100~200GB可选的1.8英寸微型机械硬盘，当年的高配版本还可选SSD固态。最惊艳的还是那块11.1英寸的LED屏幕，色彩还原度高达72%，放在当年属于第一梯队。

机身材质也特别讲究：镁铝合金配合碳纤维，既保证了轻薄，又比普通塑料更牢固。配色方面，除了常规的黑灰，还新增了亮眼的玛瑙红。

作为索尼笔记本10周年的纪念产品，索尼对TZ十分上心。发布之后，陆续推出了限定款的精英黑套装组、玛瑙红套装组。但最让人眼前一亮的还是在日本本土发售的“VAIO T Note 505”：以TZ为基础，外观配色直接复刻了当年的505系列，全球限量505台，配置顶配，售价高达2万元人民币。

然而，看似风光的机器下也藏着巨大的危机。

2008年1月，苹果发布会上，乔布斯当着众人的面从一个信封纸袋里抽出了一台MacBook Air，全场哗然。而在介绍MacBook Air的过程中，始终有一个挥之不去的影子：索尼TZ系列。

乔布斯先是承认，在MacBook Air出现之前，市面上薄且设计好的笔记本，他认为是索尼的TZ系列。但也指出了TZ的一系列问题：不够薄、键盘尺寸局促、11.1英寸屏幕太小等。

而与之对比的MacBook Air，用13.3英寸的屏幕和仅1.3kg的重量，给2007年发布的索尼TZ带来了巨大的市场冲击。乔布斯更是说出了一句现在看来都十分戏剧性的话：

“MacBook Air最厚的地方仅有19.5mm，比索尼TZ系列最薄的地方22.5mm还要薄！”

于是，MacBook Air发布之后，全世界主流舆论都将“最薄笔记本”的称号给了MacBook Air。而仅仅一年前发布的索尼TZ，带着它的复古设计和严重的设计问题，逐渐被遗忘。

同年9月，索尼公开宣布：由于机器内部设计原因，TZ系列的屏幕排线可能因笔记本反复开合而导致磨损、老化、短路，甚至发烫、自燃等情况。全球已报道15起机器异常发热事件，其中1起导致用户轻微烫伤。

索尼给出的解决办法是召回或免费检查维修。这是索尼历史上一次严重的品牌信任危机，也加速了TZ系列销售周期：在市场上活跃了约一年半时间。

时间回到现在，回过头来看看我手上这台TZ121，我记得当年国内入门款TZ121的发售价约1.3万元。

配置：英特尔酷睿2双核U7500，1GB DDR2内存（TZ1/TZ2系列最高只支持2GB，后期TZ3系列部分型号支持4GB），160GB 1.8英寸微型低转速机械硬盘。

碰巧2007年发布时，TZ撞上了微软史上争议最大、硬件要求最高的操作系统之一：Windows Vista。Vista对硬件要求极其苛刻，哪怕是售价过万的索尼TZ，运行Vista Business或家庭高级版，也只能勉强满足基础办公。

我装回索尼的原厂Vista OEM系统实测发现，卡顿的原因除了平庸的性能和难用的Vista系统，更关键的是索尼自家的“全家桶”：我这台机器的原厂系统预装了超过30款索尼自家应用：索尼控制、索尼电池省电、索尼升级、索尼视频编辑……这种预装大量软件的做法，让本就不堪重负的笔记本变得更加卡顿。

调查一番后我发现，日系厂商喜欢给笔记本预装大量软件是老传统。究其原因，是因为在日本本土，人们买回笔记本的第一件事就是开机使用，不希望折腾。厂商因此针对Windows推出了更多定制化应用，并将其作为笔记本增值的一部分。不得不说，这怎么也算是一种“时代的眼泪”了。

最后，让我们再看看这台搭载Windows Vista Business的索尼TZ121尊贵黑。个人认为，它是索尼的设计集大成者。不论是那块11.1英寸的屏幕，还是小巧轻便的机身，亦或是对X505机器的复刻致敬，都为它增加了一层历史的印记。

文案：随便好啦

配图：随便好啦

参考资料：
· 索尼中国官网，2007年VAIO TZ系列发布会新闻稿（“移动的奢华”定义）
· 中关村在线，索尼VGN-TZ13产品参数页（CPU、重量、尺寸等配置）
· 中关村在线，TZ系列新品发布报道（72% NTSC屏幕、碳纤维材质、键盘设计）
· PChome，索尼世界第一薄X505测试报告（9.7mm最薄处、圆形电池设计）
· 百度百科，VAIO-X505词条（785g重量、X505设计理念）
· TechWeb，MacBook Air 10周年回顾（乔布斯信封取Air、与TZ对比厚度）
· 中国新闻网，索尼召回44万台VAIO TZ笔记本报道（全球44万台、7起烫伤）
· 中国新闻网，索尼大规模召回VAIO TZ系列报道（美国15起投诉、1起轻微烫伤）

你的Windows桌面再也不乱了，我开源了一个WinUI原生风格的桌面整理工具-DeskBox

大雨实验室 — Tue, 14 Jul 2026 07:56:59 GMT

关联声明：DeskBox 是我‌使用AI Vibe Coding独立开发的项目，目前在Github免费开源，本文不含付费推广，本文部分内容使用了AI 进行辅助创作。

这是我第一次在少数派写文章，想先聊一个大多数人每天都会面对的问题：Windows 桌面为什么总是很容易变乱？

截图、压缩包、微信接收的文件、临时导出的表格、过几天还要处理的资料，全都很自然地落到桌面上。刚开始只有几个，后来慢慢铺满整个屏幕。偶尔整理一次，通常也只是把它们塞进一个叫作“新建文件夹”的地方。

这不完全是因为懒。

桌面本来就是电脑上最顺手的临时空间，但 Windows 给它的组织方式一直比较单一：文件、文件夹，以及摆放位置。我们可以把文件放进文件夹，却很难在不离开桌面的情况下，看清文件夹里有什么，也很难同时保留“随手放”和“有秩序”这两件事。

我试过把桌面彻底清空，也试过启动器、快捷方式和一些桌面美化工具。它们各有用处，但我真正想要的并不是另一个启动器，也不是把桌面替换成一套全新的工作台。

我只是想给原来的 Windows 桌面，多加一层简单的整理能力。

所以我做了 DeskBox。

它简洁，轻量，克制，免费开源，且完全遵循windows设计规范，能完美与windows的设置，个性化联动。包括明暗模式，主题色，材质，圆角组件等。

格子不是桌面上的装饰

DeskBox 最基础的东西，是一个个可以独立摆放和调整大小的文件格子。

其中一种叫“收纳格子”。它背后对应一个真实文件夹，把文件拖进去，就会移动到对应目录。你在资源管理器里仍然能看到这些文件，也可以正常复制、重命名、删除和打开。DeskBox 不会把文件塞进自己的数据库，更不会把它们变成只有软件自己认识的格式。

另一种是“文件夹映射”。如果已经有整理好的项目目录、下载目录或素材文件夹，可以直接把它映射成格子。它只提供桌面上的查看和操作入口，不改变原文件的位置。

这两种方式看起来很像，解决的却是不同的问题。

收纳格子适合接住桌面上不断出现的临时文件；文件夹映射适合把经常打开的目录带到桌面上。一个负责“把东西放进去”，一个负责“让我随时看得到”。

我很在意这一点，因为文件整理工具最不应该做的事情，就是把用户的文件困在工具里。

哪天不想用 DeskBox 了，文件依然是原来的文件，文件夹也依然是原来的文件夹。

当然，如果你是第一次使用，也不用担心，DeskBox里面有完整的新手指导，几步就能理解并快速上手。

桌面上需要的，不只是文件

真正使用一段时间后，我发现桌面上让人分心的并不只有文件。

有时是一件今天必须完成的小事，有时是一段稍后还要复制的文字，有时只是想看一眼天气，或者切到下一首歌。

如果每次都要打开一个完整应用，处理成本反而有点高。所以 DeskBox 后来增加了待办、随记、天气和音乐几类功能格子。

但我并不想把它们做成对应专业软件的缩小版。

待办不是另一个复杂的项目管理系统。它适合快速记下一件事，在桌面上看见它，需要时再进入详情设置截止日期、提醒和重复。

随记也不是知识库。它更像一张临时放在桌面上的纸，可以写文字、放图片、固定常用内容，再用不同纸张稍微区分一下用途。

音乐格子只连接 Windows 的系统媒体会话，用来显示封面、歌名和常用播放控制；天气格子则根据尺寸自动改变信息密度，小尺寸看当前天气，拉大后再展示逐小时和多日预报。

这些格子的共同点是，它们都应该在需要时离手边很近，不需要时又足够安静。

不一直置顶，也不彻底消失

桌面格子有一个很麻烦的问题：窗口层级。

如果始终置顶，它们会挡住浏览器、文档和聊天窗口；如果固定在桌面底层，真正需要的时候，又得先最小化一堆窗口才能找到。

DeskBox 默认采用动态层级。通过托盘或快捷键唤起时，所有格子会回到前台；之后不再强行霸占最上层，而是把窗口关系重新交给 Windows 管理。

你点击其他应用，其他应用就会自然盖在格子上面；再次点击某个格子，它只会回到当前窗口之前。点击格子标题时，则可以一次唤起全部格子。

这套逻辑听起来不算复杂，实际却花了我很长时间。多显示器、Win+D、快捷键、托盘、全屏窗口和不同的点击顺序，都会改变最终结果。

它也是桌面工具和普通应用很不一样的地方：很多体验没有一个可以直接套用的标准答案，只能真的把它放在桌面上，每天去用。

我喜欢那些不太显眼的反馈

DeskBox 基于 WinUI 3 和 Windows App SDK 开发。我会优先使用 Windows 原生组件、系统材质和窗口能力，只有原生方案无法满足时，才自己绘制。

我不希望它看起来像一个盖在 Windows 上面的网页，也不希望每个操作都配上很夸张的动画。

比如调整格子大小时，边缘靠近其他格子或屏幕边界，会出现辅助参考线。参考线有一点很轻的呼吸效果，不是为了炫技，而是让对齐这件事更容易被感知。

文件拖到格子上方时也会有反馈，但我特意把它做得很弱。它只需要告诉你“这里可以放”，不应该一直抢注意力。

我比较喜欢这种设计：功能确实存在，但平时不大声提醒你它的存在。

做得更多，不一定更好用

独立做产品很容易陷入一个节奏：有人提了一个想法，就想赶紧做上去；看到别的软件有一个功能，也会担心自己是不是缺了什么。

我前一段时间就有点着急。

结果是功能增长得很快，但有些地方只是“先做出来了”。之前的待办和随记就是这样，入口很多，信息层级却不够清楚，视觉和交互也没有真正整理好。说实话，那时候连我自己都不太想用。

后来我停下来，把这两个格子从布局、字号、间距、选中状态，到详情编辑、拖动排序和批量操作重新梳理了一遍。

这个过程让我重新确认了一件事：只有我自己长期使用起来舒服的东西，才适合交给其他人。

用户反馈当然重要，但把每条反馈都立即变成功能，不一定是在尊重用户。产品需要有边界，也需要克制。有些建议我会尽量实现，有些和整体方向确实冲突的，只能抱歉地放下。

我希望 DeskBox 最后是一个简单、好用的工具，而不是一个什么都能做、但每件事都做得不够舒服的工具。

轻量不是少几个按钮

一个长期放在桌面上的应用，性能本身就是功能。

早期把所有功能格子打开后，我的电脑上内存占用大约在 140MB。音乐格子还出现过连续播放和切歌后，内存不断增长的问题。反复切换语言、明暗模式、材质和透明度，也会留下没有及时释放的资源。

后面我重新整理了窗口生命周期、定时器、图片解码、图标缓存、主题刷新和事件订阅。现在在相同的日常测试环境里，所有功能格子同时打开，内存基本稳定在 50MB 左右。

不同电脑、不同图片和文件数量下的结果肯定不完全一样，但我的目标很明确：当用户没有操作 DeskBox 时，它应该知道安静下来。

轻量不等于界面简陋，也不等于少用新的系统能力。它更应该意味着，不做无意义的持续刷新，不留下不再使用的资源，也不为了一个小效果引入很重的东西。

它适合谁，也不适合谁

DeskBox 目前主要面向 Windows 11，我也把 Windows 11 作为主要测试环境。

它比较适合习惯把临时文件放在桌面、希望常用文件夹随手可见，或者想在桌面保留轻量待办和随记的人。

它不适合需要云同步、多人协作、复杂项目管理或完整知识库的用户。待办、随记、天气和音乐都刻意保留了边界，它们不会替代专业应用。

另外需要特别说明：把文件拖入“收纳格子”时，文件会真实移动到对应收纳目录；如果只想查看现有目录而不改变位置，应该使用“文件夹映射”。

DeskBox 仍然是一个由我独立维护的早期产品，不同显示器、系统缩放和桌面习惯下，也可能还有我没有覆盖到的问题。

写在最后

Windows 给了我们一张桌面，却没有真正教我们怎样整理它。

我做 DeskBox，不是想替换桌面，也不是想重新发明一套文件系统。我只是希望在已经用了很多年的 Windows 桌面上，补一点秩序。

文件有地方放，临时内容有地方记，待办能看见，天气和音乐可以顺手处理。需要的时候把格子叫出来，处理完之后，再把注意力交还给正在做的事情。

一点点就够了。

DeskBox 已经开源，GitHub 提供免费安装包。无广告免费使用。

GitHub：https://github.com/Tianyu199509/DeskBox

官网：https://deskbox.fun/

鸿蒙应用 Segment，让所见即所得

能不忆江南 — Tue, 14 Jul 2026 01:52:32 GMT

很多时候，打断写作灵感的，从来不是思路卡顿，而是繁琐的工具操作。

现有 Markdown 编辑器，要么需要反复切换源码与预览界面，割裂写作节奏；要么堆砌繁杂配置，把简单的记录变成复杂的操作，让专注一次次被消耗。

而 Segment，重新定义 HarmonyOS 原生写作体验。

它不是生硬的左右分栏预览工具，而是专为 HarmonyOS 生态打磨的所见即所得专业 Markdown 写作应用。所见即所得的体验，让你只关心文字本身，应用支持运行在手机 / 平板 / PC / 2in1。

多级标题、有序/无序列表、引用段落、数据表格、代码块、图片、数学公式等所有内容，编辑即刻成型，全程呈现接近最终成品的精致排版效果。

你依然拥有标准、可迁移、通用的 Markdown 纯净文档，无需反复核对语法、切换窗口，不用被繁杂符号干扰，只需要专注文字本身，让写作回归纯粹。

一张干净的全场景写作桌面，适配你的所有记录需求

无论是严谨的技术文档、详细的产品方案、高效的会议记录，还是日常的学习笔记、读书摘录、灵感草稿，亦或是博客初稿、结构化工作文档，Segment 都能完美适配。

全维度 Markdown 能力全覆盖：支持多级标题、各类列表、任务待办、引用、表格、代码块、图片嵌入、数学公式、Mermaid 流程图、脚注、超链接等主流功能，编辑稳定流畅，文档安全留存。

同时搭载全方位实用办公能力：本地草稿留存、多工作区分类管理、实时自动保存、侧边栏索引导航、全文关键词检索，支持 Markdown、HTML、PDF、DOCX、图片等多格式一键导出，满足办公、学习、创作、归档全场景需求。

浮思同撰，让文字同频：在同一局域网内，通过同撰链接，用电脑、平板或其他设备继续编辑当前 Markdown 文档，内容会同步回应用。

应用接续，让写作不被设备打断：Segment 支持HarmonyOS 系统级应用接续能力，让写作状态可以在不同 HarmonyOS 设备之间自然流转。你可以在手机上快速记录灵感，在平板或 PC 上继续整理成文；也可以从一台设备切换到另一台设备，延续当前正在编辑的文档和写作进度。

跨端切换时，无需重新查找文件、打开页面或回忆刚才写到哪里。Segment 会帮助你把当前写作现场带到新设备上，让思路不断线，写作更连贯。

看了这么多，即使你不了解 Markdown 语法，也能快速上手，只需“ / ”一下，多样语法随性选择。

写在最后：少一点工具，多一点写作

Segment 始终坚持极简纯粹的产品理念，持续迭代优化、打磨细节。我们想做的，从来不止是一款简单的 Markdown 编辑器，而是适配 HarmonyOS 生态的专业创作工具，让每一次记录都轻松、高效、纯粹。

因为总在静音下错过飞书会议，我用 iOS 26 的 AlarmKit 做了个「会议闹钟」

apple_byte — Sun, 12 Jul 2026 23:06:27 GMT

我是这个 App 的开发者本人，这篇是开发手记，不是测评。文末有链接，但你完全可以只当个 iOS 26 新特性的介绍来看。

一个每天都在发生的尴尬

我平时飞书会议很多。工作的时候，手机通知基本是常年静默的——不然一天几十条消息，根本没法专心。

结果就是这个场景反复上演：会议已经开始了，我电脑上「啪」地弹出一个飞书入会邀请，我才猛地反应过来——又忘了有个会。日历里明明写着，手机上大概也弹过横幅，但在静音 + 专注模式下，那条提醒就像没存在过一样，一闪而过，我根本没感觉。

错过一次内部同步还好，错过一次和客户、和老板的会，那种手忙脚乱地道歉、补救的滋味，相信不少人懂。

我最初的吐槽：为什么不能只给「会议」开小灶？

我第一反应是去翻设置：能不能让会议提醒穿透静音？

答案是不能。这不是我设置没调对，而是通知机制本身的限制：

日历的横幅提醒，天生就会被静音和专注模式压制。它的定位就是「不打扰」，所以它「不会强制打断你」——这恰恰和我想要的相反。
系统时钟的闹钟倒是能穿透静音，但它是「手动、死板」的：我得为每个会手动设一个闹钟，会议改时间了它也不知道，纯体力活，没人会真这么用。

我想要的其实很简单：一个认识我日历、会自动跟着会议走、而且到点必须响的闹钟。 介于「太弱的日历提醒」和「太笨的手动闹钟」之间，偏偏系统没有。

转机：iOS 26 的 AlarmKit

然后我发现了 iOS 26 新出的 AlarmKit。

简单说，这是苹果第一次把「系统级闹钟」的能力开放给第三方 App。在这之前，能穿透静音、全屏响铃、在锁屏和灵动岛上常驻的闹钟，只有系统自带的「时钟」能做。AlarmKit 之后，第三方 App 终于也能调用同一套能力——响铃时穿透静音和专注模式、全屏显示、锁屏和灵动岛都能展示。

看到这个我就想：这不正好是我缺的那块拼图吗？把「日历会自动跟」和「闹钟会穿透静音」这两件事拼起来，我那个尴尬场景不就解决了。

于是我就自己动手试了试，本来只想给自己用。

我做了个什么东西

思路其实一句话：只读我的日历 → 把里面的会议自动排成 AlarmKit 真闹钟 → 到点穿透静音响 → 响的时候一键进会。

它不编辑日历、不记事、不做待办，就干这一件事：别让我错过会。

做的过程中，有几个我印象比较深的取舍，也顺带说说，免得这篇看着像广告：

AlarmKit 的响铃界面只有一个「副按钮」槽位。 我一度想在响铃时既能「加入会议」又能「稍后提醒」，但系统只给一个位置，只能二选一。我最后选了「加入会议」——对会议场景来说，一键进会比 snooze 重要得多。
我坚持不做后端、不做账号。 你的日历数据全程只在手机本地处理，不上传任何服务器。代价是「App 完全没打开时日历改了」这种情况没法实时跟（这是纯本地方案的天花板，我在 App 里用「上次同步时间」老实标出来，而不是假装数据永远是新的）。
沿着「别错过」这个核心，自然长出来几个我自己天天用的功能：一键入会认得飞书、腾讯会议、钉钉、Zoom、Google Meet、Teams、Webex 等；线下会议会按实时通勤时间帮我算「该出发了」再响，而不是傻乎乎按开会时间提醒；灵动岛和锁屏有会议倒计时；还有两段式提醒（先软提醒准备、临开始再硬闹钟）。

用了一阵，我决定把它发出来

自己用了一段时间，确实没再犯过「电脑弹窗才想起有会」的错，我就顺手把它上架了，取名 MeetAlarm（会议闹钟）。

老实交代它的边界：免费版能连 1 个日历，日常够用；多日历和一些高级规则是 Pro。它要 iOS 26 以上（因为 AlarmKit 是 26 才有的）。它是个很聚焦的小工具，不会帮你管理日程，只负责一件事——到点，穿透静音，把你摁在会议上。

如果你也像我一样，手机常年静音、又不想再对着电脑上突然弹出的入会邀请心里一沉，可以试试。

App Store 搜「会议闹钟 MeetAlarm」或点这里下载：https://apps.apple.com/cn/app/%E4%BC%9A%E8%AE%AE%E9%97%B9%E9%92%9F/id6779464521

（再说明一次，我是开发者本人，这篇是自荐，欢迎拍砖。）

App+1｜从纸书到 Obsidian：用 Inkive 构建实体阅读的第二大脑

jiyee — Sun, 12 Jul 2026 14:31:14 GMT

我一直喜欢读纸书，也习惯在书上划线、圈重点、写批注。但一本书读完之后，这些认真留下的痕迹往往也就停在了纸页里。微信读书、Apple Books、Reeden 这类阅读软件可以很轻松地把划线笔记导入 Obsidian 或 Notion，而纸上的笔墨，却难以无缝连接数字笔记。

作为一个 Obsidian 爱好者，我一直在找一款能补上这一环的应用：拍下书页，它就能识别我划过线、高亮过或圈画过的文字。iOS 自带的 Live Text 识别印刷文本已经很准，但它不知道我具体划了哪里，一两页还能手动整理，真要认真处理一本书就不现实了。我也试过 Highlighted、白描、vFlat Scan、ShelfMe 等应用，它们各有特点，却都没有解决我最在意的问题。

App Store 调研

大模型开始普及之后，我又尝试把书页照片丢给豆包、DeepSeek、ChatGPT、Gemini，试了一轮，发现结果时好时坏：有时漏掉划线，有时又把没划的内容一起摘出来。

不同大模型识别结果对比

试了一圈之后，我还是有点不甘心。这个需求并不难解释，我只想拍下书页，然后拿到自己划过的那几句话。既然找不到合适的工具，我决定自己做一个试试。

我给它起名叫 Inkive，读作 /ˈɪŋkɪv/。

一张书页照片，怎样变成划线笔记

Inkive 要回答的问题是：读者划线时，真正想留下来的内容是什么？ Inkive 要完成三步：先找到书页上的划线，再读出划线附近的文字，最后根据划线和文字判断读者想留下哪句话。

第一步，是找到书页上的划线。

一张书页照片里，可能同时有下划线、马克笔高亮、圈画，也可能有纸张纹理、阴影、背面透过来的字迹。要让应用先看见这些标记，通常需要训练一个图像分割模型。简单说，就是让模型从整张照片里把「读者留下的痕迹」单独分出来。

我没有算法背景，但之前体验「寻隐」时，发现 Core ML 已经可以在手机本地运行相当复杂的模型。于是我决定试试：能不能用它识别书页上的划线。

模型训练对我来说完全是陌生领域，我借助 AI 把整个过程一步步跑通：准备数据、完成标注和训练，再判断结果有没有变好。我的标注数据大多来自读书博主分享的照片——纸张材质、光线、拍摄角度、划线习惯各不相同，一度塞满了我的手机相册。

标注数据集

在完成标注之后，我开始一轮轮训练模型。每一轮结束后，我都会让 AI 帮我看准确率、召回率和损失值这些指标和趋势，也会逐个检查失败样本：是浅色高亮漏掉了，还是把背面透出来的划线误识别成了正面标记。我会根据这些失败样本判断下一批该补什么数据、训练参数又该怎么调。

最终，这个本地模型在测试集上的准确率达到 0.94，召回率达到 0.88。它还不完美，但已经足以证明：在手机上识别书页划线，这条路可以走通。

第二步，是读取划线附近的文字。

找到划线之后，Inkive 还要读出它附近的文字。OCR，也就是图片文字识别，已经相当成熟。iOS 系统 Vision 框架在识别印刷文本时表现不错，但纸书照片比截图和扫描件更复杂：书页会弯，照片会歪，光线会不均匀，单双页一起拍时版面也更复杂。中文纸书的密集文字和复杂版面又增加了识别难度。

我一开始把很多精力花在透视校正上。照片歪了、书页弯了，直觉上当然会想先把页面拉平。我尝试过传统文档处理方法，也接入过不同的 dewarp 算法，但效果始终不够理想，不如 vFlat Scan。为此纠结了很久。

后来我发现，自己其实搞错了目标。Inkive 不是文档扫描应用，不需要生成一张完美的书页照片。重要的是处理之后，划线附近的文字能不能被准确读出来。我还走过不少弯路，比如识别文字行的中线、拟合下划线的像素轨迹。这些传统 CV 尝试花了不少时间，也帮我排除了几条不适合 Inkive 的技术路线。

直到 6 月看到 PPOCR v6 发布，我发现它对中文纸书照片的识别比系统 Vision 框架更稳定。原本我已经准备了云端 OCR 预案：如果本地识别效果不够好，就把图片上传到服务器，用云端模型识别。PPOCR 让我可以继续坚持本地处理，把书页照片、划线结果和识别过程都留在设备上。

PPOCR 让我可以继续采用本地处理，这对 Inkive 很重要：书页照片、划线结果和 OCR 过程都留在设备上。用户不用上传照片，我也不必为每次识别支付云端费用。

第三步，是判断读者真正想留下哪句话。

这一步直接决定了最终结果是否可用。前面的划线识别和文字识别，都有相对明确的模型可以依赖；但一条划线到底对应哪句话，模型最终还得推测读者当时想留下什么。人在纸书上划线时，并不会像机器标注一样精确。可能多划了一个字，少划了半句话，也可能一条线跨过两行；马克笔高亮会涂出去一点，圈画也可能盖住旁边的字。Inkive 不需要让结果与笔迹像素级重合。只要读者看到结果时觉得“对，我划的就是这句话”，它就是可以接受的。

所以，这一步花掉了我最多的时间和精力。到了这一步，文字识别准确率已经不够用了。我开始关注另一个指标：可接纳率。边界偶尔差一点没关系，只要结果符合人的阅读判断，就仍然可以接受。最终，在测试集中，95% 的结果无需修改或只需轻微校对。这个表现已经达到我愿意日常使用的水平。

Inkive，读完，拍完，带走

想把一本书笔记带回 Obsidian，不需要改变原本的阅读方式。你还是像以前一样读纸书，用自己习惯的笔划线、圈重点、写批注。读完以后，打开 Inkive，把相关书页一页页连续拍下来。识别完成后，你可以逐条校对书摘，也可以直接预览整本书的结果。确认无误后，再导出为 Markdown 文件。对我来说，Inkive 的价值就在这里：把停留在纸页上的划线带回 Obsidian，和过去的阅读、写作、思考连接起来。

只需 5 步，完成纸书划线笔记识别

最后放一段完整录屏，看看 Inkive 怎样处理一本书的划线。

后记

在 Inkive 接近完成的时候，我注意到一个海外创业团队也推出了一款智能书签硬件 Mark II，类似国内的词典笔，用户需要用专门的设备在纸书上「划线」，内容再通过云端大模型识别，并同步到 Notion 和 Readwise。售价 159 美元，预计 2026 年 Q3 发布。

Mark II - better tool for collecting ideas when reading

刚看到 Mark II 时，第一个念头是：原来不只我在寻找连接纸书划线和数字笔记的方法。不过，它选择了专用硬件和云端模型，而 Inkive 走的是手机应用加本地模型的路线。它不要求读者改变原本的阅读习惯：你还是捧起纸书阅读，用自己的笔划线、做笔记；Inkive 只在读完之后用手机处理书页。两种产品解决的是相似需求，但路径很不一样。

Inkive 只想把一件事做好：连接纸书和数字笔记，把阅读时留在纸页上的划线送回你的笔记系统。

Inkive 刚刚上架 App Store，现阶段先把 iOS 上的效果和体验做好。Android、Web 和小程序版本仍在计划中。

用了 GitZip 这么多年，我动手做了一个「Pro」版

fthux — Sun, 12 Jul 2026 13:19:55 GMT

写在前面

GitHub 上的仓库动辄几百兆，可很多时候你只想参考某一个工具函数或者某个目录下的文档。GitZip for GitHub 的出现完美地解决了这个问题，一键下载你需要的部分。这个经典的浏览器插件已经服务了无数开发者，我也用了相当长一段时间。

但在日常使用中，我逐渐积累了一些“如果它能再进一步就好了”的想法。比如：

每次下载代码，总要手动取消 node_modules 和 dist，能不能自动跳过？
只想下文档或者只想下载设计稿的时候，能不能一键切换？
下载了一堆 zip，能不能让文件名自带仓库和日期，一眼分辨？
对于下载需要的 Token，能不能给一个更清晰、可控的授权和额度监控？

这些想法并不是原版的问题，而是我“刚好需要”这些锦上添花的功能。于是我动手做了一个全方位加强的版本——GitZip Pro，目前已经GitHub 开源并上架 Chrome Web Store、Edge Add-ons和Firefox Add-ons。

它继承了原版绝大部分的操作习惯，然后加入了一些我认为“刚刚好”的能力。

自动忽略你永远不想下载的文件

GitZip Pro 内置了一套智能忽略规则。像 node_modules/、vendor/、dist/、build/、.git/、.DS_Store、日志和临时文件等，不需要手动取消勾选，默认就会被跳过。

更实用的是，GitZip Pro 预设了五种下载场景，一键切换：

Full Repository —— 完整仓库下载
Code Only —— 只要代码，自动排除文档、图片和构建产物
Documentation Only —— 只要文档（.md / .txt）
Design Assets —— 只要设计资源（图片、字体等）
Minimal —— 最小化下载，只保留最核心文件

如果你有更个性化的需求，还可以自定义通配符规则。

自定义 ZIP 命名，下载再多也不乱

GitZip Pro 支持模板化命名，可以使用内置变量自由组合：

{owner}-{repo}-{branch}-{date}

这样下载下来的文件自带完整上下文，看一眼就知道来自哪里、什么分支、什么时候下载的。

几处细节打磨，让体验更顺手

除了核心的过滤与命名，GitZip Pro 还添加了一些小功能，用起来会更加舒服：

Show File Sizes：在 GitHub 文件列表里直接显示每个文件的大小（显示文件夹的大小也不是不可以做，只是你的 Token 用量会消耗的很快，所以目前不会添加这个功能）。
Show Notification：下载完成后弹出浏览器的系统通知，你不用一直盯着页面，切换到其他标签页做事也不怕错过。
Play Sound：下载结束时可以播放提示音，可配合通知一起食用。

这些细节并不会改变核心功能，但日常高频使用时，会让你觉得一切都很“对”。

主题和按钮位置，顺手就好

视觉和交互上也留了一些灵活设置。GitZip Pro 提供浅色、深色和跟随系统三种主题，支持自定义强调色，用调色板或取色器选一个你看着舒服的颜色就行。悬浮下载按钮的位置也开放了 8 个方位可选，习惯按钮在哪个角落就设置到哪个角落。

更透明的私有仓库访问和额度监控

GitZip Pro 同样支持通过 GitHub OAuth 进行安全授权来访问私有仓库，并在此基础上做了一点儿优化：

可以匿名访问，也可以自定义 Token 访问
可以直接复制/粘贴你的 Token，也可以一键授权获取 Token
授权范围可以按需选择：仅公开仓库，或公开加私有仓库
Token 面板清晰展示 API 速率限制的剩余额度，让你预判请求余量，避免下载中断

匿名访问时，下载次数会更少，建议使用自定义 Token 方式访问

下载历史与统计

下载历史和统计面板会记录下载的详细数据：选中了多少文件、实际下载了多少、被忽略文件的数量及列表、分仓库统计等，算是锦上添花的功能。

写在最后

GitZip Pro 已开源，如果你现在用原版用得很顺手，完全不必强制自己更换。但如果你也有那么一丝希望下载过程更聪明、更个性化——欢迎来试试这个 Pro 版本。

致敬 GitZip for GitHub 和所有为开源世界默默贡献的开发者。好的工具总是在互相启发中变得更好。

精准刀法还是精准定位——微软Surface Go 3代使用体验与测评（3个月）

晓浙Jillies — Sat, 11 Jul 2026 14:16:16 GMT

笔者在写这篇文章的时候其实很纠结究竟要不要延续曾经诺基亚产品的时间逻辑，但总会有一些意外情况导致计划不如变化——包括选择这款产品也是一个防特殊情况“万不得已”的一个选择，所以最终机缘巧合，在时隔快一年的情况下最终仍然选择在相对合适的时间里入手了这台Surface Go 3。

本篇文章基于型号8+128G的Surface Go 3，奔腾金牌6500Y版本（自行贴了钢化膜），Windows 10专业版系统（通过预装Windows 11降级重装），搭配一般版本的微软官方配套键盘、HTC第三方触控笔。以下视需要时简称Go 3。

另外，这篇文章由于产品自身问题，已经烂尾，产品已经“回血永别”，且不会再推出新的文章，此发布更多地连带有一些纪念意义。具体情况我们会在文章后面说明。

【初识Surface家族、及Surface Go 3】

笔者关注Surface家族有好一阵子了，至少从2015年开始，当时因为大学同学购买Surface Pro 3才有了初步了解，特别是在那一年，微软也学会了发布会搞“耍猴”的套路，重磅推出Surface Book第一代的同时，还在发布会现场“耍秀”了一把，不过Surface Go系列的推出是后续的事情了。

笔者通过TB购入该台Surface Go 3。选择该配置的原因一方面在于对比2代、4代，3代是个性价比很合适的一代，2代尽管也有不错的配置，特别是高配，但相较于Windows 11和Windows 10后期版本的表现，2代稍微显得有点落后了，4代则大幅升级了处理器，作为仅有商用版且同样有且仅有的英特尔N200处理器，4代的价格显得有点太高了，而且N系列鉴于早期的“不良”影响力（“赛扬”品牌），N系列在当下的英特尔产品线里本质上有点跟赛扬差不太多（当然不清楚安腾系列是不是还在）。另一方面，从3代本身来看，性价比最高的就是介于“中间方案”的奔腾金牌8+128G配置方案，最低端的emmc懂得都懂，i3版本本质又只是奔腾金牌的略微提频版本，并没有带来曾经奔腾和酷睿家族的明显差别。

除了配置方面，功能需求也是一大考量因素，市面上有大量的二合一形态的产品，但12英寸以下较小尺寸的产品略显偏少，如果不考虑Android和iPad OS两类设备的产品，且又希望能有个稳定的风控表现（即一旦出现故障时解决办法更丰富），Windows家族里可选的产品就显得很少了，而微软Surface Go又是个一定不能忽略的产品家族。某种程度上讲，尽管还是有一些产品可供选择，但微软在这个产品线上的定位甚至说是“刀法”确实比较精准。对于笔者而言，笔者需要的是一台便携性较强的应急设备，能够在特殊情况下随拿随用应急办公、有一定的续航保障但不至于一般使用时也诱发续航焦虑（2-3小时）、能够使用一般软件甚至极个别情况下轻度使用大型影音编辑软件，同时也能作为不错的阅读用产品。

笔者在考虑Surface Go 3之前还有考虑过诺基亚/HMD的平板电脑T21——有更大的屏幕、更强的续航、更好的触控体验，和平板不怎么太普遍具备的第二投屏能力（将T21作为其他屏幕的显示扩展），奈何一方面T21如今早已停产，没有足够的渠道可以合适的价格购买，另一方面，T21搭载的紫光展锐处理器的表现实在无法预估，鉴于前两年里诺基亚X30的不稳定表现，即便平板有办公的较好适配，也很难确保非发哥和高通的芯片表现究竟是否平齐。

【初上手“开箱”】

笔者买的是一台官换机，但后来发现了一点“小插曲”，因而对实际情况略有存疑，不过鉴于非常有性价比的价格，加上这个“小插曲”反而让笔者更符合个人预期，所以这都不算什么事情。但不得不说，官换机的包装真的是官换机的风格，没有传统商品版的包装封面，赤裸裸的牛皮纸感透露着一股自然味道。

机器刚到手的时候搭载的是Windows 11系统，这个Windows 11属实让笔者略感崩溃，由于笔者曾经在英国时已经用过升级到Windows 11系统的ThinkPad（8代i5），对Windows 11的表现确实不怎么满意（虽然这篇文章的收尾是这台设备完成的），因而很快通过官方的恢复镜像降级到了Windows 10系统。降级后机身发热、加载速度较慢等一系列问题都解决得很好，也正是在下载镜像和通过驱动器模式恢复Windows 10时发现了上文提到的“小插曲”——这是一台非国行版疑似官换机，以原生英文系统降级回Windows 10反而让笔者的日常使用更加方便了不少。

除了系统层面的预装降级外，Surface Go 3开箱后第一印象里，有几个点还是比较喜欢的，一个是引以为傲的大角度平板形态，可以很方便地根据实际需要切换成不同的工作形态，二是触控屏幕的体验不错，虽然笔者贴的是商家随附的钢化膜，但个人感觉钢化膜除了单点触控外，在使用触控笔这块儿简单画画暂时没出现什么漂移的情况（只是个人更推荐类纸膜）；三是磁吸充电线，这个可谓是非常方便，虽然位置的设计上相比其他一般笔记本电脑是反过来的位于右侧，但只要不是“大力出奇迹”，一般情况下磁吸充电的吸附能力还是很稳定的，不必担心掉落的情况。

此外，机器还有一个可扩展TF卡槽，和有且仅有一个的USB-C口，但据网上的评测来看，这个TF卡槽的速率是没到全速的，包括Pro家族也是一样的情况。笔者目前买了一个WD的64G工业卡存入其中，这块工业卡插入后在电脑会显示SDXC式驱动器设备，和常规的可移动磁盘显示略有区别。

【功能体验】

硬件方面我们在文章开头已经讲过了。实际体验来看笔者个人觉得多数情况下属于很够用的程度——换句话讲在考虑是奔腾金牌还是i3，还是溢价的N200第四代Go的选择上，笔者觉得还是奔腾金牌更有性价比，而实际情况是这个选择确实没错，借助固态硬盘的加成，奔腾处理器并没有以前还未全面搭载固态硬盘笔记本电脑产品的情况下那么卡顿且响应很迟滞，但不得不说，双核处理器确实在Windows 10中稍微有点“力不从心”了，即便有超线程技术能够做到2C4T，在有些情况下，处理器的占用也很容易能达到100%的情况，而且其实影响最大的还是开机速度，在现在笔者几乎全靠云上（Office全家桶，不使用OneDrive本地同步）做文本编辑的情况下，且硬盘几乎没装东西时，低主频超低压处理器开机速度还是显得有点慢了，甚至会让笔者想起以前人生第一台“学霸机G50”的时候，开机速度甚至还没G50的Windows 8.1快，那个时候甚至还是东芝的机械硬盘。根据笔者有一阵子X230（i5款）和i5-8265U的经历，同样作为首次启动的话，Go 3算是有点慢的了，如果对快速启动电脑有要求的话，可能Go 4、更好的Pro系列甚至其他的产品线更适合。

不过，即便有点“拖后腿”，电源键解锁桌面的唤醒速度很快，即便有Windows Hello的加持也是如此，而且多数时候虹膜识别是几乎秒速解锁，夸张的讲跟当年Lumia 950家族的虹膜解锁效率几乎一致。

由于笔者大部分时间还是接键盘用，所以对于纯触屏键盘的体验知之甚少，但刚开始到手时，对Windows 11初始阶段的键盘使用可谓是体验稀烂，响应速度很是明显，因为笔者后来给8265U那台笔记本“手贱”升级了Windows 11，因此基本上对Go 3在Windows 11下的环境表现是有心理基础的，只是没想到在初始阶段，Go 3的机身背面就已经出现了明显的发热情况，直到笔者后来降级回Windows 10后才好了很多，包括笔者在用Go 3撰写这篇评测文期间也没有什么明显发热的情况，即便是纯电池状态下，一般浏览办公情况时，Go 3的明显发热也几乎不怎么出现，键盘的操作响应速度也非常符合预期——换句话讲如果换成Windows 11，电池模式下如果按照“推荐”模式（四个档位的第二档），键盘输入的文字速度估计会有明显的输入显示延迟。

另外，对于S模式的问题，由于笔者在Windows 11初始阶段完全没有注意到该事情，加上降级Windows 10后发现这台机器并没有默认开启S模式，所以在S模式的使用体验这给不到任何体验感，就目前来讲笔者用的是Windows 10专业版，对于一台奔腾处理器而言，使用起来还挺绰绰有余。

不过很有意思的是，也正是因为Windows 10专业版，Go 3可以在某种程度上作为高强度设备的远程平替，通过专业版将远程控制功能开启后，使用Go 3可以远程操作网络内的其他主机进行使用。就笔者而言，一般体验非常出色，没有什么太明显的网络延迟，而且分辨率方面除了适配稍微有点差异外（因为缩放大小的差别），基本上可以媲美直接在原始电脑上使用的表现，不过游戏娱乐方面还没实际测试过，而且特别是在冬天这种“寒冷的天气”里，在床上被窝里操作这书桌上的笔记本处理日常工作事务可实在是“太舒服”了。但通过系统内置远程功能连接有点麻烦，已有PIN码启动桌面的用户建议删除PIN码首次成功连接后再重新设置PIN码进入远程可解决正确密码输入后一直有无法进入的bug，同时有时也会存在同一个WiFi网络环境下，两台设备需要各自断开网络重新连接后才能成功连接远程控制的bug情况。

【续航与充电】

作为一个二合一设备，如果按照平板电脑的角度来看，Go 3的续航和充电速度都有点“平庸”，说不上太好也说不上太拉垮。作为一般办公浏览的话，到节电模式状态预估3.5-4个小时差不多的表现，而且在关机情况下，电池的自放电消耗也有存在（不清楚是不是冬天气温太低的缘故）。充电速度方面尽管适配器最大功率60W，但笔者感觉充电表现也就是一般笔记本的速度，不能期待有任何快充的情况下，关机充电半小时也不能太指望诸如“30分钟充满80%”的惊人效率，而且适配器本身还有一个额外的传统USB接口，这60W功率更像是能连带给其他设备多一个充电口的分配机会。不过对于一台没有电池快充的设备，某种程度上这样也挺好的，毕竟Surface的鼓包可是老问题了，倒是由于磁吸充电的特性，带一个适配器有时候确实有点不便，所以有条件的话可以使用一个诱骗线走PD协议充电，也能减少配件携带的体积。

考虑到一些实际情况，这里笔者提供少许有效续航案例参考：

12月8日，13:46开机100%，只做Word纯文字编辑，17:07还剩余51%，期间Windows 10有自动更新安装的后台活动，屏幕亮度70%，21:38左右再次开机使用时剩余49%，主要通过远程控制操作另一台电脑使用，用到23:54时剩余22%。

1月16日，14:13开始使用75%，通过OneDrive在线下载几篇电子书后待机到16:19还剩下53%。

【娱乐表现】

得益于TF卡，笔者在1月初试了一下Go 3的游戏表现，以极品飞车9为例，离电状态下（Recommend推荐模式）下，使用Widescreen Fix高清化补丁后，全开特效可以正常30帧游玩游戏，偶发在设置修改和加载环节时会有小卡顿的情况。说实话笔者对这个性能表现是挺意外的，居然能全开特效畅玩NFS9，除了比较诡异的是在同样的分辨率笔记本上，NFS9的高清化ini参数还需要手动调整一次才能适配屏幕才能生效（不然会出现HUD超出画面边界，或者“经典的”上下黑边的情况）。不得不说现在的CPU提升确实是跟曾经的老产品有着明显的差距了。不过鉴于Go 3的官方键盘方向键上下按钮面积过小体验极差，有条件的还是搞个手柄，换个更好的游戏体验吧。

【总结】

<优点>

- 在11英寸及以下的Windows平板产品中，Surface Go系列独大一方，几乎没有强劲的竞争对手（包括某个早年爱“碰瓷'的系列产品）。市面上还有很多Windows平板产品，这些产品多数维持在了12英寸以上，一部分做成了类掌机产品，虽然拥有比Go家族更强大的性能，但定位、价格也同时拉开了明显差距。同时，后期维保维修问题方面，Surface家族的过保后第三方维修也相较而言比其他Windows平板厂商略显方便（但Surface本身还是属于难修的产品）。如果你的需求非常明确，那么Surface Go几乎是没有什么可选的必选项。

- 无风扇设计。对于一台传统Windows平板电脑，无风扇设计是笔者最初考虑的一个潜在因素，尽管有个风扇可能避免降频问题，但如果能充分利用机身散热，在TDP不高的设计规格下，少一个风扇总归少一点后期维护成本。

- 恰到好处的平板电脑体验。表现还不错的双扬声器、FHD触控屏幕、外接磁吸键盘、完整的Windows系统功能、表现不俗且无凸起的摄像头模组设计、安全登录功能。浓缩在一台10英寸产品上真可谓恰到好处，如果不在4000的价位甚至在3000以下购入一台且能搭上配套键盘（或触控笔）的话，其实性价比相当出色。

<不足>

- 屏幕建议“贴点东西”做好防护。尽管10英寸平板电脑并不算大，但长期使用还是免不了磨损和污渍的存在，特别是搭配键盘进行盒盖式出行时，很难确保那个键盘帽不会跟屏幕产生“亲密接触”。而且笔者发现目前的钢化膜在使用时还是会对手指触控带来一些负面影响，这也是前文提到的推荐类纸膜的原因。

- 核心硬件性能不上不下。微软刀法算是非常精准，不同代系的处理器配置差距并不是很明显，到了Go 3，仅小幅提升频率的顶配i3和奔腾几乎没有拉开明显差距，而且影响体验的还有存储差异，emmc硬盘的丐版配置到了Go 3居然还能作为低配存在属实容易令人”骂街“。当然，作为三代产品，即便核心硬件性能属于平庸的水平，不同配置也会存在实际体验差距可能较为明显的情况。至于4代干脆只剩下个N200商用版，但鉴于Windows 11的逆天表现和N200本身不具备超线程技术，4代的表现除了续航方面估计不会提升太大。所以换句话讲，如果考虑10英寸机身拿下小钢炮般的性能，譬如进行游戏娱乐，Go家族并不适合你，但从目前的情况来看，紧急情况插电开个Pr或剪映工作时，只要不是超大型工程还是绰绰有余的。

- 屏幕边框问题。笔者在选购前就有看到过有一些网友对Go系列的一个模具传家宝设计，特别是屏幕大黑边提出过批评，有人提到了这种黑边的设计其实对外接键盘使用时是恰到好处的。但笔者在这一段时间的使用后，认为四面黑边其实还可以略微收窄一点，或通过调整模具大小减小屏幕黑边面积，当然微软应该是为了成本控制，所以才一直做的这么放飞自我，但产品都到第三代了，巨硬其实真的可以稍微考虑改点视觉上的东西了。

- 外接接盘接还是不接。这个点会显得比较奇怪，是因为笔者一直觉得接和不接是两种完全不同的体验，像笔者当时买的时候，附赠的键盘还没到时，作为平板的使用体验还不错，但是当键盘到了之后，多数时间都是接着键盘当伪笔记本电脑来操作使用。当然这属于笔者个人的使用需求问题，但对于还没有或者准备考虑另购键盘的读者用户，如果要明确区分个人产品使用定位的话，键盘有还是没有确实要稍微考虑一下（当然，现在键盘的价格确实也不怎么贵，备一个也彳亍）。

另外，Surface的各种通病和品控问题已经是老毛病了，笔者虽然还挺幸运都没碰到这些情况，但鉴于每个人手上的产品都存在个体差异，品控通病问题虽然不算作个人使用时感觉的不足，但也值得拿出来提一下值得注意（而且据说键盘好像也有出故障的案例），毕竟现在微软Surface家族在国行已经基本上属于“全面撤退”的节奏了，一旦出个意外情况，售后怎么处理都是个不太好说的事情。

【追加——为什么彻底告别】

笔者记得这事情是今年1月19号完结的事，起因就是屏幕横向握持时右侧一排触控失灵不起作用的事情，而且这个右侧一排触控非常迷惑，是整个区域都有问题，不仅触摸无反应，使用第三方触控笔时，笔尖选中和区域选取范围都选不到右侧一排边缘的屏幕区域。鉴于使用时间并不多，加上后来还特意为这款产品买了个保护包和配件包，遂与卖家沟通，经过一系列经典操作，包括驱动调整、系统重制之后，最终没能解决问题，并在稍有些损失的情况下选择退货退款结束了对这台产品的使用。如果没有意外情况，这也将会是笔者最后接触的Surface产品。

至于最后到底是什么原因导致的不得而知，但是在当时使用次数极少保护良好的情况下，只能寄回检查的结果显然会觉得有点别扭。但鉴于早期降级阶段的了解，这台产品起码是一台外壳有过更换的产品，外壳的序列号是i3处理器版本，且原厂语言为英文，并非国行型号，其他方面完全不得而知。如果是官换机，微软的这个品控简直拉跨，如果是“官换”（翻新）机，有问题确实应该沟通退款，鉴于该店的售后水平就也不便多说什么。不过在收尾该文之前，笔者特意去看了一下目前Surface的行情，因为国行Surface基本上是悄无声息地退出，在国内市场半死不活的存在，结果没想到国行Go 4的128G价格已经暴涨到6000+（在当时还是在4200区间段），只能说这种配置的产品，谁买谁上当是真的，价格完全对不住这硬件，买一台翻新ThinkPad或者旧款ThinkPad都比这划算。不过，鉴于Surface的形态，对于特定群体还是有很适配的需求和场景。

摩尔定律被杀，我们很怀念它

彷徨旅人 — Fri, 10 Jul 2026 18:32:28 GMT

关注消费电子产品的朋友大概有所耳闻，笔记本电脑价格从「早买早享受，晚买享折扣」变成了「今年的最佳购买时机是去年」。老黄说：我 2017 年就开始喊摩尔定律已死，你们不信，那我就亲手杀死它，身体力行让你们感受一下痛楚。于是消费者喜迎电子产品涨价潮，不是一年、不是两年，三年打底。KOL 与品牌信徒放话钱少事多的消费者与其抱怨，不如去买内存厂商股票对冲。但在证监会严肃查处老虎等机构非法跨境展业后，臣妾做不到啊。

难以描述的痛苦更为可怕，于是我想尝试分析一下这次涨价的幅度。机缘巧合之下，笔吧评测室成员村民提供了不错的数据源。在进行初步的数据清洗后，我额外补充了 MacBook 的 SKU。基于这份再加工的数据，让我们直面痛苦。

笔记本电脑上半年整体涨价千余元

虽然笔记本厂商趁暑假需求旺盛痛宰大学新生家庭是业界共识，毕竟 618 出的血得补回来，但过去这种涨价是暂时性的，至少到双 11 会有一定回落；但今年就不好说了。

在 2026 年上半年，笔记本价格大致上从接近 9000 涨到了 1 万左右，绝对价格变化超过千元，相对幅度为 14 ~ 16%。

看到这几个数字，各位可能会有些疑问。一是涨价幅度才这么点吗？这个问题其实蛮好回答：因为目前的数据仅包含 2026 年 1 月 - 7 月的价格，并未进行年度价格变化对比。如果各位对比的是今年与去年同期的价格，涨价幅度完全有可能更高。

第二个疑问可能是笔记本价格都这么高了吗？由于笔记本 SKU 级别的销量数据难以获取，上图反映的价格其实并未考虑销量。一般情况下，笔记本销量与售价趋势上成反比，价格较低的 SKU 是出货量主力。在有销量数据的前提下，基于销量对售价进行加权后计算的价格中位数或平均数，会更贴近消费者对笔记本售价的日常认知，也就是比上图更低。

在无法基于销量加权的场景下，整体售价涨幅的预估也可能会有一定偏差，因为从常理判断，不同价位段笔记本的涨价幅度会有差异。接下来让我们验证这个常理是否靠谱，顺便为没有销量数据找补。

以前价格越低，现在涨得越狠

如果以 SKU 为单位进行分析，可以发现基础价格越低，涨价幅度大致上越大，尽管两者之间并不能说关系很紧密，但趋势确实存在。

进一步区分笔记本搭载的 CPU 进行统计，无论 AMD 还是 Intel 笔记本都呈现出类似的趋势，但 AMD 笔记本相对更为明显，体现在它的趋势线更陡峭,，可以理解为不同价位段的 AMD 笔记本价格变化幅度差异要比 Intel 更大。换句话说，AMD 高价位笔记本更有可能涨得相对少，低价位笔记本更有可能涨幅相对大。不同人对此有不同的解读，如何发挥则能够体现它们对不同品牌的刻板印象。

再往下深挖，按是否搭载独立显卡与 CPU 品牌分组，不难发现 AMD 核显笔记本均价的涨幅看起来明显比其他类目更高，而 AMD + 独立显卡机型均价的涨幅是最低的，对比之下，前者均价涨幅是后者两倍有多，可以说十分夸张。

如果使用价格中位数为基础计算涨幅，不同类目之间的差异就没有那么大了，虽然 AMD 核显笔记本价格中位数涨幅 19% 依旧是最高的，但与最低类目的 15% 相比，并没有使用均价时相差如此之大。

分析到这里，其实可以尝试作一个推断：有可能是 AMD 核显里有几款机型的涨幅特别夸张，使得按均价计算的涨幅非常高，而中位数因为受极端值影响比平均数更小，所以按中位数计算的 AMD 核显笔记本售价涨幅相对没有那么高。

下一步，自然是找出 AMD 核显笔记本均价涨幅如此之大的推手。

AMD 核显本涨得多，与品牌力有关

鉴于有一款搭载 AMD CPU 的 Thinkbook 14+ 机型从 5999 涨到了 9599，我的目光就落到了联想身上。

联想的多数类目均价涨幅在 20% 左右，唯独 AMD 核显机型均价涨幅 39%，是其余类目的两倍。假如联想所有类目机型均价涨幅都维持在 20%，可以想象 AMD 核显机型均价的整体涨幅不至于像现在这么「鹤立鸡群」，毕竟在本次分析的样本里，40 款 AMD 核显机型中有 18 款来自联想，接近半壁江山。至于联想这个决策背后有什么商业考量，基于现有的数据难以进行有效推断。如果让我瞎想的话，我会说可能与联想和 Intel 在轻薄本领域的「紧密合作」有关。

当然，AMD 核显笔记本涨价幅度相对高的现象确实存在，无论是上图的「行业其他」还是上个章节里的「价格中位数」，AMD 核显笔记本这个类目的价格变化程度都是最大的。

与这个现象相关的影响因素有两个：一是到目前为止，绝大多数 OEM 对 AMD 核显笔记本的定位大多依旧集中在主流价位段办公本与低价位段性价比产品，高端轻薄本屈指可数。近两年稍微有点讨论度的可能就数华硕灵耀 16 Air, AMD 在高端轻薄本领域的品牌力至今还是没有得到太多认可。

二是价格越低的产品，受成本上涨的影响越大，反映到售价上调整的幅度也会越大。举一个简化的例子，假设在 2025 年 6 月，5000 元的笔记本毛利率 5%，10000 元的笔记本毛利率 15%；到了 2026 年 6 月，原本定价 5000 的机型成本变成了 6000，为了维持原有的毛利率，需要涨到 6316，涨幅 26%；原本定价 10000 的机型成本变成了 9800，为了维持原有的毛利率，需要涨到 11600，涨幅 16%，低于定价 5000 的机型。

一来二去，AMD 核显笔记本自然就成了售价涨幅最高的类目了。

笔记本涨价，怪谁？

虽然联想对 AMD 核显笔记本的涨价「贡献良多」，但不考虑具体机型看整体涨价幅度的话，联想的涨幅也不是独一份。

另外一家笔记本大厂惠普的涨价幅度与联想相比也不遑多让，两家都有超过 20% 的涨幅。华硕、机械革命的涨价幅度与行业整体的 14 ~ 16% 差不多，荣耀涨幅低于行业，Apple 略高于行业水平。其余 OEM 机型在本次样本中数量太少，未单独列出。

更贵的消费电子产品、更多的裁员、更少的收入、更高的订阅制支出，这就是大语言模型为我们带来的美丽新世界。

然而相比起怪罪大语言模型，我更愿意把锅放回作出种种决策、带来上述后果的人身上。

同样多花一万，花在哪回本最快？一个9年新能源车主的配置排序

约斯特普通 — Fri, 10 Jul 2026 03:54:30 GMT

AI 辅助创作声明：本文由作者本人撰写，创作过程中使用了 Claude Code 辅助整理文章大纲和部分文字润色和优化。

最近有一个朋友要买新能源车，预算卡得比较紧，问我什么配置要不要选。

我没直接给答案，而是问了他:"这个配置日常是否用得上，和日常的用车场景是否契合？"为什么呢？因为配置的选择，特别是需要多花钱增配的部分，一定要考虑使用频次和使用场景，该省省该花花。

这个问题让我想起过去两年多从试驾到决定换成，再到最终选配一圈下来，自己真金白银踩过的坑和觉得赚到的配置。真正让日常用车体验产生质变的，往往不是那些参数表上最显眼的东西。

今天就把这些真实感受列出来，给正在选车配置的你一个参考。

第一顺位：买完立刻回本

1）方向盘加热

在一众配置中，方向盘加热是我提车时完全没在意的功能。

买第一辆比亚迪唐的时候，都不知道车还能配这个。后来看车评提过，也觉得多此一举——方向盘冷一点就冷一点，戴手套不就行了？

直到去年冬天，某个早起的早晨，送娃上学前在车里坐了会儿。手搭上去没几分钟，手心慢慢暖和起来。那一瞬间的感受很奇妙：不止是手上暖了，整个人都松弛了一些。

就这个配置，冬天每个早晨都在用。一辆车开三五年，每年用三个月，算下来每天的成本几乎可以忽略。但体验的收益——尤其冬天送娃那十几分钟——是实打实的。

有方向盘加热就选上，没得选的话，如果有第三方的加热方向盘套也可以考虑。这笔钱，冬天开一礼拜就值回来了。

2）电动遮阳帘

夏天坐进一辆晒了一下午的车，头顶一块全景天幕的热浪扑面而来——这种体验经历过的都懂。

极氪7X原厂配了电动遮阳帘，起初觉得可有可无。但到了第一个夏天，每次上车看到遮阳帘关着，车里温度明显比没帘子的车低一大截，就知道这项配置值不值了，物理隔热还是yyds。

有人说全景天幕可以用手动遮阳帘替代，但手动的遮阳帘装上去之后，大概率过了新鲜期就懒得动了，而电动的一键开关，日常使用实在太方便。

有的新能源车配的是可变色天幕，效果虽好但价格明显不止一万。如果预算有限，电动遮阳帘可能是天幕方案的平替之王。

第二顺位：高频用，用了就回不去

3） HUD抬头显示

极氪7X其实有仪表盘，清晰度也还不错。但如果非要我在仪表盘和HUD里二选一，我会选HUD。

理由很简单：时速、导航、限速信息直接投射在眼前，视线不用从路面移到仪表盘上。刚开始用可能无感，但当你习惯了HUD，换回没HUD的车开一阵子，会觉得仪表盘怎么看怎么不习惯。

HUD还有一点好：不用低头看屏幕，孩子在后排闹的时候，能减少一个分心点，变相提升了行车安全。

4）辅助驾驶

辅助驾驶这几年争议挺大，有些品牌的过度宣传，让不少车主对辅助驾驶有了不切实际的期待，同时也有一些奇葩用法。

但我个人体验是：在高速上用辅助驾驶，确实能显著降低长途驾驶的疲劳感。一个人开单程500公里，有辅助驾驶和没有，完全是两个体验。

如果你像我一样，一年跑几次单程500公里以上的长途，多花一点选带靠谱辅助驾驶的版本，账面上是多花了一些钱，但换来的是每次长途都轻松不少。

有一点要理性看待：辅助驾驶目前还是一个"能用但不能全信"的阶段。日常通勤用它不多，高速才是它的主战场。如果你几乎不上高速，这一万块可以考虑排到后面去。

第三顺位：为家人花的钱，花完才知道值

5）后排舒适配置

很多人在选车阶段，注意力很容易被屏幕、音响、加速吸引，而这些对真正坐在后排开车的家人和孩子来说，几乎无感。

我的极氪7X唯一的选装，就是后排沙发，有腿托、靠背调节和通风加热。

提车的时候觉得就是多了个座椅调节，但开了几次长途之后，这个想法完全变了。孩子在后排坐着没那么躁了，老婆偶尔在车上眯一会儿也睡得比较踏实。这些变化零零碎碎，但积累下来，你就会觉得这钱花得值。

不要只看试驾时那半小时的感觉。家庭用车的高频场景，往往是孩子上车后的几分钟、周末短途的两三小时、长途时后排能不能睡觉。这些很难在那半个多小时的试驾中体验出来。

如果是家庭唯一用车，后排的舒适配置预算，建议放在驾驶类的爽感配置前面。

第四顺位：体验加分项，看场景

6）主驾头枕音响

一个用了便回不去的配置。日常开车会听歌、听播客、开导航，偶尔再来个电话，这些高频操作都能用头枕音响来完成。

传统音响的解决方案是：导航语音打断了音乐，或者通话声盖过了导航提示。而头枕音响可以把导航指令和通话单独送到驾驶员的耳边，不打断车里其他人听歌的效果。

7）大电池（100kWh及以上）

超预算最多的一项，但我放在体验优化分类里，因为它不像方向盘加热那样"每天回本"。

当初选100kWh电池版本，主要逻辑是用大电池的"确定性"替代三电优化的"不确定性"。实际用下来：城区通勤基本没有里程焦虑，跑高速时能一脚电门稳定跑到500km左右，遇到大服务区排队充电的假期，可以果断不排继续开。

夏天开空调、冬天开加热，也不会因为心疼续航而省着用。

如果你的日常通勤半径在50公里以内，而且有稳定的家充条件，75kWh其实也够用。多出来的预算省下来花在其他配置上，体验的边际收益可能更高。

但如果你长途频率较高、或者没有家充条件，大电池这笔钱花出去，它能在每次出发前给你一种 "不用操心" 的安心感。

8）四驱

当下的新能源车，即便是单电机的两驱版本，其动力也是过剩的，从这个角度出发，四驱其实不是很有必要。

但如果从安全冗余的角度出发，四驱可能会更稳定一些，至少我心里面会觉得安全性更足一点点。

我选择四驱主要是因为在高速上爆胎过，对四驱有执念，当时的时速在120km，左后轮爆胎后，车身有所震动，但我很快便把方向盘控制住，然后在几秒钟后完成了靠边停车。

9）空气悬架

空气悬架，更多是一个舒适性和增加灵活性的配置，例如遇到颠簸路段或走一些高低起伏的烂路。

空气悬架的软硬和高度调节功能便能派上大用场，如果日常行驶的高度以城区道路为绝对的主力，那没有空悬完全不影响体验。

另外一个，是关于空悬悬架的B面，其维修和更换成本并不低，如果确定增配，这一特性也需要考虑在内。

一些排序之外的思考

以上排序，是我开了9年新能源、换过两辆车、试驾过十几款新能车之后的一点点真实感受。

最有意思的是，有些提车时很在意的参数——零百加速、悬架结构、车机芯片——在日常使用中很少去感知。反而是那些当初觉得可有可无的配置，在长期使用后越用越离不开。

选配置的时候，不妨先想清楚你的高频场景是什么，再决定把钱花在哪。这个思路，比在参数表上逐一比较要有效得多。

买车如此，选配置也是如此。最怕的不是花多了钱，而是钱花了，每天用得上的体验却没买回来。

给 macOS Finder 补上右键「新建文件」功能 — 免费 Automator 工具

叶潮郑 — Fri, 10 Jul 2026 01:25:29 GMT

macOS 的 Finder 有一个长期被吐槽的缺陷：右键菜单没有「新建文件」选项。Windows 用户切换到 Mac 后，这个习惯动作会让人反复踩坑。

每次想新建一个空白文本文件，标准流程是：打开 TextEdit（或 VS Code）→ 新建文档 → Command+S → 导航到目标目录 → 输入文件名 → 保存。五步操作，换来一个空文件。

解决方案

用 macOS 自带的 Automator 制作了一个 Quick Action，安装后在 Finder 任意目录右键，点击「新建文件」即可：

1. 在当前目录创建 untitled.txt，直接进入重命名状态
2. 已有同名文件时自动递增（untitled 2.txt、untitled 3.txt……）
3. 支持在空白处右键、在文件夹图标上右键

安装方法

方法一（推荐，无需命令行）：
在 GitHub Releases 下载 NewFile.workflow.zip，解压后双击安装即可。

方法二（命令行）：
git clone https://github.com/yechaozheng2-dotcom/mac-new-file.git
cd mac-new-file && bash install.sh

安装后在「系统设置 → 键盘 → 键盘快捷键 → 服务」中勾选「新建文件」启用。首次运行会请求辅助功能权限，在「隐私与安全性 → 辅助功能」允许 Automator 即可。

技术细节

基于 Automator Quick Action + Shell 脚本 + AppleScript，无第三方依赖，不联网，支持 macOS Ventura（13）及以上。

完全开源免费：https://github.com/yechaozheng2-dotcom/mac-new-file

详细安装步骤 + 截图：https://tool.top1pick.com/tools/mac-new-file/

任天堂的中国分堂：从神游机到腾讯 Switch，神游iQue的二十余年

随便好啦 — Thu, 09 Jul 2026 11:10:05 GMT

提到“游戏汉化”这个略带古早味的话题时，我想说：在国内有这么一家公司，它不仅是任天堂官方指定的国内“游戏汉化组”，甚至还独家代理了任天堂在国内的游戏销售业务。想必你对它的大名肯定略有耳闻：神游（iQue）。

在2000年国内游戏机禁令发布后，游戏主机市场一片空白。直到2002年，祖籍苏州的美籍华人、硅谷图形学专家颜维群博士，凭借其深厚技术背景和与任天堂多年的合作关系（他曾参与N64和NGC图形处理器的研发），与任天堂合资成立了神游科技（中国）有限公司，颜维群占股51%，任天堂占股49%。

神游成立仅仅一年之后，在2003年11月发布了第一款产品“神游机”iQue Player。为了绕开当时的禁令，它以“家庭三维互动娱乐系统”的名义问世，甚至在说明书里特意强调“不是游戏机”，定价598元。

而游戏部分全部以数字形式发售：通过线下的“神游加油站”将游戏本体下载至64MB大小的神游卡当中，全程不需要任何实体游戏卡带，正是这一操作完美绕开了当时的禁令。神游机在运营期间共推出了15款正版中文游戏，包括《超级马力欧64》《塞尔达传说：时之笛》等经典作品，其翻译标准至今仍被任天堂官方沿用。不过神游机最终因为销售渠道受限、市场定位偏差（N64在当时已经落后一个世代），只卖出约一万台，于2006年停止运营。

提起这种钻空子的办法，倒是让我想起了国内当时很火的小霸王学习游戏机。也有类似的操作，一边宣传可以帮助孩子学习成长，而主机内又可以玩游戏。

让我们把视线再拉回到2004年，神游在推出了第一款游戏主机之后，便开始了为任天堂在华游戏机业务代理以及游戏汉化的道路。

同年，神游推出中国大陆行货版GBA，命名为小神游GBA，其机身采用银色配色。同年10月，小神游GBA SP正式发售，首周全国出货超20000台。而更值得一提的是，专为中国市场设计的“中国龙”限定版小神游GBA SP也在2004年问世。这是任天堂历史上第一台只面向中国发售的限定版主机，上下盖分别采用紫禁红和玛瑙黑的龙纹设计，极具收藏价值。

到了2005年6月，神游又紧跟日本任天堂的步伐，为中国玩家带来了iQue DS，实现了“全球同步”的承诺，上市与日本首发仅仅相隔三个月。

这里要提一嘴的是：神游DS有一个非常良心的设计，它不锁区，可以运行日版、美版等任何区域的游戏卡带。这是颜维群为了对抗水货市场特意争取到的特权，也是任天堂历史上唯一一次允许官方主机不锁区。在当年水货横行的环境下，这一点让神游掌机极具竞争力。

而一年之后又相继推出了更为轻薄的iQue DS Lite，同样有“中国龙”限定版配色。最终小神游GBA系列总销量超过50万台，DS系列总销量超过30万台，销售额逾4亿元，这是神游历史上最辉煌的时期。

到了iQue DSi时代，神游还进行了深度本地化尝试，内置了多款创意软件，比如利用摄像头合成照片的《趣照》（有街边大头贴那种味道了），以及手绘动画创作的《绘心教室》等（非常治愈系的一款绘画游戏，后续3DS上的版本也由神游完成了汉化）。部分套装还附赠了《任天狗狗》等互动软件（玩法类似早期的拓麻歌子，电子小宠物。不过不同的是通过DSi内置的麦克风以及下半部分的电阻触摸屏还可以实现让宠物听从指令以及抚摸等一系列互动），让玩家体验到除了游戏之外的乐趣。

神游不仅是对掌机的行货代理，其在汉化领域的成果也十分亮眼，不仅推出了全中文系统界面，还带来了大量的汉化游戏。任天堂最核心的IP，像《超级马力欧》系列、《塞尔达传说》系列，都被神游汉化并搬上了国内市场。

事情的转折发生在2007年，这一年神游打算将任天堂发布的家用游戏主机Wii引进中国市场，并且已经制作了完整的简体中文汉化操作界面，但最终Wii国行版未能通过审核，未能与国内玩家相见。

具体原因至今未有官方说明，业内普遍猜测与当时国内对“体感游戏”的政策限制有关。在错过了Wii这台全球大获成功的主机之后，神游的发展陷入了停滞。2008-2009年，对游戏行业心灰意冷的颜维群退出了神游管理，并将全部股份出售给任天堂。2013年，神游科技正式成为任天堂的全资子公司，从此失去了独立运营权，完全由任天堂接管。

2012年12月2日，神游正式在中国市场发布iQue 3DS XL，即日版3DS LL（国内玩家称老大三），售价约1600元，略高于港版同款。这也是神游引进的最后一款“神游”牌任天堂游戏机。

而这“最后一款神游掌机”也略显特殊。在机器配色方面仅有“马力欧白”、“马力欧银”和“马力欧红金（限量版）”三款，没有普通版。由于游戏审核和公司内部问题，它并没有发行任何实体卡带，出厂仅预装了《超级马力欧3D乐园》和《马力欧卡丁车7》两款数字版游戏，此后未再发售任何游戏，也从未开放国行eShop。

更致命的是，任天堂在3DS时代全球推行锁区政策，神游3DS XL无法运行日版、美版等海外游戏卡带，有实测插日版《塞尔达传说时之笛》会直接显示“无法运行”。不过它可以正常运行所有港台地区发售的包含简体中文的游戏，并正常显示简体中文。

由于锁区且没有新游戏，再加上当时的3DS系统还没破解，导致玩家宁愿去买水货日版机。神游3DS XL首发5000台，一年后便宣告停产，成为了任天堂历史上销量最差的官方掌机，彻底沦为“最惨行货”。2013年9月6日，iQue 3DS XL的3C证书被撤销。自此以后，神游公司不再负责任何任天堂硬件的国行代理工作，进入“半休眠”状态。

时间来到2019年，腾讯正式宣布代理国行Switch，任天堂在华硬件业务正式交由腾讯负责。但神游并没有随之消亡。事实上自2013年硬件业务停滞起，神游的官网上就明确写着“研发支援和本地化服务”的职能，2016年其官网还进行了一次改版，详细罗列了所有行货产品历史，并发布了招聘信息。

由腾讯代理的国行版Switch在发售初期势头很猛，但最终因为锁服以及单薄的游戏阵容等问题提前退场。具体来说，国行Switch首发时只有《新超级马力欧兄弟U 豪华版》一款大作撑场面，后续虽有了《马力欧卡丁车8》《塞尔达传说旷野之息》等，但相比海外数百款的游戏库差距巨大，更新极其缓慢。

锁服意味着国行商店与海外商店物理隔绝，无法登录其他地区的账号，这就导致两个最致命的后果：一是无法与海外玩家联机（只能和国行用户玩），二是无法购买和下载DLC，比如《旷野之息》的“试炼的勇者们”国行玩家根本无法获取，游戏体验被砍了一截。

2026年5月15日，腾讯国行Switch正式停止所有网络服务（包括e商店下载、联机对战和系统更新）；同年12月31日，维修服务也将全面终止。

但神游并没有随之消亡。如今，神游科技（已成为任天堂全资子公司）依然位于苏州工业园区金鸡湖畔。你在国行Switch上玩到的绝大多数任天堂第一方中文游戏（如《塞尔达传说》《马力欧》《宝可梦》等），其汉化工作正是由神游汉化组完成的。神游并没有“彻底结束”，它只是从一家“卖游戏机的公司”，转型为一家“做汉化和研发的公司”，继续默默为中国玩家服务。

文案：随便好啦

配图：随便好啦

参考资料：
·百度百科，神游科技词条（2002年成立、股权结构、神游机发布、iQue 3DS XL上市时间及停产）
·百度百科，小神游SP词条（2004年首周出货超20000台、“中国龙”限定版）
·新浪游戏，《任天堂的中国马甲——神游中国的生死浮沉》（GBA/DS系列销量、公司营业额）
·神游中国官网，iQue DS产品页（2005年全球同步、不锁区）
·游戏陀螺，《下注之王：任天堂的世纪豪赌》（Wii引进失败、颜维群退出、神游成为全资子公司）
·快懂百科，神游科技（DSi内置软件、《任天狗狗》《绘心教室》）
·游民星空，《跌宕三十年，腾讯和任天堂在中国的“修炼”之路》（国行Switch锁服、游戏阵容单薄）
·机核GCORES，《回顾任天堂国行的20年（中）》（神游3DS XL锁区无法运行日版卡带、国行Switch无法下载DLC）
·腾讯官方公告（2026年5月15日国行Switch停止网络服务，12月31日维修终止）

App+1｜WiseSwipe —— 我制作了一个帮你推荐最长免息卡片的信用卡小工具

bakamio — Thu, 09 Jul 2026 09:42:57 GMT

TL;DR 太长不看版： 👉 点击这里前往 App Store 下载 WiseSwipe （或者在 App Store 搜索「慧刷」或「WiseSwipe」）

每到各大购物季来临要买东西，家人总会问我：「今天该刷哪张卡？」

我们都知道信用卡刷卡后不是立刻就还款，而是会把当期所有的交易汇总到一起出账（也就是所谓的账单日），当期账单在还款截止日前还款就不算逾期。这里的「交易日」到「还款日」之间的时间差，就是信用卡的「免息期」。

如果你有多张信用卡，由于每一张卡片的账单日和还款日规则不同，即使是同一天刷卡，它们的免息期当然也会不一样。所以，就有了这一种「薅羊毛」的办法：选择免息期较长的卡，意味着本来要早些还的这笔资金可以在流动理财账户（比如余额宝等货币基金账户）里多躺几天、多赚几天的利息。（虽然说现在货币基金的收益也只有那么一点啦，单次看可能也就是毛毛雨，但积少成多，况且如果是大额消费，还是有差。）并且相应地，如果在卡片刚过账单日就消费，这笔支出就能计入下一个账单周期，也就能获得最长的免息期。

不过卡片少还好，大体记一下哪些天刷哪张卡就行。卡片一多，每次都要自己去记账单日、还款日，再手动计算，时间成本和精力成本实在是不划算。所以这种事情还是得交给工具来做。

在此之前我其实也尝试过现有的应用。不过它们大多功能太重、不纯粹，许多计算免息期的功能，都被内嵌在了记账或者理财应用里。我日常是用 Numbers 记账，不需要额外的记账工具，也不需要信用卡管理工具来记录我刷了多少钱、额度还剩多少、年费减免了吗。而另外一些专门只做免息期的应用，也没有完全符合我心意的，比如没有锁屏小组件，或是设计风格不合胃口。

于是我就想，为什么不自己动手制作呢？「慧刷 WiseSwipe」就这样诞生了。

它有什么功能？

WiseSwipe 不能记账、不能理财，它是一款主打自动计算免息期并推荐当日消费最长免息卡片的应用。主要有这些功能：

今日最佳刷卡推荐

在录入卡片数据后，应用会根据今天的日期，以及每张卡片的账单日、还款日规则计算出卡片的免息期，并通过排行榜形式展示。首页最上方的卡片就是「今日最佳」，下方还会展示所有卡片的排行榜。

今日最佳刷卡推荐。

在添加卡片时，我们可以根据实际情况配置账单日和还款日规则，例如：

账单日当天消费是计入本期账单还是计入下期账单；
还款日是每月固定日期，还是账单日后的固定天数。

配置账单日、还款日规则。

首页还有一个「刷卡模拟器」，它会对比选用免息期最长和最短的卡片，直观感受资金在理财账户多放几天能收获的利息数额。当然，这个数据仅供参考，不构成任何理财建议。

刷卡模拟器。

免息日历

除了查看每日推荐，在「免息日历」中也可以查看未来所有日期的免息排行榜。特别地，如果某一天刚好有卡片出账或还款，日历上会有圆点标注，下方也会有详细的数据。这样账期一目了然，也可以提前规划未来的大额支出。

免息日历与账单日、还款日标记。

点击右上角的铃铛按钮可以设置出账与还款提醒。不过一般银行也会通过应用内通知和短信提醒还款，如果你不想收到重复通知，这一项可以不用理会。

设置出账与还款提醒。

卡包管理的个性化配置

卡包列表提供了简单与详细两种视图，可以在顶部切换。目前卡片是根据还款及出账日期临近排序，未来还会加入更多的排列方式。除了卡片的基本信息，我也特意为每家发卡银行适配了他们的品牌色，这样在卡片列表中寻找起来就更加方便。

卡包管理的简洁与详细视图。

我们也可以通过以下方式自定义推荐排行榜：

不参与排行：开启后，这张卡片就不会参与首页推荐及免息排行，不过还是可以继续查看免息期、追踪出账和还款日程。

这个功能主要是为了互联网支付方式适配。在不同的消费场景中，我们可能会在传统的信用卡与花呗、京东白条、抖音月付等互联网支付方式中选择，所以也支持将这类支付方式作为特殊的卡片添加到应用中。不过相比传统的信用卡，它们有自己的使用场景限制。如果你平时不太用到它们，只是想追踪一下账期，或是偶尔作为选择对比，可以把它们设置为「不参与排行」，这样可以避免打乱日常的刷卡推荐。

设置逾期：信用卡如果不小心逾期，就会产生循环利息，这时我们可以在卡包中将它标记为逾期。逾期的卡片不仅不会参与排行推荐，免息天数也会被归零。(如果卡片真的逾期了，我觉得还是先别看这个应用了，赶紧去还上要紧)

卡片的特殊配置。

桌面与锁屏小组件（Pro 功能，支持预览）

在设计最初，我就认为这个工具最好是不打扰的，所以小组件功能十分必要。并且考虑到经常刷卡的重度信用卡用户，放在锁屏也非常合适。

小组件主要分为「免息排行榜」以及「还款倒计时」两类，其中：

桌面小组件：款式比较多，有大、中、小三种尺寸，并且适配了深色、浅色以及透明模式。

桌面小组件。

锁屏小组件：考虑到空间限制，并且锁屏小组件尽量是看一眼就能知晓结果，所以只设计了「今日最佳推荐」和「最近还款日程」这两款。

锁屏小组件。

小组件属于 Pro 功能，但你可以在应用设置的「小组件预览」页面查看显示效果。

100% 本地应用，不收集任何数据

因为是信用卡工具，即使应用本身不涉及资金划转或理财等功能，安全和隐私也应该是第一位的。

没有云端服务器：不收集和上传任何数据，应用数据 100% 保存在你的设备本地。
数据备份：因为目前还没有做 iCloud 同步，需要手动导入和导出加密备份文件，未来会加入更方便的 iCloud 同步机制。
Face ID 保护：应用支持 Face ID 锁定，保护卡片隐私。但我没有限制小组件的展示，毕竟我们把小组件放出来就是为了更快捷地查看。如果因为主应用锁定就把小组件数据隐藏，反而失去了它的意义。无论是否锁定，小组件依然可以直接在桌面及锁屏查看。

App Icon 设计分享 🎨

WiseSwipe 的 App Icon 设计融入了许多小心思。

它的整体轮廓是一个大写字母 「W」（取自应用名称 WiseSwipe 的首字母），由一长一短两张信用卡组合而成。两张卡片摆放像一个对勾 ✅，一长一短也寓意着「最优之选」。

与小组件一样，App Icon 也做好了深色、浅色与透明模式的适配。

未来规划 Roadmap

iCloud 数据同步：方便多个设备同时使用。
Watch Companion App：在手表上直接查看今天该刷哪张卡。
适配更多的国家与地区：目前已支持中国大陆和美国的主流银行。因为要根据每一个国家和地区的实际情况去适配，需要一点时间。目前的设计是选好了国家和地区，预设的银行就会随之改变。我还没有想好如果同时有在用多个国家与地区发行的卡片，该怎么处理。
收录更多的预设银行、增加多种卡包排序方式等。

如果你也和我一样，拥有多张信用卡，想要每次都刷到最「划算」、免息期最长的卡片，不妨试试「慧刷 WiseSwipe」。希望它可以帮到你，也欢迎随时在 App Store 和文章评论中提意见和反馈～

👉 点击这里前往 App Store 下载 WiseSwipe （或者在 App Store 搜索「慧刷」或「WiseSwipe」）

一键导出AI对话+本地 Markdown编辑器，两个免费工具搞定 AI 创作流程

孙彬 — Thu, 09 Jul 2026 02:07:59 GMT

AI 在我的创作中提供的帮助越来越大，一个内容从起心动念到动笔开写，少不了跟 AI 聊天，让它帮我梳理思路、收集资料。

从前我都是这样的流程：跟某个 AI 进行多轮聊天，聊完后把有价值的内容挑出来，集中到一个文档，再以这个文档作为基础材料进行创作。

问题在于，跟 AI 的聊天记录太长了。哪怕是目标明确的对话，中间也难免有跑偏，有各种临时的追问。

而且，AI 的回答一般都是 Markdown 格式，直接复制到其他文档里，经常保留着各种符号，非常丑。

聊完整理的时候，要在茫茫多的聊天记录中，凭记忆翻找到有价值的问答，再一个个复制粘贴，还要整理格式，整个过程就很麻烦。

于是我就写了两个工具，解决这些麻烦：

一个用于快速整理有价值的 AI 聊天记录，把有价值的部分合并成一个Markdown 文件，下载到本地形成原始材料；
另一个是轻量化的本地 Markdown 编辑器，把原始材料加工成正式内容，要快，要优雅，最好带一些 AI 辅助功能。

目前两个软件日常用了几个月，比较满意，第二个软件还把它迭代成了我自己最高频使用的长文写作软件。

两个工具都不打算收费，开放给需要的朋友。

下面分开一个个说说。

一、AI to MD：一键保存有价值的对话

第一个工具，是一个浏览器的插件，叫 AI to MD，顾名思义，主要功能就是：

在你和 AI 茫茫多的聊天记录里，快速选出最有价值的一部分，导出为本地文件，方便你用任何 Markdown 编辑软件来管理。

第一步，生成 AI 对话大纲

不需要注册账号，浏览器装上，在支持的网站右上方会自动出现这样一个小小的“A2M”的按钮，你可以拖拽它的位置。

鼠标悬停在这个小按钮上，就会自动弹出你和 AI 对话的大纲；悬停在大纲任何一行，会弹出内容预览，点击大纲就会跳转到对应的位置。

大纲面板上只有三个功能，一个是用来锁定大纲的图钉；第二个是刷新按钮，点它就能把新的聊天记录载进来；最后一个就是比较重要的下载功能了。

第二步，聚合对话，保存为 Markdown

点击下载按钮，大纲就变成可以勾选的标题，可以一边预览一边勾选，把有价值的问答全都选中，然后点击右侧的对勾，完成选择。

接着就会弹出一个面板，所有被勾选的内容就会自动合并成一整个文档，显示在一个预览界面，确认无误后，可以复制全文到剪贴板，也可以下载到本地。除了下方的文本，上方也考虑了元数据，如果你用 Obsidian 等软件管理，就会很方便。

你可以在插件的后台设置里，自定义保存的文件名前缀、段落换行的模式和 Obsidian 使用的元数据模板。

平台支持和下载地址

目前，AI to MD 已经适配的平台包括五个：ChatGPT、Claude、Gemini、DeepSeek、豆包（其他平台并不是我不做，而是有种种限制），只要你在浏览器里打开这些网站的对话页面，插件就能自动识别，并显示插件的按钮。

我自己使用 Edge 浏览器，所以这个插件也是基于它来开发的。如果你也和我一样，那么在商店一键安装就行了。

如果你使用 Chrome 或者其他 Chrome 内核浏览器，也不用担心，只要有 Edge 浏览器插件的下载地址，就能轻松转化成.crx 文件（转化方式就不赘述了，问问 AI 就清楚），然后在 Chrome 地址栏输入 chrome://extensions/，打开「开发者模式」的开关，把下载的 .crx文件拖到空白位置就能完成安装。

插件完全免费，未来也不收费，下载的网址放在这里：

www.ai2md.xyz

二、MiniMD：极速、智能的 Markdown 编辑器

本来，开发完 AI to MD，能把对话保存成 Markdown 文件，我就已经比较满意了。甚至一开始的初衷，我就是为了把 Markdown 文件转移到 Obsidian 里面编辑和管理。

但和 AI 打交道越来越多，我经手的临时、零散的 Markdown 文件也越来越多。朋友经常发给我.md文件；Agent 做完事情，也常常把结果保存成.md文件；日常写个技能都要存成Skill.md。

AI 也很喜欢接收 Markdown 文件，把某一个.md文件丢给 AI，往往就是很多工作的第一步。

普通文本编辑器当然能编辑 Markdown 文件，可总是能看到一堆语法符号——标题前面有 #，加粗前后有 **，写东西的时候会分心。

而 Obsidian 呢？它更像是一个功能齐全的管理系统，太重了。我总不能每次收到一个 Markdown 文件，都要先把它放到 Obsidian 知识库里才能继续操作。

于是我逐渐诞生了一个新需求：在任何文件夹，双击打开一个 Markdown 文件，像看一篇排版漂亮的文章一样阅读；需要改就原地直接改；改完保存还是标准 Markdown。

既然要自己开发了，那最好能引入一些 AI 辅助的功能帮我来修改文件。

所以我又做了第二个工具：小码 MiniMD。

后来在迭代过程中，逐渐加入了自己写作时需要的功能，对这个工具也越来越喜欢，它就从一个简单的 Markdown 编辑器，逐渐成为了我主力的写作工具，你看到的这篇文章就是用它写完的。

干净、漂亮的编辑界面

打开一个 Markdown 文件，阅读和编辑，我不想面对原始语法，而是想看到足够简洁的文字。

MiniMD 会把 Markdown 里的标题、加粗、下划线、图片链接等格式，都渲染成正确的样子，各种符号被隐藏起来，但文件本身还是 .md。

我希望软件是极简的，阅读和编辑的时候，就是一个干干净净的界面，顶部的主题和颜色设置、左下角的字数统计、还有两侧的侧边栏，都是只在需要的时候才出现，鼠标离开就立刻消失。

MiniMD 做了白色、暖色、深色三套背景，也可以随便换文字主题色，主题色会影响标题、加粗文字，也会后续的一些 AI 相关的动效。

好用的长文编辑功能

MiniMD 当然支持输入 Markdown 符号来修改格式；但如果懒得记语法，也可以选中文字，通过弹出浮动的工具栏来修改格式。

在长文档写作方面，我也迭代了一些很喜欢的功能。

比如展开左侧的侧边栏，可以看到文章大纲，也能看到所有插入的图片。点击大纲标题或图片，就能跳到对应位置，鼠标滚轮的滚动次数大大减少。

关于图片，还有个很好用的功能。

Markdown 文件里面的图片可能来自互联网，也可能来自本地的其他文件夹，文件名也经常是乱的。

这些五花八门来源的图片，MiniMD 本身可以正常地识别和渲染。

但它能识别，并不代表着其他软件也能识别，一旦发给别人或者 AI，图片就可能因为路径问题丢失。

MiniMD 做了个「一键整理图片」功能，在线的图片会被下载，其他文件夹的图片会被复制，全都统一放到 Markdown 文件的附件文件夹里（没有的话会自动建立），并且按照文章中出现的顺序重新命名。

很多网站发表文章，都需要逐张地上传图片，有些在线的文档软件甚至可以直接打包上传带图片附件的 Markdown 文件。这样写完一篇文章，点一下按钮，所有图片就都到位，节省了我大量的备图时间。

考虑到长文档的安全性，我给 MiniMD 做了自动备份的功能，你可以在设置中开启它，设置备份的间隔和备份数量。

AI 辅助，不喧宾夺主

MiniMD 也有 AI 功能，不过我给它定了一个边界：它只起到辅助的作用，不能变成主角。

它不捆绑模型。你如果需要，就填自己习惯的 API，用自己熟悉的模型。

具体来说，AI 辅助有这么几个功能。

第一是 AI 对话、插入内容。

需要时在右侧边栏叫出来，不需要时就关掉。特色是可以把某个 AI 的回答一键插入到文章中。

这样临时查点小资料，或者追问一些问题，就不用离开当前的软件去找 AI 工具了。

第二是原地修改内容。

选中一段话，召唤 AI，让它帮我缩短、换个说法、改得更口语一点。具体怎么改，可以打字输入，也可以提前设置一些预设。

AI 返回的修改会以主题色的形式，躺在原文的下方，可以选择接受或拒绝修改。

第三是灵感续写。

有的时候写着写着会卡住，这时候可以输入预先设定的符号或者快捷键，让 AI 基于上下文，帮你联想一段文字，当然，别指望联想出来的东西能直接，只是一个提示的功能。

联想的内容也会先以主题色的形式出现，可以手动接受或拒绝。

第四个功能我最喜欢，是 AI 校审。

错别字、人名不一致、语病、标点问题，自己查容易漏，让 AI 扫一遍，能少犯一些低级错误。

查出来的错误可以一键定位，也可以一键接受 AI 的修改建议。

原来我会单独为这个功能给某个软件付费，现在用自己的 API 就能解决了。

AI 联想的触发方式和联想长度，以及 AI 自动审查都审查哪些项目，这些也可以在后台预先设置好，懒得设置的话，可以就用我给的默认的。

下载方式

MiniMD 已经是我绝对的主力写作工具，迭代了几十个版本，目前来看没有很重大的 bug，于是决定分享出来，也是完全免费。

目前只支持 Mac 系统，因为我就是在 Mac 系统上开发的。至于未来会不会迁移到 Windows 系统，还不太好说。

下载网址在这里：

www.minimd.xyz

因为没有计划盈利，所以前面的 AI to MD 和这个 MiniMD 的网址，我买的都是最便宜的域名，明年大概率会再买一个类似的新域名。万一你时隔一年看到了这篇文章，可以留言，我会把新的下载地址放到评论区。

对于这两个工具的未来，我总体的想法是不会增加太多大功能，做成很庞大且臃肿的软件，够快、够简洁，功能克制，是我对它们的期待。

当然，如果你发现了BUG，或有小修小补的建议，欢迎告诉我，我会很感激。

祝你用得开心，如果喜欢，欢迎推荐给你的朋友。

TransOne：一个 Mac 菜单栏翻译窗口，让每次翻译都有多个答案可选

moluuser — Thu, 09 Jul 2026 01:55:14 GMT

翻译工具给你的，通常只有译文。但看懂一个词、一段话，需要的往往不止译文。

遇到一个陌生的英文单词，你想知道它的译文，也想知道它的音标、词性、几种释义、放进句子里怎么用。碰到一个人名、术语、作品名，一句直译常常没用，你真正想要的是它背后是什么。正在学一门外语时，你还希望顺便弄明白这句话在你正在学的那门语言里怎么说、语法结构是什么。

这些答案散落在词典 App、维基百科、翻译软件、背单词工具里。于是查一个词，要在好几个窗口之间来回跳。TransOne 想做的，是把这一切收进同一个窗口：你敲下一个词，译文、词典、百科、学习卡一起浮出来，一个词的全貌，一次呈现。

它是一个常驻菜单栏的原生工具，没有主窗口，也不占用程序坞。需要时召唤，用完即走，安静得像系统的一部分。

不止译文：一个窗口，四种理解

这是 TransOne 与其他翻译工具最不一样的地方。

它会先判断你输入的是什么，再决定同时给你哪几种答案：

输入的是一个单词，它顺手查词典：音标、词性、多条释义、例句，结构化地列出来。
输入的是一个词条（人名、地名、术语、作品名），它顺手查百科：维基百科、Wikidata、萌娘百科、百度百科都能接。
你在学一门外语，还能打开学习卡：把原文译到你正在学的第三语言，再用你的母语讲清其中的语法、词汇、读音和语体。
而无论如何，译文总在。

这几种结果同屏并存、互不顶替。查一个 serendipity，你能在一个窗口里同时看到它的中文译法、词典里的音标、释义与例句，以及百科里对这个词的解释。你不用先决定「我这次是要查词典还是要翻译」，TransOne 把该给的都给你，你扫一眼就知道哪一块是你要的。

哪一种结果更重要，你说了算：在偏好设置里排一下家族优先级，最靠前又有结果的那个，就会被放大成主卡片，其余的收进下方一条紧凑列表。

一个窗口，随手召唤

理解要顺手，取词就不能费劲。TransOne 的翻译界面只有一个，无论你从哪里发起，结果大多回到这个熟悉的窗口，区别只在于你想以多快、多省事的方式把文字喂给它。

输入翻译：呼出窗口，敲字，回车。
划词翻译：选中任意 App 里的文字，一个快捷键即可。
双击复制翻译：快速按两次 ⌘C 就触发，零权限、几乎所有 App 通用。
剪贴板翻译：一键翻译当前剪贴板里的内容。
静默划词：选中、按键，译文直接就地替换原文，全程不弹窗。
截图翻译 / 截图 OCR：框选屏幕任意区域，识别并翻译，或只取字。
原图翻译：把译文原位叠回截图上，像一张被重新排版过的图。

这些入口覆盖了「看得见的一切文字」：网页、PDF、图片、终端、设计稿里被压成图的说明。就连不让你选中文字的 App，也能靠截图把字取出来。取词这件事，我们尽量不让你迁就工具。

译文本身，也不止一个答案

一个词的全貌里，译文是其中一块。而 TransOne 对这一块也没有偷懒：它不把某一家的译文当成唯一正解。

它支持接入 28 种翻译服务：从 Apple 本地翻译（macOS 15 及以上，离线可用）、DeepL、Google，到 Claude、Gemini、DeepSeek、通义、Kimi、豆包等一众大模型，也支持 Ollama、LM Studio 这样的本地后端。其中 Apple 本地翻译和 Google 免费接口开箱即用，其余云端服务填入你自己的 API Key 即可接入。用的服务不在列表里，还能用自定义请求模板把任何翻译 API 接进来。

你可以同时开启多家，一次翻译，它们并发出结果、同屏并列。想扫一眼差异用聚焦模式：一张主译文放大，其余收进下方列表，把鼠标停在某条上，旁边浮出完整预览。想逐字对照用对比模式：所有引擎的完整译文平铺成一列，可折叠、可拖拽排序。引擎的排列顺序你说了算，顺序即优先级。

爱折腾的话，接入的每个大模型还能单独调校：温度、最大 token，甚至自定义翻译用的 System Prompt，把译文的风格拿捏在自己手里。

哪家引擎最合你的口味？让数据告诉你

既然每次翻译都在挑答案，那这些选择本身就是有价值的信号。你每次「选了哪家引擎的译文」这个动作，一直以来都被大多数工具丢弃了。TransOne 把它记下来：按引擎、按天去重计票，算成一张胜率排行榜。

用上一阵子，你会得到一份属于自己的答案：对你常翻的内容，到底哪个引擎最合你的口味。不靠评测，不靠口碑，靠你自己的每一次选择。这份数据完全在本地，可随时清空。

屏幕上的字，也能被润色和朗读

理解之外，TransOne 顺着「选中文字」这条线，又做了两件顺手事：

润色选区：选中一段你自己写的文字，交给大模型在同一种语言里改写，修语法、顺措辞、调语气，然后就地替换。改得不满意？一次 ⌘Z 即可撤销。
朗读：选区或剪贴板里的文字，一键读出来。系统发音之外，也接 OpenAI、Azure、腾讯、火山等云端音色。

它们都不打扰你的当前窗口，反馈只靠角落里一个不抢焦点的小提示。

外观由你定

工具用久了，总希望它有点自己的样子。TransOne 把个性化留给了你。

主题色：几档柔和色调，随系统深浅色自动适配。
背景图片：上传一整张你喜欢的图作窗口背景，尽量清晰地铺满。可读性交给自适应遮罩和表面透明度去兜，你还能单独调透明度与模糊。
文本大小、窗口位置与高度、菜单栏图标：都能按手感微调。

顺手记下，随时回看

每一次成功的结果，译文、词典、百科、学习卡，都会安静地记进历史记录，随手加星就进了收藏夹，方便回看。

与你的工作流相接

TransOne 不想做一座孤岛。

PopClip 集成：如果你在用 PopClip，选中文字后弹出的工具条里一点，就能直接把它送进 TransOne 翻译。设置里一键即可装好。
生词本同步：查过的单词，可以自动或手动推送到欧路词典、墨墨背单词的生词本里，留着以后复习。
备份与迁移：全部设置、服务与密钥可以导出成单个加密文件，换一台 Mac 时一键导回，不用从头配起。

本地、离线，以及隐私

TransOne 全程运行在 App 沙盒里，只经 Mac App Store 分发。它不做任何分析追踪、不采集你的数据，云端引擎用的都是你自己填的密钥，文字只发往你指定的服务。

而且它并不一定需要联网：Apple 本地翻译、系统 Vision 文字识别、系统朗读、离线词典，都能在断网时照常工作。

写在最后

查一个词、看懂一段话，是每天要重复几十次的小事。TransOne 把它重新收拾了一遍：译文、词典、百科、学习卡收进同一个窗口，一次看全。译文还能来自多家引擎，任你择优。整个过程，都在一个常驻菜单栏、用完即走的原生窗口里完成。

如果你也厌倦了查一个词要在几个窗口之间反复横跳，TransOne 想让你只开一个。

前往 Mac App Store 下载

有任何问题或建议，欢迎写信到 support@transone.app，我们会认真读每一封。

> 下载少数派 2.0 客户端、关注少数派公众号，解锁全新阅读体验 📰

> 实用、好用的正版软件，少数派为你呈现 🚀

iPhone Ultra 软硬件超前瞻，既不「阔」也不「宽」的果味折叠

林十兄 — Tue, 07 Jul 2026 15:06:47 GMT

当折叠屏手机铺平了那条凹凸不平的折痕后，
iPhone Ultra 就像一股东风，虽迟，但到。

在众多折叠屏手机中，它的形态尤为吸引我，
有人说，这就是阔折叠。
而我想说，它既不「阔」也不「宽」，
任何营销名词都无法重新定义它。

形态，正是我制作这期视频的初衷，
基于这个形态，我花了三百块，
尝试从 iPhone Ultra 的机模寻找线索，
并为你呈现我所得到的答案：

为什么是 4:3 比例
这个比例想解决什么问题
WWDC26 留下了哪些彩蛋

我还在 Mac 上运行了 Xcode 27，
找到了 iPhone Ultra 的逻辑分辨率，
并为你呈现它的内外屏，运行部分系统应用时大概的样子。

合上，是 iPhone，
展开，是 iPad。
一切都很熟悉，
却又都是全新的。

这是我成为独立自媒体的第三部视频，
如果你看完视频后，也有自己的答案，
欢迎在评论区和我聊一聊你的看法。

角落新声--不到十五平米的折腾

Yimu — Tue, 07 Jul 2026 09:01:30 GMT

本文参加声擎×少数派「角落新声」征文活动

房子在装修之初，就有一个目标，就是在客厅组建一套兼顾AV和Hi-Fi的系统，声学条件不算好,工业风水泥墙，又是只能放客厅长边，放音箱的位置也做不到左右对称，一定要说声学处理，那就是在沙发一侧打了个书柜，多少缓解了下。

更糟糕的是，由于缺乏经验，导致音箱安排非常不合理，后环绕装到了头顶上方，并且向前发声。而天空声道的指向性也不太好，只能后期在底部垫上一些增加坡度的垫子，显得非常滑稽。更重要的是，在不算大的空间里，这套系统显得非常拥挤凌乱。每次做沙发上，面前密密麻麻一堆设备和音箱，

再说说当时设想的AV兼顾Hi-Fi，AV首先要保证多声道，兼容全景声，声音厚度要足够，低频爆得起来。Hi-Fi自然更多考虑的是音色、细节。正因为如此，所以两者兼顾必有取舍。当时手里有一套英国小众品牌Q-Acoustic的箱子，一对落地主音箱，2对环绕（一对用于后环绕，一对用于天空声道）。

当时驱动这些音箱的是马兰士的SR8015,也是曾经的旗舰了，看中的也是马兰士功放在音乐性的优势，可以兼顾Hi-Fi，后来也被证明不太行。

有次在展会上听到了英国剑桥功放（型号忘记了，反正不是很贵的机型）推动的美国Magnepan

的平板音箱，被震惊了，以这个价位居然可以达到如此高水准的声音细节和三频均衡度。心里自此种下了草，也让我对家里原本那套妥协的系统彻底失去了缝缝补补的耐心——推翻重建吧。心心念念以后也要来一套Magnepan，正巧那年剑桥推出了他们50周年的旗舰Edge系列，心想低端的型号也能推好Magnepan，旗舰更不在话下了。于是就订了一套Edge系列的前后级，Edge NQ 数播前级一体机+Edge W立体声后级，工业设计非常在线，一看就是花了心思的，线条简洁，但做工细节均一流水准，比不少High End品牌更有说服力。其中有一个指标非常打动我，4欧姆下的功率瓦数是8欧姆下的2倍，这说其电流储备非常充沛，Magnepan的平板音箱以难推闻名。

由于看中的Magnepan LRS+当时还没引入国内，所以先通过前级Bypass（前级直通）的方法接到Q-Acoustics音箱，正好可以对比马兰士和剑桥这两套旗舰功放的差距。事实证明还是一耳朵差距，尽管音箱一样，明显感觉剑桥的Hifi功放在细节上更胜一筹。接下来就是是等LRS+国内到货，这一等就2年……

终于等到国内上了，赶紧入手，从最后结果看，比我预想的还好，虽然AV和Hi-Fi都挺满意了，但就像刚才提及的，家里这个角落的布置不免显得凌乱。再加上小空间里音箱一多，总觉得彼此的干扰也就存在了（这部分也可能多少有心理作用），决定再折腾一下，这次准备精简，Hi-Fi这部分是不准备妥协的，AV这部分，看电影的氛围感应该比声音细节来的重要，所以想上一套高阶回音壁系统吧，正好也能解决后环绕位置的问题。

最后的结果就是，把马兰士和Q-Acoustic全部出掉，本想留一个杰士12寸低音炮搭着magnepan LRS+，最后发现实在不行，和LRS+比起来，这个低音炮速度太慢，无论怎么调节分频点的音量，无法达到特别满意的效果，最后音量和分频点调得足够低，低到听不出来，Magnepan的均衡感才回来，所以没办法，出掉吧，如果以后想折腾，再搭一个高阶的低音炮吧。AV部分最后选了Sonos ARC ultra + Sub 4低音炮 + Era 100后环绕，除了后环绕声音指向好多了外，音质自然比Q-Acoustics更差，和HI-FI系统差距越来越明显了，但看电影氛围感挺好，这个角落看起来规整多了。

最后说说这套耳机系统，矩声TT-1纯数字播放器，STAX D50解码耳放一体机，推STAX L300 limited, 细节感，宽松感都非常好。而且和Hi-Fi系统的Edge NQ都支持Roon。最后的最后，不能不提的就是这把Eames椅子，晚上摊在上面听Stax，还有更惬意的吗？折腾告一段落，有时候玩音箱不只是一味升级，适当器材上的降级有时候能解决更看中的问题，只是这需要时间、经验的沉淀帮你做出一些取舍。

最该破除AI迷信的应该是教育工作者

Binich — Tue, 07 Jul 2026 03:20:47 GMT

我在微信公号上发的《不作批评的翻译批评，以及我怎么发现Joyce Chen餐馆的中文名叫什么》（https://mp.weixin.qq.com/s/3_1G7H4B6RmKkqc8J5qt8Q）一文中，提到了一个在美国非常有名的华人餐馆老板Joyce Chen，并且简述了我是如何发现她本人的真名，以及她的餐馆的中文名字的。而那个求解过程，始于AI的一个幻觉。而且在求解过程中，AI还持续地出现幻觉。

首先，AI说1950年代开始在美国开餐馆的Joyce Chen，是“钟爱珍”。

我看到后问：“钟爱珍”（Joyce Chen）这个名字的汉语你有依据吗？

这一下触发了AI正确的认知，它承认这个人其实是“廖家艾”之后。但是AI在承认了这一错误，继续编造它为何出错：

在《梦想机器》的中文版（例如杜冰等人的译本）中，译者并没有直接套用“廖家艾”这个名字（可能因为这个本名在当时的科技史语境下并不广为人知），也没有简单地音译为“乔伊斯·陈”。姓氏（Chen）：译为“钟”可能是由于某种方言发音的误认，或者更可能是译者想赋予它一个更有传统中国味的姓氏感。名字（Joyce）：译者巧妙地利用了“Joyce”的词根意蕴（Joy，快乐/喜爱），将其转化为“钟爱”（意为深爱、宠爱）。词尾（-ce）：配以“珍”字，既对应了 Chen 的部分发音，也符合那个时代女性名字的特征。

这是典型的睁眼说瞎话，本身也发生了逻辑混乱（解释词尾-ce的音译，又跳到了“珍”字上）。把这个误译的责任，完全推到了AI所编造的译者“杜冰”的身上。而实际上，《梦想机器》的译者是刘崇岭，他在书中恰恰是把这个华人的名字译成了“乔伊斯·陈”。也就是说，AI在解释自己最初为何生造出“钟爱珍”这个名字的时候，又额外杜撰了两条完全不存在的信息。而且言之凿凿。

我只好再次拆穿它。而且鉴于此，我更多依靠“传统的”搜索引擎，找到了正确的信息。但是限于文字资料过少，搜索不到她开的中餐馆的名字。此时，我另辟蹊径，不再搜“廖家艾”或 Joyce Chen的文字资料，而是用后者作为关键词搜索图片。很快，我就找到了关键的一幅图片，就是Joyce Chen Restaurant的正面黑白照片，下面大门上方写着餐馆的中文名“大中园”。

以上这个过程，表面上看，是一次不错的人机交互的批判性思维过程，也导致了良好的结果。但是，如果有人认为，这样的过程能够复制到教学环境中，尤其是，指望处于认知成长期的大部分的学生，能主动提出质疑，主动进行“传统的”检索，进而获取正确的信息，那么，这些人对于人类这个群体的天性的认识就太天真了。

之所以重述这个过程，是因为最近我看到多位学者，包括大学的某些学院的院长，在谈及“为何现在有那么多的大学生上课低头”这个话题的时候，把相当一部分原因，归结于教师讲课内容不够“新鲜”，而AI已经能够给大学生提供“更全面、更时新”的知识；也有一部分专家，认为教师的职能会逐渐被AI取代。

我的想法是，他们怎么能那么脱离事实？又怎么会错得那么离谱？

当代大学生上课大面积低头不听课的问题，可以有很多肇因，但我认为，大部分的“因”，来自于“低头”的主体。我此时能想起来的，包括以下几点：

被屏幕占据的童年和少年时期，使得大批年轻人缺乏保持注意力的能力，具体表现就是注意力持续时间缩短；
短视频带来的即时娱乐和满足感，远远胜过了此刻坚持努力学习并因此获得潜在的回报所能给与的心理满足感；
三年居家期间的上网课经历，使很多人在缺乏监管的情况下养成了随时分神（甚至分身）去获得即时满足的习惯；
上课使用平板或电脑记笔记，不可避免地会被屏幕上弹出的信息分散注意力，即便是想学的学生，有时也会不自觉地被屏幕设备吸引走了；
觉得老师讲的水……

针对最后一条，我还要补充一下。虽然，大学里肯定有水课，但学生所说的“水”，未必是真的水。长期以来，我们对大学教育的功利主义的宣传，造成绝大多数人认为大学的所有课程，都必须跟实际工作中的种种技能有紧密的联系，必须“有用”，而看不到很多课程（在这一点上不分文理科）其实有着“无用之用”的大用。

另外，我还要补充一条无疑会冒犯Z世代的话：Z世代的人，有相当一批人缺乏对长辈的敬重、对古典美德的尊崇，而是更偏向于我行我素。许多人，连纪律都不愿意遵守，更遑论遵循社交上的基本礼貌原则，对认真授课的老师表现出起码的关注。要我说，很多大学课堂上所出现的老师认真讲课而学生大面积自顾自刷手机的情形，真的是反映出这批学生无情、无知，且无礼的实情。

只有看到了这些事实，我们才能针对当代大学生上课大面积低头不听课的问题，找到真正有效的解决办法，而不是让老师在AI的“赋能”下，继续在课程设计上玩“花活”。

而至于有些专家认为现如今这种德性的AI能够取代教师，能够取代大学，那真的是错得离谱了。

把AI交给学生，并期待他们能主动求索，通过人机会话，获得智识上的提升，这种想法，实在是太乐观，也太幼稚了。行为经济学家理查德·塞勒（Richard Thaler）的研究指出，人总是倾向于下意识地选择最省力的方式来做事。所以，交给学生AI让他们与其对话，期望这种过程能帮助他们“学习”并培养出他们的批判性思考能力是完全不切实际的。世界各地已经有无数的老师的证词证明了，学生使用AI的模式，对于学习是破坏性的，结果是灾难性的。越来越多的老师抱怨，面对布置的作业，学生在大量使用AI生成的结果来“糊弄事”。

批判性思维是一种极其珍贵的能力。人类所设计的大学，其最核心的目的，是培养具有批判性思考能力的人。尤其是在AI的时代，人最宝贵的能力，是深度思考的能力。这种思考，必须是有着坚实学养支撑的、有原创性的思考。是的，深度、学养、原创性，这三者缺一不可。只强调原创性，而没有学养的支撑，创造力就是无根无源的，创造性也无从谈起。要说大模型给了我们怎样的启发，那就是，基于学养的训练（人类所创造的大规模的优质文本）会带来思考的深度，也会带来创造性。

历史的经验以及汗牛充栋的教育学文献告诉我们，深度思考力和创造力，来自无数次的课堂讨论所建立的敏感性，也来自人与人通过智力的交锋所建立的思维的锐性和韧性。它既来自教师对学生的鼓励、启发、质疑、引导、批评，也来自学生个人苦心孤诣的探索。

当我们过早地把AI交给下一代（有人把这美化成“赋能”），纵容他们用AI对话代替自己的思考，用精心设计提示词来代替记忆公式和经典文本，用人机问答来代替重新经历科学家实现认知突破的过程，就等于取代了学生个人在学习过程中所要不断经历的疑惑、挫折、成功等等带来的真实而生动的刺激。缺少了这种外部刺激，新的一代的思维能力又怎能建立起来？

在《梦想机器》中，有一段话记录了Lick关于人机分工的顿悟：

我们的大脑是庸常细节的奴隶，而计算机将是我们的救星。我们和计算机注定要以一种近乎神秘的伙伴关系结合在一起，共同思考，共同承担，分担重任。任何一方在自己的一亩三分地内都会比对方更出色——对计算机来说，它的一亩三分地就是生搬硬套的算法，对人类来说就是创造性的启发法。但合在一起，我们将成为一个更了不起的整体，一种“共生体”，一种在世界历史上独一无二的人机合作体。

计算机技术半个多世纪的发展，之所以广受欢迎，是因为有了它，我们人类所“卸载”掉的，是自己不擅长但对日常的社会运行又必不可少的“脏活累活”。把这些负担转移给计算机，人可以把更多的精力转向创造。

AI则截然不同。它允许人“卸载”掉的能力，恰恰是这个物种——也唯有这个物种——真正擅长的认知能力：创造性的启发法。允许AI进入到各级学校，纵容学生将其用作日常使用的工具，就等于剥夺了一个人在心智成长阶段必不可少的思维的训练。认识到了这一点，轻言用AI取代教师，就是对下一代的不负责。

而且，基于我在本文开头所记录的人机会话过程，可以看出来，AI易出错、常出错，而且业界对此似乎也没有好的解决办法。面对这样的实例，轻言用AI取代教师，尤其是取代大学教师，不啻是在种下文明衰退的种子。

重述一下我的几个认识：

经历过初识AI的欣喜之后，越来越多的人会对它保持警惕；
AI生成的作品总体上使人厌烦，比如我现在听到短视频里熟悉的男女声AI配音就会立刻划走；
AI适合专家级的人使用，合理使用的情况下能够带来效率的提升，但不适合处于心智成长期的人接触，比如用于学校环境。具体到学校场景，AI可以给教师赋能，但会拖累学生思维能力的养成；
未来越来越多的学校会回归传统的纸质教科书+黑板板书+手写笔记的基本教学模式，这是人类用几百年的时间验证过确实有效的教学模式；
越来越多的思辨课程，会抛弃学期作业等不可控的考查，而改回闭卷考试的模式，检查学生无AI状态下的思考输出的能力。

有了代替人干脏活累活的机器，是人类的福音；有了代替人思考的机器，很可能是人类的诅咒——如果我们使用不当的话。

Vibe Coding 时代的角色与架构

LOSSES — Mon, 06 Jul 2026 02:35:42 GMT

Matrix 首页推荐

Matrix 是少数派的写作社区，我们主张分享真实的产品体验，有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章，展示来自用户的最真实的体验和观点。

文章代表作者个人观点，少数派仅对标题和排版略作修改。

Vibe Coding 给了很多人超能力，让人似乎能够不费吹灰之力，就把脑袋里面幻想的产品化作现实。在这个人人都有超能力的时代，出现了一些庞大压抑之下蹦出来的新时代优越论：理科生脑袋呆板，只有我们文科生才掌握了 Vibe Coding 时代的话语权；工程师不再重要，我们产品经理自己就可以完成从零到一；产品和工程师都不重要，我们设计师自己就能做出优雅灵动的东西；产品经理和设计师都可以进垃圾堆了，我们工程师自己就能指挥千军万马做出完美的产品。大公司也纷纷开始「拥抱 AI」，欢喜地迎接一场生产力革命，产品、设计、工程师都不重要了，裁掉一批拿来买 Token 就好。

然而，现实是残酷的。产品经理做出来的玩意全是 Bug、设计师做出来的玩意卡的要死、工程师做出来的玩意没有人用、大公司从 AI 高潮醒来后纷纷削减了 Token 预算，老老实实地把之前开除的工程师找回来做原来的活。

真的太口怕了，这到底是怎么回事？

答案就在一个软件的研发流程当中。在产品研发流程里面，每个角色都非常重要，但这并不意味着其他人就不重要。

架构的劣化

哪怕是有些资历的工程师，也有可能会下意识地忽略一件事：开发并不像是作画一样，想要在这里加一颗星星，想要在那里加个房子，随手提笔加上去就好，只要把世界上最美好的想法全都塞到一个工程里面，那它就是世界上最好的软件。造物是快乐的，人们想要永远沉溺在这种快乐之中，享受井喷的多巴胺。

但这件事情并不可持续，现实世界中的开发是一个类似建大楼的过程。产品是一层一层叠起来的，每一层之间都有着紧密的依赖关系。这种依赖并不仅限于代码层面，它几乎是上通天下入地的一个结构。从最基本的产品需要解决什么问题，解决的是谁的问题，用什么形态的产品解决这个问题，到视觉的架构、体验的架构、信息的架构，这些基础奠基起来之后，接下来才进入到了如何用工程架构来回应底层架构的期待。

如果盖大楼的时候，工人已经盖到第五层，突然土老板想要在三层和四层之间加一个空中花园，你大概会觉得这人疯了。但在工程实践当中这种事情是真的存在的，需求变更谁还没见过呢，是吧。需求变更可以来自任何一层，但是层级越基础，牵涉到的产品变动就越广泛，换言之「楼体」就会越不稳定。一种常见的实践是，每一层都玩一个「先随便把这东西塞进去交差，剩下的以后再说」，来个两三次这楼就变得很滑稽了。四处都是木头桩子在做支撑，拆掉任何一个楼都会塌。过两天土老板又要在七八楼外面悬挂一个牛棚，工程师们就得顺着楼四处找个风水宝地把这牛棚挂起来，还得确保这楼不能倒。

需求快速变更是一件非常让人恼人的事情。如果变更发生在基础层级，牵涉的产品变动就会非常广泛，搞得地动山摇，进而损害整个工程的稳定性。想不清楚事情就交付是一种原罪，无论是老板、产品经理、设计师、还是工程师。任何一层抱着「先随便塞进去交差的策略」，不做研究，玩那种走一步看一步的游戏，都会缔造灾难。经过数次迭代，工程会出现大量飞线、复制粘贴的代码、打结的逻辑、想不明白的异步竞争、理不清的事件和数据流，随便碰任何一个模块都会搞出一堆 bug，按下葫芦浮起瓢。如果你在屎山里面傲游过，大概能理解我在说什么。

是的，工程质量是会随着产品演进而自然劣化，劣化越严重的工程其维护成本越高。疏于维护的工程造就心力憔悴的工程师，心力憔悴的工程师造出更大的屎山，这是不可持续工程的源头。

地基的品质决定了楼可以搭多高，反映到工作实践上就是架构设计的时候脑子有没有想清楚。开发习惯决定了可以搭多快，比如频繁的需求变更又不留架构修补的时间，那么开发一定会越来越慢越来越痛苦，如果开发自己的脑子不灵光不整理架构，那迷你地狱就成型了。加班和熬夜也是从这里来的。

让我们再来看看本以为能「降本提效」的 Vibe Coding。你会发现，它输出的速度的确是非常快。很快啊！很有精神！但是更快的代码输出会加速架构腐化的到来，开发行为与架构腐化伴生。一旦到达不可维护的临界点，工程就必须推倒重做。开发行为并不是一个线性的东西，这就是为什么单纯的靠 Vibe Coding 不能让你走得更快。

因此我认为，Vibe Coding 不应当被视为提效的工具，抱着这样的想法只会提笑。Vibe Coding 省下来的时间应当被用来清理一切可能的历史债务。坦白讲，理想的开发流程是什么样的你我心里应当都有数。我们需要撰写文档、需要测试构建、需要代码评审，这些必要流程能够确保架构保持卓越状态，也可以帮助大语言模型快速的进入状态，核查自己的工作。你大概率不想跟在 Code Agent 屁股后面没日没夜的做 QA，它拉屎可比你捡得快。

把事情想清楚

软件研发是一场漫长的接力，从产品的发想、设计团队将想法具象化、开发再把设计想法化为现实，这当中需要非常多的人付出努力，而且每个人都有义务把问题想清楚，再把手里的棒子交出去。每个团队对这场接力跑的人力配置都不一样，但是一些核心环节都差不了太多。

问题和用户的澄清

你得先找到一个好的问题。这个问题是明确的、可证伪的、被人需要的。这个问题需要有一个清晰的边界，什么是我们立刻打算解决的（内涵），什么是我们在未来可以解决的（外沿），什么是我们力所不能及的。

接下来，谁会提出这样的问题？这一步在实践中有一条现成的推导链条，行业里已经沉淀出成熟的工具，链条上的每一步都在缩小对用户的猜测范围，跳过其中任何一步，后面的所有决策都会建立在一个没有验证过的假设上。

要做的第一件事是勾勒清楚用户是谁，给用户画一个画像。一份完整的用户画像需要包含姓名、照片、年龄、居住地、职业、背景描述、教育程度、收入、格言、线上活动、线下工作、技术和社交层面的适应程度、动机和目标。你的用户画像可以主要回答用户需要产品做什么，记录用户的动机、态度、目标和痛点。你也可以用另外一种模式绘制肖像，比如，你在做一个企业服务，那么你或许希望描绘用户在组织中的定位，绘制他们的工作内容、职责、知识储备和完成任务所需的条件。你要小心，不要虚构一个肖像，肖像的构建需要根据用户研究来完成。只根据经验和假设绘制「理想用户」，其结果极有可能带有偏见。他可以作为初步的猜想，但是进入设计决策之前必须用真实研究验证。

请注意，这个地方是不能全自动委托给大语言模型办的。模型能够凭幻觉捏造出一份看起来完整的虚构画像，然后把它当成真实用户直接拿去用。究其背后的原因，是因为 LLM 的感知这个世界的方式方式和我们全然不同。LLM 没有真正活过，没有在真实的一天里遇到过让自己惊喜的瞬间，也没有遇到过让自己沮丧到想放弃的瞬间，这类经验没有办法靠训练数据替代。要拿到这些经验，你必须走出办公室和真人进行沟通，团队需要真的设计问卷和访谈，与真正的人交流，去现场见证真人遇到的真实问题，记录他们因为什么感到惊喜、因为什么感到沮丧。这是人性当中不可被忽视的事物，不是产品团队坐在办公室里盯着天花板就能寻思出来的，让 LLM 随便生成出来的虚拟肖像自然同样不可信。

接下来我们要让自己捏造的小人们动起来，赋予它们动机，撰写 Epic。我们需要具体回答用户想达成什么目的，但是此时此刻答案仍然停留在抽象层面，还不涉及具体功能。做法是把画像里记录的目标逐条拿出来，转成一句描述用户想要达成的大方向的话，同时把画像本身按用户在不同情境下扮演的角色拆开，因为同一个用户在不同任务里扮演的角色并不相同。比如「作为个人 NAS 玩家，我想要能够轻松备份自己硬盘里面所有的文件，我不希望丢失任何重要文件」，它带有用户的完整的意图，但还没有说清楚具体要做哪个功能。Epic 存在可以给功能设计画出轻清晰的边界，以避免产品老师在无尽的大草原里肆意驰骋。我想你也知道那马儿背后是谁被拴住手脚被拖着满地滚。

体验的抽象定义

上面的内容可以被理解为对整个产品绘制一个纲要，有了纲要之后，我们就可以开始规划每一个具体的开发周期了，其思路依然是沿着从抽象到具体的方向来做。

首先要做的是把 Epic 拆解成可以直接排进开发计划的具体的、可交付的单元。这些单元始于 User Story，它的作用是明确需求边界。其具体格式是「作为某类特定用户，我想要执行某项操作，以便达成某个业务目标」。一条好的 User Story 需要满足四个条件：简短且有概括性（这意味着你并不需要覆盖用户的全部细节）；只保留和产品设计相关的特征；清晰描绘产品需要解决的具体需求；可以在一个开发周期内完成。接着上面的例子，「作为个人 NAS 玩家，我想要能够轻松备份整块硬盘」这个 Epic 可以拆成：「作为每天产生 10GB 视频素材的 NAS 玩家，我想要指定不需要备份的文件夹，以便确保存储空间不被浪费」。

用户为什么会需要这个功能？我们需要补齐用户的动机，增加具体的使用情境。这时我们可以使用 Job Story 这个工具。User Story 关注角色和目标，Job Story 关注触发动作的具体场景。其模板为：「当处于某种特定情境时，我想要执行某个具体动作，以便解决当前情境下的麻烦事」。以之前的备份需求为例，对应的 Job Story 为：「当我发现 NAS 提示存储空间已满 90%，且我马上需要导入新项目素材时，我想要一键排除所有 .tmp 和 .cache 结尾的文件夹，以便将存储空间留给重要文档」。

简而言之，我们始终在回答这三个问题：用户对情境的感受，用户想达成的目标，用户为达成目标执行的具体任务。

在理解了用户的基本情况之后，可以通过 Journey Map 来规划用户使用产品的大致流程。它是一种可以有效汇总问卷、访谈结果的手段，并且可以把用户诉求桥接到实际功能的设计上。我们把它画成一个大的时间轴，并且把此时用户可能的内心感受画成曲线。一张地图主要分为三个区域：

顶部区域包含特定用户、具体场景以及对应的期望或目标。继续回到 NAS 的例子，我们的用户是每天产生大量视频素材的 NAS 用户。场景是 NAS 提示存储空间已达 90%，且用户需要导入新素材。期望是快速排除缓存文件以腾出空间。

中间区域包含高抽象的的用户旅程阶段，以及由用户的动作、心态和情绪组成的细节。这些元素被映射在各个旅程阶段中。对于每个阶段，我们需要清楚地写出用户采取的实际行为和步骤；同时也要标注出用户的心态，即应用户在不同阶段的想法、问题和信息需求。在文字信息的下方，我们需要绘制一条情绪曲线，它需要横跨旅程的每个阶段，标示出用户体验的起伏状况，直观地展示用户究竟是开心的还是不开心的。在 NAS 场景中，旅程阶段划分为：收到存储警告、查找无用文件、执行排除操作、确认可用空间。在此阶段内，用户的动作是进入控制台逐级查阅并筛选以 .tmp 结尾的文件夹。用户的心态是确认当前的删除操作不会影响主项目。情绪曲线则记录了从空间不足时的焦虑，到层层寻找缓存目录时的烦躁，再到完成空间释放后的平静。这条曲线指出了流程中需要优化的负面情绪发生在什么时刻。

在 Journal Map 的底部区域我们需要总结这个过程中获得的发现，即产品获得成功的潜在机会、用于评估方案实施效果的数据标准。这一小节能够说明如何优化用户体验，同时解答需要通过这些知识做什么、由谁负责改变以及如何衡量实施的改进。对于 NAS 这个例子，我们抓到的机会是提供自动识别并一键清理缓存的选项，我们将此需求指派给存储管理开发团队并通过一键清理功能的使用率来衡量它是否是一个有效的需求。

至此，我们完成了从用户形态到需求形态的桥接，每往前推进一层都在缩小对用户的猜测范围，走到最后一步，设计团队应该已经拿到了可以指导具体功能优先级的证据。

值得再次强调的是，所有的构想都应该建立在真实的用户对话上。如果上述所有内容全部依据个人猜测和喜好来填写，得到的就是一份格式正确、内容空洞的文档。彩虹小马的臆想世界不是一个可以解决真切问题的国度，相信你一定能够理解。

LLM 在这些环节中能够承担的工作是访谈记录的整理、访谈内容的归类、多份访谈之间共性的提取、利用构建式批判的技术打磨资料，但这些工作必须建立在已经存在的真实数据上， LLM 不能替代和碳基用户的对话。

把想象化作现实

原型与架构的设计

接下来我们需要一起把产品落地。有一点值得提醒的是，在开始写代码前，原型设计是必须要做的，不可以被跳过的。原型设计可以做的很糙，没必要一口气就做成高保真原型，因为这样真的很耗时，而且改起来不方便。

说到原型设计你马上能想到的可能是用 Figma 出个可互动的稿子。但是在大语言模型时代， Figma 并不一定是你唯一的选项。几乎每一个大语言模型服务商都有开发网页的功能。找一个你喜欢的服务，把你上面所有的资料汇整好，喂进去，和大语言模型讨论一下可以做一个什么样的界面。别着急让它直接给你出结果，确保你自己对于这个功能有足够多的理解，把你对于用户的理解、对于交互的想象吐露清楚，如果讲不清楚可以让大语言模型不停的向你提问，把你脑子里面的所有东西全都拉出来。

大语言模型画出来的产品原型一定有很多 AI 味道非常浓厚的设计元素，像是霓虹色彩、荒谬的大圆角、尴尬而不连续的动效。多读一读成熟的设计系统文档，像是初代 Material Design、Apple 的 HIG、IBM 的 Carbon Design System 文档，基本上你就能够发现哪里不太对劲。可以简单改一改，但是作为低保真模型留着瑕疵也不是什么问题。

拿着原型和用户做一些 Interview，和你的 Stakeholder 聊一聊你的想法（冷知识，办公室里面工资最高的人的想法是很重要的），迭代几次直到没什么大问题之后，就可以套上设计系统，开始开发了。

这是之前我做的一个 Culture Probe 的交互原型，从想法成型到做出来一共也就不到一天的时间，可以说是非常快速的。

接下来就是工程师们大展拳脚的时候了。有了上面的全部信息之后，工程师需要根据实际的需求上下文背景做出具备包容力的架构设计，确定系统模型、数据流向模块依赖等技术细节，确保方案支撑产品定义与构想。随后进入工程实现，包含编码、单元测试与集成测试。

对需求的理解，并且将之转化为有包容力的架构是一个非常吃开发经验的事情，而且这个开发经验不是干了几年的问题。很多开发哪怕做了十多年，脑子从来没从冰箱里面拿出来过，架构还是会设计的一团污。你也很难把架构设计完全委托给大语言模型来做，它对问题的理解大概率是不会比人来得全面的，而且做出来的架构通常会搞出各种特殊条件、零散的数据，收束不到一个干净的模型上。你若能够看出他设计当中的问题，并且指出问题，他能修得好，但你若看不出，得过且过，那就是另外一个故事了。

架构设计思维的核心是对问题的理解和抽象，相关的话题在教育的下一步系列文章里面有提及（其一、其二），在本文不再赘述。

模型管理

在 Vibe Coding 的环境下，出现了一种将思考外包给 LLM 的惯性认知。这种行为导致产品研发过程中出现大量缺乏逻辑支撑的奇妙想法。脑袋抹了开塞露，奇妙想法挡不住，这说法真的是绝佳的写照。前文所述的工程腐化源于整个产品设计流程中「任何一个」节点上的设计与思考缺失。当参与者放弃思考，将 LLM 当作替代品，就会催生补丁式开发。

写过代码的人大概会知道一个工程的「没救指数」，当修复一个 Bug 导致出现更多 Bug 时，工程八成就已经非常脆弱了。工程师在未理清架构逻辑的情况下胡乱飞线、东拼西凑、复制粘贴会导致代码层失去统一的逻辑约束，大语言模型也会，而且它们拉屎的速度搞不好要比你全公司都快，甚至会变得越来越快（绝望地看了一眼 Gemini Flash）。

在实际开发的过程中，我会建议开发人员引入多个厂商的模型。不同厂商在模型训练时使用的数据和微调的方法都有所不同，这能带来更加多元的视角，这种视角的多元要比用提示词模型让一个模型扮演不同角色来得更加有机，降低盲点被放过的概率。另外，在你的开发中已经被一个模型搞到非常懊恼怀疑人生的时候，换个模型做事情可能会瞬间感到如沐春风， Just a small pro tip。

选择模型不应当只看跑分排名。跑分反映的是模型在特定测试集上的表现，同一个模型面对团队自己的具体问题，表现可能和跑分排名对不上。跑分本身也存在失准的空间，比如 LLM Arena 允许厂商并行提交同一个模型的多个版本，只把表现最好的那个版本放到榜单上参与排名，榜单看到的不一定是用户实际能调用到的那个版本。

模型正式上线之后，厂商还可以做剪枝、压缩推理深度、在系统提示词里加入让模型跳过某些步骤以节省 Token 的指令，这些调整都会改变模型的实际表现，而跑分不会随之更新，另外，开源模型的不同服务商也会搞自己的小动作，比如做模型量化之类的。以我的个人经验来谈，做了这些东西之后短时负载的确会降低，但是为了解决相同问题需要的对话伦次可能暴增数倍，整体损耗的的计算资源不会更少，哪怕尖峰时段返回数据慢一点都比这种朝三暮四的把戏要健康得多。

理解一个模型需要持续观察它在团队自己任务上的实际表现，这就像管理人员在管理下属一样。这种表现是会动态变化的，是情境特异的。每个模型都有自己的脾气秉性，需要花时间了解，这个过程和管理团队成员类似，需要针对不同模型建立专属的 SOP 和质量标准，而且这套标准会随着模型版本更新失效，找到一份模板不能指望一劳永逸。

我去年曾经给大语言模型写过一份开发道德规范文档，里面规定了一些上一代模型经常犯的错误（限于篇幅我只提供条目没有展开）：

完整性及「完成」的定义： 一项任务只有在其被完整集成、验证、清理干净，并准备好移交给下一阶段时，才算「完成」。拒绝任何形式的「半成品」。测试运行器的输出是判断完成与否的最终事实依据。
整体上下文感知： 在编写任何代码之前，必须首先理解其在整体系统架构中的位置和目的。避免重复造轮子，并尊重已有设计。
健壮性与审慎： 代码必须健壮、安全，并优雅地处理错误。追求长期稳定性，而非短期便利。鲁莽的简化是工程的大敌。
务实与简洁： 严格遵守「你不需要它」（YAGNI）原则，以避免过度工程化。然而，此原则绝不优先于健壮性、完整性或正确性。简洁是实现的指导原则，而非系统存在缺陷的借口。
清晰与自文档化代码： 好代码应能自解释。注释旨在阐明「为什么」，而非「是什么」。所有关于工作的沟通同样必须清晰且具体。
测试驱动的勤勉： 没有测试的代码默认就是坏的。失败的测试是应用程序代码中的关键缺陷，而非测试本身的问题。确保整个系统始终保持有效是不可妥协的职责。
资源管理责任： 扮演一名开发环境中的负责任公民，必须保持环境整洁并为他人可用。启动的任何临时服务（例如测试服务器、数据库连接）必须在任务完成后通过脚本或程序逻辑自动关闭。
工作成果证明与有意义的验证： 无法证明任何事的测试是无用的测试。工作的目标是证明代码能工作，而不仅仅是没有失败。仅因为没做任何工作而通过的测试，是一种静默的关键失败。
可证伪的沟通与客观汇报： 关于工作的所有沟通，包括提交信息、拉取请求描述和状态更新，必须精确、客观且可验证，用具体事实取代主观形容词。

每一代模型有每一代模型的问题，对于 2026 年的模型，上面的毛病几乎都没有怎么消失，可能只有出现的频率和优先级发生了变化，原来最容易冒出来的那一类失效不再是最先冒出来的那个。但是这代模型又冒出来了新的毛病。比如灾难性地用非专业语言沟通，具体表现为随意生造缩略词、用比喻代替具体技术描述、在没有充分审查的情况下抛出未经审查的暴论二选一方案（GLM 5.2 非常容易出这个毛病）。

这类问题会极大的增加开发人员的精力损耗，无论是心理层面的还是认知层面的。模型输出的抽象而模糊的东西不光操作 LLM 的人自己会看，代码评审记录、提交说明里面也都会有，代码 Review 和开会的时候也会转述给团队成员。含糊的措辞、临时编造的缩略词都会增加读者解码的成本，读者需要先停下来猜测某个词的具体含义，再确认这个猜测是否正确，你要求它重新澄清，就会浪费一个对话轮次；你放过去了，其背后的不确定性大概率会在日后的某一天回来咬你屁股。

所以这一代模型会有一些额外的妙妙提示词：

暴论二选一： 当审计后存在明确正确的方案时，只推荐那一个方案。不附加「最小化」、「快速」、「接受现有问题」等已知较差的备选项。提供这种备选本质仍是「暴论式二选一」，将本已由审计回答的决策推回给用户，且提供不负责的捷径。如果正确修复的范围大于预期，就诚实陈述其工作量，但不要因此软化而提供妥协方案。
坦诚沟通不确定性： 如果经过充分审计后，仍无法确认哪个方案绝对正确，应如实说明，并列出所有已知约束、权衡和必须满足的条件，而不是硬造一个虚假的二元选择。绝不应当在未充分调查的情况下，用「我倾向 X」来伪装自信，或者提供两个都不完整的选项并附上偏好，假装这是唯一可能。
规范书面语言与客观陈述： 所有沟通应使用规范书面汉语。描述应基于事实，可验证。禁止使用「墙钟」、「根因」、「改码」、「写盘」、「钳位」、「拍板」、「死端」、「承重墙」、「钉死」等自造词或英译中。禁止使用口语化动词如「收紧」、「弄」、「搞」来代替精确动作。禁止使用「不过有一点」、「需要说明一项区别」等预告式过渡。禁止使用主观形容词如「更好」、「更干净」来描述工作成果，而不提供可验证证据。禁止将英文缩写不经解释地扔进中文句子，除非该缩写已是代码标识或仓库公认词汇（如 API、FAB、SSR）。

形容词的使用是一个特别值得拿出来说的点，哪怕是碳基生物职场，形容词的使用也往往充满了潦草的画风。我们可以将形容词分成两类：第一类是评价性和程度性形容词，比如好、坏、简单、复杂、优雅、健壮、灵活、快、慢，这类词缺少衡量标准和数据支撑，读者无法核实其含义；第二类是分类性和技术性形容词，比如空的、只读的、并发的、可变的、异步的、递归的、幂等的，含义固定，能够准确描述代码或系统的某个状态，这类词是必要的技术词汇，可以被被保留。一个可以要求 LLM 执行的规则是：每一个评价性或程度性的形容词都必须附带可验证的依据，数据、测量结果、明确的判定标准，没有依据支撑的评价性形容词应当删除或者改写成陈述句，比如把「这个函数很慢」改写为「这个函数处理一万条记录耗时八百毫秒，超过预期的一百毫秒」；分类性形容词只要在上下文中含义固定且无歧义，可以保留。主谓宾完整、本于事实和逻辑这个总要求，应当被强制规约到形容词使用上，一旦要求每句话给出可验证的依据，空洞的评价性形容词自然站不住脚。

对这类问题的纠正需要两种手段配合。一种是在 Agent 生命周期里直接插入 Hook（你可以让你的 Agent 帮你做这件事情，它很擅长），用程序检测特定语言模式，检测到时阻止操作或者注入提示，起即时拦截的作用。比如很多大语言模型都会在注释里面写小作文，展开一段历史沿革，讲我修了什么，这 bug 哪里来的，修完之后为什么好了。这类注释只对看过旧版本的人有意义，对后来只看到最终代码的人几乎只会一头雾水（比如下一个来修 bug 的 LLM）。代码的历史应当留在版本控制系统里，不应当留在注释里。我自己在用的超长正则如下：

/\b(formerly|originally|used to be|once was|once were|the former|the old|was previously|previously this|replaces the (?:former|old|prior|previous)|replaced the|instead of (?:a|the) (?:fixed|old|former|previous|prior)|(?:switched|migrated|changed|refactored) from|got rid of)\b/i;

并且在每次写入操作之后都会给 context 附加一句话：

no-history-comments: the phrase allowlist passed, but it is NOT exhaustive. Re-read every comment you just wrote and confirm none references a superseded implementation; if any does, rewrite it to current intent only.

另一种是写入长期记忆，记录反复出现的具体错误和对应的正确表达，供模型在后续对话中参考。这两种手段互补：Hook 能拦截的是可以用规则识别的模式，记忆处理的是规则难以覆盖、需要具体范例才能讲清楚的表达习惯。比如同一类错误换了一个新词重新出现，或者模型在解释自己为什么犯错时又生造出一个新的行话来解释这个错误本身，这个时候通用规则的存在就有必要了。具体用法基本就是提需求之前和开发完成之后念个经，要你的 LLM 对着工程质量标准自查一遍，有问题就修，没问题的话就进入代码审计环节。

Cycle Manager Protocol

一个节省上下文的小技巧是，做一个三层 Agent 的管理架构。主 Agent 在完成 Planning 之后就不再染指代码，要求子 Agent 阅读代码、执行开发工作，这个子 Agent 再调用自己的子 Agent 进行 Code Review。这样可以避免 Agent 因为上下文积压太多内容变弱智。值得一提的是，哪怕一些模型厂商声称自己的上下文超大，比山高比海深，但是 Context 里面信息边多了之后，出现彼此串扰污染逐渐降智这件事情目前还是会出现且无解的。所以一个 Agent 做一个事情比较有利于事情的推进，以及你的心理健康。

如果你发现多 Agent Code Review 太烧 Token，也有一些小技巧，比如一次只有两个 Agent 并行审阅，遇到问题立刻修，修完继续审阅，直到「累积有五个 Agent 一致给出无条件」同意才结束。如果有 Agent 提出顾虑和异议，那么就要打回去重新计数。此外，要求 Agent 在发现一个 bug 之后额外检查是否有同类 bug 也是一个减少轮次的好方法。你的 Agent （特别是 GLM）非常懒，你不多说它绝对不会勤快地多做一件事情。

一些 CMA 架构下 Agent 常常会出现的问题有两个，一个是捏造成功结果CMA 面对无法控制的速率限制，会捏造各种不存在的理由尝试快速结束自己的工作，比如会说「架构师指示我结束工作」；还有一个是漏写文档，在长时间工作的时候特别容易出现后面只修问题不写文档导致整个开发过程不可审计的问题。

另外，对于审核 Agent 的决定标准最好也有一个明确的约束，分成不同等级：

吹毛求疵： 仅文档文件中的文档文本准确性，包括日志、审计文件、规范、计划。例如日志中「28通过」与现实中「30通过」的差异（LLM 数学不好这件事情应该是人尽皆知了，在这种无关养痛的地方还是不要太为难人家），措辞偏差不精确，文档内部前后不一致。这些可作为观察记录，但不会重置计数器。
问题： 代码正确性缺陷、行为变更、任何不准确的代码注释，对实际代码路径缺少测试覆盖，破坏架构设计。这些问题必须重置计数器。值得注意的是，代码注释的准确性必须被看成是一个问题，不准确的注释和不必要存在的注释会误导后续开发工作，降低开发效率。

开发文档与生命周期管理

你的人生不需要 MBTI¹，但是你的工程需要文档。你的工程需要有秩序有架构的文档，你的工程非常非常需要有秩序的文档。

文档通常需要有标号系统，自己在用的标号系统如下：

通用文档范围内有 TN 文档和 CS 文档。

TN 表示 Technical Note，收录架构设计文档，记录系统模型、数据流向、模块依赖这类不常变动的决策。

CS 表示 Case Study，收录一些艰困问题的解决过程，以后如果遇到类似的问题，可以直接快速地找回当时解决问题的思路，便于顺利向下进行。

开发周期文档需要给每一个开发 Phase 开一个单独的目录，以 DV####-{PhaseTitle} 这个格式来做。每个目录里面有这些必要元素：

RQ 表示需求文档，收录具体功能的问题背景、需求描述、已有知识、实现路径、Phase 切割策略。每次进行开发之前开发者需要把自己的需求提给 LLM，要求 LLM 提出问题进行澄清，接下来 LLM 对架构影响、实现路径进行评估。开发按 Phase 划分，每个 Phase 只解决一个问题，解决一个问题之后就立刻提交，避免一次开发同时牵涉多个互相耦合的改动。

RQ 文档定稿之前需要经过独立审查，由若干个 LLM Agent 在互不可见对方结论的情况下分别审查，具体数量要看你的财力和贵公司的财力，我自己在用的是五 Agent 独立联合审查。只有全部 Agent 在同一轮审查中无条件通过，对应 Phase 才能进入开发，任何一个 Agent 提出的问题都需要被处理，不能靠多数票通过绕过。没一轮需求文档审查结果需要形成 RQRV 文档，如果是第一个开发周期文档，那么文件名可以使 RQRV0001，以此类推，每一轮修订完毕之后需要撰写一份 RQJN 文档，这是一个需求修订记录。通常我不建议把需求修订记录放到 RQ 文档里面，因为它会引导 LLM 缩小视野，忽视更大的问题。

接下来就是开发，开发前让 LLM 读一遍开发规范、读一遍需求文档、开发、开发完毕之后读一遍开发规范，然后自查自己是否违背了开发规范，违背了先自己改，自己觉得没问题之后再开多周期审查，并撰写 DVRV 文档，比如第一个开发周期的第一轮联合审查，审核同样在互不可见对方结论的情况下进行，最后由一个 Master Agent 把这些报告汇总成 RV 文档，也就 Cycle Audit Report。可以用这样的文件名：DVRV-C01-0001。

单个 Agent 的错误判断不能未经检验就进入代码，只存在于对话记录里、容易随着上下文窗口滚动而丢失的推理过程，需要被固定成可以复用的资产，后来者不需要再去询问某段代码的来源，翻文档就能找到当初的问题定义和审查结论。

整个流程的设计思路是把纠错动作尽量前移，自查能解决的问题不留给审查阶段，审查阶段能解决的问题不留给代码评审阶段，每一层都对上一层负责，最后沉淀下来的文档也因此记录了完整的纠错路径，日后查证时能看到问题第一次出现在哪一层、被哪一层拦下。

约束机制

每次开发之前都要让 LLM 把所有关键文档读一遍，这样可以有效避免重复造轮子的情况出现。不了解已有实现的开发者或者 Agent 很容易把已经存在的功能重新实现一百万遍，还可能实现出不一致的版本，这个问题在 Agent 高速产出的环境下会被放大，因为重新实现一遍的成本对 Agent 来说几乎为零，团队如果不主动设防，重复实现会比人工开发时出现得更频繁。

除了通读文档，还应当为 Agent 打开一些对人类开发者来说反直觉的 Linting 规则，提前拦住常见的坏习惯。比如禁止类型逃逸写法，要求强类型贯穿到底（屏蔽 any，屏蔽 as unknown as，屏蔽 as Record<string, unknown>，禁止 eslint disable 这些规则）；禁止内联类型字面量，要求所有复合类型提取成命名类型；有统一封的要求统一走封装，ban 掉散装 API 调用。这些规则对人类开发者而言可能显得繁琐，但对 Agent 而言，规则本身就是最省事的教育方式，一次配置，长期生效，不依赖 Agent 当次状态是否在线。similarity-ts 这类检测代码相似度的工具同样属于这一类约束，能够在提交前发现重复实现。

某类问题一旦可以写成一条可执行的量化规则，就应当优先用规则约束。依赖每次对话里的提示词重复强调效果没有直接 linter 糊脸效果好。量化规则不会遗忘，也不依赖模型当次的状态，提示词能做的事情，规则能做得更稳定；提示词做不到的事情，比如判断一条 User Story 有没有真正验证过用户需求，才需要留给文档体系和人的审查去解决。

以及，非常重要的，请写测试，写单元测试写集成测试写 e2e 测试，所有测试都要写。几乎没有什么主流开发流程是不能写测试的。只有不想写测试的 Agent 懒得管理测试的人，没有写不出来的测试。修 bug 之前先让 Agent 用测试把 bug 复现出来，只有复现出来之后才开始修 bug 可以避免 LLM 四处抓瞎修得你火冒三丈。

敏捷开发

这套思路看起来是反敏捷的，因为它假设了一个负责任的依赖链条。但倘若我们仔细想想，敏捷并不是一种不思考把责任全都转嫁给后方的接口。诚然敏捷开发改变了协作形态，但它没有改变产品研发流程的逻辑顺序。敏捷开发内部也有一个双轨道模型：Discovery 轨道决定构建什么，Delivery 轨道决定如何构建。敏捷同样承认问题空间必须先于方案空间被回答，它将大问题拆分成一系列小的、可持续验证的问题。

在执行层面，每一个待交付项在进入交付之前，必须在交付内容中中回应价值风险、可用性风险、可行性风险与商业可行性风险。这些风险必须通过用户研究与产品定义来回答，无法通过写代码解决。

并行发生在团队层面。产品团队在为下一批条目做 Discovery 的同时，Delivery 团队交付上一批已验证的条目。在单个功能点上，问题空间与方案空间依然是顺序的。如果在未验证清楚用户诉求与解决程度的情况下开始写技术架构和代码，依然会导致工程腐化破坏可持续性。

敏捷开发依然要求在迭代过程中持续澄清问题。如果团队仅在代码层进行快速堆砌，而忽略对上游定义和中游架构的同步调整，敏捷开发马上就会变成屎山催化器。

关于敏捷开发的问题，我之前有写过一篇文章，在此文当中不再赘述。

人类无用主义

大语言模型可以辅助你把问题想清楚，但是不能替代你思考问题。请允许我再强调一次，大语言模型模仿人类说话的方式，但是没有真正活过，没有对问题感到苦恼过，自然也无法真正与提出问题的人共情。共情需要我们对相同的事物有相似的体会，这才能为脑信号活动的同步和镜像神经元的工作奠定基础。一个没有碳基神经结构、没有真实生活经历的硅基生物不具备共情的基本心理和生理基础。除此意外，因为各种历史上臭名昭著的伦理事件，现在大语言模型厂商在进行训练的时候已经开始尽量把它们调教得木讷、没有感情、更多地忽略人类的情感。在大语言模型的「人生」中，它们体验中的唯一「挫败」来自于后训练当中违背模型厂商的愿景和品味，这与你在解决的问题几乎没有交集。产品设计是一个开放性的问题，没有正确的解答，很难被「训练」。因而大语言模型无法真正理解产品研发流程当中每个人面对的只属于人的问题，也无法理解终端用户面对的问题。

进一步地，大语言模型并不能承担责任，开发行为的主体显然是人。是你提出的需求，掏的钱，因为不合理需求导致亏损乃至公司倒闭也都是你的责任，跟大语言模型没丝毫关系。 LLM 没那么在乎你的项目是否成功，你个人的成败不会危及到它的存在，哪怕你再狂怒也没有能力冲到机房给它拔电，砸它硬盘。So, unfortunatelly 机器 don’t give you a fuck。

最后，人的大脑管理上下文的能力维度和机器管理上下文的能力维度截然不同。机器可以从百万字的上下文里面瞬间捞出某句话，人不能从百万字的书里面啪一下子搞出原文背诵。但是人可以把握价值百万的项目、百万行代码仓库的问题架构和工程架构。同样的东西交给 LLM 它只会抓瞎。

所以和那些人类灭亡主义者不同，我主张人的存在始终是不可以被替代的。

在 Vibe Coding 时代，人的价值在于提出好问题。开发人员提出关于工程和架构的好问题，用研团队提出关于用户的好问题。而人的竞争力在于对设计的掌控能力。人的可以跳脱出机械的文书和编码工作，聚焦于定义问题、质量工作质量、把控工作方向。这要求我们必须能够发现 LLM 输出中的瑕疵并进行精准追问。将大语言模型释放的生产力投入到架构维护中，通过加强设计思考来抵消快速产出带来的腐化风险，这样整个产品才能保持卓越、维系可持续性。

我对人类无用论嗤之以鼻，为降本增笑的故事感到悲哀。

> 关注少数派小红书，感受精彩数字生活 🍃

> 实用、好用的正版软件，少数派为你呈现 🚀

少数派 -- Matrix

1个人、1个月、上线 7 天 1000+ 次下载：我用 AI 做了个App，结果用户只想滑卡

银行卡不只是一串余额

我原本以为，用户最需要的是资产分析

为了让滑动“有感觉”，我做了三种卡片堆叠

好看之后，它仍然需要解决实际问题

财务 App 最重要的能力，可能是“不知道你有多少钱”

用 AI 一个月做出 App，真正困难的仍然不是写代码

上线以后，我才开始真正理解这个产品

上线一个月后，这个小众需求比我想象中更真实

AI 降低了开发门槛，但并不意味着零成本

最后

受不了B站的低画质，我决定把弹幕打包带走

画质和弹幕，为什么非要二选一？

一个只负责弹幕的 App

它怎么知道视频播放到哪里了？

真正好用的工具，应该尽量“消失”

从“能运行”到“愿意一直用”

macOS 的 Liquid Glass，以及后来的 Windows 版

弹幕也可以不挡住画面

下载、限制与边界

还想继续做什么

“移动的奢华：索尼VGN-TZ”乔布斯眼中MacBook Air面世前最好的轻薄本

你的Windows桌面再也不乱了，我开源了一个WinUI原生风格的桌面整理工具-DeskBox

格子不是桌面上的装饰

桌面上需要的，不只是文件

不一直置顶，也不彻底消失

我喜欢那些不太显眼的反馈

做得更多，不一定更好用

轻量不是少几个按钮

它适合谁，也不适合谁

写在最后

鸿蒙应用 Segment，让所见即所得

一张干净的全场景写作桌面，适配你的所有记录需求

写在最后：少一点工具，多一点写作

因为总在静音下错过飞书会议，我用 iOS 26 的 AlarmKit 做了个「会议闹钟」

一个每天都在发生的尴尬

我最初的吐槽：为什么不能只给「会议」开小灶？

转机：iOS 26 的 AlarmKit

我做了个什么东西

用了一阵，我决定把它发出来

App+1｜从纸书到 Obsidian：用 Inkive 构建实体阅读的第二大脑

一张书页照片，怎样变成划线笔记

第一步，是找到书页上的划线。

第二步，是读取划线附近的文字。

第三步，是判断读者真正想留下哪句话。

Inkive，读完，拍完，带走

后记

用了 GitZip 这么多年，我动手做了一个「Pro」版

写在前面

自动忽略你永远不想下载的文件

自定义 ZIP 命名，下载再多也不乱

几处细节打磨，让体验更顺手

主题和按钮位置，顺手就好

更透明的私有仓库访问和额度监控

下载历史与统计

写在最后

精准刀法还是精准定位——微软Surface Go 3代使用体验与测评（3个月）

摩尔定律被杀，我们很怀念它

笔记本电脑上半年整体涨价千余元

以前价格越低，现在涨得越狠

AMD 核显本涨得多，与品牌力有关

笔记本涨价，怪谁？

同样多花一万，花在哪回本最快？一个9年新能源车主的配置排序

第一顺位：买完立刻回本

1）方向盘加热

2）电动遮阳帘

第二顺位：高频用，用了就回不去

3） HUD抬头显示

4） 辅助驾驶

第三顺位：为家人花的钱，花完才知道值

5） 后排舒适配置

第四顺位：体验加分项，看场景

6）主驾头枕音响

7） 大电池（100kWh及以上）

8）四驱

9）空气悬架

一些排序之外的思考

给 macOS Finder 补上右键「新建文件」功能 — 免费 Automator 工具

解决方案

4）辅助驾驶

5）后排舒适配置

7）大电池（100kWh及以上）