文中数据来源：CodeRabbit 2025.12 / New Relic 2026 报告、Microsoft Work Trend Index 2026、Microsoft FY26 Frontier Firms 公告、GitHub Spec Kit、AWS Kiro、OpenAI Codex、Claude Code、Alibaba Qoder、JetBrains 2026.1 AI Pulse。案例为代表性场景归纳，不指向具体企业。

你最大的错误不是没买工具，是没写 CLAUDE.md

一家股份制银行的 CIO 跟我抱怨：AI 工具买了、模型部署了、人也训了，2026 H1 整半年下来交付周期几乎没动。核心系统组的负责人更直接：”AI 写的代码能用，但每次都要重写一遍——它不懂我们行的规则、不懂监管要求、不懂怎么和那个 30 年历史的老系统对接。”

问题不在 AI 不够强，在于你们没把规则写下来。CodeRabbit 在 2025 年 12 月对 470 个开源 PR 的分析给出了一组被广泛引用的数字：AI 协作 PR 平均含 10.83 个问题，纯人工 PR 6.45 个——1.7 倍，比人工多 70% 的 bug。到 2026 年，故事没有反转：New Relic 在《2026 State of AI Coding Report》里发现，78% 的团队在 AI 代码上线后报告了更多事故，62% 的技术领导者承认他们的团队”自信地不逐行审查就直接发” AI 代码（New Relic 官方报告 2026，0.866 score，一级源）。两组数据说的是同一件事——AI 不缺能力，缺上下文。

2026 年 8 月这个时点，所有”AI 转型加速”的叙事都得放在一组对照里看：

阵营 进展（2026 H1） 反例（2026 H1）
EY Microsoft 365 Copilot 铺到 150,000 员工，节省 250 万小时 / 2.5 亿美元；扩展到 40 万全球员工 同时承认 95% 提速、37% 财务运营成本下降的前提是”规范先行”
Atos 部署到 54 国 / 56,000 员工；同时跑 19,000 个 AI 代理，统一身份/安全/合规/治理控制平面 严守”先把 Agent 365 的治理能力上线、再扩规模”
Microsoft 自身 2026 Work Trend Index：82% 领导者计划 12-18 个月内用 AI 代理扩展劳动力 同期承认”组织变革的节奏落后于个人使用”——这是 Frontier Firm 概念里的核心矛盾

来源：Microsoft FY26 retrospective 2026.7.28；Microsoft 2026 Work Trend Index Annual Report 2026.5.5；New Relic 2026 State of AI Coding Report。

这两组对照说明一件事：没有规范，规模化等于把风险乘以 N。EY/Atos/Microsoft 的”快”不是模型快，是”组织先答完怎么用 AI 的问题”。这是 Spec-Driven Development（SDD，规范驱动开发）在 2026 H1 真正主流化的背景——不是因为工程师偏好文档，是因为不写规范已经无法在 19,000 个代理的环境里活下来。

这篇文章讲清三件事：1）AI 代码的缺陷为什么比人工严重到 1.7 倍以上；2）GitHub、AWS、OpenAI、Anthropic、Alibaba 五家平台在 2026 H1 怎么走向同一个范式——用文档约束 AI 行为；3）规范驱动为什么是组织能力、不是工具选择，以及 2026 H1 的落地三阶段。

AI 代码 vs 人工代码：缺陷分布（470 个开源 PR 分析） CodeRabbit 2025.12 报告｜所有数字为 AI / 人工的倍数比（基准线 1.0）

AI 生成的代码
人工编写的代码

总体问题数（10.83 vs 6.45 / PR） 基准 = 6.45 1.7× 逻辑 / 正确性错误 基准 = 1.0 1.75× 代码质量 / 可维护性 基准 = 1.0 1.64× 安全发现（综合） 基准 = 1.0 1.57× 密码处理不当 基准 = 1.0 1.88× XSS 漏洞 基准 = 1.0 2.74×

没有规范约束的 AI 代码，每个维度都高于人工
金融/电信 = 合规对账、密码管理、敏感字段加密，AI 全都看不到

一、AI 缺陷率不是模型问题，是上下文问题

CodeRabbit 报告里有一句话被反复引用过：**”AI 缺乏本地业务逻辑：模型按统计推断代码模式，而非语义理解。没有严格约束，它们会错过资深工程师内化的系统规则。”**

这句话解释了为什么 CodeRabbit 自己的 AI 编程平台（一个专门做 AI 代码审查的公司）会比别人更早看到这组数据——他们每天看几千个 PR，每天看 AI 写出来的代码长什么样。”最关键”的发现不是总数，是分布：

  • **逻辑/正确性 +75%**：业务逻辑错误、依赖关系错误、控制流错误、配置错误——这类问题在测试里不一定暴露，但会在生产环境导致事故。
  • **代码质量 +64%**：命名不一致、结构不清晰、违反项目模式——这是”最大差异类别”。资深工程师一眼就看出来”这不是我们这儿的写法”。
  • 安全 +57%（XSS 类最高 2.74×）：密码处理不当（1.88×）、不安全的对象引用（1.91×）、敏感信息泄露、不安全反序列化（1.82×）——**在金融行业，这不是”能不能用”，是”能不能发”**。

问题不在 AI 不够强。在于它看不到。

回到那位 CIO 的真实卡点，AI 在金融核心系统的三个具体故障：

