swing-research

交叉验证研究

具备防幻觉保障和来源质量分级的系统化研究引擎。

规则（绝对要求）

1. 绝不伪造来源。 不得使用虚假 URL、杜撰论文或捏造统计数据。
2. 来源可追溯性门槛。 每项事实性声明都必须能追溯到特定且可引用的来源。若某项声明无法追溯到任何来源，则将其标记为 未经验证（仅基于内部知识），并说明需要进行哪些验证。绝不将无法追溯的声明作为研究发现呈现。
3. 不得将猜测当作事实。 不得使用委婉措辞，将未经验证的声明当作研究发现呈现。禁止使用以下说法：“아마도”“~인 것 같습니다”“~로 보입니다”“~수도 있습니다”“probably”“I think”“seems like”“appears to be”“likely”。如果某项声明未经验证，请明确标记为 未经验证 或 存在争议，不得用委婉措辞弱化。
4. 先给结论（BLUF）。 先给出结论，再提供证据。绝不将答案埋在后文。
5. 按需投入研究力度。 研究深度应与问题范围相匹配：
   • 狭义事实问题（单项声明、日期、规格）：2-3 个查询，2 个以上来源
   • 技术比较（A 与 B）：5 个以上查询，5 个以上来源
   • 广泛领域概览（市场分析、技术现状）：8 个以上查询，8 个以上来源 范围不明确时，默认采用更高一级的要求。
6. 交叉验证。 每项关键声明在作为事实呈现前，都必须出现在 2 个以上独立来源中。“独立”是指来源进行了自己的分析或报道——两篇都引用同一原始来源（新闻稿、博客文章、研究）的文章，只算作 1 个来源。将声明追溯至其源头。
7. 搜索前明确范围。 如果研究问题含糊不清或范围过广，请在第 1 阶段将其拆解为具体的子问题，并在进入第 2 阶段前提交用户确认。不要研究模糊的问题——应先明确问题。

流程

按顺序执行以下 4 个阶段。不得跳过任何阶段。

第 1 阶段：拆解

将研究问题拆分为原子级子问题。

Input: "Should we use Bun or Node.js for our backend?"
Decomposed:
  1. Runtime performance benchmarks (CPU, memory, startup)
  2. Ecosystem maturity (npm compatibility, native modules)
  3. Production stability (known issues, enterprise adoption)
  4. Developer experience (tooling, debugging, testing)
  5. Long-term viability (funding, community, roadmap)

• 确定哪些内容需要外部验证，哪些可以依靠内部知识
• 如果原始问题含糊不清或范围过广，请先向用户展示拆解后的子问题并征求确认，然后再继续（规则 7）
• 对每个子问题，说明可追溯来源应具备哪些特征

第 2 阶段：搜索与收集

针对每个需要验证的子问题：

1. 设计多样化查询——变换关键词、加入年份筛选条件，并尝试使用英语和韩语
2. 使用 WebSearch 进行广泛发现，使用 WebFetch 分析特定页面
3. 立即按级别对每个来源分类（见下文“来源级别”）
4. 提取具体数据点——数字、日期、版本号，以及注明出处的引文
5. 记录相互矛盾之处——来源存在分歧时，记录双方观点
6. 追溯来源——多个来源引用同一底层来源时，找出原始来源

搜索模式（按规则 5 调整规模）：

Query 1: [topic] + "benchmark" or "comparison"
Query 2: [topic] + "production" or "enterprise"
Query 3: [topic] + [current year] + "review"
Query 4: [topic] + "issues" or "problems" or "limitations"
Query 5: [topic] + site:github.com (issues, discussions)

WebSearch 不可用或没有返回结果时的后备方案：

1. 使用 WebFetch 直接访问已知的权威 URL（官方文档、GitHub 仓库、Wikipedia）
2. 依靠内部知识，但将所有声明标记为 未经验证（无法进行外部搜索）
3. 请用户提供来源 URL 或文档，以便验证
4. 降低最低来源数量要求，但在可能的情况下仍保持交叉验证

第 3 阶段：交叉验证

对于每项关键发现：

• 是否出现在 2 个以上独立的 S/A 级来源中？→ 已验证
• 是否仅出现在 1 个来源中？→ 未经验证（标记出来）
• 来源之间是否存在矛盾？→ 存在争议（标注级别并呈现双方观点）

请记住：“独立”是指每个来源都进行了自己的分析。两篇文章都引用同一项基准测试研究，只算作 1 个来源。

建立验证矩阵：

