企业官网建设流程全解析

1. 当我们在聊“厂商AI能力对比”时，到底在比什么

“第24章：厂商AI能力对比”这个标题，乍一看像是某本技术手册或者内部培训材料的章节名，但它其实是一个特别接地气的话题。不管你是做技术选型、产品规划，还是单纯想搞清楚市面上这些AI服务到底哪家强，都绕不开这个命题。我自己在过去一年多的时间里，因为项目需要，陆陆续续对接过七八家主流厂商的AI能力接口，从文本生成到图像识别，从语音合成到多模态理解，踩过的坑、交过的学费、总结出来的经验，足够写一篇长文了。

先说一个反直觉的结论：厂商AI能力对比，比的从来不是“谁最强”，而是“谁最适合你当前这个场景”。很多人一上来就问“哪家的模型参数最大”“哪家的跑分最高”，这就像买车只看马力不看用途一样，最后大概率会选错。一个做客服自动回复的场景，和一个做创意文案生成的场景，对AI能力的要求完全不同；一个需要低延迟高并发的实时系统，和一个可以离线批量处理的分析任务，选型逻辑也天差地别。

所以这篇文章，我想从实际落地的角度，把“厂商AI能力对比”这件事拆开来讲。我会聊到对比的维度怎么定、测试集怎么设计、不同厂商的差异化优势在哪里、实际接入时有哪些隐藏成本、以及我自己总结出来的一套“场景匹配打分法”。不管你是刚接触AI能力选型的新手，还是已经用过几家服务想换个方案的老手，应该都能从中找到一些有用的东西。

需要提前说明的是，文中提到的所有厂商和案例都会做模糊化处理，用“A厂商”“B平台”这样的代称，重点在于方法论和实操经验，而不是给某一家做广告。毕竟这个领域变化太快，今天的第一名明天可能就被超越了，但对比的方法论和避坑经验是相对稳定的。

2. 对比维度的拆解：别只盯着跑分看

2.1 基础能力指标：准确率、召回率、F1值到底怎么看

大多数人拿到一份厂商AI能力对比文档，第一眼看到的就是各种指标表格：准确率98.5%、召回率96.2%、F1值97.3%……数字都很漂亮，但你真的知道这些数字是怎么来的吗？

我刚开始做选型的时候，也被这些数字迷惑过。后来自己动手跑了几轮测试才发现，同一个模型在不同的测试集上，指标可以差出十几个百分点。厂商在宣传材料里用的测试集，往往是经过精心挑选的、对自家模型有利的数据。这不是说厂商在造假，而是说这些指标只能作为参考，不能作为决策的唯一依据。

举个例子，某次我对比A厂商和B平台的文本分类能力。A厂商宣传准确率97%，B平台宣传95%。单看数字，A厂商赢了。但我用自己业务场景的真实数据跑了一遍，结果B平台的实际准确率是91%，A厂商只有86%。为什么？因为A厂商的模型在通用语料上表现很好，但对我的业务领域里的专业术语和特殊表达方式理解不够，而B平台恰好在这个领域有更多的训练数据积累。

所以我的建议是：厂商给的指标只看趋势，不看绝对值。你要关注的是，在多个不同来源的测试集上，哪家厂商的表现更稳定、波动更小。一个在五个测试集上都能保持90%以上准确率的模型，比一个在某个测试集上冲到98%但在其他测试集上掉到80%的模型，更值得信赖。

具体操作上，我通常会做三件事：

• 第一，要求厂商提供至少三个不同来源的测试集结果，包括通用测试集、领域测试集和对抗测试集。
• 第二，自己准备一个“黄金测试集”，规模不用大，几百条就够，但必须是你业务场景的真实数据，并且人工标注过。
• 第三，把厂商宣传的指标和自己的实测指标放在一起对比，看差距有多大。差距越小，说明厂商的数据越可信。

2.2 响应延迟与吞吐量：那些宣传页上不会写的事

响应延迟和吞吐量，是厂商宣传页上最容易被“美化”的指标。你经常能看到“平均响应时间小于200毫秒”这样的描述，但实际用起来，偶尔会冒出两三秒甚至更长的请求。这不是厂商在骗人，而是“平均”这个词掩盖了长尾分布的问题。