第一，AI 看不到 30 年的对账逻辑。 银行的风控规则写在核心系统的存储过程里——30 年前写的，没人记得全。AI 生成的代码逻辑看起来没问题，但在生产环境会触发那条没人记得的对账检查，导致整批交易失败。

第二，AI 看不到合规约束。 密码必须走密钥管理系统、敏感字段必须加密存储、日志不能打印客户信息——这是监管硬约束，写在内部制度里。AI 不知道，写出来的代码能跑但过不了合规审查。

第三，AI 看不到你的技术债。 那个 30 年的宿主系统用的是一套自己的接口协议，文档早就丢了。AI 按通用 RESTful 规范写代码，上线后发现接口对不上——返工两周。

回到 New Relic 的另一组数字：62% 的团队”自信地不审查就发” AI 代码，78% 在上线后报告了更多事故。这两个数字拼在一起，等于在说——AI 代码的缺陷率本身不是问题，”我不知道 AI 代码有什么缺陷”才是问题。

典型场景：某股份制银行引入 AI 辅助开发核心系统的风控模块，三个月内合规审查退回率显著上升，主要问题是密码管理、敏感字段加密、日志合规等内部规则。这些规则都写在内部文档里，但 AI 看不到。后来团队把核心规则写成 CLAUDE.md，退回率明显下降。

二、五大平台的 2026 H1：殊途同归的”规范驱动”

2025 年 7 月 GitHub 发布 Spec Kit，2026 年初 AWS Kiro、OpenAI Codex、Anthropic Claude Code 全部补齐；2026 年 5 月 Alibaba Qoder 把”Spec-Driven Workflow”写进了产品定位。五大平台在 2026 H1 走到了同一个范式——用文档约束 AI 行为。这不是哪一家公司的发明，是行业对”AI 代码质量危机”的集体回应。

五大平台的规范驱动路径（2025-2026 H1） GitHub Spec Kit 开源 2025.9 constitution.md 五阶段门控： constitution → specify → plan → tasks → implement 模型无关，可接 8+ 代理 Claude / Copilot / Cursor / Codex / Gemini / Qwen AWS Kiro Agent IDE 2025.7 spec.md → design.md 三阶段工作流： 需求 → 设计 → 任务 spec-driven 写进 IDE 工作流 钩子触发自动代理 合规/审计钩子预埋 不写 spec 就启动不了 OpenAI Codex 2025-2026 AGENTS.md + Skills 系统 可组合指令集 团队级共享配置 5M+ 周活（2026.6） 非开发者占 20% 从编程走向通用代理 Claude Code Anthropic 2026 H1 CLAUDE.md + .claude/rules/ + Skills（官方市场 2026.2） + MCP 生态 CSAT 91% / NPS 54 $2.5B ARR（2026.2） GitHub 11.2 万 stars Alibaba Qoder 2025.8 → 2026.5 Spec Workflow Quest Mode 自主执行 + Expert Mode 团队 + RepoWiki 上下文 5M+ 全球用户（2026.5） 2026.7.21 Qoder Security 钉钉 CLI 已接入 共同范式：把"我们怎么和 AI 协作"显式写成文档，放在仓库里 让所有人和所有 AI 代理都对着同一份规范工作——这是规范驱动的本质

逐个看每个平台在 2026 H1 的最新动作：

GitHub Spec Kit：参考实现，五阶段门控。 2025 年 9 月开源，到 2026 H1 已经成为行业参考实现。5 个核心命令 + 2 个补充：/speckit.constitution（不可协商原则）、/speckit.specify（要做什么、为什么）、/speckit.plan（怎么改）、/speckit.tasks（拆任务）、/speckit.implement（执行），加上 /clarify 和 /analyze。它的关键设计是模型无关——同一份 spec/plan/tasks 文件不绑定执行代理，Claude Code、Copilot、Cursor、Codex CLI、Gemini CLI、opencode、Windsurf、Qwen Code 都能接。这让它变成了”组织级 SDD 协议”，而不是 GitHub 专属产品（vibecoding.app 评测 2026.6，0.816 score，二级源）。

AWS Kiro：把规范驱动刻进 IDE。 2025 年 7 月发布，2026 H1 演进为完整的 Agent IDE。三阶段工作流：需求 → 设计 → 任务。和 Spec Kit 区别在”钩子”——Kiro 的 spec 文件能触发预定义的代理动作，把合规/审计/部署这类需要外部系统的步骤预埋进工作流。想强制团队写规范，就选 Kiro——因为你不写 spec，Kiro 启动不了（AWS Kiro 官方 2025.7；Kiro.dev 文档 2026）。

OpenAI Codex：AGENTS.md + 可组合 Skills。 2025-2026 把 AGENTS.md 推到生态中央。Skills 是 2026 H1 的关键扩展：把”读 Excel 表””生成 SQL””跑数据迁移”这些工序预拼好，像乐高一样调用。Codex 周活在 2026 年 6 月已破 500 万，其中 20% 是非开发者——这是个被忽略的信号：规范驱动已经不只是工程团队的事，是全员的事，产品、运营、风控都在写 AGENTS.md（OpenAI 2026.6.2 公告；thebcms.com 评测 2026，0.801 score）。

