编程的终局：AI将如何重塑开发者的角色与工作流

整个2025年，真正运行良好且持续稳定消耗Token的Agent品类，AI编码工具当属其一。它不断地向我传递一个信号：编程时代的终结，或许比我们预想的要更早到来。

在实际场景中，我身边许多非计算机科班出身、不懂代码的朋友，已经能够借助AI结对编程，成功将产品开发并上线。

代码，长久以来被视为世界最底层、最本质的逻辑真相。因此，AI编程自然成为各大模型厂商竞相布局的关键赛道。几乎每一次基础模型的重大更新，都在AI编程能力上带来显著跃升，持续刷新我们对这项技术边界的认知。

几个月前，我仍持有这样的观点：AI在编程领域主要扮演辅助角色，无法完整实现复杂的业务需求，对整体开发效率的提升可能不足30%。 像Cursor这类工具，其核心用途也集中于Tab键自动补全、代码解释以及局部功能函数的实现，很少让其承担完整需求的开发工作。

然而，随着模型能力的持续迭代，特别是Claude 4.5和Claude 4.6 Opus等强大模型的出现，我的认知被逐步颠覆。如今，AI编程已成为编码工作的主力军。在日常开发中，我们已很少手动编写代码，大约90%的代码都由AI生成。我们的工作重心，更多地转向需求描述、任务拆解、架构设计以及代码审查等领域。

本文旨在分享当前主流的AI编程工具与模型选择策略，并结合个人实践经验，总结出一些实用技巧，以帮助各位开发者更顺畅地迈入AI编程的新阶段。

编程工具概览

下表列举了国内外主流的AI编程工具，它们主要以集成开发环境（IDE）、命令行界面（CLI）或编辑器插件等形式存在：

在众多工具中，Cursor以其出色的综合表现获得广泛认可，是开发者日常使用的主力工具之一。对于偏爱命令行的开发者，Claude Code和Codex也极受欢迎。

此外，国内也有一些优秀的AI编程工具，例如字节跳动的TRAE和阿里的Qcoder。它们使用门槛相对较低，无需特殊网络配置即可访问，但通常无法调用Claude系列的模型。

AI编程工具的演进方向，大致经历了从最初的编辑器插件，到独立的集成开发环境（IDE），再到如今备受青睐的命令行界面（CLI）。目前，我们基本不再优先考虑使用插件，因为其能力受宿主编辑器的限制过多。当前更主流的方式是采用独立的IDE或CLI工具。

自Claude Code引爆市场后，众多AI编程工具相继开始支持CLI模式。那么，CLI相比IDE具备哪些优势呢？

1. 无头化（Headless）与通用性：CLI更加通用，在任何具备命令行环境的地方均可运行。
2. 较低的开发维护成本：对于工具厂商而言，开发插件需要适配多种主流编辑器；开发独立IDE则过于复杂笨重。且开发者通常有自己偏好的编辑器，迁移成本高。CLI模式有效规避了这些问题。
3. 更佳的上下文感知与结果反馈：CLI能更好地感知命令执行结果，便于AI进一步生成、修复或优化代码。

那么，有了CLI，是否就不再需要IDE了呢？

答案是否定的。对于开发者而言，通常是两种方式结合使用。当然，具体组合方式可根据个人喜好自由搭配，例如，我日常使用 Cursor + Claude Code，你也可以选择 Codex + Claude Code。

CLI更适合全程由AI主导、人为介入较少的场景，尤其适合处理复杂任务。而IDE则能提供更优的开发体验，其可视化操作界面更加直观，更适合需要人工深度介入的场景，例如：

1. AI生成代码后，需要进行人工审查时，可利用编辑器的对比分析视图，便捷地核验代码逻辑是否符合预期，并决定接受或拒绝单文件的修改。
2. 进行局部修改时，如仅需调整某个函数中的几行代码，可以直接在Cursor中选中对应行并添加上下文，指示AI进行精确修改。
3. 需要手动微调某些代码逻辑时。