我在一个实时对话项目里就吃过这个亏。选型时看某厂商宣传平均延迟180毫秒，觉得完全能满足需求。结果上线后发现，大概有5%的请求延迟超过1.5秒，用户明显能感觉到卡顿。后来找厂商的技术支持沟通才知道，他们的平均延迟是在理想网络条件下、用短文本测试出来的，而我的场景里文本长度是他们的三到五倍，还涉及多轮上下文拼接，实际延迟自然高出一大截。

所以对比延迟指标时，一定要问清楚测试条件：文本长度是多少？并发数是多少？是否包含网络传输时间？是否包含预处理和后处理时间？这些细节决定了你看到的数字和实际体验之间的差距。

吞吐量也是类似的情况。厂商说“支持每秒1000次调用”，但你可能发现并发到200的时候就开始出现超时了。这时候你要看的是在保证可接受延迟的前提下，实际能稳定支撑多少并发。我的做法是做一个阶梯式压力测试：从每秒10次开始，逐步增加到50、100、200、500，记录每个阶段的成功率和延迟分布，找到那个“性能拐点”。

下面这张表是我自己整理的一个对比框架，供参考：

2.3 成本结构：按调用次数还是按Token，差别有多大

成本这块，水比很多人想象的深。表面上看，各家都是“按量付费”，但计费单位的差异会导致最终账单相差好几倍。

目前主流的计费方式有三种：按调用次数、按Token数量、按计算资源时长。按调用次数最好理解，调一次算一次的钱，适合请求长度比较均匀的场景。按Token数量就复杂一些，输入和输出的Token单价可能不同，而且不同厂商对Token的切分方式也不一样——同样一段中文，A厂商算100个Token，B平台可能算120个，这直接影响到成本对比的公平性。

我做过一个粗略的测算：同样处理一万条平均长度200字的文本，按调用次数计费的方案大约花费X元，按Token计费的方案花费Y元，两者相差大概30%到50%。具体哪个更划算，取决于你的文本长度分布。如果你的文本长度波动很大，按Token计费通常更公平；如果长度比较均匀，按调用次数可能更省心。

还有一个容易被忽略的成本项：失败重试的成本。AI接口不是100%可用的，偶尔会返回错误或者超时。如果你的系统设计了自动重试机制，那么实际调用次数会比你预期的多。有些厂商对失败请求也计费，有些则不计费，这个差异在量大之后会非常明显。

提示：在签合同之前，一定要问清楚失败请求是否计费、重试是否算新调用、是否有最低消费承诺。这些条款看起来不起眼，但可能让你的实际支出比预算高出20%以上。

2.4 数据安全与合规：不能妥协的底线

数据安全这个维度，平时不出事的时候感觉不到它的存在，一旦出事就是大事。我在选型时会把安全能力分成三个层面来考察：

第一个层面是传输和存储加密。这个基本是所有厂商的标配了，但你要确认的是加密算法和密钥管理方式。有些厂商用的是行业标准方案，有些则是自研的加密协议，后者的安全性需要更仔细地评估。

第二个层面是数据隔离和访问控制。你的数据是和别的客户混在一起，还是独立存储？厂商的内部人员能不能看到你的数据？有没有审计日志记录谁在什么时候访问了什么数据？这些问题在对接前就要问清楚，不要等到出了事再追责。

第三个层面是数据使用授权。有些厂商会在服务条款里写明，他们有权使用你的数据来改进模型。如果你处理的是敏感信息，这一条绝对不能接受。我通常会要求厂商提供一份明确的数据处理协议，写明数据不会被用于模型训练、不会被分享给第三方、服务结束后会被彻底删除。

3. 测试集设计：怎么用最小成本摸清厂商底细

3.1 构建“黄金测试集”的四个原则

自己动手做测试集，是摸清厂商真实能力最有效的方法。但测试集不是随便找几条数据就行的，我总结下来有四个原则：

原则一：规模适中，质量优先。测试集不需要几千几万条，300到500条就足够看出差异了。但每一条都必须是真实业务数据，并且经过人工标注。我见过有人用公开数据集做测试，结果发现厂商的模型在公开数据集上表现很好，一到真实场景就拉胯，因为公开数据集和业务数据的分布差异太大了。

原则二：覆盖边界情况。正常样本谁都能处理好，真正拉开差距的是边界情况。比如文本分类任务里，那些模棱两可的、包含多个类别特征的、有错别字的样本，才是考验模型鲁棒性的关键。我在设计测试集时，会刻意让边界样本占到30%左右。

