上一篇：不会还有人只会聊天写 Prompt 吧？同事都在落地，你还 out | AI 工程化开篇
不会还有人把 Rule、Skill、MCP 写成一锅粥吧？边界一糊，落地全糊 | AI 工程化概念地图
系列：《从 Rule 到落地：AI 工程化实践》第 2 篇
标签：AI工程化 · Rule · Skill · MCP · Agent
序言
上文我们画了五层问题地图：约束、流程、工具边界、记忆、验证。童鞋们读完可能会问——那口里天天蹦的 Context、Rule、Skill、Tool、MCP、Agent，到底各管哪一层？别急，这六个词要是糊成一锅，你后面写目录、划权限、做路由，全会乱。
本篇就干一件事：把边界钉死。谁提供约束、谁提供步骤、谁提供工具、谁做编排。钉不住，后面越写越像在堆名词；钉住了，同事问你「Rule 和 Skill 差在哪」，你能一句话讲清。
说句自嘲的：我自己也懵过一阵，系统提示越写越长，什么都往里塞，结果还是翻车。后来才想明白——不是模型不听话，是我们把制度、手册、工具箱、值班长全塞进一张便利贴了。
概念
别做成名词卡片农场。咱们按「谁回答什么问题」过一遍，再配个接地气类比。
Context，就是此刻模型能看见的信息窗口：会话消息、打开的文件、检索到的片段。特点就俩字——易变。过期快、会话一换就没了。可以理解为：你桌上摊开的草稿纸，不是公司制度汇编。桌面再整齐，也不能拿它当唯一规矩。
Rule，回答「能不能做」。永远生效或按场景生效的禁止项、加载顺序、质量门禁。简单来说就是制度，偏「宪法」，不是操作手册。可以理解为：门禁上贴着「禁止带出生产密钥」——写清楚了才算数，口头「大家注意一下」不算。
Skill，回答「这类事怎么做」。面向一类任务的步骤、清单、模板、参考资料；可被意图路由选中，可版本化。可以理解为：某类故障的 SOP 手册——换个人接手，照着走，结果不至于天差地别。Rule 说「不许」，Skill 说「怎么走」。
Tool，一次可调用的具体能力动作：跑条命令、查个接口、写个文件。可以理解为：工具箱里的扳手——拧哪颗螺丝，一次干一件事。
MCP，别被英文唬住。它是把 Tool / Resource 用比较标准的方式暴露给 IDE / 助手的接入层。接上了不等于安全了哦——鉴权、熔断、谁能调写操作，还得另说。可以理解为：仓库对外的领料窗口；窗口开了，不等于谁都能进库房乱拿。
Agent，按入口纪律选规则、选技能、调工具，并对目标负责的编排者。很多人以为它是「更聪明的聊天框」。换个接地气说法：它是带纪律的值班长，不是只会递纸条的前台。嘴甜没用，得按程序把活干完。
顺带一句Prompt：单次输入指令。工程里它该被 Rule / Skill 制度化，而不是团队唯一依赖。提示词很香，但别把它当成仓库。
记住这张对照就够：
| 概念 | 一句话 | 类比 |
|---|---|---|
| Context | 此刻看见什么 | 桌面 |
| Rule | 什么不能做 / 必须做 | 制度 |
| Skill | 这类事怎么做 | SOP 手册 |
| Tool / MCP | 能调用什么能力 | 工具箱 / 领料窗口 |
| Agent | 谁按纪律编排 | 值班长 |
依赖关系也很直白：Agent 读 Rule、选 Skill、经 MCP 调 Tool；Context 只是当班桌上那一摊材料，喂给 Agent 用，不能替代前面几层。
问题在哪
名词混用，看起来「都会了」，落地时最疼的是三件事：目录设计乱、权限说不清、排障对不上号。细心的朋友可能已经中招过。
最常见的反模式，是把一切都写成超长系统提示。禁止项、操作步骤、接口密钥、验收标准，全糊在一段话里。会话一换，制度蒸发；人一换，口径漂移。你以为在「沉淀知识」，其实在「粘贴临时笔记」。
还有一类更隐蔽：把该进 Rule 的硬禁止，写成 Skill 里的某一步「记得别删库」；把该进 Skill 的步骤，写成 Rule 里的长篇散文；把该走 MCP 的能力，直接把密钥塞进 Context 长期粘贴。层放错了，后面再补救都别扭。
举例
举个不戏剧、但很真实的分层错位。
有人在聊天里跟助手说：「以后都别动生产配置。」助手当下点头，甚至还能复述一遍。过两天换会话，同事让它「帮忙改一下配置格式」，它又动手了——因为那句「别动」停在旧 Context 里，从没变成可版本管理的 Rule。
脱敏一点讲：在虚构的 acme 小团队里，有人把「禁止删库、禁止改公共入口」写进某次修故障的 Skill 步骤第三条。手册是给人做事用的，不是给门禁用的——步骤被跳过、被精简、被「这次例外」时，硬约束跟着一起蒸发。正模式很简单：硬禁止进规则包（比如acme-rules）常驻 Rule，并进版本库；Skill 只写「怎么修、怎么验」；高危写操作走带鉴权的工具出口，而不是聊天里粘密钥。
再对照一眼：
- Context：当场提醒——易丢。
- Rule：入库禁止项——可判定。
- Skill：修解析失败的步骤包——可复用。
- Tool / MCP：查日志、跑 dry-run——可调用且可收口。
- Agent：按入口清单选上面几样——可编排。
同一句话「别动生产」，放错层就是气氛；放对层才是工程。
自检
动手写下一份规则或技能之前，先花三分钟勾一下。勾不上的，就是边界债。
# 概念边界自检（可拷进团队仓库改） - [ ] 「能不能做」是不是写在 Rule，而不是聊天口头约定？ - [ ] 「怎么做」是不是沉淀成可版本化 Skill，而不是每次重讲？ - [ ] 外部能力是不是经 Tool / MCP 暴露，而不是 Context 里长期粘密钥？ - [ ] Agent 入口有没有纪律：先读规则，再选技能，再调工具？ - [ ] 有没有把硬禁止误写进 Skill 步骤、把长篇 SOP 误写成 Rule？再问自己两句更狠的：
- 你团队里「禁止改某路径」是气氛，还是入库 Rule？
- 换会话、换人之后，同一类任务还能不能走出差不多的路径？不能，多半是 Skill 层空着，或者全靠 Context 续命。
思考
六个概念各管一层，混用是落地失败的常见根因。再说直白点：Rule 管边界，Skill 管步骤，MCP 管能力出口，Agent 管编排；Context 易变，替代不了制度化的 Rule 和可版本化的 Skill。
本篇不讲 Rule 语法细节，也不讲 MCP 协议字段——那些留给后面专篇。你现在只要带走一张边界图：别再拿超长提示词当万能胶。桌面、制度、手册、工具箱、值班长，各归其位，后面目录和权限才会说话。
下篇预告：《一条主线预览：规则 → 技能 → 协议 → 记忆 → 测试闭环》——用五站导游图把全系列串起来，帮你建立全局感，并判断团队该从哪一站切入。
觉得有用的话，欢迎点赞、留言聊聊你最早分不清的是哪两个词；有「把禁止项写进步骤、把密钥粘进会话」的翻车故事，也欢迎甩过来，咱们对照边界图拆。
