企业官网建设流程全解析

1. 一个月2000个PR背后的工作方式拆解

第一次看到“每月交付2000个PR”这个数字，我的反应和大多数人一样：要么是标题党，要么是把依赖更新机器人的提交也算进去了。但仔细看完Lauren Tan在GrokBot团队的工作分享后，我发现这个数字背后其实是一套相当务实的工作方法，而且这套方法对普通开发者同样有参考价值。

先把这个数字拆开算一笔账。按每月22个工作日算，2000个PR意味着日均约90个。一个人手动完成显然不可能，所以核心必然在于把AI Agent深度嵌入到开发流水线的每一个环节，让机器承担绝大部分重复性劳动，人只负责决策、审查和关键路径上的判断。Lauren在分享中提到的工具组合主要是Cursor配合自定义的Agent工作流，再加上一套被她称为“pstack”的个人效率体系。

这篇文章我想做的事情很明确：把她的工作方式拆解成可复现的步骤和原则，而不是停留在“哇好厉害”的层面。适合谁来读？如果你已经在用Cursor或者类似的AI编程工具，但感觉效率提升有限，那这篇内容应该能帮你找到几个可以立刻用上的改进点。如果你还没开始用AI辅助编程，也可以先了解这套工作流的全貌，再决定从哪个环节切入。

提示：本文讨论的所有工具和方法都基于公开可获取的开发者工具，不涉及任何特殊渠道或非公开资源。

2. 核心思路：为什么是“Agent流水线”而不是“AI补全”

2.1 从代码补全到任务委托的思维转变

大多数人用Cursor的方式还停留在“高级自动补全”阶段：写几行代码，等AI提示下一行，Tab键接受，继续写。这种方式确实能省一些打字时间，但效率提升是有上限的，因为你仍然是整个流程的瓶颈——每一行代码都需要你的注意力。

Lauren的做法有本质区别。她把AI Agent当作可以独立完成任务的协作者，而不是一个更聪明的输入法。具体来说，她的工作单元不是“一行代码”或“一个函数”，而是“一个完整的PR”。一个PR可能包含新增功能、修改测试、更新文档、调整配置，这些子任务被打包成一个完整的上下文交给Agent去执行。

这个思维转变带来的直接后果是：你不再需要逐行审查AI的输出，而是像审查一个同事的PR一样审查Agent的产出。审查的粒度变粗了，但审查的标准反而更高了——因为一个PR涉及的面更广，你需要关注的是整体逻辑是否自洽、边界条件是否覆盖、测试是否充分，而不是某个变量名是否拼写正确。

2.2 为什么选择Cursor作为核心工具

市面上AI编程工具不少，Lauren选择Cursor作为主力有几个实际原因。第一是项目级上下文理解能力，Cursor能够索引整个代码库，Agent在生成代码时能参考项目中的既有模式、命名习惯和架构约束，而不是凭空发挥。第二是多文件编辑能力，一个PR往往涉及多个文件的联动修改，Cursor的Agent模式可以一次性处理这些关联变更。第三是终端集成，Agent可以直接运行测试、查看报错、根据反馈迭代修改，形成闭环。

这里要补充一个常见实践的判断：如果你现在的项目规模较小，或者技术栈比较单一，用GitHub Copilot配合手动操作也能达到类似效果。但当项目复杂度上升到需要跨文件、跨模块协调时，Cursor的Agent模式优势会明显放大。选择工具的核心标准不是“哪个最强”，而是“哪个能让我把完整任务委托出去”。

2.3 pstack体系的核心原则

Lauren提到的“pstack”并不是一个具体的软件产品，而是她个人总结的一套工作原则。我理解下来，核心有三条：

• 任务原子化：每个PR只做一件事，但这件事要完整。比如“给用户模块添加邮箱验证功能”是一个合格的原子任务，“修改用户模块”就太模糊了。
• 上下文前置：在启动Agent之前，把所有相关的背景信息准备好——相关的issue链接、设计文档、需要参考的既有实现、测试要求。这些信息一次性喂给Agent，而不是边做边补。
• 审查即反馈：审查Agent产出的PR时，不要直接改代码，而是把修改意见作为新的指令反馈给Agent，让它自己修正。这样Agent能在迭代中学习你的偏好，后续产出质量会逐步提升。

