背景

目前AI Coding的领域内有很多的词汇被拿出来讨论而且还时刻有新的名词，如Prompt，Prompt工程，Context 工程，embedding，RAG，Memory，Tools，Rules，Commands, MCP Server，Agent/Sub Agent，Modes，Hooks，Skills。很多同学对这些概念是什么，为什么，怎么用，能做什么都不太了解，本篇文章尝试按照整个AI Coding发展的脉络来系统的解释这些词语。

最基础的两个名词

LLM：大模型
Prompt：用户向大模型提供的输入信息，旨在引导模型生成符合预期的特定输出。

一个极简(核心代码100多行)的AI Coding Agent可以参考我的 github项目https://github.com/ximing/hello-ai-coding，帮助你快速理解到底大家都在做什么。

基本的AI Coding能力

早期AI Coding

我们需要对Ai Coding 的演变有一个基本的概念认识，在 AI Coding 的早期阶段，交互主要是一问一答的 Chat 模式，模型对**“首轮输入的Prompt”依赖极高，因此需要在提问时尽可能一次性注入相关信息，这时候讨论的最多的是Prompt工程，**它直接推动了 RAG 召回机制的普及。

Prompt工程 产生的原因是大模型具备“In-Context Learning（上下文学习）”的能力。Prompt 定义得越精准，模型对任务的理解就越深，产生的幻觉（Hallucination）就越少，输出的质量也就越高。

在Prompt工程 实际落地的时候，主要关注两点 ①有效的Prompt格式②必要信息；在编程领域一个有效的Prompt格式通常如下图所示；必要信息需要RAG来提供，RAG简单可以理解为一个私有知识库的搜索引擎，我们在调用模型之前，通过RAG搜索到足够准确的信息，通过高质量的Prompt组织，让LLM给出尽可能准确的数据，现在很多智能客服产品还都是这个思路。

AI Coding Prompt格式示例

Agent时期AI Coding

很明显，早期的方案局限性很大，随着模型对指令遵循(Instruction Following)以及工具使用(Tool Use)的能力越来越强，工具可以像人一样按照工具描述使用这些工具，这时候Coding Agent的概念逐渐被讨论，目前针对Agent 初步的共识 **Agent = LLM（大模型/大脑） + Planning（规划） + Memory（记忆） + Tools（工具使用），**此时“Context 工程” 也被频繁的提及

所谓的Context 就是Agent 多轮次对话的消息内容，是一个大数组

所以在提出Agent的概念的时候Tools/MCP就登场了。在Coding Agent的场景下，人与AI的协作模式发生了根本变化：交互从单轮对话转向多轮、长期的 Agent Loop。此时，相关信息不再需要在第一轮全部给出，而是由 Agent 在执行过程中按需检索与召回。这一变化催生了 LSP 与 grep 等能力的逐步登场。其中，Cline 和 Claude Code 在25年就从传统的 RAG 转向 grep，Cline 宣传“不能再用 2023 年的办法解决今天的问题”。这个演进的背后的核心推动力是LLM大脑已经足够强了。

Context的组成

Tools/MCP Server

Tools 赋予了 Agent可以探索外部环境的能力，Tools 通常是各类AI IDE/CLI 在提供Agent的时候内置的一系列的工具(如操作文件，搜索等)，但场景的复杂始终存在，大家有了需要自定义工具的诉求，因此Anthropic定义了MCP标准，目前大部分工具都支持了这套标准，它由 名称，功能描述，入参描述和可执行代码组成，其中名称，功能描述，入参描述 需要提前传给模型(这也带来Context体积膨胀的问题)。

简单的一个MCP示例

Rules

通过MCP，模型初步具备了影响现实世界的能力，它可以自由的查看并修改我们的代码，这带来很大的风险，所以我们通常会在Prompt中前置写很多工程规范的限制，但是每次输入都很麻烦，所以各类的AI IDE 都提供一个机制让模型可以按照一定策略自动获得这些知识，这就是Rules

一个实际的Rule例子

至此，基础的一个AI 编程工具所需要的能力就已经完成了

Context 工程新的挑战与应对

**挑战1：**当LLM提供的Context不够大的时候，随着前置的信息塞入的过多，导致留给用户和模型推理的空间就很小了，可能在几轮之后，就没有足够的Context可以使用

