企业官网建设流程全解析

上周刚结束一轮厂商选型评审，前后折腾了三周，跑了上百组测试用例，翻遍了四家厂商的文档和工单记录，总算把各家AI能力的底细摸了个大概。这篇是选型系列记录的第24章，不聊市场宣传口径，只想把实际测下来的数据、踩过的坑以及最后怎么做的决策，原原本本分享出来。如果你也正处在"老板让选一个大模型平台，但不知道从哪下手"的阶段，这篇应该能帮你省掉至少两周的调研时间，也能让你在看厂商PPT的时候，知道哪些指标该追问、哪些Demo该当场戳穿。

这轮厂商AI能力对比，核心目标不是评出一个"综合第一"的厂商，而是解决一个非常具体的现实问题：我们公司三条业务线——智能客服、代码辅助工具、企业内部知识库——各自需要什么样的模型底座。做对比之前，我先跟团队说清楚一件事：不要迷信任何公开榜单，榜单测的是一般能力，我们测的是特定场景下的实际表现。统一了这个认知，后面的评测框架才能搭得起来。

1. 写在前面：这轮对比到底要解决什么问题

1.1 从一次选型评审说起

事情起因是公司要统一AI平台底座。之前各个项目组各用各的接口，有的用开源模型自己微调，有的直接调几家商业API，还有的干脆拿开源小模型凑合。时间一长问题就来了：账目混乱、安全合规没法统一管理、接口风格五花八门，运维的同学天天在群里被@。于是老板拍板：让技术委员会牵头，做一次厂商AI能力对比，选出一到两家作为公司级供应商。

评审会第一次开的时候，争论就很激烈。智能客服这边的同事强调延迟和稳定性，代码工具那边的负责人更看重模型代码能力，知识库项目组关心长文本理解。三个业务线的需求完全是三种打法，硬要把所有指标揉成一个综合分来选厂商，结果必然是谁都不满意。所以在正式开测之前，我们先把评估口径统一了：做一个多维度评测框架，每个业务线按自己的需求加权，最后得出的不是"谁最好"的结论，而是"谁最适合哪条业务线"的决策依据。

1.2 先把"AI能力"拆成可测量的项

"厂商AI能力"这个词，在外人听起来是一个整体，但真正做选型的人必须把它拆开。拆成什么？按我这次的经验，至少得分成五个层面：模型本身的智能水平（语言、推理、代码、多模态）、工程化能力（API稳定性、并发、部署方式）、安全合规能力（数据训练条款、审计、私有化）、生态服务（文档、工单、SDK、社区）、成本（单价、配额、隐性费用）。

为什么要这么拆？因为在真实的落地过程中，模型能力只占最后成功的一半，甚至不到一半。我见过好几个项目，模型得分很高，但API动不动超时、并发一上来就限流、想私有化部署发现对方根本不给离线包，最后项目延期两三个月。反过来也有模型分数不是最高、但平台稳得很，反而顺顺利利上线了。所以这次评测，我坚持把工程化和服务生态的权重抬上去，不光测"脑子好不好使"，更测"配合起来顺不顺手"。

2. 评测框架怎么搭：维度、权重与测试集

2.1 六个评估维度的划分逻辑

我们最终把评测维度定为六个：基础语言与推理能力（25分）、代码生成与理解能力（20分）、多模态识别能力（10分）、Agent工具调用能力（15分）、工程化与私有化部署能力（20分）、服务与生态（10分）。总分100分。

这个权重分配不是拍脑袋拍出来的。我们公司是软件公司，代码能力权重偏高，所以20分；客服和知识库都需要稳定的服务，工程化占20分；多模态目前只有知识库里的图片解析场景用得上，所以只给10分。每个公司业务不同，权重一定要按自己情况调。比如你是做内容生成的，语言能力权重就该往上加；做图像处理的，多模态给20分都不嫌多。

基础语言与推理为什么给25分？因为它是所有上层应用的底座，无论客服回答还是知识库检索都依赖它。但这部分的分差其实不会太大，因为头部厂商在这块都已经很成熟，真正拉开差距的是后面几项——代码、Agent、工程化。这也是这次对比值得写下来的一些反直觉发现：总分最高的厂商，未必是你最该选的厂商。

2.2 权重分配与总分计算

确定权重之后，每个维度下面还要继续拆子项。以基础语言能力为例，我拆了四类测试：常识问答（50题）、逻辑推理（30题）、长文本理解（10篇文档带20个问题）、数学计算（20题）。每类子项按正确率折算出该维度的得分。比如星云逻辑推理答对了27题，权重内得分就是27/30乘以该子项占比，最后汇总成维度分。

