企业官网建设流程全解析

简介：这份PDF文档围绕清华大学团队推出的DeepSeek+DeepResearch展开，面向科研人员、AI工具使用者及关注智能科研流程的读者，说明如何以多agent协作把数据采集、清洗处理、分析挖掘与可视化串成链路，让科研操作更接近对话式交互。文档结合社交媒体、数据库、文本与接口等数据来源，梳理数据纠错、整合、格式转换、特征提取及诊断预测、关联聚类、分类和时序模式挖掘等环节，并归纳DeepSeek R1、OpenAI o3 mini、Claude 3.5 sonnet、Kimi k1.5在低延迟、轻量化、多模态、长文本处理、可解释性与定制化等方面的差异。内容还给出爬虫网址筛选去重、Python脚本自动提取、春运数据表格整理、中长文本集成等任务提示词与测试结论，便于读者理解各模型在真实科研场景中的表现边界与选型思路。包内为1个PDF文件，约5.66MB，已有379人学习，适合希望建立DeepSeek+DeepResearch整体认知并参考实测结果的研究者与工具实践者。

1. 先说结论：四个模型，没有一个能独自跑完科研全流程

我把这组测试从头复现了一遍，结论有点反直觉：单看某一道题，DeepSeek R1、o3-mini、Claude 3.5 Sonnet、Kimi k1.5 各有拿第一的时候；可一旦把“采集—读取—集成—分析—挖掘—可视化”串成一条流水线，没有任何一个模型能全程不出错。DeepSeek R1 在中文语义理解和异常识别上最稳，却会在 15000 token 的长文本上直接不给答复；o3-mini 出活最快、还能直接画图，偏偏不能上传附件；Claude 3.5 Sonnet 输出的表格最工整、还支持下载，爬虫却始终跑不出数据；Kimi k1.5 在数据挖掘上挖得最深，处理短文本时又总漏维度。

所以真正该问的不是“哪个模型更强”，而是“哪一步该交给谁”。这篇按选型维度、逐项对比、翻车点、接力打法四层拆开讲，给要搭多 agent 科研工作台的人一份能直接抄的分工表。

2. 选型维度：把科研流程拆成五道关卡再比

2.1 五个任务不该平均加权，先看失败可逆性

市面上大多数模型横评习惯把任务平均加权，跑完五个场景算个总分。这套算法在选型上很容易误导人，因为科研流水线里每个环节的失败成本完全不对等。

数据采集错了，后面所有分析都是在错误样本上做推理，结论再漂亮也是废的，这是不可逆失败；文件读取漏了两列，还能回头补；可视化图丑一点、配色难看，改五分钟就完事，这是可逆失败。我一般会按“失败可逆性”倒推权重：数据采集 30%、文件读取 20%、数据分析 20%、文本集成 15%、数据挖掘 10%、可视化 5%。

按这个权重再去看测试结果，排序会变。o3-mini 在可视化上表现最亮眼，但那一项只占 5%，而它因为不支持附件上传，在占 20% 的文件读取环节被迫用“粘贴”降级处理，效率优势被抵消了一截。反过来 DeepSeek R1 没有单项碾压，却在权重最高的采集和分析两项都拿到了完整结果，这才是它在流水线里当中枢的原因。

2.2 四个模型的定位底表

下面这张表是我复现完所有任务后整理出来的，不是官方参数，是实测出来的“岗位适配度”。判断依据全部来自同一批任务下的输出对比。

这张表最值得注意的一行是 Claude 3.5 Sonnet 的“长文本反而更全面”。它在 7000 token 的一般文本上漏了环比和同比数据，到 15000 token 的长文本上，集成的数据维度反倒更完整。这种非线性的表现说明：模型的短板不是均匀分布的，你必须在自己的真实文本长度上验证，不能拿短样本的结论去推长样本。

2.3 三个必须现场验证的硬指标

官方介绍里最含糊、但对流水线影响最大的三个指标，我建议全部现场验证，不要看宣传。

