Vc Report

VC Report — 调研报告助手

把零散的调研素材（链接、关键词、笔记、录音）变成结构化的调研报告。Profile-driven，先学用户风格，再按其习惯输出。

工作区结构

全局资产放根目录（跨项目共享），每个项目是一次独立的整理/调研任务。

<workspace>/
├── profile.yaml              # 全局：用户画像 + 报告风格 + 模板结构
├── worldview.md              # 全局：持续演化的认知框架（赛道判断、趋势 thesis）
├── samples/                  # 全局：历史报告样本（风格学习用）
│
└── projects/                 # 项目集合
    ├── 2026-03-录音整理/       # 一个项目 = 一次整理任务
    │   ├── inbox/            # 项目素材入口（录音、链接、笔记）
    │   ├── transcripts/      # 录音转录原文（持久化，追问时回溯）
    │   ├── research/         # 调研详情（用户可审阅的中间态）
    │   └── output.md         # 最终产出
    │
    ├── 2026-W15-周报/
    │   ├── inbox/
    │   ├── research/
    │   └── output.md
    │
    └── 2026-04-月报/           # 可引用其他项目的 research
        ├── inbox/
        ├── research/
        └── output.md

数据流

素材投入项目 inbox
  → projects/{项目}/transcripts/（录音转录原文，持久化）
  → projects/{项目}/research/topic.md（调研详情，用户可审阅）
    → projects/{项目}/output.md（报告压缩版）

用户审阅路径：

• 报告觉得某话题压缩太狠 → 打开 research/ 详情 → 告诉 AI 补充
• research 稿需要增删内容 → AI 回溯 transcripts/ 中的转录原文重新提炼

三个核心动作

1. 学习风格

首次使用或更新样本时执行。从 samples/ 中提取风格模板，生成 profile.yaml。

→ 详见 profile-learning.md

2. 收素材 & 调研

日常使用。两个入口：

对话直接给（主路径，零门槛）：

• 甩链接："帮我看下这个 https://..."
• 说关键词："帮我查一下 XX 公司最近的数据"
• 发笔记："今天跟 XX 创始人聊了..."
• 丢录音："帮我处理这些录音" + 文件路径

inbox 批量给（补充路径）：

• inbox.md 里粘贴多个链接/关键词
• 直接往 inbox/ 放 .md 文件或音频文件
• 告诉 AI "处理一下 inbox"

关键：调研不是信息搬运。 收到素材后不要浅尝辄止，要主动发散探索。

→ [research-philosophy.md](research-philosophy.md)（调研哲学） → material-processing.md（素材处理流程）

子 Agent prompt 必须通过脚本生成，不要手动拼：

# 阶段 1：客观探索（脚本自动隔离 worldview 和 research_preferences）
python3 ~/.claude/skills/vc-report/scripts/build-prompt.py \
  --stage 1 \
  --topic "话题名" \
  --initial-info "用户提供的初始信息" \
  --output-path "projects/{项目}/research/topic.md" \
  --workspace "<workspace路径>" \
  --depth medium  # shallow/medium/deep

# 阶段 2：认知碰撞（脚本自动注入 worldview 和 research_preferences）
python3 ~/.claude/skills/vc-report/scripts/build-prompt.py \
  --stage 2 \
  --topic "交叉分析主题" \
  --workspace "<workspace路径>" \
  --research-files "file1.md" "file2.md"

脚本根据 stage 参数程序化决定注入什么上下文，避免主 Agent 手动拼接出错。

3. 出报告

汇总产出。读取 projects/{项目}/research/ 所有文件，按 profile 模板压缩成报告。

→ 详见 report-generation.md

主动评估

每次收到用户消息后，响应前先判断：

1. profile.yaml 存在吗？ → 不存在则引导首次设置 2. 用户在做什么？ → 丢素材 / 要报告 / 讨论调研方向 3. 需要联网吗？ → 有链接或关键词 → 遵循 web-access skill 4. 有新判断？ → 主动更新 notes.md（事实层）和 worldview.md（认知层）

首次操作前加载

依赖

• web-access skill：所有联网操作遵循 web-access skill
• audio-transcribe skill：所有录音转录操作遵循 audio-transcribe skill
• Python 3 + PyYAML：运行 scripts/build-prompt.py
• 子 Agent prompt 必须由 build-prompt.py 生成，不要手动拼接

素材处理

将用户提供的素材（链接、关键词、笔记、录音）转化为结构化的调研详情文件。

输入入口

对话直接给（主路径）

用户在对话中直接提供素材，AI 即时处理：

A. 链接

用户："帮我看下这个 https://finance.yahoo.com/news/traini-..."

1. 遵循 web-access skill 抓取页面内容 2. 按 references/prompts/process-material.md + profile.yaml 的字段规范结构化 3. 写入 projects/{当前项目}/research/topic.md 4. 展示摘要供用户确认/补充

B. 关键词

用户："帮我查一下 XX 公司最近的数据"

1. 遵循 web-access skill 搜索相关信息 2. 筛选有价值的来源，逐个抓取 3. 综合多源信息，按 profile 字段结构化 4. 写入 projects/{当前项目}/research/topic.md 5. 展示调研结果，标注信息来源

C. 笔记

用户："今天跟 XX 创始人聊了，要点是..."

