1. 这份信息源清单到底解决什么问题？——别再靠二手消息做决策了

你有没有过这种经历：看到某家大模型公司突然发布一个新模型，朋友圈已经刷屏“性能碾压GPT-4”，你点开链接却发现是公众号转载的第三手报道，连原始技术报告PDF都找不到；或者团队要选型推理框架，技术负责人甩来一篇“2024年大模型平台横向评测”，结果发现数据来源模糊、测试环境不透明，连batch size都没写清楚；又或者市场同事急着写竞品分析，翻遍官网和新闻稿，却始终找不到该厂商API的SLA承诺原文、商用授权条款的PDF附件，最后只能凭经验“合理推测”。这些不是个别现象，而是当前大模型应用落地阶段最普遍的信息断层—— 一手信源严重缺失，二手传播严重失真 。这份清单，就是我过去18个月在37家主流大模型厂商官网、开发者中心、GitHub仓库、技术博客、白皮书发布页、甚至专利数据库里，一条条人工核验、去重、分类、标注后沉淀下来的 可直接访问、可验证、可引用的一手信息源地图 。它不包含任何媒体解读、自媒体评论、第三方评测链接，只收录厂商自己发布的、具有法律效力或技术权威性的原始内容入口。适合三类人：技术选型时需要查证API细节的工程师、写商业方案时需要引用SLA条款的售前、做竞品分析时需要追溯技术演进路径的产品经理。它不能帮你写PPT，但能确保你PPT里的每一页数据，都有一个可点击、可截图、可存档的原始链接作为支撑。

2. 为什么必须亲自爬官网？二手信息的三大致命陷阱

很多人觉得“搜一下不就完了”，但实际操作中，依赖搜索引擎或聚合平台会掉进三个深坑，我踩过，也帮客户填过。第一个是 时效性陷阱 ：某次我们为金融客户做模型选型，用某知名AI资讯站的“最新模型列表”作为依据，发现其中标注“已上线”的某款多模态模型，在其官网开发者文档里明确写着“Beta阶段，仅限白名单申请”，而该资讯站的更新日期是三个月前。原因很简单——资讯站抓取的是官网首页Banner，而Banner更新后，内页文档并未同步，导致信息严重滞后。第二个是 语义失真陷阱 ：某大厂在技术博客里发布了一篇《轻量化推理优化实践》，核心讲的是在特定硬件上将推理延迟降低40%，但被某公众号标题党改写成《重磅突破！XX模型推理速度提升400%》，把“特定场景下的40%”偷换成了“全场景400%”，而原文中的硬件型号、输入长度、batch size等关键约束条件全部被删。第三个是 法律效力陷阱 ：最典型的是商用授权条款。很多聚合平台只展示“免费商用”四个字，但当你点进原始PDF，会发现小字注明“需签署单独的商业许可协议，且不得用于生成医疗诊断建议”。去年有家创业公司就因此被发律师函，因为他们直接照搬了聚合平台的描述，没去查原始License文件。所以这份清单的底层逻辑很朴素： 所有信息必须能回溯到厂商域名下（.com/.cn/.io等）的原始页面，且该页面必须由厂商官方维护、更新、署名 。比如Hugging Face上的模型卡，虽然权威，但属于社区托管，不算“一手”；而同模型在厂商自己GitHub仓库里发布的README.md，哪怕只是个链接，也属于一手信源——因为那是厂商主动选择的、对其技术主张负责的发布渠道。

2.1 官网结构解剖：90%的有效信息藏在这5个固定位置

