2025年一整年AI圈最火的应该就是Vibe Coding了，这个概念最早是由Andrej Karpathy在X上提出的。简单来说，你只需要告诉 AI 要实现什么网站、什么功能。具体的实现过程由 AI 完成，你甚至不需要关注代码是如何编写的。

这听起来确实非常的有吸引力，所以我从2025年5月份左右开始进行了Agent Coding的探索。我更倾向使用 Agent Coding 这个词，因为在大半年的实践过程中，我发现Agent Coding能更好地概括当前人与大模型协作编程的方式。在讲具体的的Agent Coding之前，先介绍下当前比较流行的大模型。

Agent Coding工具

当前知名模型主要集中在中美这两个国家。美国就有Claude、Gpt、Gemini、Grok等一众模型，而中国也有Kimi、DeepSeek、Qwen、Glm等一众模型。不得不说，现在各家大模型都在不停地卷，各大性能排行榜甚至是按天在进行变化。但是我的观点是不管如何变化，应该始终使用第一梯队的模型，因为更强的模型能力确实会减少很多实际的问题，虽然从短期来看成本是增加的，但是从整个项目维度来说其实不光会减少返工的时间，也降低了整体的成本。截至2026.03这个时间点，Coding模型最强的还是Claude Opus 系列、GPT 最新一代模型，作为备用Kimi使用下来效果也还可以。

至于具体的Agent Coding Tool我主要使用的是Claude Code和Windsurf这两个工具。前者是Cli模式，后者则是编辑器模式。至于使用哪种类型的工具，我认为需要根据你的实际场景来决定，如果你还是需要进行手动的代码编辑，那编辑器模式显然更适合你。而如果你不关心代码细节，Cli模式则更适合你。注意我个人观点是这都不是最重要的，并且将来也许还会出现新类型的交互方式，最重要的还是模型的能力，模型能力决定了下限。

所以我当前使用Claude Code基本上也是用的Claude Opus,除非是不需要那么强的推理能力，我会使用Claude Sonnet去进行实现。使用Windsurf也类似，基本使用的是Claude Opus或者是Gpt的最新模型。这里额外说明下，由于Claude封禁策略非常严格，本人也被封了好几个号了，我当前主要基于API中转服务来进行使用, WindSurf则是因为相对便宜的价格也一直在进行订阅使用。

Agent Coding场景

上面介绍了我本人对于大模型以及相关工具的一些看法，接下来我将对 Agent Coding 的不同应用场景进行介绍。

原型项目

Andrej Karpathy说的Vibe Coding, 我认为就是针对于这类项目。如果只是想展示一个网站效果给用户看或者只是一个Weekend项目比如写一个小游戏给孩子玩。这种一次性的项目你可以全权交给AI来进行实现，因为这类项目通常只需要关注最终效果。用户能看到成品的样子，游戏可以让你的孩子愉快地玩耍，这就已经达成目的了。说实话，这样子实现一个项目确实是最吸引人的（Ps:特别是对于非技术人）。但是也要注意现在的社交平台充斥着AI要代替某某类工作等引流的标题确实比较无语，希望大家不要被这种信息制造焦虑。AI至少到现在为止还不能代替一个专业程序员的工作，这类信息也就是为他们卖课进行虚假宣传罢了。

小型项目

这类项目很大概率是你的个人项目，相对来说项目的规模比较小，比如博客网站。我的这个网站就是基于Agent Coding开发的，这类项目和原型项目的最大区别就是你需要维护你的代码，对于项目的整体架构和功能必须了解，所以这类项目我在一开始的时候就制定了全局的Rule，在Claude Code中也就是Claude.md，在Windsurf类的编辑器中也可以制定对应的全局Rule。通过全局Rule指定了网站实现的技术栈、设计风格、主要功能、代码风格等，完成规则的制定之后再让AI进行代码的实现。

在当前模型能力的加持之下，基本上不用对代码做任何改动，AI绝大部分都是按照我的Rule来进行代码生成的。并且每完成一个功能，我都会对代码进行Code Review,所以项目的整体结构和代码实现还是比较清楚。当然，实现完之后还是使用AI进行了比如页面样式、交互逻辑等的调整。

总体来说，这类小型项目由于规模和代码比较小，所以不论是从0到1还是功能修改，AI都可以比较好地理解意图。但当项目规模扩大、上下文变复杂时，模型理解偏差的问题会明显增加。

大型项目

