【实战进阶(2/4) 】IDE工具、GitHub、API、环境变量
2282 人学过
七、IDE类AI编程工具速通
正文
IDE 是 Integrated Development Environment 的缩写,中文叫集成开发环境。
简单理解: IDE 就像是程序员的"全能工作台",把写代码需要的所有工具都集成在一个软件里。
我们看看常见IDE类AI编程工具的界面。
不要被吓到,看个大概先。
TRAE
Cursor
CodeBuddy
VS Code + Codex
……
Windsurf
你发现了吗? 它们其实是一回事!
我们可以一通百通。
下面我们用大白话来解释,为什么他们是一回事!
大白话,一通百通
无论它们是黑色的还是白色的、 聊天窗口在左边还是右边, 它们至少有以下4个重要的区域!!
记住这4个区域的功能! 在不同工具当中,它们可能位置不同,但是你一定能找到!!
如下图!
四个区域分别的功能,我整理了一个表格
掌握这四个区域,你就掌握了所有AI编程工具
记住这个万能公式:
写代码 = 文件导航(找文件) + 编辑区(预览代码修改) + AI聊天(说需求、提问) + 终端(跑程序)
实战小技巧:
1.
新手阶段:重点用"AI聊天区",让AI帮你生成代码
2.
进阶阶段:学会在"编辑区"改代码,在"终端"看运行结果
3.
熟练阶段:四个区域配合使用,效率翻倍
不同工具的区别只是:
•
位置不一样(有的AI在左边,有的在右边)
•
颜色不一样(有的是深色主题,有的是浅色)
•
快捷键略有不同(但都能自定义)
核心功能都一样!学会一个,其他的上手只需要5分钟!
作业
回到本节开头,各个AI编程工具的截图。 分别找出这4个区域、在它们中的位置!
八、使用GitHub做源代码管理:跟全世界程序员接轨【重要】
什么是 GitHub?为什么要用它?
这一课非常重要,学会了GitHub和Git,你就和全世界的程序员接轨了。
不要被这些奇怪的单词吓到,你先记住一句话: GitHub = 代码的网盘
GitHub 是全世界最大的开源社区。如果你想找一个开源软件,请先到 GitHub 找。
当你能够熟练的使用 GitHub,你就离成为合格的程序员近了一大步!请千万不要错过!
此外,我们还需要它……
想象一下,你和朋友一起写一个故事,但你们住在不同的地方。你们可能会遇到这些问题:
•
谁改了哪些部分?
•
两个人同时修改了同一段怎么办?
•
我今天突然对上周我写作的所有内容不满意,想要回滚到上周一的那一版,怎么办?
GitHub 就是为解决这些问题而生的,只不过它是为代码设计的(当然,也可以用于管理其他文件,我了解到也有人用 GitHub 来管理写书的)。
简单来说,GitHub 有这些作用:
•
保存所有历史版本:就像游戏的存档点,随时可以回到过去的任何一个版本
•
备份代码:代码保存在云端,电脑坏了也不怕
•
多人协作:多人可以同时修改,然后合并各自的修改
GitHub 基础概念
在开始实际操作前,我们先了解几个基本概念。别担心,我会用生活中的例子来解释:
仓库(Repository):就像一个特殊的文件夹,里面包含了你的项目文件和所有的修改历史。
生活例子:想象它是一个魔法相册,不仅保存了最新的照片,还记录了每张照片所有的修改过程。
提交(Commit):相当于保存一个新的版本,并添加说明。
生活例子:就像在写日记,"今天我修改了第三段的错别字,并添加了一个新角色"。
分支(Branch):同一个项目的不同版本线。
生活例子:想象你在写一本书,不确定结局应该是大团圆还是悲剧,所以你复制了一份手稿,在两个版本上分别尝试不同的结局。
拉取请求(Pull Request):请求把你的修改合并到主项目中。
生活例子:你在朋友的食谱上做了改进,然后问:"嘿,我加了点香料,你要不要也加到你的食谱中?"
克隆(Clone):复制一份仓库到你的电脑上。
生活例子:借一本书回家,你可以在家里看和做笔记,之后再把你的笔记分享给大家。
推送(Push):把你本地的修改上传到 GitHub。
生活例子:把你修改后的食谱发给所有的朋友。
拉取(Pull):从 GitHub 上下载最新的修改。
生活例子:从群聊中获取朋友们最新分享的照片。
账号设置与第一步
注意:GitHub是境外网站。如果你打不开,可能需要配置海外上网环境。如有需要,可求助助教。
1.
打开 GitHub 官网
2.
点击右上角的"Sign up"(注册)
3.
填写用户名、邮箱和密码
4.
验证你不是机器人(通常是选择图片或者输入验证码)
5.
选择免费计划(Free)
6.
完成一些简单的兴趣调查(可跳过)
7.
验证你的邮箱(GitHub 会发送一封验证邮件)
8.
设置个人资料
登录后,点击右上角的头像,选择"Your profile"(你的个人资料),然后点击"Edit profile"(编辑资料)。这里你可以:
•
上传头像
•
添加个人简介
•
设置你的位置、个人网站等
在 TRAE 里使用 GitHub
激活源代码管理功能
1.
在 TRAE 中打开你的项目。
2.
从左侧的导航栏中,选择 源代码管理。
界面上显示 源代码管理 面板。
激活源代码管理功能。根据实际需求,从以下方式中选择:
•
若当前打开的文件夹中没有 Git 仓库,点击 初始化仓库 按钮以初始化一个仓库
点击后。
注意界面变化:
•
左侧的数字: 本次修改了多少个文件
•
中间的输入框:让你输入本次主要修改了什么内容,你可以输入“第一次提交代码”
•
输入框右边的星星: 如果你懒,可以点击那个星星,让AI帮你生成“本次代码修改了什么”
完成后,点击“提交”
然后你会看到这个界面
发布项目到GitHub
初始化完成后,该项目便激活了源代码管理功能。
•
点击 发布Branch 按钮 ,直接将此文件夹发布到 GitHub 仓库。
如果还没在TRAE里登录GitHub账号,可能会出现下面的界面,提示你登录。照做就行,很容易。
然后界面会出现这样
•
第一行输入框:让你输入仓库的名字(英文的),它默认是当前文件夹名。建议你修改成自己能看懂的,拼音也行,但是不允许中文
•
第二行和第三行:你需要选择一个,由你决定这是一个私有项目(Private repository)还是公开项目(public repository)。私有项目就是只有你自己能看,公开项目就是全世界所有人的人都能看到你的源码。这里我们先选择private repository
发布完成后,TRAE右下角会弹出提示框告诉你。
点击“在GitHub上打开”,就可以在GitHub网站上看到你的自己项目仓库了!!
修改代码再次提交
我们在TRAE里做一点小的修改,比如
Plain Text
把首页标题改成紫色可以看到,我们的标题,已经是紫色了
注意看源代码管理区域!!看下图
•
源代码管理区域出现了数字1,说明修改了1个文件
•
被修改的文件变了一个颜色
•
打开被修改的文件,发现有一行绿色的、有一行红色的。
◦
红色 = 被删除的行
◦
绿色 = 被新增的行
◦
修改 = 删除旧的、新增新的。
我们再切换到源代码管理区域,提交刚才的更改
点击“提交”以后,还需点击“同步更改”。
“同步更改”的意思是: 把你电脑上的修改,同步到GitHub的云端仓库当中。
小Tip:一般来说,“提交更改”可以频繁一点,但是“同步更改”不用太频繁。我们可以多提交一些更改在本地,确认无误后,再“同步更改”到云端。
这个时候在打开你的GitHub.com上的仓库,会看到刚刚提交的这笔代码!如此这般,你的新代码也存到网盘里了!!
查看每次代码记录
上面反复强调,GitHub = 网盘。
网盘,意味着有全部的记录。
你可以在TRAE里查看,如下图所示
也可以在GitHub.com上面查看
在GitHub Desktop中使用Git
除了在TRAE中使用Git以外,小白还可以用GitHub Desktop来操作Git,也很方便。
GitHub Desktop:小白使用 GitHub 的救星
虽然很多教程会教你使用命令行来操作 Git,但对于初学者来说,这可能会很困难。别担心,GitHub Desktop 就是为我们这样的人准备的!
1.
下载和安装 GitHub Desktop
2.
3.
下载适合你操作系统的版本(Windows/Mac)
4.
安装程序
5.
打开 GitHub Desktop,用你的 GitHub 账号登录
用GitHub Desktop打开项目
打开GitHub Desktop,
点击右上方File → Add Local Repository (添加本地仓库)
选中我们的项目文件夹
同样可以看到我们项目的所有代码历史!
后悔药
刚才反复强调,GitHub就是一个网盘。既然是网盘,那肯定是可以回滚的吧?
我们可以在最新一次提交“标题改成紫色”上点击右键,选择 Revert Changes in Commit
马上可以看到,我们已经回滚了!标题不再是紫色了
当然,如果我们决定“把标题改回成以前的颜色”,这本身也是一次更改。
如果你想要同步这次更改到GitHub,那就需要再次在TRAE里点击“同步更改”
你也可以在GitHub Desktop里点击 Push。 两者是同样的效果。
毕竟我们打开的是同一个仓库,无论是用哪个工具,都可以实现同样的操作,两边完全是相通的。
常见问题
使用 GitHub 的过程中,你可能会遇到一些问题。别担心,这很正常!这里是一些常见问题和解决方法:
1、推送被拒绝
问题: 你尝试推送更改,但 GitHub 拒绝了。
解决方法: 这通常是因为 GitHub 上有你本地没有的更改。先执行"拉取"操作,然后再尝试推送。
2、合并冲突
问题: 拉取时,GitHub 说有"合并冲突"。
解决方法: 这意味着同一个文件的同一部分被不同人修改了。在 GitHub Desktop 中,你会看到冲突的文件。打开这些文件,你会看到冲突的部分被特殊标记。编辑文件以保留你想要的内容,然后提交这个合并。
3、忘记了提交某些文件
问题: 你已经推送了,但发现忘记添加某些文件。
解决方法: 没关系!添加这些文件,进行新的提交,然后再次推送。
4、想撤销最后一次提交
问题: 你提交了错误的内容,想要撤销。
解决方法: 在 GitHub Desktop 中,点击"历史"标签,右键点击最近的提交,选择"Revert changes in commit"(撤销提交中的更改)。
干中学
•
练习 GitHub 教程中的实操教程,在TRAE中多修改几次自己的代码,反复熟悉提交代码、同步更改、回滚代码的过程
•
尝试把前面课程的其他项目,也使用 GitHub 管理起来。
附A:GitHub 界面介绍
为了让你在本环节充分彻底的掌握 GitHub,让我们来学习 GitHub 的整个界面操作
Git 和 GitHub
我们先来了解一下 Git 和 GitHub 是什么,有什么功能
先说结论,Git 和 GitHub 是两个东西,Git 是一个软件/工具/系统,GitHub 是一个网站/平台,GitHub 这个网站使用了 Git 这个工具。
Git 是一个分布式版本控制系统。
版本控制系统(version control system)像个数据库,它会记录所有对项目文件的更改(比如一个文件,前天加了三段文字,昨天删了一句话,今天改了几个词,这三个版本历史都能保存下来)。 版本控制系统不仅可以应用于软件源代码的文本文件,而且可以对任何类型的文件进行版本控制。
使用版本控制系统可以协同合作(多人编辑文件或代码而不出错),版本存储(你改动的每一版本都保存下来,如果改错可以回到之前的版本,如果想加上删除的内容也可以返回去找,也可以对比现在和之前的版本,看改了什么),文件备份(服务器和本地都有完整的历史版本,如果服务器坏了,本地还有一份完整的历史记录)。
总之, Git 可以避免文件丢失,改错,多人合作不同步导致的后果 。
GitHub 是通过 Git 进行版本控制的软件源代码托管服务平台,可以理解成放代码的地方,但往上放代码时用 Git 进行了版本控制。也就是 GitHub 使用了 Git 完成版本控制,下面来看看 GitHub 有哪些有用的功能!
代码托管:可以单纯地把它当成一个网盘放你的代码,同时使用 Git 功能记录你的代码历史。当然除代码外还能放其他文件。
学习优秀的开源项目:学习别人优秀的源码,写代码之前看别人是怎么写的(比如写作业的时候参考参考),看论文也可以上 GitHub 找源代码,还能找一些开源的软件,插件用。
当资料库:可以查资料,GitHub 上有总结好的面试宝典,入门指南,技术分析,论文合集,课程资料等。这些博客、公众号上有的内容 GitHub 上也有,还可能更全。
多人协作:多个人要一起写个程序,一起写本书,一起翻译一篇文章等,用 GitHub 可以管理项目保证你们的文件同步,写好后提交合并成一个完整的项目。
搭建博客:基于 GitHub Pages 搭建属于你的博客,你可以随心所欲的定制自己的样式,这是一个属于你的空间。
社交:就像微博、知乎一样,在这个网站你可以关注(following)别人,也可以有自己的粉丝(followers),看到好的开源项目可以给他点赞(star),你有啥想法还可以给这个项目改进改进(fork)。
个人简历:如果你的 GitHub 上有不错的项目,或者你改进过别人的项目,这些都能反映到你的账号上。GitHub 一定程度可以反映你的能力,如果你的项目点赞多(star),还有很多粉丝关注(followers),你就像个大 V 一样,这就是你的另一份简历。
写作:Gitbook 可以写电子书。
GitHub 能做的还远不止这些,等待你的探索发现!
虽然网站都是英语,但模块不是很多,跟着下面的教程就能学会,用几次就会了;网站有很多中国用户,所以你可以搜到很多中文资源,不用担心语言问题 ~
总结:无论你是不是程序员,你都可以用 GitHub。你可以把它当个网盘存包括代码的文件,可以和团队一起做个项目(文件啥的就不用保存一堆迭代版本啦),可以找资源(里面有很多宝藏资源),可以建个博客,也可以像在微博、知乎、博客一样,分享你的东西。
主界面
登录状态下,网站主界面如下:
首先我们来看页面最上方的灰色条
1.最左侧为导航栏
2.点击后展开目录清单
目录展开的按钮,我们会用到的功能如下:
Home :进入你的 GitHub 主页,查看动态、推荐项目、关注人的更新等。
Projects :项目管理工具。可以用看板(类似 Trello)方式管理任务、进度和优先级,适合团队协作。
Repositories 区域 :显示你常用或最近访问的代码仓库(项目),点击可以快速进入对应项目。
3.左边是 GitHub 的 logo,点它就返回现在这个主界面
4.搜索框,和搜索引擎一样用来搜索(搜源码,搜资料)
5.GitHub 的对话 ai 助手
6.新建,初期常用的是新建仓库 New repository
再来看看下面的一大块
•
左边是你的项目
Repository:翻译为仓库,也是你的项目。
你可以理解成一个大的文件夹,或者笔记本。一个项目对应一个 Repository。
•
中间是 Home 和 Feed 功能,用于帮助你快速了解项目动态、获取学习资源
Home 是你的个人工作台,聚合常用入口和学习资源,提升效率。
Feed 是你的信息流,帮你追踪社区动态、发现新项目,保持技术敏感度。
•
右侧的“Latest changes”和“Explore repositories”用来了解发现优质开源项目
Latest changes(最新变化) :可以第一时间看到 GitHub 推出的新特性、修复的 bug、重要的安全提示等
Explore repositories(探索仓库) :这里会推荐一些优质、热门或与你兴趣相关的开源项目(Repository)
个人界面
右上角那个头像就是个人
1.点击个人头像,展开个人目录
2.个人目录详情
目录展开后,我们会用到的功能
Your profile:查看和编辑你的 GitHub 个人主页,包括头像、简介、项目展示等。
Your repositories:快速访问你拥有或参与的所有代码仓库(项目)。
Your projects:查看和管理你创建或参与的项目管理面板(Project),用于任务规划和进度跟踪。
Your stars:查看你“收藏”过的项目(Starred repositories),方便以后快速找到感兴趣的开源项目。
Your organizations:查看你加入的所有组织(Organization),适合团队或公司统一管理多个项目和成员。
GitHub 官方支持区域
Settings:进入个人设置页面,管理账号信息、安全、通知、API 密钥等。
Sign out:退出当前 GitHub 账号,安全登出。
在这里详细展示下我们的常用功能
3.点击 your profile
4.可以查看个人在 GitHub 中活动的详细信息
5.点击 repositories
6.查看个人在 GitHub 上已经创建的仓库
7.点击 setting
8.进入设置界面,GitHub 的通用型设置在此完成
9.点击 GitHub community
10.浏览开源项目,查找自己需要的项目
项目界面
下面我们看看项目界面。
我们使用 GitHub ,无论存放东西,还是查资料,主要都是看自己或别人的项目/仓库,所以这个界面一定要熟悉。
你可以通过搜索项目、点击别人的界面、推荐页面打开一个项目。
我们以 Python 为例介绍界面,你可以在搜索框输入 Python 搜索,选择第一个项目,看点赞数就知道它是最欢迎的一个。
点进去就是项目/仓库界面啦,我们认识一下主要功能
首先项目标题的一条我们可以看到这个仓库的信息,像关注点赞都是按钮,点击可以看具体的人。
这里涉及到两个新词语。
•
Watch:关注观察 ,也就是你既可以关注(follow)一个人,也可以关注(watch)一个项目,你关注内容的动态都会显示在主页面。
•
Fork:直译是刀叉,它是指将 GitHub 的某个特定仓库(所有文件)原封不动地复制到自己的账户下。比如你想改进这个项目,加点儿自己的东西,就可以复制一下整个仓库再修改,但是不影响原作者的仓库,你点击 Fork 就能复制。
最上方是标签页,比如默认的一个标签页 Code 就是展示代码的页面;如果你想看别人提的问题就点击 Issues 页,也许你遇到的问题别人提过并且解决了;有的人想参与这个项目,他改好后就向作者发起了 Pull Requests,希望作者接受他的改进,点进去可以看谁提交过什么样的改进,作者是否采纳。
下面这个主要部分就是仓库里的东西了,你可以看到就是一个个文件夹或文件,里面可能是代码文件,也可能是其他文档,图片什么的。
点击可以看,你也可以点击 Clone or downloads 下载到本地,具体学习。
滑到最下面,可以看到一个叫 README.md 的一段文字,仔细看,它就是仓库里的一个文件,只不过展示出来了。它就像产品说明书,或者是一个介绍页,告诉你这个仓库的有关信息,让你对仓库有了简单的了解。
以后你要建个仓库(Repository),为了方便别人了解,也要写这样的文件。
附B:GitHub Trending
什么是 GitHub Trending?
GitHub Trending 就是 GitHub 的“热榜”。
它会按时间维度(Today / This week / This month),展示近期增长最快的开源项目和开发者。
你可以把它理解成:
程序员世界的热搜榜 + 新工具发现器。
为什么要看 GitHub Trending?
看 Trending 不只是“凑热闹”,是为了了解全世界开发者的动态!
1.
找方向:知道最近什么技术在爆发。
2.
找轮子:很多功能不用重造,直接复用开源项目。
3.
找灵感:你下一节课、下一个产品 idea,往往就藏在这里。
4.
找学习样本:看高手怎么组织代码、写文档、做版本迭代。
怎么用
2.
选择时间范围:Today / This week / This month
3.
选择语言:比如 TypeScript、Python
4.
先点进项目看这 4 个地方:
•
README(项目到底干啥)
•
License(能不能商用)
•
Releases(是否持续更新)
•
Issues(是否有人维护)
看到热门项目后,试一试
用GitHub Desktop下载项目到自己电脑,再用TRAE打开它,试试自己能不能跑起来!
九、去API超市进货:给你的产品加上现成的AI超能力【重要】
前言:
上一课我们学会了用 GitHub 管理代码,解决的是"代码怎么管"。
这一课我们解决的是另一个核心问题:产品能力从哪来?
答案很直接:
你现在做 AI 产品,绝大多数情况下,不需要自己训练模型。
你真正要学的是——去 API 超市进货。
和我们之前用扣子编程的区别是,我们在扣子编程的环境里,所有的API都被扣子编程“内置集成”了。
对于新手来说,使用很方便,
但是另一方面,我们被限制在扣子编程生态里,没办法用更多世界上的API。
因此这节课,我们要告诉你:怎么去主流的API超市里面去挑选符合自己的API.。
要知道,这世界上的API种类很多,远远不止扣子编程提供的那些。😄
一句话先记住:
做 AI 产品 = 选 API + 调 API + 换 API。
这节课你会完成什么?
这节课你要完成 3 个目标:
1.
认识主流 API 平台:OpenRouter、fal.ai、火山引擎
2.
学会 API 四要素,用 Postman 跑通一次调用
3.
把你项目里 coze sdk 默认 API,替换成其他 API(本课演示火山引擎)
这三件事做完,你就具备了一个核心能力:API 平台可替换能力。
以后你不会被某一家平台绑死。
一、再谈API和API平台
什么是API?
API就是Application Programming Interface(应用程序编程接口)。
简单理解:API就像餐厅的菜单。
•
你不需要知道厨房怎么做菜
•
你只需要看菜单,点你想要的菜
•
厨房按照你的要求做好菜,端给你
我们所谓的“API超市”,其实是“API平台”,我们先用“超市”来打比方,方便理解。
你可以把 API 平台理解成"能力超市"。
•
你要给产品增加聊天能力(比如前面的“互联网黑话翻译器”),挑一个大模型 API
•
你要给产品增加文生图能力,挑一个图片 API
•
你要给产品增加文生视频能力,挑个个视频 API
你不需要自己造发动机,你只需要会装发动机。
这就是今天 AI 产品开发最真实的工作方式。
EvoLink是我朋友做的一个小型API精选超市,你可以进去看看,“API超市”长什么样子。
世界上各个厂商的API,都可以在这里选到。
API平台怎么工作?
主流API平台,本质上是AI模型的"中转站"。下面以Openrouter.ai 这个平台为例
实际流程
1.
你发送请求:告诉OpenRouter你想用哪个AI模型,问什么问题
2.
OpenRouter处理:把你的请求转发给对应的AI模型
3.
返回结果:把AI的回答返回给你
就像点外卖:
•
你:顾客(开发者)
•
OpenRouter:外卖平台(API服务商)
•
各种AI模型:不同的餐厅(Claude、GPT-5、nana-banana等)
为什么要用Openrouter等API平台?
•
统一接口
不用分别去注册Claude、GPT-5、nana-banana等,一个OpenRouter账号搞定所有模型。
•
成本控制
可以比较不同模型的价格,选择性价比最高的。
•
灵活切换
同一套代码,可以轻松在不同AI模型之间切换测试。
怎么做厉害的 AI 产品?
心法:用积木的眼光看待 API
API 是可以像积木一样玩起来的!
我们举个例子,
HeyGen 在 2023 年爆火的一个功能是 AI 视频翻译 。用户上传一个原始视频(如英语讲话),HeyGen 自动翻译 成其他语言(如中文、法语、西班牙语等)并且调整口型,让说话人的嘴巴与翻译后语音保持一致,看起来就像原本是用该语言录制的一样。
我们从“API 积木”的视角来理解,HeyGen 需要串起来的是文字翻译、文字转语音、视频对口型这三类 API。
所以,不要小看这些 API 哦!
如果只调用一个 API,那么你的产品往往没什么价值,看起来会比较稀疏平常。
但是,如果你创造性地把多种 API 串联起来,想象空间是无限的!
没错,做产品,首先是个创意生意!
厉害的产品 = 厉害的创意!
有人会说,市面上所有的产品看起来都千篇一律,似乎没有什么可做的。
他错了! 我们假设世界上有 100 种 AI 能力(显然不止), 如果一个产品串起来其中两种 AI 能力,那么至少 100x100=1 万种产品形态。如果串起来三种 AI 能力,那么将会有 100x100x100 = 100 万种可能的产品形态! 如果你串起来 4 种呢?5 种呢?
当你用搭积木的眼光去看待 AI 能力,你会有一种“海阔凭鱼鱼,天高任鸟飞“的爽感!
从API的角度看待AI产品
🚀 简单的AI产品
简单交互 + 单一API = 入门级产品
专注于单一功能场景,通过简洁的用户界面调用特定API,降低用户学习成本,快速解决特定问题。
典型案例:
•
ChatPDF - 文档对话工具
•
Notion AI - 智能写作助手
•
Grammarly - 语法检查工具
🔧 复杂的AI产品
个性化交互 + 多API串联 = 专业工具
通过工作流设计将多个API有机结合,支持复杂业务场景,提供端到端的解决方案。
实现方式:
•
Workflow型 - 如Zapier、n8n等自动化平台
•
Agent型 - 如Manus、Genspark、Lovart、等智能代理
🎯 顶级的AI产品
沉浸式交互 + 自有API生态 = 行业标杆
拥有自主技术壁垒,构建完整的API生态系统,从基础能力到应用层面形成闭环,引领行业发展。
代表产品:
•
OpenAI ChatGPT - 对话AI的行业标杆
•
Midjourney - 图像生成领域领导者
•
Anthropic Claude - 安全AI助手
•
蝉镜数字人 - 数字人领域领导者
•
Runway - 视频AI创作平台
二、主流API平台
火山引擎
•
优点:中国网络、中文语境友好,文档和接入流程顺
•
缺点:平台上只有国产模型,尤其是偏重字节自己的模型
•
适合:国内团队、新手先跑通业务
•
常见用途:先稳定上线,再做多平台切换
进入官网,点击上面的“大模型”可以看到模型列表。
OpenRouter.ai
•
优点:模型池很大,切换模型方便
•
缺点:文本类模型占比过大,其他类型模型不够多;信用卡付款,不支持支付宝/微信等国内支付方式
•
适合:快速比较不同文本模型效果
•
常见用途:同一功能换不同模型,比效果和成本
提示:海外平台,可能需要配置海外网络
这是世界的顶级(很可能是Top 1)的API平台,只提供正规大厂的正规API。
它日常也提供API调用榜单,是全世界的风向标。
fal.ai
•
优点:图像和视频方向很强,更新快;它对自己的定位就是“generative media model gallary”
•
缺点:文本类模型一般
•
适合:文生图、图生图、视频生成
•
常见用途:搭积木
提示:海外平台,可能需要配置海外网络
三、如何找到合适的 API?
先确定技术上是否可行
对初学者来说,如果你关注 AI 技术比较少,会遇到的一个问题是——不知道自己想做的产品,是否技术上可行?
除了刚才提到的,要多保持关注以外,你也可以和 ChatGPT 等 AI 助手进行讨论、向它们请教。
比如,如果我想做一个“猫语翻译器”,不确定是否当今技术可以做到,可以问 ChatGPT。
我想做一款产品,帮我和我和家的猫沟通,「猫语翻译器」。
产品形态是:当猫叫的时候,手机能够翻译出来它的意思;我对手机说话,手机也可以翻译成猫猫能听懂的喵喵声。
我想知道,当今的 AI 技术,能不能实现?有没有现成的 API 可以让我调用?
很快可以发现两点结论:
1、当今技术可以做到,但是比较前沿,掌握在少数人手里;
2、没有现成 API
对于普通的应用开发者尤其是初学者,看到这两条结论,可以先行放弃,毕竟门槛有点高。
而对于有科学家或算法背景的人团队来说,这会让他们兴奋 ,因为他们知道,一旦自己做出来,就有壁垒。
再来。继续问 AI,
我想做一个“图片去背景产品”,不知道是否有现成的 API 可以做到?
很快得到了答复,答案是肯定的。结论如下图所示
不仅如此,我们还了解到:
1、有很多平台都提供了成熟的 API。
2、甚至有一些开源的方案,可以自行部署 API,从而节省成本
3、同样是“去除图片背景”的能力,不同的 API 有不同的优势
总的来说,我会建议初学者优先选择上文介绍的 主流API 平台上的 API。
如果你要做的功能、在 replicate 平台上找不到现成的 API,那么可能它暂时不适合现阶段的你来实现。
补充:还可以试试以下几个方案
1.
直接测试,你的需求,chatgpt-o3能做到吗?gemini-pro-2.5 能做到吗?它们如果不能做到,还给出了你什么建议?
2.
到replicate/fal等一切API平台,能找到现成的API吗?它们的效果足够好吗?
3.
n8n和coze的模板商店,有人实现过类似的产品吗?
如果3个的答案都是“否”,那就是技术上比较难的产品,无法调用现成API来实现,需要专门找人做自己的算法。
找到API后,先不要写代码,而是先测试效果
切记!找到API后,先不要写代码
很多新手朋友,找到API后,立即让大模型开始写代码 —— 然后成了一锅粥。当报错的时候,难以确定到底是哪里错了。
正确的方式是
•
通过AI平台提供的Playground ,在线测试效果。主流API平台一般都提供这样的功能。
•
通过Postman调试(下一节课马上讲到)
同一个类型的API,往往会有大量不同的供应商。
例如简单的“文生图”这个任务,主流API就不下10个,每个都很好。
为我们产品的效果、成本、性能负责,我们需要把同类API全部测试完,选择最适合自己的。
四、如何用程序调用API?
调用所有API都一样,需要凑齐以下要素。
只要凑齐以下要素,无论是人类程序员还是AI程序员,都可以一次性调试API成功。
反之,如果API调用不成功,往往是这四个要求的一个或多个有问题。
1.
API KEY (有些平台叫令牌、有些叫API Secret)
2.
API调用的示例代码
3.
API调用的示例输入
4.
API调用的示例输出
我们可以使用Postman,提前测试,「四要素」是否有问题。
五、Postman 验货:先跑通,再接入代码
为什么需要这一步?
因为如果我们「在实际写代码之前」,就先把API调通,会对AI写代码增加很大的确定性。
通过Postman的测试,我们可以「在实际写代码之前」,就集齐上文提到的「API调用四要素」。把四要素全部给到AI编程工具,大概率可以一次做对。
假如我们要调试这个API https://openrouter.ai/google/gemini-3-flash-preview
如果你没有OpenRouter,你可以在火山引擎用Kimi、GLM或其他国产模型代替(免费额度足够),但是API的响应速度要慢一些
先创建API Key
https://openrouter.ai/settings/keys 点击Create API Key
这个就是你的Key, 复制下来,找个只有你自己知道的地方,存下来。
进去点击API,复制CURL示例代码。(注:这是四要素里的「示例代码」)
登陆。
找到左侧导航栏的 "Workspace",进入后点击 "Create workspace",完成命名等任务
点击左侧的按钮出现 import
点击Import,把你刚才复制的CURL代码粘贴给它
粘贴后,界面如下。
可以点击Import Without Saving。 (点击Import Into Collection也可以)
点击 Headers,把里面的 $OPENROUTER_API_KEY 改成你Openrouter里真实的KEY
(注:这是「四要素」里的「API KEY」)
点击Body,在里面修改你实际的「请求」(Request Body)。
(注:这是「四要素」里的「示例输入」)
注意:
1.
你也可以不修改,直接用OpenRouter给的默认值。
2.
格式是JSON格式。如果不明白什么是JSON,可以问问ChatGPT-5
点击Send,就可以看到API的返回结果了。包括「状态码」和「返回内容」(Response Body)
(注:这是「四要素」里的「示例输出」)
Postman有多种形态,包括网页版、电脑客户端、Cursor插件等等。
我建议新手用网页版Postman,https://www.postman.com/
因为在网页版上,我们可以借助Dia等优秀的浏览器,帮助我们更好的学习。如下图所示
重要:构造API四要素,保存下来
调试完成后,构造我们需要的完整API说明备用,后面的课程会用到。
请不要复制我的!你自己完成。
你可以参考我的格式:
## API 代码 (curl代码)
上文已经讲了。
## API Key
上文已经讲了。
## API示例输入 (postman请求的body)
看图
## API示例输出 (postman返回结果里的body)
看图
构造后是这样。你找一个地方存起来,推荐飞书文档或者其他笔记软件。
Markdown
## API 代码 (curl代码)
curl https://openrouter.ai/api/v1/chat/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $OPENROUTER_API_KEY" \
-d '{
"model": "google/gemini-3-flash-preview",
"messages": [
{
"role": "user",
"content": [
{
"type": "text",
"text": "What is in this image?"
},
{
"type": "image_url",
"image_url": {
"url": "https://upload.wikimedia.org/wikipedia/commons/thumb/d/dd/Gfp-wisconsin-madison-the-nature-boardwalk.jpg/2560px-Gfp-wisconsin-madison-the-nature-boardwalk.jpg"
}
}
]
}
]
}'
## API Key
粘贴你自己的KEY
## API示例输入 (postman请求的body)
{
"model": "google/gemini-3-flash-preview",
"messages": [
{
"role": "user",
"content": [
{
"type": "text",
"text": "What is in this image?"
},
{
"type": "image_url",
"image_url": {
"url": "https://upload.wikimedia.org/wikipedia/commons/thumb/d/dd/Gfp-wisconsin-madison-the-nature-boardwalk.jpg/2560px-Gfp-wisconsin-madison-the-nature-boardwalk.jpg"
}
}
]
}
]
}
## API示例输出 (postman返回结果里的body)
{
"id": "gen-1760339238-BG4KZ6dgEfrjoMCRwMlQ",
"provider": "Google AI Studio",
"model": "google/gemini-3-flash-preview",
"object": "chat.completion",
"created": 1760339238,
"choices": [
{
"logprobs": null,
"finish_reason": "stop",
"native_finish_reason": "STOP",
"index": 0,
"message": {
"role": "assistant",
"content": "This image shows a **wooden boardwalk cutting through a vibrant green field under a wide, blue sky with scattered clouds**.\n\nHere's a breakdown of the key elements:\n\n* **Sky:** The upper portion of the image is dominated by a bright blue sky with numerous white and light grey clouds, some stretched thinly, others forming more distinct shapes. The overall impression is good weather.\n* **Field/Meadow:** A vast expanse of lush, green grass fills the majority of the lower image. The grass appears tall and somewhat wild, suggesting a natural or semi-natural landscape rather than a manicured lawn. The sunlight catches the blades of grass, highlighting their green color.\n* **Boardwalk:** A light-colored wooden boardwalk stretches from the bottom center of the image and recedes into the distance, appearing to curve slightly to the right. It provides a clear path through the tall grass. The planks show some signs of age or weathering.\n* **Trees/Shrubs:** In the middle ground, on either side of the field and further along the horizon, there are clusters of trees and bushes. On the left side, the trees are predominantly green, while on the right, some of the bushes have reddish-brown foliage, possibly indicating a different species or seasonal color.\n\nThe image has a bright, natural, and inviting atmosphere, suggesting a peaceful walk through a natural landscape.",
"refusal": null,
"reasoning": null
}
}
],
"usage": {
"prompt_tokens": 265,
"completion_tokens": 287,
"total_tokens": 552,
"prompt_tokens_details": {
"cached_tokens": 0
},
"completion_tokens_details": {
"reasoning_tokens": 0,
"image_tokens": 0
}
}
}
演示:使用Postman调试图片生成模型API
Seedream模型是世界一流的图片类AI模型,如果是文字转图片还是图片编辑,都很能打,不亚于Google Nano Banana
我们注册、登录火山引擎,到首页,点击选择 豆包·Seedream模型。 点击后,它会带我们来到这个地址 https://www.volcengine.com/experience/ark?launch=seedream
点击右上角的 API接入
创建API Key。如果已经创建,直接使用即可
会看到 会出现, CURL开头的代码。
我们可以直接把这段代码放到终端里运行,可以直接得到结果。
我们把这段代码复制到Postman中,用上一节提到的知识点,在Postman里调试。
点击import
找到两个图片链接。
我找了这两个
我的Prompt是:
Plain Text
让图片1里左侧的人,穿上图片2的衣服你可以考虑调整这4个字段
•
Prompt :上面已经说了
•
image:被编辑的图片。上面已经说了
•
watermark: 改成false, 生成内容不出水印
•
stream: 改成false, 我们不需要流式输出
这是我得到的结果
这是我得到的返回内容
JSON
{
"type": "image_generation.partial_succeeded",
"model": "doubao-seedream-4-0-250828",
"created": 1760336285,
"image_index": 0,
"url": "https://placeholder.example.com/image.jpg",
"size": "1600x2848"
}六、实操1:替换API:把coze sdk默认API换成外部API
本节目标是让你的代码具备"可切换能力"。今天换火山,明天换 OpenRouter,不改业务层。
步骤如下
•
先通过AI,定位到当前某个功能的API使用情况
•
确定替换目标
•
准备好新API的「四要素」(上一节内容)
•
测试
我准备了一个Prompt模板。你可以参考
Markdown
你是我的全栈工程师。请帮我把当前项目里的默认 AI API 提供商切换为另一家 API,先输出实施计划,不要立刻改代码。
【项目背景】
- 技术栈:Next.js (App Router) + TypeScript
- 当前已有功能:{填写,例如“文生图功能 / 聊天回复功能 / 语音转写功能」
- 当前接入:{旧供应商,如 coze sdk / OpenRouter / 火山引擎}
- 本次目标:把功能从 {旧供应商/旧模型} 替换到 {新供应商/新模型}
【你先确认的四个问题(先做这4步)】
1) 旧 API 的对外能力边界:入参、出参、错误码、速率限制
2) 新 API 的能力是否能完整替代(消息格式、流式、图片/文件参数等)
3) 是否需要做字段映射(例如 messages、response schema)
4) 是否需要兼容回退策略(失败时回退旧供应商)
【API 四要素(替换目标 API)】
1) 新 API Key:{填写}
2) 示例代码(curl):{粘贴官方示例}
3) 示例输入(Request Body):{粘贴请求示例}
4) 示例输出(Response Body):{粘贴返回示例}
【实现要求】
1. 先输出完整实施计划(含风险),不要先改代码
2. API Key 只能放服务端环境变量,禁止前端暴露;写入 .env
3. 统一使用服务端 service 层接入,页面组件只负责渲染/交互
4. 新增 provider 适配层,保证上层调用接口不变(你可抽象为统一 adapter)
5. 增加错误分类处理:401、403、429、5xx、timeout,返回可读的业务错误
6. 增加可观测日志(请求开始/结束、provider、耗时、状态码、错误摘要)
【你必须输出】
- 步骤计划(每步包含目的+文件)
- 你建议保留的公共接口定义(签名/返回结构)
- 关键边界映射表(旧字段 -> 新字段;新字段 -> 兼容字段)
- 对比表:替换前后能力差异
请先给我计划,等我回复“开始改”后,再给出代码实现步骤并开始改文件。1.
定位当前产品需要调用哪些API,不确定的话可以直接问AI(以虚拟男友为例)
Plain Text
看看这个 Next.js 项目目前接入的API和对应的功能是什么可以看到返回:
说明产品使用了语言模型API+图片API(数据库已经通过扣子编程配置连接完成)
2.
构造相应的 API 四要素
根据前面练习过的Postman验货的方式来分别构造语言模型和图片模型的 API 四要素
语言模型Postman测试
图片模型Postman测试
3.
把四要素填进提示词相应部分,发给AI开始替换
会得到类似这样一个替换计划
确认无误后让它开始改
到这里就替换成功了,之后可以让它再次启动,看项目能否正常运行
Plain Text
请帮我启动这个 Next.js 项目。之后可以通过返回的localhost链接来测试看功能是否正常,也可以直接在 TRAE 的显示页面里进行测试
七、实操2:从零开始接API - 使用TRAE做一个“虚拟试衣”小产品
1.
确认是否有现成API可以调用,看看技术上是不是可行的
把下面这段话发给任何AI,可以直接在 TRAE 里交流,这里我用的是GPT
Plain Text
我想做一款产品,可以实现「虚拟试衣」这个功能。
产品形态是:我上传衣服图片和我自己的图片后,可以替换服装看到我穿上这件衣服的样子。
我想知道,当今的 AI 技术,能不能实现?有没有现成的 API 可以让我调用?回答如下:
可以看到,技术上肯定能做,并且还有专门的虚拟试衣 API 。说明我们在关键功能上没有卡点
2.
选择合适的API,在Postman上完成测试,构造四要素
这里我们先用火山引擎来接入图片API
测试成功后,先把 API 四要素保存下来,存在任意的文档里即可
注意:试衣功能需要同时上传多张图片、输出一张结果图,所以要选多图参考生图的 API,别选错了
3.
和AI讨论需求,形成 SPEC
SPEC的写法在之前的课程里已经联系过了,这里直接用
下面是和AI讨论后的SPEC
Markdown
虚拟试衣 AI 工具 V1 SPEC
一、Problem Statement(问题陈述)
当前普通消费者在购买服装前,往往只能依赖模特图、商品图或想象来判断一件衣服是否适合自己。这种判断方式存在几个明显问题:第一,商品图中的模特体型、拍摄角度、搭配方式与用户本人差异较大,用户很难建立“这件衣服穿在我身上会是什么样”的直观认知;第二,用户即使有兴趣尝试多件衣服,也需要反复在不同商品图之间切换,决策成本高;第三,用户自己已有衣物与待购衣物之间的搭配关系也很难被快速验证。
因此,产品需要解决的核心问题是:让普通消费者能够用最低门槛上传自己照片和服装图片,快速获得一张可用于购买前参考的试穿预览图,从而降低购买犹豫,提高尝试意愿,并形成可持续反复使用的试穿习惯。
这个产品不是做“精确量体”或“尺码推荐”,而是做一个 低门槛、可重复使用、以购买前参考为核心价值的虚拟试衣工具。
二、Proposed Solution(方案描述)
V1 将推出一个 面向海外市场的 Web 虚拟试衣工具。用户登录后,上传一张自己的照片和一张服装图片,系统自动识别服装类别,并生成一张静态的试穿预览图。结果以“购买前参考图”的形式提供,而不是精准尺码或真实上身承诺。
1. 核心用户
普通消费者。
2. 核心场景
以 购买前预览 为主,以 穿搭尝试 为辅,同时兼顾一定程度的 身材适配参考,但不把“精准版型判断”作为首版强承诺。
3. 产品形态
Web 网页工具。
4. 输入
用户一次试衣需要提供:
1 张人物照片
1 张服装图片
V1 对输入门槛保持尽可能低:
人物图可为任意日常照片
服装图可为任意服装图片
不强制标准姿势、不强制白底图、不强制高质量输入
5. 支持品类
V1 支持:
上装
下装
连衣裙
一次试衣只替换一件衣服。
6. 识别与生成方式
系统自动识别服装类别
V1 暂不提供识别错误时的专门兜底机制
若结果不理想,用户可直接重新生成
7. 输出
返回 1 张静态试穿预览图
对外承诺为 “试穿预览图”
不承诺精准尺码、精准垂感、精准真实上身还原
8. 生成目标
生成结果应尽量满足以下方向:
尽量保持人物脸部与身份感不变
尽量保持原有身体轮廓与姿势不变
尽量保持原始背景不变
尽量还原服装的关键特征:颜色、主要版型、长度、关键图案
优先提供“购买前参考价值”,而不是纯娱乐效果
9. 复用机制
为了支持重复使用:
同一次访问中,人物图只需上传一次
用户后续可以连续更换服装图继续试穿
人物图仅在当前会话中复用,不作为默认底图长期复用
10. 账号与历史记录
V1 支持游客身份访问,登录后的账号体系支持长期保存:
试穿结果图
原始人物图
原始服装图
用户可以删除单条历史记录。
11. 商业模式
首版采用 订阅制
订阅价值主要建立在 更多试穿次数
漏斗设计为:先免费试用,再引导订阅
三、Technical Constraints(技术约束)
核心框架
框架: Next.js 16 (App Router)
语言: TypeScript 5
运行时: Node.js 24
前端技术
框架: React 19
样式: Tailwind CSS 4
组件库: shadcn/ui (Radix UI)
图标: Lucide React
AI 集成
图片 API
状态管理
方案: React Context API
全局状态: GameContext
开发工具
包管理器: pnpm (强制要求)
初始化工具: Coze CLI
代码规范: Airbnb Style Guide
四、Non-goals(明确不做的事)
V1 明确不做以下事项:
1. 不做尺码推荐
不告诉用户应该买 S、M、L 或具体尺码。
2. 不做精确身材测量
不输出肩宽、腰围、腿长等人体测量数据。
3. 不保证复杂场景适配
不承诺以下输入的效果:
多人合照
严重遮挡
极端角度
坐姿、蹲姿、复杂动作
非常模糊或极暗图像
4. 不做自动穿搭推荐
不自动推荐“这件衣服配什么裤子/鞋子/外套”。
5. 不做整套一次替换
一次仅替换一件:上装、下装或连衣裙之一。
6. 不做动态试衣
V1 只输出静态图片,不做视频或动态试穿。
7. 不做人像真实性校验
不强校验上传者是否为本人,也不限制只能上传自己的照片。
8. 不做高风险人物专项风控
除明显违规内容外,V1 暂不处理未成年人、公众人物等专项风险识别。
9. 不做高精度真实性承诺
不承诺完全真实的面料垂感、细节纹理、尺码贴合度或实体上身一致性。
五、Success Criteria(成功标准)
V1 的成功要分成 单次结果成功 和 产品层面成功 两层。
1. 单次结果成功标准
一张合格的试穿预览图,至少应满足以下四点:
用户能一眼认出是自己
衣服类别正确
结果对购买决策有参考价值
画面基本自然,不明显穿帮
这四项都至少基本成立,才算一次“成功的试衣结果”。
2. 产品层面的成功标准
V1 的首要成功指标不是一次生成率,而是 重复使用率。
重点看两件事:
(1)短期重复使用
用户在一次访问中,拿到第一张结果后,是否愿意继续试更多衣服。
(2)长期重复使用
用户是否会在几天后再次回来继续使用。
也就是说,V1 要证明自己不是一次性新鲜工具,而是一个用户愿意持续回访的消费级产品。
3. 商业化成功信号
由于产品采用“免费试用后订阅”的方式,早期可观察的商业化信号包括:
免费用户是否快速用完额度
用完后是否有明显订阅意愿
订阅用户是否确实比免费用户更高频试穿
4. 不作为 V1 核心成功指标的内容
以下指标暂不作为首版核心判断标准:
尺码准确率
身材测量准确率
高风险风控识别率
动态试衣完成率
全服装品类覆盖率
一句话版本
这是一个 面向海外普通消费者的 Web 虚拟试衣工具:
用户登录后上传自己的照片和任意服装图,系统自动识别服装类别,并在 10–20 秒内生成一张静态试穿预览图;产品以 购买前参考 为核心价值,以 低门槛、可重复使用、订阅驱动 为产品策略,不做尺码推荐、不做复杂风控、不承诺高精度真实上身效果。
如果你愿意,下一步我可以直接把这份 SPEC 继续往下扩成一版 PRD 结构,包括:
用户流程、页面模块、核心状态机、订阅设计、埋点指标、MVP 优先级。4.
将确认好的SPEC直接发给 TRAE,并确认开始创建项目
这过程中可能会有报错信息,部分AI会自行修复,部分可以手动复制终端的报错信息发到对话框让AI来修复,直到项目创建成功
5.
接入图片 API ,实现“试衣”功能
还记得前面存好的四要素吗?把它们填进下面的Prompt模板即可。
我准备了一个Prompt模板,你可以参考
Plain Text
你是我的全栈工程师。请帮我把下面这个 API 接入当前项目。
【项目背景】
- 技术栈:Next.js(App Router) + TypeScript
- 当前已有功能:{填写,如果没有,就说没有}
- 本次目标:{填写,例如"通过调用image to image的API,实现虚拟试衣功能;用户需需要传入两张图片,一张是模特照片,一张是衣服"}
【API 四要素】
1) API Key:{填写}
2) 示例代码(curl):{粘贴官方示例}
3) 示例输入:{粘贴请求 body}
4) 示例输出:{粘贴返回示例}
【实现要求】
1. 先输出实施计划,不要立刻改代码
2. API Key 只能走服务端环境变量,不能暴露到前端;API Key配置到.env中
3. 新增 service 层,不要把调用写死在页面组件
4. 增加错误处理:401 / 429 / timeout
5. 增加开发日志,便于排查
6. 最后给我:
- 修改文件清单
- 本地验证步骤
- 失败回滚方案
请先给计划,等我回复"开始改"后再改代码。确认无误后,直接让AI开始改
6.
让AI运行项目,并测试功能能否正常运行,在前端页面分别上传两张测试图
测试成功,产品的基本功能已经完成。之后可以进行一些细节的打磨和修改,比如修改页面设计、文件输入限制等等,完善产品的使用体验
八、安全红线
我们提交代码前,反复检查
•
API Key 只放后端 .env,前端禁止明文暴露
•
.env 禁止提交到 GitHub
•
每次提交前先检查变更文件
•
不在群聊/截图里暴露完整密钥
如果泄露了:立刻删除旧 key,重新生成新 key。
回顾
本节课我们介绍了:
1.
深入理解API和API平台
2.
理解AI和产品的关系
3.
写代码之前,凑齐 API 四要素
4.
调试API
5.
在产品中接入API
6.
替换产品中已接入的API
内容挺多的。你都掌握了吗?
作业
作业 1:验货
•
用 Postman 跑通一个火山引擎 API
•
提交:状态码 + 返回结果截图
作业 2:替换API
•
把项目中的默认 coze sdk调用改成使用任一API平台上的API,对比效果差异
•
提交:代码截图 + 运行截图
作业 3:从零接入API
•
在TRAE新做项目,从零接入API,可以参考课程讲义里的“虚拟试衣”
附A:Cursor / TRAE 的 API 接入通用 Prompt 模板
模板1:API 报错排查
HTML
我现在 API 调用失败,请按工程排查流程帮我定位。
【错误信息】
- 状态码:{填写}
- 响应体:{粘贴}
- 控制台日志:{粘贴}
- 最近改动:{填写}
【你需要输出】
1. 最可能的3个根因(按概率排序)
2. 每个根因的验证步骤
3. 最小修复方案(不要大改架构)
4. 修复后的验证清单(成功标准)
请先定位,再给修改建议,不要直接重构。十、去哪里看模型能力:别靠感觉选,学会看公开信号
前言
之前的课程里我们解决了"去哪里进货"的问题——你知道了 OpenRouter、火山引擎、fal.ai 这些 API 平台,也就是“进货渠道”。但进货之前,其实还有一个更前置的问题没解决:
货架上那么多模型,我怎么知道哪个好?
你去搜一圈,会发现这个问题特别乱。
自媒体今天说这个最强,明天又说那个吊打全场;厂商的宣传页上基本上个个都写自己是第一;价格还不一样,有的贵得离谱,有的看起来便宜,但实际效果又不一定行。
所以这节课,我们解决的就是“买哪个”的问题——看公开测试榜单
一、需要排除容易失真的非匿名榜单
很多榜单的问题,不是它完全没用,而是它根本不是匿名测的。
有的是你在看答案的时候就知道模型是谁,那你的判断很难完全不受品牌影响。有的是厂商早就知道这套榜单在考什么,题目、规则、指标都摆在那里,这种形式更像是一场开卷考试,本质上就是出一套公开题库,让模型去答题,最后看分数。这样测出来的高分,未必代表模型真的更强,只能说明它对这套题更熟。
听起来很科学,对吧?
问题是,只要题目是公开的,就容易变成刷题。
你让学生提前知道高考题,他当然能考高分,模型也是一样。
这也是为什么你经常会看到一种很奇怪的情况:有些模型在某些官方表格里的分数特别好看,但你自己一上手,却发现并没有传说中那么神。
不一定是你不会用,而是那个榜单本身就不一定能代表真实的使用体验。
所以我们应该看什么?
看那些更接近真实使用、也更难提前作弊的盲测榜单。
二、为什么有的榜单很难被刷
盲测榜单之所以很难被刷分,是因为它用了一套叫 ELO 的评分机制。
什么是ELO呢?我们可以先看看围棋的等级分,或者段位赛背后的那套积分逻辑,或许就很好理解了。
在围棋对弈里,一个九段选手赢了一个二段选手,这件事说明不了太多,因为大家本来就预期九段更强。所以就算九段选手赢了,加分也不会特别多。
但如果反过来,一个二段选手赢了九段选手,这个结果的信息量就很大。系统会觉得:这个二段是不是被低估了?这个九段是不是被高估了?所以前者会涨不少分,后者也会掉一些分。
这个逻辑在围棋的规则里叫“ELO”,大模型盲测榜单也是使用了同样的逻辑。
ELO的评分逻辑不再是让模型做一套公开试卷,然后看谁考了多少分。而是让模型在多轮匿名的对战里,和不同水平的对手不断交手。
比如 Artificial Analysis 上的评分系统会同时给出两个答案,但不会告诉你左边是谁、右边是谁。你只负责选:哪个更好。也是因为匿名,你很难带着品牌滤镜去投票,这样的结果就更具有真实性,也更能反映出模型本身的能力
如果一个模型经常赢本来就很强的模型,它的分数就会被不断抬高;如果一个高分模型输给了低分模型,它的分数就会往下掉。
所以这个分数看的是相对的硬实力,而不是背题能力。这也是为什么它比传统公开题的评测榜单更值得参考。
三、两个最值得看的公开评测来源
这里有两个值得推荐的公开评测榜单:
Artificial Analysis
我们一般叫 AA,https://artificialanalysis.ai/
AA的特点是它不是只给你一个总榜,还会把价格、速度、模型质量等不同维度做个相对全面的比较。
在Models页面,你可以了解到模型的能力、性能、速度和价格等多个方面的具体特性对比
在Leaderboards页面,你可以直接看到100多个模型的总排名和具体的对比参数,还可以根据自己的需要做筛选
在Speech,Image,Video页面,你可以看到图像、视频、语音模型的具体表现能力,一般ELO在1200左右的模型,综合能力相对较强。
95% CI指的是置信区间,在正常情况下,模型的分数位会存在一定的轻微波动,如果两个模型的分差本来就很小,还落在误差区间里,那它们大概率可以视为一个水平
在 AA,你还可以直接参与模型的对比测试,以图片生成为例,点击 Image Arena,就会出现两个匿名模型输出的结果,根据你的偏好直接打投就行。
文生图榜单这里还有个特殊功能,点击Try Image Lab,你就可以进入测试页面,自己写提示词免费同时测试多个模型
2. Arena
Arena 总榜:https://arena.ai/leaderboard/
在Leaderboard页面,你同样可以看到分模态模型的总排行榜和具体分数位
除了上面的模型总体的综合能力榜单之外,还可以看到模型的专项能力排名情况,以文生图模型榜单为例,除了总榜单之外还有电商、3D建模、动漫动画等不同专项能力的评测,对需要模型子能力的产品非常友好
也可以进行不同模型视频的测试,点击右上角的Start Voting,你就可以在对话框免费选择想测试的模态。
对比AA,Arena可以测试的模型形态更多,比如视频生成、代码能力测试等等,这和薅羊毛有什么区别
这里我还是用图片模型来测试,你觉得左右哪边的效果更好呢?
四、怎么把榜单变成实际决策
1.
确定你要做什么任务
不是所有模型都拿一个总榜就能解决。你是要看文本能力,还是写代码,还是生成图片、生成视频,这些都不一样。
所以第一步永远不是“谁总分最高”,而是“我现在做的到底是哪类任务”,再去看具体模型的对应能力。
2.
看分差,但不要过于纠结分差
1200分的模型和1000分的模型差异是显而易见的,但1200分和1119分的模型差异未必能直观感受到。如果两个模型只差一点点分,其实没必要过度解读。如果两个模型的置信区间有重叠,基本可以把它们视为同一水平。
因为榜单不是神谕,它也有波动,也有误差,也有样本量的问题。在能力相当的情况下,再回到火山引擎等 API 供应商去对比价格
3.
最终决策——对比价格
我们选模型不是为了追求最强,而是为了做出能用、能赚钱的产品。
如果两个模型在你的任务上表现差不多,比如文生图里 Nano Banana Pro 和 FLUX.2 的 ELO 评分相差不大,两者的置信区间还有重叠,说明它们的真实能力基本是同一水平的,但价格却差了几乎一倍,这种情况下,便宜的那个就是更好的选择。
又比如,文生图方面 GPT Image1.5 比 FLUX.2 的 ELO 评分高一些,但价格几乎是 FLUX.2 的两倍,这种情况下,也更推荐优先选择 FLUX.2 模型。当然,具体价格还要去供应商平台再对比一遍,榜单的价格会和不同供应平台的价格略有区别
能力够用 + 价格合理,就是选择模型的决策标准。
以哄哄模拟器为例,我先考虑音频能力的接入。
在榜单上先对比模型效果,发现前三的 TTS 排名靠前,价格也相对便宜,那我可以优先去 fal.ai 、火山引擎等平台找是否有提供这三个模型的接口
在 fal.ai 上我们会发现提供的 TTS 模型相对较少,没有我们希望找的前三个模型。这时候我们要么得去官网看看是否有这三个模型的接口,要么选择其他模型来接入。
这里我先选择第二种方法,发现第 4 名到第 12 名区间的模型评分不会相差太多,那我就在里面找价格最便宜的。对比下来发现同一水平下最便宜的应该是 Elevenlabs 的 Turbo v2.5,那就决定用这个了
作业
•
根据哄哄模拟器或者虚拟男友需要的模型能力,从评测榜单里找到适合的模型
•
回到供应商确认这个模型是否可以调用,对比价格,确认最终选定的模型
十一、环境变量:为什么密码不能直接写在代码里?
正文
本课目标
这一课只解决一件事:保护你的钱包、数据,以及你的职业声誉。
学完之后,你需要掌握三件事:
1. 心智模型——搞清楚为什么把密钥写在前端代码里,是 AI 应用开发的头号禁忌。
2. 标准架构——能写出「前端 → Next.js API Route(服务端) → 第三方 API」这条请求链路,并理解为什么要这么绕一圈。
3. 管理意识——知道本地开发和线上部署时,环境变量的配置方式有什么不同,不要搞混。
1. 真实案例:一次价值百万的低级错误
2026 年 3 月,国内科技圈出了一件颇受关注的安全事故。
美团旗下的光年之外团队推出了一款 AI 浏览器产品。产品上线后没多久,就有安全研究员和开发者在分析其安装包时发现,前端代码里直接硬编码了调用 AI 模型接口的 API Key。这个发现迅速扩散——有人写脚本批量薅接口,有人把密钥拿去给自己的产品免费用,账单在短时间内滚到了离谱的数字。
这件事的逻辑很简单:客户端代码是公开的。浏览器扩展、网页前端、手机 App,只要打包出去给用户安装,里面的代码就等于公开发布了。任何人打开开发者工具,或者解包安装文件,都能把密钥原样读出来。藏在变量名里没用,混淆代码也没用,只要它在客户端,就一定能被找到。
同样是这个月,还发生了另一起性质一样的事故。
这次的主角是小米 MiClaw 团队新推出的系统输入法。
触发方式简单到离谱——只需要疯狂点击输入法的版本号,就可以打开调试页面。API 调用地址、模型提供商、API KEY、模型名称、提示词,一个不少,全在里面。
这还不是小米第一次出现这种事故,2025年1月小米在 GitHub 提交代码时不慎直接暴露明文 KEY,当时也引发了一波讨论。
一句话总结这些事的教训:前端持有密钥,等于把银行卡密码印在名片上。
2. 为什么写在代码里必死无疑?
很多初学者的第一反应是:「我把变量名起得复杂一点,或者把字符串拆开拼接,是不是就安全了?」
不是的。问题不在于密钥写得明不明显,而在于它出现在了客户端这个位置。
前端代码运行在用户的浏览器里,浏览器对用户是完全透明的。用户可以查看源码、可以打断点、可以抓包,这些都是浏览器的正常功能,任何人都能用。你写的任何「混淆」手段,对一个有基础的开发者来说,顶多多花几分钟。
真正的解决方式只有一个:让密钥永远不出现在客户端。密钥只存在于服务器上,前端永远不知道它是什么。
---
3. 核心方案:Next.js 环境下的「防火墙」结构
正确的架构是这样一条链路:
浏览器(前端) → Next.js API Route(服务端) → 第三方 AI 接口
前端只负责发请求给自己的服务端,说「我需要调用一次 AI」。服务端收到请求后,从环境变量里读取 API Key,再用这个 Key 去请求第三方接口,最后把结果返回给前端。
整个过程中,前端自始至终不知道 API Key 是什么。密钥只存在于服务器的内存和配置文件里,从未出现在任何发给浏览器的代码或响应里。
核心机制:服务端读取
Next.js 里,`process.env.YOUR_KEY` 这种写法只在服务端有效。只要你的代码运行在 API Route(`/pages/api/` 或 App Router 的 Route Handler)里,读取的就是服务器上的环境变量,浏览器完全接触不到。
本地开发时,把密钥写在项目根目录的 `.env.local` 文件里:
Plain Text
OPENAI_API_KEY=sk-xxxxxxxxxxxxxxxx同时,`.env.local` 必须加进 `.gitignore`,绝对不能提交到 Git 仓库。
线上部署时(比如 Vercel),在平台的项目设置里手动填写环境变量。 我们后续的课程马上会讲到线上部署。
4. 实战代码
❌ 致命写法
这是最常见的错误,也是事故的直接原因:
JavaScript
// 直接在前端组件里调用第三方 API
const response = await fetch('https://api.openai.com/v1/chat/completions', {
method: 'POST',
headers: {
'Authorization': 'Bearer sk-xxxxxxxxxxxxxxxx', // 密钥硬编码在这里
'Content-Type': 'application/json',
},
body: JSON.stringify({ model: 'gpt-4', messages: [...] }),
})或者稍微「聪明」一点的写法,用 NEXT_PUBLIC_ 前缀的环境变量:
JavaScript
// 同样是错的——NEXT_PUBLIC_ 开头的变量会被打包进前端代码
const apiKey = process.env.NEXT_PUBLIC_OPENAI_API_KEYNEXT_PUBLIC_ 这个前缀的意思就是「把这个变量暴露给浏览器」,用它来存密钥,跟直接硬编码没有本质区别。
✅ 标准写法
第一步: 在项目根目录创建 .env.local,把密钥写进去:
Plain Text
OPENAI_API_KEY=sk-xxxxxxxxxxxxxxxx注意:没有 NEXT_PUBLIC_ 前缀,这个变量只在服务端可见。
第二步: 确认 .gitignore 里有这一行,防止提交到 Git:
Plain Text
.env.local第三步: 创建一个 API Route,让它作为前端和第三方接口之间的中间层:
JavaScript
// /app/api/chat/route.js(App Router 写法)
export async function POST(request) {
const { messages } = await request.json()
const response = await fetch('https://api.openai.com/v1/chat/completions', {
method: 'POST',
headers: {
// 密钥从服务端环境变量读取,永远不会出现在浏览器里
'Authorization': `Bearer ${process.env.OPENAI_API_KEY}`,
'Content-Type': 'application/json',
},
body: JSON.stringify({ model: 'gpt-5.2', messages }),
})
const data = await response.json()
return Response.json(data)
}第四步: 前端只请求自己的 API Route,不直接碰第三方接口:
JavaScript
// 前端组件里
const response = await fetch('/api/chat', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ messages }),
})这样,前端代码里没有任何密钥的影子,浏览器里的用户也不可能通过任何手段拿到它。
5. 如果密钥已经泄露了,怎么办?
发现泄露之后,只有一个优先级最高的动作:立刻去 API 提供商的控制台把那个密钥吊销掉。
不是先改代码,不是先发公告,是先吊销密钥。密钥还活着的每一秒,账单都在跑。
以火山引擎为例,直接在 API Key管理界面点击禁用该API
吊销之后按顺序处理:
1.
在控制台生成一个新密钥。
2.
把新密钥更新到服务器的环境变量里(本地更新 .env.local,线上更新 Vercel 等平台的配置。修改完 .env.local后,必须重启项目才能生效)。
原先:API Key 直接暴露在GitHub仓库里
修改后:API Key 从app.js 里移除,.env.local 也没有被上传
3.
检查 Git 历史记录——如果旧密钥曾经被提交过,光删掉文件是不够的,Git 历史里还留着,需要进一步处理
吊销密钥解决的是"这把钥匙不能用了",但 Git 历史检查解决的是另一个问题:这把钥匙的照片还挂在互联网上。如果旧密钥还留在 Git 历史里,其他人可能找到和密钥一起提交的数据库地址等其他敏感信息
基本操作
直接去 API 供应平台废掉旧的 API Key。其他敏感信息(如数据库密码)如果也一并提交过,同样的处理方式——废掉旧的,换新的。
高级操作
如果你的仓库是公开的,或者你想彻底抹掉历史痕迹,可以使用 git filter-repo 或者联系平台客服处理历史记录。
如果没有安装过 git-filter-repo,首先在 TRAE 等编程工具安装,指令如下:
Bash
pip3 install git-filter-repo --break-system-packages
# 或者用 brew
brew install git-filter-repo不过git-filter-repo这个工具有一个保护机制——重写历史是不可逆的高危操作,它会强制要求你在一份"备份"上操作,万一搞砸了原来那份还在,克隆指令如下:
Plain Text
git clone https://github.com/你的用户名/api-key-demo.git api-key-demo-clean接下来就可以用 git-filter-repo 把密钥从所有历史中替换掉:
Bash
echo "sk-or-v1-你的真实密钥==>LEAKED_KEY_REMOVED" > replacements.txt
git filter-repo --replace-text replacements.txt最后强制推送到 GitHub:
Bash
git push --force --all清理好后再回到刚刚的Commit记录查看,API Key 已经变成了"LEAKED_KEY_REMOVED"
4.
查一下账单,评估损失,必要时联系 API 提供商申诉。
6. 课后作业
把你上一课(C9)接入的那个 API,按本课的标准结构重新改造一遍:
1.
把 API Key 从前端代码里删掉,移入 .env.local。
2.
新建一个 API Route 作为中间层,让服务端来持有和使用这个密钥。
3.
前端改成请求你自己的 API Route。
4.
检查 .gitignore,确认 .env.local 在里面。
改完之后,打开浏览器开发者工具的 Network 面板,看看前端发出的请求里有没有任何密钥字样——如果一个都找不到,说明你做对了。
学习进度确认
你可以点击下方按钮,一键将整门课程标记为学完。