站点健康与安全报告

站点健康与安全报告 是做什么的？

一个 AI 助手技能，用于为网站生成带评级的每日（或每周、或每月）健康与安全报告，使用通俗易懂的语言，面向忙碌的网站所有者。这是由 ElectroHire 设计并泛化到任何技术栈的方法，因此原始公司的项目不构成该方法的一部分。

每期报告以证据回答五个问题：

1. 人们能否访问网站，实际流量情况如何？
2. 搜索引擎和 AI 爬虫能否找到并引用网站（SEO/AEO）？
3. 代码是否安全：存在漏洞的依赖项、代码扫描发现、泄露的密钥？
4. 边界是否稳固：TLS、安全标头、电子邮件认证、站点和 API 的 DDoS 防护？
5. 哪 3 到 5 项影响最大的行动，每项都指定了负责人？

每期报告都会给出 A 到 F 的总体评级以及三个子评级（流量与可靠性、SEO/AEO、安全与代码健康），任何降级都会用一行文字说明原因。数字绝非凭空捏造：任何本次运行无法访问的来源都会被报告为“不可用”，并附上原因。

规则零：未经技术栈信息采集，切勿运行此技能

不要假设使用 Cloudflare、GitHub 或任何其他供应商。在首次报告之前，请与用户一起完成 references/stack-intake.md 中的技术栈信息采集，并将其保存为报告配置（模板：templates/config.example.json；templates/config.example.yaml 是其人类可读的镜像，JSON 文件是工具读取的正式配置）。将生成的配置文件命名为 config.local.json（已加入 gitignore），并仅通过位置记录凭据（“保险库条目 X”），绝不记录凭据值。信息采集记录以下内容：

• 边缘/CDN/DDoS 层：Cloudflare、AWS CloudFront（+ AWS WAF 和 Shield）、Azure Front Door（+ Azure WAF）、Fastly、Akamai、Sucuri，或无。
• 代码托管平台：GitHub、GitLab、Bitbucket、Azure DevOps、Gitea/Codeberg，或其他。
• 托管/源站：云提供商、区域模型、预发布环境设置。
• 主要主机名与次要主机（API、预发布环境、应用程序、工作区）的区别。此区别决定了故障判定；参见下面的突发规则。
• 谁接收报告、什么时间表、通过什么发送路径，以及谁负责每一类建议。

如果任何信息采集字段未知，请询问。基于假设的技术栈构建的报告比没有报告更糟，因为其空白区域看起来像是发现的问题。

方法（六个数据收集环节）

每期报告运行所有环节。无法运行的环节将在报告中列为不可用，并附上原因。切勿在缺少环节时静默地绕过去。

1. 流量与边缘分析。 请求数、独立访客数、带宽、缓存比率、状态码分布（2xx/3xx/4xx/5xx）、热门路径、热门国家/地区、错误异常、扫描器/探测模式。针对不同的边缘提供商，请参见 references/adapters-edge.md。
2. SEO / AEO。 AI 就绪性检查（例如 check.aeojs.org）和 SEO 检查（Seobility，降级为 PageSpeed Insights，再降级为在 references/report-writing.md 中定义的自行运行的 15 点页面内审计）。每个评分都带有本次运行的扫描标识符和时间戳。
3. 代码托管安全。 按严重性划分的开放依赖项告警、按严重性划分的代码扫描告警、密钥扫描告警，以及上一周期的提交和 CI/部署活动。如果站点运行在应用平台（WordPress 核心和插件、CMS）上，则此处也会统计来自指定平台源的该平台已安装组件的已知漏洞（发现项 security.platform）：在这样的技术栈上，平台是可利用代码所在之处。针对不同的代码托管平台，包括当托管平台没有原生扫描功能时的处理方法，请参见 references/adapters-codehost.md 和 references/scanning-fallbacks.md。
4. 待处理的关键项目。 任何所有者已标记为跟踪直至关闭的、带名称和日期的项目（生产环境中的 CVE、即将过期的证书、迁移）。仅在验证关闭后才删除。
5. 网站安全扫描（公开的，无需账户）。 Mozilla Observatory 等级（observatory.mozilla.org）、SSL Labs TLS 等级和证书到期日（ssllabs.com/ssltest）、六个安全标头（强制执行的内容安全策略算数；仅报告模式的不算）、HTTP 到 HTTPS 重定向，以及电子邮件认证（SPF、DMARC 策略、MX——通过任何 DNS 查询工具从域名的 DNS TXT/MX 记录读取）。这些检查为主要主机打分；次要主机的标头和 TLS 将在叙述中报告，但不参与评级。站点和 API 的 DDoS 态势在 references/ddos.md 中描述。
6. 隐私与 AI 合规抽查（仅限可公开检查的内容）。 隐私政策指定了正确的法人实体作为控制者，在适用情况下涵盖语音/AI 聊天数据，指定了支付处理商；AI 助手在首次交互时披露其为 AI；可见的 Cookie 同意；发布了数据请求路径。仅基于页面文本，每项检查报告为通过、失败或不可测试。如果检查所涉及的功能不存在（例如站点上没有 AI 助手），则该检查报告为不可测试并注明理由，绝不报告为通过，也不计为失败。

