Lauren Tan · MaiYang

非 CS 出身的 Lauren Tan，是怎么一步步放手给 agent 的

Sun, 18 Oct 2026 07:41:00 +0800

Lauren Tan（@poteto）说，2024 年那会儿，她和很多写了多年代码的人一样，不太相信 agent 能写出进生产环境的代码，担心垃圾代码会混进漂亮的代码库。2026 年 9 月 21 日，她在 X 上发了一条：「here’s how i shipped 2,500 PRs last month to production」。

她现在在 SpaceX AI 做 Grok Bot，也是 React 核心团队成员。但她没读过 CS，大学学的是金融，第一次觉得编程好玩，是在金融建模课上写 Excel 的 VBA 宏。学 AI 这件事，我越来越觉得最值得花时间的，是去看顶级的实践者和构建者具体怎么做。她的路，对没有 CS 背景的人尤其有参考价值。

一、成长路径：没学过 CS，一步步走到 React 团队

十三岁，从一套盗版 Fireworks 开始。 她在新加坡长大，在 The Changelog #386 里回忆，十三岁左右，继父给了她一套盗版的 Macromedia Fireworks，她一开始「I have no idea what this software is」，就上网搜教程，后来泡在一个网页设计论坛和 IRC 上，靠「查看源代码」看别人的 HTML、CSS 和 JavaScript。她说，要不是那个论坛，她可能根本不会走进编程这一行。十五六岁，她拿到第一份有报酬的活，给学校重做网站。

大学读金融，在 VBA 宏里重新爱上编程。 她当时没想到做网页也能谋生，在父母的鼓励下选了更「实际」的专业。按她的 LinkedIn，她 2009 到 2011 年在 Monash University 读商科学士（会计与金融），上过 Dean’s List，以前 5% 的成绩毕业，2011 年还去 LSE 读了一期商业分析与估值的暑期课程。她在 React Conf 2025 的团队访谈里说，金融建模课的教授教他们写 Excel 的 VBA 宏，「And then I was like, wow, this is so much fun.」尽管成绩不错，她在 2014 年的年终博客里写，自己当时还是觉得不行，于是「what I lacked in intelligence, I decided I would make up for with sheer determination and grit.」

毕业后创业，失败了。 2012 到 2013 年，她和朋友做 ThePriceGeek，一个跨 eBay、Amazon、Craigslist 的比价搜索，她负责设计和前端。项目进了 2013 年的 Melbourne Accelerator Program，上过 Hacker News 首页。她在 Changelog 里说，最好的时候一个月大概赚 1000 美元，养不活两个全职的人，钱花完就停了。

在墨尔本边工作边学 JS，把学习写成博客。 2014 年，她给一家叫 Everperform 的创业公司当第一位工程师，和不懂技术的创始人一起，先在 Photoshop、Sketch 里画界面，再用 Ember.js 写出来；之后去了 Homely，把前端从 jQuery/Backbone 迁到 React。她在 X 上回忆，那时她是「a nobody in melbourne who was still learning how to code in js」。她学 Ember 时写博客、发推，EmberConf 的组织者顺着推文找到她，邀请她投稿演讲。她连会都没参加过，在班上做报告都会发抖，第一反应是「No way」，组织者一直鼓励，她才投了稿。被选上后，她给自己倒排了三个月的准备计划，上台头五分钟一直在发抖，但练过的内容都记住了。几年后她在博客里写：「If you’re not afraid, you’re too comfortable.」

DockYard：第一份「real job」，搬到美国。 她说那场演讲之后「my life changed」。2015 年 4 月，她进了波士顿的 DockYard 当 Senior Developer，用 Ember 和 Elixir 给客户做项目。她一边上班，一边继续发推、继续演讲。

Netflix：从工程师到经理，再回到工程师。 进 Netflix 也是靠一场演讲。她说自己没主修过 CS，是自学的程序员，FAANG 面试对她来说不可想象，一度想临阵退出。2016 年 7 月她以 Senior Software Engineer 入职，做内部的 studio 工具；2017 年 11 月经理离职，总监请她接手团队，她考虑了一周才答应，后来带过十多人的团队。她在 Netflix 待了近四年，用她的话说，当经理的日子「difficult, lonely, rewarding, and everything in between」，最想念的是当 maker。

