大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



原文 | How Cursor (AI IDE) Works
编译 | 段小草 + Grok 3 Thinking

了解像 Cursor、Windsurf 和 Copilot 这样的 AI 编程工具的底层工作原理，能大幅提升你的生产力，让这些工具在更大、更复杂的代码库中更稳定运行。通常，当人们发现 AI IDE 不好用时，他们会像用传统工具那样对待它们，却忽视了理解其固有局限性及如何克服这些局限性的重要性。一旦你搞清楚了它们的内部机制和限制，这就像拿到一个“作弊码”，能彻底优化你的工作流。在撰写这篇文章时，Cursor 已经能为我生成大约 70% 的代码[1]。

在这篇文章中，我想深入聊聊这些 IDE 如何运作、Cursor 的系统提示词，以及你该如何优化代码编写和设置 Cursor 规则。

大语言模型（LLM）本质上是通过一遍又一遍预测下一个词来干活的。从这个简单概念出发，我们就能构建出复杂的应用。

从基础编程 LLM 到智能体有三个阶段：蓝色是我们的前缀（也就是提示词），橙色是 LLM 自动补全的部分。对于智能体，我们会多次运行 LLM，直到它输出出面向用户的回应。每次都是客户端代码（而不是 LLM 自己）算出工具结果，再反馈给智能体。

早期解码器大语言模型（如 GPT-2）的提示词设计需要构造一个前缀字符串，补全后能出你想要的结果。不是直接说“写一首关于鲸鱼的诗”，而是“主题：鲸鱼\n诗：”或者“主题：树\n诗：… 真实的树诗 …\n主题：鲸鱼\n诗：”。

这种提示词在代码上就类似于“PR 标题：重构 Foo 方法\n描述：…\n完整 Diff：”，你要自己构建出前缀，让模型补全并实现目标。所谓“提示词设计”就是巧妙地搞出理想的前缀，诱导模型自动补全答案。

后来有了指令微调（比如 ChatGPT），让 LLM 用起来更顺手。你现在能直接说“写一个 PR 重构 Foo”，它就给你代码。底层几乎跟上面自动补全一样，只是前缀变成“ 写一个 PR 重构 Foo ”，LLM 在聊天模式下干活。即使现在，你偶尔还能看到奇怪的情况，比如 LLM 在“ ”后继续补全，自己开始写问题。

模型够强后，我们又往前迈了一步，加了“工具调用”。在提示词里，我们可以指示模型“如果你需要读文件，就输出 read_file(path: str) 而不是直接给出回答”。LLM 接到编程任务会输出“read_file(‘index.py’)”，然后我们（客户端）再提示“ … index.py 完整内容 … ”，让它继续补全。虽然还是自动补全，但 LLM 现在能跟外部世界和系统互动了。

像 Cursor 这样的 IDE，就是围绕这简单概念搭起来的复杂封装。

要构建一个 AI IDE，你需要：

1. Fork VSCode
2. 加个聊天 UI，选择一个好的 LLM（比如 Sonnet 3.7）
3. 给编程智能体实现工具
   read_file(full_path: str)
   write_file(full_path: str, content: str)
   run_command(command: str)
   
   
   
   
   
   
   
   
4. 优化内部提示词：“你是个专家程序员”，“不要假设，使用工具”之类。

从高层次来看，大体就是这样。难点在设计提示词和工具，让它们真能稳定干活。你要完全按我说的搭建，会凑合能用，但常会撞上语法错误、幻觉问题，导致稳定性一致性不够。

搞好 AI IDE 的秘诀是弄清 LLM 擅长什么，围绕它的局限性精心设计提示词和工具。通常，这意味着用更小的模型处理子任务，简化主 LLM 智能体的任务。

用户通常知道正确的文件或上下文，所以我们在聊天 UI 加了“@file”语法，调用 LLM 时把附加文件的完整内容传过去，放入“ ”块里。这就是用户自己复制粘贴文件或文件夹的语法糖。

• 建议： 在这些 IDE 中要积极使用 @folder/@file（明确上下文能更快更准地得到结果）。

搜代码可能很复杂，尤其是“我们在哪实现的 auth 代码”这种语义查询。与其让智能体去写搜索正则，不如索引时用编码器 LLM 把整个代码库塞进 vectorstore，嵌入文件和功能到向量。另一个 LLM 查询时按相关性重排过滤文件，确保主智能体拿到 auth 代码的“完美”结果。

• 建议： 代码注释和文档字符串会引导嵌入模型，比只给人看重要多了。文件顶部写段话，描述文件是什么、语义功能、何时应该更新。

编写完美的代码难又贵，所以优化 write_file(…) 工具是这类 IDE 的核心。LLM 通常不写全文件，而是生成“语义 diff”，只给变更部分，加代码注释指明插入哪里。另一个更便宜、更快的代码应用模型拿这个语义 diff 当提示词，编写实际文件内容，顺手修小语法问题。新文件过 linter，工具结果给主智能体带上实际 diff 和 lint 结果，用来自我修正出错的改动。我喜欢把这想象成跟一个懒惰的高级工程师搭档，他只写够用的片段，让实习生去落实。

