这是《AI 入门指南》拆分系列第 2 篇。这一篇专门讲开发工作流：从 AI IDE 到 vibe coding，再到 coding agent，以及为什么工程验证会变成真正的分水岭。

上一篇我们讲的是：AI 为什么不再只是聊天框，而会慢慢长成工作台。那下一步最自然的问题就是：当 AI 真正进入工作现场时，它会先进入哪个场景？

对很多人来说，最先发生剧烈变化的地方，不是写周报，不是做表格，而是开发环境。因为代码、文档、命令行、日志、测试、配置，本来就是高度结构化、特别适合 AI 介入的材料。

AI IDE：AI 第一次真正进入生产现场

如果说 AI 工作台解决的是“统一使用入口”的问题，那么 AI IDE 解决的就是另一个更硬核的问题：

怎么让 AI 不只停留在聊天框里，而是直接进入工作现场。

这一章先聚焦代码工程这个最典型的工作现场。它不是在说所有 Agent 都等于 coding agent，而是先用代码场景这条线，解释 AI 为什么会从“给建议”走向“参与交付”。通用型 Agent 与 coding agent 的边界，下一篇会专门拆开。

以 Cursor、Windsurf、Trae，以及 VS Code 配合各种 AI 助手为代表，AI IDE 最大的变化在于：AI 不再只依赖你手动粘贴内容，它可以直接读取项目、理解代码、查看文件、参与调试，甚至直接修改工程。

这和网页版 AI 已经不是一个层级的事了。

在网页里，你通常是这样工作的：

• 复制一段代码给 AI
• 问它这是什么意思
• 再把它的建议手动复制回去

在 AI IDE 里，AI 可以：

• 理解整个工程结构
• 同时读取多个相关文件
• 直接生成或修改代码
• 协助排查 bug
• 根据上下文给出更连贯、更精准的建议

这也是为什么程序员会最早、最强烈地感受到这波变化。因为软件开发天然就是结构化信息高度密集的场景：代码、文档、命令行、日志、测试、配置，几乎全部都适合让 AI 介入。

如果你不是程序员，也可以换个类比去理解。想象你是写文章的人：AI 不再只是你问一句、它答一句，而是直接帮你打开文档目录，找到你三个月前写过的草稿，调出相关材料，再沿着原来的语气和上下文往下续写。那种感觉，本质上就是“AI 进入工作现场”。

vibe coding 为什么会火

也正是在这一层，最近几年又长出了一个很流行的词：vibe coding。

如果用人话来解释，vibe coding 说的不是某种神秘的新算法，而是一种新的工作姿势：你主要通过自然语言描述目标，边试边改，靠快速反馈把东西一点点“拱”出来，而不是一开始就把实现细节全部想完整。

它为什么会火，其实也不难理解：

• 门槛更低
• 反馈更快
• 原型速度更高
• 让更多原本不属于传统工程背景的人开始有机会“做软件”

但这件事也很容易制造一种错觉：前期进展特别快，于是人会误以为后面也可以一直靠感觉往前冲。

问题在于，vibe coding 很适合探索、原型、工具脚本、小产品起步；一旦进入复杂系统、多人协作和长期维护，你就不能只靠“感觉对了就继续写”。因为幻觉、结构债务、测试缺口和边界不清，往往就是在这种特别顺手的时候一路混进去的。

所以这一步真正要建立的，不是“只用自然语言就能跳过工程”，而是“自然语言变成了工程过程中的一个高频入口”。

一个更工程化的 vibe coding 方法论

如果把 vibe coding 从“感觉流”往工程上稍微收束一下，它更接近这样一个循环：

1. 用户描述目标
2. AI 生成第一版草稿
3. 用户测试和反馈
4. AI 根据反馈继续修正
5. 在合适的节点补上验证、测试、边界与结构整理

也就是说，vibe coding 最健康的姿势，不是“我不再需要工程”，而是“我把探索阶段前移，让自然语言成为快速原型入口，然后再把工程纪律补回来”。

从工程角度看，vibe coding 至少要守住几件事：

1. 迭代验证循环：描述 -> 生成 -> 运行 -> 观察 -> 修正
2. 测试驱动意识：即使不是严格 TDD，也要尽早建立验证样本
3. 代码审查机制：关键逻辑不能完全跳过人工 review
4. 文档同步更新：代码变化要带着上下游说明一起改
5. 版本控制策略：AI 辅助开发同样需要严格的提交边界

