← 返回日报索引

2026-10-23 GitHub 趋势研究简报

证据边界： 本日全部元数据取自 2026-10-23 CST 06:00 前后经 gh CLI 认证的 GitHub REST / Search API（search/repositories（created:>2026-10-15 stars:>120）、repos/{owner}/{repo}、repos/{owner}/{repo}/readme（Accept: application/vnd.github.raw）、repos/{owner}/{repo}/contents/{LICENSE,AGENTS.md,.gitmodules,doc/inference_deployment_qa.md,THIRD_PARTY_NOTICES.md}、repos/{owner}/{repo}/git/trees/HEAD 与 ?recursive=1、repos/{owner}/{repo}/releases、repos/{owner}/{repo}/commits、repos/{owner}/{repo}/contributors），字段包括 stargazers_count / forks_count / subscribers_count / open_issues_count / size / language / license.spdx_id / topics / created_at / pushed_at / description。「X 小时 / Y 天 Z⭐」按 created_at（UTC）到 2026-10-23 计算，总星数除以经过时长为下限粗估；单日 star 增量未做统计（需分页遍历 stargazer 列表），因此所有增速表述都不能读作当日新增。已核验为空/为零并直接标注的字段：releases API 对 deepseek-ai/DeepInfer、Acelogic/Snapintosh、UniXNU/UniXNU 三者均返回空数组或长度 0（三者的主分发路径分别是 ./build.sh 从源码构建、clone + submodule 自建、以及文档 + 自编译）；subscribers_count 为 3 / 43 / 4 / 0（DeepInfer 43 为本批最高，reylo 0 为本批最低）；topics 字段对 DeepInfer 与 reylo 为空数组（UniXNU 有 1 个 topic，Snapintosh 为 0）。发现两处可核验的元数据不一致（本日报新增）：UniXNU/UniXNU 与 Acelogic/Snapintosh 的 license.spdx_id 均为 NOASSERTION，但两者的 LICENSE 文件首行分别明写 SPDX-License-Identifier: BSD-2-Clause-Patent 与 MIT License，且 THIRD_PARTY_NOTICES.md 也写明「Snapintosh is licensed under the MIT licence」——以文件为准两者均可正常使用，但 GitHub 侧无法被自动识别为标准许可证，依赖 license 扫描器的工具会当成非标准协议处理。这与 10-22 记录的 ikow/php2shell-poc（spdx_id 为 null 而 README 写 MIT）性质相同但严重程度低得多（本次两处 LICENSE 文件本身内容清晰无歧义，而 php2shell-poc 的 README 与元数据直接冲突）。热度的关键限定：本日四个项目 fork-star 分化为 0.5% / 5.5% / 10.6% / 15.7%，但这四个数字不可直接横向比较——高 fork 比例的两个项目（UniXNU 15.7%、DeepInfer 10.6%）分别是「fork 去移植自己的机型」与「fork 去读它的调度逻辑」，低 fork 比例的两个项目（Snapintosh 5.5%、reylo 0.5%）分别是「只支持一台机器，没有第二台可移植」与「需要的是等上游 beta 特性稳定而不是 fork 它」。连续第三天观察到同一条分界线：fork 比例在「可改造型项目」与「不可改造型项目」之间不可比。 本日没有 CVE 驱动的注意力洪峰——这是自 10-21 的 php2shell 事件以来第一次，今日热度排序对技术选型的干扰比前两日小；但这四个项目没有一个是可以直接采用的：UniXNU 与 Macintosh 是研究快照（Macintosh 仅 11 个 commit、单机型、需另一台 Mac），DeepInfer 缺三成系统（KV cache / PD 分离 / 负载均衡），reylo 依赖尚未 stable 的 TS 7.1。已过滤的 spam 仓库（本批 Search 结果中出现、已排除）：xscreensaver-official/xscreensaver（1147⭐ ⑂33，README 自述「There is no official XScreenSaver GitHub repository.」——自我否认自身权威性，可核验的伪装）、WoYun520/dsh-purge（401⭐ ⑂687，fork/star 171%，README 自述「DeepSeek Harness 破甲 (mirror of mmparko/dsh-purge) — 全量镜像：全部分支/100 个 tag/完整提交历史」，是完整的仓库镜像而非原创）。未纳入 key_projects 的候选：Gathin23/cleanyourtv（23,714⭐ ⑂2,592 NOASSERTION，19 topics 直打 Android TV 去广告，但该赛道已在 10-19/10-20/10-21/10-22 四份日报连续记录，今日不重复建档）、reason-machines/reason-network（1060⭐ ⑂86 Apache-2.0 Rust，已有 projects/reason-network.md 档案，本窗口未取其 README 故不重复更新）、kividbio/kividb（460⭐ ⑂14 AGPL-3.0 Rust，20 topics「Redis/Valkey 的 Rust drop-in 替代，含全文检索」）、ELY-Open-Source/ElyOffice（850⭐ ⑂54，已有 projects/elyoffice.md 档案，10-21 已建档，本窗口未取 README）、vercel-labs/fx0（382⭐ ⑂70，已有档案，10-21 已建档）、eagle-hq/EAGLE-4（862⭐ ⑂24 NOASSERTION，10-22 已记录为未取 README）、pengchujin/aerial-tv / simbasjungles/free-my-tv（均有档案，10-21/10-20 已建档）。

今日重点趋势（按排名）

趋势 1：Apple 内核移植的两条独立路径，撞上同一组难点（趋势分 90）

这是本日最值得记的结构性观察。两个互不相识、作者不同、路径不同的项目，在同一天各自解决同一个问题，并各自独立地把「Apple 私有输入不得入库」写成了仓库级制度。

先固定事实基线（全部来自 GitHub 官方接口与 README/AGENTS.md 原文）：

事实 UniXNU/UniXNU Acelogic/Snapintosh
目标 iOS + macOS 跑在非 Apple ARM64 硬件 macOS 27（build 26A428）跑在 Snapdragon X2 Elite 笔记本
路径 UEFI + 伪平台契约 EL2 hypervisor（monitor）+ 工具链
内核 官方 XNU，不 patch（README 明写补齐平台契约） 官方 kernelcache（J700/T8140），默认未修改
设备覆盖 35 份设备文档，多机型移植 只支持一台（ASUS Zenbook A16 UX3607OA，X2E-96-100，README 原文「Nothing else is supported」）
页表难点 docs/xnu/four-k-page-tables 单列一章 shadow/ 目录（16 KiB → 4 KiB 影子页表）
GPU 原生 Adreno 740 Metal 驱动（10-22 news） 自写 AdrenoMetal.bundle + AdrenoX2 + air2ir3 shader 编译器
私有输入 README 的 Private blobs 段 AGENTS.md 第 1 条 + THIRD_PARTY_NOTICES.md
额外依赖 — 必须有一台 macOS 27 Mac 主机（USB-C NCM）
规模信号 35 设备 · 16 驱动 submodule · subs 3 · 贡献者 6 人 · 30 commits 11 commits（5 小时内完成）· subs 4
许可 BSD-2-Clause-Patent（文件）/ NOASSERTION（API） MIT（文件）/ NOASSERTION（API）