因此，最佳实践是在Cursor这类IDE中，同时打开命令行终端使用Claude Code等CLI工具，实现高效协作。

对于新手或希望体验“感觉编码”（Vibe Coding）的开发者，无需过度纠结于工具孰优孰劣，选择一个能快速上手使用的工具即可，例如Trae、Qcoder等。

编程模型选择

综合评估当前主流模型，可以从能力、价格与适用场景三个维度进行权衡与决策：

• 能力排名：整体表现上，Claude Opus 4.6 最为强劲，其次是 GPT 5.3 Codex，再次是 Claude Sonnet 4.6。
• 价格梯度：GPT 5.3 Codex 成本最具优势，Claude Sonnet 4.6 居中，Claude Opus 4.6 最为昂贵。

基于能力与成本的平衡，建议采用以下模型使用策略：

1. 日常开发与主流任务：优先使用 GPT 5.3 Codex 或 Claude Sonnet 4.6。
2. 高复杂度推理或困难任务：直接使用 Claude Opus 4.6。
3. 前端复杂UI交互实现：可考虑使用 Gemini 3 Pro。

目前，编码能力最强的模型序列仍是Claude 4.6系列。如果条件允许，直接使用顶流模型可以减少大量的调试和修复成本，事半功倍。

如果对价格敏感或有数据安全方面的顾虑，也可以考虑国内的大模型，如GLM-4.7、Kimi k2.5、Qwen3-Coder等。它们的效果与Claude 4.5/4.6相比仍有一定差距，但满足日常任务开发基本没有问题，是性价比较高的替代方案。

我们在选择模型时的决策链路应该是：首先确保数据安全与合规，其次保证生成质量，最后再考虑模型成本。

上图引自Cursor官网，列出了主流模型不同操作（输入、输出、缓存写入、缓存读取）的计费价格。可以发现，输出（生成）的价格通常最为昂贵，其次是缓存写入和输入，最便宜的是缓存读取。

此外，上下文窗口大小也是某些场景下需要重点考量的因素。上下文窗口是指大模型单次处理时能考虑的最大Token数量（包括文本和代码），既涵盖输入提示词，也包含模型生成的输出内容。

Cursor中的每个对话都拥有独立的上下文窗口。在一次会话中，包含的提示词、附加文件和回复越多，上下文就越庞杂，可用的窗口空间也逐渐被占满。

默认情况下，Cursor使用200k tokens（约15,000行代码）的上下文窗口。“Max”模式则可以将少数模型的上下文窗口扩展到其支持的最大长度，但这会导致速度稍慢、成本也更高。此模式对Claude 4.6、Gemini 2.5 Flash、Gemini 3 Pro等模型尤其适用，因为它们本身支持超过200k token的上下文窗口。

Token计算机制

我们知道不同模型具备不同容量的上下文窗口。上下文越大的模型，自然能接收更庞大的提问信息。在Cursor等工具中，任意一次聊天的Token消耗大致遵循以下计算逻辑：

• 初始Token组成：初始输入 = SystemPrompt（系统指令） + 用户问题 + Rules（规则） + 对话历史
• 用户问题：包含我们输入的文字以及主动添加的上下文（如图片、项目目录、文件）。
• Rules：包含项目规则（project rule）、用户规则（user rule）以及记忆（memories）。
• 工具调用后的Token累积：Cursor接收用户信息后，会调用各类工具获取更详细的信息，为回答做准备：总Token = 初始输入 + 所有工具调用结果

因此，我们可能只输入了一句简短的提示词，但最终实际参与模型推理的Token数量可能高达数万。并且，随着对话轮次的增加，大模型输出的内容也会被加入上下文，供下一轮推理使用，如同滚雪球一般，上下文的体积会越滚越大。

接下来，我们将详细介绍几款常见的编程工具。