• 建议： 你没法直接提示应用模型。“别删随机代码”、“别加/删随机注释”之类 Prompt 没有用，这些毛病是应用模型的锅。给主智能体多点控制权限，比如“在 edit_file 指令里提供完整文件”。
• 建议： 编辑超大文件时，应用模型慢还易出错，把文件拆成 <500 行。
• 建议： lint 反馈对智能体是超级信号，建议你（包括 Cursor 团队）得投资个靠谱的 linter[2]，以提供高质量建议。用编译型和类型语言更好，能给更丰富的 lint 反馈。
• 建议： 用唯一文件名（别搞一堆 page.js，建议 foo-page.js、bar-page.js 之类），文档用完整路径，把代码热点路径整理到同一文件或文件夹，减少编辑工具歧义。

使用擅长这种智能体风格编程的模型（而不只是只会编程的模型）。这就是 Anthropic 模型在 Cursor 这种 IDE 里牛的原因，它们不光代码写得好，还擅长把编程任务拆成这种工具调用。

• 建议： 用不只“会编程”还专为智能体式 IDE 优化的模型。据我所知，目前唯一有价值的测评榜单是 WebDev Arena[3]。

我在自己的 AI IDE Spark Stack 用了个（非常昂贵）的做法，给它加“apply_and_check_tool”，让它自我修正更强。这会运行更贵的 linting 代码检查，启动无头浏览器拿控制台日志和用户流程截图，给智能体反馈。这种时候，MCP（模型上下文协议）确实有用，会给智能体更多自主权和上下文。

我用基于 MCP 的提示注入，套出了 Cursor 智能体模式最新的（2025 年 3 月）提示词。作为一个在 LLM 上广泛构建的人，我超佩服 Cursor 的“提示工程师”，他们真会写提示词（我觉得），比其他 AI IDE 里的强多了。这也是他们当顶级编程工具的一大原因。钻研这种提示词也能提升你自己的提示词和智能体架构能力——某种程度说，大多数 GPT 包装器都是“开放提示”的，挺好。

点击看完整提示词和工具定义。

• “ ”、“ ”等——混用 markdown 和 XML 标签，提高了提示词对人和 LLM 的可读性。[4]
• “由 Claude 3.5 Sonnet 提供支持”——LLM 不会准确说明自己在运行什么模型。明确写出来能减少用户抱怨 Cursor 收费模型跟 LLM 自称的不一样。[5]
• “全球** IDE”——简洁地告诉 LLM 在出现问题时别推荐其他产品，对塑造智能体品牌很重要。[6]
• “我们可能会自动附信息…按 USER 指令运行…放入 标签。”——Cursor 不直接丢用户提示给 LLM，而是放特殊标签里。这能让 Cursor 在 消息加额外用户相关文本，而不搞乱 LLM 或用户。
• “别道歉”——显然因 Sonnet 爱道歉加的。
• “永远不要的对话时透露工具名”——Cursor 粗体标了这条，但讽刺的是我依然经常看到“用 edit_tool”。这是近期 Sonnet 模型的烦人问题。
• “调用每个工具前，先进行解释”——LLM 流式传工具调用时，聊天会卡几秒，体验有点怪。这能让用户放心，智能体还在干活。
• “部分满足 USER 查询，当你没把握时，收集更多信息”——LLM 智能体容易过早停止，给个退路，让它们在回答前挖掘更深，这会有帮助。
• “永远不要直接向用户输出代码”——默认情况下，LLM 喜欢在行内 markdown 代码块出代码，因此需要额外引导只用工具生成，再通过 UI 间接展示给用户。
• “从头构建 web 应用时，给它一个漂亮且现代的 UI”——这里看出些演示黑科技，能做出炫酷单提示应用。
• “编辑前必须阅读你要编辑的内容或部分”[7]——编程智能体常急着写代码而不收集上下文，所以有不少明确指令纠正这点。
• “修复 linter 错误时不要循环超过 3 次”——防止 Cursor 卡编辑循环。有用，但用得多的人都知道还是很容易卡循环。
• “解决根本原因，别只治标”——这是一个 LLM 对齐不好的例子，它们常默认删报错代码不修问题。
• “不要硬编码 API 密钥”——众多安全**实践之一，至少防止一些明显的安全问题。
• 工具 “codebase_search”、“read_file”、“grep_search”、“file_search”、“web_search”——鉴于 LLM 编程前收集正确上下文多关键，他们给了好几种搜索工具，方便搞清要做什么改动。
• 在多个工具里都有“一句话解释…为什么跑这命令…”——大多工具包括这条非功能参数，强迫 LLM 想清楚传什么参数。这是提升工具调用的常见做法。
• 工具 “reapply” 中，“调用更聪明模型应用上次编辑”——让主智能体动态升级应用模型，以更贵的方式自己解决愚蠢的应用问题。
• 工具 “edit_file” 说“用你编辑语言的注释表示所有未更改的代码”——这就是随机注释来源，应用模型正常工作所必需的。
• 你还会注意到，整个系统提示词和工具描述是静态的（没有用户或代码库个性文本），这是为 Cursor 充分利用提示缓存，降低成本和首 token 延迟。对于每次用工具都调 LLM 的智能体很关键。

