这篇文章的起因很简单——我在一个开发群里答疑有人问起 AI 编程、大模型、Skills、MCP 这些东西到底怎么选、怎么组合才不浪费钱我回复完才发现信息量直接失控了。干脆把压箱底的 30 多个开发测试资源全翻出来用亲测结果说话优缺点和免费渠道一起配齐。先说清楚这份清单适合谁看正在用或准备用 AI 辅助写代码的开发者、想搭私有化大模型做应用测试的技术负责人、对 Agent Skills 和 MCP 感兴趣但被各种名词绕晕的新手以及做安全分析、EDA 设计、游戏开发等垂直领域、到处找现成工具的朋友。下文涉及的工具我都按免费优先、亲测优先、维护活跃优先三个标准筛过那些挂了半年没人管的项目直接扔了。搞完这一轮你至少能搞明白四件事Codex 到底值不值得付费、小模型怎么选怎么部署、Skills 和 MCP 在工具链里各扮演什么角色以及真出问题的时候怎么排查。1. 先盘一盘今年真正值得入手的 AI 开发资源1.1 为什么我把资源分成四类资源一多最忌讳的就是堆在一起让你自己抠。我把它们按作用拆成四条线分别对应一个团队或一个独立开发者在做 AI 应用时必然碰到的四个环节AI 编程工具负责产出代码解决怎么写的问题。大模型资源负责提供能力解决用什么模型的问题。Skills负责给 Agent 喂知识解决怎么按我的方式来干活的问题。MCP负责打通工具链解决怎么连上外部系统的问题。这个分法不是我拍脑袋定的是从实际工作流里倒推出来的。你平时用 AI 写代码先得有个编辑器接入模型这是第一层模型本地跑还是调 API这是第二层写完的代码要测试测试要连数据库、跑浏览器、调调试器这是第三层如果你还想让 Agent 按团队规范产出代码就得把规范写成它认识的格式这是第四层。一层层剥下来正好对应这四类资源。1.2 资源筛选的三个硬标准我在整理这 30 多个资源的时候给自己定了三条硬规矩也建议你照着这个标准去筛网上的推荐帖第一必须有免费渠道。不是说我反对付费工具但开发测试阶段的开销应该控制在零先把流程跑通再谈预算。所以下面每个付费工具旁边我都会标注它的免费替代方案。第二能本地跑的优先本地跑。尤其是大模型本地部署不只是省钱还能避免把代码、数据、业务逻辑全扔到别人的服务器上。这一点在做工业检测、内部系统这类场景时尤其重要。第三看社区活跃度。一个工具再炫如果 issue 区三个月没人回复那它大概率已经死了一半。我不推荐任何看起来很美但实际没人维护的项目。2. AI 编程实测从 Codex 到 Skills 的生产力组合2.1 Codex 值不值得付费以及免费的替代方案最近 Codex 的风头很猛它是 OpenAI 推出的 AI 编程 Agent跟普通补全型工具不一样的是它能自己读仓库、跑命令、改代码、跑测试一条龙干完。实测下来它的优势非常明显长上下文能力很强能把一个中大型项目的代码结构装进脑子里改 bug 的时候不用反复粘贴文件内容。而且它可以直接操作终端测试失败了自己看日志、自己改循环往复直到通过。但它的缺点也很扎心贵而且费 token。跑复杂任务的时候几个来回就能消耗掉大量上下文额度如果你用的是付费档看着配额往下掉确实肉疼。另外它偶尔会自作主张改一些你不希望它动的地方所以代码评审环节不能省。这里给大家两条免费替代路径。一条是本地方案用 Continue 插件搭配 Ollama 部署的 Qwen 或者 Llama 系列虽然聪明程度跟 Codex 有差距但做补全和局部重构够用数据不出本机。另一条是云端的免费额度比如 GitHub Copilot 的免费版、Google AI Studio 里的 Gemini 编程档以及部分云厂商给新用户的免费试用包这些跑日常 demo 完全够。我自己的习惯是复杂架构改动用 Codex日常补全和小重构用免费工具两边互补。2.2 Codex Skills给 Agent 挂上专属技能包Codex 在 2025 年底正式支持了 Skills这意味着你可以给它定义特定的工作流。以前让 AI 干活你得在对话里反复交代规则比如代码规范看 docs/style.md测试跑 pytest构建用 pnpm现在这些全都可以固化成一个技能包。具体安装方式有两种。第一种是从官方 Skills 市场直接拉取执行codex skill add 技能名就能自动装好第二种是手动创建在~/.codex/skills/目录下建一个文件夹里面放一个 SKILL.md 文件作为说明书再放一堆参考文档和脚本。一个典型的技能包结构长这样~/.codex/skills/my-project-rules/ ├── SKILL.md # 描述这个技能的用途和使用规则 ├── references/ │ └── code-style.md # 团队代码规范 └── scripts/ └── verify.sh # 跑校验的脚本SKILL.md 里用 Markdown 写清楚触发条件、执行步骤、注意事项Codex 聊到相关内容时会自动加载它。实测下来这套机制最大的价值是把隐性知识显性化了。以前新人来了要口口相传项目规范现在把规范写进技能包AI 每次动手都按规范走代码风格稳定很多。2.3 好用的 AI 编程提示词模板很多人问AI 编程提示词到底该怎么写其实核心就一句话给足上下文明确产出物限定边界。我常用的一个通用模板是这样的任务修复 [模块名] 中的 [bug 描述]。 上下文相关文件在 [路径]核心逻辑是 [一句话说明]。 约束不要改动 [哪些部分]遵守 [某个规范文件]。 产出输出修改后的代码 diff并说明改动原因。 额外运行 [测试命令] 验证如果失败继续修。这个模板看起来简单但效果比我见过的一大堆花哨 prompt 都好。原因是它把 AI 从猜你想干什么变成照单执行。还有一个技巧是给 AI 提供错误输出原文比你自己描述一万句都有用。测试阶段尤其如此——直接把报错堆栈贴进去让它定位到具体文件和行号修 bug 效率至少翻倍。3. 大模型资源小而美的开源货架与免费渠道3.1 值得本地跑的小模型一个比一个有意思大模型不是越大越好本地部署的时候更是如此。这半年我陆陆续续测了社区里讨论度比较高的几个有几个小模型非常值得放进测试货架。Space Bunny 是我最近注意到的一个轻量级模型主打消费级显卡上跑推理定位偏向日常对话和代码辅助。实测下来它的响应速度确实快显存占用比同体量的一线模型低一截适合拿来做本地 API 服务的验证。注意它跟那些超大杯闭源模型不是一个赛道别拿它做高难推理做测试链路是强项。Agnes 是社区近期冒出来的新面孔以官网可直接下载权重的方式发布部署流程比较顺滑。身边有几个朋友拿它跑文档抽取和信息整理说结构化输出的稳定性不错。我的评价是值得放进基准测试名单里跑一把反正模型下载不要钱。Herdsman 的定位是垂直场景专用我看到有人在讨论用它做特定领域的文本清洗效果比通用模型稳。不过它的社区资料还比较少遇到问题得自己啃源码适合喜欢折腾的开发者。还有一个不得不提的是造相 z-image-turbo这是一个绘图方向的大模型用起来跟常规聊天模型完全不是一个路数。它主打快速生成图片出图速度比早期版本快不少。做设计素材批量生成、原型图占位的时候本地跑一个这个模型比每次调在线 API 划算。这些小模型怎么选我的建议是别只看跑分直接拿你自己的数据测。下载之后用同一个 Prompt 跑一轮看输出质量和速度感受最直观。3.2 免费大模型 API 渠道汇总亲测可薅如果你不想折腾本地部署直接用免费 API 把功能串起来是最快的路径。我实测过几个还算稳定的免费渠道整理成表供参考渠道免费额度情况适合场景Google AI Studio有免费模型额度速率限制较低原型验证、小流量 demoGroq提供免费开发者额度推理速度快需要低延迟的测试接口GitHub Models与 GitHub 账号绑定有免费试用模型开发调试、学习大模型 APICloudflare Workers AI免费套餐有一定请求数边缘函数集成测试硅基流动平台上有开源模型的免费档国内网络环境下快速调试有一个关键词大家搜的时候容易搞混就是免费大模型 API和开源大模型——开源模型要自己部署免费 API 是别人帮你部署好白给你调用两者不是一回事。免费 API 适合快速验证但如果你想做长期稳定的业务还是得规划自己的部署方案。上面这几个渠道普遍有速率限制别拿它们跑生产流量只做开发测试问题不大。另外这些平台的免费政策调整比较频繁我上面写的以现在为准用之前建议去官网确认最新规则。3.3 单机部署还是云联网从工业检测场景说起有人问过我一个特别实际的问题像工业 AI 检测、服装质检这类场景用的是云联网还是单机 AI到底选什么大模型足够我自己接触过的工业检测项目绝大多数摄像头和数据都在工厂内网图片涉及产品参数和工艺是不能传到外网的。再加上产线上的检测要求毫秒级响应网络抖动一次可能就是一批不良品漏检。所以单机部署几乎是硬性要求至少也是局域网内的私有化部署云联网只用于模型更新和远程运维。模型选择上工业检测通常分两步先用目标检测模型定位缺陷区域再用分类模型判断缺陷类型。这类任务里YOLO 系列等垂类模型依然是主力大语言模型反而用不上。只有在检测结果汇总、生成质检报告、异常原因分析这些环节才会用到 7B 到 14B 参数量的本地大模型通过 Ollama 或者 vLLM 部署。云联网平台在这种场景下不是不行但要把数据脱敏、专线、合规这三件事都做扎实成本往往比单机更高。至于部署工具Ollama 适合入门一条命令就能把模型拉起来跑 APIvLLM 吞吐量高适合真正有并发压力的业务。如果你只有一台 4090 或者 Mac Studio先用 Ollama 撑着就行别一上来就堆分布式推理框架。4. Skills 生态从官方市场到 GitHub 的现成玩法4.1 先搞清楚 Skills 是什么和 MCP 有啥区别Skills 最近特别火源头是 Claude Agent Skills。它的定义可以这样理解一个 Skill 就是一份结构化的指令包里面写着当遇到什么情况时按什么步骤、用什么工具、参考哪些资料来处理。它不是模型能力本身而是让模型在特定场景下表现得像受过专门培训的员工。很多人把 Skills 跟 MCP 混在一起这是今年我看到的最大的认知误区。两者完全不是一回事。我给一个容易记得住的比喻Skills 是给 Agent 的岗位说明书MCP 是给 Agent 的电源插座。岗位说明书教它遇到事情按流程办电源插座让它能使用插上去的设备。Skills 不产生连接能力MCP 不产生业务知识二者配合使用才有完整效果。维度SkillsMCP本质提示词脚本参考文档的结构化集合模型与外部工具之间的标准化协议解决什么问题让 Agent 懂特定领域的工作流让 Agent 能调用外部工具和数据典型例子前端开发规范、测试流程数据库连接器、浏览器操作器配置位置~/.claude/skills或~/.codex/skills各工具的 mcp.json是否需要联网不需要静态文件取决于工具类型搞懂这个区别之后你再去看网上那些资源就不会懵了。4.2 Skills 搜索、安装与管理工具实测Skills 生态发展快催生了一批专门用来搜技能、装技能、管理技能的工具。我实测了几个比较有代表性的find skills 是一个技能搜索工具帮你按关键词在海量技能库里找需要的包。它解决的核心痛点是不知道该装什么你搜一下前端测试Git就能看到一堆候选按热度排序再装。skills ui 是可视化管理界面。默认情况下技能包都是文件夹散落在本地一个个看很麻烦。它把已安装的技能、版本、启停状态全部展示在一个面板上鼠标点两下就能切换技能开关。对于技能装得多的开发者来说这个工具能省下大量时间。reasonix 是一个我最近在关注的管理工具它不仅支持从市场安装新 skills还能做技能组合编排。它的独门功夫是能定义技能依赖关系比如你装了一个前端构建技能它会提醒你还需要配套的Node 环境检查技能。这个功能对搞复杂 Agent 工作流的人特别有用。安装技能的时候最常用的方式是命令行一条skill install 名字版本搞定。装完记得看下目录结构确认 SKILL.md 文件确实存在别装了个空壳。4.3 前端开发 Skills 实战从下载到验证前端开发是 Skills 用得最广的场景之一。我拿一个实际项目演示完整流程。先搜一下可用的前端技能包找到目标后执行安装命令claude skill add web-development # 或者 codex skill add frontend-best-practices技能装完后进~/.claude/skills/web-development/看看里面有什么。正常情况会有一个 SKILL.md里面定义了组件写法的规范、样式优先级、目录组织的建议甚至包含了实际项目的代码片段作为示例。验证技能有没有生效最好的方法是开一个新会话直接问 Agent按照已安装的前端规范帮我生成一个 React 按钮组件。如果配置成功你会发现输出代码的风格跟你设置的锦囊内容一致而不是 AI 默认的那套写法。这个机制非常有价值。前端团队想统一代码风格以前靠 code review 一遍遍指出问题现在直接在 Skill 里写清楚组件命名用 PascalCase、样式用 CSS Modules、禁止内联样式AI 生成的新代码自动遵守等于给团队装了一个全自动的规范检查员。5. MCP 资源盘点连接器才是真生产力5.1 MCP 的工作原理我用大白话讲透MCP全称 Model Context Protocol翻译过来是模型上下文协议。为什么它这么重要因为它统一了 AI 工具和外部系统的对接方式。在 MCP 出现之前每家 AI 工具都要单独开发插件去连接数据库、浏览器、设计软件非常零散。现在只要外部工具实现了 MCP Server任何支持 MCP 的 AI 编排工具都能直接连。MCP 的架构分三块左边是 MCP Host比如 Codex、Claude Desktop 这样的客户端中间是 MCP Client负责在 Host 和 Server 之间做桥接右边是 MCP Server它把具体功能暴露出来。通信底层用的是 JSON-RPC 2.0消息格式是标准化的。你用它的视角看整个过程就是给 AI 装了一堆USB 接口插上什么设备就能用什么设备。比如插上数据库 MCPAI 就能直接查数据插上浏览器 MCPAI 就能操控网页。配置 MCP 也很简单大多数客户端支持同一个 JSON 格式。以下是一个典型配置片段{ mcpServers: { figma: { command: npx, args: [-y, figma/figma-mcp-server], env: { FIGMA_API_KEY: 你的密钥 } } } }把它保存到~/.codex/mcp.json或项目根目录下的.codex/mcp.json重启客户端生效。整体思路跟拼乐高差不多一个配置块对应一个外部服务。5.2 开发调试场景的 MCP 神器IDA、x32dbg、Unreal、AltiumMCP 生态里最有意思的不是那些通用工具而是垂直领域的深度整合。这半年我看到了几个非常提效的项目。安全研究和二进制分析场景里IDA MCP 和 x32dbg 的 MCP 插件非常值得关注。IDA 是静态分析的主力工具x32dbg 是动态调试的常用工具。社区做的 MCP 桥接项目可以让 AI 直接读取反汇编结果、设置断点、读取寄存器状态甚至根据伪代码分析漏洞路径。实际用起来AI 可以自动完成一部分读代码、找可疑点、确认调用链的重复劳动分析人员只需要审阅 AI 的结论。不过这类工时工具要特别注意运行权限实验室环境里玩没有问题某些生产环境会限制调试器的自动操作这个要提前跟安全策略对齐。游戏开发这边Unreal 5.8 MCP 是近期社区里比较热的话题。它把虚幻编辑器的常见操作封装成 MCP ServerAI 可以通过自然语言调用编辑器命令比如批量创建关卡元素、调整材质参数、跑构建脚本。对独立游戏开发者来说最直接的价值是省去大量 UI 点选操作把重复工作交给 AI 执行。电子设计自动化领域也有新动向有人在做 Altium Designer 的 AI 接口 MCP。这个项目可以把 PCB 设计中的器件选择、布局检查、DRC 结果查询暴露给 AI 模型。硬件设计软件的数据格式复杂能做到这个程度并不容易。虽然目前功能范围还比较有限但思路很清晰以后硬件的评审助理可能真的能落地。这类垂直领域 MCP 的前景很大但也意味着它们往往没有商业公司维护装之前先看 last commit 时间别装一堆没法维护的半成品。5.3 浏览器与流式输出Dify 和 CherryStudio 的接法Dify 是很多人做 LLM 应用编排会用的平台它本身已经内置了不少工具而浏览器 MCP 则把它扩展成了能操作浏览器的智能体。配置方式是在 Dify 的自定义工具里添加 MCP 服务地址把浏览器操作的 Server 挂上去。之后你可以在工作流里加一个节点让 AI 打开某个页面、提取正文、填表单这些过去要写 Playwright 脚本才能做到的事现在用自然语言就能编排。CherryStudio 是另一款常用的 AI 桌面客户端它支持通过 MCP 工具把内容流式输出到本地文件。这个能力在做日志分析、批量文本处理时特别方便。配置路径大致是在客户端设置里找到 MCP 管理添加一个文件写入的 MCP Server然后在对话里让它把结果写到指定路径。实测下来流式输出的过程中就能看到文件在持续增长不需要等整段生成完再保存对长文本生成场景很友好。这两个工具的接法有个共同点都是把模型能力和系统能力通过 MCP 做了解耦。你换模型MCP 不用动你换客户端只要它还支持 MCP 协议配置基本可以平移。6. 常见问题排查实录与避坑清单6.1 Codex 找不到 MCP 的排查思路MCP 配置好之后客户端提示找不到服务这是我被问过最多的问题。大部分情况下不是配置写错了而是位置不对或者服务没起来。先按这个顺序排查第一步确认配置文件的位置。Codex 全局配置在~/.codex/mcp.json项目级配置在项目根目录.codex/mcp.json。很多人把文件放到了仓库子目录里客户端根本不会去读。第二步确认配置里的命令能独立运行。比如配置里写的npx -y 某个包你在终端先手动跑一遍。如果终端跑不通问题出在依赖或者网络环境MCP Server 自然起不来。第三步确认没有改完配置不重启。MCP 配置是启动时加载的开着的会话里改了不会热生效重启客户端再说。按这三步排查下来九成问题都解决了。剩下那一成多半是 CLI 工具版本太老导致对 MCP 支持不完整直接升级即可。6.2 Codex 接入 Figma 时的授权卡点AI 编程工具接入设计稿是个热门需求Figma MCP 是解决AI 照着设计稿写前端的关键一环。但很多人在授权这一步被卡住。Figma MCP Server 的认证方式有几种常规路径是 OAuth。你需要去 Figma 开发者后台创建应用配置回调地址获得 Client ID 和 Client Secret然后把它们写进 MCP 配置的环境变量里。启动时终端会弹出授权链接到浏览器里完成确认把回调 URL 粘贴回终端即可。容易踩的坑有五个回调地址配错、没有开启相关 API 权限、授权链接是在无头环境下弹出导致无法点击、配置的环境变量名跟文档不一致以及多人协作时每个人都要单独授权一次。遇到授权失败的时候回到开发者后台看权限列表比在终端里瞎试有效得多。6.3 上下文长度、模型选型与私有化部署经验上下文长度是大模型选型时绕不开的一个参数。我见过不少人忽略它结果任务跑到一半 AI 突然失忆把早期的约束条件全忘了。简单说上下文长度决定了模型一次性能看到多少内容。做代码分析、长文档总结这类任务尽量选上下文长一点的模型比如 128K 及以上的做短文本分类、实体抽取这种轻量任务32K 也够用硬上长上下文反而拖慢响应速度。另外一个隐藏成本点上下文越长token 消耗越多费用和响应延迟都会上升所以够用就好比越长越好更实际。模型选型这件事我的习惯是列一个对比表把几个候选模型分别在准确率、响应速度、显存占用、部署难度和许可证这几个维度打分最后根据实际业务侧重点做决策。比如离线环境不能用闭源模型那就重点看开源项目的许可证和社区成熟度如果业务对延迟极其敏感那就算效果差几个点也得优先选推理速度快的。私有化部署的经验是先小后大。一开始用 Ollama 拉一个小模型把整个链路跑通确认 API 格式、数据流、权限控制都 OK再上 vLLM 做并发优化。不要一上来就搭 Kubernetes 集群很多项目根本走不到那一步。部署完之后至少做三件事用脚本定期检查服务健康状态、给模型文件做备份、把 GPU 显存监控接上告警这样后面出了故障才不会抓瞎。7. 最后说点掏心窝的这份清单整理完我最有感触的一点是工具增长速度已经远超大多数人的学习速度。数一下你身边做开发的朋友可能还有一半没分清 Skills 和 MCP。这很正常信息过载时代的关键不是知道所有工具而是在需要的时候知道去哪找。我自己每隔两个月会把这类资源重新扫一遍该扔的扔该留的留顺便检查一下哪些免费额度过期了、哪些社区项目停止维护了。这份清单你拿过去别照单全收先从免费的开始试觉得顺手再往深了折腾。最后送一个小习惯每接触一个新工具先花十分钟看看它的配置文件长什么样再看它的目录结构。配置文件能告诉你它怎么跟外部系统打交道目录结构能告诉你它的设计哲学。看懂这两样你就已经比一半的教程博主更懂这个工具了。