古法编程

Context Mode 的工程核心在于将软件开发流程本身工程化。它通过动态 Agent 团队并行处理任务，强制执行 RED-GREEN-REFACTOR 的 TDD 垂直切片纪律，并在每次发布前进行 Grill-Me 审查。这套组合拳旨在系统性地对抗 LLM 开发的不确定性，确保对 15 个 AI 编码平台的支持稳定可靠。

Context Mode 的工程实践：并行 Agent 团队编排、TDD 纪律与 Grill-Me 发布审查

开发一个支持 15 个 AI 编码平台、运行在三种操作系统上的 MCP 服务器插件，其复杂性远超普通项目。Context Mode 采用了一套高度结构化的工程方法来应对挑战，这套方法将开发流程本身也视为需要“工程化”的对象。其核心是三大支柱：由 Engineering Manager (EM) 驱动的并行 Agent 团队、强制性的 TDD 纪律以及严谨的 Grill-Me 发布审查。本文将解析这些实践的具体运作方式。

1. 并行 Agent 团队与 Engineering Manager 模式

Context Mode 的开发摒弃了传统的单线程、顺序式工作流。它将每个问题（Issue）、拉取请求（PR）或发布任务，都视为一个需要由多个专业化 AI Agent 并行处理的“作战行动”。

动态团队组建：团队不是固定的。根据任务涉及的领域动态组建。例如，一个 OpenCode 平台的 bug，会自动生成一个包含“OpenCode 架构师”、“OpenCode Staff 工程师”、“QA 工程师”、“DX 工程师”以及可能的“OS 兼容性架构师”的团队。核心的“Context Mode 架构师”和“QA 工程师”则在每个任务中都必须出现。

Engineering Manager (EM) 角色：主对话（Main Conversation）的角色被明确定义为 EM。EM 的职责是编排、调度和决策，而非亲自实施。具体来说：

  • 分类：通过一个 Agent 分析任务，确定受影响的适配器、操作系统和核心模块。
  • 招募：根据agent-teams.md中的人员名单，构建定制化的 Agent 团队。
  • 调度：在一条消息中同时派发所有 Agent，确保真正的并行执行。每个代码修改 Agent 都在独立的 worktree 中工作。
  • 监控与决策：收集各 Agent 的结果，做出最终的“发货”或“不发货”决定。

关键规则：EM 被严格禁止阅读源代码、编写修复、运行测试或分析差异。如果 Agent 失败，EM 应该派生新的 Agent，而不是自己亲自上阵。这种分工强制实现了关注点分离，让“决策者”和“执行者”角色清晰，提升了大规模并行协作的效率。

2. TDD 纪律：垂直切片与反幻觉证据

在 Context Mode 的流程中，测试驱动开发（TDD）不是可选项，而是强制性的阻塞门控。其执行方式具有鲜明的项目特色。

垂直切片，而非水平切片：开发者被明确禁止“先写所有测试，再写所有代码”这种水平切片模式。正确的做法是严格的垂直切片：

  1. RED：为一个具体的行为编写一个失败的测试。
  2. RUN：运行该测试，确认它失败。
  3. GREEN：编写最简代码使该测试通过。
  4. RUN：再次运行，确认测试通过。
  5. REFACTOR：在保持测试通过的前提下清理代码。
  6. 重复：进行下一个行为的 RED-GREEN 循环。

反幻觉证据：LMMs 被认为容易产生“幻觉”。因此，Staff 工程师的 PR 如果没有附上 RED 和 GREEN 阶段的明确证据（例如：“RED: 测试 ‘通过环境变量检测 opencode’ — FAIL”），将被架构师直接拒绝。所有关于平台行为的断言，都必须有来自 refs/ 目录中克隆的上游源码的 file:line 引用作为证据，否则将被质疑。

架构师的审查权：架构师在审查 PR 时，有明确的权力拒绝任何缺乏测试、测试实现细节、使用水平切片或模拟内部协作者的变更。这确保了 TDD 纪律得以贯彻。

3. Grill-Me 发布审查：无情的预检

在将任何版本发布到生产环境之前，Context Mode 强制执行一套名为“Grill-Me”的严格审查流程。这并非一个简单的代码审查，而是一个结构化的质询访谈。

运作流程：

  1. EM（或系统）作为“面试官”，针对本次发布的所有变更，向用户（发布负责人）提出一系列问题。
  2. 问题必须一个接一个地提出，并沿着设计决策树的每一个分支深入，直至完全厘清依赖关系。
  3. 对于每个问题，审查者需要提供自己的建议答案，然后询问用户的意见。
  4. 如果问题可以通过探索代码库来回答，就必须先去探索，而不是直接提问。

发布阻塞条件：发布流程会被阻塞，直到：

  • 设计树的所有分支都已得到解决。
  • 不存在任何未解决的问题。
  • 用户明确批准 Grill-Me 的审查结果。

这个过程确保了在发布前，所有潜在的设计疑问、边界条件和依赖关系都被彻底讨论和确认，避免了基于未经检验的假设进行发布。

综合应用：从问题到发布的闭环

这些实践并非孤立存在，它们构成了一个完整的闭环工作流。当一个平台适配器出现问题时：

  1. Triage：EM 派遣 Agent 团队进行调查，首先进行声明验证（CLAIM_VERDICT），确认问题是否真实存在（CONFIRMED, UNCONFIRMED, DEBUNKED）。
  2. 修复：通过验证后，Staff 工程师在 TDD 纪律下编写修复，架构师通过 Ping-Pong 协议进行审查（最多 2 轮）。
  3. 集成：修复直接推送到 next 分支。
  4. 发布：当积累足够变更后，触发发布流程。此时，所有变更都必须经过 Grill-Me 审查，确保即使是一个小补丁，其背后的决策逻辑也是清晰无误的。

这套组合拳的目标，是将人类开发者从繁琐的、易错的具体实施中解放出来，专注于更高层的架构与业务决策（戴着 PO、OSS 和 Distribution 的帽子），同时通过流程和工具（/tdd, /grill-me, ctx_execute 等）确保工程质量不滑坡。其最终目的，正如项目所有者所强调的，是确保用户在任何平台上的第一次体验必须完美无缺，因为一次失败就可能永远失去用户。

FAQ

Q: 为什么 Context Mode 要强制使用“垂直切片”的 TDD 而非更常见的先写测试模式？ A: 因为该项目代码库极度脆弱（15 个适配器 × 3 个操作系统），水平切片容易导致测试脱离实际实现，编写出验证“想象中行为”而非“真实行为”的测试，这些测试在重构时极易失效，且无法提供真正的行为保障。

Q: Grill-Me 审查和普通的 Code Review 有什么区别？ A: Grill-Me 是一个发布前的、结构化的、多方质询的决策审查过程，关注的是整体设计的一致性、未解决的疑问和潜在风险。而 Code Review 通常是针对代码实现细节的同行评审。Grill-Me 是一个阻塞门控，必须完成且得到批准才能继续发布。