使用 GPT 和 Codex

2026年7月
start/aixufei/c/o/m

仍然把重点放在“提示词”上。

怎么问更准？
怎么让它写得更好？
怎么让它少废话？
怎么让它生成代码更稳定？
怎么让它理解我的需求？

这些问题当然有价值，但如果只停留在 Prompt 层面，会很容易遇到瓶颈。

因为 GPT 和 Codex 真正处理的，并不是一句提示词，而是一个上下文系统。

模型的输出质量，不只取决于你最后一句话写得好不好，而取决于它能看到什么、理解什么、记住什么、忽略什么、验证什么。

这就是为什么同样一个模型，在不同人手里效果差距很大。

有人只会输入一句：

帮我优化这个项目。

结果模型生成一堆泛泛而谈的建议。

有人会给它项目结构、核心文件、当前问题、约束条件、历史决策、测试要求和输出格式，模型就能给出更接近真实工程的结果。

差别不在于谁用了更神秘的提示词，而在于谁构建了更好的上下文。

所以，GPT 和 Codex 的高阶使用，不应该叫 Prompt Engineering，而应该叫 Context Engineering。

提示词只是入口。
上下文才是系统。

一、Prompt 是一句话，Context 是一个工作环境

Prompt 更像是用户发出的指令。

例如：

帮我给订单模块增加一个导出功能。

这句话本身并不复杂，但对模型来说信息远远不够。

它不知道：

• 订单模块在哪里；
• 项目是什么技术栈；
• 当前是否已有导出功能；
• 前端筛选条件如何组织；
• 后端接口是否存在；
• 权限系统如何设计；
• 导出数据量是否有限制；
• 文件格式是什么；
• 是否需要异步任务；
• 是否要补测试；
• 哪些文件不能修改；
• 什么结果算完成。

如果没有这些信息，模型只能基于通用经验猜。

而真实项目最怕的就是“猜”。

Context 不一样。

Context 是围绕任务构建的一整套信息环境。

它包括：

用户目标
项目结构
相关代码
历史约束
业务规则
数据格式
错误日志
测试标准
输出要求
安全边界
人工决策

当这些信息被合理组织起来，模型才不再是在空中生成答案，而是在一个具体环境里推理。

所以，Prompt 是一句话。
Context 是一张地图。

没有地图，模型只能凭经验走。
有了地图，模型才能在真实空间里行动。

二、Codex 的稳定性，本质上取决于上下文质量

很多人说 Codex 写代码不稳定。

这句话只说对了一半。

Codex 的确会犯错，会误解需求，会生成不合适的实现。
但很多“不稳定”，其实来自上下文不足。

比如你让它：

帮我修复登录 bug。

它可能会给出很多猜测：

• token 过期；
• cookie 丢失；
• 请求头没带；
• 后端返回异常；
• 前端状态没更新；
• 路由守卫有问题。

这些都可能对，也可能完全不相关。

但如果你提供更完整的上下文：

问题：用户登录成功后，刷新页面会回到登录页。

已知信息：
1. 登录接口返回 token；
2. token 存在 localStorage；
3. 刷新后 localStorage 里仍然有 token；
4. 前端使用 React Router；
5. 权限判断在 authGuard.ts；
6. 用户信息接口 /api/me 偶尔返回 401；
7. 最近改动过 axios 拦截器。

请先不要修改代码，先分析可能原因，并按优先级给排查路径。

这时候 Codex 的判断会明显更接近真实问题。

为什么？

因为它不是凭空猜 bug，而是在上下文里寻找因果关系。

对代码任务来说，上下文质量直接影响输出质量。

一个高质量上下文至少包含：

任务目标：要解决什么问题
当前现象：实际发生了什么
期望结果：应该发生什么
相关文件：需要关注哪些代码
已知事实：哪些已经确认
约束条件：不能改什么
历史改动：最近动过什么
验证方式：如何确认修复成功

这比单纯写一个“神级提示词”更重要。

三、上下文不是越多越好，而是越结构化越好

很多人误以为，给模型的信息越多越好。

