企业官网建设流程全解析

把这么多年攒下的收藏夹整个翻出来，确实有点吓人。围绕 AI 编程、大模型、Skills、MCP 这四块，我手头试过的开发测试资源少说也有三四十个，有的是正经在项目里用过的，有的是装完踩了个大坑就扔在角落的。这次干脆整理成一篇文章，把亲测的优缺点、免费渠道、适用场景一次性说清楚。不吹不黑，也不堆参数，就讲这半年多实操下来最真实的那部分：哪些能白嫖，哪些值得付费，哪些装完就后悔，以及为什么这四个关键词其实是一条链路。

1. 先理清四个词：AI编程、大模型、Skills、MCP 到底在一条链路的哪个位置

1.1 一条流水线看明白：大模型是发动机，AI编程是变速箱

很多朋友一上来就到处找工具，结果越找越乱。我个人的理解是这样：大模型是发动机，负责最核心的智能推理；AI编程工具是变速箱，把发动机的动力传导到你的 IDE 和代码仓库里；而 Skills 和 MCP 是给发动机加装的两套外设——一套教它“怎么做”，一套给它“能干活的工具”。四者是层层嵌套的关系，分开用只有 60 分体验，串起来才能到 90 分。市面上那些看起来很厉害的工作流，本质上都是把这几层拼好了。

这也是为什么我建议你别一上来就疯狂搜集各领域工具，而是先看懂手里的大模型能干什么、缺什么。比如本地跑一个 7B 模型，再挂一个文件读取型的 MCP 服务器，配上几条带具体约束的提示词，完全能解决一类非常实际的重复性工作。

1.2 这份资源清单的设计思路：按用途而不是按热度归档

我这次整理的逻辑很简单：先按场景分块，再在每个块里按“免费 / 付费 / 开源替代”排列。这样你问“我要写代码用什么”“我要做私有化部署用什么”“我要给模型加个技能用什么”的时候，能快速定位，而不是在二十个标签里乱翻。

里面有很多资源是社区话题度很高的，比如 codex 这类付费 AI 编程软件、space bunny 这类新出的开源模型、superpowers 这类第三方 Skills 集合，还有 unreal 5.8 mcp、x32dbg 的 MCP 插件这种细分领域的开发测试资源。我把它们放在对应章节，附上我真实的试用结论。至于“免费渠道”，我只会写正经能用的官方途径，不碰那些灰色的路子。

2. AI编程工具实测：免费档与付费档之间的真实差距

2.1 免费档：零成本先转起来的三个选择

先讲免费的。我第一个推荐试的是通义灵码，阿里出的 IDE 插件，目前个人版免费。它支持 VSCode 和 JetBrains 全家桶，补全速度快，中文注释理解能力在国产工具里算第一梯队。我实测用它写过一段 Vue 3 组合式 API 的页面，上下文只要给了组件结构和接口定义，生成质量能直接拿来改，不用推翻重写。适合刚接触 AI 编程、预算为零的朋友。

第二个是 CodeGeeX，智谱旗下的免费编程助手。它的特色是对中文开发者的习惯做得多一些，尤其是代码解释和注释生成，适合文档工作偏多的场景。个人体感补全准确率比通义灵码略低一点，但胜在免费且没有太多限制。

第三个是开源命令行工具 Aider。它不是插件，而是直接在你的 Git 仓库里工作的 AI 编程助手，天然支持多文件改动、自动提交。免费、开源、可自定义脚本，是喜欢命令行的人会爱上的那一类。我第一次用的时候有点不习惯它“直接改代码并提交”的工作方式，但跑顺之后反而觉得比在 IDE 里盯补全更高效。

2.2 付费档：值不值钱要看你的使用强度

再说付费的。GitHub Copilot 是补全类工具的老牌选手，按月订阅，学生通过 GitHub Student Developer Pack 能免费试用。实测它的多语言补全确实稳，尤其是 Java、Python 这类主流语言，在大型代码库里的上下文理解做得比较细。缺点是如果项目高度依赖冷门框架，它也会露怯。

Cursor 则是另一种思路，直接把整个 IDE 做成 AI 原生，免费档每天有一定次数限制，付费档解锁更强模型和更长的上下文。我实测下来，它的优势在于“项目级上下文”：打开整个仓库，它能从全局回答“这个模块里谁调用了这个方法”，而不是只看当前文件。做重构、跨模块排查时，这个能力比单纯补全值钱得多。

