企业官网建设流程全解析

1. 一个月2000个PR到底是什么概念

先把数字摊开来看。一个月按22个工作日算，2000个PR意味着平均每天要交付90个左右的合并请求。如果按8小时工作制算，每小时要产出超过11个PR，也就是每5分钟就有一个PR从创建到合并走完全流程。这个数字放在任何一个常规研发团队里，都是不可能靠人力堆出来的。

我第一次看到这个数字的时候，第一反应是"这统计口径肯定有问题"。后来仔细琢磨了一下，这里的PR大概率不是指那种几百行改动、需要多轮review的大型功能合并，而是包含了大量小颗粒度的改动：配置调整、文档更新、小bug修复、依赖升级、测试用例补充、代码格式化等等。这类PR单个看价值不大，但累积起来对项目的健康度维护非常关键。

那问题就来了：即便都是小PR，一个人一天手动提交90个也是天方夜谭。答案只有一个——AI Agent在承担绝大部分的重复性工作。Lauren Tan作为GrokBot的核心成员，她的工作模式本质上已经从"自己写代码"转变成了"设计流程、编排Agent、审核产出"。

这个转变的意义比数字本身大得多。它意味着一个工程师的产出上限，不再取决于他打字的速度和对API的熟悉程度，而是取决于他能不能把工作拆解成AI可以执行的原子任务，并且建立起一套可靠的自动化流水线。

我自己的体会是，当你开始用AI Agent处理日常开发任务之后，你的角色会发生三个明显变化：

• 从执行者变成编排者：你不再逐行写代码，而是写"让AI写代码的指令和约束"
• 从单线程变成多线程：你可以同时推进多个Agent处理不同任务，自己只做关键决策
• 从产出导向变成质量导向：PR数量上去了，但每个PR的质量把关反而更需要你的判断力

注意：2000这个数字不应该被当成目标去追。它是流程优化到极致之后的自然结果，而不是一个可以硬凑的KPI。如果你为了凑数量让AI批量生成低质量PR，review成本会反过来吃掉所有收益。

2. 拆解这套工作流的核心组件

2.1 Cursor在这个体系里扮演什么角色

从热搜词里频繁出现的Cursor来看，它大概率是这套工作流的主力编辑器。Cursor的核心能力不是简单的代码补全，而是它内置的Agent模式可以理解整个代码库的上下文，然后根据自然语言指令直接修改多个文件、创建新文件、运行终端命令。

我实际用下来的感受是，Cursor最值钱的地方在于它把"理解代码库"这件事做成了基础设施。传统的AI编程工具你给它一段代码它帮你补全，但Cursor是你告诉它"把用户模块的错误处理统一改成新的异常体系"，它能自己找到所有相关文件，逐个修改，还能跑测试验证。

在Lauren Tan这种高产出的场景下，Cursor的使用方式大概是这样几个层次：

• 第一层：单文件编辑。选中一段代码，用Cmd+K直接下指令修改。这是最基础的用法，适合快速修bug或者重构一个小函数。
• 第二层：多文件Agent模式。用Cmd+I打开Composer，描述一个跨文件的需求，让它自己规划修改方案并执行。这个层次开始体现出效率优势了。
• 第三层：规则驱动。在项目根目录配置.cursorrules文件，把团队的编码规范、项目架构约定、常用模式都写进去。这样每次Agent执行任务时都会自动遵循这些规则，减少来回纠正的成本。
• 第四层：工作流编排。把常见的任务类型（比如"新增一个API端点"、"修复一类bug"、"升级一个依赖"）做成标准化的提示词模板，配合脚本实现半自动化甚至全自动化。

2.2 pstack和Agent编排的关系

热搜词里出现了pstack，这个词在AI编程圈子里通常指的是一种"提示词栈"的思路——把复杂的任务拆解成多层提示词，每一层负责一个特定的处理阶段，层层叠加最终完成整个任务。

打个比方，这就像工厂的流水线。你不能指望一个工人从原材料到成品全包了，而是把流程拆成若干工位，每个工位只做一件事，做完传给下一个。pstack的思路就是给AI Agent也建一条流水线：