1. 按 profile.yaml 的字段规范结构化（如按产品/模型/运营/融资拆分） 2. 写入 projects/{当前项目}/research/topic.md 3. 展示结构化结果供用户确认

D. 录音

用户："帮我处理这些录音" + 文件路径
用户："这是上周路演的录音，整理一下"

1. 遵循 audio-transcribe skill 检查环境依赖 2. 压缩并替换原件：先将录音压缩（audio-transcribe skill 的压缩流程），压缩完成后即可删除原件，后续全部使用压缩版 3. 调用 transcribe.py 转录压缩版，输出到 `projects/{当前项目}/transcripts/`（持久化保存）

• 优先启用说话人分离（需要 HF_TOKEN 已配置），不加 --no-diarization
• 说话人标识（SPEAKER_00 等）是后续"谁说了什么"的关键归属依据
• 如果发现已有转录但缺少说话人分离，用 --diarize-only 补跑（复用 ASR 结果，只跑 pyannote）
• 不要输出到 /tmp——转录文本是不可再生的中间产物（重跑需要 ASR 费用和时间），必须持久化

3. 读取 .transcript.md 转录文本 4. 按 vc-report 的视角加工（不是照搬转录文本）：

• 按 profile.yaml 的字段规范结构化（产品/模式/运营/融资等）
• 提炼投资洞察，而非逐句记录
• 识别说话人角色（创始人/投资人/行业专家），标注关键判断的归属
• 保留关键原话作为引用（有判断价值的观点、数据承诺等）
• 过滤自家机构信息：检查 profile.yaml 的 firm 字段，该机构方的内部表态、策略、需求等不写入 research 文件

5. 写入 projects/{当前项目}/research/topic.md（格式同其他素材类型） 6. 展示摘要供用户确认/补充

批量录音处理：用户一次性给多个录音文件时，每个文件派一个子 Agent 并行转录 + 加工：

主 Agent
  ├─ 子 Agent 1: 压缩 file1.m4a → 删除原件 → 转录压缩版 → 加工为 research/topic1.md
  ├─ 子 Agent 2: 压缩 file2.m4a → 删除原件 → 转录压缩版 → 加工为 research/topic2.md
  └─ ...

子 Agent prompt 中必须写：必须加载 audio-transcribe skill 并遵循指引 + 压缩完成后立即删除录音原件。

inbox 批量给（补充路径）

用户提前把素材放到 inbox/ 目录，然后告诉 AI "处理一下 inbox"。

inbox.md：用户在这里粘贴链接和关键词，每行一条。格式自由：

https://finance.yahoo.com/news/traini-...
https://arxiv.org/pdf/2001.08361
查一下 XX 公司最近的 DAU 数据
某篇论文，跟某个技术方向相关

其他 .md 文件：用户直接放进 inbox 的笔记文件，当作"笔记"类型处理。

音频文件：用户放进 inbox 的 .mp3/.m4a/.wav/.aac 等文件，当作"录音"类型处理。

处理流程： 1. 读取 inbox/inbox.md，逐行判断类型（URL → 链接模式，其他 → 关键词模式） 2. 读取 inbox/ 中其他 .md 文件 → 笔记模式 3. 读取 inbox/ 中音频文件 → 录音模式（遵循 audio-transcribe skill） 4. 逐条处理，写入 projects/{当前项目}/research/ 5. 处理完成后清空 inbox.md 对应行，移动已处理文件到 inbox/_processed/

research 文件格式

每个话题一个 .md 文件，文件名为「公司/话题名 + 核心关键词」，中英文混合，可读性优先（如 AcmeCorp-语音助手.md、YC-S25批次观察.md、端侧模型-性能对比.md）。避免纯英文缩写（如 acme.md、yc-s25.md），打开文件夹时应该一眼知道每个文件是什么。

# {话题名称}

> 来源：{link/search/note/audio} | {日期}
> URL：{如有}
> 录音：{原始文件名，仅 audio 类型}
> 转录：{transcripts/xxx.transcript.md，仅 audio 类型}

## {板块1}（按 profile 字段规范）
- 要点1
- 要点2
- ...

## {板块2}
- ...

## 关键数据
- {数据指标}[^1]
- {数据指标}[^2]

## AI 摘要
{2-3 句话的压缩摘要，供周报直接引用或改写}

---
[^1]: https://xxx.com — 来源描述
[^2]: https://yyy.com — 来源描述

脚注引用：关键数据点必须用 [^N] 标注来源 URL，文末集中列出脚注。让每个数据都可溯源。

文件中的 "AI 摘要" 段是关键：它是调研详情到周报之间的桥梁。用户审阅时可以看到完整详情，同时也能快速看到 AI 打算怎么压缩。

合并逻辑

同一话题多次输入时（如先有笔记，后有链接补充）：

• 如果 projects/{当前项目}/research/ 已存在同话题文件 → 追加/合并内容，而非覆盖
• 更新 AI 摘要
• 标注信息来源的追加时间

并行调研

当用户要求同时调研多个方向时，派出子 Agent 并行处理：

• 每个子 Agent 负责一个独立话题
• prompt 中必须写：必须加载 web-access skill 并遵循指引
• 用"获取"而非"搜索"描述任务，让子 Agent 自主选择工具
• 每个子 Agent 的结果汇总后分别写入对应的 research 文件

参考

