给弱模型一本说明书：我把文档规范做成单文件 Skill，也终于分清了 Skill 和 MCP

给弱模型一本说明书：我把文档规范做成单文件 Skill，也终于分清了 Skill 和 MCP

我手里原本有一份内容很多的资料编写规范。它覆盖标题、段落、列表、表格、代码块、图片、链接、术语、标点、空格、版本号和单位等细节。人可以读完再维护文档，但每次执行都靠记忆，很容易漏掉几条。

更现实的问题是，这份规范要在一个受限的内部开发环境中交给本地 Qwen 模型使用。模型能力相对有限，对长提示词、隐含规则、跨文件引用和复杂工作流的指令遵循并不稳定。

我的最终做法不是继续堆提示词，而是用 Codex 把规范整理成一个单独的 SKILL.md。这个 Skill 的名字是 document-writing-spec，目标是指导模型完成资料的新建、修改、补全、格式化和规范检查。

这篇文章不打算把 Skill 和 MCP 写成概念百科。我更想复盘：为什么这个文件会形成现在的结构，它解决了哪些真实问题，又留下了哪些边界。

问题不是规范不够多，而是规范没有变成执行步骤

原始规范对人来说像一本手册，对较弱模型却不一定是可执行程序。

直接把整份规范粘贴到 Prompt 中，至少有四个问题：

• 上下文很长，模型可能只执行靠前或更显眼的规则。
• "适当处理""保持一致"等表达对人有意义，对模型却包含大量隐含判断。
• 不同使用者每次复制和补充的 Prompt 不同，输出难以复现。
• 模型不知道哪些规则必须执行，哪些只是建议，也不知道交付前还要检查什么。

例如，"表格写规范一些"不是可执行规则。当前 Skill 把它拆成了具体判断：表头两端保留空格、分隔行使用 | --- | --- |、空单元格填写 -、整列都是 - 时删除该列、复杂类型中的竖线写成 \|。模型不再需要猜"规范"是什么意思。

这也是整个实践的核心：不是让规范更长，而是把自然语言规范转换为可重复执行的工作说明。

为什么普通 Prompt 不够

Prompt 更像本次任务的口头交代。对于"一次性改一个标题""把这段话翻译成英文"之类的简单任务，Prompt 已经足够，没有必要为了使用 Skill 而使用 Skill。

但文档规范具有长期复用、规则多、边界严格的特点。如果每次都在 Prompt 中写完标题、表格、链接、代码和术语规则，提示词会越来越长，还会出现不同版本。规则变化后，也很难确认所有人复制的是不是最新版。

Skill 更像标准作业指导书。当前任务仍由 Prompt 指定，例如"只检查问题"或"直接修改文档"；稳定的执行流程、强制规则、禁止事项和自检清单则留在 Skill 中。这样，Prompt 负责表达本次目标，Skill 负责提供可复用的方法。

Skill 到底是什么

通俗地说，Skill 是提供给智能体或模型的一套可重复使用的任务说明和工作流程。OpenAI 官方文档把 Skill 描述为可复用工作流的编写形式：一个 Skill 目录至少包含 SKILL.md，文件内需要有 name 和 description，还可以按需加入脚本、参考资料和资源。Codex 会先看到 Skill 的名称、描述和路径，决定使用后才加载完整指令，这种机制称为渐进式披露。OpenAI Codex：Build skills

当前文件的入口很简单：

---
name: document-writing-spec
description: 根据本地资料编写规范，对文档进行新建、改写、补全、格式化和规范检查。
---

其中，description 不只是简介，也是触发边界。官方文档说明，Codex 可以被显式要求使用某个 Skill，也可以根据 description 隐式匹配。因此，描述必须清楚说明它做什么，而不是只写一个宽泛名称。

