向更多团队推广

试点之后，什么变了

按《90 天试点》设计的一次好试点，只证明一件事：一种任务类型、一个团队、一个级别，对照一条基线和一条叫停规则。推广会把试点保持不变的一切都成倍放大。在一个团队的维护工作上成立的结果，不会自动迁移到另一个团队的支付服务上；《维护与迁移》展示了同一种迁移在两家公司得出不同的数字。

DORA 在其 AI 能力模型的应用指南里用一句话概括："AI 的采用是一场组织变革。"（"AI adoption is an organizational transformation."）它建议做价值流映射，以确保"AI 带来的效率提升不只是制造出在下游堆积工作的局部优化"（DORA，2025 年 12 月）。二十个团队各自加快自己的编码，加起来可能就是《当代码变便宜，瓶颈就会转移》描述的那条队列。

也要预料到会有一段下滑。DORA 2024 年的报告提醒："实施平台工程举措，可能会在平台成熟、改进显现之前导致绩效暂时下降"（DORA，2024 年 10 月，T2）。下文要求的集中化工作就是平台工作；它先花钱，后回报。

本书的提议是：有三件事必须集中，其余大多可以留给团队自己决定：

• 立场：哪些阶段、哪些任务类型可以在哪个级别运行，上限是什么。
• 来源记录：每一次变更如何记录 AI 做了什么，以及由哪个人为它负责。
• 权限模型：防止任何团队授出超出其级别允许范围的权限的那些管控。

工具选择、提示词和工作流可以留在团队手里。Zalando 的项目是 15.6 节的案例，它说："我们从未在集中层面强制使用某一种工具"（Zalando Engineering，2026 年 8 月）。要集中的是关于权限的规则，而不是工具的品牌。

强制推行，还是讲清楚

大多数负责人在推广时面对的第一个决定，是要不要强制使用 AI。采用率确实是个问题。在覆盖微软、埃森哲和一家《财富》100 强公司共 4,867 名开发者的三项现场实验中，"大约 30–40% 的工程师"连试都没试过这个工具，尽管它无需额外投入，直接接入他们现有的编辑器（Cui 等人，T1，独立性混合；《经济性、风险与度量》解读了它的生产率结果）。光发许可证，换不来采用。

有的公司用强制来回应，有的则用禁止：

• Shopify。CEO 在 2025 年 4 月的内部备忘录中写道："条件反射式地使用 AI，如今是 Shopify 的基本要求。"据媒体概述，员工在申请更多资源之前，必须说明为什么 AI 做不了这项任务，而 AI 能力会正式纳入绩效评估和招聘决策（Digital Commerce 360，二手来源；备忘录原文未能取得）。
• Coinbase。据媒体对 2025 年 8 月一次播客访谈的报道，CEO 解雇了那些在被告知后一周内仍未采用 AI 工具、又没有正当理由的工程师（Tech.co，二手来源）。
• 高盛。其 CIO Marco Argenti 在 2025 年 7 月对 CNBC 说："起初我们会有几百个 Devin，之后可能会到几千个，视用例而定"（CNBC，2025 年 7 月 11 日，经 NBC Chicago 转载）。这是计划，不是结果。
• 三星则走向了另一个方向：据TechCrunch 转述彭博社的报道（二手来源；彭博原文有付费墙，未能阅读），在一个月前发生内部敏感数据泄露到 ChatGPT 的事件之后，三星自 2023 年 5 月起在公司设备和内部网络上限制使用生成式 AI。

这四家都没有公布过交付、质量或事故方面的结果。按《案例研究：谁做到了，测量了什么》的阅读规则，强制令是一项采用政策，而采用数字不是结果。目前没有任何把强制推行与自愿采用放在一起对照的研究。

被测量过的是清晰度。DORA 2025 年的 AI 能力模型发现，"清晰的 AI 立场会放大 AI 对个人效能和组织绩效的积极影响，并能减少员工面对的摩擦"。它还补充："这项能力并不衡量 AI 使用政策的具体内容，也就是说，无论组织持何种立场，都能具备这项能力——只要这个立场清晰并得到传达"（DORA，2025 年 9 月）。

所以，一项清晰的禁令和一项清晰的强制令，都可能在这项能力上得高分。证据奖励的，是人们清楚自己可以做什么。销售度量软件的 DX 立场更鲜明："我们强烈告诫不要自上而下地强制推行，也不要把指标用于个人绩效评估"（DX AI 度量框架，厂商指南）。这是建议，不是测量结果。

本书的立场跟着证据走：把立场写得毫不含糊，而不要依赖强制，因为没有人证明过强制有效。要付出的代价是：光有清晰度，打动不了那 30–40% 从未尝试的人；那需要赋能（15.6 节）。

按级别写下立场

