把问题从“模型不够聪明”拉回到工作流、协作方式与开发范式

AI 编程的演进：从补全到编排#

GitHub Copilot 的出现，开启了 AI 辅助编程的时代。

但很多人没意识到的是：AI 编程工具的能力已经发生了质的飞跃。

如果你还停留在"AI 就是高级自动补全"的认知，你会错过这场革命。

阅读地图
这篇不讲玄学，只回答三个问题：

模型能力怎么推动工具形态变化？

交互方式为什么从"补全"走向"编排"？

开发模式为什么从"写代码"走向"定规则"？

驱动力：模型能力的跨越式提升#

在讨论工具演进之前，我们需要理解一个关键事实：所有工具的进化，都建立在模型能力的突破之上。

模型能力演进时间线#

说明
以下只选 Anthropic / OpenAI / Google 三家，目的不是做全量盘点，而是抓住最影响 Agentic Coding 形态演进的关键拐点。

厂商	代表模型（版本）	发布时间	为什么有代表性
OpenAI	GPT-4	2023-03-14	把通用代码生成质量拉到可规模化使用的起点
Anthropic	Claude 3.5 Sonnet	2024-06-20	在工程实践中显著提升代码理解与改写稳定性
Anthropic	Claude 4（Opus 4 / Sonnet 4）	2025-05-22	官方把重点放在 coding、长任务持续性、并行工具调用与记忆能力
OpenAI	GPT-5	2025-08-07	官方给出 agentic coding 与 tool calling 的系统化提升
Google	Gemini 3 Pro	2025-11-25	原生多模态 + 长上下文（1M），更适合代码、截图、文档混合输入的开发场景
Anthropic	Claude Opus 4.6	2026-02-05	在大代码库、长链路代理任务和 code review/debug 上继续强化
OpenAI	GPT-5.3-Codex	2026-02-05	将 Codex coding 能力与 GPT-5 推理能力合并，强化长时代理编码任务

关键洞察：工具是模型能力的工程化放大器

没有可靠的 Tool Calling，Agent 只能停留在"建议"层

没有长上下文和更稳的执行，跨文件改造很难稳定

没有多模态输入，真实开发中的截图/日志/终端就很难联动

工具能力上限通常受模型能力约束，但最终体验还取决于产品工程实现。

数据来源

OpenAI（2023-03-14）：GPT-4

Anthropic（2024-06-20）：Introducing Claude 3.5 Sonnet

Anthropic（2025-05-22）：Introducing Claude 4

OpenAI（2025-08-07）：Introducing GPT-5 for developers

Google（2025-11-25）：New Gemini API updates for Gemini 3

Google（文档）：Gemini 3 Pro (Vertex AI)

Anthropic（2026-02-05）：Introducing Claude Opus 4.6

OpenAI（2026-02-05）：Introducing GPT-5.3-Codex

说明：这篇文章只引用"方向性证据"，不把单一 benchmark 当成普适结论。

理解演进的三个维度#

基于模型能力的提升，AI 编程的演进呈现出三个维度的协同进化：

底层能力演进：从文本输出到 Tool Call 到 CLI 集成
交互方式演进：从补全到对话到自主规划
开发模式演进：从手工编码到 SpecDriven、TestDriven、IssueDriven

这三个维度相互促进，共同推动了 AI 编程的革命。

维度	关注点	你会直接感受到的变化
底层能力演进	模型是否能稳定调用工具	AI 从"提建议"变成"能执行"
交互方式演进	你和 AI 如何协作	从 Tab 补全到任务级委派
开发模式演进	项目如何组织与交付	从写实现到写约束与验收

维度一：底层能力的演进#

阶段一：纯文本输出#

能力边界#

AI 只能输出文本，无法与外界交互

典型场景#

你问 AI："这段代码有什么问题？"
AI 回答："这里应该加个 null 检查"
你需要手动复制粘贴代码

局限性#

AI 无法读取文件
AI 无法执行命令
AI 无法验证自己的输出
完全依赖人工操作

这一阶段的真实成本
这一阶段的模型能力本身就偏弱，生成代码经常大段不可用。看起来省了"写代码"时间，实际只是把成本转移成了"复制粘贴 + 人工核对 + 人工回归 + 反复返工"。

阶段二：Tool Call（工具调用）#

能力边界#

AI 可以调用预定义的工具函数

典型工具#

读取文件（Read）
编辑文件（Edit）
搜索代码（Grep）
执行命令（Bash）

突破性变化#

