TL;DR: 2026 年,Context Engineering(上下文工程)已从一个模糊概念演进为一套完整的工程体系。GitHub 的 agents.mdcopilot-instructions.md.prompts.md 文件,Cursor 的 Rules 系统,TRAE 的 TRAE Rules——这些规则文件构成了系统级上下文架构的基石。本文将带你从"写一条好 Prompt"升级到"设计一套上下文架构"。

从 Prompt Engineering 到 Context Engineering 2.0

Prompt Engineering 的黄金时代,我们痴迷于 Few-shot、Chain-of-Thought、Tree-of-Thought 等技巧。这些技巧的核心假设是:模型需要被精巧地引导才能产出好结果

但到了 2026 年,这个假设正在瓦解。

Claude 4、GPT-5、Gemini 2.0 等新一代模型的指令跟随能力已经趋近完美。"请你一步步思考"这样的提示词不再能带来显著提升。真正决定 AI 输出质量的变量,已经从"你怎么问"转移到了**"你让 AI 看到了什么"**。

这就是 Context Engineering 2.0 的核心命题:不是优化指令,而是架构化地管理 AI 的信息输入。

GitHub 在 2026 年 1 月的官方博客中给出了一个精准的定义:

"Context Engineering is the discipline of bringing the right information, in the right format, to the LLM." (上下文工程是将正确的信息以正确的格式带给大语言模型的学科。)

这个定义的关键词是 "discipline(学科/纪律)"——它不再是一个临时的技巧集合,而是一套需要系统性设计的工程实践。

1.0 vs 2.0:范式跃迁

维度 Context Engineering 1.0 Context Engineering 2.0
核心关注 Token 窗口优化、RAG 检索 规则文件体系、团队级架构
信息来源 对话历史、手动粘贴 版本控制的规则文件、MCP 动态注入
适用对象 个人开发者 团队 / 组织 / 开源项目
持久化方式 CLAUDE.md、对话摘要 agents.md、instructions.md、prompts.md
标准化程度 低(各 IDE 自行定义) 高(GitHub 推动行业标准)

如果你已经读过我们的上下文工程理论篇实战篇,那么本文将带你进入 2.0 阶段——从 Token 优化升级到系统级架构设计


GitHub 三大核心实践:规则文件体系

2025 年下半年到 2026 年初,GitHub 在 Copilot 生态中推出了三种核心的上下文管理机制。这标志着 Context Engineering 正式进入"文件驱动"时代。

1. Custom Instructions:全局行为约束

copilot-instructions.md 是项目级的全局指令文件,放置在 .github/ 目录下。每次 Copilot 生成代码时,都会自动读取这个文件作为系统级上下文。

markdown
<!-- .github/copilot-instructions.md -->

## 项目概述
这是一个基于 Next.js 14 + TypeScript 的全栈 SaaS 平台。

## 编码规范
- 所有组件使用函数式组件 + Hooks,禁止 class 组件
- 样式方案:Tailwind CSS + CSS Modules,禁止内联样式
- 状态管理:Zustand(全局)+ React Query(服务端)
- 所有 API 调用通过 `src/lib/api-client.ts` 封装

## 架构约束
- 页面组件放在 `app/` 目录(App Router)
- 业务逻辑封装在 `src/services/`- 数据库操作通过 Prisma ORM,禁止原始 SQL

## 禁止事项
- 不要使用 `any` 类型
- 不要在组件中直接调用 fetch
- 不要使用 moment.js,统一使用 date-fns

关键洞察copilot-instructions.md 不是写给人看的文档,而是写给 AI 看的系统提示词。它的质量直接决定了团队中每一次 AI 交互的基线水平。

2. Reusable Prompts:任务级指令模板

.github/prompts/ 目录下的 .prompt.md 文件是可复用的任务模板。与一次性 Prompt 不同,这些模板被版本控制,可以在团队中共享。

markdown
<!-- .github/prompts/code-review.prompt.md -->

你是一个严格的代码审查员。请按以下维度审查代码变更:

### 安全性
- 检查是否存在 SQL 注入、XSS、CSRF 风险
- 检查敏感信息是否暴露(API Key、密码等)

### 性能
- 检查是否有 N+1 查询
- 检查 React 组件是否存在不必要的重渲染

### 可维护性
- 函数是否超过 50 行
- 是否遵循项目的命名约定

### 输出格式
对每个问题,按 [严重/警告/建议] 分类,并给出修复建议。
markdown
<!-- .github/prompts/api-endpoint.prompt.md -->

请为以下功能创建 REST API 端点:

### 要求
- 使用 Next.js Route Handler (app/api/)
- 输入验证使用 Zod schema
- 错误处理遵循 RFC 7807 Problem Details 格式
- 包含 rate limiting 中间件
- 编写对应的集成测试