于是把一整个项目、一大段聊天记录、一堆日志全部丢进去，让模型自己理解。

结果模型反而容易混乱。

因为上下文不是仓库，不是把所有材料塞进去就完事。

上下文更像操作台。

你要把当前任务真正需要的东西摆出来，不需要的东西收起来；重要信息放在前面，辅助信息放在后面；确定事实和猜测分开；目标和限制分开；输入和输出分开。

一个混乱上下文可能是这样：

这里是我的项目代码，还有一些报错，还有之前的需求，还有别人说的几个问题。
你帮我看看怎么改。

一个结构化上下文应该是这样：

# 任务目标
修复用户刷新页面后被错误重定向到登录页的问题。

# 当前现象
用户登录成功后可以进入首页，但刷新页面后会回到登录页。

# 期望结果
只要 token 有效，刷新后应继续保持登录状态。

# 已确认事实
- 登录接口正常返回 token；
- token 已写入 localStorage；
- 刷新后 token 仍然存在；
- /api/me 偶尔返回 401；
- 最近修改过 axios 拦截器。

# 相关文件
- src/router/authGuard.ts
- src/store/userStore.ts
- src/services/http.ts
- src/services/authApi.ts

# 限制条件
- 不要修改登录接口返回结构；
- 不要改变路由配置方式；
- 不要引入新状态管理库；
- 先分析，不要直接改代码。

# 输出要求
请按可能性排序，给出 3 个排查方向，并说明每个方向需要检查的代码位置。

这就是上下文工程的核心。

不是堆信息，而是组织信息。

模型不是神。
它需要好的输入环境。

四、上下文工程的第一原则：区分事实、推测和目标

在复杂任务里，最容易出问题的是把事实、推测和目标混在一起。

比如用户说：

应该是接口有问题，帮我改一下前端。

这句话里至少有三个层次：

目标：修复某个问题
推测：可能是接口有问题
动作建议：改前端

如果模型不区分这些层次，它可能直接开始改前端。

但正确做法应该是先拆开：

事实是什么？
用户看到什么错误？
接口真的有问题吗？
前端有没有处理异常？
后端返回是否稳定？
用户的判断是不是只是猜测？

所以，一个成熟的上下文系统，应该显式标记信息类型。

可以这样设计：

type ContextItemType =
  | "fact"
  | "assumption"
  | "goal"
  | "constraint"
  | "evidence"
  | "risk"
  | "decision";

interface ContextItem {
  type: ContextItemType;
  content: string;
  source?: string;
  confidence?: number;
}

例如：

const context: ContextItem[] = [
  {
    type: "goal",
    content: "修复刷新页面后被重定向到登录页的问题"
  },
  {
    type: "fact",
    content: "token 刷新后仍然存在于 localStorage",
    confidence: 0.95
  },
  {
    type: "fact",
    content: "/api/me 偶尔返回 401",
    confidence: 0.8
  },
  {
    type: "assumption",
    content: "问题可能与 axios 拦截器有关",
    confidence: 0.6
  },
  {
    type: "constraint",
    content: "不要修改后端接口返回结构"
  }
];

这种结构很重要。

因为模型需要知道哪些是事实，哪些只是猜测。
否则它会把用户的猜测当成确定结论。

GPT 和 Codex 的高阶使用，本质上就是不断降低模型误解上下文的概率。

五、上下文工程的第二原则：让模型知道“不要做什么”

很多人只告诉模型要做什么，却不告诉它不要做什么。

这在 Codex 场景里尤其危险。

比如：

帮我优化订单模块。

模型可能会：

• 重构大量文件；
• 改变函数签名；
• 引入新依赖；
• 修改接口结构；
• 调整数据库字段；
• 删除它认为重复的逻辑；
• 改变项目风格。

这些都可能不是你想要的。

所以，上下文里必须包含边界。

比如：

# 不允许做的事
- 不要修改数据库结构；
- 不要改变接口返回格式；
- 不要引入新依赖；
- 不要重构无关模块；
- 不要删除历史兼容逻辑；
- 不要一次性修改超过 3 个文件；
- 如果需要大范围改动，先说明原因，等待确认。

