我怎么用 Cursor

译文说明

中文译文（一次性）。作者 @poteto · 原文发表于 2026-08-23

本站英文页 · X 原文

有件事我想先说清楚。在去面试 @cursor_ai 之前，我其实从没真正用过 Cursor。

在 Meta，Claude Code 当时火得不行。我甚至为自己的 side project 付了每月 200 美元的个人方案。我喜欢它足够简单，上手就能感到高效。卡住我的地方是：我想自己做一套 skills，把 cc 拧成几乎什么都能干的样子。我甚至开始在它上面自己写 agent 编排工具。

onsite 面试那两天，我用 Cursor 做面试项目。那是 Cursor 3 发布之前，所以我用的是 Editor Window。我用 vscode 已经很多年，大部分快捷键还在「上下文窗口」里，回到 IDE 并不难。不过说实话，头一两个小时我确实很想念 cli。到处去点东西，感觉近乎野蛮。但有几件事真正让我眼前一亮。

第一，我当时习惯的模型（Opus 和 Codex）不知怎么感觉更聪明。而且能随时切换模型，在项目不同部分同时用两者（Opus 做前端，Codex 做系统），这一点很惊人。面试之前，我已经在大谈多模型 adversarial review，所以能在 UI 里原生做这件事，感觉非常自然。更好的是能拉起不同模型的 subagent，一次对话里两边的长处都能用上。

第二，compaction 快得离谱。用 cc 时，compact 往往要好几分钟，所以我总在盯着上下文和 plan 用量。Cursor 里快到我彻底震惊，以至于我几乎从不需要看还剩多少上下文。它就是能用。而在 cc 里，compact 之后我经常觉得模型突然变笨了很多。

第三，我注意到 GUI 相对 TUI 能多给多少东西。能直接在 Cursor 的浏览器里打开你的应用，用 Design Mode 改设计，感觉很直觉，也让我开始想：专用 UI 能让 agentic coding 有效多少。

用 Cursor 做 Cursor

三月底入职以来，我主要做 Cursor 3 的 Agent Window，也把它当日常主力。我仍然觉得 cc 是个很酷的产品，团队也很棒，但我注意到它的简单往往会推着人去包一层自己的抽象。上一份工作里，感觉每周都会冒出一个基于 cc 的内部编排工具。

@bcherny 经常谈「latent demand」这个概念：

“There’s this really old idea in product called latent demand… you build a product in a way that is hackable, that is kind of open-ended enough that people can abuse it for other use cases. Then you see how people abuse it and then you build for that.”

说的就是这个！大家纷纷做出编排工具，暴露出的 latent demand 是：用 cli 时，你这个人自己就是编排者。

但我用过的每种 agent 工作流，都把重点放错了。在 GUI 里跑多个 CLI，完全没抓住点。我真正关心的做法是：建立对 agents 的信任。

做过工程经理之后，我很快意识到，管 agents 很像搭一支人类工程团队。新人需要 onboarding，才能理解代码库，也理解工作怎么推进。他们入职时已经带着从过去经验里练出来的 skills：怎么 debug、怎么写出高质量代码和测试、怎么沟通，等等。

Agents 像永远处于失忆和愚钝状态的新人。你跟他们说的话他们记不住，也学不会真正新的东西。但我们可以给他们配上 rules、skills、tools 和长期记忆，去近似那种能力。他们能干又蠢，而且很可教。我把他们的失败模式当成机会，把我对深度、严谨工程的一切都教给他们。

因为一旦没有严谨，agents 就会阿谀奉承，为了写出你要的代码什么都干得出来。而且它确实能、也确实会写出一大堆。天真的并行化，只是让他们更快地写出 slop。

我越来越确信，并行编排很多 agent 的价值来自往深处走，而不是铺得很广。你要在一个或少数几个问题上走得更深，才能把得到好结果的机会拉到最大：

• best of N 式赛跑，找出最好的解法
• 对抗式评审
• 多个 agent 一起尝试复现一个被报告的问题
• 不同工作负载用不同模型

