49 lines
4.0 KiB
Markdown
49 lines
4.0 KiB
Markdown
# 版本历史
|
||
|
||
## 以前的版本
|
||
|
||
- [版本3](https://github.com/bmadcode/BMad-Method/tree/V3)
|
||
- [版本2](https://github.com/bmadcode/BMad-Method/tree/V2)
|
||
- [版本1](https://github.com/bmadcode/BMad-Method/tree/V1)
|
||
|
||
## 当前版本：V4 - Alpha
|
||
|
||
V4的指导原则：
|
||
|
||
- 简单易懂，易于安装和开始使用
|
||
- 支持绿地和棕地场景
|
||
- 更大的可配置性和更多的使用场景 - 但为了保持简单性而将其保留在主包之外
|
||
- 为安装程序和Web构建器提供帮助程序，可轻松与任何操作系统和IDE配合使用
|
||
- 使所有代理在IDE和Web上保持一致，而不会失去Web版本的功能，也不会减少IDE中文件的精简以减少上下文
|
||
- 进一步改进两个最重要的代理 - SM和DEV
|
||
|
||
## V3
|
||
|
||
尽管V2具有可定制性，但仍存在一些问题。PM只能轻松地做一件事，即创建PRD。而且，在Web和IDE代理之间保持一致性是一件痛苦的事情。
|
||
|
||
V3没有解决脱节问题，但它确实使在单个文件夹中维护所有内容变得更容易，但只有两个官方的ide代理 - 所有其余的都是为Web真正制作和优化的。
|
||
|
||
V3最大的影响是可定制性的全面爆发。任务、角色、代理配置、文档模板、数据有效载荷。
|
||
|
||
但是 - 最大的变化是意识到我们仅仅触及了可以加载到Gemini Gems中并仍然进行非常长时间聊天的表面。BMad代理应运而生，随着一个V3版本的发布 - BMad方法的未来被永远改变了。
|
||
|
||
现在，不再需要配置4个以上的Web代理，所有这些代理都需要上传许多文件来创建它们，一个名为BMad的单一代理，拥有整个团队，并且能够切换和维护角色。现在，您可以在同一个聊天线程中与整个团队或团队中的任何人交谈。不再需要在不同聊天之间导出和重新导入文档 - 突然之间，您可以完成PRD，并要求Josh将其交给架构师，就这样，架构师就拥有了它，我们继续前进！而所有这一切只需上传7个文件，即可提供所有功能。
|
||
|
||
但是V3有一个主要缺陷 - 巨大的配置带来了巨大的复杂性 - 在某些方面，V3开始偏离核心原则 - 通过简单实现强大。核心系统需要做好一件事并保持稳固，而不是用所有可能的东西来过度扩展。
|
||
|
||
此外 - 虽然dev在V3中非常出色并且比过去所有版本都好，但与SM一起 - dev开始过度记录每一步，并真正开始用自己的笔记来膨胀故事。而SM则忘记向故事中添加细节，或修饰信息。这在V3.1中有所修复 - 但dev仍然过度解释它所做的一切，而不是仅仅捕获对故事的更改。
|
||
|
||
## V2
|
||
|
||
在V1证明BMad方法是可靠且可重复的之后，出现了两个关键思想。关注点分离，以及使Web构建更容易。通过分离出模板 - 现在可以更容易地自定义PRD字段或架构。
|
||
|
||
在我看来，真正为一切注入活力的引子是Web版本！有4个硬编码的Web变体是手工制作的 - 我们看到，我们可以以极低的成本，在Gemini的巨大上下文中与代理工作数小时 - 从生成PRD的PM，到架构师，甚至是可以帮助我们进行广泛市场研究和头脑风暴的分析师。
|
||
|
||
我从未预料到的是，这些名字会保留下来，人们会继续使用我制作的我以为人们会配置的示例名称。但是现在4个版本过去了，人们仍然提到Mary、John和Bob！当我随机更改名字时，我收到了很多反馈！这些已经成为人们（包括我）依赖的值得信赖的盟友！
|
||
|
||
## V1
|
||
|
||
信不信由你（好吧，你可以查看链接），V1是一个简单的7文件系统！7个核心代理和谐地工作，帮助构建一种非常特定类型的应用程序。但它展示了它的力量和适应性。
|
||
|
||
旨在作为一个简单的技术演示，展示具有敏捷角色的自定义代理如何帮助简化您的项目，并为您的开发代理创建迄今为止无与伦比的轨道 - 同时还关注规划阶段 - 该项目激发了许多人的想象力，一个潜力的种子得以实现。
|