这类限制不是多余的。

它们是安全边界。

如果写成程序结构，可以这样表示：

interface ExecutionBoundary {
  allowedFiles?: string[];
  forbiddenFiles?: string[];
  maxFilesChanged?: number;
  allowNewDependencies: boolean;
  allowDatabaseMigration: boolean;
  requireApprovalForHighRisk: boolean;
}

例如：

const boundary: ExecutionBoundary = {
  allowedFiles: [
    "src/pages/orders/**",
    "src/services/orderApi.ts"
  ],
  forbiddenFiles: [
    "src/database/**",
    "src/auth/**"
  ],
  maxFilesChanged: 3,
  allowNewDependencies: false,
  allowDatabaseMigration: false,
  requireApprovalForHighRisk: true
};

一个没有边界的 Agent，很容易过度执行。

而软件工程里，很多事故不是因为没做功能，而是因为动了不该动的地方。

六、上下文工程的第三原则：把“验收标准”写进上下文

很多 AI 输出看起来不错，但无法判断是否完成。

原因是任务没有验收标准。

比如：

帮我提高代码可维护性。

什么叫提高了？

函数变短算不算？
重复代码减少算不算？
命名更清楚算不算？
测试更多算不算？
复杂度下降算不算？

如果没有验收标准，模型会按自己的理解处理。

而工程任务必须可验收。

例如：

# 验收标准
1. 不改变订单列表原有查询结果；
2. 新增筛选项可以正确传递给接口；
3. 接口失败时页面显示错误提示；
4. loading 状态正常；
5. 不新增第三方依赖；
6. 相关测试通过；
7. 输出修改文件列表和改动说明。

对应程序结构：

interface AcceptanceCriteria {
  id: string;
  description: string;
  verificationMethod: "test" | "manual" | "static-check" | "review";
  required: boolean;
}

例如：

const criteria: AcceptanceCriteria[] = [
  {
    id: "AC-001",
    description: "订单列表原有查询结果不受影响",
    verificationMethod: "test",
    required: true
  },
  {
    id: "AC-002",
    description: "新增筛选项能正确传递给接口",
    verificationMethod: "manual",
    required: true
  },
  {
    id: "AC-003",
    description: "不新增第三方依赖",
    verificationMethod: "static-check",
    required: true
  }
];

验收标准的作用，是把“感觉完成了”变成“可以判断是否完成”。

GPT 和 Codex 越进入真实工作流，验收标准越重要。

因为模型可以生成，但结果是否合格，必须有明确标准。

七、上下文窗口不是记忆，真正的记忆需要管理

很多人把上下文窗口理解成模型记忆。

其实不准确。

上下文窗口只是模型当前能看到的信息。
记忆则是跨任务、跨时间、跨会话沉淀下来的信息。

在复杂项目中，真正有价值的不是把所有东西一次塞进上下文，而是建立可检索、可更新、可过滤的记忆系统。

比如一个项目里可能有这些长期信息：

技术栈：React + Node.js
状态管理：Zustand
UI 库：Ant Design
接口规范：统一返回 { code, data, message }
权限系统：基于 role + permission
数据库：PostgreSQL
代码规范：不允许引入未审批依赖
历史决策：订单导出暂不支持异步任务
风险记录：支付模块不可由 AI 自动修改

这些信息不应该每次都重新告诉模型。

它们应该成为项目记忆。

可以设计成：

interface ProjectMemory {
  projectId: string;
  techStack: string[];
  conventions: string[];
  apiContracts: string[];
  forbiddenActions: string[];
  historicalDecisions: Decision[];
  riskAreas: RiskArea[];
}

例如：

