收件箱里的架构:每周团队摘要正式发布

我们 Payment 服务的 drift 分数已经连续上升了六周。两个 ADR 处于待审查的开启状态。周一出现了一个高严重度的合规性违规。新的 Inventory 服务被分配给了一个尚不存在的团队。

我之所以知道这一切,是因为今早登录 archyl 翻了五个页面。

那些团队里的大多数工程师对此一无所知。

这就是我们这周决定解决的问题。架构洞察 — drift、合规性、ADR、决策、讨论 — 在 archyl 中全部存在。已被索引、已被计算、已在仪表板上展示。但最需要它们的人正埋头写代码,不会刷新仪表板。于是洞察停在原地,架构决策继续在真空中产生。

今天我们发布 Team Architecture Digest。一封定期邮件,把每个团队的架构状态送到该团队的收件箱。每周、每两周、每月。团队自己选。

仪表板输了。收件箱赢了。

GitHub 在 2026 年依然给你发送 pull request 邮件,即使网站就在那里 — 这是有原因的。Linear 发送每日摘要,这是有原因的。每个分析工具都有 "weekly summary" 选项,这是有原因的。

人们不会主动拉取。他们扫描到达的东西。一个你必须记得打开的仪表板,就是一个你忘记打开的仪表板。

十年来,人们告诉我们 "Slack 和仪表板杀死了邮件"。但仪表板在你知道自己在找什么的时候才管用,Slack 在你需要反应的时候才管用。两者都不擅长 "这周重要的一切,两分钟内" — 这恰恰是工程团队为了在架构上保持对齐而又不必把它变成会议所需要的东西。

讽刺的是,邮件正是合适的载体。安静、密集、可归档、可搜索、可转发。每个团队也都已经有一个邮件列表。

每个团队的摘要都被 scope 到团队所拥有的项目。没有不相关的东西,没有别的团队的范围。

里面最多七个章节 — 团队选择保留哪些:

没有活动的章节会被静默省略。不会有半空的邮件。

渲染是纯 HTML。无追踪像素,无营销 chrome。白底黑字、单色、顶部带 archyl 字标 — 因为事务性邮件应该看起来像 Linear 或 Vercel,而不是营销活动。当你的邮件客户端支持 prefers-color-scheme 时,深色模式会自动切换。

打开团队设置,切到 Digest 标签。填一个团队邮箱。选频率、星期几、小时,以及团队真正所在的时区。勾选章节。保存。

你可以在应用内预览邮件而不发送任何东西,也可以向配置的地址发送一封测试邮件,在启用调度前验证可送达性和渲染。

调度器每小时运行一次,在配置的本地时间发送每个团队的摘要。一个安排在 Asia/Shanghai 周一 9 点的每周摘要,会在上海时间 9 点送达 — 即使上海有夏令时,即使你的 self-hosted 实例运行在 America/Los_Angeles。每个摘要都遵循其所属团队的时钟。

架构是团队的资产。它被集体拥有,每当其所有者之一 ship 代码时它就进化。最难的问题不是捕捉架构 — 图、ADR、drift 检测,我们做这些已经多年了。最难的问题是闭环架构所说的内容与团队所知的内容之间。

每周摘要做了一件简单但稀有的事:每周给团队一个仅五分钟的瞬间,让大家就自己的架构站在同一页。无站会。无需打开的工具。无需建立的习惯。只是大家都已经在读的邮件。

如果你是工程经理,这个瞬间值千金。如果你是团队的工程师,这是架构上下文第一次 来到你这里,而不是让你去追。

Team Architecture Digest 已在所有团队上线。打开团队设置,点 Digest 标签,你的第一封摘要会在下一个调度的 tick 发出。

告诉我们你的团队怎么看。我们已经在为更喜欢聊天而非收件箱的组织,原型 Slack 和 Teams 的等价物 — 但对于每周节奏,我们坚信收件箱才是能传递上下文而不变成噪音的载体。

架构,终于,出现在拥有它的人真正生活的地方。

想深入了解架构上下文如何在工程团队中流动?阅读 Architecture Change Requests 了解应用于你的 C4 模型的 pull request 工作流,或 Architecture Chat 来询问关于你的技术栈的任何问题,并获得基于你自己模型的答案。