AI 可以自己读取代码
AI 可以自己修改文件
AI 可以自己运行测试
形成"感知-决策-执行"的闭环

从这里开始才叫 Agentic 雏形
一旦形成"读代码 -> 改代码 -> 跑验证"的闭环，效率提升才会从线性变成指数级。

实际案例：Cursor Composer 的工作流#

你：给这个项目添加用户认证

AI 的内部流程：
1. [Tool Call: Glob] 搜索项目结构
2. [Tool Call: Read] 读取 package.json 了解技术栈
3. [Tool Call: Read] 读取现有的路由文件
4. [Tool Call: Edit] 修改路由，添加认证中间件
5. [Tool Call: Write] 创建新的认证模块
6. [Tool Call: Bash] 运行测试
7. [Tool Call: Read] 读取测试错误
8. [Tool Call: Edit] 修复错误
9. [Tool Call: Bash] 重新运行测试

阶段三：CLI 与外部系统集成#

能力边界#

AI 可以通过命令行工具访问外部系统

核心突破#

不再局限于本地文件系统
可以通过 CLI 工具访问任何系统
可以组合多个命令（pipe）
AI 更擅长写命令而不是调用复杂协议

一句话记忆
阶段一是"会说"，阶段二是"会做"，阶段三是"能接入真实世界系统"。

实际案例：Claude Code 的 Bash 工具#

你：帮我查一下数据库里有多少用户

AI 的内部流程：
1. [Bash] psql -d mydb -c "SELECT COUNT(*) FROM users"
2. 返回结果：1,234 个用户

你：把这个数据同步到 Notion

AI 的内部流程：
1. [Bash] notion-cli create-page --title "用户统计" --content "1234"

CLI vs MCP：两种扩展方式的对比#

维度	CLI 工具	MCP 协议
AI 理解难度	低（AI 擅长写命令）	高（需要理解协议规范）
组合能力	强（可以 pipe）	弱（需要单独调用）
开发成本	低（复用现有工具）	高（需要开发 MCP Server）
错误处理	简单（标准输出/错误）	复杂（协议层错误）
性能	高（直接执行）	低（协议开销）
适用场景	通用工具、自动化脚本	结构化数据、实时连接

为什么 CLI 在早期更容易落地
很多团队会先走 CLI-first，再评估是否需要 MCP，常见原因有 4 个：

AI 本质上就是在"写代码"，而命令行就是最简单的代码

CLI 工具生态成熟，不需要重新造轮子

可以直接复用开发者熟悉的工具（git、curl、jq 等）

组合能力强，可以用 pipe 连接多个工具

MCP 的价值#

对于需要持久连接的场景（数据库、WebSocket）
对于需要结构化返回的场景（类型安全）
对于需要权限管理的场景（OAuth）

实践边界
更稳妥的做法是：先用 CLI 打通链路，再在需要结构化能力时引入 MCP。不要把 "CLI vs MCP" 理解成二选一。

维度二：交互方式的演进#

先看总览，再看细节：

交互形态	主要交互	代表工具	主要瓶颈
补全式交互	Tab/注释补全	GitHub Copilot（初期）、CodeGeeX、通义灵码	上下文太浅，跨文件能力弱
对话式协作	对话式修改	Cursor（早期）、GitHub Copilot Chat	仍依赖人工执行与验证
Agent 委派式协作	任务级委派	Cursor、Antigravity、Trae；Claude Code、Codex、OpenCode、Gemini CLI	对上下文治理和约束设计要求更高

补全式交互：智能补全#

代表工具#

GitHub Copilot（初期）、CodeGeeX、通义灵码

核心能力#

Tab 补全：预测下一行或下一个函数
基于注释生成代码
单文件上下文理解

局限性#

只能"猜"你想要什么，经常猜错
需要逐行审查生成的代码
上下文理解有限（通常只看当前文件）
无法处理多文件协调修改

典型误区
把补全式工具当"自动开发"用，几乎一定会得到补丁摞补丁的黑盒面条代码。

对话式协作：对话式编程#

代表工具#

Cursor（早期）、GitHub Copilot Chat

核心能力#

对话式交互：可以问问题、要求修改
多文件理解：可以看到项目结构
代码解释和重构建议

进步#

从"被动补全"到"主动对话"
可以理解更大的上下文
可以进行代码审查和优化建议

但仍然有限#

需要你手动复制粘贴代码
无法自主执行任务
无法运行命令或测试

对话式协作的价值
它最大的贡献不是替你写完代码，而是把"问答"变成了"协作式改造"。