第一是附件上传。o3-mini 在这项上是明确的“暂不支持”，文件读取只能靠粘贴。粘贴一次 200 行以内的表格还行，超过就会丢分隔符、行列错位。如果你的科研数据是几千行的 Excel，这条直接决定它能不能进主流程。

第二是联网检索。测试里 DeepSeek R1、o3-mini、Kimi k1.5 支持联网查询网址，Claude 3.5 Sonnet 暂不支持。这个差别在爬虫任务上是致命的：不联网的模型只能对着你上传的网页源代码做静态提取，一旦页面结构和你贴的代码不一致，它生成的脚本就必然抓空。

第三是长文本上限。DeepSeek R1 在 15000 token 上直接罢工，这不是“效果差一点”，是“完全没有输出”。凡是涉及整本政策文件、全年流水、完整会议纪要的场景，都必须提前做分片设计，别等跑到一半才发现。

提示：这三个指标建议在正式接入前用你自己的一份真实数据各跑一遍，十分钟能省掉后面两周的返工。

3. 逐项对比：五类任务里谁真能跑通

3.1 爬虫采集：能生成代码 ≠ 能跑出数据

这组测试的任务设计很典型：给一份网页源代码，要求先提取所有符合“某月某日，全社会跨区域人员流动量完成 X 万人次”格式的网址，去重筛选合并成列表，再写 Python 脚本批量抓取正文数据写入本地文件。这是“理解 + 编码 + 执行”三段式任务，任何一段断了，最终文件就是空的。

实测结果分成了两档。DeepSeek R1 能完整提取所有网址并完成筛选去重，生成的脚本运行后确实完成了采集，数据准确，只是少量日期有遗漏；o3-mini 响应更快，同样提取出了全部需求链接，输出了完整可运行的脚本，但采集结果为空。Claude 3.5 Sonnet 和 Kimi k1.5 都能提取网址，调整后也能输出正确代码、运行生成本地文件，但提取的数据结果同样是空的。

这里有个容易被忽略的细节：四个模型都能完成“提取网址列表”这一步。也就是说，纯文本层面的模式匹配它们都过关，真正拉开差距的是“生成的代码能不能在真实环境跑通”。代码跑通但结果为空，本质是模型对页面结构的假设和真实页面不符——它按记忆中常见的 DOM 结构写了选择器，而不是按你贴给它的那份源代码。

我一般会用这个骨架来验证模型的代码是否“真的对着数据写的”：

import requests from bs4 import BeautifulSoup HEADERS = {"User-Agent": "Mozilla/5.0 (research-collector)"} TIMEOUT = 10 def fetch_one(url): """抓单页并返回正文文本；失败返回 None 而不是抛异常，方便批量统计""" try: r = requests.get(url, headers=HEADERS, timeout=TIMEOUT) if r.status_code != 200: print(f"[SKIP] {url} status={r.status_code}") # 状态码打出来，空结果时能立刻定位 return None r.encoding = r.apparent_encoding soup = BeautifulSoup(r.text, "html.parser") node = soup.select_one("div.article-content") # 选择器必须来自你贴的源码 return node.get_text(strip=True) if node else None except Exception as e: print(f"[ERR] {url} {e}") return None

关键在select_one那一行的选择器。让模型输出脚本时，必须要求它先把“从源代码里读到哪些 class 名、哪些层级”列出来，再写代码。跳过这一步，模型基本都会凭记忆编一个article-content之类的通用类名，跑起来就是零结果。TIMEOUT和状态码打印也是必需项，否则你面对一个空文件根本分不清是选择器错了、被限流了、还是网络不通。

3.2 文件读取与文本集成：附件和长文本两道坎

文件读取任务给了一份按日汇总的多交通方式数据文本，要求整理成表格，每行包含日期、铁路客运量及其同比环比、公路客运量及其同比环比、民航客运量及其同比环比。这是一个“多列 + 多衍生指标”的提取任务，考验的是模型会不会为了输出好看而主动裁列。

