企业官网建设流程全解析

1. 这堆资源到底解决什么问题

先把话说在前头，这篇不是那种“收藏了就等于学会了”的资源清单。我在过去大半年里，把 AI 编程、大模型本地部署、Skills 机制、MCP 协议这几条线的东西几乎翻了个底朝天，踩过的坑包括但不限于：装了一半发现显卡带不动、API 免费额度第二天就没了、Skills 写完了 Agent 根本读不到、MCP 服务连上了但工具列表是空的。所以这篇的核心目的很直接——把我在开发测试环节真正留下来、反复在用的 30 多个资源，按“它是什么、解决什么问题、优缺点、免费渠道在哪”四个维度摊开讲清楚。

如果你现在处于这几种状态，这篇对你会比较有用：想入门 AI 编程但不知道从哪个工具下手；本地想跑大模型但被显存和环境劝退；听说过 Skills 和 MCP 但一直没搞明白它们到底在 Agent 体系里扮演什么角色；或者你已经在用某个工具，但总觉得差点意思，想看看有没有更顺手的替代方案。我会尽量把每个东西的“为什么选它”讲透，而不是只丢一个链接。

需要提前说明的是，下面提到的所有工具和平台，我都会基于公开可获取的信息和我自己的实际使用体验来描述，涉及付费的部分我会明确标出来，免费渠道也会说清楚限制条件。资源类内容有时效性，具体额度、价格、版本以你实际打开时为准，这点先打个预防针。

2. AI 编程工具：从补全到 Agent 的完整光谱

2.1 为什么 AI 编程工具要分三档来看

很多人一上来就问“哪个 AI 编程软件最好”，这个问题本身就问错了。AI 编程工具现在至少分三个档位，解决的问题完全不同。第一档是代码补全型，代表是各类 IDE 插件，它在你敲代码的时候预测下一行，适合写重复性高的业务代码；第二档是对话式编程助手，你贴一段代码或者描述一个需求，它给你完整函数甚至整个文件，适合解决具体问题；第三档是Agent 型编程工具，它能自己读项目、改多个文件、跑测试、根据报错自我修正，代表就是 Codex 这类。

分档的意义在于：你如果只是想让写 CRUD 快一点，用第一档就够了，没必要上 Agent，因为 Agent 的配置成本和 token 消耗都高得多。反过来，如果你要重构一个几十个文件的老项目，补全型工具基本帮不上忙，必须上 Agent。我自己现在的组合是：日常写业务用补全型，遇到不熟的库用对话型，做重构和批量修改用 Agent 型。

2.2 Codex 这类 Agent 编程工具的真实体验

Codex 是我目前用得最多的 Agent 编程工具之一。它的工作方式是：你给它一个任务描述，它会自己去读项目结构、定位相关文件、生成修改方案、执行修改，然后跑测试验证。实测下来，它在有明确测试用例的项目里表现最好，因为测试给了它一个明确的成功信号，它能根据测试失败信息自我修正。

但它的缺点也很明显。第一，token 消耗大，一个中等复杂度的重构任务，来回几轮下来消耗的额度不小，如果你用的是按量付费的 API，成本要提前算。第二，对项目结构混乱的代码库效果打折，如果项目里没有清晰的模块划分，它容易改错地方。第三，Skills 配置是门槛，Codex 的 Skills 机制需要你理解它的目录结构和触发条件，配不好它根本不会调用你写的 Skill。

关于 Codex 的 Skills，我的经验是：Skill 的描述文件比实现代码更重要。因为 Agent 是靠描述来判断“什么时候该用这个 Skill”的，如果你的描述写得含糊，它要么不用，要么乱用。我一般会在描述里写清楚三件事：这个 Skill 解决什么具体问题、什么情况下应该触发、输入输出分别是什么格式。

2.3 免费 AI 编程资源的获取渠道与限制

免费渠道这块，我踩过的坑最多。常见的免费来源有几类：一是各家大模型厂商的新用户赠送额度，通常有有效期，注册后要尽快用；二是开源模型的本地部署，这个是真免费，但吃硬件；三是社区维护的免费 API 聚合，这类稳定性参差不齐，不建议用在正式项目上。

我个人的建议是：学习和测试用免费额度，正式项目用付费 API。因为免费额度随时可能调整，你把生产流程建在上面，某天额度没了整个流程就断了。本地部署开源模型是个折中方案，适合对数据隐私要求高、且愿意投入硬件成本的场景。至于那些来路不明的免费 API，我一般只用来做非敏感的格式转换测试，绝不传业务数据。

3. 大模型：本地部署与云端调用的取舍

3.1 本地部署大模型的硬件门槛到底在哪

本地部署大模型，核心瓶颈是显存。模型参数量和显存需求的关系，粗略估算的话，FP16 精度下每 10 亿参数大约需要 2GB 显存，也就是说一个 70 亿参数的模型，FP16 需要约 14GB 显存。如果显存不够，就要用量化，比如 4-bit 量化能把需求降到约四分之一，但代价是精度损失，具体损失多少要看模型和任务。