Agent 委派式协作：Agentic Coding（自主规划）#

代表工具#

Native IDE：Cursor、Antigravity、Trae
CLI 工具：Claude Code、Codex、OpenCode、Gemini CLI
持续演进：GitHub Copilot Agent Mode

核心能力#

自主规划：理解任务，拆解步骤
多文件编辑：同时修改多个文件
执行命令：运行测试、安装依赖、启动服务
自我纠错：发现错误，自动修复
全局理解：理解整个项目的架构和规范

Agent 委派式协作的关键不是更会写，而是更会收敛
真正的提升来自：能在约束内连续执行，并在失败后快速回到可用状态。

深度理解的突破：以 Codex 为例#

当你给 Codex 一个需求时，它会：

大量读取项目文件（可能几十个文件）
理解项目的架构模式
识别现有的工具函数和组件
确保新代码符合项目规范
然后才开始生成代码

这种"先理解，再动手"的方式，让 AI 生成的代码质量大幅提升。

Agent 委派式协作的代价
模型更强，不代表可以放弃工程纪律。没有规则、测试和回滚，能力越强翻车越快。

维度三：开发模式的演进#

随着 AI 能力的提升，开发模式也在演进。

模式	起点输入	交付重点	最适合
SpecDriven	规格文档	一致性、可追溯	需求清晰、多人协作
TestDriven	测试用例	正确性、回归安全	逻辑复杂、重构频繁
IssueDriven	Issue/Ticket	需求-代码闭环	开源协作、敏捷团队
AICR	代码变更	风险发现、质量门禁	中大型团队持续交付

SpecDriven（规格驱动开发）#

代表工具#

Kiro、SpecKit、OpenSpec

核心理念#

先写详细的 Spec 文档（需求、接口、数据结构）
AI 根据 Spec 生成代码
自动生成测试和文档

工具/机制	典型入口	核心产物	定位
Kiro	IDE 内 spec 流程	spec -> design -> tasks	IDE 原生 SpecDriven
SpecKit	`specify` CLI / 命令流	specify -> plan -> tasks -> implement	开源规范化流水线
OpenSpec	`/openspec:proposal` 等命令	proposal/specs/design/tasks	以变更为中心的 SDD 框架
Agent 的 Plan 模式	`/plan` 或 plan-mode	实施计划、步骤拆解、验收顺序	轻量 Spec 入口（推断）

为什么 Plan 模式也算 Spec 的一部分（推断）
从工作机制看，Plan 模式把"先定义步骤和边界，再执行"前置到了编码前。它不一定生成完整规格文档，但已经具备了 SpecDriven 的核心约束思想。

常见 Plan 能力（按官方文档可核验）#

Codex：提供 /plan-mode（多步规划）
Gemini CLI：提供实验性 Plan Mode（只读规划）
GitHub Copilot：官方指标里已单独统计 plan mode
Claude Code：官方工作流强调先分析再执行（不同界面形态下能力入口可能不同）

适用场景#

需求明确的项目
团队协作开发
对文档要求高的企业项目

优势#

需求和实现分离
代码质量更可控
文档自动生成

SpecDriven 的现实收益
它不是让文档变多，而是把"含糊需求"提前暴露，减少后期返工。

参考链接

Kiro（官方介绍）：https://kiro.dev/blog/introducing-kiro/

SpecKit（GitHub）：https://github.com/github/spec-kit

OpenSpec（GitHub）：https://github.com/Fission-AI/OpenSpec

Codex slash commands（/plan-mode）：https://developers.openai.com/codex/app/commands/

Gemini CLI Plan Mode：https://geminicli.com/docs/cli/plan-mode/

Copilot plan mode 指标：https://github.blog/changelog/2026-03-02-copilot-metrics-now-includes-plan-mode/

Claude Code 工作流文档：https://code.claude.com/docs/en/common-workflows

TestDriven（测试驱动开发）#

核心理念#

先写测试用例
AI 根据测试生成实现代码
确保代码通过所有测试

工具/机制	典型入口	核心产物	定位
单元测试框架（Jest / Vitest / Pytest）	`test` 命令 + 测试文件	可执行断言	最小质量门禁
E2E 测试（Playwright / Cypress）	场景脚本 + CI	用户路径回归	业务可用性验证
覆盖率与门禁	`coverage` + CI 规则	覆盖率报告、阻断策略	防止“改了就漏测”
Agent 测试闭环	读失败日志 -> 改实现 -> 回归	迭代修复链路	降低人工校验强度

