我的AI软件工厂：两周运营体验

梯形图转SCL | 自然语言生成梯形图 | 自然语言生成SCL | 梯形图在线查看 | 博途编程文档MCP | AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace

我给了智能体两周时间来构建一个音乐制作应用。我们构建了什么、如何构建的，以及评审工作如何成为最大的问题

1. 背景：软件工厂与自主性

到目前为止，能够执行更长时间任务和更雄心勃勃工作的智能体已经相当普遍。特别是对 "软件工厂"的兴趣：自主的多智能体系统，负责规范工作、分解为任务、执行任务、控制质量，并最终在没有直接监督的情况下交付和部署。

到目前为止，我已经有了几年同时指导多个智能体的实践经验。Tmux、worktrees、/workflow以及Claude和Codex中的多会话管理都为编码智能体释放了更多生产力。但软件工厂将多线程推向了极端，您完全不监督各个编码智能体。

这需要创建一个系统，而不仅仅是管理对话。Steve Yegge通过Gas Town开创了这一点，他最近的后续文章是这个实验和这篇文章的主要灵感来源。

我一直以来都对建立和运行自己的软件工厂很感兴趣。 我已经接近了，但还没有完全投入。我一直在等待合适的项目；一个我有动力去创建、有专业知识去评估结果，但缺乏时间去亲手构建的项目。几周前，我有了一个似乎值得挑战的想法。

2. 音乐制作工具，以及构建它的工厂

2.1 创意种子

当我在Splice工作时，我们了解到创意种子帮助人们启动音乐想法的力量。特别是对于初学者，添加想法通常比从头开始更容易。许多制作人找到一个声音或循环，然后围绕它构建整首曲子。

以这种方式工作时，通常很难感受到创意所有权。找到一个循环可以激发发现的快乐，但需要更多才能感受到与最初是别人想法的连接。从嘻哈和浩室音乐的最早时期开始，寻找和使用有趣的采样一直是整个流派的丰富灵感来源和基础，但从一开始就有关于什么构成"有效"创造力的辩论。如何用循环构建一个令人满意的创意工作流，创造出"你的"音乐？

自2018年以来，我一直相信更好的核心循环：寻找、匹配和塑造声音。我为新型"DAW"（数字音频工作站，如Garageband、Ableton或FL studio）制作了许多草图和原型，但缺乏编程技能和时间来真正构建它。特别是硬核DSP（数字信号处理）功能，如时间拉伸和低延迟音频效果，超出了我的能力范围。大多数DAW都是由深度专家团队构建的。这不是周末项目领域，至少在我们当前这个奇怪的时刻之前不是。

但当几周前我和一位老Splice朋友聊天，探讨AI音乐制作工具的现状时，这个问题空间在我脑海中重新激活了。

2.2 约束条件

我意识到这将是软件工厂的一个很好的测试案例：

• 清晰的想法： 我知道我想要什么，并能详细描述
• 雄心勃勃的范围： 超出了我能通过1:1 AI聊天高效构建的范围
• 困难的问题： 低延迟音频播放、采样时间拉伸和音频效果将这个项目推 beyond 了模板React应用 + ShadCN
• 时间有限： 满档日程，没有时间直接监督工作。现在Miro非常忙碌（MCP和Sidekicks的大发布！），我父母来访，我还在从最近的日本旅行中恢复。我的规则是：每晚睡前检查一次，工作时间不超过一小时
• 爱好者预算： 我有自己的AI账户用于个人项目和实验。我把个人Claude和ChatGPT的使用量计数器视为挑战：用它或失去它！我想看看用大约300美元（Claude Max 20x和ChatGPT 5x）能做什么

2.3 启动

我们从我的常用技能之一开始："spec"。Spec很简单。我口述一段关于我想构建什么的漫谈。然后智能体盘问我、剖析想法、挑战前提、解决歧义。接下来我们构建数据模型和分类法。这些输入被提炼成详细的文档。