Claude Code：CLAUDE.md + .claude/rules/ + Skills。 Anthropic 把项目指令文档叫 CLAUDE.md（2026 年 2 月进官方市场）、.claude/rules/（按目录分层的规则）、Skills（可共享的工作流）。Claude Code 是 2026 H1 开发者满意度最高的工具——JetBrains 2026.1 调研给的数字是 CSAT 91%、NPS 54，两个独立调研（Pragmatic Engineer 2026.2）一致。这是行业目前 AI 编程工具赛道的最高分（uvik.net 2026.5，0.956 score，一级源汇总）。Claude Code 在 9 个月内从 0 冲到 25 亿美元年化营收（2026.2 Anthropic G 轮口径），GitHub 11.2 万 stars（Skills 仓库）——开发者用脚投票说明了规范驱动的真实价值。

Alibaba Qoder：中国市场的规范驱动。 2025 年 8 月发布，2026 年 5 月 15 日升级到 1.0 版本，正式从”AI IDE”升级为”Autonomous Agent Development Workbench”。它的 Spec-Driven Workflow 是和 Quest Mode（自主多文件任务）、Expert Mode（专家团队并行）、RepoWiki（仓库知识图谱）一起推出的。2026 年 5 月 28 日上线 Cloud Agents（完全托管的代理运行时），7 月 21 日上线 Qoder Security（合规安全能力），同月推出 Mobile 版（Android/iOS/鸿蒙）。到 2026 年 5 月全球用户已超 500 万，钉钉 CLI 把它列为支持的代理执行环境之一（Yahoo Finance 2025；Alibaba Cloud 官方 2026；Baidu Baike 2026.7）。

共同范式：把”我们怎么和 AI 协作”显式写成文档，放在仓库里，让所有人和所有 AI 代理都对着同一份规范工作。 五家平台的实现细节不同（文件名/阶段数/钩子机制），但目标完全一致。

为什么这件事 2026 H1 集中发生？因为 AI 能力门槛已经过去了——Claude Code 自主代理、Codex 多代理并行、Cursor 多文件重构，AI 不再是”补全工具”，是”同事”。你能给新同事的入职文档，必须也能给 AI 看。

三、规范驱动是组织能力，不是工具选择

这是对决策者最重要的一条。规范驱动不是选工具，是定义”我们组织怎么和 AI 协作”。 你选 GitHub Spec Kit 还是 Claude Code 不重要，重要的是你有没有把规范写成文档、放进仓库、让所有人和 AI 都对着它工作。

没有这个，再好的工具也只是让团队用更快的速度造更多的债。

把这件事放到 2026 H1 的规模化部署里看，证据更硬。Microsoft 在 2026 年 7 月的 FY26 retrospective 里，把 EY 和 Atos 两个案例写成”Frontier Firm”模板——不是因为模型新，是因为这两家都先答完”怎么用 AI”的问题：

EY：规范先行，规模化兑现。 EY 在 2024-2025 把 Microsoft 365 Copilot 铺到 15 万人，节省 250 万小时、约 2.5 亿美元。**前提是”AI 治理框架先建好”：EY 用 Power Platform、Copilot Studio、Azure、Foundry、Fabric 做了统一的工具链，把规范/合规/审计放进同一个底座。这才有后面的 95% 提速、37% 财务运营成本下降、最高 90% 的手工工作流减少。EY 的副总裁在 2026 AI Tour 上讲得很直接：“我们不是先铺 AI 再补治理，是先补治理再铺 AI”**。

Atos：19,000 个代理的统一控制平面。 Atos 是全球第一批部署 Microsoft 365 E7（Frontier Suite）的组织，把 Copilot 铺到 54 国 56,000 名员工。同时在跑 19,000 个 AI 代理——从内部 IT、业务部门到客户项目，全在用 Foundry + Copilot Studio 建代理。Atos 把这件事做成的关键是”一个控制平面”：Entra（身份）+ Defender（安全）+ Intune（设备）+ Purview（合规）+ Agent 365（代理治理），五件事绑定在一起。这种绑定方式，对应到金融行业就是”等保 + 数据出境 + 算法备案 + 审计 + 模型治理”，是治理架构而不是单纯的 AI 工具。

Microsoft 自己的”组织变革悖论”。 2026 Work Trend Index 报告里，Microsoft 自己承认了一件事：**”组织变革的节奏落后于个人使用”。他们调研的 20,000 名 AI 使用者里，82% 领导者计划在 12-18 个月内用 AI 代理扩展劳动力，但只有 24% 已经在企业级部署完成。81% 领导者预计 AI 代理会被中等或大量地集成进 AI 战略——但同样只有 24% 已经做到。这意味着绝大多数企业在”准备”和”做到”之间还有 12-18 个月的距离，这段距离怎么填，规范驱动是主要承重点**。

来源：Microsoft FY26 retrospective 2026.7.28；Microsoft 2026 Work Trend Index Annual Report 2026.5.5（assets-c4akfrf5b4d3f4b7.z01.azurefd.net，PDF 一级源）；Futurum Group 2026.1.26 分析（二级源）。

启示一：投资规范是高 ROI。

CodeRabbit 的数据给出了明确的 ROI 计算基础：AI 代码问题率约 1.7 倍、安全漏洞减少 2.74 倍。这意味着：

  • 更少的返工（金融行业一个合规审查返工就是 2-4 周）
  • 更少的安全事故（一个数据泄漏事件的监管罚款、声誉损失）
  • 更低的维护成本（技术债减少 40% 是常见数字）

