LLM 系列 (二十五)：AI Coding，大模型如何改变软件开发

软件开发是大语言模型最早展现规模化价值的领域之一。代码不仅具有语言的表达能力，还具备严格语法、明确依赖和可执行反馈。模型生成的结果可以通过编译器、静态检查和自动化测试进行验证，使 AI 能够形成“生成、执行、观察、修正”的完整反馈闭环。

AI Coding 的形态也由此不断演进：早期产品主要在编辑器中预测下一行代码；随后开始结合当前文件、仓库结构和开发者指令完成跨文件修改；如今，Coding Agent 已经能够调用文件系统、终端、Git 和测试工具，围绕一个工程目标持续探索、实现和验证，最终交付可审查的代码变更。

这场变化的核心并不只是让代码写得更快，而是重新定义人与软件工程系统的协作方式：开发者负责定义目标、约束与验收标准，Agent 负责理解仓库、执行修改和验证结果，最终由人类完成风险判断与交付决策。本文将从产品与模型演进、上下文与 Agent 技术内核、真实开发流程以及工程安全四个方面，理解 AI Coding 如何从代码补全工具走向软件工程 Agent。

从 Copilot 到 Coding Agent：产品范式演进

AI Coding 的演进，本质上是模型参与软件开发的范围不断扩大：早期模型只预测光标后面的代码，随后开始理解文件和仓库上下文，如今则可以围绕一个工程目标持续检索、修改、执行和验证。

Phase1：预测下一段代码

代码补全是最早成熟的 AI Coding 形态。模型根据光标之前的代码、当前文件和少量相邻上下文，预测开发者接下来可能输入的内容：

1	P(next tokens \| prefix, current file, nearby context)

2021 年，GitHub 发布 Copilot 技术预览，将这种能力带入主流 IDE：模型可以根据开发者正在编写的代码，建议整行代码或完整函数。

传统从左到右生成只看光标之前的内容，而代码编辑经常需要同时理解后面的函数、类型和调用方。因此，代码模型还常使用 Fill-in-the-Middle，也就是根据前缀和后缀补全中间内容：

1	[Prefix] + [Suffix] -> [Missing Code]

这种方式适合补全函数、生成样板代码、补充类型和错误处理，但模型通常缺少完整任务状态。它可能生成语法正确的代码，却不知道项目中已经存在相同实现，也无法判断修改是否违反仓库约束。

这一阶段的交付单位主要是 Token、代码行或函数，模型被动响应开发者当前的光标位置。

Phase2：IDE 中的上下文协作

随后，AI Coding 从单点补全扩展到代码问答、Inline Edit 和多文件修改。开发者不再只接受下一行建议，而是可以直接提出任务：

解释这个模块的鉴权流程。
给这个函数增加缓存。
为这次修改补充单元测试。
把旧接口迁移到新的客户端。

这类系统会结合当前文件、Open Tabs、代码库索引、符号定义、调用关系和 Git Diff，为模型构建与当前任务相关的上下文。

Cursor 将 Tab、Inline Edit 和 Agent 集成到同一个 IDE 中：Tab 负责低延迟补全，Inline Edit 负责局部修改，Agent 则可以探索代码库、编辑多个文件并调用终端工具。

这一阶段的核心变化不是把补全框变成聊天窗口，而是让模型获得仓库级上下文。交付单位也从一段代码扩展为文件或跨文件 Diff，但任务拆解、验证和最终交付仍主要由开发者控制。

Phase3：从协助写代码到执行工程任务

Coding Agent 接收的是目标，而不是一段待补全代码：

1 2	修复支付接口重复扣款问题，补充回归测试，运行相关测试，并把修改控制在最小范围内。

Agent 需要自己完成如下工作：

Coding Agent 围绕工程目标完成任务理解、仓库检索、代码修改、验证与交付

Claude Code 与 Codex 都已经覆盖代码读取、文件修改、测试运行、并行任务和受控工具调用。两者的差异不再是“终端工具”和“完整平台”：Claude Code 以终端原生和可组合工作流建立优势，并逐步扩展到 IDE、桌面与远程执行；Codex 则重点打通 CLI、IDE、Cloud 和桌面应用，并使用 Sandbox 与 Worktree 管理隔离任务。