Cursor深度使用指南

在基础环境配置上，使用Cursor首先需要解决网络访问问题。通常需要VPN，节点建议选择欧美区域。在Cursor的网络设置中，HTTP协议建议选择1.1，避免使用HTTP/2。

Cursor基于VSCode二次开发，操作体验与后者高度一致，并且共享丰富的插件生态。它支持将原有的VSCode配置直接导入，从而保留熟悉的环境设置。

模式选择

Cursor提供了四种主要模式供我们使用，它们的适用场景及工具调用范围如下：

我们可以在对话框左下角手动切换模式，也可以使用快捷键 Shift + Tab。在让AI执行任务前，建议先评估任务属性，选择对应模式后再执行。

建议：有时Agent生成的内容与预期不符。与其通过后续提示一点点修补，不如重新清晰地描述需求。可以先回滚（Revert）这些更改，然后将需求描述得更加具体、清晰，再重新执行。这通常比中途反复修改更高效，生成的代码也更干净。

对于较大的改动，多花些时间制定一个精确、范围清晰的计划是值得的。最困难的部分往往是明确“应该做什么改动”——这更适合由人来完成。在给出合适的指令后，再将具体实现交由Agent。

添加上下文

使用快捷键 Command + L 可以打开对话侧边栏。在输入框中，我们可以描述需求，让AI去实现。

除了输入文本，我们还可以使用 @ 符号快捷键添加更多上下文信息，例如项目文件夹、具体文件、外部参考文档、命令行输出信息、Git分支差异等，具体如下：

除了使用 @，也可以通过直接拖拽文件或文件夹到输入框中来添加上下文。对于更细粒度的代码，例如某个特定函数，我们可以选中这几行代码，然后手动将其添加到输入框中。

手动指定上下文是一种极佳的实践。它能缩小AI需要关注的修改范围，使其理解更精准，从而提升实现质量。

当然，不指定上下文也行，但并不推荐。因为这会降低实现效果，需要依赖我们在提示词中加入更精准的描述，才能通过语义检索关联到对应的代码文件或代码块。

自定义命令

在输入框中输入 / 即可唤起命令选择列表。这些命令通常是可复用的工作流，并且支持自定义。命令以普通的Markdown文件形式定义，可以存放在以下三个位置：

1. 项目命令：存放在项目的 .cursor/commands 目录中。
2. 全局命令：存放在用户主目录下的 ~/.cursor/commands 目录中。
3. 团队命令：由团队管理员在Cursor Dashboard中创建，并自动对所有团队成员可用。

创建命令的步骤如下：

1. 在项目根目录下创建 .cursor/commands 目录。
2. 添加一些具有描述性名称的 .md 文件（例如 code-review-checklist.md、create-pr.md）。
3. 使用纯Markdown编写内容，描述该命令应执行的操作。
4. 当你输入 / 时，这些命令会自动出现在聊天选项中。

commands目录结构示例如下：

命令文档内容示例：

# 代码审查清单

## 概述
全面的代码审查清单，用于确保代码质量、安全性和可维护性。

## 审查类别

### 功能性
- [ ] 代码实现预期功能
- [ ] 已处理边界情况
- [ ] 错误处理恰当
- [ ] 无明显 bug 或逻辑错误

### 代码质量
- [ ] 代码可读性好且结构清晰
- [ ] 函数简洁且职责单一
- [ ] 变量命名具有描述性
- [ ] 无重复代码
- [ ] 遵循项目规范

### 安全性
- [ ] 无明显安全漏洞
- [ ] 已实现输入验证
- [ ] 敏感数据处理得当
- [ ] 无硬编码密钥

使用方式非常简单直观：

忽略文件

项目中可能存在一些敏感文件，例如包含密钥、Token的配置文件。为防止信息泄露，我们不希望AI读取这些内容。