const memory: ProjectMemory = {
  projectId: "order-admin",
  techStack: ["React", "Node.js", "PostgreSQL"],
  conventions: [
    "API response must use { code, data, message }",
    "Frontend services are placed in src/services",
    "Do not introduce new dependencies without approval"
  ],
  apiContracts: [
    "Order list API supports pagination",
    "Export API must respect current filters"
  ],
  forbiddenActions: [
    "Do not modify payment settlement logic automatically",
    "Do not change database schema without review"
  ],
  historicalDecisions: [
    {
      date: "2026-01-10",
      decision: "Order export uses synchronous CSV for MVP",
      reason: "Data volume is currently acceptable"
    }
  ],
  riskAreas: [
    {
      module: "payment",
      level: "critical",
      rule: "human approval required for any change"
    }
  ]
};

这才是真正的上下文工程。

不是每次写更长的 Prompt，而是构建一个可持续的上下文资产。

八、RAG 不是简单搜索，而是上下文装配

很多人把 RAG 理解成“从知识库里搜索资料，再让模型回答”。

这个理解太浅。

在 GPT 和 Codex 的高阶使用里，RAG 更像是上下文装配系统。

用户提出任务后，系统需要判断：

这个任务需要哪些信息？
哪些文件最相关？
哪些历史决策需要加载？
哪些风险规则需要加载？
哪些测试标准需要加载？
哪些信息不应该加载？

也就是说，RAG 的关键不是“搜到更多”，而是“装配正确”。

一个上下文装配流程可能是：

用户目标
  ↓
识别任务类型
  ↓
检索相关代码
  ↓
检索项目规范
  ↓
检索历史决策
  ↓
检索风险规则
  ↓
压缩无关信息
  ↓
生成任务上下文
  ↓
交给模型推理

如果写成代码结构：

interface ContextAssemblyInput {
  userGoal: string;
  taskType: "bugfix" | "feature" | "refactor" | "analysis" | "document";
  projectId: string;
}

interface AssembledContext {
  goal: string;
  relevantFiles: FileContext[];
  conventions: string[];
  constraints: string[];
  risks: RiskArea[];
  acceptanceCriteria: AcceptanceCriteria[];
  historicalDecisions: Decision[];
}

async function assembleContext(
  input: ContextAssemblyInput
): Promise<AssembledContext> {
  const taskType = classifyTask(input.userGoal);

  const relevantFiles = await retrieveRelevantFiles(input.projectId, input.userGoal);
  const conventions = await retrieveConventions(input.projectId, taskType);
  const risks = await retrieveRiskRules(input.projectId, relevantFiles);
  const historicalDecisions = await retrieveDecisions(input.projectId, input.userGoal);
  const acceptanceCriteria = generateAcceptanceCriteria(taskType, input.userGoal);

  return {
    goal: input.userGoal,
    relevantFiles,
    conventions,
    constraints: buildConstraints(taskType, risks),
    risks,
    acceptanceCriteria,
    historicalDecisions
  };
}

这就是高阶 RAG。

它不是知识搜索，而是任务上下文构建。

对于 Codex 来说，这尤其重要。

因为代码任务不是看一个文件就能完成。
它需要加载正确文件、正确规范、正确历史、正确风险。

上下文装错了，模型再强也会做错。

九、上下文压缩：高阶使用中最容易被忽略的能力

模型上下文窗口再大，也不可能无限承载信息。

所以必须进行上下文压缩。

但压缩不是简单摘要。

好的压缩要保留：

任务相关事实
关键约束
因果关系
风险点
历史决策
代码结构
未解决问题

同时丢弃：

重复信息
无关讨论
过期方案
低价值日志
和当前任务无关的文件
已经被否定的猜测

例如一个项目会议记录很长，直接丢给模型可能很混乱。

更好的方式是压缩成：

# 当前任务相关摘要

目标：
- 给订单列表增加异常订单筛选能力。

已确认：
- 后端已有 orderStatus 字段；
- 前端当前筛选组件支持动态配置；
- 异常状态包括 timeout、refund_failed、manual_review。

约束：
- 不修改订单主表结构；
- 不影响现有订单状态枚举；
- 先只做前端筛选和接口参数传递。

风险：
- orderStatus 与 afterSaleStatus 容易混淆；
- 旧导出接口不支持异常状态筛选。

待确认：
- 导出功能是否也需要同步支持该筛选条件。

这种上下文比一万字聊天记录更有用。