经过对37家厂商的反复比对，我发现其官网信息架构高度趋同，有效信息基本集中在五个“黄金位置”，掌握这个规律，你能在30秒内定位到90%的关键内容。第一是 Developer Portal（开发者门户） ，这是最核心的入口，通常位于导航栏最右侧，名称可能是“Developers”、“API”、“Get Started”或“Docs”。这里不是简单的API文档，而是包含：实时更新的API Reference（含所有endpoint、参数、返回值示例）、SDK下载页（带版本号和校验码）、Rate Limiting策略（精确到每分钟请求数和token数）、错误代码表（如429对应的具体触发条件）。第二是 Research / Blog（研究/技术博客） ，注意不是普通新闻稿，而是带有“Research”、“Paper”、“Technical Deep Dive”标签的栏目。这里发布的是模型架构图、训练数据构成、消融实验结果等硬核内容，比如某厂在博客里公开了其MoE架构中专家路由的top-k算法伪代码，这就是调优时的关键依据。第三是 Documentation（文档中心） ，常被忽略，但它包含部署指南（Docker镜像tag、GPU显存要求）、安全合规说明（GDPR数据处理流程图）、以及最重要的—— 变更日志（Changelog） 。我见过太多团队因没看Changelog，在升级SDK后发现某个字段类型从string变成了object，导致下游服务崩溃。第四是 Whitepapers & Reports（白皮书与报告） ，通常在“Resources”或“Insights”栏目下，PDF格式，包含模型能力评测方法论、基准测试结果（如MMLU、GSM8K的详细分数）、以及最关键的—— 商用限制条款（Commercial Use Restrictions） ，比如是否允许用于SaaS产品、是否禁止转售API调用等。第五是 GitHub Organization（GitHub组织页） ，不是单个仓库，而是整个组织主页（如github.com/xxx-ai），这里能看到所有开源项目、模型权重发布仓库、以及最重要的—— Issue Tracker 。很多厂商会在Issue里回复用户关于API行为的疑问，这些回复具有事实效力，比如某厂明确回复“/v1/chat/completions endpoint目前不支持streaming mode”，这就是比文档更及时的确认。

2.2 识别“伪一手”：3个信号教你一眼识破无效链接

不是所有看起来像官网的链接都是有效一手源。我在整理过程中筛掉了超过200个“伪一手”链接，总结出三个高危信号。第一个是 路径异常 ：真正的官网文档URL通常结构清晰，如 https://api.xxx.com/docs/v1/chat ，而伪一手链接常带 /blog/2024/03/15/xxx-model-release 这种长日期路径，这往往是CMS系统自动生成的新闻稿，内容已被编辑加工。第二个是 元信息缺失 ：打开页面后，按Ctrl+U查看源码，搜索 <meta name="author" 或 <link rel="canonical" 。一手信源必然有明确的作者署名（如“XXX AI Research Team”）和规范的canonical URL指向自身；而伪一手页面常为空，或指向其他媒体域名。第三个是 交互功能缺失 ：真正的API文档页必然有“Try it out”按钮、参数下拉选择器、实时响应预览框；而伪一手页面只有静态文字和图片。有一次我遇到一个链接，表面看是某厂的“Model Card”，但点开后没有版本号、没有数据集链接、没有评估指标表格，只有两段宣传文案，一查源码发现canonical URL指向一个科技媒体子域名——这就是典型的“挂羊头卖狗肉”。

3. 清单结构设计：按信息类型分层，而非按厂商罗列

如果只是把37家厂商的官网链接堆在一起，那和百度搜索结果没区别。这份清单的核心价值在于 按信息类型重构认知框架 ，让你摆脱“找A厂资料→找B厂资料”的线性思维，建立“我要查API SLA→所有厂商的SLA在哪”的网状检索能力。因此，我将其分为四大信息层，每一层都对应一个具体决策场景。

3.1 第一层：API与服务级信源——工程师每天要敲的命令行背后