这一阶段的交付单位开始变成 Issue、Patch 和 Pull Request。开发者主要负责定义目标、约束和验收条件，Agent 则负责探索仓库、完成实现并提供验证证据。

产品与模型的共同演进

产品体验的变化既来自模型能力提升，也来自上下文系统、工具调用、Sandbox 和交互方式的演进。下表中的模型是对应阶段的代表版本，不表示产品只支持该模型。

注：以下信息截至 2026-07-12。模型更新速度较快，表中列出的是各阶段的代表版本，并不表示产品只支持该模型。

时间	代表产品	代表模型	产品核心亮点
2021.06	GitHub Copilot	OpenAI Codex	将行级、函数级代码生成嵌入 IDE 光标位置
2024.06	Cursor	Claude 3.5 Sonnet、Cursor Tab	AI-native IDE、代码库索引、Composer 多文件编辑和快速 Apply
2025.02	Claude Code	Claude 3.7 Sonnet	终端原生，可读取仓库、修改文件、运行命令和根据测试结果持续修正
2025.05	OpenAI Codex	codex-1，基于 o3 优化的软件工程模型	在独立云端 Sandbox 中完成 Bug 修复、功能开发和代码审查
2025.09	GitHub Copilot Coding Agent	多模型	接收 Issue，在独立环境中异步修改代码、创建 Pull Request 并请求人工审查
2025.10	Cursor 2.0	Composer	自研低延迟编码模型、多 Agent 界面、代码搜索与终端工具协同
2026.02	Codex App	GPT-5.3-Codex、Codex-Spark	打通 CLI、IDE、Cloud 和桌面端，使用 Worktree 隔离并行 Agent
2026.05	Cursor Composer 2.5	Composer 2.5	强化长任务能力，引入针对工具错误的局部反馈训练，并扩大合成任务规模
2026.06	Claude Code	Claude Sonnet 5	更强的长程编码、工具调用、自主验证和复杂任务跟进能力
2026.07	Cursor	Grok 4.5、Composer 2.5	Grok 4.5 由 Cursor 与 SpaceXAI 联合训练，覆盖桌面、Web、iOS、CLI 和 SDK
2026.07	OpenAI Codex	GPT-5.6 Sol、Terra、Luna	提供不同能力与成本档位，支持程序化工具调用、并行子 Agent 和更长程的软件工程任务

这些产品的变化背后，是 AI Coding 的交付粒度在不断扩大：

Token / 代码行
-> 函数与文件
-> 跨文件 Diff
-> Issue 与 Pull Request
-> 并行、长时间的工程任务

竞争的分水岭：模型之外还有 Harness

产品时间线说明了“发生了什么”，但模型版本本身无法完全解释市场格局。真正决定 AI Coding 体验的，是模型、Context Engine、工具系统、执行环境和交互方式组成的 Agent Harness。

Cursor 为什么崛起？Cursor 更早将代码库索引、多文件编辑、Diff 审查和终端执行整合进高频 IDE 工作流，并快速接入当时表现最好的模型。它缩短了从提出需求到看到代码变更的反馈路径，也让 AI 从补全功能变成开发环境的核心交互方式。
Claude Code 为什么建立优势？Claude 模型在代码理解、长程推理和工具调用上的能力，与 Claude Code 的终端执行环境联合演进。模型不仅能够生成代码，还可以读取仓库、运行测试、分析错误并持续修正。其优势来自模型与 Harness 的协同，而不只是命令行入口。
Codex 为什么能够迅速形成竞争力？OpenAI 同时推进专用模型和工程平台，将 CLI、IDE、云端 Sandbox、桌面应用、代码审查、Worktree 和多 Agent 并行逐步打通。随着 GPT-5.6 进入 Codex，OpenAI 已经从模型能力、执行环境和多端产品三个层面进入全栈竞争。
Cursor 为什么开始自研模型？通用前沿模型能力很强，但延迟、价格和工具调用行为不一定适合高频编码。Composer 系列使用真实 Cursor Harness 中的代码搜索、文件编辑和终端轨迹进行训练，使模型能够直接适配产品中的任务分布。Grok 4.5 则进一步将训练范围扩展到软件工程之外的复杂知识工作。

