AI 编程原理透视：Global、上下文与任务并行

为什么要理解原理？

你可能会问：工具能用就行，为什么要了解底层？

因为当你不理解机制时，你只能按教程操作；当你理解机制时，你能自己发明最佳实践。

工具在更新、文档在过期、场景在变化。但底层原理是相对稳定的——理解了它们，你就拥有了”第一性原理”思维，能快速适应任何新工具和新场景。

---

原理一：Global 视角——AI 如何”看到”你的项目

什么是 Global 原理

当 AI 编程工具开始工作时，它需要回答一个根本问题：这个项目是什么，它的结构是怎样的？

不同工具对这个问题的回答方式截然不同：

• Claude Code 采用”主动全局扫描”——启动时读取目录树、关键配置文件、git 历史，主动构建项目全貌
• Cursor 采用”按需局部获取”——只在你显式引用（@file）时才读取相关文件
• Codex 采用”快照隔离”——在沙盒中拥有仓库完整副本，但每次任务独立

这意味着什么

Claude Code 的全局视角带来的优势：当你说”重构 UserService 的接口”，它能自动找到所有引用了这个接口的文件并一并修改。不需要你手动指定哪些文件受影响。

但也有代价：全局扫描消耗上下文窗口容量。如果项目过大（数百个文件），AI 的注意力会被分散，对单个文件的编辑质量可能下降。

实践指导

• 大项目中使用 Claude Code：通过 CLAUDE.md 明确告诉它项目的关键模块和依赖关系，减少无效扫描
• 多仓库/monorepo：在子目录中运行 Claude Code，缩小 global 范围
• Cursor 中需要全局视角时：手动用 @folder 引入相关目录，弥补它不主动扫描的短板

---

原理二：上下文窗口——AI 的”工作记忆”

什么是上下文窗口

上下文窗口是 AI 模型一次能”看到”的全部信息量。你可以把它理解为 AI 的短期记忆容量。

关键认知：上下文窗口是有限的，而且越满，性能越差。

这不是简单的”超过限制就报错”——实际情况更微妙：

上下文使用量     AI 表现
   0-30%        最佳：精准理解、高质量输出
  30-70%        良好：偶尔丢失细节
  70-90%        下降：开始忽略早期信息
  90-100%       糟糕：关键信息被截断或遗忘

上下文管理的三个层次

第一层：被动填充（大多数人的用法）

• 不断追加对话，直到 AI 开始”犯傻”
• 此时上下文已经污染，修复成本高

第二层：主动清理

• 定期开新对话
• 只在关键时刻手动指定相关文件
• 使用 compact/summarize 功能压缩历史

第三层：结构化上下文工程（最优实践）

• 用 Rules/CLAUDE.md 预设”始终可见”的核心信息
• 按任务粒度拆分对话（每个对话只做一件事）
• 利用 MCP 按需获取外部信息，而非一次性塞入

工具差异

维度	Claude Code	Cursor	Codex
上下文来源	对话 + 文件读取 + 命令输出	对话 + @引用 + Rules	仓库快照 + 任务描述
持久上下文	CLAUDE.md	.cursor/rules/	AGENTS.md
清理机制	/compact 命令	新对话	每个任务独立
容量感知	显示 token 用量	隐式管理	固定预算

实践指导

1. 写好 CLAUDE.md / Rules：把”AI 每次都需要知道的信息”固定下来，不要每次对话都重复说明
2. 一个对话只做一件事：修完 bug A 就开新对话修 bug B，避免无关信息污染上下文
3. 大文件不要全量引入：只引入相关函数/类，而非整个 1000 行文件
4. 利用 Git Diff：让 AI 只看变更部分，而非完整文件

---

原理三：任务并行——AI 如何同时做多件事

为什么需要并行

传统工作方式：等 AI 完成任务 A → 开始任务 B → 完成后开始任务 C。

但很多任务之间是相互独立的：修 bug A 和修 bug B 之间没有依赖关系，为什么要串行？

并行的底层机制

Cursor 的并行：多 Tab 对话

• 每个 Tab 是独立的 AI 对话
• 可以同时开 3-5 个 Tab 处理不同任务
• 限制：本地资源（CPU/内存）和 API 配额

Codex 的并行：多任务提交

• 每个任务在独立沙盒中执行
• 可同时提交多个不相关的修改请求
• 限制：任务间不能有依赖（因为彼此看不到对方的修改）

Claude Code 的并行：受限串行

• 单进程运行，本身不支持并行
• 但可以通过 subagent/多终端实例模拟并行
• 限制：多实例可能产生文件冲突

并行编排策略

识别可并行的任务——核心判断标准：两个任务是否修改同一个文件？

可以并行:
  - 修 component A 的 bug + 修 component B 的 bug
  - 写新组件 + 写测试用例（不同文件）
  - 修前端样式 + 修后端 API（不同层级）

不能并行:
  - 修 UserService + 修调用 UserService 的 Controller
  - 改数据库 schema + 改依赖该 schema 的查询
  - 重构接口 + 更新接口文档（有依赖顺序）

推荐工作流：

1. 识别当前迭代中的所有任务
2. 画依赖关系图，找出独立的任务组
3. 独立任务组分别用不同工具/实例并行执行
4. 有依赖关系的任务严格串行

并行的陷阱

• 文件冲突：两个并行任务修改了同一文件的不同位置 → Git merge 冲突
• 上下文不一致：任务 A 改了接口签名，任务 B 还在用旧签名 → 编译错误
• 过度并行：同时开太多任务，每个都做了一半 → 心智负担反而增加

最佳实践：并行度控制在 2-3 个任务为宜，确保你有能力审查所有并行输出。

---

三大原理的协同

这三个原理不是孤立的，它们相互影响：

• Global 视角决定上下文填充策略：AI 越”了解”项目全貌，就越需要精心管理上下文窗口
• 上下文容量限制并行度：每多开一个并行任务，就需要独立的上下文预算
• 并行需要 Global 信息来划分边界：只有理解项目的模块划分，才能判断哪些任务可以并行

   Global 原理
      ↓
  确定项目边界
      ↓
  划分独立模块  →  并行执行
      ↓
  分配上下文预算  →  控制信息密度

---

本章小结

原理	核心认知	实践要点
Global	AI 的项目认知范围决定输出质量	用 CLAUDE.md/Rules 预设关键信息
上下文	窗口容量有限且越满越差	单任务单对话，结构化信息管理
并行	独立任务可以同时执行	按依赖关系划分，控制并行度 2-3

理解这三个机制后，选择工具和调整用法就有了判断依据，不需要对每个新工具都从零试错。

最后验证日期：2026-06-13。各工具的全局扫描范围、上下文窗口大小和并行能力可能随版本更新变化，使用前请核对官方文档。