2026-03-01 07:35:00
This is my very personal, very meta take on AI tooling — not a how-to, just a lens: treat an LLM like an improv comedian. The model is the performer; the context is whatever the performer has to work with — the audience suggestions, the rules of the game, and everything said so far. Change that input, and you change the performance. It’s a simple framing, but it matters, because most of the “new” tooling we talk about later is really just different ways of shaping context.
If we go back a bit — when ChatGPT first went mainstream — prompt engineering became a buzzword. The idea was that the right wording could coax noticeably better output. That hype has cooled, especially as a standalone job title, but not because the practice vanished. My take is that, back then, the comedian simply wasn’t that strong yet, so you had to feed it very specific suggestions to get a good bit. Today, the comedian is better, and the craft has shifted: less about finding magic phrases, more about shaping context and building workflows. In that sense, the kaleidoscopic tools we have today are still extending prompt engineering — they’re just turning it into scaffolding, templates, and context choreography.
Fast forward to today, we live in an age of abundance in AI models. There are a lot of capable performers, and within the top tier the difference is often subtle — and highly task-dependent. So the leverage moves to the room you put them in: the better you can shape the context, the better outcomes you tend to get. Give a decent comedian great suggestions and a clear setup, and they can outperform a better comedian stuck with a confused, noisy room. Context really matters.
How do we control context? Tools can help, but most of them are generic — they don’t really know what you consider signal versus noise, so they can’t safely curate the room for you. For example, Claude Code can compact the conversation to make more room for what comes next. But if you toss in an unrelated question halfway through, or dump a giant chunk of raw logs into the chat, the performer is now doing improv in a noisy room: it becomes harder to track what matters, what’s incidental, and what should be ignored.
At this point, you might think we’re powerless. We’re not. A whole set of inventions exists for one purpose: keep the context window aligned with the problem we’re actually trying to solve.
Let’s start with MCP. To me, it’s a great invention not because it’s yet another integration, but because it changes how much integration knowledge you have to carry in the context window. MCP gives the model a small, discoverable interface to external systems — tools, resources, and even reusable prompts — via clear schemas and structured inputs/outputs. In practice, an MCP server often fronts one or more APIs, but it doesn’t have to expose the entire surface area. It can present a curated menu of capabilities with sane defaults. The LLM sees a menu of dishes, not a book full of recipes: instead of pasting curl/auth/swagger docs into the chat, you give it a handful of typed tool calls. That keeps the context lean and the model focused on the task.
Next, I’d like to talk about subagents. In my opinion, this is another great invention: instead of stuffing everything into one ever-growing chat, you delegate a narrowly scoped task to a separate agent running in its own context window (often with its own prompt and tool permissions), then bring the result back to the main thread. The goal isn’t “zero context” so much as “clean context”: keep the orchestrator’s context focused on the plan and the decisions, not the churn. Debugging is a classic example. Logs are high-volume and usually low-signal, and they can quickly drown out what you actually care about. A subagent can wade through the noise in isolation and can be instructed/designed to return a short, decision-ready summary so the rest of the workflow doesn’t get contaminated.
I don’t see skills as a breakthrough. To me, it’s prompt engineering with better ergonomics: modular, shareable, and loaded on demand. That’s a real UX win. But context-wise, it’s an incremental improvement, not a new paradigm. You’re not eliminating instruction tokens — you’re moving them out of the chat transcript and pulling them in when relevant. Once loaded, those tokens still compete with conversation history and everything else. If anything, a large catalog of Skills can create a new kind of noise: routing and discoverability overhead.
While I know Geoffrey Huntley personally, Ralph Loop still doesn’t feel like a new kind of context management to me. It’s a solid reliability pattern: keep the long-term state outside the conversation, restart with a clean context each round, do one small unit of work, validate it, then loop. That can be very effective precisely because it avoids context rot. But it’s not the “art” I’m seeking. It’s less about shaping the room and more about clearing the room over and over — paying iteration cost for robustness.
Gas Town adds real value in coordination and persistence — it stores work state outside the chat in git-backed hooks/ledgers — but at the end of the day it still inherits the strengths and limits of the underlying agent runtime (e.g., Claude Code or Codex). So if you only care about token-level context shaping, it may feel like ‘nothing new’; if you care about multi-agent reliability, it’s a different story.
So if we zoom out, a lot of AI tooling innovation is really context management innovation — not making the comedian magically smarter, but managing what the comedian gets to hear, when, and at what bandwidth. Different tools optimize different bottlenecks — token budget, noise isolation, state persistence, and coordination. The “art”, for me, is knowing which bottleneck you’re hitting and picking the smallest intervention that keeps the room coherent.
2026-02-23 09:58:00
这个月读完的书只有一本, 总共读书的时间也只有12个小时. 都算是很长时间以来的新低了. 读完的是一本无需动脑的网络小说成何体统, 主要也是看着新上的网剧/动漫在那儿挤牙膏, 于是直接找来书把小说读完了. 这本刚开始读的时候还好, 后面就开始拖沓和不堪了. 读到搞定太后之后都很难再读下去.
这个月看的剧会多一点, 首先是某天晚上无聊躺在沙发上看完了刚上的驯龙高手真人版, 不算什么上好的片, 不过诚意还算足, 合家欢可以一看. 另一个是爱情要怎么翻译, 这部肥皂剧很甜, 底子还是很正常的韩剧, 大概可以一看. 再后面是The Playbook: A coach’s rules for life, 这个是本月最佳, 让我对coach这个角色有了更多的理解. 能够从各种不同的方面让人信任, 给予反馈, 给予激励, 能够让人更好, 才是一个coach该做的事情. I’m not gonna coach you to who you are, I’m gonna coach you to who you should be someday. 另外还在Netflix上看了唐宫奇案, 这个片子的质量就太烂了, 各种硬伤层出不穷, 剧情和台词也幼稚得让人实在不好意思读下去, 所以后面就弃剧了.
这个月还看了一部非Netflix上的电影, The Life of Walter Mitty, 这个是真不错, 白日梦想虽然能够让人沉迷, 但是如果在真实世界不能像主角最后这样更主动地去拥抱这个世界, 你只会被这个世界遗忘. 另外, 如前所述, 也看了成何体统的剧集版和动画版的第二部, 仍然没看完, 一天一两集挤牙膏实在是让我不能接受, 而且老实说就这个剧本和演出, 不值得我那么长的注意力.
OpenClaw大火我是实在没看太明白. 当然, 单纯从技术角度来说, 整个世界都会很无聊: 手机不过是一台微型电脑, iPad只不过是一台微型笔记本. 但是, 很多东西实际上是touch point的改变导致了质变. 所以, 要理解, 还得真正去touch一下, 然后发挥一下自己的想象力, 看看有什么是之前做不到而现在可以做到的了. 当然, 你让我心甘情愿的去安装一个TS写的放权给AI的软件, 我是一定不愿意的. 于是找来了PicoClaw. 在我一台美国的VPS上跑通了后, 又想着去拿一个Oracle Cloud的虚拟机来专门跑这个玩意.
然后就要开始连绵不绝地对Oracle吐槽了. 云服务我用过的也有不少了, 有像AWS这样挑不出大毛病的, 也有GCP这种用起来云里雾里的, 还有想IBM当年的Bluemix完全是半成品的. 但是像Oracle这样的厂商真是第一次见. 注册账号就花了两三天, 每次注册都报信用卡信息有问题, 但是我这个卡在全世界都买过服务了, 凭什么他们家有问题? 而且, 我每次重来换一个信用卡, 就开始报错说我尝试次数太多. 但是我一个人科人属的个体, 真的不是一个电子生命啊, 我就是之前试了一次第二次就不让了, 突然死亡是吧? 好容易回头记起来要做这个事情, 换了两次卡, 终于通过了注册这一关, 然后发现这个新账户创建后需要人工审核的, 于是我无语到家了. 接下来, 几天后, 这个账户终于姗姗来迟, 我开始创建机器. 然后这儿就开始好玩了. 我本来想着找个类似Cloudformation, Deployment manager这样的东西, 这样可以反复重试, 结果发现Oracle没有做自己的control plane, 而是让用户自己跑terraform, 挺古朴的. 接下来我就开始不断遇到Out of capacity的问题了, 其他资源都创建成功了, 关键要创建虚拟机的时候报这个错. 我甚至还写了一个脚本, 反复重试了一晚上, 但还是没能成功启动服务器. 我觉得像猴一样被耍了, 就去查了一下, 貌似必须要升级到Pay-As-You-Go账号才行. 好吧, 这算是游戏策划逼氪对吧? 升级就升级吧, 升级又需要人肉审核. 还好这次的审核没开账号那么久, 几个小时就搞定了, 回来直接跑terraform, 终于就可以连接到远程服服务器了.
PicoClaw开始跑了, 也连到了Telegram, 具体要怎么用, 还没想好, 找找有没有好玩的idea先.
拖延了这么久, 终于写完了第一部中篇小说: 忘川, 欢迎捧场. 这本书是和Claude Opus 4.6一起完成的. 创作的出发点是某次我和deepseek聊天, 让它想想小小说的梗概. deepseek出了不少梗概, 其中我最喜欢一个保镖的故事, 不过它的背景是在现代, 我就想着放到古代去会怎么样. 以此, 我就有了一个这样的设定:
江湖人好排座次, 虽大多无缘得见真容, 但四绝之名无人不晓: 未尝一败的”凝岳”李慢, 身为第一美人, 腊月便将出阁的”无花”颜寂, 主动放弃高官厚禄加入忘川, 卦算无双的“司辰”陆承影, 一叹定生死的”金针”钟无鬼. 四位的传奇在坊间传了又传, 故事都已褪成了神话. 普天之下, 知晓内情者不过十指之数: 这四位绝顶人物, 皆听调于天下第一秘会, 忘川. 他们或曾并肩退敌, 或曾隔空交手. 偶遇江湖, 不过颔首互道”久仰”. 只是他们自己不知, 当这些偶遇与声名被细细织成江湖这张大网时, 布线之人, 正坐在忘川最深处的阴影里, 侧首垂目静听.
这个故事的背景是在宋朝, 我很为这个背景着迷, 还花了不少时间去研究北宋洛阳城里皇城有哪几个门. 但是, 显然, 如果简单就是这样一个组织, 就太假太烂了: 有这样一个五人组, 整个世界的平衡性就会被摧毁. 我写到这儿停了很久, 想着该怎么演进这个世界. 后来仍是和deepseek聊天, 我问它有没有什么其他的可能性, 讨论过程中, 我问他有没有什么宋朝背景的夺嫡的故事, 它告诉我的第一个故事就是赵竑的故事.
于是, 这几个人就从之前高高的架子上走下来了, 他们不再是那些神仙般的人物, 而变成了有血有肉有悲有喜的人. 李慢不再需要是天下第一, 颜寂不需要那么美, 陆承影不需要有那么深厚的背景, 钟医官也不需要那么神秘了(名字和性别也被改了, 我脑子里本来是类似平一指的角色). 而且, 我在读这段历史的时候, 也发现这个故事挺传奇的. 一场大雨, 真的就改变了一个王朝的命运. 另外, 我也不需要改太多史实就能让这个故事站住. 很幸运, 史弥远似乎当年也真的给赵竑身边安插了一个弹琴的女卧底. 我真正改过的有两处, 一处是让历史上寿终正寝的余天锡早死了几年, 因为当颜寂站在掌柜面前的时候, 我实在是没办法不让她开这个口. 另一处, 史书上说去赐死赵竑的门客叫秦天锡, 我囫囵地将这两个天锡合成一个了.
2026-01-26 12:06:00
这个月读的书稍多一点点, 首先是一人公司做私域, 这本名义上是书, 实际上是引流广告而已, 没什么读的必要. 然后是一个欧亨利的短篇小说集, 这本和我高中时读过的另外一本没什么大的区别, 印象深刻的是之前那个选本没收入的公主与美洲狮, 以及他未完成的手稿, 梦. 接下来是普通人如何做小红书, 这本比我想象中要实在, 介绍了很多心得体会, 是我的本月最佳. 最后是昨天花了三个小时一口气读完的太白金星有点烦, 这本数次逗得我大笑, 也数次鄙视微信读书里那些感觉没读过原著的人没理解亲王的梗. 但是这本最大的硬伤是国内的体制实在是一种很奇葩的存在, 因此这些政治笑话不能说有太多的普适性, 水平上比是大臣/是首相这种还是要稍差一点点.
游戏来说, 玩通了逃离鸭科夫的第一个结局(也是难度最低的一个结局), 农场镇的boss都打过至少一遍了, 实验室转了几圈后懒得往里面走了. 半路劝退我的大概是这样几件事情:
Netflix里, 这个月看完的两个片子都告诉我不要害怕失败. 一个是100 meters, 里面的人物也会有挣扎, 也会有崩溃的场景, 但是无论如何, 这些人还是能够爬起来, 继续往前走. 这部的缺点是主线不够明确, 看得出来想要走多主角并行的故事, 但是在这个电影里非主角的背景交待得不够多, 所以有时候会有喧宾夺主的感觉. 第二个是昨天直播的Alex Honnold直播徒手爬台北101的Skyscraper Live, 真令人羡慕有这样的心理承受力. 另外, 无聊放松的时候随便从我的电影库里面找了两个老片看, 一个是加勒比海盗5, 视觉效果片. 另一个是更老的新龙门客栈, 这个电影豆瓣有8.7的高分, 其中9分都是张曼玉的, 其他人是在拖后腿.
另外, 这个月还看了Youtube上柴静对严歌苓的采访, 谈芳华和文革. 严的状态挺好, 敢说真话, 敢说直话, 不藏不掖. 另外, 里面有句话让我印象很深刻: “文学都是萌发于记忆的不可靠性”.
下面记录一些我最近是如何和AI协作的:
也会颔首互道一声"久仰"和静静听着都有些现代汉语的表达习惯, 在古代白话中是没有的. 这样, 至少可以避免你写中国古代背景的武侠小说里, 出现焦距这样让人出戏的词语.在和AI合作了这么长时间后, 我也有了一些自己的心得: 在这个和AI共存的时代, 高等级的鉴赏力是最稀缺的资源. 比如AI写出来的小说梗概是不是合理, 是不是有一个好的内核, 是不是值得继续衍生发展, 都需要一定的文学鉴赏力. 而选定方向后, AI写出来的内容, 节奏感, 音韵感, 都大概率是不达标的, 都是需要人来读, 来朗读, 来指导AI提高的. LLM的机制决定了AI学习到的内容的水准不会高, 所以更需要人在其中来充当阀门, 掌控内容的输出. 又比如摄影, AI固然能够保证我的拍摄能够有一个底线, 不会差到哪儿去, 但是对于如何拍出好的照片, 仍然是需要大量的联系和大量的阅读, 真正提高自己的鉴赏水平. 换句话说, 对于掺杂了主管成分的艺术创作, 不管是写作绘画还是摄影, 甚至编程也可以算得上: AI能帮你入门, 但是至少目前没办法帮你精通.
2026-01-07 06:43:00
更新: 因为GLM-ASR的单次音频识别长度只有30秒, 我回退了我的修改.
这一两年AI用得很多, 我也养成了一个口述的习惯: 虽然不太常见, 但是偶尔我会希望去口述一些内容给AI, 而不是自己逐字手打出来. 比如, 对于一些长文档的review, 或者对Claude Code的一个长的plan的review. 之前我vibe code了一个rust版本的工具, 叫murmur. 基本功能在这个页面里说得比较清楚了. 简而言之就是命令行不带参数的时候是等着语音输入, 然后转成文本, 并丢给OpenAI润色一遍后给出来. 如果带了参数, 则认为参数是音频文件名, 会提取音频文件里的文本.
在Claude Code还没有ctrl-g来打开编辑器的时候, 我使用murmur的频率还会更高一点. 除了日常当工具在工作中使用外, 我还用这个工具提取了一些纪录片的台词. 总体来说, 我对这个工具还是挺满意的. 不过要说吹毛求疵, 我主要的不满意在于对OpenAI的依赖. 根据我自己毫不科学的体验, whisper API有时候返回质量会比较差. 于是, 我一直在找一个合适的开源实现来替代.
日本旅游回来后想找点小项目练手, 就看到了GLM ASR. 这个模型比较小, 参数量为1.5B. 自己测试了一下, 基本符合我的要求: 识别率在线, 对于中英混合的语句支持也和whisper API一样好. 为了上一点难度, 我用普通话朗读了李白的春夜宴桃李园序, 保存成音频文件后丢给这两个模型横向对比, 能够看到GLM还稍胜一筹:
浮天地者，万物之逆旅；光阴者，百代之过客。而浮生若梦，为欢几何？古人秉烛夜游，良有以也。况阳春召我以烟景，大块假我以文章，会桃花之芳园，序天伦之乐事。
作为对比, OpenAI的结果为:
浮天地者, 万物之逆旅, 光阴者, 百代之过客, 而浮生若梦, 唯欢几何? 古人秉烛夜游, 良友宜也, 况阳春朝我以烟尽, 大快甲我以文章, 惠桃花之芳园, 续天伦之乐事。
两个模型对于古汉语发语词”夫”的处理都不到位, 都被录成了”浮”. 但是从那以后, GLM的输出是全对, 而OpenAI的输出就差了一圈.
接下来就简单了, 我需要修改murmur的代码, 使用GLM ASR来替代OpenAI, 这份代码之前就是Claude Code写的, 所以仍然是Claude Code来帮我完成. 最主要的一个障碍是, 我本希望用SGlang来运行模型, 但是后来发现SGLang的容器镜像实在是有点大得离谱(>10GB), 于是还是在本地起了一个python的虚拟环境. 但是总体来说, 这种套壳在技术上没什么难点, Claude Code照着spec写一次就写好了.
2025-12-31 11:23:00
这个月很多筹划相关的事情, 包括安排日本的旅游, 读书不算多. 读完了一本教练型管理者, 单纯是因为这个名字和公司内部对manager的称谓就是coach. 读完后不太满意, 这本虽说是以实操性为主, 但是可读性实在是差. 只在乎是不是把内容呈现出来了, 但是完全没把内容呈现得好看并令人信服. 另外一本是猎奇性的奢侈品经济学, 分析学习时尚这个行当如何做市场营销, 挺有意思.
游戏来说, 终于通关了丝之歌, 一共105个小时, 93%的完成度, 懒得去刷100%了. 不过这基本是本月玩的唯一一个游戏了. 在旅途上看完了是大臣和是首相, 觉得这么好的台词, 需要重刷. 另外, 在日本的一天早上看完了Netflix上的日本沉没, 在日本本岛看这个剧, 代入感很强(比如前几天刚见过的富士山), 不过剧情实在有点太胡来. 另一个沉没主题的是Netflix上的The great flood, 灾难片的主题本来很好, 却生硬地往里面塞入AI的思辨, 真是令人摇头.
按着上个月的想法, 这个月开发了一个类似于暗黑三刷装备的页游, 目前还处于残废状态, 就不放链接了. 开发过程还是挺爽的, 看着游戏按照自己的想法一点一点成型, 那种创世的成就感是无可比拟的. 为了这个目的, 还在电脑上把游戏装了回来, 查各种数据. 在开发的过程中也发现自己还是很幼稚, 做游戏系统这个事情真不简单. 本来我的想法是把暗黑三的装备数据库抄过来, 然后自己筛选一下, 剔除掉不适合页游的装备就好. 但是装备上的数值直接迁移到页游时我遇到了比较大的障碍, 装备上的秒回如果给的不够的话, 游戏人物前期会各种死, 但是如果秒回给得够的话, 怪物的攻击又完全不疼, 所以一度是前期如果随机到回复的装备就一马平川, 而如果没随机到回复, 则是各种死各种卡关. 为此, 我也是各种调整, 到现在也还没有一个完美的解决办法. 后面还是得深入一点去研究这个过程中的机制, 然后有针对性地设计系统. 另外, 暗黑三里的游戏职业有很多个, 而我目前只做了野蛮人, 各个职业之间的平衡性还完全没开始着手. 各个游戏内的系统的开发也还是ongoing, 比如游戏的关卡设计完成后, 做了商店系统和宝石系统, 但是还有赌博, 大小秘境, 传奇宝石, 卡奈魔盒等各个系统需要开发. 本以为是一个一两周的项目, 不过现在也只能慢慢往前走了.
趁着圣诞假期跑来日本旅游, 路线大概是东京-京都-东京. 出发前查过天气, 感觉全程都会下雨, 但实际上运气却非常好, 大部分时间都没有下雨, 尤其是在京都, 很多时候是大晴天. 旅游景点都是人山人海, 所以挑几点回忆记录一下:
2025-11-29 09:27:00
这个月事情超级多, 所以书只是读完了一本一个叫欧维的男人决定去死, 这本书真的很反差萌, 本来是讨论一个沉重的话题, 故事里面也经常不经意给你展示出生活残酷的一面, 但是里面的各种比喻和展现出爱的那一面, 总会让人又对生活充满期待.
玩游戏来说, 重玩了一下kittens game, 边玩边觉得心里痒痒的, 想做一个仿品出来, 主题就是Diablo-like的刷装备.
丝之歌到了月底才缓慢进展, 过了第三幕的Trobbio和织女, 清掉了翠庭. 还有一群boss需要打. 我偶尔会在Youtube上看一下BlueSR的速通. 今天早上他刚刚又刷新了世界记录, 很厉害. 而且看他一边玩一边解说, 幽默感和人格魅力都是在线的.
影视来说, 看了水形物语, 人物脸谱化比较严重, 缺乏变化. 晚上锻炼时继续在看是大臣系列, 已经看到了第三部, 马上Jim Hacker就要升级当首相了. 非常喜欢这个三人组, 笑点满满, 很好.
最后, 月中整理自己浏览器收藏的时候重看了两个视频:
看到片段中的广州网易大楼的食堂/天台, 恍如隔世.
上个月月底的时候, 公司把所有澳大利亚和新西兰的员工全部召集到了悉尼, 参加为期两三天的Canva World Tour活动. 这次公司的行政人员很辛苦, 两三个月内要安排这么多人的机票酒店. 这还不用说要为了Canva Tech Day订ICC和为了Canva World Tour的主题演讲订奥林匹克公园就需要很多组织工作了.
这次酒店不错, 住的不是公司附近的小酒店, 而是Hyatt Regency, 餐标也由$100升级到了$200. 主要的槽点是第一天的机票太早了, 6点半, 所以当我坐进ICC开始听会时就开始打瞌睡. 尤其是Cliff一上台我就彻底睡着了.
另外, Tech Day下午有一个技术讨论里面分享的细节挺有意思. 这个讨论的主题是分享今年年内的那些sev 0(canva不可访问)的原因. 我们对AWS的依赖已经达到了比较严重的程度, 而且已经开始摸到各种瓶颈了. 比如其中一个sev 0是因为某个mysql数据库比较大的时候会有锁表的情况, 又比如ALB虽然看起来是一个无限使用的服务, 但是实际上它内部有一个100台实例的上限, 而我们的流量击穿了这个上限, 从而导致了我们的服务质量下降. 这个也不太能用草台班子理论来怪罪, 而是应该说, 对于任何不是自己维护/编写的软件, 都应该有戒惧之心.
这个月主持将一个git repository合并到了另外一个repository的工作, 这儿写一点笔记.
源repo A里面是一群小工具的集合, 目的地repo B是一个更大的monorepo. 两者都用Bazel管理. A里面除了有Bazel外, 打包还使用了nix. 这是因为由于历史原因, A里面有很多功能是用python/bash来实现的, 虽然后面的主流是golang.
为了实现这个repo的merge, 我们做了很久的准备工作:
这个月做的工作主要是:
说起来不多, 实际上杂事不少. 比如为了能保证B里面的CI能够正常工作, 就需要patch一堆代码. 又比如CD pipeline创建好之后, 我们才发现CD pipeline里面构建出来的Linux可执行文件在Linux下运行的时候会segfault, 为了解决这个问题也是花了好久, 绕了些路. 不过现在来看, 算是成功落地了.