我用 Ollama 部署过几个不同规模的模型，实测下来：7B 级别的模型，4-bit 量化后 8GB 显存的卡能跑，速度可以接受；13B 级别建议 12GB 以上显存；再往上，消费级显卡就比较吃力了。这里有个容易被忽略的点：显存不是唯一瓶颈，内存和硬盘速度也会影响加载时间。我第一次部署时，模型文件放在机械硬盘上，加载等了快两分钟，换到固态硬盘后降到十几秒。

3.2 云端大模型 API 的选型逻辑

云端 API 的选型，我主要看四个维度：上下文长度、价格、响应速度、稳定性。上下文长度决定了你一次能喂多少内容进去，做长文档分析、大代码库理解的时候这个是硬指标。价格方面，不同厂商差距很大，而且经常调整，建议直接看官网的定价页。响应速度上，流式输出体验比一次性返回好很多，尤其是长回答的时候。

这里要提一个实际使用中的技巧：不要把所有任务都丢给最强的模型。比如格式转换、简单分类这种任务，用便宜的小模型就够了，把强模型留给需要推理的复杂任务。我自己的做法是维护一个任务到模型的映射表，简单任务走便宜模型，复杂任务走强模型，成本能降不少。

3.3 大模型微调：什么时候该做，什么时候不该做

微调这个话题被讨论得很多，但我的观点是：大部分场景不需要微调。微调适合的是那种“模型能力够，但输出格式或风格总是不对”的场景。如果你发现模型是“根本不会做这个任务”，那微调也救不了，应该考虑换更强的模型或者用 RAG 补充知识。

微调的实际门槛比想象中高。首先是数据准备，你需要几百到几千条高质量的标注数据，这个成本往往被低估。其次是训练资源，全量微调需要大量显存，一般用 LoRA 这类参数高效微调方法，能在消费级硬件上跑，但效果和全量微调有差距。最后是评估，微调完怎么判断变好了还是变差了，需要一套评估集，这个也得提前准备。

我的建议是：先用提示词工程和 RAG 试，实在不行再考虑微调。微调是最后手段，不是第一选择。

4. Skills 机制：Agent 的能力扩展单元

4.1 Skills 到底是什么，为什么需要它

Skills 这个概念，简单说就是给 Agent 预定义的一套可复用能力单元。你可以把它理解成 Agent 的“技能包”：Agent 本身有通用的推理和工具调用能力，但具体到某个领域的具体操作，比如“按公司规范生成代码注释”“用特定格式解析某类日志”，这些就需要通过 Skill 来定义。

为什么需要 Skills？因为 Agent 的通用能力再强，也不可能知道你项目里的所有约定。比如你们团队的代码规范、日志格式、部署流程，这些是私有知识，Agent 不知道。Skills 就是把这些私有知识封装成 Agent 能理解和调用的形式。没有 Skills 的 Agent，每次都要你在提示词里重复说明这些约定，效率低还容易漏。

4.2 写一个能被 Agent 正确调用的 Skill

写 Skill 的关键，前面提过，是描述文件。我总结了一个描述文件的模板，包含四个部分：触发条件、输入说明、输出说明、边界情况。触发条件写清楚“什么情况下用这个 Skill”，输入说明写清楚“需要提供什么参数”，输出说明写清楚“返回什么格式”，边界情况写清楚“什么情况下不要用”。

实现部分反而相对简单，因为 Agent 调用 Skill 的时候，主要是靠描述来判断，实现只要逻辑正确就行。但有个坑要注意：Skill 的实现要尽量无副作用。因为 Agent 可能会在你不预期的时候调用它，如果 Skill 有副作用（比如修改文件、发送请求），可能会造成意外。我一般会把有副作用的操作拆成独立的 Skill，并且在描述里明确标注。

4.3 Skills 的测试与调试方法

Skills 写完不是就完事了，必须测试。我的测试方法是：构造一批触发场景和非触发场景，看 Agent 是否在正确的场景调用 Skill，在错误的场景不调用。这个测试集要覆盖边界情况，比如“描述里提到了关键词但实际不需要用 Skill”的场景。

调试的时候，如果发现 Agent 不调用 Skill，先检查描述文件是不是太含糊；如果发现 Agent 乱调用，检查触发条件是不是写得太宽泛。还有一个常见问题是Skill 之间的冲突，两个 Skill 的触发条件有重叠，Agent 不知道该用哪个。解决办法是在描述里明确区分，或者合并成一个 Skill。

5. MCP 协议：工具与模型的标准化接口

5.1 MCP 解决的核心问题

MCP 要解决的问题是：让模型和外部工具的连接标准化。在没有 MCP 之前，每个模型要接一个工具，都得单独写适配代码，工具多了就是 N×M 的适配工作量。MCP 定义了一套标准协议，工具方按协议实现一次，模型方按协议接入一次，就能互通。

这个思路和 USB 接口类似：以前每个设备有自己的接口，现在统一成 USB，谁都能插。MCP 的价值在于降低了工具接入的成本，让模型能调用的工具生态能快速扩大。我实测下来，支持 MCP 的工具接入确实比自定义适配快很多，尤其是那些已经有 MCP 实现的常用工具。