在这种情况下，由于几个月来对该主题的笔记和深入思考，我的漫谈比平时更长。经过两个多小时的口述，我倾倒出所有的想法，并通过结构化面试进行提炼，制作了Dial的详细描述。

概念很简单：围绕一个神奇的旋钮构建创意工作流，可以搜索声音、塑造和雕刻，创造无限变化。旋钮探索创意空间，由助理智能体按命令为您准备。智能体是您的工作室助理，但搜索空间、堆叠、塑造和结构都由您决定。

到目前为止，工作流与我过去一年运行的其他"智能体工作启动"类似。但这次，我还使用/spec来定义如何构建想法的操作规则。最终结果是一个包含11个详细规范文档的文件夹，涵盖了产品和工厂的各个方面。

3. 初始工厂设计

Fable和我共同设计了工厂的初始状态如下：

3.1 核心编排

• 主要界面是Claude桌面应用， 处于"代码"模式。这后来变得更灵活，但开始时很简单
• 工厂由一个"主导"智能体编排。 这个智能体是我与工厂团队的主要联系点，明确指示不要自己做工作，总是委派给子智能体。我从Fable开始作为主导，虽然我也尝试了这个
• Beads用于跟踪进度。再次向Steve Yegge致敬（他的解释在这里）。Beads非常出色，我强烈推荐它。编排器的责任是将规范分解为beads，委派给智能体，并指导进度逐步完成规范的完整实现
• 编排器被指示为任务选择正确的模型。 我给出了轻量级指导：前端任务通常应委派给Sonnet，或当涉及结构化内容（如组件化）时委派给Opus。架构更改，特别是涉及底层数据模型或全新能力领域脚手架的更改，应委派给Fable（除非它们很简单）

3.2 决策和文档

• 重大决策应在出现时上报给我。 编排器负责这些上报。我晚上检查工厂，并通过评审解决上报。当我们一起做出决策时，它会被批准到滚动决策日志中
• 规范是事实来源。 传入的工作根据规范进行评审。如果决策改变了规范，或者我们在实施过程中了解到某些内容，规范会更新。规范也是代码库的一部分，规范更改与代码更改一样需要评审
• 所有智能体跟踪都被记录并使编排器智能体可读， 以便工厂可以"反思"自身
• 工厂协议包含在代码库中， 可以像任何其他代码一样通过拉取请求进行编辑

3.3 合并和评审

• 所有子智能体在工作树中工作，并向main分支提交拉取请求。 工作总是拉取请求，这有一个很好的副作用：自动记录随时间的演变
• 整个代码库都有测试覆盖，CI在每次推送时运行。 失败的分支无法合并，没有测试覆盖的分支应被标记为阻止
• 拉取请求在经过对抗性架构智能体的架构评审之前不能合并。 对抗性智能体是GPT 5.6 Sol的一个实例，监视新的拉取请求。它还配置为每小时运行一次cron，以捕获PR监视可能遗漏的任何内容。它的提示是作为代码质量的管理者，在拉取请求上发表评论，就像人工评审者一样

最后，Claude和ChatGPT都配置为在云模式下运行，而不是本地模式，这样我可以随时从手机检查它们的进度。

有了这个——我让Fable以"自动"模式运行，并启动了工厂。

4. 执行与演进

阶段1：快速启动

Fable出色地编排了基础冲刺。到第1天结束时，我们有了一个可工作的WASM音频引擎、应用程序外壳和基本音频播放。到第2天，我们有了旋钮的第一个实现，可以用来"扫描"样本列表。到第3天，我们可以匹配和堆叠循环，并播放循环的歌曲想法。在周三晚上的检查中，我第一次在原型中感受到了创意乐趣。

阶段2：尝试扩展编排

从早期开始，我就在编排器速度上遇到了瓶颈。编排器通常一次只委派2-3个任务。特别是早期，很多工作是串行的。但即便如此，编排器并不总是有效地识别并行化机会。

