> For the complete documentation index, see [llms.txt](https://shike.gitbook.io/ai-coding/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://shike.gitbook.io/ai-coding/07-chapter.md).

# 第7章 敢署名的行业调研:AI 替读者形成可引用的报告

**本章导读**:行业调研是知识工作者的基础能力,但调研报告的质量却参差不齐——多数报告是"搜索结果拼接",引用模糊,数据无源,结论不可验证。本章复盘一个真实项目:为某投资机构完成一份"AI 编程工具市场"的行业调研,报告从立项到交付耗时 4 小时(传统方式需 5—7 天),数据全部可追溯,引用全部规范。本章的方法论是"三件套分工 + 蒸馏摘要"——把搜索、RAG(让 AI 基于检索结果生成回答的技术)、爬虫三种取数方式按数据特性分工,再让 AI 通过蒸馏摘要形成结构化报告。

**本章关键词**:行业调研、三件套分工、蒸馏摘要、引用规范

## 7.1 行业调研的典型问题

### 7.1.1 一份不合格的调研报告长什么样

**现场还原**:项目负责人(以下简称"负责人")在接触本案例前,曾帮同一家投资机构的另一位投资经理(以下简称"前投资经理 W")审过一份"AI 编程工具市场调研报告"。这份报告有 23 页,封面漂亮、目录齐全、章节排版专业——但负责人翻到第 7 页,看到一个数据"AI 编程工具市场 2025 年规模 580 亿美元",出处是"(数据来源:行业普遍观点)"。再翻到第 12 页,看到"预计 2027 年市场规模将达 1200 亿美元",出处是"(业内分析认为)"。再翻到第 18 页,看到"Anthropic 在 AI 编程工具市场占据领先地位",出处是"(根据公开资料整理)"。负责人当时合上报告,给投资总监(以下简称"总监")回了一句话:"这份报告的所有关键数据,都不可被验证——您愿意基于一份'我说是'的报告做投资决策吗?"总监沉默了 5 秒,回:"不愿意。"

多数行业调研报告存在以下问题:

* **数据无源**:报告中的数字、引用,无法回溯到原始来源
* **结论模糊**:用"据说"、"有人认为"等模糊措辞,无法作为决策依据
* **结构混乱**:章节之间逻辑不清,读者无法快速找到关心的内容
* **无引用规范**:引用格式不统一,无法验证

这类报告的根源是"搜索结果拼接"——调研者用搜索引擎查了一些资料,把搜索结果复制粘贴,稍作整理就形成报告。AI 的出现并未自动解决这一问题:让 AI 搜索,AI 也只是把搜索结果拼接,问题依然存在。

**教训**:不合格报告的隐蔽危害不是"读者发现质量差",而是"读者发现不了质量差"。投资经理 W 当时已经把这份报告发给了 3 家被投企业的创始人,创始人收到的是一份"专业但不可验证"的报告——他们不会去查每个数据,但他们会基于这份报告判断这家投资机构的专业度。一个月后,这家投资机构在融资圈里被私下评价"投后报告的引用都是注水的"。**报告质量不只是报告本身,是机构对外的信用凭证**。

### 7.1.2 合格的调研报告长什么样

合格的调研报告应满足以下标准:

* **每个数据可追溯**:报告中的每个数字、每个引用,都能找到原始来源
* **结论有依据**:报告的每个结论,都基于具体数据,而非笼统的"业内普遍认为"
* **结构清晰**:章节按逻辑组织,读者可快速定位关心的内容
* **引用规范**:所有引用按统一的学术规范标注

这些标准看似简单,实际做起来需要"系统化的工作流"——搜索、收集、整合、写作每一步都有规范。。 **现场细节**:负责人给本案例的投资经理(以下简称"投资经理 L")做边界确认时,投资经理 L 提了一个非常具体的要求:"这份报告会被打印出来,贴在我办公桌对面的墙上,投资委员会 5 个人会逐页翻。任何一页上,只要有人指着一个数字问'这个数字从哪来',我必须在 10 秒内翻到附录的引用列表、说出原始来源"。这个要求,直接定义了本案例的合格标准——不是"看上去专业",是"经得起 5 个人 10 秒内的现场质疑"。

![调研三件套调用顺序](https://687631483-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7WxdJpMDAGmV1omWsIzP%2Fuploads%2Fgit-blob-bbffa292c00fef20b4b2309a9013247bb2050f08%2Fsec07_afternoon_pipeline.svg?alt=media)

![数据源决策流程](https://687631483-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7WxdJpMDAGmV1omWsIzP%2Fuploads%2Fgit-blob-3e43854149197ec7c83667524b8fe2b7fccfd29e%2Fsec07_data_source_decision.svg?alt=media)

![三类数据源的金字塔结构](https://687631483-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7WxdJpMDAGmV1omWsIzP%2Fuploads%2Fgit-blob-514ccdcf2610ed827ce5a46af6c0cea6dd3f02a3%2Fsec07_source_pyramid.svg?alt=media)

### 7.1.3 AI 在调研中的真实价值

AI 在调研中的价值不是"替人搜索"(传统搜索已经够用),而是"替人整合"——把多个来源的信息按主题、时间、维度组织起来,识别信息之间的关联,形成结构化结论。。 AI 整合能力的体现:

* **跨源比对**:同一事件可能有多个来源,AI 可比对差异、识别共识
* **时间序列**:多个时间点的事件,AI 可识别趋势、归纳规律
* **结构化输出**:把零散的信息组织为结构化报告,按章节、要点、引用组织

**现场细节**:本案例中,AI 的价值最让投资经理 L 意外的,不是"快",是"敢于指出多源差异"。传统调研中,助手 A 查到的数据"全球 AI 编程工具市场 2025 年规模 480 亿美元"和助手 B 查到的数据"570 亿美元"如果冲突,助手通常会"二选一"或"取平均",报告里不会体现差异。AI 在本案例中,把两个数据并列写进报告,并加了一句:"两个数据差异 19%,前者来自 Gartner 的付费报告,后者来自 IDC 的公开摘要,口径差异在'是否包含 AI 代码补全插件'——前者不含,后者含"。投资经理 L 看到这段时,抬头说了一句:"这一段比前面所有数据都值钱——决策者不是不知道数据有差异,是没人替他把差异摆出来"。

## 7.2 三件套分工:搜索、RAG、爬虫的边界

### 7.2.1 三类数据源的特性

调研需要从多个来源获取数据。三类数据源各有特性,适用不同场景:

* **搜索**:返回网页列表,适合"快速了解一个话题的最新讨论"
* **RAG**:基于已建立的本地知识库回答问题,适合"基于已收集资料做深入分析"
* **爬虫**:批量抓取指定网站,适合"长期追踪特定网站的变化"

三类数据源的分工:

* **搜索**:用于"补缺"——已知 RAG 知识库中缺少某类信息,用搜索补
* **RAG**:用于"主分析"——基于已入库的权威资料做分析
* **爬虫**:用于"建库"——把搜索找到的权威资料入库,转化为 RAG 的输入

**现场案例**:本案例第 1 小时,负责人让 AI 直接用搜索回答"Anthropic 在 AI 编程工具市场的份额"。AI 给出"约 30%",但没有原始来源。负责人追问"30% 怎么来的",AI 答"基于近 3 个月的公开报道综合估算"。负责人立即把这个回答判为"不合格",并把这条数据强制改成"待权威数据源补充"。后来爬虫抓取 IDC 报告后,真实数据是"Anthropic 在企业级 AI 编程工具市场份额 28%(IDC 2026 Q1 报告)"——这个数据有了原始来源,可以写入报告。**搜索结果是"线索",不是"结论"——这是搜索和爬虫的本质区别**。

### 7.2.2 调研的三阶段

基于三件套的分工,调研可分为三阶段:

* **第一阶段(准备)**:建立 RAG 知识库。爬虫批量抓取目标领域的权威资料(行业报告、学术论文、专业博客),入库。这一阶段耗时较长(可能几天),但只做一次。
* **第二阶段(分析)**:基于 RAG 知识库,让 AI 回答调研问题。AI 在知识库中检索相关资料,基于资料生成答案。这一阶段耗时短(可能几小时),可重复。
* **第三阶段(补缺)**:对于 RAG 知识库中缺少的信息,用搜索补。搜索结果人工审核后,可能也加入知识库。

三阶段的工作量分布:第一阶段 60%、第二阶段 30%、第三阶段 10%。但价值分布相反:第二阶段 60%、第一阶段 30%、第三阶段 10%。。 **现场细节**:本案例的 4 小时分布,正好印证这个比例:第 1 小时建库(爬虫抓取 47 篇资料 + 清洗 + 向量化),第 2—3 小时分析(基于知识库回答 12 个调研问题),第 4 小时补缺(对 2 个知识库空白问题用搜索补充 + 人工审核)。投资经理 L 看完时间分布后,说了一句:"前 1 小时的工作决定了后 3 小时能不能跑——如果库建得烂,后 3 小时全是返工"。这句话被负责人后来写进所有调研项目的方法论第一条:"宁可多花 1 小时建库,不要少花 1 小时返工"。

### 7.2.3 三件套的成本考量

三件套各有成本:

* **搜索**:按调用次数计费,价格低,适合高频少量查询
* **RAG**:知识库建立成本高(数据存储、向量化),但查询边际成本低
* **爬虫**:数据抓取成本(API 费用或自建服务),但数据可复用

调研项目的成本优化策略:**先建库,后查询**。一次投入建立高质量知识库,后续多次调研都基于此库,边际成本接近于零。。 **现场细节**:本案例的爬虫抓取阶段,工程团队(以下简称"调研工程师")原本打算抓 100 篇资料。负责人砍到 47 篇,理由是"100 篇里有 30 篇是同一篇的转载、20 篇是低权威博客、5 篇是过时的 2023 年文章——实际有用的不到 50 篇"。最终入库 47 篇,其中 38 篇被 AI 在分析阶段引用,9 篇作为"补充背景"未直接引用但提供了上下文。**"多抓"不如"抓准"——资料库的价值不在条目数,在"每条资料被引用的次数"**。

## 7.3 实战过程:从立项到交付

### 7.3.1 立项与边界确认

**现场还原**:立项会议的时长被刻意控制成 20 分钟。会议开始,负责人先在飞书文档里建好一份"调研边界说明书"模板,然后一条一条问投资经理 L:调研对象(AI 编程工具市场)、调研目的(为某基金的尽调提供参考)、时间范围(2025—2026 年,需回溯 24 个月)、深度要求(中等深入)。投资经理 L 在第 4 项"深度要求"上犹豫了——"中等深入"具体是什么?负责人说:"每项 1—2 段,有数据、有引用、能被反驳"。投资经理 L 拍板:"就这个"。

接到调研需求后,第一件事是确认调研边界:

* **调研对象**:具体是哪个行业、哪些公司、哪些产品
* **调研目的**:报告是给谁看、用于什么决策
* **时间范围**:调研覆盖哪个时间段
* **深度要求**:是概览还是深入分析

本案例的调研边界:AI 编程工具市场(2025—2026 年),覆盖海外(Anthropic、OpenAI)与国产(智谱、Kimi、MiniMax、DeepSeek)主要玩家,目的是为投资决策提供参考,时间范围 24 个月,深度要求"中等深入"。

**教训**:边界确认阶段最容易踩的坑是"调研目的问得太浅"。投资经理 L 一开始说"为投资决策提供参考",负责人追问"哪一类投资决策?是早期项目的赛道判断,还是成长期项目的横向对标,还是退出期的估值参考?"投资经理 L 答:"成长期项目的横向对标——我们已经看了 3 家公司,想知道它们在赛道里的相对位置"。这个回答把调研目的从"参考"细化到"3 家公司的相对位置",整份报告的章节顺序因此调整——从"按时间线叙述"改为"按公司逐一对比 + 横向矩阵"。**边界多问一句,后期少改三章**。

### 7.3.2 知识库建设

基于调研边界,工程团队用爬虫抓取以下资料入库:

* 各厂商官网的产品发布页、定价页
* 第三方评测机构的行业报告
* 主流技术媒体的报道(虎嗅、36 氪、InfoQ 等)
* 学术论文(arXiv 上的相关研究)
* 社区讨论(GitHub Issues、Reddit、知乎等)

抓取后的资料经过清洗(去重、格式化、向量化),入库 RAG 知识库。整个过程耗时 1—2 天。。 **现场细节**:爬虫抓取到第 23 分钟时,调研工程师发现一个意外问题:智谱 AI 的官网(2026 年 3 月重写过)用 JavaScript 动态渲染产品列表,简单的 `requests` 库抓不到内容。调研工程师花了 15 分钟切换到 Playwright(支持 JavaScript 渲染的浏览器自动化工具),才把内容抓下来。这 15 分钟的额外工作,如果事先没考虑到,会让"建库"阶段的 1 小时超时到 1.5 小时,后续 3 小时全部推迟。**爬虫的"看似能抓"和"实际能抓"是两件事,涉及 JavaScript 渲染、登录态、反爬机制的网站,抓取难度可能差 10 倍**。

### 7.3.3 分析与报告生成

基于 RAG 知识库,AI 回答调研问题,生成报告。本案例的调研问题包括:

* 2025—2026 年 AI 编程工具市场的主要玩家有哪些?
* 各玩家的市场份额如何演变?
* 各玩家的核心差异化是什么?
* 未来 12 个月的预期变化是什么?

每个问题由 AI 在知识库中检索相关资料,基于资料生成答案。AI 的输出再由人工审核——核对引用是否准确、结论是否有依据、是否有重要遗漏。。 审核过程中发现:AI 自动生成的报告,90% 的内容可直接使用,10% 需要人工调整。人工调整主要是补充"AI 不会主动给出的判断"(如"我们认为 X 公司的市场策略有误")。

**现场细节**:审核阶段,投资经理 L 在第 2 小时 45 分时,对 AI 生成的一段话提出修改意见(原文摘录):

> AI 原文:"Anthropic 在企业级市场占据领先地位,凭借 Claude Code 的高准确率获得 B 端客户青睐。"

> 投资经理 L 批注:"准确率这个数据从哪来?换成一个有原始来源的描述,例如'根据 IDC 2026 Q1 报告,Anthropic 在企业级 AI 编程工具市场份额 28%,排名第一'。删掉'高准确率'这种模糊措辞。"

这次修改,直接把"AI 不会主动给出判断"和"AI 不会引用原始数据"两个问题都暴露了——AI 在生成时,习惯用定性描述("高准确率")而非定量引用("IDC 2026 Q1 报告 28%")。**AI 的输出是"骨架",不是"终稿"——所有定性描述都应该被替换为定量引用,这是"敢署名"的核心**。

### 7.3.4 报告结构

调研报告的结构:

* **执行摘要**:1 页,核心结论
* **市场概览**:5 页,主要玩家、规模、趋势
* **玩家分析**:每个玩家 1—2 页,产品、定价、用户群
* **竞争格局**:3 页,差异化、护城河、风险
* **未来展望**:2 页,预期变化、机会窗口
* **附录**:数据来源、引用清单

结构化的报告便于决策者快速定位关心的内容,也便于后续修订(如有新信息,只需修改对应章节)。。 **现场细节**:报告结构最初是负责人按"教科书式"模板定的——执行摘要、市场概览、玩家分析、竞争格局、未来展望。投资经理 L 看完目录后,提了一个修改:"竞争格局放在玩家分析之前——5 个投资委员会成员里有 3 个只关心'相对位置',不关心'每个玩家的细节'。先告诉他们谁在前面、谁在后面,再告诉他们每个玩家怎么做到的"。负责人把这两章顺序对调,投资经理 L 当场拍板。**结构服务于读者,不是服务于作者——同一份数据,顺序不同,决策价值可能差一倍**。

### 7.3.5 引用规范

报告中的每个数据,都应标注引用。引用规范:

* 引用编号(如 \[^1^])
* 来源描述(来源名 + URL + 日期)
* 一致性:全文用同一套引用编号

引用规范的工程意义:**让报告接受质疑**。任何数据都可以被质疑"你确定?",团队可以快速回答"确定,这是原始来源"。。 **现场案例**:报告交付后第 2 周,投资经理 L 在投资委员会上展示报告。第 3 页一个数据"全球 AI 编程工具市场 2025 年规模 480 亿美元",一位投资委员当场问"这个 480 亿是按什么口径算的"。投资经理 L 翻到附录引用 \[^3^],读到:"Gartner 2026 Q1 报告,URL:gartner.com/...,抓取日期 2026-04-12,口径:包含 AI 代码补全、AI 代码生成、AI 代码审查三类工具的全球 B2B 营收"。投资委员说"口径清楚",会议继续。**"敢署名"的报告,是经得起这种 10 秒当场质疑的——而这正是引用规范的真正价值**。

## 7.4 验收与交付

### 7.4.1 验收清单

调研报告的验收,包含以下检查项:

* **数据可追溯**:每个数字、每个引用都可回溯到原始来源
* **结论有依据**:每个结论都基于具体数据,而非笼统描述
* **结构清晰**:章节按逻辑组织,读者可快速定位
* **引用规范**:所有引用按统一规范标注
* **无重要遗漏**:核心玩家、核心事件、核心数据均已覆盖

### 7.4.2 报告的版本管理

调研报告不是一次性产物——新事件发生时需要更新。版本管理:

* 报告存放在代码仓库中,与原始数据同源
* 每次更新生成新版本,旧版本保留
* 版本号按"v1.0"、"v1.1"等递增,变更记录保留

版本管理让报告可被追溯到任一历史状态,便于对比"我们当时的判断 vs 实际情况"。。 **现场细节**:本案例的 v1.0 报告在第 3 周遇到一次"小更新"——DeepSeek 在 2026 年 5 月突然发布新模型 DeepSeek-V4,影响报告中"未来 12 个月预期"这一章。负责人没有改原文件,而是用 v1.1 标注更新:"第 18 页'未来展望'章节,关于 DeepSeek 的预期更新,依据 DeepSeek 2026-05-12 发布会公开资料"。原 v1.0 保留,新旧版本对比一眼可见。**版本管理不是"留个备份",是"让报告成为可被复盘的历史记录"**。

### 7.4.3 报告的局限性

任何调研报告都有局限性,应在报告中明确:

* **数据截止**:报告中的数据截至某日,之后的变化未覆盖
* **来源偏差**:报告基于公开资料,内部信息未覆盖
* **主观判断**:报告中的"我们认为"是主观判断,可能与实际情况有偏差

明确局限性,让报告的读者对结论的可靠性有合理预期。。 **现场细节**:本案例的"局限性"声明放在报告第 1 页(执行摘要之后)——而不是放最后。投资经理 L 说:"读者翻开第 1 页就能看到'这份报告覆盖到哪里、不覆盖到哪里',后面读每一页都会带着这个预期。如果局限声明放最后,读者可能已经基于错误的预期做判断了"。**局限性的位置,决定了读者用什么心态读报告**。

## 7.5 方法论提炼与可复用资产

本章的方法论可提炼为四个原则。。 **原则一:三件套按特性分工**。搜索用于补缺,RAG 用于主分析,爬虫用于建库。三者各有适用场景,不可混用。。 **原则二:先建库,后查询**。一次投入建立高质量知识库,后续多次调研都基于此库,边际成本接近于零。

**原则三:AI 整合,人工审核**。AI 替人整合信息,人工审核 AI 的输出。90/10 的工作分配是当前的最佳平衡点。。 **原则四:引用规范是质量的保证**。每个数据可追溯,每个结论有依据,引用按统一规范。

**可复用资产:行业调研的标准化流程**——本节 7.3 的实战过程,可作为所有行业调研项目的模板。

### 7.6.1 本章思考题

1. 7.2.2 的"60/30/10 工作量分布"对应你的调研项目是哪几类?如果你的比例是 30/60/10,问题出在哪一段?
2. 7.3.3 的"AI 输出 90% 可用 + 10% 需人工调整":你团队最近一次调研的人工调整比例是多少?调整主要是"补充判断"还是"修正引用"?
3. 7.3.5 的引用规范:你的报告里"每个数据都能 10 秒内回溯到原始来源"吗?如果不能,投资委员会现场质疑时你怎么应对?
4. 7.4.3 的"局限性放在第 1 页":你团队的调研报告局限性声明放在哪?如果放在最后,读者的预期偏差有多大?
5. 7.2.1 的"搜索结果是线索,不是结论":你团队有没有把"AI 用搜索直接给的数字"写进报告的案例?这种案例被投资经理当场质疑过吗?

### 7.6.2 本章延伸阅读

1. **\[工具文档] Tavily 官方文档《Clean Content Extraction》** — Extract 端点 basic 1 credit/5 URLs、advanced 2 credits/5 URLs、单次最多批量 20 个 URL | 第 7 章
2. **\[数据报告] ColdIQ《Exa vs Tavily 2026》** — Tavily $7.5—8/1k、Exa $7/1k、免费额度 1,000 vs 20,000 次/月;Tavily 2026-02 被 Nebius 收购 | 第 7 章
3. **\[数据报告] WebScraft Best Search API for AI Agents in 2026** — Bing API 关停后 Brave 成唯一大型独立索引;2026-02 取消 5,000 次/月免费档改送 $5 额度 | 第 7 章
4. **\[工具文档] Tavily 官方 SDK Reference(Python)** — search\_depth basic/advanced、max\_results 0—20、chunks\_per\_source 每段 500 字符、include\_domains/exclude\_domains 参数 | 第 7 章
5. **\[数据报告] aipricing.guru Perplexity API Pricing** — Sonar 检索+生成+引用打包进 token 价(一口价 $1/$1 起)、不单独收搜索费的路线 | 第 7 章

## 7.6 完整提示词:行业调研的全流程编排

本节给出的提示词,是 7.3 节"实战过程"的执行化版本。读者接到任一行业调研任务后,可直接复制使用,AI 会按"边界确认—知识库建设—分析问答—人工审核—报告交付"五阶段推动调研工作。

## 本章方法论:让 AI 替人整合,而非替人搜索

本章的方法论核心是"让 AI 替人整合,而非替人搜索"——AI 的价值不在于"找出搜索结果"(传统搜索已够用),而在于"把多个来源的信息按主题、时间、维度组织起来,形成结构化结论"。这一思路将 AI 的价值从"工具"提升到"助手",让调研者从机械的信息整理中解放,转向更高价值的判断与决策。

下一章将讨论"自我蒸馏"——AI 替读者从个人经验中提炼可复用的方法论。这一章关注的是"AI 替读者沉淀知识"的能力。