需要强调的是：Skill 不是新模型，不会改变 Qwen 的参数规模；它不等于微调、知识库或插件，也不会自动让弱模型变强。它主要解决"模型应按什么流程和规范做事"。最终效果仍受模型能力、上下文长度和运行平台支持程度影响。

如果一定要用比喻：模型像执行人员，Prompt 像本次口头任务，Skill 像标准作业指导书，MCP 像连接外部系统的标准接口。后文会把这个比喻还原成更准确的技术关系。

这个 SKILL.md 为什么有十九个章节

我实际读取的文件不是一份笼统的写作建议，而是按"入口---执行---规则---兜底---验收"组织的单文件工作流。

它先定义"使用范围、不适用范围和输入内容"，接着给出"规则优先级"和"固定执行流程"；中间集中放内容、结构、Markdown、标题、列表、表格、图片、链接、代码、标点、单位和术语规则；后面再处理"禁止事项、信息不足、规则冲突、正反例、输出要求和最终自检"。

这个顺序很重要。较弱模型如果先看到几百条格式细节，却不知道当前任务是什么，很容易局部执行。先确定任务，再加载约束，能降低把"检查"误做成"重写"、把"格式化"误做成"润色"的概率。

先明确任务类型

固定流程的第一步是判断任务属于新建、修改、补全、检查还是格式化。它们的动作边界不同：

• 新建需要确定结构并生成内容。
• 修改应尽量保留已有正确内容。
• 补全需要识别缺失信息，必要时使用占位符或询问。
• 检查默认应该报告问题，而不是擅自重写全文。
• 格式化主要应用 Markdown、标题、列表、表格、标点、空格等规范。

这里有一个值得如实记录的缺口：当前 SKILL.md 虽然把"格式化"列为任务类型，但没有单独定义"仅格式规范化"模式。它的边界分散在"必须保留关键信息""禁止改变原意""禁止混用名称""用户只要求指出问题时不得重写"等规则中。

因此，在真实测试里，我仍会在 Prompt 中明确补上一层限制：只修正排版，不润色、不扩写、不缩写、不重构，不修改接口、参数、路径、代码和专有名词。这个做法不是否定 Skill，而是让本次任务边界更精确。后续版本可以考虑把"仅格式规范化"提升为独立模式。

用明确词语划分规则等级

文件大量使用"必须""禁止""不得""优先""建议"。这不是文风偏好，而是指令遵循设计。

"必须"代表验收条件；"禁止"和"不得"代表越界条件；"优先"和"建议"允许在不冲突时采用。相比之下，"适当""视情况""酌情"等表达把判断责任重新丢给了模型。模型越弱，这种隐含判断越容易产生不一致结果。

固定流程不是让模型展示思维过程

当前 Skill 的流程是：判断任务、提取用户要求、识别文档和读者、检查信息完整性、处理冲突、确定结构、编写或修改、应用格式、统一术语和标点、检查禁止事项、静默自检、输出结果。

流程的目标是减少漏项，不是要求模型展示内部推理。文件反而明确要求执行过程保持静默，只输出最终文档或必要问题。这既减少无关内容，也避免把"解释自己做了什么"误当成任务成果。

规则优先级负责处理冲突

当前优先级从高到低是：用户当前任务中的明确要求、强制规则、特殊场景规则、通用规则、推荐规则、模型默认写作习惯。

例如，用户只要求检查问题时，模型不应该因为"完整输出更好看"就重写全文。又如，规范要求使用三段式版本号，输入却给出四段式版本号时，模型需要识别冲突，而不是静默选择一个自己喜欢的结果。

没有优先级，规则越多，冲突越难排查；有了优先级，至少可以复现模型为什么采取某种处理。

禁止事项是任务边界的负面清单

只告诉模型"应该怎样写"还不够。当前 Skill 单独集中了一章禁止事项，包括不得虚构事实、数据、接口、参数、路径和引用，不得改变原文含义，不得删除关键条件，不得混用名称，也不得使用裸链接、错误标题层级和未经评审的网页图片。

