我写了十年代码，直到AI出现

此时此刻，你可能已经听说过"vibe coding"这个术语。

这通常与零编程、仅通过一系列编码代理指令来构建应用和网站的想法相关联。

所以现在每个人都是开发者了……对吧？

错了。

软件开发中有很多东西无法塞进几个文本提示中。

当然，传统编程正在消亡。Vibe coding极其危险。真正的优势现在属于将AI与真正工程判断相结合的开发者。

在这篇文章中，我想从一个多年构建软件的人的角度，解释传统编码、vibe coding和agentic coding之间的区别。

我还会分享我个人关于使用和偏好哪种工作流程的想法。

在深入细节之前，我认为分享我的背景和经验很重要。我是一名拥有超过12年经验的软件开发者。我的大部分工作经验在C++领域。你可以在Credly上验证我的专业认证，或者在LinkedIn上查看我所有的认证。

我这不是在吹嘘。我只是想说明，我分享的不是编造的论点，也不是复制粘贴的AI垃圾。

好吧，让我们深入细节。

1、传统编码

让我们从一个例子开始。

在我作为软件开发者的早期，大约2014年到2020年，在编码代理被广泛使用之前，我大部分代码都是手写的。

那时我在日本工作，为一家知名笔记本电脑品牌做的一个项目是Windows设备驱动发布自动化系统。

它的工作方式相当简单：当新版本的设备驱动准备好时，系统触发远程构建，执行自动化测试，提取发布包，准备所有必要文档，并通知组件负责人处理正式发布。

是的，听起来可能很简单，但实际项目花了5人团队大约3个月才完成。

凭记忆，我们的时间线大概是这样的：

• 规划+文档：2周
• MVP准备：2周
• 构建实际系统：6周
• 测试+bug修复：1周
• 部署+交接：1周
  

这就是传统编码痛苦的地方。

它给你完全的控制权，但很慢。你需要规划架构，编写代码，测试行为，修复bug，准备文档，并确保整个系统在别人使用时不会出问题。

我们每天花一个小时开会，确保所有人和事都与进度保持同步，并确定下一步行动。

传统编码还有人们谈论得不够的另一个方面：人为错误。

我记得几年前，当我把一个项目交给一个初级开发者时，他不小心把.env.local文件提交到了一个公开仓库。那个文件包含API密钥、数据库URL、私人凭证或其他敏感值。

那是一个巨大且严重的安全问题。

在当今的AI编码工作流中，特别是使用Claude Opus 4.7这样的模型，如果系统配置得当，这种错误不太可能发生。团队现在可以构建自己的约束、规则、检查和子代理，以提高开发过程的安全性和可靠性。

当然，AI不会神奇地消除所有风险。但与手动完成所有工作的旧方式相比，差异是巨大的。

2、Vibe coding

如果你在使用Lovable、Bolt或Google AI Studio等工具来构建应用，那么你已经知道vibe coding是什么以及它是什么感觉。

你对一个软件有了一个很酷的想法，然后你在提示框中描述它。AI在后台施展魔法，然后给你发送一个打包精美的应用，前后端都已实现。

想添加新功能？只需告诉AI，它会在几分钟内交付。

想修改应用的外观和感觉？简单。只需描述更改。

想把应用发布到互联网上？只需点击几下。

但如果我问你，作为一个零编程经验的vibe coder，你能回答这些问题吗？

• 你能在Neon、Supabase、Firebase和MongoDB之间为你的应用选择最佳数据库吗？
• 你的项目正确的CI/CD设置是什么？比如：Warp → GitHub → Vercel？
• 当应用在本地预览中工作正常但部署后就崩溃时，你如何调试生产环境问题？
• 什么是适合你应用的最佳支付平台、邮件API或文件存储服务？
• 你如何保护自己不交付表面看起来不错但实际很糟糕的东西？
  这些只是会让一个完全不知道代码如何运作的vibe coder感到困惑的部分问题。