代码能力拆得更细：经典算法题30道、真实业务场景编程题10道（比如实现一个订单状态机、写一段数据清洗逻辑）、代码补全测试20次、Bug修复测试10个。多模态拆成图片描述、OCR识别、图表理解三类。Agent则设计了一套带有多步工具调用的任务流程，比如"查询某员工本月考勤，统计迟到次数，生成汇总报告"——这个任务需要模型依次调用多个API，非常考验规划能力。

所有分数的计算我建议都留底稿，每一道题的输入输出、模型的回答、人工评分结果全部归档。这不是为了做学术研究，而是评审会上总有不同意见，到时候把原始记录一摆，比争论"我觉得谁家更聪明"有用得多。

2.3 测试集：别直接用网上流传的题库

测试集是我特别想多说两句的地方。很多团队图省事，直接去网上下载开源评测集，比如一些广泛流传的benchmark题库，然后跑一遍出分。这种做法不能说完全没用，但对选型决策的参考价值很有限。原因有两个：一是这些题早就被厂商针对性优化过了，各家分数都很高，拉不开差距；二是你的业务场景大概率不是"做奥数题"，而是"回答用户关于退货政策的问题"，两者完全是两码事。

我的建议是，用自己业务里的真实数据来构造测试集。我们这次的做法是：从客服工单系统里脱敏抽取100个真实用户问题，从代码仓库里摘出20个真实业务模块，从内部文档里挑出10篇高频检索内容，再配上网上的通用题作为参照。脱敏的步骤不能省，因为真实日志里往往有手机号、姓名、内部系统名，直接丢给第三方API会存在数据外泄风险。

另外一个经验是测试集要固定版本，冻结下来，不要评测到一半临时加题。加题看着是完善，实际上会让不同厂商的测评时间不同步，前面测的厂商吃亏，后面测的占便宜。测评环境也要保持一致，同一批题目、同一批次请求、同一网络环境，甚至同一个时间窗口调用，避免因服务波动导致结果失真。

3. 四家厂商能力逐项实测记录

3.1 基础语言与推理：差距比榜单分数更明显

这次对比涉及四家厂商，我都用化名记录：星云智能（综合型头部厂商）、智屿科技（代码见长的独角兽）、磐石云（老牌云厂商）、海岳数据（主打私有化交付）。第一轮跑的是基础语言与推理，结果就有惊喜。

星云在逻辑推理和长文本理解上表现最均衡，正确率在四家里排第一。智屿的数学能力很强，一些多步运算题答得既快又准，但奇怪的是常识题偶尔会犯低级错误，比如把"中国的首都是北京"这种题都能答岔，后来我分析可能跟它的训练数据分布有关。磐石的模型表现中规中矩，各项都在85到90分之间，没有明显短板，但也没哪个方向特别突出。海岳是四家里唯一让我感到意外的——它之前主打B端私有化，我一直以为模型能力偏弱，结果基础语言得分竟然跟磐石差不多，只是长文本处理稍逊。

这里要说一个评测中的细节：千万不要只看正确率，还要看错误答案的类型。同样一道题答错，A模型错得离谱（给出完全无关的答案），B模型错得接近（思路对但算错最后一步），在真实业务里这两者的差距是天壤之别。客服场景下，离谱的错会导致客诉，接近的错顶多让用户再确认一次。所以每次评分我都额外记录"错误严重程度"，最终计入该维度的加权分。

3.2 代码生成与理解：高分低能的情况真的存在

代码能力测试是这轮对比里最花时间的一项。我们给每家的API发同样的30道算法题和10道业务场景题，由团队里三位资深工程师盲评，不告诉他们答案是哪家生成的，只看代码质量打分。发现的问题很有参考意义。

智屿在算法题上确实强，很多中等难度的题目能给出最优解，代码风格也算干净。但在业务场景题上就暴露问题了：让它实现一个订单状态机，它写出来的逻辑漏掉了"退款中"这个中间态，导致流程跑不通。相比之下，星云虽然算法题不是每题最优，但业务代码考虑得很周全，异常处理也写到位了。这个现象我后来想明白了：公开题库里的算法题训练语料充裕，模型见得多自然答得好；但真实的业务代码每个公司的写法都不同，训练数据里这种样本不足，差距就暴露了。

磐石的代码能力在四家里偏弱，算法题正确率只有70左右，业务题倒是没出大岔子。海岳的代码能力让人有些着急，算法题勉强及格，业务场景题里连续出现语法错误，而且它不会主动修错，需要人工反复提示。对于一个把"私有化部署"当核心卖点的厂商来说，代码能力弱对某些研发团队来说可能是致命的，但如果你只是把它用作内部知识库问答，代码能力弱也就无所谓了。这也再次印证了：选型必须绑定场景。