可以在项目根目录下创建 .cursorignore 文件，来控制Cursor可访问的目录和文件。默认情况下，Cursor会自动忽略 .gitignore 中列出的文件以及其内置的默认忽略列表中的文件（如各类锁文件、环境变量文件、版本控制目录等）。

除了防止敏感信息泄露，在大型项目或Monorepo项目中，通过排除无关文件，可以减少代码索引的范围，从而加快索引速度并提高文件发现的准确性。

对于 .cursorignore 中列出的文件，Cursor会阻止以下访问途径：

1. 语义搜索
2. Tab、Agent和Inline Edit模式可访问的代码
3. 通过 @ 提及引用的代码

需要注意的是：Agent使用的终端和MCP server工具不会受到 .cursorignore 的限制，它们仍然可以访问所有代码。因此，配置信息最好避免直接放在代码中，而应在项目构建时动态注入。即使必须放在项目中，也务必做好严格的账号权限管控。

并行Agent

在AI Coding的加持下，我们的开发效率显著提升。我们常常需要同时开发多个功能需求，并希望它们彼此互不干扰。传统做法是为不同需求创建不同的Git分支，但问题在于同一时间工作区只能切换到一个分支，无法实现真正的并行开发。

为此，Cursor推出了“并行代理”功能。它允许我们在本地同时运行多个代理，每个代理都在自己独立的工作树中工作，可以各自进行编辑、构建和测试，完全互不影响。

这样一来，多个功能就能真正并行开发。我们甚至可以使用不同的模型运行相同的提示词，对比哪个模型的输出效果更优（当然这会消耗更多Token，适用于复杂任务场景）。

工作树（worktree）是Git的一项功能，允许同时检出同一仓库的多个分支。每个工作树都拥有自己独立的一套文件和变更。

举例说明：

• 基于分支 feature/test-worktree-1 进行修改：
• 基于分支 feature/test-worktree-2 进行修改：

这两个Agent任务将在不同的工作区中并行运行，互不干扰。当Agent运行完成后，点击“Apply”按钮即可将其更改应用到本地分支。

通过在终端运行 git worktree list 命令，我们可以看到实际上是在用户根目录的 .cursor 文件夹下创建了不同的工作区域，从而实现并行运行且互不干扰。但需要注意磁盘空间的占用，使用完毕后应及时清理。

Claude Code 简介

前面我们介绍了Cursor编辑器的常见功能，这里也简述一下Claude Code的基本用法。这款工具近期非常火爆，原因在于其生成的代码质量高，且拥有超长的上下文窗口，能够一气呵成地完成耗时较长的任务。

Claude Code效果出众，我认为主要由两方面因素促成：第一，它使用了当前最顶级的Claude系列模型；第二，它在编码Agent的工程化实现上非常出色。两者叠加，才造就了其优异的表现。

由于Claude Code默认使用Claude系列模型，而Anthropic公司限制在中国大陆直接使用Claude模型，导致许多开发者无法体验。下面介绍如何在Claude Code中接入其他厂商的模型，以智谱AI的GLM-4.7为例：

1. 获取智谱AI提供的API-KEY（平台地址：https://bigmodel.cn/usercenter/proj-mgmt/apikeys）。
2. 替换环境变量参数。Claude Code支持供应商替换，只需将供应商的API端点和第一步获取的密钥写入环境变量即可。

   export ANTHROPIC_BASE_URL=https://open.bigmodel.cn/api/anthropic
   export ANTHROPIC_AUTH_TOKEN="上面获取到的sk开头的key"
   

   在Claude Code中接入其他模型也类似，但配置可能略有差异，具体需查阅各模型厂商的接入文档。目前，国内的主流模型厂商基本都支持接入Claude Code。

最佳实践指南

接下来，我们探讨一些AI编程的通用最佳实践，这些经验并不局限于特定的编程工具。

1. 善用规则（Rules）

Rules本质上是一种可复用的上下文机制，它会在每次对话时自动将预设的规则添加到提示词中。