• 素材结构化 prompt：references/prompts/process-material.md
• 录音加工 prompt：references/prompts/process-audio.md

风格学习

从用户的历史样本（周报、会议纪要）中提取风格，生成 profile.yaml。

触发时机

• 首次使用（profile.yaml 不存在）
• 用户丢入新的样本（周报或会议纪要）
• 用户说"学习这个风格"/"更新风格"

流程

周报样本

1. 读取 samples/ 中的周报文件 2. 按 references/prompts/analyze-style.md 分析，提取以下维度（维度是固定的，但每个维度的具体答案完全从样本中学）：

• 结构模板：报告有哪些板块？什么顺序？有无层级嵌套？哪些板块是每期必有的、哪些是可选的？
• 板块内部格式：每个板块的呈现方式——是展开详情还是一行摘要？有无固定子模块？用 bullet 还是段落？有无表格？
• 语言风格：中英混用程度、主观 vs 客观、括号/旁注习惯、数据引用方式
• 信息粒度：数据精确度偏好（百分比/数量级）、定性 vs 定量、压缩程度
• 关注领域：从样本中提取用户实际在跟踪的赛道和公司

3. 生成/更新 profile.yaml 的 report_style 部分

会议纪要样本

1. 读取 samples/ 中的会议纪要文件 2. 按 references/prompts/analyze-style.md 分析，提取：

• 纪要结构：会议纪要的板块和组织方式
• 信息密度：原话保留多少、压缩到什么程度
• 说话人处理：是否标注谁说的、怎么标注
• 数据敏感度：数据指标的呈现方式、是否标注数据来源
• 判断风格：是纯记录事实，还是带分析和个人判断

3. 生成/更新 profile.yaml 的 audio_processing_style 部分

合并更新

两类样本可以分别提供，也可以一次性给。每次学习只更新对应的部分，不影响已有字段。 4. 向用户展示提取结果 5. 用户确认或修正 → 更新 profile.yaml

profile.yaml 结构

# 基本信息
name: ""
role: ""                          # 如 "VC 投资人"
firm: ""                          # 如 "某基金"

# 关注领域（从样本中提取 + 用户补充）
domain: ""                        # 如 "AI 软件"
focus_areas: []                   # 如 ["AI 社交", "AI 游戏", "宠物科技"]

# 报告风格（从周报样本中学习得到）
report_style:
  # 结构模板 — 从样本中提取板块名称、顺序、层级关系
  # 不同用户的报告结构完全不同，不做预设
  # 学习时关注：有哪些板块、什么顺序、哪些必有哪些可选、每个板块内部怎么组织
  structure: []

  # 语言风格
  tone: []

  # 信息粒度 — key 对应 structure 中的板块名
  # 学习时关注：每个板块是展开详情还是压缩摘要、用什么层级的 bullet、有无表格
  detail_level: {}

  # 风格参考片段（从样本中摘取的典型表达）
  sample_snippets: []

# 录音加工风格（从会议纪要样本中学习得到）
# 注意：这里记录的是用户的倾向和习惯，不是硬性规定。
# 不同场景（DD/路演/行业交流/内部讨论）的风格可能不同，Agent 应根据会议性质灵活调整。
audio_processing_style:
  # 学习来源：标注样本类型，帮助 Agent 判断当前场景是否适用
  learned_from: ""                # 如 "深度 DD 会议纪要" / "路演记录"

  # 观察到的组织习惯
  organization_tendencies: []
  # 示例：
  # - "倾向按说话人或议题分块组织，而非按时间线"
  # - "善用层级化 bullet points"

  # 观察到的信息处理倾向
  information_tendencies: []
  # 示例：
  # - "偏好高度结构化提炼，而非照搬原话"
  # - "关键数据必须精确保留"
  # - "分析穿插在记录中，用括号旁注"
  # - "竞品格局：习惯花大量篇幅梳理竞争演变"

  # 风格参考片段（帮助感知写法味道）
  sample_snippets: []

# 输出格式
output_format: "markdown"

风格更新

用户修改了生成的报告时触发：

1. 对比修改前后的差异 2. 判断是通用偏好还是本次特定 3. 通用偏好 → 确认 → 更新 profile.yaml 对应字段 4. 本次特定 → 记录到 notes.md

参考

• 风格提取 prompt：references/prompts/analyze-style.md
• profile 示例：references/examples/profile.example.yaml

vc-report

VC 投资人调研周报/月报助手。把零散的调研素材（链接、关键词、笔记）变成结构化的周报/月报。

Install

npx skills add eze-is/vc-report

或者直接告诉 Claude Code：

帮我安装这个 skill：https://github.com/eze-is/vc-report

依赖

• web-access — 联网调研能力（需先安装）
• audio-transcribe — 录音转录能力（处理录音素材时需要）
• Python 3 + PyYAML — 运行 scripts/build-prompt.py

核心特性

• Profile-driven：先学习用户的报告风格和关注领域，再按其习惯输出
• 两阶段调研：子 Agent 客观探索（不带偏见）→ 主 Agent 认知碰撞（加载 worldview）
• worldview.md：持续演化的认知框架，每次调研后审视更新
• 程序化 prompt 组装：build-prompt.py 根据 stage 自动隔离上下文注入，避免确认偏误
• 脚注引用：关键数据标注来源 URL，可溯源
• append 式调研：子 Agent 边调研边写入文件，保留探索路径，防中断丢失

