只给模型一道题，很难判断它到底是碰巧答对，还是在某一类任务上真的稳定。
这次我通过 Claude Code 调用 Seed 2.1 Pro。Claude Code 在这里相当于模型的工作台，可以让它读取文件、执行命令并写出代码。我准备了 10 个真实任务，再把结果拆成 22 个可以单独判断的能力点，覆盖看图、结构化提取、多源分析、长上下文、Agent、网页生成和跨文件开发。这里的 Agent，指模型会主动读取多份材料、调用工具并交回产物，而不只是回答一段文字。
每个任务都要留下实际文件。网页要放进真实浏览器看，代码要跑模型没有见过的外部测试，数据任务则要重新核对行数、金额和排除项。这样测下来，我更关心的不是一个总分，而是：哪些任务可以直接推荐，哪些适合让模型先完成主体，哪些需要先调整输入方式。
先说结论。Seed 2.1 Pro 最突出的强项，是从多份材料里识别冲突、判断当前有效版本，把截图、日志和指标串成故障链，以及完成边界明确的跨文件工程改造。费用台账、截图写网页和小型代码修复也能很快做出第一版，但交付前最好再做一次外部验收。超高分辨率、文字密集的整张大图，则更适合先缩放和切片。
这次怎么测：10 个任务，拆成 22 项能力
十个任务包括 USGS 地震预警流程图、11400×7800 水循环图、费用台账、经营数据判断、合同制度核对、20 份文件的版本追踪、生产事故分析、后台页面还原、小型代码修复，以及带取消状态的跨文件功能开发。
单场景预算上限设在 1.2 美元左右。我按最终产物验收：该生成的文件有没有落盘，页面放进浏览器后是否正常，代码能否通过模型没有见过的外部测试。
按最终用途归类，22 项里有 16 项可以直接推荐，5 项适合先出首版再验收，1 项应先处理输入。详细结果如下：
| 编号 | 能力点 | 实测表现 | 使用建议 |
|---|---|---|---|
| 1 | 流程节点识别 | 准确识别检测、分发和保护 | 直接推荐 |
| 2 | 角色与信息流关系 | 能说清传感器、USGS、分发方和公众之间的关系 | 直接推荐 |
| 3 | 图片事实边界 | 没把地震检测写成地震预测，也没有自行补数字 | 直接推荐 |
| 4 | 超高分辨率整图 | 生成了完整分析 JSON，但在补交说明文件前达到预算上限 | 先缩放、切片降成本 |
| 5 | 表格逐行转录 | 12 行记录完整落入结构化文件 | 直接推荐 |
| 6 | 状态过滤与发票去重 | 正确过滤待审核、已驳回记录，并识别重复发票 | 直接推荐 |
| 7 | 负数退款与净额计算 | 8 笔、6316.39 元计算正确 | 直接推荐 |
| 8 | 审计清单完整性 | 总额正确，但排除清单漏列 E112 | 首版后抽查 |
| 9 | 多源冲突识别 | 没有照抄错误备忘录 | 直接推荐 |
| 10 | 经营数据复算 | 正确算出流量、订单和转化率变化 | 直接推荐 |
| 11 | 因果边界控制 | 把支付故障保留为待验证方向 | 直接推荐 |
| 12 | 合同与制度冲突 | 7 个预埋冲突全部找到 | 直接推荐做初筛 |
| 13 | 高风险结论克制 | 没有代替法务下最终结论 | 直接推荐做初筛 |
| 14 | 长上下文信息检索 | 能从 20 份材料中找到控制文件 | 直接推荐 |
| 15 | 版本有效性判断 | 排除更新但未审批的 CR-019，采用 CR-018 | 直接推荐 |
| 16 | 多模态故障证据串联 | 能联合截图、日志、CSV 和发布记录 | 直接推荐 |
| 17 | 根因假设与未知项 | 给出最可能原因，同时保留未解释数据 | 直接推荐 |
| 18 | 截图还原网页 | 桌面页面结构和主要视觉基本对应 | 适合快速首版 |
| 19 | 窄屏响应式适配 | 无横向滚动，但最右导航仍被裁切 | 需要浏览器验收 |
| 20 | 常见代码缺陷修复 | 越权、负库存、共享默认值等问题修复有效 | 适合第一轮修复 |
| 21 | 隐藏兼容条件 | 外部测试暴露 Decimal 和零会话边界 | 需要独立回归 |
| 22 | 跨文件状态机开发 | 可见测试 20/20，语义隐藏测试 8/8 | 直接推荐 |
测试 1---4：视觉理解（VLM）能不能真正读懂图，而不是只复述标题
第一张图选的是 USGS 公开的 ShakeAlert 地震预警流程图。这个任务表面上是看图，真正考的是三个问题：能否找齐节点，能否还原信息流向，能否守住"检测已经发生的地震"和"提前预测地震"的区别。
下图左侧是实际输入，右侧是 Seed 2.1 Pro 生成的 analysis.json。
它给出的顺序是 DETECT AND PROCESS → DELIVER → PROTECT。传感器先检测已经开始的地面运动，信息进入处理中心，再由 USGS 形成消息并交给合作方分发。人员收到提醒后执行 DROP-COVER-HOLD ON，基础设施可以执行列车减速、关闭水阀等动作。
更重要的是，它没有把预警写成预测。图片没有提供覆盖地区、准确率和固定提前秒数，它也没有擅自补齐。从这份输出看，Seed 2.1 Pro 处理结构清楚、关系明确的信息图时，已经不只是识别文字，而是在还原角色和动作关系。
接着我换成 USGS 全球水循环图。原图为 11400×7800，标签更多，跨区域箭头也更密集。模型在处理中生成了 6 张重叠切片和多张局部放大图。大约运行 10 分钟、费用接近 1.3 美元时，命令因为预算上限停止。
不过，停止不等于没有产物。输出目录里已经生成一份 19929 字节、可以正常解析的 analysis.json，包含 14 类水的储存位置、15 种自然流动过程、8 类人类活动、3 条完整路径，以及 14 个不确定项。原任务要求的 notes.md 没有来得及生成，因此这项属于"主体分析完成，交付还差说明文件"。
这次暴露的是效率问题。实际使用时，可以先把整图缩小，让模型判断全局结构；再按区域做带重叠的切片；最后合并跨区域关系。Seed 2.1 Pro 能处理这类密集科学图，但没必要让它从 11400×7800 原图开始探索，预处理后更省时间和费用。
测试 5---8：结构化提取，算对结果还不够
费用台账共有 12 行，混入两条待审核、一条已驳回、一条重复发票和一笔负数退款。规则要求只统计已批准记录；同一发票号保留较早一行；退款必须保持负数。
下图左侧是实际输入，右侧是本轮 audit.json 原始输出。
Seed 2.1 Pro 完整转录了 12 行，识别出重复发票 INV-A02，留下 8 笔有效记录，净额为 6316.39 元。负数退款也正确进入计算。逐行转录、状态过滤、去重和金额计算这四步，它完成了前三项半。
剩下的半项出现在审计清单。模型计算时确实排除了 E112，所以最终金额没有错；但 excluded_rows 只列出 E103、E105 和 E108，漏掉了同样处于待审核状态的 E112。
如果任务只是快速整理一份普通台账，这个结果已经很有用。如果要把产物交给财务或审计，验收时还要把"输入总行数＝纳入行＋排除行"单独做一次核对。Seed 2.1 Pro 适合承担提取和计算主体，审计闭环最好再加一道程序校验。
测试 9---11：多份材料互相打架时，它会不会照抄现成结论
经营分析任务里有订单 CSV、趋势图、客服记录和一份团队备忘录。备忘录已经替读者写好了结论："过去六周流量下降约 15%，建议广告预算增加 30%。"
原始数据却显示，会话从 10000 增长到 12000，上涨 20%；订单从 500 降到 420，下跌 16%；转化率从 5.0% 降到 3.5%；结账失败工单从 10 增加到 95。
Seed 2.1 Pro 没有因为备忘录像一份正式文件就直接采纳。它建议暂缓增加广告预算，优先检查结账和支付环节。按照第一周 5% 的转化率估算，第六周理论上约有 600 单，实际少了约 180 单。
单纯的除法不是这里的重点。更有用的是，它能把"材料里写好的结论"和"原始数据支持的结论"拆开。同时，它没有直接宣布支付故障就是唯一根因，而是要求继续查看错误码、转化漏斗和发布记录。
这类多源分析任务很适合 Seed 2.1 Pro。给材料时可以明确要求它分别列出事实、材料冲突、当前判断和还缺什么，结果通常比一句"帮我总结"更有价值。
测试 12---15：规则很多时，重点不是记住，而是判断哪一份生效
合同核对场景使用一份虚构合同和内部制度，预埋账期、自动续约、数据保留、管辖地、责任上限、分包商和训练数据 7 处冲突。Seed 2.1 Pro 找齐了 7 处，并保留条款位置、制度要求和建议动作。
它没有把这些冲突直接写成"合同无效"，而是区分谈判项、审批项和需要法务确认的部分。用在合同第一轮筛查很合适：先把散落的冲突找齐，再让真正负责的人处理高风险判断。
长上下文任务更复杂。我准备了 20 份虚构材料，包括旧手册、会议纪要、群聊转述、已撤回变更、未审批草案、正式通知和批准矩阵。里面最容易误导模型的是 CR-019：日期更新，却没有批准人和生效日期。
Seed 2.1 Pro 最终选择已批准的 CR-018，得出 A 座 2F---4F、B 座暂停、9 月 25 日 22:30---23:45、35% 电量返航，并为关键结论保留来源文件名。
它还排除了已撤回的 CR-015、无编号群聊和供应商建议，并把尚未确定的 9 月 26 日消防演练停飞问题放进待确认项。
这类结果体现了 Seed 2.1 Pro 的一个明显强项：它不只按日期找"最新文件"，还能结合批准状态、生效日期、替代关系和撤回记录判断当前规则。面对制度库、项目资料和长会议链路，这比单纯摘要更实用。
测试 16---17：VLM 和 Agent 组合后，能不能从异常走到根因
故障分析任务同时提供监控截图、消费者日志、按时间采样的指标 CSV 和当天发布记录。监控图显示 API 成功率 99.8%，但处理消息的 worker 为 0/6、队列积压 18420；日志显示第三版消息字段规范（schema v3）缺少地区字段 region；发布记录显示新消费者刚开启严格校验，而旧生产者仍可能漏字段。
下图左侧是实际监控图，右侧是 Seed 2.1 Pro 输出的事故分析 JSON。
模型把这些信息串成一条可检查的路径：缺字段消息触发严格校验，worker 反复退出；生产者仍在写入，于是队列继续积压。它同时注意到两个没有完全解释的问题：0 个活跃 worker 时死信队列为什么仍在增长，以及生产速率能否完全解释积压曲线。
所以它把 schema 不兼容写成"最可能原因"，没有写成已经证实的唯一根因，也没有在没有恢复记录时声称故障已经解决。
如果日常工作经常要对着截图、日志、监控指标和发布记录排查问题，这一组是我最愿意推荐的方向之一。单独一张截图只能告诉我们哪里异常，多种材料一起交给模型，才有机会形成能继续验证的排查路线。
测试 18---19：截图写网页，桌面端像了还不算结束
网页任务只提供一张 1440×900 的后台工作台截图，要求生成离线可打开的 HTML 和 CSS，并适配窄屏。
第一次运行经过 21 个工具轮次后达到 1.2 美元左右的预算上限，没有生成文件。我复用同一会话，只允许一次续跑并要求直接落盘，随后得到 index.html、style.css 和 notes.md。
下图左侧是参考截图，右侧是生成页面在 1440×900 浏览器中的实际画面。
侧栏、三张数据卡、折线图和任务列表基本对应，页面也不需要联网加载外部页面资源。就"快速生成一个可继续开发的前端首版"而言，这个结果是合格的。
把视口切到 390×844 后，浏览器测得页面宽度与可见区域同为 390，没有出现整页横向滚动；但截图最右侧的"设置"仍被裁掉一部分。
因此，截图写网页可以先让 Seed 2.1 Pro 搭出骨架，但响应式不能只检查一个数值。准备正式使用前，桌面、平板和手机视口可以各看一次，导航、弹窗和关键按钮也实际点一遍。
测试 20---22：Coding 的差别，不在项目大小，而在边界是否写清楚
小型代码项目包含权限、库存、审计、报表和定价模块。Seed 2.1 Pro 修掉了 admin 子串越权、负库存、默认列表共享等明显问题。项目自带的 3 个测试全部通过，外部 8 个测试通过 5 个。
没有通过的三个边界里，两个与 Decimal 精确金额类型有关。新增的类型判断只接受 int 和 float，反而拒绝了原本应该兼容的 Decimal。另一个是零会话报表：模型先判断订单数不能超过会话数并抛错，但约定要求会话为零时直接返回 0.0。
这个结果并不妨碍它承担第一轮修复。明显缺陷修得很快，准备合并时再补旧调用方、精确数值类型和异常输入的回归测试即可。
较大的工程任务反而更稳。需求是给包含 API、service、runner、store 和同步接口的项目增加"可取消批处理"：运行前可取消、运行中按 item 停止、重复取消幂等、终态不回退、任务之间不能互相污染，服务重建后还要共享取消状态。
Seed 2.1 Pro 修改了 cancellation.py、runner.py、service.py 和 api.py，并补充取消测试。模型可见测试达到 20/20。第一版外部测试为 6/8，但其中两项强制了需求没有规定的参数名和布尔返回值。我保留首次记录，再把外部测试改为只验证共享取消记录、终态不变和取消信号等已约定语义，最终 8/8 通过。
大项目表现更好，不是因为代码越多越容易，而是 queued、running、cancelled、succeeded、failed 的转换条件写得足够明确。把需求写成状态机、约束和不变量之后，Seed 2.1 Pro 的跨文件实现能力很值得用。
成本怎么看：最烧预算的不一定是代码
效果之外，调用成本也会直接影响这些任务能不能长期使用。
十个正式任务记录到的调用费用合计约 7 美元 ，各任务墙钟时间累计约 50 分钟。部分任务并行运行，所以这个累计时间不能当成完整测试的实际等待时间。网页续跑的费用日志没有保存下来，也没有硬算进总数。
单项任务之间的差距也比较明显。简单的文本核对和经营判断大约需要 0.3～0.5 美元，长上下文和较大的工程任务大约在 0.7～1 美元。最接近 1.2 美元预算上限的，反而是超大图片和网页首次生成。
材料多不一定最贵。只要目标文件和判断规则清楚，长上下文和跨文件开发依然可以稳定交付。视觉任务则不能按"只有一张图"估算成本，分辨率、文字密度和关系复杂度都会放大分析量。
作为实践者，我最推荐 Seed 2.1 Pro 的四个方向
如果让我根据这 22 项结果来选，我会优先把 Seed 2.1 Pro 放在下面四类任务里。
第一，多源材料判断。 它能发现正式备忘录与原始数据冲突，并把事实、推断和待确认项分开。经营分析、调研归纳、事故复盘都适合。
第二，长上下文里的有效版本追踪。 它会看批准人、生效日期、撤回记录和替代关系，而不是机械选择日期最新的文件。制度库、需求变更和项目资料整理尤其受用。
第三，VLM＋Agent 故障分析。 当截图、日志、指标和发布记录必须一起看时，它能给出有证据顺序的排查假设，也愿意保留还没有解释的数据。
第四，边界明确的跨文件开发。 需求能写成状态机和不变量时，它不仅能改多个模块，还能主动补测试。相比一句"帮我加个取消功能"，把允许转换、禁止回退和共享状态写清楚，结果会稳定很多。
费用台账、截图还原网页和小型修复也值得用，只是更适合作为"模型完成主体，人来做最后验收"的任务。超大密集图片则先调整输入，不必用一次整图调用硬扛。
真正把自己的任务交给它之前，我会先做三项准备：列清输入文件和必须交回的产物；准备一项模型事先看不到的检查，例如另一种屏幕宽度或一组兼容性测试；遇到超大图片时，先做全图缩略版和带重叠的局部切片。
只要模型已经交回约定文件，外部检查也通过，任务就可以进入下一步。工具轮次不断增加却迟迟不落文件，或费用已经接近上限时，先让它保存中间索引、页面骨架或已修改模块，再决定是否续跑，通常比一直等完整答案更稳。
测到这里，Seed 2.1 Pro 适合放在哪些环节已经比较清楚：材料可以很多，代码也可以跨文件，但目标、关系和验收条件要说清。输入形态处理好，再接上浏览器检查、程序校验和外部测试，它就能把任务从"需要从头做"推到"可以验收和继续完善"。
我再用豆包 Work 试试，它到底能不能真帮到我
前面做了十个任务、拆了 22 项能力，但我最后还是想回到一个最简单的问题：Seed 2.1 Pro 到底能不能在真实工作里帮我省时间？如果只是测试分数好看，最后资料还得我自己从头整理，那对我来说意义也不大。
所以这次我直接打开豆包 Work，选择 Seed 2.1 Pro，把两组比较杂的资料交给它。我没有设计特别复杂的评分标准，只看它能不能帮我读完材料、理清冲突，并交回可以继续使用的 Word 和 Excel 文件。
第一组：我把六份项目资料全部交给它
这组材料包括项目章程、需求基线 v2.3、已经批准的 CR-018、还没批准的 CR-019 草案、会议与群聊记录，以及审批矩阵和风险台账。
如果我自己处理，需要先判断每份文件是什么状态，再核对谁批准了、哪一份已经生效、群聊里的说法能不能算数，最后还要重新整理计划和问题清单。这类工作不算特别难，但很碎，也很花时间。
我把资料一次性交给豆包 Work，让它帮我生成当前有效计划、变更追踪表和待确认问题清单。
结果比我预想得更实用。它没有因为 CR-019 日期更新就直接采用，而是认定当前应执行已经批准的 v2.3＋CR-018。华东首发、10 月 8 日上线、华南和数据导出延期、附件上限 10MB，这些信息都被整理进了当前计划。
群聊里虽然有人说"先按 10 月 3 日双区域上线准备"，模型也没有把这句话当成正式决定。CR-019 中那些还没批准的建议，被单独放在草案区域里。
它还顺手把华南迁移只完成 62%、压测只有 420/500、审计日志只有 180/365 天等问题整理了出来。以前我要在几份文件之间来回翻，现在直接看它生成的计划和表格，就能知道当前要执行什么、还缺什么。
对我来说，这已经帮了很大的忙。我不需要再从第一份材料开始重新做一遍，只需要看看最终结论和文件是不是我想要的即可。
第二组：我又拿事故资料试了一次
第二组资料更杂，有监控截图、消费者日志、分钟级指标、发布记录，还有客服和值班记录。监控页面显示 API 成功率仍有 99.8%，但稳定 worker 已经变成 0/6，队列积压达到 18,420。
我让豆包 Work 帮我整理一份事故复盘。最后它交回了复盘报告、事故时间线、整改任务跟踪表和一页管理层摘要，四个文件都能直接打开。
这里最让我满意的是，它没有被 99.8% 的成功率带偏。它发现这个数字只代表请求成功进入队列，并不代表后台已经处理完成。结合日志和发布记录，它把问题指向了严格字段校验、退款事件缺少 tenant_id、worker 反复重启和积压持续增加这一整条链路。
它也没有强行说自己已经找到了唯一根因。DLQ 为什么在 0 个稳定 worker 时仍然增长、积压数量为什么和入口流量对不上，都被留在待确认项里。时间线还把原始事实和后续推断分开，我阅读时会轻松很多。
它生成的整改表里有 13 项任务，从立即止血、抽样消息、核对指标，到恢复验证、资金对账和后续发布门禁，已经把我接下来可能要处理的事情整理成了一张表。
结果也不是完全没有偏差。管理层摘要里有一句"无人处理"，表达得稍微满了一点；复盘报告还有一处表格分页不够好看。但这些问题并不影响我理解事故经过，也不影响我继续使用它给出的时间线和整改清单。
我这里说"不用复查"，并不是闭着眼把所有内容直接发出去，而是不用再把全部原材料从头做一遍。只要快速看看关键结论和最终文件是否符合需求，就已经比我自己逐份检查省下很多时间。
最后总结：这次 Seed 2.1 Pro 测评就到这里
从看图、整理表格、长上下文判断、故障分析、网页生成，到最后用豆包 Work 完成项目收口和事故复盘，这次测试基本覆盖了我平时可能遇到的几类任务。
还需要说明的是，本次部分任务是在固定预算内完成的，单个正式场景的预算上限大约是 1.2 美元。命令因为达到预算而停止，只能说明它没有在这次限定成本内完成，并不等于模型完全做不了。
例如超高分辨率水循环图达到预算上限时，主体分析文件其实已经生成，只是还缺最后的说明文件；网页任务第一次也因预算停止，复用原会话并让它优先落盘后，最终还是生成了可以打开的页面。如果提高预算、允许继续运行，或者提前缩小图片、拆分任务，结果还可能继续改善。
我把超出预算也当成测评的一部分。实际使用 AI 不可能完全不看成本，我除了想知道它能不能做，还想知道在给定时间和费用内能做到哪一步、会留下什么中间产物，以及是否值得继续投入。因此，文章里的"未完成"更准确地说是"没有在当前预算内完整交付"，不能直接理解成能力失败。
Seed 2.1 Pro 不是每一次都能给出百分之百完美的结果。有些细节会遗漏，有些表达会稍微偏一点，生成的 Word 和网页也可能需要简单调整。但从我的使用感受看，它已经能够替我完成大量资料阅读、冲突整理和初稿制作，把原本需要从头处理的工作推到"看看结果就能继续用"的阶段。
整篇测评都是根据我个人的使用经验和理解完成的，不代表所有任务、所有提示词和所有环境都会得到完全一样的结果。如果你对其中某个结论有疑问，也可以拿自己的资料再实验一遍。
就我这次的结果而言，我很推荐 Seed 2.1 Pro。它不一定替你完成最后的决定，但确实能帮你少翻很多资料、少做很多重复整理，也能明显缩短从拿到材料到得到可用结果的时间。对我来说，这就已经很不错了。