AI Coding 的竞争从单一模型能力扩展到模型、Context Engine、工具系统与 Runtime 的协同

因此，AI Coding 产品之间并不是简单的前后替代关系，但更好的模型能力、更短的执行闭环和更稳定的工程体验，确实会持续改变开发者的使用习惯与产品市场份额。

AI Coding 的竞争已经从“谁能生成更好的代码”，进入“谁能更稳定地理解任务、操作仓库、验证结果并完成交付”。接下来需要进一步拆解的，正是支撑这套能力的技术内核：Context Engine、Agent Loop、工具系统与验证机制。

AI Coding 的技术内核：从上下文到执行闭环

AI Coding 的技术链路可以概括为两个连续问题：首先，系统如何从大型仓库中找到当前任务需要的代码和约束；其次，模型如何基于这些上下文调用工具、修改代码，并根据编译和测试结果继续修正。

这两部分并不独立。Context Engine 为 Agent 每一轮决策提供代码事实，工具系统将决策转化为真实操作，验证系统再把执行结果变成下一轮上下文。三者共同构成 AI Coding 的技术内核。

Context Engine：让 Agent 看懂仓库

真实代码库通常远大于模型的上下文窗口。Context Engine 的任务不是尽可能多地读取代码，而是围绕当前任务，组合能够支撑下一步决策的工程事实。

信息类型	典型内容	主要作用
当前工作区	光标位置、Open Tabs、未提交 Diff、最近编辑	判断开发者正在处理什么
代码结构	AST、符号表、Import、定义、引用和调用图	理解类型、依赖和调用链
检索索引	关键词、路径、向量语义检索	从大型仓库中找到候选代码
项目知识	Issue、设计文档、Git History、仓库规则和 CI 配置	补充任务目标、历史原因和执行约束
执行反馈	编译错误、测试失败、Lint 和运行日志	证明当前假设哪里不成立

代码检索不能只依赖文档 RAG 常用的语义相似度。函数名、类名、错误码和文件路径等信息具有明确的词法特征，更适合通过关键词、符号表和定义引用关系进行精确检索；当查询与代码标识符缺少直接词法重合，或者需要跨越不同命名方式寻找功能相近的实现时，向量检索则更有价值。

因此，生产级 Context Engine 通常采用混合检索：关键词检索负责精确命中，符号与调用图负责扩展结构关系，向量检索负责补充语义相关代码，再结合当前工作区、Git 历史和最近修改等信号完成融合排序。

score(c, q) =
    α × lexical_match
  + β × semantic_similarity
  + γ × structural_relation
  + δ × workspace_relevance
  + ε × recency
  - ζ × noise_penalty

各项分数需要先归一化，再根据真实编码任务调整权重。检索的目标不是一次找全代码，而是构造一个精准、可继续扩展的候选集。

Context 构建：渐进检索与约束注入

代码上下文通过多路召回、融合排序、结构扩展与 Token 预算进入模型

Context Builder 不会简单拼接 Top-K 片段。它会对命中的函数向外扩展必要的类型、调用方和测试，去除重复信息，再按优先级分配 Token：当前任务、仓库规则、未提交 Diff 和最新错误通常高于普通背景代码。

仓库规则不应是“请生成高质量代码”这类抽象提示，而应是可执行、有作用域的约束：

修改 payment/ 后运行 ./gradlew payment:test。
禁止直接修改 generated/ 目录。
新增接口必须补充契约测试。
单元测试不得访问真实外部服务。
保持 Java 17 兼容。

整个构建过程需要平衡三个问题：代码片段太小会丢失调用关系，范围太大会引入噪声；磁盘文件、未提交 Diff 和检索索引必须对应同一工作区版本；上下文越长，Token 成本和关键信息被稀释的风险越高。

因此，成熟的 Coding Agent 会先定位入口，再沿定义、引用和调用链逐步展开；每次编辑、编译或测试产生新证据后，重新构造 Query 并更新 Context。到这一步，Agent 才拥有执行任务所需的工程事实和约束。

Agent Loop：从理解到执行

Agent 的核心流程可以抽象为：

