Grok Bot开发团队：将功能决策置于代码编写之上
Grok Bot开发团队在撰写首行代码后仅用7周便推出了产品。据该团队透露，相较于编码工作，团队成员在决定“将哪些功能纳入产品”这一问题上花费了更多的精力与时间。
SpaceX工程师Lauren Tan与Grok Bot核心团队成员Roman Ugarte于14日亮相Y Combinator旗下的Lightcone播客节目，详细阐述了产品的开发历程及实际应用场景。
以Bot为核心的工作流设计
Grok Bot是一款AI团队型产品，用户可通过设定名称、角色及工具来指派任务。Ugarte解释说，他们希望将开发者将编码工作委托给AI的模式推广至公司其他部门。
Ugarte提出的设计原则包含三点：
- 以Bot为核心构建工作流，而非依赖对话或文件；
- 为Bot配备类似人类使用的工具，包括内置计算机环境；
- Bot无需等待指令即可持续运行并主动提出创意。
开发团队表示，在内部测试阶段，无论是对AI熟悉与否的员工均给予了积极反馈，随后才决定对外公开产品。这一上市决策充分参考了内部试用结果。
Ugarte指出，用户通常起初会将小型任务委托给Bot，若效果良好，便会赋予其更多权限与工具。随着使用深入，工作任务从单一操作升级为以目标为导向的项目，最终用户倾向于将整个业务流程交由Bot处理。
跨部门协作与实际应用案例
在市场营销领域，团队授予Bot访问Google和Facebook广告账户的权限及预算。Bot能与设计团队的Bot协同工作，对多组广告素材进行A/B测试。
在客户服务领域，Bot能够基于用户举报重现问题场景，并在拥有必要工具的情况下，独立处理部分咨询请求的全流程。Bot可承担的工作范围取决于其所获的工具与权限。
此外，开发团队约两周前发布了“团队Bot”功能，允许个人创建的Bot与同事共享。Bot之间可以相互对话并分配任务。例如，Tan的工程师Bot“Potato”曾在Slack线程中向负责数据仓库的Bot查询用户数据，团队成员亦可实时查看进展过程。
PR数量增长反映维护而非新功能发布
在播客讨论中，主持人提到Tan曾介绍每月PR（Pull Request，即代码合并请求）数量约为2000件，而目前已超过4000件。Tan对此予以确认，但她强调这代表的是代码变更请求的规模，而非新功能的发布数量。
Tan表示：“我的自动化流程主要用于软件维护，而非开发新功能。”她解释说，自动化被广泛用于错误修复和性能优化。
Tan还分享了一个在Slack公开线程中与同事Samantha合作开发新功能的案例。在简要说明想法后，Bot调用了Cursor的云代理生成了原型，团队成员通过对话窗口中的视频和图像进行意见交流。Tan指出：“在此过程中，我甚至没有打开Cursor编辑器，所有工作均在Slack对话中完成。”
功能上线标准与团队共识瓶颈
Ugarte表示，团队每天通过产品界面、客户支持渠道以及X平台接收数千条用户反馈。对于小型错误，团队通过自动化流程复现并修复，随后将其整合至代码中。
对于涉及用户日常交互界面的功能，其上线标准更为严格。Ugarte透露，团队会在内部充分测试新功能，若反响不佳，即便开发完成也不会推出。
“团队在产品路线图规划及如何评估‘良好结果’上达成共识，是目前的主要瓶颈。”Ugarte总结道，如果将所有功能强行整合，可能会导致产品体验支离破碎。