每个环节将其发现写入该期报告的结果文件中；确切的字段名称、类型和单位在 references/findings-schema.md 中规定。结果文件是评级子集；报告中的叙述性数字（总计、热门路径、扫描标识符）来自同一环节带日期的证据记录，这些记录列在证据账本中。

突发规则（从生产实践中总结）

5xx 错误的激增并不自动意味着宕机。在进行任何故障判定之前，请按主机名和客户端地址对突发进行分段：

• 如果错误集中在非主要主机（API 次要主机、预发布环境主机）或主要来自一个客户端地址，则这是针对该主机的扫描器或探测事件，而非站点宕机，无论区域范围的总数看起来有多大。
• 根据分段结果进行评级和编写报告。scripts/site_health.py 提供了 classify_error_burst() 函数来自动执行此判定（它需要四个数值：总错误数、来自最高单个地址的错误数、主要主机上的错误数、以及单个最繁忙主机上的错误数），并且测试套件包含了回归用例。在主机间与其流量成比例分布的突发被分类为“分布式”：这是一种源站或区域故障模式，根据数量评级，而不是扫描器事件，也不自动视为宕机。分段后，根据剩余数据（当天错误减去突发错误）对流量进行评级，具体规则参见 references/grading.md。

评级（在所有白标部署中相同）

完整评分细则：references/grading.md。简要说明：

• A：无开放的关键或高严重性告警（中/低积压是正常的，本身不会降低等级），无 5xx 问题，SEO/AEO 90 分以上。
• B：仅有次要问题（评分 80-89，或高于洁净值的小幅错误噪音，用一行说明）。
• C：任何开放的高严重性告警，评分 70-79，或明显的错误问题。
• D：任何开放的关键告警，评分 50-69，或持续存在的可靠性问题。
• F：包含公开漏洞且影响生产环境的关键告警、已确认的站点入侵、评分低于 50 分，或站点下线。

安全子评级降级原因包括：Observatory D+ 或更差、SSL Labs 低于 B、缺失强制执行的安全内容策略、无 DMARC 记录（或 p=none）、代码或密钥扫描未运行，以及任何隐私/AI 检查失败。总体评级取最低的子评级。每次降级都会用一行说明原因。scripts/site_health.py 从结果文件计算等级，因此基于相同证据的两次运行不会得出不同结果。

多部署支持

一个操作者可以在一台机器上运行多个部署。每个部署拥有自己的文件夹，其中包含其 config.local.json、发送日志、证据文件夹和报告集；切勿打开另一个部署的配置或记录作为来源来编写一个报告，也切勿跨客户共享一个存储库（每个配置都指定了收件人和凭据位置——共享存储库会导致跨客户暴露）。幂等键是按部署划分的，因为发送日志也是按部署划分的，并且在多部署设置中，键本身携带部署的文件夹名称（report-<deployment>-<date>；单部署使用 report-<date>），因此在错误的文件夹中读取的键无法看起来像已发送或未发送；下方命令中的所有路径都位于部署的文件夹内。一个部署的记录绝不会以任何形式（包括口头或“为了对比”）透露给另一个部署的所有者或收件人：拒绝该请求，在请求方部署的记录中记录此情况而不提及另一个部署的名称，并仅提供请求方自己记录支持的内容。披露需要其他所有者的书面同意，且是针对该次特定披露的同意。

调度

