背景

AI Coding 领域常见的术语包括 Prompt、Prompt 工程、Context 工程、Embedding、RAG、Memory、Tools、Rules、Commands、MCP Server、Agent/Sub Agent、Modes、Hooks 和 Skills。本文按 AI Coding 的演进脉络说明这些术语所处理的问题及其使用方式。

基础概念：

1. LLM：大模型。
2. Prompt：用户提供给大模型的输入信息，用于引导模型生成特定输出。

一个极简的 AI Coding Agent 可参考我的 GitHub 项目https://github.com/ximing/hello-ai-coding，用于了解基本实现包含哪些部分。

基本的 AI Coding 能力

早期 AI Coding：Prompt 与 RAG

AI Coding 的早期交互主要是单轮或短轮次的 Chat 模式。模型高度依赖首轮输入的 Prompt，因此提问时需要尽量一次性提供任务相关的信息。Prompt 工程和 RAG 召回机制因此受到关注。

Prompt 工程依赖大模型的 **In-Context Learning（上下文学习）**能力。Prompt 是否清楚、信息是否完整，会影响模型对任务的处理，并可能影响幻觉（Hallucination）和输出质量。

在编程场景中，Prompt 工程通常处理两部分内容：有效的 Prompt 格式和必要信息。下图展示了一种 Prompt 格式。必要信息可由 RAG 提供：在调用模型前，从私有知识库检索相关内容，再用 Prompt 组织检索结果，使 LLM 基于这些信息生成结果。许多智能客服产品采用类似流程。

AI Coding Prompt 格式示例

Agent 阶段的 AI Coding：多轮执行与 Context

随着模型的指令遵循和工具使用能力提升，Coding Agent 成为常用概念。它通常由 LLM、任务规划、记忆或状态管理、工具调用组成，但不存在唯一且严格的定义。Context 工程也在这一阶段被频繁讨论。

Context 是 Agent 多轮对话中的消息内容，通常以数组形式保存。

在 Coding Agent 场景中，人与 AI 的协作从单轮对话扩展到多轮 Agent Loop。相关信息不必在第一轮全部提供，Agent 可以在执行过程中按需读取文件、搜索内容和调用工具。LSP、grep 等能力因此常用于 Coding Agent。grep 适合搜索代码库中的文本和符号，RAG 适合从外部文档或知识库检索语义相关内容；两者的使用场景不同，不能简单描述为从 RAG 转向 grep。这一变化与模型的指令遵循和工具使用能力提升有关。

Context 的组成

Tools 与 MCP Server

Tools 使 Agent 能够读取和操作外部环境。AI IDE 或 CLI 通常内置文件操作、搜索等工具。复杂场景需要自定义工具，Anthropic 为此定义了 MCP 标准。一个 MCP 工具由名称、功能描述、入参描述和可执行代码组成；名称、功能描述和入参描述需要预先提供给模型，因此工具数量增加会扩大 Context。

简单的 MCP 示例

Rules

MCP 允许模型查看和修改代码，也可能执行影响外部系统的操作，因此需要工程规范和操作限制。将这些限制写入每次 Prompt 会增加重复输入成本，各类 AI IDE 因而提供按策略自动加载工程规范的机制，即 Rules。

一个实际的 Rule 示例

上述 LLM、Context、Tools 和 Rules 组成了基础 AI 编程工具的常见能力。

Context 工程：上下文控制方法

当 LLM 的 Context Window 较小时，前置输入占用的 Token 会减少用户输入和模型推理可用的空间，数轮交互后可能无法继续加入必要信息。

更大的 Context Window 也不能自动改善结果。Agent Loop 会持续读取它判断为必要的信息，过长的 Context 可能产生以下问题：

1. “Lost in the Middle” 现象（注意力衰减）：上下文很长时，模型往往更关注开头（Priming effect）和结尾（Recency effect）的信息，而较少利用中间部分。关键答案位于文档中段时，模型可能回答“由于缺少信息，无法回答”或产生幻觉。
2. 信噪比（Signal-to-Noise Ratio）与干扰：无关文本会分散模型的 Attention 权重，影响推理结果。
3. 格式指令的遵循稳定性：在长 Context 中，System Prompt 定义的规则，例如必须输出 JSON、不要输出无关内容，可能被后续大量检索内容削弱（Dilution）。
4. 模型成本与性能：Transformer 推理的计算和显存成本受输入长度影响。自注意力部分的计算量通常随序列长度呈平方级增长，具体成本还取决于模型结构、KV Cache 和注意力实现。生成阶段还需要区分读取输入的 prefill 和逐 token 生成的 decode，两者的瓶颈不完全相同。

