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

为什么要理解原理？

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

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

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

---

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

什么是 Global 原理

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

三个工具的做法相近：启动时先读项目约定文件，然后边做边搜，用到哪些文件再读哪些文件。差别在搜索方式和运行位置：

• Claude Code：启动时读 CLAUDE.md（或 AGENTS.md）、当前分支、未提交的改动和最近的提交记录；之后用文件名匹配和全文搜索找代码，读到哪个目录，就再加载那个目录下的约定文件
• Cursor：同样先读 Rules 和 AGENTS.md；除了文件名和关键词搜索，还会给代码库建语义索引，能按意思找到相关代码；你也可以用 @ 手动指定文件
• Codex：本地 CLI 直接在你的仓库里搜索；云端任务会在独立的工作区里拿到一份仓库副本，每个任务互不影响

这意味着什么

好处：当你说”重构 UserService 的接口”，工具能自己搜出所有引用这个接口的文件并一并修改，不需要你手动列出受影响的文件。

代价：每读一个文件、每跑一次搜索，结果都要占用上下文窗口。项目越大、任务描述越模糊，工具读进来的无关内容越多，留给真正要改的代码的空间就越少。

实践指导

• 在约定文件里写清项目地图：关键模块在哪个目录、改哪里要先看哪里，工具就不用自己摸索
• 多仓库或 monorepo：在子目录里启动工具，或者给子目录单独写一份约定文件，缩小搜索范围
• 你已经知道相关文件时：直接在任务里写出路径（Cursor 用 @ 引用），省掉搜索这一步

---

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

什么是上下文窗口

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

关键认知：上下文窗口是有限的，装得越满，早期的细节越容易被忽略。

快满的时候，工具会自动压缩：先清掉较早的命令输出，再把对话总结成摘要。摘要会保留你的需求和关键代码，对话早期交代的细节规则可能丢失。所以需要长期遵守的规则要写进约定文件，压缩之后工具会重新读取它。

上下文怎么管

上下文要分层管理：始终可见的项目约定写进约定文件，每次任务只交代相关文件和完成标准，迭代中的反馈和外部资料按需补充。具体分层和模板见 上下文工程实战。

工具差异

维度	Claude Code	Cursor	Codex
上下文来源	对话 + 文件读取 + 命令输出	对话 + 语义搜索 + @引用 + Rules	对话 + 仓库内容 + 命令输出
持久上下文	CLAUDE.md 或 AGENTS.md	.cursor/rules/ 和 AGENTS.md	AGENTS.md
清理机制	自动压缩，也可手动 /compact	新对话	新会话；云端每个任务独立
查看用量	/context 列出每类内容占了多少	对话界面显示	会话界面显示

实践指导

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：并行代理

• 同一个需求最多可以同时交给 8 个代理，每个代理自动分到一个 git worktree
• 也可以交给云端代理在远程机器上跑，关掉电脑也不影响
• 限制：并行越多，你要审查的结果越多

Codex：多个云端任务

• 每个任务在独立工作区里执行，可以同时提交多个不相关的修改请求
• 结果以 diff 呈现，确认后再提交或开 PR
• 限制：任务之间看不到对方的修改，有依赖的任务不能同时跑

Claude Code：子代理和多会话

• 子代理在自己的上下文窗口里完成搜索或调研，只把结论交回主对话
• 用 git worktree 给每个会话一个独立目录，可以同时跑多个会话；桌面应用和网页版会自动处理这一步
• 限制：多个会话改同一个文件，合并时会冲突

并行编排策略

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

可以并行:
  - 修 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-10-01。各工具的全局扫描范围、上下文窗口大小和并行能力可能随版本更新变化，使用前请核对官方文档。