还有个绕不开的名字是 Codex，OpenAI 出的智能体式编程工具。它跟普通补全不一样，是把任务拆成“思考—改代码—跑测试”的循环，能自主完成一整块功能开发。付费门槛不低，而且用起来很吃提示词水平。我的建议很直白：如果你的日常工作里 80% 是复制粘贴老代码加小修小改，Copilot 那一档就够；如果你经常要按一个简短描述生成一整个模块，再让工具自己迭代测试，那 Codex 这类 agent 模式才值得掏钱。

2.3 一个被低估的分水岭：提示词写法

同样一个工具，在不同人手里效果差距巨大，分水岭就是提示词。AI 编程提示词不是越详细越好，而是要把“项目背景、技术栈、约束、验收标准”讲清楚。我常用的精简模板是这样的：

【项目背景】这是一个基于 Vue 3 + TypeScript 的电商后台管理模块 【本次任务】实现订单列表的分页筛选功能，支持状态过滤和按时间排序 【约束条件】不引入额外 UI 库，沿用现有 Element Plus 风格；接口地址从 env 读取 【验收标准】列表加载有 loading 态，筛选参数变化时自动重置页码

这样写，工具能明确知道你要什么、不要什么。很多朋友说“生成的一坨完全不能用”，其实问题往往不在模型而在需求描述太过模糊。

3. 大模型资源盘点：开源选型、免费API与本地部署

3.1 开源模型先看参数再看场景

大模型这块，我踩过的坑比吃过的盐还多。一开始盲目追大，拉了个 70B 模型回来，结果显存直接爆掉。后来学乖了：先定场景，再定参数规模。做代码生成和结构化输出，Qwen 系列表现很稳，从 0.5B 到 72B 都有，中文能力扎实；DeepSeek 的推理类模型在数学和逻辑题上相当出彩，且开源协议比较友好；Llama 系列胜在生态大，周边工具和量化方案最全；Mistral 的 MoE 架构在显存效率上有优势，适合有限硬件跑大参数量；还有像 space bunny 这类新出的轻量模型，主打低成本部署，我最近专门跑过一次，应对基础问答和文本分类完全够用。

我整理了一张选型参考表，方便你按自己的显卡做初步判断。这里给的是量化模型在消费级显卡上的常见配置，实操时需结合上下文长度和并发数微调：

3.2 免费API渠道：我实测过的入口与额度

免费 API 是水很深的话题，因为额度变化特别快。我把自己实测过、仍然还活着的渠道列一下，但你用之前务必去官网确认最新政策，别拿着我截图里的老额度去对线。

阿里云百炼平台给新用户提供免费额度，Qwen 系列模型能在上面直接调 API，对应的是国内可用的标准 OpenAI 风格接口，改一下 base_url 和 key 就能接入很多开源客户端。硅基流动这一类聚合平台也送注册额度，上面集合了 Qwen、Llama、GLM 等一大票开源模型，一个 key 测多家模型，做模型对比评测非常方便。DeepSeek 开放平台同样可以申请 API，我早期大规模实测时用的是它的接口，响应速度快，文档也全。智谱开放平台则有免费的体验额度，GLM 系列适合中文场景。还有个不算 API 但很实用的免费路线：直接用 Ollama 在本地起模型，拉下来之后本地调本地接口，一分钱不花，模型随便换。

我把常用 API 平台的接入要点整理成了一张记忆卡：

3.3 本地部署实录：从Ollama到vLLM

本地部署我认为是所有想要“数据不出内网”的人绕不开的一关。个人和中小团队直接用 Ollama 效率最高。它的命令设计非常傻瓜化：装好之后拉模型、起服务、调接口，基本就是几行命令的事。先看系统有没有 Ollama：

ollama run qwen2.5:7b

这条命令会自动拉取模型并进入交互模式。如果要走 API 方式，先确保服务在跑：

ollama serve

然后就能用标准 HTTP 请求访问本地模型。这样一套流程走下来，相当于你拥有了一个完全免费的本地大模型 API 服务。

等团队到了要通过高并发接口对外提供服务时，再考虑 vLLM。vLLM 的优势是推理吞吐量高，支持 PagedAttention 等一系列优化，部署起来比 Ollama 复杂，但生产稳定性强得多。我的建议是：开发调试、个人实验用 Ollama，生产化、多人共用再上 vLLM，别一上来就上重武器。

3.4 微调与私有化的“入门绿灯”

大模型微调这件事听起来高深，实际上现在的工具链已经把门槛压得很低了。我入门用的是 LoRA 微调，核心思路是不动原模型的全部参数，只训练一小部分低秩矩阵，普通消费级显卡也能跑。用 Hugging Face 的 PEFT 库加几张条理清晰的数据集，就能把模型往你需要的表达风格上掰。步骤大致是：准备对话数据（提问+回答成对出现），套用对话模板格式化成文本，用脚本训练，最后合并权重。