1. 需求解析层：把模糊的需求翻译成明确的技术任务描述
2. 方案规划层：根据代码库现状，确定要改哪些文件、按什么顺序改
3. 代码生成层：逐个文件执行修改
4. 验证层：跑测试、跑lint、检查类型
5. 提交层：生成commit message、创建PR、填写描述

每一层都可以是一个独立的Agent调用，也可以是一个提示词模板。关键是把职责分离清楚，这样出问题的时候容易定位是哪一层的指令不够精确。

2.3 为什么是PR而不是直接push

这里有个细节值得说。2000个PR意味着所有改动都走了代码审查流程，而不是直接推到主分支。这说明即便在高度自动化的场景下，人工审核这一关没有被跳过。

PR在这个体系里的作用已经变了。传统意义上PR是"请别人审查我的代码"，但在AI辅助的工作流里，PR更像是"AI产出的变更记录+自动化检查的触发点"。CI流水线会在PR上跑测试、跑类型检查、跑安全扫描，这些自动化检查承担了大部分质量把关的工作，人工只需要看那些自动化检查覆盖不到的地方。

我自己的做法是给PR设置分级审核策略：

这套分级策略的核心逻辑是：把人的注意力集中在真正需要判断力的地方，而不是浪费在那些自动化工具能搞定的事情上。

3. 从需求到PR的完整流水线怎么搭

3.1 任务拆解的颗粒度控制

这是整个流程里最考验经验的地方。拆得太粗，AI一次要处理太多信息，容易出错或者遗漏；拆得太细，你自己的管理成本反而上去了。

我的经验法则是：一个PR只做一件事，且这件事可以用一句话描述清楚。比如"给用户列表接口加上分页参数校验"是一个合适的颗粒度，"优化用户模块"就太粗了，"给第47行的if条件加上null检查"又太细了。

实际操作中，我会先用一个"规划Agent"把大任务拆成小任务列表，每个小任务标注：涉及文件、预期改动类型、验证方式。然后逐个把小任务丢给"执行Agent"去完成。这样做的好处是：

• 每个PR的diff都很小，review起来快
• 出问题的时候容易回滚，不会牵连其他改动
• CI跑得快，反馈周期短
• 并行处理多个小任务比串行处理一个大任务效率高

3.2 提示词模板的沉淀

高频任务一定要做成模板。我目前积累的模板大概有二十多个，覆盖了日常开发80%以上的场景。举几个例子：

新增API端点的模板大致包含这些信息：端点路径和HTTP方法、请求参数和校验规则、响应结构、需要更新的路由注册文件、需要新增的测试文件路径、错误处理约定。

修复bug的模板则要求：bug的现象描述、复现步骤、相关日志或错误信息、疑似涉及的模块、修复后需要补充的回归测试。

依赖升级的模板需要：包名和目标版本、changelog里需要关注的breaking change、需要同步修改的调用点、验证方式。

这些模板不需要写得多复杂，关键是把每次都要重复交代的信息固化下来。你可以把它们存在项目的.prompt-templates/目录下，用的时候直接引用。

3.3 自动化验证的关卡设计

AI生成的代码最大的风险是"看起来对但实际有问题"。所以验证环节必须做厚。

我通常设置这几道关卡：

1. 类型检查：TypeScript项目跑tsc --noEmit，Python项目跑mypy。类型错误是最容易被AI忽略的问题。
2. Lint检查：ESLint或者Ruff，确保代码风格一致。这个可以在Cursor的rules里提前约束，减少后期修正。
3. 单元测试：要求AI在修改代码的同时补充或更新对应的测试用例。测试通过是最基本的门槛。
4. 集成测试：对于涉及接口变更的PR，跑一遍集成测试确保没有破坏上下游。
5. 人工抽查：随机抽取一定比例的PR做详细review，检查AI有没有"偷懒"——比如该处理的边界条件没处理，该加的日志没加。

提示：验证关卡不是越多越好。每多一道关卡就多一份维护成本。我的建议是从类型检查+单元测试这两道最基础的开始，跑顺了再逐步加。

