如何为 awesome-artificial-intelligence 配置并部署本地每周 curation 自动化？-港品优选

如何为 awesome-artificial-intelligence 配置并部署本地每周 curation 自动化？

【免费下载链接】awesome-artificial-intelligenceA curated list of Artificial Intelligence (AI) courses, books, video lectures and papers.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-artificial-intelligence

awesome-artificial-intelligence 是一个面向 AI 工程学习者的精选资源列表，README 中的条目由一套"本地每周 curation 自动化"维护：一个本地 Codex 定时任务每周一次做联网调研，只改README.md，在独立评审和确定性检查全部通过后才会自动 squash-merge。这篇文章的任务就是把这个自动化在你自己的环境里配置并部署起来。部署成功的标志是：每周一 09:00（桌面时区）的定时运行能独立完成调研、检查、评审，并产出"有改动的 curation PR"或"无改动报告"这两种结果之一——两者都被文档视为成功。

部署前需要准备什么

确认仓库内版本受控的组件齐全

设计文档的 Rollout 第一步要求：policy、prompts、schema、validator、tests 和 quality workflow 必须全部纳入版本控制（见 docs/weekly-curation/design.md）。这些文件在仓库中已存在，部署前确认你手上的是包含它们的版本：

CURATION.md：curation 策略（范围、评分、每周变更规则）；
AUTOMATION.md：定时代理的操作契约，定时任务必须先读它再行动；
.github/codex/prompts/weekly-curation.md：锁定（locked）的 curator 提示词，是一个短的/goal契约；
.github/codex/prompts/review-curation.md：评审提示词，与 curator 提示词分开存放；
.github/codex/schemas/curation-review.schema.json：评审结果 schema；
scripts/validate_readme.py 与 tests/test_validate_readme.py：无依赖的校验器及其单元测试；
.github/workflows/quality.yml：GitHub Quality 工作流。

把详细契约放在版本控制中，是为了让定时提示词保持稳定且可审查。

配置 GitHub 侧的访问与分支保护

CURATION.md 的 Repository setup 一节给出了本地 weekly curator 的三项硬性前提：

一个处于活动状态的 Codex desktop automation，且具备已认证的 GitHub 访问；
权限上能创建隔离 worktree、推送或更新其 curation 分支，并能合并已验证的 pull request；
分支保护规则要求合并前必须通过 quality workflow。

第 3 项决定了后面 GitHub Quality 工作流（见下文）必须实际生效，否则自动合并的门禁不成立。

准备本地运行环境

Python：pyproject.toml 声明requires-python = ">=3.13"，仓库根目录的.python-version固定为 3.13，Quality 工作流也用 3.13。校验器是无第三方依赖的（pyproject 的dependencies为空，设计文档称其为 "dependency-free Python validator"），所以本地只需要一个满足版本要求的 Python 解释器。
git 引用可用：curator 的 churn 检查以--base origin/master运行，校验器内部通过git show <ref>:README.md取出基线版本的 README 做对比，因此本地克隆必须先 fetch 到origin/master引用，且 curator 每次运行都从最新的origin/master建 worktree。

配置本地 Codex 定时任务

设置调度时间与调度提示词

设计文档的 Rollout 第 2 步是"Configure the local Codex automation for Monday at 09:00 in the desktop timezone"，CURATION.md 同样规定 specialist weekly curator 每周一 09:00（桌面时区）运行。

AUTOMATION.md 的 Scheduled-task bootstrap 一节给出了本地调度器应使用的短提示词，它把细节委托给该文件，可以直接照用：

ReadAUTOMATION.mdandCURATION.mdfrom the latest default branch. Act as the repository steward for one bounded run. Follow the authority, exact-head gates, memory rules, and reporting requirements. Do not weaken policy or auto-merge governance changes.

文档还说明：AUTOMATION.md修改后，除非 bootstrap 或运行时本身变化，否则调度器提示词不需要重写。

理解 curator 的锁定提示词

真正执行 curation 的是 .github/codex/prompts/weekly-curation.md 中锁定的/goal提示词。它委托仓库级操作规则给AUTOMATION.md、编辑判断给CURATION.md，并明确了允许改动的文件、要跑的检查、证明要求、精力预算和停止条件。其中与部署直接相关的约束：

只编辑README.md；
运行python -m unittest discover -s tests -v和python scripts/validate_readme.py README.md --check-links --base origin/master；
最多三轮调研迭代或 45 分钟后停止，不确定的条目保持不变；
无改动的报告（no-change report）就是成功结果。

每次运行实际做什么

按设计文档，一次 curator 运行的流程是：

从最新的origin/master创建隔离 worktree；
在本地 Codex 环境中做联网调研，只改README.md，记录证据与评分；
用--base origin/master跑仓库测试和 live link 校验，让 churn 限制被确定性地检查；
由一个没有参与 curation 的全新评审子代理检查实际 diff、来源、评分、分类匹配与替换分差；
只有评审给出 Approve 且无 blocker/important findings，才会提交并推送，使用带日期的codex/curation-YYYY-MM-DD分支创建或更新一个 pull request，其中包含证据报告、检查结果和评审结论；
无论结果如何，自动化只检查并安全删除本次运行创建的精确临时 worktree；遇到未知或用户改动会阻塞清理并上报。

部署后先手动跑一遍本地检查