这一层解决“怎么调用、有什么限制、出错了找谁”的问题，是技术落地的第一道门槛。它包含三个子类：首先是 API Reference与SDK ，这是最基础的。我不仅收录了主API文档链接，还特别标注了每个厂商的“版本管理方式”：比如A厂采用语义化版本（v1/v2），每次大版本更新会破坏性变更；B厂则用日期版本（2024-03），强调向后兼容。这种差异直接影响你的SDK升级策略。其次是 服务等级协议（SLA）与计费细则 ，这是最容易被忽略的“法律层”。我专门建了一个表格，横向对比了12家提供商用API的厂商，列出了他们的SLA承诺项（如API可用性99.9%）、未达标补偿方式（信用额度还是服务延期）、以及最关键的—— SLA的适用范围 。例如，C厂的99.9%只适用于/v1/completions endpoint，而/v1/embeddings endpoint不在此列；D厂则明确写出“SLA不涵盖因用户输入超长导致的超时”。第三是 错误代码与故障排查指南 ，这不是简单的HTTP状态码列表。比如E厂的文档里，429错误被细分为429-1（超出rate limit）、429-2（超出concurrent request limit）、429-3（超出daily token quota），每种都配有具体的修复建议和监控指标。我在清单里为每个错误码都加了简短注释，告诉你“看到这个码，第一步该检查什么”。

3.2 第二层：模型与技术级信源——产品经理写PRD时要引用的硬数据

这一层支撑“为什么选这个模型、它到底强在哪、有哪些隐藏缺陷”的论证。它聚焦于模型本身的技术属性。首先是 模型卡（Model Card）与技术报告 ，我坚持只收录PDF格式的原始报告，因为HTML版常被动态渲染，内容可能随时间变化。每份报告我都标注了其核心数据维度：训练数据量（TB级还是PB级）、参数量（是否包含MoE中的专家数）、上下文长度（是原生支持还是通过RoPE外推）、以及最关键的—— 评估基准的完整度 。比如F厂的报告只测了MMLU，而G厂则同时公布了MMLU、GSM8K、HumanEval、MT-Bench四组数据，后者显然更具参考价值。其次是 开源模型权重与训练脚本 ，这不仅是给研究人员的，更是给工程团队的“可信验证通道”。当某厂宣称其模型支持128K上下文时，开源的config.json文件里 max_position_embeddings 字段就是铁证；当他们说“使用RLHF优化”，开源的training_script.py里就能看到reward model的架构和训练轮数。我在清单里为每个开源仓库都写了“可验证点”，比如H厂的仓库里， model_config.yaml 第47行定义了attention dropout rate，这就是调优时的锚点。第三是 模型安全与偏见评估报告 ，这是合规审查的刚需。I厂的报告不仅给出整体bias score，还按性别、地域、职业等12个维度拆解了prompt响应偏差率，并附上了用于测试的prompt模板——这意味着你可以用同样的模板测试自己的微调模型，做横向对比。

3.3 第三层：商业与法律级信源——法务和销售签合同前必读的条款

这一层决定“能不能用、怎么用才合法、出了事谁担责”。它超越技术，直指商业本质。首先是 商用许可协议（Commercial License） ，我将其细分为三类：完全开源（如Apache 2.0，可商用无限制）、有限商用（如需单独申请、禁止转售）、和闭源商用（仅限API调用，禁止下载权重）。对每一份协议，我都提取了核心条款并做了通俗解读，比如J厂的协议里有一条“Prohibited Use Cases”，明确列出“不得用于自动化法律文书生成”，这就直接否决了某律所的立项计划。其次是 数据隐私与处理政策（Data Processing Agreement, DPA） ，这是GDPR和国内《个人信息保护法》落地的关键。K厂的DPA PDF里，第3.2条明确规定“客户上传的prompt数据在24小时内自动删除，不用于模型再训练”，而L厂的DPA则写“数据可能用于改进服务质量”，后者就需要客户额外签署数据豁免条款。第三是 服务条款（Terms of Service）中的责任限制 ，这是风险兜底条款。M厂的ToS第7.4条写着“服务商不对因模型输出错误导致的间接损失承担责任”，而N厂则承诺“对因API服务中断导致的直接业务损失，按当月费用200%赔偿”。这种差异，直接决定了你在合同里要不要加“AI输出审核”义务条款。

