这是关于 Caffeine V3 版本更新内容的系列文章的第一篇，本文将介绍新的构建架构，下一篇：V3 的设计系统如何打造更美观的应用。
如果你曾经遇到过 Caffeine 在 50 次修改后忘记你的应用原本的样子，那么这里解释了为什么会发生这种情况，以及为什么以后不会再发生这种情况。
在 V3 版本中，我们从底层重构了 Caffeine 的应用构建方式，此前，Caffeine 采用的是顺序流水线，本质上是由一系列依次运行的代理组成：规划应用、构建后端、构建前端、运行质量检查、部署，每个步骤都必须完成才能开始下一个步骤，如果第三步发现第二步存在问题，则无法回滚。
这种方法对于简单的应用程序来说效果不错，但随着项目规模的扩大（页面更多、功能更多、迭代次数更多），流程开始遇到瓶颈，上下文窗口会被填满，早期的决策会被忽略，质量也会下降。
V3 用一支由专业代理组成的团队取代了原有的顺序流程，这些代理可以并行工作，跨多轮迭代，并在每轮之间传递学习成果，所有这些都由我们称之为“编排者”的协调器负责，你可以这样理解：你不再需要指望一个人完成所有工作，而是有一家公司为你服务。
从一个 Agent 到一支团队
Composer 从不读取或编写代码，它的职责是将您的请求分解成多个任务，将它们分配给合适的专家，收集结果，并决定下一步该做什么，实际的工作由专家完成：
Discovery 的一名代理会扫描您的项目，以便在任何变更发生之前准确了解项目的现状。
产品专员会将您的需求转化为结构化的需求，供整个团队参考。
设计代理会创建一套视觉系统（颜色标记、字体、布局指南），前端的所有决策都遵循这套系统。
前端工程师编写 React 代码，多个 React 代码可以并行运行，用于不同的页面。
后端工程师为互联网计算机编写 Motoko 代码。
质量保证人员会审核代码并运行视觉测试。
当你让 Caffeine 构建某个东西时，Composer 会在后台接管，构建过程中，你可以继续聊天、添加上下文、更改方向，或者根据需要完全停止构建。
波浪：团队如何协调
Composer 将工作组织成波浪式的流程，在每个波浪式流程中，独立的任务并行运行，波浪式流程之间，结果会依次传递。
典型的开发过程如下：
第一波 - 探索阶段扫描项目，产品代理生成规格说明。
第二波 - 设计团队创建视觉标识，后端编写 API 合约，两者同时进行。
第三波 - 前端使用上一波的设计令牌和后端合约构建应用程序结构。
第四波 - 如果应用程序有多个独立页面，则它们是并行构建的（每个页面都由一个单独的前端代理构建）。
第五波 - 根据原始要求进行质量审查，并进行目视检查。
部署。
关键在于迭代周期之间的变化，每个专家都会返回一个结构化的结果：它构建了什么（以便下游代理了解可用资源），在此过程中学到了什么，以及发现了哪些无法解决的问题，这些信息会不断传递，因此每一迭代都比上一迭代拥有更丰富的背景信息，并且学习成果会在构建过程中持续积累，从而使系统随着时间的推移变得更加智能。
这带来了旧流程所不具备的两个特性：并行性，这意味着在每个迭代周期内，独立的任务（设计、后端、多个页面等）可以同时运行，旧流程一次只能执行一项任务，以及迭代性，Composer 可以根据需要运行任意多个迭代周期，如果前端发现需要对后端进行更改，后端工程师就会再次被派去处理，如果质量审核发现问题，则会添加另一个迭代周期来修复这些问题，而旧流程只能运行一次，从头到尾。
并非每次更改都需要整个团队，如果您只是提出一些针对性的需求，例如更改颜色或修改标题，Composer 会识别出这一点，并直接派遣单个代理，跳过完整的开发流程，复杂的功能会走完整的开发流程，快速修复则会走快速路径。
每次构建都带来全新的上下文
每次构建都从零开始，即使只是调整标题，Caffeine 也会在进行任何更改之前从头开始重新检查项目，这是有意为之：人工智能模型只有在不受先前会话累积影响的情况下才能发挥最佳性能。
不同版本之间真正保留的是一个轻量级的偏好设置和经验积累文件，这是关于如何使用项目的元数据，而不是项目本身的快照，一个拥有 50 个文件和 700 个草稿版本的项目，其工作效率与一个全新的项目一样高，实际上，Caffeine 会随着时间的推移记录下哪些方法对你的特定项目有效，因此每次构建都比上一次更完善，这与你之前的体验截然相反。
你现在可以看到正在发生的事情
在 V2 版本中，你发送一条消息，会看到“正在构建你的应用……”的提示，然后就只能等待，对于复杂的应用来说，这可能意味着几分钟的沉默，你根本无法知道发生了什么，也无法判断一切是否顺利。
V3 版本会实时显示构建过程，任务清单会列出 Composer 计划的每项工作，并在任务完成、失败或跳过时显示状态指示器，进度摘要会说明 Caffeine 当前正在处理的工作，此外，还有一个停止按钮 - 如果您想要更改方向，可以随时暂停构建。
该检查清单与开发流程图直接对应，您可以查看设计步骤何时完成、后端何时编译、多个页面何时并行构建以及质量审查何时进行，如果出现故障，您可以查看是哪个任务失败以及失败的原因。
更智能的错误恢复
旧版流程最后只有一道质量检查 - 它检查的是代码结构是否合理，而不是应用程序是否真正运行，代码能编译吗？能，点击“加入购物车”按钮后，商品真的能添加到购物车吗？没人检查过，V3 版本则同时测试了这两方面：结构质量和功能质量是不同的，两者都很重要。
V3 版本能够及时发现问题，后端代码会在前端开发开始前进行编译，前端代码在每次修改后都会进行类型检查，质量保证系统会根据原始需求验证最终应用，并对每个应用进行评分 - 通过或失败，并给出原因，它还会截取运行中应用的屏幕截图，并与设计概要进行比对 - 文本在背景上是否清晰可读？交互元素的位置是否正确？
当出现故障时，Composer 会利用上下文信息重试：错误详情、从失败中吸取的经验教训以及全新的上下文窗口，无需再为累积的错误而烦恼。
这同样适用于部署，当部署失败时，错误会返回给 Composer，Composer 会读取错误信息，尝试修复，然后重试部署 - 通常在你注意到问题之前就已经完成了，如果构建确实无法完成，它会被干净利落地丢弃，而不是停留在损坏状态。
哪些方面没有改变
您的项目运作方式仍然相同，您仍然需要用简洁明了的语言描述您的需求，您仍然会收到一个可以预览、修改和发布的草稿。
改变的是你的信息传递到结果产生之间发生的一切。
本系列下一篇：V3 的设计系统和 DESIGN.md 简报如何打造更一致、更美观的应用程序。
#CaffeineAI #caffeine #vibecoding #AI
你关心的 IC 内容
技术进展 | 项目信息 | 全球活动
收藏关注 IC 币安频道
掌握最新资讯