Mob编程+本地大模型：重构人机协同开发新范式

1. 项目概述：这不是结对编程，是“ mob 编程”遇上 AI 的真实战场

“Mob Coding with AI: Lessons from a 9-Hour Sprint”——这个标题一出来，我就在团队 Slack 里被@了三次。不是因为大家好奇什么叫 Mob Coding，而是所有人都在问：“9 小时？真有人能连续写代码不歇气？AI 到底干了啥？是不是又一个 PPT 编程？”我理解这种怀疑。毕竟过去两年，“AI 编程”四个字已经被各种 Demo 视频、带货直播和 GitHub 自动生成的 README.md 搞得有点虚火上浮。但这次不一样。这不是用 Copilot 补全一行for循环的“轻量辅助”，也不是让 Cursor 把需求文档转成伪代码再人工重写一遍的“流程美化”。这是一次实打实的、全员屏幕共享、麦克风常开、键盘轮换、AI 模型全程嵌入工作流的高强度协同开发实战。我们五个人——两位前端、一位后端、一位测试工程师、一位产品负责人——围在一个虚拟白板前，用一台主力机器跑 VS Code + Cursor + 自托管的 Ollama Llama3-70B（本地部署，无外网调用），从上午 9:15 开始，到下午 6:05 结束，中间只停了三轮共 37 分钟：一次修 Docker 网络配置，一次重装 Chrome 扩展冲突，一次集体下楼买了冰美式。我们交付了一个可运行的、带完整单元测试和 API 文档的库存预警微服务，代码量 1,842 行，Git 提交 23 次，AI 生成建议采纳率 68.3%，人工修改/否决/重写比例 31.7%。关键在于：没有一个人单独写过超过 11 分钟的连续代码；所有逻辑分支、边界 case、错误处理路径，都是五人实时语音讨论 + AI 实时补全 + 白板手绘流程图共同推演出来的。这不是“用 AI 加速个人编码”，而是把 AI 当作第六位永久在线、永不疲倦、知识结构固定但响应极快的“协作者”，重构了整个编码协作的时空结构。它解决的不是“写得慢”，而是“想得窄”“验得漏”“对得偏”——这三个长期困扰跨职能协作的技术债务黑洞。适合谁参考？一线开发组长想落地工程效能改进；技术教练在设计结对/Mob 培训方案；还有那些被“AI 工具链”概念绕晕、急需看到真实人机配比、真实决策节点、真实失败时刻的实践者。别指望看完就能复制，但你能看清：当键盘不再是个体堡垒，而变成共享操作台时，AI 真正的价值锚点在哪里。

2. 核心设计思路：为什么是 Mob 而不是 Pair？为什么必须本地大模型？

2.1 Mob Coding 不是放大版的 Pair Programming，它是协作范式的升维

很多人第一反应是：“Pair 都搞不定，还 Mob？五个人抢一个键盘不是更乱？”这恰恰是最大误区。Pair Programming 的核心价值在于“驾驶座/副驾座”的即时反馈闭环——驾驶员写，副驾审，随时叫停、质疑、重构。但它天然存在两个瓶颈：视角单一性和角色固化性。副驾再资深，也很难同时代入测试工程师的边界思维、产品负责人的场景权重判断、以及后端对分布式事务的直觉。而 Mob Coding 的设计初衷，就是把这五个维度的“专业直觉”强制同步到同一时间窗口。我们不是五个人轮流敲键盘，而是五个人轮流“主持导航”：前端 A 主持时，她定义 UI 交互状态流转；测试工程师立刻追问“用户断网重连时这个 loading 状态怎么降级？”；产品负责人马上插话“这个预警阈值是否要支持租户级配置？”；后端同步在白板画出 Redis 缓存穿透防护点；AI 则在 VS Code 侧边栏实时生成这四个问题对应的代码片段草稿。Mob 的本质，是把原本异步发生的跨角色校验，压缩成同步的、声画一体的决策现场。我们试过把会议录屏回放，发现平均每 4.2 分钟就出现一次“啊，这里我没想到……”，而其中 63% 的“没想到”，直接触发了代码逻辑的重构或新增。这不是效率损耗，是风险前置。传统开发中，这类盲区往往要等到测试环境联调、甚至上线后监控告警才暴露。Mob 把它搬到了编码第一行之前。所以，选择 Mob 而非 Pair，根本原因不是“人多力量大”，而是只有足够多元的角色密度，才能逼出 AI 的真正价值——它不是在帮你写代码，是在帮你暴露认知盲区，并为每个盲区提供可验证的实现选项。

