Cursor工程师开源Pstack：AI编程全流程技能拆解

什么是Pstack？

Lauren Tan 是 SpaceX 的首席工程师、Cursor 的技术成员，同时也是 Meta 的资深工程师和 React 团队的核心成员。最近，她将自己多年积累的开发知识、工作流和原则全部开源，形成了一个名为 Pstack 的仓库。

与市面上常见的 AI 编程技能包不同，Pstack 并不是一套零散的提示词集合，而是围绕 AI 软件开发生命周期 构建的完整技能体系。B站UP主在视频中将其拆解为六个阶段：规划、设计、构建、测试、部署和维护，并逐一分析了每个阶段对应的核心技能。

对于正在探索 AI 辅助编程的开发者来说，Pstack 的价值在于它展示了一位顶级工程师如何系统性地将 AI 嵌入真实开发流程，而不是停留在“让 AI 写一段代码”的层面。

六个阶段的核心技能拆解

规划阶段：面向存量项目的学习与拆解

Pstack 的规划阶段明显偏向 brownfield 项目，也就是已有大量存量代码的工程。它提供了两个主要工作流：

• 先学代码：通过 help 技能了解代码如何运作，用 why 技能追问为什么这样设计，再用 teach 技能将两者结合。
• 拆解大任务：使用 figure out 和 show me your work 技能，把大任务拆成小工单，并将决策记录到文档或 MD 文件中。

UP主在视频中坦言，自己不会优先使用 Lauren 的规划技能，因为她的设计重心不在从零构建应用，而在于大型迁移和存量改造。对于独立开发者或从零起步的项目，Matt Pocock 的技能或 Superpower 技能可能更合适。

Brownfield 项目是软件工程中的常用术语，指已有大量存量代码、需要在其基础上继续开发或改造的工程；与之相对的是 greenfield 项目，即从零开始的全新项目。Brownfield 项目的核心挑战在于：开发者必须先理解既有代码的架构、约定和隐含决策，才能安全地添加功能或进行迁移。这正是 Pstack 规划阶段设置 help、why、teach 等“先学代码”技能的原因——它们帮助 AI 和开发者共同建立对存量系统的认知，而不是直接跳到写代码环节。

设计阶段：多智能体竞标与聚合

设计阶段只有一个工作流：确定代码形态。但实现方式很有意思——architect 技能会调用多个不同模型和多个 AI 智能体，让它们各自输出设计方案，然后通过 interrogate 技能进行交叉评判，最终聚合为一份统一报告。

这与过去常见的“多个模型各写一版然后人工挑选”不同，Pstack 把评判和聚合也交给了 AI 智能体，形成了一种类似竞标的机制。据UP主观察，这种设计在过往评测的技能包中并不常见。

多智能体（multi-agent） 是指让多个独立的 AI 智能体各自承担不同角色或任务，再通过某种机制汇总结果的架构模式。与单次调用一个大模型相比，多智能体的优势在于可以并行探索多个方案、引入交叉验证，并降低单一模型偏见带来的风险。Pstack 的设计阶段正是这一模式的典型应用：architect 技能让多个模型分别产出设计方案，interrogate 技能则扮演“评审”角色进行交叉评判，最终聚合为统一报告。这种“生成—评判—聚合”的流水线，本质上把软件设计中的竞标与评审流程自动化了。

构建阶段：TDD + 类型安全 + 去AI味

构建阶段包含两个工作流，核心是 测试驱动开发（TDD）。Pstack 的 TDD 技能与 Matt Pocock、Superpower 的 TDD 技能存在差异，UP主专门做了横向对比，针对快速修 bug、新功能、严格团队纪律等场景给出了选型建议。

由于 Lauren 主要深耕 React 生态，Pstack 还内置了 TypeScript 最佳实践 技能，强制 AI 按 TypeScript 规范构建应用。另一个值得关注的技能是 clean up diff：它检查主分支与当前分支的差异，清理多余注释、无类型变量、深层嵌套等“AI 味”代码，同时通过运行测试保证行为不变，最终给出一到三句话的总结。

为什么专门移除注释？视频给出了一个关键洞察：AI 有时会优先读取注释而非代码本身。如果注释与实际代码不符，AI 可能被误导。去除注释等于减少噪音，让 AI 真正去读代码。

