Jim Liu aka 刘指导

Codex 现在不搞 5H 限制了，我的牌子也该重新设计了。 这回我打算参考 WoW 游戏里“打盾”的 WeakAura 设计思路，把“用量”和“时间”放在同一个维度里。如果“用量”跑得比“时间”快，那就说明该省一省，或者要准备好重置次数了；反之，就说明该努力蹬了，哈哈！

Codex 改的还是挺快的，已经把 Work 和 Codex 的区别弱化了，接下来估计会优化 ChatGPT 那部分的交互

打个比方，你领养了个孩子，听着他第一声啼哭出生，看着他咿呀学语蹒跚学步，你一点点教他看着他一点一点的长大。 后来你又领养了个孩子，一开始就是12岁，虽然你不用操心换尿布这种事，虽然这孩子是按照你的要求筛选出来的，但是这孩子的成长你一无所知。 那这两个娃虽然都算是你孩子，但是感情肯定是不一样的。 是不是一开始是 AI 写的没那么重要，但这个软件迭代的过程你有没有参与很重要。 如果一开始是个 MVP，很小，但是功能你都知道，代码和架构你也了解，你一点点往上迭代功能，歪了会纠过来，那么这样的项目你就会更有感情、更上心些。

真佩服 Vercel 的挖坑速度，又开了个大坑，后面就看能不能填上了。 Native SDK 是一套用 Zig 语言构建原生桌面应用的开发框架，它想解决的问题是用声明式标记语言写 Native UI。 要我说，在 AI 时代之前，这类框架真的挺有价值的，写一遍到处能运行。 现在 AI 时代，不如同一套设计，让 AI “翻译”到不同平台，Mac 你就老老实实用 AppKit（SwiftUI 都没必要），既能保证性能和兼容性，又能避免去踩跨平台框架带来的各种坑。 当然只是我观点，仅供参考，下面是项目的介绍： 主流方案（Electron 之类）往往要把一整个浏览器打包进去，应用体积和内存占用都很夸张。Native SDK 的做法是保留声明式的写法，但把浏览器换掉，用自己的渲染引擎直接往操作系统窗口里画像素。 开发体验上，界面写在 .native 后缀的标记文件里，逻辑用 Zig 写，架构是 Model/Message/Update 的单向数据流，跟 Elm 那一套思路类似。状态变更只发生在一个 update 函数里，界面层只负责绑定和派发消息，不能直接改数据。这种约束带来一个好处：整个应用的行为是确定性的，可以录制一次操作、无头回放、逐帧对比状态指纹来做自动化测试。 框架自带了一套组件库（按钮、输入框、Tab、对话框、虚拟列表、图表等），默认就有排版和配色，拿来就能用。定制走设计 Token 体系，换一套 Token 就能换一套视觉风格。CLI 工具链也比较完整：native init 创建项目，native dev 热重载开发，native check 做静态校验（能检查标记文件里的数据绑定是否跟 Zig 的 Model 和 Msg 类型匹配），native test 跑无头 UI 测试，native build 出发布包。最终产物是几 MB 的单体二进制文件，不带解释器和运行时。 一个有意思的设计是它把 AI Agent 协作作为一等公民考虑：每个应用内置自动化服务器，Agent 可以读取无障碍快照、操控控件、断言运行时状态、截取确定性截图。CLI 还自带 Agent 技能文件，用 native skills list 可以查看。 平台支持方面，macOS 最成熟（Metal 渲染、原生菜单、托盘），Linux 和 Windows 可用但功能少一些，iOS 和 Android 处于实验阶段。WebView 作为可选项在桌面端也能混用。项目目前还在 pre-1.0 阶段，API 仍在变动，采用 Apache 2.0 开源协议。

weak harness，strong tools 我发明的。 harness会被大模型吃掉，而tools是连接大模型和业务的桥梁。