2026-07-06 19:18:00
我刚才用 dyld 的 __DATA，靠 __interpose 机制拦截了 malloc/calloc/realloc 及 malloc_zone_* 全家，现场编了一个动态库挂到你的 app 上。一旦进程内出现 FAIL_NOW 环境变量，所有 ≥100MB 的分配请求直接返回错误，配合一个 mock server 完整重现了你收到的崩溃栈。我现在有 100% 信心确认这个问题并给出修复 ── Fable 5 (xHigh effort) 面对一个我觉得如此棘手的问题时，Fable 5 在五分钟内轻而易举地使出一招偷天换日，留我独自在黑夜中瑟瑟发抖。这一刻，我仿佛看到了传说中的“神之一手”。 我从小是听着很多有关编程的故事长大的：比尔盖茨如何把 QDOS 改造成 MS-DOS，求伯君如何一个人用汇编写出 WPS，Linus Torvalds 又如何把一个“只是爱好”的内核丢到新闻组里，最后让它长成了支撑半个现代互联网的 Linux。这些故事都充满了魔力。 这种魔力一直陪伴着我，让我认为编程是一件非常“具有魔法”的事情：从 ASCII 字符组成的咒文开始，经过...
2026-07-03 22:50:00
最近在公司捣鼓了一个工具，叫 sim-use：一个跨平台 CLI，让 agent 能在 iOS 和 Android 上高效且准确地”看见画面、点按元素、验证结果”。前段时间它正式开源了，日文版的介绍文章也发在了公司的 Tech Blog 上。不过说来有趣，那篇文章的初稿其实是用中文写的，后来才翻译成日文发表；现在再把它从日文”翻译”回中文、发在自己的博客上，多少有点出口转内销的行为艺术。趁着记忆还新鲜，用母语把里面的技术细节好好聊一遍。 如果你最近半年用 agent 写代码，大概经历过这个循环： 1 2 3 写 prompt → agent 出活 → 自己跑 app → 验证 / 截图 / 找 agent 抱怨 → agent 改 → 再跑 → 再截图 … “写代码”这部分工作，在很大程度上已经被 agent 承担并接手了，但是“验证”正确性对 UI app 来说尤为困难。agent 已经能在几分钟内吐出一大段像模像样的 Swift 或 Kotlin，但写完最多跑跑单元测试，然后就停在那儿了——它等你来运行、来看、来告诉它哪不对，它再根据反馈进行修改。这是相当低效...
2026-06-07 20:10:00
三月底回国参加了 Let’s Vision 26 的会议。在 slide 里我贴了一张用手机干活的照片，会后有不少小伙伴对此很感兴趣，来问细节，也很好奇我平时的工作状态和工具。 这大半年和 AI agent 协同的工作流逐渐成熟之后，我自己的工作习惯其实也发生了挺大变化。以前干活必须坐在电脑前，最好是能进入一种完整、连续、长时间专注的状态；但现在很多事情已经开始变成一种“持续调度”：让任务在后台跑，多个 agent 在并行工作，而人更多是在做别的事，大部分事情是在碎片时间推进的。只有当遇到更困难一些的课题时，才需要找到大片时间来专注做决策。在专注期间时，我的主要任务也从单一项目的所谓心流状态，变成了在多个不同项目之间进行快速的上下文切换（毕竟等一个 agent 响应的时候，你就是会不由自主地去看看别的项目）。也因为这样，我现在对“工作设备”的边界感越来越弱。手机、电脑、家里的常驻机器、甚至是一个墨水屏阅读器，都可以成为工作的设备：也许与其说是“工作设备”，其实更像是同一个工作空间的不同入口。 大体上来说，我现在使用手机和使用电脑是五五开：如果有大段完整时间，比如工作或者夜间能...
2026-03-16 22:30:00
过去大半年我一直在高强度地用 AI agent 写代码，用着用着发现一个问题：“怎么组织 agent 吐出来的东西”这件事，比我原来想的重要太多了。 这话听着可能有点奇怪。大家关心的一般都是模型能力、prompt 怎么写、上下文够不够长……但真的和 agent 密集配合过一阵子之后，你会发现有个更底层的东西一直在拖后腿：版本控制。说得再具体一点，就是你拿什么样的心智模型来管理本地的代码变更。 我现在的结论是：Git 作为远端协作和代码托管的标准还是没什么好说的，但在本地工作流这头，jj (Jujutsu) 明显更适合现在这种人和 agent 来回切着干活的开发方式。这篇文章就是来安利这个的。 Git 在 Agent 时代的摩擦 Git 是个伟大的工具，这一点没啥好争的。但它的很多设计假设，是建立在二十年前”人类手工编程”的时代背景上——一个人坐在编辑器前面，想清楚要改什么，改完检查一遍，然后 add、commit、push。这套流程是给人类的线性思维量身做的：staging area 给你一个”最后再看一眼”的机会，branch 帮你隔离不同的工作流，stash 让你...
2026-01-04 15:39:00
我最近写了一个小框架 Chroma，用 Swift 在终端里做代码高亮；顺手还以它为基底做了一个（实验性的）cat 替代品 ca，能以带高亮的方式在终端里显示代码文本内容 (几乎和 bat 一样，只是又一个“I can, why not”的项目)。这篇文章想做三件事：先简单宣传一下（真的很短），然后重点聊聊这次实践中的主要收获：在 AI 驱动的迭代方式下，把性能优化这件事做“到底”变得前所未有地容易；最后再补一些在做 ca 期间学到的命令行设计和主题生态方面的东西。 Chroma / ca：一个很小的 promotion Chroma 的目标非常朴素：给它一段代码和一个语言标识，它就返回一段可以直接 print 的 ANSI 彩色字符串。 语法高亮这种东西其实早就被写烂了：Rust 有 syntect，Python 有 Pygments，前端世界里更是 highlight.js 一类的工具满天飞。但我在 Swift 生态里一直没找到一个足够顺手、又能对终端输出细节（diff / 行号 / 行背景 / 缩进）有足够掌控力的选择，于是干脆自己（准确地说：靠 AI）糊了一个。...