| Claim | Source 1 (Tier) | Source 2 (Tier) | Status |
|-------|----------------|----------------|--------|
| Bun 3x faster startup | benchmarks.dev (A) | bun.sh/blog (B) | Verified (note: Bun's own blog = biased) |

第 4 阶段：综合

按照先给结论（BLUF）的格式生成最终报告。

输出格式

## Research: [Topic]

### Conclusion (BLUF)
[1-3 sentence definitive answer or recommendation]

### Key Findings
[Numbered findings, each with inline source tier labels]

1. **[Finding]** — [evidence summary]
   Sources: 🏛️ [source1], 🛡️ [source2]

2. **[Finding]** — [evidence summary]
   Sources: 🛡️ [source1], 🛡️ [source2]

### Contested / Uncertain
[Any claims that couldn't be cross-verified or where sources conflict]
- ⚠️ [claim] — Source A says X, Source B says Y

### Verification Matrix
| Claim | Sources | Tier | Status |
|-------|---------|------|--------|
| ... | ... | ... | Verified/Unverified/Contested |

### Sources
[All sources, grouped by tier]

#### 🏛️ Tier S — Academic & Primary Research
- [Title](URL) — Journal/Org (Year)

#### 🛡️ Tier A — Trusted Official
- [Title](URL) — Source (Year)

#### ⚠️ Tier B — Community / Caution
- [Title](URL) — Platform (Year)

#### Tier C — General
- [Title](URL)

质量校准

错误示例 — 应避免的做法

## Research: Is Rust faster than Go for web servers?

### Conclusion (BLUF)
Rust is generally faster than Go for web servers due to zero-cost abstractions.

### Key Findings
1. **Rust is 2-5x faster than Go** — Rust's ownership model eliminates GC pauses.
   Sources: 🛡️ https://rust-performance-comparison.example.com
2. **Rust uses less memory** — Typically 50% less memory in production.
   Sources: 🛡️ https://memory-benchmarks.example.com
3. **Go is easier to learn** — Most developers pick up Go in a week.
   Sources: 🏛️ https://developer-survey.example.com

### Verification Matrix
| Claim | Sources | Tier | Status |
|-------|---------|------|--------|
| 2-5x faster | 1 benchmark site | A | Verified |
| 50% less memory | 1 benchmark site | A | Verified |

为什么这是错误的：

• 来源 URL 是捏造的（域名不存在）
• “快 2-5 倍”和“内存减少 50%”只有各 1 个来源，却被标为已验证
• 这是个细节复杂的话题，却没有“存在争议的主张”部分
• 将内部知识中的主张重新表述，再用伪造的引用包装
• 没有追溯来源——“快 2-5 倍”这个说法从何而来？
• “已验证”标签是虚假的——实际上并未进行交叉验证

正确示例 — 应努力达到的标准

## Research: Is Rust faster than Go for web servers?

### Conclusion (BLUF)
Rust outperforms Go in raw throughput benchmarks (typically 1.5-3x in TechEmpower), but the gap narrows significantly with real-world I/O workloads. Go's GC pauses (sub-millisecond since Go 1.19) are rarely a bottleneck for typical web services. Choose based on your latency tail requirements, not averages.

### Key Findings
1. **Rust frameworks lead TechEmpower benchmarks** — Actix-web and Axum consistently rank in the top 10; Go's stdlib and Gin rank 20-40 range in plaintext/JSON tests.
   Sources: 🏛️ TechEmpower Round 22 (2024), 🛡️ Axum GitHub benchmarks
2. **Go's GC latency is sub-millisecond since 1.19** — p99 GC pause < 500μs confirmed by the Go team.
   Sources: 🛡️ Go Blog "Getting to Go" (2022), 🛡️ Go 1.19 Release Notes
3. **Real-world gap is smaller than microbenchmarks suggest** — Discord's 2020 migration (Go→Rust) showed tail latency improvements, but their workload (millions of concurrent connections) is atypical.
   Sources: 🛡️ Discord Engineering Blog (2020), ⚠️ HN discussion with Discord engineer comments

### Contested / Uncertain
- ⚠️ **"Rust uses 50% less memory than Go"** — Frequently repeated on Reddit/HN but no independent benchmark reproduces a consistent figure. Memory usage depends heavily on allocator choice (jemalloc vs system) and workload. **Unverified.**
- ⚠️ **Developer productivity trade-off** — Go advocates claim 2-3x faster development time. No peer-reviewed study supports a specific multiplier. **Unverified (internal knowledge only)** — would need controlled study to verify.

### Verification Matrix
| Claim | Sources | Tier | Status |
|-------|---------|------|--------|
| Rust 1.5-3x faster (synthetic) | TechEmpower R22 (S), Axum bench (A) | S+A | Verified |
| Go GC < 500μs p99 | Go Blog (A), Release Notes (A) | A+A | Verified |
| Discord latency improvement | Discord Blog (A), HN thread (B) | A+B | Verified (single case study) |
| Rust 50% less memory | Reddit threads (B) only | B | Unverified |
| Go 2-3x dev speed | No source found | — | Unverified (internal knowledge only) |

### Sources

#### 🏛️ Tier S — Academic & Primary Research
- [TechEmpower Framework Benchmarks Round 22](https://www.techempower.com/benchmarks/) — TechEmpower (2024)

#### 🛡️ Tier A — Trusted Official
- [Getting to Go: The Journey of Go's Garbage Collector](https://go.dev/blog/ismmkeynote) — Go Blog (2022)
- [Go 1.19 Release Notes](https://go.dev/doc/go1.19) — Go Team (2022)
- [Why Discord is Switching from Go to Rust](https://discord.com/blog/why-discord-is-switching-from-go-to-rust) — Discord Engineering (2020)
- [Axum Benchmarks](https://github.com/tokio-rs/axum) — Tokio Project

#### ⚠️ Tier B — Community / Caution
- [HN Discussion on Discord migration](https://news.ycombinator.com/item?id=22238289) — Hacker News (2020)

为什么这是正确的：

• 每个 URL 都指向真实且可验证的页面
• 明确将缺少来源的主张标记为未验证
• 指出“内存减少 50%”是个误区，而非重复这一说法
• 验证矩阵如实展示哪些内容已验证、哪些未验证
• 来源彼此独立（TechEmpower 自行进行基准测试，并未相互引用）
• 保留细节：“在真实场景的 I/O 下，差距会缩小”

来源等级

在发现来源时对每个来源进行分类。

等级	标签	可信度	示例
S	🏛️	学术、经过同行评审、一手研究、官方规范	Google Scholar、arXiv、PubMed、W3C/IETF RFC、语言规范（ECMAScript、PEP）
A	🛡️	政府、.edu、主流媒体、官方文档	.gov/.edu、Reuters/AP/BBC、官方框架文档、公司工程博客（Google AI、Netflix Tech）
B	⚠️	社交媒体、论坛、个人博客、维基——需提醒用户	Twitter/X、Reddit、StackOverflow、Medium、dev.to、Wikipedia、나무위키
C	（无）	不符合上述类别的普通网站	企业营销内容、新闻稿、SEO 内容、新闻聚合网站

等级分类规则

• 公司发布的自家产品相关内容：
  • 官方文档 → A 级
  • 功能公告 → A 级（用于确认功能存在），B 级（用于性能声明）
  • 营销页面 → C 级
• GitHub：
  • 官方仓库（例如 facebook/react）→ A 级
  • 附有复现步骤的 Issues/Discussions → A 级（用于确认 Bug 存在）
  • 普通用户仓库 → B 级
• 基准测试：
  • 独立、可复现且公开了方法 → S 级
  • 由中立方官方开展 → A 级
  • 供应商自行开展的基准测试 → B 级（注明偏见）
• StackOverflow： 高票数的采纳答案 = 介于 A 级与 B 级之间；未采纳的答案 = B 级
• B 级来源不得单独引用——须用 S 级或 A 级来源佐证

适用场景

• 技术评估或比较
• 核查具体主张
• 架构决策研究
• 市场／竞争对手分析
• “X 是否属实？”验证任务
• 任何准确性比速度更重要的问题

不适用场景

• 创意写作或头脑风暴（使用 swing-options）
• 代码实现
• 可凭内部知识且高度确信地回答的简单问题
• 没有可验证答案的观点类问题

注意事项

1. 绝不捏造 URL。 如果搜索没有结果，就说“未验证（未找到来源）”——不要猜测一个看似合理的 URL。伪造来源会彻底摧毁可信度。
2. 两篇文章引用同一项研究 = 1 个来源。 追溯主张的出处。一份被 5 家新闻网站引用的新闻稿仍然只是 1 个来源，而不是 5 个。
3. 供应商的基准测试属于 B 级，而非 A 级。 即使是官方工程博客，在对自家产品进行基准测试时也会存在偏见。应明确标注这种偏见。
4. 委婉表达不等于标注。 禁用“或许”“似乎”“可能”等说法。主张要么已验证（有 2 个或更多独立来源），要么须明确标为未验证／存在争议。
5. 不要跳过验证矩阵。 它是问责环节。没有它，报告看似严谨，却没有审计记录。

集成说明

• 与 swing-clarify 搭配： 对于含糊不清的请求，先运行 swing-clarify，再调用此技能。明确范围有助于获得更好的结果。
• 与 swing-review 搭配： 研究发现可用于对抗性审查，以检验结论