我踩过最大的坑是数据格式不一致：一半数据是 JSON，一半是 Markdown，训练时预处理报错反复折腾。后来我统一为对话模板再加校验脚本，一次就过了。企业私有化部署也是一个道理，别一上来就要搞大集群，先用一个小模型在目标业务数据上做微调和评测，验证效果之后再把规模放大，这样成本可控，心理压力也小很多。

4. Skills机制拆解：官方市场、第三方仓库与自写规范

4.1 Skills与提示词的区别在哪

Skills 是这一两年被聊得很多的机制。很多人问它跟提示词有什么区别，我用一句话解释：提示词是你每次都要重新叮嘱模型的话，Skills 是把这种叮嘱固化成一个可复用的“标准作业流程说明书”。

举个例子，你想让模型每次生成的前端代码都符合你团队的组件规范。如果靠提示词，你得每次复制一大段规范进去；如果做成一个前端开发 Skills，模型每次用到这个能力时，会自动读取 skill 里写的规范、示例代码和检查清单，然后按这套流程做事。换句话说，Skills 把“经验”从人脑里搬到模型的工作台上，而且可以随仓库一起分发。GitHub 上有一堆现成的 skills 集合，比如 superpowers 就是把各种工作流封装成技能包，nature skills 也经常被社区推荐，直接在 GitHub 搜 skills 目录能看到大量积累。

4.2 好用Skills清单与获取方式

我用的 Skills 主要有几个来源：Claude 官方市场是第一个要看的，里面技能分类比较正规，适合先建立正确认知；GitHub 上是最大最杂的宝库，搜关键字加 stars 排序，能找到前端开发、论文写作、代码审查等各类现成技能包，比如 codex 写论文的 skills、github skills 这类仓库。我的习惯是下载回来先打开 SKILL.md 看里面的约束和输出格式是否跟自己的需求匹配。另外社区里还有人做 skills 推荐列表，按“效率工具”“代码生成”“数据清洗”等维度归档，省去不少翻仓库的时间。

有一点要提醒：不是所有 skill 都能直接被你的客户端识别，有些项目对 skill 存放目录或配置文件格式有要求，装之前一定要看 README，别一股脑丢进目录就当完事了。我最初就栽过这个跟头，下了十来个 skill，真正能直接被识别的不到一半。

4.3 自写Skills：模板、规范与血泪坑

自己写一个 skill 没那么高深，核心就是一个 SKILL.md 文件。它通常带 YAML frontmatter，在最上面写 name 和 description，下面用 Markdown 写清楚工作流程、注意事项、输出模板和参考示例。以“SQL 查询审查”技能为例，关键文件大致长这样：

--- name: sql_review description: 审查 SQL 查询，找出性能隐患并给出优化建议 --- # SQL 查询审查 ## 审查步骤 1. 检查是否包含 SELECT *，如存在则标记为待优化 2. 检查 WHERE 条件是否命中索引字段 3. 检查子查询是否可以改写为 JOIN ## 输出格式 按"风险等级 + 问题位置 + 优化建议"逐条输出，最后给出整体评分。

写完之后把整个文件夹放到模型客户端的 skills 目录里。我实测中最常见的三个问题：第一，description 写得太泛，导致模型不知道该在什么时候调用；第二，正文里全是抽象原则，没有具体输入输出示例，模型执行起来容易放飞；第三，直接拿别人的 skill 改个名字就用，里面的命令路径和上下文全是别人的，跑起来大概率翻车。建议新写的 skill 先拿一个最小测试用例跑通，再逐步加复杂度。

5. MCP开发测试资源：理解协议、挑选服务器与调试技巧

5.1 用一次“文件操作”理解MCP

MCP 是 Model Context Protocol 的缩写，中文常叫模型上下文协议。我见过最贴切的类比是把它理解成“大模型世界的 USB 接口”——以前你想让模型读文件、查数据库、操作浏览器，得给每个工具单独写适配代码，现在只要工具实现了 MCP 标准，模型就能通过统一的方式去调用。

以文件操作场景为例：配置一个 filesystem 类型的 MCP 服务器后，模型可以直接按你的描述读取指定目录的文件列表、读写某个文件的指定段落，全程不需要你在聊天框里粘贴文件内容。这是 MCP 最有价值的地方：让模型从“只动嘴”变成“能动手”。而测试人员的关注点是：每个 MCP 服务器到底暴露了哪些工具、工具参数怎么填、返回值是什么结构，这些都是可以直接用工具查到的。

5.2 我实测过的MCP服务器清单

