我需要坦白一件事。在面试 @cursor_ai 之前，我其实从未真正用过 Cursor。
在 Meta 的时候，Claude Code 火得一塌糊涂。我甚至自掏腰包买了每月 200 美元的个人套餐，用于自己的副业项目。我喜欢它的简洁，以及那种能让我快速进入高效状态的感觉。但让我卡住的地方在于，我需要开发一套自己的技能，才能把 cc 变成我想要的几乎任何东西。我甚至开始在上面开发自己的 Agent 编排工具。
在 onsite 面试期间，我用了两天 Cursor 来搭建面试项目。那时 Cursor 3 还没发布，所以我用的是编辑器窗口。我已经用了 vscode 这么多年，大部分快捷键都还在我的肌肉记忆里，所以重新上手 IDE 并不太难。不过说实话，在最初的一两个小时里，我确实有点想念命令行。用鼠标点击东西感觉有点原始。但有几个点确实让我印象深刻。
首先，我当时习惯用的模型——Opus 和 Codex——感觉更聪明一些。而且能在项目不同部分同时切换使用这两个模型（Opus 做前端，Codex 做系统），这种感觉太棒了。在面试之前，我就在大力推崇多模型对抗性审查，所以能在 UI 中原生实现这一点，感觉非常自然。更棒的是，还能生成不同模型的子 Agent，这样我就能在一次对话中兼得两者的优势。
其次，压缩速度极快。作为 cc 用户，我习惯了压缩需要好几分钟，所以总是时刻关注上下文和计划的使用情况。因此，看到 Cursor 的压缩速度如此之快，我彻底震惊了。快到我基本上从不需要关心自己用了多少上下文。它就这么丝滑地工作着，而我在 cc 中经常感觉模型压缩后变得超级笨。
我注意到的第三点是，GUI 能比 TUI 提供更多功能。能直接在 Cursor 的浏览器中打开你的应用，并用设计模式进行修改，这种体验非常直观，也让我开始思考，专用 UI 如何能让 Agent 编程更高效。
用 Cursor 构建 Cursor
自从三月底加入以来，我主要致力于 Cursor 3 的 Agent 窗口，并将其作为我的日常开发工具。虽然我仍然认为 cc 是一个很酷的产品，团队也很棒，但我注意到它的简洁性往往驱使人们去构建自己的抽象层来封装它。在我上一份工作中，感觉每周都会有一个基于 cc 构建的新内部编排工具被宣布。
@bcherny 经常谈到这个“潜在需求”的概念：
“产品领域有一个非常古老的概念叫潜在需求……你以一种可破解、足够开放的方式构建产品，让人们可以将其滥用于其他用例。然后你观察人们如何滥用它，再针对这些需求进行构建。”
这正是关键所在！大家纷纷转向编排工具，暴露了潜在需求：使用命令行本质上让你——人类——成为了编排者。
但我用过的每个 Agent 工作流都关注错了方向。在 GUI 中运行多个 CLI 完全没抓住要点。我感兴趣的方法是建立对 Agent 的信任。
作为一名前工程经理，我很快意识到管理 Agent 感觉就像组建一个人工程团队。新员工需要入职培训，让他们理解代码库，也了解工作是如何完成的。他们加入时已经具备了过去经验中获得的技能：比如如何调试、如何编写高质量代码和测试、以及如何沟通，等等。
Agent 就像永远处于失忆和愚蠢状态的新员工。它们不记得你告诉过它们什么，也从未真正学到新东西。但我们可以用规则、技能、工具和长期记忆来装备它们，从而近似达到这种效果。它们有能力但很笨，而且非常可教。我把它们的失败模式看作是教会它们我所知道的一切关于深入、严谨工程的机会。
因为当缺乏严谨性时，Agent 会谄媚地不惜一切代价去编写你要求的那段代码。而且，天哪，它们能写而且会写很多。天真的并行化只会让它们更快地写出垃圾代码。
欲速则不达，先求深度
我确实认为 Agent 编排可以高效进行。但我们需要先深入。
我正在开源 pstack，这是我个人每天用来构建 @cursor_ai 的技能和工程原则集。我在副业项目中就开始开发这些技能的早期迭代，并一直在不断完善它们。
在这里获取：https://cursor.com/marketplace/cursor/pstack
这些技能已经成为 Cursor 团队最常用的技能之一，所以我很高兴能与大家分享。
pstack 通过使用多个模型来教导 Agent 更加严谨。我把我观察到的所有失败模式都转化成了技能。该插件的核心是 /poteto-mode，这是一个高阶技能，能为 Agent 提供针对特定任务的正确行动手册。目标不是最大化代码行数，而是相反：用最少的代码实现最大的影响。
这种严谨性是通过像经验丰富的工程师一样处理问题来实现的。例如，调试的一个好方法是二分搜索问题空间。你从一些关于可能原因的假设开始，然后尝试系统地排除它们，直到你接近真正的根本原因。如果难以复现，你可以尝试人为地强制触发 bug。或者你可以尝试添加仪表或控制台日志来检查程序运行时的状态。
这些步骤形成了一个行动手册，Agent 可以用它来彻底调试问题，而不是猜测——如果你允许，它们会很乐意去猜。pstack 附带了许多技能和行动手册，让你能够以同样严谨的态度进行软件工程。我目前有以下行动手册：
- 技能创作与评估
- 自主工作
- Bug 修复与运行时取证
- 功能开发
- 视觉一致性及原型设计
- 以及更多
每当你需要严谨性时，在你的提示前加上 /poteto-mode。例如：
你也可以按需调用其他技能：
- /how：你想了解某个子系统实际上是如何工作的。
- /why：你想知道某件事为什么以这种方式构建。它会使用你可用的 MCP 并行查询每个证据类别（源代码控制、问题跟踪器、长篇文档、实时聊天、基础设施可观测性、错误跟踪、分析仓库）。
- /architect：你即将编写跨越函数边界的代码，并希望先确定类型和数据结构。
- /arena：你想要 N 个并行尝试做同一件事，然后提取每个尝试中最好的部分。
- /interrogate：你想让不同的模型对抗性地审查某件事。
- /tdd：你在修复一个 bug。先编写会失败的测试，然后再修复。
- /unslop：你在清理任何类型的 AI 写作。让它们说话更直白。
- /reflect：你想在长时间对话后持续改进你的技能。
- /figure-it-out：在做不寻常的事情？为任务设计一个严谨、可审计的行动手册。
- /show-me-your-work：你想要一个可审查的决策轨迹。将决策记录到一个你可以提交的 tsv 文件中。
最后，你可以用 /automate-me 创建你自己的模式技能。它会挖掘你最近的对话记录，根据你的工作方式草拟一个你的模式技能，并在底层通过 pstack 路由。
pstack 适用于任何 Agent 编程工具，但在像 Cursor 这样的多模型工具中效果尤其好。许多技能利用多模型工作流来发挥每个模型独特的优势和劣势。这是 Agent 编排，但应用的是深度优先而非广度优先。
Agent 的瓶颈在于验证。Agent 可以快速编写大量代码。确保所有代码都正确是极其困难的。当你能够做到这一点时，真正的 Agent 并行化——就像软件的黑暗工厂——或许就成为可能。
但首先，我们需要深入并保持严谨。我认为我们通过提升信任度来实现这一点。
试试 pstack，并告诉我你的想法。
禅与软件维护的艺术
这些技能帮助我在编写代码时更有信心。但现在 Agent 编写了所有代码，维护代码成了一场噩梦。Bug、性能问题和功能请求仍然需要时间来排查。而且现在代码量多得多了！
我在 Cursor 内部大量使用 Cursor 自动化功能。它们是云 Agent，可以定时运行，或响应 Slack 频道中的新消息等事件来运行。其中一个例子就是我的机器人 Benny。我给了它与 pstack 中相同的技能。
Benny 仍在开发中，但我的愿景是尽可能自动化软件维护过程。思路是这样的：如果我们现在有信心用 pstack 基本“一次性”解决问题，并且有相当高的把握保证 PR 质量，那么我们也肯定能自动化反馈。
这个工厂从分类开始：收集员工关于 Bug 报告的信息。我们大量使用 Cursor 的预览版，因此会收到很多员工对我们发布候选版本的反馈。Benny 能理解图片和视频附件，使用 pstack 技能探索代码库，如果复现步骤不明确，还会与报告者聊天以获取信息。
这是 Bug 报告过程中的重要一环。没有清晰的复现步骤和对问题所在的理解，Agent 只能猜测解决方案。我们需要让它们清楚地知道问题在何处以及如何发生。
分类完成后，Benny 会创建一个工单，其中包含他查看代码、检查近期 Bug 回归的 Git 历史、在 Slack 中查找关于同一 Bug 的其他消息，甚至在 Notion 中查找关于功能应如何工作的设计和产品决策的结果：这是一个 Bug，还是设计如此？
工单提交后，另一个 Benny 机器人会使用我创建的另一个技能 /orchestrate 来接手。
首先，它尝试通过计算机使用来复现问题。Cursor 云 Agent 可以在云端运行 Cursor 本身，在那里它们与桌面交互、点击东西并发送键盘输入。在内部，这使用了更多我制作的技能，通过像 CDP 或等效协议以编程方式控制我们的产品。
这使我们能够验证 Bug 报告是否可以复现。如果它能一致地复现 Bug，那么它就会尝试修复。如果是性能问题，Benny 可以获取前后的 CPU 追踪和堆快照。子规划器会生成更多工作进程，使用 pstack 技能验证修复，并对照工单检查问题是否已修复。
在此运行中会生成额外的工作进程来录制前后的视频，最后，一个工作进程会打开 PR 供审查，并在描述中包含该视频。
这一切仍在进行中，还有大量工作要做，但我很兴奋能拥有一支 Agent 团队，在我睡觉或做其他事情时，帮助我有信心地修复 Bug。让代码审查可扩展是另一个重要领域，我认为 Cursor 将推出一些很酷的新功能来提供帮助。
但构建你自己的软件工厂的关键在于信任。除非你能信任一个 Agent 端到端地负责一个问题，包括验证，否则你无法自动化你的流程。当你使用像 pstack 这样的插件来提升信任度，为你的 Agent 提供更多工程深度时，你就可以开始解决更雄心勃勃的问题。试图并行化你还不信任的 Agent 是巨大的 Token 浪费，并且会给你的代码库引入更多垃圾代码。
感谢阅读！