你看，在构建应用时，你仍然需要了解可用的工具和库。更重要的是，你需要知道哪个最适合你的项目。

你不能把每一个决定都委托给AI代理，然后希望它做出正确的选择。它的倾向是选择最容易、最熟悉或与你使用的平台最相关的东西。

例如，如果你使用Lovable，系统通常会引导你使用Supabase作为数据库。如果你使用Antigravity，它可能会引导你使用谷歌自己的Firebase平台。这些都不是糟糕的选择。事实上，两者都是很好的工具。问题不在于工具本身。问题在于不理解权衡就盲目接受决定。

AI可以帮助你更快地前进，但你仍然需要足够的技术判断力来知道它的选择何时合理，何时不合理。

这就把我们带到了另一种软件开发方法——agentic coding。

3、混合工作流（Agentic coding）

过去3年我一直在使用agentic coding。

我构建和上线了像Flux Labs AI、Zeniteq、BloggFast和DemandHunt这样的Web应用。我的GitHub上还有十几个正在进行中尚未发布的项目。

我已经尝试了市面上大多数流行的AI编码工具。VS Code、Cursor、Antigravity、Warp、Codex、Claude Code、Cline等等。

但有一件事我个人会避免，那就是使用完全在远程服务器上运行的AI编码工具，比如Lovable、Bolt或Emergent。

我并不是说它们是糟糕的工具。它们很好，特别是对于想快速构建东西的初学者或非技术用户。但对于硬核程序员来说，我仍然更喜欢本地文件、本地控制和对源代码的直接访问。

Agentic coding与简单地让AI工具生成一小块代码不同。它更像是与一个AI开发者在你的项目中一起工作。代理可以读取文件、编辑代码、运行终端命令、检查错误、安装包、编写测试，并在代码库的多个部分进行修改。

这里有一个图表可以帮助理解区别：

• Vibe coding依赖直觉、自然语言提示和快速迭代，开发者保持深度参与。
• Agentic coding使用自主AI群体或代理，它们与文件交互、运行终端命令，并以最少的人工干预解决多步骤问题。
  回到我之前分享的设备驱动发布自动化项目，如果我有机会使用agentic开发方式在今天重建它，我坚信我可以在不到一周的时间内独自完成。

当然，不实际重建系统我不能保证。但凭借我对合适的库、工具和外部服务的知识，加上现代编码代理的力量，时间线会完全不同。

我还相信代码质量会比我最初发布的版本更好。

不是因为我突然变成了天才开发者，而是因为现代AI编码工具已经非常擅长处理重复性实现工作、检查模式、修复错误，以及比我快得多地在代码库中穿梭。

如果有人告诉你写代码时不要使用AI，那是胡说八道。

不要听他们的。

他们是最后一批仍然无法放下骄傲、接受AI已经在改变软件构建方式的人。

4、我更喜欢哪个？

还需要多说吗？当然，我更喜欢agentic coding（在我的监督下）。

我喜欢它，因为我对源代码保持控制。我可以直接添加、修改和删除文件。我可以审查每一个更改。我可以运行测试。我可以检查diff。我可以在坏代码到达仓库之前拒绝它。

所有文件都保存在我的本地磁盘上，这也给了我额外的安全层。我可以使用自己的环境、自己的工具和自己的项目结构。如果需要，我甚至可以在失去互联网连接或想要私下测试时切换到本地模型开发。

当使用本地文件时，集成Vercel、Cloudflare、GitHub、Neon或我想要的任何服务也容易得多。

我不受远程AI应用构建器想让我使用的任何技术栈的束缚。

这是我的工作环境的样子：

我在Warp中使用Claude Code。Claude Code配合Opus 4.7是我使用过的最可靠、最有能力的代码生成设置之一。我使用Warp是因为它速度快，并提供了我需要的现代基于终端的开发环境功能。

