GitLab 团队实践：上下文驱动的 AI 开发工作流

从混乱到有序：上下文驱动的 AI 开发工作流实践

来自 GitLab 团队博客，团队认为：AI 时代开发效率的瓶颈从原来的工具能力，转为了上下文。管理上下文的能力、识别问题的判断力，以及持续打磨工具的底层能力。 https://about.gitlab.com/blog/building-an-ai-dev-workflow/

GitLab 团队优化后的 AI 工作流长什么样？

· 优先级主动送上门：会话启动时，AI 自动加载活跃任务、阻塞项、历史决策，并按他定义的顺序呈现（搁置事项 → 他人评审请求 → 待回答问题 → 自己被阻塞的 MR）。他不再花时间想"该做什么"。 · 专注范式改变：过去深度开发需要数小时不被打扰；现在 15–30 分钟的碎片窗口就能开工，因为 AI 负责瞬间重建上下文。 · 并行多 MR：用 git worktree + 隔离测试数据库 + "认领机制"（claiming system），多个 AI 会话同时推进多个 MR，互不踩踏。 · 重复任务程序化：如每周 epic 状态汇报，AI 自动拉取数据、对比上周、生成增量报告。 · Token 效率工程化：他甚至为 GitLab API 和 OpenCode 插件贡献了优化代码，并自建本地 MCP 服务器封装常用模式——让工具做数据收集，LLM 只做推理。

五条核心经验

1. 指令要"外科手术式"精确，不要模糊 关键技巧：当 AI 犯错时，不要只纠正它，而是问它"什么指令能防止你下次再犯"，然后让它记下来。久而久之形成一套贴合自己实际工作流的指令集（AGENTS.md 体系），而非泛泛的最佳实践。

2. 并行会话需要"协调原语" 多会话并行的问题本质是经典的并发编程问题：竞态、重复劳动、互相删除。解法也类似——认领/释放（claim/release）、状态追踪、上下文共享。作者为此构建了 opencode-memory：一个持久化语义记忆系统，后来长成包含 76 万+ 代码实体、1.5 万+ 记忆、2.7 万+ 链接的知识图谱，并与 GitLab 官方的 Orbit（SDLC 知识图谱）打通——本地记忆管会话级上下文，Orbit 管跨 SDLC 的全局视图。

3. 动手前先查重 AI 把"从想法到原型"的成本压缩到一周，导致大量人独立造出雷同的轮子（他发现 PyPI 上早有同名包）。他的自省很尖锐：

"我是认真查过是否已有方案，还是 AI 让写代码太容易，以至于我跳过了所有尽职调查？"

能贡献就不要分叉——他选择给 OpenCode 的 GitLab 插件提交改进，非 fork。

4. 从"主动回忆"到"被动上下文注入" 记忆系统建好后的下一步，是让 AI 无需提示就自动想起相关上下文：提到 MR 编号，历史决策自动浮现；准备写评论，评论规范自动加载。30 天内自动注入有效率达 91%，显式调用记忆工具的次数从平均 17 次降到 0。剩余的失败案例促使他加了"启动门"（boot gate）——强制 AI 在动手前先停下来加载指令。

5. AI 仍然做不到的事 全文最有分量的部分。AI 能稳定执行程序、能被要求改进自身指令、能在有原语时协调——但它不会隐式地察觉问题：感觉不到流程别扭，不会意识到"这周第三次踩同一个坑"，没有多年凌晨两点调试生产系统磨出来的模式识别。

作者的亲身案例：AI 热情地构建功能，同时在自己的工具里引入并发 bug、用同步操作把自己阻塞——它毫无察觉。人指出架构缺陷后，AI 几分钟就修好了。模式是：人发现问题，AI 快速执行修复。

底层认知：两层递进

1. 投资工具本身（磨刀）：不要试图安顿进某个"新常态"，工具下周可能就过时。正确姿势是把工作流本身当作优化对象——他为 AI 辅助开发的需要，直接给 GitLab 贡献了新的 API 端点。形成正循环：更好的工具 → 更高产能 → 更多余力改进工具。

2. 代码已成商品，判断力才是报酬来源："我们不再主要靠敲代码获得报酬，要靠知道什么代码应该存在。" AI 放大人的判断——好决策和坏决策都会被放大。Vibe coding 能走很远，但即便经过最彻底的 AI 评审，设计上的质量保障与深思熟虑，AI 尚不能独立提供。