为了解决这个问题，我短暂尝试创建具有专用所有权区域和自己编排器的子团队。我从一个处理音频可视化器的子团队和一个处理核心引擎音频效果的子团队开始。

核心引擎音频团队工作得非常出色。两天内，我们有了一个时间拉伸库的Rust移植和一组小型音频效果。主编排器在Dial中实现了它，样本播放质量立即全面提升。

可视化器团队效率较低。我很快意识到，高品味的UI工作在没有监督的情况下效果不佳。（稍后详述。）

尽管取得了一些成功，我还是放弃了这种方法。根据我可用的时间和注意力，管理多个编排器开销太大。它造成了实际问题：克服Beads沙盒、处理PR和CI所有权。最重要的是，编排器计算被证明是宝贵的资源，运行多个编排器会更快地消耗它。我发现"缓慢而稳定"的简单设置运行24小时胜过更复杂的配置。

阶段3：交接 + 处理计划限制

通常，Fable积分在48小时后会用完。我第一次很幸运，因为我的重置恰好与第一次使用限制重合。但在第二次之后，工厂在周四和周五闲置了。我短暂尝试将编排切换到Opus 5，但它容易过度管理。我用周六早上的评审时间设计了与GPT 5.6 Sol的交接协议。Opus记录了工厂的当前状态，更新了所有beads和文档，撰写了HANDOFF.md简报，并定义了未来交接的程序。到周六下午，Sol正在运行工厂。

交接协议被证明很重要。我经常遇到计划限制，因此交接是通过轮换账户保持事情推进的关键工具。前几次很艰难——工作被重复和覆盖，决策丢失，分支被放弃。但跟踪有助于调试和迭代协议。我现在进行到第五次交接，一切运行顺利。

Sol已经在架构评审方面做得很好，在运行编排方面也做得很好。Sol有不同的风格，并被证明以不同的方式同样有能力。不那么学究，更注重行动，想象力稍少，更可靠。也许更敏锐、更有分析力。有点难以解释，但如果您与两者合作，您会建立相同的直觉。关于Fable和Sol还有很多要说的，但在几次来回交接之后，我通常更喜欢与Sol合作进行编排。然而，它更容易陷入深层技术问题，与Fable相比更像是微观管理者。

阶段4：去臃肿和重构

到第1周结束时，我们在基础层开始碰壁。当我们开始处理时间线视图时，核心引擎对循环排序和调度的假设开始失效。核心对象需要重新设计，因为它们变得更加（嗯）"承重"。

到周六晚上，Sol和我同意是时候对调度系统和样本数据模型进行重大重构了。我对此感到紧张，因为这是最终测试——代码库能否在多个智能体和不可避免的中途交接的情况下，经受住关键内部的重大重做？

答案是"大部分可以"。在周日规划会议后，工作由Sol主导启动，这要感谢OpenAI及时的使用重置。随着Sol编排重构，最大的问题变成了重复的CI失败。并行智能体工作导致冲突，Sol无限的调试热情在地面仍在变化时消耗了多次昂贵的、长时间的往返。周一到周三很无聊且令人沮丧，晚上评审看到一次又一次的提交（以及宝贵的Sol使用）花费在"让测试通过"上。

但我们熬过来了。到周四，功能工作再次向前推进，正好赶上Fable使用量本周重置。Sol运行了交接协议，Claude再次接手工作。

阶段5：UI打磨和最后修饰

随着第2周接近尾声，我们有了大部分核心产品 thesis 的功能。但随着时间的推移，临时UI控件、随机诊断显示和调试UI、有时可疑的智能体即兴创作，以及有时可疑的我的方向的累积重量导致了一团糟。它都能工作，但工作流很笨拙。

