上下文工程：AI 编程的核心能力

作为一线开发者，你可能已经用过 Copilot、Claude Code 或 OpenAI Codex。它们确实强大，但很多人发现，用了一段时间后，AI 的建议质量开始下降——代码越来越不相关，甚至答非所问。

问题往往不在 AI 本身，而在你给它的「上下文」。

什么是上下文工程

上下文工程（Context Engineering）是 Prompt Engineering 的进阶形态。Prompt Engineering 关注的是「怎么问」，而上下文工程关注的是「AI 在回答之前看到了什么」。

一个 AI 编程助手的输出质量，直接由它接收到的上下文决定。你给它的项目背景越准确，它的建议就越切中要害。上下文工程的核心，就是系统性地管理这个信息供给。

五个立竿见影的实践技巧

1. 项目结构文档化

在项目根目录放置一个 CONTEXT.md 文件，用结构化的方式描述项目：

# 项目概述
电商后端 API 服务，基于 Node.js + NestJS

## 核心领域模型
- Order（订单）：id, userId, status, totalAmount, createdAt
- Product（商品）：id, name, price, stock, categoryId
- User（用户）：id, email, role, addresses[]

## API 设计约定
- RESTful，URL 使用 kebab-case
- 统一错误响应格式：{ code, message, data }
- 认证：JWT Bearer Token

## 数据库
- PostgreSQL，使用 Prisma ORM
- 迁移文件在 prisma/migrations/

AI 看到这份文档后，能在几秒内理解项目结构，而不需要从几千行代码里慢慢推断。

2. 精准的代码片段注入

不要让 AI 自己搜索相关代码，而是在对话中主动粘贴关键片段。

举个例子，你想让 AI 帮你写一个新的 API 路由，但 Copilot 给的建议完全不符合项目的代码风格。你可以这样做：

我正在为商品模块添加一个新的 API 端点。
这是项目中现有的商品相关路由的写法（符合我们的风格）：

// 现有代码
@Get(':id')
async findOne(@Param('id') id: string) {
  const product = await this.productService.findById(id);
  if (!product) throw new NotFoundException('商品不存在');
  return { code: 0, data: product };
}

请参考这个模式，帮我写一个根据分类获取商品列表的端点。

这样做，你是在用具体的代码「教」AI 项目的编码风格，而不是抽象地描述规则。

3. 分层记忆策略

根据任务的性质，决定给 AI 看多少上下文：

• 小任务（修复 bug、写简单函数）：只提供相关文件片段，不需要项目全局信息
• 中等任务（添加功能模块）：提供 CONTEXT.md + 相关业务逻辑文件
• 大任务（架构调整、重构）：提供完整的项目结构描述 + 核心领域模型 + 相关测试文件

一个常见错误是：不管任务大小，都把整个代码库扔给 AI。这不仅浪费 token，更会让 AI 被无关信息干扰。

4. 用测试锁定行为预期

在让 AI 写代码之前，先把测试用例写出来。测试本质上是对期望行为的精确描述。

describe('OrderService', () => {
  it('应拒绝创建库存不足的订单', async () => {
    const product = await seedProduct({ stock: 0 });
    await expect(createOrder({ productId: product.id }))
      .rejects.toThrow('库存不足');
  });
});

当你把这个测试给 AI 时，它不是在猜你需要什么代码，而是在「满足一个明确的技术规格」。

5. 建立 AI 友好的代码组织

如果项目结构混乱，AI 也难以给出好的建议。一些简单的约定能显著提升 AI 的理解效率：

• 文件名要自解释：auth/jwt.strategy.ts 比 auth.js 好太多
• 模块职责单一：每个文件的职责一目了然，AI 能快速定位
• 一致的命名模式：团队统一的前缀、缩写和命名风格

真实案例

我最近在做一个内部工具项目，需要给 AI 描述整个代码库以实现一个复杂的数据导出功能。按照旧习惯，我直接让 AI 「帮我写一个导出功能」。结果生成的代码完全不符合项目风格，还需要大量修改。

后来我换了一种方式：

1. 先在 CONTEXT.md 里描述了数据模型和现有的导出模式
2. 把现有导出功能的核心代码粘贴给 AI 参考
3. 给出了新功能的测试用例

AI 这次生成的代码，一次性通过了所有测试，后续只做了两处微调。从「生成 → 大量修改 → 重写」变成了「生成 → 少量微调 → 通过」。

写在最后

AI 编程工具的差距，往往不在模型本身，而在于使用者对上下文的掌控能力。掌握上下文工程的开发者，能让同一个 AI 模型发挥出数倍的效能。

这不是关于如何使用某个 AI 工具的技巧，而是关于如何系统性地思考人机协作的基础能力。上下文工程的思维，也可以迁移到任何与 AI 系统交互的场景中——不只是编程。

如果你还没试过 CONTEXT.md，从今天开始，在你的一个项目里试试。一周后，你会回来感谢这个建议。