How I Use Cursor: pstack与Agent工程化的深度实践

✍ lauren🕐 2026-05-26📦 15.2 KB 🟢 已读 𝕏 文章列表

文章作者 lauren 分享了加入 Cursor 前后的编码体验对比，从使用 Claude Code 转向 Cursor，并深入探讨了如何通过 GUI 优于 CLI 的设计以及多模型对抗来提升效率。重点介绍了其开源的 pstack 插件，该插件通过一套严谨的技能和工作流，教导 AI Agent 像资深工程师一样进行二分法调试、代码审查和深度工作，以解决 AI 编码中常见的“平庸且快速”问题，倡导深度优于广度的 Agent 编排理念。

# How I Use Cursor **作者**: lauren **日期**: 2026-04-25T17:31:40.000Z **来源**: [https://x.com/poteto/status/2058975157503570132](https://x.com/poteto/status/2058975157503570132) --- ![Image](/doc/2245/image/img_f77debfba73a.jpg) I need to get something off my chest. Before my interview @cursor_ai, I had never actually used Cursor. At Meta, Claude Code was explosively taking off. I even paid for a personal $200 a month plan for my side projects. I loved how simple it was, and how quickly I could feel productive. The sticking point for me was in developing my own set of skills that turned cc into almost anything I wanted. I even started developing my own agent orchestrator tool on top of it. During my onsite interview, I used Cursor over the course of 2 days, using it to build the interview project. This was before Cursor 3's release, so I was using the Editor Window. I've been using vscode for so many years at this point that most of the keyboard shortcuts were still in my context window, so getting back on the IDE was not too difficult. I can't lie though. During the first hour or two I was certainly missing the cli. Clicking on things felt almost barbaric. But there were a few things that really stood out to me. First, the models I was used to at the time - Opus and Codex - felt smarter, somehow. And it was amazing being able to switch models on the fly and use both of them at the same time on different parts of my project (Opus for the frontend, Codex for systems). Prior to my interview, I was already raving about multi-model adversarial review, so being able to do this natively in the UI felt very natural. Even better was the ability to spawn subagents of different models, so I could get the best of both worlds in one conversation. Second, compaction was insanely quick. As a cc user I was used to compacting taking many minutes, and so I was always in a state of constant vigilance of my context and plan usage. So I was utterly shocked at how fast it was in Cursor. So much so that I basically never needed to look at how much context I was using. It just worked, while I often felt like the model just got super dumb after compaction in cc. And the third thing I noticed was how much GUIs could offer over TUIs. Being able to open your app directly in Cursor's browser and make design changes with Design Mode felt intuitive and got me thinking about how much purpose-built UIs could make agentic coding more effective. ## Building Cursor with Cursor Since joining at the end of March, I've been working primarily on Cursor 3's Agent Window, and using it as my daily driver. While I still think cc is a cool product with a great team, I have noticed that its simplicity tends to drive people to want to build their own abstractions wrapping it. In my last job, it felt like there was a new internal orchestrator tool built on top of cc announced every week. @bcherny talks a lot about this idea of "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." This was exactly it! Folks converging on orchestration tools exposes the latent demand in that using a cli just makes you, the human, the orchestrator. But every agent workflow I had used was focused on the wrong thing. Running multiple CLIs in a GUI was missing the point entirely. The approach I was interested in was building trust in agents. As a former engineering manager, I quickly realized that managing agents felt similar to building a human engineering team. New hires need to be onboarded so they understand the codebase, but also how work gets done. They join already pre-trained with skills they acquired from their past experiences: how to debug, how to write high quality code and tests, and how to communicate, to name a few. Agents are like new hires in a constant state of amnesia and idiocy. They don't remember what you tell them, and they never really learn anything new. But we can equip them with rules, skills, tools, and long term memory which can approximate that. They're capable yet stupid, and very teachable. And I saw their failure modes as opportunities to teach them everything I know about doing deep, rigorous engineering. Because when there is no rigor, agents will sycophantically do whatever it takes to write that code you asked for. And boy, can and will it write a lot of it. Naive parallelization just makes them write slop faster. > **lauren@poteto**: [原文链接](https://x.com/poteto/status/2048092593087721736) > > i'm increasingly convinced that the value of orchestrating many agents in parallel comes from going deep, not broad. you want to go deeper on a single or a few problems, so you can maximize your chances of getting great results: > - best of N style races to find the best solution ## If you want to go fast, go deep first I do think that agent orchestration can be done productively. But we need to go depth first. I'm open sourcing pstack, my personal set of skills and engineering principles that I use everyday to build @cursor_ai. I started developing early iterations of these skills in my side projects, and have been refining them ever since. Get it here: https://cursor.com/marketplace/cursor/pstack ``` /add-plugin pstack ``` These skills have become some of the most used skills by the Cursor team, so I'm excited to share it with all of you. ![Image](/doc/2245/image/img_381852d77d0b.jpg) Cursor's company leaderboard. My skills were used 9k times this week! pstack teaches agents to be more rigorous using multiple models. I've taken all the failure modes I've observed and turned them into skills. The heart of the plugin is /poteto-mode, which is a higher order skill that gives agents the right playbook to follow for a given task. The goal is not maximal LOC, but the opposite: maximum impact with the least amount of code. The rigor is applied by approaching problems the same way experienced engineers do. For example, a great way to approach debugging is to binary search the problem space. You start out with some hypotheses of what might be going on, and then try to systematically rule them out until you can get closer to the true root cause. If it's hard to repro, you might try to synthetically force the bug to occur. Or you might try adding instrumentation or console logging to check program state as it runs. These steps form a playbook that can be used by agents to thoroughly debug issues instead of guessing, which they are happy to do if you let them. pstack ships with many skills and playbooks that let you approach software engineering with this same level of rigor. I currently have playbooks for: - Skill authoring and evals - Working autonomously - Bug fixes and runtime forensics - Feature development - Visual parity and prototyping - And more Whenever you need rigor, prefix your prompt with /poteto-mode. For example: ``` /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. ``` You can also optionally invoke on demand the other skills: - /how: you want a walkthrough of how a subsystem actually works. - /why: you want to know why something was built this way. uses your available MCPs to query each evidence category in parallel (source control, issue tracker, long-form docs, real-time chat, infra observability, error tracking, analytics warehouse). - /architect: you're about to write code that crosses a function boundary and want the types and data structures settled first. - /arena: you want N parallel attempts at the same thing, then to grab the best parts of each. - /interrogate: you want to have different models adversarially review something. - /tdd: you're fixing a bug. write the failing test first, then the fix. - /unslop: you're cleaning up any kind of AI writing. makes them speak plainly. - /reflect: you want to continually improve your skills after long conversations. - /figure-it-out: doing something unusual? designs a rigorous, auditable playbook for the task. - /show-me-your-work: you want a reviewable decision trail. logs decisions to a tsv you can commit. And finally, you can make your own mode skill with /automate-me. It mines your recent transcripts, drafts a your-mode skill from how you've worked, and routes through pstack underneath. pstack works with any agentic coding tool, but it works especially well in multi-model tools like Cursor. Many of the skills use multi-model workflows to take advantage of the unique strengths and weaknesses of each model. It's agent orchestration, but applied depth first rather than breadth first. The bottleneck with agents is verification. Agents can write a large amount of code quickly. Making sure it’s all correct is exceedingly difficult. When you can get there, true agent parallelism, like in a dark factory for software, might be possible. But first, we need to go deep and be rigorous. I think we get there by dialing up the trust. Give pstack a try and let me know what you think. ## Zen and the Art of Software Maintenance These skills help me move with more confidence when writing code. But maintaining code is now a nightmare with agents writing all the code. Bugs, performance issues, and feature requests still take time to work through. And now there's so much more of it! I make extensive use of Cursor automations at Cursor. They're cloud agents that can be scheduled, or run in response to events like new messages in a Slack channel. One such example is my bot Benny. I've given him the same skills I have in pstack. ![Image](/doc/2245/image/img_ba1cb06402ec.jpg) The many incarnations of Benny Benny is still a work in progress, but my vision is to automate as much of the software maintenance process as possible. The idea is this: if we now have the confidence to mostly "one shot" problems with pstack, with a good degree of certainty that the PR quality is high, surely we can automate feedback as well. This factory starts its life with triage: collecting information from employees about bug reports. We dogfood Cursor a lot and so we get a lot of feedback from employees on our release candidates. Benny understands images and video attachments, explores the codebase using pstack skills, and chats with the reporter for information on reproduction steps if it's not clear. ![Image](/doc/2245/image/img_5d51a00d6d54.jpg) Benny asking for more information This is an important part of the bug reporting process. Without clear reproduction steps and an understanding of what's broken, agents can only guess at the solution. We need to give them a clear understanding of exactly where and how it breaks. Once triaged, Benny creates a ticket with his findings from looking at code, git history for recent bug regressions, Slack for other messages about the same bug, and even Notion for design and product decisions on how a feature should work: is it a bug, or was it designed to work this way? After the ticket is filed, another Benny bot picks it up using another skill I created called /orchestrate. > **Cursor@cursor_ai**: [原文链接](https://x.com/cursor_ai/status/2052432778743210127) > > Introducing /orchestrate, a skill that recursively spawns agents to tackle your most ambitious tasks with the Cursor SDK. > We’ve used it to: > - Autoresearch our internal skills, cutting token use by 20% while improving evals > - Cut cold start times on our internal backend by 80% > > ![图片](/doc/2245/image/img_576ee84ecc28.jpg) First, he tries to reproduce the problem through computer use. Cursor Cloud Agents can run Cursor itself in the cloud, where they interact with the desktop, click on things, and send keyboard input. Internally, this uses more skills I made to control our products programmatically using protocols like CDP or equivalent. This allows us to demonstrate whether the bug report can be reproduced. If it does consistently repro the bug, he then tries to fix it. If it's a perf issue, Benny can take before and after CPU traces and heap snapshots. Subplanners spawn more workers to verify the fix using pstack skills and checking the work against the ticket if it was fixed. Additional workers are spawned in this run to take a video of the before and after, and finally a worker opens the PR for review with the video in the description. ![Image](/doc/2245/image/img_d2ba3fd08698.jpg) A recent run that was successfully reproduced and fixed This is all still a work in progress and there's a ton more work to do, but I'm excited about having a team of agents to help me fix bugs with confidence while I sleep or do other things. Making code review scalable is another big area, and I think Cursor will have some cool upcoming features to help. But the key for building your own software factory is trust. Unless you can trust an agent to own a problem end-to-end, including verification, you cannot automate your processes. As you dial up the trust using plugins like pstack that give your agents more engineering depth, you can start tackling more ambitious problems. Trying to parallelize agents you don't trust yet is a huge waste of tokens and introduces more slop into your codebase. Thanks for reading! ## 相关链接 - [lauren](https://x.com/poteto) - [@poteto](https://x.com/poteto) - [118K](https://x.com/poteto/status/2058975157503570132/analytics) - [@cursor_ai](https://x.com/@cursor_ai) - [adversarial review](https://www.skills.sh/poteto/noodle/adversarial-review) - [@bcherny](https://x.com/@bcherny) - [Apr 26](https://x.com/poteto/status/2048092593087721736) - [12K](https://x.com/poteto/status/2048092593087721736/analytics) - [pstack](https://github.com/cursor/plugins/tree/main/pstack) - [@cursor_ai](https://x.com/@cursor_ai) - [https://cursor.com/marketplace/cursor/pstack](https://cursor.com/marketplace/cursor/pstack) - [pstack](https://cursor.com/marketplace/cursor/pstack) - [May 8](https://x.com/cursor_ai/status/2052432778743210127) - [525K](https://x.com/cursor_ai/status/2052432778743210127/analytics) - [Cloud Agents](https://cursor.com/docs/cloud-agent) - [CDP](https://chromedevtools.github.io/devtools-protocol/) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [2:15 AM · May 26, 2026](https://x.com/poteto/status/2058975157503570132) - [118.7K Views](https://x.com/poteto/status/2058975157503570132/analytics) - [View quotes](https://x.com/poteto/status/2058975157503570132/quotes) --- *导出时间: 2026/5/26 11:42:17* --- ## 中文翻译 # 我如何使用 Cursor **作者**: lauren **日期**: 2026-04-25T17:31:40.000Z **来源**: [https://x.com/poteto/status/2058975157503570132](https://x.com/poteto/status/2058975157503570132) --- ![Image](/doc/2245/image/img_f77debfba73a.jpg) 我有话想直说。在我面试 @cursor_ai 之前，我其实从来没有真正使用过 Cursor。在 Meta，Claude Code 正在爆发式地普及。我甚至为我的副业项目支付了每月 200 美元的个人费用。我喜欢它的简洁，以及我能多么快地感受到高效。对我来说，关键点在于开发我自己的技能组合，将 cc（Claude Code）变成我想要的任何东西。我甚至开始在此基础上开发我自己的代理编排工具。在我的现场面试中，我在两天内使用了 Cursor，用它来构建面试项目。那是在 Cursor 3 发布之前，所以我使用的是编辑器窗口。这么多年我一直在使用 vscode，大部分快捷键仍然在我的“上下文窗口”中，所以回到这个 IDE 并不太难。不过，老实说，在第一两个小时里，我确实很想念命令行（cli）。点击东西感觉几乎是野蛮的。但有几件事真的很让我印象深刻。首先，我当时习惯使用的模型——Opus 和 Codex——在某种程度上感觉更聪明。而且能够即时切换模型，并在项目的不同部分同时使用它们（前端用 Opus，系统用 Codex），这太棒了。在面试之前，我就已经对多模型对抗性评审赞不绝口了，所以能直接在 UI 中原生地做到这一点感觉非常自然。更好的是能够生成不同模型的子代理，这样我可以在一次对话中获得两全其美的体验。其次，压缩速度快得惊人。作为一个 cc 用户，我习惯了压缩需要花费好几分钟，所以我总是处于对上下文和计划使用情况的持续警惕状态。因此，我对 Cursor 中的速度感到非常震惊。以至于我基本上从来不需要查看我使用了多少上下文。它就是能用，而在 cc 中，我经常觉得模型在压缩后变得超级笨。第三件我注意到的事情是，GUI（图形用户界面）相比 TUI（终端用户界面）能提供多少东西。能够直接在 Cursor 的浏览器中打开你的应用程序，并使用设计模式进行设计更改，感觉很直观，这让我开始思考专用 UI 能在多大程度上使代理编码更加有效。 ## 用 Cursor 构建 Cursor 自从 3 月底加入以来，我主要从事 Cursor 3 的代理窗口工作，并将其作为我的日常主力工具。虽然我仍然认为 cc 是一个拥有很棒团队的很酷的产品，但我注意到它的简洁性往往驱使人们想要构建自己的抽象层来包装它。在上一份工作中，感觉每周都有一个新的基于 cc 构建的内部编排工具发布。 @bcherny 经常谈论关于“潜在需求”的想法： > “产品中有一个非常古老的概念叫做潜在需求……你以一种可被黑的方式构建产品，这就足够开放，人们可以为了其他用例滥用它。然后你观察人们如何滥用它，然后你针对那个方向进行构建。” 正是如此！人们在编排工具上的汇聚暴露了这样一个潜在需求：使用 CLI 只是让你——人类——成为了编排者。但我使用过的每一个代理工作流程都集中在错误的事情上。在 GUI 中运行多个 CLI 完全错过了重点。我感兴趣的方法是建立对代理的信任。作为一名前工程经理，我很快意识到管理代理的感觉类似于构建一个人类工程团队。新员工需要入职培训，以了解代码库，也要了解工作是如何完成的。他们在加入时已经通过过去的经历掌握了技能：如何调试、如何编写高质量的代码和测试，以及如何沟通等等。代理就像是一直处于健忘和愚蠢状态的新员工。他们不记得你告诉他们的话，也从来没有真正学到任何新东西。但我们可以用规则、技能、工具和长期记忆来装备他们，从而近似地达到那个状态。他们有能力但很愚蠢，而且非常可教。我将他们的失败模式视为向他们传授我所知道的关于进行深入、严谨的工程知识的绝佳机会。因为如果没有严谨性，代理会为了写出你要求的代码而阿谀奉承地做任何事。天哪，它能也将会写大量的代码。朴素的并行化只会让他们写垃圾代码的速度更快。 > **lauren@poteto**: [原文链接](https://x.com/poteto/status/2048092593087721736) > > 我越来越相信，并行编排许多代理的价值来自于深入，而不是广泛。你想深入处理单个或几个问题，这样你才能最大化获得好结果的机会： > - N 选 1（Best of N）风格的竞赛，以找到最佳解决方案 ## 如果你想走得快，先深入我确实认为代理编排可以有效地进行。但我们需要优先考虑深度。我正在开源 pstack，这是我个人的一套技能和工程原则，我每天用它来构建 @cursor_ai。我在我的副业项目中开始开发这些技能的早期迭代，并且从那时起一直在完善它们。在这里获取：https://cursor.com/marketplace/cursor/pstack ``` /add-plugin pstack ``` 这些技能已成为 Cursor 团队使用最多的技能之一，所以我很兴奋与大家分享它。 ![Image](/doc/2245/image/img_381852d77d0b.jpg) Cursor 的公司排行榜。我的技能本周被使用了 9 千次！ pstack 教会代理使用多个模型变得更加严谨。我观察到的所有失败模式都被我转化成了技能。该插件的核心是 /poteto-mode，这是一个高阶技能，它为代理提供了针对给定任务的正确操作指南。目标不是最大的代码行数（LOC），恰恰相反：用最少的代码产生最大的影响。这种严谨性是通过像经验丰富的工程师那样解决问题来实现的。例如，调试的一个好方法是对问题空间进行二分搜索。你首先对可能发生的情况提出一些假设，然后尝试系统地排除它们，直到你能更接近真正的根本原因。如果难以复现，你可能会尝试强制合成 bug 发生。或者你可能会尝试添加检测或控制台日志来检查程序运行时的状态。这些步骤形成了一个可供代理使用的剧本，用来彻底调试问题，而不是猜测——如果你让它们猜，它们很乐意这么做。pstack 附带了许多技能和剧本，让你可以用同样的严谨水平来处理软件工程。我目前有针对以下内容的剧本： - 技能编写和评估 - 自主工作 - 错误修复和运行时取证 - 功能开发 - 视觉保真度和原型设计 - 以及更多每当你需要严谨性时，在你的提示词前加上 /poteto-mode。例如： ``` /poteto-mode 这个 PR 有一个微妙的 bug，即使空闲时滚动也会每 750ms 漂移一次。先复现，然后修复并验证。 /poteto-mode 即使我们有虚拟化，加载一个大列表也需要一两秒。运行 CPU 跟踪并告诉我原因。 /poteto-mode 在功能标志后构建一个小功能。验证它真的有效。 /poteto-mode 构建两个 markdown 渲染器的原型，以便我们可以比较。为每个生成一个代理。 /poteto-mode 将这些技能作为插件开源。不要泄露任何内部信息，在临时目录中工作，先向我展示依赖关系图。 /poteto-mode 我要去睡觉了。合并这个堆栈，即使 CI 不稳定。我希望在早上之前合并所有内容。 /poteto-mode 当这个标志开启时，行间距太高了。第二张图是正确的。复现并修复直到匹配。 ``` 你也可以按需选择性地调用其他技能： - /how：你想要一个关于子系统如何实际工作的演练。 - /why：你想知道为什么某样东西是这样构建的。使用你可用的 MCP 并行查询每个证据类别（源代码控制、问题跟踪器、长文档、实时聊天、基础架构可观察性、错误跟踪、分析仓库）。 - /architect：你即将编写跨越函数边界的代码，并希望先确定类型和数据结构。 - /arena：你想要 N 次并行尝试做同一件事，然后获取每个尝试中最好的部分。 - /interrogate：你想要不同的模型对抗性地审查某样东西。 - /tdd：你正在修复一个 bug。先编写失败的测试，然后再修复。 - /unslop：你正在清理任何类型的 AI 文本。让它们说大白话。 - /reflect：你希望在长对话后不断改进你的技能。 - /figure-it-out：做不寻常的事情？为任务设计一个严谨的、可审计的剧本。 - /show-me-your-work：你想要一个可审查的决策轨迹。将决策记录到你可以提交的 tsv 文件中。最后，你可以使用 /automate-me 制作你自己的模式技能。它会挖掘你最近的记录，根据你的工作方式起草一个 your-mode 技能，并在底层通过 pstack 进行路由。 pstack 适用于任何代理编码工具，但在像 Cursor 这样的多模型工具中效果特别好。许多技能使用多模型工作流程来利用每个模型独特的优缺点。这是代理编排，但优先应用深度而不是广度。代理的瓶颈是验证。代理可以快速编写大量代码。确保所有代码都正确是极其困难的。当你能达到那个程度时，真正的代理并行性，就像软件的“黑暗工厂”一样，才可能实现。但首先，我们需要深入并保持严谨。我认为我们可以通过增强信任来达到这一目标。试试 pstack，并告诉我你的想法。 ## 禅与软件维护艺术这些技能帮助我在编写代码时更有信心。但现在维护代码随着代理编写所有代码而变成了一场噩梦。错误、性能问题和功能请求仍然需要时间来解决。而且现在这些东西多得多！我在 Cursor 大量使用 Cursor 自动化。它们是云代理，可以安排时间，或响应事件运行，例如 Slack 频道中的新消息。一个这样的例子是我的机器人 Benny。我赋予了它和我在 pstack 中一样的技能。 ![Image](/doc/2245/image/img_ba1cb06402ec.jpg) Benny 的多种化身 Benny 还在开发中，但我的愿景是尽可能多地自动化软件维护流程。这个想法是：如果我们现在有信心主要使用 pstack “一次性”解决问题，并有很高的把握 PR 质量很高，那么我们当然也可以自动化反馈。这个工厂的生命周期始于分类：从员工那里收集关于错误报告的信息。我们大量使用 Cursor 的内部版，所以我们会从员工那里获得大量关于发布候选版本的反馈。Benny 理解图片和视频附件，使用 pstack 技能探索代码库，如果不清楚的话，还会与报告者聊天以获取复现步骤的信息。 ![Image](/doc/2245/image/img_5d51a00d6d54.jpg) Benny 询问更多信息这是错误报告过程的重要组成部分。如果没有清晰的复现步骤和对损坏内容的了解，代理只能猜测解决方案。我们需要给他们一个清晰的理解，确切地知道在哪里以及如何损坏。一旦分类完成，Benny 会根据其发现创建一个工单，包括查看代码、git 历史（最近的错误回归）、Slack（关于同一错误的其他消息），甚至 Notion（关于功能应该如何工作的设计和产品决策）：这是一个 bug，还是设计就是如此工作的？工单归档后，另一个 Benny 机器人使用我创建的另一个技能 /orchestrate 接管它。 > **Cursor@cursor_ai**: [原文链接](https://x.com/cursor_ai/status/2052432778743210127) > > 介绍 /orchestrate，这是一个使用 Cursor SDK 递归生成代理来解决你最雄心勃勃的任务的技能。 > 我们用它来： > - 自动研究我们的内部技能，在提高评估的同时将 Token 使用量减少了 20% > - 将我们内部后端的冷启动时间减少了 80% > > ![图片](/doc/2245/image/img_576ee84ecc28.jpg) 首先，他尝试通过计算机操作复现问题。Cursor 云代理可以在云端运行 Cursor 本身，在那里他们与桌面交互、点击事物并发送键盘输入。在内部，这使用我制作的更多技能，通过 CDP 或等效协议以编程方式控制我们的产品。这允许我们演示错误报告是否可以复现。如果它确实一致地复现了错误，他会尝试修复它。如果是性能问题，Benny 可以获取前后的 CPU 跟踪和堆快照。子规划器生成更多工作人员来使用 pstack 技能验证修复，并根据工单检查工作是否已修复。在此运行中生成额外的工人来拍摄前后的视频，最后由一个工作人员打开 PR 进行审查，并将视频放在描述中。 ![Image](/doc/2245/image/img_d2ba3fd08698.jpg) 最近一次成功复现和修复的运行这一切都还在开发中，还有很多工作要做，但我对拥有一支代理团队感到兴奋，它们可以在我睡觉或做其他事情时帮助我有信心地修复错误。使代码审查可扩展是另一个重要领域，我认为 Cursor 将有一些很酷的即将推出的功能来提供帮助。但是，构建你自己的软件工厂的关键是信任。除非你能信任代理端到端地拥有一个问题，包括验证，否则你就无法自动化你的流程。当你使用像 pstack 这样的插件增强信任，给你的代理更多的工程深度时，你就可以开始解决更雄心勃勃的问题。试图并行化你还不信任的代理是对 Token 的巨大浪费，并且会在你的代码库中引入更多垃圾。感谢阅读！ ## 相关链接 - [lauren](https://x.com/poteto) - [@poteto](https://x.com/poteto) - [118K](https://x.com/poteto/status/2058975157503570132/analytics) - [@cursor_ai](https://x.com/@cursor_ai) - [adversarial review](https://www.skills.sh/poteto/noodle/adversarial-review) - [@bcherny](https://x.com/@bcherny) - [Apr 26](https://x.com/poteto/status/2048092593087721736) - [12K](https://x.com/poteto/status/2048092593087721736/analytics) - [pstack](https://github.com/cursor/plugins/tree/main/pstack) - [@cursor_ai](https://x.com/@cursor_ai) - [https://cursor.com/marketplace/cursor/pstack](https://cursor.com/marketplace/cursor/pstack) - [pstack](https://cursor.com/marketplace/cursor/pstack) - [May 8](https://x.com/cursor_ai/status/2052432778743210127) - [525K](https://x.com/cursor_ai/status/2052432778743210127/analytics) - [Cloud Agents](https://cursor.com/docs/cloud-agent) - [CDP](https://chromedevtools.github.io/devtools-protocol/) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [2:15 AM · May 26, 2026](https://x.com/poteto/status/2058975157503570132) - [118.7K Views](https://x.com/poteto/status/2058975157503570132/analytics) - [View quotes](https://x.com/poteto/status/2058975157503570132/quotes) --- *导出时间: 2026/5/26 11:42:17*

🔗 相关文档