TestDriven + Agent 的典型闭环
一个高频、可落地的节奏是：

先让 AI 写最小可验证测试（而不是先写实现）

跑测试，拿到失败用例

让 AI 只针对失败点修改实现

回归全量测试，直到绿灯

适用场景#

对代码质量要求高的项目
需要频繁重构的项目
复杂的业务逻辑

优势#

测试覆盖率高
代码更健壮
重构更安全
显著降低人工校验与回归验收成本

为什么它能降低人工校验成本
因为“验收标准”从口头描述变成了可执行断言。AI 每次修改都可以先过自动校验，人只需要做关键路径决策和异常复核。

TestDriven 的前提
如果测试本身不可信，AI 只会更快地产生"通过假测试的错误实现"。

TestDriven 常见误区
只追求覆盖率数字会制造“看起来很安全”的假象。比覆盖率更重要的是断言质量、边界用例和失败信息可读性。

IssueDriven（问题驱动开发）#

核心理念#

从 GitHub Issue / Jira Ticket 出发
AI 自动读取 Issue 内容
生成代码并创建 Pull Request

工具/机制	典型入口	核心产物	定位
GitHub Issues + Agent	Issue 指派/评论触发	Draft PR、变更说明	开源与团队协作主链路
Jira + Agent	Ticket 指派/提及触发	Draft PR、状态回写	企业流程集成
CLI 闭环（`gh` 等）	读取 issue -> 建分支 -> 提 PR	自动化交付链路	不依赖特定 IDE 协议
Project 规则文件（AGENTS.md）	约束实现边界与验收	可追溯执行规范	防止任务漂移

IssueDriven + Agent 的典型闭环
一个常见的自动化交付节奏是：

读取 issue/ticket，补齐上下文

生成实现计划和风险点

编码 + 测试 + 自检

提交 Draft PR 并回写任务状态

适用场景#

开源项目
敏捷开发团队
需要追溯需求来源的项目

优势#

需求和代码自动关联
便于追溯和审计
减少沟通成本

IssueDriven 的工程价值
把"讨论"和"实现"绑定在同一条链路上，后续复盘和审计成本会显著下降。

IssueDriven 的边界
Issue 文本质量低时，Agent 只会更快地产生偏航实现。先补齐验收标准（DoD）和边界条件，再交给 Agent 执行。

参考链接

GitHub Copilot coding agent for Jira（官方）：https://github.blog/changelog/2026-03-05-github-copilot-coding-agent-for-jira-is-now-in-public-preview/

Codex ExecPlan（官方 Cookbook）：https://developers.openai.com/cookbook/articles/codex_exec_plans

AICR（AI Code Review）#

核心理念#

AI 自动审查代码
发现潜在问题（安全漏洞、性能问题、代码规范）
提供修改建议

工具/机制	典型入口	核心产物	定位
PR 自动审查	PR 创建/更新触发	风险清单、建议修复	第一层质量筛网
规则化检查（lint/test/security）	CI 流水线	可执行阻断结果	防止低级错误入主干
语义审查（Agent）	结合代码上下文评审	架构/边界问题提示	发现人工容易漏掉的系统性问题
人工复核	高风险改动人工决策	最终合入判断	关键路径兜底

AICR 的推荐落地顺序
先把“确定性检查”自动化（lint/test/security），再叠加“语义审查”。否则只会上升噪音，不会上升质量。

适用场景#

团队协作开发
对代码质量要求高的项目
需要快速迭代的项目

优势#

自动化 Code Review
发现人工容易忽略的问题
提高代码质量

AICR 不是免审通行证
AI Review 适合做第一道筛网，不应该替代关键路径上的人工决策。

AICR 的衡量指标
如果要判断 AICR 是否有效，至少跟踪三类指标：误报率、漏报率、审查耗时变化。只看“评论条数”会产生错觉。

三个维度的协同进化#

这三个维度不是三条平行线，而是一条闭环：

底层能力决定“AI 能不能真正执行”
交互方式决定“人机协作成本高不高”
开发模式决定“结果能不能稳定复用”

常见卡点	表面现象	真正缺口	优先动作
AI 改来改去总返工	能写但总不稳	底层能力与验证闭环不足	先补 `read/edit/run/test` 闭环
对话很多但产出很慢	聊天时间长、落地少	交互方式停留在问答层	从“对话式协作”升级到“任务级委派”
每次都要从头讲规则	同类任务重复踩坑	开发模式没固化	用 Spec/Test/Issue/AICR 固化流程