为了方便复现，我把当时跑批测试的脚本简化了一下，核心逻辑就是循环读取测试题目文件、调用各家API、把回答保存下来。伪代码如下：

import json import time import requests # 测试用例加载 with open("test_cases.json", "r", encoding="utf-8") as f: cases = json.load(f) # 各家API配置：替换为实际接入地址和密钥 vendors = { "星云": {"api_url": "https://api.example-xingyun.com/v1/chat", "api_key": "KEY1"}, "智屿": {"api_url": "https://api.example-zhiyu.com/v1/chat", "api_key": "KEY2"}, "磐石": {"api_url": "https://api.example-panshi.com/v1/chat", "api_key": "KEY3"}, "海岳": {"api_url": "https://api.example-haiyue.com/v1/chat", "api_key": "KEY4"}, } results = {} for vendor, config in vendors.items(): vendor_results = [] for case in cases: payload = { "model": "default", "messages": [ {"role": "system", "content": case["system"]}, {"role": "user", "content": case["prompt"]} ], "temperature": 0.1, } try: resp = requests.post(config["api_url"], json=payload, headers={"Authorization": f"Bearer {config['api_key']}"}, timeout=60) data = resp.json() vendor_results.append({ "case_id": case["id"], "response": data["choices"][0]["message"]["content"], "status": "ok" }) except Exception as e: vendor_results.append({"case_id": case["id"], "error": str(e), "status": "error"}) time.sleep(0.5) # 控制请求频率，避免触发限流 results[vendor] = vendor_results # 保存原始结果，用于后续盲评 with open("raw_results.json", "w", encoding="utf-8") as f: json.dump(results, f, ensure_ascii=False, indent=2)

这个脚本本身没什么高深的，但注意三个细节：temperature要调低（我用的0.1），保证多次调用结果稳定；每次请求之间加延时，防止触发限流；原始回答原封不动保存，方便后续人工或程序化评分。

3.3 多模态与Agent：宣传最猛翻车也最多的地方

我再强调一遍这轮实测里的结论：多模态和Agent能力，是四家厂商宣传材料里说得最凶、但实际测试中翻车最多的地方。多模态测试我们做了三类任务：给一张带表格的截图让它提取数据并回答问题、给一张产品图片让它描述特征、给一段PDF扫描页做OCR识别。

结果很有意思。星云的OCR识别准确率还行，但面对复杂表格时会把行列搞混；智屿的图片理解能力明显偏弱，一张"三栏对比图"它都描述不清楚；磐石居然在多模态上表现最稳，表格提取很少出错，OCR准确率也最高，这让我有点意外；海岳的多模态基本没法用，连续好几个任务都不符合预期，问它图片里有什么，它给出的描述跟图片内容对不上。如果你的业务里图像理解很重要，这次对比的结果会直接改变你最初的选型直觉。

Agent测试更惨烈。我们的测试任务设计得很明确：模拟一个人力资源助理，需要依次调用三个接口——先查员工信息，再查考勤记录，最后生成汇总报告。这个任务要求模型理解多步流程、正确输出工具调用参数、处理中间结果的错误。

智屿在Agent这块表现最好，能够自主规划步骤，中途偶发工具调用参数错误，但给它报错之后能自我纠正。星云也能完成任务，但不够智能——它把三个步骤一次性全规划完了，中间某个环节失败后不会动态调整，整个流程就卡住了。磐石直接退化成"你问我答"模式，全程没有调用任何工具，完全没理解这个任务要做什么。这个结果很好地说明了一件事：Agent能力跟模型本身的推理能力并不完全正相关，它更依赖厂商在工具调用链路上的专门优化。

如果你要测Agent，我建议不要只测"能不能完成"，还要测"失败后能不能恢复"。真实业务里工具调用一定会有失败，模型能否根据报错信息调整策略，这决定了你落地智能体的时候要配多少人工兜底。这块目前四家没有一个能让人省心，都还需要外部SOP兜底。

3.4 工程平台与私有化部署：落地顺畅度的分水岭

工程化能力这块，四家的差距比模型能力更加明显。评测项包括API响应延迟、稳定性（连续调用500次看错误率）、并发吞吐（模拟20路并发请求）、私有化部署支持、SDK完善度、部署文档质量。