我也喜欢使用Codex，因为OpenAI的GPT 5.5模型在token限制方面很慷慨。每当我在Claude中用完token时，我就切换到Codex。

不过Codex的一个缺点是它消耗大量内存。它会让我的机器很快变慢，特别是在大型项目中。这是我一直更喜欢基于终端的环境如Warp的另一个原因。它感觉更轻、更快、更容易控制。

当然，你可以自由探索其他AI开发工具，如Google的Antigravity、Cline、Cursor或VS Code。市面上有很多，每一个都有自己的优势。

6、什么时候该用AI编码，什么时候不该

说了这么多，我认为可以问一个公平的问题：你什么时候应该用AI编码？

我的简单回答是：当你已经了解项目的方向、涉及的工具和期望的输出类型时，使用AI。不要把AI当作思考的替代品。把它当作力量倍增器。

当你需要快速推进时，AI编码工具极其好用。例如，如果你正在构建原型、MVP、落地页或管理后台，AI可以为你节省大量时间。这些是结构已经已知的任务类型。你知道应用应该做什么。你知道可能涉及哪些文件。你知道如何测试输出是否工作。

但到最后，你仍然需要审查输出。

AI可以写代码，但你仍然拥有结果。如果应用在生产环境中崩溃，不是AI去跟客户解释。是你。如果支付流程失败，如果数据库泄露数据，如果应用的权限出了问题，你才是负责的人。

对于系统的关键部分——认证、支付、数据库迁移、权限逻辑、安全规则、用户数据处理和生产基础设施——不要盲目使用AI。

我不是说AI不能帮助处理这些。它可以。但你永远不应该在不仔细检查的情况下接受这些更改。

以下是我从多年经验中观察到的一些常见问题：

• 缺少验证
• 安全规则薄弱
• 密钥泄露（.env.local被暴露）
• 糟糕的数据库设计
• 错误处理有缺陷或根本不存在
  经验法则是：如果你无法解释生成的代码是如何工作的，就不要发布它。

你不需要记住每一行，但你应该理解流程。你应该知道数据从哪里来、到哪里去、涉及哪些服务，以及出现故障时会发生什么。

另外，当AI开始修改太多文件时要小心。这种情况经常发生，特别是如果你使用的是较弱的编码模型。你要求一个小修复，突然它修改了十个文件，添加了辅助函数，更改了依赖项，并重写了已经正常工作的逻辑。

当这种情况发生时，停下来。审查diff。还原不需要的更改。

AI编码很强大，但只有与真正的工程纪律结合时才如此。仅仅提示是不够的。

所以什么时候该用AI编码？在它能帮助你更快推进而不会让你变得盲目的时候使用它。

什么时候不该用？当你还没准备好为它产出的结果承担责任时，不要使用它。

对我来说，这就是界限。

7、结束语

就是这样。我从个人作为开发者的视角解释了传统编码、vibe coding和agentic coding之间的区别。

传统编码给你基础。Vibe coding给你速度。Agentic coding给你杠杆，特别是当你已经知道软件如何运作时。AI格局也在快速变化，所以我会继续关注日常发展，并准备好在事情再次改变时适应。

那么你到底应该使用什么？

如果你有零编程技能或经验，先去学习程序是如何工作的。学习构成完整软件应用的库、框架、服务和工具。这里没有捷径。你不能只是给AI代理一个高级指令，就期望一切都能完美运行。不，它不是那样工作的。

至少花你20-30%的时间学习你使用的技术栈。当出了问题、当AI做出错误决定、或者当你需要理解为什么一个工具比另一个更好时，这将会有回报。

另外，我很感谢那些推动技术边界的公司。我从一个底层工程师起步，但AI把我推到了更高层次的工程，说实话那有趣得多。过渡很顺利，因为我已经掌握了基础知识。AI并没有神奇地让我成为一个更好的开发者。它只是碾压了大量以前拖慢我的技术壁垒。

原文链接：我写了十年代码，直到AI出现 - 汇智网