写一份 CLAUDE.md/AGENTS.md 项目规范，是 AI 时代 ROI 最高的工程动作。EY 的案例给了真实世界的换算——15 万人铺 Copilot，节省 2.5 亿美元。注意 EY 不是因为”工具厉害”省下的，是因为”规范把工具的价值兑现了出来”。

启示二：把规范写进组织流程，而不是依赖个人。

规范如果只存在某个资深工程师的脑子里，人员一流动就丢了。必须沉淀到：

  • 仓库文档（AGENTS.md / CLAUDE.md / constitution.md）
  • CI 门控（自动检查规范遵守情况）
  • 团队共享配置（Skills 系统让全团队能用）

让规范成为组织资产，不是个人技能。这在金融行业尤其重要——你们的合规要求、安全规则、业务规则都是组织级资产，不是某个工程师的”经验”。Atos 的 19,000 个代理能在 54 国跑，因为治理不是”某个人懂”，是”系统强制”。

启示三：门控比速度重要。

GitHub Spec Kit 的五阶段门控（constitution → specify → plan → tasks → implement）、Claude Code 的”测试失败前不写代码”、Kiro 的”不写 spec 启动不了”，都在做同一件事：在 AI 和最终产出之间加”刹车”。每一步都有可审查的产物（spec.md、plan.md、tasks.md），都可以在代码生成前被否决或修改。

自主性越强的 AI，越需要门控。 金融行业的变更审批委员会（CAB）、算法备案流程、等保测评，本质上都是在生产之前加门控。AI 代码也需要类似的门控，只是形式不同。新 Relic 2026 报告里那 62% “自信地不审查就发”的团队，正在用更高的事故率（78%）为这种自信买单。

金融行业规范落地三阶段（2026 H1 实操版） 第一阶段：盘点规则 2-4 周｜最花时间，ROI 最高 合规要求清单（等保/出境/备案） 安全规则（密码/加密/日志） 业务规则（风控/交易/计费） 技术约束（老接口/版本限制） 供应商治理（合同/审计/责任） 把散落在各处的规则 整理成结构化文档 第二阶段：落进仓库 1-2 周｜放进仓库，AI 自动加载 CLAUDE.md / AGENTS.md constitution.md Skills 定义（可共享工作流） 门控流程设计（五阶段） .claude/rules/（分层规则） 把规则放进仓库， AI 自动加载 第三阶段：制度化 持续｜从工具变组织能力 CI 门控（自动审查） 团队共享配置（Skills） 定期更新机制（季度评审） 度量（缺陷率/合规通过率） 代理治理（Agent 365 一级） 规范成为组织资产， 不依赖个人

第一阶段最花时间，但 ROI 最高
大部分金融组织的规则都散落在文档/邮件/人脑里，第一次整理是 3-8 周的投入

四、2026 H1 的真实落地三阶段

以金融行业为例的三阶段路径，其他强监管行业可参考。EY 和 Atos 2026 H1 的实践刚好对应这三个阶段。

第一阶段：盘点规则（2-4 周）。

这是最花时间但 ROI 最高的阶段。把散落在各处的规则找出来：

  • 合规要求：金融业最低基线 = 等保三级 + 数据出境评估 + 算法备案（缺一项就别铺 AI），往上还有监管报送规则、客户信息保护、跨境数据流转限制、哪些数据可以给 AI 看
  • 安全规则：密码管理、加密标准、敏感字段处理、日志要求
  • 业务规则：风控阈值、理赔条件、交易限制、计费逻辑
  • 技术约束：老系统接口、数据库命名、框架版本限制
  • 供应商治理：怎么在合同里要求供应商用我们的规范、怎么审计供应商的 AI 使用

典型场景：某证券公司在盘点阶段发现，规则散落在大量 Word 文档、JIRA wiki、个人邮件、Excel 表格里——整理后才得到结构化的规则清单。Atos 的做法更系统——他们直接把规则按”合规、安全、业务、技术、供应商”五类拆开，每类一个治理工作流，统一接入 Agent 365 的控制平面。

这不是技术活，是组织活——你得把合规部门、安全部门、业务部门拉到一起，把大家都认可的规则写下来。第一次做这个，金融组织通常要 3-8 周——但这是永久性的组织资产。

第二阶段：落进仓库（1-2 周）。

把第一阶段整理的规则写成文档、放进仓库。GitHub Spec Kit 用 constitution.md，Claude Code 用 CLAUDE.md，OpenAI Codex 用 AGENTS.md，Alibaba Qoder 用 Spec Workflow。文件名不同，目标一致——让 AI 在打开仓库那一刻就加载。

结构建议（2026 H1 主流形态）：

  • 项目概述：这个系统是干什么的，服务谁
  • 不可协商原则：安全红线、合规红线、业务红线
  • 技术栈和约束：用什么框架、什么数据库、什么接口规范
  • 代码规范：命名约定、目录结构、测试最低覆盖要求（不强制 TDD 节奏——把测试覆盖率、必测路径、禁区路径写清即可，TDD 是组织可选节奏，不是规范驱动的硬要求）
  • 业务规则：风控逻辑、交易规则、计费规则
  • 合规要求：等保、数据出境、监管报送、AI 生成算法是否需要备案
  • AI 使用规范：什么场景可以用 AI、什么场景必须人工审查、数据出境规则
  • 供应商治理：合同条款、审计机制、责任划分