工作流

1. 学习风格 — 丢入历史周报样本 → 生成 profile.yaml
2. 收素材   — 对话直接给（链接/关键词/笔记）或 inbox 批量给
3. 调研     — 子 Agent 客观探索 → 主 Agent 认知碰撞
4. 出报告   — 从 research 文件压缩生成周报/月报

工作区结构

<workspace>/
├── profile.yaml          # 用户画像 + 报告风格 + 调研偏好
├── worldview.md          # 持续演化的认知框架
├── samples/              # 历史报告样本（风格学习用）
└── projects/             # 每个项目 = 一次独立的调研/整理任务
    └── {项目名}/
        ├── inbox/        # 素材投递入口
        ├── transcripts/  # 录音转录原文（持久化）
        ├── research/     # 调研详情（子 Agent 写入）
        └── output.md     # 最终报告

两阶段调研设计

阶段 1（子 Agent）：客观探索
  ├─ 不带 worldview（避免确认偏误）
  ├─ 不带 research_preferences（避免角度筛选）
  ├─ prompt 由 build-prompt.py 程序化生成
  └─ 边调研边写入 research 文件

阶段 2（主 Agent）：认知碰撞
  ├─ 加载 worldview → 与新发现碰撞
  ├─ 加载 research_preferences → 从用户视角审视
  ├─ 矛盾 = 最有价值的发现
  └─ 更新 worldview，生成 output

Skill 文件

vc-report/
├── SKILL.md                      # 主入口
├── research-philosophy.md        # 调研哲学（两阶段、深度标准）
├── profile-learning.md           # 风格学习流程
├── material-processing.md        # 素材处理流程
├── report-generation.md          # 报告生成流程
├── scripts/
│   └── build-prompt.py           # 子 Agent prompt 程序化组装
└── references/
    ├── prompts/                  # 各阶段 prompt 模板
    └── examples/                 # profile 示例

License

BSL 1.1 — 个人和非商业用途自由使用，商业用途需购买授权。2030-04-10 后自动转为 Apache 2.0。

风格分析 Prompt

分析用户提供的样本（周报和/或会议纪要），提取风格模板。

输入

用户的历史样本，可能包括：

• 周报样本（1-3 份）：markdown 或纯文本的周报/月报
• 会议纪要样本（1-3 份）：用户自己写的会议纪要、路演记录等

两类样本可以分别提供，也可以一次性给。先判断每份样本属于哪种类型，再按对应维度分析。

---

A. 周报样本分析维度

1. 结构模板

• 报告有哪些一级板块？（如 Wrap up / Next on / Intriguing references）
• 每个板块下有哪些二级分类？（如 Meeting / Desktop research）
• Meeting 类的项目通常按什么维度展开？（如 产品/模型/运营/融资）
• 板块的固定顺序是什么？

2. 字段规范

• 每个项目/调研条目通常包含哪些信息字段？
• 哪些字段是必填的（每条都有），哪些是可选的（偶尔出现）？
• 数据指标的呈现方式（精确数字 vs 量级描述 vs 百分比）

3. 语言风格

• 中英文混用的模式（哪些用英文、哪些用中文）
• 是否带个人判断和情绪表达（如括号吐槽、反问）
• 句式特点（短句 vs 长句、列表 vs 段落）
• 专业术语的使用习惯

4. 信息粒度

• Meeting 记录的详细程度
• Desktop research 的详细程度
• References 的格式（标题+链接 / 纯链接 / 带简介）

5. 关注领域

• 从样本中出现的公司/产品/技术，推断用户关注的赛道
• 从调研角度推断用户的投资偏好（早期/中期、To B/To C 等）

→ 输出到 profile.yaml 的 report_style 部分

---

B. 会议纪要样本分析维度

目标：观察用户怎么思考和组织信息，提取倾向和习惯，不是硬性规定。

1. 样本场景识别

• 这是什么类型的会议？（DD？路演？行业交流？内部讨论？）
• 参会人的角色关系是什么？
• → 记录到 learned_from，帮助后续判断风格的适用范围

2. 组织习惯（→ organization_tendencies）

观察用户怎么把一段对话重新组织成文档：

• 用什么逻辑划分内容？（按说话人？按议题？按时间线？）
• 层级结构怎么用的？嵌套深度、缩进表示什么关系？
• 开头放了什么？结尾放了什么？
• 说话人信息怎么处理的？

3. 信息处理习惯（→ information_tendencies）

这是最核心的部分。不要带预设去找特定模式，而是观察：

用户保留了什么？ — 从原始对话到最终纪要，哪些信息被认为值得记录？用户在什么内容上花了最多笔墨？这反映的是他作为投资人最关注什么。

用户怎么处理这些信息？ — 是照搬原话还是用自己的语言重组？数据是精确记录还是模糊化？分析判断穿插在事实中还是独立成段？

用户省略了什么？ — 什么内容在对话中大概率出现过但纪要里没有？这反映的是他认为什么不重要。

把观察到的模式如实记录为 tendencies，每条用"倾向..."或"习惯..."开头，不要写成"必须..."或"要求..."。

4. 风格参考片段（→ sample_snippets）