可以用结构表示：

interface CompressedContext {
  summary: string;
  confirmedFacts: string[];
  constraints: string[];
  risks: string[];
  openQuestions: string[];
  outdatedInformation: string[];
}

上下文压缩能力决定了 AI 能否参与长期任务。

没有压缩，信息会越来越乱。
压缩不好，重要信息会丢失。
压缩准确，模型才能在长周期任务中保持方向。

十、上下文污染：AI 系统中最隐蔽的风险

上下文工程里有一个非常重要的问题：上下文污染。

所谓上下文污染，就是错误、过期、不确定或无关的信息进入模型上下文，并影响后续判断。

比如：

用户曾经猜测 bug 是接口问题，但后来证明不是。
如果这个猜测仍然留在上下文里，模型可能继续围绕接口排查。

或者：

项目曾经计划使用异步导出，但后来决定暂不做。
如果旧计划仍然被检索出来，模型可能错误设计异步任务。

或者：

某段代码已经废弃，但仍然被 RAG 当成相关文件召回。
模型可能基于废弃代码生成方案。

这就是上下文污染。

它比普通错误更危险，因为它会让模型在错误前提下做出看起来合理的推理。

所以，成熟的上下文系统必须有状态管理。

例如：

type ContextStatus =
  | "active"
  | "deprecated"
  | "rejected"
  | "uncertain"
  | "confirmed";

interface ManagedContextItem {
  content: string;
  status: ContextStatus;
  updatedAt: string;
  source: string;
  confidence: number;
}

上下文不应该只是文本堆积。

它应该有生命周期。

新信息进入
  ↓
被确认
  ↓
被使用
  ↓
被更新
  ↓
可能过期
  ↓
被废弃或归档

未来 AI 系统的可靠性，很大程度取决于它能不能管理上下文污染。

十一、Codex 的真正难点：不是生成代码，而是维护工程上下文一致性

单独生成一个函数并不难。

难的是在一个真实项目里做修改，同时保持上下文一致性。

例如你修改一个订单状态字段，可能要同步考虑：

前端类型定义
接口请求参数
后端 DTO
数据库枚举
状态展示文案
筛选条件
导出逻辑
权限判断
测试用例
文档说明

如果只改一个地方，系统就会不一致。

Codex 的高级能力，应该不是“写出这段代码”，而是理解这种一致性网络。

可以把工程上下文看成一张图：

OrderStatus
  ├── frontend/types/order.ts
  ├── frontend/pages/OrderList.tsx
  ├── frontend/services/orderApi.ts
  ├── backend/dto/orderQuery.dto.ts
  ├── backend/services/orderService.ts
  ├── backend/repositories/orderRepository.ts
  ├── tests/orderQuery.test.ts
  └── docs/order-status.md

修改一个节点，可能影响多个节点。

这就是工程上下文图。

如果写成结构：

interface ContextGraphNode {
  id: string;
  type: "file" | "function" | "type" | "api" | "test" | "doc";
  name: string;
}

interface ContextGraphEdge {
  from: string;
  to: string;
  relation: "imports" | "calls" | "defines" | "tests" | "documents" | "depends-on";
}

interface EngineeringContextGraph {
  nodes: ContextGraphNode[];
  edges: ContextGraphEdge[];
}

未来 Codex 类工具如果要真正可靠，就不能只看文件文本，而要理解工程上下文图。

因为软件不是文件集合，而是依赖网络。

十二、上下文工程会成为 AI 时代的新基础设施

如果 GPT 和 Codex 越来越多地进入工作流，那么上下文工程就会变成基础设施。

未来很多团队可能不只是维护代码库，还会维护上下文库。

包括：

项目规范库
业务规则库
历史决策库
接口契约库
风险边界库
测试标准库
常见问题库
用户偏好库
任务模板库

这些内容过去也存在，只是散落在文档、聊天记录、会议纪要、代码注释和人的脑子里。

AI 时代，它们需要被结构化。

因为模型要用它们。

一个团队如果没有上下文资产，AI 就只能靠临时输入工作。
一个团队如果拥有高质量上下文资产，AI 就能更稳定地参与任务。

