S24-A04 · AI 工具的团队落地：许可、度量与阻力

工具买回来三个月，后台统计显示只有三个人在持续使用，其中两个只是偶尔问问题。这不是工具不好用，而是**“能用”和“进入日常流程”之间隔着两道墙**：流程没接上，组织习惯没形成。落地是组织工程，技术选型只是起点。

1. 三层落地与卡点识别

层次	达成标志	未达成的表现	识别方法
工具可用	账号、网络、IDE 插件就绪	有人装不上、被代理拦	抽样问“昨天用过吗”
流程接入	评审、测试、提交环节含 AI 产物	生成的代码被特殊对待或偷偷改	看 review 记录与 CI 日志
组织习惯	遇到问题先想“这件事能否委派”	只在赶工时用一次	看非紧急需求里的使用比例

判断卡在哪一层，最快的办法是问三个人上一条命令什么时候跑的：答“装的时候”= 第一层；答“写 demo 时”= 第二层；答“昨天的需求里”= 第三层。

卡点问诊清单（逐层打勾，第一个否即定位）
1 是否所有需要的人都有账号且网络可达
2 是否有明确说明哪些仓库/文件不许外发
3 试用者的产出是否走过正常评审
4 是否有可复用的提示/案例沉淀
5 是否有人在 review 时特别审 AI 产物

第一层没通就谈度量，等于统计一个空集。

2. 该不该允许：判据与分级

判据	要回答的问题	常见结论
代码外发风险	请求会不会带业务代码出去	敏感仓库禁止，其余按文件类型分级
许可证合规	生成/补全片段是否可能命中 GPL 类代码	需法务口径，不能由开发者自判
生成物归属	产出物能否被公司主张权利	依服务条款，须书面确认
审计要求	是否需要留请求与产出记录	需要则禁止个人账号，统一入口

分级策略的关键是给出白名单而不是黑名单：说清哪些仓库放开、哪些文件类型禁止（密钥、配置、客户数据样本），比笼统的“注意保密”可执行得多。

# 仓库分级占位（放进仓库根目录或集中配置）
tier: A            # A 放开 / B 仅对话式 / C 禁止
deny_paths:        # 任何级别都不外发
  - "**/secrets/**"
  - "**/*.pem"
  - "config/prod/**"
deny_filetypes: [".env", ".sql", ".csv"]
review: "所有 AI 产出必须走标准评审"

3. 度量指标：采用率之外的三个数

指标	定义	常见失真
采用率	周活人数 / 目标人数	登录即算，虚高
有效使用率	有产出被采纳的会话占比	需埋点，多数工具给不出
返工率	AI 产出被返修的比例	与任务难度相关，不可跨团队比
周期时间	需求从开始到合并的时长	受评审排队影响，单看会误判
代码行数	生成行数	最不该用的指标，鼓励多写不等于写好

{"metric":"ai_session","user":"U","repo_tier":"A","suggestion_accepted":true,
 "rework":false,"task":"BUGFIX","cycle_hours":13.5,"week":"W"}

三条纪律：指标按任务类型分层（修 bug 与写新功能不可比）；只看趋势不看绝对值；绝不把采用率当 KPI——一旦考核，人会刷会话数，指标立刻失去信息量。

4. 效率收益的真实来源

收益来源	典型量级	可度量性
减少搜索与查阅（API、写法、报错含义）	明显	中：可看会话类型分布
减少样板代码（CRUD、测试骨架、胶水）	明显	高：看生成后接受率
加快不熟悉语言的起步	中等	低
替代思考与设计	几乎没有	—

不可度量的部分往往是大头：认知负担下降、上下文切换减少。这些收益可以通过访谈与“最烦的事是否变少”来近似，不要硬凑成数字。

5. 抵抗的三种来源

来源	真实诉求	有效应对	无效应对
不信任产出	怕背锅、怕出线上问题	明确责任仍在提交者，评审标准不变	反复讲模型多强
怕被替代	需要安全感与角色定位	说明角色转向判断与验证	强调“效率提升多少倍”
学习成本	时间被挤占	给小而具体的上手任务	发文档让人自学

最常见的错误是把抵抗当态度问题处理。抵抗多数是流程缺位的信号：如果评审标准对 AI 产出没有说法，谨慎的人自然会选择不用。