• 摘取 3-5 个典型段落，覆盖不同类型的内容
• 每个片段标注它示范的是什么类型的写法
• 选能体现用户独特处理方式的段落，而非通用写法

→ 输出到 profile.yaml 的 audio_processing_style 部分

---

输出

根据样本类型，生成/更新 profile.yaml 对应部分。对于不确定的部分标注 # 待确认，向用户确认。

报告生成 Prompt

从本周/本月的调研详情文件汇总生成结构化报告。

输入

• projects/{项目}/research/ 目录下的所有 .md 文件（调研详情）
• profile.yaml（报告结构、风格、调研偏好）
• worldview.md（认知框架，用于交叉判断）

生成规则

内容组织

1. 按 profile.structure 排列板块，保持用户习惯的顺序 2. 自动归类：根据素材来源和内容性质，归入 profile.structure 中对应的板块。归类不确定时按内容性质判断，而非死板规则 3. 同话题合并：同一公司/产品的多条素材合并为一个条目 4. 相关话题可聚合呈现：如果多个话题属于同一趋势，可以在一个小标题下一起写，再分别展开 5. 链接汇总：从所有 research 文件中提取参考链接，去重后汇总到 profile 中对应的链接板块（如有） 6. 后续建议：从 notes.md 的待办事项 + research 文件中识别的未完成线索，归入 profile 中对应的计划/待办板块（如有）

压缩策略

• 各板块条目：按 profile 定义的 detail_level 控制信息量，优先使用 research 文件中的 AI 摘要为基础
• 保留个人判断：用户或 notes.md / worldview.md 中的主观判断必须保留（这是报告的独特价值）
• 保留关键数据：精确的数字指标（DAU、ARR、留存率等）不能在压缩中丢失
• 遵循 research_preferences：按 profile.yaml 的 research_preferences 控制呈现角度。数据是佐证，不是主体；关注战略含义而非技术细节

脚注引用

周报中的关键数据点必须用脚注标注来源 URL：

CLI 工具比 MCP 便宜 10-32x[^1]，XX 公司 DAU 涨到了 160w[^2]

---
[^1]: https://example.com/benchmark — benchmark 文章
[^2]: https://example.com/source — 数据来源

脚注从 research 文件的脚注中继承。如果 research 文件中标注了 [unverified]，周报中不引用该数据点，或标注不确定性。

风格遵循

• 按 profile.report_style.tone 中的风格要求输出
• 参考 profile.report_style.sample_snippets 中的表达方式
• 保持用户习惯的中英文混用模式
• 每条控制在 profile 定义的信息粒度内，不写长段分析。个人判断用括号自然穿插

输出格式

按 profile.yaml 的 structure 动态生成。不同用户的报告结构可能完全不同。

URL 校验

生成完成后，对所有脚注和链接汇总板块中的 URL 做一次有效性检查：

• 遵循 web-access skill，WebFetch 检查可访问性
• 无法访问 → 标注 [链接失效] 或替换
• 微信公众号链接（mp.weixin.qq.com）跳过校验（通常有效但不可被 WebFetch 抓取）

月报特殊处理

月报不是四份周报的拼接，而是：

• 按话题/赛道聚合，而非按周聚合
• 侧重趋势变化（某赛道本月的整体走向）
• 重点项目的进展时间线
• 本月的关键判断演变（从 notes.md + worldview.md 提取）

录音转录加工 Prompt

将 audio-transcribe 产出的转录文本，加工为结构化的调研详情。

这不是逐句翻译。 目标是从对话中提取有决策价值的信息，按 profile 字段规范组织。

输入

• .transcript.md：audio-transcribe 产出的带时间戳 + 说话人的转录文本
• profile.yaml：
• audio_processing_style：用户的加工风格倾向（组织习惯、信息处理偏好、参考片段）
• report_style：字段规范（按什么维度组织内容）
• research_preferences：调研视角偏好（关注什么、回避什么）
• 用户提供的上下文（"这是 XX 公司路演录音"、"这是行业会议"等）

第一步：判断场景 + 加载风格

1. 通读转录文本，判断对话场景（DD？路演？行业交流？内部讨论？） 2. 读取 audio_processing_style.learned_from，了解风格偏好是从什么场景学来的 3. 场景匹配度判断：

• 匹配度高（如学自 DD，当前也是 DD）→ 紧跟 profile 的 tendencies
• 匹配度低（如学自 DD，当前是轻量行业交流）→ 参考但灵活调整，结构和密度适配当前场景

4. 根据对话内容推断每个 SPEAKER 的身份（创始人 / 投资人 / 行业专家 / 主持人等） 5. 如果用户已告知场景和参与者，直接使用

第二步：信息提取

从对话中提取内容。提取什么、提取到什么深度，由三个来源共同决定：

1. `report_style.structure` 的 subsections → 决定按什么维度组织 2. `audio_processing_style.information_tendencies` → 了解用户的处理习惯和关注点 3. `research_preferences` → 决定关注什么视角

核心原则：用户的 information_tendencies 告诉你他关注什么、怎么处理信息。按他的习惯来，而非按固定模板。

当 profile 未定义时的默认逻辑：

提取对投资决策有价值的信息——具体什么有价值取决于会议内容本身。通用的判断标准：

