指南 — 本 Playbook 如何运作¶

最终更新: 2026-08 · owner: Youngjin · volatility: 低（流程页面 — 仅在管道变更时更新） ← 返回 index

L0 TL;DR：本站不是新闻归档，而是一条验证管道。新出现的技术、论文、发布不会立刻登上正文 — 自动扫描收集候选，由人依据一手来源验证，只有通过 4 个关卡中 2 个（THE FILTER）的项目才会进入正文。即便已登上正文，其新鲜度也会被自动监控、以 4 种语言同步，并须通过构建关卡才会部署。

全流程一览¶

graph TD
    A1["🤖 每日自动扫描<br>(每日 02:00 UTC — arXiv·网络)"] --> R
    A2["💬 SA 提报<br>(晋升管道)"] --> R
    A3[🔍 手动调研] --> R
    R["Radar 队列<br>全部标注为'未验证 [4]' — 禁止用于客户提案"] --> V["一手来源验证<br>人 + 验证 agent (对照官方发布·论文原文)"]
    V --> F{"THE FILTER<br>ⓐ production 验证 ⓑ AWS 映射 ⓒ 实际问询 ⓓ GA"}
    F -- 满足 2 个及以上 --> P["晋升至支柱正文<br>(由 owner 以标准模板)"]
    F -- 未达标 --> K["在 Radar 中保留一行<br>(注明晋升条件)"]
    P --> AFTER[登上正文之后]
    AFTER --> M1["⏳ 新鲜度自动监控<br>(按 volatility 超过 1/3/6 个月时加徽章)"]
    AFTER --> M2["🌐 4 种语言同步<br>(ko 原文 → ko_hash → en/zh/ja)"]
    AFTER --> M3["✅ strict 构建关卡 (锚点·链接验证)<br>→ 自动部署至 GitHub Pages"]

① 它是如何构建的¶

本 playbook 由一份完整的规格文档（主提示）生成。信息架构（5 个支柱 + 决策树 + Radar + 维护规则）与纳入标准在规格中固定，且每个页面都经过对抗式验证（专门查找事实错误·夸大的独立验证步骤）。实际上这一步就抓出了版本笔误·许可证错误等问题 — 原则不是"既然生成了就相信它"，而是"连生成的内容也要验证"。

② 什么会被登载，什么会被过滤¶

每个项目都必须通过 THE FILTER 才能进入正文：ⓐ production 验证 ⓑ 可 AWS 映射 ⓒ 有实际问询记录 ⓓ GA（或路线图）— 4 个中满足 2 个及以上。"刚出来"、"演示很惊艳"都不是纳入理由。已登载的项目会附带成熟度标签（🟢 GA / 🟡 Preview / 🔵 Research / ⚪ Hype）与来源等级（[1] 官方文档 ~ [4] 未验证）— 标签的读法见主页。

③ Radar 与每日自动扫描¶

尚未通过过滤器的项目以一行形式存在于 Radar（队列）中。每日 02:00 UTC 自动扫描运行，将最新论文·新闻填入 Radar 的"最新扫描流入"区块（当日无新增则不更新）。要点：自动流入的内容全部作为未验证 [4] 隔离，不得用于客户提案。自动化只做到把候选放上队列为止。

④ 验证与晋升 — 人的职责¶

流入项目的一手来源确认（官方发布·论文原文·许可证对照）与晋升判断由人完成。自动扫描可能产生貌似合理的错误（例如不存在的产品世代名），因此未经验证不会晋升。一手来源验证不必由 owner 独自完成 —— 可由多人分担，参与者记录在晋升议题和条目底部的 验证: 字段。通过后，owner 会以标准模板将其编入相应支柱并从 Radar 中移除。完整流程参见晋升管道。

⑤ 新鲜度自动监控¶

已登载的项目也会变旧。每个页面都有变动性（volatility）等级 — 高 1 个月 / 中 3 个月 / 低 6 个月 — 若超过基准而未更新，部署时会向该页面（4 种语言全部）自动注入"⏳ 需要复核"徽章。每日都会重新部署，因此即便没有推送，徽章也会保持最新状态。看到徽章即表示该页面正在等待重新复核。

⑥ 4 种语言同步¶

韩语是原文，英语·中文·日语是衍生物。每个翻译文件都记录了翻译时点的原文指纹（ko_hash），因此当原文变更时，系统会自动检测哪个翻译已滞后（CI¹ 警告）。术语通过共用术语集在 4 种语言中保持一致。语言切换在页面右上角的下拉菜单。

⑦ 部署管道¶

一旦推送到 main，CI 会运行新鲜度检查·翻译同步检查，并仅在通过 strict 构建（只要有一个断裂的链接或锚点就会失败）时才部署至 GitHub Pages。也就是说，你现在看到的每一个页面都处于已通过该关卡的状态。

⑧ 复核实务指南（owner · 验证负责人）¶

被指定为页面 owner 或验证负责人后，以下就是复核的全部。所需只有仓库访问权限 + 本页 10 分钟。

何时 —— 系统会告诉你。 当线上页面顶部出现 "⏳ 需要复核"徽章时，就轮到该页面了（超过 1/3/6 个月的易变性阈值时自动附加）。想提前查看，在仓库运行一行 python3 scripts/check_staleness.py --check 即可打印全部页面的现状。

在哪 —— 仓库中的韩语原文。 Clone GitHub 仓库，复核 docs/<页面>.md（ko）。线上站点仅供确认，编辑始终在仓库中进行。

如何 —— 五步：

事实核对 —— 打开各条目名上附带的官方来源链接（已全量连接验证），对照一手来源确认版本·许可证·GA 状态是否仍然正确。
更新易变块 —— 折叠的 <details> 块被设计为只需改动其中的版本·价格·区域数值。正文（稳定层）是原理，很少变化。
更新元数据 —— 复核完成后将 updated: 改为当前年月。这是清除徽章的唯一正当方式（脚注·格式整理等非内容工作不更新它）。
同步四种语言 —— 改了 ko 就把同样的变更反映到 en/zh/ja 并刷新 ko_hash（流程见仓库 CLAUDE.md，术语见 i18n/glossary.md）。
过门禁后推送 —— python3 scripts/check_translation_sync.py（不同步为 0）与 mkdocs build --strict（exit 0）都通过才能提交。推送 main → 自动部署。

按语言分工时 —— owner 每页仅 1 人（以 ko 原文为准），语言分工者是记录在条目 验证: 字段中的验证负责人。只需记住一条规则：不要直接改译文文件 —— 永远从 ko 原文开始。ko 变更后，同步检查会报告哪些译文落后了，语言复核者只需按术语表更新那些文件。

按角色指引¶

我是…	这样用就对了
只是阅读的人	从主页的 FAQ Top 20 或支柱进入。只要认得标签（🟢🟡🔵⚪）和来源等级（`[1]`~`[4]`），就能一眼读出可信程度
想提报项目的人	通过晋升管道提报。若一并注明满足 THE FILTER 4 个中的几个会更快
owner	复核每日自动流入 → 一手验证 → 晋升/保留判断。参见完整的维护规则

CI（Continuous Integration，持续集成） — 每次提交·推送都自动运行检查与构建的管道。在本仓库中，新鲜度检查·翻译同步检查·strict 构建都在 CI 中运行，全部通过才会部署。 ↩