3.4 第四层：生态与集成级信源——ISV和解决方案商构建产品的基石

这一层面向“如何把大模型能力嵌入现有系统”的集成者。它关注的是连接性与扩展性。首先是 官方插件与工具链 ，比如O厂的VS Code插件，其GitHub仓库的README里明确写了“支持本地模型加载，需配置 local_model_path 参数”，这就是私有化部署的关键线索；P厂的Postman Collection，不仅包含API请求示例，还内置了环境变量模板（如 {{api_key}} ），可直接导入团队协作。其次是 云平台集成文档 ，这不是泛泛而谈的“支持AWS”，而是具体到“在AWS SageMaker中部署的AMI镜像ID”、“Azure Marketplace中的SKU编号”、“阿里云镜像市场的更新频率”。Q厂的文档里，甚至给出了在Terraform中创建推理集群的完整代码块，包含GPU型号、网络配置、IAM权限策略。第三是 行业解决方案白皮书 ，这是最易被忽视的宝藏。R厂发布的《金融风控场景大模型应用指南》里，不仅描述了方案架构，还附上了真实脱敏的prompt engineering模板（如“请以监管报告格式，分析以下交易流水的可疑点”），以及对应的评估指标（如“监管报告生成准确率需≥92%”）。这些不是理论，而是可直接复用的行业Know-How。

4. 实操过程：如何用这份清单完成一次完整的竞品技术尽调

光有清单不够，得知道怎么用。我以一次真实的金融客户竞品尽调为例，演示全流程。客户需要评估三家厂商（A、B、C）的模型在“财报摘要生成”任务上的可行性，核心诉求是：1）支持100页PDF输入；2）输出符合证监会格式要求；3）API调用延迟≤3秒；4）商用授权明确允许SaaS分发。

4.1 步骤一：锁定信息源，5分钟内完成初筛

打开清单，先定位到“API与服务级信源”层。对A厂，我找到其API文档页，快速扫描三个关键点：在“Input Limits”章节，确认其 /v1/document/summarize endpoint支持最大128MB文件（满足PDF页数）；在“SLA”表格中，看到其“P95延迟承诺为2.8秒”（满足≤3秒）；在“Commercial License”链接里，PDF第2页明确写着“Permitted for SaaS Resale”。A厂初步过关。对B厂，其API文档里“File Upload”部分只提到“支持PDF”，但没写大小限制；我立刻切到“模型与技术级信源”层，找到其技术报告PDF，第15页的“Data Preprocessing”章节指出“文档解析模块最大处理10MB”，这意味着100页PDF大概率超限。B厂出局。对C厂，其SLA表格显示“P95延迟为5.2秒”，不满足要求，但我在“生态与集成级信源”层发现其提供了“Edge Inference SDK”，文档里写着“本地部署时P95延迟可降至1.9秒”，这意味着需放弃纯API方案，改用私有化部署。C厂进入第二轮。

4.2 步骤二：深度验证，用原始文档交叉印证

对A厂和C厂，进入深度验证。目标是确认“证监会格式要求”的适配性。我打开A厂的“行业解决方案白皮书”，在“金融”章节找到“财报摘要Prompt Template”，复制其示例prompt：“你是一名资深证券分析师，请根据以下财报数据，生成一段不超过300字的摘要，重点突出营收增长率、净利润率和现金流变化，并用【】标出关键数字。” 我用这个prompt调用A厂API，输入测试财报，结果符合预期。再查C厂，其白皮书里没有金融模板，但我在其GitHub仓库的 examples/finance/ 目录下，找到了一个 sec_filing_summary.py 脚本，里面硬编码了类似的prompt结构。我运行脚本，结果也合格。但这时我注意到C厂脚本的注释里写着“Requires v2.3.1+ SDK”，而客户当前用的是v2.2.0，这意味着必须升级——这就是一手信源带来的精准决策依据。

