北京
一个叫@lingxi的工程师，最近分享了一套有点反常规的做法：用一支由Grok Bot组成的"工程团队"，来开发Grok Bot本身。他把这套玩法发出来后，很快引来了4.2K的浏览量。
核心思路很简单：把Grok Bot当成一个"自带电脑的聪明实习生"。这个实习生不是单打独斗，而是管理着一群更底层的编码代理（coding agents），像带团队一样把活儿拆下去。
按领域分工，让每个Bot保持锋利
@lingxi没有让所有Bot干一样的活，而是按领域做了切分：iOS、桌面端（desktop）、基础设施（infra）、Android，以及测试框架（harness）。每个Bot只盯着自己那一亩三分地，这样做的效果是——专注的Bot能保持更敏锐的判断力，不会因为任务太杂而"精神涣散"。
这套体系跑起来之后，Bot们会自己拉起云端代理（cloud agents），检查代码证明（proofs），处理测试不稳定（flakiness）的问题，并且会一直干下去，直到结果达到你设定的标准线才停手。换句话说，你只需要定好"什么叫做好"，剩下的执行环节，Bot会自己盯着。
什么时候用云，什么时候用本地机器
有意思的是，@lingxi并没有把所有任务都丢到云端。当任务需要特定网络环境、iOS模拟器（iOS sim）或者截图验证时，他会选择让Bot跑在自己的机器上。这种混合策略既保住了云端的高并发能力，又解决了本地环境依赖的问题。
这套体系里还有一个专门处理"上下文溢出"（context limit）的环节。当对话内容超出模型上下文窗口时，@lingxi的做法是：盯着BugBot、CI（持续集成）和冲突报告，发现问题就跟进，然后审查，确认安全后自动合并（auto-merge）。整个流程像一条流水线，把最繁琐的代码审查工作也交给了自动化。
从15个到200个：规模翻了十几倍
最直观的变化在数字上。以前，@lingxi需要手动管理大约15个云端代理，现在通过这套"舰队"（fleet）机制，他同时跑着200多个代理。规模翻了十几倍，但管理成本反而降下来了——因为管理动作本身也被Bot接管了。
除了开发任务，他还安排了一个专门的运维Bot（ops bot），负责每天的一对一沟通（1:1s）、事后复盘（postmortems）和新成员入职培训（onboarding）。这么做的目的很直接：让犯过的错误不再重复发生。
这套玩法最反直觉的地方在于：让AI来管理AI，而不是让人去管AI。当每个Bot的职责足够聚焦，当流程里的每个环节都有Bot盯着，人要做的事情反而只剩下定标准和看结果。至于这算不算未来软件工程的一种形态，至少从@lingxi晒出的数据来看，这条路已经跑通了。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