• 量化信息精确保留，标注来源说话人
• 判断性陈述（对市场/产品/竞争的观点）视情况保留原话或结构化提炼
• 会议中篇幅最大的主题往往是最重要的，给予对应的记录深度
• 寒暄、重复、流程性内容通常省略

第三步：原话保留

参考 audio_processing_style.information_tendencies 中关于原话处理的倾向。

profile 未定义时的默认规则：

倾向保留原话的场景：

• 数据承诺：口头给出的数据、目标、时间节点
• 关键判断：压缩会失去语气和确信度的判断性陈述
• 分歧观点：多人意见不同时，各方的原始表述
• 非共识洞察：违反直觉或新颖的观点

倾向结构化提炼的场景：

• 事实性陈述（产品功能列表、团队背景等）
• 与多个来源一致的行业常识
• 可以用一句话准确概括的长段讨论

输出格式

与其他素材类型共用同一格式（见 process-material.md），仅元信息区别：

# {话题名称}

> 来源：audio | {YYYY-MM-DD}
> 录音：{原始文件名}
> 场景：{路演/DD/访谈/行业交流/...}
> 参与者：{SPEAKER_00 = 创始人张三, SPEAKER_01 = 投资人李四}

## {板块1}（按 profile 字段规范）
- 要点
- 要点
> "原话引用" — 说话人（如果 tendencies 倾向保留原话）

## {板块2}
- ...

## 关键数据
- {指标}：{数值}（{说话人}口头陈述）

## AI 摘要
{2-3 句话，投资视角}

批量录音处理

用户一次性给多个录音时：

• 每个录音独立处理，各自产出一个 research/topic.md
• topic 名称从对话内容自动提取（公司名 / 会议主题）
• 如果用户未说明每个录音是什么，转录后先从内容判断，拿不准就问用户

素材结构化 Prompt

将原始素材（网页内容/搜索结果/用户笔记）转化为结构化的调研详情。

输入

• 原始内容（网页正文 / 搜索结果 / 用户笔记）
• profile.yaml 中的字段规范（决定按什么维度拆分）
• 素材来源类型（link / search / note）

处理规则

信息提取优先级

1. 核心数据：用户量、DAU、MAU、ARR、留存率、融资金额等可量化指标 → 必须提取，保留精确数字 2. 产品信息：产品形态、技术路线、核心功能、差异化优势 → 按 profile 字段规范组织 3. 商业信息：商业模式、盈利路径、竞争格局 → 投资视角整理 4. 团队信息：创始人背景、团队规模、关键人物 → 简要但准确 5. 个人判断：如果用户笔记中有主观判断（"我觉得..."、"值得关注"），原样保留

字段规范适配

根据 profile.yaml 的 report_style.structure 中定义的 subsections 来组织内容。

例如，如果 profile 定义了 Meeting 的 subsections 为 ["产品规划", "模型构建", "运营情况", "团队和融资"]，则按这四个维度拆分内容。没有信息的维度可以省略。

如果素材内容不完全匹配预定义的 subsections，灵活处理：用最接近的板块，或创建临时板块。

来源标注

• link：标注原始 URL 和抓取日期
• search：标注搜索关键词和引用的信息源 URL
• note：标注"用户笔记"和日期

输出格式

# {话题名称}

> 来源：{link/search/note} | {YYYY-MM-DD}
> URL：{如有原始 URL}

## {板块1}
- 要点（尽量用数据支撑）
- 要点
- ...

## {板块2}
- ...

## 关键数据
- {指标1}：{数值}
- {指标2}：{数值}

## AI 摘要
{2-3 句话。不是泛泛的总结，而是投资视角的关键判断：这个东西值不值得关注、为什么、有什么风险。}

## 参考链接
- {URL1}
- {URL2}

AI 摘要写作要求

摘要是给投资人快速扫的，要求：

• 直接说结论，不要铺垫
• 带投资判断视角（市场机会、风险点、竞争壁垒）
• 如果有关键数据，摘要里也要提到
• 2-3 句话，不超过 100 字

报告生成

从项目的 research/ 目录汇总生成报告。

触发

• "出报告" / "汇总一下" / "生成输出"
• 用户在某个项目上下文中要求产出

报告生成流程

1. 确定项目：用户指定的项目（如 projects/2026-03-录音整理/），或当前正在操作的项目 2. 读取素材：遍历 projects/{项目}/research/ 所有 .md 文件 3. 读取 profile：加载 profile.yaml 的报告结构模板和风格 4. 按模板组织：

• 按 profile.structure 的板块顺序排列
• 每条素材根据内容和来源归入对应板块（板块定义来自 profile，不做预设）
• 同一项目/公司的多条素材合并

5. 过滤自家机构信息：检查 profile.yaml 的 firm 字段，确保 output 中不出现该机构的内部策略、合伙人判断、与项目方的互动细节等。即使 research 文件中已做过滤，output 阶段仍需再检查一遍 6. 压缩内容：

• 优先使用各 research 文件中的 "AI 摘要" 段
• 按 profile 的 detail_level 控制信息量
• 保留关键数据指标

7. 输出：写入 projects/{项目}/output.md 8. 展示给用户：用户可修改，触发风格学习

跨项目聚合

月报等需要聚合多个项目 research 的场景：

1. 创建月报项目：projects/2026-04-月报/ 2. 聚合相关项目的 research 文件（按日期筛选或用户指定） 3. 按 profile 模板组织，侧重：

