1. 从"模型/应用"双维度切入：为什么这个分类框架比单纯罗列模型更有用大多数人整理大模型资料时，习惯按厂商或者按发布时间拉一张长表，结果就是"知道有哪些模型，但不知道什么场景该用哪个"。我最初也这么干过，后来发现这张表越拉越长，真正要用的时候反而找不到东西。问题出在分类维度上——按厂商分，你记住的是品牌；按时间分，你记住的是新闻。这两种分法都不指向"我该选谁"这个真实问题。"模型/应用"双维度这个框架的价值在于，它把"底层能力"和"落地形态"拆开了。模型维度回答的是"这个模型本身能干什么、擅长什么、边界在哪"；应用维度回答的是"它被包装成了什么产品、面向谁、解决什么具体任务"。同一个底层模型，可能对应好几个应用形态；同一个应用，背后也可能切换过不同的模型。把这两层分开看，选型时就不会被"某某模型又更新了"这种消息牵着走。这篇内容适合三类人：一是刚接触大模型、面对一堆名字发懵的入门者；二是需要给团队做技术选型、但不想逐个试错的开发者；三是想搞清楚"某个应用到底靠不靠谱"的产品或运营角色。我会按模型维度和应用维度分别展开，中间穿插我自己踩过的坑和判断标准，尽量让每个结论都能落到"你该怎么用"上。需要先说明一点：大模型领域变化极快，任何一份清单都有时效性。所以比起记住具体名字，更重要的是掌握一套判断框架——知道从哪几个角度去评估一个模型或应用，这样即使名单更新了，你也能自己判断。2. 模型维度：拆解一个模型该看哪几个硬指标2.1 参数规模不是越大越好，关键看"有效容量"很多人一上来就问"这个模型多少参数"，好像参数越大越强。实际用下来，参数规模只说明了一部分问题。参数可以理解为模型的"脑容量上限"，但脑容量大不等于会做题——训练数据质量、训练方法、对齐策略都会极大影响最终表现。我自己的经验是：参数量主要影响的是"知识密度"和"推理深度"。小参数模型（比如几B到十几B级别）在常识问答、简单分类、格式转换这类任务上完全够用，而且推理成本低、响应快。大参数模型（几百B以上）在复杂推理、长链条逻辑、多步计算上优势明显，但代价是部署成本高、延迟大。所以选型时不要问"哪个参数最大"，而要问"我的任务需要多深的推理"。如果只是做文本摘要、情感分类，硬上超大模型就是浪费。反过来，如果要做多步数学推理或者复杂代码生成，小模型经常会在中间步骤掉链子。2.2 上下文窗口：决定"能一次喂多少料"上下文窗口这个指标，直接决定了你能把多长的材料一次性交给模型处理。早期模型只有几千token，现在主流模型动辄几十万token。这个数字看着很爽，但实际用起来有几个坑。第一，窗口大不等于"记得住"。很多模型在超长上下文里会出现"中间遗忘"——开头和结尾的信息记得清楚，中间部分容易丢。我实测过一些标称超长窗口的模型，喂进去几万字文档后问中间细节，回答质量明显下降。所以如果你的任务是长文档问答，不能只看窗口大小，还要实测它的"有效记忆范围"。第二，窗口大意味着成本高。token是按量计费的，一次喂十万token和一次喂一千token，成本差两个数量级。我的做法是：先用检索或摘要把材料压缩到最相关的部分，再喂给模型，而不是无脑全塞进去。第三，窗口大小和推理速度是矛盾的。窗口越长，模型处理越慢。如果做实时交互应用，长窗口反而会拖累体验。2.3 推理能力与知识边界：分清"会推理"和"知道得多"这两个能力经常被混为一谈。一个模型可能知识面很广（训练数据覆盖多），但推理能力一般；也可能推理很强，但知识更新不及时。选型时要分开评估。判断推理能力，我常用几个测试：多步数学题、逻辑谜题、代码调试。这些任务光靠记忆答不出来，必须一步步推。判断知识边界，就问它训练截止时间之后的事情，看它是老实说"不知道"还是硬编。后者更危险，因为会误导人。这里有个实用技巧：不要只测一个模型，拿同一组题去测几个候选模型，横向对比。单个模型的绝对表现说明不了太多，相对差异才是选型依据。2.4 开源与闭源：不是信仰问题，是成本和控制权问题开源模型和闭源模型的争论很多，但落到实际选型上，核心就两点：成本和控制权。闭源模型通常效果更稳、维护省心，但按调用量付费，长期用下来成本可能很高，而且数据要经过对方服务器，有些场景不方便。开源模型可以自己部署，数据不出内网，长期成本可控，但需要自己有运维能力，效果也可能略逊一筹。我的判断标准是：如果任务敏感、调用量大、团队有工程能力，优先考虑开源自部署；如果任务通用、调用量小、想快速上线，闭源API更省事。两者也可以混用——核心敏感任务走自部署，边缘任务走API。3. 应用维度：同一个模型，为什么做出来的产品差别巨大3.1 应用层拼的不是模型，是"任务编排"底层模型能力趋同之后，应用之间的差距主要来自任务编排。所谓任务编排，就是把一个复杂需求拆成多步，每步调用模型或工具，再把结果串起来。举个例子，同样是"帮我分析这份财报"，有的应用直接把全文丢给模型让它总结，结果又泛又浅；有的应用会先抽取关键财务指标，再让模型做同比分析，最后生成结论。后者效果明显更好，但工程复杂度高得多。所以评估一个应用时，不要只看它"用了什么模型"，要看它怎么拆任务、怎么调工具、怎么处理中间结果。这些才是护城河。3.2 检索增强：让模型"查资料"而不是"背答案"检索增强（RAG）是目前应用层最常用的技术之一。原理不复杂：用户提问后，系统先去知识库里检索相关片段，再把片段和问题一起交给模型生成回答。这样模型不用把知识全背在参数里，而是"现查现用"。这个方案的好处是知识可更新、可溯源。坏处是检索质量直接决定回答质量——检索错了，模型再强也白搭。我踩过的坑是：早期只做关键词检索，结果同义词、近义表达经常漏检。后来加了向量检索做语义匹配，召回率明显提升。实操建议：检索环节要做"混合检索"——关键词和向量各跑一遍，再合并去重。另外，检索回来的片段要排序和截断，不能全塞给模型，否则又回到长上下文的老问题。3.3 智能体形态：从"问答"到"干活"的跨越智能体（Agent）是应用层的一个明显趋势：不再只是回答问题，而是能调用工具、执行多步任务。比如自动查资料、写代码、跑测试、生成报告。这个形态的难点在于"可靠性"。单步问答错了，用户能看出来；多步任务中间错一步，后面全崩。所以智能体应用的关键不是模型多强，而是有没有"检查点"和"回退机制"——每步做完验证一下，不对就重来或换路径。我实测下来，目前智能体在边界清晰、步骤固定的任务上表现不错（比如按模板生成报表），在开放式任务上还容易跑偏。选型时要看你的任务是不是足够结构化。3.4 垂直应用 vs 通用助手：场景越窄，往往越好用通用助手什么都能聊，但什么都不精。垂直应用只做一件事，但做得深。比如专门做合同审查的、专门做代码补全的、专门做客服的。我的经验是：如果你的需求明确且重复，优先找垂直应用，因为它的提示词、检索库、输出格式都是为这个场景调过的，开箱即用效果好。如果需求杂、变化多，通用助手更灵活。判断一个垂直应用靠不靠谱，看它有没有"领域知识库"和"输出规范"。只有领域知识库，说明它真的在这个场景下积累过；有输出规范，说明它考虑过落地时的格式要求。4. 选型实操：把需求和能力对上号的四步法4.1 第一步：把需求翻译成"任务类型"很多人选型失败，是因为需求描述太模糊，比如"我要一个聪明的模型"。这种描述没法选。要把它翻译成具体任务类型：是文本生成、信息抽取、分类、推理、还是多轮对话？不同任务类型对模型的要求完全不同。分类任务看重准确率和速度，推理任务看重逻辑链条，生成任务看重流畅度和风格控制。先把任务类型定下来，候选范围立刻缩小。4.2 第二步：列出硬约束，先做减法硬约束包括：预算上限、延迟要求、数据合规要求、部署环境。这些是"一票否决"项，不满足的直接排除，不用纠结效果。比如预算只够调用小模型，那就别去看超大模型的效果对比，看了也白看。延迟要求100毫秒以内，那长窗口模型基本出局。先把硬约束列清楚，能省掉大量无效对比。4.3 第三步：小样本实测，别信榜单公开榜单只能做参考，不能做决策依据。因为榜单的测试集和你的真实数据分布往往不一样。我的做法是：从自己的业务数据里抽50到100条，做成小测试集，让候选模型都跑一遍，人工评估结果。这个测试集不用大，但要覆盖你的典型场景和边界情况。跑完之后，你会得到一份"在自己数据上的真实表现"，这比任何榜单都可靠。4.4 第四步：算总账，不只看单价选型最后要算总账：不只是API单价，还包括工程改造、运维、人工审核、错误修复的成本。有些模型单价便宜，但输出格式不稳定，需要大量后处理，综合成本反而高。我一般会做一个简单的成本模型：单次调用成本 × 预估调用量 + 工程投入 + 人工兜底成本。把这几项加起来对比，结论往往和只看单价时不一样。5. 那些年我踩过的坑：选型和使用中的真实教训5.1 坑一：盲目追新，忽略稳定性新模型发布时效果演示都很惊艳，但实际用起来可能不稳定——同样的输入，不同时间输出质量波动大。我早期追过几个新模型，上线后用户反馈"时好时坏"，排查半天发现是模型服务本身在调整。教训是：生产环境优先选稳定版本，新模型先在小流量上灰度，观察一段时间再放量。别拿线上业务当试验田。5.2 坑二：提示词写得太随意很多人觉得提示词随便写写就行，反正模型聪明。实际恰恰相反——提示词的质量对输出影响极大。同样的模型，提示词写得好和写得差，效果能差一个档次。我的提示词模板一般包含：角色设定、任务描述、输出格式、约束条件、示例。尤其是输出格式和示例，能大幅提升稳定性。如果要做结构化输出，一定要在提示词里明确字段和格式，最好给一两个例子。5.3 坑三：不做输出校验，直接信模型模型会"一本正经地胡说"，这在需要准确性的场景里是致命的。我见过直接把模型生成的财务数据用进报表的，结果数字对不上。正确做法是：关键输出必须校验。结构化输出用schema校验，数值输出做范围检查，事实性输出做交叉验证。校验不过的，要么重试，要么转人工。别省这一步。5.4 坑四：忽略成本监控大模型调用是"温水煮青蛙"式的成本——单次不贵，量大了很吓人。我见过团队上线后没做成本监控，月底账单出来才发现超预算好几倍。建议从第一天就做成本监控：按调用量、按token数、按业务线分别统计。设置预算告警，超阈值就通知。另外，缓存高频请求的结果也能省不少钱。6. 面向未来的判断：这套框架怎么跟着领域一起更新大模型领域几个月就变一次样，任何具体清单都会过时。但判断框架可以相对稳定。我自己的做法是：每季度重新过一遍选型四步法，看看硬约束有没有变化、候选模型有没有更新、自己的测试集要不要补充新场景。另外，我会持续关注两个方向：一是模型能力的"性价比曲线"——同样的效果，成本是不是在快速下降；二是应用层的"编排模式"——有没有新的任务拆解方式出现。这两点决定了未来能做什么、怎么做更划算。最后分享一个我自己的习惯：建一个"选型日志"，记录每次选型的背景、候选、测试结果和最终决定。过一段时间回头看，能清楚看到自己的判断哪里对了、哪里错了。这个日志比任何外部资料都更有针对性，因为它记录的是你自己场景下的真实经验。模型和应用都在快速迭代，但"先明确任务、再列硬约束、然后小样本实测、最后算总账"这个顺序不会变。把这套流程跑熟，无论名单怎么更新，你都能快速找到当下最适合自己的那个选项。
1. 从"模型/应用"双维度切入：为什么这个分类框架比单纯罗列模型更有用大多数人整理大模型资料时，习惯按厂商或者按发布时间拉一张长表，结果就是"知道有哪些模型，但不知道什么场景该用哪个"。我最初也这么干过，后来发现这张表越拉越长，真正要用的时候反而找不到东西。问题出在分类维度上——按厂商分，你记住的是品牌；按时间分，你记住的是新闻。这两种分法都不指向"我该选谁"这个真实问题。"模型/应用"双维度这个框架的价值在于，它把"底层能力"和"落地形态"拆开了。模型维度回答的是"这个模型本身能干什么、擅长什么、边界在哪"；应用维度回答的是"它被包装成了什么产品、面向谁、解决什么具体任务"。同一个底层模型，可能对应好几个应用形态；同一个应用，背后也可能切换过不同的模型。把这两层分开看，选型时就不会被"某某模型又更新了"这种消息牵着走。这篇内容适合三类人：一是刚接触大模型、面对一堆名字发懵的入门者；二是需要给团队做技术选型、但不想逐个试错的开发者；三是想搞清楚"某个应用到底靠不靠谱"的产品或运营角色。我会按模型维度和应用维度分别展开，中间穿插我自己踩过的坑和判断标准，尽量让每个结论都能落到"你该怎么用"上。需要先说明一点：大模型领域变化极快，任何一份清单都有时效性。所以比起记住具体名字，更重要的是掌握一套判断框架——知道从哪几个角度去评估一个模型或应用，这样即使名单更新了，你也能自己判断。2. 模型维度：拆解一个模型该看哪几个硬指标2.1 参数规模不是越大越好，关键看"有效容量"很多人一上来就问"这个模型多少参数"，好像参数越大越强。实际用下来，参数规模只说明了一部分问题。参数可以理解为模型的"脑容量上限"，但脑容量大不等于会做题——训练数据质量、训练方法、对齐策略都会极大影响最终表现。我自己的经验是：参数量主要影响的是"知识密度"和"推理深度"。小参数模型（比如几B到十几B级别）在常识问答、简单分类、格式转换这类任务上完全够用，而且推理成本低、响应快。大参数模型（几百B以上）在复杂推理、长链条逻辑、多步计算上优势明显，但代价是部署成本高、延迟大。所以选型时不要问"哪个参数最大"，而要问"我的任务需要多深的推理"。如果只是做文本摘要、情感分类，硬上超大模型就是浪费。反过来，如果要做多步数学推理或者复杂代码生成，小模型经常会在中间步骤掉链子。2.2 上下文窗口：决定"能一次喂多少料"上下文窗口这个指标，直接决定了你能把多长的材料一次性交给模型处理。早期模型只有几千token，现在主流模型动辄几十万token。这个数字看着很爽，但实际用起来有几个坑。第一，窗口大不等于"记得住"。很多模型在超长上下文里会出现"中间遗忘"——开头和结尾的信息记得清楚，中间部分容易丢。我实测过一些标称超长窗口的模型，喂进去几万字文档后问中间细节，回答质量明显下降。所以如果你的任务是长文档问答，不能只看窗口大小，还要实测它的"有效记忆范围"。第二，窗口大意味着成本高。token是按量计费的，一次喂十万token和一次喂一千token，成本差两个数量级。我的做法是：先用检索或摘要把材料压缩到最相关的部分，再喂给模型，而不是无脑全塞进去。第三，窗口大小和推理速度是矛盾的。窗口越长，模型处理越慢。如果做实时交互应用，长窗口反而会拖累体验。2.3 推理能力与知识边界：分清"会推理"和"知道得多"这两个能力经常被混为一谈。一个模型可能知识面很广（训练数据覆盖多），但推理能力一般；也可能推理很强，但知识更新不及时。选型时要分开评估。判断推理能力，我常用几个测试：多步数学题、逻辑谜题、代码调试。这些任务光靠记忆答不出来，必须一步步推。判断知识边界，就问它训练截止时间之后的事情，看它是老实说"不知道"还是硬编。后者更危险，因为会误导人。这里有个实用技巧：不要只测一个模型，拿同一组题去测几个候选模型，横向对比。单个模型的绝对表现说明不了太多，相对差异才是选型依据。2.4 开源与闭源：不是信仰问题，是成本和控制权问题开源模型和闭源模型的争论很多，但落到实际选型上，核心就两点：成本和控制权。闭源模型通常效果更稳、维护省心，但按调用量付费，长期用下来成本可能很高，而且数据要经过对方服务器，有些场景不方便。开源模型可以自己部署，数据不出内网，长期成本可控，但需要自己有运维能力，效果也可能略逊一筹。我的判断标准是：如果任务敏感、调用量大、团队有工程能力，优先考虑开源自部署；如果任务通用、调用量小、想快速上线，闭源API更省事。两者也可以混用——核心敏感任务走自部署，边缘任务走API。3. 应用维度：同一个模型，为什么做出来的产品差别巨大3.1 应用层拼的不是模型，是"任务编排"底层模型能力趋同之后，应用之间的差距主要来自任务编排。所谓任务编排，就是把一个复杂需求拆成多步，每步调用模型或工具，再把结果串起来。举个例子，同样是"帮我分析这份财报"，有的应用直接把全文丢给模型让它总结，结果又泛又浅；有的应用会先抽取关键财务指标，再让模型做同比分析，最后生成结论。后者效果明显更好，但工程复杂度高得多。所以评估一个应用时，不要只看它"用了什么模型"，要看它怎么拆任务、怎么调工具、怎么处理中间结果。这些才是护城河。3.2 检索增强：让模型"查资料"而不是"背答案"检索增强（RAG）是目前应用层最常用的技术之一。原理不复杂：用户提问后，系统先去知识库里检索相关片段，再把片段和问题一起交给模型生成回答。这样模型不用把知识全背在参数里，而是"现查现用"。这个方案的好处是知识可更新、可溯源。坏处是检索质量直接决定回答质量——检索错了，模型再强也白搭。我踩过的坑是：早期只做关键词检索，结果同义词、近义表达经常漏检。后来加了向量检索做语义匹配，召回率明显提升。实操建议：检索环节要做"混合检索"——关键词和向量各跑一遍，再合并去重。另外，检索回来的片段要排序和截断，不能全塞给模型，否则又回到长上下文的老问题。3.3 智能体形态：从"问答"到"干活"的跨越智能体（Agent）是应用层的一个明显趋势：不再只是回答问题，而是能调用工具、执行多步任务。比如自动查资料、写代码、跑测试、生成报告。这个形态的难点在于"可靠性"。单步问答错了，用户能看出来；多步任务中间错一步，后面全崩。所以智能体应用的关键不是模型多强，而是有没有"检查点"和"回退机制"——每步做完验证一下，不对就重来或换路径。我实测下来，目前智能体在边界清晰、步骤固定的任务上表现不错（比如按模板生成报表），在开放式任务上还容易跑偏。选型时要看你的任务是不是足够结构化。3.4 垂直应用 vs 通用助手：场景越窄，往往越好用通用助手什么都能聊，但什么都不精。垂直应用只做一件事，但做得深。比如专门做合同审查的、专门做代码补全的、专门做客服的。我的经验是：如果你的需求明确且重复，优先找垂直应用，因为它的提示词、检索库、输出格式都是为这个场景调过的，开箱即用效果好。如果需求杂、变化多，通用助手更灵活。判断一个垂直应用靠不靠谱，看它有没有"领域知识库"和"输出规范"。只有领域知识库，说明它真的在这个场景下积累过；有输出规范，说明它考虑过落地时的格式要求。4. 选型实操：把需求和能力对上号的四步法4.1 第一步：把需求翻译成"任务类型"很多人选型失败，是因为需求描述太模糊，比如"我要一个聪明的模型"。这种描述没法选。要把它翻译成具体任务类型：是文本生成、信息抽取、分类、推理、还是多轮对话？不同任务类型对模型的要求完全不同。分类任务看重准确率和速度，推理任务看重逻辑链条，生成任务看重流畅度和风格控制。先把任务类型定下来，候选范围立刻缩小。4.2 第二步：列出硬约束，先做减法硬约束包括：预算上限、延迟要求、数据合规要求、部署环境。这些是"一票否决"项，不满足的直接排除，不用纠结效果。比如预算只够调用小模型，那就别去看超大模型的效果对比，看了也白看。延迟要求100毫秒以内，那长窗口模型基本出局。先把硬约束列清楚，能省掉大量无效对比。4.3 第三步：小样本实测，别信榜单公开榜单只能做参考，不能做决策依据。因为榜单的测试集和你的真实数据分布往往不一样。我的做法是：从自己的业务数据里抽50到100条，做成小测试集，让候选模型都跑一遍，人工评估结果。这个测试集不用大，但要覆盖你的典型场景和边界情况。跑完之后，你会得到一份"在自己数据上的真实表现"，这比任何榜单都可靠。4.4 第四步：算总账，不只看单价选型最后要算总账：不只是API单价，还包括工程改造、运维、人工审核、错误修复的成本。有些模型单价便宜，但输出格式不稳定，需要大量后处理，综合成本反而高。我一般会做一个简单的成本模型：单次调用成本 × 预估调用量 + 工程投入 + 人工兜底成本。把这几项加起来对比，结论往往和只看单价时不一样。5. 那些年我踩过的坑：选型和使用中的真实教训5.1 坑一：盲目追新，忽略稳定性新模型发布时效果演示都很惊艳，但实际用起来可能不稳定——同样的输入，不同时间输出质量波动大。我早期追过几个新模型，上线后用户反馈"时好时坏"，排查半天发现是模型服务本身在调整。教训是：生产环境优先选稳定版本，新模型先在小流量上灰度，观察一段时间再放量。别拿线上业务当试验田。5.2 坑二：提示词写得太随意很多人觉得提示词随便写写就行，反正模型聪明。实际恰恰相反——提示词的质量对输出影响极大。同样的模型，提示词写得好和写得差，效果能差一个档次。我的提示词模板一般包含：角色设定、任务描述、输出格式、约束条件、示例。尤其是输出格式和示例，能大幅提升稳定性。如果要做结构化输出，一定要在提示词里明确字段和格式，最好给一两个例子。5.3 坑三：不做输出校验，直接信模型模型会"一本正经地胡说"，这在需要准确性的场景里是致命的。我见过直接把模型生成的财务数据用进报表的，结果数字对不上。正确做法是：关键输出必须校验。结构化输出用schema校验，数值输出做范围检查，事实性输出做交叉验证。校验不过的，要么重试，要么转人工。别省这一步。5.4 坑四：忽略成本监控大模型调用是"温水煮青蛙"式的成本——单次不贵，量大了很吓人。我见过团队上线后没做成本监控，月底账单出来才发现超预算好几倍。建议从第一天就做成本监控：按调用量、按token数、按业务线分别统计。设置预算告警，超阈值就通知。另外，缓存高频请求的结果也能省不少钱。6. 面向未来的判断：这套框架怎么跟着领域一起更新大模型领域几个月就变一次样，任何具体清单都会过时。但判断框架可以相对稳定。我自己的做法是：每季度重新过一遍选型四步法，看看硬约束有没有变化、候选模型有没有更新、自己的测试集要不要补充新场景。另外，我会持续关注两个方向：一是模型能力的"性价比曲线"——同样的效果，成本是不是在快速下降；二是应用层的"编排模式"——有没有新的任务拆解方式出现。这两点决定了未来能做什么、怎么做更划算。最后分享一个我自己的习惯：建一个"选型日志"，记录每次选型的背景、候选、测试结果和最终决定。过一段时间回头看，能清楚看到自己的判断哪里对了、哪里错了。这个日志比任何外部资料都更有针对性，因为它记录的是你自己场景下的真实经验。模型和应用都在快速迭代，但"先明确任务、再列硬约束、然后小样本实测、最后算总账"这个顺序不会变。把这套流程跑熟，无论名单怎么更新，你都能快速找到当下最适合自己的那个选项。