**挑战2：**随着LLM支持了更大的Context支持，LLM Loop 会不断地获取它觉得有必要的信息，随着LLM获取的信息增多，没有带来正向的效果，大家发现大Context存在几个很大的问题：

“Lost in the Middle” 现象（注意力衰减）：上下文变得非常长时，模型往往倾向于关注开头（Priming effect）和结尾（Recency effect）的信息，而忽略中间部分的信息。如果关键答案藏在文档的中间段落，模型很可能回答“由于缺少信息，无法回答”或者产生幻觉。
信噪比（Signal-to-Noise Ratio）与干扰：无关文本会分散模型的 Attention 权重，导致推理能力下降。
格式指令的遵循稳定性：在长 Context 中，System Prompt 定义的“规则”（如：必须输出 JSON，不要废话）很容易被后文大量的检索内容冲淡（Dilution）。
模型本身成本与性能问题：Transformer 架构的推理成本与 Context 长度通常呈线性甚至近乎二次方（取决于 Attention 实现）增长。

随着实践中这两个挑战的出现，大家意识到必须对Context进行有效的控制，这时 Context Engineering 概念应运而生，Context Engineering是指通过系统化的方法，对输入给大模型（LLM）的上下文信息（Context）进行筛选、组织、压缩和优化，以确保模型在有限的“上下文窗口（Context Window）”内，能够获取最相关、最准确的信息，从而生成高质量的回答。它不仅仅是写一句话，而是涉及数据流的系统处理：

信息检索与筛选 (Retrieval)：从海量数据中找到与当前问题最相关的内容。
信息剪枝与压缩 (Pruning & Compression)：去除无关的噪音数据，或者将长文本摘要化，节省 Token。
信息排序 (Ordering)：解决模型“首尾关注度高、中间关注度低”的问题，将最关键的信息放在模型最容易注意到的位置。
格式化 (Formatting)：将非结构化数据转化为模型易读的格式（如 JSON、XML 或 Markdown 表格）。

Context Condensation(上下文压缩)

Rules

首先被下手的就是Rules，现代AI 编辑器都支持多种加载策略，比如catpaw 支持四种形式的Rules加载策略，通过2,3,4的方式可以让模型按需或先加载必要的信息的方式来减少Context的Dilution问题(本质是用时间换空间，模型要多调用一次文件的读工具才能获取到它想要的信息)

Always: 始终加载
Auto Attached: 根据 globs 策略自动加载，如处理 *.ts 时加载
Manual: 手动加载
Model Request: 先加载rule的 description，模型根据description和当前Context的信息自行决策是否加载剩下的内容

Skills

为什么有Skills

前文提到过AI IDE加载MCP的时候会将它的名称，功能描述，入参描述 一开始就传给LLM，随着我们使用的MCP功能越来越多，会带来爆炸的Context，哪怕很多时候这个任务都不会用到这些mcp，但是我们必须也要将其全部放到Context中。为了解决这个问题Anthropic提出了Skill的概念

上面说的是从Context优化视角，从另一个视角看，Skill相比MCP的好处是显著的降低了非专业研发用户拓展Agent能力的门槛，它将相对复杂的 MCP 定制过程简化为写文档，让 AI 能真正低成本的进入日常标准化的工作中

chrome devtools 一个MCP就有 26个工具

Skill是什么

Skills 是一套基于文件系统的 Prompt 工程化规范。一个Skill最核心的是 SKILL.md 这个文件，他由两部分组成，头部的元数据以及正文内容，IDE会在首次加载时候只加载元数据内容，然后当模型判断需要的时候，再加载剩余内容，通过这种方式解决了Tool Overload导致的MCP Context爆炸的问题。Skill的推出也是模型能力的进步所带来的，本质上也还是通过时间换空间。(细心的同学应该可以看到，Skill 的 SKILL.md文件其实就是一个 Model request 类型的 rule，它的 description 定义了模型应该何时使用这个 Skill)

一个Skill.md的示例

一个标准的Skill的组成

和MCP有什么区别

在AI Coding领域下其实没有太大的区别，一个Skill能做的事情使用Rules+MCP或者使用Command也是可以做到的(Skill.md其实就是一个 Model request 类型的 rule，它的 description 定义了模型应该何时使用这个 Skill)。