原则三：标注一致性要高。如果标注本身就有争议，那测试结果就没有意义了。我的做法是让两个人独立标注，然后对比结果，对于不一致的样本进行讨论直到达成共识，实在无法达成共识的就直接剔除。

原则四：定期更新。业务在变化，测试集也要跟着更新。我一般每季度会补充一批新数据，替换掉过时的样本，保持测试集的时效性。

3.2 自动化测试脚本的搭建思路

手工一条条测试效率太低，我通常会写一个自动化测试脚本，把测试集跑一遍，自动统计各项指标。脚本的逻辑不复杂，核心就是三步：读取测试集、调用厂商接口、对比结果并统计。

import json import time import requests from collections import defaultdict class AITester: def __init__(self, test_data_path, api_config): with open(test_data_path, 'r', encoding='utf-8') as f: self.test_data = json.load(f) self.api_config = api_config self.results = defaultdict(list) def call_api(self, text): start = time.time() try: response = requests.post( self.api_config['endpoint'], headers={'Authorization': f"Bearer {self.api_config['key']}"}, json={'input': text}, timeout=10 ) latency = time.time() - start if response.status_code == 200: return response.json(), latency, None else: return None, latency, f"HTTP {response.status_code}" except Exception as e: latency = time.time() - start return None, latency, str(e) def run(self): for item in self.test_data: result, latency, error = self.call_api(item['text']) self.results['latency'].append(latency) if error: self.results['errors'].append(error) else: predicted = result.get('label') self.results['correct'].append(predicted == item['label']) return self.summarize() def summarize(self): total = len(self.test_data) correct = sum(self.results['correct']) latencies = sorted(self.results['latency']) return { 'accuracy': correct / total if total else 0, 'error_rate': len(self.results['errors']) / total if total else 0, 'avg_latency': sum(latencies) / len(latencies) if latencies else 0, 'p95_latency': latencies[int(len(latencies) * 0.95)] if latencies else 0, 'p99_latency': latencies[int(len(latencies) * 0.99)] if latencies else 0, }

这个脚本的核心价值在于，它把主观感受变成了客观数据。你可以拿着这份数据去和厂商沟通，也可以用它来对比不同厂商的表现。我一般会跑三轮：第一轮用短文本，第二轮用长文本，第三轮用混合长度，这样能更全面地了解厂商的能力边界。

3.3 人工评估与自动评估的取舍

自动评估适合那些有明确标准答案的任务，比如分类、实体识别、情感分析。但有些任务是没有标准答案的，比如文本生成、摘要、翻译，这时候就需要人工评估。

人工评估的难点在于主观性强、成本高、难以规模化。我的做法是设计一套评分标准，把主观判断变成相对客观的分数。比如对于文本生成任务，我会从流畅度、相关性、信息量、创造性四个维度各打1到5分，然后取平均值。评分标准要写得足够具体，比如“流畅度5分：全文没有语法错误，读起来像母语者写的；3分：有少量语法错误但不影响理解；1分：语法错误多到影响理解”。

为了降低人工评估的成本，我通常只对自动评估中表现接近的厂商做人工对比，那些自动评估就明显落后的直接淘汰。这样能把有限的人力集中在最需要判断的地方。

4. 不同厂商的差异化打法：没有全能冠军

4.1 通用能力型选手的强项与短板

有一类厂商，走的是“大而全”的路线，文本、图像、语音、视频全都做，而且每个方向都投入了大量资源。这类厂商的优势很明显：接口统一、文档完善、生态丰富。你用一个账号就能调用多种能力，不用在多个平台之间来回切换，省去了很多对接成本。

但短板也很明显：在垂直领域的深度不够。因为要覆盖的领域太多，资源被分散了，所以在某些专业场景下的表现可能不如那些专注单一领域的厂商。我做过一个测试，在医疗文本理解任务上，某通用型厂商的准确率是82%，而一家专注医疗AI的厂商达到了91%。差距主要来自训练数据的差异——专注型厂商有大量标注好的医疗语料，而通用型厂商的医疗数据相对有限。

所以我的建议是：如果你的业务场景比较通用，比如客服问答、内容审核、通用翻译，选通用能力型厂商没问题；但如果你的场景有很强的专业性，比如法律文书分析、医疗诊断辅助、金融风控，那就要重点考察那些在垂直领域有积累的厂商。