4.3 步骤三：风险闭环，法律条款逐字比对

最后是法律闭环。A厂的商用许可PDF第4.1条写着：“Licensee may sublicense the Service to End Users as part of a hosted application.” 这里的“hosted application”是否包含SaaS？我查其术语表（Glossary），第2页定义为“a software application delivered over the internet, where the Licensor hosts and manages the application.” 完全匹配。C厂的许可则更复杂，其PDF第5.3条写着：“Distribution of Model Outputs is permitted only if accompanied by prominent attribution to [C Company].” 这意味着客户的产品界面必须永久显示C厂Logo，这可能影响品牌一致性。我把这两条原文截图，连同出处页码，一起放进尽调报告。整个过程，从初筛到闭环，耗时47分钟，所有结论都有原始链接和页面截图支撑，客户法务当天就签字确认。

5. 常见问题与避坑指南：那些没写在文档里的真相

整理这份清单的过程中，我记录了23个高频问题，它们大多不会出现在官方文档里，却是实操中绊倒最多人的“暗礁”。

5.1 关于API文档：你以为的“稳定”其实是厂商的“策略性留白”

问题：为什么某厂的API文档里， temperature 参数范围写的是“0.0 to 1.0”，但实际传0.01会报错？

真相：这不是Bug，而是厂商的流量调控策略。我通过抓包和反复测试发现，该厂对 temperature=0.0 的请求做了特殊路由，强制走高优先级队列，但队列容量极小。当并发超过5QPS时，就会返回503。文档写“0.0 to 1.0”是技术上正确，但没写“0.0有并发限制”。我的应对方案是：在清单里为该参数加了“⚠️ 实测并发阈值：5 QPS”，并备注“若需更高并发，建议用 temperature=0.001 替代”。

5.2 关于模型卡：PDF里的“SOTA”可能只在特定条件下成立

问题：某厂模型卡宣称在MMLU上达到92.3%，但我们的测试只有85.1%，差距在哪？

真相：模型卡里的92.3%是在“5-shot”设置下测的，而我们用的是“0-shot”。更关键的是，该厂在附录的“Evaluation Details”里写了“使用了custom prompt template with chain-of-thought”，而这个template并未开源。我最终在该厂GitHub的issue #456里，找到工程师回复：“The CoT template is internal; public eval uses standard prompts, score ~86.5%”。所以，官方数据和你的实测，差的就是那个没公开的prompt。我的清单里，对每个模型卡都标注了“评估设置”，如“MMLU: 5-shot, custom CoT prompt (not public)”。

5.3 关于商用许可：一个标点符号决定法律效力

问题：某厂许可协议里写着“Free for commercial use.”，但客户用了却被追责，为什么？

真相：原文是“Free for commercial use.”，注意句末是英文句号。而该厂在另一份《FAQ》PDF里解释：“The period indicates this clause applies only to the preceding sentence about API access. Model weights require separate license.” 这就是典型的“标点即法律”。我的清单里，对所有许可条款，都强制要求截图原文，并在旁边用红框标出关键标点和上下文句子。

5.4 关于GitHub：Star数不是质量指标，Issue活跃度才是

问题：某厂GitHub仓库有12k Star，但模型效果一般；另一家只有200 Star，却更可靠，为什么？

真相：Star数反映的是营销力度，而Issue的回复速度和质量反映的是工程文化。我统计了12家厂商的GitHub：A厂Star 8k，但近30天Issue平均响应时间47小时，且30%的Issue被标记为“wontfix”；B厂Star 320，近30天Issue平均响应时间2.3小时，且所有“bug”类Issue都在24小时内确认并给出临时修复方案。我的清单里，“GitHub”条目下，除了链接，必写“近30天Issue平均响应时间”和“关键Issue处理状态”，比如“#1234: Confirmed latency bug in v2.1, fix scheduled for v2.2.0”。

5.5 关于技术博客：发布时间比内容更重要

