上一篇不会还有人只会聊天写 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 调 ToolContext 只是当班桌上那一摊材料喂给 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 协议字段——那些留给后面专篇。你现在只要带走一张边界图别再拿超长提示词当万能胶。桌面、制度、手册、工具箱、值班长各归其位后面目录和权限才会说话。下篇预告《一条主线预览规则 → 技能 → 协议 → 记忆 → 测试闭环》——用五站导游图把全系列串起来帮你建立全局感并判断团队该从哪一站切入。觉得有用的话欢迎点赞、留言聊聊你最早分不清的是哪两个词有「把禁止项写进步骤、把密钥粘进会话」的翻车故事也欢迎甩过来咱们对照边界图拆。