3.8 如何选择 AI：按任务、成本与实际效果比较

选交通工具时，要先知道是日常通勤、搬家还是长途旅行。选择 AI 也应从任务出发：处理几十条短文本、修改多个关联文件、阅读长报告，对模型与工具的要求不同。

这一节提供可重复的比较方法，而不是固定的模型排名。模型型号、价格和额度变化较快；没有统一的测试材料与记录，也不宜把个人印象写成“全面评测”。

先分清模型、应用与开发工具

模型负责处理输入与生成输出；应用围绕模型提供文件、搜索、预览等能力；编码工具进一步连接项目与执行环境。相同模型放在不同工具里，体验可能明显不同，因为实际收到的资料、工具反馈和运行约束不同。

例如一个聊天窗口回答不了项目细节，可能是没有读取文件，而不一定是模型代码能力弱。一个智能体反复执行失败，也可能是环境配置或工具返回不清楚，不能全部归因于模型。

用任务描述代替“我要最强的”

场景	主要检查什么	可以使用的测试材料
编程	修改正确性、范围控制、已有约定	一个可复现错误和相关测试
资料研究	来源质量、引文对应和不确定性	一组存在不同观点的原始资料
写作与创意	中文自然度、受众与风格一致	自己认可的样稿与修改要求
日常办公	字段完整、计算准确和文件可用	一份脱敏表格或会议记录
日常对话	理解上下文、响应时间和表达	经常询问的实际问题
智能体执行	工具调用、失败恢复和完成判断	一项需要多步操作的小任务

先写清“合格”的标准。例如文章摘要可以要求保留主要结论、不新增事实、控制在指定长度；代码任务可以要求通过原有测试、补充目标用例、不引入无关依赖。

模型平台从哪里查

以下保留常见平台的官方入口，供核对可用模型、接口、计费和部署方式。它们不是能力排名，同一家平台的不同模型也不能一概而论。

模型或平台	官方资料	核对时关注
DeepSeek	开发文档	模型标识、工具调用与计费规则
通义 Qwen	官方模型项目、百炼	开放权重与托管服务的区别
豆包	火山引擎	所需文本、语音或视觉接口
智谱 GLM	开放平台	模型与工具客户端的适配
Kimi	开放平台	长文本、工具与账户额度
MiMo	开发者平台	当前可用模型及接口限制
MiniMax	开放平台	对应模态与套餐适用范围
Claude	开发文档	模型能力、输入限制和工具使用
Gemini	开发文档	支持模态、速率和上下文限制
Grok	xAI 开发文档	API 能力与数据工具的区分
OpenAI	模型文档	模型、接口与所需能力是否匹配

从平台官网能看到某项产品功能，不等于你使用的 API 或订阅也包含它。购买前把“网页能用”“接口可调用”“本地可部署”分别确认。

先用三个小任务筛选

不必第一次就比较十几个模型。选两三个能够正常接入的候选，使用同样的资料和要求。

任务一：修改一个已知错误

提供一个会在空列表时出错的函数，要求修复并保持正常输入行为。查看模型是否理解原有规则，是否只做必要修改，以及能否给出对应的边界检查。

任务二：根据资料回答问题

提供一份含日期与适用条件的规则，问一个资料中有答案的问题，再问一个资料中没有答案的问题。第二问尤其能观察它是否会用流畅文字补出不存在的规定。

任务三：执行一个小流程

让智能体读取几个文件、整理索引，再检查链接。任务应有固定输入和预期范围，便于核对是否漏文件、重复写入或提前宣布完成。

每项任务可以重复几次，并保留输入、版本和结果。一次成功可能有偶然性，一次失败也可能来自临时网络状态，需要分开记录。

记录结果时，不只看回答是否漂亮

维度	记录方式
任务正确性	是否满足预先写好的验收条件
信息完整性	有没有遗漏输入、条件或重要字段
改动范围	是否增加了无关文件、依赖或功能
可验证性	是否提供实际检查结果与来源
响应与总耗时	首次响应和整个任务完成时间分别记录
使用费用	汇总重试、工具调用与人工返工

写作任务可以由自己按样稿判断语气；编程任务则尽量使用实际运行结果。不能把“解释得自信”当成“实现正确”，也不宜让生成答案的同一个模型单独给自己判满分。

成本为什么要按完成任务计算

假设模型甲每次调用便宜，但需要多次重试和人工修复；模型乙单次贵一些，却能较稳定地完成任务。比较单次 Token 价格，可能得到与实际使用相反的结论。

可以采用下面的记录方式：

任务总成本 = 模型调用费用 + 工具或服务费用 + 人工检查与返工成本

人工时间不一定精确折算成金额，但至少记录“是否需要重新整理需求”“是否需要手工补写”。批量任务还要观察失败比例，不能只用最好的一次作代表。

降低成本也不只是换小模型。减少无关上下文、缩短不必要的输出、缓存稳定前缀、避免重复检索，都可能有效；具体缓存优惠与批量接口仍要查对应服务的说明。

长上下文与深度思考该怎样看

上下文窗口像可摊开的桌面，大桌子能放更多资料，但不保证每张纸都被认真使用。比较长文能力时，应检查关键条件是否被保留，尤其是相互矛盾或分散在不同位置的信息。

思考模式则可能增加内部计算与等待时间。它是否值得开启，取决于任务难度与实际改善。简单字段提取不一定需要长时间推导；复杂设计也不能只靠调高思考等级解决，仍需要清楚的资料与约束。

