拆解 Cursor：上下文工程与人在环透明度
用技术地基五层与 Harness 框架拆 Cursor，看它如何把整个 codebase 喂进有限窗口、用 diff 守住信任。
这篇怎么读
这是一篇「实战示例」，目的不是评测 Cursor 好不好用，而是把课程里那套抽象框架架在一个真实产品上，看它能照出什么。Cursor 是当下最成熟的 AI 编程 IDE 之一，公开材料多、设计决策清晰，正好当标本。
读的时候请始终带着两个问题：第一，课程框架的每一个透镜（技术地基五层、L3 五维、Harness、上下文工程）落到这个产品上分别对应哪个具体功能；第二，哪些设计是「因为它是 IDE 而不是纯 chat」才成立的。
一句话定位与本质区别
Cursor 是一个把 LLM 编程能力深度嵌进编辑器的 AI-first IDE：它在 VSCode 的交互骨架上，叠了一套从「补全」到「自主修改多文件」的连续 AI 参与光谱。
它和「纯 chat 编码」（你在对话框里贴代码、让模型回一段代码、你再复制回去）的本质区别有三点：
- 上下文不是你手动贴的，而是产品替你检索的。纯 chat 里模型只看见你贴进窗口的片段；Cursor 主动把整个 codebase 索引成可检索的语义库，按需把相关片段拉进上下文。这是它最核心的工程能力。
- 动作不是「返回文本」，而是「落到文件系统」。纯 chat 的输出终点是一段文字，需要人来搬运；Cursor 的输出终点是一次 apply，直接改你的工作区文件，再用 diff 让你确认。
- 参与度是连续的而非二元的。纯 chat 只有「问/答」一种模式，Cursor 有 Tab、Chat（Ask）、Agent 三档，对应从零认知负担到全自主执行。
这三点决定了：Cursor 的难点不在「模型会不会写代码」，而在「上下文怎么组织」和「人怎么留在环里」。
用框架看 Cursor
技术地基五层
| 层 | Cursor 的对应实现 | 看点 |
|---|---|---|
| Loop | Agent 模式是 gather→act→verify 的多轮自主循环；Tab 是单步补全，不构成循环 | 同一产品里同时存在「无循环」和「全循环」两种形态 |
| Tool | 读文件、grep/语义检索、编辑文件、跑终端命令；Agent 可多次调用 | 工具集围绕「编辑器能做的事」收敛，边界清晰 |
| Planning | Agent 接到任务先拆步骤再逐个执行；多文件任务隐含一个执行计划 | 计划对用户半透明，体现在它逐个文件改 |
| Memory | Rules（项目/全局规则）做长期记忆；单次会话上下文做短期记忆 | 记忆是「显式维护」而非自动学习，规则需人写 |
| Multi-Agent | Cloud Agent 可并行跑多个任务；主线仍以单 agent 为主 | 多 agent 更多是「并行任务」而非「分工协作」 |
L3 五维行为透镜
| 维度 | Cursor 的表现 |
|---|---|
| 任务路径 | 用户给意图 → 检索相关代码进上下文 → 模型生成编辑 → 以 diff 呈现 → 用户 apply 或拒绝。路径在 UI 上几乎全程可见 |
| 失败节点 | 检索召回不全（漏了关键文件）、编辑与现有代码冲突、终端命令报错。多文件编辑里失败点更密集 |
| 错误恢复 | 终端报错后 Agent 可读取报错再修；diff 被拒后可重试；编辑器原生 undo 兜底 |
| 透明度 | Cursor 设计的重心：每一次修改都先以 diff 预览，apply 前需确认；命令执行可设为需确认 |
| 边界行为 | 写文件、跑命令这类有副作用的动作通过确认机制和权限设置拦在闸门后，而非默默执行 |
上下文工程：把整个 codebase 喂进有限窗口
这是 Cursor 最值得细看的地方。任何真实项目的代码量都远超模型上下文窗口，所以核心问题永远是「窗口有限，代码无限，怎么选」。Cursor 的解法是一条典型的检索增强（RAG）流水线：
- 索引：对整个仓库做切分与 embedding，建成一个可语义检索的代码库。这一步是后台完成的，用户无感。
- 检索：每次请求时，根据当前意图、打开的文件、光标位置等信号，召回最相关的代码片段。
- 组装：把召回片段、当前文件、用户显式 @ 引用的文件、以及 Rules 一起拼成发给模型的上下文。
- 显式覆盖：用户可以用 @file、@folder、@symbol 等方式手动把特定上下文钉进窗口，纠正自动检索的偏差。
这套设计的精髓在于「自动检索为主、显式引用兜底」：默认让产品替你选上下文以降低认知负担，但永远留一个手动通道，让用户在检索召回不准时能强行修正。这正是课程里说的上下文工程核心权衡——在窗口预算约束下，用检索质量换取覆盖广度，同时给人一个逃生口。
Harness 五子系统视角
| 子系统 | Cursor 的落点 |
|---|---|
| 上下文管理 | codebase 索引 + 语义检索 + @ 显式引用 + Rules |
| 工具/动作执行 | 文件读写、终端、语义搜索，统一收敛在编辑器能力内 |
| 控制流 | Tab / Chat / Agent 三档参与光谱，由用户选择介入深度 |
| 安全与权限 | apply 前 diff 确认、命令执行确认、规则的多级优先级 |
| 反馈与可观测 | diff 预览、终端输出回流、编辑器内联展示，让人随时看见 agent 在干什么 |
它选择「IDE 即载体」而非「CLI 即载体」：IDE 提供了天然的 UI 表面，能同时承载补全、对话、自主三种模式，也能把 diff、内联建议这类视觉反馈做得很重——纯命令行很难承载这么丰富的人在环交互。
关键洞察：最值得学的设计决策
- Tab 补全的低延迟黏性。 Tab 是高频、零认知负担的单步补全，每分钟都在触发，形成肌肉记忆级的使用习惯。它对延迟极度敏感——慢一点就毁掉手感，所以这一档在工程上是独立优化的，不能用 Agent 那套重链路。启示：高频轻动作和低频重动作要分开设计。
- Composer/Agent 的多文件编辑。 真实改动往往跨多个文件（改接口要连带改调用方），单文件补全解决不了。Agent 把「跨文件协同修改」做成一次任务，并用统一的 diff 视图呈现所有改动。难点在于召回全、改得一致、让人看得懂。
- 人在环的 diff 确认。 这是信任的锚点。模型再强也会出错，Cursor 不赌「模型一定对」，而是把每次修改拦在 apply 前，用 diff 让人扫一眼再放行。它把「控制权」留给人，把「生产力」交给模型——这正是当前 AI 编码产品能被信任的底线设计。
- 参与光谱而非单一模式。 同一个产品里，简单场景用 Tab，探索用 Chat，重活交 Agent。不强迫用户在「全自动」和「全手动」之间二选一，而是给一条连续滑杆。
对做 Agent 的启发清单
- 先把「上下文从哪来」想清楚再写 prompt。窗口永远不够，检索/筛选/组装的策略比 prompt 措辞更决定上限。先画一张「上下文构成表」：哪些自动来、哪些用户显式给、哪些常驻（规则）。
- 自动检索一定要配显式覆盖通道。再好的召回也有失手的时候，给用户一个 @file 式的强行钉入手段，是低成本高回报的兜底。
- 有副作用的动作必须有确认闸门。写文件、跑命令、发请求这类不可逆动作，默认走「预览 + 确认」。diff 是预览的最佳形态——让人一眼看清「改了什么」而不是「要改什么」。
- 按动作频率分层设计，别用一个循环套所有。高频轻动作优化延迟、砍认知负担；低频重动作可以慢、可以多轮、可以要确认。
- 让 agent 的每一步可见。任务路径、正在调的工具、产生的 diff、终端的报错，都要回流到界面上。透明度不是锦上添花，是用户敢把控制权交出去的前提。
- 记忆要不要自动化是一个明确取舍。Cursor 选了显式维护的 Rules（可控、可审计），代价是要人写。先想清楚你要「可控」还是「省事」。
模型能力决定上限，但上下文工程决定你能不能逼近上限，人在环的透明度决定用户敢不敢用。这三件事，比「接哪个模型」重要得多。