AI Native 研发流程：用 AI 的方式，开发 AI
当 AI coding agent 成为团队的主要生产力，瓶颈就不再是模型能力，而是流程本身。Spec 先行、门禁分级、仓库宪法、写保护 hook、度量与自进化——一套让人和 AI 能对齐、能扩展、能持续变好的研发流程设计。
开场：瓶颈不是模型，是流程
一个反直觉的观察：当团队把 AI coding agent 当成主要生产力之后，制约产出的第一件事不是模型够不够聪明，而是流程够不够用。模型写代码的速度以分钟计，团队对齐「到底要做什么」的速度以天计——于是大量时间花在返工上：AI 按字面要求写了一千行，评审时发现方向错了，整批作废，重来。代码产出的瓶颈早就从「写」挪到了「对齐」，而传统研发流程里的对齐机制——口头沟通、IM 讨论、评审会上临时讲两句——全部是为「人写代码慢」的时代设计的，根本喂不饱一个每分钟产出几百行的协作者。
AI 编程时代的流程设计，核心命题只有一个：把对齐成本前置，并且做成机器可读的形式。 这篇文章把这个命题拆成七块——Spec 先行的文档流、分级人工门禁、仓库级规约文件、写保护 hook、绞杀者迁移策略、度量闭环、自进化机制——每一块都来自「用 AI 开发 AI 产品」的真实团队实践，抽象成任何团队都能搬走的方法论。
Spec 先行：文档不是负担，是对齐界面
传统团队里，文档是代码的附属品，写完代码补一份交差。AI 协作团队里关系恰好颠倒：先有 spec（方案），再有 plan（实施计划），最后才有代码。 一个跑了两年、五千多个提交的真实仓库里，方案与计划文档累积了一百一十多篇，评审记录九十多篇——这不是文档癖，是流水线必需的上游工序。
为什么？因为 prompt 是对齐的最差载体：一次性、无版本、不可评审、无法被下一轮会话重新读取。而文档是可 diff、可评审、可被每一轮 AI 会话重新加载的对齐界面。人对 AI 说的每句话都会随会话蒸发，写进文档的每句话都是持久化的上下文。
spec 回答三个问题：做什么、为什么、边界在哪里（明确不做什么，比写什么更重要——AI 最擅长把模糊需求做成过度实现）。plan 回答另三个：分几步做、每步的验收标准、哪几步需要人来确认。
# 方案：订单导出功能
## 背景与目标
- 运营需要按月导出订单明细，当前靠手工跑 SQL，每次 2 小时
- 目标：后台一键导出，10 万行内秒级响应
## 边界（不做什么）
- 不做自定义字段选择（下期）
- 不做定时推送
## 关键决策
- 异步生成 + 对象存储下载链接，不走同步 HTTP 长响应
- 复用现有权限体系，不新建角色
## 验收标准
- 10 万行导出 < 30s；无权限用户请求返回 403
写这份文档要二十分钟，AI 读完它只要几秒。跳过它，AI 会在第三次返工之后「猜」出同样的结论——成本是几小时的错误产出加一轮士气损耗。对齐成本不会消失，只会前置或后置：前置是写文档的二十分钟，后置是返工的两个下午。
门禁分级：把人的注意力分配到风险最高的环节
有了 AI 之后，「什么都人审」和「什么都不审」同样不可行。前者让人成为瓶颈，后者让错误直通主干。务实的设计是分级门禁：
| 门禁 | 审查对象 | 通过标准 | 谁来审 |
|---|---|---|---|
| G0 需求澄清 | spec | 目标、边界、验收标准齐全且无歧义 | 需求提出者 + 技术负责人 |
| G1 方案 | spec 的技术部分 | 架构决策有据、复用现有能力、风险列明 | 架构负责人 |
| G2 代码 | diff + plan 的逐项勾选 | 与 plan 一致、测试通过、无越权改动 | 模块 owner |
| G3 合并 | 完整变更集 | CI 绿、评审记录完整、可回滚 | 维护者 |
门禁不是不信任 AI，是把人的注意力当成稀缺资源来配给。 人的评审带宽是固定的，AI 的产出速度是没有上限的——唯一可持续的策略是让人只看风险最高的环节：G0 管方向（错了全白做），G3 管不可逆（合进主干就成历史包袱），中间的 G1、G2 随着信任累积可以逐步放宽为抽查。门禁的松紧应该是数据驱动的：哪一级拦截率高就保持严，哪一级连续几十次全票通过就降级为抽检。
仓库级规约文件：给每一轮 AI 会话注入的团队宪法
AI coding agent 每次启动新会话，做的第一件事通常是读仓库根目录下的规约文件（AGENTS.md、CLAUDE.md 这类约定俗成的名字）。这个文件的本质，是一份自动注入到每一轮会话里的团队宪法。
它应该写四类内容：
# 项目规约
## 架构地图
- domain/ 领域层：纯业务逻辑，零外部依赖
- app/ 应用层：编排用例，只做胶水
- infra/ 基础设施层：DB、HTTP、消息队列的实现
## 模块边界（硬性）
- 禁止 domain 层依赖 UI 与 infra
- 禁止跨模块直接 import 内部文件，只走 index 导出
## 禁止事项
- 禁止新增依赖而未在方案文档中说明理由
- 禁止绕过统一错误处理直接 throw 裸 Error
## 工作方式
- 改动前先读 docs/ 下对应模块的方案文档
- 任务完成后更新受影响文档
三条设计要点。第一，写「禁止」比写「建议」有效：模型对明确禁令的遵守率远高于对风格偏好的模仿，「禁止 domain 层依赖 UI」能拦住越界，「建议保持分层整洁」基本是废话。第二，规约是活文档：AI 会认真执行过期规则，一条半年前写下的「禁止修改 X 模块」在架构演进之后可能每天都在挡正经需求——规约文件要和代码一样进评审、有 owner、定期重读。第三，规约的篇幅有上限：它是每轮会话都要消耗的上下文预算，写成百科全书的结果是每轮会话先烧掉几千 token 读规章制度，真正重要的条款反而被注意力稀释。控制在一次快速浏览能读完的体量，细节分流到 docs/ 里的专题文档，规约里只放指针。
写保护 hook：硬阻断优于事后 review
规约文件管得住「听话」的部分，但模型在上下文漂移、长会话压缩丢失细节之后，仍可能越权改动。所以第二层防线是硬阻断：用工具调用前的 hook（PreToolUse 这一类机制）在代码层面拦截，而不是指望事后 review 能捞回所有问题。
一个典型设计是写保护分区：
// 工具执行前的写路径拦截
const DEV_MODE_MARKER = ".dev-mode"; // 显式开启框架开发的标记文件
function guardWrite(path: string): void {
const normalized = normalize(path);
if (isFrameworkPath(normalized) && !existsSync(DEV_MODE_MARKER)) {
// 退出码 2 = 硬阻断，工具调用根本不会发生
console.error(`拒绝写入框架目录: ${normalized}`);
console.error("如需修改框架，先落 .dev-mode 标记并走设计评审");
process.exit(2);
}
}
机制上有三个讲究。一是阻断发生在执行前：hook 返回非零退出码，写入根本不发生，不需要事后从 git 历史里翻案。二是例外通道必须显式且留痕：改框架本身不是禁止，是要先落一个标记文件声明「我在开发框架」，配套设计评审加代码评审的双重合并请求。显式成本的存在，让「顺手改一下框架」这种事故在动作发生前就被拦下。三是错误信息要写给人和 AI 双方看：hook 的输出会回到模型上下文，一句「如需修改框架，先落标记文件并走设计评审」既是给值班同学的提示，也是给模型下一步行为的指令——好的阻断信息本身就是引导。
绞杀者模式：老系统迁移的正确姿势
AI 大幅降低了「重写」的成本，也大幅抬高了「一把梭重写」的诱惑。正确姿势仍然是绞杀者模式（Strangler Fig）：新老系统并存，按协议或模块逐个迁移，迁一个删一个。
落到操作上是四条纪律。第一，每类待迁移对象一个迁移计划文档，写清映射规则、兼容策略、回退方案——AI 按文档执行迁移，人按文档验收。第二，并存期容忍重复：新旧两套实现同时存在是迁移的正常状态，不是技术债；为了「干净」而提前删旧实现，等于烧掉回退通道。第三，迁移一个删一个：每完成一个模块就删掉对应旧代码，让剩余工作量和重复面积单调下降，避免「永远迁不完」的僵尸状态。第四，迁移顺序按风险排：先迁低风险、边界清晰的模块建立模式，核心高风险模块留到最后——那时模式已经跑顺，工具链和验收标准都已验证。
这套打法和 AI 天然契合：迁移任务边界清晰、输入输出可对比、验收可自动化，是 AI 协作里性价比最高的任务类型。反过来，「帮我把这十万行老系统重写成新架构」这种无边界的巨型任务，是给 AI 挖坑，也是给自己挖坑。
度量闭环：没有采纳率，一切体感都是玄学
团队对 AI 生产力的评价，如果没有数据，一个月之内就会分裂成两派：一派说「效率翻倍」，一派说「净制造返工」，双方都凭各自的最近三次经历说话。唯一的裁判是采纳率：AI 产出的代码，有多少真正被合并、被使用、存活到了一个月后。
度量要按维度拆开才有信息量：
-- AI 产出采纳率：按作者 × 任务类型拆分
SELECT author,
task_type, -- 新特性 / 重构 / 修复 / 迁移
COUNT(*) AS ai_commits,
AVG(survived_30d) AS keep_rate, -- 30 天后仍在主干
AVG(rework_commits) AS rework -- 合并后 7 天内的返工提交数
FROM ai_attributed_commits
GROUP BY author, task_type
ORDER BY keep_rate DESC;
拆完之后常见的发现是：某些任务类型（迁移、测试补全、样板代码）采纳率八成以上，某些（涉及隐性业务规则的修改）不到三成；不同同学使用 AI 的采纳率能差两到三倍——差距不在提示词技巧，在会不会写 spec、会不会拆任务。这类结论直接指导两件事：把 AI 集中投放到高采纳率任务上，以及把高采纳率同学的协作方式沉淀进规约和模板。
配合采纳率，还要有遥测：skill、工具、hook 的调用埋点上报，回答「哪套流程真的在被用、哪套写了没人跑」。没人调用的流程不是流程，是文档装饰。
自进化：执行 → 日志 → 模式 → 改进
度量告诉你「现在怎么样」，自进化机制回答「怎么持续变好」。闭环是四步：执行留痕 → 日志沉淀 → 模式提炼 → 规约与流程改进。
关键在第三步「模式提炼」：不是读完日志写感想，而是带证据计数的归因。一条合格的提炼长这样——「近一个月某类任务失败 17 次，其中 11 次的共同特征是动手前没读接口定义文档」，于是规约里新增一条「改动接口调用前先读接口定义」，并注明证据。带证据计数的规则是工程结论，不带的是玄学。这类提炼可以定期由 AI 自己跑——让它读执行日志、聚类失败模式、产出规约修订提案，人来评审合入——流程的维护成本也随着 AI 能力水涨船高。
这个闭环和训练一个模型是同构的：日志是数据集，模式提炼是训练，规约更新是发布新权重。区别只是「训练」由人和 AI 共同完成，周期是周而不是月。
协作纪律：上下文与鉴权的两条底线
最后补两条容易被当成细节、实则决定成败的纪律。
上下文不管控等于白搭。 长会话不压缩，模型的注意力被几十轮前的噪声稀释，越到后面越答非所问；任务完成了不清理会话，下一个任务带着上一个任务的残留意图起跑。纪律只有两句话：长会话主动压缩（让 AI 把进展写成结构化摘要再开新段），任务完成就清理会话。模型自己的上下文管理是被动机制，主动管理是流程责任。
鉴权走正规通道。 给 AI 配权限，走正规 SSO、发专用凭证、按最小权限授。不要去抠浏览器 cookie、复用个人会话这类「省事」方案——它绕过了审计、绕过了权限回收，也把账号安全绑在了最不可控的环节上。这类条款值得白纸黑字写进规约：它们正是那种「每个人都觉得自己不会犯」的事故类型。
争议：文档驱动的开销值不值，门禁会不会拖慢节奏
关于文档开销。 反对方的理由很实在：两三个人的原型团队，需求一天三变，写 spec 的速度跟不上推翻 spec 的速度，文档驱动是纯 overhead。这个判断在原型期成立。分歧点在于拐点何时到来：一旦协作人数上去、AI 参与产出，「口头对齐」的成本随人数平方增长，而文档对齐的成本近似线性——文档是唯一可扩展的对齐机制。务实的做法是分级：原型期只写三行验收标准的轻 spec，进入多人协作立刻上完整模板。真正错的是两个极端：原型期搞文档仪式，以及规模化之后还在靠 IM 记录对齐。
关于门禁拖慢节奏。 门禁确实拖慢了写代码的速度——这是设计目的，不是缺陷。算总账要看的是交付正确东西的速度，而不是产出代码的速度。门禁拖慢的是「写」，省的是「返工」；AI 把写的成本压低一个数量级之后，返工在总成本里的占比只会更高，门禁的净收益也随之更高。值得警惕的反倒是另一种失败：门禁齐全但流于形式，评审人一天看四十个方案、两百个 diff，从第二十个开始就在无脑通过——门禁的数量要以人的评审带宽为预算，超预算的门禁等于没有门禁，还额外提供虚假安全感。
常见误区
- 把 AI 当高级 autocomplete：没有 spec、没有门禁，想到哪让 AI 写到哪，产出速度上去了，返工和方向错误的成本涨得更快
- 规约文件写完不维护：AI 会一丝不苟地执行过期的规则，过期规约比没有规约更危险——它把错误包装成「按规矩来」
- 没有采纳率度量：凭感觉评价 AI 生产力，团队内部分裂成乐观派和悲观派，谁也说服不了谁，决策全靠职位高低
- 上下文管理全靠模型自己：长会话不压缩、任务结束不清理，模型注意力被噪声稀释之后，用越来越差的输出质量给整个流程背锅
- 门禁一刀切：所有改动走同一重量级评审，人的评审带宽被打爆之后，审批流于形式，真正高危的改动混在里面被顺手放行
- 重写冲动失控：AI 降低了重写成本，就放弃绞杀者模式搞一把梭，新旧系统切换失败时连回退通道都没有
术语表
| 名词 | 定义 | 一句话直觉 | 常见混淆 |
|---|---|---|---|
| Spec（方案文档） | 动手前定义目标、边界、验收标准的文档 | 先画靶子再射箭 | 不是需求罗列：「不做什么」的边界声明才是核心价值 |
| Plan（实施计划） | 把 spec 拆成带验收点的执行步骤 | 施工进度表 | 不是 TODO 清单：每步要有可检查的验收标准 |
| 门禁（Gate） | 流程中必须人工确认才能通过的节点 | 高速路的收费站 | 不是不信任 AI：是对人的注意力做预算分配 |
| 仓库级规约 | 根目录下每轮 AI 会话自动加载的规则文件 | 团队宪法 | 不是 README：README 给人 onboarding，规约给 AI 行为定边界 |
| 写保护 hook | 工具写入前的代码层拦截，违规直接阻断 | 物理护栏 | 和事后 review 不同：阻断发生在动作之前，不需要翻案 |
| 绞杀者模式 | 新老系统并存、按模块逐个迁移替换的策略 | 藤蔓绕着老树长，长成了再砍树 | 不是拖延：并存期的重复是设计好的状态，迁一个删一个 |
| 采纳率 | AI 产出中被真正合并并留存的占比 | AI 交付的「留用率」 | 不是生成量：生成快不等于有用，合并且存活才算数 |
| 遥测 | 对流程与工具调用的埋点上报 | 流程的心电监护 | 不是监控人：度量对象是流程的运转，不是个人的产出排名 |
| 自进化 | 从执行日志提炼模式、回流成规约改进的闭环 | 流程自己的训练循环 | 不是复盘会：复盘出感想，自进化出带证据计数的规则 |
| 上下文压缩 | 把长会话历史浓缩成结构化摘要再继续 | 换班交接日志 | 不是删历史：压缩是提炼交接，不是丢失信息 |
参考材料
- Building effective agents — Anthropic — Agent 工程实践的经典总结，流程与编排的设计原则
- 12-Factor Agents — 人与 AI 协作的十二条工程原则，门禁与上下文管理两节和本章直接相关
- AGENTS.md 规范 — 仓库级规约文件的开放约定，「团队宪法」一节的标准出处
- Strangler Fig Application — Martin Fowler — 绞杀者模式的原始定义
- GitHub Spec Kit — Spec-Driven Development 的开源工具链，spec → plan → 实现的工业化样板
- OpenTelemetry GenAI 语义约定 — AI 调用遥测埋点的字段标准
小结
一句话收束：模型能力决定 AI 能写多快，流程设计决定团队能走多稳。 展开是七件事：Spec 先行把对齐成本前置，门禁分级把人的注意力投到风险最高的环节，仓库规约给每轮会话注入团队宪法，写保护 hook 用硬阻断守住边界，绞杀者模式让迁移进可攻退可守，采纳率与遥测让评价有数据，自进化闭环让流程自己会变好。这套流程的元特征是——它本身也是为 AI 可读、AI 可执行而设计的：文档是结构化的上下文，规约是可执行的指令，门禁是明确的协议。用 AI 的方式设计研发流程，才能让 AI 的生产力真正兑现为团队的交付力。