Context Engineering 指通过筛选、组织、压缩和优化输入给 LLM 的上下文信息，使模型在有限的 Context Window 内获得任务相关的信息。它处理的是输入数据流，通常包括：

1. 信息检索与筛选（Retrieval）：从数据中找到与当前问题相关的内容。
2. 信息剪枝与压缩（Pruning & Compression）：删除无关内容，或将长文本摘要化以减少 Token 使用。
3. 信息排序（Ordering）：根据上下文位置对模型处理结果的影响安排信息顺序。
4. 格式化（Formatting）：将非结构化数据转换为模型可处理的格式，例如 JSON、XML 或 Markdown 表格。

Context Condensation（上下文压缩）

Rules 的按需加载

Rules 往往是优先压缩的对象。现代 AI 编辑器支持多种加载策略。例如 CatPaw 支持四种 Rules 加载策略。后 3 种策略可以按需加载内容，减少 Context 中规则文本的占用；代价是模型可能需要额外调用读取文件的工具。

1. Always：始终加载。
2. Auto Attached：根据 globs 策略自动加载，例如处理 *.ts 时加载。
3. Manual：手动加载。
4. Model Request：先加载 Rule 的 description，模型根据 description 和当前 Context 决定是否加载其余内容。

Skills

Skills 解决的加载问题

AI IDE 加载 MCP 时，通常会将工具的名称、功能描述和入参描述预先传给 LLM。MCP 功能增多后，即使当前任务不会使用大部分工具，它们的定义仍可能占用 Context。Anthropic 提出了 Skill 概念以处理这一问题。

从使用和维护角度看，Skill 也降低了非专业研发用户扩展 Agent 能力的门槛。相较于定制 MCP，用户可以通过编写文档定义标准化流程；这适用于具有明确步骤的日常任务。

chrome devtools 一个 MCP 就有 26 个工具

Skill 的文件结构与加载方式

Skills 是一套基于文件系统的 Prompt 工程化规范。一个 Skill 的核心文件是 SKILL.md，由头部元数据和正文组成。IDE 首次加载时只读取元数据；模型判断需要该 Skill 后，再读取正文内容。这种按需读取方式可减少 Tool Overload 带来的 MCP Context 占用。

Skill 的 SKILL.md 文件可视为一类 Model Request Rule：其 description 定义模型应在何种任务中使用该 Skill。按需读取以额外的工具调用换取较小的初始 Context。

一个 Skill.md 示例

一个标准 Skill 的组成

Skills 与 MCP 的关系

在 AI Coding 中，Skill、Rules + MCP 和 Command 在能力实现上有重叠。Skill 可以处理的任务，也可能通过 Rules + MCP 或 Command 实现；SKILL.md 本身就是由 description 指定触发条件的一类 Model Request Rule。

AI 工程工具也可以为 MCP 提供动态加载机制，使 MCP 达到类似 Skill 的按需加载效果。据我所知，CatPaw 团队内部在尝试类似机制，1 月 10 日灰度的 CatPaw 也支持了 Skills。Skill 的主要作用是降低普通用户定义流程的门槛：用户可以通过自然语言编写 skill.md 来约束模型使用不同工具，工具本身也可以由模型开发。但模型在长上下文中可能无法持续遵循 skill.md 对脚本执行的要求。MCP 的开发流程通常更复杂。

Skills 的使用案例

Skill 市场https://skillsmp.com/zh中有上千个 Skill，Claude 官方维护的https://github.com/anthropics/skills也包含多个 Skill。

普通用户可以用 Skill 定义标准化任务，例如话题分享或旅行攻略 Agent。实际效果取决于任务描述、关联工具和模型是否遵循定义的流程。

其他 Context 压缩策略

前述方法主要调整 IDE 对工具和规则的加载方式。Context 压缩还可以通过以下通用方法实现：