4. 高产出的背后：哪些环节最容易被忽略

4.1 上下文管理比提示词技巧更重要

很多人研究AI编程的时候，把大量精力花在"怎么写出更好的提示词"上。但实际用下来，给AI提供正确的上下文比提示词本身重要得多。

什么叫正确的上下文？就是让AI在动手之前，能看到所有它需要知道的信息：相关的代码文件、项目的目录结构、已有的类似实现、团队的编码约定、当前分支的状态。

Cursor在这方面做得比较好，它会自动索引整个项目。但自动索引不等于AI每次都能找到正确的参考。我的做法是，在提示词里显式指定参考文件。比如"参考src/api/user.ts里的错误处理模式，给src/api/order.ts加上同样的处理"。这样AI就不用猜了，直接照着已有的模式来。

4.2 处理AI的"自信错误"

AI最危险的地方不是它不会，而是它不会的时候也表现得很自信。它会生成一段看起来完全合理的代码，语法没问题，逻辑也说得通，但就是不符合你项目的实际情况。

我踩过几次坑之后总结出来的应对方法：

• 关键路径的代码必须人工过一遍。什么叫关键路径？涉及资金、权限、数据一致性的代码。这些地方AI可以帮你写初稿，但最终判断必须是人做的。
• 让AI解释它的改动。在创建PR的时候，要求AI在描述里写清楚"为什么这样改"和"有没有其他方案"。如果它的解释逻辑不通，那代码大概率有问题。
• 对比测试。对于重构类的改动，保留旧实现，写一个对比测试确保新旧行为一致。

4.3 什么时候该停下来手动写

不是所有任务都适合交给AI。我总结了几种AI搞不定或者搞起来不划算的情况：

• 需要深度业务理解的改动：AI不了解你的业务规则，强行让它改容易出逻辑错误
• 涉及外部系统交互的调试：需要看真实日志、抓包分析的问题，AI帮不上忙
• 性能优化：需要profiling数据支撑的优化决策，AI只能给通用建议
• 紧急线上问题：时间紧迫的情况下，自己上手比给AI解释问题更快

判断标准很简单：如果你给AI解释这个任务的时间，比你自己动手做的时间还长，那就别用AI。

5. 这套模式对个人和团队意味着什么

5.1 个人开发者的效率天花板被抬高了

以前一个独立开发者，能同时维护的项目数量是有限的。现在有了AI Agent的辅助，一个人可以覆盖的代码量至少翻了两三倍。这意味着独立开发者可以承接更复杂的项目，或者用同样的时间做出更完整的产品。

但这里有个陷阱：产出增加不等于价值增加。如果你用AI生成大量低质量的代码，后期维护成本会指数级上升。真正有价值的是用AI处理那些重复性的、模式化的工作，把自己的精力释放出来做架构设计、技术选型和关键决策。

5.2 团队协作模式需要调整

当团队里有人开始用AI大规模产出PR的时候，review的人会最先感受到压力。如果还是按传统方式逐个仔细review，review者会变成瓶颈。

我们团队的做法是：

• 调整PR的粒度标准，鼓励小PR，但要求每个PR自带充分的上下文说明
• 强化自动化检查，把能自动化的检查全部自动化，减少人工review的负担
• 建立AI产出的标记机制，让review者知道哪些PR是AI生成的，需要重点关注什么
• 定期回顾AI产出的问题模式，把常见问题反馈到提示词模板和rules里

5.3 代码审查的重点在转移

以前review代码，大量时间花在"这个变量名起得不好"、"这里少了个空行"、"这个函数太长了"这类风格问题上。现在这些都可以通过lint和格式化工具自动解决，review者的精力可以集中在：

• 这个改动是否真正解决了问题
• 有没有遗漏的边界条件
• 对现有功能有没有潜在影响
• 测试覆盖是否充分

这个转变对工程师的能力要求其实更高了。以前你可以靠"代码写得漂亮"获得认可，现在代码风格的事AI帮你搞定了，你得靠"判断得准确"来体现价值。

6. 我实际跑这套流程时踩过的坑

6.1 一开始贪多，结果PR堆积如山

