最近讨论 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 是标准作业程序 SOPMCP 是服务之间的接口协议。参数决定一次调用怎么执行配置决定整个系统默认行为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确认识别状态。建议准备的工具项目版本建议用途Python3.10 及以上读规则文件、调用模型 API、写演示脚本Node.js18 及以上部分 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 Composecd 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_words150, date2026-03-20, days3, reason家中有事, ) response requests.post( http://127.0.0.1:11434/api/chat, json{ model: model_name, messages: [{role: user, content: prompt}], stream: False, }, timeout120, ) 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(encodingutf-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, }, timeout120, ) 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(encodingutf-8) skill_content Path(skills/weekly-report/SKILL.md).read_text(encodingutf-8) work_log Path(work-log.txt).read_text(encodingutf-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, }, timeout180, ) 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 接入一个只读工具做端到端验证。跑通后再决定要不要继续扩展更多模型和批量任务。 提示词、规则、Skill与MCP详解：构建AI工程化协作链路
最近讨论 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 是标准作业程序 SOPMCP 是服务之间的接口协议。参数决定一次调用怎么执行配置决定整个系统默认行为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确认识别状态。建议准备的工具项目版本建议用途Python3.10 及以上读规则文件、调用模型 API、写演示脚本Node.js18 及以上部分 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 Composecd 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_words150, date2026-03-20, days3, reason家中有事, ) response requests.post( http://127.0.0.1:11434/api/chat, json{ model: model_name, messages: [{role: user, content: prompt}], stream: False, }, timeout120, ) 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(encodingutf-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, }, timeout120, ) 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(encodingutf-8) skill_content Path(skills/weekly-report/SKILL.md).read_text(encodingutf-8) work_log Path(work-log.txt).read_text(encodingutf-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, }, timeout180, ) 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 接入一个只读工具做端到端验证。跑通后再决定要不要继续扩展更多模型和批量任务。