Vibe Coding 的力量：六个月如何改变了我的开发方式

六个月来，我几乎一直使用vibe coding。最初，我对那些声称要让我的核心职业消失的工具持怀疑态度：分析程序员。然而，随着时间的推移，我学会了欣赏它们，了解它们的局限性，最重要的是，衡量它们在管理得当时真正能带来什么。

01我的第一个POC：漂亮的外观是不够的

我的第一个 POC 重点关注我完美掌握的主题：我已经开发了数十次的功能，并且我几乎总是根据相同的原则实现这些功能。创建客户档案就是一个很好的例子。

起初，我的提示非常基本：为我创建一个客户端管理应用程序。对于不熟悉开发的客户来说，结果可能看起来很棒。门面很干净，程序也有效。

但当我打开盖子时，我发现了与一年级计算机科学实习生的代码相当的代码：功能齐全，但难以维护，并且与专业应用程序的预期标准相去甚远。

因此，我的以下测试更具指导性：

我想要一个三层的架构。对数据库的访问必须通过 API 来实现。使用专业的技术堆栈，限制不必要的依赖项，并尽可能避免使用 Python。

通过这种类型的指令，结果变得更加有趣。我开始明白，只要我为它提供精确的技术框架，我就可以真正利用该工具。

02使用本地模型降低成本

经过这些初步测试后，合乎逻辑的下一步就是寻求降低成本。 Codex 或 Claude Code 等系统基于使用配额，当项目链接在一起时，这些配额很快就会变得受到限制。

于是我用LM Studio和Ollama在本地测试了几个模型。第一个结果令人鼓舞，但我很快就遇到了一个重要的限制：上下文的大小。

启动时，一切都很顺利。随着项目的发展，代理开始循环，忘记某些决策或不断压缩其上下文。

一种解决方案是使用参数较少的模型来为上下文释放更多内存。不幸的是，推理水平通常不足以满足复杂开发任务的专业用途。

我的结论是，自托管解决方案尚未系统地达到此用途的标准，即使定期测试它们仍然很重要。

出于专业目的，我的客户购买了一台 DGX Spark，其 CPU 和 GPU 之间共享 128 GB 内存。上下文限制少得多，但某些开发任务仍然特别长。

然而，我对这一观察进行了限定：在撰写本文时，我主要在超反射模式下使用GPT-5.6 SOL。它也可能很慢，但从第一次启动起获得的结果通常是正确的。

03从POC到专业用途

我的第一个真正的专业用例是将使用 WinDev 开发的 API 项目迁移到另一种技术。我将在以后的文章中更具体地讨论我的方法。

PC SOFT 使用其应用程序服务器的费用。去年，该许可证的成本翻了一番，但在我看来却没有足够大的变化来证明其合理性。

所以我决定改变技术栈，同时利用操作来纠正应用程序中存在的错误。凭借我对该项目的功能和技术知识，我能够精确地指导代理。

大约两个小时后，迁移完成。用另一种语言开发的新 API 继续通过 ODBC 驱动程序使用现有的 HFSQL 数据库，同时现在在 Linux x64 环境中运行。

经过第一系列手动单元测试后，我想知道Codex本身是否可以自动验证所有 API。于是我问他：

在我的 API 上启动测试活动，为我提供一个 Excel 表格，列出所有执行的场景并纠正检测到的故障。

那天，我得到了第二个大惊喜。系统识别出我没有怀疑的异常，纠正了故障，然后将更改发布到服务器。

几乎作为 POC 启动的实验刚刚成为真正的质量控制步骤。

04用Gitea替换GDS

此时，我的新项目正在生产中运行，但我失去了常用环境中的一个重要元素：GDS，PC SOFT的源代码管理器。

在研究了几种解决方案后，我选择在 Docker 容器中部署 Gitea。 Gitea 基于 Git，并提供一个 Web 界面，允许您查阅存储库、历史记录、分支和文件，如 GitHub，同时保持自托管。

我将我的源代码推送到存储库中并找到了一个完整的版本管理器。我仍然缺少文档。

然而，人工智能工具对于生成 Markdown 文档特别有效，而且 Gitea 知道如何在其界面中本地显示它们。

只需几个步骤，我就发现自己拥有了比我使用了十多年的 GDS 更完整的源代码和文档管理器。

05我的开发规则Markdown文件

和许多开发人员一样，我坚信“最少的努力”。在每次干预之前写下完美的提示是有效的，但特别重复。

因此，我创建了一个 Markdown 文件，描述了代理在开发过程中必须遵守的所有规则。

该文件特别规定：

• 根据项目的性质优先考虑的架构；
• 严格的数据建模，受到 Merise 的启发；
• 前端、API 和数据层之间的明确分离；
• 创建可重用的视图和组件；
• 继承和多态性的相关使用；
• 线程、事件或观察者老板的执行何时合理；
• 使用异步调用来避免不必要的重新加载；
• 限制不必要的库和难以维护的依赖项；
• 使用数据库时的备份和恢复；
• 配置端口和运行时设置的能力。

这些最终是我们日常应用的原则，但其形式化通常需要漫长的架构阶段。

一旦记录在参考文件中，这些规则就成为代理人和我之间的一种技术合同。

06AI总是寻找最短路径

我谈到了一个特别贴近我心的主题。当我只是要求人工智能创建一个程序，而不让它明白我是一个开发人员并且我期望一个可维护的结果时，它通常会选择最快的路径来实现目标。

另一方面，当我对它施加架构、质量、安全和操作规则时，它就成为一个非常高效的开发人员，我可以指导它实现特定的结果。

这就是vibe coding真正强大的地方。并非每个人都是开发人员。我们学习过，积累过经验，做过成功的项目，也做过其他更困难的项目。

这种专业知识使我们能够区分简单的功能演示和真正可用的应用程序。

AI不会删除这个值。相反，它使我们能够使用它为客户提供以前难以获得的架构、工具和自动化水平，即使他们的预算有限。

07从vibe coding到AI驱动开发

现在回想起来，我今天的练习已经不再真正符合vibe coding有时所传达的即兴意象。

我不再简单地要求人工智能生成应用程序。我为它提供目标架构、开发约定、安全规则、测试程序和操作约束。

我的角色逐渐接近领导虚拟团队的架构师或技术经理的角色：我定义框架，我控制选择，我验证结果，并且我仍然对交付的内容负责。

08现在呢？

今天，我将所有 WinDev、WebDev 和 WinDev Mobile 应用程序转换为其他技术。

下一个项目将是逐步迁移仍持有维护合同的客户的应用程序。

那是另一个故事了：有必要管理现有的依赖关系、用户习惯、生产环境、数据恢复和合同承诺。

这可能是未来系列文章的主题。