磐石在这项上全维度领先，毕竟老牌云厂商做平台是强项。它的API响应P95延迟只有1.2秒，500次调用零错误，20路并发轻松扛住，私有化部署有完整方案，还可以选择一体机交付，文档写得也很规范，照着快速入门文档半小时就能跑通第一个Demo。星云表现次之，在线API很稳定，但私有化部署方案只支持虚拟化环境，而且交付周期长，需要至少一个月。智屿的在线API响应很快，但并发一高就开始限流，500次调用里出现了11次429错误，私有化部署只给容器镜像，不给离线包。

海岳的重心本就在私有化，交付形式很灵活，物理机、虚拟机、容器都支持，还会派驻场工程师协助部署。但它的在线API配额很小，默认并发只有5路，SDK只提供了Java和Python两个版本，README里还有几处拼写错误。综合来看，如果需求是"快速上线、在线调用"，磐石和星云是最稳妥的；如果是"数据必须留在内网"，海岳是四家里最省心的。

这里给个建议：工程化测试不要只看厂商提供的性能报告，自己一定要在真实环境里压测一遍。厂商报告里的数据往往是理想环境下测的，还可能只挑了最好的一轮结果。我们测出来有个厂商的P95延迟比它官方宣称的多了快一倍，这种差距不实测根本发现不了。

4. 隐藏成本：价格、配额、文档与工单

4.1 算一笔全链路成本账

只看单价是最容易踩的坑。我们这次整理了四家厂商的报价，按照三种业务场景分别估算月成本：客服场景按日均10万次请求、平均每次请求消耗800个输入token和200个输出token估算；代码助手场景按100个活跃开发者、每人每天生成5000个token估算；知识库场景按日均2万次检索、每次消耗1500个token估算。

算下来发现，单价最低的智屿，因为需要在回答前加一长串系统提示词来维持效果，实际每次调用的token消耗比别家多了将近三成，总成本反而跟单价次高的星云差不多。海岳的私有化部署看着是"一口价买断"，但一体机硬件三年质保到期后的续保费用、每次大版本升级的实施费用都不低，摊销下来月成本甚至超过了走量的商业API。

另外一个没人明说的问题是上下文长度。四家都宣传支持很长的上下文窗口，但实际把长文档灌进去之后，真正能用的只有宣传值的一半到三分之二，超过这个长度，模型就开始"健忘"——前面刚给的信息后面就忘了。我们在知识库场景的测试中专门验证了这一点：把一份80页的合同文本喂进去，然后问第75页上的条款细节，只有星云和磐石答对了，另外两家都在编。这个差距不在价格表上，但直接影响知识库项目的选型决策。

4.2 配额限制才是真正的天花板

配额这个东西，很多团队在选型初期根本不在乎，等真正上线了才发现是致命的。四家厂商对新用户的默认配额宽严不一，智屿最抠，默认每分钟请求数限制很低，我们在Agent测试时跑一个稍微复杂一点的任务就触发限流。想申请更高配额，得走商务流程，填一堆材料，审核周期一周到两周不等。如果你的业务有流量高峰，这个审核周期会直接耽误上线窗口。

还有一些配额是隐形存在的，比如单次请求的最大输入长度、每分钟的token消耗上限。有一个厂商的文档里写着"单次输入最大可支持大上下文，但每分钟token消耗上限受实例规格限制"，这句话翻译过来就是：你可以发很长的请求，但发的多了就会被限流。这种细节点不实测根本发现不了，建议在签合同之前把你未来半年的峰值流量估算出来，跟厂商的商务确认清楚，写进合同附件。

4.3 文档和工单质量直接决定接入速度

文档和工单响应，是这次对比里最容易被低估的隐性成本。我们做了一个很务实的测试：模拟一个接入团队，从注册账号开始，到成功调用第一个API，记录每一家需要花多少时间。结果磐石最快，半小时搞定；星云需要一小时，因为文档里有一个参数示例跟实际不符，我们被迫去翻社区帖子；智屿花了两小时，主要是权限配置的部分讲得不清楚；海岳花了一个下午——它的认证流程比其他三家复杂得多，还要提供额外的材料。

工单响应速度的差距更大。我统计了每家三张工单的平均响应时间：磐石平均4小时给出有效答复，星云8小时，智屿14小时，海岳最快的一单也隔了一整天。海岳可能习惯了现场交付模式，在线支持的服务意识确实较弱。这里特别提醒一点：如果选了响应慢的厂商，一定要在合同里写明SLA，约定工单响应时限和不达标的赔偿条款，否则上线期间遇到问题，你只能干等着。

5. 选型决策建议与踩坑复盘

5.1 按业务场景匹配厂商