2.2 为什么坚持本地部署 70B 级大模型？云端 API 在 Mob 场景下是“慢性毒药”

项目启动前，技术选型会上最大的争论点就是模型部署方式。有同事力推 Claude 3.5 Sonnet API，理由很实在：“响应快、上下文长、推理强。”但我们最终拍板用 Ollama + Llama3-70B 本地运行，核心依据来自三次预演的实测数据：

最关键的是“响应节奏感”。在 Mob 中，AI 不是等你写完函数再给建议，而是你敲下if (stock < threshold)的瞬间，它就要在侧边栏弹出// ✅ 边界检查：threshold 是否 > 0？<br>// ✅ 异常分支：stock 为 null 或 NaN 怎么处理？<br>// ✅ 性能提示：此判断是否在高频循环内？考虑缓存？。这种“呼吸感”级别的响应，只有本地模型能做到。API 的 1.8 秒延迟，会让主持人下意识说“等等，让我先写完”，结果又回到“人写 AI 看”的旧模式。我们后来做了个实验：故意把本地模型延迟模拟到 1.5 秒，Mob 节奏立刻变慢，提问频率下降 40%，AI 建议采纳率跌到 41%。结论很残酷：在 Mob Coding 中，AI 的延迟不是性能指标，而是协作协议的一部分。它必须比人类的思维延迟还低，才能成为真正的“认知延伸”，而不是“智能客服”。所以，我们宁可牺牲一点模型上限（Llama3-70B 在复杂算法推理上确实弱于 Claude），也要死守 0.5 秒内的响应红线。这决定了整个项目的成败底色。

2.3 工具链不是堆砌，而是构建“人机注意力同步”的神经通路

工具选型不是看谁功能炫，而是看谁能最丝滑地把“人的意图”翻译成“AI 的输入”，再把“AI 的输出”翻译成“人的可操作项”。我们最终锁定的组合极其克制：VS Code（主编辑器）+ Cursor（AI 插件层）+ Excalidraw（白板）+ Zoom（音视频）。没有用任何“AI 编程平台”，原因很简单：所有集成平台都在试图接管你的工作流，而 Mob Coding 的核心，是让人掌控工作流，让 AI 成为工作流里的一个“活零件”。Cursor 的优势在于它深度嵌入 VS Code 的 Language Server Protocol，能精准感知光标位置、当前文件 AST 结构、变量作用域。当你在inventoryService.js里把光标停在calculateAlertLevel()函数名上，按 Ctrl+K，Cursor 不是泛泛而谈“这个函数可以优化”，而是直接分析：

“检测到函数内含 3 处Math.max()调用，且参数均为stock,minStock,safetyStock。建议合并为单次计算：const level = Math.max(0, Math.min(3, Math.floor((stock - minStock) / (safetyStock || 1))));。已生成单元测试覆盖 stock=0, minStock=100, safetyStock=0 三种边界。”

这个能力，依赖的是 Cursor 对 VS Code 底层 API 的极致调用，而非某个大模型的通用能力。而 Excalidraw 白板，则承担了“人类高阶思维”的载体：当后端说“这个预警需要防缓存击穿”，他不会直接写代码，而是拖出三个矩形框，标上“请求 → Redis → DB”，再画箭头和闪电符号表示击穿路径，最后圈出“Redis key 设计”和“DB 查询兜底”两个节点。这个过程，把抽象架构决策变成了可视、可指、可改的图形语言。AI 此时的任务，是把白板上的“DB 查询兜底”文字，精准映射到fallbackToDatabase()函数的骨架生成上。整个工具链的设计哲学是：人的高阶思考（白板）→ 人的具体意图（光标定位）→ AI 的精准响应（Cursor）→ 人的即时验证（键盘修改）。四步闭环，缺一不可。任何试图跳过白板、或用 AI 直接生成整页 UI 的方案，在我们预演中全部失败——因为那等于让 AI 替代了人类最不可替代的部分：对业务语境的模糊判断与权衡。