"负责任地使用 AI"不是一个清晰的立场。立场清晰的标准是：工程师面对手头的任务，能回答 AI 能不能做、能做到什么程度、由谁来检查。成熟度模型已经提供了词汇：每个阶段、每种任务类型一个级别，一个风险上限，以及 AI 实际持有的权限。下表是本书的提议，列出一份成文立场应包含什么。《模板》里有一份可直接复制的版本。

有两条规则让立场能够推广。第一，团队靠满足准入条件来升级，而不是靠申请。第二部分的每一章结尾都写明了进入下一级所需的证据，立场只需指向它们。能拿出该级别所要求证据的团队，就能获得那个级别——以 L3 为例：由机器强制执行的路由规则、演练过的回退、智能体无法修改的核验器，以及 90 天的逃逸缺陷对照；拿不出来的就不行，不管发起人职位多高。第二，降级不需要开会。如果某个团队的变更失败率越过了它的触发条件，先降级，再讨论。《衡量成效，以及何时回退》负责写这些触发条件。

把立场写在一页纸上，做版本管理，每次修改都要公告。DORA 测量的是清晰并且得到传达；一份没人读过的政策不算立场。本 Wiki 关于治理实践和问责与角色的条目讨论了归属问题。

按级别划分集中与本地管控

只存在于文档里的立场只是一条指令，而《安全、权限与爆炸半径》已经说明，当智能体手握凭据时，指令值多少。让立场成真的是权限模型。它的管控随级别升高而收紧，由中心决定的部分也随之增多。下面的划分是本书的提议。

每一项集中管控今天都有具体的实现手段：

• 托管设置。Claude Code 允许管理员在托管设置中禁用其绕过模式，"且不能被覆盖"（Claude Code 权限文档，截至 2026 年 10 月）。安全一章的迁移步骤讲了这一点；推广时的要点在于，这项设置要推送到每一台机器，而不是交给各团队自行决定。Nx 恶意软件正是打开权限绕过开关来运行已安装的 AI 工具的，其中包括 Claude Code 的 --dangerously-skip-permissions。
• 对智能体配置做代码所有者评审。Pillar Security 证明，规则文件里隐藏的 Unicode 字符可以让 Cursor 和 Copilot 插入恶意脚本而只字不提，并建议"以对待可执行代码同样的审慎"对待 AI 配置文件（Pillar Security，2025 年 3 月，T1）。把指令文件、规则文件、权限文件和 MCP 配置纳入所有代码库的必需评审。
• 按组织启用。GitHub 写明"Copilot 云端智能体和第三方 MCP 服务器的使用默认是禁用的"，企业所有者可以把策略设为"为选定的组织启用"（GitHub 文档，截至 2026 年 10 月）。用这个开关，只把 L3 工具授予已满足 L3 条件的团队。
• 模型网关。Zalando 通过一个 LiteLLM 代理接入模型，这让平台团队得到"一个衡量采用情况的单一入口：MAU、WAU、模型、User-Agent"，代理服务约 2,000 名月活用户（截至 2026 年 8 月）。对旧客户端，它的做法很直接："对于自行管理的客户端安装，遗憾的是，阻止访问是唯一有效的措施。"网关也是工具审批、模型下线和团队预算得以强制执行的地方。
• 不靠人工填报的清单。Zalando 称，它"通过扫描已部署的 Docker 镜像"自动发现 AI 模型的使用，随后要求负责人补充文档或接受法务审查。本 Wiki 的智能体清单与登记和策略执行条目介绍了这一模式；智能体的策略即代码讲了如何把规则写成机器可检查的形式。

要付出的代价是：集中管控会拖慢最先准备好的团队，每个例外都会变成一张工单。这是为了不让一个尚未准备好的团队手握一张自己都不知道的 L4 凭据而付出的代价——本书里每一起破坏性事故，都是这样开始的。

来源记录：谁为变更负责

当每一次变更都有一部分由 AI 编写，就必须有人能在事后说清楚它写了什么、谁接受了它。开源项目最先、也最公开地面对了这个问题，并分成了三个阵营。

禁止派给出的理由是版权、质量和伦理。对企业来说，第三个阵营是可行的默认选择，而内核的格式最容易照搬。内核文档的"latest"构建（截至 2026 年 10 月）给出的格式和示例如下；7.2 正式版文档用的则是 Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]，所以照搬前请确认你参照的是哪个构建：

Assisted-by: LLM [TOOL1] [TOOL2]

Assisted-by: LLM coccinelle sparse

这个格式仍在变化。截至 2026 年 10 月，同一页面的开发版（linux-next）删去了 Assisted-by 格式，改为指向一份关于工具生成内容的独立文档；那份文档要求在 cover letter 和变更说明中披露，但没有规定标签格式。开发版仍保留"智能体不得添加 Signed-off-by"这条规则。把尾注的语法当作你可以自行确定的部分，把它的原则当作已有定论：AI 要被标注，只有人才能认证。

