TL;DR:
2026 年,Context Engineering(上下文工程)已从一个模糊概念演进为一套完整的工程体系。GitHub 的 agents.md、copilot-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 生成代码时,都会自动读取这个文件作为系统级上下文。
<!-- .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 不同,这些模板被版本控制,可以在团队中共享。
<!-- .github/prompts/code-review.prompt.md -->
你是一个严格的代码审查员。请按以下维度审查代码变更:
### 安全性
- 检查是否存在 SQL 注入、XSS、CSRF 风险
- 检查敏感信息是否暴露(API Key、密码等)
### 性能
- 检查是否有 N+1 查询
- 检查 React 组件是否存在不必要的重渲染
### 可维护性
- 函数是否超过 50 行
- 是否遵循项目的命名约定
### 输出格式
对每个问题,按 [严重/警告/建议] 分类,并给出修复建议。
<!-- .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 拥有独立的指令集和工具访问权限。
<!-- .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 文件通常包含以下五个部分:
<!-- 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)采用了一套分层的规则系统:
项目根目录/
├── .trae/
│ └── rules/
│ ├── code-style.md # 编码风格规范
│ ├── git-commit.md # Git 提交规范
│ ├── architecture.md # 架构约束
│ └── testing.md # 测试规范
TRAE 的设计哲学是规则文件即配置:每个 .md 文件定义一个维度的约束,系统自动合并所有规则作为 Agent 的行为基线。
<!-- .trae/rules/code-style.md -->
# 编码风格规范
## 组件规范
- 使用函数式组件 + Hooks
- Props 必须解构
- 事件处理函数使用 handleXxx 命名
## 导入顺序
1. React 及相关
2. 第三方库
3. 项目内部组件
4. Hooks
5. 工具函数 / 常量
6. 样式(最后)
Cursor Rules 体系
Cursor 的规则系统经历了从 .cursorrules 到 .cursor/rules/ 的演进:
项目根目录/
├── .cursor/
│ └── rules/
│ ├── global.mdc # 全局规则(始终生效)
│ ├── react-components.mdc # 匹配 *.tsx 文件时生效
│ └── api-routes.mdc # 匹配 app/api/** 时生效
Cursor 的独特之处在于基于文件路径的条件匹配(.mdc 文件支持 glob 模式),可以为不同模块加载不同的上下文规则:
---
description: React 组件开发规范
globs: ["src/components/**/*.tsx", "src/pages/**/*.tsx"]
---
## 组件规范
- 使用 Ant Design 组件库
- 所有文本使用 useTranslation hook
- 样式使用 CSS Modules
- 性能敏感组件使用 React.memo
Windsurf 的规则方案
Windsurf 使用 .windsurfrules 文件,语法类似 Cursor 早期的 .cursorrules,但增加了对 Cascade(多步推理)工作流的支持。
跨工具对比
系统级 Context 架构设计
当团队规模超过 3 人时,零散的规则文件就不够用了。你需要一套分层的上下文架构,确保从组织到个人的每一层都有明确的规则定义。
三层架构模型
组织层:安全与合规的基线
<!-- .github/copilot-instructions.md (组织级模板) -->
## 安全规范(强制)
- 所有用户输入必须经过校验和转义
- 禁止在代码中硬编码密钥、Token、密码
- 数据库查询必须使用参数化查询
- API 响应不得包含内部错误堆栈
## 合规要求(强制)
- 日志中不得记录 PII(个人身份信息)
- 所有 HTTP API 必须支持 HTTPS
- 文件上传必须校验 MIME 类型和大小
## 代码质量(推荐)
- 函数单一职责,不超过 40 行
- 测试覆盖率目标:核心业务 > 80%
- 提交信息遵循 Conventional Commits 规范
项目层:技术栈与架构约束
<!-- 项目根目录/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() 进行页面统计打点
个人层:偏好与风格
<!-- ~/.config/cursor/rules/personal.mdc -->
<!-- 或通过 IDE 的 User Settings 配置 -->
## 沟通偏好
- 用中文回复
- 修改代码前先说明修改计划
- 给出 2-3 个方案时,标注你的推荐
## 代码风格微调
- 我偏好显式类型标注(即使 TypeScript 能推断)
- 变量命名偏好描述性名称而非缩写
- 注释使用中文
规则冲突的优先级
当多层规则发生冲突时,遵循就近原则:
个人层 > 项目层 > 组织层
但安全和合规相关的规则是例外——它们在任何层级都具有最高优先级,不可被覆盖。
Context Engineering 与 MCP 的协同
MCP(Model Context Protocol)是 Anthropic 在 2024 年底提出的开放协议,到 2026 年已被主流 AI IDE 广泛支持。它与 Context Engineering 的关系可以这样理解:
- 规则文件(静态上下文):定义 AI "应该知道的事"——编码规范、架构约束、项目结构
- MCP(动态上下文):让 AI "能够获取的事"——实时数据库 Schema、API 文档、Issue 列表
┌─────────────────────────────────────────────┐
│ 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 周)
目标:验证规则文件的价值。
- 在你的主力项目中创建
agents.md(或对应 IDE 的规则文件) - 写入 5-10 条最核心的编码约束
- 使用 1-2 周,观察 AI 生成代码的质量变化
Phase 2:项目标准化(2-4 周)
目标:建立项目级的 Context 体系。
- 创建完整的目录结构:
项目根目录/
├── .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
- 将团队中最常用的 Prompt 模板化到
.github/prompts/ - 在代码审查中加入"规则文件是否需要更新"的检查项
Phase 3:组织级推广(1-3 个月)
目标:建立组织级的 Context 治理体系。
- 创建组织级的规则模板仓库(如
org/.github) - 定义规则文件的所有权和变更流程(谁能修改?如何审批?)
- 建立规则文件的效果度量体系(AI 代码首次通过率、审查打回率等)
- 定期审查和更新规则(建议每月一次)
使用 AI 工具目录 寻找适合你的 AI 编程工具
在选择 AI IDE 和配置 Context 体系时,不妨先通过 AI Directory 和 Agent Directory 对比不同工具的 Context 管理能力,找到最适合你团队的方案。如果你需要格式化 AI 返回的 JSON 配置,JSON Formatter 也是一个高效的辅助工具。
实战案例:为一个 Next.js 项目搭建 Context 架构
以下是一个真实的 Next.js 全栈项目的 Context 架构实例,展示了如何将上述理论落地:
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.md和agents.md
核心规范在 agents.md 中维护一份,其他 IDE 特定文件引用或镜像这些规范。
总结:Context 是新的基础设施
如果说 2024 年的 AI 工程关键词是 Agent,那么 2026 年的关键词就是 Context Architecture。
我们正在见证一个有趣的转变:代码仓库中不仅有写给机器编译的代码,还有写给 AI 阅读的规则。.md 文件正在成为一种新的基础设施层。
你的下一步行动:
- 今天:在你的主力项目中创建一个
agents.md,写入 10 条核心规则 - 本周:将团队最常用的 3 个 Prompt 模板化到
.github/prompts/ - 本月:建立完整的三层 Context 架构,并在团队中推广
记住 GitHub 的那句定义:Context Engineering 是将正确的信息以正确的格式带给 LLM 的学科。而规则文件,就是你为团队中每一个 AI 交互奠定的基石。