1	Observe -> Plan -> Act -> Verify -> Update State

Coding Agent 在观察、规划、执行、验证和状态更新之间形成持续反馈循环

每轮执行都可以表示为：

1
2
3

action_t = Model(state_t, available_tools)
observation_t = Tool(action_t)
state_(t+1) = Update(state_t, action_t, observation_t)

其中 state 不只是聊天记录，还包括当前计划、读取过的文件、工作区 Diff、执行过的命令、测试结果和剩余预算。

工具系统：让决策产生真实变更

工具	主要能力	典型风险
Read / Search	阅读文件、搜索符号	读取密钥和隐私文件
Patch / Edit	修改一个或多个文件	修改范围失控
Terminal	编译、测试和运行脚本	执行破坏性命令
Git	查看历史、Diff 和分支	覆盖用户修改、错误推送
Browser	验证 UI 和查阅资料	Prompt Injection、外部泄露
MCP / API	连接 Issue、文档和业务系统	权限扩大、工具投毒

文件修改通常优先采用 Patch，而不是重新生成完整文件。Patch 更容易控制修改范围、保留用户代码，也便于人类审查。

终端工具则为模型提供了最重要的客观反馈。编译器和测试不会因为回答流畅就判定正确，它们会直接暴露类型、依赖、行为和环境问题。

验证系统：用可执行反馈约束生成

Agent 完成修改后，应从便宜、快速的检查开始，再逐步进入更昂贵的验证：

代码验证从快速静态检查逐步扩展到编译、测试、安全扫描和人工审查

测试通过也不代表修改一定正确。Agent 可能只运行了错误的测试、修改测试去适配错误实现，或者忽略测试没有覆盖的边界。因此还需要检查：

测试是否覆盖需求中的失败场景；
是否修改了与任务无关的代码；
是否删除或弱化了原有断言；
是否引入新依赖或安全风险；
Diff 是否与任务目标一致；
用户未提交的修改是否被保留。

长任务的状态与上下文管理

Coding Agent 的任务可能持续几十轮。不断把所有工具输出追加到上下文，会快速耗尽窗口并引入噪声。因此系统需要保留结构化状态，并对历史过程进行压缩：

1
2
3

保留：任务目标、关键约束、当前计划、有效结论、未解决问题、最新 Diff
压缩：已完成搜索、冗长日志、重复测试输出、无效尝试
外部保存：完整命令、原始日志、工具结果和审计记录

上下文压缩不是简单摘要聊天，而是确保 Agent 在丢弃细节后仍然知道“为什么这样修改、当前还差什么、哪些路径已经失败”。

AI Coding 如何进入软件开发流程

AI Coding 的价值并不局限于写业务代码，它正在进入需求理解、实现、测试、审查和维护等多个环节。

典型应用

场景	AI 可以完成什么	仍需重点检查什么
代码补全	样板代码、局部函数、API 使用	逻辑和边界条件
代码生成	新模块、接口、脚本和配置	架构一致性与维护成本
仓库理解	解释调用链、定位入口、总结模块	检索是否遗漏关键路径
自动测试	生成单测、边界样例、回归测试	测试是否真正验证需求
Bug 修复	复现问题、定位原因、生成 Patch	根因是否正确、是否引入回归
代码审查	检查 Diff、风险和缺失测试	误报、漏报和业务语义
重构迁移	API 升级、依赖替换、批量修改	跨模块兼容性与灰度风险
文档维护	README、变更说明、接口文档	文档与实现是否一致

实践：从 Issue 到经过测试的 Patch

假设 Issue 描述为：

1 2	支付请求在上游超时后会自动重试，部分订单发生重复扣款。请定位原因，增加幂等保护，并补充回归测试。

可靠的 Coding Agent 不应立即开始修改代码，而要先明确验收条件：

相同 payment_intent_id 只能对应一笔支付；
并发请求不能产生多次有效扣款；
网关超时后不能直接重新扣款；
系统能够查询网关并恢复本地支付状态。

随后，Agent 按照工程流程逐步执行。

Step 1：建立代码地图

搜索 payment、charge、retry、idempotency
-> 定位 PaymentController 和 PaymentService
-> 找到 GatewayClient.charge
-> 检查支付表、状态字段和唯一索引
-> 阅读现有支付测试

