极致效能背后的工程师背景与核心数据

SpaceX AI团队资深工程师Lauren Tan（网名poteto）展示了一种令人震惊的AI协作模式：她个人在一个月内成功合并了2500张PR（Pull Request，即代码提交记录）。对于非技术背景读者而言，一张PR可视为一份工作结案报告；传统工程师一天处理两三个小案子已属高效，配合普通AI辅助每天十几个已是顶尖水平，而Lauren的平均处理量高达80多个案子/天。更惊人的是，她曾发现AI在她睡眠期间自动完成了20个PR的编写、检查与提交。这一成果并非源于低质量代码，而是基于她曾在Netflix、Meta及Cursor等顶尖科技公司积累的深厚工程素养。Lauren将这套工作流开源为pstack，其核心在于通过精细化的模型分工与自动化流程，解决人类审核瓶颈。她强调：不同模型有各自的强项跟成本，不应该从頭到尾只用同一个模型。因此，pstack通过初始化设置（/setup-pstack），将耗体力任务分配给便宜快速的Grok，而将架构设计、深度判断等复杂思考交给Claude Opus等前沿模型，从而在成本与效率间取得平衡。

规划阶段：从全局理解到Prompt深度优化

pstack工作流包含近60个skill，其中24个为底层工程原则（供AI阅读），其余35个左右为工具型skill。用户只需记住一个总管指令/poteto-mode，它作为“工地主任”会根据任务类型（修Bug、新功能或性能优化）自动调用标准作业手册。在前期规划阶段，Lauren引入了两个关键skill：/how与/why。/how强迫AI在规划前彻底读透相关模块，建立全局观以避免架构冲突；/why则通过挖掘Git记录、工单系统甚至Slack聊天记录，还原代码设计的历史背景与防呆机制，防止AI因不知前因而破坏原有逻辑。此外，/sharpen skill用于优化用户输入的Prompt，它不发散需求而是聚焦深度：要求AI从第一性原理出发查看原始源码而非二手文档，并锁定领域专家使用的具体工具与验证方法。最终生成的Prompt包含明确的验收条件和专业深度，确保AI在动手前已充分理解任务本质。

实作阶段：架构隔离、多模型比稿与测试驱动开发进入中期实作，pstack引入了/architect（建筑师）skill。其核心精神是“先画格局图再动砖”，规定AI从用户视角倒推系统外框与分工，且设计标准需满足“即使下一个AI只看局部文件也能无脑照抄出正确结果”的鲁棒性。在架构设计环节，/arena skill会自动将同一题目丢给不同模型进行比稿，交叉比对后融合各家亮点形成最终骨架。在代码编写阶段，pstack强制使用/tdd（测试驱动开发）以防止AI作弊。传统做法中，若让AI先写代码再补测试，它可能生成配合错误逻辑的假测试来通过检查；而/tdd要求AI在写任何代码前必须先编写注定失败的红色测试用例，只有当功能实现使绿灯亮起时才允许提交。这种机制确保了代码逻辑的正确性从源头得到验证，避免了后续返工。

验收阶段：自动化审核、独立裁判与防呆机制

后期验证是解决Agentic Coding中Verification（自我检查）瓶颈的关键。Lauren通过三个Skill逼AI在提交PR前自证清白：首先，/create-verification-skill让AI阅读项目并生成类似真人的操作SOP，自动运行App录制视频或截图作为功能正常的证据；其次，/blast-radius评估修改的影响范围，标记高风险PR以便人工重点审核；最后，/interrogate进行交叉审问，将代码同时丢给不同家族模型（如Claude与Grok）抓漏，利用盲点互补发现单一模型无法察觉的漏洞。在全自动夜间模式下（/poteto-mode），系统设定铁律：写PR的AI永远没有权力核准自己的PR。当PR准备合并时，/swarm skill会派出约10个未参与编写的独立AI在云端进行点击测试，只有全部通过才会自动合并。次日早上，Lauren利用/show-me-your-work查看AI的决策记录表（包含失败尝试与最终验证），并通过另一模型核对标记出风险点，从而快速抽样检查。若发现AI反复犯同一错误，她使用/correct skill将软规则转化为系统级的防呆机制（如统一代码写法、增加Linter检查），从物理上杜绝错误复现。

