但最近遇到一个特别邪门的问题。一个用 uv 管理的 Python 项目，editable 方式安装，前一个小时还好好的，突然就：

$ .venv/bin/mycli --help
Traceback (most recent call last):
  File ".venv/bin/mycli", line 4, in <module>
    from mycli.cli import main
ModuleNotFoundError: No module named 'mycli.cli'

邪门在哪呢？同一个 venv、同一个解释器，pytest 跑起来一千六百多个用例全绿。测试说包在，入口脚本说包没了。去 site-packages 里看，editable 安装落下的 .pth 文件好好躺在那，内容就是一行指向源码目录的路径，权限 644，路径也真实存在。文件在、内容对、权限对，但它就是不生效。

排查：谁把我的 .pth 吞了

先补一句背景：editable 安装的机制，是往 site-packages 里放一个 .pth 文件，Python 启动时 site 模块会读它，把里面的路径追加进 sys.path。这个文件失效，包就从解释器眼里消失。

做了三个对照实验，结果非常有意思：

1. 自己写一个探针 .pth（内容随便指个存在的目录）放进同一个目录——生效；
2. 把出问题的 .pth 原样 cp 成另一个文件名——生效；
3. 出问题的那个文件本身——死活不生效。

同目录、同内容、同权限，副本能用原件不能用，那唯一的区别只剩下文件的元数据了。ls 加个 -O 把 BSD 文件标志打出来：

