06 · 组织与流程：怎么落地，而不是发个账号
核心观点
给全员开通 AI 工具 ≠ 完成数字化转型。
没有流程改造的 AI Coding，只是把个人效率差异放大，并把风险从键盘转移到合并按钮。
1. 落地的三个阶段
阶段 A：个人飞轮
- 少数人重度使用
- 产出局部加速
- 规范靠口口相传
风险：影子 IT、密钥乱贴、风格分裂。
阶段 B：团队协议
- 共享仓库说明与提示模板
- PR/评审标准适配 AI diff
- 权限与审计基本盘建立
- 成功/翻车案例沉淀
这是大多数团队应该尽快到达的阶段。
阶段 C：组织能力
- 度量周期时间与逃逸缺陷，而不是「用了多少次 AI」
- 平台组提供内部 agent、知识库、评测集
- 招聘与绩效承认「编排与验证」能力
- 安全/法务/工程形成统一红线
2. 必须先统一的最小协议
- 数据边界：什么代码/日志/客户数据可以进哪些模型
- 权限边界：agent 默认可做什么、不可做什么
- 提交边界：AI 生成内容如何标注、如何验证、谁负责
- 评审边界：哪些变更必须人审关键路径，不能只看 CI 绿
- 事故边界：出问题后如何复盘提示、工具、门禁，而不是只骂人
没有这五条，工具越强越危险。
3. 改造 PR 与评审
建议 PR 描述增加：
- 意图与非目标
- AI 参与程度（探索 / 主要实现 / 仅补测试）
- 验证证据（测试、截图、手动路径）
- 已知风险与未覆盖点
评审清单从「行级洁癖」转向：
- 行为正确性
- 安全与权限
- 数据与兼容
- 可维护性
- 是否可用更小 diff 达到目标
对超大 AI diff：要求拆分，或要求作者先讲设计再看代码。
4. 知识工程比模型选型更重要
组织应投资：
| 资产 | 作用 |
|---|---|
| 架构图与模块说明书 | 降低每次会话冷启动 |
| ADR / 决策日志 | 避免 AI 重复被否决的方案 |
| 可运行的演示与夹具 | 提供真实反馈环 |
| 内部包与脚手架 | 把最佳实践变成默认路径 |
| 评测集（关键场景） | 换模型/换工具时有回归基准 |
| 事故复盘库 | 把痛转化成约束 |
谁掌握高质量上下文，谁的 AI 就更强。
这会成为新的团队护城河。
5. 平台与治理
中大型组织可考虑：
- 统一模型网关（鉴权、审计、限流、数据驻留）
- 内部 coding agent（预装规范、工具、只读生产元数据）
- 密钥与依赖变更的强制策略
- 对高风险仓库更严的 allowlist
- 提示/会话的可追溯（在合规需要时）
避免两个极端：
- 全开放：流畅但不可控
- 全封锁：员工转向个人账号，风险更大
目标是 可控的便捷。
6. 度量什么
少看：
- 生成 token 数
- 接受补全率（单独看会误导）
- 提交行数
多看：
- 需求到合并的 lead time
- 变更失败率 / 回滚率
- 评审轮次与等待时间
- 线上缺陷中「AI 引入且本可测出」的比例
- 开发者主观认知负荷（是否更累）
- 关键模块所有权清晰度
AI 若让人更快却更焦虑、更不敢改核心代码，那是失败的落地。
7. 培训怎么做才有用
无效培训：
- 两小时工具演示
- 「多写提示词」鸡汤
有效培训：
- 带着真实 backlog 结对：从意图到合并走通
- 专门练「审 AI diff」
- 复盘一次幻觉导致的 bug
- 教人写验收标准与最小复现
- 建立内部冠军网络（champions），而不是中心化控一切
8. 招聘与绩效的隐含变化
面试可增加：
- 给定模糊需求，如何写成 AI 可执行规格
- 面对一份可疑 AI diff，如何审查
- 如何设计验证策略
绩效应奖励：
- 稳定交付与质量
- 把个人技巧沉淀为团队资产
- 降低系统风险的行为
而不是奖励「我用 AI 一天提了 20 个 PR」。
9. 反模式清单
- 只发 license，不改评审与测试
- 用 AI 掩盖架构腐烂
- 禁止讨论 AI 失败，导致地下使用
- 让最不了解业务的人制定全公司提示词规范
- 把模型厂商当灵魂绑定，不保留迁移能力
- 用 AI 替代必要的设计讨论
10. 给 Tech Lead 的一周行动
- 选 1–2 个真实仓库写好给人和模型看的说明
- 定数据与权限红线（一页纸）
- 改 PR 模板，要求验证证据
- 组织一次「AI 实现 + 对抗评审」工作坊
- 记录本周三个成功、三个翻车，变成团队 FAQ
- 选一个可度量的流程指标做基线
30 天版勾选清单见：12 · 清单附录 · H。
11. 试点怎么设计才不会变成「体感汇报」
范围
- 1–2 个仓库，2–6 人，4–6 周
- 任务类型先限：修 bug、小功能、测试补全（高风险域后置）
基线（试点前采一周）
- 某类需求 lead time（提出 → 可合并）
- 评审轮次 / 返工次数（能粗估即可）
- 线上/预发因变更引起的缺陷条数
- 开发者主观：认知负荷 1–5 分
过程规则（写进试点说明）
- 必须用意图模板与验证证据
- 允许失败，但失败要记「缺了什么约束」
- 禁止用 token 数或 PR 数当唯一成功标准
结束时只回答四个问题
- 哪类任务明显加速？哪类没有？
- 逃逸缺陷与返工升了还是降了？
- 人是更敢改核心，还是更焦虑？
- 哪些约束应升为全团队默认？
答不清这四题，就还没资格谈「全面推广」。
12. 国内/中文组织的额外摩擦（务实备注）
不涉及特定厂商站队，只标常见卡点：
| 摩擦 | 务实处理 |
|---|---|
| 代码出网与合规 | 分级：公开/内部/机密；网关与合同优先于一刀切禁止 |
| 采购与发票周期长 | 先小范围试用额度 + 评测集，避免未验证就全公司绑定 |
| 需求在 IM 里流转 | 强制「可执行规格进 issue」，否则 AI 与人都在猜 |
| 层级汇报爱看大数字 | 用试点四问替换「提效 XX%」空诺 |
| 安全与工程两张皮 | 红线共写一页纸：数据、权限、事故字段 |
组织能力的护城河仍是：上下文资产 + 门禁 + 责任协议，不是账号数量。
下一篇：未来判断