这组负面约束尤其适合技术资料。一个"更通顺"的参数名如果并不存在，就是错误；一个看似合理但来源不明的接口字段，就是幻觉。文档任务中的"no hallucination"不能只靠一句"请准确"，而要变成可检查的禁止项。

自检必须能回答是或否

文件最后有 29 项静默自检，从用户要求、事实完整性、标题层级，一直检查到表格、代码块、链接、图片、单位、术语、个人信息和无关解释。

每一项都能回答"是"或"否"，比"整体检查一下质量"更容易执行。它仍不能保证百分之百正确，但给模型建立了明确的完成条件，也让失败样例更容易定位到具体规则。

为什么最终只保留一个 SKILL.md

官方 Skill 结构允许加入 scripts/、references/ 和 assets/，Codex 也通过渐进式披露减少不必要的上下文加载。OpenAI Codex：Build skills

但这次使用场景是受限的内部开发环境，本地模型能力相对有限。我不希望它跨多个文件查找规则，也不想为复制、路径和加载顺序增加新的失败点。因此，我选择把关键规则、正反例和自检全部集中在一个文件里。

单文件方案的优势很直接：复制一个文件即可使用；排查问题时只有一个入口；规则不容易因漏加载某个 reference 而失效。它是一种针对当前环境的工程取舍，不是所有项目的最佳实践。

缺点同样明显：文件会变长；规则更新容易造成重复；大量模板、脚本和复杂示例不适合继续塞在正文中。如果规范持续扩大，或者运行平台和模型能够稳定支持渐进式加载，就应该考虑把详细参考、模板和确定性脚本拆出去。

Skill 最重要的作用是把经验变成可测试的流程

这个实践让我感受到，Skill 的价值不是保存一篇更长的 Prompt，而是把个人经验和团队规范转成可复用、可版本管理、可测试的工作流。

同一类任务不必反复解释；任务边界更清晰；输出更一致；失败时可以定位是触发描述、执行流程、某条规则还是自检失效。规则修改也可以通过 Git 记录，而不是散落在聊天历史里。

当然，Skill 不能保证模型永远正确。必须准备真实样例，比较修改前后差异，并保留人工检查。对于弱模型，结构化指令能降低随机性，但不会消除能力上限。

MCP 解决的是另一层问题

MCP 全称 Model Context Protocol。官方文档将它定义为 AI 应用与外部系统交换上下文和能力的协议。它采用 Host---Client---Server 架构：Host 是协调一个或多个连接的 AI 应用；Host 为每个 Server 创建对应的 Client；Client 维护连接；Server 提供上下文或能力。MCP Architecture overview

MCP Server 可以暴露三类核心能力：

• Tools：可执行函数，例如文件操作、API 调用和数据库查询。
• Resources：供应用读取的上下文数据，例如文件内容、数据库记录和接口响应。
• Prompts：可复用的交互模板或指令。

这些定义来自 MCP 官方服务端规范。MCP Server Features

因此，MCP 可以用于读取数据库、查询知识库、获取 GitHub 信息、操作文件系统、读取项目管理工具或调用业务 API。它不是模型训练方式，也不是普通 HTTP 接口本身；HTTP 可以是传输方式之一，但 MCP 还定义了生命周期、能力协商、消息结构和核心原语。它同样不会自动提高模型能力。

Skill 与 MCP 的区别

对比项	Skill	MCP
核心作用	告诉模型如何完成任务	连接模型与外部数据和工具
解决的问题	流程、规范、经验复用	外部能力接入
主要内容	指令、规则、流程、示例、可选脚本	Tools、Resources、Prompts 等协议能力
是否需要外部服务	通常不一定	通常需要 MCP Server 或对应连接
是否直接提供业务数据	通常不提供	可以提供
是否定义工作步骤	是主要用途	不是核心职责
典型例子	文档规范 Skill	GitHub、数据库或文件 MCP Server
与模型关系	教模型怎样做	给模型可调用的能力