4.2 垂直领域专精型选手的生存逻辑

垂直领域专精型厂商，通常规模不如通用型厂商大，但他们在某个特定领域深耕多年，积累了大量的领域数据和行业知识。这类厂商的典型特征是：在特定任务上的表现明显优于通用型厂商，但接口的通用性和生态的丰富度可能稍逊一筹。

我接触过一家做工业质检AI的厂商，他们的模型在缺陷检测任务上的准确率比通用型厂商高出15个百分点。原因很简单：他们收集了数十万张工业质检的标注图片，而通用型厂商在这个细分领域的数据积累可能只有几千张。这种数据壁垒是通用型厂商很难在短期内追赶的。

但专精型厂商也有自己的烦恼。首先是场景迁移能力弱，他们的模型在训练过的场景里表现很好，换一个稍微不同的场景可能就需要重新训练。其次是服务稳定性风险，小厂商的抗风险能力不如大厂商，万一出现经营问题，你的业务可能会受到影响。所以我在选择专精型厂商时，会额外关注他们的客户案例、融资情况和团队背景，确保他们有能力持续提供服务。

4.3 开源方案与商业API的混合使用策略

除了商业厂商，开源方案也是一个重要的选项。开源模型的优势是成本低、可控性强、数据不出本地，适合对数据安全要求极高或者预算有限的场景。但开源方案的短板也很明显：需要自己部署和维护、需要自己调优、没有技术支持。

我目前的策略是混合使用：核心业务用商业API保证稳定性和效果，边缘业务或者对成本敏感的业务用开源模型。比如在一个内容推荐项目里，主推荐模型用的是商业API，但一些辅助性的标签生成任务用的是开源模型，这样既保证了核心效果，又控制了整体成本。

混合使用的一个关键点是接口抽象。我会在业务代码和AI服务之间加一层适配层，把不同厂商的接口统一成相同的调用方式。这样切换厂商或者调整混合比例时，只需要改适配层的配置，不用动业务代码。

class AIProvider: def predict(self, text): raise NotImplementedError class VendorAProvider(AIProvider): def predict(self, text): # 调用A厂商接口 pass class VendorBProvider(AIProvider): def predict(self, text): # 调用B平台接口 pass class OpenSourceProvider(AIProvider): def predict(self, text): # 调用本地开源模型 pass class AIService: def __init__(self, providers): self.providers = providers def predict(self, text, strategy='primary'): if strategy == 'primary': return self.providers[0].predict(text) elif strategy == 'fallback': for provider in self.providers: try: return provider.predict(text) except Exception: continue raise RuntimeError("所有服务均不可用")

这种设计的好处是，你可以在不同厂商之间灵活切换，也可以根据业务需求组合使用。比如高峰期用商业API保证吞吐量，低峰期用开源模型降低成本。

5. 实操中的隐藏成本与避坑指南

5.1 接入阶段的“最后一公里”问题

很多人在选型时把大量精力花在对比模型效果上，却忽略了接入阶段的成本。我见过不少项目，选型阶段花了两个月，结果接入阶段又花了三个月，问题就出在“最后一公里”上。

最常见的坑是文档和实际接口不一致。厂商的API文档写得很漂亮，但实际调用时发现参数名对不上、返回格式有差异、错误码没有文档说明。我现在的习惯是，在正式选型之前，先让团队花半天时间做一个最小可行性接入测试，把文档里的示例代码跑一遍，看看能不能顺利调通。如果连示例代码都跑不通，那这个厂商的接入成本可能会很高。

另一个坑是SDK的维护质量。有些厂商提供的SDK版本更新不及时，和最新的API不兼容；有些SDK只支持特定版本的编程语言，你的技术栈可能用不了。我的做法是优先选择提供RESTful API的厂商，因为HTTP接口的兼容性最好，不依赖特定的SDK。

还有一个容易被忽略的点是配额和限流。厂商通常会设置默认的QPS限制，如果你的业务量突然增长，可能会触发限流导致请求失败。我一般会在接入时就申请提高配额，并且设计一个降级方案，在触发限流时自动切换到备用服务或者返回缓存结果。

5.2 效果不达预期时的排查路径

模型效果不达预期，是最让人头疼的问题。我的排查路径通常是这样的：