5.2 常见 MCP 工具的实际接入体验

我接入过的 MCP 工具里，比较典型的有几类：文件系统类，让模型能读写本地文件；数据库类，让模型能查询数据库；浏览器类，让模型能操作浏览器；专业软件类，比如设计软件、调试工具的 MCP 接口。

接入体验上，文件系统和数据库类最成熟，基本是开箱即用。浏览器类次之，配置稍复杂但文档齐全。专业软件类差异最大，有的做得很完善，有的还在早期阶段，功能有限。我遇到的最常见问题是授权配置，很多 MCP 工具需要配置访问凭证，配置错了就连不上，而且报错信息往往不明确，需要看日志排查。

5.3 MCP 接入失败的排查思路

MCP 接入失败，我总结了一个排查顺序：先确认服务是否启动，再确认配置是否正确，最后确认权限是否足够。服务没启动是最常见的，尤其是本地 MCP 服务，忘了启动或者启动失败但没注意。配置错误次之，主要是路径、端口、凭证这几项。权限问题最少见但也最难排查，因为报错往往不直接指向权限。

还有一个容易被忽略的点：MCP 服务的版本和客户端的版本要匹配。我有一次接入失败，排查了半天，最后发现是 MCP 服务版本太老，不支持客户端用的新协议特性。所以接入前先确认版本兼容性，能省很多时间。

6. 开发测试资源的组合使用与避坑

6.1 一套可复用的开发测试工作流

把上面这些串起来，我目前的工作流是这样的：用 Agent 编程工具做主要开发，用本地大模型做敏感数据的处理，用 Skills 封装项目规范，用 MCP 连接外部工具。这个组合的好处是各司其职：Agent 负责代码生成和修改，本地模型负责隐私敏感任务，Skills 保证输出符合规范，MCP 扩展能力边界。

具体到一次开发任务：我先用 Agent 工具生成初版代码，然后用 Skills 里定义的规范检查一遍，需要查数据库或调外部服务的时候走 MCP，涉及敏感数据的部分切到本地模型处理。这套流程跑下来，效率比纯手工高不少，但前提是每个环节都配置到位。

6.2 资源选型的常见误区

选型误区我见过几个典型的。误区一：追求最新最强的工具。新工具往往不稳定，文档不全，踩坑成本高。我的建议是选成熟度够、社区活跃的工具，新工具可以关注但不要急着上生产。误区二：什么都想本地部署。本地部署适合隐私敏感和离线场景，但维护成本高，不是所有场景都值得。误区三：忽视成本核算。API 调用、Agent 的 token 消耗、本地部署的硬件成本，这些都要算进去，不然用着用着发现成本超预期。

6.3 免费资源的合理使用边界

免费资源能用，但要有边界意识。我的原则是：免费资源用于学习和验证，不用于生产。学习阶段用免费额度试各种工具，找到合适的再考虑付费。验证阶段用免费资源做原型，验证可行后再迁移到付费方案。生产环境用免费资源，风险在于额度随时可能变、稳定性没保障、出问题没人负责。

还有一个实际建议：把免费资源的依赖隔离在独立模块里。比如你用某个免费 API 做格式转换，就把它封装成一个独立函数，将来要换实现只改这一个地方。这样即使免费资源没了，迁移成本也可控。

7. 常见问题速查与实操心得

7.1 高频问题速查表

7.2 我踩过的几个典型坑

第一个坑是Skills 描述写得太宽泛。我一开始写 Skill 描述，写的是“用于处理代码相关任务”，结果 Agent 什么代码任务都往里塞，包括不该用的场景。后来改成“用于按公司规范生成 Python 函数的文档字符串”，触发就准确多了。

第二个坑是MCP 凭证配置错误但报错不明确。我配一个数据库 MCP，凭证填错了，报错只说“连接失败”，没说是凭证问题。排查了半天才发现。后来我养成了习惯：配置 MCP 先单独测试连接，确认通了再接入 Agent。

第三个坑是本地模型量化过度。为了在低显存卡上跑，我用了很激进的量化，结果模型输出质量明显下降，经常答非所问。后来换了个稍大的显存卡，用量化程度低一些的版本，质量就正常了。量化程度和质量的平衡，需要根据具体任务试。

7.3 给不同阶段读者的建议

如果你是刚入门，建议从对话式编程助手开始，先熟悉 AI 辅助编程的感觉，再逐步接触 Agent 和 Skills。如果你是有一定基础，建议重点研究 Skills 和 MCP，这两个是当前 Agent 体系里最能拉开效率差距的部分。如果你是在做团队方案，建议先小范围试点，把工作流跑通再推广，同时做好成本核算和资源隔离。

最后分享一个我自己的习惯：每用一个新工具，先花十分钟看它的官方文档和 issue 区。文档告诉你它设计上能做什么，issue 区告诉你它实际上的坑在哪。这十分钟往往能省下后面几个小时的排查时间。资源再多，用不起来也是白搭，找到适合自己当前阶段的那几个，用透，比收藏一堆强。