一句话概括：Skill 解决"怎么做"，MCP 解决"可以连接什么、调用什么"。

这只是方便理解的概括，现实系统中二者边界会有交叉。例如，MCP Server 也可以提供 Prompts，Skill 也可以声明工具依赖。但二者的主要关注点仍然不同：前者偏工作方法，后者偏标准化连接。

Skill 与 MCP 不是二选一

假设任务是：根据团队规范，从知识库读取接口资料并生成 API 文档。

Skill 负责定义文档结构、标题层级、术语表达、禁止虚构接口信息的规则，以及生成后的检查流程。MCP 负责连接知识库、查询接口定义、读取代码仓库、获取真实参数和版本信息。

用户提出任务
    ↓
Skill 规定执行方法
    ↓
模型通过 MCP 获取真实资料
    ↓
模型按照 Skill 生成文档
    ↓
执行 Skill 中的最终检查

这种组合同时解决了"方法是否一致"和"数据是否真实"。如果只有 Skill，没有外部数据访问，模型可能缺少事实；如果只有 MCP，没有写作规范，模型虽然拿到了真实数据，输出结构仍可能不一致。

Prompt、Skill、MCP 怎么选择

只使用 Prompt，适合一次性、规则少、不需要外部数据、无需长期复用的任务。

使用 Skill，适合需要反复执行、有固定规范、有明确流程、输出需要保持一致，或者需要沉淀团队经验的任务。

使用 MCP，适合需要访问外部系统、调用工具、读取实时或私有数据，或者连接数据库、文件、代码仓库和业务平台的任务。

Skill 与 MCP 一起使用，适合既有固定工作规范，又需要真实外部数据或工具的任务。

判断时不要从技术名词出发，而要先问两个问题：任务的方法是否需要复用？任务是否需要连接外部世界？前者决定是否需要 Skill，后者决定是否需要 MCP。

我如何测试这个文档 Skill

我会先复制一篇 Markdown 文档并保留原始版本，再故意加入标题、列表、空格、表格和代码块问题。测试时明确要求"仅格式规范化"：

使用 document-writing-spec Skill 对 test.md 执行仅格式规范化。

只修正格式问题，不润色、不扩写、不缩写、不改变原文含义，不修改代码、参数、路径和专有名词。

直接修改 test.md，完成后列出修复的格式问题。

执行后使用 Git diff 验证，而不是只看最终文档"好像更整齐"。重点检查：

• 正文语义是否发生变化。
• 标题、列表、表格和代码块问题是否遗漏。
• 接口、参数、路径、代码和专有名词是否被擅自修改。
• 相同输入多次执行时，结果是否基本稳定。
• diff 中的每一处变化能否对应到 Skill 或本次 Prompt 的明确规则。

如果模型持续犯同一种错误，应该修改规则、示例或任务边界，再重复测试。Skill 的维护过程更像规则驱动的回归测试，而不是写完文件就结束。

实践后的认识

这次实践让我确认：Skill 的价值不在于把提示词写得更长，而在于把任务边界、规则优先级、执行流程和检查标准写清楚。

对较弱模型而言，明确往往比聪明更重要。单文件 Skill 是针对受限远程环境的取舍：它牺牲了一部分渐进式拆分和资源复用能力，换取更低的加载复杂度和更直接的排障路径。

当规范继续扩大、模型能力提高或平台支持更多能力时，这个 Skill 还可以演进：补上独立的"仅格式规范化"模式，拆出模板和参考资料，或者用脚本完成需要确定性的检查。

Skill 与 MCP 解决的是两个层面的问题。一个可靠的 Agent 系统，既需要清晰的做事方法，也需要可信的外部能力。前者减少随意发挥，后者减少脱离事实；两者配合，才更接近可复现、可验证的工程流程。