扁平AI工作流缺乏持久性和版本控制。可组合架构，如Bit和Hope AI，通过创建可重用、有文档、有版本的组件，将AI代码转化为可演进的模块化系统，实现长期价值积累和维护。
译自：The 4 Ways AI Code Is Breaking Your Repo (And How To Fix It)
作者：Laly Bar-Ilan
“不要让模型构建你的整个应用程序。将你的请求分解成更小的部分，一次生成一个函数、hook 或组件。”
如果你使用 Copilot 或 ChatGPT 等 AI 工具来编写代码，你可能已经听过这条建议。这是一条可靠的建议，因为更小的提示往往能产生更清晰的输出，并减少幻觉。它们还能让你更好地控制代码库中包含的内容。
然而，即使你的提示描述性极强，代码片段看起来也不错，这种工作流程最终仍会遇到同样的局限性。如果没有一个将所有内容联系在一起的总体架构，任何东西都无法大规模地连接。
每次你开始一个新的聊天时，你都在生成独立的、没有共享内存、版本历史或一致性的代码片段。一旦聊天结束，模型就会忘记它构建的内容。当你稍后回来扩展或重用该代码时，通常生成新代码比改进现有代码更容易。
那么，如果你的 AI 工作流程不必每次都从头开始呢？如果每个生成的函数、hook 或组件都有一个归宿、一个版本以及使用记录呢？
这就是可组合架构所能实现的。它为你的 AI 工作流程提供了一个结构，将每个生成的片段连接成一个活生生的系统。组件变得可重用、有版本且有文档，你的工作将不断积累，而不会随着每一次新的聊天而消失。
在本文中，你将看到遵循当前最佳实践提示会发生什么，以及为什么它在大规模应用时仍然会产生摩擦。你将学习可组合架构如何通过引入重用、版本控制和协作框架来弥补这一差距。你还将发现 BitCloud 和 Hope AI 如何通过搭建模块化组件使该系统实用化，这些组件能够超越单个项目而持续存在。
扁平的 AI 工作流程为何无法扩展
考虑一个 Copilot 生成的 React UserAvatar 组件。该片段在系统上有效且功能完整：
export function UserAvatar({ name, img, onClick }) {
return (
<button className="avatar" >
{img ? <img src={img} /> : <div className="fallback">{name[0]}</div>}
<span className="dot online" />
</button>
);
问题 不在于生成的 代码；而是缺乏一个组织它的系统。如果没有明确的工作流程来推进它，你最终会得到：
- 无持久性： 此组件仅存在于聊天会话中。除非手动保存或添加到仓库中，否则一旦会话结束，它就会消失，无法追踪且是临时的。
- 无版本控制： 每次调整或更改都会生成一个新片段，没有血缘关系。没有版本历史记录显示更改了什么或哪个版本是当前的。
- 无共享上下文： UserAvatar 不了解其他 UI 片段。重用意味着从头重新实现 props、类名或状态逻辑。
- 无架构连续性： 没有持久性、版本控制或共享上下文，就没有可供演进的基础。系统只会不断重新生成新片段，而不是基于之前的内容进行构建。
这些问题限制了 AI 代码的演进方式。如果没有保留上下文、版本历史和依赖关系的模式，AI 生成的代码就无法演进为可重用或可维护的模块。
可组合架构如何解决扁平 AI 工作流程问题
可组合架构 为 AI 生成的代码带来了其所缺乏的结构。每个功能块不再是会话结束后就消失的片段，而是一个带版本控制的模块，拥有自己的文档、测试和历史记录。持久性确保会话之间不会丢失任何内容。版本控制记录每一次迭代，使更改可追溯。此外，清晰的接口和依赖图为模块提供了共享上下文和架构连续性，确保系统作为一个有组织的库而不是一堆不相关的片段来成长。
扁平 AI 工作流程与可组合工作流程对比。
我们以电商 UI 为例。在可组合工作流程中，Button、Card 和 ProductTile 被定义并发布为独立的模块。一位开发者更新 Button 以改善键盘可访问性。在更改发布之前，系统会显示哪些组件依赖于 Button 以及哪些应用程序会受到影响。开发者打开一个更改请求，单独测试 Button 并在依赖组件中测试，标记一个新的次要版本，并发布它。Button 的使用者可以选择新版本或保留旧版本。
与此同时，一位设计师浏览组件库，查看现有的 Card 变体、使用示例和测试覆盖率。他们不是重新构建，而是扩展现有 Card 变体，并提交审核。库记录了更改历史、依赖图和已发布的版本，因此每次更改都可见且可追溯。
通过这种结构，更改通过清晰的契约和共享版本进行流动，将分散的片段转化为一个统一的系统，该系统随着每次更新而演进。
如何使用 Bit 搭建可重用组件
在 Bit 中搭建遵循提示驱动、架构优先的工作流程。以下步骤展示了如何在 Bit Cloud 中使用 Hope AI 来搭建、组织和管理可重用组件，从而使你的代码库保持模块化和可维护性。
1. 从一个提示开始
每个组件都始于一个清晰的请求。Hope AI 将你的提示作为其理解要构建内容的第一个简要说明。它应该尽可能简单地描述组件的核心功能和用途。
例如，你可以提示：
为电商网站创建一个包含图片、标题、价格和加入购物车按钮的产品卡片组件。
当你提交提示时，Hope AI 不会立即生成代码。相反，它会解释你的请求并开始为组件构思一个架构方案。
2. 审查提议的架构
在 Bit Cloud 中，Hope AI 提供了一个在任何实现之前定义结构的架构。这包括涉及的模块、它们之间的接口以及它们所依赖的依赖项。
显示 Hope 生成的架构的图片。
在此阶段，你需要审查提议的架构，以确认它与组件的意图一致，遵循逻辑结构，并与现有模块（如果相关）连接。这会让你清楚地了解组件将如何生成以及它如何融入系统。
3. 生成组件
一旦你批准了架构，Hope AI 就会生成实际的实现，这是一个完全结构化的模块。
Bit Cloud 中的界面会显示生成的组件的文档、依赖关系图、API 引用和测试覆盖率。每个组件都作为一个独立的单元存在，具有清晰的生命周期，从而更容易更新、测试和重用，而无需深入研究应用程序代码。
4. 重用现有组件
为了扩展设计系统，你可以要求 Hope AI 在现有工作基础上进行构建：
创建一个利用 @hackmamba-creators/design.content.card 的产品网格
Hope AI 会检测引用，理解依赖关系，并将新组件连接到现有组件。这意味着新的产品网格将继承原始卡片组件的样式约定和设计模式，同时尊重其既定的接口。
5. 版本控制与协作
当组件准备就绪后，你将打开一个更改请求以审查实现。Bit 的 Ripple CI 在此自动化了大规模治理。它不仅运行测试；它还会自动识别真正的“爆炸半径”，映射出将受你的更改影响的每个组件和应用程序，并对其进行验证。这使你能够 100% 确信地发布。
外部重用组件。
一旦发布到 Bit Cloud，你的组件就会成为你组织“数字资产工厂”中的一流“数字资产”。每个资产都以版本化包的形式存储，无论在何处使用，都保留其结构和契约。它保持可发现、有文档和有版本，允许团队在多个项目和环境中自信地重用组件。
可组合 AI 与扁平 AI 工作流程的关键特性对比
扁平 AI 与可组合 AI 工作流程之间的主要区别在于即时性与持久性。扁平工作流程优先考虑快速生成代码，而可组合工作流程则侧重于结构、重用和长期可维护性。
以下是一个清晰的对比：
- 速度： 扁平 AI 工作流程专注于提供即时结果，以最少的预先规划快速生成代码。相比之下，可组合工作流程会花费更多时间定义结构，从而在项目生命周期中节省时间。
- 持久性： 扁平 AI 工作流程不存储生成的内容。代码片段仅存在于当前上下文中，之后便会消失。与此同时，可组合工作流程会创建有文档、有版本的组件，这些组件跨会话和项目持久存在。
- 可移植性： 扁平 AI 工作流程产生的代码绑定到单个项目或上下文，而可组合工作流程生成的组件可以在项目之间干净地移动，而不会破坏依赖关系。
- 协作： 扁平 AI 工作流程缺乏共享的真相来源，这导致重复的变体和手动修复。而可组合工作流程将组件作为共享模块发布，使 团队和项目之间的协作更加容易。
- 可扩展性： 随着代码库的增长，扁平 AI 工作流程会碎片化，使维护更加困难。可组合工作流程通过可重用、可互操作的构建块实现清晰的扩展。
最佳实践
将提示分解成更小的部分是一个好习惯。它有助于减少错误并控制代码，但它并没有解决更深层次的问题。没有架构层，AI 输出仍然是一次性的。今天能用的代码明天常常会碎片化。
可组合架构填补了这一空白。通过将每个 AI 生成的片段视为一个具有生命周期的组件，你将从孤立的片段转向一个价值不断增长的系统。Bit 和 Hope AI 通过从一开始就生成有文档、有版本且可共享的组件，使这种方法变得实用。
这种方法带来的优势是结构完整性。你的 AI 工作流程不再是将短命的片段分散到各个项目中，而是构建一个可重用模块和相互连接的构建块库。这种转变将 AI 生成的代码从临时解决方案转变为一个随着时间推移而复合的模块化架构，为 AI 辅助开发时代管理代码提供了一种更可持续的方式。
如果你已经在日常工作中尝试使用 AI 工具，这就是下一步。尝试搭建组件，看看可组合工作流程如何 改变你的代码演进方式。
