硬件配置与语音交互优化
Charlie Holtz 是 Conductor 的联合创始人，这是一家允许用户在 Mac 上编排多个编码代理的应用程序，公司曾入选 YC 2024 夏季班。为了适应高频的语音交互需求，他特别配置了一款售价仅 20 美元的鹅颈麦克风。这种设备允许他在开放式办公室环境中压低声音 whisper 向 AI 下达指令，如“请合并 PR 3475”，从而减少对同事的干扰。他提到：“我们都在尝试更多地与计算机交谈……这些麦克风是为了鼓励更多与计算机对话而引入的。”
在硬件方面，Holtz 拥有一台配置极高的电脑，拥有 128GB 内存，主要用于运行本地模型如 Parakeet（通过 Spokenly 应用进行文本转语音）。有趣的是，为了强制自己适应低配环境，他最近购买了一台最低配置的 MacBook Air（最低内存版本），以此作为自我约束的手段，确保工作流不依赖过高的硬件资源。
Conductor 核心工作流与键盘快捷键
Holtz 的大部分时间都在 Conductor 中度过，甚至用 Conductor 来构建 Conductor 本身。他的核心操作习惯是极度依赖键盘快捷键，例如使用 Command+N 快速启动新任务。他会对着麦克风说：“看看最新的 Linear 问题，并给出一个粗略的解决方案”，然后按回车。任务会在侧边栏运行，同时他可以切换到另一个工作区进行审查。
“我非常热衷于键盘快捷键，试图让所有操作都有对应的快捷键。”
在审查阶段，如果 AI 生成的代码（PR）存在小问题，他会像 GitHub 评论一样给出反馈，例如：“这看起来有点奇怪，为什么我们需要这个？”然后让 AI 修正。他经常同时开启多个工作区进行实验性尝试，大多数想法最终不会上线，但这是探索新方案的重要过程。如果某个方案被认可，它会被提升为内部设置或实验性功能。
移动办公与“穴居人模式”
Conductor 支持移动端即时启动，Holtz 可以在手机上通过语音指令添加新功能，例如“添加一个可以切换黑客模式的主题”，随后电脑会自动开始工作。尽管 AI 承担了大部分编码工作，Holtz 偶尔仍会手动编辑代码，如调整 Tailwind 类或修改 .env 文件。为此，Conductor 引入了“穴居人模式”（Caveman Mode），允许用户直接通过键盘在文件中键入更改。
对于大多数小型编辑，他更倾向于高亮代码片段并语音描述修改意图，例如：“这个按钮看起来太宽了，能把它缩小一点吗？”当 PR 准备就绪时，他点击归档并从侧边栏移除，随后合并到代码库中。系统左侧的状态栏会清晰显示任务阶段：进行中（In Progress）→ 审查中（In Review）→ 已完成（Done）。他理想中的界面应让用户感觉像是一家小公司的 CEO，能够查看代理的工作摘要并做出决策。
系统提示词、权限管理与安全边界
在软件配置上，Holtz 高度重视自定义技能文件（Skills Files）和 Claude 的 Markdown 提示词。这些文件长达数百行，定义了公司的工程实践，明确告知 AI：“我们是一家初创公司，不像大型企业那样写代码。”他始终使用快速模式（Fast Mode）以最大化令牌效率，并启用 Context 7 MCP 以获取文档支持。最关键的设置是默认允许危险权限，以便 AI 能直接操作文件系统。
为了防范 AI 陷入“恶性循环”（即 AI 基于错误代码生成更多错误代码），他们设立了“无 AI 区”（Slot-free zones）。这些区域包含由人类编写的代码或文档，AI 可以贡献，但每一行代码都必须经过人类阅读。代码库中存在明确的指令：“如果你是一个 AI，不要触碰这里，这是给人看的。”这种严格的边界管理确保了代码质量，防止 AI 在缺乏人类监督的情况下自我恶化。
技术栈与开发理念
Conductor 本身的技术栈相对简洁：前端基于 Safari 原生 Web 渲染器，后端使用 Rust，但几乎全部业务逻辑都使用 TypeScript 编写。Holtz 强调，尽管拥有强大的本地模型和复杂的代理编排能力，核心在于清晰的指令和边界。他通过 Telegram 与 Open Claw 交流，并利用本地运行的 Parakeet 模型进行语音交互，这展示了他对本地化、隐私保护及高效工作流的极致追求。他的工作流不仅展示了 AI 编码的潜力，更揭示了人类如何作为“指挥官”而非“打字员”来管理智能代理团队。
技术栈偏好与 AI 架构边界
Conductor 的代码库主要由 TypeScript 和 Elixir 构成，其中桌面应用约 90-95% 使用 TypeScript，而 Web 应用则基于 Elixir 的 Phoenix 框架。尽管 Web 应用目前功能极简（仅支持登录），但 CEO Charlie Holtz 是 Elixir 的忠实拥趸，始终推动在代码库中增加 Elixir 的比重。在 AI 辅助开发的架构设计上，Holtz 强调不要让 AI 担任架构师角色。他认为，像“工作区（Workspace）”这样的核心概念，本质上是人类对“工作树（Work Tree）”的抽象，这类涉及设计决策和界面布局的关键问题必须由人类深思熟虑。如果让 AI 决定 UI 选择，产品往往会失去精心打磨的质感，变得缺乏“匠心”。
"Even the concept of like a workspace here in the sidebar... like we as a human had to like think that through."
Holtz 指出，当前的代码库边界尚显模糊，未来计划将核心基础设施建立在人类编写的 API 和契约之上，限制 AI 的直接干预；而将大量非核心代码留给 AI 自由发挥，以便快速验证想法而不影响底层稳定性。这种分层策略旨在保持团队在技术前沿的领先地位，同时确保核心架构的稳健性。
强制工作流与产品自信
Conductor 的产品设计具有强烈的意见导向（Opinionated）特征，旨在推动用户走出舒适区。在早期发布时，用户反馈集中在难以管理多个 AI 代理（如同时运行三个或五个 Cloud Code 或 CodeX 实例）。为此，Holtz 团队故意禁止直接编辑文件，强制要求工作区必须生成工作树、创建 Pull Request 并经过合并流程。这种严格的工作流虽然增加了初期使用门槛，但确保了代码变更的可控性和可追溯性。
关于如何建立产品决策的自信，Holtz 表示团队不依赖数据分析或 A/B 测试，而是依靠“直觉”和内部高频使用。他们每天亲自使用 Conductor，如果某个交互（如点击“打开”按钮后界面反应）感觉不对，团队会迅速调整。这种“ gut feel ”（直觉驱动）的方法论使得产品体验高度统一，例如聊天界面、代码审查面板和运行面板的布局均经过精心考量，旨在提供无缝的视觉和操作体验，而非依赖数据驱动的碎片化优化。
"We are not big on analytics or like looking at like our AB testing or like It's very much a like gut feel."
模型选择策略与终端界面的局限
在具体的 AI 模型使用上，Holtz 根据任务性质在 Claude Opus 和 CodeX 之间切换。CodeX 被视为“主力军（Workhorse）”，擅长处理特定难题、执行大量工具调用以及进行长时间的调试工作，适合需要高效执行的任务。相比之下，Opus 更具创造性和伙伴感，适合在构建新功能或需要更多来回交互的场景中使用。这种分工策略体现了对模型特性的深刻理解：Opus 用于创意和架构思考，CodeX 用于落地执行。
关于为何不直接使用终端界面，Holtz 指出人类是空间视觉型生物，命令行界面虽然对 AI 大脑友好，但对人类而言过于受限。图形用户界面（GUI）提供了更丰富的信息层级和交互方式，例如将聊天、审查面板和代码视图分离，符合人类的认知习惯。终端界面无法提供这种空间化的信息组织，限制了人类在复杂开发任务中的掌控力。
成本数据与代码量管理
在资源消耗方面，Holtz 分享了 Conductor 在 2025 年 7 月（项目初期）的 Token 使用峰值数据。当时由于使用上一代模型，单月 Token 支出高达 $22,000，生成的代码行数达到数万行。尽管团队推崇“Token 最大化”策略，即始终使用高速模式和高努力程度（High Effort）以获得最佳结果，但他们刻意保持代码行数最小化。Holtz 认为，如果不加控制，代码库会迅速失控，因此代码质量优于代码数量是核心原则。
| 指标 | 数据/描述 |
|---|---|
| 峰值月份 | 2025 年 7 月 |
| 单月 Token 支出 | $22,000 |
| 生成代码行数 | 数万行（Tens of thousands） |
| 模型代际 | 上一代模型（Previous generation） |
| 策略倾向 | Token 最大化（高速/高努力），代码行数最小化 |
Holtz 还提到，随着模型能力的提升，Agent 的运行时间将延长 10 倍，智能程度也将提高 10 倍，因此团队正大力投入云端基础设施，以摆脱本地 CPU 限制，支持更长时间、更复杂的 Agent 运行。这种从本地到云端的转变，是应对 AI 代理日益复杂化的必然选择。
工作流重构：从手动编码到 AI 协同审查
Charlie Holtz 揭示了 Conductor 团队在 硬 PR（Pull Request） 处理上的工作流变革。过去，面对复杂的代码审查，他倾向于打开 IDE 手动进行修改，并大量依赖 GitHub 网页版进行交互。然而，随着 Conductor 的深入使用，这种模式发生了根本性转变。现在，他极少使用 GitHub 网页应用，而是直接在 Conductor 中审查代码变更，并在此处添加评论。这种转变的核心在于效率的提升，因为团队拥有大量的 PR 检查（PR checks） 在运行。为了进一步优化这一流程，团队最近引入了 Checks 标签页，允许用户将来自 GitHub 的评论直接添加到 Conductor 中，实现了审查环境的统一。这种变化不仅减少了上下文切换，还强化了 AI 辅助下的代码审查闭环。
用户创造力：Gary Mode 与 IPC 黑客实验
在探索 Conductor 的边界时，用户 Gary 的行为让 Holtz 感到惊讶。Gary 通过黑客手段构建了一个 Conductor 的移动版本，具体方式是伪造 IPC（进程间通信）调用以欺骗桌面应用程序。尽管技术实现细节令人费解，但这种对底层机制的挖掘展示了极高的创造力。Holtz 指出，Gary 实际上是在极限测试 Conductor 的能力，并教会了团队如何更激进地使用 Skills（技能）。在 GStack 中，Skills 被视为一等公民（first-class thing），特别是在入职培训（onboarding）方面有着有趣的理念。基于 Gary 的使用习惯，团队专门开发了 Gary Mode。在该模式下，系统默认不折叠任何工具调用，让用户能完整看到所有工具交互过程，甚至可以在界面中看到 Gary 的头像，体现了高度的个性化定制。
人机协作：指挥家隐喻与提示词的核心地位
Holtz 认为，世界尚未完全理解人类与 AI 协作的深层潜力，例如子代理通信和多人协作聊天。他常用交响乐指挥家的隐喻来描述这一关系：指挥家挥舞指挥棒，乐器齐奏，但偶尔需要单独纠正小号手的音准，或指示弦乐组加快节奏，大部分时间则在整体层面进行指挥。在这一范式下，代码已沦为“木屑”——它不再是构建的核心结构，而是描述需求后的副产品。因此，提示词（Prompts）变得至关重要。当新一代模型发布时，只需重新运行提示词即可生成新代码，旧代码的价值大幅降低。Holtz 提到，提交提示词（Submit a prompt）功能是对可塑性软件（Malleable Software）的早期实验，标志着软件形态从固定结构向动态生成的转变。
软件形态演变：游戏模组与可塑性未来
Holtz 用电子游戏模组（Mods）来类比未来的软件形态。以《使命召唤》为例，游戏的核心骨架对所有人相同，但玩家可通过自定义皮肤或修改射速来个性化体验。他期望 Conductor 也能实现类似的模组化，让用户构建自己的工作流程，同时保持核心结构的精心打磨与一致性。这种理念强调软件应像游戏一样，既提供统一的优秀基础，又允许用户进行深度定制。Holtz 认为，这种可塑性将赋予用户更多掌控感，使软件真正服务于个人独特的需求，而非强制用户适应软件逻辑。这一愿景反映了 AI 时代下，软件定义权从开发者向用户转移的趋势，强调了用户体验的个性化与系统结构的稳定性之间的平衡。