一年后重读得物 BuildingClosure 优化
2025 年 4 月，得物技术团队发了一篇文章得物 iOS 启动优化之 Building Closure，讲他们排查到 iOS 启动耗时中 BuildingClosure 阶段的一次诡异暴增。根因不是动态库、不是编译选项、不是打包脚本,而是新增的几个 ObjC 方法名，跟已有符号在 dyld 的完美哈希构造算法里...
Recent Posts
GitHub Actions 每日自动测试：从 schedule 踩坑到跑通
我在维护两个项目，一个是 Swift 写的 macOS CLI 工具（ForgeLoop），另一个是 Rust 写的微信 Bot（AMClaw）。开发阶段每次 push 都跑全量测试太费时间，而且有些测试在本地 commit 之前已经跑过了，CI 再跑一次完全重复。
UITextField：一个控件，半个系统
在 iOS 开发里，没有哪个基础控件能像 UITextField 这样—-表面上代码只有一行，背地里却牵扯到半个操作系统的子模块。它泄漏、它卡顿、它生命周期诡异、它让内存检测工具集体失语。更麻烦的是，这些问题往往不是你代码写错了，而是系统层面组合出的结果。
Agent 上下文工程的关键，不是记住历史，而是重建工作面
把 Agent 的上下文理解成“聊天记录”，很自然，也很容易把问题看浅。
对 Thought 的复盘：从推理引擎到信息提示
我最早把 Thought 看得很重。
对 ToolUse 的复盘：模型不可信，系统只信执行链
前两篇写 Planning 和 ReAct 的时候，我其实一直没把问题说到底。
对 Planning 模式的复盘：计划不会错，错的是你以为计划不会错
我最早搭 Planning 模式的时候，觉得它比 ReAct 优雅很多。先花一点时间把任务想清楚，拆成步骤，排好依赖，再一条条往下走。不像 ReAct 那样边想边做，每一步都临场拍脑袋。Planning 看起来更有条理，也更可控。
对 ReAct 的复盘：失控、修正与混合架构
我最早接触 ReAct 的时候，对它的理解很简单。模型先想一下，再调一个工具，拿到结果以后继续往下走。这个循环本身不复杂，真正难的地方，看起来也很明确：提示词怎么写，工具描述怎么给，示例要不要补，输出格式怎么约束。