这就像过去企业重视数据资产。

未来可能还要重视上下文资产。

数据回答“发生了什么”。
上下文回答“为什么这样做、现在应该怎样做、不能做什么、历史上发生过什么”。

对 GPT 来说，上下文资产决定内容和决策质量。
对 Codex 来说，上下文资产决定代码修改是否可靠。

十三、未来程序员的新角色：上下文架构师

如果上下文工程变得重要，程序员的角色也会发生变化。

过去程序员主要写代码。
后来程序员还要设计架构、维护 CI/CD、管理云服务、关注安全和可观测性。
未来程序员可能还要设计 AI 可用的上下文系统。

也就是说，程序员不仅要写：

业务代码
接口代码
数据库代码
测试代码

还要维护：

工具描述
接口语义
任务边界
风险规则
上下文检索逻辑
Agent 可调用能力
验收标准模板

这是一种新的工程能力。

可以称为：

Context Architect

上下文架构师要思考：

哪些信息应该进入模型上下文？
哪些信息不能进入？
信息如何分类？
上下文如何压缩？
历史决策如何检索？
过期信息如何淘汰？
风险规则如何注入？
模型输出如何验证？

这不是传统 Prompt 技巧能解决的。

这是系统设计问题。

十四、真正高级的 AI 系统，是可控上下文系统

很多人判断 AI 系统好不好，只看模型强不强。

但未来真正高级的 AI 系统，可能不只是模型强，而是上下文系统强。

一个强上下文系统应该做到：

知道当前任务需要什么信息；
知道哪些信息已经过期；
知道哪些规则不能违反；
知道哪些文件最相关；
知道哪些历史决策必须参考；
知道什么时候需要人工确认；
知道如何压缩长上下文；
知道如何避免污染；
知道如何验证输出。

这比单纯调用模型复杂得多。

可以用一条管线表示：

User Goal
  ↓
Intent Classification
  ↓
Context Retrieval
  ↓
Context Filtering
  ↓
Context Compression
  ↓
Risk Injection
  ↓
Task Planning
  ↓
Model Execution
  ↓
Verification
  ↓
Context Update

最后一步很重要：Context Update。

AI 完成任务后，上下文系统也要更新。

例如：

本次做了什么决策？
哪些方案被否定？
哪些文件被修改？
哪些风险被发现？
哪些测试被新增？
哪些规则需要沉淀？

否则系统不会成长。

真正的 AI 工作流，不是一次性对话，而是上下文资产持续演化。

十五、结语：GPT 和 Codex 的高阶竞争，不在模型，而在上下文

GPT 和 Codex 让很多人第一次感受到 AI 的生产力。

但越往深处走，就越会发现：模型能力只是第一层。

真正决定效果的，是上下文。

没有上下文，GPT 只能生成通用内容。
没有上下文，Codex 只能写孤立代码。
没有上下文，Agent 只能凭空规划。
没有上下文，自动化执行就会失控。

上下文让模型从“回答问题”变成“参与任务”。
上下文让 Codex 从“生成代码”变成“理解项目”。
上下文让 AI 从“聪明聊天”变成“可靠协作”。

所以，未来真正重要的能力，不只是写提示词，而是构建上下文。

谁能更好地组织事实、目标、约束、记忆、风险和验收标准，谁就能更稳定地使用 GPT 和 Codex。

这也是为什么 AI 时代不会简单淘汰工程能力。

相反，它会让更深层的工程能力变得更重要。

因为模型可以生成结果，但上下文决定结果是否可靠。

GPT 和 Codex 的真正高阶使用，不是问得更花，而是让模型站在一个正确、干净、结构化、可验证的上下文里工作。

这才是从 Prompt Engineering 走向 Context Engineering 的核心变化。

未来的 AI 竞争，表面上看是模型竞争。
深入看，是工具竞争。
再往深看，是上下文工程竞争。

谁拥有更好的上下文系统，谁就能更好地调度智能。

而这，可能才是 GPT 和 Codex 背后最值得长期关注的技术命题。