Meta：React 团队六年。 她在伦敦一场会上认识了 Dan Abramov，后来他问她要不要来 React 团队，她的反应是「uh, hell yes?! but wait, me?」，还说「massive imposter syndrome」一路跟着她。2020 年 3 月她以 Staff Software Engineer 加入 Facebook，先在 React Data Core 做 Server Components 等工作；2021 年 11 月到 2022 年 8 月，她当了 React Core 的工程经理，期间发布了 React 18；之后又回到工程师岗位，主攻 React Compiler 的重写和开源发布。她离开时写道，在 React Conf 上发布 React Compiler 会是她职业生涯的高光之一。

低谷，然后 Cursor。 她说过，早在前一年就想离开 Meta，只是不知道下一步去哪，「every hour spent there felt like agony」。她也坦白自己那时 burnt out 得厉害，甚至以为自己不再适合当工程师。她休息了一个月，第一次尝试做 agent 编排器，从头重写了 6 次。发现自己在公司一小时都坐不住，做自己的项目却能一天干 16 个小时还很开心，她就知道该换了。2026 年 3 月她加入 Cursor，LinkedIn 上写这段经历「Shipped Cursor 3 and Grok Bot」；8 月 Cursor 被收购后，她成了 SpaceXAI 的 Principal Engineer。

她在 X 粉丝过 5 万时总结过这一路：每一份工作都来自在这里结识的人，「i owe my entire career to it.」

二、信任是一点点攒出来的

还有个细节挺让人放松的。她在《How I Use Cursor》里坦白，去 Cursor 面试之前，她其实没用过 Cursor，为了做面试项目，才用它写了两天。

她在那场 2500 个 PR 的分享里讲得很清楚，数字从来不是目标，她要的是信任：自己不在场的时候，agent 也能交出高质量的活。

刚加入 Cursor 时，她每天对着 Chrome DevTools 抓性能 trace、拍内存快照，手工到她自己都烦了，开始想：「wait, we have agents. What am I doing?」她后来写道：「The bottleneck with agents is verification.」agent 写代码很快，难的是确认它写对了。于是她开始写验证类的 skill，让 agent 自己把应用跑起来，自己抓 trace、找热点、一点点把性能往上推。

她对 agent 的看法很冷静：「Agents are like new hires in a constant state of amnesia and idiocy.」它们记不住你说过什么，也不会真的学会新东西，只能靠 rules、skill、工具和长期记忆去近似。

她把用 agent 的过程讲成一条往上爬的曲线。她说自己一开始也在「一到五个」这个区间：每个对话都得盯着，不停纠偏，人一走开 agent 就会做错。她认为这一段反而最难走出去，因为不知道该从哪儿下手。之所以没法从五个跳到一百个，是因为你还不信任它们的产出。不信任就硬开一百个子 agent，结果只会是一堆低质量 PR、回归和 bug。

怎么建立信任？她 10 月中旬发过一条帖子，把办法排成一个倒金字塔，越往上越该多花力气：

改代码库本身：更好的架构、更强的类型和不变量、清晰的边界。agent 爱照抄现有代码、爱走最短的路，那就让最省事的那条路正好是对的。
静态分析：lint、测试、CI，在问题出现前就拦住。
文字：注释、rules、AGENTS.md、skill，这些靠 agent 自己判断、没法强制的东西，少用，但要用。
人工审查：最难扩展的一层。agent 合代码的速度太快，不可能每个 PR 都细看，所以人的精力要花在设计一个让 agent 默认就做对的环境上。

她 8 月发过一句更直接的：「every time you intervene and correct your agent, you should think about how to eliminate it entirely.」10 月又补了一句「your codebase is memory」：agent 反复犯的错不变成约束，就会像病毒一样一直复制下去。

三、懒，是很实在的动力

