前段时间我把手头的 AI 工具站彻底推倒重写了一版。重写之前其实已经有一个能跑的版本工具也有三十多个但用起来总觉得像套了个壳的对话框用户点进来不知道该干嘛。这次重做我给自己定了三个硬指标工具够具体、模型够用、没人掏钱也能顺畅用。于是就有了现在这版48 个工具、8 个模型文字类工具已经全部跑通 DeepSeek图像和视频还挂在路线图上正在补。这个项目对两类人最有用。一类是自己想搭 AI 工具站但不知道怎么下手的个人开发者可以照着这套架构和接入方式少走弯路另一类是已经在做类似产品、卡在模型接入选型和成本控制上的朋友我踩过的坑和排查思路可以直接抄作业。文章里讲的不是概念是已经跑起来的实现方案包括配置驱动的工具扩展机制、DeepSeek 的完整接入链路、免费策略下的限流与降级处理以及文生图、文生视频的技术选型思路。1. 一个人的工具站为什么要重做一版1.1 旧版输在哪工具多但不好用旧版的问题不在技术在定位。我当时一口气塞了几十个工具每个都是输入一句话调用某个大模型回复一段话界面几乎长一个样用户刷三五个页面就发现这跟直接打开 ChatGPT 没什么区别唯一的差别是我这边还有广告。留存率低得可怜用户来了生成一次走了再也不回来。这次重做前我认真复盘了一下核心毛病出在工具感太弱。工具的含义是我知道输入什么、期待输出什么而不是开放式聊天。比如同样是文案生成直接说帮我想个广告语和给一个固定表单让你填品牌名、产品卖点、目标人群、语气风格然后一键生成 10 条带理由的广告语这体验完全是两回事。后者才是工具站该有的样子用户不需要组织语言只需要填空。1.2 这版定位不是套壳对话而是场景化工具箱想明白这一点重做的方向就定了48 个工具每一个都必须有明确的输入表单、固定的 prompt 模板、规范化的输出格式。用户打开页面看表单就知道要提供什么看按钮就知道能拿到什么结果整个过程不需要跟模型对话也不需要懂任何 prompt 技巧。这等于把跟模型聊天这件事拆解成了面对具体任务的操作流程。背后依赖的是大模型的指令跟随能力但用户感受不到模型的存在只会觉得这工具还挺好用。我刷了近几年的爆款工具站筛选标准其实也是这个用户遇到具体问题比如写周报、取标题、生成正则表达式他们不想要一个万能的回答者而想要一个专门解决这类问题的入口。1.3 为什么文字优先、图像视频后置技术选型上我做了很明确的优先级排序文字类工具先上。原因很直接文字类已经是当下最成熟的场景模型 API 便宜、延迟低、返回稳定一个人完全扛得住而图像和视频涉及 GPU 资源、分布式排队、显存管理这些都不是一台普通云服务器能解决的。与其两个方向都做半吊子不如先把文字类打磨到能稳定服务把用户留存和成本模型跑通再腾出手来做图像视频。加上当时 DeepSeek 在文字生成上的综合表现已经相当能打API 价格也压到了极低的水平这让我确认了文字打底、图像视频续航的节奏是划算的。2. 48 个工具和 8 个模型的架构怎么设计2.1 整体架构配置驱动是单人开发的核心一个人维护 48 个工具最忌讳的是写 48 套页面和 48 套接口逻辑。我采用的是配置驱动的结构所有工具的定义都放在一个 JSON 配置里前端根据配置自动渲染表单后端根据配置自动拼接 prompt、选择模型、解析参数。新加一个工具不动一行页面代码只加一段 JSON 配置。这样说可能有点抽象我拿小红书文案生成这个工具举例配置的核心字段大致是这个样子{ id: xiaohongshu_copy, name: 小红书文案生成, category: 文案营销, model: deepseek-chat, temperature: 0.8, max_tokens: 1024, system_prompt: 你是一名熟悉小红书风格的中文写作者擅长用口语化、带情绪、有节奏感的文字结构输出内容。, user_prompt_template: 请根据以下主题写一条小红书文案\n主题{input}\n要求包含吸引人的开头、2~3个要点、结尾话题标签。, fields: [ { key: input, label: 主题或商品信息, type: textarea, required: true } ] }前端拿到这个 JSON会根据 fields 字段渲染出表单后端拿到这个 JSON会把 temperature、max_tokens 这些参数动态传给模型接口。工具数量从 10 个涨到 48 个对代码的压力几乎为零真正的压力在于每个工具的 prompt 质量。所以我把运营重心放在优化 prompt 模板和调整参数上而不是堆功能页面。2.2 8 个模型怎么选、怎么接入文字类跑通 DeepSeek 之后我并没有把所有工具都绑死在 DeepSeek 上而是做了一个多模型接入层接入了 8 个模型让不同场景自动选择最合适的模型同时保留降级方案。以下是当时接入的模型和各自承担的角色模型角色使用场景DeepSeek V3deepseek-chat文字主力绝大多数文字生成类工具综合效果好性价比高DeepSeek R1deepseek-reasoner复杂推理逻辑题、数学题、代码调试、需要深度推理的工具Qwen-Plus备用路由DeepSeek 繁忙或超时时的自动降级模型GLM-4-Flash轻量任务摘要、分类、关键词提取这类低成本短文本任务Moonshot-v1-8k长文场景长文总结、多段落改写上下文窗口更宽Doubao-Pro创意文案中文语感要求高的营销文案类工具Qwen-Turbo高频轻量取名、标题、短问答这类 token 消耗极小的工具本地开源 7B 模型最终兜底所有云端接口不可用时的本地降级方案接入层统一走了 OpenAI 兼容协议也就是说无论底层是哪家模型到我这边都是同一个 chat completions 接口格式差异只在 model 字段和 base_url。这样一来模型路由变得非常简单本质上就是一张工具 ID → 模型名称的映射表运行时按映射调用不同服务商的接口。2.3 工具清单的设计思路从分类到 prompt 沉淀48 个工具不是随便凑的我先按使用场景分了七类再逐类补充。文案营销类比如小红书文案、电商产品描述、短视频标题写作辅助类比如扩写、缩写、改写、纠错办公效率类比如周报生成、会议纪要、邮件回复编程相关类比如代码解释、Bug 定位、正则表达式生成学习类比如古文翻译、英文润色、论文摘要创意类比如小说开头、藏头诗、对联生成生活实用类比如菜谱规划、健身计划、旅行攻略。分类的意义不只是好看它直接影响 prompt 沉淀。同一类工具之间写作风格、语气偏好是相近的我可以抽出一份公共的 system prompt 作为基座再在每个工具里补充差异化的指令。这个设计后来帮了大忙DeepSeek 的模型能力本身很强但优秀的输出必须依赖优质的指令而按类维护指令比按工具单独维护效率高太多了。3. 文字类工具跑通 DeepSeek 的完整链路与关键参数3.1 API 调用链路统一 OpenAI 兼容协议DeepSeek 是目前接入成本最低的大模型之一因为它直接提供 OpenAI 兼容接口官方也在文档里给出了 base_url 和模型名。我的后端跑的是 Python直接用了 OpenAI 官方 SDK把 base_url 指到 DeepSeek 的接口地址然后按正常的 chat completions 方式调用关键代码如下from openai import OpenAI client OpenAI( api_keysettings.deepseek_api_key, base_urlhttps://api.deepseek.com ) resp client.chat.completions.create( modeldeepseek-chat, # 或 deepseek-reasoner messages[ {role: system, content: tool_def[system_prompt]}, {role: user, content: user_prompt} ], temperaturetool_def.get(temperature, 0.7), max_tokenstool_def.get(max_tokens, 2048), streamTrue )这段代码看着简单但有两个细节决定了成败。第一是 api_key 绝不能写死在代码里我用环境变量管理部署时从配置中心注入避免打包时泄露。第二是 streamTrue 一定要开我做了对比测试不开流式整个接口的响应体感时间会长一倍对工具站这种等待结果的交互非常致命。3.2 流式输出和上下文管理流式输出在实现上是 SSE 协议后端不断把 token 推给前端。我在前端用 fetch 读取流解析每一次 chunk再把内容逐段渲染到展示区同时做轻量的 Markdown 解析和代码高亮。用户看到的效果是文字一行行冒出来配合打字机光标等待感明显弱很多。上下文管理方面48 个工具里绝大多数都是单轮任务不需要多轮对话所以我每次请求都只传一条 system prompt 加一条用户消息干净利落。少数对话类工具比如职场沟通模拟和口语练习我单独设计了会话模块后端最多保留最近 6 轮消息超出后把最早的消息摘要压缩一版再继续传避免对话越长上下文越贵的成本失控。3.3 temperature、max_tokens 与 prompt 模板的搭配模型参数不是拍脑袋定的我根据工具类型做了一套参数基线。创意类工具比如小红书文案、广告语、小说开头temperature 放到 0.8 到 1.0让输出更有发散性事实类工具比如代码解释、论文摘要、数据提取temperature 压到 0.3 以下减少胡编乱造介于中间的改写、润色、翻译类工具维持 0.5 左右。max_tokens 的设置同样有讲究。我在配置里按工具设定上限比如取名字的 max_tokens 只需要 300而长文总结需要 2000 以上。这样做表面上是限制输出长度实际上是控制接入层的资源占用防止某个工具吃满模型返回而导致后续请求排队。顺便说一句max_tokens 设小不会影响输入长度输入长度由上下文窗口约束DeepSeek 官方文档给的窗口足够日常使用但我还是把单次输入控制在 8K 以内超长文本走摘要压缩流程。3.4 多模型路由DeepSeek 主力、其他模型兜底模型路由我做了三层策略。第一层是默认路由工具配置里写了哪个模型就用哪个模型大多数工具直接落在 deepseek-chat 上只有推理类工具落到 deepseek-reasoner。第二层是自动降级如果 DeepSeek 接口返回限流或超时后端自动把这个请求重试到 Qwen-Plus 上用户几乎感知不到最多觉得慢了一点。第三层是本地兜底如果所有云端接口都挂了本地部署的开源 7B 模型顶上保证页面不报错生成质量差一些但至少有输出。这种一主多备的路由结构对个人开发者来说是刚需。因为免费工具站的高峰流量不可预测单靠一家服务商很容易被限流而多模型轮换既能延展容量又给了自己议价和迁移的弹性空间。4. 免费策略与成本控制一个人也能扛住4.1 单次请求成本到底是多少说到免费工具站所有人都会问一句钱从哪来。我的答案很朴素先把自己烧的钱降到最低。DeepSeek 的 API 价格公开单次请求的成本低到什么程度呢我这边实际统计下来一个普通文案生成任务输入加输出加起来大概消耗 800 到 1500 个 token成本折合人民币基本在一分钱以内。长文总结类任务消耗会高一些但也不超过几分钱。也就是说即使每天几千次请求只要不被恶意刷量一个月的 API 账单完全在个人开发者可承受范围内。这也是为什么我敢把工具站做成免费当单次边际成本足够低用免费换取用户量和技术口碑比一开始就收费追求回本要有价值得多。4.2 缓存、降级与限额三板斧成本控制不是靠祈祷用户少用而是靠系统设计。我上了三层机制。第一层是结果缓存对于相同工具、相同输入参数的请求如果结果在 Redis 里且没过期直接返回缓存结果不再调用模型接口。这在固定模板场景下效果明显比如古诗词接龙这种输入重复率高的工具缓存命中率非常高。第二层是模型降级正如前面说的当主模型繁忙或费用曲线异常上升时自动切到更便宜的备用模型。我在工具配置里给每个工具设了一个预算档位创意类请求一般落到标准档而摘要、分类任何请求落到低档模型进一步压低消耗。第三层是配额管理。每个 IP 每天有免费的调用次数上限用完后会提示今日免费额度已用完。上限设计是动态的普通工具每天 50 次深度推理类每天 10 次这组数字是我跑了半个月后调出来的既能保证重度用户有得用又挡掉了大量脚本刷量。4.3 人机验证与防滥用额度上限只能挡住轻度滥用防不住恶意脚本。我加了 Cloudflare Turnstile 人机验证用户第一次访问工具页时会有个无感的验证脚本直接拿不到会话凭证。验证是一次性的之后 24 小时内不再弹出对真实用户基本无感知但对爬虫和批量调接口的程序是硬门槛。还做了一层基于设备指纹的频控。后端会给每个浏览器生成指纹标识和 IP 联合做限流判断。就算脚本换 IP只要设备指纹不变照样会被卡在额度内。这两层组合起来效果很明显目前每天被拦截的异常请求占比能到 20% 左右放在以前这些都会变成白花花的 API 费用。4.4 数据埋点与成本可视化最后说说成本可视化。我在后端给每次调用都打了日志记录工具 ID、模型名称、输入 token 数、输出 token 数、请求耗时。每 5 分钟聚合一次生成一张仪表盘实时展示今日请求总量、token 消耗总量和估算费用。这个习惯强烈建议每个做 AI 工具的人都养成没有数据的成本控制就是盲人摸象。有一次我发现某天费用异常飙高查日志发现是某个商品描述生成工具被某个用户用脚本刷了三千次。靠着日志定位到问题后我直接把这个工具的单个 IP 日配额调低了一档之后费用曲线立刻回归正常。如果没有数据埋点这种问题可能到月底账单出来才会发现。5. 实操中踩过的坑从超时到被薅一次说清5.1 接口返回超时和报错怎么排查文字类工具刚上线那几天用户反馈最集中的问题就是转圈圈很久没反应。我一开始以为是模型慢后来看日志发现问题出在超时时间设置上。DeepSeek 高峰期排队可能超过 10 秒而我当时的 HTTP 客户端超时设的是 5 秒等于模型还没开始返回我这边就主动断开了。排查方法很简单把所有请求的超时时间拉长到 30 秒并且把超时后的处理从直接失败改成进入降级重试流程。同时给前端加了 Loading 状态提示承诺最长等待 30 秒用户心里有数了投诉反而少了。另外部分报错是 max_tokens 设得太小而触发了输出截断这类报错要区分清楚模型返回正常但内容明显中断多半是 max_tokens 不够调大即可和超时是两种完全不同的处理方式。5.2 长文本超出上下文窗口怎么办有个会议纪要生成工具需要用户粘贴长对话记录经常有人贴几万字进来直接把上下文窗口撑爆。我后来设计了一套 map-reduce 式的处理流程先把长文本按段落切块每块用便宜的小模型分别提取关键信息再把所有提取结果合并成一份紧凑的摘要最后把摘要送给主模型生成纪要。这个过程有个容易踩的坑切块大小和重叠度。切得太小信息割裂导致摘要丢失上下文切得太大小模型同样容易被截断。我自己调试后的经验是单块控制在 2000 字左右相邻块保留 200 字重叠这样既能覆盖上下文衔接又不会让单块内容过载。最终效果是用户贴 5 万字进来系统先花 5 秒左右做预压缩再花 15 秒生成纪要整体体验完全在可接受范围。5.3 被恶意刷量后的加固措施上线第二周我突然发现某个工具的调用量在一个小时内暴涨了十倍明显不是正常用户行为。第一时间我关掉了这个工具的外链分享入口然后看日志发现是有人在脚本里循环调用直接打的接口而绕过了前端页面。加固措施分三步第一步所有接口加了签名参数签名由前端页面动态生成有效期 5 分钟拿不到页面就不可能刷量第二步将 Turnstile 验证从首次访问改为首次调用接口时校验堵住直接调接口的通道第三步接口层加上了每秒每 IP 的令牌桶限流突发请求直接被丢弃。这套组合拳打完之后刷量基本绝迹正常的免费用户完全不受影响。5.4 prompt 模板管理的版本化方案还有一个不起眼但频繁踩的坑改 prompt。早期我直接改 JSON 里的模板上线后才发现新版 prompt 在部分工具上效果变差了但又没有快速回退的办法。后来我给每个工具的 prompt 加了一个 version 字段修改模板时保留旧版本线上默认跑最新版本后台可手动切换到任意旧版本。这个习惯帮我保住了一次事故某次我把英语润色工具的 system prompt 从强调地道改为强调简洁结果用户反馈输出质量明显下滑我直接在后台把 version 回退到上一版一分钟内恢复。如果你也在做配置驱动的工具站prompt 版本管理一定要从第一天就做起不然后面改坏的次数多了你连改坏的现场都找不回来。6. 图像视频工具还在路上技术路线与推进节奏6.1 文生图和文生视频的技术选型比较文字类跑通之后我把精力转向图像和视频。先说选型文生图这块我在 Flux、SDXL、SD3.5 这条线里做取舍。Flux 生成质感很稳但对显存要求高SDXL 生态成熟、插件丰富部署资料最多适合单人起步SD3.5 画质更强但社区资料相对少。我最终选了以 SDXL 为基线兼顾 ComfyUI 工作流后续如果显存和效果瓶颈明显再切 Flux。文生视频比图像更麻烦开源社区可用的模型就那么几个方向最核心的矛盾是单卡显存根本跑不动长视频一段十几秒的视频生成可能要占用一张高显存卡好几分钟。所以文生视频这边我的策略是先留接口再上服务后端把任务队列和回调接口先写好模型接入放在本地 GPU 机器上做灰度测试不追求一步到位。6.2 单机 GPU 下的任务队列设计一个人做图像视频最缺的是 GPU 资源最怕的是任务并发。我的设计是用户在前端点生成请求进入后端任务队列队列消费端连接本地 GPU 机器上的 ComfyUI 服务按顺序执行生成任务。生成结束后通过 WebHook 回调把结果地址写回数据库前端轮询查询任务状态完成后展示图片或视频。任务队列的排队机制直接用 Redis 的 list 结构实现先进先出同时记录每个任务的状态和失败重试次数。刚开始的时候我把并发数设成 1也就是一次只跑一个任务后面熟悉了并发处理再逐步放开。这套设计的价值在于图像视频功能即使模型本身没完全调好任务管理和状态展示的框架已经就位等接上模型就能直接输出。6.3 推进节奏从 MVP 到逐步放开图像视频这块我给自己排的节奏分三步。第一步是生图工具先跑通一个核心爆款比如商品主图生成或头像风格转换目标不是工具数量而是把单张图的质量打磨到可对外展示。第二步是接入局部重绘和图像编辑能力让用户能上传自己的图做背景替换和风格迁移这类功能对工具站的粘性提升比纯文生图大得多。第三步才是文生视频等 GPU 资源和成本模型都算清楚之后再上。行业里做图像视频的工具站很多一上来就铺十几个入口但生成排队动不动半小时用户体验反而极差。我更倾向于用批次开放的思路宁可只上三个能稳定输出的工具也不要上十个排队几十分钟的入口。等队列调度成熟、平均出图时间控制在两分钟以内再逐步增加工具数。我个人在实际操作里还有一个体会做这种一个人维护的免费工具站最重要的是别被功能数量绑架。48 个工具听起来多但真正带来新用户和回访的其实不到十个这部分才应该花八成的精力去优化 prompt、降延迟、调参。图像视频也是一样的逻辑先集中资源把一两个场景做到超出用户预期比铺满二十个平庸入口有价值得多。顺便分享一个小技巧每个工具上线后我都会在日志里统计生成成功率和平均请求耗时一旦某个工具成功率低于 90% 或耗时超过 20 秒就自动拉进优化队列这条规则几乎保证了我每次迭代都在做最紧要的事。