提示词、规则、Skill、MCP 四个词经常同时出现在 AI 工程化的讨论中但它们解决的并不是同一个问题。提示词是一次对话里的即时指令规则是跟随项目长期生效的约束文件Skill 是按需加载的操作手册MCP 则是让模型连接外部工具的标准化插口。很多人在尝试 Claude Code、Cursor、Codex 这类 AI 编程工具时搞不清四者的边界导致写了很多提示词却无法沉淀装了 Skill 却只是在重复规则文件配了 MCP 却不知道什么时候该用它。这篇文章的目标是先把四者的定位讲清楚再分别给出可操作的最小示例最后演示一次“真实的安装与部署链路”并补充排查清单。整条链路按“概念 - 环境 - 示例 - 验证 - 排错”组织适合刚接触 AI 编程工具的开发者也适合要做工程规范的技术负责人。1. 先分清四个概念它们解决的是不同层次的问题在开始安装任何东西之前先要建立一个判断框架。提示词、规则、Skill、MCP 不是同一个事物的四种叫法而是 AI 工程里的四层不同能力。混淆它们会导致一种典型现象觉得“只要规则写得更详细AI 就能学会调用外部系统”或者“Skill 文件里加了工具说明为什么工具还是不能真正执行”。这两类期望分别属于不同层次。1.1 提示词一次对话里的即时指令提示词是用户发给模型的自然语言指令它只在当前会话或单次请求内生效。你可以把它理解为“给一名临时员工的现场交代”你说明背景、任务和输出要求但下一次换一个工位、换一个项目后这名员工不会自动记住上一份交代。在企业实践中提示词通常被拆成几个部件角色设定、背景信息、任务目标、输入数据、约束条件、输出格式、验收口径。部件之间未必每次都要齐全但缺了任何一个模型都可能用自己的默认假设去补全生成结果就会飘。很多人遇到“AI 写出来的代码风格和项目不一致”本质不是模型能力不足而是提示词里没有把项目上下文传递过去。1.2 规则随项目一起生效的长期约定规则文件解决的是“让 AI 每次都带着项目规范工作”的问题。它的常见载体是项目根目录下的文本文件例如 CLAUDE.md、AGENTS.md 或者工具约定的项目配置目录。会话启动时客户端自动读取相关文件并注入上下文模型不需要用户每次重复“我们这个项目用 Java 17、接口返回统一用 Result 包装”。一个容易被忽略的点是规则文件不是普通帮助文档它会被如实注入上下文并参与生成决策。因此项目里写什么、不写什么非常重要。它适合放技术栈、目录结构、提交规范、接口约定、禁用模式等不变信息不建议放与本次任务强相关的临时分析结论。规则文件写得太长也会占用上下文窗口导致真正处理代码时的可分配上下文变小。1.3 Skill按需加载的可复用“操作手册”Skill 在概念上比规则更接近“能力包”或“操作手册”。规则描述的是项目的“常态”而 Skill 描述的是“当某个任务出现时应该按照什么流程处理”。Skill 通常表现为一个包含说明文件与配套资源的目录代表文件一般叫 SKILL.md里面以固定格式声明技能名称、描述、适用条件和执行步骤目录里还可以附带参考文档、模板、脚本和示例。Skill 与提示词最大的差异在于“可以被检索和按需触发”。模型不是每次启动都把所有技能读进上下文而是在任务描述匹配技能描述时才把对应技能包加载进来。这样既节省上下文又能把一次性的优秀经验固化成新的能力单元。在 AI 编程工具里Skill 既可以由官方渠道分发也可以由团队自行编写并提交到项目仓库后者是团队知识沉淀最容易落地的方式。1.4 MCP让 AI 接入外部系统的标准插口MCPModel Context Protocol解决的问题与前三层完全不同。提示词、规则、Skill 都在回答“模型应该如何思考”而 MCP 回答的是“模型如何操作真实系统”。MCP 是一套开放协议约定了 AI 应用和外部工具服务之间的通信方式。接入 MCP 后对话客户端可以调用 MCP Server 暴露的能力比如读取文件、执行 SQL、搜索代码仓库、操作 Git甚至调用公司内部 API。可以把 MCP Server 看作一个“能力适配层”它把外部系统的复杂 API 包装成模型可理解、可调用的工具列表。模型通过协议拿到工具的说明、参数结构然后在合适的时机发起调用而不是在提示词里靠文字描述“假装调用”。这也是 MCP 与 Skill 最明显的分界线Skill 给模型方法MCP 给模型双手。1.5 四者不是替代关系而是分工关系理解四者关系最简单的方式是看它们各自承担的工作可以先用一张表固定下整体分工。层次持续作用范围常见载体加载时机典型作用提示词本次会话或单次请求对话文本、API 参数每次请求发出时定义本次任务的上下文、边界和输出要求规则项目级或用户级CLAUDE.md、AGENTS.md、项目配置会话启动时自动加载让 AI 持续遵守项目规范和技术约定Skill技能包目录或项目发布物SKILL.md、附带脚本与文档任务与技能描述匹配时按需加载给 AI 提供可复用的“标准作业流程”MCP客户端配置的本地或远程服务MCP Server、协议配置文件客户端启动并发现工具时让 AI 获得真实读写与调用能力四者的使用顺序也常被人搞反。正确认知是先用提示词把当前任务表达清楚用规则守住项目级边界用 Skill 处理高频重复的专业流程最后才在确有必要时通过 MCP 接通外部系统。反过来如果一上来就接十个 MCP Server却没有项目规则约束生成方向AI 的行为很快就会失控。2. 环境准备先想清楚在哪套 AI 工具里做实验四者的落地方式与具体 AI 编程工具强相关。同样一份提示词在命令行工具、IDE 插件、桌面客户端里的生效方式不一样规则文件在有的工具里叫 CLAUDE.md在另一些工具里被识别为 AGENTS.mdSkill 的目录约定也会随版本演进。动手前先确认运行环境能省掉后面大量“为什么没生效”的排查时间。2.1 不同产品里四者的搭载位置并不完全一样以常见的 AI 编程工具为例规则和技能通常有各自的加载位置。当前比较主流的产品会理解项目根目录下的 AGENTS.md部分产品同时兼容 CLAUDE.md、.cursorrules 等历史文件名Skill 则可能放在用户目录、项目目录或者通过命令导入MCP 可以通过图形界面配置也可以写 JSON 配置文件。这里不要追求“一套配置通吃所有工具”。更稳妥的做法是先确认你当前使用版本支持的加载目录和文件名再选择一种主工具做最小实验。判断依据有三个工具自己的帮助命令如 /help、官方文档中的“rules”和“mcp”页面、以及启动日志中实际读取了哪些文件。如果你在多个工具之间复制规则文件至少先做一次“改名后是否仍然生效”的验证因为工具之间对文件名大小写和目录层级的要求不统一。2.2 最小实验环境的检查清单本文演示的链路偏向“命令行可复现”的工程环境大致需要以下条件项目检查方式说明Node.js 运行环境node -vMCP 客户端常通过 npx 拉起本地 Server建议安装当前 LTS 版本npm 与 npxnpm -vnpx --versionnpx 会临时下载 MCP Server 依赖缺了它配置会直接失败终端与路径环境echo $PATH从图形界面启动客户端时PATH 可能与终端不一致这是 MCP 启动失败的常见原因实验目录mkdir -p ~/ai-tool-demo所有文件、规则、日志统一放在一个目录方便验证和清理版本确认工具菜单里的 About/版本号不同版本对 Skill 目录名、MCP 配置项的支持不同排错时先记录版本如果后面要编写自己的 MCP Server还需要 Python 3.10 或与 SDK 匹配的 Node 环境但这个不是前置硬性要求。建议先跑通“文件系统类 MCP Server”它最容易观察结果也最容易排查问题。3. 提示词先跑通一次可验证的任务再谈工程化提示词看起来门槛最低却是四层里最容易“看起来会、实际不会”的部分。真正可复用的提示词不是几行聊天话术而是一份可重复执行的任务说明。只有先掌握提示词的结构化写法才能理解规则和 Skill 中“该放什么、不该放什么”。3.1 一段可直接使用的结构化工单式提示词假设现在要分析一段后端服务日志。可以这样组织提示词你现在是一名 Java 后端性能排查工程师。 背景 下面是 user-service 最近 5 分钟内的错误日志片段字段包括时间、IP、 调用方法、错误码、耗时与详情。 log [2026-05-01T10:01:22.000Z] ERROR 10.0.0.5 UserService#getOrder timeout3002 detailFeignTimeout [2026-05-01T10:01:25.000Z] ERROR 10.0.0.7 UserService#getOrder timeout1805 detailFeignTimeout [2026-05-01T10:01:31.000Z] ERROR 10.0.0.6 PaymentService#callback timeout4500 detailReadTimeout /log 任务 1. 列出出现次数最多的异常类型。 2. 对每种异常给出 3 个可能根因并引用日志字段作为证据。 3. 对每条根因给出下一步排查命令或观察指标。 约束 - 只能分析 log 中存在的字段不要编造日志里没有的信息。 - 当证据不足以判断某条根因时明确标注“证据不足”。 - 不要给修复代码本次只需要定位方向。 输出格式 第一部分三列表格列为“异常类型|出现次数|最可能根因”。 第二部分三句话以内的自然语言解释。 第三部分按优先级给出的下一步命令列表。这段提示词的关键点在于它把任务分解成了背景、输入、任务、约束、输出格式五段。模型在回答时不需要猜测“用户到底想要结果还是要解释”所以输出结构稳定便于人做验收。真实项目里只需要把log替换成动态输入即可反复使用。3.2 提示词里最容易忽略的是约束与验收标准很多人写提示词只写“帮我分析这段日志”或“给我写个登录接口”这样的写法默认把判断权全部交给了模型。模型会按训练数据里的通用偏好生成结果而你的项目可能并不需要那种格式。改进方向可以对照下面的表格常见写法问题推荐补上的要素“帮我写个接口”不知道技术栈、不清楚入参出参要求给语言版本、框架约定、入参结构、返回结构“分析一下报错”不知道要诊断还是要修复明确产出物是定位报告还是代码补丁“注意代码风格”没有可执行规范给出项目风格文件或具体的命名约束“不要乱改”范围不明确明确哪些文件可以改、哪些禁止动判断一段提示词是否合格可以拿三个问题来检查如果把这段提示词交给另一个人对方是否知道要处理什么输入、按什么原则处理、输出成什么格式。如果三件事里有任何一件不清楚模型同样会糊涂。3.3 提示词的验证方法是看“是否还需要你追问”一段生效良好的提示词通常不需要用户连续追问补条件。测试方法是对同一段提示词跑三组不同输入观察结果结构是否一致、是否出现编造字段、是否遵守了禁止项。如果发现模型反复忽略某个约束不要只在原文后面加“一定要遵守”而要检查这段约束是不是放在输入段之前、是否足够具体。比如“不要编造日志里没有的信息”就比“保证准确”有效因为它给出了可执行的判断方式。提示词层级的失败大多是表达问题而不是“模型不听话”问题。4. 规则文件把项目约束沉淀下来而不是每次都复制提示词提示词解决了单次任务但同一个项目里的几十次对话如果都靠手写上下文很快会失控。规则文件的意义在于把项目内的“稳定事实”固化下来让每一次会话自动携带这些事实。4.1 规则文件要放在哪里命名和加载范围怎么选当前主流工具的规则文件基本遵循两种模式项目级规则和用户级全局规则。项目级规则放在代码仓库内通常位于项目根目录名称为 AGENTS.md 或 CLAUDE.md用户级全局规则放在工具约定用户目录内作用范围覆盖所有项目。在不确定当前工具使用哪个文件名时先在项目根目录建立一个 AGENTS.md再启动会话问一句“你当前加载的项目规则有哪些”。如果工具没有自动读取去官方文档确认它是否支持 AGENTS.md或者是否仍在使用 CLAUDE.md 等旧文件名。不要一次性创建三个同名文件规则重复会占用上下文并且可能出现冲突。4.2 一份最小可用的项目规则文件长什么样下面是一个面向 Java Web 项目的规则文件示例核心是“只放需要模型长期遵守的内容”# user-service 项目协作约定 ## 技术栈 - Java 17 - Spring Boot 3.x - MyBatis-Plus - MySQL 8.x ## 接口规范 - 所有对外接口统一返回 ApiResponseT。 - 新增接口必须提供 OpenAPI 注释字段必须有业务含义说明。 - 接口方法内禁止直接 catch 所有异常后返回 null。 - 分页参数统一为 pageNo 和 pageSize禁止使用 page 和 size 混用。 ## 数据访问 - 所有 SQL 必须写明确字段不得使用 select *。 - 修改类 SQL 必须带条件禁止不带 where 的 update 和 delete。 - 事务方法不允许在类内部通过 this 调用避免代理失效。 ## 日志与排查 - 错误日志必须携带 traceId、方法名和关键参数。 - 日志格式固定为时间|级别|traceId|调用方|消息。 ## 代码提交 - 提交信息格式type(scope): subject。 - 不要一次提交多个无关联需求。 - 禁止把本地配置、密钥文件提交进仓库。这份文件的每一条都可以被直接执行。“禁止不带 where 的 update 和 delete”就比“注意数据安全”对模型更有约束力。反过来也不需要写“请遵守项目规范”这样的空句子它没有提供任何新信息。4.3 规则文件里不建议放什么规则文件不适合放三类内容临时分析结论、敏感信息、大段示例代码。临时分析结论会导致旧结论在后续会话中持续干扰新判断敏感信息如果放在规则文件里会被完整注入上下文一旦仓库泄露就会连带泄露大段示例代码会占用大量上下文而模型本身已经具备较好的代码生成能力规则只需要给出约束方向。写规则文件的更合适姿态是“让 AI 帮团队守住默认值”而不是“把项目代码复制给 AI 看”。默认值包括语言版本、包结构、错误处理方式、日志格式、提交规范。这些内容变化频率低又对生成质量影响大是最适合放进文件的。4.4 如何验证规则真的生效规则文件的生效验证不能只靠“模型说知道了”。可以做一个定向测试在规则文件里写一条明确约定例如“接口返回统一使用 ApiResponse”然后让 AI 生成一个新增用户接口检查返回类型是否符合约定。如果模型忽略了这条约定再去检查文件名、所在目录、工具版本是否选对。另一种验证方式是让 AI 概括当前项目规则“请列出你在本次会话中自动加载的项目规则并指出来源文件。”如果回答与规则文件完全对不上说明加载链路出问题如果只是概括不全可能是上下文裁剪导致部分内容未生效这时候应该精简文件而不是继续堆内容。5. Skill从临时提示词升级成可复用的“技能包”当一段提示词在多个项目里反复使用而且步骤固定、产出物固定时就有理由把它封装成一个 Skill。Skill 的威力在于它把“经验”变成了可以分发、版本管理、按需加载的软件制品而不是躺在聊天记录里的一段话。5.1 Skill 包的目录结构一个 Skill 通常是一个目录目录名就是技能名称内部至少包含一个 SKILL.md核心信息全部写在这个文件里。复杂技能还会附带 prompt 模板、脚本、参考文档和校验规则。以“接口测试计划生成”技能为例结构大致是test-plan-skill/ ├── SKILL.md ├── scripts/ │ └── make_mock.py ├── templates/ │ └── test_case.md └── references/ └── assertion-guidelines.mdSKILL.md 负责告诉模型“何时触发这个技能、按什么步骤执行、输出什么”templates 提供稳定的输出骨架references 提供执行时需要参考的业务规则scripts 则可以让模型在执行过程中调用外部程序生成数据或做校验。需要说明的是并非每个工具都允许技能包内脚本被自动执行落地前要看技能运行环境的能力边界。5.2 SKILL.md 的核心结构SKILL.md 一般由两部分组成头部声明区和正文执行区。下面的示例用于说明结构实际字段名应以所用工具当前支持的规范为准--- name: interface-test-plan-demo description: 当用户需要设计接口测试计划、生成接口测试用例或梳理接口异常分支时使用。输入接口文档或 YAML 描述输出可执行测试用例。 --- # 接口测试计划技能 ## 适用场景 - 新增接口需要设计冒烟测试用例时。 - 需要把接口文档转换成接口测试需求时。 ## 执行步骤 1. 读取接口说明找出路径、方法、请求参数和响应结构。 2. 按正常路径、边界值、业务异常、系统异常四组用例设计输入。 3. 每组用例标注前置条件、请求样例、预期状态码和断言字段。 4. 将用例输出为 Markdown 表格。 ## 输出格式 - 前置条件 - 测试数据说明 - 用例表格列名固定为“编号|用例名称|请求方法|路径|输入|预期结果”description 字段非常重要它是模型判断“是否应该加载该技能”的依据。description 写得太宽泛模型会在不合适的任务里加载技能写得太窄模型又可能错过该触发它的场景。比较好的写法是包含触发词、输入条件和解决目标例如“当用户需要……时使用”的句式。5.3 安装 Skill 的几种典型方式Skill 的安装路径因产品而异大体上可以分成三类本地目录放置把技能目录放入工具约定的用户技能目录或项目技能目录随项目一起提交例如放在团队仓库的 skills 子目录中。命令导入部分 AI 工具支持从 Git 仓库地址或压缩包导入技能导入命令的具体名称以当前版本help输出为准。市场安装从官方或第三方技能市场搜索后一键安装适合已验证的公开技能。如果工具没有现成的导入命令就不要强求特殊能力。把 Skill 目录放在约定位置、确保文件结构正确然后进入下一轮验证即可。对于团队内部项目把 Skill 随仓库提交通常比依赖个人安装更稳定因为新成员 clone 后即可获得同样能力。5.4 Skill 与规则、提示词如何区分区分三者有没有一条更简单的判断标准可以按“作用范围”和“触发方式”来问内容在每一个会话里都必须存在选规则。内容只在某个高频行业流程里需要且步骤完整、输出固定选 Skill。内容只针对当前这个具体任务、用完不保留直接写提示词。同一个知识内容三种形态都能表达区别在于成本。规则是常驻内存放得越多上下文浪费越多Skill 是按需加载只在匹配时占资源提示词是临时构造每次都需要用户重新组织。一个项目里应当是“少而精的规则 适量技能 按需提示词”的结构而不是把所有约束全部堆进规则文件。6. MCP把外部工具接入客户端做一次完整安装演示前四章讲的是模型内部的知识组织现在进入真正的“接线”环节。MCP 演示最容易出现“配置写了但连不上”的问题因此本节会按“配置文件 - 启动验证 - 结果检查”的顺序完整走一遍。6.1 MCP 的连接模型MCP 采用客户端-服务端模型。一侧是嵌入在 AI 应用中的 MCP Client另一侧是提供能力的 MCP Server。Server 通过协议暴露三类能力工具Tools、资源Resources和提示模板Prompts其中工具是最常用的一类模型可以在推理过程中发起工具调用。通信层面MCP Server 通常以两种方式运行本机子进程方式客户端通过标准输入输出来启动并通信这种叫 stdio 模式远程服务方式客户端通过 HTTP 或 SSE 连接一个独立服务适合部署在公司服务器上供多人使用。本地实验优先用 stdio因为它更容易观察启动日志和排查环境变量问题。6.2 一段用于演示的 MCP 配置文件多数支持 MCP 的客户端会读取一个 JSON 格式的配置最外层是 mcpServers。下面这段配置先做说明用命令中的具体包名和路径要以你要安装的服务器的官方文档为准{ mcpServers: { demo-filesystem: { command: npx, args: [ -y, modelcontextprotocol/server-filesystem, /Users/yourname/ai-tool-demo ], env: {} } } }解释一下这几个字段mcpServers 下有多个服务器每个服务器的 key 是唯一名称command 是启动命令通常指定 npx 或 uv 等工具客户端负责拉起进程args 是传给命令的参数数组其中-y表示下载依赖时跳过确认env 用于传入环境变量必要时可以把密钥从这里注入。配置中出现最多的错误有三种。第一种是路径写错导致 Server 启动后没有权限访问目标目录第二种是 args 里把目录参数漏写Server 起来后不知道自己该管理哪个目录第三种是 Windows 环境下直接使用 npx 失败此时可能需要把 command 写成cmd、args 首项写成/c npx。这些内容在客户端日志里通常会有明确提示。6.3 安装启动前要做的环境确认在把配置保存进客户端之前先回到终端做一次人工启动验证。原因是能直接在终端启动的进程客户端的启动成功率会高很多反过来如果终端都启动失败配置文件写得再正确也没有用。node -v npm -v npx --version然后确认实验目录存在mkdir -p ~/ai-tool-demo ls -la ~/ai-tool-demo这里使用的命令是 Unix 风格Windows 环境下可用mkdir %USERPROFILE%\ai-tool-demo代替。如果公司网络访问 npm registry 受限先确认 registry 配置可以访问不要跳过这一步直接去客户端里找原因。此后把上一步的 JSON 配置按客户端要求放入指定配置文件或图形界面中。由于不同产品的配置入口位置不同进入客户端的 MCP 管理页查看已配置列表是最直接的确认方式。6.4 如何验证 MCP Server 真的连接成功MCP 连接成功的标志不只是配置保存成功还要在对话里能看到该 Server 暴露的工具列表。以文件系统演示为例连接成功后模型通常会获得类似“列出目录、读取文件、写入文件”的能力。验证可以分两步第一步在对话中问你能使用哪些文件系统相关工具列出名称和用途。 第二步给模型一个具体任务请在 ~/ai-tool-demo 下新建一个 notes.md写入内容“MCP demo ok”然后读取并展示内容。如果第二步成功说明链路完整。如果第一步能列出工具但第二步执行失败需要去查看客户端输出面板中的实际报错这类问题通常与目录权限、路径解析或 Server 进程崩溃有关。如果第一步列出了工具但提示“不可用”或工具列表为空则优先检查配置里是否启用了该 Server、Server 进程是否仍在运行。6.5 MCP 和 Computer Use 不是同一类能力在搜索讨论中经常出现“MCP 和 computer use 的区别”。这里做一个快速澄清MCP 解决的是“程序化接口的调用”Server 以结构化工具形式暴露能力模型按参数规范调用Computer Use 解决的是“像人一样操作图形界面”模型直接观察屏幕截图并控制鼠标键盘。前者的执行路径确定、适合生产环境后者适合 GUI 自动化场景但稳定性和安全边界需要更谨慎。对比项MCPComputer Use交互方式通过协议调用结构化工具通过视觉识别操作屏幕接入形式本地子进程或远端服务桌面代理或云端浏览器稳定性较高接口固定依赖界面变化稳定性较低典型场景文件、SQL、Git、CI 等程序化操作网页点击、桌面软件操作风险点权限控制、命令注入、数据访问范围误操作、隐私展示、界面元素识别错误两者可以组合使用但不要把 MCP 当作用来替代 GUI 操作的万能方案。MCP Server 只要保证输入输出契约清晰就能稳定接入生产工作流。7. 组合实践一份规则加一个技能加一个 MCP 的完整实验单独演示四者之后还需要把它们组合起来看协同效果。下面用一个“MR 代码审查小助手”作为实验场景既能在学习环境里快速跑通也方便验证各层职责。7.1 实验设计为什么选代码审查场景代码审查任务天然会触达四层能力。首先需要一个仓库规范告诉模型项目使用什么语言、什么分支策略这对应规则文件其次需要一个审查流程告诉模型按“变更影响 - 代码规范 - 异常风险 - 测试覆盖”四步审这对应 Skill最后需要拿到真实的 diff 内容和文件列表这对应 MCP 的文件或 Git 工具。如果缺少任何一层实验都会表现出明显缺陷。没有规则模型评论会脱离团队风格没有 Skill每次审查步骤都可能不一致没有 MCP模型只能基于用户粘贴的代码片段做评论无法看完整上下文。7.2 实验步骤第一步在实验目录建一个仓库并写入规则文件mkdir -p ~/ai-tool-demo/review-demo cd ~/ai-tool-demo/review-demo git init然后在仓库根目录创建 AGENTS.md内容示例可以精简成几条# review-demo 项目约定 ## 技术栈 - Python 3.11 - FastAPI ## 审查要求 - 对外接口必须使用 Pydantic 模型做参数校验。 - 禁止在请求处理函数内写大段事务逻辑。 - 错误信息必须移除内部堆栈细节。第二步准备一个审查技能包核心 SKILL.md 说明审查顺序。技能目录可以放在项目下的 skill 目录中也可以按你的工具约定位置放置。第三步在 MCP 配置文件里启用一个能访问该项目目录的 MCP Server让对话客户端可以读取仓库文件与 diff。7.3 对话串联完成上述准备后在对话中发起任务请对当前分支相对于 main 分支的变更做一次代码审查。 要求 1. 按我项目规则文件中的约定检查。 2. 使用 code-review 技能的流程执行。 3. 只评论这次变更中真实存在的问题。 4. 输出格式为问题列表 | 严重级别 | 具体证据 | 修改建议。这个请求同时用到了四层能力规则文件约束“按团队约定”、提示词定义了本次任务范围与输出格式、Skill 规定了审查执行步骤、MCP 提供了读取分支差异的能力。会话启动时规则自动加载任务触发时 Skills 自动匹配并加载模型需要访问文件时再调用 MCP 工具提示词作为会话顶层的“调度中心”。7.4 实验结果与失败定位如果实验过程中模型回复“没有权限读取该目录”或“不知道如何读取 diff”说明 MCP 链路失败问题不在规则也不在 Skill应直接去查 MCP Server 配置。如果模型读了文件但审查意见明显不符合项目规范说明规则文件没有被自动加载要回到第 4 章的验证方法检查。如果模型知道规范也看得到文件但步骤混乱、漏评测试覆盖则是 Skill