在做 Grok Bot 之前，她先给自己做了一个 bot，叫 Benny，头像是一只小狗。她在一段访谈里说：

I’m a fairly lazy person. … we’re getting so many bug reports for Cursor, right? And I wanted to just fix them all.

她想的是，怎么让 agent 在她睡觉时自动把 bug 修掉。很多人来问她 Benny 怎么做的、自己能不能也有一个，她说这启发了 Grok Bot 的一部分想法：每个人都能定义自己的 bot，给它身份、自己的电脑、日常任务和自动化。现在别人给 Grok Bot 提反馈，她的 bot 会自动去修，她负责 review 代码。问她现在的工作是什么，她说自己「almost like a manager for my digital colleagues」。

Grok Bot 是一个团队一起做出来的。她在发布当天写的是「we just launched Grok Bot」，自己说最骄傲的一块是客户端架构：最早是一个很糙的原型，后来她用自己在做的一个 agent 友好框架（暂定代号 Dune）把它整个重构了。这个框架的目标，是让上下文很少的 agent 也能默认写出高质量代码。

她开源的 pstack 里也带了一个叫 benny 的自动化包，默认不启用，做的也是这件事：分拣 Slack 上的问题报告，复现并修掉确认的 bug。

四、普通人能照着做的几件事

她的机遇不是每个人都有，但下面这些，今天就能开始：

边学边公开。 她进 EmberConf，靠的是学 Ember 时写的博客和推文。不用等学成了再发，学到哪写到哪，别人才有机会找到你。
列一张害怕清单。 她把「不害怕就是太舒服」当信号用。写下你最近因为怕而没做的一两件事，比如投稿、发第一条长帖、去面试，挑一件去试。
从最烦的那件重复活下手，先自己走一遍。 Benny 的起点就是 bug 太多、她不想一个个手修；验证 skill 也是在她手工抓了很久 trace 之后才写的。先把流程亲手走通，你才知道该让 agent 怎么做、怎么算做对。
动手前先定义怎么验证。 给 agent 一个检查自己的办法：做网页就让它打开页面截图，写脚本就让它跑一遍贴结果。pstack 里的 /create-verification-skill 可以帮你生成这样的 skill。
少开几个，盯清楚。 先跑一到五个，看它们具体在哪里犯错，别急着堆数量。
同一个错，往上提一层修。 第二次纠正同一个问题时，能写成检查就写成检查，能改结构就改结构，文字说明放最后。pstack 的 /correct 就是干这个的。想要自己的 mode，可以试 /automate-me，它会照你的工作记录起草一个。
每年问自己一次，还兴奋吗。 她当经理前就跟自己约好，每年重新评估这还是不是梦想中的工作，不是就回头。用 AI 也可以这样，给自己定个回看的时间。

五、我自己做到哪了

我也在用 pstack 和 poteto-mode，日常的活大多交给一组 bot：找选题、做字幕和剪辑、写初稿、做封面。看起来挺「自动化」了，但对照她那条曲线，我大概还停在第一段。

说实话，我每个关键节点都还在盯：成片要我看过，文案要我看过，发不发要我点头。有些是该留的把关，有些其实是我还没给 bot 足够的验证手段，只好自己当那个验证器。她那个倒金字塔我也是反着来的：同样的问题出现第二次，我多半还是在对话里再提醒一遍，很少把它变成一个自动的检查。

接下来想做的，就是把这些「盯着看」一条条变成 bot 能自己跑的验证。信任攒够了，再放手。

结尾

10 月 8 日，她发了一条只有两行的帖子：

you should be more ambitious

way more ambitious

不是每个人都有这样的机会，但是不做就一定没机会。先付出，先努力去做。

参考资料

