---
title: 将团队”伪BMI”化的话题
description: "※本文内容基于笔者个人经验和见解,不代表所属组织或特定厂商的官方观点。此外,这里介绍的方法并不保证对所有组织都有效且安全。实际引入时,请根据贵司的情况、合同、法规、安全策略等进行判断。 --- ## 引言:最浪费时间的或许是\"达成共识\"这件事 在我司这种基础设施、应用、存储混杂的现场工作时, 经常会出现这样的场景。 - \"这个最终是按什么方针决定的来着?\" - \"那个工单进展到哪一步了?\" - \"这个设计,不知道是谁基于什么前提考虑的...\" **比起实施时间更多时间消耗在\"达成共识\"上的感觉**,您是否也有过? 于是突然冒出了一个想法, > \"如果能把相关工程师的大脑和身体连接起来作为集合体行动,岂不是最强?\" 这已经是偏向科幻的想法了。 当然,现实中通过脑机接口(BMI)物理连接大脑还是相当遥远的事情。 但是,**如果结合工具、运维和文化,是否能接近\"伪连接状态\"呢?** 因此,我尝试构思了一个面向10人以下团队的\"伪脑机接口团队运维模型\"。 --- ## 目标团队的条件 这次设想的大概是这样的团队。 - 成员:**10人以内** - 角色:**基础设施、应用、存储混合**(云和本地都要接触) - 使用工具(示例) - GitHub - Slack - Notion - Teams / SharePoint(与其他部门或外部协作用)…"
url: "https://bestnetllc.co.jp/zh-hans/docs/%e5%b0%86%e5%9b%a2%e9%98%9f%e4%bc%aabmi%e5%8c%96%e7%9a%84%e8%af%9d%e9%a2%98/"
updated: "2026-10-19"
category: Tech Blog
---

# 将团队”伪BMI”化的话题

※本文内容基于笔者个人经验和见解,不代表所属组织或特定厂商的官方观点。此外,这里介绍的方法并不保证对所有组织都有效且安全。实际引入时,请根据贵司的情况、合同、法规、安全策略等进行判断。

---

## 引言:最浪费时间的或许是"达成共识"这件事

在我司这种基础设施、应用、存储混杂的现场工作时,
经常会出现这样的场景。

- "这个最终是按什么方针决定的来着?"
- "那个工单进展到哪一步了?"
- "这个设计,不知道是谁基于什么前提考虑的..."

**比起实施时间更多时间消耗在"达成共识"上的感觉**,您是否也有过?

于是突然冒出了一个想法,

> "如果能把相关工程师的大脑和身体连接起来作为集合体行动,岂不是最强?"

这已经是偏向科幻的想法了。
当然,现实中通过脑机接口(BMI)物理连接大脑还是相当遥远的事情。

但是,**如果结合工具、运维和文化,是否能接近"伪连接状态"呢?**
因此,我尝试构思了一个面向10人以下团队的"伪脑机接口团队运维模型"。

---

## 目标团队的条件

这次设想的大概是这样的团队。

- 成员:**10人以内**
- 角色:**基础设施、应用、存储混合**(云和本地都要接触)
- 使用工具(示例)

  - GitHub
  - Slack
  - Notion
  - Teams / SharePoint(与其他部门或外部协作用)
  - Nextcloud(文件共享等)

简而言之,设想的是**"所有人都接触各种技术的全栈型小团队"**。

---

## 理念:在外部构建团队的"集合大脑"

想要达成的状态用一句话概括就是,

> **减少"只存在于某人大脑中的信息",
> 向团队整体的"外部大脑"集中。**

就是这样。

代替脑机接口,

- 工具(GitHub / Slack / Notion / 仪表板)
- 协议(如何流转信息)
- 文化(如何行动)

通过组合这些要素,构建**"伪连接状态"**。

---

## 工具的角色分工:将哪里视为"大脑"

首先,要给手头的工具明确分配角色。

### 1. GitHub：任务、代码和决策的"中枢神经"

- Issue / Projects：任务管理（基础设施和应用程序混合也可以）
- PR：代码和配置的变更点
- `docs/adr`：架构的"决策日志"（ADR）

要点是，

> **无论是基础设施还是应用程序，首先全部记录到 GitHub Issue 中**

这样的规则。
"将任务的入口统一到 GitHub"，这样认知的入口就统一了。

---

### 2. Slack：实时的"脑内聊天"

Slack 是用来分享对话和"当前想法"的地方。

**示例：频道构成**

- `#dev-general`：开发和基础设施综合
- `#infra`：网络、虚拟基础设施、存储相关
- `#alerts`：监控、告警联动
- `#daily-sync`：每日"想法"分享（后述）
- `#random`：闲聊

重要的是，

> 在 Slack 中讨论并"决定的事项"出现后，
> **必须记录到 GitHub Issue / ADR / Notion 中**

这一步骤。
**"讨论完就结束"的话，会瞬间被遗忘。**

---

### 3. Notion：设计和知识库的"长期记忆"

在 Notion 中，放置**多次重复使用的知识和设计**。

构成示例：

- `📚 Knowledge`

  - 系统列表（URL、负责人、概要）
  - 常见流程（Runbook）
- `🧠 Architecture`

  - 整体架构
  - 网络概要
  - 认证/权限的整体架构
- `📝 Meeting Notes`

  - 定期会议笔记
  - 每页末尾设"决定事项"部分
- `✅ Playbooks`

  - 故障响应和定期维护流程

> "同样的说明重复3次以上就升级到 Notion"
> 这种简单粗暴的标准也不错。

---