测试驱动开发（TDD，Test-Driven Development） 是一种先写测试、再写实现代码的开发方法，通常遵循“红—绿—重构”循环：先写一个会失败的测试（红），再写最少的代码让测试通过（绿），最后在测试保护下重构代码。TDD 对 AI 辅助编程尤其有价值，因为测试为 AI 生成的代码提供了可验证的行为契约，能有效防止 AI “看起来对但实际跑不通”的问题。Pstack 的 TDD 技能在此基础上做了场景化调整，针对快速修 bug、新功能开发、严格团队纪律等不同情境给出不同的测试粒度与流程建议。

测试阶段：从单元测试到端到端验证

测试阶段有三个工作流。第一个是 证明应用可用，使用 create verification 技能。它与 TDD 技能的分工在于：TDD 聚焦功能测试和单元测试，而该技能负责端到端测试，需要启动应用、配置数据库和服务器、模拟用户行为、收集证据并在结束后清理临时环境。

这里还有一个 swarm 技能，让多个 AI 智能体分别负责端到端流程的不同片段，最后聚合报告，而不是由一个智能体包揽全部。

第二个工作流是 攻击差异，复用了设计阶段的 interrogate 技能。它会对比主分支与功能分支的代码变更，让多个模型尝试“打破”这些改动。此外还有一个名为 thermonuclear code quality review 的技能，执行格外严格的代码质量审查，寻找进一步简化的空间。

部署阶段：围绕 PR 的完整流水线

部署阶段的目标是让功能顺利合并。Pstack 提供了一组围绕 Pull Request 的技能：生成易于审查的 PR、 babysit 整个 PR 直到合并完成、处理合并冲突（fixed merge complex）、获取 PR 评论列表、修复 CI 检查。

UP主指出，PR 的写作风格因人而异，Pstack 的 PR 技能可以作为参考，但不必照搬。

维护阶段：Pstack的空白

在六阶段模型中，维护阶段是 Pstack 没有覆盖的部分——如何收集问题并回流到规划阶段，Lauren 没有提供对应技能。UP主建议可以参考 Superpower 等技能包中的维护类技能来补足。

辅助技能与原则设计

除了主流程，Pstack 还有可随时触发的辅助技能：router（俗称“potato mode”，在不知道该用哪个技能时描述问题，由它路由到合适的技能）、catch up（切换上下文后快速回顾进展）、plain talk（用平实语言沟通）以及写作和持续改进类技能。UP主特别推荐 catch up 和 plain talk，认为在多项目切换时非常实用。

原则部分的设计思路值得单独讨论。Lauren 没有把所有规则塞进系统提示词，而是拆成多个技能并建立索引映射，按需触发。原因很直接：系统提示词每条消息都要被读取，全量规则会消耗大量 token，且大部分内容与当前任务无关。

在具体原则上，UP主重点提到了三个：

• 保持小：与 pony tail 技能思路相近，控制改动规模。
• 攻击前提：当 AI 反复修同一个 bug 却始终修不好时，停下来质疑假设——方向是不是一开始就错了。UP主表示会把这个原则加入自己的 Superpower 工作流。
• 类型系统纪律：拒绝不可能的状态，例如一笔支付不能同时处于“已支付”和“待处理”状态。

系统提示词（system prompt） 是每次调用大模型时随消息一同发送的指令文本，模型在生成回复前都会读取它。由于系统提示词在每一轮对话中都要被重新处理，把大量规则全量塞入其中会持续消耗 token，并可能稀释模型对当前任务的注意力。Pstack 的做法是把原则拆成独立技能，再通过索引映射按需加载——只有当任务涉及某条原则时，才把对应技能调入上下文。这种“索引 + 按需触发”的设计，与软件工程中的懒加载（lazy loading）思路一致，在控制成本和保持规则有效性之间取得了平衡。

值得关注的启示

Pstack 的意义不在于提供一套万能技能，而在于展示了一种工程化的 AI 编程思路：按生命周期分层、多智能体交叉验证、用技能索引替代巨型系统提示词、把代码质量审查做成可复用技能。

对于团队而言，可以借鉴其结构设计，再根据自身技术栈（如是否重度使用 React/TypeScript）做裁剪。对于个人开发者，UP主的建议也很务实——规划阶段可以另选更适合从零构建的技能包，而设计阶段的多智能体聚合、构建阶段的去 AI 味清理、测试阶段的端到端验证流程，都具备较高的迁移价值。

（注：视频中段包含一段赞助商产品演示，与 Pstack 主题无关，本文未展开。）