官方维护的 MCP servers 仓库是目前最可靠的起点。用过的几个给大家参考：filesystem 管文件读写，git 管仓库状态检查和提交操作，sqlite 让模型直接查数据库，github 能在对话里操作 issue 和 PR，playwright 类服务器则让模型能驱动浏览器做自动化操作。拿 github 的 MCP 服务器来说，配置好之后让模型“看一下仓库里最近的 PR 标题”，它真的会去调接口然后汇总给你，这个体验远不是“把内容复制进聊天框”能比的。

行业细分方向的 MCP 资源这两年也冒出来一大批，我挑能验证的说几个：游戏和三维场景方向，unreal 5.8 MCP 可以辅助操作虚幻引擎资产；逆向分析方向，有 IDA MCP 以及 x32dbg 的 MCP 插件，能在调试器里跟 AI 对话；硬件设计方向，Altium Designer 的 AI 接口 MCP 开始流行起来。国内开发框架也在跟上，比如 ruoyi-vue-pro 这类后台管理脚手架已经把 MCP 功能合并进来。桌面客户端里，Cherry Studio 支持 MCP 配置，还能用 MCP 工具流式输出内容到文件，做记录归档很顺手。

配置 MCP 服务器通常是在客户端的配置文件里加一段 JSON，声明服务器名称、启动命令和参数。下面是一个本地启动 filesystem 服务的 JSON 片段，可照此扩展：

{ "mcpServers": { "local-fs": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/data"] } } }

5.3 调试MCP的必备工具与原生问题

调试 MCP 服务器，官方有个 MCP Inspector 可以直接用起来。它是一个可视化界面，能枚举服务器暴露了哪些工具、查看每个工具的参数 schema、手动发起调用看返回值。我几乎每次新接入一个服务器都会先用它做冒烟测试，确认工具的输入输出符合预期，再进入正式流程，省掉很多在客户端里反复试错的时间。

实测中常见的 MCP 问题集中在几类：一是命令找不到，也就是 PATH 环境变量没把 npx 或 node 的路径暴露给服务进程，这种情况把服务器启动命令改成绝对路径最省事；二是 stdio 超时，通常是因为服务器启动太慢，先手动在终端把启动命令跑一遍能快速定位；三是工具描述太长太多，模型在调用时反而不知道选哪个，建议只显式暴露当前场景需要的工具，把无关的注释或过滤掉。MCP 的坑大多不在协议本身，而在环境与配置细节，带着这几个常见问题去排查，通常能省下大半天。

6. 压箱底经验的三大坑：版本、资源与配置

6.1 版本地狱：依赖锁定比什么都重要

AI 圈的版本迭代速度快到离谱，今天装好的配置，下周可能就因为某个依赖升级而崩掉。我现在的习惯是给每个项目单独做一套依赖快照，尤其是 MCP 服务器和 Skills 这类通过 npx 或 git 拉取的工具。没有锁版本之前，我曾经遇到过一个前端开发 skill 一夜之间变了执行方式，第二天整个工作流直接失效，排查了半天才发现是上游仓库改了目录结构。所以我的建议很朴素：把关键依赖的版本号写进 README 或配置注释里，不要用“最新版”这种随缘策略。

6.2 资源管理与并发测试的现场教训

本地部署大模型时，最实际的问题是显存、内存和并发之间的平衡。同样是 7B 模型，4bit 量化和 8bit 量化对显存的占用差一截，响应速度也不一样。并发测试时尤其要留意：你以为模型能扛住 50 个并发请求，实际一压测才发现 token 生成速度跟不上，表现为响应排队越来越久、甚至直接超时。我的做法是先低并发跑一遍看延迟曲线，再逐步加压，把最大并发数控制在一个“延迟不爆炸”的区间内。这个现场教训来自于一次做内部效率工具时，上线第一天被几十个同事同时访问，模型服务直接卡死的尴尬经历。

6.3 按项目做环境快照：我现在最依赖的习惯

最后分享一个我自己长期在用的习惯：每玩一个新工具，不直接改全局环境，而是先按项目做一份独立配置目录。AI编程客户端的配置文件、模型拉取脚本、MCP 服务器注册信息、Skills 存放位置，全部收进项目的 .ai/ 目录里，用文档记录当时的版本和踩坑备注。这样换机器、关项目、回滚实验都极其干净，不会出现“这台电脑上能跑，换个地方就废了”的情况。

这个习惯来自数次惨痛教训。最初我把所有 skill 和 MCP 配置堆在全局目录，结果某次清理时误删了一堆有用的配置，花了一个下午才恢复。现在每套实验环境都自带一份“说明书”，哪怕半年不碰的项目，再打开也很快能进入状态。如果你也打算认真玩转 AI 编程和模型生态，我强烈建议从第一天就建立这种按项目隔离的配置管理方式。