主题
三代范式与企业架构
一句话：AI Coding 的演进不是模型突然变强，而是把“人负责的那一段”不断往外推——补全把敲键盘交给 AI，Agent 把执行交给 AI，SDD 把流程编排和验证门禁交给系统/代码、人保留方向性决策与签字；每推一层，产出上限更高，纠错成本也从“改一行”变成“改一份规格”。
适用：2026 年主流 AI Coding 工具。三代的时间划分是粗略口径，不同团队进入某一代的时间差异很大。
为什么需要
只上补全的团队，复杂任务仍要靠人拆成几十个片段；直接上 Agent 的团队，常见的是任务跑偏、diff 越改越大、没人敢合；再往上堆工具，又会出现密钥散落、模型成本看不见、每个仓库一套规则。问题不在工具少，而在用同一种自主性去覆盖风险完全不同的任务。企业真正需要的是两件事：一个按任务复杂度切换范式的路由，一套让自主性可以被放大的底座（身份、成本、权限、审计、知识）。前者决定“用哪一代”，后者决定“敢放多开”：少了前者，简单任务被流程拖死、复杂任务被随手放过；少了后者，任何一代都只能停在个人玩具阶段。
核心机制
第一代：补全，把“写”变成“选”
痛点是样板代码多、API 记不住、边查文档边敲。补全的做法是让 IDE 把当前文件、邻近文件和注释一起喂给模型，实时预测下一段，人按 Tab 接受或继续打字拒绝。它只解决了“局部生成”，因为模型看到的上下文就是局部的：跨文件的接口一致性、分层约束、历史决策都不在视野里。但它换来了极低的风险——代码最终由人敲进仓库，人仍然是执行者。代价是复杂任务必须由人先拆解，AI 只负责其中最小的那一块。
第二代：Agent，把“执行”也交出去
补全解决不了“改五个文件、跑测试、根据报错再改”。Agent 接收一个任务描述后自己规划步骤、读写文件、执行命令、跑测试、修正，最后交一个 diff 或 PR。关键因果是：能执行，就意味着错误也会被执行。补全写错只是屏幕上多一行，Agent 写错可能改错文件、删错数据、跑危险命令。所以 Agent 的自主性和它的安全面是同一件事，必须同时给出沙箱、最小权限、命令白名单、变更上限，否则效率提升会被一次事故抹平。
人的角色从“写”变成“审”，审查负担因此集中。Agent 能不能自我修正，取决于仓库有没有可执行的反馈回路：测试、类型检查、lint。没有这些，它只能靠语言模型猜自己对不对，“自修”很快变成反复改同一处。
第三代：SDD，把“流程与验证”交出去
Agent 的失败模式是需求漂移和不可追溯：它说“做完了”，但没人能证明做完的是不是要的。SDD（Spec-Driven Development，规格驱动开发）把结构化规格作为唯一真相，按 Specify → Plan → Tasks → Implement → Verify 推进，每阶段有产出物，验证不通过不能进入下一阶段。它没有让模型更聪明，而是缩小了搜索空间：先把“做什么、验收是什么、不做什么”钉死，再让 AI 在范围内执行，错误会更早暴露。需要说清楚的是，SDD 对缺陷率的收益目前缺乏一致的同行评审证据，不要把“上 SDD 就降缺陷”当成承诺；它可确认的收益是可追溯与协作。代价是前期要写规格、要评审、要维护；更贵的是规格写错会把错误放大到整条流水线，而且小改动走完整流程通常净亏。五阶段的具体做法见 03-SDD规格驱动。
每一代的驱动力都是上一代暴露的失败模式，不是参数规模变大。两条虚线回流说明它们不是替代关系：同一个团队里，改一行仍然用补全最快，验收清晰的小任务用 Agent 最划算，只有需要对齐和追溯时才值得上 SDD。
三代对比
| 维度 | 第一代 补全 | 第二代 Agent | 第三代 SDD |
|---|---|---|---|
| 抽象层级 | 代码行 / 函数 | 任务 / 功能 | 规格 / 项目 |
| 人的角色 | 写代码，AI 辅助 | 审代码，AI 执行 | 定规格与验收，AI 工程化 |
| AI 自主性 | 低，只提示 | 中，可读写与执行 | 高，但在流程与门禁内 |
| 主要风险 | 片段不一致、架构盲区 | 跑偏、误改、成本与权限 | 规格错误被放大、流程成本高 |
| 适合团队 | 个人 / 小团队 | 小 / 中团队，仓库有测试 | 中 / 大团队，需审计与协作 |
| 质量保证 | 开发者逐段把关 | 开发者 CR + 测试 | 自动化门禁 + CR |
企业级六层架构
- 接入层：IDE 插件、CLI、Web 统一入口与身份。没有它，员工各自购买工具、密钥散落，出了事查不到人。
- AI 网关：模型路由、限流、预算、内容安全。没有它，模型密钥下发到每台电脑，成本不可见，换模型要全员改配置。
- 能力层：补全、Agent、SDD 三种引擎共存，并按任务自动路由。只有一种引擎，简单任务被过度流程化，复杂任务又缺少约束。
- 工具层：用 MCP 等标准协议接代码库、CI、数据库、工单，统一权限与审计。没有它，每个 Agent 自己写脚本接系统，权限失控且重复建设。
- 治理层：质量门禁、SAST/SCA、合规审计、效果度量。没有它，AI 的产出速度会超过人的审查能力，风险在合并后集中爆发。
- 知识层：AGENTS.md、编码规范、架构决策记录（ADR）。没有它，每个会话都要重新解释项目，输出风格随人漂移。
实线是请求路径：身份先于模型调用，模型选择先于任务执行，工具调用必须经过统一权限。虚线是横切注入：知识层决定 AI 知道什么，治理层决定它的产出能不能进主干。治理和知识如果等到工具全部接完再补，成本会高一个量级（经验值），因为每个接入点都要返工。所以企业的答案不是三选一，而是按任务切换：能力层把“改动范围、风险等级、验收能否自动判定”做成默认路由，而不是让每个人凭喜好选工具。
范式选择
先问三个问题：改动跨几个文件或模块？验收能不能用命令判定？出错代价有多大？三个答案组合起来，范式基本就定了。
| 任务特征 | 推荐范式 | 判据 |
|---|---|---|
| 单函数、正则、SQL、样板代码 | 补全 | 范围局部，人一眼能判断对错 |
| 明确 Bug、补测试、单模块功能 | Agent | 范围可界定，仓库有测试 / lint 反馈 |
| 新模块 0→1、跨模块重构、需审计 | SDD | 需求要先对齐，且必须可追溯 |
| 迁移、权限、计费等高危改动 | SDD + 人工门禁 | 出错代价高，必须可回滚、可复核 |
一句话：局部改动用补全，边界清晰的任务用 Agent，需要先对齐再执行的工程用 SDD。拿不准时从低一代开始，卡住了再升级，比一上来就上重流程便宜。
实战场景
事故复盘：对话编程的三天之痒
一个 40 人的支付团队，6 名开发者第一次在支付模块（约 8 万行、五年历史、仓库里并存三代代码风格）上批量使用 Chat 式工具。第一天做手续费计算重构，AI 一次给出干净产出、测试通过，团队准备上报“提效一倍”。第三天改退款流程合并后，线上集中暴露三类问题：
| 故障现象 | 直接根因 |
|---|---|
| 上游对账服务解析不了错误码，告警漏报 | 模块长期使用 5 位数字错误码加映射表，AI 新造了一套字符串风格错误码 |
| 预发环境 ORM 映射报错，开发环境正常 | 新字段用 refundAmount，既有约定是 refund_amt，隐式映射在本地侥幸通过 |
| 生产慢查询突增 | service 层直查数据库绕过了 repository；老代码里两种写法并存，模型学到了较新的违规样例 |
三天退化的时间线：
text
D1 手续费计算重构：一次通过，测试全绿，当天合并 2 个 PR
D2 退款流程改造：同一会话连续追问 4 轮，diff 从约 120 行涨到 400 多行，越改越不像要的东西
D3 合并后 48 小时内集中爆雷：对账解析告警、预发映射报错、生产慢查询突增代价：两次热修复加对账数据回填，一个上线前一周的功能变成两周返修。复盘时定位到共同根因：三条约定都是真实存在的，但不存在于模型看得见的任何地方——模型能看到的只有会话里注入的代码，而命名、分层、错误码规则活在资深工程师的脑子和没人维护的 Wiki 里。代码库越大、历史越长，上下文窗口之外的隐式约定就越多，每轮生成破坏其中一条的概率越高。这不是模型能力问题，而是视野问题：生成再强，对看不见的约定只能猜。
团队后续路径正好对应本文三代演进的因果链：先把可判定的约定沉淀为仓库内 AGENTS.md（知识层要进架构的原因）；核心模块的小改动退回补全模式，人逐段接手，约定顺手就被校验；跨模块改动升级 Agent，并挂上可执行测试与 diff 范围检查两道门禁；需要跨角色对齐“做完了是什么”的改动，才用规格先钉死。往规格化和 Agent 化走的原因是对话编程的错误不来自生成能力，而来自不可见的约定：规格和规则文件把约定搬进模型视野，门禁和自证把验证挪到合并之前。
场景：一个团队该停在哪一代
“我们该用哪一代”没有标准答案，正确的问题是“每类任务停在哪一代”。一家中型 SaaS 公司半年的实际分配（经验值，需按团队校准）：
| 任务类别 | 典型例子 | 使用范式 | 判据 |
|---|---|---|---|
| 一次性 | 修数脚本、日志解析、临时迁移 | 补全/手写 | 错误代价低，人一眼能判断对错；套流程纯亏 |
| 迭代特性 | 列表加筛选、接已有 SDK、补测试 | Agent | 验收可用测试加 lint 判定；独立分支上错误可回滚 |
| 核心模块 | 计费逻辑重做、状态机变更、跨服务接口迁移 | SDD + 人工门禁 | 错误代价直达生产；隐式约定多，必须先对齐且可追溯 |
判据只有两个维度：错误代价与可验证性。错误代价低、验收容易判定的，停在低一代；错误代价高但验收可自动判定的，用 Agent 加门禁；错误代价高、且“做完了是什么”需要先对齐的，才值得付 SDD 的规格成本。同一个团队对不同任务同时停在不同代，这正是企业六层架构里能力层写“三种引擎共存并按任务路由”而不是“全员最新一代”的原因。拿不准从低一代开始，卡住再升级，是范式选择一节“从低一代开始”的实操依据。
事故复盘：没有反馈回路的 Agent 自我修正
一支团队把 Agent 放进测试几乎没有的内部工具仓库修一批导入错误。Agent 每次改完只跑启动脚本，看报错消失就停。两天内它在同一个配置解析函数上循环了 7 轮：先改成吞掉异常的 try/except，再改成给默认值，再改成打印错误后继续执行，最后一轮改回了原始写法；token 消耗涨了一个量级（经验值，基线需按团队校准），合进去的代码“能跑”，但错误处理语义已经全错，真正的配置缺失被静默放过了三个月，直到一次凭证轮换才暴露。
这正是 Agent 一节那条因果的现实版：能自我修正的前提，是仓库里有可执行的反馈回路。没有测试、类型检查和 lint，“对不对”就只能由模型用语言自己定义，它自然退化成“不报错就行”，自修随之变成反复改同一处。修复顺序不能反：先给配置解析路径补冒烟与特征测试（characterization test），把现有行为钉死，再放 Agent 进去自修；同时给单任务设循环次数与 diff 规模上限，超限转人工拆解（阈值经验值，需按团队校准）——生产动作一节“Agent 必须有围栏”和“只认验证证据”两条，缺任何一条，这次事故都会原样重演。同一个仓库补齐测试后重跑同类任务，Agent 中位迭代次数从 7 降到 2（经验值）：改善来自反馈回路，不来自换模型。
最小上手
用同一个需求分别按三代跑一遍，成本差异会非常直观。先准备一张任务卡，补全时当作自己的拆解提纲，Agent / SDD 时直接贴给工具。
md
## 任务卡
目标：为订单模块增加退款申请接口
范围：只改 src/order/，不碰公共 API 和其他模块
验收：`pnpm test order` 全绿；`pnpm lint` 无新增告警
禁止：升级依赖、改数据库 schema、改鉴权中间件
交付：独立分支 + 变更说明 + 测试输出bash
git switch -c ai/order-refund
# 补全：在目标文件写清意图注释，逐段接受，不整段盲收
# Agent / SDD：贴任务卡，要求先给计划再改，改完自证
git diff --stat
pnpm test order && pnpm lint跑通的判据不是“AI 说完成了”，而是测试与 lint 通过，且 git diff --stat 没有超出任务卡范围。省略了 CI 配置和真实测试命令，按自己的项目替换。
生产动作
- 路由写进平台：按改动文件数、是否触及核心链路、验收是否可自动判定打标；默认补全，跨模块升级 Agent，高风险升级 SDD。不要靠个人记忆。
- Agent 必须有围栏：独立分支、最小权限令牌、命令白名单、禁止访问生产网；单任务的文件数和行数上限按团队基线定（经验值），超限转人工拆解。
- 只认验证证据：要求附测试命令与输出，不接受“已完成”。没有测试的仓库先补特征测试（characterization test），再放 Agent 进去自修。
- 网关管成本：按团队 / 项目设预算与限流，长任务拆小；成本异常先看调用来源、循环次数和上下文注入量。
- 知识层进仓库：AGENTS.md 与架构变更一起评审；规范只写可判定条款，风格交给格式化工具。
| 现象 | 先查 | 判断 |
|---|---|---|
| Agent 反复改不对 | 验收是否可执行、是否漏了关键文件 | 验收模糊就补规格，不要继续对话硬拧 |
| diff 越改越大 | 是否声明了“只改 X、不动 Y” | 补边界并回滚无关改动 |
| 成本突然上升 | 网关的 token 与调用来源 | 循环、大文件注入或模型选错 |
边界
- 补全不适合跨文件任务：它看不到全局，强行让它生成架构级代码，得到的是表面合理、局部冲突的片段。
- Agent 不适合需求模糊和高危操作：它能执行，所以错误也会被执行；没有测试、没有沙箱、没有回滚时，不要放它碰核心链路。
- SDD 不适合小改动和探索期：规格成本收不回来，需求还会变时流程只会拖慢反馈。它的优势是可追溯，不是更快。
- 更强的范式不等于更省：在没有测试的仓库里上 Agent，会把错误固化成“能跑”的代码；在小任务上套 SDD，审查和文档成本可能超过写代码本身。
- 常见误区：把三代当替代关系；以为上了 SDD 就不用人工 CR；把治理等同于审批拖慢。实际上治理是自主性的前提——没有门禁，团队只能靠缩小权限来控风险，反而放不开。六层全部自建会很重，早期可以借托管网关和现成工具，但身份、权限、审计三条不能外包给个人账号。
讲清楚
AI Coding 的三代是人的责任边界三次外移。补全只让 AI 猜下一段，人仍负责执行，风险低、上限也低。Agent 接管读写和测试，但错误也会被真实执行，所以沙箱、最小权限、变更上限和可执行测试是前提。SDD 再接管流程与验证，用规格钉住目标和验收，用门禁挡住不合格产出，换来可追溯与协作，代价是规格成本，且规格错则全错。企业落地不是选一代，而是分层共存：能力层按任务路由，网关统一身份与成本，工具层统一权限，治理层管门禁审计，知识层沉淀规则。判断看改动范围、验收可判定性、出错代价；拿不准从低一代开始。
适用：2026 年主流 AI Coding 工具 | 初稿 2026-10