同时AI的工程工具也可以给MCP提供类似的动态加载的机制，使MCP可以达到类似Skill动态加载的效果，据我所了解Catpaw 团队内部在做类似的尝试(1月10日灰度的Catpaw也支持了Skills)。所以Skill其实不会对AI Coding带来质提升；但是另一方面SKill最大的好处是降低了普通用户的准入门槛，用户可以简单的通过自然语言实现一个 skill.md文档，用以约束模型去使用不同的工具(甚至工具也可以让模型来开发)，但是同样要承受模型注意力衰减后没办法按照skill.md的要求执行脚本的问题。相比较而言MCP的开发流程就更复杂一些。

能做什么

玩法很多样化了，Skill市场https://skillsmp.com/zh中有上千个skill；Claude 官方维护https://github.com/anthropics/skills也有很多

普通的用户也可以用来做一些有实感的事情：话题分享对AI帮我干活有了实感，旅行攻略Agent分享（Claude skills应用实例）

Context压缩的其他的策略

上面的压缩办法都是IDE优化工具的加载方式进行压缩，实际上还有很多其他的通用手段进行，这里列出来一部分如下：

分类	方法	说明
基于规则的压缩 (Rule-Based Compression)	滑动窗口 (Sliding Window / FIFO)	原理：保留最新的 NN 个 Token，丢弃最早的 Token。适用：多轮对话（Chatbot）。通常假设最近的对话最相关。缺点：容易丢失早期的关键指令或长期记忆（例如用户刚开始设定的角色）。
	选择性保留 (Selective Preservation)	原理：在滑动窗口的基础上，强制保留特定的部分。通常保留 System Prompt（系统指令）和 First User Query（首个用户问题），只对中间的历史记录进行滑动删除。好处：保证模型不忘初心（Role 不会丢失）。
	停用词/符号过滤 (Stop-word/Symbol Removal)	原理：删除不影响语义的词汇（如 “the”, “a”, “is” 等）或多余的换行符、标点。效果：压缩率较低（约 10-20%），但几乎无损。
基于语义的压缩 (Semantic-Based Compression)	关键信息提取 (Key Information Extraction / Entity Extraction)	原理：利用 NLP 工具（如 spaCy, BERT）提取文本中的命名实体（人名、地名、时间）和关键词，只保留包含这些实体的句子。适用：处理新闻、 factual 资料。
	语义聚类与去重 (Semantic Clustering & Deduplication)	原理：如果上下文中有许多重复表达的段落，利用 Embedding（向量化）计算相似度，删除语义高度重复的片段。
	向量检索筛选 (RAG-style Filtering)	原理：这是 RAG 的一部分，但也可以用于长对话压缩。 1. 将历史对话切片并存入向量数据库。 2. 当用户提问时，只检索与当前问题向量相似度最高的几段历史记录放入 Context。优点：可以处理无限长的历史记录，只提取相关部分。
基于模型的压缩 (Model-Based Compression)	摘要 (Summarization)	原理：每隔几轮对话，调用一个（通常较便宜的）LLM，将之前的长对话总结成一段简短的摘要（Summary）。 - 原始：用户和AI来回说了20句关于买苹果的细节。 - 压缩后：[摘要：用户想买5斤红富士苹果，预算50元。] 进阶：递归摘要 (Recursive Summarization)。对长文档分段摘要，再对摘要进行摘要。缺点：细节丢失较多，难以找回具体某个数值。
	LLMLingua (Prompt 压缩专用技术)	原理：由微软提出。使用一个小模型（如 Llama-2-7b）来计算 Prompt 中每个 Token 的困惑度 (Perplexity)。逻辑：困惑度低的 Token 意味着它是“可预测的废话”，困惑度高的 Token 包含主要信息。算法会删除低困惑度的 Token。效果：可以在保留语义的情况下实现 5x - 20x 的压缩率。
	Chain-of-Thought (CoT) 压缩	原理：在大模型进行推理时，CoT 会产生大量的中间步骤。压缩策略是只保留 CoT 的关键转折点，或者在存储记忆时，只存储最终结论，丢弃推理过程。

Context Branching(上下文分支) - Sub Agent

为什么有 Sub Agent

Sub Agent（子智能体架构） 就是典型的Context Branching策略，它采用了“分而治之”（Divide and Conquer）办法将专业的事情交给专业的Agent去完成。这种架构的出现是为了解决单个大模型（LLM）在面对复杂真实场景时的局限性：

