Google 白皮书解读：SDD 之后的团队文化与流程演进

Google 官方「5天 AI Agents 课程」

第 5 份白皮书「Spec-Driven Production Grade Development in the Age of Vibe Coding」，其中一章「Team Culture & Process Evolution」，咱们重点看看，它讲述了 SDD 和规格编写规则之上，团队文化与流程演进会遇到的问题，以及要怎么顺应 AI 发展去解决。
https://drive.google.com/file/d/1lCx0Lh06sK6j59nTNc_pYRdnoxgDtJcn/view

Google 认为，把现代 Agent 塞进旧研发流程 = 给马车装喷气发动机。工具提速后，协作摩擦被等比放大成瓶颈！

三种新问题
1. 合并冲突倍增：产出越快，同文件提交冲突越多
2. 评审死锁：巨型 PR 拆成套娃式依赖链，卡在跨时区评审者手里
2. 上下文碎片化（AI 特有）：Agent 拿着过期快照，写出调用“已不存在函数”的代码，编译前毫无异常

五项应对策略（共同方向：人的注意力从“行”上移到“架构”）
1. PR 附 AI 生成的变更摘要 + 风险评估：评审者先看架构影响，再决定是否下潜
2. 重构评审所有权：代码是一次性易耗品，风格 nitpick 交给 linter；人只审架构蓝图
3. Conditional LGTM：批准以测试全绿为条件，绿灯自动合并，消灭跨时区等待
4. 无责文化：事故归因于破损的流程，而非产出最多的个人（否则惩罚机制会精确打击你最能干的人）
5. Agent 评审 Agent：用 skill 自动做代码评审，GitHub Actions 全自动触发

更根本的追问：还需要团队吗？
一个人带一队 Agent，团队的必要性被动摇。Google 认为：若保留团队，就按“人几乎不碰同一批文件”来设计；API 与 UX 清晰分权，必须重叠时由指定的“部分所有者”做最终同步。代码冲突管理从技术问题升格为组织设计问题。

持续评审 Agent 三个档位
Tier 1 托管型：SaaS 评审器，分钟级启用，但标准是厂商的，会漏掉你的特定风险（如 HIPAA、PII 合规模式）
Tier 2 混合型：GitHub Action 跑你自写的 review skill，多数团队的最佳起点，运行时归 CI，评审标准归自己
Tier 3 定制型：ADK agent 部署到 Agent Runtime，挂 webhook 监听仓库。适合需要跨 PR 记忆（贯穿多次提交的大重构）或任务分解的场合，代价是自担评估、可观测性和值班

选型三问：评审标准多特定？要不要跨 PR 记忆？出错最坏后果是什么（合入回归或泄密 → 必须 Tier 3 并前置 Policy Server）。

案例：金融科技团队用 Tier 1 时，通用评审者标记审计员已放行的样板代码，却漏掉日志中未脱敏的 PII；换成一个 40 行的 Tier 2 skill，一周内误报锐减。多数团队的档位，是在被通用评审者漏掉关键问题的那一刻才确定的。

Tier 3 完全体：图原生代码理解，在亿行级遗留代码上，把代码、文档、工单、设计 PDF 摄入知识图谱，组合图遍历（结构查询）、向量检索（语义查询）、全文搜索（标识符匹配）三种检索，回答“改这里会破坏什么”；再配 Search → Story → Impact → Task-breakdown → Coding 的子 agent 流水线做任务分解。必须用图谱的原因：标准 RAG 会压平代码的结构关系（类属于文件、调用追溯到十年前的需求文档），“压平进向量库，地图就没了”。西门子生产试点把等价重构从两周压到几小时。定义：Tier 3 不是盯着 PR 的 agent，是理解 PR 所在系统的 agent。