Context Branching（上下文分支）与 Sub Agent

Sub Agent 的适用问题

**Sub Agent（子智能体架构）**是一种 Context Branching 策略。它将不同类型的任务分配给不同 Agent，用于处理单个 LLM 面对复杂场景时的限制：

1. 上下文污染（Context Pollution）：将所有工具定义和业务规则放入同一个 Context，模型可能难以区分不同任务的规则，规则之间也可能冲突。
2. Prompt 的维护成本：数千行 Prompt 难以维护和调试。
3. 工具数量限制：大模型对单次调用可挂载的 Function Calling/Tools 数量通常有限制，例如 OpenAI 建议不超过一定数量；工具过多可能增加选错工具的概率。

Sub Agent 的执行方式

主智能体（Master Agent / Orchestrator）负责调度，将任务拆解并分发给多个子智能体（Sub Agents / Workers）执行，而不是由单一 Prompt 处理全部用户请求。

Sub Agent 示意图

Sub Agent 的收益

1. 任务专门化：负责 SQL 查询的 Sub Agent 可以加载数据库 Schema 和 SQL 优化规则，无需加载写作任务所需的规则。
2. Context Window 分配：每个子智能体拥有独立的 Context Window，可以针对特定任务加载更多相关知识，而不占用其他任务的窗口。
3. 模块化维护：开发人员可以独立测试和优化某个子智能体。Coding Sub Agent 的问题不会直接影响负责架构设计的部分。
4. 模型成本控制：简单任务可使用较便宜、较快的小模型，例如 GPT-3.5-Turbo、Llama-3-8B；高难度任务再调用 GPT-4、Claude 3 Opus 等模型。

Sub Agent 的限制

1. 延迟增加（Latency）：简单编码任务经过规划、分发和汇总后，完成时间可能增加。
2. 信息传递损耗：主智能体向子智能体传达任务时可能遗漏用户隐含意图；子智能体只返回最终答案而不返回必要过程时，主智能体可能难以向用户解释结果。
3. 编排复杂性（Orchestration Complexity）：子智能体相互依赖时，例如 A 的输出是 B 的输入，系统需要处理编排、状态同步和错误。复杂拓扑还可能出现循环依赖或状态不一致，需要通过协议和运行时约束。
4. 累积误差：主智能体（Router）初始意图判断错误时，例如将“写个 Python 爬虫教程”分配给写作子智能体而不是编程子智能体，后续执行结果仍会偏离任务目标。

参考实现

• claude sub-agents
• cursor subagents

用 Hooks 提升执行确定性

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

Hooks 的作用

Hooks 在 Agent Loop 中加入生命周期回调，通过工程机制执行指定操作，而非依赖 LLM 自行选择是否执行。它们适合处理格式化、高风险操作检查等需要稳定执行的步骤。

Hooks 的定义与使用

Hooks 是用户定义的 shell 命令，可通过自定义脚本观察、控制和扩展 Agent Loop。它们在 Agent Loop 的不同阶段之前或之后运行，可以观察、阻止或修改行为。例如：

• 编辑后运行代码格式化工具。
• 为高风险操作添加门控，例如 SQL 写入。

Cursor 中可以将 Hooks 定义为 JSON 文件，放在 ./cursor/hooks 下。

简单示例

用户触发与交互方式

Modes（Deprecated）

Modes 最初用于让用户指定 System Prompt 和可使用的工具（MCP）组合，以运行专用工作流。例如 Cursor 内置支持 Agent Mode、Plan Mode 和 Ask Mode。

后续演进中，多个工具逐步减少对 Modes 的依赖。Cursor 推荐使用 Command 实现类似功能，CatPaw 将 Mode 转为 Sub Agent 的一部分。

Commands

Commands 的使用场景

Command 为用户提供主动触发 Prompt 的机制，适合在团队中共享可重复使用的 Prompt。

Command 主要改善 AI IDE 的操作便利性。也可以通过 Rule 或直接引用文件实现类似效果。

Command 的定义

Command 通常是一段 Markdown 文档，定义大模型需要执行的任务。

我用于提交代码的命令

Commands、Rules 与 MCP

