企业官网建设流程全解析

这次我们来看一个技术概念辨析的实战场景：如何用一份周报讲清 skill、plugin 和 mcp 的区别。这三个词在 AI 开发、工具集成和自动化领域频繁出现，但它们的定位、实现方式和应用边界常常让人混淆。对于开发者、产品经理或技术决策者而言，理清这三者的区别，是设计可扩展系统、选择技术栈和评估第三方工具的关键。

本文的核心目标是：通过一份具体的“周报生成”需求，将抽象概念转化为可操作的对比分析。我们将围绕一个共同的任务——自动生成周报，分别用 skill、plugin 和 mcp 三种方式来实现，从而直观地展示它们的设计哲学、集成成本、能力边界和适用场景。读完本文，你将能清晰地判断：你的项目应该用 skill、plugin 还是 mcp？各自的部署门槛、开发成本和长期维护代价如何？

1. 核心能力速览：Skill vs Plugin vs MCP

在深入周报案例前，我们先通过一个速览表，从顶层视角把握三者的核心差异。这有助于你在后续的详细对比中快速定位关键信息。

简单来说：

• Skill是AI的“手”，告诉AI“去做什么事”。
• Plugin是软件的“瑞士军刀”，给特定软件增加新功能。
• MCP是AI的“万能插座”，为AI安全地连接任何外部工具和数据源提供了标准接口。

接下来，我们将这个对比落到一个具体的“周报生成”任务上。

2. 场景定义：一份周报的生成需求

假设我们是一名开发工程师，每周需要汇总以下信息形成周报：

1. 代码提交记录：从Git仓库（如GitLab）提取本周的commit列表。
2. 任务完成情况：从项目管理工具（如Jira）提取本周已关闭的任务。
3. 本周总结与下周计划：基于以上信息，生成一段连贯的文本总结。

我们的目标是自动化这个过程。我们将分别探讨如何用Skill、Plugin和MCP的思路来实现它。

3. 方案一：使用 Skill 实现周报生成

Skill模式的核心是任务封装。我们期望对AI说一句“帮我生成这周的周报”，它就能自动完成所有步骤。

3.1 设计与实现思路

1. 技能定义：创建一个名为generate_weekly_report的Skill。
2. 输入/输出：
   • 输入：可选参数，如date_range（默认为本周）、user_id。
   • 输出：一份结构化的Markdown格式周报。
3. 执行逻辑：该Skill内部需要按顺序执行以下子任务：
   • 调用GitLab API获取commit记录。
   • 调用Jira API获取已完成的任务。
   • 将获取的数据进行整理和格式化。
   • 调用文本生成模型（如GPT）撰写总结文本。
   • 组合所有部分，生成最终周报。

3.2 伪代码示例

# 伪代码：一个Skill的框架示例 class GenerateWeeklyReportSkill: name = "generate_weekly_report" description = "自动生成开发者周报，汇总Git提交和Jira任务。" async def execute(self, inputs: Dict) -> Dict: # 1. 获取Git提交 git_commits = await self._fetch_git_commits(inputs.get('date_range')) # 2. 获取Jira任务 jira_tasks = await self._fetch_jira_tasks(inputs.get('date_range')) # 3. 整理数据 report_data = self._organize_data(git_commits, jira_tasks) # 4. 生成总结文本（调用AI） summary = await self._call_llm_for_summary(report_data) # 5. 组装最终报告 final_report = self._format_report(report_data, summary) return {"report": final_report} # ... 具体的方法实现 _fetch_git_commits, _fetch_jira_tasks 等

3.3 部署与调用方式

• 部署：将该Skill代码部署到支持Skill运行的AI Agent平台（如LangChain的Agent、GPTs的Actions等）。需要在该平台上注册此Skill。
• 调用：用户通过自然语言向AI Agent发出指令，例如：“@Agent， 请使用generate_weekly_report技能帮我生成周报。” Agent会解析指令，加载并执行对应的Skill。

3.4 优缺点分析

• 优点：
  • 用户体验极佳：一句话触发复杂流程，完全自动化。
  • 高度封装：对使用者隐藏了所有技术细节。
• 缺点：
  • 平台锁定：这个Skill严重依赖特定的AI Agent平台。脱离该平台，它无法独立运行或被其他系统调用。
  • 灵活性差：如果我想单独获取Git提交记录而不生成完整周报，这个Skill无法满足。它被设计为完成一个固定的“大”任务。
  • 维护复杂：所有逻辑（Git、Jira、AI调用）都耦合在一个Skill里，任何一部分（如Jira API变更）出错，整个Skill失效。

小结：Skill适合构建面向最终用户的、开箱即用的自动化智能体应用，但牺牲了灵活性和可复用性。

4. 方案二：使用 Plugin 实现周报生成

Plugin模式的核心是功能扩展。我们假设在一个已有的“开发者仪表盘”Web应用中，增加一个周报生成功能。

4.1 设计与实现思路