这三条原则看起来简单，但实际执行时需要刻意练习。尤其是第一条，很多人会不自觉地在一个PR里塞进多个不相关的修改，导致审查困难、回滚风险高。

3. 实操流程：一个PR从需求到合并的完整路径

3.1 需求拆解与任务描述编写

假设现在有一个需求：给系统的用户设置页面增加一个“导出个人数据”的按钮，点击后生成包含用户基本信息和操作记录的JSON文件供下载。

Lauren的做法不是直接打开Cursor开始写代码，而是先花几分钟写一段任务描述。这段描述会包含以下要素：

• 功能目标：用户可以在设置页面点击按钮，下载包含个人数据的JSON文件
• 涉及范围：前端设置页面组件、后端API接口、数据查询逻辑、文件生成逻辑
• 参考实现：项目中已有的“导出操作日志”功能可以作为参考，路径在src/modules/export/目录下
• 测试要求：需要覆盖正常导出、无数据导出、大数据量导出三种场景
• 约束条件：JSON文件大小不超过10MB，导出操作需要记录审计日志

这段描述写完后，直接粘贴到Cursor的Agent对话窗口中，作为启动指令。这里的关键是信息密度要高但不要冗余——把Agent需要知道的都写上，但不要写“请帮我实现一个功能”这种废话。

实操心得：任务描述写得好不好，直接决定Agent第一次产出的质量。我自己的经验是，如果Agent第一次产出需要大改，八成是因为任务描述里漏了关键约束。与其反复调教Agent，不如回头把需求想清楚。

3.2 Agent执行与中间检查点设置

Agent启动后，会经历几个阶段：理解需求、检索相关代码、生成修改方案、执行修改、运行测试。Lauren不会全程盯着Agent执行，但会设置几个中间检查点。

第一个检查点是Agent生成修改方案后。这时候Agent通常会列出它打算修改哪些文件、每个文件改什么。这个阶段花30秒扫一眼，确认方向没错，比等到全部改完再发现方向错了要划算得多。

第二个检查点是Agent完成代码修改但还没运行测试时。这时候快速浏览一下核心逻辑的实现，确认没有明显的逻辑错误。如果发现问题，直接在当前对话中反馈，让Agent修正后再继续。

第三个检查点是测试运行结果出来后。如果测试通过，进入人工审查阶段；如果测试失败，看Agent是否能自行修复。Lauren提到，大约70%的测试失败Agent能自己解决，剩下30%需要人工介入——通常是环境问题或测试用例本身有误。

3.3 人工审查的重点与边界

Agent完成PR后，Lauren的审查重点集中在四个方面：

审查时有一个重要原则：不要直接修改代码。如果发现需要调整的地方，把修改意见写清楚，反馈给Agent让它自己改。这样做的好处是，Agent会在后续任务中记住你的偏好，同类问题会越来越少。直接改代码虽然快，但相当于放弃了让Agent学习的机会。

3.4 合并策略与批量处理技巧

当多个PR同时在进行时，Lauren采用批量审查、批量合并的策略。具体做法是：每天固定两个时间段集中处理PR审查，而不是来一个审一个。这样做的原因是，审查工作需要上下文切换，频繁切换会降低效率。

批量处理时，她会先按优先级排序：阻塞其他工作的PR优先审，纯文档或配置修改的PR可以稍后。审查过程中如果发现某个PR需要较大修改，直接打回给Agent重新处理，不占用自己的时间。

合并策略上，她倾向于小步快跑：每个PR尽量小，合并频率高。这样即使某个PR有问题，影响范围也有限。2000个PR的数字之所以能成立，很大程度上是因为每个PR的粒度控制得好，审查和合并的成本都低。

4. 关键工具链配置与参数调优

4.1 Cursor的项目级配置要点

要让Cursor的Agent模式发挥最大效果，项目级的配置很关键。Lauren的配置清单里，以下几项是必须的：

首先是.cursorrules文件。这个文件放在项目根目录，用来告诉Cursor这个项目的编码规范、技术栈约束、目录结构约定等信息。比如：