第一步，确认是数据问题还是模型问题。把测试集中模型判断错误的样本拿出来，人工分析一下。如果错误样本有明显的共性，比如都是长文本、都是包含专业术语的、都是带有反讽语气的，那可能是数据分布的问题，需要调整测试集或者补充训练数据。如果错误样本很分散，没有明显规律，那可能是模型本身的能力边界问题。

第二步，检查输入数据的质量。很多时候模型效果不好，不是模型的问题，而是输入数据的问题。比如文本里有多余的空格、特殊字符、编码错误，这些都会影响模型的理解。我一般会在调用模型之前加一个数据清洗步骤，把明显的噪声去掉。

第三步，对比不同厂商的表现。如果同一批数据在A厂商上表现不好，在B平台上表现正常，那说明问题出在A厂商的模型上。这时候可以拿着具体的错误案例去找厂商的技术支持，他们通常能给出针对性的优化建议。

第四步，考虑微调或者提示词优化。如果厂商支持微调，可以用自己的数据对模型进行微调，通常能带来明显的效果提升。如果不支持微调，那就只能在提示词上下功夫，把任务描述得更清晰、给出更多的示例、明确输出格式。

5.3 从单厂商依赖到多厂商容灾的演进

我刚开始做AI选型的时候，习惯只选一家厂商，觉得这样管理起来简单。但后来遇到过一次厂商服务中断的事故，整个业务停了四个小时，损失不小。从那以后，我就开始推动多厂商容灾的方案。

多厂商容灾的核心思路是：主服务用一家厂商，备用服务用另一家，通过适配层统一接口，在主服务不可用时自动切换。切换的触发条件可以是请求失败率超过阈值、延迟超过阈值、或者健康检查失败。

实施多厂商容灾的难点在于效果一致性。不同厂商的模型输出格式和风格可能不同，切换后用户可能会感觉到差异。我的做法是，在切换时加一个过渡层，把备用服务的输出转换成和主服务一致的格式。如果差异实在太大，那就只能接受短期的体验下降，优先保证服务可用性。

从成本角度看，多厂商容灾会增加一些开支，因为备用服务即使不承载主要流量，也可能需要支付最低消费或者保持热备状态。但考虑到服务中断带来的损失，这笔投入是值得的。我一般会建议客户把容灾方案的成本控制在总预算的10%到20%之间。

6. 场景匹配打分法：一套可复用的选型框架

6.1 权重分配：不同场景下的优先级排序

经过多次选型实践，我总结出了一套“场景匹配打分法”。核心思路是：先确定你的场景最看重哪些维度，然后给每个维度分配权重，最后对每个厂商在每个维度上打分，加权求和得到总分。

权重的分配完全取决于你的场景。比如：

• 实时对话场景：延迟权重0.3，准确率权重0.25，成本权重0.2，稳定性权重0.15，安全权重0.1
• 批量分析场景：准确率权重0.35，成本权重0.25，吞吐量权重0.2，延迟权重0.1，安全权重0.1
• 敏感数据处理场景：安全权重0.4，准确率权重0.25，稳定性权重0.15，成本权重0.1，延迟权重0.1

权重确定后，对每个厂商在每个维度上打分，1到10分。打分依据就是前面做的各种测试和调研。最后算加权总分，得分最高的就是最适合你当前场景的厂商。

这套方法的好处是把主观判断变成了可量化的决策依据，而且权重可以根据业务变化灵活调整。比如业务从起步期进入成熟期，对成本的敏感度下降，对稳定性的要求提高，只需要调整权重重新算一遍就行。

6.2 打分表的实际应用案例

我拿一个真实项目来演示一下。这是一个智能客服场景，核心需求是快速响应用户提问，同时保证回答准确。我们对比了四家厂商，打分表如下：

从这个打分结果看，A厂商虽然准确率不是最高的，但凭借延迟和成本的优势，加权总分最高。B平台准确率和稳定性最好，但延迟和成本拖了后腿。最终我们选择了A厂商作为主服务，B平台作为备用服务。

这个案例说明了一个道理：没有最好的厂商，只有最适合当前场景的厂商。如果这个项目的核心需求变成了“回答必须极其准确，延迟可以放宽”，那B平台就会反超。

6.3 动态调整：业务变化后如何重新评估