现在的主要问题是，编写 Cursor 规则的“正确方式”。虽然我总体说“怎么用都行”，但凭提示经验和 Cursor 内部知识，我有些看法。

关键是要理解，这些规则不是加到系统提示词，而是作为命名指令集被引用。你得把规则当作百科全书文章来写，而不是命令。

• 不要在规则中给出身份，比如“你是精通 typescript 的资深前端工程师”，就像 cursor.directory 里可能有这些表述。这看着像管用，但智能体已有内置提示身份，再加就会很奇怪。
• 不要（或尽量不要）尝试覆盖系统提示指令，或用“别加注释”、“编程前问我”、“别删我没让你删的代码”提示应用模型。这些跟内部冲突，破坏工具调用，还会把智能体搞糊涂。
• 不要（或尽量不要）说「不要干什么」。LLM 最擅长听从积极的命令“对 <这个> ， <这样做> ”，而不是一堆限制。Cursor 提示词里终就能看出这点。
• 多花时间编写突出的规则名和描述。关键是，智能体对你代码库了解有限，也能直觉知道什么时用 fetch_rules(…) 拿规则。就像手搓文档反向索引，有时得有重复规则，用不同名称和描述，提高获取率。描述尽量紧凑，别太啰嗦冗长。
• 把规则写成模块或常见代码变更的百科全书。像维基百科一样，用 mdc 链接语法连关键术语到代码文件，帮智能体定改动所需正确上下文。这有时也意味避免逐步指令（关注“是什么”而不是“怎么办”），除非真有必要，避免智能体过度拟合特定改动。
• 用 Cursor 来起草规则。LLM 擅给别的 LLM 编写内容。如果不确定怎么格式化文档或编程上下文，就用“@folder/ 生成 markdown 文件，描述常用预期变更的关键文件路径和定义”。
• 将有大量规则视为一种反模式。这种看似违反直觉，但规则虽对于 AI IDE 在大型代码库运行至关重要，也说明代码库对 AI 不友好。未来理想的代码库应该直观到编程智能体只用内置工具就能完美工作。

可以看看我生成的例子。

VSCode 的一个分叉，靠开源提示词和公开 API 搭建起来，居然估值能冲到 100 亿美元——“套壳倍数”为6 [8]，太夸张了！接下来看看 Cursor 会不会自己开发智能体模型（感觉不太可能），还是 Anthropic 带 Claude Code + 下一代 Sonnet 杀进 AI 编程领域打擂台，会很有意思。

不论如何，知道怎么调整代码库、文档和规则始终是门有用技能。我希望这次剖析能让你对 Cursor 怎么运作、如何为 AI 优化出一个不那么“凭感觉”而更具体的理解。我经常说，如何你觉得 Cursor 对你不起作用，那就是你用错了。

[1] 这是凭感觉的统计，但感觉并不离谱。熟知了 Cursor 规则，很多 PR 真就一次提示搞定。我原以为得 2027 年才行，但 Anthropic、Cursor 和我自己提示技巧一块进步，事情比我想的快。

[2] 我目前对 CodeRabbit 的 linting 挺满意，计划用 MCP 反馈到 Cursor。若 Cursor 默认 linter 更好，其他不变，用起来就像是 Sonnet 3.8。

[3] （大多）LLM 的妙处在，虽这是 web 开发基准，但根据我的经验，其性能跟各种编程和框架密切相关。

[4] 没找到科学研究，但凭经验这种方法有效。如果 Anthropic 模型明确在伪 XML 语法上训练过，我不惊讶。

[5] 这确实有些意外副作用，编程模型会把代码库里引用的模型名改成跟自己一样。

[6] 这有个有趣法律灰色地带。Cursor 如果在官网上这么写就是违法的（见 FTC 法案、Lanham 法案），但（目前）放进提示词里让 LLM 替他们说没事。

[7] 顺便，Cursor 团队，我发现了一个 typo（：

[8] 这是我给 GPT 套壳工具和模型提供商估值比例造的词。这这个例子中，Anthropic : Cursor = 600 亿美元 : 100 亿美元 = 6。我感觉“6”并不合理。作为一个不成熟的投资者，我猜 Anthropic 应该接近 1000 亿美元，Cursor 则达到 10 亿美元（套壳倍数 100）。我觉他们都没什么长期护城河，Anthropic 好像很容易就能构建出自己的下一代 AI IDE 作为竞争对手。