Codex地球泡泡

plus 与 pro

过去谈 ChatGPT，很多人喜欢讲“提示词”。

怎么提问更准确？
怎么让 AI 按格式输出？
怎么让它一步一步思考？
怎么让它模仿某种语气？

这些问题当然有价值，但如果只停留在提示词层面，很容易把 AI 理解成一个更聪明的文本生成器。

真正更深的变化，其实不是提示词，而是上下文。

ChatGPT 和 Codex 代表的方向，并不是让人写出更漂亮的指令，而是让软件系统开始围绕“上下文”重新组织。

以前的软件系统，核心是流程。

输入什么，执行什么，输出什么。

现在，AI Agent 参与以后，系统的核心开始变成上下文。

它不仅要知道用户说了什么，还要知道任务目标是什么、已有状态是什么、代码仓库里有什么、文件之间怎么关联、哪些限制不能突破、结果应该如何验证。

从这个角度看，ChatGPT 和 Codex 的真正价值，不是“会回答”或“会写代码”，而是它们让软件系统进入了一个新的阶段：上下文驱动的执行系统。

---

一、提示词工程为什么不够了？

提示词工程解决的是单轮交互问题。

你给 AI 一个输入，希望它给你一个更好的输出。

比如：

请帮我写一个登录接口

或者：

请用专业、简洁的语气解释这段代码

这类任务本质上是“输入—输出”模式。

它适合文本生成，也适合简单代码生成。

但真实软件开发不是这样。

真实任务往往不是一句话能完成的。

比如：

把旧项目里的用户权限系统改成新的角色模型，
但不能影响现有后台账号登录，
需要保留历史数据兼容，
并补充对应测试。

这个任务就不是单纯提示词能解决的。

因为它涉及：

• 旧系统结构
• 数据库字段
• 权限模型
• 登录逻辑
• 后台管理
• 历史兼容
• 测试覆盖
• 风险控制
• 回滚策略

这时候，真正重要的不是“提示词写得好不好”，而是系统能不能组织足够完整的上下文。

也就是说，AI 要完成复杂任务，不能只靠一句指令，而要靠一个上下文系统。

---

二、什么是上下文工程？

上下文工程，可以理解为：

如何为 AI 提供正确、完整、可执行、可验证的任务背景。

它不是简单地把更多文字塞给模型，而是把任务相关的信息组织成一种结构。

一个完整的上下文，至少包含五层：

Context
├── Goal          任务目标
├── State         当前状态
├── Constraints   约束条件
├── Resources     可用资源
└── Verification  验证标准

如果映射到软件开发里，大概是这样：

AgentContext
├── user_intent          用户意图
├── repo_structure       项目结构
├── relevant_files       相关文件
├── dependency_graph     依赖关系
├── coding_rules         代码规范
├── business_constraints 业务限制
├── test_strategy        测试策略
└── rollback_plan        回滚方案

这已经不是简单提问了。

这是在为 AI 构建一个可执行环境。

ChatGPT 更擅长处理自然语言上下文，帮助人整理问题、拆解任务、形成方案。

Codex 更擅长处理工程上下文，围绕代码仓库、文件结构、修改目标和测试反馈推进任务。

两者结合，本质上是在把“人类语言”转化为“工程动作”。

---

三、从 Prompt 到 Context，系统结构发生了什么变化？

传统 AI 使用方式大概是这样：

User Prompt
    ↓
Model
    ↓
Text Output

这是最简单的人机交互结构。

但 Codex 这类工具参与工程任务后，结构会变成这样：

User Intent
    ↓
Context Builder
    ↓
Task Planner
    ↓
Code Executor
    ↓
Verifier
    ↓
Human Review

它不再是一个模型直接回答问题，而是一个多阶段系统。

可以抽象成这样的程序结构：

type AgentTask = {
  goal: string
  constraints: string[]
  context: ProjectContext
  plan?: ExecutionPlan
  result?: ExecutionResult
}

type ProjectContext = {
  files: FileNode[]
  dependencies: DependencyGraph
  conventions: CodingRule[]
  tests: TestCase[]
  risks: RiskPoint[]
}

type ExecutionPlan = {
  steps: Step[]
  affectedFiles: string[]
  verification: VerificationMethod[]
}

type ExecutionResult = {
  changedFiles: string[]
  summary: string
  testResults: TestResult[]
  warnings: string[]
}

这说明一个问题：

未来的 AI 编程，不是“模型生成代码”这么简单，而是围绕任务建立一个上下文生命周期。

任务从目标开始，经过上下文收集、计划生成、代码执行、测试验证，最后进入人类审查。

这就是从提示词工程走向上下文工程的本质变化。

---

四、Codex 的价值在于进入“项目上下文”

普通文本生成只需要理解一句话。

但软件开发必须理解项目。

这两件事完全不同。