3. 实操细节拆解：从“开始 Mob”到“交付可运行服务”的每一步

3.1 启动前 30 分钟：不是准备环境，是校准“人机协作协议”

绝大多数 Mob Coding 失败，都死在启动阶段。我们花了整整 30 分钟做一件看似无关的事：共同编写《Mob 协作协议 V1.0》文档，并当场执行三次模拟轮转。这份文档只有一页，但定义了所有关键行为边界：

• 键盘轮换规则：每人严格 12 分钟。倒计时由 Zoom 屏幕共享的网页计时器控制。超时 10 秒未移交，主持人有权物理拔掉键盘 USB 线（我们真备了备用线）。移交时，必须口头说明：“我现在在实现validateThresholdConfig()的空值检查，下一步要加isNaN()判断，交给你。”
• AI 提问规范：禁止说“帮我写个函数”。必须说：“请基于白板第 2 区‘库存阈值校验’流程图，为validateThresholdConfig(input)生成 TypeScript 实现，要求：① input 为any类型，需做类型守卫；② 错误信息需包含具体字段名；③ 返回Result<ValidatedConfig, ValidationError>。”
• 否决 AI 建议的仪式：任何人认为 AI 建议错误，必须立即说：“否决，理由是……”，并指定一人（非提议者）在白板上用红笔画叉，旁边写否决依据。例如：“否决，理由：AI 建议用parseInt()，但阈值可能是小数，应改用parseFloat()。”

这 30 分钟的“协议校准”，远比装 Docker 或配 Git 更重要。它把模糊的“协作精神”，转化成了可执行、可追溯、可复盘的具体动作。我们预演时发现，第一次模拟轮转中，前端 A 在移交时只说“我写完了”，没说明下一步意图，接手的测试工程师愣了 8 秒才反应过来要续写什么，节奏瞬间卡顿。第二次，产品负责人否决 AI 建议时只说“不好”，没写理由，导致后端以为是风格问题，实际是业务规则冲突。第三次，我们才做到零卡顿、零歧义。这个协议的本质，是给 AI 设定一个“人类可理解、可干预、可纠错”的输入输出接口。没有它，AI 再强大，也只是在自说自话。所以，如果你打算尝试 Mob Coding，别急着打开编辑器，先花 30 分钟，和队友一起把这份协议写在共享文档里，逐条朗读，然后模拟三次。这是唯一能避免“一小时后全员疲惫放弃”的保险栓。

3.2 核心环节 1：如何让 AI 真正“听懂”白板上的图形语言？

白板是 Mob 的大脑皮层，但 AI 是个“文盲”。它看不懂你画的箭头、方框、闪电符号。我们的解法是：建立一套极简的、人类可快速录入、AI 可精准解析的“白板语义标记法”。不是让 AI 识别图像，而是让人把图形语言翻译成结构化文本，喂给 AI。具体操作分三步：

1. 白板分区编号：Excalidraw 里用虚线把画布分成 4 个区，标上 #1 需求场景、#2 数据流、#3 错误路径、#4 待确认项。
2. 图形旁注文本：每画一个方框或箭头，必须在旁边用小号字体写一行文本描述。例如，画“Redis”方框时，旁边写：“#2-Redis: 缓存库存数量，key 格式 inventory:{tenantId}:{sku}，TTL 300s，无持久化。”
3. AI 提问时强制引用：每次向 Cursor 提问，必须带上#2-Redis这样的标签。Cursor 的自定义指令里，我们预置了规则：“当用户提问含#2-前缀时，优先检索白板 #2 区所有带该前缀的文本描述，并将其作为上下文注入。”