在整个开发过程中，我们通常会总结出许多具有普适性的约束或偏好，例如：避免冗余注释、不要留下TODO标记等。如果每次对话都重复说明这些约束，不仅效率低下，还容易遗漏。因此，可以将它们沉淀为统一的规则（Rules），让模型在后续交互中自动遵循，从而减少重复沟通的成本（时间+Token），并提升代码输出的稳定性。

例如，以下常见的约束就非常适合固化为规则长期使用：

1. 不要留下TODO标记，必须完整实现代码逻辑。
2. 始终使用中文回答问题。
3. 除非明确要求，否则不要生成测试文件或说明文档。
4. 不要输出总结性段落。
5. 始终遵循最小化修改原则。
6. 具体的项目技术栈要求、代码风格、组件规范、架构设计等。

在编写规则时，也应遵循一些原则。以下是Cursor官方推荐的最佳实践：

1. 将规则控制在500行以内。
2. 将较大的规则拆分为多个可组合的小规则。
3. 提供具体示例或参考文件。
4. 避免模糊的指导，应像编写清晰的内部文档那样撰写规则。
5. 在聊天中重复使用提示时，尽量复用已有规则。
6. 通过引用文件路径而非复制其内容来利用现有文件——这既能保持规则简短，又能在代码变更时避免规则失效。

规则中应避免包含：

1. 整篇照搬的风格指南：改用Linter工具。Agent已经了解常见的风格约定。
2. 逐条记录所有可能的命令：Agent知晓npm、git、pytest等常见工具的基本用法。
3. 为极少出现的边缘情况添加冗长说明：让规则聚焦在经常使用的模式上。
4. 重复代码库中已有的内容：引用标准示例，而非复制代码。

然而，设定好规则后，我们不应让所有规则在每次对话中都生效，因为有些规则仅适用于特定场景。因此，需要指定规则的生效条件。以Cursor为例，它将规则生效方式分为四种：

创建规则有多种方式：

• 方式一：手动在项目根目录的 .cursor/rules 目录下创建 .md 格式的规则文件。
• 方式二：在Cursor设置（Settings）=> Rules中直接设置，分别填写文件名称、规则内容、生效方式。
• 方式三：通过Cursor官方提供的 create-rule 技能（skill）创建。该技能封装了官方推荐的规则最佳实践，使用简单：在聊天窗口中直接输入 /create-rule，然后描述要创建的规则内容及生效方式即可。

创建规则时，需要注意两种类型：用户规则和项目规则。用户规则适用于个人特有的习惯和风格，会在所有项目中生效，其规则文件存放在用户根目录下。项目规则则跟随特定项目，受版本控制管理。通常，我们会将团队协作所需的规则设定在项目规则中。

需要注意的是，用户规则的更新可能不是立即生效的，通常需要等待几分钟（推测是因为后台使用了RAG技术进行离线索引构建）。

另外，在实际开发中，我们可能同时使用多种工具，而不同工具的规则存放位置可能不同（例如Cursor的规则在 .cursor 目录，Claude Code的规则在 .claude 目录）。需要注意这些规则的同步问题。在团队协作中，最好能统一使用1-2种主流工具，以减少规则维护的负担。

2. 适时开启新会话或回退

在使用AI编程工具时，我们可能都有一种感受：在同一个会话中聊得越久，模型越容易遗忘之前说明的细节，甚至产生“幻觉”，输出质量下降。

这背后的根本原因在于：随着对话轮次增加，会话上下文不断变长，早期输入的信息权重被后续内容稀释，模型对最初需求的关注度下降。

较好的解决方案是：

