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
选一个可度量的流程指标做基线

下一篇：未来判断