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