2. 标准化

在分析之前，将统一记录中的证据结构化为规范形式：

• 框架：名称、版本、渲染模式（SSR/SSG/CSR/ISR）
• 网络：请求数量、外部域名、资源类型
• 控制台：错误数量、警告模式
• 爬取：状态、内容类型、字节数

在使用富集数据前检查 enrichmentStatus：

• "ok" — 富集数据存在且可用
• "timeout" — 捕获完成但富集数据未及时到达；注意此缺口

检查 evidenceQuality 以了解整体证据健康状况：

• "complete" — 无缺口，所有数据都存在
• "partial" — 存在缺口但捕获成功
• "degraded" — 捕获级别失败或富集服务器错误

3. 分析

根据评估标准比较标准化后的证据。通过 create_finding 生成结构化的发现结果。

反模式

切勿这样做：

trigger_capture({ url: "..." })
// sleep(5000)
get_enrichment({ url: "..." })

请这样做：

analyze_page({ url: "https://example.com" })

切勿临时拼凑证据结构。 来自 analyze_page 的记录是规范的证据格式。不要临时重新组织它。

切勿在标准化前进行分析。 先从证据记录中提取字段，然后得出结论。

对比协议

用于两个站点的并排分析：

compare_pages({ urlA: "https://site-a.com", urlB: "https://site-b.com" })

响应包含一个带有类型化证据字段的 comparisonSummary：

• comparisonReadiness — ready（两者均完整）、cautious（一个部分完整）、unreliable（任一为降级状态）
• symmetric — 双方是否具有相同的缺口概况
• degradationNotes — 每方缺口的人类可读列表
• timingDelta — 绝对时间差异（捕获、富集轮询）
• enrichmentAgeDeltaMs — 两次分析之间的时间戳差异
• evidenceIdA / evidenceIdB — 用于通过 get_observation 进行往返验证的观察 ID

对比维度

比较两个站点时，从以下 10 个维度进行评估：

1. 框架 — 名称、版本、渲染策略
2. 性能 — 资源数量、总字节数、外部依赖
3. 安全性 — HTTPS 强制实施、混合内容、CSP 存在性
4. SEO — 元标签、结构化数据、规范 URL
5. 可访问性 — 语义化 HTML、ARIA 使用、替代文本
6. 错误表面 — 控制台错误、失败资源、4xx/5xx 响应
7. 第三方加载 — 分析、跟踪、CDN 使用
8. 架构 — SPA 与 MPA、API 模式、水合策略
9. 内容交付 — CDN、缓存头、压缩
10. 移动端就绪度 — 视口元标签、响应式信号

并非每个页面都会在所有维度上都有数据。请明确注明缺口。

发现结果

分析后，持久化洞察：

create_finding({
  title: "站点使用 Next.js 14 并采用 ISR",
  url: "https://example.com",
  evidence: ["obs_abc123"],
  synthesis: "框架检测确认了 Next.js 14.2.0 并采用增量静态再生...",
  confidence: "high",
  category: "framework"
})

发现结果在标准化证据之后产生，绝不在之前。

示例工作流

// 1. 获取
result = analyze_page({ url: "https://example.com" })

// 2. 标准化
framework = result.enrichment.framework  // { name: "Next.js", version: "14.2.0" }
networkCount = result.enrichment.networkRequests.length
consoleErrors = result.enrichment.consoleLogs.filter(e => e.level === "error")

// 3. 分析 & 记录
create_finding({
  title: "Next.js 14 具有较高的外部依赖数量",
  url: "https://example.com",
  synthesis: "检测到 Next.js 14.2.0。页面加载了 47 个网络请求，包括 12 个第三方域名..."
})

每周安装量

1

代码仓库

crawlio-app/cra…o-plugin

首次出现

今天

安全审计

Gen Agent Trust HubPassSocketFailSnykWarn

安装于

zencoder1

amp1

cline1

openclaw1

opencode1

cursor1

2. Normalize

Structure evidence from the unified records into canonical form before analysis:

• Framework : name, version, rendering mode (SSR/SSG/CSR/ISR)
• Network : request count, external domains, resource types
• Console : error count, warning patterns
• Crawl : status, content type, byte count

Check enrichmentStatus before using enrichment data:

• "ok" — enrichment data is present and usable
• "timeout" — capture completed but enrichment didn't arrive in time; note this gap

Check evidenceQuality for overall evidence health:

• "complete" — no gaps, all data present
• "partial" — has gaps but capture succeeded
• "degraded" — capture-level failure or enrichment server error

3. Analyze

Compare normalized evidence against a rubric. Produce structured findings via create_finding.

Anti-Patterns

Never do this:

trigger_capture({ url: "..." })
// sleep(5000)
get_enrichment({ url: "..." })

Do this instead:

analyze_page({ url: "https://example.com" })

Never improvise evidence shapes. The record from analyze_page is the canonical evidence format. Don't restructure it ad hoc.

Never analyze before normalizing. Extract fields from the evidence record first, then draw conclusions.

Comparison Protocol

For side-by-side analysis of two sites:

compare_pages({ urlA: "https://site-a.com", urlB: "https://site-b.com" })

The response includes a comparisonSummary with typed evidence fields:

• comparisonReadiness — ready (both complete), cautious (one partial), unreliable (either degraded)
• symmetric — whether both sides have identical gap profiles
• degradationNotes — human-readable list of gaps per side
• timingDelta — absolute timing differences (capture, enrichment polling)
• enrichmentAgeDeltaMs — timestamp difference between the two analyses
• evidenceIdA / evidenceIdB — observation IDs for round-trip verification via get_observation

Comparison Dimensions

When comparing two sites, evaluate across these 10 dimensions:

1. Framework — name, version, rendering strategy
2. Performance — resource count, total bytes, external dependencies
3. Security — HTTPS enforcement, mixed content, CSP presence
4. SEO — meta tags, structured data, canonical URLs
5. Accessibility — semantic HTML, ARIA usage, alt text
6. Error surface — console errors, failed resources, 4xx/5xx responses
7. Third-party load — analytics, tracking, CDN usage
8. Architecture — SPA vs MPA, API patterns, hydration strategy
9. Content delivery — CDN, caching headers, compression
10. Mobile readiness — viewport meta, responsive signals

Not all dimensions will have data for every page. Note gaps explicitly.

Findings

After analysis, persist insights:

create_finding({
  title: "Site uses Next.js 14 with ISR",
  url: "https://example.com",
  evidence: ["obs_abc123"],
  synthesis: "Framework detection confirmed Next.js 14.2.0 with incremental static regeneration...",
  confidence: "high",
  category: "framework"
})

Findings come after normalized evidence, never before.

Example Workflow

// 1. Acquire
result = analyze_page({ url: "https://example.com" })

// 2. Normalize
framework = result.enrichment.framework  // { name: "Next.js", version: "14.2.0" }
networkCount = result.enrichment.networkRequests.length
consoleErrors = result.enrichment.consoleLogs.filter(e => e.level === "error")

// 3. Analyze & Record
create_finding({
  title: "Next.js 14 with high external dependency count",
  url: "https://example.com",
  synthesis: "Detected Next.js 14.2.0. Page loads 47 network requests including 12 third-party domains..."
})

Weekly Installs

1

Repository

crawlio-app/cra…o-plugin

First Seen

Today

Security Audits

Gen Agent Trust HubPassSocketFailSnykWarn

Installed on

zencoder1

amp1

cline1

openclaw1

opencode1

cursor1