上下文污染（Context Pollution）：如果把所有工具的定义、所有业务规则都塞进一个 Context，模型会“注意力分散”。不同任务的规则可能相互冲突。
Prompt 的复杂性维护：一个几千行的 Prompt 极难维护和调试。
工具数量限制：大模型通常对单次调用能挂载的 Function Calling/Tools 数量有限制（例如 OpenAI 建议不超过一定数量），太多工具会导致模型选错。

Sub Agent 是什么

在这个架构中，不再由一个单独的“超级全能 Prompt”来处理所有用户请求，而是设立一个主智能体（Master Agent / Orchestrator） 负责调度，将任务拆解并分发给多个子智能体（Sub Agents / Workers） 执行。

Sub Agent示意图

Sub Agent 架构的好处 (Pros)

**专精化与准确率提升：**负责 SQL 查询的 Sub Agent，其 Prompt 可以包含极尽详细的数据库 Schema 和 SQL 优化规则，而不需要知道如何写诗
**上下文窗口利用率优化：**每个子智能体拥有独立的上下文窗口（Context Window）。这意味着你可以在不超出 Token 限制的情况下，为每个特定任务加载大量的特定知识库。
**模块化与可维护性：**开发人员可以独立测试和优化某个子智能体。如果“写代码”的功能坏了，你只需要调试 Coding Sub Agent，而不会影响到负责“架构设计”的部分。、
**成本控制：**简单任务可以使用较便宜、较快的小模型（如 GPT-3.5-Turbo, Llama-3-8B），只有在遇到高难度任务时，才调用昂贵的子智能体（如 GPT-4, Claude 3 Opus）

Sub Agent 架构的坏处 (Cons)

**延迟增加 (Latency)：**这是最显著的缺点，你完成一个很简单的编码任务可能有几个Agent先开个会
信息传递损耗：主智能体在向子智能体传达任务时，可能会丢失用户的某些隐含意图；子智能体返回结果给主智能体时，如果仅仅返回最终答案而没有中间过程，主智能体可能无法很好地向用户解释。
**编排复杂性 (Orchestration Complexity)：**如果子智能体之间需要交互（例如：子智能体 A 的输出是子智能体 B 的输入），系统的复杂度会指数级上升。容易出现死循环或状态不同步的问题。
**累积误差：**如果主智能体（Router）一开始就判断错了意图（例如把“写个 Python 爬虫教程”分配给了“写作子智能体”而不是“编程子智能体”），那么后面子智能体做得再好也是错的。

怎么体验

工程手段提升确定性

Hooks

catpaw 有一个内部试用版，还没到灰度阶段；Cursor 和 Claude Code目前均有提供

为什么有Hooks

之前提到的Agent loop 的过程中，加入一些生命周期的回调，通过工程的手段提供确定性控制，确保一定会执行，而不是依赖 LLM 选择运行它们(会有注意力衰减或者幻觉问题)

Hooks是什么

Hooks 是用户定义的 shell 命令，允许你通过自定义脚本来观察、控制和扩展 agent 循环。它们在 agent 循环中定义的各阶段之前或之后运行，可以观察、阻止或修改行为。借助 Hooks，你可以：

在编辑后运行代码格式化工具
为高风险操作加上门控（例如 SQL 写入）

Hooks怎么用

就是一个json文件，放到 ./cursor/hooks 下即可

简单的实例

提升用户体验

Modes(Deprecated)

最开始的设计目的是希望让用户自己指定System Prompt和可使用的工具(MCP)组合进而完成专用的工作流，比如Cursor 内置支持 Agent Mode，Plan Mode，Ask Mode等

不过在新的演进中，大家陆续都废弃了这个路线，cursor推荐使用 command来实现同样的功能，catpaw 中将mode这个功能转为了 subAgent的一部分

Commands

为什么有Commands

提供给用户一个可以主动触发Prompt的机制，便于好的Prompt在团队内部共享使用。

这个能力不是必须的，更大程度上是为了方便人去使用AI IDE而存在的，你可以使用Rule或者文件直接来达成这个效果

Commands是什么

就是一段markdown文档，里面详细告诉大模型应该需要去做什么。