1. 宿主程序：一个已有的开发者仪表盘（使用React + Node.js构建）。
2. 插件目标：在仪表盘上新增一个“周报生成”标签页，包含一个按钮，点击后生成并展示周报。
3. 实现内容：
   • 前端插件：编写新的React组件，用于展示周报表单和结果。
   • 后端插件：编写新的API路由（如POST /api/plugin/weekly-report/generate），该接口的实现逻辑与Skill类似（调用Git、Jira、AI）。
   • 集成：将前端组件注册到仪表盘的路由/菜单中，将后端API注册到主服务器。

4.2 伪代码示例

// 前端插件组件 (React) function WeeklyReportPlugin() { const generateReport = async () => { const response = await fetch('/api/plugin/weekly-report/generate', { method: 'POST', body: JSON.stringify({ dateRange: 'this-week' }) }); const data = await response.json(); setReport(data.report); }; return ( <div> <button onClick={generateReport}>生成周报</button> <MarkdownViewer content={report} /> </div> ); } // 需要将 WeeklyReportPlugin 注册到主应用的插件系统中

// 后端插件API (Node.js/Express) app.post('/api/plugin/weekly-report/generate', async (req, res) => { // 1. 获取Git提交 (依赖主应用可能提供的Git服务客户端) const gitCommits = await gitServiceClient.getCommits(req.body.dateRange); // 2. 获取Jira任务 (依赖主应用配置的Jira客户端) const jiraTasks = await jiraClient.getClosedTasks(req.body.dateRange); // 3. 调用AI服务 (依赖主应用集成的LLM服务) const summary = await llmService.generateSummary({gitCommits, jiraTasks}); // 4. 格式化返回 const report = formatReport(gitCommits, jiraTasks, summary); res.json({ report }); });

4.3 部署与调用方式

• 部署：将插件代码与主应用程序代码一起构建、部署。通常需要修改主应用的构建配置和路由配置来“激活”这个插件。
• 调用：用户登录开发者仪表盘，在界面上找到新增的“周报生成”标签页，点击按钮触发。

4.4 优缺点分析

• 优点：
  • 深度集成：UI/UX与主应用完全一致，用户体验无缝。
  • 可利用宿主能力：插件可以直接使用主应用已经封装好的服务（如统一的认证、HTTP客户端、数据库连接池）。
• 缺点：
  • 强耦合：插件与宿主应用生死与共。宿主应用框架升级、API变更都可能导致插件失效。
  • 无法独立存在：这个周报功能无法脱离这个特定的开发者仪表盘运行。
  • 技术栈锁定：必须使用宿主应用指定的技术栈（如特定的JS框架、Python版本等）进行开发。

小结：Plugin适合为某个特定的、复杂的软件系统增加垂直功能，追求深度集成和一致体验，但同样存在严重的平台锁定问题。

5. 方案三：使用 MCP 实现周报生成

MCP模式的核心是协议化工具暴露。它不直接构建最终应用，而是为AI模型提供获取周报所需“材料”的标准工具。

5.1 设计与实现思路

1. 角色转变：我们不再是构建一个“周报生成器”，而是构建一个数据和服务提供方。
2. 定义工具(Tools)：我们实现一个MCP服务器，对外提供两个核心工具：
   • get_git_commits: 根据时间范围返回Git提交记录。
   • get_jira_tasks: 根据时间范围返回Jira任务列表。 （注：撰写总结文本的能力，由调用方——AI模型自身——提供。）
3. 协议通信：MCP服务器通过标准协议（基于JSON-RPC或SSE）与MCP客户端（如Claude Desktop）通信，宣告自己有哪些工具可用。

5.2 伪代码示例 (MCP 服务器端)

# 伪代码：一个简易的MCP服务器示例 (使用官方SDK简化) from mcp.server import Server, NotificationOptions from mcp.server.models import TextContent import asyncio server = Server("weekly-report-data-server") # 1. 声明工具 @server.list_tools() async def handle_list_tools(): return [ { "name": "get_git_commits", "description": "获取指定时间范围内的Git提交记录。", "inputSchema": { "type": "object", "properties": { "date_range": {"type": "string", "description": "时间范围，如 'last-week', '2024-01-01:2024-01-07'"} } } }, { "name": "get_jira_tasks", "description": "获取指定时间范围内已关闭的Jira任务。", "inputSchema": {...} # 类似上面 } ] # 2. 实现工具 @server.call_tool() async def handle_call_tool(name: str, arguments: dict): if name == "get_git_commits": date_range = arguments.get("date_range", "this-week") commits = await fetch_git_commits_from_api(date_range) # 你的实际逻辑 return [TextContent(type="text", text=format_commits(commits))] elif name == "get_jira_tasks": # ... 类似实现 pass async def main(): async with server.run_stdio() as (read_stream, write_stream): await server._run(read_stream, write_stream, NotificationOptions()) if __name__ == "__main__": asyncio.run(main())

5.3 部署与调用方式

• 部署：将上述MCP服务器作为一个独立的进程运行。它可以通过stdio、HTTP或SSE与客户端连接。
• 配置：在MCP客户端（如Claude Desktop）的配置文件中，添加这个MCP服务器的路径或地址。

  // Claude Desktop 的 mcp_config.json 示例 { "mcpServers": { "weekly-report-data": { "command": "python", "args": ["/path/to/your/mcp_server.py"] } } }