评测结束后，我们把分数汇总成一个总表，加了场景权重，结果很有意思：没有一家厂商三个场景全拿第一。智能客服场景（重视响应延迟、稳定性、基础语言能力）综合下来星云最优，磐石次之但差距不大；代码助手场景（重视代码能力、私有化）智屿最强，但需要接受配额的约束；知识库场景（重视长文本、多模态、私有化）磐石和海岳各有优势，一个胜在线上的稳定性，一个胜在数据不出内网。

所以我给了管理层一个结论：不要搞"一家通吃"，而是按场景指定主供应商和备选供应商。客服和知识库的在线部分用星云或磐石，代码助手用智屿，有严格数据合规要求的知识库私有化场景用海岳。这样做的坏处是要维护多个厂商关系，好处是每个场景都用最合适的模型，整体效果最优。从我实际经验看，多厂商策略对中等以上规模的公司是值得的，关键是要在中间加一层网关统一接口，后面我会提到。

5.2 组合使用而不是二选一

多厂商策略听起来复杂，做起来其实有成熟方案。我们在API之上封装了一层统一的网关，把各家模型的调用地址、密钥、计费都集中管理。业务方不用关心底层用的是哪家，只管按统一格式发请求。网关层再根据业务类型做路由：代码类请求转发到智屿，客服类请求转发到星云，知识库检索类请求转发到磐石或海岳，某个厂商出现故障时自动切换到备用厂商。

这个架构还有一个额外的好处：模型升级不透明的时候，可以在网关层针对某个特定版本固定路由，避免厂商悄悄换版导致线上效果波动。我这次踩到一个很典型的坑：某厂商在评测期间和签约后的模型版本不一样了，回答风格整体变化，之前调好的提示词全部失效。如果你用的是网关架构，至少可以锁定版本，把变化的影响降到最小。

当然，多厂商策略也有代价。安全合规更难统一，每家的数据处理条款都要法务单独审一遍；运维复杂度上升，监控、告警、出账都要接多套；运营上还要防着厂商之间的商务竞争条款。所以小团队建议还是单选一家，省心；等体量上来了再考虑多厂商，收益才划算。

5.3 签约前必须确认的十个问题

最后把签约前要跟厂商确认的问题整理成一份清单，这些全是我在选型过程中遇到过的真实问题，建议逐条过：

1. 模型版本更新频率和通知机制是什么？重大版本升级会不会提前通知，能不能指定老版本继续使用？
2. 数据用于训练的条款怎么写的，能不能签数据不用于训练的补充协议？
3. 服务可用性SLA是多少？如果故障，赔偿标准是什么？
4. 私有化部署是只给部署包还是包含后续升级服务？升级费用怎么算？
5. 配额扩容的申请流程和响应时限是什么？有没有预付费锁定配额的方案？
6. 有没有专属实例方案，还是共享资源池？共享资源池在高峰期是否会影响响应质量？
7. 支持的上下文长度在真实业务中的有效值是多少？能不能提供一份大上下文压测报告？
8. 工单响应时限写在合同里了吗？每个优先级对应多久必须回复？
9. 迁移成本：如果未来想换厂商，平台方是否提供数据导出工具和接口文档？
10. 安全审计：能不能提供SOC2报告或等保测评材料？日志保留多长时间？

这份清单里最后一项我特别想强调：一个真实发生过的事情，某厂商的SLA只承诺"月度可用性99.5%"，看起来还行，但折算下来一年里可以有超过43小时的不可用时间。对客服系统来说，这个数字是没法接受的。所以看SLA不要看年化，要把不可用时间折算出来，再对照业务容忍度判断。

最后再分享两个小经验

这次对比做下来，我最大的体会是：选AI厂商跟选结婚对象有点像，热恋期看的是能力上限，过起日子来拼的是下限——稳定性、响应速度、配额够不够、出了问题理不理你。模型能力再强，服务不靠谱也不行。

第二个经验跟评测本身有关：一定要让真正会用这个系统的人参与盲评，不要只看自动评分的数值。我一开始让算法同学写脚本跑分，分数拉不开差距，后来让客服业务骨干、开发组长、知识库运营的人分别来打分，他们关注的点完全不一样，这才把厂商之间的真实差异暴露出来。技术上大家都做得到七八十分，但"谁更贴合我的人用"这件事，只有使用者说了算。

如果时间紧张，至少要跑三轮：第一轮用通用题摸底，第二轮用业务题定方向，第三轮做工程化压测定生死。这三轮跑完，再结合价格和商务条款，选出来的厂商大概率不会让你半夜被叫起来处理故障。