第 8 章：团队落地 — 把一个聪明工具变成可复用制度
出处
来源：原网页 · 状态：已读 · PDF：book1-claude-code.pdf p.65–71
一句话
团队落地的关键，是先把可接受边界、验证标准和高频工作流稳稳固定下来。 个人顺手不代表团队能稳定复用。目标不是制度越堆越多，而是边界越清楚、系统越可承受。Gate：新人首次使用无需高手旁站，即视为制度成熟。
核心概念
个人技巧之所以有效，恰恰因为它依赖个人持续盯防、背景知识和临场判断。团队一旦接手，不能再假定每个人都知道哪些命令危险、哪些 memory 已经过期、哪些 skill 会 fork 子代理、哪些步骤必须 ask。真正要解决的，是把原来靠高手脑内维持的秩序，压成多数人都能重复执行的工作流。引入 coding agent，既是引入更聪明的补全工具，也是重新安排「谁在什么边界内做什么事」。
第一步：先把最低边界做清楚
多数团队一开始不会先上 hooks、审计链和复杂 skill 目录。更常见的起点只有四件事：
- 哪些任务允许 agent 直接参与
- 哪些改动必须经过人工 review
- 改完至少要跑什么验证
- 哪些资源一律不能碰
边界画错，后面所有自动化都会失真：允许范围没定义 → 拿 agent 做本不该自动化的事；review 责任没定义 → 出问题时没人知道最后一层把关是谁；验证标准没定义 → 系统会自动学会迎合最低标准；禁区没定义 → 效率提升只是扩大事故半径。
现实顺序：先把可接受使用范围讲清楚 → 再把 review 和验证口径讲清楚 → 然后才考虑如何把高频流程复用起来。很多团队最后失败，往往不是因为 agent 不够强，而是因为起步时跳过了这一步。
分阶段落地清单：
- 第 1 周：分层 CLAUDE.md 生效（team / personal / project 三级可验证）；统一验证定义（lint / type / test 命令写进 CLAUDE.md）；禁区写入仓库级硬约束
- 第 2 周：按后果划 allow / deny / ask，Bash 单独规则；首批 ≤3 个 skill，每个有 precondition / postcondition / 可验证产物；定义「完成但带已知问题」的允许条件
- 第 3 周：stop / post-tool-use hook 落地，记录 transcript + task output；stale memory 月度维护；基线复盘（Git diff / PR / CI）无缺口才考虑高阶审计
CLAUDE.md：稳定、分层、少争议
团队级 CLAUDE.md 更适合承载稳定规则，不必把所有流程细节都堆进去。适合：代码库级硬约束（禁止写某类目录、禁止危险命令）；统一验证口径；协作纪律（不要覆盖用户未要求改动，不要在脏工作区擅自 reset）；输出风格（review 先报 findings，再报总结）。不适合：频繁波动的临时流程、只有少量任务才用到的操作细节、本应沉淀成 command / skill / 脚本的步骤。
写成百科全书会同时丢掉稳定性和可信度：成员搞不清哪些是现行规则、哪些是半年前的残留，系统也会学会把过期规范当现行法律。理想状态不是信息越多越好，而是内容稳定、几乎不需要争论。它更像地基，而不是公告栏。
复用的重点：先是验证定义，再是 skill 数量
落地最常见的失败不在 prompt、不在 model、也不在 skill 数量，而在团队对「完成」根本没有统一定义。有人觉得能跑就行，有人觉得测试过一半就行，有人觉得模型解释得挺像样也行——再聪明的系统也只能学会迎合最低标准。Skill 可以复制流程，但只有验证定义才能复制质量。
先写清楚三件事：哪些任务必须有独立验证；验证至少包含哪些动作（测试、运行、日志检查或人工验收）；验证失败时能不能标记为「已完成但带已知问题」。这三件事先统一了，即使一开始 skill 很少，也能先把质量底线稳住。优先级：先统一验证定义 → 再把高频流程沉淀成 skill 或命令 → 最后才考虑更复杂的自动化编排。
Skill 是工作流模块，不是长一点的 prompt
两种误解：当成「长一点的 prompt 模板」，或神圣化成「组织制度切片」。SkillTool 不是提示词仓库：匹配到必须调用、已加载不应重复加载、必要时还会在 forked sub-agent 里执行，自带上下文边界和工具集合。落地时更稳妥的理解仍是「先解决高频任务如何稳定复用」。先答四条：服务哪类任务、默认能动哪些工具、直接执行还是 fork 子代理、调完留下什么可验证结果。答不出，skill 很快退化成名字好听、内容冗长、谁也说不准实际做了什么的半自动口号。
Approval 按风险分层，不按工具名字一刀切
会做 ≠ 应该被允许做。个人往往愿意临场放权；团队里每一步都在移动责任边界。另一个错误：一上来就想设计非常复杂的审批体系，落地成本极高，最后没人执行。
更现实：先按风险分层。读文件、列目录、纯分析通常风险较低；改工作区、改配置、执行写操作明显更高；推 Git、打外网、访问敏感环境再上一个等级。真正要控制的是不可逆性和环境敏感度，而不是按钮名称。边界一旦清楚，自动化才不会在错误的地方放大伤害。
审批规则模板要点：按后果分 risk_tier（read / write / irreversible）；decision ∈ {allow, deny, ask}；不可逆必问；Bash 复合命令超 subcommand cap 不放行；ask 永不自动升级成 allow。
Hook 是高级能力，通常不必作为第一步
Hook 的真正价值：让制度有机会在正确时机发生。例如 instruction file 加载时补充组织级上下文；subagent 停止前补一轮验证；compact 前后记录摘要；session 结束时做归档或清理。有用 ≠ 应该优先引入。
多数普通研发团队更常见的第一步是仓库级说明文件、code review 规则、CI 和测试要求、少量高频命令或 skill。只有当使用规模、风险等级或合规要求继续上升时，hook 才真正有价值；否则带来新的复杂度：脚本没人维护、触发时机没人说清、调试成本反而比人工更高。Hook 适合挂「时点动作」，更适合放在基础治理已经稳定之后再引入。
可复盘轨迹：先基线层，再高阶层
基线层：Git diff / commit、PR 评论、CI 与测试日志、issue 与验收结论——多数团队本就有，也足够支撑日常复盘。高阶层：transcript path、tool 调用记录、hook 事件、compact 前后摘要、子代理 usage 与状态变化。先确认基线层没有缺口。连验证和 review 都没统一就追求全链路审计，治理会做成高成本摆设。基线层复盘是必需品；高阶层审计是高风险 / 高规模 / 强合规团队的增强项。
关键洞察
翻成团队可执行原则：先定义可接受使用范围再谈大规模推广；先统一验证定义再扩 skill；先用 review / CI / 最少说明文件把底线稳住，再引入 hooks 和复杂编排；任何自动化都要能解释做了什么，但不必起手就追求全链路重审计。
源码可迁移的启发：指令先分层，稳定规则和临时流程不要混；skill 适合沉淀高频工作流，前提是适用边界、工具范围和输出物清楚；approval 按风险和环境分层；hook 属于高阶能力；复盘轨迹分层建设。
个人思考
对照 Anthropic AI-native SDLC：人守闸门、循环自己转。这一章把闸门从「产品负责人 / code owner / release manager」落到更细的工程边界——允许范围、验证定义、approval 分层。本仓库的 CLAUDE.md / 技能 / 笔记模板，本质上就是在做「把个人经验压成可重复工作流」。下一章把全书压成十条原则。