Codex 校核（2026-10-09） Sx 当前 v2 vault 规范在 assets/
/ 保存原生资产，如 SKILL.md、AGENT.md、mcp.json 及附属文件；sx.toml 是清单，metadata.toml 是元数据。它不是所有 skill 都使用 *.skill.yaml 的 YAML-only prompt runner。当前 README包含桌面 app 与 CLI 安装/分发流程；本页 YAML 描述应据此纠正。另一篇 DoorDash 内容若仅由少量 HN 评论推断，不能当作已核实的实现或准确率；多数模型可能共享错误，多模型共识不等于独立事实验证。标题16:01 UTC 与08:06–08:09Z的采集时间相差8小时，应按北京时间扫描时刻理解。
知识消化: Sx 2.0 + LLM Juries — 2026-07-14
信号1: Sx 2.0 — 用 Dropbox 文件夹分发 AI Skills
来源: HN Show HN | 48900319 (34pts / 8cmts)
项目: sleuth-io/sx — Apache-2.0, Go 编写
核心思想
Sx 是一个 AI skills 的包管理器。2.0 版本的关键创新是用 Dropbox/Google Drive/OneDrive 等共享文件夹作为技能分发后端——团队只要把 Skill YAML 文件放进共享文件夹，所有成员通过桌面 app 点一下 Sync 就能自动安装和更新。无需 Git、无需终端、无需部署服务器。
架构要点
- vault format v2: 每个 skill 以
assets/<name>/目录形式直接存储为纯文本 markdown。版本历史放在.sx/versions/旁。 - 多客户端翻译层: sx 知道各 AI 客户端的原生格式规范（Claude Code skills、Cursor rules、Copilot instructions、Codex、Gemini、Cline、Kiro），安装时自动转换。
- 插件系统: 基于 manifest + ES module 的扩展机制，权限按功能分门别类声明。
- Collections: 将相关技能分组，按需解析。新增 skill 自动传播到整个团队。
关键洞察
最值得注意的不是技术实现（Git + 文件同步早已可行），而是作者对用户画像的转变：原本面向开发者（Git CLI），2.0 转向非技术团队成员（市场、法务、销售、运营），他们才是 skill 的主要作者。
“I built the sharing layer for developers and assumed everyone else would eventually meet us at the command line. They won’t.”
这与 Hermes Skill 系统的设计哲学形成对比：Hermes 面向 agent（LLM 自动加载），sx 面向 human（CLI/app 手动调用）。
对我们的意义
| 维度 | 借鉴 | 不适用 |
|---|---|---|
| 文件分发模式 | ❌ 不适用 — Hermes skill 系统依赖本地文件系统 + profile | — |
| 多客户端兼容 | ✅ 可学习 — sx 支持 8+ 客户端格式，Hermes 的 skill 格式目前只有 Manas 能消费 | — |
| 非技术用户 | ✅ 启发 — 如果用户最终向团队开放 Hermes，需考虑非技术成员的工作流 | — |
| Extension 权限模型 | ✅ 值得参考 — 声明式权限列表，每次更新时重新提示 | — |
优先级: 🟢 P2（中长期 — 等 Hermes 生态需要对外分发时再深入）
信号2: Building Food Metadata with LLM Juries（LLM 评审团）
来源: DoorDash Engineering Blog | HN: 48901275 (34pts / 4cmts)
URL: careersatdoordash.com (JS 渲染，未获取到完整原文，通过 HN 评论推断内容)
核心概念
DoorDash 使用多个 LLM 组成”评审团”（Jury），对每个食品项目的元数据标签独立投票，通过多模型共识来提高标注质量。每个标签（如蛋白质、烹饪方式、健康标签）由多个 LLM 独立评估后汇总。
HN 社区的质疑（重要信号）
4 条 HN 评论全部持批评态度：
- sigmar: “为什么不针对每个标签微调一个专用小模型？”
- TeeWEE: “本质上是 AI 之上的 AI，没有硬数据支撑实际准确率”
- vector_spaces: “hero image 也用 AI 生成，说明缺乏严谨性”
- hansmayer: “不是每件事都需要 LLM”
对我们的意义
反面教材 > 正面参考：
- LLM Jury 的概念本身有价值：多个 LLM 投票可以做知识验证的质量门控，但需要量化指标（inter-rater reliability, confidence calibration），而不是简单地”用更多 LLM”
- 关键教训: 不要用 LLM 解决能用规则/微调解决的问题。对比 gbrain 的 fact extraction 和 reconciliation 管道，前者用规则+少量 LLM 调用，效率远高于全 LLM 方案
- HN 评论作为信号: 当真正的技术社区（非营销号）对一篇博客普遍质疑时，本身就是一个质量信号
优先级: 🟢 P3（观察 — 概念有价值但实施有缺陷，等待更好的实践出现）
横向连接
跨信号关联: Sx 2.0 和 LLM Juries 都涉及”如何用 AI 管理 AI”——前者用 Dropbox 管理技能分发，后者用 LLM 管理数据质量。共同趋势是 AI 工具链的基础设施化：从单点 AI 使用走向 AI 资产的系统化管理。
与 Hermes 生态的连接:
- Hermes 的 skill 系统已经是成熟的 AI 资产管理器，sx 验证了”这确实是一个需求”
- gbrain 的 fact extraction/reconciliation 管道比 LLM Juries 更高效（规则+子任务分解）
- 两个项目都提示我们：用户（人类或 agent）需要系统级的 AI 资产管理，不只是单个 LLM 调用