上下文工程：给 AI 喂什么，比问什么更重要

## 一个对照实验

同一个模型，同一个问题：

```
问法 A：
"帮我优化这段 SQL"

问法 B：
"这是订单表，2000 万行，order_date 有索引但 status 没有。
这个查询要跑 8 秒，业务要求 500ms 内返回。
表结构：id, user_id, status, amount, order_date, created_at
当前 SQL：SELECT * FROM orders WHERE status = 1 AND order_date > '2026-01-01'
执行计划显示走了全表扫描。
帮我优化，并说明为什么原方案慢。"
```

A 会得到「可以加索引」「避免 SELECT *」这类正确但无用的建议。

B 会得到具体的复合索引设计方案、覆盖索引的取舍、以及为什么优化器没选索引的分析。

**差别不在模型，在上下文。**

## 上下文的三层结构

我把上下文分成三层，缺一层效果就掉一档。

### 第一层：事实（What）

**客观存在的信息。** 表结构、字段类型、数据量、错误堆栈、配置值、日志片段。

这一层的常见错误是「省略自认为不重要的细节」。

```python
# AI 只看到这个，只能猜
"接口报错了，怎么修？"

# 加上事实，AI 才能定位
'''
接口 POST /api/orders 返回 500
错误：psycopg2.errors.UniqueViolation: duplicate key value violates
unique constraint "orders_order_no_key"
请求体：{"order_no": "ORD20261111001", "amount": 299}
数据库：PostgreSQL 15，orders 表有 order_no 唯一索引
并发量：约 50 QPS
'''
```

### 第二层：约束（Why not）

**为什么不能用某个方案。** 这一层最容易被忽略，也最能筛掉 AI 的「教科书答案」。

```
不好的约束表述：
"给我一个高可用的方案"
-> AI 会给 K8s + 多副本 + 负载均衡，但你只有一台机器

好的约束表述：
"只有 1 台 4C8G 的 ECS，预算不能加，
但要求服务中断时间 < 30 秒，
日活约 500，只需要读写分离不要求分库"
-> AI 才会考虑单机上的优雅重启、蓝绿切换
```

约束要写「边界」而不是「愿望」。愿望是形容词，边界是数字。

### 第三层：目标（What for）

**这个产出要给谁用、用来干什么。**

```
同一个函数，两种目标：

目标 A："写一个数据校验函数"
目标 B："写一个数据校验函数，报错信息要给非技术的运营同学看懂，
他们需要知道改哪个字段、改成什么格式"

A 的输出：raise ValueError("invalid email")
B 的输出：raise ValueError("邮箱格式不对，需要包含 @ 符号，例：name@company.com")
```

**目标决定抽象层次。** 不写目标，AI 默认按「程序员给程序员看」的标准输出。

## 一个实操模板

我现在写 prompt，基本按这个结构：

```
【背景】我在做什么，现在到哪一步了
【事实】相关代码/数据/报错，原文贴，不概括
【约束】试过什么不行，为什么不行；不能做什么
【目标】谁看这个产出，用来做什么决策
【输出格式】要代码/要分析/要清单；多长
```

举一个真实例子：

```
【背景】
一个内部工具，每天有 20 个运营同事用它批量导入商品数据。
现在导入 1 万条要 3 分钟，超时会被网关切断。

【事实】
技术栈：Python 3.11 + FastAPI + PostgreSQL
导入逻辑：逐条 INSERT，在 for 循环里
表结构：products(id, sku, name, price, stock, category_id)
当前代码：
for item in items:
db.execute("INSERT INTO products ...", item)
db.commit() # 每条都 commit
日志：单条 INSERT 平均 18ms，1 万条 = 180 秒

【约束】
- 不能改成异步任务（运营需要同步看到结果）
- 不能加机器
- sku 有唯一索引，重复导入要跳过不能报错
- 必须能返回「成功 N 条、跳过 M 条、失败 K 条」

【目标】
让运营同事点一次按钮，1 万条能在 20 秒内导入完成，
并且能看懂结果（哪些失败了、为什么）

【输出】
给我改后的代码 + 说明为什么能快 10 倍
```

这个 prompt 的输出质量，比「帮我优化批量插入」高出一个量级。

## 三个反模式

### 反模式一：把 AI 当搜索引擎

```
"Python 怎么做批量插入"
```

这是在问「有哪几种方法」。但你的问题不是「有哪些方法」，而是「我的场景该用哪个」。

搜索引擎给你选项，上下文工程给你决策。

### 反模式二：信息倾倒

把 500 行日志全部贴进去，指望 AI 自己找重点。

**上下文不是越多越好。** 无关信息会稀释注意力。正确做法是先自己筛一遍：

```
贴之前问自己：
这条信息如果去掉，AI 的答案会不会变？
不会变 -> 删掉
```

### 反模式三：一次问到底

```
"帮我设计一个电商系统的数据库"
```

这种问题得到的必然是教科书架构。因为你没给任何具体约束，AI 只能按「最常见的电商」来设计。

**拆解**：先问「订单表怎么设计，要考虑退款和部分发货」，再问「库存表怎么设计，要支持预售」，逐个击破。

## 为什么这对 AI Coding 尤其重要

写代码是**强上下文任务**：

| 维度 | 影响 |
|---|---|
| 现有代码风格 | 不一致的代码后期维护成本翻倍 |
| 依赖版本 | 用错 API 直接运行失败 |
| 项目结构 | 文件放错位置，找都找不到 |
| 命名约定 | 团队协作时沟通成本上升 |
| 已有抽象 | 重复造轮子 |

这些信息如果不显式提供，AI 只能按「最常见的写法」生成——和你的项目不一定匹配。

所以我现在的做法是：**动手前先让 AI 读项目**。

```
"先看一遍 src/ 目录结构、package.json、还有 src/utils/ 下的文件，
理解现有的代码风格和抽象方式。
然后告诉我你打算怎么改，先不要写代码。"
```

这一步花 30 秒，能省下后面 30 分钟的返工。

## 小结

```
上下文三层：
事实 -> 让 AI 知道"是什么"
约束 -> 让 AI 知道"不能怎样"
目标 -> 让 AI 知道"为谁而做"

缺事实：答案泛泛
缺约束：答案理想化但不可行
缺目标：答案专业但不实用
```

提示词工程的讨论常常聚焦在「怎么说」，但**说什么**往往更关键。

模型能力是给定的，上下文是你唯一能完全控制的部分。把它用好，比换更强的模型更划算。