$ ls -lO .venv/lib/python3.12/site-packages/*.pth
-rw-r--r--@ 1 me  staff  hidden  56 Jul 16 17:42 _editable_impl_mycli.pth
-rw-r--r--@ 1 me  staff  hidden  18 Jul 16 17:45 _virtualenv.pth

flags 一栏赫然写着 hidden——macOS 的 UF_HIDDEN 文件标志。cp 不会复制 BSD flags，所以副本是干净的，这就解释了实验 2。而 CPython 从 3.11 起，site.py 处理 .pth 时加了一条安全加固（防止恶意软件用隐藏 .pth 做隐蔽注入）：

if ((getattr(st, 'st_flags', 0) & stat.UF_HIDDEN) or
    (getattr(st, 'st_file_attributes', 0) & stat.FILE_ATTRIBUTE_HIDDEN)):
    _trace(f"Skipping hidden .pth file: {fullname!r}")
    return

带隐藏标志的 .pth，静默跳过，一个字的错都不报。两个各自都算合理的行为叠在一起，效果就是：文件在，import 没了。

那谁给文件打的 hidden？chflags nohidden 清掉，几秒钟之后再看，又变回 hidden 了——有个进程在实时跟我对抗。答案到这基本明了：这个仓库在 ~/Documents 底下，而这台 Mac 开着 iCloud 的“桌面与文稿”同步。把仓库挪出 Documents、重建 venv，flags 干干净净，问题再没复发。

iCloud Drive 到底在做什么

开了”桌面与文稿”同步之后，~/Documents 就不再是普通目录，而是由 fileproviderd 守护进程托管的同步空间。它主要干三类事：

1. 监听并上传每一次文件变更——它假设文件是”偶尔被人编辑的文档”；
2. 冲突消解——当它认为同一个文件出现两个竞争版本，不丢弃任何一边，而是生成”xxx 2″”xxx 3″这样的冲突副本；
3. 元数据管理——给托管文件打 xattr 和文件标志（上面那个 hidden 就是它干的），开了”优化 Mac 存储”还会把冷文件驱逐成无数据的占位符，读取时才按需下载。

对文档来说这些设计都挺好。但代码库不是文档。

代码库为什么全中

第一，写入模式冲突。开发工具链的写入是高频、批量、依赖原子性的：包管理器一次重写上万个小文件，Python 用”临时文件 + rename”做原子写，git 靠锁文件和 rename 更新引用。同步进程和这些写入异步竞争，竞争输了就落冲突副本。我这次在 site-packages 里就看到了 “_editable_impl_mycli 2.pth”、”3.pth”、”4.pth” 一窝副本，主 .pth 的内容更是被拼接成了四份路径首尾相连的乱码：

/Users/me/Documents/dev/mycli/src/Users/me/Documents/dev/mycli/src/Users/me/...

第二，元数据篡改。就是前面 UF_HIDDEN 那一段，而且它是主动维护的，你清掉它还会打回来。

第三，驱逐。.git/objects 里的 packfile、venv 里的二进制，都可能被”优化存储”驱逐成占位符——在线时表现为构建随机卡顿，离线时表现为仓库”损坏”。

第四，git 自己的风险。.git 里的 index、refs 一旦出现冲突副本，仓库状态可能真损坏。git 本身就是分布式同步工具，外面再套一层文件级同步，等于双重同步，语义必然打架。

这次踩到的坑

1. chflags nohidden 修不好——几秒内被 fileproviderd 顶回来，别在这条路上浪费时间；
2. 症状自相矛盾极具误导性：pytest 全绿（它靠 rootdir 机制自己把源码目录塞进了路径），入口脚本却挂了，两个工具对”包是否存在”给出相反答案，直觉上会先怀疑一万个别的东西，最后才怀疑文件系统在说谎；
3. 损坏是异步、随机发生的：同一个 venv 一小时内坏了两次，中间检查全都正常——因为坏不坏取决于同步进程什么时候追上来；
4. 诊断口诀：文件明明在但 import 不到，先 ls -lO 看 flags 列。

结论

iCloud（以及 Dropbox、OneDrive 这些文件级同步盘，机制细节不同但三板斧一样）适合放终态文档：文稿、图片、表格。任何带衍生状态的目录——代码库、venv、node_modules、.git、构建缓存——都不该放进去。代码的跨机同步交给 git，这本来就是它的职责，而且语义正确。仓库放个非托管路径（比如 ~/dev）就好；实在有目录必须留在 iCloud 里又想排除，macOS 没有官方排除项，只有给目录名加 .nosync 后缀这个 hack。

一个按文档假设设计的同步器，遇上一堆违反它全部假设的文件，双方都没有 bug，组合在一起就是灾难。就此，完毕。

The post 代码库放 iCloud 文件夹会怎样？ first appeared on I am LAZY bones?.

市面上背单词的软件很多，但它们解决的基本都是”认识”：看见 soldier 知道是战士，看见 warrior 也知道是战士。可这两个词的区别是什么、什么场合该用哪个——这种”掌握”层面的功夫，几乎没有软件管。而”认识一个单词”和”掌握一个单词”之间恰恰隔着一条鸿沟，它决定了你的英语是只能读，还是真的能用。所以我做了一个专门练这个的 App。

每天一道题，它长什么样

玩法抄了 Wordle 的作业：每天全球所有人拿到同一道题——一对容易混淆的英语近义词，各配一张黑白线稿插图。你用英语写出这两个词在含义、语气、用法上的区别，一两句话就行，然后 AI 给你批改。

批改是这个 App 的核心。不是给个分就完事，而是从五个维度（准确性、覆盖度、语言、清晰度、洞察）各打一个 0–100 的分，每个维度都附一句针对你这次答案的点评——指出你答到位的地方、漏掉的要点，像一对一外教改作业。五个分数汇总成总分和等级，从 D 到 SSS。SSS 很难拿：不光要总分 95 以上，还要求最低的那个维度也不低于 90，纯靠某一项拉平均分是蒙不到的。

批改完揭晓标准答案，对照着学。之后就是熟悉的套路：每日连击打卡、日历一格格点亮，还能导出一张成绩卡分享——卡上只有词对、插图、等级和雷达图，刻意不含答案，朋友看到照样能去玩。

题库目前 200 道，四百张插图全是 AI 生成的黑白线稿，风格统一得像一个插画师画的。

技术上几个有意思的决定

作为技术博客，还是得聊聊后端。整个服务端就是一个 Cloudflare Worker，配 D1（题库和用户数据）和 R2（插图），没有一台服务器要运维，账单基本可以忽略——独立开发选这套栈真的省心。

我之前的服务，都是部署在自己的home lab上的，这也是一次全套采用cloudflare的技术方案，发觉这个赛博菩萨果然名不虚传，免费额度够用不说，wrangler的开发体验还非常棒！

几个细节自认为做得还算讲究：

1. 评分标准（rubric）永远不下发到客户端。客户端只上传题目 ID 和你写的答案，评分要点由服务端按 ID 查表后喂给模型。否则抓个包就能看到得分点，这游戏就没法玩了。

2. 总分和等级不信任模型自己报的数。LLM 的算术是出了名的不可靠，让它算五个维度的加权和，隔三差五给你算错一个。所以模型只负责逐维度打分和写点评，加总、定级在代码里重算。

3. 匿名用户不用注册就能玩，每天免费批改一次。防滥用靠的不是强制登录，而是 Apple 的 App Attest——让苹果证明请求来自真机上的正版 App，机器人和脚本过不来。这套东西的原理和服务端验证的坑，我之前单独写过一篇《Apple App Attest 简介》，感兴趣可以看看。

4. 批改额度是”先预扣、失败退还”。最早的实现是先只读检查额度、批改成功了再扣，看起来很稳妥——但批改一次要跑上一两分钟，这个窗口里并发发请求，每个请求检查时都显示”还有额度”，就都放行了，白烧 token。改成预扣制之后，靠 D1 单写者的串行化保证并发下最多放行额度上限那么多个请求，批改失败再把额度退回去。

免费与收费

说说钱的事，明码标价：每天的题目永远免费，匿名一天能批改 1 次，登录后 2 次。Pro 订阅（月付或年付）解锁 200 道历史题库、研读模式（先看标准答案再作答）和每天 15 次批改。订阅收入拿去付 AI 推理的账单——每一次批改都是真金白银的 API 调用，所以免费额度给得抠门，请理解哈哈。

来玩

App Store 搜「DailyDiff」或「每日一辨」，或者直接点这个链接。中英文界面都有，今天的题不用注册就能做。

如果你试了之后觉得 AI 批改哪次明显不靠谱，或者有任何建议，欢迎邮件 support@dailydiff.vip 或者直接在下面留言——独立开发，每一条反馈我都会看。

顺便说一句，今天的题你打算拿几分？我至今没拿到过自己 App 里的 SSS。

就此，完毕。

The post 每日一辨 DailyDiff first appeared on I am LAZY bones?.

这次发 2.3.0 的时候我终于忍不住了：这玩意儿就没有 CLI 能自动化吗？

还真有，而且就是 fastlane。有意思的是，fastlane 我其实早就装了——之前一直拿它给 App Store 截图加设备边框（frameit），我一直以为它就是个截图美化工具，哈哈。这次才发现，截图加框只是它十八般武艺里最不起眼的一样。

fastlane 到底是什么

fastlane 的定位是”把 iOS/Android 发布流程的每个环节都变成可脚本化的命令”。它其实是一整套工具的集合，每个工具管一段：

1. deliver：上传元数据（What’s New、描述、关键词、截图）到 App Store Connect，本文主角。
2. snapshot：跑 UI 测试自动截图，能覆盖每种语言 × 每种设备尺寸。
3. frameit：给截图加设备边框，我之前唯一用过的那个。
4. gym / pilot：打包上传、TestFlight 分发和测试员管理。
5. match / cert / sigh：证书和描述文件的团队共享管理。
6. precheck：上传前扫描文案里的审核高危词。

单人开发、Xcode 自动签名的话，match 这类团队工具基本用不上；但 deliver 对多语言 App 来说是刚需级的效率工具。

deliver：把 ASC 表单变成本地文件

deliver 的思路很直接：ASC 后台的每个表单字段，对应本地一个文本文件，目录按语言组织：

fastlane/metadata/
├── zh-Hans/
│   ├── release_notes.txt      ← What's New
│   └── promotional_text.txt   ← 推广文本
├── en-US/
├── ja/
├── ko/
├── de-DE/
├── fr-FR/
└── ar-SA/

一个很贴心的设计是：目录里有什么文件，它就只上传什么。我只放了 release_notes.txt 和 promotional_text.txt，那么描述、关键词、截图这些都不会被碰。配置文件 Deliverfile 里再把二进制和截图明确跳过：

app_identifier "Senob.NightSnore"

skip_binary_upload true
skip_screenshots true
force true                        # 跳过上传前的 HTML 预览确认
run_precheck_before_submit false
submit_for_review false           # 只填表单，提交审核仍手动

搭一条 What’s New 流水线

我的 App Store 文案一直维护在仓库的 AppStore/*.md 里（七个语言各一个文件），每次发版往里追加一段”## What’s New (X.Y.Z)”。这个 Markdown 就是唯一数据源，所以流水线只需要一个提取脚本：从 md 里抠出指定版本的段落，写到 deliver 要的 metadata 目录去。再包一个 fastlane lane 串起来：

lane :whatsnew do |options|
  version = options[:version] || get_version_number(
    xcodeproj: "NightSnore.xcodeproj",
    target: "NightSnore"
  )

  # 从 AppStore/*.md 生成 fastlane/metadata/<locale>/release_notes.txt
  sh("python3", "../utils/whatsnew_sync.py", version)

  deliver(
    api_key_path: "fastlane/api_key.json",
    app_version: version
  )
end

提取脚本里顺手做了两层校验：七个语言缺任何一个对应版本的段落就直接报错（强制多语言同步，防漏），超过 ASC 的字符上限（What’s New 4000 字符、Promotional Text 170 字符）也直接拦下。以后发版就是一条命令：

$ fastlane whatsnew version:2.3.0
[18:02:20]: ▸ 同步版本 2.3.0 的 What's New + Promotional Text → fastlane/metadata/
[18:02:20]: ▸ zh-Hans  notes  240 字符 / promo  57 字符
[18:02:20]: ▸ en-US    notes  659 字符 / promo 158 字符
...
[18:02:29]: Uploading metadata to App Store Connect for localized version 'ja'
[18:02:29]: Uploading metadata to App Store Connect for localized version 'ar-SA'
[18:02:31]:  2.3.0 七语言 What's New 已同步到 ASC
[18:02:31]: fastlane.tools finished successfully 

从跑命令到 ASC 七个语言全部填好，9 秒。之前手动粘贴至少十分钟，还得祈祷别粘串了语言。

API Key，和一个专门坑你的格式问题

deliver 走的是 App Store Connect API，需要一个 API 密钥：ASC 后台”用户和访问 → 集成 → App Store Connect API”里创建一个团队密钥，角色选 App Manager，会得到一个 .p8 私钥文件（只能下载一次）加 Key ID 和 Issuer ID。

然后我就结结实实踩了个坑。deliver 支持用一个 JSON 文件传密钥，我很自然地写成了指向 .p8 文件路径的形式，结果：

Spaceship::ConnectAPI::Token.from_json_file':
[!] App Store Connect API key JSON is missing field(s): key (RuntimeError)

查了才知道：fastlane 的 Fastfile 里有个 app_store_connect_api_key 这个 action，它支持 key_filepath 参数指向 .p8 文件；但 deliver 的 api_key_path 参数指向的 JSON 文件，只认内联的 key 字段——你得把 .p8 的 PEM 内容整个塞进 JSON 字符串里（换行转成 \n）。同一个工具链里两种密钥写法长得几乎一样但互不兼容，这不纯纯挖坑嘛。正确格式长这样：

{
  "key_id": "ABCD123456",
  "issuer_id": "12345678-abcd-....",
  "key": "-----BEGIN PRIVATE KEY-----\nMIGT...\n-----END PRIVATE KEY-----",
  "in_house": false
}

这个文件含私钥，务必进 .gitignore，待遇跟你的其他 secrets 一样。

踩坑与注意事项

1. deliver 只能写”可编辑状态”的版本（准备提交、被拒等），已在审核中或已上架的版本改不了。所以要在上传 build 之后、点提交审核之前跑它；版本还没建也没关系，deliver 会自动创建。

2. locale 代码不都带地区后缀：日语是 ja 不是 ja-JP，韩语是 ko，但英语是 en-US、德语是 de-DE。写映射表的时候留意。

3. metadata 目录里有什么就传什么，这既是特性也是风险：目录里残留一个过期的 description.txt，就会把线上描述覆盖掉。我的做法是 metadata 目录整个 gitignore，每次由脚本从 md 重新生成，保证它永远是纯派生产物。

用 skill 操作，vibe coding 更顺畅

还有一层我觉得比工具本身更有意思：这整条流水线，从功能开发、写七语言文案，到搭 fastlane、踩坑、修好，都是在 Claude Code 里完成的。搭好之后我顺手让它把整个发版流程沉淀成一个项目 skill——仓库里的一个 .claude/skills/release/SKILL.md 文件，把九个步骤写成清单：bump 版本号 → 编译验证 → 七语言 What’s New / Promotional Text → commit → xcodebuild 归档上传 → 打 tag → fastlane 同步 ASC 表单，连”deliver 的 JSON 只认内联 key”这种坑位说明都写在里面。

下次发版，我只需要说一句 /release 2.4.0，AI 就照着清单把整条链路跑完，唯一剩下的手动操作是去 ASC 点提交审核。skill 跟着仓库走，clone 下来就有，等于把发版的”部落知识”固化成了可执行的文档。对 vibe coding 来说这很关键：写代码交给 AI 大家都会了，但发布环节往往还是人肉在各个后台之间点来点去——把这段也纳入对话式工作流，从开发到上架才算真正闭环。

下一个目标

尝到甜头之后我看了一圈 fastlane 工具箱，对我这种多语言独立开发场景，下一个最值得上的是 snapshot：七个语言的商店截图现在还是手动截的，每次界面大改就是一下午。snapshot 跑 UI 测试自动出全语言截图，再接上我已经会用的 frameit 加框、deliver 上传，理论上截图这条线也能变成一条命令。挖个坑，做完再写。

发布流程自动化这件事，本质上是把”每次发版都要凭记忆和手感重复一遍的操作”变成”写一次、以后白嫖”的脚本。对独立开发者来说，省的那十几分钟是小事，真正值钱的是不再需要担心”这次是不是又漏了哪个语言”——机器不会漏。

就此，完毕。

The post fastlane——App Store Connect CLI（非官方） first appeared on I am LAZY bones?.

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

OKF 到底是个啥

说穿了特别朴素：一堆带 YAML frontmatter 的 Markdown 文件，按目录组织起来，就这么点东西。没有复杂的压缩、没有运行时、不强制你装任何 SDK。一个 OKF 的 bundle（知识包）就是一个目录，每个概念对应一个 .md 文件：

sales/
├── datasets/
│   └── orders_db.md
├── tables/
│   ├── orders.md
│   └── customers.md
└── metrics/
    └── weekly_active_users.md

每个文件头上用 YAML 写结构化字段，正文用 Markdown 写说明、schema 之类。比如一张订单表，用Google自己的例子，大概长这样：

---
type: BigQuery Table
title: Orders
description: One row per completed customer order.
resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders
tags: [sales, revenue]
timestamp: 2026-05-28T14:30:00Z
---

# Schema
| Column | Type | Description |
|--------|------|-------------|
| `order_id` | STRING | Globally unique order identifier. |
| `customer_id` | STRING | FK to [customers](/tables/customers.md). |
......

注意最后那行——customer_id 直接用 Markdown 链接指向了 customers 表。文档之间这么互相一引用，整个知识包其实就织成了一张图。人能读，agent 也能顺着链接爬。

很克制

我个人比较欣赏它的一点是”少管闲事”。整个规范里强制要求的字段只有一个：type。其余全交给生产者自己定。这意味着它不会因为你的场景特殊就用不了。

围绕这点，它立了三条原则，我觉得是整个设计的魂：

1. 极简约束——只认 type，绝不替你过度规定。
2. 生产者和消费者解耦——格式本身就是契约。谁来生成这些文件、谁来消费它们，两边可以各自独立替换，互不绑死。
3. 是格式，不是平台——没有厂商锁定，不依赖某朵云，不要专有 SDK。这条是它跟那些”元数据目录产品”最本质的区别。

这三条凑一块，好处就很实在了：人可读（任意编辑器能打开，GitHub 能直接渲染），可移植（打成 tarball、塞进 git、挂任意文件系统都行），可互操作（A 团队产的知识包，B 团队的 agent 不用翻译直接就能吃）。而且因为就是一堆文本文件，它可以躺在版本控制里，跟代码放一起，agent 能读也能改，团队像 review 代码一样 review 知识。

Google 顺手给了几个轮子

光发个规范是空的，所以这次还附带了配套，降低上手门槛：一个参考用的”富化 agent”，能从 BigQuery 数据集自动生成 OKF 文档；一个纯静态的 HTML 可视化器，不需要任何后端，打开就能看那张知识图谱长啥样；外加三个示例 bundle——GA4、Stack Overflow、Bitcoin 数据集，拿来照着学格式正好。

这里头我觉得最值得单拎出来说的是那个富化 agent，因为它远不只是”导出元数据”那么简单。

富化 agent：让 LLM 去读文档

名字里”富化”（enrichment）这俩字是关键。光靠 BigQuery 的元数据，你能拿到的只是表名、列名、类型这些骨架；可 customer_id 到底什么含义、orders 和 customers 怎么关联、某个枚举值代表哪种业务状态——这些”肉”通常只长在人写的文档里。富化 agent 干的就是把骨架和肉缝起来。它的做法是两段式（two-pass）：

第一段，BigQuery Pass。扫源数据集，光靠 BigQuery 自身元数据，给每个发现的概念（表、字段、数据集）生成一份初始 OKF 文档。这步是机械的、确定的，产出骨架。

第二段，Web Pass，这段才是精华——它把一个 LLM（Gemini，走 AI Studio 或 Vertex AI）当成一个会自主决策的爬虫：你丢给它几个种子 URL（--web-seed，一般是官方文档地址），agent 用一个 fetch_url 工具去抓页面，然后 LLM 自己判断每页”看起来像不像权威文档”，再决定怎么处理——是拿来丰富某个已有的概念文档，还是单独建一份参考文档，还是这页没用直接跳过。它不是傻爬，是带着”我手里有哪些概念、这页能补哪个”的目标在选择性吸收。

既然是放 LLM 出去爬网，缰绳得备好：--web-max-pages 限制最多抓多少页，防止跑飞；--web-allowed-host 上域名白名单，只许它在你信任的站点里转悠。

最后吐出来的，就是一组分层组织好、带 frontmatter、能直接进版本控制的自包含 bundle。说白了，这个 agent 是 Google 给的一份”如何把现有系统改造成 OKF 生产者”的样板：结构化元数据打底，再让 LLM 读人类文档来富化——你完全可以照着这套路，给自家的数据系统写个类似的生产者。

可视化器：一个 HTML 文件就是查看器

如果说富化 agent 是”生产端”的样板，那这个可视化器就是”消费端”的样板，而且它把 OKF “是格式不是平台”那套哲学贯彻得相当彻底——连查看器都拒绝引入后端，就一个静态 HTML 文件。生成命令是富化 agent 的一个子命令：

.venv/bin/python -m reference_agent visualize --bundle ./bundles/stackoverflow
# 写出 bundles/stackoverflow/viz.html

它在生成时把整个 bundle 当成一段 JSON 直接嵌进 HTML 里，所以产物是个自给自足的单文件，可以分享、可以丢任意静态服务器、也可以跟 bundle 一起 commit。Google 就是这么干的——仓库里直接躺着三个生成好的 viz.html（GA4 50KB、Stack Overflow 122KB、Bitcoin 28KB），双击就能在浏览器里打开，看的人那边什么都不用装。

打开后是个左图右文的单页：左边一张力导向图，每个概念是个节点，颜色按 type 区分（table / dataset / reference…），节点之间的有向边就是文档正文里那些 Markdown 互链——前面说的那张”知识图谱”，在这儿被画了出来；点某个节点，右边详情面板就用 marked 把那份 .md 的 frontmatter 和正文实时渲染出来，正文里的内部链接还被改写成”在查看器里跳转”，点了不会把你甩走，而是切到对应节点。顶上一排是搜索框（匹配标题、ID、tags）、type 过滤、还有好几种图布局可切（cose、concentric、breadth-first、circle…）。图用 Cytoscape.js 渲染，全程在浏览器里跑，数据不出本地。

光说没用，我把 Stack Overflow 那个样例的 viz.html 直接搬到了自己博客下，你点开就能玩：stackoverflow_viz.html。其实我这个动作本身就是 OKF “好传播”的一个现成注脚——一个别人生成的知识查看器，我啥都不改、原样拷过来挂上就能用，这要是搁个需要起后端、连数据库的”平台”，可没这么轻巧。

几个我会留意的点

新东西总归要泼点冷水，几个我看完留了心眼的地方：

1. 目前才 v0.1。规范号摆在这，意思是接口和约定都还可能动，真要拿去做生产，得做好跟着升级的准备。
2. “只强制 type”是把双刃剑。约束少确实灵活，但也意味着不同团队产出的字段可能五花八门，跨组织互操作时，光有格式统一、字段语义不统一，照样得对齐。这部分活儿规范帮不了你。
3. 它解决的是”知识怎么存、怎么传”，不解决”知识怎么保证是对的、是新的”。frontmatter 里那个 timestamp 写得再漂亮，背后没人维护，照样会过期。说到底它是个格式，不是个能自动保鲜的系统。

说点本质的

抛开这些细节，我觉得 OKF 真正想干的事很清楚：在这个人人都在拿内部数据喂 agent 的当口，给”知识”这件东西定一个最朴素、最不挑食的通用载体。用最普通的文件约定，换跨工具、跨组织、跨时间的可移植性——这套思路，过去在代码上是 Git 干成的，在文档上是 Markdown 干成的。OKF 想在”知识”这一层复刻同样的故事。

能不能成，要看有多少人愿意给自己的系统写”生产者”、给自己的 agent 写”消费者”，把生态滚起来。但方向我是认的：与其每家都把知识锁在自己那套不兼容的专有系统里，不如先在格式上达成一致。毕竟，朴素的东西才传得开。

就此，完毕。

The post 聊聊 Google 的 OKF first appeared on I am LAZY bones?.

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

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

我想实现的是”匿名用户每天送一次 AI 评分”，不登录就能用，体验好、转化高。可这接口裸奔在公网上，谁拿 curl 写个循环都能把额度刷爆。加验证码太伤体验，强制登录又把”尝鲜”这个卖点废了。

我想要的其实是一句话：能不能让服务器确信”这条请求确实是从我那个正版 App、在一台真机上发出来的”？Apple 的 App Attest 就是干这个的。这篇把它的原理、整体流程，以及服务端到底该怎么验，讲清楚；我自己趟过的几个坑放在最后当佐料。

App Attest 解决的是什么问题

传统的”防刷”思路是给请求带个密钥或 token，可只要密钥在客户端，逆向、抓包、改包就能仿造，挡不住有心人。App Attest 换了个思路：它借助 Secure Enclave（设备上独立的安全芯片），由苹果来给你的 App 背书，证明两件事——这是从 App Store 渠道的正版 App 发出的，且跑在一台真实的苹果设备上。

这个背书是密码学保证的：签名私钥生成在 Secure Enclave 里、永远导不出来，连越狱也偷不走。所以它特别适合”匿名但要防滥用”的场景：免费额度、防注册机刷号、防接口被脚本薅。它不是用户身份认证（那是 Sign in with Apple 的活），它认的是”设备 + App”这个组合可信。

代价是它只在真机、正版渠道下成立——模拟器用不了，这点后面会再提。

两段式：attestation 和 assertion

理解 App Attest，关键是分清它的两段，这俩验证逻辑完全不同。

第一段 attestation，一次性的。App 首次要证明自己时，在 Secure Enclave 里生成一对密钥，请苹果给这把公钥签发一张证书；证书连同一坨 authenticator data 打包成 attestation 对象，发给你的服务器。服务器验完，把这把公钥存进库，跟这台设备绑定。这一步只做一次。

第二段 assertion，每次请求都做。App 用第一段那把私钥，对”本次请求的内容”签个名，随请求发出。服务器用之前存下的公钥验签——对得上，就说明这条请求确实来自那台被证明过的设备，且内容没被篡改。

客户端的代码很薄，DCAppAttestService 几个方法调一调就行。真正有讲究的是服务端这两段验证，下面分开说。

服务端怎么验 attestation

attestation 对象 CBOR 解开后，核心是一条证书链 x5c 和一段 authData。要验的东西不少，挑要点说：

证书链。x5c 里只有两张证书：给设备公钥签的叶子证书，和一张中间证书。你要做的是把它验到苹果的 App Attest 根证书。这里有个反直觉的点——根证书不在链里。别去比对”链里最后一张是不是根”，那是中间证书。正确做法是把苹果根证书内嵌进代码，用它的公钥验中间证书，再用中间证书验叶子。根证书是信任锚，得自己持有，不能从对方给的链里取。苹果根证书在 certificate authority 页面下载，建议顺手核对哈希：

curl -fsS https://www.apple.com/certificateauthority/Apple_App_Attestation_Root_CA.pem \
  | openssl x509 -outform DER | shasum -a 256
1cb9823ba28ba6ad2d33a006941de2ae4f513ef1d4e831b9f7e0fa7b6242c932  -

nonce。光证明”证书合法”挡不住重放——截一个合法 attestation 反复发也行。苹果的办法是：服务器先发一个随机 challenge，苹果会在叶子证书的扩展里（OID 1.2.840.113635.100.8.2）塞进 nonce = SHA256(authData ‖ SHA256(challenge))。服务器照样算一遍比对，对上才说明这份证明是冲着你这次的 challenge 来的，authData 也没被动过。

剩下几项是常规校验：rpIdHash 要等于 SHA256(appId)（appId = Team ID 加 Bundle ID）；新鲜的 attestation 计数器必须是 0；aaguid 标明这是 App Attest（正式环境是 appattest，Xcode 调试走的开发环境是 appattestdevelop，两者都要放行）；最后把 authData 里的公钥 SHA256 一下，应当等于凭证 ID。全过了，把这把公钥存库。

证书链验签自己撸 ASN.1 容易出隐蔽 bug，我直接用了 @peculiar/x509，它在 Cloudflare Worker 的 WebCrypto 环境里能跑。

服务端怎么验 assertion

每次请求的验证简单些：CBOR 解开 assertion 拿到签名和 authenticatorData，先验 rpIdHash、再查计数器是否比库里存的大（防重放，每签一次苹果会自增），最后用存下的公钥验签。

验签的消息构造是这段里唯一的”暗礁”。苹果文档说签名覆盖的是 authenticatorData ‖ clientDataHash，但你要是把这俩直接拼起来交给 ECDSA-SHA256 去验，会失败。真相是：苹果用 ES256 签的是 nonce = SHA256(authData ‖ clientDataHash)，而 ES256 自己还会再 hash 一层，所以最终参与 ECDSA 的摘要是 SHA256(nonce)。WebCrypto 的 ECDSA 必定做一次 hash、跳不过，因此正确写法是先把 nonce 算出来，再把 nonce 当消息传进去，让它在上面再 hash 一次：

const base  = concat(authData, clientDataHash);
const nonce = new Uint8Array(await crypto.subtle.digest("SHA-256", base));
const ok = await crypto.subtle.verify(
  { name: "ECDSA", hash: "SHA-256" }, key, sigP1363, nonce
);

这层”看不见的 hash”我是把原始字节 dump 出来在本地穷举才定位到的——推理走不动时，让事实说话往往更快。

实现时几个容易绊倒的点

主线讲完了，把我真机联调时踩到的坑列一下，纯属佐料，但能省你几个小时：

1. Team ID 不一定是你以为的那个。报 “RP ID hash mismatch” 时我很懵，appId 明明拼对了。后来去构建产物里一看，签名证书的 team 和描述文件的 team 是两个，App Attest 取的是 application-identifier 里那个：

codesign -dvv MyApp.app
Authority=Apple Development: 我的名字 (TEAMBBBBBB)
TeamIdentifier=TEAMAAAAAA          # appId 用的是这个

2. COSE 公钥是整数键。authData 里那把公钥是 COSE 格式，x、y 的键是 -2、-3 这种整数。cborg 默认解对象会直接抛 “non-string keys not supported”，得开 useMaps 解成 Map 再 get：

const coseKey = cborDecode(authData.slice(coseOffset), { useMaps: true });
const x = coseKey.get(-2);
const y = coseKey.get(-3);

3. 模拟器测不了。App Attest 在模拟器上直接不支持，匿名链路只能上真机。开发期可以在服务端留个开关跳过验证方便联调，但上线前务必删掉。

值不值得用

如果你有”匿名 / 低门槛、但又怕被脚本滥用”的接口，App Attest 是目前苹果生态里最硬的一道闸：信任根在苹果、私钥锁在 Secure Enclave，比任何塞在客户端的密钥都难仿造。代价是只覆盖真机正版、客户端服务端都得改、还得忍受一段真机调试的来回。

它的坑也基本都不在文档主线上，而在那些”想当然”的接缝处——根证书的位置、Team ID 的来源、COSE 的键类型、ES256 那层默认的 hash。单看每个都不难，叠在一起就够耗你一天。提前知道它们长什么样，就能少趟很多。

全文完。

The post Apple App Attest简介 first appeared on I am LAZY bones?.