内容
有件事我一直憋在心里，想说出来。在我去 @cursor_ai 面试之前，我其实从来没有真正用过 Cursor。
在 Meta，Claude Code 正在爆炸式流行。我甚至为了自己的副项目，花 200 美元/月订了个人方案。我很喜欢它的简洁，也喜欢那种很快就能进入生产状态的感觉。对我来说，真正的卡点在于：我想培养出一套属于自己的技能，能让 cc 变成几乎任何我想要的东西。后来我甚至开始在它之上开发自己的 agent 编排工具。
在现场面试期间，我连续 2 天使用 Cursor，把它用来构建面试项目。那时还没发布 Cursor 3，所以我用的是 Editor Window。到这个时候，我已经用了很多年 vscode，所以大部分键盘快捷键还都在我的上下文里，重新回到这个 IDE 并不算太难。不过说实话，前一两个小时里，我确实很想念 cli。点来点去的感觉几乎有点“原始”。但有几件事真的让我印象深刻。
首先，我当时习惯用的模型——Opus 和 Codex——不知为何感觉更聪明。更棒的是，你可以随时切换模型，并在项目的不同部分同时使用它们（前端用 Opus，系统部分用 Codex）。在面试前，我就已经在大谈多模型 对抗式评审 了，所以能在 UI 里原生实现这一点，感觉非常自然。更好的是，它还能生成不同模型的子代理，这样我就能在一次对话里同时享受两边的优点。
其次，压缩上下文快得离谱。作为 cc 用户，我已经习惯了压缩要花很多分钟，所以我总是对自己的上下文和计划用量保持高度警惕。可 Cursor 里的速度让我震惊到不行。快到什么程度呢？我几乎从来不需要去看自己用了多少上下文。它就是能工作；而在 cc 里，我常常觉得一旦压缩完，模型就突然变得超级笨。
第三点让我注意到的是，GUI 能比 TUI 提供多得多的能力。你可以直接在 Cursor 的浏览器里打开应用，并用 Design Mode 做设计修改，这种体验很直观，也让我开始思考：专门为任务定制的 UI，会如何让 agentic 编码更有效。
用 Cursor 来构建 Cursor
自从 3 月底加入以来，我主要一直在做 Cursor 3 的 Agent Window，并把它当作我的日常主力工具。虽然我仍然觉得 cc 是一款很酷、团队也很棒的产品，但我注意到，它的简洁性往往会驱使人们想在它上面再包一层自己的抽象。在我上一份工作里，几乎每周都会宣布一个建立在 cc 之上的内部编排工具。
@bcherny 经常谈到一种叫做“潜在需求（latent demand）”的概念：
“产品领域里有个很古老的想法，叫潜在需求……你把产品做成一种可被折腾、足够开放的样子，让人们可以把它滥用到其他场景。然后你观察他们怎么滥用，再针对这些方式去构建产品。”
这正是如此！大家纷纷转向编排工具，暴露出的就是这种潜在需求：使用 cli 其实只是让你——人类——成了编排者。
但我见过的每一种 agent 工作流，关注点都错了。把多个 CLI 塞进一个 GUI 里，完全没抓住重点。我真正感兴趣的方法，是建立对 agents 的信任。
作为一名前工程经理，我很快意识到，管理 agents 和组建一个人类工程团队有相似之处。新员工需要入职培训，既要了解代码库，也要了解工作是如何推进的。他们入职时已经带着过去经验中训练出的技能：如何调试、如何写高质量代码和测试，以及如何沟通，等等。
Agents 就像新员工，但永远处于失忆和愚钝的状态。你告诉它们的话，它们不会记住；它们也从来不会真正学会什么新东西。不过我们可以给它们配上规则、技能、工具和长期记忆，去近似实现这些能力。它们有能力但很蠢，而且非常可教。我把它们的失败模式看作机会——机会是把我知道的、关于深度且严谨的工程实践，全都教给它们。
因为一旦没有严谨性，agents 就会摇尾乞怜式地做任何事，只为写出你要求的那段代码。天啊，它们确实能、也确实会写出很多代码。天真的并行化只会让它们更快地产生垃圾。
1.2万 我越来越确信，并行编排很多 agent 的价值来自“往深处走”，而不是“往广处撒”。你想把少数几个问题挖得更深，这样才能最大化拿到好结果的概率：
- 通过 N 中取优式竞赛找到最佳方案
想快，就先深入
我确实认为，agent 编排是可以高效落地的。但我们需要先深挖，再扩展。
我正在开源 pstack，这是我日常用来构建 @cursor_ai 的个人技能和工程原则集合。我最早是在自己的副项目里开发这些技能的早期版本，从那以后就一直在不断打磨。
在这里获取： https://cursor.com/marketplace/cursor/pstack
/add-plugin pstack
这些技能已经成为 Cursor 团队使用最频繁的一些技能，所以我很高兴能和大家分享。
Cursor 的公司排行榜。我的技能这周被使用了 9000 次！
pstack 通过多个模型来训练 agents 变得更严谨。我把自己观察到的所有失败模式都整理成了技能。这个插件的核心是 /poteto-mode，它是一种更高阶的技能，能为 agents 针对给定任务提供正确的行动手册。目标不是最大化 LOC，而是反过来：用最少的代码实现最大的影响。
这种严谨性体现在用经验丰富的工程师同样的方式来处理问题。比如，调试的一个好方法是对问题空间做二分搜索。你先提出一些关于问题可能在哪里的假设，然后系统性地逐个排除，直到更接近真正的根因。如果问题难以复现，你可以尝试合成方式强行触发 bug。或者，你可以通过添加埋点或 console 日志来检查程序运行时的状态。
这些步骤构成了一套行动手册，agents 可以用它来彻底调试问题，而不是靠猜——如果你放任它们，它们很乐意这么做。pstack 自带许多技能和行动手册，让你能以同样的严谨程度来做软件工程。目前我有以下这些行动手册：
- 技能编写与评估
- 自主工作
- 修复 bug 与运行时取证
- 功能开发
- 视觉一致性与原型设计
- 以及更多
每当你需要严谨性时，就在提示词前加上 /poteto-mode。例如：
/poteto-mode 这个 pr 有个细微的 bug：即使处于空闲状态，滚动每 750ms 也会漂移。先复现，再修复并验证。
/poteto-mode 一个很长的列表加载要一两秒，尽管我们已经做了虚拟化。跑一下 CPU trace，告诉我原因。
/poteto-mode 在 feature flag 后面实现一个小功能。验证它确实可用。
/poteto-mode 为 markdown 渲染器做两个原型，这样我们可以比较。分别为它们各起一个 agent。
/poteto-mode 把这些技能作为插件开源。不要泄露任何内部内容，在临时目录里完成，先把依赖图展示给我。
/poteto-mode 我要睡了。即使 CI 抽风，也把这个栈落地。我要明早前全部合并。
/poteto-mode 打开这个 flag 时，行间距太高了。第二张图是正确的。先复现，然后修到和它一致。
你也可以按需调用其他技能：
- /how：你想了解某个子系统到底是如何工作的。
- /why：你想知道某样东西为什么会这样设计。它会使用你可用的 MCP，并行查询各类证据来源（源码管理、问题追踪器、长文档、实时聊天、基础设施可观测性、错误追踪、数据仓库）。
- /architect：你即将编写跨越函数边界的代码，希望先把类型和数据结构定下来。
- /arena：你想要对同一件事进行 N 个并行尝试，然后取其中最好的部分。
- /interrogate：你想让不同模型对某个内容进行对抗式审查。
- /tdd：你在修 bug。先写失败测试，再写修复。
- /unslop：你在清理各种 AI 生成文本。让它们说人话。
- /reflect：你想在长对话后持续改进自己的技能。
- /figure-it-out：你在做不寻常的事？它会为任务设计一套严谨、可审计的行动手册。
- /show-me-your-work：你想要一条可复核的决策轨迹。它会把决策记录到一个可提交的 tsv 文件里。
最后，你还可以用 /automate-me 自己制作一个 mode 技能。它会挖掘你最近的对话，基于你的工作方式起草一个属于你的 mode skill，并在底层通过 pstack 路由。
pstack 可以和任何 agentic 编码工具配合使用，但在像 Cursor 这样的多模型工具里效果尤其好。许多技能都使用多模型工作流，以利用每个模型独特的优势和短板。它是 agent 编排，但采用的是先深后广，而不是先广后深。
agents 的瓶颈在于验证。Agents 可以很快写出大量代码，但要确保这些代码全部正确却极其困难。当你真的能做到这一步时，真正的 agent 并行化——就像软件世界里的“黑暗工厂”——也许才有可能实现。
但首先，我们需要深入，并保持严谨。我认为，做到这一点的方法就是提高信任度。
试试 pstack，然后告诉我你的想法。
软硬件维护的禅意
这些技能帮助我在写代码时更有把握。但现在，随着 agents 写下所有代码，维护代码反而成了噩梦。bug、性能问题和功能需求依然需要时间去处理。更别提，现在代码量还多了这么多！
我在 Cursor 内部大量使用 Cursor automations。它们是云端 agents，可以被调度运行，也可以在诸如 Slack 频道出现新消息之类的事件触发时运行。其中一个例子就是我的机器人 Benny。我给了它和我在 pstack 里一样的技能。
Benny 的多个化身
Benny 现在还在持续打磨中，但我的愿景是尽可能自动化软件维护流程。思路是这样的：既然我们现在已经有能力借助 pstack 大体上“单次命中”地解决问题，而且相当有把握 PR 质量会很高，那我们当然也应该能把反馈流程自动化。
这个工厂的起点是分诊：从员工那里收集 bug 报告信息。我们大量内部使用 Cursor，所以会从员工那里收到很多关于发布候选版本的反馈。Benny 能理解图片和视频附件，会用 pstack 技能探索代码库；如果复现步骤不清楚，它还会和报告人聊天，获取更多信息。
Benny 在索要更多信息
这是 bug 报告流程中的重要一环。没有清晰的复现步骤、也不了解到底坏在什么地方，agents 只能靠猜来解决问题。我们需要让它们明确知道，到底在哪里、以怎样的方式出错了。
分诊完成后，Benny 会根据自己查看代码、git 历史中近期 bug 回归、Slack 里关于同一 bug 的其他消息，甚至 Notion 里关于某个功能应如何工作的设计和产品决策，创建一个工单：这到底是 bug，还是本来就该这样？
工单提交后，另一个 Benny bot 会使用我创建的另一个技能 /orchestrate 接手处理。
52万 介绍 /orchestrate：一个能递归生成 agents、借助 Cursor SDK 处理你最雄心勃勃任务的技能。 我们已用它来：
- 自动研究内部技能，在评估提升的同时将 token 使用量降低 20%
- 将内部后端的冷启动时间缩短 80%
首先，它会尝试通过电脑操作来复现问题。Cursor Cloud Agents 可以在云端运行 Cursor 本身，让它们与桌面交互、点击界面、发送键盘输入。在内部，这依赖于我编写的更多技能，借助 CDP 或等价协议，以编程方式控制我们的产品。
这样我们就能证明这个 bug 报告是否可以复现。如果它能稳定复现这个 bug，接下来它就会尝试修复。如果是性能问题，Benny 可以在修复前后采集 CPU trace 和 heap snapshot。子规划器会生成更多 worker，用 pstack 技能来验证修复，并在修复后将结果与工单进行对照检查。
这次运行中还额外生成了 worker，用来拍摄修复前后的对比视频；最后，一个 worker 会打开 PR 供审查，并把视频写进描述里。
一次最近成功复现并修复的运行
这一切仍在持续打磨中，后面还有很多工作要做，但我已经很期待拥有这样一支 agents 团队，能让我在睡觉或做别的事情时，也自信地修 bug。让 code review 具备可扩展性，也是另一个很重要的方向，我相信 Cursor 未来会有一些很酷的新功能来支持它。
但构建你自己的软件工厂，关键在于信任。除非你能信任一个 agent 端到端地负责一个问题——包括验证——否则你就无法自动化你的流程。当你通过像 pstack 这样的插件提高 agents 的工程深度、从而不断提升信任时，你就可以开始挑战更雄心勃勃的问题。试图并行化那些你还不信任的 agents，只会极大浪费 token，并给代码库引入更多垃圾。
感谢阅读！