结果分化明显。DeepSeek R1 详细全面地提取了文件中的数据，整理成可视化表格，逻辑性强、指标清晰；Claude 3.5 Sonnet 同样完成了任务，没有漏数据指标，逻辑性好，而且一次性生成后支持直接复制和表格文件下载；o3-mini 因为不支持附件上传，只能靠粘贴，虽然响应快、输出格式工整简洁，但输入方式本身就是降级；Kimi k1.5 能快速读取并整理成表，但数据填入有明显缺失。

文本集成任务进一步放大了差距。7000 token 的一般文本上，DeepSeek R1 提取的维度最全面，但受样本量和模型稳定性影响会出现末尾缺失，需要重复尝试才能生成完整表格；Claude 3.5 Sonnet 提取准确、表格简洁，但完全没提文本里的环比和同比数据；Kimi k1.5 数据准确但维度不够全面。到了 15000 token 的长文本，DeepSeek R1 直接无法给出答复，Kimi k1.5 反而表现突出，粘贴后自动形成文件、集成准确但维度有限，Claude 3.5 Sonnet 集成的维度比短文本时更全面。

这组结果说明一件事：文本集成环节不能按“短样本表现”来选型。如果你的数据源普遍在两三万 token 量级，就该直接把 DeepSeek R1 从这一环撤下来，交给 Claude 3.5 Sonnet 或 Kimi k1.5，然后单独安排一个人工核对“同比环比两列在不在”。

3.3 数据分析与挖掘：思维链深度决定结论质量

数据分析任务用的是一份经典的事故幸存者名单，要求读取后找出规律。这一轮比的不是谁算得准，而是谁能从特征里看出因果、看出异常。

DeepSeek R1 详细展示了长思维链，精准提取“幸存率”这个核心指标，逐项分析多个因素特征对幸存率的影响，结合历史背景对数据规律做验证，还敏锐察觉到数据异常并提出了异常处理建议。o3-mini 响应快、结果输出高效，语言表达自然、重点突出，也结合了历史背景做验证，但没有察觉数据异常。Claude 3.5 Sonnet 能精准抓关键指标，但对特征提取不完整，只识别出较浅层的数据关联，分析能力相对较弱。Kimi k1.5 提供的是分析程序的代码，能提取大部分特征并分析与生存率的关联，但最终没有形成明确结论。

数据挖掘任务换成了一份电影数据集。这一轮 Kimi k1.5 表现最出色，对特征做了精准分类，从多个维度深入挖掘指定数据的深层内涵和关联性；DeepSeek R1 与 Claude 3.5 Sonnet 都能准确完成分类，但数据之间关联的挖掘程度相对较浅；o3-mini 受附件上传限制，数据集较大时无法完成该任务。

两轮对比能看出一个规律：越往“发现”走，越依赖模型的推理深度而不是速度。异常检测这种活儿，快没有意义，能看出“这条记录不可能存在”才有意义。DeepSeek R1 在这一点上明显领先，它的长思维链不是炫技，是把“为什么认定这是异常”的推理过程摊开给你看，你能逐条反驳，这就是科研场景最需要的可审计性。

3.4 可视化：直接出图还是给代码，差别在返工次数

可视化这轮的分差最直观。o3-mini 能直接调用绘图能力生成多种类型的图表，准确度高，部分较为复杂的图表会出现数据错误或生成不出来；DeepSeek R1 和 Kimi k1.5 能结合数据样本给出多种图表绘制方案和对应 Python 代码，但都需要复制到本地运行，部分代码会报错，大样本时还会省略数据；Claude 3.5 Sonnet 同样不能直接出图，需要复制代码本地运行。

按“能不能立刻拿到图”排，o3-mini 第一；按“图能不能改、能不能复现”排，反而是给代码的三个模型更实用。科研图表的真实使用周期很长，审稿意见回来要改配色、改分组、改坐标轴刻度，直接生成的位图在这一步就废了，得从头再来。所以我的判断是：探索阶段用 o3-mini 出草图，定稿阶段必须落到代码，用可参数化的脚本重绘。

4. 避坑：多模型接力跑科研流水线最容易翻车的五个地方

4.1 输入侧的两个坑

坑一：脚本跑通了，生成的文件是空的。