Lauren Tan 的 LinkedIn，学历和每段工作的时间、职位。
My 2014 in review, or how I beat impostor syndrome，她 2014 年的年终博客，讲冒名顶替感和 grit。
I am still learning，2017 年博客，讲恐惧和舒适区。
Does it spark joy?，2020 年博客，从工程经理回到工程师的决定。
The Changelog #386: Engineer to manager and back again，2020 年播客访谈，讲童年自学、读金融和 The Price Geek。
React Conf 2025 团队访谈，她讲自己从 Excel VBA 宏学会编程。
粉丝过 5 万时的感谢帖，从 EmberConf 到 DockYard、Netflix、React 团队的经历。
This week I joined Cursor，2026 年 3 月加入 Cursor，感谢在 React 的 6 年。
想离开 Meta 的那段，休息一个月做 side project 后决定换工作。
burnt out 之后，她说曾以为自己不再适合当工程师。
加入 Cursor 前的 side project，编排器重写了 6 次。
How I Use Cursor，X 长文，面试前没用过 Cursor、agent 像失忆的新员工、验证是瓶颈。
here’s how i shipped 2,500 PRs last month，她在 X 发布的分享视频，讲信任曲线。
怎样更信任 agent 的产出，四层倒金字塔。
让 agent 验证自己的工作，最基础的一步。
your codebase is memory，把反复出现的错变成约束。
每次纠正都想办法让问题彻底消失，纠错的优先顺序。
Grok Bot 发布帖，客户端架构和 Dune 框架。
Grok Bot 发布访谈片段，讲 Benny 的由来（第三方转载）。
pstack README，她每天在用的开源 skill 合集。

一天几百个 PR 有什么意义？我照着 SpaceXAI 工程师 Lauren（@poteto）的九类清单，把自己的活拆了一遍

Fri, 09 Oct 2026 19:24:00 +0800

朋友们好呀，我是 SpaceXAI Ambassador MaiYangAI。

这篇想聊三件事。

Lauren 上个月往生产环境发了 2,500 个 PR，背后是很多条并行的工作线、按风险分级的审核，还有她一直在讲的信任。
我们大多数人没有她那样的条件，可她说的大公司的问题，已经落到每个带着 agent 干活的人身上。普通人可以从哪里开始，我放在最后。
我照着她的九类清单把自己的活拆了一遍。拿我自己的业余项目 ContextEcho 来说，从 4 月到 10 月初，大概有 1,020 个 commit，走 PR 合并的只有 18 次。

起因是 Emil 的一个问题

10 月 9 日凌晨（今天），Linear Designer Engineer Emil Kowalski（@emilkowalski）在 X 上问了一句：“Can someone help me understand how shipping 100s PRs a day makes sense?” 他想知道一天发几百个 PR 到底有什么意义，为什么非得发这么多。他还补了一句，说自己可能只是还不够 AI-pilled，是真心想弄明白。

https://x.com/emilkowalski/status/2108270779200852148

Emil 在 Linear 做 Design Engineer (设计工程)。这条帖子发出六个小时左右，就有了 15 万浏览、1300 多个赞、180 条回复，想问同一个问题的人显然不少。他在楼下又说得更直接一点，推这种说法的人大多在 token 公司，自然希望大家多用 token，他想不出一天 100 个 PR 能放些什么，可看起来真有人这么干。（原帖 https://x.com/emilkowalski/status/2108273062517071997 ）

在推文的回复里面，很快就分成两派。支持的人说，小而原子的 PR 好审、好回滚，用 git worktree 可以让好几个 agent 同时干活。怀疑的人说 PR 数量是虚荣指标，有人直接问，那么多 PR 合进去，到底有多少用户问题消失了。

这几条回复的原帖依次在：

https://x.com/abysmal_pepto/status/2108304504684777888 、 https://x.com/dusangran/status/2108294033340768601 、 https://x.com/pmjohnson/status/2108283256084766978 、 https://x.com/hexablob/status/2108318903709368829

我把回复也都看了，然后又看了 Lauren（@poteto）后面接着发的几条 X。

Lauren 怎么答

九类清单

赞最多的回复来自 Lauren。她说自己同时在推很多个项目，加起来数量很容易就上去了，她列了九类清单：

