## 暗工厂日记 #1：组织理论、误差数学与自主软件工厂的架构

当你尝试构建一个无人操作的软件工厂时会发生什么。组织理论、误差数学，以及为什么有趣的问题从来都不是代码本身。

在过去的几个月里，我一直在构建一个软件工厂，它能生成完整的、可投入生产的应用程序，而无需人工接触代码。它不是一个代码助手，也不是一个副驾驶。它是一个工厂。熄灯，关门。你给它一份产品简报，它就能给你一个已部署的应用程序。

我远非唯一一个尝试这样做的人。现在的步伐快得惊人。Claude Opus 4.6 发布了，然后是 GPT-5.3，然后是下一个。每周都有新的模型或功能重塑着代理的实际能力。Anthropic、OpenAI、Google 和开源社区之间的竞争意味着，当你还在打地基时，天花板却在不断向上移动。这是从事这项工作最激动人心的时期，也是最令人迷失方向的时期，因为你上个月设计的架构可能到下周二就显得力不从心了。

制造业对我在构建的东西有一个称呼。他们称之为“暗工厂”。一条生产线，无需人类在场，无需开灯就能运行。富士康多年来一直在追逐这个目标，他们的“熄灯”iPhone 装配线就是如此。Dan Shapiro 写了一篇很棒的文章，将此映射到软件领域：从“刺激的自动补全”到完全自主的软件工厂，分为五个级别。大多数开发者止步于第三级，在那里你像经理一样审阅 AI 生成的代码。真正的爆发，也就是小团队能做出非凡成就的部分，只在第四级和第五级才能实现。那就是我试图达到的目标。

有趣的部分不在于自动化本身，而在于你尝试时会出什么问题。

## 组织结构图问题

以下是我没想到的：构建 AI 软件工厂最困难的部分不是 AI，而是组织设计。

我开始阅读 Ethan Mollick 关于将管理作为 AI 超能力的作品，这让我恍然大悟。他简单地阐述道：AI 生产力的瓶颈不是模型能力，而是传统的管理技能。问题界定、可交付成果定义、工作评估——那些在 AI 会议上没人愿意谈论的无聊内容。然后他在领英上发表了一篇文章，认为代理系统需要真正的组织结构，而不仅仅是更多的代理。他认为，100 个子代理对于一个协调者来说太多了，并且边界对象比纯文本交接更有效。

于是我做了研究。深夜里，我开着 Claude Code，翻阅着旧的组织理论论文。Graicunas 在 1933 年发现，当管理者直接下属超过 5 人时，其协调负担会急剧增加。我发现 AI 代理也存在同样的阈值：在一个扁平的群体中，超过 4 个代理，协调开销就会吞噬生产力收益。解决方案与组织在 90 年前发现的相同——层级结构。不是一个单一的协调者管理一切，也不是一个所有代理都互相交流的扁平群体，而是分层。

## 确定性的骨骼，非确定性的血肉

我构建的工厂运行着一个 8 阶段的管道（后来压缩到 6 阶段）。每个阶段都有一个生产代理生成工件，一个评估代理对其进行审查。生产代理使用 Claude，评估代理是 GPT-5.3 在高推理模式下运行，这个“强迫症”式的审阅者会挑剔每一个字段名和缺失的关系。它们会争论，直到输出足够好，最多进行 3 次迭代。

但有一件事让我花了很长时间才尴尬地弄清楚：你不能仅仅依靠非确定性基础来构建可靠的软件。

大型语言模型是概率性的。它们是“满意”的（这是 Herbert Simon 的术语，不是我的）。它们在信息约束下找到“足够好”的答案，而不是最优解。这对于撰写产品简报分析来说没问题。但如果你的领域模型存在损坏的外键引用，并级联影响到下游的 5 个阶段，那将是灾难性的。

所以，真正的架构是混合的。非确定性生成用于创意工作（撰写 PRD、设计屏幕、生成组件），在此之上，在每个边界处都进行确定性验证。JSON 模式验证、跨阶段语义检查。每个实体是否至少有一个屏幕？每个屏幕是否有内容？每个组件是否有设计令牌？

非确定性部分负责梦想，确定性部分负责保持它们的诚实。

## 非确定性反击的地方

这种混合模式对于结构化工件很有效。领域模型、屏幕定义、组件规范。但管道中有一个部分是确定性验证无法挽救的：设计。

工厂有一个设计代理。其核心概念是我称之为“创生式变形”的理念。创生 DNA 配置文件（捕捉产品个性的那 5 个维度）被输入到设计阶段，设计者必须将这种抽象的身份转化为具体的视觉决策。调色板、字体排版系统、间距系统、插图风格。从“富有表现力、低密度、新手熟练度”到一个感觉像人类艺术总监会制作出来的实际设计系统的变形。

在设计代理之上是一个工件创建器，一个路由层，根据需要协调多个生成工具。图标由 Claude 生成为 SVG（基于代码，微小，支持 currentColor）。插图路由到 Recraft 进行原生矢量输出。英雄图像路由到 FLUX。写实内容路由到 DALL-E。带有文本的徽标路由到 Ideogram，因为它是唯一能正确渲染文本的提供商（90%以上的准确率，而其他提供商只有 40-60%）。视频和动态素材路由到 Runway 和 Veo 等工具。路由器根据创生 DNA 分析每个请求，并选择正确的提供商并优化提示。

