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 的 Ultra 推理模式。它同样可能很慢，但往往第一次执行就能得到正确结果。

03从 POC 到专业用途

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

PC SOFT 会对应用服务器的使用收费。去年，这项许可证价格翻了一倍，但产品变化在我看来不足以解释这样的涨幅。

因此，我决定更换技术栈，并趁机修复应用中已有的缺陷。凭借对项目业务与技术细节的了解，我能够准确地引导智能体。

大约两小时后，迁移完成。新 API 改用另一种语言开发，仍通过 ODBC 驱动访问现有 HFSQL 数据库，并开始运行在 Linux x64 环境中。

完成第一轮手动单元测试后，我想知道 Codex 能否自动验证全部 API，于是给出了下面的任务：

对我的 API 执行一轮测试，生成一份列出所有测试场景的 Excel 表格，并修复发现的问题。

那天，我遇到了第二次真正的惊喜：系统发现了我此前没有察觉的异常，完成修复，并把改动发布到服务器。

一个原本接近 POC 的实验，就这样变成了真正的质量控制环节。

04用 Gitea 替换 GDS

此时，新项目已在生产环境运行，但我失去了原有工作方式中的关键工具：PC SOFT 的源码管理器 GDS。

比较多种方案后，我选择在 Docker 容器中部署 Gitea。它基于 Git，提供类似 GitHub 的 Web 界面，可查看仓库、历史、分支和文件，同时保持自托管。

把源码推送到仓库后，我重新获得了完整的版本管理能力，但文档仍然缺失。

AI 工具尤其擅长生成 Markdown 文档，而 Gitea 可以在界面中原生展示这些文件。

只经过几个步骤，我就拥有了一套比过去使用十多年的 GDS 更完整的源码与文档管理环境。

05我的开发规则 Markdown 文件

和许多开发者一样，我也希望减少重复劳动。每次操作前重新写一份完美提示词虽然有效，却非常机械。

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

这份文件主要规定：

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

这些原则本就是日常开发中的常规要求，只是过去往往要经过较长的架构阶段才能完整写出来。

一旦写入参考文件，它们就成为智能体与我之间的一份技术契约。

06AI 总是寻找最短路径

这里涉及一个我非常重视的问题：如果我只是让 AI 创建程序，却没有说明自己是开发者、也没有要求结果可维护，它通常会选择最快的实现路径。

相反，一旦明确架构、质量、安全和运维规则，它就会成为效率很高的开发力量，并能被引导到准确目标。

这正是 Vibe Coding 真正强大的地方。开发者接受过训练、积累了经验，也经历过成功与困难的项目，这些积累不会因为 AI 出现而消失。

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

AI 不会抹去这种价值，反而让我们能够在客户预算有限时，也提供过去难以触及的架构、工具和自动化水平。

07从 Vibe Coding 到 AI 驱动开发

回头看，我现在的做法已经不太符合 Vibe Coding 常给人的即兴开发印象。

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

我的角色越来越像带领虚拟团队的架构师或技术负责人：定义框架、审核选择、验证结果，并对最终交付负责。

08现在呢？

目前，我已经把自己的 WINDEV、WEBDEV 和 WINDEV Mobile 应用迁移到其他技术栈。

下一阶段，是逐步迁移那些仍在维护合同范围内的客户应用。

这会是另一类挑战：必须处理既有依赖、用户习惯、生产环境、数据迁移和合同承诺。

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