一种名为"Build Wide, Ship Narrow"的现代软件开发工作流正在改变传统的任务分解方式[1]。这一方法利用AI助手大幅降低了代码编写、设计迭代和分支整理的成本[1]。具体而言，AI助手能在数小时或数分钟内将问题转化为代码，设计迭代可在对话速度下进行，分支整理从最繁琐的工作简化为一条提示词就能完成[1]。
该工作流的核心思想是先进行充分的规划和演示验证，然后在单个分支上完整构建功能，最后再将其分割成独立可审查的小PR进行合并[1]。具体步骤包括：完善计划直到产生真实决策，提交设计规范后再开始编码，在单分支上完整构建，演示迭代后才进行代码审查，按代码揭示的边界分割成PR，最后在独立的PR中清理和删除旧代码[1]。通过使用AI提示词（例如"Split the current work into the smallest set of independently reviewable PRs"），可自动生成git worktree和分支[1]。
并非所有工作成本都因此下降[1]。代码审查的判断工作（而非机械性检查）和产品验证（确认构建的是正确的产品）这两项成本仍未见降低[1]。该方法遵循两条关键规则：只在有真实依赖时堆叠分支，清理和删除旧代码必须在最后单独的PR中进行[1]。
A new development methodology leverages artificial intelligence to fundamentally reshape how teams write, iterate, and submit code for review [1]. The "Build Wide, Ship Narrow" approach reduces three major cost categories in the development process: AI assistants can convert problem specifications into code within hours or minutes rather than days; design iterations now proceed at conversation speed; and branch organization, once the most tedious task, can be completed with a single prompt [1].
The workflow introduces a structured sequence designed to maximize efficiency while preserving critical human judgment. Developers begin by refining plans until genuine decisions emerge, then submit design specifications before writing code [1]. The core distinction lies in constructing entire features on a single branch rather than pre-dividing work into separate branches [1]. Only after demonstrating and iterating on the implementation do teams proceed to code review [1]. The final steps involve splitting the completed work into the smallest set of independently reviewable pull requests, guided by boundaries revealed during development, with code cleanup and deletions handled in a separate final pull request [1].
Two critical activities remain resistant to cost reduction: the judgment required for substantive code review—as opposed to mechanical checking—and product validation to ensure the right product was built [1]. The methodology establishes two core rules: branches should only be stacked when genuine dependencies exist between them, and cleanup of deprecated code must always appear in a dedicated, separate pull request [1].