在等第一个周一之前，可以先在仓库本地把 curator 自己会跑的检查执行一遍，确认环境没问题。curator 提示词中的原命令是：

python -m unittest discover -s tests -v python scripts/validate_readme.py README.md --check-links --base origin/master

第一条跑单元测试，覆盖解析、重复项、类别处理、URL 归一化、链接状态分类和 churn 边界（见 tests/test_validate_readme.py）。
第二条做结构校验 + 在线链接检查 + 相对origin/master的每周 churn 限额校验。churn 限额来自 CURATION.md：单次运行最多改 6 个资源条目、净新增不超过 3 条、Learn 章节的基础性条目改动不超过 1 个。
如果只想做结构 + 链接校验、不做 churn 对比（例如本地还没有可用的 base 引用），可以用不带--base的形式，这正是 Quality 工作流在没有 base ref 时的做法：

python scripts/validate_readme.py README.md --check-links

输出判断方式（来自 scripts/validate_readme.py 的实际行为）：WARNING: ...和ERROR: ...行写到 stderr，最后标准输出打印Validated N resources with E errors and W warnings.（N/E/W 为当次实际计数）；只要存在 error，退出码就是 1。链接状态分类规则是：404/410 计为 error；401/403/429、超时（408）、5xx 以及 DNS/TLS 之外的临时性服务端错误计为 warning；确定的客户端错误、DNS 失败和 TLS 失败才会让链接校验失败。

CONTRIBUTING.md 给的是同样的检查，只是用python3前缀并在链接检查上分两条（不带/带--check-links，均加--base origin/master），供人工提交前手动使用；内容上与 curator 的自检一致。

确认 GitHub Quality 工作流已就位

自动合并依赖 "GitHub Actions 负责确定性质量检查" 这一分工（CURATION.md），且分支保护要求合并前必须通过 quality workflow。检查 .github/workflows/quality.yml 是否满足：

触发条件：pull_request（路径限定为README.md、AUTOMATION.md、CONTRIBUTING.md、CURATION.md、scripts/**、tests/**、.github/codex/**、.github/ISSUE_TEMPLATE/**、.github/pull_request_template.md、.github/workflows/**）、push到master、workflow_dispatch；
权限只有contents: read；
validate任务在 ubuntu-latest 上运行（超时 10 分钟），actions/checkout@v4带fetch-depth: 0，用actions/setup-python@v5装 Python 3.13；
先跑python -m unittest discover -s tests -v；再跑 README 校验：若 PR 有 base ref（github.base_ref），先git fetch origin "$BASE_REF"并执行python scripts/validate_readme.py README.md --check-links --base "origin/$BASE_REF"，否则执行不带 base 的--check-links校验。

curation PR 只改README.md，而该路径在触发列表中，所以每个 curation PR 都会触发这个工作流——这是"exact head 上 Quality workflow 通过"这一合并门禁的数据来源。

首次运行与合并的成功判定

部署完成后，第一个周一 09:00 的运行就是验收点。按文档，一个运行结束时可能出现三种形态：

有改动且通过评审：在codex/curation-YYYY-MM-DD分支上创建或更新一个自动化拥有的 PR，包含证据报告、检查结果和评审结论。自动化最多维护一个分支名匹配codex/curation-*的自动化周 PR。
无改动：README 保持原样，产出 no-change report。AUTOMATION.md 明确"A run that verifies the current state and makes no changes is successful"，所以没有 PR 不代表部署失败。
冷却期：若 8 天内已有自动化拥有的周 PR 被合并或关闭，本次运行会跳过创建新的周提案；贡献者的资源 PR 不触发这个冷却。

PR 能否被自动 squash-merge，取决于在精确 head commit上所有门禁同时成立（CURATION.md）：PR 只改README.md；每个资源过硬门槛且评分不低于 80；每周 churn 与替换分差规则通过（替换现有条目需挑战者高出至少 10 分或现有条目硬门槛失败）；本地 unit、structure、churn、live-link 检查通过；全新独立评审返回 Approve 且无 blocker/important findings；GitHub Quality workflow 通过；PR 可干净合并且无未解决的重大反馈。head 一旦变化，先前评审与检查全部作废。

最终合并是原子的：用gh pr merge --squash --match-head-commit <sha>匹配被评审的 head SHA（<sha>即评审通过的那个 head commit 的 SHA），不匹配即停止合并，需要重新评审和检查。任何"降低策略、测试、权限或评审门禁来让 PR 可合并"的行为都是被禁止的。

运行 4 次之后，按设计文档 Rollout 第 6 步复盘接受率（acceptance rate）与 churn，作为自动化健康度的依据。

限制与回退

时间预算：单次运行默认 45 分钟，curator 在最多三轮调研迭代或 45 分钟后停止；错过或无改动的一次运行是安全的，下一次调度会自然恢复（设计文档 Risks 一节）。
合并权限边界：自动化只能合并 README-only 的资源 PR。对AUTOMATION.md、CURATION.md、贡献模板、自动化提示词、workflow、validator、测试或权限的改动永远走人工评审，绝不由该自动化合并（AUTOMATION.md）。
清理边界：清理只针对本次运行创建的精确临时 worktree；遇到未知改动会阻塞清理并上报，不会覆盖用户工作。
回退方式：设计文档给出的 backout 就是暂停本地自动化——README 与确定性的 GitHub 检查在没有它时依然可用，不需要额外回滚动作。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析