这类项目遇到最多的应该就是公司类的项目，一般项目的规模比较大，代码比较多。之前我就吃过这个亏了，再开发了个人博客之后我就想在公司项目进行Agent Coding练手，同样的我也首先给我项目进行了Rule的制定，然后告诉了AI改动点之后直接让它进行了代码的修改，最终的问题是：模型对需求理解出现偏差，生成了大量结构混乱的代码，并且后续维护和修改都变得非常困难，后来只能代码回退重新进行修改了。

在小型项目中，直接让 AI 编码通常没有问题。但当代码规模变大、上下文变复杂时，如果缺乏明确的规则和流程，模型很容易出现理解偏差甚至产生大量幻觉代码。因此在实践中，我逐渐形成了一套结构化的 Agent Coding 工作流。

Agent Coding流程

为了解决大型项目AI幻觉的问题，我探索了一套基本的工作流：

1.规则制定（Rule）: 规则可以杜绝AI生成明显不符合标准的代码。规则主要分为Global级别和Project级别，Global级别适用于所有项目，比如设计方案必须有明确的依据严禁假设等。Project级别是针对特定项目地一些定制化规则，比如项目使用的技术栈、代码风格等(为了确保AI更好地遵守规划和上下文，社区还提出了MCP和Skills等工具来进行支持)。
2.项目方案(Spec)：这部分是告诉AI当前要做的功能是什么，为什么要这么做以及必要的注意事项, 必须将功能涉及到的相关的上下文提供完整，这一步非常重要。本质上AI出现幻觉的绝大部分原因都是上下文给的不够精确导致的，必须时可以额外标注让AI务必遵守指定的Rule。
3.详细功能规划（Plan）: 这部分包括具体的技术方案设计、业务方案设计、数据结构的设计等。 Plan中包含的是针对于功能具体实现思路，如果不正确的话必须及时进行纠正。注意如果是功能修改，根据代码的复杂度需要判断是否应该先重构。
4.功能实现(Task)：制定好Rules、Spec、Plan之后，注意让AI不要一次性实现所有的功能，必须进行小步迭代，按一个个小功能去实现，现在的Agent Coding Tool一般都支持将Plan拆分成一个个Task去实现。每一步完成之后及时通过Git提交代码做好版本控制，或者可以有效地利用好Worktree比如让不同的模型去实现同样的功能然后进行选择。
5.代码测试(Test)：AI生成代码必须经过严格的测试才能上生产，所以对于每一个task实现的功能都需要进行自动化的测试（情景或者单元测试），并且对于生成的代码质量也要进行Review。对于测试不同的场景差异性可能比较大，对于前端可以利用Playwright MCP进行自动化测试，对于后端可以让AI生成具体的单元测试用例来验证数据的正确，找到一套合适的验证机制即可。

随着功能的持续迭代，需要及时更新 Spec 中的内容，同时也需要让 AI 同步更新对应的 Plan 和 Task。对于复杂项目而言，当前的 Agent Coding 本质上仍然是一种 Human-in-the-loop 的协作模式。开发过程中，人主要维护的是 Spec 这一层的上下文与约束信息。在我的实践中，如果功能发生变更，我会在 Spec 中追加新的内容，并明确标注版本变更记录，以确保后续生成的 Plan 和实现逻辑始终基于最新的需求上下文。

目前社区也有一些开源项目，对类似的 Agent Coding 工作流进行了更加规范化的抽象，例如spec-kit、OpenSpec等。这些项目对 Spec → Plan → Task → Implementation 的流程进行了结构化设计，可以根据自身项目需求进行参考和扩展。

展望

当前无论是 Claude Code、Windsurf 还是 OpenClaw，本质上都在弥补模型本身的两个问题：幻觉以及能力边界。

在我的设想中，真正的通用人工智能（AGI）应该具备接近通用的问题解决能力，而不是像现在这样依赖各种插件或工具来补充能力。最近比较火的 OpenClaw 在某种程度上已经朝这个方向做了一些探索，但距离真正意义上的通用人工智能显然还有很长的距离。

当前我们通过各种Agent Coding Tool来增强模型的编程能力，或者通过类似OpenClaw的项目扩展模型的通用能力。但随着模型能力不断迭代，也许未来某一天这些工具本身就不再那么重要，因为模型可能已经天生地具备了这些能力。

至于大模型最终能够发展到什么程度，现在没有人能够给出确定的答案。对我们来说，更现实的做法是持续学习，并不断调整与 AI 的协作方式。只有这样，才能在这波技术浪潮中保持竞争力。