1997年，Eric S. Raymond 用《大教堂与市集》描述了两种软件生产方式。
一种像建造大教堂：由少数专业人员规划，在相对封闭的环境中精心施工，完成到一定阶段以后再向外发布。
另一种像经营市集：尽早开放，频繁迭代，让大量参与者在使用、反馈、修改和争论中推动软件演化。
在很长一段时间里，这两种模式大致对应商业软件与开源软件。它们争论的核心，是软件应该由谁创造、以什么方式协作，以及开放能否比集中规划更有效地发现问题。
AI出现以后，这组问题没有失效。相反，它正在以一种更彻底的方式回到软件行业内部。
因为AI改变的不只是写代码的速度，也改变了进入软件生产的资格、协作网络的规模，以及整个工程体系中真正稀缺的东西。
《大教堂与市集》真正讨论的不是开源许可证
如果只把《大教堂与市集》理解成“开源优于闭源”，就容易错过它更重要的部分。
它讨论的是一种生产组织问题：复杂软件是否只能依靠少数专家自上而下完成，还是可以通过持续发布、广泛反馈和分布式协作，在使用过程中逐渐生长出来。
市集模式之所以有效，并不只是因为参与者多。它还依赖几个条件：问题能够被看见，修改能够被比较，贡献能够被追踪，维护者能够决定哪些变化进入主干。
因此，市集从来不是没有秩序的自由创作。代码仓库、版本控制、测试、评审和维护者，本身就是市集得以运转的基础设施。
这也意味着，大教堂与市集并非简单的对立关系。很多成功的开源项目，外部看起来像市集，内部却有清晰的架构边界、严格的合并规则和少数承担最终责任的维护者。
开放扩大了参与面，但秩序决定了这些参与能否形成可靠的软件。
AI改变了软件生产中的稀缺性
传统软件开发中，最昂贵的环节之一是把需求翻译成可运行的代码。
一个想法要成为产品，往往需要经历需求分析、原型设计、技术选型、编码、测试和部署。即使想法本身很清楚，缺少工程能力的人也很难独立完成实现。
AI正在压缩这条路径：
想法 → 自然语言描述 → AI生成 → 人类验证 → 持续修改
原型可以在几小时内出现，过去因为开发成本太高而不会被尝试的小需求，也开始获得实现机会。个人、小团队和非技术岗位，都能更直接地参与软件创造。
这像是把原本位于组织外部的开源市集，搬进了每一个开发环境。一个人面对的不再只是编辑器和代码库，还可能同时调度多个模型、Agent、开源组件和自动化工具。
但生产能力的扩张并没有让所有工程成本一起下降。
代码生成变便宜以后，真正稀缺的部分转移到了别处：
- 问题是否被正确定义；
- 系统边界是否清楚；
- 生成结果是否满足真实需求；
- 测试是否覆盖了关键风险；
- 安全、数据与许可问题是否得到处理；
- 软件出错以后由谁判断、修复并承担责任。
过去，团队常常受限于“做不出来”。AI时代，团队更容易受限于“无法证明做出来的东西是对的”。
更多代码，不等于更多有效的眼睛
市集模式有一个经典判断：当足够多的人查看和使用代码时，问题更容易暴露。
AI看起来把这个逻辑推到了极致。一个开发者可以要求多个Agent并行提出方案、检查实现、补充测试，仿佛瞬间获得了一支庞大的协作队伍。
但Agent数量不能直接等同于认知多样性。
十个Agent可能来自相似的基础模型，依赖相近的训练材料，读取同一份上下文，也可能重复同一种误解。当它们共享盲点时，增加输出数量只会放大一种看似一致的错误。
更关键的是，AI可以检查代码是否符合已知规则，却无法自动保证规则本身正确。需求遗漏、商业判断偏差、权限边界错误和对真实用户的误解，都可能在一套逻辑自洽的实现中被完整保留下来。
因此，AI时代不能把“更多生成”误认为“更多审查”。
真正有效的眼睛，必须具有不同的信息来源、不同的利益位置，以及对结果负责的能力。用户反馈、领域专家、安全审查、运行数据和维护者判断，仍然无法被单纯的模型调用次数替代。
AI让大教堂与市集同时扩张
AI并没有让软件世界单向走向市集。它反而让两种结构同时变得更强。
在底层，基础模型需要巨额算力、集中训练、数据治理和持续运维。模型接口、云平台和计算资源掌握在少数机构手中，这比传统软件更像一座庞大的大教堂。
在上层，开发者可以调用模型、组合开源项目、编排Agent，并快速生成面向细分场景的应用。应用实验的成本下降，参与者增加，变化速度加快，这又形成了更繁荣的市集。
于是，一种新的软件生产结构正在出现：
集中的智能基础设施，支撑分布式的软件创造。
这不是大教堂被市集取代，而是市集开进了大教堂。市集中的每个参与者都能获得更强的建造能力，但他们依然依赖底层模型、平台接口、软件供应链和组织规则。
这种结构带来效率，也带来新的脆弱性。模型升级、接口变化、平台政策或上游组件问题，都可能同时影响大量应用。表面上高度分散的创新，可能建立在非常集中的能力来源之上。
所以，AI时代讨论开放，不应只看应用代码是否开源，还要看模型能否替换、数据能否迁移、过程能否追溯，以及一个系统是否具备离开单一平台继续运行的能力。
Vibe Coding扩大的是创造入口
Vibe Coding最值得关注的地方，不是“不会编程的人也能写代码”，而是软件创造的入口从“技术实现”向“问题表达”前移了。
过去，开发者通常先理解编程语言，再学习如何把想法变成系统。现在，越来越多人可以先描述目标，在与AI的往返中逐步逼近实现。
这会让大量过去没有机会进入开发排期的需求被尝试，也会让软件更像一种可持续修改的个人工具，而不只是由专业公司交付的标准产品。
与此同时，原型与产品之间的界线会变得更加重要。
原型可以依靠直觉推进，生产系统却必须面对真实数据、真实权限、真实攻击和真实损失。AI可以帮助一个人迅速搭起建筑，但不能因此取消消防规范、承重计算和验收责任。
未来的专业开发者不会因为代码生成而失去价值。其角色会从大量亲手实现，逐渐转向：
- 把模糊愿望转化为可验证的问题；
- 为AI划定架构、数据和权限边界；
- 设计能够发现错误的测试与观测系统；
- 判断哪些生成结果可以进入长期维护的主干；
- 在效率、成本、安全和可演化性之间作出取舍。
AI扩大了创造软件的人群，却也提高了对工程判断的要求。
大教堂不会消失，它将负责边界与责任
当生成速度越来越快，组织更需要稳定的结构来吸收变化。
架构规则决定不同模块如何协作，测试体系判断变化有没有破坏已有能力，发布机制控制风险进入真实环境的速度，审计记录说明一个决策从哪里来。它们都带有大教堂式的集中秩序。
未来更有效的软件组织，很可能不是在两种模式中选择一种，而是重新分配二者的职责：
- 用大教堂确定目标、边界、标准和责任人；
- 用市集并行探索方案、暴露问题并吸收反馈；
- 用AI扩大可尝试的方案数量；
- 用人类判断决定什么值得保留、发布和长期维护。
这里最危险的误区，是只扩大市集的产出能力，却没有同步扩大大教堂的验证能力。
如果生成的代码越来越多，而测试、评审、文档和维护资源没有增长，软件组织得到的就不是更高生产力，而是更快积累的技术债务。
AI真正考验的不是团队能生成多少代码，而是团队能否建立一套与生成速度相匹配的判断系统。
软件资产需要记录创造过程
当软件由人类、AI、开源组件、外部服务和多个Agent共同形成时，传统的“作者是谁”会变得越来越难回答。
Git能够记录哪一行代码在什么时间发生变化，却未必能解释这次变化基于什么需求、采用了哪些外部材料、由什么模型参与、经过了哪些验证，又由谁批准进入生产环境。
这意味着版本控制仍然必要，但已经不够。
未来的软件资产需要同时保留三类信息：
- 结果：最终代码、配置、模型和文档是什么；
- 来源：人类贡献、AI生成、开源依赖和外部数据分别来自哪里；
- 决策：为什么采用这一方案，经过了哪些验证，由谁承担最终责任。
开源时代解决了代码如何协作的问题。AI时代还需要继续解决智能如何参与、贡献如何归属、结果如何验证的问题。
只有当这些过程能够被追溯，AI带来的大规模协作才可能沉淀为可信的软件资产，而不只是大量无法解释的生成物。
结语
《大教堂与市集》在AI时代依然重要，但它需要一个新的注脚。
过去，人们争论集中开发与开放协作谁更有效。现在，更重要的问题变成：当智能生产可以被大规模调用，谁来定义方向，谁来验证结果，谁来承担责任？
AI让建造本身越来越便宜，却没有让判断与责任一起廉价化。
未来的软件不会只来自大教堂，也不会只来自市集。它会诞生于二者的组合：稳定的边界容纳高速的探索，集中的责任管理分布式的创造，人类判断驾驭机器生成。
当砖块不再稀缺，真正决定软件价值的，将是图纸、验收，以及每一次创造为什么值得被保留下来。