首页 › LLM大语言模型 › 大模型技术工程 › 上下文工程 › Context Engineering 2.0：从 Prompt 技巧到系统级上下文架构设计

Context Engineering 2.0：从 Prompt 技巧到系统级上下文架构设计

​

🌌

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：范式跃迁​

​

#cORnPZdDMtTe text { white-space: pre; }#cORnPZdDMtTe .fb0 { stroke: var(--N900-FG, 0.15); }#cORnPZdDMtTe .fb0 {stroke: rgba(31,35,41, 0.15)}#cORnPZdDMtTe .fx0 { stroke-miterlimit: 10; }#cORnPZdDMtTe .fx0 {stroke-miterlimit: 10}#cORnPZdDMtTe .fa1 { fill: rgb(187, 191, 196); }#cORnPZdDMtTe .fa1 {fill: rgb(187, 191, 196)}#cORnPZdDMtTe .fx1 { font: 400 12px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#cORnPZdDMtTe .fx1 {font-style: normal}#cORnPZdDMtTe .fx2 { text-anchor: middle; }#cORnPZdDMtTe .fx2 {text-anchor: middle}#cORnPZdDMtTe .fx3 { dominant-baseline: central; }#cORnPZdDMtTe .fx3 {dominant-baseline: central}#cORnPZdDMtTe .fx4 { stroke: none; }#cORnPZdDMtTe .fx4 {stroke: none}#cORnPZdDMtTe .fc0 { fill: var(--text-caption); }#cORnPZdDMtTe .fc0 {fill: #646a73}#cORnPZdDMtTe .fa2 { fill: var(--text-link-disabled); }#cORnPZdDMtTe .fa2 {fill: rgb(187, 191, 196)}#cORnPZdDMtTe .fa3 { fill: rgb(31, 35, 41); }#cORnPZdDMtTe .fa3 {fill: rgb(31, 35, 41)}#cORnPZdDMtTe .fx5 { font: 400 16px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#cORnPZdDMtTe .fx5 {font-style: normal}#cORnPZdDMtTe .fx6 { text-anchor: start; }#cORnPZdDMtTe .fx6 {text-anchor: start}#cORnPZdDMtTe .fx7 { dominant-baseline: alphabetic; }#cORnPZdDMtTe .fx7 {dominant-baseline: alphabetic}#cORnPZdDMtTe .fc1 { fill: rgb(255, 255, 255); }#cORnPZdDMtTe .fc1 {fill: rgb(255, 255, 255)}#cORnPZdDMtTe .fx8 { font: 700 16px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#cORnPZdDMtTe .fx8 {font-style: normal}#cORnPZdDMtTe .fc2 { fill: rgb(51, 51, 51); }#cORnPZdDMtTe .fc2 {fill: rgb(51, 51, 51)}#cORnPZdDMtTe .fb1 { fill: var(--N900-FG, 0.15); }#cORnPZdDMtTe .fb1 {fill: rgba(31,35,41, 0.15)}#cORnPZdDMtTe .fb2 { fill: rgb(225, 228, 232); }#cORnPZdDMtTe .fb2 {fill: rgb(225, 228, 232)}#cORnPZdDMtTe .fa4 { fill: var(--bg-body); }#cORnPZdDMtTe .fa4 {fill: #fff}ABC123456维度Context Engineering 1.0Context Engineering 2.0核心关注信息来源适用对象持久化方式标准化程度Token 窗口优化、RAG 检索对话历史、手动粘贴个人开发者CLAUDE.md、对话摘要低（各 IDE 自行定义）规则文件体系、团队级架构版本控制的规则文件、MCP 动态注入团队 / 组织 / 开源项目agents.md、instructions.md、prompts.md高（GitHub 推动行业标准）

​

本文将带你进入 2.0 阶段——从 Token 优化升级到系统级架构设计。​

​

​

​

​

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

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

Custom Instructions：全局行为约束​

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

​

代码块​

Markdown

​

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

Reusable Prompts：任务级指令模板​

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

​

代码块​

Markdown

​

​

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

​