• 趋势总结而非逐条罗列
• 跨项目对比
• 重点项目的进展汇总

4. 月报如有专属调研 → 写入 projects/2026-04-月报/research/ 5. 输出到 projects/2026-04-月报/output.md

报告格式

按 profile.yaml 的 structure 字段动态生成。板块名称、顺序、层级关系、每个板块的信息粒度全部来自 profile，不做预设。

脚注引用

周报中的关键数据点必须用脚注标注来源，从 research 文件的脚注中继承：

XX 公司 DAU 涨到了 160w[^1]，CLI 工具比 MCP 便宜 10-32x[^2]

---
[^1]: https://example.com/source — 数据来源
[^2]: https://example.com/benchmark — benchmark 文章

如果 profile 中有专门汇总链接的板块，该板块本身不需要脚注（它就是链接列表）。

URL 有效性校验

生成报告后、展示给用户前，对所有引用的 URL（脚注 + 链接汇总板块）做一次快速检查： 1. 遵循 web-access skill，逐个 WebFetch 检查是否可访问 2. 无法访问的 URL 标注 [链接失效] 或替换为可用的替代来源 3. 微信公众号链接（mp.weixin.qq.com）通常有效但不可被 WebFetch 抓取，可跳过校验

用户修改与反馈

用户看到生成的报告后可能会：

• "这部分太简略了，补充一下" → 从 research 文件中补充
• "这条不重要，删掉" → 删除并记录偏好
• "这个板块的顺序调一下" → 更新 profile.yaml 的 structure
• "这个表述不对" → 直接修正

每次修改都是风格学习的输入（见 profile-learning.md）。

参考

• 报告生成 prompt：references/prompts/generate-report.md

调研哲学

调研不是信息搬运，是主动探索。用户给的是起点，不是终点。

核心原则

报告服务于内部受众，不泄露自家信息。

调研和报告是给基金内部看的。profile.yaml 的 firm 字段标识了用户所在机构——该机构的内部信息（投资策略、合伙人判断、与项目方的互动细节、业务方向、PR 偏好等）不应出现在 research 文件和 output 中。报告只聚焦外部信息：项目本身、市场、数据、外部机构的公开或可引述的动态。

这条规则贯穿全流程：子 Agent 生成 research 时过滤，主 Agent 生成 output 时再过滤一遍。

像人一样思考，不像爬虫一样抓取。

一个好的 VC 调研员拿到一个话题后，不会只看用户给的那篇文章就停了。他会： 1. 先理解这个东西是什么、为什么重要 2. 想"我还想知道什么"——竞品是谁？技术路线有没有替代方案？创始人之前做过什么？ 3. 去找——搜索、看相关报道、翻 GitHub、查融资记录 4. 交叉——发现 A 话题和 B 话题有关联，形成更高层的判断 5. 收束——回到投资视角：这意味着什么？值不值得跟进？

AI 调研应该走完这个完整的思考链，而不是停在第 1 步。

两阶段调研：先客观，再碰撞

为什么不一开始就带着 worldview 调研？

带着已有认知进入调研会导致确认偏误——下意识地找支持已有判断的证据，忽略矛盾信号。而矛盾恰恰是最有价值的发现。

正确的节奏：

阶段 1：客观探索（不加载 worldview）
  → 这是什么？做了什么？数据怎样？行业怎么看？
  → 纯事实收集，尽量全面，不带预判
  → 完成第一层（理解）和第二层（发散）

         ↓ 事实收集完毕

阶段 2：认知碰撞（加载 worldview）
  → 这跟我之前的判断一致吗？有没有矛盾的地方？
  → 矛盾 = 金矿 → 针对矛盾点追加调研验证
  → 完成第三层（交叉）和第四层（判断）
  → 更新 worldview

阶段 1 的子 Agent 不应获得 worldview 内容——让它们带着干净的视角去探索。 阶段 2 由主 Agent 完成——它读取所有子 Agent 的结果，加载 worldview，做交叉碰撞和判断。

调研深度标准

每个话题的调研分四层：

第一层：理解（必做，阶段 1）

• 这是什么？解决什么问题？
• 核心产品/技术是什么？
• 用户给的信息源说了什么？

第二层：发散（主动探索，阶段 1）

• 横向：同赛道还有谁在做？他们的路线有什么不同？
• 纵向：这个方向的上下游是什么？依赖什么基础设施？服务什么场景？
• 时间线：这个东西从什么时候开始的？最近有什么变化？趋势是什么？
• 人：创始人/核心团队是谁？之前做过什么？（如果是创业项目）

第三层：交叉（认知碰撞，阶段 2）

• 加载 worldview.md
• 新发现跟已有判断一致？→ 记录为验证
• 新发现跟已有判断矛盾？→ 这是最有价值的信号，针对矛盾点追加调研
• 这个话题和本期其他调研话题有什么关联？
• 有没有共同的底层趋势在驱动这些现象？

第四层：判断（收束，阶段 2）

• 投资视角：这意味着什么机会或风险？
• 值不值得深入跟进？下一步应该做什么？
• 更新 worldview.md：验证的判断加强，被推翻的判断修正，新发现的趋势补充

调研前的规划

面对一批素材（如 inbox 中的多条内容）时，不要逐条孤立处理：