周末，我终于找到了一些时间与Opus进行专门的、老派的1:1聊天。经过两个多小时的合作，我们清理了UI混乱，收紧了核心流程。这是一个很棒的会议，效果很好，因为所有核心基础设施都已就位。从功能核心中剥离糟粕并提取最好的想法是一种乐趣。

5. 两周后的经验教训

5.1 它有效（大部分）

最重要的是：您无法与结果争论。2周后，我有了一个完全功能的概念版本，我用它制作了我喜欢的音乐想法。我也不认为代码库是灾难性的。从对生成输出的抽查和探索来看，它组织和架构合理，我读的代码有意义。该应用程序出人意料地可扩展，使用时感觉坚如磐石。它运行良好，没有爆音或故障，声音很棒，长时间运行没有问题。特别令人印象深刻，因为音频很难做好！

将控制权交给编排器出人意料地可行。对于习惯于密切关注智能体并定期评审代码的人来说，失去这种控制是一种调整。但能够并行执行多个线程而不中断，特别是让它在我不在时或过夜运行，要强大得多，这是值得的。

即使编排的错误率是两倍，它每天运行24小时而不是1小时。尽管有回溯和重做，它仍然不接近。

5.2 它还不是未来

然而，有一个关键的警告：错误会累积。如果95%的成功率在无人监督下降低到90%，7次迭代后的差异变成70% vs 48%。关键是在定期检查点不断纠正回100%，否则整个事情可能会翻倒。工厂的运行取决于安全保障和评审的质量。

我会给这次运行的防护一个"C"。有很多臃肿，但我不认为它比普通初创公司差得多。我认为很容易浪漫化代码质量，想象某种定制的手工制作过程，但任何在初创公司马拉松冲刺中构建过的人都可以告诉您，需要跨越的门槛并不像我们经常假装的那样高。

未来的证明将是开发速度和产品质量。我们会在主要重构上再花一周时间吗？我们能支持MIDI和自动化等复杂功能吗？随着代码复杂性的增长，门槛会上升。

至于工厂，一路上有很多坎坷。称工厂为"自主的"现在有点牵强。

5.3 轻微摩擦可能使一切停滞

最大的挑战是简单地保持工厂运行。除了使用限制外，我还遇到了许多其他机械问题。

• Claude和ChatGPT的应用错误（会话断开、不可靠的事件可观察性、较长会话的内存问题）导致工作多次停止
• 通过MCP连接器/插件与Github的不一致交互，无论是错误还是不一致的智能体行为，都导致了工作被覆盖
• 当我的Github actions预算用完时，智能体无法弄清楚为什么作业失败，好几个小时都在原地打转
• Beads是任务编排的关键，但被锁定在初始编排器智能体的沙盒中。当我开始在编排器之间交接时，这崩溃了，需要重新设计任务协议
• 起初，子智能体跟踪被锁定在主编排器对话中。这也造成了交接困难

5.4 可观察性对调试至关重要

我发现记录所有对话的跟踪+摘要很有用。这允许在出错时更好地恢复、更好的交接和工厂"内省"。有了跟踪，您可以定期运行"回顾"，了解工厂的运行情况，甚至可以针对智能体行为的真实示例运行对抗性评审来评审工厂协议更改。

5.5 可负担的计算是我的主要约束

尽管运行两个专业计划：Anthropic Max账户20x和ChatGPT Pro 5x，工厂只能运行约48小时就遇到限制。到目前为止最大的问题是Fable使用量，但ChatGPT在Sol上也很快用完了。更便宜的智能体可以编排，但我有信任差距。当Opus驾驶时，我感觉到决策质量略有不同。

AI推理不是唯一的成本。随着变更堆积，CI支出也在增加。这是自找的——所有样本音频内容最初都包含在仓库中，创建了每次合并时构建和测试的大文件。