一句话的上下文很短，而一个项目的上下文可能包括几百个文件、多个模块、历史提交、隐含约定、业务规则和测试体系。

如果 AI 不能进入项目上下文，它只能生成孤立代码。

孤立代码看起来可能很漂亮，但放进真实项目里未必能用。

比如，让 AI 写一个登录函数很容易：

function login(username: string, password: string) {
  // verify user
}

但真实项目的问题是：

• 用户表叫什么？
• 密码如何加密？
• Token 怎么生成？
• 是否有多租户？
• 是否支持验证码？
• 是否记录登录日志？
• 是否限制错误次数？
• 是否影响旧接口？
• 前端依赖什么返回格式？

这些信息不在提示词里，而在项目上下文里。

所以 Codex 的关键，不是写代码，而是读取、理解和修改真实项目。

它需要把代码仓库转化成可理解的上下文图谱。

可以抽象成：

Repository
├── File Tree
├── Symbol Index
├── Dependency Graph
├── Test Graph
├── Runtime Errors
├── Documentation
└── Change History

这就是为什么 Codex 比普通代码生成更接近“工程代理”。

它不是凭空写代码，而是在已有系统里做有限、可追踪、可审查的修改。

---

五、未来的软件系统会出现“Agent Layer”

传统软件系统一般分层如下：

Application
├── UI Layer
├── Service Layer
├── Domain Layer
├── Data Layer
└── Infrastructure Layer

但 AI Agent 进入后，系统可能会多出一层：

Application
├── Agent Layer
├── UI Layer
├── Service Layer
├── Domain Layer
├── Data Layer
└── Infrastructure Layer

这个 Agent Layer 不直接等同于业务层，也不等同于自动化脚本。

它负责理解意图、调用工具、编排任务、检查状态。

可以理解为系统中的“认知控制层”。

它可能包含：

Agent Layer
├── Intent Parser       意图解析
├── Context Retriever   上下文检索
├── Task Planner        任务规划
├── Tool Router         工具路由
├── Memory Manager      记忆管理
├── Action Executor     动作执行
├── Verifier            验证器
└── Human Gate          人类审批关口

这意味着，未来的软件不是简单增加一个聊天窗口，而是会把 AI 能力嵌入系统结构中。

用户不再只是点击按钮，而是表达目标。

系统不再只是执行固定流程，而是根据上下文组织行动。

比如传统系统是：

点击按钮 → 提交表单 → 保存数据

Agent 系统可能是：

描述目标 → 理解意图 → 查找相关数据 → 生成方案 → 执行动作 → 验证结果 → 请求确认

这就是软件交互范式的变化。

---

六、ChatGPT 是自然语言控制台，Codex 是工程执行器

可以把 ChatGPT 和 Codex 放在一个系统结构里看：

Human
  ↓
ChatGPT: Intent Interface
  ↓
Task Specification
  ↓
Codex: Engineering Executor
  ↓
Codebase / Tools / Tests
  ↓
Human Review

ChatGPT 更像自然语言控制台。

它帮助人把模糊想法变成清晰任务。

Codex 更像工程执行器。

它把任务落实到代码仓库、文件修改和测试反馈中。

两者之间需要一个关键中间层：任务规范。

Natural Language
    ↓
Task Specification
    ↓
Executable Steps
    ↓
Code Changes
    ↓
Verification

很多人用不好 AI，不是因为 AI 不够强，而是缺少中间这一层。

直接从自然语言跳到代码修改，风险很高。

正确结构应该是：

先定义任务
再生成计划
再执行修改
再验证结果
最后人工审查

这也是未来程序员的重要能力：不是直接让 AI 写代码，而是让 AI 按工程规范完成任务。

---

七、上下文工程的核心是“边界”

AI 最危险的地方，不是不会做事，而是不知道哪里不能做。

所以复杂任务里，边界比目标更重要。

目标告诉 AI 要做什么。

边界告诉 AI 不能做什么。

一个好的任务上下文应该包含：

goal:
  - 增加手机号登录支持

allowed_changes:
  - auth/service.ts
  - auth/controller.ts
  - tests/auth.test.ts

forbidden_changes:
  - database schema
  - existing password login behavior
  - token format
  - frontend response structure

verification:
  - old login tests must pass
  - new phone login tests must pass
  - no breaking API changes

这已经非常接近工程任务单。

它比一句“帮我加个手机号登录”更可靠。

因为它定义了权限边界、修改边界和验收边界。

未来 AI Agent 的稳定性，很大程度取决于边界设计。

边界不清楚，AI 越强越容易失控。

边界越清楚，AI 越像一个可靠执行线程。

---

八、程序员会从“代码作者”变成“上下文架构师”

过去程序员主要写代码。

后来程序员还要写文档、写测试、做架构、做协作。

到了 AI Agent 阶段，程序员会多一个角色：上下文架构师。