# 项目编码规范 - 使用TypeScript严格模式 - 组件文件使用PascalCase命名 - 工具函数使用camelCase命名 - 所有API接口必须有JSDoc注释 - 测试文件放在__tests__目录下，与源文件同层级

这个文件的作用是让Agent在生成代码时自动遵循项目规范，减少后续调整的工作量。根据我的实测，配置好.cursorrules后，Agent产出的代码在命名规范方面的返工率能降低60%以上。

其次是索引配置。Cursor需要索引整个代码库才能提供准确的上下文。对于大型项目，建议在.cursorignore中排除node_modules、dist、build等目录，加快索引速度。索引完成后，Agent在检索相关代码时的准确率会明显提升。

4.2 Agent提示词模板设计

Lauren在长期使用中沉淀了一套Agent提示词模板，核心结构如下：

## 任务 [一句话描述任务目标] ## 背景 [相关issue链接、设计文档、业务上下文] ## 参考实现 [项目中已有的类似功能路径] ## 具体要求 - [要求1] - [要求2] - [要求3] ## 测试要求 - [测试场景1] - [测试场景2] ## 约束条件 - [约束1] - [约束2]

这个模板的价值在于结构化和可复用。每次启动新任务时，只需要填充各个部分的内容，不需要重新组织语言。而且由于结构固定，Agent能更快理解任务意图，减少来回确认的次数。

注意：模板中的“参考实现”部分特别重要。给Agent一个具体的参考文件路径，比用文字描述“类似某某功能”要有效得多。Agent可以直接读取参考文件的代码，理解实现模式，然后应用到新任务中。

4.3 测试与验证的自动化配置

Agent生成的代码需要验证，而验证的核心手段是自动化测试。Lauren的项目中配置了以下自动化环节：

• 单元测试：使用Jest或Vitest，Agent生成代码后自动运行相关测试文件
• 类型检查：TypeScript项目配置tsc --noEmit作为快速验证手段
• Lint检查：ESLint配合Prettier，确保代码风格一致
• 构建验证：对于前端项目，运行一次生产构建确认没有引入编译错误

这些检查项被配置为Agent工作流的固定步骤。Agent完成代码修改后，会自动依次运行这些检查，根据结果决定是否需要迭代修改。只有当所有检查都通过后，PR才会进入人工审查阶段。

这套自动化配置的收益是显而易见的：人工审查时不需要再关注代码风格、类型错误、构建失败这些低级问题，可以把精力集中在业务逻辑和架构设计上。

5. 常见问题与排查技巧实录

5.1 Agent产出质量不稳定的应对方法

即使配置得当，Agent的产出质量也会有波动。Lauren总结了几种常见情况和对策：

情况一：Agent生成的代码偏离项目既有模式。这通常是因为.cursorrules配置不够具体，或者任务描述中没有指定参考实现。对策是在任务描述中明确给出参考文件路径，并在.cursorrules中补充更详细的模式说明。

情况二：Agent反复修改同一个问题但始终不对。这往往是因为任务描述本身有歧义，或者Agent对某个业务概念的理解有偏差。对策是暂停Agent，人工介入澄清需求，然后用更精确的语言重新描述任务。

情况三：Agent生成的测试用例质量差。测试用例的质量取决于任务描述中对测试要求的详细程度。如果只写“需要测试”，Agent可能只生成一个最简单的正常流程测试。对策是在任务描述中明确列出需要覆盖的场景，包括边界条件和异常情况。

5.2 PR审查中的高频问题速查

以下表格整理了Lauren在审查Agent产出PR时最常遇到的问题类型和处理方式：

这张表的价值在于快速定位问题类型。审查时如果发现某个PR有问题，先对照这张表判断属于哪一类，然后按照对应的处理方式操作，避免每次都要从头分析。

5.3 避免Agent“幻觉”的实用技巧

AI Agent有时会“幻觉”出项目中不存在的函数、库或配置项。Lauren的应对技巧包括：