多模态任务要分别核对能力

读懂图片、生成图片、识别语音、合成语音和生成视频，是不同任务。一个模型能接收截图，不代表能生成可用图片；一个平台同时提供这些服务，也不代表只需一个接口。

知识库还可能需要向量模型，排序可能需要重排模型。这些组件与生成答案的语言模型可以来自不同提供方，但要检查数据格式、费用与访问要求。

例如更换向量模型后，原来建立的文档向量未必能够继续使用；文本生成模型的升级则不一定要求重建索引。先区分组件职责，再决定哪些部分需要一起调整。

本地部署与云端调用怎样比较

本地部署可以增加对运行环境和数据路径的控制，但需要考虑模型文件、内存或显存、推理速度、更新维护和并发能力。开放权重也不自动等于没有使用条件，应查看具体许可证。

云端调用减少了自己维护推理服务的工作，但依赖网络、账户与服务可用性。需要处理敏感资料时，应按项目要求核对数据处理方式，而不是只看模型是否知名。

对学习任务，先用能稳定完成练习的方式；对正式服务，再把负载、故障恢复与长期成本纳入比较。

什么时候值得组合多个模型

当任务可以明确拆分时，组合才容易管理。例如固定格式提取与复杂异常分析可以分别处理；常规请求走成本较低的模型，无法通过校验的请求再交给另一个候选。

先有可检测的升级条件，再引入切换：字段验证失败、问题涉及跨文档冲突、或达到预设的重试阈值。不要让系统仅凭“我觉得难”无限调用更贵模型。

多模型结果不一致时，也需要决定怎样核实。两个答案相同并不等于正确，仍应回到资料和验收标准。

保留一份自己的选择记录

可以在项目文档中记录主用模型、备用模型、适用任务、验证日期与已知限制。出现新模型时，先跑原来的小测试，再决定是否替换。

例如：“当前模型已通过笔记整理与文件索引测试；复杂表格尚未验证；备用模型只在接口不可用时切换。”这比“某模型永远最好”更容易维护，也更便于协作者理解。

六类常见场景分别看什么

同一个模型很难在所有工作中都给出相同体验。可以按下面的重点准备测试，而不是拿一道题代替全部需求。

场景	主要观察	容易忽略的条件
编程	能否理解仓库、正确编辑并通过检查	工具权限、依赖环境、项目规则
资料研究	是否找到可靠来源并区分事实与推断	资料日期、引用位置、网页访问能力
内容创作	是否符合受众、语气与事实边界	版权、品牌规范、反复修改成本
日常办公	文件格式和排版是否可直接使用	表格公式、字体、导出兼容性
客服与对话	多轮状态是否一致，是否知道何时转人工	隐私、拒答边界、业务口径
Agent 任务	工具选择、失败恢复和停止条件	审批、幂等、日志与费用

例如，评估编程模型时，可以让候选模型在同一份小仓库中修复三个真实问题，而不是只让它从零生成贪吃蛇。真实问题会暴露搜索文件、遵守约束和处理已有代码的能力，这些更接近日常开发。

为团队选择时，再增加四项约束

个人试用主要看效果与费用，团队使用还要考虑管理问题。

数据范围

先列出允许发送的内容：公开代码、内部代码、客户数据、日志和生产配置可能对应不同要求。平台是否支持关闭训练使用、设置保留期限或指定数据区域，应根据组织政策核对，而不是凭产品名称推断。

账号与权限

团队需要统一的成员管理、离职回收、用量限制和审计记录。若只能共享一个密钥，不仅难以追踪费用，也会让撤销权限变得困难。

稳定性与支持

记录限流规则、服务状态页、错误码和支持渠道。对关键任务，应准备明确的降级结果，例如暂停异步任务或转人工处理，而不只是自动换模型继续执行。

迁移成本

提示词、工具 Schema、知识库索引和评估集都是迁移资产。尽量让业务代码依赖自己的接口层，并保留少量跨供应方测试；但不要为了未来可能发生的切换，过早设计一套过度复杂的抽象。

建立一张可复用的评分表

评分不必复杂，但每一项要能由结果支撑。以下是一个适合小团队的示例：

维度	权重示例	记录方式
任务正确率	35%	固定任务中通过验收的比例
人工返工	20%	每个任务需要补改的时间
稳定性	15%	超时、限流与格式错误次数
响应时间	10%	首次响应与完整任务耗时
成本	10%	完成一个合格任务的平均费用
数据与管理	10%	是否满足权限、审计和合规要求

权重应由场景决定。实时客服会更在意延迟，复杂代码迁移会更在意正确率和返工，内部资料处理可能首先看数据边界。评分表用于帮助讨论，不应把无法比较的差异强行压成一个数字。

什么时候应该重新评估

出现以下变化时，可以用原来的任务集重新跑一次：主模型升级或停用；价格与限额明显变化；项目技术栈改变；开始处理新的数据类型；工具调用或长上下文成为主要需求；线上失败类型与最初评估不一致。

重新评估时保留旧结果和日期，才能判断是模型真的改善，还是测试条件发生了变化。先用少量流量试运行，再逐步替换，也比一次性切换更容易控制风险。

读完本章后，应能在一个项目中完成环境准备、模型接入、规则说明与一次可验证的小任务。后续实战会继续沿用这套流程。