持续的性能优化
用户报上来的 bug
持续重构 Grok Bot 的代码库，让它对 agent 更友好，也帮团队跑得更快
持续改进自己的 skill
新功能
UI 打磨
改进 harness
Grok Bot 性能相关的开发工具、发布管理和可观测性
其他个人项目

https://x.com/poteto/status/2108279582088671583

她说这些全用 pstack 在跑，靠 agent 能覆盖非常大的宽度，成为 10x 工程师很难，但确实可能。pstack 既有 Cursor plugin 也有 Grok Bot。

对我更有用的是她给我们列出的这九类清单。一天上百个 PR，拆开看是九条工作线各自往前走，每条线交几个，叠起来就很多了。

谁来审

Emil 接着问了最要紧的一个问题，这些 PR 是不是都不用人审，还是只审大的？Lauren 回答，他们有 agentic code review，每个 PR 先评估风险，低到中风险的不需要人审，直接合并，另外还有 Bugbot。

https://x.com/poteto/status/2108283057581195413

回复里面的追问

也有人在下面反讽。他把 Lauren 的清单抄了一遍，在性能优化、bug 修复、代码重构后面各加一句，意思是这些活都是代码发太多发出来的。Lauren 回他，大公司在有 agent 之前就一直有这类工作，这就是大团队维护软件的成本，要不然大公司为什么雇那么多工程师。（反讽原帖 https://x.com/msdGYT/status/2108280539383742855 ，Lauren 的回复 https://x.com/poteto/status/2108281063852413046 ）

另一个人追问她到底怎么同时推这么多项目，她说工程师的新工作就是把这件事想清楚，她也没说自己的流程已经完美，只是把学到的东西分享出来，边用边学。（追问原帖 https://x.com/20minCode/status/2108281588513447974 ，Lauren 的回复 https://x.com/poteto/status/2108282476938633325 ）

volume does matter

过了一会儿，Lauren 又引用 Emil 的帖子写了一篇长帖，开头就是 volume does matter，量是重要的。她的意思我大概转述一下。

https://x.com/poteto/status/2108290818746528017

以前大家看影响力，不看数量。一行配置改对了，可能帮公司省下几百万美元。量只在两头会被拿出来说，一头是表现吃力的人，另一头是那种关起门来、出门时抱着一摞 PR 解决一大堆问题的 coding machine。agent 来了以后，每个人都有机会成为 coding machine。如果你的产出还和以前一样多，她觉得值得停下来想想为什么。

她反复提信任。没下功夫让自己能信任 agent 的产出，产能就很难放大。她也承认这样要花更多 token，她按每单位智能的成本来算，这比雇一大群高薪工程师便宜，而且会越来越便宜。最后她说，工程师的工作已经变了，要造的是那台写软件的机器。有人叫它软件工厂，她更喜欢叫米其林厨房。

2,500 个 PR，和 Jacob 的 250 个

我读下来，Lauren 的上百个 PR 背后有三样东西。很多条并行的工作线，一套按风险分级的审核，还有她一直在讲的信任。她 9 月 21 日发过一条，讲自己上个月往生产环境发了 2,500 个 PR，配了一段演讲视频，现在有 350 万浏览、3 万多收藏。我也分别做了中英双语字幕版：

一个月怎么合进约 2000 个 PR （中英双语）： https://x.com/MaiYangAI/status/2102344659276099794
Matt Pocock 访谈 Lauren 如何做到的？ https://x.com/MaiYangAI/status/2106256004346441909

最近，在 SpaceXAI 团队里面有一个 Jacob Gold（@jacobgold）晒出他超过 poteto 的 PR 数量，他当前正在做 Origin，Lauren 回 Emil 时也 cc 了他。10 月 5 日他发帖说，要跑在 Lauren 前面可不容易，不过内部有点竞争是好事，他这间米其林厨房过去两周已经做到每天合并将近 250 个 PR。

https://x.com/jacobgold/status/2106843104758419459

同一天他又补了一句，他很清楚合并的 PR 数不等于商业价值，只是他在造未来的软件厨房，自己得先天天用上。（原帖 https://x.com/jacobgold/status/2106975237581766972 ）