现象是模型返回的代码没有任何报错，运行也正常结束，但你打开生成的 txt 一看，要么 0 字节，要么只有表头没有数据行。原因基本是两个：一是模型没真联网，凭记忆编了网址，或者把示例域名当成真实域名写进列表；二是选择器基于它“想象”的页面结构，和你贴的源代码对不上。解决方式是把这一步拆成两段验收：先只让它输出网址列表，人工抽检其中 5 条能正常打开；再让它对每条 URL 打印 HTTP 状态码和选择器命中的节点数量，两样都对不上就退回重写，别急着跑全量。

坑二：大表格一粘贴就错位。

现象是把几千行的数据粘进对话框后，模型返回的表格行列对不上，或者某些列整体串位。原因是不支持附件上传的模型只能靠纯文本粘贴，粘贴过程会丢分隔符、丢表头，模型为了“对齐好看”还会主动脑补缺失值。解决方式是粘贴前先转成 CSV 或 TSV，第一行必须是完整表头，单批控制在 200 行以内分批处理，最后用代码而不是模型来做合并。

4.2 执行侧的两个坑

坑三：长文本一贴就“无法答复”。

现象是同一份任务，7000 token 的版本能出结果，15000 token 的版本直接空白，连报错都没有。原因是上下文长度限制叠加模型稳定性波动，长输入下的失败是静默的。解决方式是提前按章节切分，每片控制在 3000 到 4000 token，让模型逐片输出结构化中间结果，最后用脚本合并。分片时按语义边界切，不要按字符数硬切，否则跨片的表格会被切成两半。

坑四：表格维度悄悄少列。

现象是输出看着非常整齐漂亮，但你数一下列，要求的同比、环比两列不见了。原因是模型对“输出整洁”的偏好高于“信息完整”，它会主动裁掉那些它认为冗余或者自己没把握填的列。解决方式是把列名写成硬性约束清单，要求它逐列确认，缺失的列必须显式写“数据缺失”，不允许省略。这一条在文本集成任务上尤其关键，Claude 3.5 Sonnet 在一般文本上就漏掉了环比同比，而表格看起来毫无破绽。

4.3 结果侧的一个坑

坑五：可视化代码在本地跑不起来。

现象是模型给的绘图代码执行时报 KeyError、字体缺失导致中文全变方块、时间轴解析失败。原因是模型默认的运行环境和你本地不一致，它假设列名是date，你本地可能是日期。解决方式是先让它输出“依赖清单 + 列名假设 + 数据类型假设”三行说明，你逐行核对后再执行代码；绘图脚本开头统一加中文字体配置和列名映射字典，把环境差异收敛到一处。

注意：这五个坑的共同点是失败时都不报错。空文件、少一列、图变方块，全靠人工核验才能发现，所以验收动作必须固化成流程，不能靠当时的心情。

5. 协同打法：把四个模型串成四段接力

5.1 采集段：DeepSeek R1 定网，o3-mini 补漏

采集段最怕的是“网撒得不够宽”。测试里 DeepSeek R1 抓取完整准确但少量日期遗漏，o3-mini 速度快、链接提取全但采集结果为空。把两者组合起来用，思路是让 DeepSeek R1 当主采集器负责主要页面的抓取和筛选去重，o3-mini 当补充器专门处理 R1 漏掉的日期区间，因为它响应快，适合做小批量补抓。

具体做法是先用 R1 生成网址列表和主脚本，跑完后用日期做差集，算出哪些日期没有记录；把这些缺失日期单独作为一个小任务丢给 o3-mini，要求它只针对这些日期输出 URL 和抓取代码。补漏阶段的样本量小，o3-mini 的数据维度短板影响有限，而它的速度优势能放大。

5.2 预处理段：Claude 3.5 Sonnet 洗文本，DeepSeek R1 保完整

预处理要做的是清洗、格式转换、字段对齐。这一环我最看重“不漏指标”，恰好是 Claude 3.5 Sonnet 的强项——它在文件读取任务里没有漏任何数据指标，而且输出表格支持直接复制和下载，长文本场景下集成的维度甚至比短文本更全面。