### 安全性- 检查是否存在 SQL 注入、XSS、CSRF 风险​

- 检查敏感信息是否暴露（API Key、密码等）​

​

### 性能- 检查是否有 N+1 查询​

- 检查 React 组件是否存在不必要的重渲染​

​

### 可维护性- 函数是否超过 50 行​

- 是否遵循项目的命名约定​

​

### 输出格式​

​

​

代码块​

Markdown

​

​

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

​

### 要求- 使用 Next.js Route Handler (app/api/)​

- 输入验证使用 Zod schema​

- 错误处理遵循 RFC 7807 Problem Details 格式​

- 包含 rate limiting 中间件​

- 编写对应的集成测试​

​

### 模板​

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

​

Custom Agents：领域专家 AI​

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

​

代码块​

Markdown

​

​

## 角色​

你是数据库架构专家，精通 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

​

​

​

GitHub 的关键发现​

​

​

​

​

多 IDE 的 Context 实践对比​

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

TRAE 的 TRAE Rules 系统​

TRAE（字节跳动推出的 AI IDE）采用了一套分层的规则系统：​

​

代码块​

Plain Text

项目根目录/​

├── .trae/​

│ └── rules/​

│ ├── code-style.md # 编码风格规范​

│ ├── git-commit.md # Git 提交规范​

│ ├── architecture.md # 架构约束​

│ └── testing.md # 测试规范​

​

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

​

代码块​

Markdown

​

​

# 编码风格规范## 组件规范- 使用函数式组件 + Hooks​

- Props 必须解构​

- 事件处理函数使用 handleXxx 命名​

​

Cursor Rules 体系​

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

​

代码块​

Plain Text

项目根目录/​

├── .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（多步推理）工作流的支持。​

跨工具对比​

​

​

​

系统级 Context 架构设计​

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

三层架构模型​

​

​

组织层：安全与合规的基线​

​

代码块​

Markdown

​

​

## 安全规范（强制）- 所有用户输入必须经过校验和转义​

- 禁止在代码中硬编码密钥、Token、密码​

- 数据库查询必须使用参数化查询​

- API 响应不得包含内部错误堆栈​

​

## 合规要求（强制）- 日志中不得记录 PII（个人身份信息）​

- 所有 HTTP API 必须支持 HTTPS​

- 文件上传必须校验 MIME 类型和大小​

​

## 代码质量（推荐）- 函数单一职责，不超过 40 行​

- 测试覆盖率目标：核心业务 > 80%​

- 提交信息遵循 Conventional Commits 规范​

​

项目层：技术栈与架构约束​

​

代码块​

Markdown

​

​

# 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

​​

​

## 沟通偏好- 用中文回复​

- 修改代码前先说明修改计划​

- 给出 2-3 个方案时，标注你的推荐​

​

## 代码风格微调- 我偏好显式类型标注（即使 TypeScript 能推断）​

- 变量命名偏好描述性名称而非缩写​

- 注释使用中文​

​

规则冲突的优先级​

当多层规则发生冲突时，遵循就近原则：​

​

代码块​

Plain Text

​

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

​

​

Context Engineering 与 MCP 的协同​

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

•

规则文件（静态上下文）：定义 AI "应该知道的事"——编码规范、架构约束、项目结构​

•

MCP（动态上下文）：让 AI "能够获取的事"——实时数据库 Schema、API 文档、Issue 列表​

​

代码块​

Plain Text

┌─────────────────────────────────────────────┐​

│ AI 的上下文窗口 │​

│ │​

│ ┌─────────────┐ ┌──────────────────────┐ │​

​

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 体系。​

创建完整的目录结构：​

​

代码块​

Plain Text

项目根目录/​

├── .github/​

│ ├── copilot-instructions.md​

│ └── prompts/​

​

将团队中最常用的 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 架构实例，展示了如何将上述理论落地：​

​

代码块​

Plain Text

my-saas-app/​

├── .github/​

│ ├── copilot-instructions.md # Copilot 全局指令​

│ └── prompts/​

​

这套架构确保了：​

•

使用 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 交互奠定的基石。​