实践顺序建议
先补齐底层执行闭环，再升级交互方式，最后固化开发模式。顺序反了，通常会陷入流程空转。

边界提醒：别把"趋势"当成"定律"#

这篇文章最容易踩的 3 个误区

把“趋势”当“立即全量替换”：并不是所有任务都要一上来就 Agentic。

把“模型更强”当“可以省掉工程纪律”：没有规则、测试和回滚，能力越强翻车越快。

把“工具选择”当“立场之争”：既包括方法层（CLI、MCP、Skills），也包括产品层（GitHub Copilot、Cursor、Claude Code、Codex 等）；关键是匹配项目约束，不是跟风站队。

更稳妥的判断是：

Agentic Coding 是方向，但落地节奏要按项目风险分层推进
Plan 过程已经包含在 SpecDriven 内，不需要强行拆成独立范式
生产阶段的运行治理（如 AgentOps）放到后续文章再展开更合适

示例：把 4 种模式整合成一条工作流#

这一节给一个最小可落地范例，把 SpecDriven + IssueDriven + TestDriven + AICR 串成闭环：

立项与调研（IssueDriven 起手）
把目标拆成可追踪任务（Issue/Ticket），明确 DoD（完成定义）和风险边界，避免“需求在对话里漂移”。
方案与任务拆解（SpecDriven 定边界）
为每个关键需求生成 spec -> design -> tasks artifacts，让“要做什么、怎么做、做到什么算完成”可审计。
开发实现（IssueDriven 驱动执行）
围绕任务清单推进实现，代码提交与 Issue 保持关联，保证需求来源与变更路径可追溯。
自动验证（TestDriven 把验收变成可执行）
先补最小可验证测试，再实现功能；每轮改动都走“失败用例 -> 修复 -> 回归”的闭环，压低人工校验成本。
合并前守门（AICR 做第一道筛网）
PR 阶段先跑确定性检查（lint/test/security），再做语义审查；高风险改动保留人工最终决策。
上线与沉淀（四种模式回流）
把实现结果回写到 spec/issue/测试与评审记录，形成下一轮迭代可复用的工程上下文。

实战复盘参考
作者实战复盘：AI Native ：重塑从 0 到 1 的生产力法则与实战复盘，可结合原文的 7 个 phase 对照阅读。

小结#

这篇文章真正要完成的是一个角色切换：从“写代码的人”，变成“定义目标与约束、让系统稳定交付的人”。

离开这篇文章前，建议先做 3 件事：

在一个真实需求上试一次 SpecDriven + TestDriven 的最小闭环。
给项目补齐最小上下文约束（例如 AGENTS.md、代码规范、禁止事项）。
把“可执行验证”接入日常流程（最少是测试与基础审查门禁）。

一句话收束
AI 编程的核心，不是“更快地产生代码”，而是“更稳定地交付可验证结果”。

下一篇文章，我们将深入探讨当前 Agentic Coding 工具的生态位，帮你选择最适合自己的工具。

为什么很多人觉得 AI 很笨：其实是工作流还停在补全时代

AI 编程的演进：从补全到编排#

驱动力：模型能力的跨越式提升#

模型能力演进时间线#

理解演进的三个维度#

维度一：底层能力的演进#

阶段一：纯文本输出#

能力边界#

典型场景#

局限性#

阶段二：Tool Call（工具调用）#

能力边界#

典型工具#

突破性变化#

实际案例：Cursor Composer 的工作流#

阶段三：CLI 与外部系统集成#

能力边界#

核心突破#

实际案例：Claude Code 的 Bash 工具#

CLI vs MCP：两种扩展方式的对比#

MCP 的价值#

维度二：交互方式的演进#

补全式交互：智能补全#

代表工具#

核心能力#

局限性#

对话式协作：对话式编程#

代表工具#

核心能力#

进步#

但仍然有限#

Agent 委派式协作：Agentic Coding（自主规划）#

代表工具#

核心能力#

深度理解的突破：以 Codex 为例#

维度三：开发模式的演进#

SpecDriven（规格驱动开发）#

代表工具#

核心理念#

常见 Plan 能力（按官方文档可核验）#

适用场景#

优势#

TestDriven（测试驱动开发）#

核心理念#

适用场景#

优势#

IssueDriven（问题驱动开发）#

核心理念#

适用场景#

优势#

AICR（AI Code Review）#

核心理念#

适用场景#

优势#

三个维度的协同进化#

边界提醒：别把"趋势"当成"定律"#

示例：把 4 种模式整合成一条工作流#

小结#