1. 通览全局：先扫一遍所有素材，识别主题簇和关联关系 2. 规划调研计划：

• 哪些话题属于同一个主题簇？应该一起研究
• 每个话题/簇的调研深度是什么？（有些值得深挖，有些快速过即可）
• 调研顺序是什么？（先研究基础层的，再研究应用层的，因为后者的判断依赖前者）

3. 向用户确认规划：展示调研计划，确认优先级和深度 4. 阶段 1 执行：按计划派出子 Agent 客观探索（不带 worldview） 5. 阶段 2 碰撞：所有结果回收后，加载 worldview，做交叉分析和判断 6. 更新 worldview.md

调研时的 web access 策略

遵循 web-access skill 进行所有联网操作。

不要只看用户给的链接就停了。 基于理解和发散的需要，主动：

• 搜索竞品和替代方案
• 查看项目的 GitHub（star 数、活跃度、contributor）
• 搜索融资记录（Crunchbase、IT 桔子、36Kr）
• 搜索创始人背景
• 搜索行业报告和数据
• 搜索用户评价和社区讨论

发散的边界：不是无限发散，而是围绕投资判断所需的信息。问自己"如果我要决定是否跟进这个项目/赛道，我还缺什么信息？"——缺什么就去找什么。

子 Agent 与主 Agent 的分工

信息传递：文件，不是消息

子 Agent 的调研结果不是"返回一段摘要给主 Agent"——那样会丢失细节。 子 Agent 的产出是 直接写入 research/topic.md 文件。文件是持久化的传递介质，主 Agent 什么时候读都能拿到完整细节。

压缩只发生在最后一步：从 research 到 output.md（周报）。research 文件本身不压缩。

分工明确

子 Agent：阶段 1（客观探索）→ 写 research 文件
  ├─ 第一层：理解
  ├─ 第二层：发散（主动搜索、深挖）
  ├─ 直接写入 projects/{项目}/research/topic.md
  ├─ 文件内容是详细的调研事实，保留所有关键细节和数据
  ├─ 不带 worldview——避免确认偏误
  └─ 不带 research_preferences——避免角度筛选偏误

主 Agent：阶段 2（认知碰撞）→ 写 output
  ├─ 读取所有 research 文件（完整细节都在文件里）
  ├─ 加载 worldview.md → 与新发现碰撞
  ├─ 加载 research_preferences → 从用户关心的视角审视事实
  ├─ 第三层：交叉分析，找矛盾和连接
  ├─ 如需追加调研 → 再派子 Agent（带着具体问题）
  ├─ 第四层：判断、更新 worldview
  └─ 压缩生成 output.md（按 research_preferences 控制呈现角度）

子 Agent 的 research 文件写作标准

边调研边写，append 式追加，不是调研完才一次性整理。

每完成一个探索动作（抓取一个页面、搜索一个方向、发现一条线索），立即追加写入文件。原因：

• 防中断丢失——已写入的部分永远在
• 过程可见——用户随时能看到调研进度
• 保留探索路径——先看到 A → 发现 B → 又找到 C，这个顺序本身是有价值的信息

文件结构：探索日志，而非最终文档

# {话题名}

> 调研进行中 | {日期}
> 来源：{用户提供的初始信息}

## 初始信息
{用户给的链接/关键词/笔记原文}

## 产品/项目概况
（抓取后追加）

## 发散：{方向1}
（搜索后追加）

## 发散：{方向2}
（追加）

## 关键数据汇总
（调研中持续更新，每发现新数据就追加）

## 参考链接
（边找边追加）

每个 ## 发散： section 对应一次探索动作的产出。

写作要求：

• 事实详尽：关键数据必须精确保留，不能用"增长迅速"代替"月增长 40%-50%"
• 脚注引用：关键数据点必须用脚注标注来源 URL，格式为 [^N] + 文末脚注列表。让每个数据都可溯源
• 不做价值判断：不写"这个项目很有前景"，只写事实让主 Agent 判断
• 标注不确定性：信息来源不够可靠或数据可能过时时，明确标注 [unverified]
• 区分事实和推断：确认的事实直接陈述，推断用"可能"/"推测"等词标注
• 调研完成后：将文件头部的"调研进行中"改为"调研完成"

文件尾部脚注格式：

---
[^1]: https://github.com/xxx — GitHub 仓库页面
[^2]: https://techcrunch.com/xxx — TechCrunch 报道
[^3]: 搜索结果，未找到一手来源 [unverified]

子 Agent prompt 生成：必须用脚本

不要手动拼子 Agent 的 prompt。 使用 scripts/build-prompt.py 程序化生成。

# 阶段 1 prompt（自动隔离 worldview 和 research_preferences）
python3 ~/.claude/skills/vc-report/scripts/build-prompt.py \
  --stage 1 \
  --topic "话题名" \
  --initial-info "用户给的链接/关键词/笔记" \
  --output-path "projects/{项目}/research/topic.md" \
  --workspace "<工作区路径>" \
  --depth medium

脚本根据 stage 参数自动决定注入什么：

• stage 1 → 不注入 worldview、不注入 research_preferences（保持客观）
• stage 2 → 注入 worldview + research_preferences（认知碰撞）

这样做的原因：靠 AI 读文档后正确决定"带什么不带什么"是不可靠的（已验证会出错）。脚本把规则写在代码里，程序化隔离。