Cursor工程师开源Pstack：六阶段AI编码流水线拆解

当AI编码进入"流水线"时代

一个值得注意的现象是，越来越多的资深工程师开始把自己的开发方法论"产品化"——不再停留在博客或演讲里，而是直接封装成AI可执行的技能（skills）开源出来。Cursor技术团队成员、React核心成员Lauren Tan最近开源的Pstack，就是这类实践中最成体系的一个。

据B站UP主的拆解视频，Pstack覆盖了从规划、设计、构建、测试到部署、维护的完整AI软件开发生命周期，将她的工作流、技能与原则沉淀为一套可复用的仓库。本文基于该视频的梳理，结合多阶段细节，拆解Pstack的设计思路，并指出它与市面上其他spec-driven框架的差异所在。

六阶段流水线：Pstack的核心骨架

UP主将Pstack的技能拆成六个阶段，对应完整的AI软件开发周期。需要先说明一个前提：Lauren Tan的规划类技能主要面向"棕地项目"（brownfield，即已有代码库的项目），擅长处理大型迁移和存量改造，而不是从零起步的绿地项目。

阶段一：规划——先读懂代码，再拆解任务

规划阶段的技能围绕"理解存量代码"展开。想知道代码如何运作，用 how 技能；想弄清某段代码为何这样设计，用 why 技能；teach 技能则把前两者组合成一套学习流程。若要把一个大任务拆成小工单，可以用 figure out 和 show me your work，后者会把决策记录到文档或MD文件中。

UP主对此给出了明确的个人判断：如果是独立开发者或从零搭建应用，他更倾向Matt Pocock或Superpower的技能，而非Pstack的规划技能。这个差异值得留意——Pstack的定位从一开始就不是"万能脚手架"，而是有明确适用边界的工程工具。

阶段二：设计——多模型"竞技场"式方案聚合

设计阶段只有一个工作流：settle the code shape。其中 architect 技能会触发一个"arena"机制，让多个不同Agent并行发散，各自产出设计方案。

随后 interrogate 技能介入，由一个模型担任裁判，评估各方案并聚合为一份统一的设计报告。这与以往依赖单一模型的技能框架有本质区别——Pstack把"多模型交叉验证"写进了设计环节，让Opus、GPT、Grok等模型各自出方案，再取长补短。

多模型交叉验证 是指让多个不同的大语言模型（如Opus、GPT、Grok等）对同一问题独立给出答案，再通过比较、投票或裁判模型聚合的方式得出最终结论。其原理在于不同模型在训练数据、架构和偏好上存在差异，单一模型的盲区可能被另一模型覆盖，从而提升方案的鲁棒性。这种做法借鉴了集成学习（ensemble learning）的思想——多个弱分类器的组合往往优于单一强分类器。在Pstack的设计阶段，“arena”机制让多个Agent并行发散方案，再由裁判模型评估聚合，实质上是在AI编码流程中引入了“同行评审”环节，减少单一模型偏见导致的架构决策失误。

阶段三：构建——TDD打底，TypeScript规范兜底

构建阶段分两条工作流。其一是遵循测试驱动开发（TDD）写代码，UP主此前已专门对比过Pstack、Matt Pocock与Superpower三家的TDD技能在快速修bug、新功能、严格团队纪律等场景下的差异。其二是TypeScript最佳实践技能，这与Lauren Tan的React背景直接相关——React生态以TypeScript为主，该技能会强制AI按TS规范写代码。

还有一个容易被忽视的细节：clean up diff 技能会比对主分支与当前分支的差异，清理多余注释、无类型变量、深层嵌套等问题，并在保持行为不变的前提下跑测试验证，最后输出一到三句话的总结。

这里有个耐人寻味的设计——no comments 技能，即主动移除代码中的注释。原因在于AI有时会优先读注释而非读代码：如果注释说函数返回A、实际代码返回B，AI可能被注释误导。移除注释本质上是在为AI"降噪"，逼它直面真实代码。

TDD（测试驱动开发） 是一种以测试为先导的编程实践：开发者先编写描述期望行为的失败测试，再编写刚好能让测试通过的生产代码，最后重构优化。其核心循环被称为“红-绿-重构”——红表示测试失败，绿表示测试通过，重构表示在不改变行为的前提下改进代码结构。在AI编码场景中，TDD的价值被进一步放大：测试用例为AI提供了明确、可验证的目标，使AI生成的代码有客观标准可依，而非仅凭模型“感觉”正确。Pstack将TDD作为构建阶段的默认工作流，正是利用测试作为AI编码的“验收护栏”，降低幻觉代码混入主干的概率。