### 4. Teams / SharePoint / Nextcloud:对外接口与仓库

- Teams:与其他部门/客户沟通用(对外窗口)
- SharePoint / Nextcloud:文档和文件存储位置

**内部"工程师思维"集中在 GitHub / Slack / Notion**,
其他工具定位为"与外部世界的连接点",这样整理起来会更清晰。

---

## 类BMI式"一天工作流程"设计

### 早上:团队"脑波同步"(约15分钟)

#### 1. `#daily-sync` 各自发布

格式示例:

```
[今日任务]
- ISSUE-1234 Proxmox 存储配置调整
- ISSUE-1201 API 延迟调查

[昨日遇到问题]
- DB连接限制问题,等待决策(@○○)

[咨询/求助]
- SWIFT对接批处理作业设计,希望有人帮忙review 30分钟
```

仅此而已,

- 谁在关注什么任务
- 哪里可能成为瓶颈

就能通过文本快速掌握全局。

#### 2. 浏览仪表板

准备一个汇总监控、CI、关键指标的仪表板,
每天早上安排一个人(可轮班)查看,发现可疑之处就在 Slack 发一条:

> "DB延迟比昨天恶化。今天边观察边查原因"

仅此就能避免"莫名不安"无法共享的问题。

---

### 日间:任务启动～完成流程

#### 任务开始时

1. 将 GitHub Projects 的卡片移到 `Doing`
2. 在 Issue 开头写下当前掌握的上下文:

```
## 现状
- X环境的数据库连接错误仅在特定时段增加
- 日志显示接近 connection limit 值

## 假设
- 与连接池设置不一致
- 批处理作业增加

## 完成条件
- 确定原因
- 决定应对方针(必要时创建ADR)
```

留下"上下文数据包",
之后任何人看都能轻松追踪情况。

---

#### 遇到困难时

- 在 Issue 评论中写"做到哪里了""在哪里遇到困难"
- 复制该评论并粘贴到 `#infra` 或 `#dev-general`:

```
关于 ISSUE-1234,已调查到这里:

- A方案(增加连接数)似乎只是权宜之计
- application侧的池设置可能与RDS不一致

接下来想向熟悉应用侧设计的人咨询一下
```

通过**"一起输出作业日志+思考日志"**,
其他成员能更容易地"连同头脑中的内容一起共享"。

---

#### 确定方针时

- 在 Issue 中写结论
- 重要的创建一个 ADR
- 在 Slack 发送"已写好ADR"并粘贴链接

这样做,
**"讨论并达成一致的事项"就会留在团队的长期记忆中**。

---

### 下班前:小型"大脑快照"(5分钟)

各自要做的事很简单。

- 在 `Doing` 的Issue中写一行"明天要做的事"备忘
- 有余力的话在 `#daily-sync` 追加"今天做了什么"的概要

```
[今日做的事]
- ISSUE-1234 确定 Proxmox 存储设计并创建 PR
- DB 连接上限、RDS 侧参数候选追加到 Notion
```

第二天早上自己或成员可以更容易地重建状况,
**脑内上下文的重新加载成本**会降低。

---

## 不忘记决定的"ADR"机制

讨论时间最浪费的是,
**"再次说明之前已经决定的事情"**。

因此想要引入的是 **ADR(Architecture Decision Record)**。

- 在各个仓库中创建 `docs/adr` 目录
- 即使只记录"日后可能有争议/容易忘记的决定"也可以

文件示例:`docs/adr/0001-choose-proxmox-as-hypervisor.md`

```
# 0001: 采用 Proxmox VE 作为虚拟机管理程序

- 日期: 2025-12-11
- 状态: Accepted

## 背景

～(略)

## 决定

～(略)

## 采用的理由

～(略)

## 被否决的选项
- VMware ESXi:
  - 理由:
- Hyper-V:
  - 理由:

## 影响范围

～(略)
```

Slack 讨论结束后,有人写 ADR,
在 `#dev-general` 贴上链接就能产生很大效果。

> "为什么选择这个",
> 从一个人的脑内转移到团队的"外部大脑"的感觉。

---

## 如果分阶段引入

一下子全部实施会很困难,
分阶段进行会更顺利。

### Phase 1(最初2周):统一入口

- 创建 GitHub Projects,
  **新任务必须创建 Issue** 的规则
- 在 Slack 创建 `#daily-sync`,即使一天一行也要尝试发布

### Phase 2(接下来2~4周):记录决定的习惯

- 出现重要技术判断时,至少写一篇 ADR
- 在 Notion 只创建以下3项:

  - 系统一览
  - Runbook
  - Meeting Notes

### 阶段3：培育仪表板和Playbook

- 将监控和CI的仪表板整合到一个屏幕
- 将重复性工作作为Notion的Playbook保留下来

---

## 总结：锻炼"外部大脑"以替代BMI

本文介绍的伪BMI模型，
简单来说是以下思路。

- **将任务、决策、设计从特定人员的头脑转移到GitHub / Slack / Notion**
- **在每天开始和结束时，共享小型"大脑快照"**
- **将重要决策记录为ADR，避免重复相同的讨论**

通过这些方法，

- 认识对齐会议的时间缩短
- 减少"仅存在于某人头脑中的前提"
- 整个团队更容易作为一个"集体智慧"运作

虽然不知道真正用BMI直连大脑的时代是否会到来，
**但我认为通过组合工具、运维和文化，
即使在现在也能充分接近"伪链接状态"**。

如果有团队也有类似的问题意识，
请务必尝试哪怕一部分内容。
一定能发现某些"认识对齐的浪费"。