附录：CLAUDE.md 金融版骨架（约 200 行，可直接 fork 改造）

下面是一份针对股份制银行核心系统改造的 CLAUDE.md 骨架，已按”不可协商原则 → 合规要求 → AI 使用规范 → 业务规则 → 工程约束”的顺序组织。你公司不需要从零开始——把空槽填进你们的具体规则就行。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
# CLAUDE.md — <系统名> AI 协作规范

> 适用范围：<系统名> v<版本>，所有 AI 代理（Claude Code / Cursor / Copilot / Codex）
> 在本仓库工作时必须遵守本规范。本文件由 <治理委员会> 维护，季度评审。
> 最后更新：YYYY-MM-DD

## 1. 项目概述
- **业务定位**：核心系统名 / 服务客群 / 主要交易类型
- **关键链路**：交易 → 风控 → 清算 → 对账 → 报送
- **不可用窗口**：<YYYY-MM-DD HH:MM> ~ <YYYY-MM-DD HH:MM>（任何变更禁止进入）
- **核心依赖**：上游 <系统>、下游 <系统>、监管报送平台

## 2. 不可协商原则（红线，违反即拒绝合并）

### 2.1 安全红线
- 密码、密钥、Token 一律走 KMS（密钥管理服务），**禁止硬编码**、**禁止日志打印**
- 客户敏感字段（身份证 / 卡号 / CVV / 手机号）**必须加密存储**，明文禁止落库
- 日志中禁止出现：完整身份证、完整卡号、明文密码、客户姓名+手机号组合
- 外部接口调用必须经过 API 网关，禁止直连

### 2.2 合规红线
- AI 生成的代码如涉及客户数据访问，必须在 PR 描述中标注 "数据访问：<字段>"
- 跨境数据传输禁止，**所有数据出境需走数据出境评估流程**（联系合规部）
- 算法决策（信贷 / 保险定价 / 反欺诈）必须保留人工复核入口
- 模型变更需走算法备案，备案号必须在 PR 描述中引用

### 2.3 业务红线
- 风控阈值变更需风控负责人 + 业务负责人双签
- 涉及客户资金的操作必须有幂等设计 + 失败回滚
- 交易限额、费率、产品参数变更走参数管理平台，不在代码中硬编码

## 3. 技术栈和约束
- **语言**：Java 17（核心）/ Kotlin（新增模块）/ SQL（数据库）
- **框架**：Spring Boot 3.x + Spring Cloud Alibaba
- **数据库**：OceanBase 4.x（MySQL 兼容模式），**禁止使用外键**
- **接口规范**：内部一律 gRPC；对外接口 OpenAPI 3.0；RESTful 仅限管理类接口
- **命名约定**：Java 类 PascalCase，方法 camelCase，常量 UPPER_SNAKE；表名 `t_<业务域>_<实体>`；索引 `idx_<表>_<字段>_<顺序>`
- **包结构**：`com.<公司>.<业务域>.<子域>.<层>`（如 `com.bank.pay.tx.core.service`）

## 4. 代码规范
- **测试最低覆盖**：核心链路 ≥ 80%，工具类 ≥ 60%，新代码 PR 必须含测试
- **必测路径**：所有 controller 必须有集成测试（含失败路径）；所有 enum 分支必须有单元测试
- **禁区路径**：禁止修改 `<历史包袱模块>` 目录——需先建适配层
- **依赖管理**：新增第三方依赖需走 SCA 扫描 + 安全审批

## 5. 业务规则（按域拆分）
### 5.1 交易
- 单笔限额：<金额>；单日限额：<金额>；超限走人工审批
- 交易时间窗口：<HH:MM> ~ <HH:MM>
- 重复交易判定：<时间窗口> 内同 <字段> 视为重复

### 5.2 风控
- 黑名单匹配优先级：内部黑名单 → 监管下发表 → 司法冻结
- 反欺诈模型输出阈值：<分数>；超过必须人工二审

### 5.3 计费
- 费率变更必须有版本号 + 生效时间
- 历史订单按生效时的费率计算，不回溯

## 6. 合规要求
- 等保三级：<测评机构>，<下次测评日期>
- 数据出境评估：适用范围（仅跨境业务模块）
- 算法备案：适用范围（信贷 / 保险定价等关键算法），备案号 `<编号>`
- 监管报送：<银保监 / 人行> 字段映射表在 `<路径>`

## 7. AI 使用规范
- **可使用 AI 的场景**：CRUD 样板、单元测试生成、文档初稿、SQL 优化建议
- **必须人工审查的场景**：风控逻辑、计费规则、权限控制、加密解密、跨境数据
- **禁止 AI 单独完成的场景**：CAB 审批材料、生产变更执行、应急响应
- **数据出境规则**：训练数据 / 提示词 / 输出日志一律不出境；本地化部署版本（<厂商>）优先
- **审计要求**：所有 AI 生成的代码必须在 PR 描述中标记 "AI 辅助：<工具名>"

## 8. 供应商治理
- **供应商准入**：需提供 SOC 2 / ISO 27001 报告；AI 模型需提供模型卡
- **合同条款**：数据归属、模型可解释性、退出条款、审计权
- **审计机制**：季度供应商 AI 使用审计；高风险供应商月审计