1. 开启新会话：如果是开发全新的功能，最好重新开启一个会话。因为每个会话的上下文独立，模型不会被旧信息干扰，注意力更集中，输出质量通常更高。
2. 回退或总结重来：如果是同一功能，但已聊了很多轮次且输出质量变差，应立即停止追加指令。可以采用两种方式：
   • 回滚（Revert）：回退到开始出错的地方，然后一次性把后续完整、清晰的需求描述清楚，让模型重新实现。
   • 总结后新开：让模型总结当前的需求和已做的修改，然后拒绝所有更改。新开一个会话，将完整、清晰的需求输入，让模型从头实现。

这两种方法通常都比在多轮对话中不断纠错更高效。在IDE类工具中，回滚操作通常很方便（点击“Revert”按钮）。但在Claude Code等CLI工具中，回滚相对不便，因此可以考虑在开发过程中进行更频繁的Git提交（commit）。

3. 复杂问题拆分为多个简单问题

实践中发现，一次性让AI实现一个庞大或复杂的需求，效果往往不佳，容易遗留大量TODO，代码质量堪忧。

针对这种情况，通常的做法是：对大需求进行任务拆解。尽量使每个子任务独立，并呈递进关系。然后，为每个子任务开启新的会话，让AI依次实现。

任务拆解的好处包括：

• 任务颗粒度越细，AI的完成度和完成质量越高。
• 每次修改的代码量相对较少，便于代码审查（Code Review）。一次性修改大量代码会让人工审查变得困难。
• AI在一次性完成复杂需求时特别容易产生Bug和错误代码，并且可能基于错误代码继续生成更多错误（即“错上加错”），导致难以修正。小范围的任务有利于人为监督和把控。

4. 提供清晰的上下文

AI编程工具在首次加载项目时，会为代码库建立索引：将源代码按逻辑结构（如类、函数、模块）拆分成语义片段，再利用向量模型转化为向量表示并存入向量数据库。这样做的目的是让后续查询能基于“语义相似度”精准定位相关代码，而非简单的关键词匹配。

当我们向AI提问时，背后会经历一整套流程：问题向量化、意图解析、多路召回、相似度匹配、上下文拼接，以及必要的调用链或依赖关系追溯。这本质上是一个面向代码库的知识检索系统，属于典型的RAG（检索增强生成）模式。

因此，在向AI描述问题时，信息越具体，检索路径就越短、越准确。最好能给出具体的功能模块、文件名、目录路径、函数名或代码片段。这样，模型就能通过语义检索等方式，以较短的路径找到相关代码，避免在检索阶段混杂过多无关内容，干扰最终生成的上下文。

除了清晰描述，我们还可以通过前面提到的方法（如使用 @ 或拖拽），手动添加需要修改的具体文件或目录。

5. 与AI进行需求澄清

在真正让AI开始编写代码之前，我通常会先让它与我一起澄清需求、对齐实现方案。很多时候，我们给出的初始描述可能存在歧义或信息不完整。如果直接让AI写代码，结果很可能偏离预期。

在需求模糊时，AI常常会自行脑补细节、替我们做决定，导致后续需要花费大量时间和Token去纠正和补充。尤其是在使用Claude 4.6 Opus这类昂贵模型时，无谓的浪费更令人心疼。

在需求澄清阶段，AI会反过来询问一系列问题，帮助我们补全遗漏信息，使需求更清晰。同时，它也会给出初步的实现方案供我们审阅。如果发现方案有问题，可以及时调整；确认无误后，再让它基于已澄清的需求和方案去执行。这种方式能大幅提高一次性成功的概率，整个过程由我们掌控节奏，整体效率更高。

6. 频繁提交代码

在使用AI辅助编程时，养成频繁提交（Commit）代码的习惯至关重要。

通过提交将当前阶段的代码保存下来，如果后续AI在修改中不慎破坏了原本正常的功能，我们可以快速回滚到之前的提交记录进行恢复，而无需手动排查、重写或凭记忆还原。

我最初也觉得频繁提交很麻烦，但在踩过几次大坑后明白了其重要性。最佳实践是遵循“最小功能实现”原则，并按照最小功能单元进行提交，而非等到所有功能都完成后才一次性提交。