一个典型的 vibe coding 工作流，可能长这样：

 1# 1. 用户描述需求
 2"帮我写一个函数，接收用户列表，返回按年龄分组的统计信息"
 3
 4# 2. AI 生成代码草稿
 5def group_users_by_age(users):
 6    age_groups = {}
 7    for user in users:
 8        age = user.get("age", 0)
 9        group = (age // 10) * 10
10        age_groups.setdefault(group, []).append(user)
11    return age_groups
12
13# 3. 用户测试和反馈
14"这个函数没有处理异常情况，而且分组逻辑可以优化"
15
16# 4. AI 改进代码
17def group_users_by_age(users):
18    if not users:
19        return {}
20
21    age_groups = {}
22    for user in users:
23        try:
24            age = int(user.get("age", 0))
25            key = f"{(age // 10) * 10}-{(age // 10) * 10 + 9}"
26            age_groups.setdefault(key, []).append(user)
27        except (ValueError, TypeError):
28            age_groups.setdefault("unknown", []).append(user)
29    return age_groups

你会发现，这套流程的关键不在“第一版是不是完美”，而在“反馈能不能被快速吸收，并且不断往可验证的工程结果收敛”。

从 AI IDE 到 coding agent

如果再往前走一步，你就会看到另一类工具开始冒出来：它们不只是待在编辑器里给建议，而是更像一个真正参与交付的 AI coding agent。

你给它目标，它自己去读代码、改文件、跑命令、补测试、做验证，然后把产物交回来。像 Claude Code、Codex 这样的产品，更适合作为这一层变化的代表性例子来理解：AI 不只是补全代码，而是开始承担一个会读仓库、会动工具、会交付结果的 coding agent 角色。

更深一层看，coding agent 之所以会快速兴起，并不只是因为它能比聊天框多做几步事，而是因为开发者开始从“我要打开哪个编辑器、复制哪段代码”转向“我直接描述目标，让系统自己决定该读什么、改什么、测什么”。这其实是在改写开发者与代码库的交互入口。

coding agent 的技术原理

一个成熟的 coding agent，通常会有几层能力一起工作：

1. 代码理解模块：通过 AST、依赖关系、调用链和文件结构理解代码。
2. 上下文感知能力：从仓库、文件系统、历史改动中获取任务所需背景。
3. 工具调用能力：接入终端、Git、测试框架、构建系统、代码检查工具。
4. 规划与执行循环：把复杂任务拆成子任务并逐步推进。
5. 验证与反馈机制：通过测试、lint、构建结果和差异对比判断改动是否有效。

一个典型的 coding agent 执行流程，大概会是这样：

这时候，有三个概念值得先做一个最低限度的前置理解，但还不必在这里把它们当成完整课程：

• Prompt：任务到底怎么讲清楚
• Context：AI 当前这一步到底能看到什么
• Tool Use：AI 到底能不能调用文件、终端、Git、测试和构建系统这些代码工程工具

企业级 coding agent 为什么难

当 coding agent 从个人工具走向企业级应用时，架构设计需要更加严谨。一个成熟的企业级 coding agent 往往不会是“一个大模型外加一个终端插件”，而会变成一套协同服务：

• 代码理解服务：负责分析仓库结构、依赖关系和语义边界
• 规划服务：把自然语言任务拆解为可执行序列
• 执行服务：安全地调用终端、测试、构建和变更工具
• 验证服务：检查质量、安全、性能和回归
• 状态管理服务：维护任务上下文、历史记录和工作记忆

这里真正难的，不是“能不能改文件”，而是：

• 多仓库依赖怎么理解
• 上下文窗口有限时，哪些文件该先读
• 不同团队的权限边界如何控制
• 高风险改动什么时候必须人工确认

多服务架构背后的真实挑战

如果再往深里看，企业级 coding agent 会很快碰到几个现实问题：

1. 跨仓库依赖分析：一个改动到底影响到哪些仓库、哪些接口、哪些测试体系。
2. 上下文窗口编排：大型代码库不可能整仓塞进上下文，必须做摘要、检索、优先级排序和分层加载。
3. 多仓库协作与一致性：不同仓库风格、权限和发布节奏未必一致。
4. 安全边界：删除文件、改配置、执行发布类命令时，什么时候必须人工确认。

所以对很多团队来说，AI IDE 和 coding agent 真正的分水岭，不在“能不能生成代码”，而在“能不能把生成、修改、验证、交付串成一个可信的闭环”。

AI IDE / coding agent 产品矩阵

把这一层工具放在一起看，会更容易理解不同产品的定位：

开源替代方案为什么值得关注

对于预算有限、需要高度定制，或者对隐私特别敏感的团队，开源方案通常有更高的吸引力：

1. Continue：适合 VS Code 体系，容易集成本地模型和自定义工作流。
2. Aider：偏命令行，更适合自动化流程和精简链路。
3. OpenHands：更偏协作式、任务式的工程操作环境。
4. Tabby、FauxPilot 等：更接近“自己搭一套替代型助手”。

你会发现，商业产品和开源方案的区别不只是“贵不贵”，更是“你想买一个成熟体验，还是买更多控制权”。

最后还是要回到工程验证

这一篇真正想留下的，不是“AI 写代码更快了”，而是：

代码生成从来不是终点，工程验证才是分水岭。

一个真正可用的 coding agent，不只是“会写”，还得“会验”：

• 会不会跑测试
• 会不会看错误
• 会不会回退和修正
• 会不会在不确定的时候停下来问人

也正因为如此，下一篇就必须把视角再往上抬一层。因为只要 AI 开始持续执行、多步调用、维护状态，你讨论的就已经不再只是一个“写代码工具”，而是一整套 Agent 系统。

下一篇，我们就专门讲：为什么 Agent 不是一个聊天功能，而是一个由模型、工具、状态和执行循环组成的系统。