---
name: quantum-speed-reading
description: High-concurrency execution profile for bulk content ingestion and ASR. Use when the user explicitly says 量子速读/量子速度, requests benchmarked high-throughput processing, or when content workflow has already selected this profile for a confirmed large batch. Do not take over a plain “content workflow” request; content workflow owns scope discovery and routing.
---

# Quantum Speed Reading

## Purpose

“量子速读” is the productized high-throughput version of content workflow: download everything safely, cut media into chunks, run ASR through one global queue, then summarize and route memory candidates.

The public product name is **量子速读**. If the user says “量子速度”, treat it as the same product unless they explicitly mean something else.

Use it for batches across B站、小宇宙、小红书、公众号, especially when the user wants speed.

If the user only says “content workflow”, return routing control to content workflow. Run this skill after the batch scope is confirmed or when the user explicitly requests 量子速读.

## Core Rules

1. Scan and confirm scope before ingestion unless the user has already confirmed full processing.
2. Never summarize video/audio from descriptions or subtitles. Download media, cut audio, ASR, merge `full.txt`, then summarize.
3. Benchmark concurrency on current network/API conditions before raising limits.
4. Use one global ASR queue across all `chunk_*.wav`, not “one item at a time”.
5. Treat download concurrency separately from ASR concurrency.
6. Final summaries must be understanding-based writing, not extractive sentence ranking.
7. Do not ship or present legacy extractive summaries as product output. If only ingestion/ASR finished, say “素材摄入完成，摘要待重跑”.

## Concurrency Defaults

- ASR: start with 16, benchmark 16/24/32 using 60-second samples.
- If 32 workers has 0 errors and better total elapsed time, use global 32 workers for the real batch.
- B站 download: do not blindly parallelize. If 4 workers produces HTTP 412, fall back to 1 worker with UA/Referer and `--sleep-requests 2`.
- Cutting audio with `ffmpeg` can run around 8-12 local workers when disk/CPU are healthy.

Known measurement from 2026-06-05:

| Workers | Chunks | Errors | Elapsed |
|---:|---:|---:|---:|
| 16 | 32 | 0 | 24.07s |
| 24 | 32 | 0 | 22.13s |
| 32 | 32 | 0 | 19.27s |

## Workflow

1. Build a manifest with `platform`, `title`, `url`, `type`, `duration`, `dir`.
2. Download source media or text into per-item directories.
3. Cut every media item:
   ```bash
   ffmpeg -y -i input.m4a -ar 16000 -ac 1 -f segment -segment_time 300 -c:a pcm_s16le chunk_%03d.wav
   ```
4. Run `scripts/transcribe_global.py` from the batch root or adapt it to the current manifest.
5. Merge each directory:
   ```bash
   cat chunk_*.txt > full.txt
   ```
6. Write understanding-based summaries from `full.txt` / `article.md`, then run memory queue routing.
7. Report pass/fail counts and do not mark Reminders/B站稍后再看 complete until the user confirms cleanup.

## Quality Gate

For each media item verify:

- source media exists;
- `chunk_*.wav` exists;
- matching `chunk_*.txt` exists;
- `full.txt` exists;
- no `chunk_*.txt` starts with `[ERROR]`.

Short videos can legitimately fall below normal transcript thresholds. Flag them as short/low-density instead of pretending they failed ASR.

Do not use an extractive preview script as the final summary layer. Final output must include:

- 质量门禁: source completeness, ASR/chunk status, noise/truncation, and whether it is suitable for memory;
- 一句话概括: a clear one-line conclusion;
- 核心内容: topic-based core content, not transcript-fragment order;
- 核心论点与推导: claim, evidence/case, inference/conclusion;
- 高光亮点: high-signal moments;
- 金句/引述: short quotable lines only;
- 与小明相关: relevance to the user's projects/workflows where genuinely relevant;
- 编辑层提炼: value, limits, bias/soft-ad risk, reusable methods.

Summary layout must not start with a Markdown table. Use short metadata lines if needed.

## Package Validation

Before uploading or selling the package, run:

```bash
python3 scripts/validate_skill.py
python3 scripts/asr_benchmark.py --help
python3 scripts/transcribe_global.py --help
```

These checks must pass without requiring an API key. Real ASR runs still require `SF_KEY`, `SILICONFLOW_API_KEY`, or `~/.config/siliconflow/api_key`.

## Resources

- `scripts/asr_benchmark.py`: benchmark current TeleSpeechASR concurrency.
- `scripts/transcribe_global.py`: submit all pending chunks through one global worker pool.
- `scripts/validate_skill.py`: offline package and quality-gate self-check.