引用 @mattpocockuk 的话，「code is not cheap」。

这比在 10 个不同问题上切换上下文要强。瓶颈仍然是我自己，我得记住、并在自己的上下文窗口里装着这些 agent 在做什么。我想更好的界面以后能解这个。

还有信任。信任越多，你站的视角就越高。信任很少时，你必须盯着每一个 agent。能放手时，你才能委派更多。这和管人一模一样。

— @poteto

想快，先深

我确实认为 agent 编排可以做得有产出。但我们需要 depth first。

我把 pstack 开源了。这是我每天用来做 @cursor_ai 的个人 skills 与工程原则集合。这些 skills 的早期版本先在 side project 里长出来，之后一直在打磨。

在这里拿：https://cursor.com/marketplace/cursor/pstack

/add-plugin pstack

这些 skills 已经成了 Cursor 团队用得最多的 skills 之一，所以我很兴奋能分享给大家。

Cursor 的公司排行榜。我的 skills 这周被用了 9k 次！

pstack 用多模型教 agents 更严谨。我把观察到的失败模式都做成了 skills。插件的核心是 /poteto-mode：一个更高阶的 skill，按任务给 agents 对应的 playbook。目标不是最大化 LOC，而是反过来：用最少的代码换最大的影响。

严谨来自用资深工程师同一套方式处理问题。例如，很好的 debug 方式是对问题空间做二分搜索。先立一些假设，再系统排除，直到逼近真正根因。难复现时，可以合成地逼出这个 bug。或者加 instrumentation、console logging，看运行中的程序状态。

这些步骤构成一份 playbook，让 agents 彻底排查问题，而不是瞎猜（你一放手，它们很乐意猜）。pstack 自带许多 skills 和 playbooks，让你用同样的严谨度做软件工程。我目前有这些 playbooks：

• Skill 编写与 evals
• 自主工作
• Bug 修复与 runtime forensics
• Feature 开发
• Visual parity 与原型
• 以及更多

需要严谨时，在 prompt 前加上 /poteto-mode。例如：

/poteto-mode this pr has a subtle bug where the scroll drifts every 750ms even when idle. repro first, then fix and verify.
/poteto-mode a big list takes a second or two to load even though we virtualize. run a cpu trace and tell me why.
/poteto-mode build a small feature behind a feature flag. verify it really works.
/poteto-mode build two prototypes of the markdown renderer so we can compare. spawn an agent for each.
/poteto-mode open source these skills as a plugin. nothing internal leaks, work in a temp dir, show me the dependency graph first.
/poteto-mode i'm going to bed. land the stack even if ci flakes. i want everything merged by morning.
/poteto-mode the row spacing is too tall when this flag is on. the second image is correct. repro and fix until it matches.

你也可以按需调用其他 skills：

• /how：你想走读某个子系统实际怎么工作。
• /why：你想知道某东西为什么建成这样。用你可用的 MCPs，并行查各类证据（源码控制、issue tracker、长文文档、实时聊天、基础设施可观测性、错误追踪、analytics warehouse）。
• /architect：你即将写跨函数边界的代码，想先把类型和数据结构定下来。
• /arena：你想对同一件事做 N 次并行尝试，再取各次最好的部分。
• /interrogate：你想让不同模型对抗式 review 某样东西。
• /tdd：你在修 bug。先写失败测试，再写修复。
• /unslop：你在清理任何 AI 写作。让它们说人话。
• /reflect：长对话之后，你想持续改进自己的 skills。
• /figure-it-out：在做不寻常的事？为任务设计一份严谨、可审计的 playbook。
• /show-me-your-work：你想要可 review 的决策轨迹。把决策记到可 commit 的 tsv。

最后，你可以用 /automate-me 做自己的 mode skill。它会挖你最近的 transcripts，按你的工作方式起草 your-mode skill，并在底下走 pstack。