阶段四：测试——从单元验证到多Agent"围攻"

测试阶段有三个工作流。第一个是 create verification 技能，它与TDD的区别在于专注端到端测试：需要搭环境、建数据库、起服务、模拟用户行为、收集证据、最后清理临时资源。视频特别强调"一功能一文件夹"的组织规则，而非把所有功能塞进同一个目录。

随后是 swarm 机制：不再让单个Agent跑完全程，而是让多个Agent（可选不同模型）各自负责一小块，最后聚合为一份报告。第三个工作流 attack the diff 复用了设计阶段的 interrogate 技能，让多个模型针对主分支与特性分支的差异发起"攻击"，看能否找出破绽。配合一个名为 thermonuclear code quality review 的"核弹级"代码质量审查层，进一步追问代码能否更简单。

阶段五：部署——把PR当作需要"照看"的对象

部署阶段的技能围绕Pull Request展开：生成易于review的PR、babysit整个PR直到可合并、处理合并冲突（fix merge conflict）、拉取review评论清单、修复CI/CD流水线检查。

UP主也指出一个现实问题：PR的写法因人而异，Lauren Tan的技能只能作为参考，团队仍需沉淀自己的风格。

阶段六：维护——留白的一环

维护阶段在Pstack中没有对应技能，UP主认为这恰恰是其他框架（如Superboard的collect技能）可以补位的地方，形成"收集问题→回到规划"的闭环。

棕地项目（brownfield）与绿地项目（greenfield） 是软件工程中一对常用隐喻。绿地项目指从零开始、不受既有代码约束的全新开发；棕地项目则指在已有代码库上继续开发、改造或迁移，需要理解存量逻辑、兼容历史决策并控制变更风险。两者的技能需求差异显著：绿地项目更依赖快速脚手架和从零规划能力，棕地项目则更强调代码理解、影响面分析和渐进式重构。Pstack的规划类技能明确面向棕地场景，这解释了它为何把“读懂代码”（how/why技能）放在规划阶段的核心位置，而非提供通用的项目初始化模板。

次级技能与原则技能：随时可触发的"外挂"

除六阶段主干外，Pstack还提供了一批随时可触发的次级技能。当你不确定该用哪个技能时，可以启动 potato mode，描述问题后由它路由到合适的技能。此外还有setup、catch up、plain talk、writing等技能。UP主特别推荐 catch up 与 plain talk：在多个项目、多个上下文之间切换时，用它们快速回忆进度非常实用。

原则技能（principles）则回答了一个好问题：为什么不把这些规则写进system prompt？因为全部塞进去会让每次对话都携带巨量token，其中大部分信息与当前任务无关。Pstack的做法是把原则拆成多个技能，并维护一张索引，标明何时该触发哪一条。

UP主从中挑出两个最有价值的原则。其一是 attack the premise：当AI陷入"修bug→失败→再修→再失败"的死循环时，先停下来质疑前提——我们是不是从一开始就走错了方向。其二是类型系统纪律中的拒绝不可能状态：一个支付不可能同时处于"已支付"和"待处理"状态，用类型系统把这类非法状态挡在门外。

多源视角下的Pstack定位

从视频作者的横向对比来看，Pstack与Matt Pocock、Superpower等框架的分工已经比较清晰：Pstack强在存量代码的理解与大型改造、多模型竞技场式的方案设计与攻击性测试；弱在绿地项目的规划与维护闭环。这不是缺陷，而是设计取向。对团队而言，更务实的做法是取各家之长——把 attack the premise、拒绝不可能状态这类原则并入自己的技能库，而不是整体照搬。

核心要点

• Pstack是Lauren Tan开源的AI编码技能仓库，覆盖规划、设计、构建、测试、部署、维护六阶段。
• 设计阶段采用多Agent并行发散+裁判模型聚合的"竞技场"机制，与单模型方案有本质区别。
• no comments技能主动移除注释，避免AI被错误注释误导，逼迫其阅读真实代码。
• 原则不写进system prompt而是拆成技能+索引，以控制token开销并按需触发。
• 适用边界明确：擅长棕地项目与大型改造，绿地项目规划与维护闭环可结合其他框架补足。