specification.website自动化运维每日规范扫描Agent如何自动产出Draft PRRoutine完整拆解【免费下载链接】specification.websiteWebsite specification — HTML, accessibility, security, SEO, agent-readiness. Platform-agnostic, sourced, MIT.项目地址: https://gitcode.com/gh_mirrors/sp/specification.websitespecification.website是一个平台无关的「网站规范」开源项目——从title到/.well-known/security.txt把 HTML、无障碍、安全、SEO 与 AI Agent 就绪度写成一条带来源的规范条目。它的自动化运维核心是一个每日规范扫描 Agent每天自动巡检各标准化组织发现新主题或失效引用后自动写好规范页、开出Draft PR并向 Slack 发送一份摘要报告。本文完整拆解这套 Routine 的定义文件、判断规则与 PR 产出流程新手也能看懂如何让 Agent 自动维护一个规范网站。一、Routine 是「一个文件」不是一段代码整套每日扫描由一个 Markdown 文件定义ops/routines/daily-standards-scan.md。文件开头就写明了它的设计原则This file is the single source of truth for the daily standards-scan routine. A scheduled agent reads this file each run and follows it exactly. Edit this file to change what the routine does — do not edit the routines prompt.也就是说定时调度的 Agent 每次运行都读取这个文件并严格按步骤执行想改扫描行为只需编辑这个文件、提交到main下次运行自动生效不需要维护 cron 脚本、提示词参数或 CI 配置。这就是该项目自动化运维最关键的一点把运维逻辑写成仓库内版本化的「说明书」。Routine 还要求 Agent 先读CLAUDE.mdAgent 工作指南与CONTRIBUTING.md贡献规范再开工——两者被标记为「binding」有约束力规范先行扫描才能跑。二、 Agent 去哪里找新闻信源清单Routine 逐条列出了每天要检查的标准化信源信源类型具体内容活标准WHATWG HTML / DOM / FetchW3C / CSSW3C TR 索引、CSSWG 草案、WCAG 2.2/3.0 进展IETFweb / security / well-known 领域的新 RFC 与活动草案IANA 注册表Well-Known URIs、Link Relations、报文头的新注册生态约定schema.org、llmstxt.org、modelcontextprotocol.io、sitemaps.orgBaseline 推送信号webstatus.dev 公开 API新达 Baseline 的浏览器特性其中webstatus.dev 的 Baseline API是最有意思的「推送式」信源不靠人肉发现「某特性三大浏览器都支持了」而是由 API 直接列出新达到 Baseline 的浏览器特性。Routine 要求用约 8 天的滑动窗口查询保证漏跑一天也不会漏掉特性。三、Agent 只找三种信号每次扫描Agent 只处理三类发现新主题New topics——标准或约定里还没有规范页的条目状态变化Status changes——已覆盖的主题推进了CR→REC、被废弃了或recommended/required/avoid状态该调整失效引用Dead or stale citations——页面引用 404、内容搬家、或不再支持页面主张。引用采用轮转抽样不逐页天天查。判断「浏览器支持度」时Agent 不抓网页而是调用MDN MCP 服务器免费、无需鉴权它返回 MDN 条目的当前 canonical URL 和 Baseline / BCD 支持状态——正好是这次扫描需要的两个数据。MDN 只作为背景来源页面的首要引用必须是 WHATWG / W3C / IETF 这类一手标准。四、作用域规则为什么「达 Baseline」不等于「开 PR」这是 Routine 里最有价值的部分——一组防止 Agent「逢新特性就开 PR」刷屏的硬规则可审计的结果而非构建技巧主题必须是「好网站应有的、能从外部检查的属性」一个响应头、一个元素、一种行为、一个 well-known URI。纯开发便利特性如 CSS subgrid不配拥有页面——用 flexbox 做出同样布局的网站并不更差也没有东西可审计采用度门槛而非最终性门槛RFC 再终稿没有实现在用就不开页面反之被广泛部署的约定可以先于 RFC 落地获得页面状态纪律required只给「没有它平台契约就断裂」的场景拿不准时默认recommended。主题「真实但太早/超范围」时Agent 既不能悄悄丢弃也不能开 PR——必须登记进src/content/considered/「否决登记表」写明reasontoo-early/out-of-scope/too-narrow与revisit什么条件会改变决定。该登记表公开渲染在/considered/页面而每次规范内容的实际变化都会记录在src/content/changelog/变更日志集合中——例如「llms.txt 达到 v2」「AVIF 成为首选编码格式」这类条目都能在其中查到。五、Draft PR 产出全流程拆解发现「solid candidate」后Agent 执行固定流水线去重检查先git fetch列出现有开放 PR 与分支确认主题未被提出或覆盖——对每日任务这是最容易被忽视的保命步骤写规范页复制src/content/spec/category/下既有条目填全 front mattertitle、status、sources2–4 条等正文按五个标准小节写作What it is/Why it matters/How to implement/Common mistakes/Verification。英式英语约 1000 词难题可到 2000禁止为凑字数注水构建验证npm run build必须通过开 DRAFT PRPR 描述写明改了什么、为什么是现在、一手来源、所选状态的一句话理由。一题一 PR永不自动合并——合并按钮永远在人手里不动部署mcp/是独立 Cloudflare Worker重新部署属于合并后的人类步骤Agent 明确禁止执行。关键设计在于Agent 只负责「产出一个合格的 PR」合并与部署决策永远留给人。Draft PR 给维护者一个完整的审查窗口——来源、状态、理由全都看得见但什么都不会自动上线。六、每日 Slack 摘要安静的一天也要汇报Routine 要求每天给维护者发一份 Slack 摘要即使当天零发现也必须发。报告固定四块新主题 → PR 链接或「已标记需实现决策」状态变化 → 页面 变了什么 来源 PR 链接失效引用 → 页面 坏链 修复 PR刻意跳过的内容与原因——以及是否进了/considered/登记表。最后一项值得强调「跳过清单」不是可选项。它让 Agent 的每个判断可见、可复核维护者能核实「你到底查了没」「为什么不给它开 PR」。这正是自动化运维系统能长期跑下去的关键不是 Agent 不犯错而是每个决定都有据可查。七、上手体验如何定制这套 Routine整套自动化都在仓库里clone 下来看ops/routines/daily-standards-scan.md就是 Agent 的完整「岗位说明书」git clone https://gitcode.com/gh_mirrors/sp/specification.website如果你维护类似的内容驱动项目可以直接照抄这个模式把运维逻辑写成仓库里的单一 Markdown「事实来源」文件如ops/routines/文件里写清信源优先公开 API 做推送信号、硬规则作用域、状态、去重、输出形式Draft PR 报告输出形式永远是「PR 报告」不直接合并所有否决都进公开登记表让「没做的那部分」同样可见。specification.website 的这套 Routine 说明自动化运维不必从复杂 CI 起步——一份写得好的说明书 一套保守的输出规则就足以让 Agent 持续、稳定地为一个开源项目贡献规范内容。【免费下载链接】specification.websiteWebsite specification — HTML, accessibility, security, SEO, agent-readiness. Platform-agnostic, sourced, MIT.项目地址: https://gitcode.com/gh_mirrors/sp/specification.website创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考