### 模板
请参考 `app/api/users/route.ts` 的实现模式。

3. Custom Agents:领域专家 AI

Custom Agents 允许为特定领域创建专属的 AI Agent。每个 Agent 拥有独立的指令集和工具访问权限。

markdown
<!-- .github/agents/database-expert.md -->

## 角色
你是数据库架构专家,精通 PostgreSQL 和 Prisma ORM。

## 能力范围
- 设计和优化数据库 schema
- 编写高效的数据库查询
- 分析和优化慢查询
- 设计数据迁移策略

## 约束
- 所有 schema 变更必须通过 Prisma Migration
- 索引策略必须考虑读写比
- 敏感字段必须加密存储
- 禁止使用 CASCADE DELETE(使用软删除)

## 可访问工具
- @database: 查询数据库 schema
- @terminal: 执行 prisma 命令

agents.md 深度解析:来自 2500+ 项目的实践

GitHub 在 2026 年初发布了一份基于 2500+ 公开仓库的分析报告,揭示了高质量 agents.md 文件的共性特征。

什么是 agents.md?

agents.md 是放置在仓库根目录的规则文件,用于定义 AI Agent 在该项目中的行为边界。与 copilot-instructions.md 的区别在于:前者定义"AI 是什么",后者定义"AI 应该怎么做"。

高质量 agents.md 的五个核心要素

GitHub 的分析发现,表现最好的 agents.md 文件通常包含以下五个部分:

markdown
<!-- agents.md -->

# Project: QubitTool

## 1. Identity(身份定义)
你是 QubitTool 项目的核心开发者。这是一个面向开发者的在线工具平台,
基于 Next.js + React 构建,支持中英文双语。

## 2. Knowledge(知识边界)
- 熟悉项目的文件结构:`src/` 下是前端代码,`content/` 下是内容文件
- 了解 Ant Design 组件库的用法
- 知道项目使用 next-i18next 进行国际化

## 3. Boundaries(行为边界)
- 不要修改 `src/core/tool-definitions.js`,除非明确要求
- 不要删除任何现有的测试用例
- 不要引入新的第三方依赖,除非讨论后确认

## 4. Workflow(工作流偏好)
- 修改前先阅读相关文件,理解现有模式
- 新增功能时,先更新 i18n 文件,再写组件
- 所有改动必须通过 `npm run lint` 检查

## 5. Communication(沟通风格)
- 修改超过 3 个文件时,先列出修改计划
- 遇到不确定的架构决策时,提供 2-3 个方案让我选择
- 用中文回复

GitHub 的关键发现

发现 数据
拥有 agents.md 的项目,AI 生成代码的首次通过率提升 40%+
最有效的 agents.md 平均长度 800-1500 词
过短(<200 词)的文件几乎没有效果
过长(>3000 词)的文件反而降低效果(信息过载)
包含代码示例的文件效果最佳

多 IDE 的 Context 实践对比

不同的 AI IDE 采用了不同的上下文管理方案。理解它们的差异,是构建跨工具 Context 架构的前提。

TRAE 的 TRAE Rules 系统

TRAE(字节跳动推出的 AI IDE)采用了一套分层的规则系统:

code
项目根目录/
├── .trae/
│   └── rules/
│       ├── code-style.md      # 编码风格规范
│       ├── git-commit.md      # Git 提交规范
│       ├── architecture.md    # 架构约束
│       └── testing.md         # 测试规范

TRAE 的设计哲学是规则文件即配置:每个 .md 文件定义一个维度的约束,系统自动合并所有规则作为 Agent 的行为基线。

markdown
<!-- .trae/rules/code-style.md -->

# 编码风格规范

## 组件规范
- 使用函数式组件 + Hooks
- Props 必须解构
- 事件处理函数使用 handleXxx 命名

## 导入顺序
1. React 及相关
2. 第三方库
3. 项目内部组件
4. Hooks
5. 工具函数 / 常量
6. 样式(最后)

Cursor Rules 体系

Cursor 的规则系统经历了从 .cursorrules.cursor/rules/ 的演进:

code
项目根目录/
├── .cursor/
│   └── rules/
│       ├── global.mdc          # 全局规则(始终生效)
│       ├── react-components.mdc # 匹配 *.tsx 文件时生效
│       └── api-routes.mdc      # 匹配 app/api/** 时生效

Cursor 的独特之处在于基于文件路径的条件匹配.mdc 文件支持 glob 模式),可以为不同模块加载不同的上下文规则:

yaml
---
description: React 组件开发规范
globs: ["src/components/**/*.tsx", "src/pages/**/*.tsx"]
---

## 组件规范
- 使用 Ant Design 组件库
- 所有文本使用 useTranslation hook
- 样式使用 CSS Modules
- 性能敏感组件使用 React.memo

