但凡自己动手给 LLM 接过点内部数据的人，大概都被同一件事恶心过：上下文到处都是，就是没法用。表结构在元数据目录里，藏在某个有专有 API 的系统后面；指标的口径写在某个 Wiki 页面，链接还时不时失效；运维手册在网盘，注释在代码里，剩下一半干脆只在某个老同事脑子里。你想做个能回答”上周活跃用户怎么算的”的 agent，光是把这些上下文拼起来就得脱层皮，而且换个数据源、换个团队，这套拼装逻辑还得从头再来一遍。

Google 最近发了个东西想治这个病，叫 OKF（Open Knowledge Format，开放知识格式），目前是 v0.1。我看完第一反应是：这不就是给”内部知识”定了个通用文件格式嘛——类比一下，有点像知识界的 Markdown，或者说，想成为 Git 之于代码那样的存在。

在这个AI时代，越来越多的应用（APP）是和AI相关的，其中有不少，对用户的请求需要调用LLM来处理，也就是要消耗token。如果这个应用，是对免费用户甚至未注册用户有一定的体验使用量的话，就要考虑怎么防止token被刷爆的问题了。恰巧我就在做一个这样的应用。

此时，一个自然而然的问题是：要怎么证明”这是正版 App 发来的”？

Apple App Attest 就是来解决这个问题的。（PS：大家如果有安卓的、PWA的解决方案，可以留言）

起因是最近我的域名要过期了，在操作续费(顺便还换了个注册商)的过程中，习惯性地敲了个 whois：

被拒了。换 whois 服务器、加参数，都是同一句话：请去网页上查。哈哈，用了快二十年的命令，说不让用就不让用了。

和之前的awk手册一样，又是一个Claude design的作品。

这次做了《滕王阁序》的逐字解析，还挺有意思的，丢个链接。

如果有错误之处，可以去这里提issue，也不排除以后做其他经典古文的解析。

还记得上次那篇吗？当时我接手 Notchy 的时候，基本就是原作者 Adam Lyttle 的初始版本——点子非常好，但功能比较基础，bug 也不少。我本来只是想”修修 bug，打个包”就完事了。

结果一改就停不下来了。

55 个 commit、4600 多行 Swift 之后（当然大部分都是 vibing 的），Notchy 已经从一个”能用”的 demo 变成了我日常干活的主力终端。是的，之前我还是混着状态，现在 iTerm2 已经从 Dock 上消失了。

将近20年前，我自己在学习awk的时候，整理过一个awk中文手册（整理、输出真的是学习的最佳方式之一），当时内容都校对过，但格式真的挺乱的。
而刚刚的5月底，我发现我的Claude design额度要用不完了，于是干脆给这个手册来个再版。样式现代化了不少！
链接不变，之前的老版本在这。