问题：某厂博客写着“全新推理引擎，性能提升3倍”，但我们的压测只看到1.2倍，怎么回事？

真相：该博客发布于2024年3月1日，而其GitHub release page显示，相关优化代码直到3月15日才合并进main分支。也就是说，博客发布时，技术尚未上线。我后来发现，该厂有“Preview Blog”传统——先发博客造势，再等代码成熟。我的清单里，对每篇技术博客，都强制关联其对应的GitHub PR链接和Merge时间，并计算“Blog-to-Code Delay”，如“Blog: 2024-03-01 | PR Merged: 2024-03-15 | Delay: 14 days”。

提示：不要迷信“最新发布”，要查“最新代码”。所有声称“已上线”的技术，必须能在GitHub release或Docker Hub tag里找到对应版本。

注意：厂商的“开发者关系”团队和“产品团队”常有信息差。博客由DevRel写，但API变更由产品团队定，两者节奏不同。我的清单里，对每个API变更，都同时标注“Blog Announcement Date”和“API Docs Update Date”，当两者相差超过7天，我会加“⚠️ 同步延迟预警”。

6. 维护机制与更新原则：如何让这份清单持续保鲜

这份清单不是一次性交付物，而是一个活的系统。我建立了三重维护机制，确保它不变成“古董”。

6.1 自动化监控：用最少的人力守住底线

我用Python写了三个轻量脚本，每天凌晨执行：第一个是 链接健康检查 ，用HEAD请求遍历所有URL，记录404/503状态码，并自动邮件告警；第二个是 文档更新监测 ，对所有PDF和HTML文档，定期抓取 <meta name="modified" 或 Last-Modified 头，对比上次哈希值，有变更即触发人工复核；第三个是 GitHub活动追踪 ，监听指定仓库的release事件和issue创建事件，一旦有新tag或高优先级issue，立即加入待审队列。这三个脚本加起来不到200行代码，但守住了90%的时效性风险。

6.2 人工复核规则：什么必须改，什么可以缓

自动化只能发现问题，判断是否需要更新，靠的是明确规则。我定了三条铁律：第一，“ 核心参数变更必改 ”——只要API Reference里新增/删除/修改了任何参数、状态码、错误类型，无论多小，24小时内更新；第二，“ 法律条款修订必改 ”——商用许可、DPA、ToS的任何文字增删，48小时内更新并标注变更点；第三，“ 重大模型发布必改 ”——新模型上线、旧模型EOL（End of Life）、技术路线重大调整（如从Transformer转向Mamba），72小时内更新，并补充影响分析。其余如博客更新、非核心文档修订，纳入周度批量复核。

6.3 用户反馈闭环：把你的痛点变成清单的进化点

清单开放了轻量反馈通道（一个简单的Google Form），但关键是我设计了反馈过滤机制。所有提交，我先用规则引擎打标：如果反馈含“404”、“Not Found”、“Link Broken”，归为“链接失效”；含“Outdated”、“Old Version”、“No Longer Valid”，归为“内容过期”；含“Missing”、“Can't Find”、“Need This”，归为“信息缺口”。每周五，我花一小时处理这些标签，高优问题当天解决，低优问题放入季度更新计划。上个月，一位用户反馈“找不到某厂的中文版DPA”，我查后发现该厂只在.cn域名下发布中文DPA，而清单里只收录了.com链接——这直接推动我增加了“多语言版本”字段。

我个人在实际使用中发现，最有效的维护不是追求“100%覆盖”，而是确保“关键路径100%可靠”。比如，当客户问“某厂API现在支持JSON Schema输出吗？”，我必须能立刻给出答案，而不是说“我查查”。这份清单的价值，正在于把这种“立刻回答”的能力，从依赖个人记忆，变成了可共享、可验证、可传承的团队资产。它不教你如何写prompt，但能确保你写的每个prompt，都跑在一条信息透明、权责清晰、风险可知的轨道上。