所谓上下文架构师，不是简单写提示词，而是设计 AI 能够理解和执行的任务环境。

这包括：

• 代码结构清晰
• 文档准确
• 测试完善
• 模块边界明确
• 命名一致
• 任务描述规范
• 变更可追踪
• 风险可回滚

从这个角度看，AI 不会让软件工程基本功变得不重要。

恰恰相反，它会让基本功更重要。

项目越规范，AI 越好用。

项目越混乱，AI 越容易犯错。

所以，未来最强的程序员，不一定是手写代码最快的人，而是最会组织上下文的人。

他知道如何把一个复杂系统整理成 AI 能理解的结构。

他知道如何把一个模糊需求转化成可执行任务。

他知道如何让 AI 在安全边界内完成工作。

---

九、上下文工程会重塑团队协作

以前团队协作主要依赖人脑记忆和口头沟通。

比如：

这个接口不能改，因为某个老客户在用。
这个字段虽然没用，但报表系统依赖它。
这个异常不能直接抛出，因为前端会白屏。
这个逻辑看起来奇怪，但和历史数据兼容有关。

这些信息如果没有写进文档、测试或代码注释，就属于隐性知识。

隐性知识对人类团队已经是问题，对 AI 更是问题。

因为 AI 不知道你们团队口口相传的规则。

所以 Agent 时代会倒逼团队把隐性知识显性化。

未来团队可能需要维护这样的文件：

/ai-context
├── project-overview.md
├── coding-rules.md
├── business-constraints.md
├── forbidden-changes.md
├── test-strategy.md
└── release-checklist.md

这些文件不只是给新人看的，也会成为 AI Agent 的上下文入口。

也就是说，文档会从“写给人看的说明”，变成“写给人和 AI 共同使用的系统接口”。

这是一种很大的变化。

---

十、真正高级的 AI 工作流不是生成，而是闭环

很多人看 AI，只看生成结果。

但工程系统里，生成只是开始。

真正可靠的工作流必须是闭环：

Plan → Execute → Test → Review → Iterate

对应到 Codex 场景，就是：

任务规划
  ↓
代码修改
  ↓
自动测试
  ↓
差异审查
  ↓
风险说明
  ↓
人工确认

可以抽象成一个 Agent Loop：

async function runAgentTask(task: AgentTask) {
  const context = await buildContext(task)

  const plan = await createPlan(task.goal, context)

  if (!humanApprove(plan)) {
    return stop("Plan rejected")
  }

  const result = await executePlan(plan, context)

  const testResult = await runTests(result.changedFiles)

  const review = await generateReview(result, testResult)

  return {
    plan,
    result,
    testResult,
    review,
    requiresHumanDecision: true
  }
}

这个结构说明：

AI 不应该绕过人。

AI 应该把更多中间过程结构化，让人更容易判断。

未来优秀的 AI 编程系统，不是让人完全消失，而是让人从重复劳动中上移到关键决策点。

---

十一、为什么说上下文比模型更重要？

很多人使用 AI 时，最关心模型强不强。

模型当然重要。

但在复杂工程任务里，上下文可能比模型还重要。

一个强模型，如果拿不到正确上下文，也会给出错误结果。

一个中等模型，如果上下文清晰、边界明确、验证完善，也可能完成稳定任务。

可以用一个公式表达：

AI Output Quality = Model Capability × Context Quality × Verification Strength

很多人只盯着 Model Capability。

但真正可控的部分，往往是后两项：

Context Quality
Verification Strength

上下文质量决定 AI 是否理解任务。

验证强度决定 AI 的错误能不能被发现。

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

它不是玄学，而是把 AI 的不确定性放进工程系统里管理。

---

十二、结语：AI 时代的软件工程，不是少写代码，而是重组系统

ChatGPT 和 Codex 带来的变化，不应该只被理解为“效率工具”。

它们真正推动的是软件系统组织方式的变化。

ChatGPT 让自然语言成为认知入口。
Codex 让代码仓库成为可委托对象。
上下文工程让 AI 从回答问题走向执行任务。

未来的软件开发，不会只是“人写代码”或“AI 写代码”的二选一。

更可能是一种新结构：

人定义目标
AI 组织方案
Agent 执行任务
测试系统验证结果
人类负责最终判断

这意味着程序员的价值不会消失，而是发生迁移。

从写代码，迁移到定义问题。
从处理细节，迁移到设计上下文。
从单点实现，迁移到系统调度。
从依赖经验，迁移到构建可验证流程。

真正高阶的 AI 使用，不是问出一个好答案，而是搭建一个让 AI 稳定完成任务的上下文系统。

提示词工程解决的是“如何让 AI 回答得更好”。

上下文工程解决的是“如何让 AI 做事做得更稳”。

从 ChatGPT 到 Codex，真正改变的不是某一段代码的生成方式，而是软件工程如何组织知识、任务和执行。