AI辅助编程实战：在Vibe Coding与Spec Coding间找到平衡

在前期的探讨中，我们初步验证了与AWS的Spec Coding类似的规范驱动开发思路。该方法强调先输出精准的需求定义，待需求确认后再输出设计文档，设计确认后才展开具体的开发任务。关键阶段可引入人工评审与确认，有效降低了后期返工的风险。

在与技术社区交流时，了解到另一种思路——BMAD（Blueprint-Model-Assemble-Debug）过程驱动方法论。具体而言，其四个阶段分别是：

• B - Blueprint (蓝图)：在编码开始前，创建清晰的架构设计与实现计划。这包括定义项目结构、关键组件、数据流和接口。类似于建筑师的图纸，这一步有助于理清整体思路，让AI更好地理解项目全貌。
• M - Model (建模)：设计与定义核心的数据模型、类结构或算法逻辑。这一步聚焦于“做什么”，明确所需的数据结构与业务规则，为后续实现奠定准确的基础。
• A - Assemble (组装)：将各个组件组合起来，实现具体功能。这是实际的编码阶段，将蓝图和模型转化为可运行的代码。在与AI协作时，可将此阶段分解为多个小型、可管理的任务。
• D - Debug (调试)：测试、验证与优化代码。不仅包括修复缺陷，还涉及性能调优、代码重构和质量保证。

为了让思路更清晰，我们让AI对Spec Coding与BMAD两种方法论进行了简要比较：

同时，AI也对两种方法论的适用场景给出了建议：

简单总结：BMAD是一种流程导向的方法论，强调开发的完整性与阶段性控制；而Spec Coding是一种规格导向的方法论，强调需求的精确性与可验证性。两者并非互斥，在实际项目中可根据需要结合使用。

更直观地理解：对于一个10人左右、开发中等规模系统的团队，我们更倾向于推荐BMAD方法论。因为它能在前期更好地进行架构蓝图规划与人员分工，这正是其过程导向优势的核心体现。但随之而来的问题是，在AI辅助下，过多的过程跟踪与管控细节可能会削弱AI的自主性，影响整体开发效率。

这引出了一个根本性问题：在软件开发中，我们究竟该选择类似Vibe Coding（仅需清晰需求描述，后续过程全权交由AI）的极简方式，还是采用BMAD+Spec这种过程与规范驱动的重型软件工程方法论？

关键在于：AI工程化应避免走向两个极端。一端是过于简化的“一句话Vibe Coding”，另一端是过度文档化的“Spec Coding强规范”，后者可能因流程繁琐而丧失AI的高效优势。

举例说明：一份仅有一页纸的需求文档，交给团队内部的成员A或B开发，最终成果可能大同小异。但若交给外部技术能力相当的不同开发者，结果可能千差万别。若想获得一致效果，可能需要将需求文档扩充至5页甚至10页，这 reminiscent of 早期的离岸外包模式。

因此，真正的解决方案在于找到一种最适合特定项目或团队的方法。目标是：需求仍为一页纸，但AI产出的效果能与内部团队成员媲美。这涉及到团队内部“规则”（Rules）的定义与“Claude.md”等规约文件的制定。重点不是将文档扩展至5页以求AI的精确执行，而是形成一套最适合本团队的、内化了共同经验的轻量级模板。

我们需要在人工对关键节点的粗粒度管控与最大化释放AI能力之间取得平衡，而非退回传统软件工程的繁琐老路。AI编程不应追求普适的“大一统”标准方案，而应致力于构建面向特定企业或组织的垂直解决方案，将团队已有的规范、标准、经验与约定俗成的规则深度融入。这才是符合实际需求的路径。

回顾前文所探讨的观点：AI时代个人的核心竞争力在于将隐性知识经验显性化的能力。同理，对于组织或团队而言，整体开发能力与效率的提升，必然体现在将团队共性经验显性化、沉淀并有效输入给AI的能力上。这既能满足精确性控制的要求，又规避了传统软件工程的流程陷阱，是AI时代真正需要的软件工程实践。

大模型与AI工具本身是基础，但最终，那些善于进行知识萃取并将其显性化为高效团队规范的技术团队，才更有可能在AI时代脱颖而出。