@jholtdigital：最近有位朋友鼓励我，如果想了解某件事物对我的用例效果如何，就应该试用一个月……

X AI KOLs Following 工具
ai-tool long-horizon-tasks factory-ai flutter code-generation agent-orchestration design-system

摘要

一位用户分享了使用 FactoryAI 将设计系统从 HTML/CSS 转换为带有 E2E 测试的 Flutter 组件的体验。该工具使用编排器、工作者和验证器，结合多种 AI 模型来规划和执行长达 79 小时的长期任务，总共生成了超过 229 个代理。

最近有位朋友鼓励我，如果想了解某件事物对我的用例效果如何，就应该试用一个月。于是我尝试了另一个我一直想探索的 AI 工具。 我运行了我的第一个 @FactoryAI 任务——这是 Factory/Droid 团队一个非常酷的想法。他们为这类长期任务构建的结构——编排器负责规划，提出澄清性问题，创建里程碑，根据你的代码库限制进行规划，并执行长期工作。这比我用过的其他应用中的 /goal 命令要结构化得多。 这次运行的一些统计数据： - 活跃时间：79 小时 2 分钟 - 每个里程碑平均耗时：5.3 小时 - 每个功能平均耗时：30.2 分钟 - 生成了超过 229 个代理——不包括它们产生的子代理（用于审查代码在简洁性和架构适配性方面的子代理） - 158 个任务 这个具体任务是将我原型设计并在 HTML/CSS 中微调的设计系统，转换为带有 Patrol 中的 E2E 测试的 Flutter 组件。它替换了现有的基本 Material Design 主题和组件。代理首先捕获了 HTML 原型的多个截图，然后才规划实现。编排器创建的初始计划由 Fable 5 完成，但在计划创建后，编排器通常是 Opus 4.8，更多时候是 GPT 5.5 xhigh。工作者包括 Composer 2.5、一些 GLM 5.2，以及一些 Kimi K2.6/K2.7。验证器几乎全是 GPT 5.5。 我从未见过这样的系统。它令人印象深刻。我需要花几周时间进行大量优化。系统完整且运行良好，但存在一些 UI 错误，未能正确匹配原型。不过我认为无论怎样都会出现这种情况。代理可以帮你完成大约 80% 的工作，而最后 20% 的优化才是大部分工作的所在。非常钦佩！如果大家有兴趣了解更多细节，也许我可以写一篇更长的文章。
查看原文
查看缓存全文

缓存时间: 2026/06/23 21:54

最近有位朋友鼓励我，如果想了解某个工具是否适合自己的场景，不妨先试用一个月。于是我便用另一款一直想探索的AI工具尝试了一下。

我运行了首个 @FactoryAI 任务——这是 Factory/Droid 团队提出的一个非常酷的理念。他们为这种长周期任务构建的体系结构非常系统：由一个编排者进行规划、提出澄清性问题、创建里程碑、根据你的代码库限制制定计划，并执行长时间的工作。与我曾在其他应用中使用过的 /goal 命令相比，这个体系要严谨得多。

本次运行的一些数据：

  • 活跃时长：79小时2分钟
  • 每个里程碑平均耗时：5.3小时
  • 每个功能平均耗时：30.2分钟
  • 累计生成 229+ 个智能体——这还不包括它们所衍生的子智能体（用于审查代码在简洁性和架构匹配度等方面的子智能体）
  • 共158个任务

这项具体任务是：将我之前用 HTML/CSS 设计并优化过的设计系统，转换为 Flutter 组件，并使用 Patrol 进行端到端测试。它替代了原有的基础 Material Design 主题和组件。在规划实现之前，智能体首先需要截取 HTML 原型的多张截图。编排者所创建的初始规划由 Fable 5 完成；但规划创建之后，编排者使用的模型要么是 Opus 4.8，更常见的是 GPT 5.5 xhigh。工作智能体使用 Composer 2.5、部分 GLM 5.2 以及一些 Kimi K2.6/K2.7。验证智能体几乎全部使用 GPT 5.5。

我从未见过这样的系统。它令人印象深刻。接下来几周我需要做大量优化。系统本身完整且运行良好，但有不少界面错误与原型并不完全一致。不过我认为无论使用什么工具，这种情况都难以避免。智能体可以完成大约80%的工作，而最后20%的优化才是重头戏。非常震撼！如果大家有兴趣了解更多细节，我或许可以写一篇更长的总结。

相似文章