AI年代：低码+Vibe Coding，以文档为中心的DADD模式介绍

低代码平台因为可以较大的提升开发效率，在企业开发应用中的占比越来越高.。但随着AI大语言模型的逐步成熟，Vibe Coding异军突起，一时间，Vibe Coding好像有席卷开发场景的趋势。本文分析了双方各自的优劣，并且提出了下一代软件开发的“混合体系”DADD（Document& AI Driving Develop），与大家一起分享与探讨。

继续我们的上一个话题，企业级软件开发是否可以使用Vibe Coding，我们先列出一个大家比较一致的看法：

企业级系统往往不需要特别高深的编码技巧，我们称之为生产力编程，与AI的Vibe Coding相比，有着很大的差异：

在吸取了低代码开发的规范和效率之后，我们设计了一个新的开发体系，在一个严格的框架中引入了Vibe Coding，充分考虑了AI大语言模型的发展未来，建构了一个被称之为文档+AI驱动开发的模型，简称 DADD（Document& AI Driving Develop）。

在该体系中，我们认识到，AI已经有足够的阅读和理解能力，能够在良好的文档指引下构建包括文档自身在内的所有系统，通过低代码框架的约束，加强了边界的管理，将系统进行解耦，各司其职，利用低代码框架的强壮性和灵活性，加上Vibe Coding的高效，来构建新一代的企业编程最佳实践。

一句话概括：AI专注于文档构建和实现文档描述的“功能，而低代码则专注于开发管理和工程化部署与迭代。

在这个模式中，企业级软件开发的所有工作重点从代码转移至橙色的“软件结构化文档“：

1、 构建资料库，包括需求文档、历史需求文档、企业知识库中的业务说明、业务约束、审计的合规要求等，

2、 通过大语言模型，自动的生成格式化的详细设计，并放置入结构化文档库中。结构化文档库是一个能够被AI读取和识别的标准结构。

3、 Vibe Coding 工具读取对应的开发文档。

4、 Vibe Coding 在开发文档（需求）的基础上，叠加企业开发标准，开发规则，以及低代码平台的规范，生成指定模块的代码，并放入指定的文件目录。

5、 自动化测试的Agent同样读取对应的开发文档

6、 自动化测试的Agent生成测试用例、测试脚本

7、 自动化测试调用脚本在低代码平台进行测试

8、 测试结果回到测试平台。

9、 自动化测试Agent针对测试结果再次调用Vibe Coding工具，进行迭代。随着AI能力的进一步提高，这一步的自动迭代就回归到传统的TDD（Test Driving Develop）开发模式。

10、 结构化文档平台可以随时看到目前的模块和功能结构，以及开发进度

结构化文档的树状结构示例：

针对企业最头疼的屎山代码重构问题，也可以用AI读取旧系统代码并生成结构式文档的方式，用极低的成本，进行快速评估，从而协助技术人员在风险和成本收益之间快速找到平衡。

另外，模块和功能的复用这个Vibe Coding的难题，我们通过在文档系统中人工指定来解决，AI也可以协助筛选类似的需求和子功能来给出复用建议，这部分可以和低代码平台实时同步：

Vibe Coding的功能被精简为：按照清晰的文档和边界，在约束规则下生成小规模的代码，大大减少了不确定性。

通过构建这样一套体系，我们的开发组织体系，也随之发生了变化：

采用了这种混合体系之后，我们为低代码平台插上了AI的翅膀，又弥补了Vibe Coding针对大型系统的各种现实问题：

我们拥抱AI，拥抱变化，通过成熟低代码系统的连接，使得AI的长处得以发挥。通过在低代码平台之上构建一个新的结构化文档中心，以文档作为AI与代码间的“法定语言“，带来了更高的普适性，并充分发挥了大语言模型的能力

DADD（Document& AI Driving Develop）模式，进一步解放了开发人员的生产力，直接提升了DevEx（开发者体验），如果我们说开发人员是一个一个优秀的工匠，AI就变成了随时随地在边上跑腿递工具的助手，把重复性的枯燥工作交给AI，工匠们可以集中精力在结构、复用、性能优化等更有挑战性的工作上，把流程开销的成本降至更低，整个开发过程更加透明，甚至业务部门都可以清晰的了解开发的进程，在降本增效的企业级软件开发的大环境下，更加有着深远的意义。

综合来看，成功的企业级软件开发，其核心并非单纯追求代码层面的“炫技”，而是遵循一套系统性的法则，以确保软件资产的长期价值。这些法则构成了我们评估任何新技术或新范式的基准：

1. 复用与协作：企业业务规则极其复杂，不同的人有不同的理解。最大化地复用经过验证的业务组件、服务和逻辑，是降低沟通成本、保证逻辑一致性的最有效手段。无论是初次开发、后续测试还是功能迭代，高复用性都能带来指数级的效率提升。

2. 效率与节奏：企业级开发追求的不是绝对的“快”，而是一种可预测、有节奏的交付能力。通过锁定开发流水线和标准化流程，可以最大限度地减少不确定性，让开发变得有计划性。关键在于，你是否能在承诺的时间内，交付符合质量标准的产品。

3. 快速定位问题（需求与代码的映射）：业务的敏捷性要求技术能够快速响应。当业务部门提出一个微小的迭代需求，例如“在审批环节增加一个风险控制点”，系统必须能够支持快速定位到对应的代码或配置，并进行精准修改。这种外科手术式的修改，远比基于个人“Vibe”的全盘重构或修改更高效、更安全。

4. 解耦：企业是活的有机体，其组织架构、部门职能、业务流程会随着战略进行频繁调整。软件系统必须具备高度的解耦能力，以适应这些变化。

• 案例：并购与整合。假设某企业并购了上游的一个重要合作伙伴，企业的系统需要多久才能将新并购企业纳入统一的数字流程？一个高度解耦、组装式的系统可以快速完成整合，将以前外部协作的“不确定性”变为内部流程的“确定性”，从而实现显著的降本增效。
• 案例：剥离与分拆。反之，假设某企业将一块原有业务剥离，变为独立核算的组织，系统需要多久才能将其安全、完整地分拆出去？这要求将原本封闭的内部流程改造为开放的、基于标准接口的协作模式，这对系统的解耦能力和灵活性提出了极高的挑战。

5. 严格的需求管理：与消费级应用不同，企业级软件的需求往往来自多个业务部门，且相互关联。建立严格的需求评审、分析和管理制度，是确保项目不偏离航向、避免后期大规模返工的基石。

6. 运行效率优化：业务的成功往往伴随着数据量和交易量的爆炸式增长，这必然带来性能问题。系统必须具备良好的可观测性，能够快速定位性能瓶颈并进行针对性优化。

7. 软件服务于业务：最后也最重要的一点，软件永远是工具，其最终目的是为业务创造价值。任何技术决策，都必须回归到“它是否能更好地支持业务目标”这一根本问题上。

在成功实施了以文档为中心的开发模式后，企业不仅优化了当前的软件交付能力，更重要的是，踏上了一条通往未来软件创造方式的演进之路。