我用 commit 代码的命令

和 Rules 和 MCP的关系

和 Manual 的Rules 没有区别，比如下面在 catpaw中，没有支持 Commands之前，我可以使用 @ 唤起Rules 进行文档生成，支持command后，我使用 / 唤起命令进行文档生成。(你甚至可以在项目中随便使用一个目录，然后放一个md文档通过@ 操作符引用即可)

Command	Rules

MCP其实也可以对外暴露出命令供用户主动触发

一个简单的示例

和Skills的关系

核心维度	Command	Skills
功能定位	轻量级 Prompt 封装用于快速执行单一、明确的任务。	复合型能力编排用于处理需要多步骤推理或调用外部工具的复杂逻辑。
触发机制	显式被动调用必须通过输入 `/` 前缀（如 `/fix`）手动触发。	智能隐式路由模型根据上下文意图，自动判断并按需调用（Function Calling）。
物理结构	单文件定义通常仅需一个 `.md` 文件即可定义。	工程化目录结构以目录形式存在，包含入口文件 (`SKILL.md`) 及配套资源。
组成要素	纯文本/模板主要由自然语言提示词构成。	混合资源集合包含提示词、执行脚本、代码模板或数据文件等。
版本管理	Git 协同作为代码库的一部分进行提交和共享。	Git 协同作为代码库的一部分进行提交和共享。

Commands能做什么

快速、经常使用的Prompt，示例：

**/review** → “Review this code for bugs and suggest improvements”
**/commit** → “use git commit this code ”
**/explain** → “Explain this code in simple terms”
**/optimize** → “Analyze this code for performance issues”

继续深入- Memory管理

上面讲的都是在控制 Context 大小，就是瞬时记忆，RAG被认为是持久记忆的一种都属于Memory管理。感兴趣的同学可以继续阅读 https://arxiv.org/abs/2512.13564 这个论文，讲的挺细致的，就是很长，可以看下我写的✅ 如何阅读科学文献快速找重点

这些东西实际开发中怎么用

我们在做Vue2转React的架构演进，我们以一个React Web项目为例讲解一下

常用的一些prompt可以抽象为command如

command

代码提交

样式还原

可以使用review 命令，将当前对话中人工介入的环节沉淀为Rules

Modes

在 [实践]AI研发助手-MRN开发实操需求中，我们添加了很多 mode，其实就是 Sub Agent 帮我们完成不同场景下的任务。新的Catpaw上可以使用 Sub Agent的方式，当设计到界面代码开发的时候，切换到子Agent，使用Gemini模型进行还原，逻辑还是使用Claude

Rules/Skills

项目中的各类规范，目录规范等

MCP

"mastergo-magic-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@mastergo/magic-mcp",
        "--token=xxxx",
      ],
      "env": {
        "NPM_CONFIG_REGISTRY": "https://registry.npmjs.org/"
      }
    }
"context7": {
      "command": "npx",
      "args": [
        "-y",
        "@upstash/context7-mcp"
      ]
    }
"chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest"]
    }

// 终端文档合集
    "ai-doc-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@osgfe/ai-doc-mcp",
        "--project-keys=osg-fe-web-api,keeta-design-pc,osg-fe-web-utils"
      ],
      "env": {
        "RERANK_SCORE_THRESHOLD": "0.87"
      }
    },

开发模式探讨

看了下云图中自己代码变更量22年28W行，23年30W行，24年64W行，今年25年有70W行。28W行上下是我这几年带架构团队正常的代码产出基线。24年我在管理一个后端团队的同时还有64W的代码量，绝对离不开AI的帮助(当时还是Copilot，需要人写AI辅助)。而在今年我几乎很少亲手编写代码(思考怎么让Agent自主完成项目)，从CatPaw的数据看，今年实际AI帮我写了至少有100W代码，采纳了89.9W行。我在工位上常年同时开两个电脑，调度着三到四个 AI coding agent ，不分昼夜的帮我干活。甚至还玩笑的提了一个“无人工时”的指标。从我自己的视角上来看AI绝对已经很出色了。