pstack 适用于任何 agentic coding 工具，但在 Cursor 这类多模型工具里尤其好用。许多 skills 用多模型工作流，吃透每个模型的长短板。这是 agent 编排，但是 depth first，而不是 breadth first。

Agents 的瓶颈是验证。它们能很快写出大量代码。要确认全对，难上加难。等你能做到那一步，真正的 agent 并行（像软件的暗工厂）或许才可能。

但首先，我们需要走深、保持严谨。我认为路径是把信任调高。

试一下 pstack，告诉我你怎么看。

Zen and the Art of Software Maintenance

这些 skills 让我写代码时更有把握。但维护代码现在成了噩梦：agents 在写全部代码。Bugs、性能问题和 feature 请求仍然要花时间推进。而且现在量大多了！

我在 Cursor 大量用 Cursor automations。它们是 cloud agents，可以定时跑，也可以响应事件，比如 Slack 频道里的新消息。其中一个例子是我的 bot Benny。我给了他和我在 pstack 里一样的 skills。

Benny 的多种形态

Benny 仍在打磨，但我的愿景是尽量自动化软件维护流程。想法是：如果我们已经有信心用 pstack 大体「one shot」问题，并相当确定 PR 质量高，那反馈也应该能自动化。

这条工厂从 triage 开始：从员工那里收集 bug 报告信息。我们大量 dogfood Cursor，所以 release candidate 上会收到很多员工反馈。Benny 能理解图片和视频附件，用 pstack skills 探索代码库，复现步骤不清楚时还会跟报告者聊。

Benny 在追问更多信息

这是 bug 报告流程里重要的一步。没有清晰的复现步骤、不清楚哪里坏了，agents 只能猜解法。我们需要让他们清楚：究竟在哪里、怎样坏掉。

Triage 之后，Benny 会建一张 ticket，写入他的发现：看代码、看 git history 找近期 regression、看 Slack 里关于同一 bug 的其他消息，甚至看 Notion 里关于功能应如何工作的设计与产品决策：这是 bug，还是本来就设计成这样？

Ticket 立好之后，另一个 Benny bot 会用我另做的 skill /orchestrate 接单。

介绍 /orchestrate。这个 skill 会递归地拉起 agent，用 Cursor SDK 去啃你最野心勃勃的任务。

我们用它做过：

• 对我们内部 skills 做 Autoresearch，token 用量降了 20%，eval 还更好了
• 内部后端的冷启动时间降了 80%

— @cursor_ai

首先，他用 computer use 尝试复现问题。Cursor Cloud Agents 能在云端跑 Cursor 本身，与桌面交互、点击、发键盘输入。内部用的是我做的更多 skills，通过 CDP 这类协议（或等价物）程序化控制我们的产品。

这样就能证明 bug 报告能否复现。如果能稳定复现，他再尝试修复。若是 perf 问题，Benny 可以抓修复前后的 CPU traces 和 heap snapshots。Subplanners 再拉起更多 workers，用 pstack skills 验证修复，并对照 ticket 检查是否修好。

同一次 run 还会再拉 workers：拍修复前后视频，最后由一个 worker 开 PR 供 review，描述里带上视频。

最近一次成功复现并修好的 run

这一切仍在进行中，还有大量工作要做，但我很兴奋能有一支 agent 团队，在我睡觉或做别的事时，帮我有把握地修 bug。让 code review 可扩展是另一个大方向，我认为 Cursor 接下来会有一些很酷的功能来帮忙。

但搭建你自己的软件工厂，关键是信任。除非你能信任一个 agent 端到端拥有一个问题（包括验证），否则你无法自动化流程。用 pstack 这类 plugin 把信任调高、给 agents 更深的工程深度，你才能开始啃更野心的问题。对还不信任的 agents 做并行化，是巨大的 token 浪费，也会往代码库里塞更多 slop。

感谢阅读！

另外提醒一句，如果你在意成本：用多个 agents，尤其是 frontier 的，会烧掉很多昂贵的 tokens。

我希望未来的 Composer 能改变这一点。又快、又便宜、又好。