AI重塑软件工程05-避免走向两个极端

图片

大家好，我是人月聊IT。今天继续聊AI软件工程方面的话题。

在前面我简单的验证和AWS的Spec Coding规范驱动的开发思路，当时也谈到了里面的关键亮点，比如遵循了先输出精准的需求定义，在需求确认后输出设计文档，设计确认后再展开到具体的Task开发任务。中间关键阶段步骤可以人工进入Review和确认，减少了后期返工的概率。

图片

我在微信技术沟通群和大家沟通的时候，有些小伙伴采用的是BMAD的基于软件工程过程驱动的思路。简单来说即：

B - Blueprint (蓝图)在开始编码前，先创建清晰的架构设计和实现计划。这包括定义项目结构、关键组件、数据流和接口设计。就像建筑师在施工前画图纸一样，这一步帮助你理清思路，让AI更好地理解你的整体意图。

M - Model (建模)设计和定义核心的数据模型、类结构或算法逻辑。这一步关注的是"what"——你需要什么样的数据结构和业务逻辑。通过明确的建模，可以让后续的实现更加准确和高效。

A - Assemble (组装)将各个组件组合在一起，实现具体的功能。这是实际编码的阶段，把蓝图和模型转化为可运行的代码。在与AI协作时，这一步可以分解成小的、可管理的任务。

D - Debug (调试)测试、验证和优化代码。这不仅包括修复bug，还包括性能优化、代码重构和确保代码质量。

因此我又让AI对两种方法论进行了一个简单的比较如下：

同时对应两种方法论的使用场景选择也给出建议：

最后简单总结就是：BMAD 是流程导向的方法论，强调开发的完整性和阶段性。而Spec Coding 是规格导向的方法论，强调需求的精确性和可验证性。两者并不互斥，在实际项目中可以根据需要组合使用。

图片

再简单点来理解，如果是一个10人左右的团队要开发一个中等规模的软件系统，实际我们更加推荐BMAD方法论，因为该方法论在前期可以更好的做好架构蓝图规划，人员角色安排和分工。这是BMAD过程导向性方法论的核心优势。但是带来的问题也是相当明显的，就是会让在AI辅助下陷入太多的过程跟踪和管控细节，降低了AI的自主性和整体开发效率。

所以这个就回答了一个本质问题，即：

我们在软件开发的时候究竟应该选择类似Vibe Coding这种方法，只要需求描述清楚，后面所有过程完全不关心；还是采用BMAD+SPEC的过程+规范驱动的AI软件工程方法论？

所以在这里再次强调我的一个观点：

AI工程化不能走两个极端，一个就是一句话Vibe coding。一个就是Spec Coding强文档化或过重的文档化，丧失了AI的优势。

我举个例子大家就容易理解。

比如我现在有一个需求文档，只有一页纸，这个需求我给我团队里面的张三或李四做，实际做出来的功能，基本差不多。但是这个一页纸需求给另外两个不是你团队的，其他公司的，技术能力没有问题的人做，实际做出来千差万别。你如果要让外人做出同样效果，可能你的需求文档从1页要变成5页乃至10页。类似早期日本软件项目的离岸外包。

所以现在真正的最佳解决方案，是要找到一种项目或团队级最适用的方法，需求就1页，做到AI做出来和我找团队成员做一样的效果。这个就涉及到Rule定义，Claude.md文件规约。我要做的就是如何形成这么一套团队最适合的模板。而不是去找一个文档定义变5页纸，让AI精确做的方法。

既需要保证人工介入对粗粒度关键点的管控和审查，又不能还是倒回去走传统软件工程的老路，没有将AI本身的能力最大化发挥。AI编程不要去搞大一统的标准解决方案，而是应该做面向企业或组织团队的垂直解决方案，将团队已有的规范标准，经验技能，一些团队约定成俗的规则全部融入进去。这才是我们真正需要的解决方案。

大家再回顾下我前面一篇文章讲的内容，即AI时代个人的核心竞争力不是AI大模型和工具的使用，而是个人已有知识经验显性化的能力。那么转变到组织或团队的AI编程也是一样的道理，团队整体开发能力和效率的提升，一定是体现在团队整体将共性经验显性化沉淀并输入给AI的能力。既满足精确化控制要求，又避免了传统软件工程过于繁琐的过程陷阱。这才是AI时代真正需求的软件工程。

大模型还是那个大模型，AI编程工具还是一样的，但是最终懂得知识萃取并显性化为规约表达的技术团队最终才能够真正在AI时代胜出。

今天分享就到这里，希望对大家有所启发。