从团队大多数人的视角看则不尽然，很多同学使用下来的反馈是：幻觉多，写代码太多没办法Review，只能胜任一些小的具体的模块开发，特别大的项目无法完成，这明显有较大的Gap。我觉得可能是因为AI更吃架构经验和对AI底层工作原理的理解，这些都是需要提前学习的，就像学习一门编程语言一样。只不过现在AI Coding模糊度太高还没有一个特别具象化的培训路线图。同时目前我们私有的组件都没有成熟的MCP能力。

从软件工程体系的迭代看，0-1指令到汇编语言，再到高级编程语言，都是逐步让程序更容易让人理解，从这个角度自然语言编程明显比高级编程语言更有优势。但是当前阶段，我们最终沉淀的还是代码，代码是我们重要的资产，但AI时代还是这样么？现在的Prompt，Rules，Skills等还是围绕怎么产出准确可控的代码，我从直觉上来讲觉得可能会有更底层的变革，从能力表象上来说，目前的AI编程还达不到汇编语言到高级编程语言的一跃。

Spec Coding它的编程范式很直接，不要再给 AI 模糊的指令，而是先写好“技术规格说明书”。把SOLID 原则、TDD、DDD 这些软件工程经验写入Spec，定义好 Interface 和 Schema，把架构信息喂给 AI。这样开发者就从“代码编写者”变成了“架构师”和“审查者”。但Agent最终生成的结果很大程度上依赖了其遵循的spec文档，所以需要很重视spec文档的规范性和全面性，久而久之会发现在做一件很诡异的事：写文档的时间比写代码还多。这套流程相当于把 AI 的认知负担转嫁给了人类**。**更直接的例子是它能帮新手快速执行明确的指令，但它无法替资深开发者做架构决策。

Spec Coding目前有三种流派

OpenSpec 必须先生成一份标准化的 Markdown 规格文件，像签法律合同一样锁定所有接口、数据结构和业务逻辑。
1. 优势在于确定性高。特别适合老系统重构，因为你可以清晰对比“当前实现”与“规格要求”的差异。它是对抗 AI “胡编乱造”的最强盾牌。
2. 劣势是你要花大量时间去审查一份复杂的技术文档，而不是享受 AI 带来的便利。
SpecKit 通过 /plan、/tasks 等指令，强制 AI 严格遵循“需求分析 -> 计划拆解 -> 任务执行”的流水线，禁止跳步。
1. 优势是让 AI 每次只做一件小事，成功率很高。
2. 问题是它太僵化了。本来两句话能解决的小功能，SpecKit 非要逼你走完一整套流程仪式。
BMAD 的思路是模拟敏捷开发团队，引入了 PM，RD，QA等多种角色。优势是“上下文分治”。通过角色分工，解决了单体 AI 记不住大规模项目细节的问题。但它带来了“赛博官僚主义”。为了修一个简单的 Bug，你可能需要等待 5 个 AI 开个会。

Everett Rogers 的创新扩散理论提到，任何新技术都会经历五个阶段：创新者（2.5%）、早期采纳者（13.5%）、早期大众（34%）、晚期大众（34%）、落后者（16%）。关键转折点在于从“早期采纳者”到“早期大众”的鸿沟。而AI Conding目前就在这个阶段。我觉得按照目前的进展来说，或许26年就有更好用方案 SDD会被完全推翻，我们目前做的一系列沉淀可能都是镜中花水中月也说不定，还需要不断地探索。

备注

本文图片使用 Nano Banana Pro 生成
代码里图片使用 https://carbon.now.sh/ 生成

背景

基本的AI Coding能力

早期AI Coding

Agent时期AI Coding

Context的组成

Tools/MCP Server

Rules

Context 工程新的挑战与应对

Context Condensation(上下文压缩)

Rules

Skills

为什么有Skills

Skill是什么

和MCP有什么区别

能做什么

Context压缩的其他的策略

Context Branching(上下文分支) - Sub Agent

为什么有 Sub Agent

Sub Agent 是什么

Sub Agent 架构的好处 (Pros)

Sub Agent 架构的坏处 (Cons)

怎么体验

工程手段提升确定性

Hooks

为什么有Hooks

Hooks是什么

Hooks怎么用

提升用户体验

Modes(Deprecated)

Commands

为什么有Commands

Commands是什么

和 Rules 和 MCP的关系

和Skills的关系

Commands能做什么

继续深入- Memory管理

这些东西实际开发中怎么用

command

Modes

Rules/Skills

MCP

开发模式探讨

备注

评论与讨论