6. 试点到推广的节奏

试点章程（占位模板）
范围    1 个团队 / 1 个仓库 / 8 周
目的    验证“能进流程”，不验证“能提效多少倍”
成功标准 3 条，且必须可观测：
  a 该仓库的评审与 CI 全绿率不低于试点前
  b 团队自己写出 5 条以上可复用提示
  c 无一次因 AI 产出导致的线上问题
观察项  周期时间、返工率、访谈印象（仅参考）
终止条件 触及合规红线或成功标准 a 不达标

节奏上，先选“有痛点、能说话、不算高风险”的团队，而不是最先进的团队。推广阶段把试点结论变成默认做法（模板、检查表），而不是靠宣讲。

7. 知识沉淀

ai-assets/
  prompts/      # 按任务类型的提示模板，带适用条件与反例
  cases/        # 真实案例：任务、输入、产出、返工点
  checklist/    # review 关注点（安全、错误处理、依赖引入）
  changelog.md  # 提示与清单的版本变更记录

沉淀的判断标准只有一个：新人能否照着做出同样质量的结果。只保存“好用的提示词”而没有适用条件，等于制造更多幻觉。

8. 与既有工程流程的冲突

冲突点	表现形式	处理
评审标准	“这不是你写的，所以我更严”	统一标准：产出物一视同仁
测试要求	生成代码缺测试仍被合并	覆盖率门槛对来源不区分
文档规范	注释/提交信息变成模板腔	提交信息规范里明确要求
依赖引入	模型推荐了新库，绕过选型流程	依赖变更仍走统一审批
知识产权	出处不明片段进主干	大段粘贴类产出必须能解释

冲突的本质是既有流程没写“来源”这一维度。补一条“来源不影响标准”的规则，比新造一套 AI 专用流程更省事。

9. 成本核算

成本项	计价方式	常被漏掉的部分
订阅/席位	按人/月	只买不用照样付
算力/令牌	按用量	长上下文与批量任务
返工	人力时间折算	最难估，却是主要成本
培训与沉淀	人力时间	提示库与清单的维护
合规与审计	一次性 + 持续	统一入口的建设

总成本 ≈ 席位费 + 令牌费 + 返工人力 + 培训与维护人力
判据：返工人力与培训人力若长期为零，说明要么没人用，要么没人在看

10. 明确不适用的场景

场景	原因
合规敏感代码（密钥、支付、隐私数据）	外发与审计不可控
老旧遗留系统	上下文难给全，模型给出的“最佳实践”与现状不符
强实时与嵌入式约束	需要精确控制内存与指令，生成物常不可用
一次性关键决策（架构、数据迁移）	判断责任无法委托
团队自己都没写清规范	先有规范，再有自动化

11. 失败复盘的常见结论

1 没有明确允许范围 → 谨慎的人选择不用（第一层卡住）
2 没有一条流程真正接上 → 使用停留在个人摸索（第二层卡住）
3 度量选错（行数） → 数据好看但没人信
4 变成绩效指标 → 数据失真，讨论变成博弈
5 试点团队选错（高风险）→ 一次事故否掉全部尝试
6 只有工具没有沉淀 → 换一批人重头踩坑

12. 排错

现象	可能原因	处理方向
只有少数人用	允许范围不清	出白名单 + 禁止清单
用了但不进主干	评审标准模糊	明确“来源不影响标准”
数据好看但团队无感	指标与体验脱节	更换指标，访谈校准
一有人反对就停	抵抗被当态度问题	把诉求翻成流程改动
换人后效果消失	无沉淀	建提示库与案例库
成本超预期	未统计返工	把返工纳入核算

13. 边界

场景	判断
团队小于五人	不必搞流程，直接约定范围即可
管理层不投入	落地必然停在第一层，别先买工具
度量被当 KPI	指标立刻失真，宁可不度量
已有严谨评审流程	只需补“来源”维度，不新增体系
团队工程规范尚未建立	先建规范，再谈 AI 接入

14. 自测

怎么判断团队卡在“工具可用”还是“流程接入”？
为什么“代码行数”是最不该用的度量？
抵抗情绪背后常见的真实诉求是什么？
试点章程里的成功标准应该包含什么？
知识沉淀到什么程度才算有效？
什么情况下买工具本身就是错的顺序？