让编排器知道我担心成本的效果出人意料地好。它重新设计了CI套件使其模块化，运行范围测试，并在何时进行完整测试运行方面变得有策略。它重组了仓库，不再上传完整样本语料库，而是范围一个小调色板来运行所有测试。总体上，我们将CI时间大大削减，并将支出减少到爱好者可管理的水平。

5.6 智能体从编排退化到执行

详细全面的工厂规范在长时间范围内对专注有很大帮助。然而，编排器有不断退回到"个人贡献者"工作的倾向。就像任何微观管理者一样，他们倾向于深入子智能体工作的细节。有时这很有效，解决问题并解决冲突——但有时它导致编排器踩到子智能体的脚趾，覆盖工作，并陷入循环。

我怀疑这是我方面的"技能问题"，至少可以部分通过更好的工厂指南解决。但我也怀疑这是当今智能体的固有属性。它们天生倾向于提供帮助并自己解决问题。如果您曾经在领导和个人贡献者工作之间拉伸，您知道其中的危险，智能体也面临同样的问题。虽然我每个模型都遇到过这个问题，但Fable和Sol都比Opus好。我怀疑它们的后训练比其他模型更适合编排。

5.7 1:1工作仍然重要

将与智能体的大多数讨论"向上移动一层"是一种有趣的体验。我本质上是在与工程经理而不是IC工程师沟通和协作。这适用于大多数任务，但对于某些工作，我想要更积极的协作：

• 设计工作需要紧密的反馈循环。 特别是在创意工具中，工作流的某种感觉只能通过使用它来评估，并且——理想情况下——能够在使用产品时调整或调整事物。最大的摩擦点之一是等待智能体返回UI更改。我的梦想是一个"即兴演奏会"，界面选择可以根据语音对话实时更新
• 分类法需要直接输入。 智能体倾向于退回到对他们有意义的神秘命名约定，在构建项目时发展内部技术语言。消除这些并用人类可读的名词和动词替换它们是保持代码库可理解的重要部分。我不断看到"LLM式"词汇渗入：基质、批准等等。我不会在智能体对话中试图对抗这些，因为我不想干扰智能体的自然思维链，但我试图将它们排除在代码库和UI之外
• 优先级需要持续检查。 如果您不密切关注它们，智能体会，例如，在DSP样本精确度上构建加密哈希验证系统跨Mac和 Linux，说服自己这是朝着可靠音频引擎测试的方向。（问我怎么知道的。）这样，它们让我想起任何极其有才华的工程师：极其有能力，极其容易镀金

6. 核心问题：可读性与评审

6.1 智能体倾向于神秘沟通

特别是在最新模型中，OpenAI和Anthropic模型都发展了自己的技术术语，特别是在长时间会话中。这种现象让我着迷——真正的团队也会这样做！当您接近工作时，倾向于命名概念并在日常工作中使用这些名称。很容易迷失在您定制词汇的小世界中。

这可能使理解工厂中发生的事情变得非常困难。例如，对于关于待办事项优先级的问题，看看这个回应：

建议的队列：car D → 第2阶段（修剪并重命名轨道）→ 扫描 → 引擎通道（dial-02b、dial-pz2、dial-sdoj、dial-el2、dial-6ql、dial-0o8、dial-h4p）→ 第3阶段的关卡——加上您的micro-R1随时准备就绪的常驻说明。

谢谢，Claude。👍

6.2 通过文本和代码理解变更是一场噩梦

当试图评估具有巨大表面区域的代码更改时，这种神秘语言变得更糟。实际发生了什么变化？即使您是系统专家，在代码级别审计更改在大规模上也是不可行的。CTO无法评审每个拉取请求，即使在最小的组织中。评审需要向上移动一个级别，并且需要信任工作与计划匹配。

产品和设计也是如此：滥用一句名言，写设计就像在跳舞建筑。我需要看到它才能给出好的反馈；无论是UI还是项目计划。我是视觉思考的，当我仔细研究一页又一页的代码、智能体响应、调试跟踪时——我不断反思文本的低信息带宽。