Jacob 也讲了他怎么放心。他给自己所有的 PR 加了一道检查，拿 PR 的改动去对照他发过的全部提示词，确认这件事确实是他要的，只要有一点可能不是他想要的，就推到他的决策小工具里让他拍板。他说这让他快了很多。人也会审一部分，但校验要能靠 token 扩展上去。（这一句的原帖 https://x.com/jacobgold/status/2107153694303330320 ）

补充： https://x.com/jacobgold/status/2106898268001292290

但我们不是 Lauren

我们大多数人都是在有限的资源下，Lauren 则相对是无限的资源。她所在的公司在高速发展，也支持她这样干，她背后有团队，也有公司的投入。我们大多数人是一个人，或者一个很小的团队，还要挤时间做自己的东西。拿她的数字给自己定目标，很容易一上来就泄气。

大公司的问题，变成了所有人的问题

Lauren 10 月 5 日还发过一条，讲大公司和小团队的区别，我在下面回了一句“I completely agree.”

https://x.com/poteto/status/2106916667599278365

（我的回复 https://x.com/MaiYangAI/status/2106943685149835611 ）

她说自己管理 agent 的一切，都是从前辈程序员和计算机科学家那里学来的。代码库里的约束，对人和 agent 都是一种解放。小团队以前可以信任同伴把代码写好、审好，不太需要深想这件事。大公司在有 agent 之前就得解决它，先有 human slop，才有 agent slop。办法就是约束，lint 规则、更聪明的编译器和诊断、高质量的测试、在可观测性上的投入。

那条里我最认同的一句是，agent 的到来，让大公司的问题变成了所有人的问题。好消息是这些都不新鲜，就是好的工程。

对普通人来说，这句比一天几百个 PR 更重要。你一个人带着几个 agent 干活，就已经碰上一个大团队的问题了。产出一多，谁来审，哪些能放心合进去，哪些要自己看，这些问题不会因为你团队小就绕开你。

我自己的真实情况

我现在怎么干活

我的工程以前主要在 Cursor 里做，现在在逐渐往 Projects 迁，用 Grok Bot 加 Cursor cloud agent。Projects 我刚开始用，还没摸索出适合自己的方式。

一天 100 个 PR，对我来说确实很难。在 Cursor 的 agent window 模式里，高频工作的时候，我一天能交掉 20 到 30 个改动。这个数很依赖输入。你给的输入越多，越能有针对性地加约束、加校验、定判断方法。

1,020 个 commit，18 次 PR

这些改动不全是 PR。ContextEcho 没有每个改动都走 PR，它不涉及协作，项目本身也比较小。我翻了一下仓库，从 4 月到现在一共 1,020 个 commit，最多的一天有 54 个，一天 20 个及以上的有 17 天。通过 PR 合并的只有 18 次。

我觉得 PR review 的价值在于影响面和质量保障。改动牵涉的范围越大，越值得多一道审核。Lauren 那边按风险分级，低到中风险直接合，其余的再让人看，也是把审核的力气花在影响面大的地方。ContextEcho 就我一个人在改，影响面小，我就没让每个改动都走一遍 PR。

另一部分任务，我交给 Grok Bot 承接。我直接交代任务，它自己去完成，做完交回来。这样算下来，每天并行的事情就很多了，你看看我非工作日在 X 上的输出就知道。

我的九类

我照着 Lauren 的九类清单，把自己手上的工作也分了分。

ContextEcho 的 iOS 迭代，新功能、bug、界面打磨都在里面，Cursor agent window 为主，慢慢在往 Projects 和 Cursor cloud agent 迁
ctxly.ai 和 castmind.ai 两个网站，Cursor 开发的，做得比较早，近期没多少要维护的
每天的 AI 资讯和 X 信息流简报，Grok Bot 承接
X 上的推文分析和长文起草，Grok Bot 承接，我定角度、改稿，发布键我自己按
小红书笔记，Grok Bot 承接，同样由我自己发
视频精品大片和中英字幕，Grok Bot 承接
播客推荐和深读，Grok Bot 承接
每天一张的日推小卡，Grok Bot 承接
线下 Meetup，Grok Bot 承接，连分享要用的 PPT 也是它准备的
bot template 和 skill 的维护，主要在 Grok Bot，项目里的 skill 跟着项目走，不分 Cursor 还是 Grok Bot
跑步训练，Grok Bot 读手表数据给建议

