Skills 和 MCP 这两个词最近被放在一起讨论的频率，高到有点失真。我第一次看到有人把两者并列成"AI 编程必备资源"的时候，直觉是这不搭——一个是写给模型看的操作手册，一个是让模型能伸手够到外部系统的插槽，层次完全不在一条线上。但把一套流程从零跑到能用之后，我改主意了：单看任何一个都只是半成品，真正决定体验的是两者怎么咬合。这篇就把我这边从选型、搭建、写 Skill、接 MCP 服务端到全链路拼装的完整过程摊开讲，包括那些文档里不会写、但一定会让你卡住半小时的细节。适合已经能让模型跑起来、但觉得"它总是在瞎猜我意图"或者"每次都要我手动贴上下文"的开发者，也适合正在评估要不要把内部系统接进 AI 工作流的技术负责人。看完你至少能判断：哪些环节该用 Skill 兜住，哪些必须靠 MCP 打通，以及什么情况下两个都别上。
1. Skills 与 MCP 的分工边界，先掰扯清楚再动手
很多人一上来就问"这两个哪个更好"，这问题本身就问错了。它们解决的是两类完全不同的问题，混在一起讨论只会得出"都挺有用但都不好用"的结论。我先把这两层的职责划清楚，后面所有的配置和踩坑才有坐标。
1.1 一个管"怎么干"，一个管"能碰到什么"
用厨房打个比方。MCP 是灶台、冰箱、刀具架——它决定了你物理上能接触到哪些食材和工具，以及每个工具怎么用（接口签名、参数、返回什么）。Skills 是贴在墙上的菜谱卡片——它不提供任何食材，但它告诉你做这道菜先切什么、火候多大、什么时候放盐、失败了怎么补救。
落到技术层面，MCP 是一套基于 JSON-RPC 的客户端-服务端协议，服务端对外暴露三类东西：tools（可调用的函数）、resources（可读取的数据，比如文件、数据库行）、prompts（可复用的提示模板）。客户端负责发现这些能力、在合适的时候调用、并把结果回填给模型。它解决的核心问题是连接：让模型能触达真实世界的数据和动作。
Skills 本质上是一组带元数据的指令文件，通常是一个目录加上一个入口说明文件。它里面写的是流程、判断条件、注意事项、甚至可执行脚本的调用顺序。它解决的核心问题是知识：把"我们团队做这件事的约定俗成"从人的脑子里搬到模型能读到的地方。
关键差异在这里：MCP 服务端再多，模型也不知道什么时候该用哪个、按什么顺序用、用之前要检查什么。反过来，Skill 写得再详细，如果它引用的工具压根不存在，那就是一张废纸。所以正确的表述不是"Skills 和 MCP 哪个好"，而是"Skills 声明意图和顺序，MCP 提供执行能力"。
下面这张表是我自己梳理的对照，建议在动手前先对一遍，能省掉很多返工：
| 维度 | Skills | MCP |
|---|---|---|
| 核心职责 | 流程编排、领域知识、判断规则 | 能力暴露、数据与动作接入 |
| 载体形式 | 目录 + 说明文件（含元数据头） | 独立进程或 HTTP 服务 |
| 加载时机 | 按需、渐进式加载 | 会话建立时握手、按需调用 |
| 主要成本 | 上下文 token（正文长度） | 连接管理、延迟、权限风险 |
| 失效表现 | 模型不按流程走、误触发 | 工具调用报错、超时、返回异常 |
| 谁维护 | 业务方 / 流程 owner | 平台方 / 系统 owner |
| 变更频率 | 高（流程常调整） | 低（接口相对稳定） |
这张表里最容易被忽略的是"变更频率"那一行。我见过有团队把业务规则直接硬编码进 MCP 服务端的返回里，结果每次流程微调都要发版、重启服务、通知所有人更新配置。这类内容天然属于 Skill 层，改一个 Markdown 文件就生效，完全不用碰服务端。
1.2 从一次具体需求看两条路的取舍
举个我实际遇到的场景。团队需要一个"根据提交记录生成发版说明"的能力。最朴素的做法是每次手动把 git log 贴给模型，让它整理。这个做法的问题是显而易见的：贴多少条、按什么格式整理、哪些提交要合并、哪些要过滤掉（比如格式化提交），全靠人临时交代，每次结果都不一样。
这时候有两条路。第一条是写一个 MCP 服务端，暴露一个generate_release_note工具，把所有逻辑写在服务端代码里。第二条是写一个 Skill，里面声明：先调用已有的get_commits工具拿数据，然后按下面的规则分组、过滤、排序，最后按模板输出。
我选了第二条，理由有三点。第一，这套规则会变——上个月按模块分组，这个月产品要求按影响范围分组，改 Skill 是分钟级的事，改服务端要发版。第二，规则本身需要人 review，放在 Markdown 里非技术同事也能看懂、能提意见，塞进 Python 函数里就没人看了。第三，get_commits这个能力是通用的，别的流程也要用，没必要为了一件事重复造一个服务端。
但反过来，如果需求是"读取内网的构建产物清单"，那就必须走 MCP。因为模型没有任何办法自己访问那个系统，这属于纯粹的能力缺口，Skill 再怎么描述也变不出一只手来。
我总结的判断口诀是：能不能碰到 → MCP；碰到了之后怎么处理 → Skills。遇到需求先问自己这句，八成不会选错。剩下的两成是混合场景，那才是全链路真正发挥价值的地方，后面第 5 节会专门讲。
2. 把最小链路跑起来：环境、配置与第一次握手
理论讲完就该动手了。这一节的目标很明确：让一个最简 MCP 服务端能被客户端发现并成功调用一次。别小看这一步，我统计过自己在不同机器上重搭环境的耗时，第一次平均要花 40 分钟以上，而卡住的地方几乎从来不是代码，是配置和环境。
2.1 目录结构与配置文件的实际长相
先说清楚目录怎么放。我习惯把 Skill 和 MCP 服务端分开放，因为它们生命周期不同：
workspace/ ├─ skills/ │ ├─ release-note/ │ │ ├─ SKILL.md # 入口，含元数据头 │ │ ├─ reference.md # 参考资料，按需加载 │ │ └─ scripts/ │ │ └─ verify.py # 辅助校验脚本 │ └─ incident-triage/ │ └─ SKILL.md ├─ mcp-servers/ │ ├─ kb-server/ # 内部知识库检索 │ └─ repo-server/ # 代码仓库只读查询 └─ mcp.json # 客户端配置Skill 的入口文件必须带元数据头，这一段是触发机制的全部依据，写不好后面全是误触发。最小可用版本大概长这样：
--- name: release-note description: 当用户要求整理发版说明、生成 changelog、或提到 release note / 发版公告 时使用。不适用于日常提交总结或代码评审。 version: 1.3 --- ## 前置检查 1. 确认已获取起始 tag 与结束 tag，任一缺失则先反问用户，不要猜测。 2. 调用 `repo.list_commits`，参数 base 与 head 使用上面两个 tag。 ## 处理规则 - 过滤掉类型为 chore、style、test 的提交 - 同一 PR 的多个提交合并为一条，以 PR 标题为准 - 按 feat / fix / perf / refactor 四类分组，组内按影响模块排序 - 破坏性变更单独成段，置于最前 ## 输出格式 固定使用三级结构：破坏性变更、新增能力、问题修复。 每条包含：一句话描述 + 关联 PR 编号。禁止输出原始 commit hash。 ## 失败处理 若 `repo.list_commits` 返回空列表，直接告知用户区间内无有效提交并终止，不要自行编造。注意description那一行的写法。它同时承担两个功能：告诉模型这个 Skill 干什么，以及明确排除什么。我最初只写了前半句，结果模型看到"提交记录"四个字就触发，天天在代码评审时给我弹发版模板。加上排除句之后误触发率肉眼可见地降下来。
客户端配置这块，各家格式略有差异，但核心字段就那几个。以本地进程方式启动的服务端为例：
{ "mcpServers": { "repo": { "command": "python", "args": ["-m", "repo_server", "--root", "/data/repos"], "env": { "REPO_TIMEOUT": "30", "LOG_LEVEL": "warn" } }, "kb": { "url": "http://127.0.0.1:8931/mcp", "headers": { "X-Tenant": "dev" } } } }这里有个特别容易翻车的点：command和args走的是本地子进程，标准输入输出就是协议通道。任何往 stdout 打印的东西都会污染协议流。我在服务端里加了一句调试用的print("server started")，结果客户端直接报解析错误，排查了二十多分钟才定位到。后来统一规定：所有日志走 stderr，或者写到文件，stdout 只允许出现协议报文。这条规矩现在写进了内部规范第一条。
2.2 第一次握手：确认它真的连上了
配置写完别急着让模型干活，先做一次纯协议层验证。MCP 的报文是标准 JSON-RPC 2.0，你完全可以手动构造，看清楚每一步返回了什么。
先发初始化请求：
{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"probe","version":"0.1"}}}正常响应里会带serverInfo和capabilities，capabilities里有没有tools、resources、prompts这几个键，直接决定了后面能用哪些能力。如果这里返回的是空对象，说明服务端压根没注册任何原语，后面的调用必然失败——很多"工具调不通"的问题其实在这一步就已经有答案了。
接着列工具：
{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}返回大概是这样：
{"jsonrpc":"2.0","id":2,"result":{"tools":[{"name":"list_commits","description":"按区间列出提交","inputSchema":{"type":"object","properties":{"base":{"type":"string"},"head":{"type":"string"}},"required":["base","head"]}}]}}然后真正调用一次：
{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"list_commits","arguments":{"base":"v1.2.0","head":"v1.3.0"}}}返回里如果有isError: true，说明工具本身执行出错，错误信息在content数组里。这个字段非常重要，它跟协议层的 error 是两回事：协议层 error 意味着方法不存在或参数格式错误，isError意味着方法执行了但业务失败。我在做错误处理时把两者分开对待，前者直接崩，后者走降级。
提示：手动验证这一步强烈建议保留成脚本，每次改动服务端或客户端配置后跑一遍。它比打开界面点来点去快得多，也更容易看出是哪一层出的问题。
3. Skills 编写的门道：别把说明书写成论文
Skill 看起来门槛最低——不就是写个 Markdown 吗。但我见过太多写废的：要么写了三千字把模型淹了，要么三行字什么都没说清楚，模型只能自由发挥。这里面的分寸感，是整套链路里最需要经验的部分。
3.1 触发条件与边界的写法
description是整个 Skill 里最重要的一行，没有之一。因为它是唯一常驻上下文的部分，其他内容都是命中后才加载。这意味着模型做"要不要用这个 Skill"的判断时，手里只有这一句话。
我总结了几条写法上的硬经验。第一，用用户的话说，不要用系统的话说。写"处理 CI 流水线产物归档"就不如写"当用户说打包产物放哪儿、构建结果在哪、artifact 找不到时使用"。用户不会说"产物归档"，他会说"那个 zip 在哪"。第二，把排除项写明确。上面那个发版 Skill 的例子已经演示过，不适用于...这半句的价值不低于前半句。第三，写清楚触发强度。有些 Skill 是"只要提到就必须用"，有些是"用户明确要求时才用"，这个差别得在描述里体现，比如加"仅当用户显式要求"或"任何涉及 X 的操作都应先加载本 Skill"。
还有一个反直觉的点：Skill 数量不是越多越好。每个 Skill 的描述都要占上下文，二十个 Skill 就是二十条常驻描述，模型在选的时候容易犹豫。我现在的做法是按项目分组，同一时间只挂载当前项目相关的五到八个，其余的放在库里按需启用。这比一股脑全开效果好很多。
3.2 渐进式加载与上下文预算
Skill 的加载是分层的。第一层只有名称和描述（几十个 token），第二层是正文（几百到几千 token），第三层是引用的外部文件和脚本（只在需要时读）。用好这个分层，能省下大量上下文。
我的实践是：正文控制在 300 行以内，超出的部分拆到 reference 文件里。正文只保留判断逻辑和步骤骨架，详细的数据字典、字段说明、历史背景全部挪到同级文件，然后在正文里写一句"字段含义参见 reference.md，遇到不明确的字段时读取"。模型真的需要时会自己去读，不需要时这部分完全不占位置。
这套做法带来的一个副作用是：Skill 内部的引用路径必须写相对路径，而且得确认客户端的工作目录设置。我用过绝对路径，换台机器就全废；也试过省略./前缀，某些客户端解析不到。现在的统一写法是scripts/verify.py这种纯相对形式，从 Skill 所在目录起算。
测上下文开销的时候我做了个简单对照，样本是本地中等配置的开发机，跑了约两百次调用，口径是单次会话平均消耗：
| Skill 组织方式 | 常驻描述 token | 命中后正文 token | 首次响应延迟 | 流程走对率 |
|---|---|---|---|---|
| 单个巨型 Skill，全部塞正文 | 约 60 | 约 2600 | 2.1s | 78% |
| 拆分三层，正文精简 | 约 60 | 约 700 | 1.4s | 91% |
| 拆成多个小 Skill 协同 | 约 220 | 约 500 | 1.6s | 89% |
第三个方案常驻成本高了不少，走对率反而略低，原因是多个 Skill 之间存在职责重叠，模型偶尔会挑错。所以我的结论是：优先做单个但分层清晰的 Skill，只有在职责确实正交时才拆分。这个数据和直觉不太一样，值得记一下。
3.3 版本与回归测试
Skill 是活文档，改起来太方便，反而容易失控。我吃过一次亏：改了一句过滤规则，把某个重要的修复提交类型误排除了，连着两个版本的发版说明都漏了东西，等到用户反馈才发现。
现在我的做法是给每个 Skill 配一组最小回归样例。不需要复杂的测试框架，就是一个 Markdown 文件，记录"输入 → 期望输出特征"，每次改动后拿几条跑一遍。比如发版 Skill 的样例里会有：包含破坏性变更的提交集合、全是 chore 的空集合、跨模块合并的场景。跑完对照输出，明显跑偏能立刻看出来。
另外一个细节是Skill 里引用的工具名必须和服务端实际暴露的一致。这个听起来是废话，但服务端改个工具名、Skill 没跟着改的情况太常见了，而且报错信息往往很隐晦——模型会以为是工具不存在，然后自己编一个替代方案出来。我在 Skill 的头部加了一行requires: repo.list_commits, repo.get_pr，纯给人看的，但 review 的时候一眼能对出来。
4. MCP 服务端实测：三类能力的风险差异极大
服务端写起来不难，难的是知道哪种能力可以放心暴露、哪种必须加护栏。我按风险从低到高把常见能力分成三类，每一类的实测表现和注意事项差别很大。
4.1 只读查询类：最适合作为起点
只读类工具是最安全的，也是最容易做出效果的。典型的是文档检索、代码搜索、配置查询、日志筛选。它们的共同点是：不改变任何状态，重复调用不会产生副作用，出错最多是返回不准。
我的第一个服务端就是知识库检索，暴露两个工具：search_docs和read_doc。实现上没什么特别的，但有两个细节决定了它好不好用。
第一个是返回粒度。最初我把整个文档内容直接返回，一篇长文档八千字，一次调用就把上下文吃掉大半，模型接下来啥也干不了。后来改成返回"片段 + 位置标识"，每条片段控制在 200 字以内，最多返回 5 条，模型觉得不够会自己再调read_doc精确读取。这个改动之后，同一批任务的成功率明显上升，因为上下文留给了推理而不是搬运。
第二个是描述里的检索提示。search_docs的description不能只写"搜索文档"，得写清楚"支持按标题关键词和正文关键词检索，返回按相关度排序的片段，中文分词已处理"。这几句话直接影响模型怎么构造查询词。我对比过，加上这段说明之后，模型胡乱用长句查询的比例下降了很多。
4.2 写入与执行类：幂等和权限是命门
一旦工具会改变状态，风险等级立刻跳一档。我这边所有写操作类工具都强制遵守两条规矩。
规矩一：必须幂等。理由是模型会重试。工具超时了它会重试，返回结果看不懂它会重试，甚至有时候只是单纯地重复了一次。我遇到过最典型的情况是"创建任务"工具被连续调用了三次，生成了三条重复记录。解决办法是让工具接受一个request_id参数，服务端做去重；如果做不到，就在 Skill 里显式写"调用前先查询是否已存在"。后者更笨但更通用。
规矩二：高危操作必须二次确认。我在服务端做了一个简单的分级：影响范围可逆的（新建、追加）直接执行；不可逆的（删除、覆盖、发布）要求调用方传入一个confirm_token，这个 token 由另一个只读工具预先探查出影响范围后生成，并且在 Skill 里明确规定"必须先调用预览工具并向用户展示影响范围"。这条设计拦住过至少两次误删。
权限这块还有一个实践：能给服务端加白名单就别指望模型自觉。我早期靠 Skill 里的"禁止执行 X"来约束，结果模型在上下文被塞满之后偶尔会忽略这些约束。后来直接在服务端做了参数校验，非法参数一律拒绝并返回明确原因，问题就消失了。写在代码里的规则比写在提示里的规则可靠得多，这个判断我至今没变过。
4.3 长任务与流式返回的取舍
有些工具天然耗时，比如全量索引重建、大规模代码扫描。这类工具如果同步阻塞，客户端那边很容易超时。
我试过三种处理方式。同步阻塞：最简单，但超过 30 秒基本必超时，而且模型在这期间什么都做不了。流式返回进度：体验好，但实现复杂，客户端支持程度参差不齐。异步任务模式：调用立即返回一个任务 ID，再暴露一个get_task_status轮询，模型可以边等边做别的。
实测下来我选第三种为主。它的好处是把长耗时拆成了可观测的短交互，模型能明确知道"任务还在跑"，而不是傻等。缺点是多了一次轮询的工具调用开销。我的优化是把轮询间隔做在 Skill 里，明确写"每轮最多轮询一次，超过三次未完成则告知用户稍后查看"，避免模型陷入无限轮询。
5. 全链路拼装：Skill 调度 MCP 的编排模式
前面都是零件，这一节讲装。全链路的典型流程是：用户提需求 → 模型读常驻描述判断命中 → 加载 Skill 正文 → 按正文指示调用 MCP 工具 → 处理返回 → 继续下一步或输出。
5.1 编排契约该怎么写
所谓编排契约，就是 Skill 正文里对"调什么、传什么、拿到之后怎么办"的规定。这里最常见的问题是写得太松，只写了"调用 X 工具获取数据"，没写清楚参数从哪来、返回怎么用。
我现在要求 Skill 里的每个工具调用都写四件事：工具名、参数来源、成功判据、失败处理。举个真实在用的片段：
### 步骤 2：拉取变更清单 - 工具：`repo.list_commits` - 参数：base = 用户指定的起始 tag；head = 用户指定的结束 tag - 成功判据：返回的 commits 数组非空，且每条含 sha 与 message - 失败处理：若 `isError` 为真，原样转述错误信息并终止，不要改用其他工具替代最后那句"不要改用其他工具替代"很关键。模型的默认倾向是遇到障碍就绕路，会自作主张换个工具试试，结果往往是数据源不一致，生成的东西看起来对但实际是错的。显式禁止绕路，比事后解释为什么错要省事。
参数来源也得写死。我吃过"参数靠模型猜"的亏：Skill 里只写了"传入合适的 tag"，模型就真的猜了一个看起来很像的 tag 名，调用成功、返回为空、然后它开始编造内容。现在凡是需要用户提供的参数，一律写成"必须先向用户确认，不得推断"。
5.2 错误传播与降级策略
全链路上任何一环出错，都会让最终输出变成幻觉温床。我的处理原则是：错误必须显式传播到用户，不允许模型自行消化。
具体做法是在 Skill 里统一规定错误表达格式。工具返回isError时，模型要输出"步骤 N 执行失败：<原始错误摘要>，已停止后续步骤"。这里的关键词是"已停止"。如果不写死，模型会说"虽然获取数据失败，但根据我的理解……"然后开始编。这类输出比直接报错危险得多，因为用户往往看不出它在编。
降级策略要看场景。只读查询失败，可以降级到"告知用户暂时无法获取，请稍后重试"。写操作失败，绝对不能降级，必须停。还有一种介于两者之间的情况：工具成功返回但数据为空。这个和失败是两回事，我在 Skill 里专门区分了——空返回要明确说"区间内无符合条件的记录"，而不是"获取失败"。
5.3 观测与追踪
链路一旦超过三步，出问题时就很难定位是哪一环。我在服务端加了一套轻量追踪，每次tools/call记录五项：请求 ID、工具名、入参摘要（截断到 200 字）、返回大小、耗时。
返回大小这一项特别值得单独拎出来说。我统计过自己这套服务端的调用记录，返回体超过 4000 字的调用只占一成多，但这一成多贡献了大部分的上下文溢出问题。加了这个字段之后，哪个工具容易返回巨量数据一目了然，优化目标立刻明确。
请求 ID 的用法是在 Skill 里不做任何要求，纯粹给日志关联用。因为模型不会主动传请求 ID，所以我在客户端侧统一注入一个会话级的 ID，服务端记录下来，事后按 ID 串起来就能看到完整调用链。这套东西加起来不到一百行代码，但排查效率提升非常明显。
6. 实测记录与几个反复出现的坑
这一节把实测数据和踩坑记录集中放一下，都是我在实际运行中记下来的，不保证在你的环境下成立，但可作为参考基线。
6.1 开销与延迟的实测对照
测试环境是本地开发机，中端配置，服务端都是本地进程，样本约两百次完整链路调用。延迟指从用户发出请求到模型开始输出第一段内容。
| 链路形态 | 平均耗时 | 上下文峰值占用 | 任务完成率 | 主要瓶颈 |
|---|---|---|---|---|
| 纯对话，无工具 | 0.9s | 低 | — | 无 |
| 单次只读工具调用 | 1.6s | 中 | 88% | 检索质量 |
| Skill + 两次工具调用 | 2.8s | 中 | 92% | Skill 正文长度 |
| Skill + 五次以上调用 | 5.4s | 高 | 81% | 上下文累积 |
| 异步长任务 + 轮询 | 视任务而定 | 中 | 86% | 轮询策略 |
第五行那个"五次以上调用完成率反而下降"的结果，一开始让我很困惑。后来看日志才明白：调用次数多了之后，前面步骤的返回内容还堆在上下文里，模型对早期信息的注意力明显下降，开始出现"忘了第一步拿到的 tag 是什么"这种情况。解决办法是在 Skill 里加一步"中间结果摘要"——每两到三步让模型输出一个极简摘要，把关键值写下来，后续只依赖摘要而不是原始返回。这个改动把完成率拉回到 90% 以上。
6.2 那几个绕不过去的坑
第一个坑：stdout 污染协议流。前面提过，这里再说细一点。不只是print，某些库的默认日志、进度条、警告都会往 stdout 写。我的处理方式是启动时立刻重定向 stdout 到 stderr，只在需要发报文时用原始句柄。这个改动之后，那类"客户端莫名报解析失败"的问题基本绝迹。
第二个坑：工具描述写成小作文。有个工具的描述我写了二十多行，把参数含义、注意事项、历史变更全塞进去了。结果它每轮都要占这些 token，而且模型反而抓不住重点。后来压到三句话：干什么、什么时候用、返回什么形状。详细说明全部挪进 Skill。这个调整对成本影响很直接。
第三个坑：Skill 描述里的模糊动词。"处理"、"优化"、"整理"这类词在描述里几乎等于没写。我改过一条："整理项目文档"改成"把项目里的散落 Markdown 收敛成目录索引并补齐缺失的标题层级"，触发准确率立刻不一样。描述要具体到能让人一眼判断"这事归我管还是不归我管"。
第四个坑：服务端热重载导致的连接失效。开发时我习惯改完代码自动重启服务端，但客户端那边持有的还是旧连接，会出现"工具列表是新的、调用却失败"的诡异现象。现在的做法是改完必须重启客户端会话，别图省事。
第五个坑：以为通了就是稳了。第一次跑通那个兴奋劲儿过去之后，真正的问题才开始暴露——换个输入就崩、并发两个请求就串数据、跑一上午上下文就满了。我现在给每条链路都准备了至少五组异常输入：空参数、超长参数、不存在的 ID、权限不足的账号、服务端故意超时。这五组能过，才算初步可用。
注意：上面提到的所有工具名、参数名、配置字段都是示意性质，实际使用时以你所用客户端和服务端 SDK 的文档为准，协议层的字段（
jsonrpc、method、params、isError）是通用的，其余可能各家有差异。
我个人在实际操作中的体会是，Skills 和 MCP 这条链路最难的部分从来不是把它们跑通，而是把边界划清楚——哪些逻辑该沉到服务端做硬约束，哪些该浮到 Skill 里保持灵活。我现在的默认倾向是：凡是涉及安全和正确性的，一律沉到服务端；凡是涉及流程和偏好的，一律浮到 Skill。按这个原则走过几轮之后，改动的频率和出问题的概率都降下来了。另外一个小建议，如果你的 Skill 超过十个，先别急着加新的，花半天时间把已有的合并、分层、补回归样例，收益比再写十个都大。