• 在任务描述中明确技术栈版本：比如“使用React 18的hooks API”，避免Agent使用过时的类组件写法。
• 要求Agent先检索再生成：在提示词中加入“请先搜索项目中是否已有类似实现，如果有则复用，如果没有则新建”。这个简单的指令能大幅减少重复造轮子和引用不存在模块的问题。
• 对关键依赖进行锁定：在package.json中锁定依赖版本，避免Agent引入不兼容的新版本。
• 审查时验证import路径：Agent生成的import语句有时会指向不存在的文件，审查时快速扫一眼import部分就能发现。

实操心得：Agent幻觉最常出现在它“不确定”的时候。如果你发现Agent在某个地方反复修改或者给出多种方案，说明它对这部分不够确定。这时候人工介入给一个明确的指令，比让Agent自己猜要高效得多。

6. 从2000个PR中提炼的可复用经验

6.1 任务粒度控制的黄金标准

2000个PR能成立的前提是每个PR都足够小。Lauren的粒度控制标准是：一个PR的diff应该能在5分钟内审查完。如果超过这个时间，说明PR太大了，需要拆分。

具体拆分方法：按功能点拆、按文件类型拆、按依赖关系拆。比如“添加导出功能”可以拆成“添加导出API接口”、“添加导出按钮组件”、“添加导出功能的测试”三个PR。每个PR独立可审查、可合并、可回滚。

这个标准的底层逻辑是：审查成本与diff大小呈超线性关系。diff越大，审查者需要维持的上下文越多，遗漏问题的概率越高。控制diff大小是保证审查质量的前提。

6.2 让Agent“记住”项目偏好的方法

Agent本身没有长期记忆，但可以通过以下方式让它“记住”项目偏好：

• .cursorrules文件：项目级的规则文件，每次Agent启动时都会读取
• 参考实现路径：在任务描述中指定参考文件，Agent会模仿该文件的风格
• 审查反馈的积累：每次审查时把修改意见写清楚，Agent在当前会话中会记住这些偏好
• 模板化提示词：固定的提示词结构本身就在传递项目的工作方式

这些方法的共同点是：把隐性的项目知识显性化。你脑子里的“这个项目应该这样写”对Agent来说是未知的，只有写出来、指出来，Agent才能遵循。

6.3 个人效率体系的搭建建议

如果你也想搭建类似的工作体系，我的建议是从小处开始，逐步扩展：

第一周：只在一个小功能上尝试Agent工作流，熟悉任务描述编写和审查流程。不要一上来就全面铺开，那样容易因为不熟悉而受挫。

第二周：把.cursorrules配置好，把常用的提示词模板固化下来。这时候你应该能感受到效率的明显提升。

第三周：开始批量处理PR，尝试一天集中审查两次。同时记录哪些类型的任务Agent完成得好，哪些需要人工介入多。

第四周：根据前三周的记录，调整任务分配策略。Agent擅长的任务多委托，不擅长的任务自己来或者换一种描述方式。

这个渐进过程的核心是建立反馈循环：你越了解Agent的能力边界，就越能准确地分配任务；Agent越了解你的偏好，产出质量就越高。两者相互促进，效率提升是指数级的。

6.4 关于“AI替代”的真实体会

Lauren在分享中有一个观点我特别认同：AI Agent替代的不是开发者，而是开发过程中的摩擦。那些重复性的、机械的、不需要创造性思考的环节——写样板代码、补测试用例、更新文档、修复lint错误——这些才是Agent真正擅长的。

开发者被释放出来的时间，应该投入到更有价值的事情上：理解业务需求、设计系统架构、审查关键逻辑、做技术决策。这些是Agent目前做不了、也不应该交给它做的事情。

2000个PR的数字背后，不是一个人被AI替代了，而是一个人借助AI把自己的产出放大了。这个放大倍数的上限，取决于你如何定义自己的核心价值，以及你如何把非核心的部分有效地委托出去。

我在实际使用类似工作流的过程中发现，最大的障碍往往不是技术层面的，而是心理层面的——很多人不放心把完整任务交给AI，总想自己盯着每一步。这种不放心在初期是合理的，但如果一直停留在“盯着”的阶段，效率提升就非常有限。信任是逐步建立的：先从小任务开始，验证Agent的可靠性，再逐步扩大委托范围。这个过程没有捷径，但一旦跨过去，工作方式会发生质的变化。