AI编程与本地大模型实战：Skills与MCP组合选型指南

这篇文章的起因很简单——我在一个开发群里答疑，有人问起 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 把功能串起来是最快的路径。我实测过几个还算稳定的免费渠道，整理成表供参考：

有一个关键词大家搜的时候容易搞混，就是"免费大模型 API"和"开源大模型"——开源模型要自己部署，免费 API 是别人帮你部署好白给你调用，两者不是一回事。免费 API 适合快速验证，但如果你想做长期稳定的业务，还是得规划自己的部署方案。

上面这几个渠道普遍有速率限制，别拿它们跑生产流量，只做开发测试问题不大。另外这些平台的免费政策调整比较频繁，我上面写的以现在为准，用之前建议去官网确认最新规则。

3.3 单机部署还是云联网，从工业检测场景说起

有人问过我一个特别实际的问题：像工业 AI 检测、服装质检这类场景，用的是云联网还是单机 AI，到底选什么大模型足够？

我自己接触过的工业检测项目，绝大多数摄像头和数据都在工厂内网，图片涉及产品参数和工艺，是不能传到外网的。再加上产线上的检测要求毫秒级响应，网络抖动一次可能就是一批不良品漏检。所以单机部署几乎是硬性要求，至少也是局域网内的私有化部署，云联网只用于模型更新和远程运维。

模型选择上，工业检测通常分两步：先用目标检测模型定位缺陷区域，再用分类模型判断缺陷类型。这类任务里，YOLO 系列等垂类模型依然是主力，大语言模型反而用不上。只有在检测结果汇总、生成质检报告、异常原因分析这些环节，才会用到 7B 到 14B 参数量的本地大模型，通过 Ollama 或者 vLLM 部署。云联网平台在这种场景下不是不行，但要把数据脱敏、专线、合规这三件事都做扎实，成本往往比单机更高。

至于部署工具，Ollama 适合入门，一条命令就能把模型拉起来跑 API；vLLM 吞吐量高，适合真正有并发压力的业务。如果你只有一台 4090 或者 Mac Studio，先用 Ollama 撑着就行，别一上来就堆分布式推理框架。

4. Skills 生态：从官方市场到 GitHub 的现成玩法

4.1 先搞清楚 Skills 是什么，和 MCP 有啥区别

Skills 最近特别火，源头是 Claude Agent Skills。它的定义可以这样理解：一个 Skill 就是一份结构化的指令包，里面写着"当遇到什么情况时，按什么步骤、用什么工具、参考哪些资料来处理"。它不是模型能力本身，而是让模型在特定场景下表现得像受过专门培训的员工。

很多人把 Skills 跟 MCP 混在一起，这是今年我看到的最大的认知误区。两者完全不是一回事。我给一个容易记得住的比喻：Skills 是给 Agent 的岗位说明书，MCP 是给 Agent 的电源插座。岗位说明书教它"遇到事情按流程办"，电源插座让它"能使用插上去的设备"。Skills 不产生连接能力，MCP 不产生业务知识，二者配合使用才有完整效果。

搞懂这个区别之后，你再去看网上那些资源就不会懵了。

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 接口"，插上什么设备就能用什么设备。比如插上数据库 MCP，AI 就能直接查数据；插上浏览器 MCP，AI 就能操控网页。

配置 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、Altium

MCP 生态里最有意思的不是那些通用工具，而是垂直领域的深度整合。这半年我看到了几个非常提效的项目。

安全研究和二进制分析场景里，IDA MCP 和 x32dbg 的 MCP 插件非常值得关注。IDA 是静态分析的主力工具，x32dbg 是动态调试的常用工具。社区做的 MCP 桥接项目可以让 AI 直接读取反汇编结果、设置断点、读取寄存器状态，甚至根据伪代码分析漏洞路径。实际用起来，AI 可以自动完成一部分"读代码、找可疑点、确认调用链"的重复劳动，分析人员只需要审阅 AI 的结论。不过这类工时工具要特别注意运行权限，实验室环境里玩没有问题，某些生产环境会限制调试器的自动操作，这个要提前跟安全策略对齐。

游戏开发这边，Unreal 5.8 MCP 是近期社区里比较热的话题。它把虚幻编辑器的常见操作封装成 MCP Server，AI 可以通过自然语言调用编辑器命令，比如批量创建关卡元素、调整材质参数、跑构建脚本。对独立游戏开发者来说，最直接的价值是省去大量 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。这很正常，信息过载时代的关键不是"知道所有工具"，而是"在需要的时候知道去哪找"。

我自己每隔两个月会把这类资源重新扫一遍，该扔的扔，该留的留，顺便检查一下哪些免费额度过期了、哪些社区项目停止维护了。这份清单你拿过去别照单全收，先从免费的开始试，觉得顺手再往深了折腾。

最后送一个小习惯：每接触一个新工具，先花十分钟看看它的配置文件长什么样，再看它的目录结构。配置文件能告诉你它怎么跟外部系统打交道，目录结构能告诉你它的设计哲学。看懂这两样，你就已经比一半的教程博主更懂这个工具了。