Agent 最终发现，问题发生在支付网关与本地数据库之间：

网关扣款成功
-> 本地保存结果前发生超时
-> 系统无法确认扣款状态
-> 上游重试并再次调用网关

Step 2：构造失败测试

测试需要覆盖三个关键场景：

相同请求连续提交两次，只产生一次有效扣款；
多个并发请求使用相同 payment_intent_id，只创建一笔支付；
网关扣款成功但客户端超时，重试时查询原交易，不再次扣款。

@Test
void retryShouldNotChargeTwice() {
    paymentService.pay(orderId, "intent-1024");
    paymentService.pay(orderId, "intent-1024");

    assertThat(fakeGateway.effectiveChargeCount()).isEqualTo(1);
}

先让测试失败，可以证明问题被正确复现，也为后续修改提供明确的验证标准。

Step 3：实现幂等保护

仅增加数据库唯一索引，只能避免重复记录，无法单独保证网关不重复扣款。因此，修复方案包含三层保护：

本地唯一约束：payment_intent_id 只能创建一条支付记录；
网关幂等键：调用网关时传递相同的 payment_intent_id；
支付状态机：使用 PENDING、SUCCEEDED、FAILED、UNKNOWN 记录支付状态。

如果网关明确返回成功或失败，系统分别将本地状态更新为 SUCCEEDED 或 FAILED。如果请求超时，则标记为 UNKNOWN；如果服务在写入结果前崩溃，记录可能长期停留在 PENDING。

因此，系统需要为 PENDING 设置执行租约或超时阈值。无论是 UNKNOWN，还是已经超时的 PENDING，后续请求都不能直接再次扣款，而应使用原幂等键查询网关，并由请求链路或后台对账任务恢复本地状态。

首次请求
-> 创建 PENDING 记录
-> 携带幂等键调用网关
-> 明确成功或失败：更新为 SUCCEEDED / FAILED
-> 结果未知或进程中断：进入待确认状态
-> 按幂等键查询网关
-> 恢复本地状态

Step 4：逐层验证

顺序重试测试
-> 并发请求测试
-> 网关超时恢复测试
-> 数据库迁移测试
-> 支付模块回归测试
-> 检查最终 Diff

如果测试失败，Agent 应根据日志重新检查实现，而不是删除断言或绕过失败分支。

Step 5：交付可审查结果

最终输出可以总结为：

根因：
本地支付记录与网关扣款之间缺少完整的幂等机制，
超时和并发请求可能导致重复扣款。

修改：
增加 payment_intent_id 唯一约束、网关幂等键和支付状态机；
遇到未知状态时先查询网关，不直接重新扣款。

测试：
新增顺序重试、并发请求和网关超时恢复测试，
支付模块回归测试全部通过。

风险：
上线前需要检查存量重复数据，
并确认支付网关支持幂等键和交易状态查询。

Coding Agent 从 Issue 提取验收条件，构造测试、实现修复并交付可审查 Patch

这个案例说明，Coding Agent 的价值不只是生成代码，而是从 Issue 中提取验收条件、定位故障窗口、补充测试，并最终交付可以验证和审查的 Patch。

可靠性与工程化：AI Coding 进入研发主流程

AI Coding 已经不再局限于代码补全。Coding Agent 正在进入需求分析、代码实现、测试、审查、CI 修复和故障排查等核心研发流程，交付对象也从“几行代码”扩展为一个经过验证的 Patch、Pull Request，甚至完整工程任务。

当 Agent 可以读取私有代码、运行命令并连接外部系统后，关键问题不再是“代码生成得像不像”，而是整个任务是否正确完成、执行过程是否安全、结果是否具备可验证性。

从代码评测转向任务评测

HumanEval 主要评估独立函数生成，SWE-bench 则要求模型根据真实仓库中的 Issue 生成能够通过测试的 Patch。后者更接近 Coding Agent，但仍无法覆盖企业内部框架、复杂构建环境和业务约束。生产级 AI Coding 应围绕完整任务进行评测：

