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

一位同时拥有SpaceX首席工程师、Cursor技术团队和Meta Staff Engineer三重身份、还是React核心成员的工程师Lauren Tan，最近把自己完整的AI编程知识体系、工作流与编码原则开源成了一个仓库——Pstack。B站UP主对其进行了系统拆解，本文基于该视频内容，梳理这套工作流的六个阶段、关键技能与背后值得借鉴的工程思想。

为什么Pstack值得关注

Pstack的特殊之处不在于"又一个AI编程提示词集合"，而在于它把整个AI软件开发生命周期拆成了可复用的技能（skills），并为每个技能定义了触发时机。据B站UP主的分析，Lauren Tan将技能按规划、设计、构建、测试、部署、维护六个阶段组织，这与过去常见的"单点提示词"思路形成明显差异。

另一个值得注意的设计是：原则（principles）没有塞进system prompt，而是被拆成独立技能并配了一张索引表。原因是system prompt会被每条消息重复读取，把大量原则堆进去既浪费token，也可能与当前任务无关。这种"按需加载"的思路对长期维护AI工作流的团队有直接参考价值。

System prompt（系统提示词）是对话开始时注入给大模型的全局指令，通常在整个会话中持续生效。由于大模型的上下文窗口有限，且每次推理都会重新读取窗口内的全部token，把大量原则性规则塞进system prompt会导致两个问题：一是token成本随每轮对话重复累积，二是模型注意力被无关规则稀释，反而可能忽略当前任务的关键指令。按需加载（lazy loading）则是把这些规则做成可检索、可触发的独立模块，只在相关任务被激活时才注入上下文，这与软件工程中的模块化与依赖注入思想一脉相承。

阶段一：规划——面向存量代码库

Pstack的规划阶段明显偏向brownfield项目，即已有代码存量的工程。核心工作流是"先学代码"：how技能回答代码如何运作，why技能解释为何这样设计，teach技能则把两者合并。若要拆分大任务，可以用figure out和show me your work，后者会把决策记录到文档或Markdown文件中。

UP主对此给出了保留意见：如果是从零起步的独立开发者，他更倾向Matt Pocock或Superpower系列的规划技能，因为Pstack的规划更服务于大型迁移和存量改造，而非从零构建。这是一个值得如实呈现的定位差异，而非优劣判断。

Brownfield（棕地）与greenfield（绿地）是软件工程中的一对常用隐喻。Brownfield指已有大量存量代码、历史包袱和隐性约束的项目，改造时首要任务是理解现有系统而非从头设计；greenfield则指全新项目，约束少、设计自由度高。AI编程工具在两类项目上的能力需求差异很大：棕地项目更依赖代码理解、影响面分析和渐进式迁移能力，绿地项目更依赖需求拆解和架构决策。Pstack把规划阶段的重心放在棕地场景，实际上对应的是企业级真实工程中占比更高的那部分工作。

阶段二：设计——多模型并行出方案

设计阶段只有一条工作流"settle the code shape"，但实现方式颇具看点。architect技能会触发一个"arena"，让多个不同模型（如Opus、GPT、Grok等）或多个agent并行给出设计方案；随后interrogate技能充当裁判，对结果做评估并把各家方案的优点聚合为一份统一报告。

这与多数单模型方案形成鲜明对比——过去我们习惯让一个模型反复迭代，而Pstack的思路是先用广度换质量，再做收敛。多模型交叉验证在这里不是噱头，而是设计决策的防错机制。

阶段三：构建——TDD、类型纪律与去AI味

构建阶段有两条主线。其一是测试驱动开发，Pstack的TDD技能与Matt Pocock、Superpower的TDD技能各有侧重，UP主专门做了对比，覆盖快速修bug、新功能、严格团队纪律等场景。其二是TypeScript最佳实践技能，这与Lauren Tan的React背景直接相关——React生态重度依赖TypeScript，因此该技能会强制AI按TS规范产出代码。

