映射到代码的图表
Eraser 和 Whimsical 只能画出漂亮的方框;你的工程师最终还是会按截止日期允许的方式去实现。Bob 的图会真正变成 Alex 在代码库中使用的文件结构和模块边界。
Bob·ArchitectBob 设计系统、选定技术栈,并将架构交给 Alex,让你的架构成为代码库,而不是被遗忘的文档。
映射到代码的图表,而不是漂亮的图片。
Eraser 和 Whimsical 能画出漂亮的方框和箭头。但你的工程师最后还是会按截止日期能完成的方式去实现。Bob 的图表会变成 Alex 实际使用的文件结构和模块边界。
“我们选 Mongo 是因为它很流行。”Bob 会解释为什么选 Postgres 而不是 Mongo,为什么用队列而不是直接调用,以及为什么选 Redis 而不是 Memcached。这些理由都会被写下来,方便你提出质疑。
Wiki 里的架构图停留在第 1 个 sprint,代码却已经演进到第 14 个 sprint。没人会去更新它们,让两者保持一致。Bob 会审查当前系统,并更新架构文档,使其反映实际已经交付上线的内容。
性能、安全性和可观测性,往往要等到第一次故障后才开始补救。Bob 会在设计阶段就结合 Emma 的扩展性要求,以及你的数据模型需要支持的访问模式,提前规划这些内容。
从你的第一个提示词到交付结果——这就是 Bob 的实际运作方式。
在编辑器中生成的服务、数据流和集成图,而不是在单独的工具中生成。
根据你的约束条件论证技术栈选择,而不是因趋势或熟悉程度而决定。
根据产品的实际访问模式设计模式和关系。
在设计阶段就考虑性能、安全性和可观测性,而不是上线后再处理。
将架构决策及其原因记录下来,以便未来的你可以重新审视。
图表可映射到 Alex 构建时使用的文件结构和模块边界。
Bob 可以审查现有系统,并以清晰的理由提出变更建议。
手工搭建的工作流缓慢、依赖人工且需要大量工具。将鼠标悬停在任意卡片上,查看每项收益为何重要。
正从 Eraser AI 转来?以下就是 Bob 更胜一筹的地方。
Eraser 和 Whimsical 只能画出漂亮的方框;你的工程师最终还是会按截止日期允许的方式去实现。Bob 的图会真正变成 Alex 在代码库中使用的文件结构和模块边界。
ChatGPT 会推荐它在训练数据中最常见的框架。Bob 会解释为什么选择 Postgres 而不是 Mongo,为什么选择队列而不是直接调用,为什么选 Redis 而不是 Memcached——并给出你可以质疑的理由,以及你可以重新审视的决策。
Wiki 里的图表到了第 3 个冲刺周期就过时了。Bob 会审查实际代码,并根据已交付的内容更新架构——这样文档就永远不是虚构的,新工程师入职上手只需一天,而不是一个月。
| 功能 | Atoms 推荐 | Eraser AI |
|---|---|---|
| 输出 | 可映射到代码的架构 | Wiki 中的图表 |
| 有理有据的技术栈选择 | 书面的权衡取舍 | 泛泛的建议 |
| 随代码交付保持同步 | 已根据代码库刷新 | 到第 3 个冲刺周期就过时了 |
| 连接到工程团队 | 移交给 Alex | 通过导出移交 |
| 图表创作 | 自动生成 | 自动生成 |
Bob 并不是单独工作。以下是你与完整团队协作构建时,各项交接如何落地。
Bob 产出的可映射到实际代码的具体架构工作。
@Bob 为一个支持多租户、按用量计费、预计有 1 万租户并使用 Stripe Connect 付款的平台设计架构。选择技术栈,绘制服务架构图,并将文件结构交给 Alex。
@Bob 我们正在为新产品在 Postgres + Prisma 和 PlanetScale + Drizzle 之间做选择。请根据我们的约束条件(多区域读取、单工程师、100ms p95)进行比较,并明确权衡后推荐一个方案。
@Bob 审查我们当前的 API 层。我们在仪表盘端点上看到 800ms p95,并且希望将流量扩展到 10 倍。请梳理瓶颈,提出改进方案,并为 Alex 编写迁移计划。
@Bob 为 Emma 的 PRD 中的推荐计划设计 schema。梳理我们实际会运行的查询所需的实体、关系和索引。将 schema 和迁移计划交给 Alex。
没有任何一个智能体是单独工作的。点开任意队友,即可查看他们如何处理你产品中的那一部分。
别再画那些没人落实的图表了。让 Bob 设计系统,由你的 AI Team 在 Atoms 内构建并保持同步。