• 调用：用户在与AI（如Claude）对话时，AI模型会“看到”可用的工具。用户可以说：“请帮我生成周报，需要汇总我本周的代码提交和工作任务。” AI会自主决定调用get_git_commits和get_jira_tasks这两个工具来获取数据，然后利用自身的文本生成能力撰写周报。

5.4 优缺点分析

• 优点：
  • 解耦与复用：MCP服务器独立于任何AI前端。今天给Claude用，明天可以给Cursor、Codeium或其他任何支持MCP的AI工具用。
  • AI自主规划：将“如何完成任务”的规划权交给AI。AI可以灵活组合工具，例如只获取Git数据，或先获取Jira任务再获取Git记录。
  • 安全与可控：MCP服务器运行在本地或受控环境，数据不出域。暴露的工具是精确定义的，避免了AI直接访问原始数据库或API的风险。
• 缺点：
  • 不提供最终产品：它只提供“砖瓦”，不提供“房子”。最终用户需要一个支持MCP的AI客户端才能享受到自动化便利。
  • 依赖AI能力：生成周报的文本质量依赖于所连接的AI模型的能力。
  • 概念较新：生态和工具链仍在快速发展中，可能会遇到兼容性或调试上的挑战。

小结：MCP是一种面向未来的、更架构化的思路。它专注于提供标准化、可复用的“能力接口”，将复杂任务的编排和决策交给更通用的AI智能体，实现了工具提供方与工具使用方的解耦。

6. 对比总结与选型指南

让我们回到“周报生成”这个任务，横向对比三种方案：

选型建议：

• 选择 Skill：如果你在构建一个具体的AI智能体应用（如客服机器人、个人助理），希望提供“一句话办事”的魔法体验，且不介意绑定在某个AI平台上。
• 选择 Plugin：如果你需要深度增强某个现有软件的功能，追求无缝的用户体验，并且该软件提供了稳定完善的插件生态。
• 选择 MCP：如果你拥有需要被AI访问的核心数据或服务（如内部API、数据库、知识库），并希望这些能力能一次开发，永久复用于未来各种AI工具和场景中，追求架构的开放性和可持续性。

7. 进阶思考：混合模式与未来趋势

在实际项目中，边界并非泾渭分明，混合模式正在涌现：

1. MCP as Skill/Plugin的底层：一个强大的AI Agent平台（Skill运行环境）或IDE（Plugin宿主），其内部可以通过集成MCP客户端来动态接入海量外部工具，从而使其自身的Skill或Plugin能力得到极大扩展。
2. Skill调用MCP工具：一个Skill的内部实现，可以不直接写死调用Git/Jira的代码，而是去调用对应的MCP服务器提供的标准化工具。这样，这个Skill就与具体的数据源解耦了，变得更轻量、更易维护。
3. Plugin集成MCP客户端：像Cursor、Windsurf这类新一代AI IDE，它们本身以Plugin形式存在，但内部深度集成了MCP客户端，让用户能方便地配置和使用各种MCP服务器。

未来趋势是向协议化和解耦发展。MCP所代表的思路——通过开放协议为AI提供标准化工具接口——正在成为行业共识。这降低了AI应用开发的门槛，让开发者可以更专注于构建有价值的工具和服务，而不必担心它们会被绑定在某个特定的AI模型或前端界面上。

8. 实践第一步：从MCP服务器开始体验

如果你对MCP感兴趣，建议从构建一个最简单的MCP服务器开始。以下是快速体验步骤：

1. 环境准备：确保安装Python 3.10+。
2. 安装SDK：使用官方或社区的MCP SDK可以简化开发。

   pip install mcp

3. 编写第一个服务器：参考上文伪代码，实现一个最简单的服务器，比如提供一个get_time工具返回当前时间。
4. 配置Claude Desktop：下载Claude Desktop，在其配置目录下创建或修改mcp_config.json，添加你的服务器配置。
5. 重启并对话：重启Claude Desktop，新建对话，尝试问：“现在几点了？” 观察Claude是否会调用你的get_time工具。

通过这个“Hello World”级别的实践，你可以最直观地理解MCP的工作模式：你提供工具，AI使用工具。

9. 总结

回到最初的问题：如何用一份周报讲清skill、plugin和mcp的区别？答案就是为同一个目标（生成周报）设计三种不同架构的实现方案。

• Skill告诉你：“交给我，你一句话就行。” 它代表了一种产品化、场景化的封装思路。
• Plugin告诉你：“来我们软件里，新增了一个按钮。” 它代表了一种生态化、集成化的扩展思路。
• MCP告诉你：“这是我提供的标准数据接口，任何AI都可以安全地来取。” 它代表了一种协议化、基础设施化的开放思路。

理解这些区别，能帮助你在技术选型时做出更明智的决策：你是要做一个用完即走的“魔法”，一个深度集成的“功能”，还是一个长期受益的“能力基座”？希望这份特别的“周报”，能为你未来的项目架构提供清晰的蓝图。