Windsurf 的规则方案

Windsurf 使用 .windsurfrules 文件,语法类似 Cursor 早期的 .cursorrules,但增加了对 Cascade(多步推理)工作流的支持。

跨工具对比

graph TB subgraph "GitHub Copilot" A1[".github/copilot-instructions.md - 全局指令"] A2[".github/prompts/*.prompt.md - 可复用模板"] A3[".github/agents/*.md - 自定义 Agent"] end subgraph "Cursor" B1[".cursor/rules/*.mdc - 条件匹配规则"] end subgraph "TRAE" C1[".trae/rules/*.md - 分层规则文件"] end subgraph "通用" D1["CLAUDE.md / agents.md - 项目记忆"] end A1 --> E["系统级上下文"] A2 --> E A3 --> E B1 --> E C1 --> E D1 --> E

系统级 Context 架构设计

当团队规模超过 3 人时,零散的规则文件就不够用了。你需要一套分层的上下文架构,确保从组织到个人的每一层都有明确的规则定义。

三层架构模型

graph TD L1["组织层 (Organization Layer) - 适用于所有项目, 安全规范 / 合规要求 / 通用编码标准"] L2["项目层 (Project Layer) - 适用于特定项目, 技术栈约束 / 架构模式 / API 规范"] L3["个人层 (Personal Layer) - 适用于个人偏好, 输出语言 / 代码风格微调 / 沟通方式"] L1 --> L2 L2 --> L3 style L1 fill:#1a1a2e,stroke:#e94560,stroke-width:2px,color:#fff style L2 fill:#16213e,stroke:#0f3460,stroke-width:2px,color:#fff style L3 fill:#0f3460,stroke:#533483,stroke-width:2px,color:#fff

组织层:安全与合规的基线

markdown
<!-- .github/copilot-instructions.md (组织级模板) -->

## 安全规范(强制)
- 所有用户输入必须经过校验和转义
- 禁止在代码中硬编码密钥、Token、密码
- 数据库查询必须使用参数化查询
- API 响应不得包含内部错误堆栈

## 合规要求(强制)
- 日志中不得记录 PII(个人身份信息)
- 所有 HTTP API 必须支持 HTTPS
- 文件上传必须校验 MIME 类型和大小

## 代码质量(推荐)
- 函数单一职责,不超过 40 行
- 测试覆盖率目标:核心业务 > 80%
- 提交信息遵循 Conventional Commits 规范

项目层:技术栈与架构约束

markdown
<!-- 项目根目录/agents.md -->

# QubitTool 项目规则

## 技术栈
- Framework: Next.js 14 (Pages Router)
- UI: Ant Design 5 + CSS Modules
- i18n: next-i18next
- 部署: Vercel

## 文件结构约定
- `src/pages/tools/[slug].tsx` — 工具页面入口
- `src/core/tool-definitions.js` — 工具注册表(单一数据源)
- `content/blog/posts/{lang}/*.md` — 博客文章
- `public/locales/{lang}/*.json` — 多语言文件

## 核心模式
- 新增工具时,必须同步更新 tool-definitions.js
- 所有用户可见文本必须通过 t() 函数国际化
- 使用 recordCount() 进行页面统计打点

个人层:偏好与风格

markdown
<!-- ~/.config/cursor/rules/personal.mdc -->
<!-- 或通过 IDE 的 User Settings 配置 -->

## 沟通偏好
- 用中文回复
- 修改代码前先说明修改计划
- 给出 2-3 个方案时,标注你的推荐

## 代码风格微调
- 我偏好显式类型标注(即使 TypeScript 能推断)
- 变量命名偏好描述性名称而非缩写
- 注释使用中文

规则冲突的优先级

当多层规则发生冲突时,遵循就近原则

code
个人层 > 项目层 > 组织层

但安全和合规相关的规则是例外——它们在任何层级都具有最高优先级,不可被覆盖。


Context Engineering 与 MCP 的协同

MCP(Model Context Protocol)是 Anthropic 在 2024 年底提出的开放协议,到 2026 年已被主流 AI IDE 广泛支持。它与 Context Engineering 的关系可以这样理解:

  • 规则文件(静态上下文):定义 AI "应该知道的事"——编码规范、架构约束、项目结构
  • MCP(动态上下文):让 AI "能够获取的事"——实时数据库 Schema、API 文档、Issue 列表
