拆解PStack：Cursor工程师的AI编程技能库与工作流

AI编程工具正在从单一的代码补全走向系统化的技能库。最近，曾任职于SpaceX、Meta并身为React核心团队成员的工程师Lauren Tan，将其积累的知识工作流与开发原则整理成一套名为PStack的开源仓库。这套工具究竟包含哪些技能？它与我们熟悉的MapPocock、Superpowers等框架有何不同？本文基于B站UP主的详细拆解视频，带你完整梳理PStack的六阶段工作流与核心设计哲学。

PStack是什么：面向存量项目的AI开发操作系统

PStack并非一个从零开始的项目脚手架，它的核心定位是服务所谓的“Brownfield项目”——即已经有一套现成代码的存量项目。Lauren Tan将技能归入六个阶段，对应一整套AI软件开发生命周期：规划、设计、构建、测试、部署、维护。

这套仓库的独特之处在于，它不追求覆盖所有场景，而是聚焦于“在既有代码基础上继续开发”这一高频痛点。对于独立开发者或想从零搭建全新应用的人来说，UP主坦言自己更倾向于MapPocock或Superpowers的技能；但如果你面对的是大规模迁移或复杂系统调整，PStack的规划技能就非常对路。

六阶段工作流拆解：从读懂代码到安全交付

规划与设计：先理解，再让多模型“赛马”

在规划阶段，PStack提供了两条工作流：读懂现有代码，以及规划一项大任务。想知道代码怎么运转，可以用How技能；想理解设计动机，用Why技能；Teach则把两者结合，既解释工作方式也说明背后原因。若要将任务拆成工单，Figure It Out配合Show Me Your Work能把决策记录到正式文档中。

设计阶段的亮点是“确定代码形状”。Architect架构技能会调用多个不同的AI智能体，让它们分别展开设计，拿出各自的实现方案。随后Interrogate技能让模型评判这些方案，比较各家结果并汇总成一份完整设计报告。这和大多数只依赖单一模型给出答案的框架截然不同——你可以让Opus、GPT、Grok各自跑一轮设计，再挑出每个模型做得最好的部分整合。

Brownfield与Greenfield：在软件工程中，Greenfield项目指从零开始、无历史包袱的全新开发；Brownfield项目则指在已有代码库上继续演进，需兼容现有架构、依赖和业务逻辑。后者往往面临理解成本高、变更风险大等挑战，PStack的定位正是系统化应对这类场景。

多模型“赛马”机制：指并行调用多个不同的大语言模型（如Opus、GPT、Grok）对同一设计任务独立生成方案，再通过评判技能比较优劣、整合最佳部分。这种模式利用模型间的多样性降低单一模型的偏见风险，但会增加Token消耗与协调复杂度，适合对设计质量要求高的关键决策。

构建：TDD先行，清理AI味代码

构建阶段准备了两条工作流。第一条是按测试驱动开发写代码，由TDD技能负责。UP主此前专门对比过PStack、MapPocock与Superpowers的TDD技能差异：快速修复小问题、开发新功能、或在强调纪律的团队中工作，适合的选择各不相同。TDD之后还会配上TypeScript最佳实践技能，因为Lauren Tan主要关注React开发，而React与TypeScript深度绑定。

第二条是清理代码差异。Deslop技能会比较主分支与当前分支，检查改动中是否有多余注释、不必要的Try Catch、缺少明确类型的变量以及过深嵌套。这里有一个关键设计：PStack专门有一项No Comments技能，强调少写注释。原因很直接——AI有时会直接读注释而不仔细看实际代码。如果注释写着函数返回A，实现却返回B，AI可能只盯着注释把它当事实。去掉多余注释，是为了让AI真正去看代码本身。

测试驱动开发（TDD）：一种先写测试、再写实现代码的开发方法，通过“红-绿-重构”循环确保代码始终有测试覆盖。在AI编程场景中，TDD技能要求AI先根据需求生成失败的测试用例，再编写通过测试的实现，从而约束AI不偏离目标。

AI味代码：指AI生成代码中常见的冗余模式，如过度防御性的Try-Catch、无信息量的注释、模糊的类型声明（如any）以及不必要的深层嵌套。这些代码虽能运行，但降低可读性与可维护性。Deslop技能通过对比分支差异自动识别并清理此类问题。

测试：端到端验证与多智能体“攻击”

