> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # 后IDE时代的软件开发 - URL: https://www.hubwiz.com/blog/post-ide-software-development/ - Published: 2026-04-18T17:03:56.000Z - Updated: 2026-10-13T15:59:46.000Z - Description: 对我来说，一个重要的时刻出现在最近，当我意识到IDE不再是我工作流的中心。Claude Code、Beads、Gas Town、GStack和规格驱动开发教会我关于IDE之后的软件开发。 - Author: admin - Tags: INDUSTRY, #Import 2026-10-14 14:41 在过去一年中，我发现Steve Yegge关于编码代理的文章很有用，因为它提供了一种实用的方式来思考工具的发展方向。Andrej Karpathy也从不同角度提出，随着编码越来越以代理为中心，周围的工具和工作流技术栈将持续变化。如果认真对待从自动补全到聊天、从聊天到代理、从代理到协调执行的演进过程，那么编排就开始看起来不像是一个可选的附加功能，而更像是一个新的操作层。他的演进模型之所以有用，是因为它捕捉到了许多工程师已经能感受到的转变：重心正在从本地实现转向编排。 大多数关于AI辅助软件开发的讨论仍然停留在第二到第四阶段。这些阶段已经非常有用，对许多人来说仍然是自然的起点。一个更具影响力的转变发生在后面，当代理成为更广泛执行系统的一部分时。 对我来说，一个重要的时刻出现在最近，当我意识到IDE不再是我工作流的中心。我能看到我不太可能再像以前那样花那么多时间直接编写代码了。我的角色正在转向监督：定义任务、塑造架构、设定约束、审查输出、决定什么应该保留。工作仍然是技术性的，但我操作的水平已经改变了。 > 吸引我的部分原因是一种探索前沿的感觉。一旦重心开始从IDE转向编排，你就不再只是采用一个新工具。你正在一个新的开发模型开始形成的边界附近工作。技术栈仍然是流动的，惯例仍在涌现，抽象仍在被发现。这使得周末的实验感觉非常有价值。 这种转变也改变了我对软件本身的看法。在由编码代理塑造的工作流中，最有价值的工具往往是那些节省认知的工具：压缩重复推理、减少返工、让人类和代理都以更少的努力达到有用结果的系统。这使得编排、结构化任务系统、持久规范和可重用工作流手册比它们初看起来更加核心。它们加速实现并减少每次必须从头重建的思考量。 上个周末，我想通过一个一次性的但技术上非平凡的原型来探索这种转变。我构建了一个小型媒体处理沙盒，用于摄取视频和音频文件、提取元数据、生成缩略图、标准化格式、生成轻量级转录和摘要，并公开一个简单的作业仪表板用于监控管道状态。正是这种有边界的系统项目之所以有用，恰恰是因为它是一次性的：足够复杂以锻炼真正的工程工作流，足够普通以至于没有重要的事情依赖于它。 这个原型是有用的，但主要价值来自构建它的工作流。Claude Code处理了大部分实现。Beads为工作提供了结构。Gas Town实现了并行编排。规格驱动的工作流提供了跨任务和会话的持久书面意图层。GStack提供了用于规划、审查、QA和发布的可重用高级工作流，使整个系统更容易一致地操作。在本文中，我将逐一介绍这些工具，并描述我如何将它们组合成一个工作流，让我能够协调数十个代理来处理一个非平凡的软件系统。GStack本身将项目描述为Claude Code工作流的"23个有主见的工具"集合，这是对其在此处所扮演角色的很好总结。 ## 1、Steve Yegge的编码代理演进模型 我发现Yegge演进模型中最有价值的是它捕捉到了开发者工作水平的转变。 在早期阶段，重心仍然接近代码。开发者观察本地编辑，在编辑器中批准更改，并以紧密同步的方式与模型交互。思考单元是一个函数、一个文件或一个补丁。 在后期阶段，思考单元变成一个任务、一个工作流或一个系统边界。工作围绕分解、排序、隔离和评估展开。代理成为更广泛工程系统中的执行层。这需要更传统的软件开发者进行真正的思维转变。放弃IDE作为工作流中心是最初的步骤之一。 这就是这个周末清楚展现的模式。我不再花大部分时间编写单个函数了，而是在决定任务应该是什么、哪些任务可以独立运行、什么算完成、什么应该测试、系统之间的边界应该在哪里、以及哪些类型的工作可以安全地委托。 代码仍然重要。杠杆越来越多地来自模型接触之前如何塑造工作。 ## 2、一个有边界的原型，旨在探索多代理执行 原型本身是故意设计为一次性的，但技术上是真实的。我构建了一个媒体处理沙盒，摄取上传的视频和音频，提取元数据，标准化格式，生成缩略图和预览，生成轻量级转录和摘要，并公开一个小型内部仪表板用于监控作业执行和刷新状态。 项目的重点不是产品。而是工作流。我想要一个足够广泛的系统，涉及几种不同形式的工程工作——后端路由、处理作业、文件处理、模板、支持工具、测试和部署问题——而不与任何战略性的重要事项绑定。这使它成为探索代理编码工作流的有用环境，特别是我可以将数十个代理对一个代码库的结构化协调推到多远。 为了支持这一点，我保持了基础设施的简单并按职责分离。我使用了三台EC2实例。一台服务于应用程序并处理实时Web和API层。第二台处理较重的管道任务，包括媒体摄取、格式转换、元数据提取、转录生成和缩略图作业。第三台作为工作台，Claude Code可以访问仓库、任务列表、测试环境、版本控制以及围绕它的更高级别工作流工具，但不能直接控制生产服务。 这种分离结果非常重要。小型机器不能很好地容忍混合职责，当环境本身施加合理的边界时，代理执行变得更容易信任。这个设置给了代理在开发中快速移动的空间，同时保持服务、管道工作和执行控制干净地分离。更广泛地说，它使核心实验成为可能：找出一个结构化系统是否能够有效地协调许多代理来处理一个非平凡的软件项目。 ## 3、Beads是共享大脑 Beads是设置中最重要的组成部分之一。在传统工作流中，问题跟踪器通常位于仓库之外，这意味着模型必须跨系统重建上下文。这对人类来说可能是可管理的，但对代理来说很尴尬。Beads通过将任务列表作为仓库本身的一部分来解决这个问题。工作队列与代码并存。 这在很大程度上改变了工作流。当Claude开始一个会话时，它可以立即读取现有任务，理解优先级，选择一个bead，完成它，然后关闭它。仓库不仅是代码库，还是一个包含实现和意图的共享工作空间。 这种结构选择使自主执行更加自然。代理不需要即兴规划系统。它从环境中继承一个。 Beads还为代理工作鼓励了一种有用的纪律。一个bead必须足够具体才能可操作。它需要有界范围和明确的完成概念。仅此一点就在任何编排开始之前改善了软件执行。 Beads这样的工具在此设置中有用的一部分原因是它将重复出现的工程工作模式压缩成人类和代理都可以重用的形式。不再反复从分散的上下文中重建优先级、范围和完成状态，这些信息被明确化和本地化。从这个意义上说，价值不仅是组织性的。它是认知性的。该工具通过保留否则必须反复重新生成的结构来节省精力。 ## 4、规格驱动开发提供了持久的意图层 在整个工作流中越来越重要的另一个想法是规格驱动开发。在将重要工作交给Claude之前，我为项目写了一份轻量级章程：原型的目的、大致的技术形态、几个不可协商的设计约束，以及从摄取到处理到呈现的预期路径。对于较大的工作块，我还写了简短的功能级说明和验收标准。这不是繁重的流程。它是一个超越任何单个提示窗口的书面意图层。 那个额外的层比我预期的更重要。一旦编码代理超越孤立的任务，进入更长时间的会话或多代理工作流，非正式的提示就开始暴露其局限性。书面规格更可靠地传递上下文，减少偏差，使人类更容易在意图层面管理，而不是反复重建相同的指导。 从这个意义上说，规格驱动开发感觉像是代理软件开发的基建。它使工作在会话之间保持清晰，并为代理提供更稳定的执行基础。 这在代理工作流中也有一种实际的生存品质。干净地保留意图的系统往往会保持有用，因为它们节省重复解释并降低协调成本。项目章程、明确的规格或边界清晰的验收测试可能看起来像轻量级流程，但在实践中它们起到可重用认知基建的作用。 ## 5、GStack添加了可重用工作流模式 在实践中另一个有用的层是GStack。如果Beads提供了任务基础，Gas Town处理了编排，GStack则在该基础之上提供了可重用的工作流模式。仓库将其呈现为Garry Tan的Claude Code设置，并将其描述为"23个有主见的工具"集合，正是在此背景下考虑它的正确方式。 对我来说重要的不是任何一个单独的工具，而是这些高级工作流减少重复设置并使常见活动更清晰的方式。规划、设计审查、工程审查、QA和发布工作都受益于拥有可重复的操作手册，而不是每次都重新即兴写提示。 一旦多个代理同时运行，这就变得特别有用。你可以通过足够的提示要求代理做几乎任何事情，但可重用的工作流脚手架使过程更稳定。它减少了歧义，提高了可重复性，并在意图和执行之间创建了一致的接口。 在我自己的设置中，GStack充当了专门操作模式的层。它帮助将"审查这个计划"、"测试这个流程"或"准备这个发布"等广泛指令变成更清晰、更可重复的程序。这使得更容易委托工作而不必每次重新解释流程的形状。 ## 6、Gas Town是真正的力量倍增器 如果Beads是共享大脑，Gas Town就是劳动力。单个编码代理是有用的。Gas Town添加的是跨多个代理针对同一仓库和任务系统的协调。Yegge自己的框架在这里很有帮助：Gas Town是"2026年IDE的新尝试"，旨在处理同时运行大量编码代理实例的实际开销。在他的描述中，问题不再仅仅是生成代码，而是跟踪谁在做什么、保留状态、协调工作并保持整个系统运转。 这就是城镇比喻重要的原因。Gas Town是一个由专业化工人、角色和例程组成的微型社会，针对共享状态运作。Beads给这个社会一个通用的任务基础。Gas Town位于其上作为协调层：分配工作、管理进度、允许许多代理运行并行推进，而不会一切都崩溃成逐提示的混乱。 > 不再是一个长长的串行循环，工作开始扇形展开。一个代理可以处理一个处理任务。另一个可以写测试。另一个可以更新模板。另一个可以处理支持脚本或管理视图。因为任务以bead形式表达，状态是共享的，编排层有稳定的东西可以围绕协调。 这就是Yegge后期阶段模型变得具体的地方。第七阶段是设计一个系统，其中多个代理可以在没有持续人类干预的情况下取得进展。第八阶段更进一步：构建你自己的编排器。Yegge最近关于Gas City的写作明确了这个下一步。他将Gas City描述为从头重写和Gas Town的超集，但也是一个**编排器构建器**：一个用户可以定义自己的编排器、自定义角色和协调模式的系统，而不是仅依赖一组固定的内置功能。 这个演进是有用的，因为它澄清了正在变化的东西。下一层越来越是**可编程协调**。人们从使用代理开始，然后学会运行多个，最终开始塑造协调它们的系统。从这个意义上说，从Gas Town到Gas City的移动符合本文的更广泛模式：开发者的角色继续向上移动，远离本地实现，转向工作流设计、系统设计，最终是编排设计本身。 为了使其良好运作，任务需要良好分解，文件边界需要相当干净，验收标准需要清晰可辨。这也是规格驱动开发变得有用的地方：它给系统一个持久的书面意图层，所以代理在更清晰的范围、更清晰的边界和更清晰的完成定义下运作。它还要求人类更像执行管理者而非监督每个补丁的打字员来思考。 一旦这种结构到位，好处是巨大的。不同类别的工程工作可以同时进行。那是周末最重要的实践教训。Gas Town让Claude更快，但更重要的是它改变了进展的形状。 ## 7、系统只有在分解良好时才能工作 编排的价值取决于分解。当工作可以干净地划分时，并行代理是高效的。如果任务严重重叠，如果所有权不明确，或者如果规范留下太多解释空间，优势就会迅速消失。代理开始触碰相同的文件，重新处理彼此的假设，或者产生仍需昂贵解缠的输出。 从这个意义上说，Beads、Gas Town、规格驱动开发和GStack提供的工作流模式都强化了同样的纪律。薄弱的任务设计立即可见。薄弱的规格产生歧义。薄弱的边界产生返工。好的任务设计、清晰的章程、明确的功能规格和可重复的操作模式创造杠杆。 这也是Yegge框架有用的一个原因。它不仅描述了工具复杂性的阶梯。它还描述了工作如何被框架化的工程成熟度阶梯。 ## 8、代理用户体验比许多人认为的更重要 周末的另一个教训是，代理可用性应该被视为一等设计关注点。一个工具在原则上足够强大是不够的。代理必须能够发现正确的操作，以可预测的方式调用它，从小错误中恢复，并在没有过多提示或重试的情况下继续。 在实践中，这意味着低摩擦接口非常重要。如果任务系统、命令表面或工作流与代理自然尝试操作的方式一致，该工具就变得更有用。如果接口笨拙、脆弱或令人意外，代理通常会快速放弃它，转而回退到能力较弱但更可预测的路径。这使得代理UX成为一个实质性的工程关注点，而不是一个表面问题。 这也强化了Beads、规格驱动开发和GStack的价值。它们通过使意图、状态、预期结果和常见程序更容易被代理正确推断来降低摩擦。在多代理工作流中，这种摩擦的减少会复合。 它也有助于解释为什么运行时层开始变得更重要。一旦代理变得长期运行、多步骤和越来越自主，围绕它们的框架就开始几乎和模型本身一样重要：*沙盒化、权限、执行环境、监控以及在更长时间范围内维持工作的能力*。我自己的工作流从外向内探索这个问题，Beads、Gas Town、GStack和规格在执行层周围提供结构。看到更多的运行时和框架基建随时间产品化也就不足为奇了。 ## 9、运行时层正在产品化 这感觉像是一个拐点的另一个原因是，我手动组装的技术栈部分现在正开始作为产品化基建出现。Anthropic最近宣布的**Claude Managed Agents**相当清楚地指向了这个方向。它打包了围绕模型的框架、沙盒执行环境、长期运行的云运行时、权限和监控层——正是那些一旦代理变得多步骤、长期运行和越来越自主后开始重要的运行时关注点。Anthropic自己的表述是，大规模部署代理是一个复杂的分布式系统问题，许多团队之前一直在自己解决。 回顾起来，我的三台EC2设置感觉像是同一通用架构关注的轻量级、自组装版本。它在成熟度或能力上不可比较，但它解决了问题的一个可识别部分：给代理一个专用执行环境，将服务与较重的作业分离，并允许在人类离开时继续工作。这使得系统更容易信任、更容易观察、在出现问题时更容易恢复。 在我看来，Claude Managed Agents验证的不是特定工具选择，而是更广泛的方向。一旦编码越来越以代理为中心，周围的运行时就开始几乎和模型本身一样重要。我自己的工作流从外向内探索这一点，Beads、Gas Town、GStack和规格作为执行层周围的高级结构。托管基建只是暗示着这个技术栈的更多部分将随时间标准化。 ## 10、tmux会话让一切感觉真实 操作循环本身很简单。我定义了一组P0和P1任务，告诉Claude按顺序完成它们，要求它实现、测试、提交、推送并关闭相应的bead，并指示它在需要人类输入或特权访问时停止。然后我让会话在工作台服务器的tmux中运行。 设置中最令人满意的方面之一是知道Claude仍然在EC2上工作，在我离开键盘时处理P0和P1 bead。每月大约200美元的API支出，我就有了一个可以持续推进有用工程工作的持久执行层。我可以出去喝咖啡，或者简单地继续一天的其他事情，然后回到有边界、可检查和具体的进展。 在任何时候，我都可以重新连接并检查实时会话： ``` ssh -i ~/.ssh/founders-workbench.pem ec2-user@44.202.185.44 tmux attach -t work ``` 回到服务器意味着回到进展的证据：提交、测试结果、关闭的bead、带有明确障碍说明的未完成工作，以及可见的执行轨迹。 ## 11、代理系统构建了什么 在周末期间，系统产生了大量真实的实现。 它构建了媒体摄取流程、元数据提取作业、轻量级处理管道、缩略图和预览生成、一个对索引资产的小型搜索层，以及一个用于作业状态和项目计数的简单内部仪表板。它还编写了测试，发现了处理流程中的一个真正错误并修复了它，同时生成了支持脚本和实用的操作说明。 这项工作的广度很重要。Claude Code、Beads、Gas Town、规格驱动工作流和GStack层的组合处理了应用程序逻辑、测试、支持工具、配置和文档。编排层允许整个工程表面积移动，而不仅仅是一次一个编码任务。 ## 12、我的角色向上移动了 这次经历也使人类角色更清晰了。 我选择了原型的形状。我定义了架构。我写了章程。我决定了优先级。我将工作分解为bead。我决定了什么可以并行运行。我审查了差异。我拒绝了薄弱的抽象。我处理了不安全或难以委托的基础设施任务。我决定了输出何时好到可以保留。 代理系统承担了很大一部分执行负担，我的角色向上移动到判断、结构和评估。这在实际意义上就是Yegge演进模型所指向的。 重要的变化是人类在不同的抽象水平上工作。 ## 13、为什么这对未来很重要 这种组合也因更广泛的原因而重要。它改变了什么感觉可行的规模。很长一段时间以来，软件雄心一直受到一个实际约束的塑造：一个人或一个小团队实际能够承担的实现量。代理工作流松动了这个约束。它们不消除对判断的需求，也不使架构变为可选，但它们确实扩展了在清晰方向下可用的执行能力。 这是这让我觉得重要的部分。价值不仅在于熟悉的工作可以更快完成。而在于更大类别的项目开始感觉在操作上是可行的。一旦执行变得更容易扩展，问题就转向某件事是否值得构建，以及它是否能被结构化得好到足以成功。 我也认为这指向了软件应该如何评估的更大变化。在代理可以合成越来越多实现的环境中，保持最有价值的系统通常是那些节省认知、减少摩擦、保留结构并使重复工作更容易协调的系统。这包括编排、工作流状态、持久执行、搜索、规范、可重用操作手册和其他形式的认知基建工具。这些系统不仅仅是添加功能。它们降低了完成有用工作的成本。 我对这些工具的兴趣就在那里。我想了解当周围的纪律足够强时，这个模型能走多远：清晰的规格、边界清晰的任务、可靠的编排、减少重复解释的可重用工作流模式，以及保持接近架构和判断的人类监督。吸引力在于以以前在纯手动工作流下感觉遥不可及的规模来构建。 ## 14、失败模式具有澄清作用 出现的问题也是有用的。 长文件仍然脆弱。当代理必须修补大型复杂模块时，错误变得更常见。这使得模块化比平时更有价值。 资源限制很快浮出水面。当太多工作被强制放在错误的机器上时，系统以可预测的方式变得不稳定。编排不消除内存和CPU的底层约束。 任务质量极为重要。好的bead产生稳定进展。薄弱的bead造成混乱和返工。薄弱的规格有类似的效果。薄弱的工作流脚手架同样会快速产生偏差。因此，Beads加规格的工作流感觉不仅仅是一个生产力技巧，更像是一种强制更清晰工程思考的机制。 这些失败模式是周末有用的部分原因。它们向我展示了代理软件开发在哪里依赖于普通的工程纪律。 ## 15、我的端到端代理编码工作流技术栈 综合来看，我当前的端到端代理编码技术栈如下，尽管随着工具的改进它可能会继续演进： - **Claude Code**提供强大的实现能力。 - **Beads**提供共享的、仓库原生的任务基础，代理可以直接理解。 - **Gas Town**提供跨任务的编排和并行执行。 - **规格驱动开发**提供跨会话存续并保持代理一致的持久书面意图层。 - **GStack**提供用于规划、审查、QA和发布工作的可重用高级工作流模式。 - **Yegge的演进模型**提供概念语言和过渡模型，用于理解为什么工作流感觉与普通的AI辅助编码不同。 更广泛的价值，以及这个周末探索让我感兴趣的核心，在于这些部分如何组合成一个围绕编排构建的端到端代理编码工作流。Beads给代理共享结构。Gas Town将该结构转变为协调执行。规格驱动开发跨任务和会话稳定意图。GStack提供使常见活动更可重复和更容易委托的可重用工作流模式。Claude Code提供执行引擎。Yegge的模型帮助解释为什么这种安排将开发者的角色向上移动，远离本地编辑，转向分解、审查和判断。 ![None](https://www.hubwiz.com/blog/content/images/2026/04/1-KRPZYzpCEIRjMQ8FJIVDkw.png) **图2：** 一个端到端代理编码工作流。规格提供持久意图，Beads提供共享任务状态，GStack添加可重用工作流手册，Gas Town协调并行执行，审查将人类判断保持在循环中，与Claude Code并驾齐驱。价值在于这些层如何组合成一个用于结构化委托和监督的单一系统。📖 **来源：** 作者自制图片。 综合来看，这些部分形成了一个系统，其中执行可以以结构化的方式委托，进展可以在人类离开时继续，工作流变得比逐提示交互更持久。这种组合感觉像是未来软件开发标准的早期版本。 ## 16、软件开发的未来 原型本身是有用的，但最终它是一个更广泛教训的载体。编码代理中最有趣的发展是它们现在可以参与协调执行循环，前提是周围系统设计得足够仔细。 这将软件开发的实践向上移动。更多的技艺在于良好地塑造工作、合理地构建环境、写下持久意图、重用经过验证的工作流模式和严格评估结果。执行变得更容易扩展。判断变得更加核心。 对我来说，这就是这种工作方式背后面向未来的动机。更强的编排、更清晰的规格、更好的任务基础、更好的操作手册和更低摩擦的代理工作流，让单个构建者可以尝试以前感觉太大、太慢或协调太重而无法认真追求的项目。代码移动得更快，但更大的影响在于范围。更容易以更好的系统和更有雄心的产品来思考，同时将人类角色锚定在判断、结构和方向上。 这感觉像是工程实践中的一个有意义变化。 --- 原文链接: [Software Development After the IDE](https://medium.com/@sean.j.moran/i-let-an-ai-agent-build-an-entire-prototype-while-i-went-for-coffee-c7860c852a6d?ref=hubwiz.com) 汇智网翻译整理，转载请标明出处 > **这是「AI 编程 / Vibe Coding」专题的一部分。**完整地图见：[AI 编程 / Vibe Coding 完全指南](https://www.hubwiz.com/blog/vibe-coding-stack/)