code
┌─────────────────────────────────────────────┐
│              AI 的上下文窗口                   │
│                                             │
│  ┌─────────────┐  ┌──────────────────────┐  │
│  │ 静态上下文    │  │ 动态上下文(MCP)      │  │
│  │             │  │                      │  │
│  │ agents.md   │  │ @database → Schema   │  │
│  │ rules/*.md  │  │ @github → Issues     │  │
│  │ prompts.md  │  │ @docs → API 文档      │  │
│  │             │  │ @terminal → 运行结果   │  │
│  └─────────────┘  └──────────────────────┘  │
│                                             │
│  ┌──────────────────────────────────────┐   │
│  │ 用户当前指令 (Prompt)                  │   │
│  └──────────────────────────────────────┘   │
└─────────────────────────────────────────────┘

MCP 的加入使得 Context Window(上下文窗口) 的管理变得更加复杂,但也更加强大。一个完善的 Context 架构应当同时规划静态规则和动态数据源。


从个人 Prompt 到团队 Context 的标准化路径

将 Context Engineering 从"个人技巧"提升为"团队基础设施",需要一条渐进式的路径:

Phase 1:个人探索期(1-2 周)

目标:验证规则文件的价值。

  1. 在你的主力项目中创建 agents.md(或对应 IDE 的规则文件)
  2. 写入 5-10 条最核心的编码约束
  3. 使用 1-2 周,观察 AI 生成代码的质量变化

Phase 2:项目标准化(2-4 周)

目标:建立项目级的 Context 体系。

  1. 创建完整的目录结构:
code
项目根目录/
├── .github/
│   ├── copilot-instructions.md
│   └── prompts/
│       ├── code-review.prompt.md
│       ├── api-endpoint.prompt.md
│       └── bug-fix.prompt.md
├── .cursor/
│   └── rules/
│       └── project.mdc
├── .trae/
│   └── rules/
│       └── code-style.md
└── agents.md
  1. 将团队中最常用的 Prompt 模板化到 .github/prompts/
  2. 在代码审查中加入"规则文件是否需要更新"的检查项

Phase 3:组织级推广(1-3 个月)

目标:建立组织级的 Context 治理体系。

  1. 创建组织级的规则模板仓库(如 org/.github
  2. 定义规则文件的所有权和变更流程(谁能修改?如何审批?)
  3. 建立规则文件的效果度量体系(AI 代码首次通过率、审查打回率等)
  4. 定期审查和更新规则(建议每月一次)

使用 AI 工具目录 寻找适合你的 AI 编程工具

在选择 AI IDE 和配置 Context 体系时,不妨先通过 AI DirectoryAgent Directory 对比不同工具的 Context 管理能力,找到最适合你团队的方案。如果你需要格式化 AI 返回的 JSON 配置,JSON Formatter 也是一个高效的辅助工具。


实战案例:为一个 Next.js 项目搭建 Context 架构

以下是一个真实的 Next.js 全栈项目的 Context 架构实例,展示了如何将上述理论落地:

code
my-saas-app/
├── .github/
│   ├── copilot-instructions.md    # Copilot 全局指令
│   └── prompts/
│       ├── new-feature.prompt.md  # 新功能开发模板
│       ├── code-review.prompt.md  # 代码审查模板
│       ├── db-migration.prompt.md # 数据库迁移模板
│       └── test-gen.prompt.md     # 测试生成模板
├── .cursor/
│   └── rules/
│       ├── global.mdc             # Cursor 全局规则
│       ├── frontend.mdc           # 前端文件匹配规则
│       └── backend.mdc            # 后端文件匹配规则
├── .trae/
│   └── rules/
│       ├── code-style.md          # TRAE 编码规范
│       └── git-commit.md          # TRAE Git 规范
├── agents.md                      # 通用项目规则
├── CLAUDE.md                      # Claude 项目记忆
└── src/
    └── ...

这套架构确保了:

  • 使用 GitHub Copilot 的成员自动获得 copilot-instructions.md + prompts/ 的上下文
  • 使用 Cursor 的成员自动获得 .cursor/rules/ 的上下文(支持路径匹配)
  • 使用 TRAE 的成员自动获得 .trae/rules/ 的上下文
  • 使用 Claude 的成员可以引用 CLAUDE.mdagents.md

核心规范在 agents.md 中维护一份,其他 IDE 特定文件引用或镜像这些规范。


总结:Context 是新的基础设施

如果说 2024 年的 AI 工程关键词是 Agent,那么 2026 年的关键词就是 Context Architecture

我们正在见证一个有趣的转变:代码仓库中不仅有写给机器编译的代码,还有写给 AI 阅读的规则。.md 文件正在成为一种新的基础设施层。

你的下一步行动:

  1. 今天:在你的主力项目中创建一个 agents.md,写入 10 条核心规则
  2. 本周:将团队最常用的 3 个 Prompt 模板化到 .github/prompts/
  3. 本月:建立完整的三层 Context 架构,并在团队中推广

记住 GitHub 的那句定义:Context Engineering 是将正确的信息正确的格式带给 LLM 的学科。而规则文件,就是你为团队中每一个 AI 交互奠定的基石。


延伸阅读