共同的三个技术难点：

  1. 16 KiB → 4 KiB 页表翻译。Apple 的 XNU 用 16 KiB 页，而绝大多数 ARM64 SoC 的 MMU 只支持 4 KiB。两个项目都把它单列为核心章节/核心目录——这说明它是这类移植绕不过去的第一个真问题，而不是某个项目的个性选择。

  2. Apple 平台契约的构造。UniXNU 的做法是提供内核"认识的"设备与寄存器（16 个 Native* submodule + Arm* 平台层）；Macintosh 的做法是在 EL2 提供 SPTM/TXM 调用、内核 16 KiB 页表翻译、以及 AIC / ANS2 NVMe / DART 等 Apple 设备模型。两者都不 patch 内核——这是一个共同的、且反直觉的取舍：继承内核的全部不兼容，换来内核升级时零 rebase。

  3. 私有输入的合规处理。UniXNU README：「Do not add Apple IPSW files, kernelcaches, disk images, trust caches, Data seeds or vendor firmware to this repository.」Macintosh AGENTS.md 第 1 条列举了九类不得提交的内容（kernelcache、固件、restore-image 部件、KDK、kext、dyld cache、ACPI dump、反汇编/vtable/ABI dump、重建的 *26A428.h 头文件），并加了一句「Do not paste protected source material into PRs, tickets, build logs or test fixtures」——把禁止范围从代码扩展到了 issue、构建日志与测试夹具。

架构师速览（UniXNU）：

