我在 Claude Code、Codex 和 Pi-Bolt 之间换着用，经常遇到这种情况：只想让 AI 帮忙写个页面，配置里先冒出一排名词，像来办事之前还得考个证。
拿“根据 Figma 设计稿实现页面”来说，MCP 可以负责接入设计稿，Skill 规定图片怎么处理，Workflow 安排确认和执行的顺序，Rules 限制哪些文件不能动，Memory 留下下次还需要的约定。
它们可以一起用，分工大致如下：
| 概念 | 主要解决什么问题 | 开发中的例子 |
|---|---|---|
| Rules，规则 | 哪些约定在适用范围内要一直遵守？ | 未经授权，不提交代码；接口报错不能伪装成成功 |
| Skill，技能 | 遇到这一类任务，按什么方法做？ | 处理设计稿图片、排查页面问题、整理交付报告 |
| MCP | 怎样以统一协议接入外部工具和数据？ | 读取浏览器、设计稿、文档服务 |
| Workflow，工作流 | 先做什么，后做什么，什么条件下暂停？ | 先给样帧，得到确认后才能渲染全片 |
| Memory，记忆 | 哪些旧信息值得保存，在以后找回来？ | 用户偏好、已确认的决策、某个环境的特殊限制 |
各家产品的命名还会重叠。一个 Skill 可以包含 Workflow，某个客户端也可能把规则文件放在“Memory”菜单里。判断它做什么，得看加载时机、维护方式和执行行为，光认菜单名容易认错亲戚。
后面提到的 Agent，就是能读写文件、调用工具的 AI 助手；宿主指运行它的客户端。
一、先从处理设计稿图片说起
我做小程序开发时，经常要从 Figma 导出素材，压缩 PNG，上传腾讯云 COS，复制地址，再放回代码。页面还没开始写，我已经先给图片当起了快递员。
遇上一个页面有好几张图，就得把这套操作重复好几遍。后来我把它做成了 image-auto-upload Skill，带两个脚本，一个压缩 PNG，一个上传 COS，再把素材处理接到页面开发里。
当时我用 Figma MCP 读取设计稿。图片怎样压缩、传到哪里、怎样返回链接，由 Skill 说明；先确认素材清单再上传，是这项任务的 Workflow。密钥不能出现在代码和日志里，则适合留在长期规则中。
实际调用压缩服务和 COS SDK 的是脚本。AI 判断当前任务需要走哪些步骤，通过宿主工具运行它们。
如果已有脚本能完成任务，Agent 也能运行命令，就可以先这么用。没必要为了把配置凑齐，再给每个脚本套一层 MCP。图片还没传上去，先多维护一个服务，这笔账不太划算。
旧文采用了上传成功后清理源图的做法。现在给新手设计类似流程，我会先保留源文件，核验远端结果后，再按约定清理。密钥即使放进不提交的环境文件，也要防着日志、截图和工具输出把它带出去。
二、Rules：把反复纠正的事写下来
如果刚开始用 AI 编程，我会先写几条规则。
“不要顺手把其他问题也改了”“工作区原来的修改，别算成你这轮做的”“测试没跑，就写没跑”，这些要求可能已经说过很多次。只想补个按钮时，我通常不期待收到一份顺便重构半个仓库的惊喜。
这类要求适合放进长期指令文件。Claude Code 常见的是 CLAUDE.md，Codex 和 Pi 常见的是 AGENTS.md。客户端决定文件怎么发现、在哪个范围加载。
项目里可以先写这么几条：
# 项目协作约定
- 修改前先检查工作区，保留与当前任务无关的改动。
- 沿用项目现有组件和依赖；新增依赖前说明原因。
- 接口失败必须保留错误信息，不用空数据冒充成功。
- 修改后运行相关检查，并记录通过、失败和未运行项。
- 没有明确授权，不暂存、提交、推送代码。
每条都能对应到一次具体行为。出了问题，也方便检查是哪条没被遵守。我更愿意写这些，至于要不要先授予 AI 一个“世界顶级工程师”的头衔，可以缓缓。
别让所有规范都跟着每个任务上班
个人所有项目都适用的偏好，放用户级；团队共享的构建命令和目录约定，放项目级；只管接口目录的规范，就尽量限定到那个范围。
例如，Claude Code 可以把路径规则放在 .claude/rules/api.md：
---
paths:
- "src/api/**/*.ts"
---
修改接口调用时，沿用现有请求封装。
不要在页面组件里重复拼接服务端地址。
这是 Claude Code 的具体语法，换到其他工具要另查支持方式。
拆成多个文件，也要检查它们怎样加载。主文件如果把所有规范都直接引入，模型每次照样可能读一大堆。想减少无关上下文，需要配合客户端支持的路径范围或按需读取机制，不能只给文件搬个家。
规则用久了也得清理。项目从 npm 换成 pnpm，旧命令就该更新；临时排障加的限制，结束后再看看还要不要留。
对于确实不能允许的动作，Markdown 里的“禁止”只是一条指令。权限、沙箱、命令检查和 CI 可以在相应环节拦截，具体能拦到哪儿，需要核实。文件里把“严禁”写三遍，也不会自动多出一道门禁。
三、Skill：这类活，下次照这份做
拿不准 Skill 怎么写时，我会先用 skill-designer 整理结构。它帮助梳理适用场景、入口说明和参考资料的分工。在 cc，pi、codex等agent 中，可以这样提要求：
/skill-designer
帮我把“排查页面问题”整理成一个 Skill。
先确认适用场景和输入，区分只读分析与修改代码。
列出连接失败时的处理方式，以及交付前的检查点。
说明哪些内容放入口，哪些拆成参考文档，哪些适合写成脚本。
这是我自己使用的 Skill，要先安装到客户端能发现的位置。不同工具的调用语法也不一样，后面有对照。
草稿出来以后，仍要拿真实任务试。看看会不会误触发、漏步骤，失败后能不能如实停下。目录看着整齐，和实际干活靠谱，还得分别检查。
哪些任务值得做成 Skill？
同一套要求开始反复粘贴，或者一次返工留下了可复用的方法，我就会考虑做成 Skill。下次再做，至少不用先去聊天记录里考古。
图片上传、代码审查、排查某类接口问题，都可以整理。先把任务入口和完成标准想清楚，再决定需要哪些文件。
常见目录是这样：
page-check/
├── SKILL.md
├── references/
│ └── checklist.md
└── scripts/
└── check-output.mjs
SKILL.md 说明什么时候用、按什么步骤做。详细检查项可以放进 references，稳定重复的计算和校验交给脚本。没有脚本也能做 Skill，不必为了让目录显得专业，先建一排空文件夹。
第一份 Skill，写清触发条件和交付物就很好
这是一个简化的页面排查示例，用来展示写法，尚不是验证过的通用排障工具：
---
name: page-check
description: 排查运行中的页面显示和交互问题。适用于用户要求复现页面故障；仅阅读代码时不使用。
---
1. 确认目标页面、运行环境和用户看到的异常。
2. 阅读项目的启动与验证说明，再打开实际页面。
3. 记录复现步骤，检查相关 DOM、控制台和网络请求。
4. 对照代码定位原因。没有修改授权时，只给分析结论。
5. 获得修改授权后修复，并按原步骤复测。
6. 交付原因、改动范围、验证结果和未验证项。
浏览器连接失败时，说明阻塞；不要把代码推断写成现场复现。
详细检查项见 references/checklist.md，进入页面检查时再读取。
它说明了该做什么，也说明了连接失败、没有修改授权时怎么处理。
描述里最好写上适用和不适用的情况。“优化开发体验”太宽，模型很难决定什么时候该用。范围一大，问个命令都可能被拖去做全套体检。
“渐进式披露”，就是用到哪儿读到哪儿
在我用的 Pi-Bolt 中，模型先看到 Skill 的名称、描述和路径，决定使用后再读取正文。正文可以指引它，到某一步再读相应的详细资料。
Codex、Claude Code 也采用按需加载的思路，具体字段、发现规则和上下文预算有所不同。
我之前做微缩动画 Skill，就把画风、参考图处理、运动检查、音频和导出分开。设计场景时不用读整份编码说明，到了正式出片再读。
在关于 Skill 与 Prompt、新街口微缩动画的那篇文章里，我写过一句：“拆文件还不够，入口得写清楚读取时机。”
至于“Skill 到底是不是 Prompt”，正文当然还是给模型看的指令。我保存的是这类任务的说明、资料、模板和脚本，以及何时读取它们。换个文件名，模型不会多长一个脑子。
四、MCP：需要外部接入时，再来配它
MCP 的全称是 Model Context Protocol，可以先理解成客户端连接工具和数据服务的一套协议。浏览器服务可以提供读取页面、检查请求的能力，文档服务提供搜索和阅读，设计工具服务则提供设计稿信息。
连接成功以后，排查方法、目标环境、登录状态和权限仍需确认。浏览器工具能打开页面，接下来该复现问题、查请求还是对照代码，还得有一套做法。
什么时候值得装
希望 AI 直接检查运行中的页面、读取设计稿、查询文档服务时，可以看看有没有成熟的 MCP 接入。
如果只是读本地文件、运行测试、处理几张图片，而客户端已经能读文件和运行命令，就先用现成能力。CLI、SDK、HTTP API 都可能满足需求。
我用 Tauri 开发的这个桌面应用，就有个容易踩的坑：通过 MCP 桥接检查实际界面时，开发版必须带 dev-mcp 特性启动。普通开发命令也能把应用打开，桥接能力却没编进去。看着窗口好好的，连接就是不通，挺适合让人怀疑人生。
这种启动要求适合写进项目 Skill，让后续验证先读说明。
先连一个只读服务，实际查一次
例如，Codex 可以在 ~/.codex/config.toml 中配置官方文档 MCP：
[mcp_servers.openaiDeveloperDocs]
url = "https://developers.openai.com/mcp"
配置后检查连接状态，再让它查一条文档，核对返回内容和来源。这个官方只读文档服务，不会因此得到你的数据库或云账户权限。
Claude Code、Pi 的格式和位置不同，要按各自文档配置，别把 TOML 原样粘进 JSON。
有些 MCP 通过远程网址连接，有些需要在本地启动服务程序，通过标准输入输出通信，常称为 stdio。后者可能依赖 Node、Python 等环境，还要处理服务端安装和文件访问授权。
列表里出现名字后，继续检查客户端是否读到了配置、服务是否连上、需要的工具能否调用，以及调用结果是不是来自正确的环境。能读公开页面，不代表能进登录后的后台；能查测试库，也不代表该给生产库写权限。
浏览器尤其要看清它连的是哪个窗口和会话。我习惯复用可见浏览器，方便确认环境。会不会另起浏览器、支持哪种连接方式，则取决于具体服务。
Chrome DevTools MCP：查网页时，别把我挤下线
我之前遇到过，新开一个 AI 会话，Chrome 就弹连接授权；让 AI 打开网页，它又切走我正在看的标签页。换成独立浏览器，登录态却分开了。原本想让它帮忙查个页面，结果我还得先给它安排座位。
当时的完整配置和脚本在：《chrome-devtools-mcp 总弹授权、抢标签页？我是这样一步步配好的》。
那次是 macOS、Codex CLI 和官方包 1.12.0 的实践，分别处理了这些问题：
| 遇到的问题 | 当时的处理办法 |
|---|---|
| 独立浏览器没有日常登录态 | 用 --autoConnect 连接日常 Chrome，并开启它要求的远程调试 |
| 新会话反复建立连接、弹授权 | 通过自写适配脚本，复用官方 CLI 的常驻连接 |
| 新网页抢走当前标签页 | 适配脚本强制后台创建页面，切换工具上下文时不激活标签页 |
| 项目配置写死个人路径 | 把 Node 和启动器的个人路径放用户级配置，清理项目中的旧入口 |
--autoConnect 负责选择连接目标；自写的 quiet 启动器转发调用、复用连接，并约束后台操作。这里的 quiet 是额外适配代码，没有一个官方“quiet 开关”包办这几件事。
后台创建页面用 background: true，选择任务页面但不抢前台用 bringToFront: false。除了写规则提醒，我当时还在适配脚本里固定了这两个参数，减少漏传。
首次连接仍要用户允许。Chrome、连接或常驻进程重启后，也可能再次要求授权。客户端批准工具调用，和 Chrome 允许远程调试，是两层权限，前者不能代替后者。
配好后要另开一个 AI 会话测试：是否复用原进程，能否后台开页，原标签页是否仍选中。当前会话成功一次，还没验证到跨会话复用。日常也别每完成一个任务，就顺手把共用进程停掉。
在这套配置里，MCP 提供浏览器操作，配套 Skill 介绍用法，Rules 约束不要动用户原有标签页，适配代码处理连接复用和固定参数。启动器依赖特定包版本的内部模块，升级时需要一起核查，也不能直接套到所有系统。
服务装得多，还要考虑上下文成本。工具定义、调用结果和日志都可能占空间；部分客户端支持工具发现或延迟加载，实际开销不能只按 MCP 数量算。先留当前任务会用到的服务，连接出了问题也好找。
五、Workflow：把顺序和确认条件写明白
有的产品把可重复调用的 Markdown 步骤叫 Workflow，有的提供能保存状态、执行分支的工作流引擎。在 Skill 里组织一套步骤，也是在设计工作流。
所以，Skill 可以装下工作流：前者是能力包，后者描述执行过程。遇到具体产品，还得看它把哪些功能叫作 Workflow。
图中街景为示意，实际作品见前面引用的新街口动画回答。我制作时采用的顺序是：
阅读参考图，确认风格要求
生成同一动画的四张实际样帧
等待我确认当前版本
执行检查，再渲染全片
如果画面或剧情有改动，重新确认
“先让我看看”说得太笼统。看概念图还是实际帧？认可车辆造型，算不算批准整部片子？改了镜头以后，旧批准还有效吗？一句夸奖要是能附送整部片子的制作授权，这优惠力度未免太大。
后来我补了批准记录与版本核对，出片前由程序检查批准是否对应当前版本。Markdown 说明该遵循的顺序，代码检查在指定执行入口拒绝不符合条件的请求。
开发任务也可以这样组织：
复现问题并记录证据
确认原因和修改范围
修复并补相关测试
按原步骤复测
检查 diff，交付验证结果
确认环节放在会扩大范围、产生费用、覆盖数据或影响外部系统的步骤。改一句文案就停下来审批五次，我也受不了；能连续完成的部分，就让它连续做。
需要无人值守、固定分支或可靠重试时，可以把适合确定执行的部分交给脚本、CI 或工作流引擎，由 AI 处理需要判断的步骤。自然语言清单未必能独自承担这些要求。
六、Memory：下次别让我从头解释
隔几天换了会话，我仍希望 AI 能找到之前确认的约定：某个项目暂时不能升级依赖，某个环境只能用特定方式启动，或者先做分析，得到授权后才能修改代码。
这些信息可以保存为 Memory。稳定偏好、已确认决策和仍有效的环境限制，适合长期留着。今天读到哪个文件、某项测试还没跑，则更适合当天记录或任务进度。什么都永久收藏，最后只好在便签里翻便签。
保存以后，还得试试能不能找回来
文件叫 MEMORY.md，不意味着模型每次完整读取，更不能证明内容都正确。要看客户端加载哪些部分、有没有按需检索，新增记录多久生效，旧信息怎么修改或删除。
我在 Pi-Bolt 中用了 pi-memory 扩展，把长期记录、每天日志和待办分开保存，提供读写、检索和遗忘等工具。搜索还依赖可选的 qmd 检索工具；按意思找相近内容的语义检索，需要相应的索引和模型。这是我的扩展配置，安装 Pi 本身并不默认附带这一整套记忆。
Claude Code 有自己的 auto memory，和人工维护的 CLAUDE.md 在写入方式、用途上不同。换到 Codex，也要检查对应版本和配置支持什么。双方都能读 Markdown，离自动同步记忆还差不少事情。
在已经配置好记忆能力的客户端里，可以这样提要求：
请记住：在这个项目里，没有明确授权，不要暂存或提交代码。
请保存为项目长期约定，告诉我写到了哪里。
不要把测试账号、密钥或本轮临时日志存进长期记忆。
然后换个新会话，问它约定是什么、从哪里读到，再检查保存的文件。不能只听到一句“记住了”就放心，我自己的记性都没好到敢这么保证。
留下范围和原因，也记得清理
一条依赖限制可以这样记录：
范围：当前项目的支付依赖。
结论：暂时保持现有版本。
原因：新版本兼容性尚未验证。
重新评估：完成兼容性验证后，再确认是否升级。
这是示意，实际原因和批准人得来自真实讨论，不能让模型补个顺耳的理由。决策或环境变了，就更新、删除旧记录，否则同一个错误会跟着记忆跨会话复活。
规则和记忆也有交集。“未经授权不推送”既可以作为个人偏好被保存，也可以写进需要长期执行的规则。记忆强调保存与召回，规则强调希望它遵守什么。
操作生产环境时仍须重新核实。Memory 可以提示上次的情况，今天的环境却可能已经变了。
七、命令、脚本、Hooks，又分别管什么？
同样一个斜杠入口，换到不同工具，背后的机制也可能不同。
Pi 的 Prompt Template 可以把常用提示变成 /review。只想少粘贴一段审查提示，用模板就行；需要参考资料和完整处理方法，再考虑 Skill。
Claude Code 已把自定义 Commands 合并进 Skills 的使用体系，旧目录仍兼容。别看都长成 /名字，就直接认作同一套机制。
脚本执行固定逻辑。文件摘要、数据转换、格式校验，这类结果明确的工作，我愿意让 Agent 调用现成脚本，省得每次重新推演一遍。
Hooks 则在某个事件发生时执行配置的命令或检查，适合在指定环节提醒、拦截。某个 Hook 能覆盖哪些入口，需要结合宿主实现验证。在 Skill 里写“工具调用前检查”，不会自动生成一个 Hook；装了 Hook，也不能据此认定所有操作都被安全隔离。
插件可以打包 Skill、连接和其他资源，方便分发。Pi 扩展还能注册工具或响应事件，增加宿主能力。等手头任务需要这些能力时再用，不必提前把编辑器装修成工具展览馆。
八、换成 Pi、Codex、Claude Code，怎么落地？
常见本地入口如下。~ 是用户主目录；项目目录里的配置则对相应项目生效。加载行为仍受版本和设置影响。
| 工具 | 常见指令文件 | 常见 Skill 位置 | 显式调用例子 |
|---|---|---|---|
| Claude Code | 用户级 ~/.claude/CLAUDE.md，项目级 CLAUDE.md | 用户级 ~/.claude/skills/，项目级 .claude/skills/ | /page-check |
| Codex | 用户级 ~/.codex/AGENTS.md，项目级 AGENTS.md | 用户级 ~/.agents/skills/，项目级 .agents/skills/ | $page-check，也可从 /skills 选择 |
| Pi，我使用的是 Pi-Bolt | 用户级 ~/.pi/agent/AGENTS.md，项目级 AGENTS.md | 支持 ~/.agents/skills/、项目 .agents/skills/ 等位置 | /skill:page-check |
我本机启动的是 pi-bolt，修改 Skill 后用 /reload 刷新。上游 Pi、Pi-Bolt、不同版本以及已安装扩展会有差异，我本机能用的功能，未必全是裸 Pi 的默认配置。
Claude Code 当前也有条件支持读取 AGENTS.md，受版本、项目是否已有 CLAUDE.md 和相关设置影响。多工具共用规范时，要核对实际加载来源；需要兼容时，可以在 CLAUDE.md 中用 @AGENTS.md 引入共享内容。
尽量共用内容，接入差异分别处理
我会尽量让几家工具读同一份 Skill，把实体放在共享目录，再为需要专属入口的工具建链接，免得复制三份以后，各自长成不同的性格。建立链接前先检查已有文件，别直接覆盖。
内容仍需审查。Claude Code 特有字段、写死的工具名，换到 Codex、Pi 后未必适用。任务说明、参考资料和普通脚本相对容易共享，宿主特有行为则要适配。
我之前的《Claude Code 基础分享》整理过 Rules、Skill、MCP 和共享目录的使用经验，相关配置还要结合当前版本文档核对。
偶尔检查一下，到底读的是哪份
我自己的 Sessions Viewer 汇总了 Skill 和 MCP 配置，平时用它检查实体目录和引用关系。同一份 Skill 的多个入口，与内容已经分叉的几份副本，需要分别处理。
同名 MCP 也可能配了不同参数。图中的 token 是缓存估算的定义开销，配置状态不能证明当前会话已经连通，仍要实际调用核对。不用管理界面，直接检查文件也可以。
九、装完以后，怎么验收？
拿同一组图片做个对照：先直接给要求，再带上 Skill，看看有没有少漏步骤、结果是否更容易核对。还可以试试缺少密钥、文件已经存在、上传失败时，它能不能停在该停的位置。
正常流程能跑通以后，继续试误触发、工具断连，以及用户临时改需求。这些情况更容易把设计上的疏漏翻出来。
下载来的 Skill 要连同引用文件和脚本一起看，MCP 服务也要核对来源与权限。写着“安全”的说明书，不能替实际执行的代码担保。先在测试目录、测试账号或合适的隔离环境中试，尤其留意删除、覆盖、上传和读取凭据的动作。
我做过一个收尾报告 Skill，叫 ask-report-html。因为任务一长，我总要重新翻记录，找出改了什么、测了什么、还有什么没验，翻得比查 bug 还像在查案。
具体设计和安装方式在这篇关于
ask-report-html的实战回答。
Skill 负责内容与生成方法，规则说明何时调用，Workflow 要求到了任务交付阶段再整理。换会话继续时，保存的任务记录也能帮助恢复进度。
没有浏览器验收，就写“未运行”。HTML 文件生成成功，证明不了业务通过；报告再漂亮，也不能替没跑过的检查签字。和上传成功后才清理文件一样，完成标准必须能核对。
我会继续看重复解释和返工是否减少，失败时有没有留下足够信息，结果是否更容易验收。装了多少工具，替代不了这些判断。
十、今天就想试，可以从哪儿开始？
挑一个手头的小任务，先用现有 Agent 做。它在哪儿让你反复解释、哪一步总要人工接手，再补相应配置。
总要纠正同一条要求，就写规则；一类任务反复交代步骤，就整理 Skill。现有能力拿不到外部信息时，再接 MCP。长任务出现确认条件和失败分支，就把 Workflow 写清楚。隔一阵子回来还要重讲的已确认信息，再考虑保存到记忆。
具体可以这么做：
- 写一份简短的项目指令，只放真正经常用的约定。
- 把一个已经做过、下次还会做的任务整理成 Skill，写清适用范围和交付物。
- 如果需要外部接入，只接一个服务，核对实际返回结果。
- 给会花钱、覆盖文件或影响外部系统的步骤加确认，并测试失败时是否会停下。
- 下次换新会话，检查关键约定能否找到，发现过期信息就更新。
先做到前两步也很好。等任务需要时再加，省得本来想让 AI 帮忙写代码，最后给自己新添一份配置运维的工作。
总结
放回一次开发任务里，Rules 留下长期约定，Skill 保存这类活的做法，MCP 接入工具和数据，Workflow 交代顺序与确认条件，Memory 帮下次会话找回已确认的信息。它们可以配合，也可以只用其中一两样。
用得好不好，还是看任务有没有少漏步骤、结果能不能验收，出错时能否如实停下。先拿一个真实小任务试，比对着配置列表挨个打勾更容易看出效果。
两个 Skill 附件下载
- skill-designer 下载：帮你梳理 Skill 的适用场景、内容结构和检查点。
- 微缩动画 Skill 下载：文中新街口案例使用的技能，先看样帧，确认后再出片。