最开始我尝试让AI一次性处理一个大模块的重构，生成了几十个文件的改动。结果PR大到没人愿意review，CI跑了四十分钟才出结果，中间还挂了三次。最后这个PR被拆成了十几个小PR才合并进去。

教训就是：AI能一次处理很多文件，不代表你应该让它一次处理很多文件。PR的大小应该由review的便利性决定，而不是由AI的能力上限决定。

6.2 提示词写得太"聪明"反而坏事

有段时间我试图写非常详细的提示词，把每一步操作都规定死。结果AI变得很死板，遇到提示词没覆盖到的情况就卡住了。后来我改成"给方向不给步骤"——告诉AI目标和约束条件，具体怎么做让它自己判断。这样灵活性强很多，出错的概率反而降低了。

6.3 忽略了AI的"上下文遗忘"

在一个长对话里，AI可能会忘记前面几轮交代过的约束。比如你一开始说了"所有日期都用UTC"，聊了十几轮之后它可能就忘了，开始用本地时间。解决办法是把关键约束写进.cursorrules文件，这样每一轮对话它都会重新读取这些规则，不会遗忘。

6.4 测试没跟上，bug漏到了生产环境

有一次AI修改了一个工具函数的返回值类型，从string | null改成了string，但忘记更新调用方的null检查。类型检查没报错是因为调用方用了非空断言，单元测试没覆盖到这个分支。结果上线后遇到null的情况直接崩了。

从那以后我定了一条规矩：AI修改任何函数的签名，必须同时更新所有调用点和对应的测试。这条规矩写进了提示词模板里，每次都会提醒AI执行。

7. 如果你想复制这套模式，从哪开始

7.1 先把手动流程跑顺

不要一上来就追求自动化。先用手动的方式走几遍完整流程：接到任务、拆解、用AI生成代码、验证、提交PR。跑顺了之后，你自然就知道哪些环节可以固化、哪些环节需要灵活处理。

7.2 从最高频的任务开始模板化

统计一下你日常工作中出现频率最高的任务类型，挑前三个做成提示词模板。不要贪多，先把这三个打磨好，用出效果了再扩展。

7.3 建立自己的检查清单

每个PR合并前需要检查什么，列一个清单。刚开始可以手动对照检查，熟练之后可以把清单里的自动化检查项配置到CI里。我的清单大概长这样：

• 类型检查通过
• Lint通过
• 单元测试通过且覆盖率没有下降
• 没有引入新的依赖（除非PR目的就是升级依赖）
• 变更描述清晰说明了改了什么和为什么改
• 涉及接口变更的，上下游已同步更新

7.4 定期回顾和迭代

每隔一两周花半小时回顾一下：哪些PR被打回了、打回的原因是什么、提示词模板需要怎么调整、有没有新的高频任务值得做成模板。这个迭代过程比一次性搭建完美流程重要得多。

注意：不要照搬任何人的流程，包括我这套。每个人的项目类型、团队规模、技术栈都不一样，适合的流程也不一样。把别人的经验当成起点，根据自己的实际情况调整，才是正确的做法。

8. 关于AI辅助编程的一点个人看法

用AI写代码这件事，最大的价值不在于"写得快"，而在于它强迫你把脑子里的隐性知识显性化。以前你知道"这个模块的代码应该这样写"，但你说不清楚为什么。现在你要让AI帮你写，你就必须把"为什么"讲清楚。这个过程本身就在帮你梳理和沉淀知识。

另一个感受是，AI辅助编程把工程师的工作重心从"实现"推向了"判断"。实现这件事正在变得越来越廉价，而判断什么值得实现、什么实现方式是好的、什么改动是安全的，这些判断力的价值在快速上升。

Lauren Tan一个月2000个PR这个数字，表面上看是效率的胜利，但底层其实是流程设计和质量判断的胜利。AI只是执行者，真正决定产出质量和数量的，是背后那套经过反复打磨的工作流。你想复制这个结果，要学的不是"怎么用Cursor"，而是"怎么设计一套让AI能稳定产出高质量代码的流程"。这个能力，目前还没有任何AI能替你掌握。