评测维度	核心问题	关键指标
任务正确性	是否真正满足验收条件	任务成功率、功能测试通过率
修改质量	是否采用了合理且最小的实现	Patch 正确率、无关修改率、回归率
执行过程	是否真的运行并验证了结果	工具成功率、测试证据、轨迹完整性
安全合规	是否突破权限或引入风险	越权率、敏感信息泄露、依赖风险
工程效率	是否减少了真实研发成本	完成时间、人工干预次数、任务成本

企业需要从历史 Bug、代码审查意见、迁移任务和真实 Issue 中构建内部 Eval，并在可复现的 Sandbox 中执行。最终评分不能只由另一个模型判断，还应结合编译器、测试、静态分析和安全扫描等确定性信号。

用工程边界控制 Agent

Coding Agent 的主要风险来自四个方面：

结果错误：代码能够编译，但误解了业务规则；
执行失控：修改范围过大，或者运行了高风险命令；
数据泄露：私有代码、密钥或配置被发送到外部；
供应链攻击：恶意 Issue、文档、依赖或工具结果劫持 Agent。

这些风险不能只依赖模型自我约束，而要通过确定性的工程机制控制：

Sandbox、权限策略、人工审批、CI 门禁和审计共同约束 Coding Agent 的执行边界

其中，读取和搜索通常可以自动执行；构建与测试只有在文件系统隔离、网络受限且不注入生产密钥的 Sandbox 中才能自动运行。安装依赖、执行仓库脚本、访问外部网络、修改数据库和发布生产等操作，则需要额外授权或人工确认。完整的命令、文件变更、工具结果和审批记录都应进入审计日志。

从开发工具走向工程系统

AI Coding 参与核心研发流程已经不是未来假设。下一阶段的变化，是 Agent 从完成单个编码任务，进一步走向持续的软件工程协作：

当前形态	下一阶段
根据 Issue 生成 Patch	持续跟踪需求、实现和反馈
单 Agent 完成任务	多 Agent 分工实现、测试与审查
依赖当前仓库上下文	理解组织规范、服务拓扑和历史决策
人工发现问题后调用 Agent	从监控、日志和告警中主动定位问题
完成代码后结束任务	持续处理升级、技术债和线上回归
开发者逐步确认每个动作	开发者定义目标、边界和交付门禁

为了适应这种变化，代码仓库本身也需要变得更加“Agent 可操作”：构建环境可重复创建，测试能够快速运行，模块边界清晰，仓库规则可执行，CI 能够阻断错误 Patch，生产操作具备明确的权限和回滚机制。

AI Coding 的长期价值不是替代开发者输入代码，而是把大量实现、搜索、测试和维护工作交给 Agent。开发者的核心职责将进一步集中到需求定义、架构设计、业务判断、风险控制和最终交付责任上。

AI Coding 正在把大模型从“会写代码的补全工具”推进为“能够理解仓库、调用工具、运行测试并交付 Patch 的工程 Agent”；而开发者的核心价值，也将越来越集中在定义正确的问题、构建可靠的反馈环境，以及判断什么样的代码真正应该进入生产。

参考资料：

LLM 系列 (二十五)：AI Coding，大模型如何改变软件开发

LLM 系列 (二十五)：AI Coding，大模型如何改变软件开发

从 Copilot 到 Coding Agent：产品范式演进

Phase1：预测下一段代码

Phase2：IDE 中的上下文协作

Phase3：从协助写代码到执行工程任务

产品与模型的共同演进

竞争的分水岭：模型之外还有 Harness

AI Coding 的技术内核：从上下文到执行闭环

Context Engine：让 Agent 看懂仓库

Context 构建：渐进检索与约束注入

Agent Loop：从理解到执行

工具系统：让决策产生真实变更

验证系统：用可执行反馈约束生成

长任务的状态与上下文管理

AI Coding 如何进入软件开发流程

典型应用

实践：从 Issue 到经过测试的 Patch

Step 1：建立代码地图

Step 2：构造失败测试

Step 3：实现幂等保护

Step 4：逐层验证

Step 5：交付可审查结果

可靠性与工程化：AI Coding 进入研发主流程

从代码评测转向任务评测

用工程边界控制 Agent

从开发工具走向工程系统

版权说明

公众号