测试阶段有三条工作流。第一条是证明应用确实能运行，对应Create Verification Skill。它与TDD的区别在于：TDD侧重功能测试和单元测试，而这项技能重点是搭建端到端验证环境——数据库要配置、服务器要启动、依赖要就位，按真实用户使用应用的方式把整套环境跑起来，遇到问题就诊断，收集证据后清理环境。

第二条是Swarm，让一组智能体分工合作。不必让同一个智能体独自跑完整条流程，可以让多个智能体分别负责不同页面，你甚至可以为每个智能体选择不同的模型，最后汇总成一份报告。

第三条是主动攻击这次改动。Interrogate技能再次登场，先比较主分支与功能分支识别改动范围，再让不同模型从不同角度尝试把变更弄出问题，找出薄弱之处。另有一项名为“热合级代码质量审查”的技能，相当于再加一层格外严格的审查，追问代码还能不能写得更简单，思路与Ponytail技能相似。

部署与维护：覆盖交付全链路

部署阶段处理合并请求。第一步是让PR更容易审查，但每个团队有自己的写作风格，PR怎么写仍取决于你的偏好。后续还有BabySit技能持续盯住合并请求直到确认合并成功，修复合并冲突的技能，以及获取PR审查意见、列出评论、修复CI流水线检查的相关技能。

到了维护阶段，PStack没有专门负责“把问题带回规划阶段”的技能。UP主指出，这一环可以借助此前评测过的Superpowers的SuperCollab等维护类技能补齐。

PR（Pull Request）审查自动化：PStack部署阶段包含获取PR评论、列出待办、修复CI流水线失败等技能，旨在将代码审查与合并流程中的重复性工作交给AI代理。BabySit技能可持续监控PR状态直至合并，减少人工轮询成本。

CI流水线检查：持续集成（CI）流水线会在每次提交时自动运行测试、构建和静态检查。PStack相关技能能读取CI失败日志，定位问题并尝试修复，缩短反馈循环。

辅助技能与原则技能：按需加载的Token经济学

除了六阶段主流程，PStack还有一组随时可调用的辅助技能。路由技能Petito Mode会在你不知道该调用哪个技能时，帮你把问题说清楚并选择合适的技能处理。

此外还有安装设置、回顾上下文、写作以及持续改进PStack本身的技能。UP主特别喜欢用来补齐上下文、用简单化解释的那一组，尤其是Recall——当你在几个项目间来回切换，想重新想起某个项目之前做到了哪一步，这组技能能帮你跟上进展。

PStack里还有大量原则技能。为什么把它们写成技能而不直接放进系统提示词？原因在于Token成本：把所有规则塞进系统提示词会变成一个巨大文件，每发一条消息AI都要读一遍，而其中信息未必与眼前任务相关。PStack把这些原则拆成若干技能，再配一张索引图，明确每项原则应该在什么情况下触发。

UP主挑了几项最有帮助的原则。第一是保持简单、控制规模，与Ponytail技能思路相近。第二是一条关于“卡住循环”的原则：有时你让AI修一个问题，它说修好了但问题还在，再修还是发生，AI陷进一边修一边卡住的循环。这时该技能要求AI先停下来，重新审视自己的假设——在继续沿这个方向动手之前，先确认选的路对不对。第三是类型系统纪律：必须把不可能成立的状态排除掉，比如一笔付款不可能同时既是已支付又是等待支付，应通过类型设计解决。

Token经济学：大语言模型按Token计费，且上下文窗口有限。将大量原则性规则放入系统提示词会导致每次请求都携带冗长前缀，既增加成本又可能稀释关键指令的注意力。PStack将原则拆分为独立技能，仅在触发时加载，实现“按需付费”的上下文管理策略。

类型系统纪律：利用TypeScript等静态类型系统，通过联合类型、字面量类型和不可变状态建模，使非法状态在编译期无法表示。例如用type Payment = { status: 'paid' } | { status: 'pending' }替代可同时为真的布尔标志，从根源上消除一类运行时错误。

多源视角下的框架选型

综合B站UP主的拆解与Lauren Tan公开的仓库设计，PStack的差异化价值在于两点：一是面向存量项目的务实定位，二是多模型协作的设计与审查机制。但也要看到它的边界——从零规划并非其强项，维护闭环也需要配合其他框架。对于正在搭建AI编程工作流的团队，PStack更像是一套可借鉴的“技能组织方法论”，而非一站式解决方案。

UP主表示会把PStack技能图谱与对比页面入口放在视频简介中，方便开发者直接研究。无论你最终是否采用这套框架，它关于注释噪音、多模型赛马、按需加载原则的设计思路，都值得纳入自己的AI编程实践。