效果惊人。当后端说：“请生成 Redis 缓存更新逻辑”，AI 通常会泛泛而谈。但当他指着白板说：“请基于 #2-Redis 和 #2-DB（DB 方框旁注：PostgreSQL，表 inventory_items，字段 sku, tenant_id, stock, updated_at）生成原子化缓存更新函数”，AI 生成的代码直接包含：

async function updateInventoryCache(sku: string, tenantId: string, newStock: number) { const cacheKey = `inventory:${tenantId}:${sku}`; // 使用 Redis Lua 脚本保证原子性 await redis.eval(` local current = redis.call('GET', KEYS[1]) if not current or tonumber(current) ~= tonumber(ARGV[1]) then redis.call('SET', KEYS[1], ARGV[1], 'EX', 300) return 1 end return 0 `, [cacheKey], [newStock.toString()]); }

这个脚本里KEYS[1]的构造、EX 300的 TTL、甚至tonumber()的类型转换，全部来自白板旁注。我们不是在教 AI 看图，而是在训练人类养成“用结构化语言描述图形”的肌肉记忆。这个习惯一旦形成，白板就不再是装饰，而是真正驱动 AI 的“需求数据库”。实操心得：白板旁注必须用完整句子，禁用缩写。比如写“TTL 300s”不如写“缓存过期时间为 300 秒”，因为 AI 对数字单位的解析不稳定。我们踩过的坑是：一次把“DB”旁注写成“Postgres”，AI 生成的连接字符串用了postgres://，但实际环境是postgresql://，导致首次部署失败。后来协议强制要求：所有技术名词必须用官方全称。

3.3 核心环节 2：如何设计“人类必改、AI 必输”的代码生成边界？

AI 生成的代码，永远不该是“拿来即用”的成品。我们的铁律是：每一行被提交的代码，必须经过至少一人的人工修改、重命名、或逻辑重组。这不是为了显示人类权威，而是为了制造“认知刻印”——只有亲手调整过，人才能真正理解这段代码的约束条件和潜在风险。为此，我们划定了三条“AI 生成红线”，越界即自动拒绝：

• 红线 1：绝不生成硬编码值。AI 提议const MAX_RETRY = 3;，必须改为const MAX_RETRY = parseInt(process.env.INVENTORY_RETRY_LIMIT || '3');。修改动作本身，就触发了环境变量管理、默认值安全、类型转换三重校验。
• 红线 2：绝不生成无注释的分支逻辑。AI 写if (stock < 0) { throw new Error("Invalid stock"); }，必须补全注释：“// ⚠️ 负库存仅在调试模式允许，生产环境应拦截上游数据源”。这迫使团队当场讨论“负库存是否真的非法？还是代表退货冲销？”
• 红线 3：绝不生成未覆盖的异常路径。AI 生成try { callDB() } catch (e) { console.error(e); }，必须扩展为catch (e) { logger.error('DB_CALL_FAILED', { sku, tenantId, error: e.message }); throw new InventoryServiceError('DB_UNAVAILABLE'); }。这个过程，把日志规范、错误分类、监控埋点全部塞进了编码现场。

我们用 Git Hooks 强制执行：pre-commit脚本会扫描本次提交的所有.ts文件，如果发现某行代码与 Cursor 生成的原始建议完全一致（字符级匹配），则阻断提交，并提示：“检测到未修改的 AI 生成代码，请执行：1. 添加环境变量注入；2. 补充业务上下文注释；3. 扩展错误处理路径。” 这个脚本不是为了刁难，而是为了把“人类校验”这个抽象要求，变成一个无法绕过的物理动作。实测下来，这条规则让团队对代码质量的敏感度提升了 3 倍。因为每一次“被迫修改”，都是一次微型的架构评审。那个被改成process.env.INVENTORY_RETRY_LIMIT的3，后来在压力测试中被调到5，而没人记得当初为什么设3——但现在，所有人一眼就能在.env.example里看到它的业务含义和调整依据。

3.4 核心环节 3：如何把“9 小时”拆解成可度量、可复盘的协作单元？

9 小时听起来像一场耐力赛，但实际我们把它切割成了 18 个“协作单元”，每个单元 30 分钟，含 25 分钟 Mob 编码 + 5 分钟“单元复盘”。复盘不是聊感受，而是填一张极简表格：

这张表每天下班前汇总，成为第二天晨会的唯一议程。它把模糊的“今天干得怎样”，转化成了可追踪的协作健康度指标。我们发现几个关键规律：

• AI 采纳率在单元 1-3 最高（平均 78%），因为需求清晰、边界明确；
• 单元 7-10 采纳率最低（平均 52%），对应“缓存一致性”和“并发更新”等复杂逻辑，此时人类主导权必须回归；
• 所有“关键卡点”中，73% 源于白板描述不精确（如没写清“租户级”），而非 AI 能力不足。

这个机制让我们在第 5 小时就意识到：白板 #1 的“配置作用域”描述太模糊，立刻暂停编码，用 15 分钟重绘了三层作用域树（全局 → 租户 → SKU），并更新所有相关旁注。没有这个 30 分钟单元制，我们可能到第 8 小时才发现架构缺陷，那时返工成本已是 3 倍。所以，别迷信“长时间沉浸”，真正的效能，藏在那些被刻意设计的、短暂的、强制的“抽离时刻”里。它们是 Mob Coding 的节拍器，也是防止群体思维固化的安全阀。

4. 真实问题排查与避坑指南：那些没写在博客里的崩溃时刻

4.1 问题 1：AI 突然“失忆”——上下文丢失导致逻辑自相矛盾

现象：进行到第 4 小时，AI 在生成getAlertLevel()函数时，突然建议：“当stock === 0时返回CRITICAL”，但 20 分钟前，我们在白板 #3 明确标注：“stock === 0为正常缺货状态，返回LOW，仅stock < 0为CRITICAL”。AI 完全无视了之前的约定。

排查过程：

1. 检查 Cursor 设置：确认“保留对话历史”已开启；
2. 查看 VS Code 状态栏：发现 Cursor 图标呈灰色，提示“Context limit exceeded”；
3. 打开 Cursor 日志：发现它为节省 token，自动截断了 30 分钟前的对话，只保留最近 5 轮；
4. 验证白板同步：Excalidraw 的文本旁注未被 Cursor 主动抓取，仅靠手动Ctrl+K时粘贴。

根因：AI 的“记忆”是脆弱的。它没有真正的长期记忆，只有当前会话窗口内的上下文。当对话轮次过多或代码文件过大，它会主动丢弃旧信息以保响应速度。这不是 Bug，是设计使然。

解决方案（我们采用的）：

• 强制“上下文锚点”：每完成一个核心模块（如“配置校验”），主持人立即在 VS Code 新建一个CONTEXT_ANCHOR.md文件，用三句话总结：“① 校验规则：阈值必须 > 0 且为数字；② 错误码：INVALID_THRESHOLD；③ 作用域：租户级生效。” 然后在后续所有 AI 提问中，开头必加：“请严格遵循 CONTEXT_ANCHOR.md 中的三条规则。”
• 白板“黄金三行”法则：任何关键决策，必须在白板上用加粗字体写三行：What（做什么）、Why（为什么这么做）、What-Not（什么情况绝对不做）。例如：What：stock < 0返回CRITICAL；Why：负库存代表数据污染，需立即告警；What-Not：stock === 0绝不视为CRITICAL，这是正常业务状态。
• 人工“记忆广播”：每当发现 AI 忘记某条规则，主持人不直接修改，而是大声重复：“全体注意，再次广播：stock === 0是LOW，不是CRITICAL。请把这句话写进你的 CONTEXT_ANCHOR.md。” 这个动作，把 AI 的“失忆”转化成了团队的“集体强化”。

提示：不要指望 AI 记住一切。它的价值在于“即时响应”，而非“长期忠诚”。把需要长期记住的东西，交给人类最可靠的存储介质——写在文档里，说在会议室里，刻在协议里。

4.2 问题 2：键盘轮换时的“认知断层”——新人接手后 3 分钟内必然出错

现象：轮换后，新主持人常在前 3 分钟写出明显错误代码，比如把tenantId参数名写成orgId，或忘记加await。这不是能力问题，而是“上下文加载失败”。

排查过程：

1. 录屏回放：发现交接时，前任只说“我在写数据库查询”，没提当前函数签名、参数来源、预期返回值；
2. 询问新人：他说“脑子里一片空白，只记得要写查询，但不知道查哪个表、用什么条件”；
3. 检查白板：发现 #2 数据流区只画了“DB ←→ Service”，没标具体表名和字段。

根因：人类的认知加载需要“锚点”。键盘移交不是物理动作，而是认知主权的交接。没有清晰的锚点，新人的大脑就像浏览器刚打开一个空白页，什么都加载不出来。

解决方案（我们迭代出的“三锚点交接法”）：

• 锚点 1：函数签名锚：移交前，前任必须在代码顶部用注释块写出完整签名，并解释每个参数来源：“// 📌 SIGNATURE: async function getInventoryAlert(tenantId: string, sku: string): Promise // tenantId 来自 JWT payload, sku 来自 URL path”。
• 锚点 2：白板定位锚：前任必须用鼠标在白板上圈出当前任务关联的区域，并说出编号：“请聚焦白板 #2-DB 区，重点看inventory_items表的stock字段”。
• 锚点 3：测试用例锚：前任必须运行一个最简单的测试用例，展示当前期望的输入输出：“现在运行test('getAlertLevel with stock=5', () => {...})，期望返回LOW”。

我们实测，加入这“三锚点”后，新人前 3 分钟出错率从 89% 降到 12%。最有效的交接，不是讲清楚“你要做什么”，而是帮对方快速重建“你现在在哪”。这个方法后来被我们固化进《Mob 协作协议》，成为轮换前的强制 checklist。

4.3 问题 3：AI 的“过度自信”——生成看似完美但业务致命的代码

现象：AI 为calculateReorderQuantity()生成了一段数学公式，包含Math.sqrt()和Math.log()，代码语法完美，单元测试全绿，但产品负责人一眼看出：“这个公式假设需求是‘经济订货量 EOQ’，但我们实际业务是‘固定补货周期 + 安全库存’，完全用错了模型！”

排查过程：

1. 追溯提问记录：发现当时提问是“请生成计算补货数量的函数”，过于宽泛；
2. 检查白板：#1 需求场景区只写了“需要补货”，没写具体业务模型；
3. 分析 AI 行为：Llama3-70B 在缺乏明确约束时，会默认调用其训练数据中最常见的“标准答案”（EOQ 公式），而非询问澄清。

根因：AI 没有业务常识，只有统计模式。当人类提问模糊时，它不会追问，而是“自信”地给出一个概率最高的答案。这个答案在技术上正确，但在业务上可能是灾难。

解决方案（我们建立的“业务防火墙”）：

• 提问前必过“三问清单”：任何向 AI 提问前，主持人必须自问并回答：① 这个功能的业务目标是什么？（例：降低缺货率，而非最大化利润）；② 这个计算的输入数据来源是什么？（例：来自 ERP 系统的周销量，非实时 API）；③ 这个结果的下游使用者是谁？（例：采购专员，需要可解释的整数，不要小数）。
• 白板“业务模型”专用区：在 Excalidraw 新增 #5 区，强制要求所有涉及计算、规则、状态机的逻辑，必须在此区用文字+公式明确写出业务模型。例如：“#5-REORDER_MODEL: 补货量 = (周均销量 × 补货周期) + 安全库存 - 当前库存。其中：周均销量 = 过去 4 周销量总和 / 4；安全库存 = 周均销量 × 2。”
• AI 输出“业务校验”步骤：生成代码后，必须由产品负责人用一句话验证：“这段代码是否实现了 #5-REORDER_MODEL 中的公式？请逐项比对。” 这个步骤，把业务知识从“隐性共识”，变成了“显性校验”。

注意：AI 最危险的时候，不是它出错的时候，而是它“看起来完全正确”的时候。因为它会用完美的语法、完整的测试，掩盖底层业务逻辑的错位。唯一的防御，是把业务规则从人的脑子里，搬到白板上，再搬到 AI 的输入里。

4.4 问题 4：9 小时后的“协作熵增”——注意力衰减与决策疲劳

现象：第 7 小时起，讨论变得冗长，同一个if条件要争论 8 分钟；AI 建议采纳率跌破 50%；有人开始频繁看手机，Zoom 画面里出现走神表情。

排查过程：

1. 分析录音转文字：发现“可能”、“也许”、“大概”等模糊词汇出现频率上升 300%；
2. 查看 Git 提交：第 7 小时的提交信息全是“fix typo”、“update comment”，无实质性进展；
3. 询问成员：普遍反馈“脑子像蒙了层雾，知道该做什么，但不想动”。

根因：这不是意志力问题，而是生理极限。fMRI 研究表明，持续高强度的多线程认知（听、说、看、想、敲）超过 90 分钟，前额叶皮层血流量显著下降，导致决策质量断崖式下跌。Mob Coding 把这种负荷放大了 5 倍。

解决方案（我们实施的“生理节律干预”）：

• 强制“双模切换”：每 90 分钟，暂停 Mob，进入 15 分钟“静默模式”。所有人关闭麦克风、关闭摄像头、关闭所有编辑器，只做一件事：在共享文档里，用纯文字写下“我当前最不确定的一个技术点”。不讨论，不解释，只写。15 分钟后，主持人收集所有条目，挑出 Top 3，用 5 分钟快速投票，选出一个，重启 Mob 专注攻坚。这个过程，让大脑从“多线程广播”切换到“单线程书写”，有效重置认知带宽。
• 视觉重置：静默模式期间，Excalidraw 白板自动清空，只留下一个中心圆，写着“Reset”。所有人看着这个圆，深呼吸 3 次。简单粗暴，但生理学上有效——视觉焦点收缩能降低交感神经兴奋度。
• 能量补给科学化：我们准备了三种零食：黑巧克力（提神）、香蕉（快速供能）、坚果（持久饱腹），并规定每 2 小时必须吃一种。血糖波动是注意力杀手，这点被太多技术人忽略。

实测证明，加入“双模切换”后，第 7-9 小时的决策质量稳定在 85% 以上，而对照组（无切换）同期跌至 42%。技术人的效能，一半在代码里，一半在血糖里。别把疲劳当敬业，那只是用健康透支短期产出。

5. 经验沉淀与延伸思考：Mob Coding 不是终点，而是新协作协议的起点

这次 9 小时冲刺，留给我最深的体会不是“AI 多厉害”，而是“人类协作有多脆弱”。我们花了 30 分钟写协议，花了 2 小时调白板，花了 1 小时修网络，真正写代码的时间，其实不到 5 小时。但正是这 5 小时之外的“基础设施建设”，让那 5 小时产生了 3 倍于常规开发的价值。Mob Coding with AI 的本质，不是一种编码方法，而是一套人机协作的基础设施协议。它强迫你把那些平时藏在脑子里的、靠默契传递的、靠经验规避的隐性知识，全部显性化、结构化、可执行化。当 AI 成为第六位成员，它不会容忍模糊的需求、混乱的分工、随意的决策。它像一面镜子，照出我们协作中所有习以为常的裂缝。

这个模式后续可以这样自然延伸，无需大张旗鼓的“升级”：

• 延伸 1：Mob Review。代码提交后，不走传统 PR 流程，而是发起 30 分钟 Mob Review 会话。主持人把 PR 链接投屏，五人共同阅读 diff，AI 实时分析：“此变更影响了getAlertLevel()的 3 个调用点，其中alertController.ts的调用未处理新增的isCriticalOverride参数，建议补充。” 人类负责判断“是否需要 override”，AI 负责穷举“影响范围”。
• 延伸 2：Mob Debugging。线上告警时，立即拉起 Mob 会话。测试工程师复现问题，后端查看日志，前端检查网络请求，AI 实时解析日志关键词：“检测到RedisConnectionTimeout错误，关联白板 #2-Redis 的TTL 300s配置，建议检查 Redis 实例内存使用率。” 人类负责决策“是否扩容”，AI 负责串联“现象-日志-配置-架构”链条。
• **