这就是我要开诚布公的地方：这是工厂里最薄弱的环节。结构化阶段（领域建模、屏幕架构、组件映射）能产出可靠、可验证的成果。设计阶段产出的成果在技术上是正确的，但往往缺乏灵魂。你可以验证一个调色板是否有足够的对比度，但你无法验证它是否有个性。

这是非确定性系统真正难以应对的前沿。生成“一个设计系统”很简单。但要生成一个设计系统，让人感觉每个决策都出自同一人之手，具有独特的观点，让真正的设计师看后会说“是的，这是有意为之”而不是“这很普通”？那完全是另一个问题了。而且这不是通过增加阶段或改进提示词就能解决的问题。这或许是“暗工厂”在熄灯状态下最后才能学会的事情。

## 背后的数学原理

伊桑·莫利克（Ethan Mollick）曾谈到过一个包含三个变量的框架：人类基线时间、成功概率和AI处理时间。听起来很简单。但当你把多个阶段串联起来时，概率计算很快就会变得非常棘手。

如果你的管道中每个阶段都有95%的准确率（这听起来很棒），并且你有8个阶段，那么你的端到端成功率是0.95的8次方，即66%。大约有三分之一的运行会在某个地方失败。如果每个阶段的准确率降到90%，你的成功率就只有43%，比抛硬币的几率还低。

这就是错误累积问题，它是任何多阶段AI系统中头号的可靠性杀手。每个阶段5%的改进不会给你带来5%更好的输出。它是复合的。将8个阶段中每个阶段的准确率从90%提高到95%，你的端到端成功率就会从43%提升到66%。这仅仅是每个阶段看似微小的改进，却带来了23个百分点的巨大提升。

我在自己的管道中找到了一个具体的例子。评估代理将其审查截断在5,000个字符。领域模型通常有15-30KB。因此，评估器根据内容的第一个三分之一来批准工件，遗漏了其余部分中损坏的引用和模式违规。一个确定性的JSON模式验证器本可以立即且廉价地捕获所有这些错误。我当时用大语言模型在做一台电脑本该做的工作。

## 真正的产品不是代码

我学到的最反直觉的一点是：工厂真正的产出不是应用程序代码，而是中间工件。

每个阶段都会生成结构化文档。一个创世DNA档案，从5个维度捕捉产品的个性。一个包含显式关系（不是抽象的hasMany/belongsTo，而是具有级联规则的具体外键）的领域模型。屏幕定义。内容地图。设计令牌。组件规范。

斯塔尔（Star）和格里塞默（Griesemer）在他们1989年的论文中称这些为“边界对象”。这些工件具有足够的“可塑性”来适应局部需求，同时又足够“健壮”以在不同群体之间保持一致性。在我的管道中，genesis-dna.json充当标准化形式。domain-model.json是一个仓库。screens.json是一个理想类型图谱。每一个都在不要求各阶段共享上下文或就方法达成一致的情况下，将意图从一个阶段传递到下一个阶段。

从公开可见的信息来看，我研究过的工具（v0、Lovable、Bolt.new、Devin）都没有产生结构化的边界对象。我不了解它们的内部机制，但从外部看，它们似乎只是将原始提示传递给代码生成器。这就是工厂和作坊的区别。

## 实际有效的方法

经过数月的迭代，以下是我所知道的有效和无效的方法。

有效：生成器-评论器模式。让两个不同的模型就输出质量进行“辩论”，比单一模型生成能提高23%的事实准确性。MetaGPT在ICLR 2024上发布了带有“代码 = 标准操作程序(团队)”框架的这一成果，其中代理通过结构化文档而非对话进行通信。

有效：带有工件的顺序管道。谷歌明确推荐这种方式，以提高调试的清晰度。当第5阶段出现问题时，你可以检查第4阶段的输出并找到根本原因。如果是扁平的集群，你很难追踪到故障。

有效：将模式验证作为廉价的质量门。几乎不费成本，能捕获最常见的错误类别，并且在毫秒级内运行。

无效：基于大语言模型对结构化数据进行审查。让电脑做电脑的工作，让大语言模型做判断性工作。

无效：超过3-4个代理的扁平代理集群。协调开销会让你不堪重负。层级结构不是官僚主义的遗物，而是一种信息处理优化。

无效：将每次运行都视为同等复杂。一个简单的CRUD应用不需要与实时代理系统相同的管道。为更简单的原型跳过不必要的阶段，可以降低成本并减少错误范围。

## 灯还没有熄灭

我不会假装“暗工厂”今天已经完全熄灯运行了。并没有。设计阶段后的视觉审查关卡仍然需要人工干预。复杂领域模型中的边缘情况仍然会让评估器出错。代码生成阶段仍然比我希望的更像“发射后不管”。

但我已经不再把这看作是一个AI问题。这是一个组织设计问题，恰好使用了AI作为其劳动力。代理就是员工。管道就是组织结构图。结构化工件就是那些让所有人保持一致的备忘录和规范。而使其发挥作用的管理原则，早在1933年至1990年间就已经发表了。

这种讽刺意味深长。我们正在构建历史上最先进的软件系统，但最有效的操作手册却是在计算机诞生之前就写好的。