现代编辑器（如Cursor）通常支持基于修改内容自动生成语义化的提交信息（Commit Message），非常方便，无需再绞尽脑汁思考怎么写，或写下“修改文件”这类无意义的信息。

常用MCP工具推荐

上面介绍了一些AI编程的最佳实践，下面推荐几款日常高频使用的模型上下文协议（MCP）工具。

Context7

Context7 是一款MCP工具，可与前面提到的AI编辑器集成。我们可以将其理解为专为AI编程设计的“文档补课”工具。

其核心作用是：在我们提问或让AI写代码时，自动查询对应技术栈的官方文档，获取最新、最相关的内容，并将精简后的资料作为上下文提供给大模型。这使得AI生成的代码更准确、更贴近最新实践，而非依赖旧知识或猜测。

Context7能通过语义或关键词自动筛选相关信息，有助于控制上下文长度。在实际开发中，它充当了AI与技术文档之间的桥梁，帮助我们减少查资料和踩坑的时间，特别适合使用新框架或经常升级依赖的项目。

以Cursor为例，只需在提示词中加入“use context7”，它便会自动调用相关工具获取最新文档信息。

Figma-Context-MCP

这款MCP工具偏向前端开发，主要用于UI设计稿还原。

前端开发中，很大一部分工作在于还原UI设计稿。通过此MCP，我们可以自动获取Figma设计稿的关键信息，包括布局结构、原始尺寸、颜色、文案、字体、边框属性等。然后，将这些信息结合提示词交给大模型进行UI实现。

目前，这种方式虽然还达不到100%的还原度（实测约60%），但已能节省大量时间。剩余部分仍需手动调整。相比直接截图给AI识别（容易导致设计信息失真），通过MCP获取原始设计稿信息更为精准。

结语

我们深刻感知到AI编程能力的快速进化，并且可以预见其必将越来越强大。过去那些高度依赖人工编写的环节，正在被AI逐步接管。无论我们相信与否、接受与否，这都是技术发展的大势所趋。

这里要讨论的并非“AI会不会取代程序员”，而是编程这件事本身正在发生结构性变化。AI降低了技术门槛，在编程领域实现了某种程度的“平权”，使得更多人能够利用AI构建自己的应用。这意味着，单纯的“写代码”能力，其稀缺性正在下降。

对于开发者而言，需要重新思考：当实现成本大幅降低后，我们的核心价值应体现在何处？如何与AI更好地协同？

目前，AI辅助编程大致呈现两种范式：

1. 一种偏随意、即时反馈，适合探索和试错（即“Vibe Coding”）。
2. 另一种则强调约束、结构和规范，更贴近工程实践。Vibe Coding能提升效率，但难以支撑复杂系统的长期演进；后者虽然前期成本更高，却更符合真实生产环境对稳定性、可维护性的要求。

开发者终究要为系统的最终质量负责。因此，真正可靠的AI协作方式，必然是可控的、工程化的，而非随意的。

与此同时，开发工作的重心也在转移。以往，开发更像一条线性流程：分析、编码、调试、上线，精力多集中于“实现”。而现在，更多工作在于描述需求、制定规范、拆解任务，然后交由AI实现，最后进行人工审核。如果前期设计混乱、描述不清、拆分粗糙，即使AI能力再强，也容易在错误的基础上叠加错误。

因此，AI编程工具的进化也在推动开发者角色的演变。AI正在接管执行层，而开发者正在向决策层和设计层迁移。未来，真正的差距将不在于谁写代码更快，而在于谁能更好地驾驭AI，使整个开发过程高效、稳健、有序。

程序员不会消失，但数量可能会减少：不会使用AI的人，可能被淘汰；只会使用AI的人，不够稀缺；能驾驭AI完成复杂系统构建的人，将成为关键角色。