Meetup 的 PPT 是 10 月 8 日晚上的事，我当时发了一条：“我刚刚用 Grok Bot 做 slides，效果完全超出我预期！！！”主办方对分享 PPT 有严格的格式要求，按原来的方式，我不但要准备分享内容，还要按要求调格式、字体、大小、动画特效。这次分享主题、大纲和详细材料是我原本就准备好的，我把它们和模板、要求一起交给 Grok Bot，剩下的全由它搞定，它还在 Slides 里写好了逐字稿。

https://x.com/MaiYangAI/status/2108197683307634709

两张清单的差别

两张清单放在一起，差别很明显。Lauren 的九类大多围着同一个产品转，宽度长在一个代码库里。我的宽度散在产品、内容和社区几头，承接的工具也不一样。有一类我们是重合的，就是改进自己的 skill。我给 Bot 写的那些 skill 和检查规则，跟她改 harness 是同一类活，都在让产出更值得信任。

还有一个差别。ctxly.ai 和 castmind.ai 用户少，近期也没多少要维护的。产品没发展起来的时候，你做不到随时都有那么多开发需求、新特性和 bugfix。硬找活来空耗，没人愿意做，浪费资源，也没有价值。Lauren 的九类能跑满，Jacob 一天能合进去几百个，很关键的一点是他们做的产品正在高速发展，有大量用户在用。用户报的 bug、要的新功能、碰到的性能问题，一直在往他们那几条线上送活，公司也在全力往前推。

需求是真的，量才有意义。

量是怎么长出来的

两条路

我觉得普通人的量，大概有两条路。

第一条是时间和问题喂出来的。我迭代 ContextEcho 的时候就是这样。这跟我多厉害没什么关系，迭代时间长了，见多识广，各种问题都碰过，你要给它们做的 harness 自然就多了，能放心交出去的活也跟着多了。

第二条是主动磨刀，磨刀不误砍柴工。专门针对自己的工作场景拆一遍，把两头搭起来。一头是输入加上下文，你要交给 agent 什么材料、什么背景、什么限制。另一头是输出加验证，它交回来的东西，用什么标准判断能不能用。两头搭好，更多的事可以自动处理，你能处理的量自然就多起来了。我写稿的 Bot 就有这样一道验证，起草完先过检查器，再去一遍 AI 味，才交到我手上。

两条路可以一起走。第一条靠时间，急不来。第二条今天就能开始。

同时展开一多，人跟不上

回复区里有个人问 Lauren，你到底怎么在脑子里跟住这么多条线？他说每次给 bot 派下一个任务之前，都得先花时间搞清楚它刚才在干什么。（原帖 https://x.com/ExcanatorGames/status/2108288891476181244 ）

这个问题我也没有好答案。同时展开一多，很考验一个人的并行处理能力和习惯。我自己的专注力确实下降得很厉害，碎片化很严重，这是实打实的代价。这也正是我当初开发 Contextly App（ ctxly.ai ）的初衷。

最后想说的话

ContextEcho 开发出来的代码，我现在基本不看了，交给 AI 做 code review。

人的品味和判断还是非常稀缺，不能无脑信任所有产物。我的判断花在别的地方，定方向，定标准，看结果，自己用一遍看体验。逐行读代码这件事，我交给了 AI。Lauren 那边靠风险分级和 Bugbot 决定哪些要人看，我这边把代码审核交给 AI，把自己的判断留给方向和体验。

一天 100 个 PR 对大多数人还很远。先把手上的工具用顺，比追这个数字有用。

如果今天只做一件事，我建议照着 Lauren 那张九类清单，把你自己的工作也分一次类，再挑其中一类，给它加一条校验。