构建防呆环境与多模型交叉验证

Lauren在Cursor内部推行了一套名为pstack的自动化工作流，其核心在于通过环境改造让AI难以犯错。她首先在项目中新增Linter规则并禁用错误写法，一旦CI自动检查亮红灯，AI必须修正才能完成任务。这种硬性约束优于软性规则（如AGENTS.md），因为后者缺乏强制力。得益于此，团队中不懂深度开发的产品经理和设计师也能自行调用AI修改功能并提交PR，且通常一眼即可核准。这套流程在前期规划、中期实作到后期验证中，善用不同模型的强项进行比稿和交叉审问，将单次产出质量拉到极致。随后通过极致的自动化验证与防呆环境，确保每张PR都经得起考验，从而让人类敢于放手。

平行派工与自动进单的双引擎机制

为了支撑每月合并2500张PR（日均80+）的规模，Lauren在pstack外围搭建了两套机制：平行派工与自动进单。她像经营分店一样，同时开启十几个项目（如桌面版速度优化、Bug修复），每个项目中有一个不写代码的“总管AI”负责全局拆解任务，派发给底层工人AI执行。在自动进单方面，对外使用Grok Bot 24小时监控Slack、X和Email的用户反馈。针对模糊的报错，Grok Bot会先查阅代码与工单记录，在云端复现Bug并确认未修复后，打包成清晰的任务单派发给总管AI。对内则派遣巡逻AI扫描坏写法并记录清单，发现共性问题时由总管AI统一处理，避免多个AI各自瞎忙。这种机制解决了开发瓶颈，适应了非Scrum模式下快速响应需求的趋势。

信任曲线的四个进阶阶段与Matt Pocock方案对比

Lauren的成长轨迹印证了“人类介入越少，AI并行度越高”的信任曲线。她经历了四个阶段：第一阶段是全程紧盯着做“人肉转接头”，这是大多数人的起点；第二阶段实现AI自我验收，通过附带截图和视频证据让人类判断对错；第三阶段进化为AI自动接单与修复，人类仅在最后看结果；第四阶段才是AI自动合并，人类仅做事后抽查。这与Matt Pocock的skill工作流形成对比：Matt侧重动工前的人机对齐（grill-me生成规格书）和合并前的最后把关，适合从0到1的模糊需求；而Lauren的pstack侧重动工后的多模型自动验收和极低的人类介入，适合处理庞杂的历史代码修复。两者可互补：前期用Matt理清思路，后期用pstack严格落地。

新手构建自动化工作流的六步法建议

对于希望迈向全自动工作的开发者，Lauren给出了保守且扎实的六个步骤。第一步是用单个AI观察其常见错误并记录；第二步是将纠正转化为规则，优先使用系统检查而非文档约束。第三步要求AI交件时必须附带证据（如截图、核对列表），让人类无需打开文件即可判断。第四步尝试同时开启两三个AI，并实行“写”与“审”分离，由不同模型挑错。第五步是睡前交代任务但停在合并前，设定非黑即白的完成条件和停损点。第六步在确认AI能稳定产出后，开启自动合并与定时巡检。前四步是投资回报率最高的基本功。最终形成的不是通用的pstack或grill-me，而是属于个人工作流的信任体系。Lauren强调，不要在地基未稳时盲目并行运行AI，否则只会加速产出垃圾并浪费Token。

结论

pstack工作流通过精细化模型分工、强制测试驱动开发及自动化交叉验证，成功将单人月合并PR量提升至2500张（日均80+），证明了在严格防呆环境下，AI可承担绝大部分工程劳动。其核心优势在于利用廉价模型处理体力活、前沿模型负责架构，并通过独立AI集群进行夜间自动审核与合并，极大降低了人类介入成本。

该方案并非万能解药：它高度依赖开发者深厚的工程素养以建立初始规则，且主要适用于庞杂历史代码的修复与迭代，而非从零开始的模糊需求探索。对于新手而言，直接并行运行AI易导致垃圾产出与Token浪费；建议遵循六步法逐步建立信任体系，先实现AI自我验收再过渡到自动合并。