第三条容易被忽略但很实用：cleanup diff技能。它会对比主分支与当前分支的差异，清理多余注释、奇怪的try-catch、缺少类型的变量、过深嵌套等"AI味"代码，并通过运行测试保证行为不变，最后给出一到三句话的总结。

配套的no comments技能解释了一个常见陷阱：AI有时会读注释而不读代码。如果注释说函数返回A、代码实际返回B，AI可能采信注释。去掉注释本质上是在减少噪声，让模型直面真实代码。这个洞察对经常被"过期注释"坑到的团队尤其实用。

TDD（测试驱动开发）的经典循环是红—绿—重构：先写一个会失败的测试（红），再写最少量的代码让测试通过（绿），最后在测试保护下重构。在AI编程语境下，TDD的价值被进一步放大——测试用例相当于给模型一份可执行的验收标准，把“代码是否正确”从主观判断变成可自动验证的客观信号。模型每改一轮代码就跑一次测试，能显著降低幻觉和回归风险。不同TDD技能的差异主要体现在测试粒度（单元/集成/端到端）、是否强制先写测试、以及失败后的修复策略上。

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

测试阶段分三条工作流。第一条"证明应用能用"依赖create verification技能，与TDD的区别在于它面向端到端测试：需要拉起环境、数据库、服务器，模拟真实用户行为，收集证据，最后拆除临时资源。它还有一条规则——每个功能一个文件夹，而不是全部塞进单一目录。

在此基础上，swarm技能让多个agent（可选用不同模型）分头负责不同页面或小模块，最后聚合成一份报告。第二条工作流"攻击差异"复用了设计阶段的interrogate技能，让多个模型尝试击破当前分支的改动。

这里还有一个名字颇为夸张的技能：thermonuclear code quality review，即在常规审查之上再加一层更严苛的质量审查，看代码能否进一步简化。UP主认为它与自己频道的ponytail技能思路相近。

阶段五与六：部署与维护

部署阶段覆盖了提PR到合并的完整链路：按团队风格撰写PR、easy to review技能整理PR便于评审、babysit全程盯守PR、处理合并冲突的fix merge complex、获取PR评论、修复CI检查。这套技能的价值在于把"合并前的琐碎摩擦"也纳入了AI工作流。

维护阶段Pstack是空缺的——没有把issue收集并回流到规划阶段的技能。UP主在此补充了自己的super collect等方案，说明这一环目前仍需外部工具补齐。

随时可用的辅助技能与两条值得借鉴的原则

辅助技能中，potato mode充当路由器：不确定该用哪个技能时，描述问题即可，它会选择合适的技能。catch up和plain talk在切换项目上下文时特别有用，能快速回顾此前进展。

原则层面，UP主挑出两条最有价值的。第一条是attack the premise：当AI反复修同一bug、陷入"修复—阻塞—再修复"的循环时，应停下来质疑前提假设，确认方向是否正确，而不是继续在错误路径上加码。第二条是类型系统纪律：拒绝不可能状态，例如一笔支付不能同时处于已支付和待处理状态，用类型设计把这类非法组合排除在外。

核心要点

• Pstack把AI编程拆成规划、设计、构建、测试、部署、维护六个阶段，每个阶段由可触发的技能组成，原则按需加载而非塞入system prompt。
• 设计阶段用多模型arena并行出方案、再由interrogate聚合，是区别于单模型迭代的关键设计。
• no comments与cleanup diff针对AI读注释、写冗余代码的通病，通过减少噪声让模型直面真实代码。
• 测试阶段强调端到端环境搭建与多agent swarm分工，并复用设计阶段的技能对改动做攻击性验证。
• 维护阶段是Pstack的空白区，需要结合其他工具补齐闭环。

常见问题

Pstack适合从零开始的独立开发者吗？

规划阶段偏向存量项目改造，从零构建时UP主建议参考Matt Pocock或Superpower的规划技能。

为什么Pstack要把原则做成技能而不是system prompt？

避免每条消息重复读取大量无关规则，节省token并保证相关性。

no comments会不会让代码失去必要文档？

其目标是消除与代码不一致或冗余的注释噪声，避免AI采信过期注释而误判行为。