## 9. 治理与更新
- **所有者**：<治理委员会>（合规 + 安全 + 架构 + 业务）
- **更新频率**：季度评审；紧急变更走快速通道（双签 + 24h 公示）
- **变更日志**：见 `CLAUDE_CHANGELOG.md`
- **违规处理**：首次违规 = 警告 + 强制培训；二次违规 = 暂停 AI 工具使用；三次 = 取消权限

这份骨架不是”标准答案”，是”填空模板”。每一条空槽填什么，比写多少字更重要——空白处暴露的，是你们公司”没想清楚”的那部分。

典型场景：某股份制银行的 CLAUDE.md 专门定义了密码处理规则——AI 生成的代码涉及密码时必须调用内部密钥管理 API，禁止硬编码。这类规则在合规审查退回原因中占比很高。

2026 H1 一个重要的新字段是 Skills/工作流定义——不只是文档，是可被 AI 调用的工具链。Claude Code 的 Skills 系统（2026 年 2 月进 Anthropic 官方市场，GitHub 11.2 万 stars）让”读 Excel 表””生成 SQL””跑数据迁移”这些工序变成可共享的工作流。这是规范驱动 2026 H1 的关键进化：规范不只是约束，是可执行的工作流。

第三阶段：制度化（持续）。

规范写完不是结束，是开始。你得把它变成组织流程的一部分：

  • CI 门控集成：自动检查代码是否遵守规范（比如检测密码硬编码、敏感字段未加密）
  • 团队共享配置：用 Skills 系统让全团队能用同一套规范
  • 定期更新机制：规则变了，规范也要跟着变（季度评审）
  • 度量与反馈：跟踪 AI 代码的缺陷率、合规审查通过率、返工率
  • 代理治理：把对人的治理延伸到对 AI 代理的治理——Atos 在 Agent 365 上做的事就是把这个做成”系统级”而不是”个人级”

EY 和 Atos 在 2026 H1 都把第三阶段做成”组织能力”。EY 的 250 万小时节省，归功于第一阶段和第三阶段做对了——第二阶段只是把规则翻译成 AI 能读的文档。

五、强监管变体：合规嵌入的三种工程化做法

金融、电信、医疗这些强监管行业，规范驱动落地比通用行业多一道关——合规不是流程外挂，是代码内置。下面三种做法是 2026 H1 验证过的合规嵌入方式，CIO/数字化负责人在做组织设计时可以直接参考。

5.1 流团队内嵌合规代表：让合规”在场”而非”审批”

传统做法：业务团队写代码，合规团队事后审查——审查发现问题时，代码已上线半个月，返工成本 2-4 周。问题本质是合规在流程末端。

新做法：在每个流团队（stream-aligned team）里嵌入合规代表，形式是”实线在合规部、虚线在业务团队”的双线汇报。具体设计：

  • 人头编制：合规代表每 6-8 个流团队配 1 个，归属合规部门，物理座位在业务团队——不是出差式”借调”
  • 虚线 KPI：合规代表 50% 权重挂在业务团队的”合规缺陷率”和”审查一次通过率”，不是单纯看合规部的”审计覆盖”
  • 前置介入：合规代表参与每日站会（每周 1 次足够）、PR 审查、AI 生成的代码必须在合并前过合规代表——不是合并后被发现再补
  • 工具支撑：合规代表用合规检查清单的 Skills 调用，而不是人工逐条对照

典型场景：某全国性股份制银行 2026 H1 试点 3 个流团队嵌入合规代表，把 AI 代码合规退回率从 35% 降到 8%——核心不是合规”看得更严”，是合规”看得更早”。这种做法的关键是合规代表的虚线激励要对齐业务目标——如果合规代表的 KPI 还是只看合规部给的任务，嵌入就是失败的。

5.2 合规做成 enabling team：把约束变成 affordance

传统做法：合规团队是”守门人”，业务团队把合规看作”麻烦制造者”。双方零和博弈。

新做法：合规团队按 Team Topologies 的 enabling team 模式重构——不直接写代码、不直接审 PR，但提供三件事让业务团队”自助合规”：

  1. CI 流水线内合规检查：把密码硬编码、敏感字段明文、跨境数据传输、算法决策点这些高频合规点，做成 GitHub Actions / GitLab CI 的强制门控。业务团队的 PR 触发自动检查，不合规直接 fail——不需要合规代表人工跑一遍
  2. 监管要求做成 affordance（环境响应式约束）：例如，开发涉及客户数据的功能时，IDE 插件弹出”此字段建议调用 KMS”的提示；写日志时自动检测是否包含敏感信息并报警。**让合规要求变成”开发时自然发生的动作”**，不是”上线前被告知违反了什么”
  3. 共享 Skills 库 + 合规培训：合规团队维护一个”合规 Skills”集合，新人入职 / 跨团队转岗时直接调用——把合规知识从”文档”变成”可执行工具”

典型场景：某城商行 2026 H1 上线 CI 合规门控 + IDE 合规提示，把 AI 代码合规审查的人均时长从 45 分钟/次降到 8 分钟/次，**核心不是合规”审查变快”，是 AI 生成时就”不犯错”**。

5.3 双速合规：分层匹配业务节奏

最后一个细节：合规不要”一刀切”。把规则按风险等级分两档：

  • 高风险规则（涉及客户资金 / 算法决策 / 跨境数据 / 等保红线）走严格门控：必须人工审查 + AI 二次确认 + CAB 备案
  • 低风险规则（CRUD 样板 / 工具类代码 / 文档生成）走自服务门控：CI 自动检查即可，不需要人工审查