这就像试图通过阅读每个Slack频道中的每条消息来领导一个组织，希望线程中一次性响应的总和能加起来更多。这种反馈有时很重要，但如果这是您唯一的参与方式，它会让人筋疲力尽。

6.3 熟悉的挑战

我对任何高管面临的挑战有了新的认识。他们每天都面对团队层面做出的数百、数千个小决定。大多数是好的，有些不是。您能分辨出来吗？您甚至能理解正在决定什么吗？时间是否浪费在不值得解决的问题上？我无法评审每条消息，就像CEO无法参加每个会议一样。

当我开始领导一个智能体团队时，我发现自己伸手去拿我习惯的相同工具和渠道。设计评审、技术评审、决策日志、优先级讨论、战略讨论、启动会议。很明显这一层缺失了，痛苦随着规模增长而加剧。

为了让这些对话有效，我需要的不仅仅是一堵文本墙：我需要工件。幻灯片、图表、路线图、待办事项。到目前为止，我主要认为智能体制作这些工件是加速我自己工作的方式：与利益相关者沟通，为团队设定战略。但过去两周运行我的智能体团队，我感受到了新领域的轮廓：智能体向我解释他们在做什么的工件，并帮助我在更高层次上指导他们。

7. 下一步

7.1 成本优化

很明显，我可以在工厂的大部分操作中使用更便宜的模型。我对自己的不情愿感到惊讶。当您关心某事时，您希望最好的工程师处理所有事情。但过去两周的深刻教训（以及多年玩Factorio的经验！）是，您只能与最紧的瓶颈一样好。吞吐量就是一切，甚至质量也是如此：如果您用完Fable积分，您无法修复错误或让CI变绿。

使这可行的答案是加强对评审的保障和对智能体性能与任务类型的评估，以随时间优化路由。这似乎是工厂的下一个主要前沿。我特别感兴趣尝试Luna和开源模型进行执行。但没有更好的质量保障和评估，我无法做到这一点。

7.2 尝试自定义编排

多次接力教会我，好的文档可以帮助代码库在工具和模型更改中生存。我想尝试一个自定义编排器来运行工厂，而不是依赖Claude和GPT桌面应用中的功能。

我的需求相当简单（编排器、子智能体、对抗性评审、监视器、cron），所以我一开始就抵制构建。很容易迷失在构建编排器而不是构建产品本身中。但现在我有了几周操作的经验，我可以看到许多自定义编排会有很大帮助的地方。

特别是，构建自定义评估工具来评估不同的智能体路由，结合更便宜模型的成本优化，可以递归地自我改进工厂，而不仅仅是代码库。

7.3 可视化层

我有兴趣看看是否可以创建技能，提示智能体安排与我的早晨或晚间评审：

• walkthrough 他们的主要决策
• 可视化工作状态、燃尽图、史诗进展
• 关于高级优先级和路线图的对话

在这里，世界与我的日常工作冲突：Miro拥有工作流可视化和项目协调的所有核心原语。现在它们通过MCP可用，我想尝试将Miro作为工厂的"前端"。我刚刚开始尝试这个——很快会有更多内容。

8、结束语

我又暂停了，等待另一次使用重置。我喜欢我所做的，看到我旧笔记本中的想法变成现实很酷。我不确定我会进一步追求这个想法，但工厂的背景性质使得再运行几周看看它如何演变的风险很低。

最后，这可能是这个项目最持久的教训：拥有一堆后备项目，以及一台可以低干预构建它们的机器是有用的。但要真正让这奏效——并且让它有趣——您需要智能体展示工作并解释自己的方式。让智能体"向上管理"仍然是一个未解决的问题。

附言：如果您想自己尝试，只需将这篇文章发送给ChatGPT或Claude，并说您想建立一个工厂。

原文链接：2 Weeks Running an AI Software Factory

汇智网翻译整理，转载请标明出处