但 Claude 3.5 Sonnet 在一般文本上会漏掉环比同比，所以我的分工是：Claude 负责把非结构化文本切成规整的字段表，DeepSeek R1 负责做一次完整性复核，专门检查“该有的列是不是都在”。复核不需要它重做全表，只需要它输出一份“应有列 vs 实有列”的差异清单，成本很低但能兜住最关键的一类错误。

5.3 分析与呈现段：Kimi 挖深度，o3-mini 出图

分析段的分工取决于你要的是“结论”还是“方向”。要明确结论，用 DeepSeek R1，它的长思维链能把推理过程摊开，异常检测也最敏锐；要挖掘方向和多维关联，用 Kimi k1.5，它在电影数据集那轮的多维度深入挖掘是四个模型里最好的。

呈现段则直接交给 o3-mini，它是唯一能直接出图的。但按第 3 章的分析，出图只用于探索和讨论，定稿图必须回到代码。所以实际流程是：o3-mini 先生成三四版草图确定图表类型和分组方式，Kimi k1.5 或 DeepSeek R1 再根据确定下来的方案输出可参数化的 Python 绘图脚本，本地重绘定稿。

5.4 一段可以直接抄的提示词骨架和校验脚本

流水线跑不跑得稳，很大程度上取决于提示词有没有把“验收标准”写进去。我常用的骨架是这样的：先声明输入的来源和规模，再逐条列出输出必须包含的字段名，然后明确“缺失字段必须显式标注为数据缺失，禁止省略”，最后要求先输出一份自检清单再输出正文。这四段缺一不可，尤其是自检清单那一步，它能逼模型在生成正文前先对一遍要求。

配套的校验脚本可以写得很短，但必须自动跑：

import csv REQUIRED = ["日期", "铁路客运量", "铁路同比", "铁路环比", "公路客运量", "公路同比", "公路环比", "民航客运量", "民航同比", "民航环比"] def check(path): """逐列核对必需字段，缺列直接打印，不做任何自动补全""" with open(path, encoding="utf-8-sig") as f: header = next(csv.reader(f)) missing = [c for c in REQUIRED if c not in header] if missing: print(f"[FAIL] 缺失列: {missing}") # 缺列是最常见的静默失败 else: print("[OK] 字段完整") return not missing if __name__ == "__main__": check("2025春运数据.csv")

REQUIRED列表就是你和模型之间的契约，改流程时先改这个列表，再改提示词。utf-8-sig是为了兼容 Excel 导出的 BOM 头，不加这行，第一列列名会带一个看不见的字符，导致校验永远报缺列——这个坑我踩过不止一次。

6. 最后一步：把验收固化成“三查”动作

如果只能从这组测试里带走一个动作，我建议是“三查”，每次模型交付后强制走一遍，五分钟内能做完，但能挡掉绝大多数静默失败。

第一查是查输入通道。确认这一步用的是附件上传还是粘贴，如果是粘贴，检查表头在不在、行数有没有超过 200、分隔符是不是被吞了。第二查是查字段完整性，直接跑上面那段校验脚本，不看表格长什么样，只看列名对不对得上契约。第三查是查可复现性，把模型给的代码在本地空环境里跑一次，确认它没有依赖你机器上某个碰巧装了的库。

这三查对应的正是测试里暴露出来的三类问题：o3-mini 的附件限制、Claude 3.5 Sonnet 的漏列、以及多个模型绘图代码在本地报错。它们都不是模型“能力不行”，而是流程里缺了一道检查。

回过头看，我最初也想过找一个“全能模型”一把梭，结果在长文本上被静默失败坑了整整两天——文件生成了，表头也在，就是数据行全空，而我直到写分析稿时才发现。从那以后我每次接入新模型、新数据源，都强制先跑一遍三查，不管它上一轮表现多好。模型会抽卡，流程不能抽卡。这套 DeepResearch 工作台真正的价值也不在于它内置了哪个模型，而在于它把采集、处理、分析、挖掘、可视化拆成了可替换的环节，你可以按环节换人，而不是被一个模型绑死。希望这份分工表能帮你在自己的科研流水线上少返工几次。

本文还有配套的精品资源，点击获取