Atos 的 Agent 365 控制平面本质上就是这个分层——不同级别的代理绑定不同的治理要求。把合规规则按风险分层，能让业务团队感受到”合规不是处处卡我”。

这三件事合在一起的判断：合规嵌入不是加一道流程，是重新设计流团队的结构和激励。如果你的合规部还在”事后审查”模式，规范驱动落地会卡在最难的”制度化”那一关——合规部需要先转型，业务团队的规范驱动才能跑顺。

六、你可能想问

“我们已经有编码规范了，和这个有什么区别？”

编码规范管的是”怎么写代码”，规范驱动管的是”怎么和 AI 协作”。编码规范不包含：业务规则、合规要求、AI 使用策略。规范驱动是把”人和 AI 协作的全流程”显式化，不是代码风格指南。

“写规范会不会降低开发速度？”

短期会，长期不会。CodeRabbit 的数据给出了明确的答案：无约束 AI 代码的缺陷风险约高 1.7 倍、2.74 倍的安全漏洞。在金融行业，一次合规审查返工是 2-4 周——省一次返工，就够你写一个月的规范。EY 的 2.5 亿美元节省，是把这件事做成组织能力的真实证据。

“我们团队没人会写规范怎么办？”

不需要从零开始。GitHub Spec Kit、Claude Code Superpowers、AWS Kiro 都有模板。你只需要把你们组织特有的规则填进去——大部分是合规和安全规则，这些合规部门和安全部门早就写好了，只是没有放进 AI 能看的地方。

“AI 工具那么多，选哪个？”

不重要。选你们已经在用的。规范驱动不绑定工具——CLAUDE.md 在 Claude Code、Cursor、Codex 里都能用；AGENTS.md 在 OpenAI 生态里能跑；constitution.md 是模型无关的。关键是写规范，不是换工具。EY 在 Microsoft 生态里铺，Atos 在 Microsoft 生态里铺，工具选择的不同只是表面的，治理架构的统一才是里子。

“2026 年 8 月 EU AI Act 全面生效，这对我们有影响吗？”

有。EU AI Act 在 2026 年 8 月 2 日进入全面执行阶段，对高风险 AI 系统（包括信贷、保险定价、就业筛选、关键基础设施）有强制合规要求——风险管理（Art. 9）、数据治理（Art. 10）、文档透明度（Art. 11-13）、人工监督（Art. 14）、准确性/稳健性（Art. 15）。违规罚金最高 3500 万欧元或全球营收的 7%。对中国出海企业，欧盟市场是必答题；对国内企业，EU AI Act 的框架也是全球范围内被参照最多的标准——你可以不直接适用，但你很难绕过它对你的供应商、合作伙伴、跨境业务的传导影响（whisperly.ai 2026；surecloud.com 2026.6；artificialintelligenceact.eu 2026.6）。

“国内对照：欧盟管 AI，我们管什么？”

国内对生成式 AI 的治理走的是”算法备案 + 语料审查 + 安全评估”三件套，2023 年 8 月生效的《生成式人工智能服务管理暂行办法》是核心抓手。两者最大的差异不在条款粗细，而在立法哲学：

维度 EU AI Act 中国《生成式 AI 服务管理办法》
法律定位 横向法规（适用于所有 AI 系统） 纵向规则（聚焦生成式 AI 服务）
风险分级 4 级（不可接受 / 高 / 有限 / 极小） 2 级（涉及舆论安全 / 一般商用）
监管时点 前置（开发即备案） 后置（上线后备案 + 算法备案）
透明度 高（要求公开训练数据来源摘要、模型卡） 中（要求语料合规但不强制披露来源）
罚则上限 全球营收 7% 或 3500 万欧元 暂停服务 / 罚款（通常为违法所得倍数）
适用范围 全球营收门槛内的所有企业 在中国境内提供服务的所有主体

实操上，国内金融机构的 AI 系统通常同时受三套规则约束——《生成式 AI 管理办法》（基础层）+《商业银行互联网贷款管理办法》（业务层）+ 等保 + 算法备案（合规层）。这意味着在国内做规范驱动，不能照搬 EU AI Act 的框架，要把国内”语料合规 + 算法备案 + 监管报送”三条线全写进 CLAUDE.md。

对出海企业：EU AI Act 的”风险管理 + 数据治理 + 文档透明 + 人工监督”四件套是国内监管也在逐步对齐的方向——2025 年网信办的几个生成式 AI 备案反馈已经明显借鉴了欧盟的颗粒度。今天写 EU AI Act 兼容的规范，未来 3 年大概率也兼容国内收紧趋势（网信办备案公告 2025-2026；eu-ai-act compliance 2026.6）。

七、对决策者的启示

启示一：写一份 CLAUDE.md/AGENTS.md 项目规范，是 AI 时代 ROI 最高的工程动作。

它的投入是 3-8 周的整理时间 + 1-2 周的文档时间。它的回报是：缺陷风险上限约 1.7 倍、安全漏洞减少 2.74 倍、返工率下降 40%+。在金融行业，省一次合规审查返工（2-4 周）就够覆盖这个成本。EY 15 万人铺 Copilot 节省 2.5 亿美元，前提是先有规范。

启示二：规范驱动是组织能力，不是工具选择。