业务不是一成不变的，选型也不是一劳永逸的。我一般会每半年做一次重新评估，或者在业务发生重大变化时随时启动评估。

重新评估的触发条件包括：业务量增长超过50%、对延迟或准确率的要求发生变化、厂商调整了计费方式、出现了新的厂商或者新的技术方案、现有厂商的服务质量出现明显下降。

重新评估的流程和初次选型基本一致，但可以复用之前的测试集和测试脚本，效率会高很多。我通常会保留每次评估的打分表和测试数据，这样可以看到厂商表现的长期趋势，也能看到自己的需求变化轨迹。

有一点需要特别注意：不要频繁切换厂商。每次切换都有接入成本和适应成本，如果切换带来的收益不足以覆盖这些成本，那就不要切。我一般会设定一个阈值，比如新方案的加权总分比现有方案高出15%以上，才考虑切换。

7. 我踩过的那些坑和总结出的经验

7.1 被“跑分”误导的一次选型经历

早期做选型的时候，我特别迷信跑分。有一次看到某厂商在公开评测榜单上排名第一，几乎没怎么测试就选了它。结果上线后发现，它在我的业务场景里表现平平，甚至不如排名第三的厂商。

后来复盘才发现，那个公开评测榜单的测试集和我的业务数据分布差异很大。榜单侧重的是通用知识问答，而我的场景是专业领域的文本分类。厂商为了在榜单上拿高分，可能针对性地优化了通用能力，但专业领域的能力并没有同步提升。

这件事给我的教训是：跑分只能作为初筛的依据，不能作为最终决策的依据。初筛之后，一定要用自己的数据做实测。实测的结果才是真正属于你的、有参考价值的数据。

7.2 忽视数据安全条款带来的麻烦

还有一次，我们在对接某厂商的服务时，没有仔细看数据使用条款。后来法务同事审查合同时发现，条款里有一条写着“厂商有权使用客户数据来改进服务”。这意味着我们处理的用户数据可能会被厂商用于模型训练，这在我们的合规框架下是不允许的。

虽然最终通过谈判删除了这一条，但过程很折腾，差点影响了项目进度。从那以后，我养成了一个习惯：在技术对接之前，先让法务过一遍合同和条款。技术团队关注的是接口好不好用、效果好不好，但数据安全这种问题，需要法务的专业判断。

7.3 多厂商适配层带来的意外收益

前面提到过，我为了做多厂商容灾，加了一个适配层。本来只是为了方便切换，后来发现这个适配层还带来了几个意外的好处。

第一个好处是方便做A/B测试。有了适配层，我可以把一部分流量切到新厂商，对比新旧方案的实际表现，而不用改动业务代码。这让我们的选型决策更加数据驱动。

第二个好处是方便做成本优化。适配层可以根据请求的特征，自动选择最经济的厂商。比如短文本用便宜的方案，长文本用效果好的方案，整体成本降了大概20%。

第三个好处是降低了厂商锁定的风险。因为切换成本很低，我们在和厂商谈判时更有底气，也能更快地响应厂商的价格调整或服务变化。

7.4 关于“自建还是采购”的思考

最后聊一下自建和采购的选择。有些团队会觉得，既然开源模型这么多，为什么不自己部署一套？我的看法是：自建适合有较强技术团队、数据安全要求极高、且业务量足够大的场景；采购适合大多数中小团队和快速迭代的业务。

自建的成本不只是服务器和电费，还包括模型调优、运维监控、版本升级、故障处理等一系列人力投入。我粗略估算过，一个中等规模的自建方案，每年的综合成本可能在几十万到上百万之间，而同等能力的商业API可能只需要几万到十几万。除非你的业务量特别大，或者有特殊的安全合规要求，否则采购通常是更经济的选择。

当然，混合方案也是一个不错的选择。核心数据用自建模型处理，非核心数据用商业API，这样既保证了安全，又控制了成本。具体怎么选，还是要回到你的业务场景和资源约束上来。

说到底，厂商AI能力对比这件事，没有标准答案，也没有一劳永逸的方案。它是一个持续迭代的过程：理解自己的需求、设计合理的测试、客观地评估结果、灵活地调整策略。我自己的经验是，每次选型都会踩一些新坑，但每次踩坑之后，对业务的理解和对技术的判断都会更深入一层。希望这篇文章里的经验和框架，能帮你在选型的路上少走一些弯路。