最近讨论 AI 工程化的时候，总绕不开四个词：提示词、Prompt、规则、Skill、MCP。很多同学会把它们当成同一件事去搜资料，结果越看越乱。有人以为“只要提示词写得好，其他概念都不需要”，也有人以为“MCP 是一种新模型”“Skill 是一个配置文件”。其实这些说法都不准确。
提示词管的是“这一次请求怎么问”，规则管的是“长期稳定的约束怎么沉淀”，Skill 管的是“一个完整任务流程怎么打包”，MCP 管的是“AI 怎么规范地调用外部工具和数据”。四者可以各自独立使用，也可以组成一条完整的工程链路。这篇文章会用最小可运行的部署环境，把四个概念从原理到配置全部演示一遍，重点是让你看完后能直接在自己的开发机上动手验证。
先说清楚边界：本文涉及本地模型部署、提示词模板、规则文件、Skill 结构和 MCP 配置，面向合法开发、自用测试和合规的生产场景。不要用这些能力处理未经授权的数据、人脸、声音或版权素材，也不要把本地服务随意暴露到公网。
1. 核心概念速览：提示词、规则、Skill、MCP 各管一段
先给一张速览表，把四个概念放在同一张图里看，边界会清楚很多：
| 概念 | 管理对象 | 生命周期 | 典型形态 | 改动成本 |
|---|---|---|---|---|
| 提示词 Prompt | 单次对话的输入指令 | 请求结束即失效 | 文本、模板字符串 | 低，改文本即可 |
| 规则 Rule | 系统/项目长期约束 | 跟随项目持续生效 | rules.md、AGENTS.md、系统提示词 | 中，改动后影响后续所有请求 |
| Skill | 可复用的完整任务流程 | 放在技能目录后持续可用 | SKILL.md、脚本、素材目录 | 中，需要组织目录结构 |
| MCP | 外部工具、数据源接入方式 | 由 MCP Server 决定，常驻运行 | MCP Server 配置、协议接口 | 较高，涉及进程与权限控制 |
如果用业务系统做类比，会更直观：Prompt 是调用函数时传的参数，Rule 是项目的配置文件，Skill 是标准作业程序 SOP，MCP 是服务之间的接口协议。参数决定一次调用怎么执行，配置决定整个系统默认行为，SOP 决定复杂任务怎么一步步完成，接口协议决定外部能力怎么接入。
这四个概念不是替代关系。先有 Prompt 把任务说清楚，再用 Rule 让每次任务都遵循同一套约束，接着用 Skill 把多步骤任务固化成能力包，最后用 MCP 让模型能读取文件、查数据库、操作外部服务。对于一个 AI 工程新手来说，理解这个分层，比收藏几百条“神奇提示词”更有价值。
2. 适用场景：从聊天助手到工程流水线
按使用阶段区分，这四个工具适合三种场景。
第一类是个人效率工具。你需要一个模型帮你写邮件、做总结、翻译文档。此时最主要的工作是设计模板提示词，可能再准备一个简单的规则文件，规定输出语言、格式和篇幅。启动门槛最低，本地或云端都能跑。
第二类是团队协作场景。项目里多人同时使用 AI，如果每个人都自己写提示词，很容易出现同一个需求在不同人那里得到完全不同的结果。这时候需要把 Rule 沉淀到项目里，写清楚代码风格、命名习惯、安全红线，让 AI 助手在每一次回答前都自动加载。
第三类是产品化场景。你要把 AI 能力接进自己的工具、App 或自动化流程，让模型具备读取业务数据、调用内部接口、批量处理任务的能力。这时只靠 Prompt 和 Rule 已经不够，需要引入 Skill 把复杂任务编排成固定流程，再用 MCP 打通模型与外部系统。
举个例子：假设你要做一个“自动生成周报”的功能。简单做法是每次把用户工作记录粘贴给模型问“请帮我生成周报”，复杂一点的工程做法是：用一个周报 Skill 声明整个任务流程，用 Rule 规定周报必须包含哪些模块，用 MCP 读取日历或项目管理系统里的任务列表，最后再由 Prompt 模型按指定格式输出。从效果上看，前一种方法经常需要复制粘贴和反复纠偏，后一种方法可以在接口层稳定复用。
这四个工具最大的价值，是把不可控的“聊天对话”变成可控的“软件工程链路”。
3. 环境准备与最小可运行部署方案
要实际跑通这些概念，只需要一台普通开发机，不需要很高配置的显卡。纯 CPU 环境也能跑小参数模型，只是速度会慢；如果本机有 NVIDIA 显卡，建议安装对应驱动与 CUDA，然后用nvidia-smi确认识别状态。
建议准备的工具：
| 项目 | 版本建议 | 用途 |
|---|---|---|
| Python | 3.10 及以上 | 读规则文件、调用模型 API、写演示脚本 |
| Node.js | 18 及以上 | 部分 MCP Server 需要npx启动 |
| Docker | 可选 | 需要部署完整 AI 应用平台时使用 |
| Ollama | 最新稳定版 | 本地拉起大语言模型推理服务 |
本文的演示主线采用 Ollama，因为它是目前最容易在本地跑通的开源模型推理工具。安装完成后先启动服务，在 Linux 或 macOS 上通常在后台常驻，Windows 上可以打开 Ollama 桌面端确认托盘图标。可用以下命令确认服务已经运行：
ollama list如果提示连接失败，可以先手动启动服务，再重新查看：
ollama serve拉取一个本地演示模型。Qwen2.5 系列是通用能力比较均衡的选择，7B 量化版本在普通开发机上可以跑：
ollama pull qwen2.5:7b拉取结束后，可以通过本地 API 验证服务是否正常：
curl http://127.0.0.1:11434/api/tags如果返回 JSON，里面包含模型列表，说明本地推理服务已经可用。这里需要注意：本文所有命令里的模型名、端口号都是示例，实际使用时要换成你本机拉取的模型名称和你自己的端口配置。
如果你希望把规则、Skill、MCP 这些能力做成可视化流程而不是纯写代码，还可以考虑使用 Dify 这类开源 LLM 应用平台。部署方式通常是在项目目录下执行 Docker Compose：
cd dify/docker cp .env.example .env docker compose up -d启动后访问配置的 Web 地址，按界面指引创建应用即可。不过为了把原理讲透，本文后续演示会先用代码方式完成，这样每个环节发生了什么都能直接看到。
4. Prompt 提示词工程：把一次请求变成可复用模板
Prompt 是所有环节的入口。先看一段最基础的提示词：
请帮我写一封请假邮件，说明我需要请假三天。这种写法能跑通，但不可控。模型可能帮你写成 800 字的叙事散文，也可能只回复两句话。工程上的做法是给提示词分层，让它结构明确、可以复用。
更合适的模板结构是：
# 角色 你是公司的行政助理 # 背景 我需要申请年假 # 任务 根据我的要求输出一封请假邮件 # 要求 1. 全文控制在150字以内 2. 语气礼貌、简洁 3. 不要编造具体日期 4. 直接输出邮件正文，不要解释 # 输入 日期：2026-03-20 天数：3 原因：家中有事先用这样的完整文本去调用本地模型，观察输出质量，然后再逐步把可变的输入项抽取出来，变成 Python 模板。下面这段脚本会把模板中的“输入部分”替换成动态传入的值：
import requests model_name = "qwen2.5:7b" template = """# 角色 你是公司的行政助理 # 背景 我需要申请{leave_type} # 任务 根据我的要求输出一封请假邮件 # 要求 1. 全文控制在{max_words}字以内 2. 语气礼貌、简洁 3. 不要编造具体日期 4. 直接输出邮件正文，不要解释 # 输入 日期：{date} 天数：{days} 原因：{reason} """ prompt = template.format( leave_type="年假", max_words=150, date="2026-03-20", days=3, reason="家中有事", ) response = requests.post( "http://127.0.0.1:11434/api/chat", json={ "model": model_name, "messages": [{"role": "user", "content": prompt}], "stream": False, }, timeout=120, ) print(response.json()["message"]["content"])在本地服务已经启动、模型已经拉取的情况下，运行这段脚本可以得到一段固定格式的请假邮件。如果模型返回内容频繁出现格式不齐，可以继续调整模板的“要求”部分，让它更具体。把 Prompt 做成模板的最大收益，不是省去复制粘贴，而是让程序可以批量生成不同入参的请求。
5. Rule 规则：把长期约束从对话里拆出来管理
模板提示词有一个明显问题：如果项目有一百条规则，总不能每次都在模板里写一百行。更合适的做法，是把长期固定的约束放到独立的规则文件里，由程序在发起请求前统一读取并注入。
创建一个 rules.md：
# 项目规则 1. 语言：所有回答默认使用简体中文。 2. 输出格式：需要分点时使用 Markdown 列表。 3. 代码：生成代码前先说明语言类型，关键步骤要注释。 4. 信息边界：没有提供的资料不得编造，不确定时明确说明“资料中未提供”。 5. 隐私：不要输出真实的手机号、身份证号、密钥；示例数据一律使用占位符。 6. 敏感内容：拒绝生成违反法律法规、侵犯他人权益的内容。然后在调用模型前，通过程序读取这个文件，把文件内容放入 System Prompt，让模型的每次请求都遵循同一套约束：
import requests from pathlib import Path model_name = "qwen2.5:7b" rules_content = Path("rules.md").read_text(encoding="utf-8") user_prompt = "请给这段代码写一个简短的使用说明：print('hello')" response = requests.post( "http://127.0.0.1:11434/api/chat", json={ "model": model_name, "messages": [ {"role": "system", "content": f"请严格遵守以下规则：\n{rules_content}"}, {"role": "user", "content": user_prompt}, ], "stream": False, }, timeout=120, ) print(response.json()["message"]["content"])这就是 Rule 的核心思想：把系统级约束放到模型对话之外，让所有请求共享一套配置。规则文件可以提交到 Git 仓库中，团队成员都能看到，也都能参与修改。
在工程实践中，一些 Agent 工具也定义了项目级约束文件的约定，例如 AGENTS.md、CLAUDE.md。它们本质上都是 Rule 的载体，只是读取规则的工具不同。具体使用哪个文件名、放在哪个目录，要以你当前工具的文档为准，但维护思路是相同的。
规则拆分时有一个经验：不是每一条说法都能成为规则，只有那些“无论用户怎么提问都必须遵守”的内容才值得放进去。比如“输出使用中文”“不确定不要硬编”这类，属于通用行为约束；而“请帮我写请假邮件”这种，属于具体任务，应该放在 Prompt 模板里，不要放进 Rule。
6. Skill 技能包：一个可装载的完整作业流程
Rule 解决了长期约束，但它仍然不擅长描述多步骤任务。例如我们想让模型扮演“周报整理助手”，这个任务包含多个阶段：理解工作日志、归类、生成摘要、按模板输出。如果把所有这些步骤都写进规则文件，规则会非常膨胀，而且一旦换任务，整个规则文件就不可复用。
Skill 要解决的就是这个问题。一个 Skill 通常是一个目录，里面包含一份任务说明文件、可能还有脚本、参考素材或示例输出。常见的结构如下：
skills/ weekly-report/ SKILL.md examples/ sample.md其中 SKILL.md 是核心文件，用来描述这个技能的触发条件、执行步骤和输出要求。下面是一份 SKILL.md 示例：
--- name: weekly-report description: 根据用户提供的一周工作记录，生成一份结构化周报。当用户输入包含“做周报”“整理周报”“本周总结”等意图时使用。 --- # Weekly Report Skill ## 任务目标 把零散的工作日志整理成可供提交的结构化周报。 ## 执行步骤 1. 先阅读用户提供的工作记录。 2. 按“项目进展 / 问题和风险 / 下周计划”三个模块分类。 3. 对每一条工作记录做一句话摘要，不要照抄原文。 4. 按输出模板生成最终周报。 ## 输出模板 # 本周工作周报 ## 项目进展 - ## 问题和风险 - ## 下周计划 - ## 注意事项 1. 没有提到的模块，不要强行编造内容。 2. 每条摘要控制在 40 字以内。 3. 不要输出与周报无关的建议。在支持 Agent Skills 的工具里，把这个目录放到对应的技能目录，模型就能通过用户输入自动匹配并调用。例如用户说“这是我的本周记录，帮我做一份周报”，agent 会从技能索引中匹配到 weekly-report，按 SKILL.md 里的步骤执行。
Skill 和普通 Prompt 文件的本质区别在于“可组合性”。比如你要开发一个代码审查工具，可以做一个code-reviewSkill，里面把代码质量问题、安全红线、格式规范都写成检查步骤。另一个项目需要类似能力时，直接复制这个 Skill 目录，而不是重写一段超长 Prompt。
Skill 的设计原则是：description 要写得清晰具体，因为它决定模型什么时候会触发这个技能；body 里的步骤要可执行，不能只写一句“生成周报”就结束；如果 Skill 依赖额外素材或脚本，要通过相对路径放到同一目录，保证目录可以整体迁移。
7. MCP 接入：给 AI 加一层标准工具接口
Rule 和 Skill 解决的是“让模型更听话、更专业”的问题，但模型本身有一个天然限制：它无法主动读取本地文件、查询数据库、调用你公司内部的 API。传统方案是在对话前手动把文件内容复制进 Prompt，这种做法不仅低效，而且不适合动态数据。
MCP 全称 Model Context Protocol，可以把模型与外部工具、数据源的连接标准化。这里要特别提醒：MCP 不是一种模型，也不是某个具体插件，它是一个应用层协议。理解成“USB-C 接口”更合适：MCP Server 相当于一个外部设备驱动，MCP Client 相当于设备管理器，模型只需要按协议描述工具、执行调用即可。
一个 MCP 系统由三部分组成：
- MCP Host：负责承载模型和用户对话的程序，例如支持 MCP 的客户端或开发框架。
- MCP Client：在 Host 内部，负责与 MCP Server 建立连接并转发工具调用。
- MCP Server：独立进程，提供文件读取、数据库查询、HTTP 请求等具体能力。
以一个常见的文件系统 MCP Server 为例，配置内容通常是这样的：
{ "mcpServers": { "filesystem": { "command": "npx", "args": [ "-y", "@modelcontextprotocol/server-filesystem", "/path/to/your/allowed-directory" ], "env": {} } } }配置里需要注意几点：command启动了一个外部进程，所以 Node.js 环境必须可用；args中最后的目录，一般应指向一个受控目录，而不是整个磁盘根目录；配置文件的具体存放位置和格式因客户端而异，要先查你所用工具的文档。
MCP Server 启动后，模型会看到一组可用的“工具”。比如文件系统 Server 会提供读取文件、列出目录、写入文件等能力。当用户问“帮我看看当前目录有哪些代码文件”时，模型会决定调用list_directory工具，拿到真实文件列表后再组织回答。这一步对比非常关键：没有 MCP 时，模型只能凭训练知识猜测；接入 MCP 后，模型拿到的答案是当前系统的真实状态。
在设计 AI 应用时，MCP 的引入原则是“最小权限”。能读单个目录就不要给根目录，能只读就不要给写权限，能查询指定数据表就不要给整个数据库连接串。
8. 真实部署与安装演示：提示词、规则、Skill、MCP 串联跑通
前面每一章都单独演示了一个概念，这一节把它们全串起来，构成一个最简单的端到端流程。
演示场景是：让 AI 读取某个目录下的工作日志文件，再结合规则和 Skill，生成一份周报。整体链路如下：
- Ollama 中已经运行一个本地模型。
- 程序读取 rules.md，得到全局约束。
- 程序读取每周报 Skill 的 SKILL.md，得到任务执行步骤。
- 支持 MCP 的客户端通过 MCP 文件读取工具，拿到工作日志目录里的文件内容。
- 程序把规则、Skill 和文件内容一起构造成消息。
- 调用模型 API，得到最终周报。
先准备一个工作日志文件：
2026-03-16：完成登录模块重构，修复 token 刷新问题。 2026-03-17：联调用户中心接口，处理了两个边界异常。 2026-03-18：写自动化测试用例，覆盖率从 71% 提升到 82%。再写一个调用脚本，把 rules.md 和 SKILL.md 都读入，并在用户消息中带上日志内容：
import requests from pathlib import Path model_name = "qwen2.5:7b" rules_content = Path("rules.md").read_text(encoding="utf-8") skill_content = Path("skills/weekly-report/SKILL.md").read_text(encoding="utf-8") work_log = Path("work-log.txt").read_text(encoding="utf-8") user_message = ( f"请根据以下工作日志生成周报：\n{work_log}\n" f"请按照 Skill 中的说明执行。" ) response = requests.post( "http://127.0.0.1:11434/api/chat", json={ "model": model_name, "messages": [ {"role": "system", "content": f"规则：{rules_content}"}, {"role": "user", "content": f"加载 Skill：{skill_content}"}, {"role": "user", "content": user_message}, ], "stream": False, }, timeout=180, ) print(response.json()["message"]["content"])这段脚本帮助你理解三个要素如何组合。真实的 MCP 调用不会在 Prompt 字符串里拼接工具内容，而是由 MCP Client 负责工具发现、调用和结果回填。比如你在支持 MCP 的对话工具中启动 filesystem server 后，同样能看到模型访问文件内容并获得结果。因此，本文示例里的本地 API 调用只用于演示链路，生产工程中建议使用成熟的支持 MCP 的开发框架，或直接在 Dify 这类平台里配置节点。
验证是否跑通的标准是：最终生成的周报明显由你的日志内容驱动，而不是模型自己编造的通用文案。如果模型输出大量“改进中”“待跟进”等空话，说明缺失了“不编造”相关 Rule，或者工作日志内容没有真正传进去，需要先检查文件路径、读取权限和消息结构。
整个部署演示的关键点在于：先把最小的链路跑通，再逐步增加复杂度。第一次运行可以先不接 MCP，只把一条手动输入的工作日志当作用户消息；第二次再读取真实文件；第三次再加入 MCP。如果第四步接不成功，问题通常集中在 MCP Server 启动失败、路径配置错误、工具权限不足，而不是模型本身出了问题。
9. 常见问题与排查方法
| 问题现象 | 可能原因 | 排查顺序 | 解决方案 | | --- | --- | --- | --- | | 本地模型服务连接失败 | Ollama 服务未启动或端口改变 | 执行 ollama list | 先运行 ollama serve，再确认端口 | | 模型返回内容乱编 | 规则中没有“不确定不编造”约束 | 检查 rules.md 是否被读取 | 在规则里补充信息边界 | | 输出格式不稳定 | Prompt 模板缺少模块和示例 | 检查模板要求部分 | 增加输出模板和禁止项 | | Skill 没有被触发 | SKILL.md 的 description 不清晰 | 查看工具日志 | 描述里加入触发关键词和任务说明 | | MCP Server 一直启动失败 | Node 环境异常或依赖缺失 | 手动执行 command 启动命令 | 在终端单独运行 npx 命令看报错 | | MCP 工具提示无权限 | Server 指向目录不正确 | 检查配置 args 中路径 | 将目录改为确有读取权限的路径 | | API 调用超时 | 模型体积大且无 GPU | 减少同时请求数和上下文 | 换更小参数模型或增加推理资源 | | 批量任务一直卡住 | 单条请求未设置超时 | 检查脚本是否卡在 HTTP 请求 | 为请求增加 timeout，增加日志输出 | | 端口被占用 | 前一个服务进程未退出 | 查看监听进程 | 手动结束旧进程或换端口启动 |排查时最重要的习惯是分开定位。先确认“本地模型服务是否能直接调用”，再确认“是否读到 rules.md 和 SKILL.md”，最后确认“MCP Server 是否成功启动”。如果整体流程失败，优先把这些环节拆开单独测试，不要在一个报错信息里反复试。
10. 最佳实践与合规使用建议
工程上建议从最小链路开始。第一次部署不要同时追求大量 Skill、完整 MCP、多个模型，先用一个小模型跑通一条单请求链路，再去扩展批量任务和复杂编排。这样出现问题，能清楚判断是模型问题、规则问题还是工具调用问题。
目录管理方面，建议把模型配置文件、规则文件、Skill 包、输入素材、输出结果分目录存放。尤其是 Skill 包，它必须是一个可以迁移的独立单元，理想情况下整个目录可以放进 Git 仓库由团队维护。建议在提交前清理掉里面可能存在的私密信息和本地绝对路径。
接口与服务安全要单独强调。本地模型推理服务默认建议绑定本机地址，不要直接在公网开放。MCP Server 配置目录时遵循最小权限；如果 MCP 需要读取数据库，尽量使用只读账号；如果是供测试用的环境，也不要写入真实生产数据。涉及他人信息的内容，必须先取得授权，涉及人脸、声音、版权素材的修改或生成场景，更要明确合规边界后再执行。
关于模型能力，需要提醒的是：不要把所有输出都直接当成事实。即使是本地部署的开源模型，也可能生成错误内容，批量使用时必须加人工复核环节。上线前可以准备一个由典型问题组成的验证集，把规则文件和 Skill 的变更纳入测试，避免改一个通用规则导致线上任务全部异常。
对于本地部署方案，不必一开始就追求大参数模型。先选择一个中小参数的量化模型，把提示词模板、规则文件、Skill 和 MCP 基础链路跑通，分析实际效果与耗时，再根据业务需要升级模型。这样既降低试错成本，也方便对比不同模型的真实输出差异。
11. 总结
回到最初的问题：提示词、规则、Skill、MCP 到底怎么用？用一句话总结就是：提示词解决单次请求质量，规则让系统保持稳定，Skill 把复杂任务固化为可复用流程，MCP 让模型拥有外部工具的调用能力。这篇文章给出的演示并不复杂，但已经覆盖一条真实工程链路中最重要的环节。如果你准备在自己的开发机上开始尝试，建议按顺序做三件事：先用 Ollama 拉起一个本地模型，用一组模板提示词跑通第一个请求；再针对你要长期执行的任务写一份 rules.md，通过程序自动注入；最后把重复次数最多的任务封装成一个 Skill，并用 MCP 接入一个只读工具做端到端验证。跑通后再决定要不要继续扩展更多模型和批量任务。