决策问题 研究判断 证据边界
系统边界 Apple 内核保持官方二进制不动，边界划在"内核之下"：UEFI 引导链（uefi-sheng 等仓库）+ 平台契约提供者（设备树、时钟、寄存器、设备模型、4 KiB 页表补丁）+ 16 个 Darwin 侧驱动 submodule。数据面是内核对硬件的读写；控制面是构建系统按设备选择 modules 与 kit 全部来自 README 的 Repositories 表 + .gitmodules 的 16 条 URL + Documentation 目录清单；平台契约提供者的具体实现形式（kext / 伪装固件 / 两者）README 未展开，docs/concepts/{prelink,userdata,payload}.md 存在但本窗口未取内容
主路径 设备上电 → UEFI 固件（移植版）→ DarwinBoot 装载官方 kernelcache → 平台契约层向内核呈现它认识的设备与寄存器 → XNU 启动到 EL1 → Native* 驱动接管实际硬件（含 Adreno GPU 经自研 Metal 驱动）→ 用户空间 由 README 的 boot chain 文档结构 + .gitmodules 分层 + news 段落推出；官方 kernelcache 从哪来 README 明令不得入库，docs/concepts/payload.md 应有说明但未取
关键权衡 伪 Apple 硬件 vs 重写 Linux 侧驱动（与 Asahi 路线相反）· 保持官方内核 vs patch 内核（前者继承全部漏洞与不兼容但零 rebase）· 驱动独立仓库 vs 单一大仓库（前者让移植者只 clone 自己机型需要的部分）· BSD-2-Clause-Patent vs 宽松许可（含专利条款在逆向领域是保护，但会劝退部分商业使用者）· 原生 GPU 驱动 vs GPU 透传/虚拟 AGX（gpu/agx* 显示其自身也走过更省事的路并放弃了） README news 段 + Documentation 清单 + .gitmodules 16 条 + LICENSE 首行 SPDX 标识 + docs/drivers/native-adreno.md 存在；「为什么从虚拟 AGX 转向原生驱动」README 未解释
最小 PoC 1. 确认目标机型未被 35 份 docs/devices/*.md 覆盖（这是唯一决定可行性的变量）→ 2. 在已支持机型上跑通整条链作对照 → 3. 按 docs/drivers/device-tree-matching.md 做设备树匹配 → 4. 按 docs/porting/ 复制最接近的机型仓库作模板 → 5. 官方 kernelcache 与固件留在本地不入库 → 6. 只验证"能进内核并跑起来"，不要一上来碰 GPU 顺序按依赖倒排；第 1 步（机型是否已被覆盖）是唯一真实门槛，第 5 步是合规前提而非可选项；README 未给最低机型门槛（内存/存储/SoC 特性要求），本日报无法核验

架构师速览（Macintosh）：

决策问题 研究判断 证据边界
系统边界 一台 ASUS Zenbook A16 + 一台必须存在的 macOS 27 Mac 主机（USB-C NCM）+ EL2 monitor（compat/ shadow/ probes/）+ EL1 官方内核与 AuxKC + EL0 用户空间与 Metal 插件。控制面在 EL2 契约提供者与主机侧工具链；数据面是 GPU 命令流与 NVMe I/O 全部来自 README 自带的 Architecture in brief mermaid 图、Repository layout 表、AGENTS.md 分层职责表；q1n1 只做 proxy，实际驱动逻辑在 tools/cycle.py 与 q1n1 proxy client 侧，控制流未细述
主路径 A16 UEFI → q1n1（EL2 proxy，USB-C NCM 连 Mac 主机）→ Snapintosh EL2 monitor（SPTM/TXM 契约、16K→4K 影子页表、AIC/ANS2/DART、GPU ring 与 SMMU 中介）→ 官方 XNU + AuxKC（AdrenoX2 + AdrenoDisplay、SnapI2CHID 等）→ 用户空间（WindowServer、Core Animation、应用、AdrenoMetal.bundle + air2ir3） README 自带 mermaid 图与逐层说明，本档案架构图在此基础上补出「私有输入不入库」边界与待核验节点；air2ir3 编译器在运行期的角色（按需 vs 构建期预编译）未明说，待核验
关键权衡 不改内核 vs 改内核 · 自写 Metal 驱动 + shader 编译器 vs 虚拟 AGX vs 透传（README 明文否决软件/CPU/半虚拟路径，gpu/agx* 是保留的早期路线）· 依赖 Mac 主机 vs 独立运行（AGENTS.md 明写独立运行是「a direction, not an already implemented or authorized replacement」）· 只支持一台机器 vs 多机型 · GPL-2.0 成分与 MIT 主体共存 AGENTS.md 三条硬规则 + Status 表 + Required hardware 段 + gpu/agx* 目录 + LICENSES/ 四份文本；未明示：为什么依赖 Mac 主机、GPU ring 中介的具体实现、air2ir3 的支持度
最小 PoC 1. 确认有指定那台机器（不支持任何其他机型）→ 2. 确认有第二台 macOS 27 Mac 主机（比目标机更硬的门槛）→ 3. 按 docs/RUNNING.md 接 USB-C 并 AC 供电→ 4. 按 AGENTS.md「Start Here」读 README → ARCHITECTURE → BUILDING → STATUS（硬件执行再读 RUNNING），AGENTS.md 明写「Do not rely on status summaries from earlier sessions in place of the current tree」→ 5. 从自己机器获取 kernelcache 与固件（不下载不提交）→ 6. 只验证 Status 表第一行（启动到桌面 + 像素检查通过）→ 7. 不要验证 60 Hz（README 自己写着 in progress，当失败判据是误读）→ 8. 用 tools/test-* 与 tools/replay-* 对照而非重复跑真机 第 1–2 步是纯硬件门槛，先于任何技术判断；第 7 步是本 PoC 最重要的判断：Status 表把"已可用"与"进行中"明确分开，读错这张表就会得出错误结论

趋势 2：把"不在范围内的东西"写进 README（趋势分 89）

deepseek-ai/DeepInfer（7 天 19,806⭐ ⑂2,106 fork/star 10.6%，subs 43 为本批最高，Apache-2.0）是本日唯一一个由头部模型厂商官方开源、且明确描述了自己生产环境规模的项目。

doc/inference_deployment_qa.md 里的三目标把整个架构的来源说清楚了：支持多厂商加速器 · 围绕商用硬件组织 prefill 与 decode（普通 8-GPU 机做 prefill，普通 64–128-GPU 超节点做 decode）· KV cache 保留超过 72 小时以换上下文复用。同一份文档给出规模声明：单集群每日 15.5 万亿 token、每 GPU 小时 38 美元（谷值定价）。

最值得记的是它对"不含什么"的处理。 README 有一整段叫 Required for a complete inference service (not included in this release)，列出三项：KV cache 系统 · VE/Prefill/Decode 分离（注明"引擎大部分必需功能已实现"）· prefill 与 decode 两侧的跨 DP 副本负载均衡。QA 文档补充：KV cache 管理与负载均衡"与内部基础设施耦合紧密，尚未完全开源"。

这个信息的后果是实质性的：即使全部编译成功，也无法用它复现 72h 缓存复用——而那是这个框架最核心的设计目标之一。这与本日另一个项目 Macintosh 的 Status 表（逐项写明"不支持"）是同一种纪律的两种形态。

架构师速览（DeepInfer）：

决策问题 研究判断 证据边界
系统边界 Python 包 + csrc/ + vendor/（顶层：csrc, deep_cluster, deepinfer, doc, eval, examples, scripts, tests, vendor）。边界清晰地停在 KV cache 与负载均衡之前。数据面是 GPU/NPU 上的 kernel 执行；控制面是 DP/CP/EP 并行组构、批次调度、投机解码的验证调度 README 的三项"不含" + 顶层目录（deep_cluster/ 暗示集群能力有部分代码）+ QA 文档的「not yet fully open-sourced」；deep_cluster/ 的实际内容与 PD 分离实现程度未取，待核验
主路径 加载 checkpoint（默认首次下载 DeepSeek-V4.1-Flash-1017，可用 DEEPINFER_HF_MODEL_DIR 指向本地）→ MoE 在（超）节点内用 EP 提升 batch 与 GEMM 效率 → prefill 在 8 卡机、decode 在 64–128 卡超节点 → 异步调度把 CPU 批调度与设备执行重叠 → DSpark 产 draft token、按置信度调度验证 → SWA bounded replay 只重放保留后缀（须覆盖 SWA 窗口 + 最大回退）→ KV cache 保留 >72h（该层不在本次开源范围） 由 QA 文档三目标 + README 特性段 + examples/offline_inference.py 推出；benchmark 硬件（prefill 4×SM100、decode 64×SM100）与生产组织方式一致是可核验的交叉印证，但代码中这两级的自动化切分是否已开源未核验
关键权衡 围绕商用硬件组织 vs 围绕顶级超节点优化 · KV cache 保留 >72h vs 容量与管理开销（文档明说有代价）· 置信度调度验证 vs 固定 draft 长度 · SWA bounded replay 省 prefill vs 保留后缀须覆盖 SWA 窗口 + 最大回退（写死在文档里的正确性约束）· 开源引擎但不开源 KV cache（保住核心调度价值，拿不到完整系统）· batch-invariant + 确定性采样 vs 吞吐（两条均标 NVIDIA only） QA 文档三目标 + README 三项"不含" + 环境变量开关分组 + benchmark 硬件配置与生产组织方式一致的交叉印证；未明示：EPLB 具体策略、draft 模型的显存/算力成本占比、昇腾与 NVIDIA 路径的功能对等程度
最小 PoC 1. 确认硬件落在 NVIDIA SM100 或 Ascend 950 之一（CUDA 13 / CANN 9.2、GCC≥13、Python 3.12）→ 2. 建空 Python 3.12 环境并 export DEEPINFER_ACCELERATOR=nvidia（昇腾改 ascend），跑 ./build.sh → 3. 首次运行下载 checkpoint（或先设 DEEPINFER_HF_MODEL_DIR）→ 4. python examples/offline_inference.py 跑通默认路径——注意默认路径不含 KV cache，72h 复用本 PoC 验证不了 → 5. 逐个开特性且每次只改一个：DEEPINFER_ENABLE_MTP_VARLEN=1 → DEEPINFER_YOCO_PREFILL_TRUNCATION_MODE=compact + ..._KEEP_TOKENS=140 → DEEPINFER_BATCH_INVARIANT=1 → 6. DEEPINFER_BATCH_INVARIANT=1 DEEPINFER_ENABLE_MTP_VARLEN=0 + 固定 seq_seed，验证两次运行输出逐 token 相同——这是整个 PoC 里唯一真正可证伪的一步 → 7. 结构化输出按 examples/_structured_output.py 传 so_args → 8. 复现 benchmark：examples/sweep/run_sweep.sh 第 5 步最值得做：batch-invariant 是本框架少数几个能在一台机器上自我验证的性质，且同时解锁确定性采样；第 4 步要留意 README 自标的三项"不含"——结果与官方 API 有出入时先排除是否落在这三项内，而不是先怀疑框架有 bug

趋势 3：codegen 的派生物从磁盘上消失（趋势分 87）

colinhacks/reylo（1.9 天 616⭐ ⑂3，fork/star 0.5% 为本批最低，subs 0）的方向与前两个项目都不同——它不碰硬件，也不碰集群，只处理一件事：让 SQL 文件本身成为类型的事实源。

它的技术前提是单一且决定性的：TypeScript 7.1 的 content mappers。README 引用的是 microsoft/typescript-go 的 PR #4712，明写「introduced in TypeScript 7.1 (currently in beta)」。

六条卖点里最关键的两条：

还有一条论证方式的转变值得记：「Agent-friendly — each fact lives in one place, so an agent cannot leave a stale type behind, and the type check finds every caller it missed.」这把"单一事实源"从面向人的 DRY 论点改写成面向 agent 的失效模式论证——不再是"这样更整洁"，而是"这样 agent 就无法制造过期状态"。2026 年工具设计开始用「agent 会怎么弄坏它」而不是「人会不会弄错它」来论证，这是一个值得注意的转变。

架构师速览（reylo）：

决策问题 研究判断 证据边界
系统边界 TS 语言插件层（content mapper）· Rust 引擎（engine/）· 对真实数据库的 schema 读取通道 · 类型检查期（tsc 与编辑器）· 运行期（.run(db, params)）。数据面是类型检查时的 SQL 解析 + schema 查询；控制面是 TS 编译器调用 mapper README Setup 段（需 TS 7.1 beta、Node 24+、一个正在运行的开发数据库）+ 六卖点 + Cargo.toml/engine//oracle/ 目录；oracle/、skills/、lab/、wiki/ 的内容未取，待核验
主路径 编辑器或 tsc 遇到 .sql import → 调 content mapper 请求类型 → mapper 交给 Rust 引擎 → 引擎解析 SQL 并连开发库读取当前 schema → 推导该条查询的行类型（受方言与 cast 影响）→ 返回给 type checker → hover 得到类型，错列名/参数在检查期报错 → 运行期 .run(db, params) 执行同一条 SQL 由 README 的 Setup 依赖 + 六卖点 + 示例代码倒排；「schema 读取是否每次检查都发生、是否缓存、缓存如何失效」README 未说明，这是本项目最关键的未决问题
关键权衡 零 codegen（检查时实时查询）vs 生成文件（离线、快、可 review）——实时查询把成本转移到 type check 延迟与对开发库的依赖上 · 对着真实数据库校验 vs 纯静态解析 · 零手写类型 vs 显式类型（可读性） · 依赖 TS 7.1 beta vs 现在就能用（ORM 或 codegen） · 方言原生 SQL 全文力 vs 可移植性（README 强调 "any statement, function, operator or syntax your database supports, in its own dialect"） README 三项依赖 + 六卖点逐条 + cast 直接影响推导结果这一事实（::int → number）；未明示：type check 性能开销、schema 缓存策略、错误信息质量、非 TS 后端的可用性
最小 PoC 1. 先确认 TS 7.1 可安装（npm install -D typescript@beta）——这一步不成立则整个 PoC 不成立，先不要往下走→ 2. 准备 Node 24+ 与运行中的开发库 → 3. 安装三件 → 4. 在 tsconfig.json 为 .sql 与 .reylo.yaml 注册 → 5. 用 README 的 get_author.sql 原样建表并 import，hover 确认类型为 { id: number; name: string; post_count: number } | null → 6. 故意把 post_count 改成不存在的列，确认编辑器立刻标红且 tsc 报错——这一步是整个 PoC 的意义所在：验证"对着数据库校验"是真的而非只做了静态解析 → 7. 改 SQL 的 cast，确认类型随之变化 → 8. 运行 .run() 确认一致 → 9. 测量 type check 延迟（tsc --diagnostics，小项目与大项目各一次）——这是唯一能回答"零 codegen 是否真的划算"的方法 第 5–7 步是最关键的自检：若第 6 步不报错，说明它根本没连库校验，"Checked against your database" 就是空话；第 9 步是 README 完全没提但决定该方案成败的问题

最值得关注的方向

今天四个项目分属四个领域（硬件移植 / 推理框架 / 工具链 / 语言工具），没有一个共同的技术主题。但有一条判断标准可以跨领域复用，而且它在前三天已经连续出现：把边界、缺口与失败模式写成可核验的文档，比 star 数更能预测项目会不会被用起来。

按项目逐个说：

跨项目的第二个观察（本日最实用的一条）：fork-star 在本日四个项目之间完全不可比，但有一个可解释的规律。

项目 ⭐ ⑂ fork-star 归类 机制解释
UniXNU/UniXNU 750 118 15.7% 可改造型 fork 去移植自己的机型——README 专设 docs/porting/，35 份设备文档就是证据
deepseek-ai/DeepInfer 19,806 2,106 10.6% 可读型 fork 去读它的调度逻辑；kernel 栈本身已拆成 5 个独立仓库
Acelogic/Snapintosh 530 29 5.5% 不可改造型 只支持一台机器，没有第二台可移植（README「Nothing else is supported」）
colinhacks/reylo 616 3 0.5% 不可改造型 需要的是等 TS 7.1 stable 并升级，而不是 fork 它

推断（不构成事实）：本批四个数据点显示，fork 比例与「项目是否允许/需要用户改造」相关，而与项目质量、热度或价值无关。这是连续第三天观察到同一条分界线（10-21 记录 1.1%–18.6%，10-22 记录 5.5%–35.9%，本日记录 0.5%–15.7%）。但这仍是四个数据点，不足以支撑任何普遍结论。

必须同时说清的第三点：本日没有事件驱动的热度洪峰，但"没有一个可直接采用"这件事比"排名"更重要。

项目 现在能不能用 卡在哪
UniXNU 不能（除非你的机型已在 35 份设备文档里） 单机型移植成本；无 release
DeepInfer 不能用于生产 缺 KV cache / PD 分离 / 跨副本负载均衡——即缺它的核心设计目标
Macintosh 不能（除非你有那台 A16 和一台 Mac） 11 commits、单机型、需第二台设备、音频摄像头蓝牙全缺
reylo 不能（除非 TS 7.1 stable） 单一语言特性依赖

这四个项目没有一个可以直接投入生产——这一点比它们的排名更能说明今天这个窗口的性质：这是研究快照与设计样本的窗口，不是工具发布的窗口。

重点项目深度分析（top 3）

Deep Dive 1：UniXNU/UniXNU（把移植难度写成可查询索引）

项目定位。 独立项目，通过 UEFI 在非 Apple ARM64 硬件上启动 iOS 与 macOS，3.5 天 750⭐ ⑂118（fork/star 15.7%，本批最高），Python，BSD-2-Clause-Patent，1947 KB，subs 3，oi 6。

为什么它值得比它的 star 数更多的注意力。 因为它的规模信号来自三处可核验的结构事实，而不是来自热度：

  1. 35 份设备文档（docs/devices/）。README 明确说明设备仓库用与主仓库相同的布局，其 modules 覆盖同名 modules，其 package/ 成为构建树里的一个 kit——这是一套已经被复用到至少 35 款设备的架构，不是单机型 hack。
  2. 16 个独立公开驱动的 submodule。驱动不在主仓库里，各自独立、按需克隆。这既是可复用性设计，也是一种责任边界划分。
  3. 文档站 unixnu.com 是一等公民：docs/concepts/{boot-chain,payload,prelink,security,userdata}.md、docs/drivers/{device-tree-matching,kexts,native-adreno}.md、docs/xnu/four-k-page-tables，配 docs.yml 与 macos.yml 两条工作流。

风险。 - ⚠️ license.spdx_id 为 NOASSERTION，而 LICENSE 首行明写 SPDX-License-Identifier: BSD-2-Clause-Patent——可核验的元数据不一致（严重程度低，因文件本身无歧义） - star 数与社区规模严重不匹配：750⭐ 但 subs 3、贡献者 6 人、主仓库 30 个 commit - 没有任何 release：分发路径是 clone + submodule + 自建 - 原生 GPU 驱动的声明无法在本日报核验：news 段落称 Adreno 740 驱动在小米平板 6S Pro 上完全工作，但仓库按其自身规则不含可运行产物 - 设备覆盖是查表式的：README 未给"最低可移植门槛"（内存、存储、特定 SoC 特性） - 35 份设备文档中的机型代号大量为国产 SoC（sheng / fajita / nuwa / pipa / piano / q2q / gta4l），意味着实际使用者集中在特定法域

是否值得跟踪。 值得，但跟踪方式应是"设备覆盖表"而非"star 数"。 它是本日唯一一个把难度直接写成可查询索引的项目。观察重点：docs/devices/ 是否从 35 增长到 40+（说明有外部贡献者）；是否出现第二个由外部贡献者提交的设备文档；macOS/iOS 内核变更如何被跟进（保持官方内核意味着每次系统更新都要重做契约层）。

Deep Dive 2：deepseek-ai/DeepInfer（本日最有信息量的一份"不做什么"清单）

项目定位。 DeepSeek 生产推理框架的开源版本，7 天 19,806⭐ ⑂2,106（fork/star 10.6%），Apache-2.0，2965 KB，subs 43 为本批最高，oi 193。

为什么它值得比它的 star 数更多的注意力。 因为它是本日唯一同时具备两个特征的项目：由头部模型厂商官方开源，且明确描述了自己的生产环境规模。QA 文档里的三条目标（多厂商加速器 / prefill 用 8 卡机而 decode 用 64–128 卡超节点 / KV cache 保留 >72h）解释了所有架构选择——尤其第二条，prefill 与 decode 差一个数量级的硬件配置不是为了省钱，而是为了让缓存有一个能待得住的家。

它的三条技术观察点：

  1. DSpark 的 confidence-scheduled verification 用置信度决定验证多少个 draft token，而不是固定值——这正是 2026 年投机解码的核心争论点，README 直接把开关暴露为环境变量。
  2. SWA bounded replay 的正确性约束被写进文档：保留的后缀"必须覆盖 SWA 窗口加上最大回退长度"。一条可写死的正确性要求，比一个漂亮的 benchmark 更有价值。
  3. batch-invariant 与确定性采样 把可复现性做进引擎而非依赖外部固定种子，且两者都标注 NVIDIA only——说明昇腾路径并非功能对等。

风险。 - ⚠️ 最关键的限制是框架不完整：不含 KV cache、PD 分离、跨副本负载均衡。即使全部编译成功，也无法复现 72h 缓存复用——而那是它最核心的设计目标之一。 - 7 天 193 个 open issue：对新框架属正常，但配合 subs 43 说明确有大量真实用户。是早期信号而非质量缺陷，需观察关闭率。 - 「155T tokens/日、38 USD/GPU-hour」是作者声明，本日报无法核验（私有集群数据）；README 的两张 Pareto 图（prefill 4×SM100、decode 64×SM100）是当前唯一可复核的量化证据 - 昇腾路径成熟度未知：列为受支持硬件，但本窗口未取到任何昇腾特定的性能数据或限制 - 无 release

是否值得跟踪。 值得，优先级在本日四个项目中最高。 理由：它是本日唯一一个有公开声明的生产规模、且把不在范围内的东西写进 README 的项目。观察重点（三项缺失是否开源，是这个项目未来的分水岭）、deep_cluster/ 的实际内容（PD 分离代码是否已在树内未接线）、昇腾与 NVIDIA 的功能差距、subscribers_count 与 issue 关闭率的变化。

Deep Dive 3：Acelogic/Snapintosh（Status 表是本日最值得学的一个形式）

项目定位。 在 ASUS Zenbook A16（Snapdragon X2 Elite）上运行 Apple 官方 macOS 27 的 EL2 hypervisor，20 小时 530⭐ ⑂29，Python，MIT（文件），9641 KB，subs 4，oi 4，全仓库仅 11 个 commit。

为什么它值得比它的 star 数更多的注意力。 因为它的 Status 表。 这一张表把以下内容放在同一套"已可用 / 进行中 / 不支持"的三档措辞里：

这张表的价值在于它同时给出了"已验证"和"未达标"的边界，且给了未达标项一个量化目标。 对比同规模项目通常只写一句 "coming soon"，信息密度高一个量级。

第二条值得记的是 gpu/agx* 目录的存在本身就是一份诚实的路线记录。 README 说这是"an earlier virtual-AGX model, kept for reference"。保留一条放弃的路径并标注为参考，比删掉它更能让读者理解为什么现在选原生驱动。

风险。 - ⚠️ license.spdx_id 为 NOASSERTION，而 LICENSE 首行明写 MIT License——同类元数据不一致 - 只支持一台笔记本：README「Nothing else is supported. The monitor, device tables, clocks and register addresses are specific to this machine.」 - 必须有一台 macOS 27 的 Mac 主机，且 AGENTS.md 把独立运行列为「a direction, not an already implemented or authorized replacement」 - ⭐ 11 个 commit、单机型、单次公开：历史集中在 2026-10-22 的 5 小时内，这不是成熟项目，是一个刚公开的快照 - 未经第三方复现：「pixel checks across the desktop test scenes pass」是作者自述 - GPL-2.0 成分：主体 MIT，但 LICENSES/ 含 GPL-2.0-only 与 GPL-2.0-or-later，具体哪些文件是 GPL-2.0 本窗口未逐项核验

是否值得跟踪。 值得，但应作为"分层与状态记录的样本"而非"可用工具"。 它的 EL2/EL1/EL0 分层表、Status 三档措辞、AGENTS.md 的九条禁止提交清单、THIRD_PARTY_NOTICES 的成分声明——这四样加起来是一份关于"如何在硬件逆向项目里表达边界"的完整示范，而这些都不需要它继续可用。观察重点：60 Hz 目标是否有进展；是否出现第二台机型（决定它是封闭作品还是可移植方案）。

风险与机遇

机会

  1. "缺什么"比"有什么"更值得读。 DeepInfer 用整段 README 写"本次发布不含 KV cache、PD 分离、跨副本负载均衡"，Macintosh 用 Status 表逐项写"音频、摄像头、蓝牙、休眠、外接显示器均不支持"。对准备引入的人，这两张清单的信息价值高于任何特性列表——它们直接决定"我能不能用"和"我要自己补多少"。
  2. 两个独立项目同时把"Apple 私有输入不得入库"写成仓库级制度，且 Macintosh 进一步扩展到 issue 与构建日志。 UniXNU 的 README Private blobs 段与 Macintosh 的 AGENTS.md 第 1 条是两个互不相识项目的独立表述。这类合规纪律在硬件逆向领域正在标准化，值得被抄进任何相关项目。
  3. codegen 的替代路径出现了，而且论证方式变了。 reylo 让派生物不再存在于磁盘上（type checker 直接问引擎），并把"单一事实源"从 DRY 论点改写成 agent 失效模式论证。凡是"事实源 A 变了，派生物 B 需重新生成"的场景，content mappers 都适用——这个思路的可迁移性比项目本身大。
  4. 16 KiB→4 KiB 页表翻译这个难点被两个独立项目同时确认为核心。 Macintosh 的 shadow/ 与 UniXNU 的 docs/xnu/four-k-page-tables 都在同一位置把它单列。一个技术难点被两条独立路径同时撞上，是这个难点真实存在成本的最好证据。
  5. 本日是自 php2shell 事件以来第一次没有事件驱动的热度洪峰。 这意味着连续三天观察到的"fork-star 低区间"现象在本日不是事件驱动的结果——它更像是常态。这为后续几天的观察清掉了一个混淆变量。

风险

  1. 四个项目没有一个可直接采用。 今日的性质是研究快照与设计样本窗口，不是工具发布窗口。做选型时"有没有被关注"与"能不能用"在今天是完全脱钩的两件事——19,806⭐ 的 DeepInfer 不能用于生产，616⭐ ⑂3 的 reylo 反而把技术路线说得最清楚。
  2. reylo 的存续完全由一个尚未 stable 的语言特性决定。 README 要求 typescript@beta。若 content mappers 在 stable 前变更 API，项目需重写；若 TS 7.1 跳票，项目为零。这是本日四个项目中最大的单点风险，且风险不在项目内部。
  3. 两处 license.spdx_id = NOASSERTION（UniXNU 与 Macintosh），尽管两处 LICENSE 文件内容清晰。依赖 license 扫描器的工具（合规流水线、企业采购清单）会把这当成非标准协议处理——这是本日新增的可核验元数据问题。
  4. "生产规模声明"目前无法被任何外部证据交叉验证。 DeepInfer 的「155T tokens/日、38 USD/GPU-hour」是私有集群的运行数据；Macintosh 的「pixel checks pass」无法在无硬件的情况下复现。这两个项目的可信度都依赖读者对作者的信任，而不只是依赖 README 的措辞。
  5. 单机型 / 单次公开项目的信息衰减很快。 Macintosh 的 11 个 commit 全部集中在 5 小时内，UniXNU 的设备文档覆盖完全依赖项目自己。这类项目在 star 数上升的同时可能没有任何功能进展——阅读它的 README 快照不能反映它今天的真实能力。
  6. Android TV 去广告赛道继续第 6 天有新项目，但今日仍不重复建档。 Gathin23/cleanyourtv 已达 23,714⭐ ⑂2,592（NOASSERTION，19 topics），simbasjungles/free-my-tv 3,366⭐、humblemuzzu/dumbtv 1,295⭐、Ansub/tv-detox 1,278⭐、mihirgupta0900/tv-home 407⭐。该赛道已在 10-19/10-20/10-21/10-22 四份日报完整记录，今日仅记为赛道延续性证据，不计入趋势排名——重复计入会让趋势指数失真。

证据边界总结

项目 关键事实（可核验） 推断（不构成事实） 待观察（待后续数据）
UniXNU/UniXNU Python + 1947 KB + 3.5 天 750⭐ ⑂118（fork-star 15.7%，本批最高）+ UniXNU 组织 + subs 3 oi 6 + 主仓库 30 commits、贡献者 API 返回 6 人 + releases API 返回空数组 + 定位「run iOS and macOS on non-Apple ARM64 hardware through UEFI」+ news 段落（10-22）原生 Metal GPU 驱动已在小米平板 6S Pro（sheng）完全工作、渲染服务器经 Adreno 740 合成系统 UI、被列入名单的进程获得各自 Metal 设备 + docs/devices/ 下 35 份设备文档（amethyst/sheng/fajita/nuwa/pipa/piano/q2q/tb128fu/gta4l 等）+ README 明写设备仓库与主仓库同布局、其 modules 覆盖同名 modules、其 package/ 成为构建树里的 kit + .gitmodules 16 条独立驱动 submodule（ArmCpu/ArmDTPlatform/ArmVirtPlatform/DarwinBoot/NativeAES/NativeAdreno/NativeGeniSpi/NativeHidInput/NativeKeyStoreEvents/NativeMetal/NativeMobileDisplay/NativeRamBlock/NativeUfs/NativeVirtioBlock/NativeVirtioConsole）+ 4 KiB 页表补丁单列一章（docs/xnu/four-k-page-tables、README Documentation 列表）· 文档站 unixnu.com（docs/.vitepress/config.mts）+ .github/workflows/{docs.yml,macos.yml} + 三仓库分工（UniXNU 构建驱动+UEFI 引导管理器+module 子模块与补丁 / UniXNU-sheng 设备仓库 / uefi-sheng UEFI 固件移植）+ README Private blobs 段：「Do not add Apple IPSW files, kernelcaches, disk images, trust caches, Data seeds or vendor firmware to this repository. Keep them in a local cache or external storage.」 + LICENSE 首行 Copyright (c) 2026, UniXNU contributors. All rights reserved. + SPDX-License-Identifier: BSD-2-Clause-Patent，而 GitHub license.spdx_id 为 NOASSERTION（可核验的元数据不一致） 推断：15.7% 的 fork-star 与「专设 docs/porting/ + 35 份设备文档」直接相关——fork 去移植自己的机型是核心使用方式；推断：BSD-2-Clause-Patent 而非 MIT，在 Apple 硬件逆向领域是有意义的信号 待核验：原生 Adreno 740 驱动的声明无第三方复现记录 + README 未给最低可移植门槛（内存/存储/SoC 特性要求） + 35 份设备文档目前看全是项目自己的，是否有外部贡献者提交待观察 + 平台契约提供者的具体实现形式（docs/concepts/{prelink,userdata,payload}.md 未取） + 「为什么从虚拟 AGX 转向原生驱动」README 未解释 + 是否会发布任何预构建产物
deepseek-ai/DeepInfer Python+csrc+vendor + Apache-2.0 + 2965 KB + 7 天 19,806⭐ ⑂2,106（fork-star 10.6%）+ deepseek-ai 官方组织 + subs 43 为本批最高 + oi 193 + topics 为空数组 + releases API 返回空数组 + 自述「powers DeepSeek's large-scale production services… open-source release provides offline inference with the core features needed for serving at scale」+ 仅支持 DeepSeek-V4.1-Flash（默认 checkpoint deepseek-ai/DeepSeek-V4.1-Flash-1017，首次运行下载到 HF 缓存，可用 DEEPINFER_HF_MODEL_DIR 指向本地）+ ⚠️ README 整段「Required for a complete inference service (not included in this release)」明列三项不含：KV cache 系统 / VE-Prefill-Decode 分离（注明引擎大部分必需功能已实现）/ prefill 与 decode 两侧的跨 DP 副本负载均衡；doc/inference_deployment_qa.md 补充 KV cache 管理与负载均衡「tightly coupled to our internal infrastructure, so that code is not yet fully open-sourced」+ 支持硬件仅 NVIDIA SM100 与华为 Ascend 950（Linux/GCC≥13/Python 3.12/CUDA 13 或 CANN 9.2）+ 八项特性（优化 kernel：FlashMLA·DeepGEMM·DeepEP·TileKernels·DeepSelect + 自定义 TileLang kernel 位于 deepinfer/model_executor/layers/tilelang_ops，前五者均为独立仓库 / DSpark confidence-scheduled verification：DEEPINFER_ENABLE_MTP_VARLEN=1，DEEPINFER_USE_NEXTN_DECODE 控制最大 draft 长度默认 5 / decoder SWA bounded replay：compact 模式 + DEEPINFER_YOCO_PREFILL_KEEP_TOKENS=140，保留后缀须覆盖 SWA 窗口加上最大回退长度 / 异步调度默认开启，README 称 zero-overhead batch scheduler / batch-invariant：DEEPINFER_BATCH_INVARIANT=1，仅 NVIDIA / 确定性采样：同开关 + DEEPINFER_ENABLE_MTP_VARLEN=0 + 固定 seq_seed，仅 NVIDIA / 结构化输出：regex·JSON schema·EBNF，见 examples/_structured_output.py）+ 并行：Attention DP / balanced CP / MoE EP + EPLB + QA 文档三目标（支持多厂商加速器 / prefill 用普通 8-GPU 机而 decode 用普通 64–128-GPU 超节点 / KV cache 保留超过 72 小时换上下文复用）+ 作者声明「A single cluster currently serves 155 trillion tokens per day, with overall revenue of US$38 per GPU-hour (at valley pricing)」 + benchmark 图在 4 张 SM100（prefill）与 64 张 SM100（decode）上测、各在一个 scale-up 域内，可用 examples/sweep/run_sweep.sh 复现 + 自述「originally built primarily on vLLM, with additional inspiration from SGLang and TensorRT-LLM」 + 同时开源 deepseek-recipe（生产级 token 编解码，逻辑完全对齐官方 DeepSeek API）· 顶层目录 csrc, deep_cluster, deepinfer, doc, eval, examples, scripts, tests, vendor（共 398 条），eval/ 含 aime/gpqa/hle 三套 推断：「把不在范围内的东西写成整段」在本项目上比在多数开源项目上更可信——理由是它同时给出了三项缺失的准确定义（KV cache / PD 分离 / 跨副本负载均衡），而不是笼统说「更多功能即将到来」；推断：**「155T tokens/日、38 USD/GPU-hour」的表述方式（给出 GPU 小时单价而非仅 token 量）说明作者知道读者会追问成本结构 待核验：三项缺失是否会在后续版本开源（这个项目未来的分水岭） + deep_cluster/ 的实际内容——PD 分离代码是否已在树内但未接线 + 昇腾路径与 NVIDIA 路径的功能差距（batch-invariant 缺失已知，实际影响未知） + EPLB 的具体策略 + draft 模型的显存/算力成本占比 + 「155T tokens/日、38 USD/GPU-hour」为作者声明，本日报未独立核验且无法核验（私有集群运行数据）
Acelogic/Snapintosh Python + LICENSE 文件首行 MIT License 而 GitHub license.spdx_id 为 NOASSERTION（可核验的元数据不一致）· 9641 KB + 20 小时 530⭐ ⑂29（fork-star 5.5%）+ subs 4 oi 4 + 全仓库仅 11 个 commit，历史集中在 2026-10-22 的 5 小时内（01:26:36Z「Snapintosh public release」→ 06:36:49Z，含 3 个 Merge PR）+ releases API 返回空数组 + topics 0 + 定位 EL2 monitor + toolchain，「boots Apple's macOS 27 (build 26A428) on an ASUS Zenbook A16 laptop with a Qualcomm Snapdragon X2 Elite (X2E-96-100)」+ 「The monitor runs Apple's stock kernelcache (the J700/T8140 kernel) unmodified by default.」 + 提供 SPTM/TXM 监控调用 + 内核 16 KiB 页表翻译 + Apple 设备（README 列出 AIC / ANS2 NVMe / DART / GPU ring / SMMU 中介）+ 图形经笔记本自带 Adreno X2-90 GPU 走项目自写栈（AdrenoMetal.bundle Metal 驱动插件 / AdrenoX2 IOGPU kext 配 AdrenoDisplay 驱动内屏 / air2ir3 把 Apple AIR 即 Metal 的 IR 翻译成 Mesa ir3）+ 硬边界「There is no software, CPU or paravirtual rendering path.」+ gpu/agx* 为「an earlier virtual-AGX model, kept for reference」 + 配套 q1n1（从 Asahi Linux m1n1 fork 的 UEFI EL2 proxy）经 USB-C NCM 把机器交给 macOS 27 Mac 主机驱动，每次启动、镜像上传与日志抓取都走该链路；README 明写需要一台 Mac 主机，AC 供电强烈推荐，工具在电量低于阈值时拒绝启动或写盘 + Status 表：桌面启动到桌面且 GPU 加速、桌面测试场景像素检查通过 / 流畅度 in progress「usable but not yet smooth」目标稳定约 60 Hz、面板 120 Hz 排后 / 输入内置键鼠与触控板手势·Mission Control·应用切换可用 / Wi-Fi QCC2072 扫描·WPA2·DHCP·ping 在 host-proxy 测试架可用但从 macOS Wi-Fi 菜单发起连接尚不可用 / 存储已装到内置 NVMe 并从其启动 / 音频·摄像头·蓝牙·休眠·外接显示器均不支持 + AGENTS.md 开篇「This is the complete policy, not an addendum to an earlier AGENTS.md」+ 三条硬规则（①绝不提交 Apple/Qualcomm/ASUS 的 kernelcache、固件、restore-image 部件、KDK、kext、dyld cache、ACPI dump、反汇编/vtable/ABI dump、重建的 *26A428.h 头文件、从 Apple shader 编译的 shader 集，且不得贴进 PR/issue/构建日志/测试夹具 ②绝不提交密钥或机器标识数据（个人路径、用户名、主机名、接口名、IP/MAC、序列号、SSID/密码、SSH 密钥、容器 ID），用 tools/cycle_lib/pins.example.json 参数化 ③保留 opt-in 语义，新运行时特性需编译期 ADRENO_/SNAP_ 开关）+ 「Standalone execution is a direction, not an already implemented or authorized replacement for this flow」 + 分层表 compat/（EL2 monitor + SPTM/TXM 中介 + CPU/中断/定时器/设备模拟 + GPU ring 与 SMMU 中介 + NVMe 后端）、shadow/（页表遍历器 16K→4K）、probes/、tools/（cycle.py + cycle_lib 启动编排/安全检查/日志、test- 与 replay- 主机测试与离线重放）、gpu/adreno-kext/{kext,plugin}、gpu/air2ir3/、gpu/agx*、drivers/{snap-i2c-hid, snap-qcc2072}、config/ + THIRD_PARTY_NOTICES.md「The repository contains no Apple, Qualcomm, ASUS or Microsoft binaries」，输入停在 git-ignored 的 downloads/ build/ gpu/adreno/ gpu/air2ir3/corpus + LICENSES/ 含 BSD-3-Clause.txt GPL-2.0-only.txt GPL-2.0-or-later.txt MIT.txt 推断：Status 表的三档措辞（「已可用 / 进行中 / 不支持」+ 对"进行中"给出量化目标 60 Hz）是本日最值得抄的一个文档形式——读者不读完全文即可知道这台机器能干什么；推断：gpu/agx* 保留为参考使读者能理解为什么最终选原生驱动——项目保留了判断过程而非只有结果；推断：AGENTS.md 第 1 条把禁止范围从代码扩展到 issue/构建日志/测试夹具，这比只写"不要提交内核"要难遵守得多，因此更可能是被真实问题推动的 待核验：「pixel checks across the desktop test scenes pass」为作者自述，本日报无法核验，仓库按其自身规则不含可分发的运行产物 + air2ir3 在运行期的角色（按需编译 vs 构建期预编译）README 未明说 + q1n1 与 tools/cycle.py 之间的控制流未细述 + LICENSES/ 中哪些文件是 GPL-2.0，本窗口未逐项核验（若用于分发需先确认） + 60 Hz 目标是否有进展记录 + 是否出现第二台受支持机型（决定 STATUS.md 是单页还是多页）
colinhacks/reylo Rust + TypeScript + MIT + 66704 KB（67 MB）+ colinhacks 个人 + 1.9 天 616⭐ ⑂3（fork-star 0.5%，本批最低）+ subs 0 + oi 13 + topics 为空数组 + 定位「Import .sql files into TypeScript with full type inference」+ ⚠️ 完全依赖 TypeScript 7.1 beta 的 content mappers（README 引用 microsoft/typescript-go PR #4712，明写「introduced in TypeScript 7.1 (currently in beta)」）+ 需 Node 24 或更高 + 一个正在运行的开发数据库（README Prerequisite 原文「A running dev database. Postgres, MySQL 8.0.22 or later, or a SQLite file: Reylo reads your current schema from it.」）+ 安装 npm install reylo + @reylosql/postgres（or mysql/sqlite）+ typescript@beta，并在 tsconfig.json 为 .sql 与项目文件 .reylo.yaml/.reylo.yml 注册 + 六卖点：全文力 SQL（any statement, function, operator or syntax your database supports, in its own dialect）/ DRY（类型来自 SQL 本身，无手写行类型、无 schema 文件需同步）/ Checked against your database（拼错的列名、错误参数、已删除的表都是类型错误，在 tsc 和编辑器里都成立）/ Agent-friendly（each fact lives in one place, so an agent cannot leave a stale type behind, and the type check finds every caller it missed）/ 支持 Postgres·MySQL·SQLite 且自带驱动 pg·postgres.js·mysql2·better-sqlite3·Bun.sql·Cloudflare D1 等 / No codegen — the type checker asks Reylo directly: no generated files, no watcher + 示例：select u.id, u.name, count(p.id)::int as post_count … 的 .run(db, {id:1}) 返回 { id: number; name: string; post_count: number } | null —— cast 直接影响推导结果，::int 得到 number 而非 bigint + 仓库顶层 Cargo.toml/Cargo.lock、engine/、oracle/、src/、packages/、lab/、skills/、wiki/、site/ + 文档站 reylo.dev 推断：subs 0 + fork-star 0.5% 说明热度目前完全是曝光，没有任何采用信号——这与本项目"需要等上游 beta 特性而非 fork 它"的形态完全吻合；推断：「agent 论证」是 2026 年工具设计的一个可观察转变——把 DRY 论点改写成「agent 无法制造过期状态」的失效模式论证 待核验：TypeScript 7.1 的发布时间表与 content mappers 的 API 稳定性（决定性变量） + type check 的性能开销是否有公开基准（决定"零 codegen"卖点的真实成本，README 通篇未提） + schema 缓存策略：是否每次检查都连库、是否可离线（本项目最关键的未决问题） + oracle/ 与 skills/ 的职责（若 oracle 是对推导正确性的对照实现，其测试方式是可信度关键） + oi 13 对 616⭐ 的库偏高——可能反映真实用户遇到 beta 边界，也可能反映 API 未稳定；本窗口未取 issue 内容，不做判断

总证据边界： 本日全部元数据取自 2026-10-23 CST 06:00 前后经 gh CLI 认证的 GitHub REST / Search API，README 与 AGENTS.md / doc/inference_deployment_qa.md / THIRD_PARTY_NOTICES.md / LICENSE / .gitmodules 原文经 Accept: application/vnd.github.raw 抓取，仓库结构经 git/trees/HEAD 与 ?recursive=1，历史与贡献者规模经 commits 与 contributors。「X 小时 / Y 天 Z⭐」按 created_at（UTC）到 2026-10-23 计算，总星数除以经过时长为下限粗估；本日报未做逐日 star 增量统计（需分页遍历 stargazer），因此任何「增速」表述都不能读作当日新增。 releases API 对 deepseek-ai/DeepInfer、Acelogic/Snapintosh、UniXNU/UniXNU 三者均返回空数组或长度 0（三者的主分发路径分别是 ./build.sh 从源码构建、clone + submodule 自建、以及文档 + 自编译）。subscribers_count 为 43 / 3 / 4 / 0（DeepInfer 43 为本批最高，reylo 0 为本批最低）；topics 对 DeepInfer 与 reylo 为空数组、UniXNU 有 1 个 topic、Macintosh 为 0。本日新增发现两处可核验的元数据不一致：UniXNU/UniXNU 与 Acelogic/Snapintosh 的 license.spdx_id 均为 NOASSERTION，但两处 LICENSE 文件首行分别明写 SPDX-License-Identifier: BSD-2-Clause-Patent 与 MIT License，且 THIRD_PARTY_NOTICES.md 也写明 Snapintosh 采用 MIT——以文件为准两者均可正常使用，但 GitHub 侧无法被自动识别为标准许可证，依赖 license 扫描器的工具会当成非标准协议处理；这与 10-22 记录的 ikow/php2shell-poc（spdx_id 为 null 而 README 写 MIT）性质相同但严重程度低得多（本次两处 LICENSE 文件内容清晰无歧义，而 php2shell-poc 的 README 与元数据直接冲突）。本日没有 CVE 驱动的注意力洪峰——这是自 10-21 的 php2shell 事件以来第一次，今日热度排序对技术选型的干扰比前两日小；但这四个项目没有一个是可直接采用的：UniXNU 与 Macintosh 是研究快照（Macintosh 仅 11 个 commit、单机型、需另一台 Mac 主机、音频摄像头蓝牙全缺），DeepInfer 缺三成系统（KV cache / PD 分离 / 跨副本负载均衡），reylo 依赖尚未 stable 的 TS 7.1——今天这个窗口的性质是研究快照与设计样本，而不是工具发布。 四个项目 fork-star 分化为 0.5% / 5.5% / 10.6% / 15.7%，但这四个数字不可横向比较：高 fork 比例的两个分别是「fork 去移植自己的机型」（UniXNU，专设 docs/porting/ + 35 份设备文档）与「fork 去读它的调度逻辑」（DeepInfer，kernel 栈本身已拆成 5 个独立仓库），低 fork 比例的两个分别是「只支持一台机器，没有第二台可移植」（Macintosh，README「Nothing else is supported」）与「需要的是等上游 beta 特性稳定而不是 fork 它」（reylo，subs 0）；连续第三天观察到同一条分界线——fork 比例在「可改造型项目」与「不可改造型项目」之间不可比。已过滤可核验的 spam 模式：xscreensaver-official/xscreensaver（1147⭐ ⑂33，README 自述「There is no official XScreenSaver GitHub repository.」——自我否认自身权威性，可核验的伪装）；WoYun520/dsh-purge（401⭐ ⑂687，fork/star 171%，README 自述「DeepSeek Harness 破甲 (mirror of mmparko/dsh-purge) — 全量镜像：全部分支/100 个 tag/完整提交历史」，是完整的仓库镜像而非原创）。未纳入 key_projects 的候选：Gathin23/cleanyourtv（23,714⭐ ⑂2,592 NOASSERTION，19 topics 直打 Android TV 去广告，但该赛道已在 10-19/10-20/10-21/10-22 四份日报连续记录，今日不重复建档）；reason-machines/reason-network（1060⭐ ⑂86 Apache-2.0 Rust，已有 projects/reason-network.md 档案，本窗口未取其 README 故不重复更新）；kividbio/kividb（460⭐ ⑂14 AGPL-3.0 Rust，20 topics 描述「Redis 与 Valkey 的 Rust drop-in 替代，含全文检索」，未建档）；ELY-Open-Source/ElyOffice（850⭐ ⑂54，已有 projects/elyoffice.md 档案，10-21 已建档，本窗口未取 README）；vercel-labs/fx0（382⭐ ⑂70，已有档案，10-21 已建档）；eagle-hq/EAGLE-4（862⭐ ⑂24 NOASSERTION，10-22 已记录为未取 README）。本日最重要的判断不是「哪个项目最热」，而是三个各自独立的项目在同一天做了同一件事：把边界写成可核验的文档——DeepInfer 用整段 README 写「本次发布不含什么」，Macintosh 用 Status 表逐项写「什么不支持、什么进行中及目标值」，UniXNU 用 README 的 Private blobs 段与 BSD-2-Clause-Patent 许可写「什么不能进来、以什么条款进来」，而 reylo 用六卖点中的「No codegen」与「Checked against your database」写「派生物不存在于磁盘上、校验发生在类型检查期」。这四条与 star 数完全无关，却是本日跨领域最强的共同信号。 与前三日不同的是，本日的第二条共同信号来自技术路径本身：UniXNU（UEFI 伪平台契约，35 款设备）与 Macintosh（EL2 hypervisor，单机型）两个互不相识的项目撞上了同一组核心技术难点——16 KiB→4 KiB 页表翻译与 Apple 私有输入的合规处理——并各自独立地把后者写成了仓库级制度；一个技术难点被两条独立路径同时确认为核心，是这个难点真实存在成本的最好证据。

重点项目档案