你选 GitHub Spec Kit 还是 Claude Code 不重要，重要的是你有没有定义”我们组织怎么和 AI 协作”。没有这个，再好的工具也只是让团队用更快的速度造更多的债。

启示三：把规范写进组织流程，而不是依赖个人。

规范如果只存在某个资深工程师的脑子里，人员一流动就丢了。必须沉淀到仓库文档、CI 门控、团队共享配置、代理治理平台里。让规范成为组织资产，不是个人技能。Atos 的 19,000 个代理能在 54 国跑通，因为治理不是”某个人懂”，是”系统强制”。

启示四：门控比速度重要。

GitHub Spec Kit 的五阶段门控、Superpowers 的”测试失败前不写代码”、Kiro 的”不写 spec 启动不了”，都是在 AI 和最终产出之间加”刹车”。AI 能力越强，治理越要先行。New Relic 2026 报告里那 78% 的事故率，是 62% 团队”不审查就发”的代价。金融行业的 CIO 最懂这个：你们的变更审批委员会（CAB）、算法备案流程、等保测评，都是在生产之前加门控。AI 代码也需要类似的门控，而且必须更前置。

反向自检（回答时别美化）：你们 AI 生成的代码，合规审查是不是经常返工？最近一次 AI 代码导致的问题是什么？如果你问技术负责人”我们怎么和 AI 协作”，他能不能拿出一份文档？三条里有条答不上来，说明规范驱动还没落地——先写规范，再买工具。

给决策者的三个教练提问

最后留三个问题——不是清单，是你和团队讨论时可以直接用：

  1. “如果明天所有 AI 工具下线，你们团队的代码质量会下降多少？” —— 这个问题暴露的是规范驱动的真实价值：如果答案是”显著下降”，说明你的规范还没沉淀下来；如果答案是”几乎不变”，说明规范驱动已经在跑。
  2. “合规部在你们的规范驱动项目里，是’守门人’还是’enabler’？” —— 如果答案是”守门人”，你的落地速度会被审查瓶颈卡住；如果答案是”enabler”，你们已经走对了 5.2 节的路径。
  3. “12-18 个月后，你的团队规模会怎么变？” —— 微软 WTI 2026 的答案是 82% 的领导者会用 AI 代理”扩展”劳动力。如果你的答案是”不变”，要么你的业务没增长，要么你的组织设计没跟上规范驱动的红利。

这三个问题没标准答案。但答案的方向，比答案本身更重要。

下一步

这是”AI 时代软件工程变革”系列的第六篇。从康威（组织决定架构）走到 Team Topologies（怎么设计组织），再到瓶颈转移（瓶颈在验证不在编码），今天讲到规范驱动（用文档约束 AI 行为）。

下一篇（第七篇），我们看支撑这一切的底层基础设施——MCP 协议（Model Context Protocol）：为什么 Anthropic 开源的协议被称为”AI 的 USB-C”，为什么 OpenAI、Google、Microsoft 全部跟进，以及它如何让多工具、多代理的互操作成为可能。

想把这套判断落到你公司？

规范驱动进入企业后，真正需要解决的通常是几个具体问题：核心规则如何沉淀成 CLAUDE.md / AGENTS.md，存量代码怎么补规范，合规嵌入怎么做，以及试点应该用什么指标验收。

目前提供三类合作：

  • 企业内训：结合你公司的真实项目，完成规范文档梳理、CI 门控设计、合规嵌入路径和治理机制搭建。
  • 专项咨询：聚焦一个明确决策，例如”我们公司是否要先写 CLAUDE.md / AGENTS.md”，或存量代码的合规整改优先级。
  • 管理层分享与行业演讲：围绕 AI 编程工具、规范驱动、组织治理和 Frontier Firms 展开。

文章能够提供通用框架。具体落地仍需结合企业的合规要求、监管边界、工程成熟度和现有交付流程重新设计。合作可通过 coach@iaiuse.com 联系。

延伸阅读：《见招牌方法论 v1.0》（慢慢学 AI 187），系统介绍企业 AI 转型的 7 步框架。

关于本系列

“AI 时代软件工程变革”是面向电信、金融、制造、电商等行业 CIO、CDO、CTO 和数字化负责人的研究系列，共 18 篇，重点讨论 AI 编程工具、规范驱动、组织治理如何影响软件交付流程、组织结构和工程成熟度。

系列持续跟踪学术论文、厂商资料和行业报告，研究资料库累计超过 200 篇，并对关键判断标注证据层级，尽量区分已验证事实、厂商主张、行业观察和作者推演。

我有近 8 年大型企业咨询与商业分析经验，曾任职于 IBM，参与过电信、金融、保险和制造业相关项目。此后，我继续在运营商产品、互联网产品和 AI 应用开发一线，从事需求分析、产品设计和跨团队落地。

本系列关于规范驱动、组织治理和工程化的判断，来自这些实践，并结合公开研究和行业案例进行交叉验证。涉及具体项目的内容均已脱敏；部分行业场景属于典型问题推演，相关依据见文末参考来源。

这个号背后其实是一个小团队——我和 1-2 位长期协作的同事，分头负责 AI 编程工具研究、组织治理案例梳理、教练对话这几块。文中”我们陪企业蹚过”的多数项目，是我们几位共同交付过的。涉及客户的合规边界与人名仍然不点名，匿名保留给未来协作同事留出空间。

参考来源（均已核实，逐条标注证据层级）