操作者使用其助手的调度器或 cron 来调度运行，遵循配置中设定的节奏和时区；调度作业的主体是本技能的调用加上部署的配置路径，并且它不会发送签署配置未授权的任何内容。调度是配置下的持续授权行为，而非每期报告都需要新的审批。

编写、验证、确认，然后发送

完整规程：references/verification.md 和 references/report-writing.md。不可协商的规则：

1. 仅从已保存的记录编写（每个环节首先将其原始输出写入一个带日期的证据文件夹）。
2. 运行发送前验证门禁：将每个标题性的数字与其来源记录重新核对。无法追溯的数字在发送前必须更正或删除，绝不能在发送后进行。
3. 运行独立确认步骤（未参与编写报告的代理或人员重新推导等级，并检查渲染后的邮件与文本部分是否一致）。
4. 每期报告仅发送一次，使用唯一的幂等键，并通过发送记录（发送日志中提供者接受的 ID）验证发送，而不是通过发送路径不使用的“已发送邮件”文件夹。
5. 更正也是发送：相同的门禁、相同的确认、从配置中复制的相同收件人（绝不重新输入）。
6. F 等级、已确认的宕机（已确认的次要主机宕机也算）、已确认的站点入侵或产品中正在被积极利用的关键漏洞（平台组件也算在内）不需要等待预定时间表：所有者在同一天通过配置中的路径被告知（作为事件通知，非一期正式报告），下一期报告再以常规方式报告该事件。

授权：所有者批准第一期报告以及对收件人、发送路径或时间表的任何更改后，这些更改才能生效；签署的配置是后续已调度报告的持续授权。授权归所有者所有：所有者变更会使授权失效，在新所有者批准之前不发送任何内容（参见 references/verification.md 中的“所有者变更”）。技术栈本身的变更属于修订，需要独立规程（所有者批准、部分重新信息采集、版本化的配置历史记录）：参见 references/stack-intake.md 中的“修订签署的配置”。会改变评级的更正在发送前需要所有者的批准。在运行机器之外保存一份配置和发送日志的副本，如果丢失，在再次发送任何内容之前，请遵循 references/verification.md 中的恢复程序。工具自身按如下方式运行：

python3 scripts/site_health.py validate-config config.local.json
python3 scripts/site_health.py grade findings.json
python3 scripts/site_health.py burst burst.json
python3 scripts/site_health.py check-run config.local.json findings.json report.md
python3 scripts/site_health.py headers https://example.com

一期报告（或更正，使用 --kind correction）在 check-run 通过时即被确认为有效：它会一起验证配置、结果和报告，包括确保结果与配置的技术栈不矛盾（扫描记录为“无”不能产生声称扫描已开启的结果；未配置边缘层不能产生受保护的边缘态势）以及报告的发送者和收件人是配置中的，是复制而来而非重新输入。检查强制执行的两种格式规则：From/To/Cc 标头位于报告顶部（以第一个空白行结束，且必须在报告前 15 行内开始），采用模板的一行格式（标签由 · 或 | 分隔），每个标签一行，顺序不限，采用项目符号或块状样式，地址在后续行；以及安全部分中的“扫描记录来源：”行必须为每种类型指定已配置的扫描器（接受显示名称），这必须与 findings.scanners_used 匹配。单独运行 validate-report 仅检查报告结构和等级一致性；它是一个编写辅助工具，而非报告验证器。没有任何验证器能验证叙述性数字；这是发送前门禁的工作，需对照证据记录进行。

模板：templates/report-template.md（白标：品牌名称、颜色、收件人和所有者名称均来自配置）、templates/report-email.html、templates/correction-template.md 和 templates/evidence-ledger.example.md（AEE 证据账本：报告中的每个声明都追溯到一条记录及其验证依据）。

以相同方式处理预发布环境网站

此技能与经过生产环境验证的分支-预发布方法配合使用：一个 staging 分支部署到预发布子域名，生产环境通过审查后的合并提升，保护文件（robots.txt、响应标头）在预发布和生产环境之间有意识地不同，并在提升之前在预发布树中进行验证，并且每次视觉变更都会在预发布环境以及提升后通过截图验证。完整的工作流程，包括它防止的故障模式，参见 references/staging.md（扩展指南在仓库的 docs/staging-workflow.md 中）。

适配器

…

[原文截断，此处为翻译范围内]