级别越高，这条原则越难落实。在 L2，每份 diff 都有人评审过，评审者可以签名。到了 L3 和 L4，并不是每份 diff 都有人读过，那么谁来签？内核的规则以人类提交者为前提，所以没有回答这个问题。本书的提议：智能体永远不签名；在 L2，批准变更的评审者签名；在 L3 和 L4，变更附上负责该任务类别路由规则或验证记录的那个人的名字，由此人为整个类别负责。归属标注必须是机器可读的，因为 L3 的准入条件——AI 执行的工作相对人工基线的逃逸缺陷率——离开它就无从计算。《模板》里有来源记录政策，本 Wiki 关于披露与内容溯源的条目讨论了更广泛的做法。

与来源记录相关的许可条款也在变化。微软的客户版权承诺写明，对 GitHub 产品，"自 2026 年 4 月 3 日起，没有额外的必需缓解措施"："获得 CCC 保障不再需要使用重复检测过滤器功能"（Microsoft Learn，页面更新于 2026 年 7 月）。一份 2024 年写成、把该过滤器列为获得赔偿前提的治理清单，在这一点上已经过时。这类易变条款收录在《监管与许可现状（截至 2026 年 10 月）》中；请对照你自己的合同核实。

赋能与平台团队

清晰度告诉人们可以做什么；让那 30–40% 的人去尝试，靠的是赋能。这方面的证据很薄。本书的研究没有找到任何公布过前后对比的采用或结果数据的非厂商赋能项目。唯一有这类数字的项目是 Booking.com 的，但它由其度量厂商发布，且属于观察性数据；《90 天试点》带着这个标注解读了它。描述得最完整的项目，则完全没有数字。

Zalando：不靠强制的赋能 · T3 · 工程博客

Zalando 的智能体工程速写（2026 年 8 月）描述了一个由五部分组成的项目，与 15.4 节中的代理和清单并行：

• 公会：每周一小时的分享会，"每段 20 分钟用于演讲或演示"，全程录像。
• 实验室：每场"约 20 人"的现场课程，时长一到四小时；"三天内我们可以在多个地点举办 6 场，参与者约 120–150 人"。
• 有引导的黑客松：事先选定约十个主题，"在为期 2–3 天、开放报名的黑客松中攻克"。
• 常设培训：每月两场，"使用 MCP 服务器，以及用 pydantic-ai 构建智能体"。
• 技术雷达上的 AI 专栏。

有一条设计规则格外醒目。培训师会"明确说明何时要求学员手写代码"，因为"学员把编码智能体当作捷径来拿结果的诱惑很大"。教人委派的赋能，也可能教会人跳过学习；《人：角色、技能与初级工程师培养》针对初级工程师讨论了这一点。

这个项目也展示了立场如何落地。工具选择留给工程师（"根据可用的模型和他们自己的偏好（IDE 还是 CLI）"），而访问和模型下线则通过中心的代理进行。它的基于风险的评审机器人（见《代码评审》）是同一模式在合并系统中的体现。

它没有说明什么。公会、实验室或黑客松是否改变了采用、交付或质量，以及哪一部分起了作用。这是一个可以照搬的设计，而不是证明该设计有效的证据。

平台本身带有取舍。DORA 把高质量的内部平台列为放大 AI 作用的七项能力之一，但有了它，AI 对受访者所报告摩擦的中性影响"变成了有害"；《AI-SDLC 成熟度模型》解读了这一发现。护栏会增加摩擦。要给平台团队留出预算去消除其他地方的摩擦，也不要把早期的抱怨当成失败。

预算也归平台管。按用量计费而不设团队预算，很快就会出问题。《经济性、风险与度量》讲了 Uber 被报道的超支（T4，二手来源）。一个按团队计量的网关，配上每个团队的结果指标，能让开支成为一项决策，而不是一次意外。

监管与绩效评估

对大多数软件团队来说，监管要求的是素养和文档，而不是禁用编码助手。有两点应写进立场；附有日期的细节见《监管与许可现状（截至 2026 年 10 月）》。

素养义务已经生效。据欧盟委员会，欧盟《人工智能法》对提供者和部署者的 AI 素养义务自 2025 年 2 月 2 日起适用（截至 2026 年 10 月）。像 Zalando 那样的赋能项目，同时也可以作为你采取了措施的记录，所以请保留出勤记录。

让 AI 指标远离个人评估。该法附件三把用于在雇佣关系中"监控和评估人员的绩效与行为"的系统列为高风险（附件三第 4(b) 点，据未来生命研究所整理的合并文本）。AI 驱动的开发者生产率评分是否落入其中，是一个需要法律审查的推断，而不是定论。但实际做法并不取决于法律答案：DX 反对"把指标用于个人绩效评估"的建议，以及它关于"代码生成量这类指标尤其容易被操纵"的警告，指向同一方向。而媒体概述的 Shopify 备忘录，做的恰恰相反。要在团队层面、用流动和稳定性指标来衡量 AI，如《衡量成效，以及何时回退》所述。凡是有职工委员会或工会的地方，在引入任何此类指标之前，都适用本 Wiki 关于员工协商与共同决策的条目。