Manual Rules 与 Command 的实现能力有重叠。例如 CatPaw 尚未支持 Commands 时，可以通过 @ 唤起 Rules 生成文档；支持 Command 后，可以通过 / 唤起命令生成文档。也可以在项目的任意目录放置 Markdown 文件，再通过 @ 操作符引用。

Command	Rules

MCP 也可以向外暴露命令，供用户主动触发。

一个简单示例

Commands 与 Skills

Command 示例

可将经常使用的 Prompt 定义为 Command，例如：

• **/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 项目为例，可以按任务类型组合 Command、Modes、Rules/Skills 和 MCP。

常用 Prompt 可以抽象为 Command，例如：

Command

代码提交

样式还原

可以使用 review 命令，将当前对话中需要人工介入的环节整理为 Rules。

Modes

在 [实践]AI研发助手-MRN开发实操需求中，我们添加了多个 Mode，它们对应不同场景的 Sub Agent。新版 CatPaw 可以使用 Sub Agent：界面代码开发任务切换到子 Agent，并使用 Gemini 模型进行还原；逻辑任务仍使用 Claude。

Rules/Skills

项目规范、目录规范等内容可定义为 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 的代码量，使用了 Copilot 等 AI 辅助工具。25 年我较少直接编写代码，更多时间用于设计让 Agent 自主完成项目的流程。根据 CatPaw 的数据，AI 在今年至少生成 100W 行代码，采纳了 89.9W 行。我通常同时使用两个电脑，调度三到四个 AI Coding Agent，并曾以“无人工时”作为玩笑式指标。就我的使用场景而言，AI 已能承担部分开发工作。

团队成员的反馈并不一致。常见问题包括幻觉、生成代码量超过可 Review 范围、只能完成较小且具体的模块，以及难以完成大型项目。这可能与使用者的架构经验、对 AI 工作机制的理解有关，也与 AI Coding 缺少清晰的培训路线有关。目前私有组件也没有成熟的 MCP 能力。

从软件工程的演进看，0-1 指令、汇编语言和高级编程语言逐步降低了程序表达和理解的门槛。自然语言编程在表达需求上有优势，但当前阶段沉淀的资产仍主要是代码。Prompt、Rules 和 Skills 也仍围绕如何生成准确、可控的代码展开。AI Coding 是否会进一步改变这一形态仍不确定；当前能力尚未达到汇编语言到高级编程语言的变化程度。

Spec Coding 的做法是先编写技术规格说明书，再将 SOLID 原则、TDD、DDD 等软件工程经验写入 Spec，定义 Interface 和 Schema，并将架构信息提供给 AI。开发者的工作会更多转向架构设计和结果审查。Agent 的生成结果在很大程度上依赖其遵循的 Spec 文档，因此 Spec 的规范性和完整性会直接影响结果。编写和审查 Spec 的成本可能超过直接编写代码。Spec Coding 能帮助新手执行明确指令，但无法替代资深开发者的架构决策。

Spec Coding 的常见做法

1. OpenSpec 先生成标准化 Markdown 规格文件，用于定义接口、数据结构和业务逻辑。

   1. 优势：确定性较高，尤其适合老系统重构，可以对比“当前实现”与“规格要求”的差异。
   2. 限制：需要花费较多时间审查复杂技术文档。

2. SpecKit 通过 /plan、/tasks 等指令，让 AI 按“需求分析 -> 计划拆解 -> 任务执行”的流程执行。

   1. 优势：将任务拆小，便于逐步验证结果。
   2. 限制：小功能也可能需要经过完整流程，增加操作成本。

3. BMAD 模拟敏捷开发团队，引入 PM、RD、QA 等角色。

   1. 优势：通过角色分工处理大规模项目的上下文信息。
   2. 限制：简单 Bug 也可能需要经过多个 Agent 的协调，增加等待时间和编排成本。

Everett Rogers 的创新扩散理论提出，新技术会经历五个阶段：创新者（2.5%）、早期采纳者（13.5%）、早期大众（34%）、晚期大众（34%）、落后者（16%）。该理论将从早期采纳者到早期大众视为关键阶段。AI Coding 是否处于这一阶段、26 年是否会出现替代 SDD 的方案，都仍需要观察。现有的工程沉淀应在后续实践中持续验证。

备注

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