个人创始人用Grok构建自动化工作流，把重复任务交给Bot

作者此前承诺分享结合Grok @bot更新后的独立创始人工作流，相关内容将分为多篇文章发布。

作者提到，自己曾多次在旅行途中通过手机开发Visor，同时不放松对交付质量的要求，认为这种模式是未来方向。本文解答什么时候创建Bot的问题，并介绍作者认为能提升工作稳定性、让自己聚焦核心工作的一个实用Bot。

关于创建Bot的时机和结构：按领域划分单个Bot虽然有吸引力，但存在明显问题。如果你的现有任务正在进行，又需要Bot处理新任务，Bot必须暂停当前任务才能执行新任务，除非配置云代理，但云代理通常仅适用于代码场景。

因此更合理的做法是将Bot按任务队列拆分，每个Bot对应一类职责下积累的工作。举例来说，单个支持Bot无法扩展应对多用户、多账户、多请求的场景。可以让一个总支持Bot作为外部接口，统筹调度不同分工的子Bot，任务自然形成「队列中的队列」。

作者按照这个思路，创建了筛选Bot、跟进Bot、运营Bot，分别负责功能与故障面板整理、根据用户疑问更新文档等工作。所有子Bot向总支持Bot汇报，作者通过总支持Bot统一管理，每个领域一般设置一个入口，很少只保留一个Bot。相关支持工作流会在后续文章展开介绍。

作者开发的SRE（站点可靠性工程）Bot对保障服务质量非常实用，它有固定例程检查Sentry、Slack告警、Datadog日志和故障报告。

Linear被用作所有工作的统一收件箱，所有工作单元都要进入这里排序优先级，哪怕是自动完成的工作，也方便后续对用户跟进。没被记录的工作很容易丢失，记录后也方便根据工作量调整优先级。

这个Bot会自动创建拉取请求，如果是低风险修改，比如修复页面崩溃，会自动合并并在部署后检查日志。如果发现新部署的内容出错，会自动回滚，创建包含修复的新拉取请求，重复整个流程。如果一切正常，只会在Slack发送提醒。

作者此前没有固定例程处理这些重复检查，将工作委派给Bot后极大减轻了精神负担。作者邀请读者试用并反馈意见。