AI 工程的文化
2011 年，Noah Brier 联合创立了 Percolate。在那里，他学到了作为 CEO 最艰难的工作：如何让整个公司朝着同一个方向前进。如今，在他自己的 AI 咨询公司 Alephic 以及个人工作中——他将 Claude Code 用作第二大脑——他正面临一个同样的问题，只不过这次，参与者中多了 AI 智能体。AI 本来被期望能让协调工作变得更简单。但 Noah 认为，它反而制造了新的协调难题。在本文中，他反驳了“软件工厂”这一比喻，并从 Stewart Brand 的“节奏层”（Pace Layers）理论中汲取灵感，提出了一个框架，旨在让人类与硅基智能体共同构建同一个目标。—— Kate Lee
Strong DM 是一家软件公司，其仅有三人的 AI 团队将他们用于自主生成代码的系统称为“软件工厂”。企业家 Dan Shapiro 提出的一个关于 AI 编程的、广为流传的框架，最终形态被命名为“黑暗工厂”，这名字源于一家可以在关灯状态下运行的日本机器人制造厂。Factory.ai 已从红杉资本和 Khosla Ventures 等风投机构筹集了数百万美元，并围绕这个比喻建立了一整套业务——他们将自己的自主编程智能体称为“Droids”。
在我们于 Alephic 的工作中，我吸收了许多 StrongDM 关于智能体辅助软件开发的理念，但有一点我完全无法认同：我认为“工厂”是一个错误的比喻。
如果说最艰巨的难题是制造人们想要的东西，那么构建软件的过程，看起来更像 安迪·沃霍尔 的工厂，而非 亨利·福特 的。两者都关注产出，但福特的工厂专注于机械化，力求尽可能无偏差地大规模生产一模一样的汽车。而沃霍尔关心的，则是如何确保所有工作都围绕着一个单一的创意愿景展开。
福特的工厂——更确切地说，是其内部的流水线——是为消除瑕疵而设计的。六西格玛 这套因通用电气而广为人知、备受制造商喜爱的质量管理方法论，其衡量标准就是缺陷率。但质量的起点，在于决定要建造什么。这就是为什么产品与市场的契合是创业公司的通用语言：如果你没有做出市场需要的东西，其他一切——包括你的代码质量——都毫无意义。
业界太多时候把软件当作一个待优化和解决的问题。这在代码编写和测试环节或许成立，但一个更贴切的比喻其实一直就在我们眼前：那是一家软件公司，而不是一家软件工厂。
正如在 AI 出现之前一样，对于企业而言，最核心的难题依然是创造愿景并围绕它达成共识——如何让整个人类团队，以及现在的人类和智能体（以及带着智能体的人类），从系统架构到每一行代码，都朝着同一个愿景构建。在智能体远未出现之前我就明白，实现这一点的过程，更类似于创建一家创业公司，而不是组装一辆汽车。以下是我尝试提出的一个框架，旨在让整个人类和智能体系统共同构建同一件事物。
对齐问题并非新鲜事——AI 也未能解决它
多年前，在 2011 年我联合创立内容营销平台 Percolate 时，就曾遭遇过这个问题。当我们在不到三年内将公司从零扩展到上百人时，我作为 CEO 的职责，也从构建产品，转变为构建一个能够持续构建产品的公司。我的“智能体”是员工，我的工作是设计他们工作的系统。我当时的结论是，文化是我能运用的最强有力的杠杆之一。
正如 Ben Horowitz 所言，文化是“当你不在场时，你的公司如何做出决策”。这正是我需要的：那些文档、工具和惯例，能帮助每个人在没有把决策层层上报的情况下，尽可能做出最佳决策。我大概花了一半的时间在这上面，建立了一本活的文化手册，为每一位新员工举办入职培训，并开发了内部工具，将知识自动推送给合适的人。
每一项新技术都承诺会解决这些协调问题。但现实当然没那么简单。它们真正做的，是重塑周围的环境，并在这个过程中，制造出以前不存在的新问题。AI 也不例外。
开源软件提供了一个早期的视角，展示了 AI 可能造成的意外问题：几年前，主要挑战是寻找愿意仅凭善意贡献代码的维护者，而今天的挑战，则变成了从涌入 GitHub 的、由 AI 生成的成百上千份劣质拉取请求中进行筛选。
十五年后的今天，我在 Alephic 的受众不再仅仅是与我共事的人类。这些人类常常与智能体搭档，而且，智能体本身也越来越多地独立交付工作。然而，核心问题依旧没变。
如果你使用编程智能体超过一周，你很可能已经有过这种体会：代码能跑，但读起来感觉完全不是你的风格——它忽略了代码库中显而易见的抽象方式和风格规范。换句话说，它看起来就像是团队里一个没有经过适当入职培训的新工程师。我们会为人类同事撰写入职文档并进行培训，但大多数人还没有为 AI 智能体做这件事。目前还没有。
AI 工程的节奏层
我至今仍然保留着一份入职文档和一系列每位新员工在第一周需要完成的活动，其中包括在他们的第一个编程任务里，在我们自制的学习系统中构建一个模块（最近几期的主题是 GPU、量化技术和智能体商务协议）。
但我也在构建能更进一步发挥作用的工具，确保我们的代码可维护、风格一致，并且以我们期望的方式构建。
我将我们的工具集视为一种“文化堆栈”：在这套堆栈里，标准塑造架构，架构又反过来塑造规格说明、计划和代码。这些层次的灵感，来源于反主流文化系统思想家 Stewart Brand 提出的“节奏层”框架。这是一个描述社会如何以不同速度变化的模型：从历经千年演变的大自然，到可能一日一变的时尚潮流，不一而足。底层变化缓慢，上层变化迅速。
核心启示：AI 并未自动解决团队协作的对齐问题，反而通过引入新的参与者和工作方式，使其变得更为复杂。真正的挑战在于构建一套融合文化与工具的系统，像管理人类团队一样，将标准和愿景注入到 AI 智能体的“行为”中，确保从底层架构到单行代码都服务于同一个创意目标。
《The Culture of AI Engineering》的发芽报告
材料核心
Noah Brier 用他管理人类团队的经验重新思考 AI 编程代理的管理问题，指出“软件工厂”是错误隐喻——软件开发更像安迪·沃霍尔的创意工厂而非亨利·福特的流水线。真正的挑战始终是对齐：如何让人类和 AI 代理围绕同一愿景工作。他借用 Stewart Brand 的“步调节奏”框架，提出了一套分层管理工具和文化的方法。
发芽 01：工厂隐喻之争——当机械复制碰上创作意图
种子
Brier 区分了两种“工厂”：“福特工厂追求零缺陷的标准化复制；沃霍尔工厂追求批量生产中的单一创意意志。”这不是文字游戏，而是两种根本不同的组织逻辑。一个将人的判断视为需要清除的噪音源，一个将人的判断视为必须传递的信号。AI 代理的出现在放大产能的同时，也放大了这个问题：当产出速度飙升，如果你传递的是错误信号，你会更快地造出没人要的东西。
但沃霍尔的工厂本身就是一个需要仔细审视的隐喻。1962 年到 1968 年间，安迪·沃霍尔位于纽约东 47 街的工作室（被称为“银色工厂”）并非传统意义上的创作空间。沃霍尔同时操作着多幅丝网版画（玛丽莲·梦露系列、坎贝尔汤罐系列、灾难系列），由助手完成实际印制，他本人常常只是指出颜色选择和位置。来工厂的人包括鲍勃·迪伦、卢·里德、伊迪·塞奇威克——他们不是雇员，而是素材提供者。沃霍尔的核心能力不是“做”，而是“选择”和“命名”：选择什么进入画面，选择用多少颜色，选择“这算完成”。质量和价值的来源不在执行端，而在判断端——什么值得被生产。
这正是 Brier 所说的“愿景对齐”问题。1964 年，沃霍尔工厂的一名助手独立完成了一组丝网版画并试图以沃霍尔的名义出售。沃霍尔的回应不是检查每张画的印刷质量（那些画技术上完美），而是切断了那名助手的接触渠道。从工业质量管理的角度看，这些画是合格产品——丝网定位准确，颜色均匀，签名真实。但从沃霍尔工厂的角度看，它们没有经过核心的“选择”行为：沃霍尔没有决定“这个要做”。它们是对齐失败的产物。
Brier 的代理问题在这里找到了惊人的对应：AI 编码代理生成的代码技术上可以正常工作——它们通过了测试，语法正确，性能达标。但它们“感觉像别人写的”，因为缺少那个“选择”时刻。当 Brier 说他为代理建立 onboarding 文档和活动（而不是简单地给 API 密钥和 prompt 模板），他实际上在做沃霍尔对每个新助手做的事情：传递判断标准，而不仅仅是执行指令。
2015 年经济学家 Brian Arthur 在《The Nature of Technology》中提出一个被低估的观点：技术不是“被发明的”，而是“被组合的”。但在 AI 编程代理的语境下，这种组合行为一旦委托给代理，就会产生一个微妙后果——代理组合出的输出可能技术上是新颖的组合，但它组合的原理（“这里应该抽象”，“这个函数应该拆开”）来自于训练数据中的统计模式，而非对当前项目特定上下文的理解。这就像沃霍尔的助手如果在没有沃霍尔指令的情况下独立组合坎贝尔汤罐和玛丽莲·梦露——技术上可能，但它缺少那个判断：“这有意义吗？”
Aha 瞬间
“标准化工厂的敌人是缺陷；创意工厂的敌人是脱离意图。而 AI 代理让二者以新的方式同时出现：你可以零缺陷地制造大量脱离意图的产物。”
发芽 02：步调节奏——为什么你的 linting 规则不能解决对齐问题
种子
Brier 引入 Stewart Brand 的“步调节奏”框架不是为了制造漂亮的架构图，而是指出一个深层问题：人类和 AI 代理在不同步调节奏的层面上操作时，会出现系统性的“节奏错配”。编码代理运行在最快层（分钟级的代码生成），而代码库的架构范式和业务愿景运行在较慢层（月级或年级的变化）。当代理在快层疯狂操作而缺少慢层输入时，就会产生 Brier 观察到的现象——代码能跑，但“不像我们写的”。
Melvin Conway 在 1968 年提出的“康威定律”在这里发生了奇怪的逆变。康威的原始观察是：“任何设计系统的组织，其产生的设计结构都是该组织沟通结构的复制品。”如果一个组织用四个团队分别负责编译器、UI、数据库和网络，那么他们生产的软件就会有四个耦合松散的模块——因为团队沟通边界成为了系统边界。
在 AI 代理时代，问题不只是“代理会复制什么样的组织沟通结构”，而是“代理是从哪里获得它的组织沟通信号的？”如果代理只是从 GitHub 上数百万个代码仓库的统计平均中学习——“这里通常这么做”——那么它继承的“组织沟通结构”是模糊的、平均化的、来自一个不存在的“平均工程团队”的。这就是为什么 Brier 说要为代理建立 onboarding 文档：你不是在教它编码，你是在把它纳入你的组织沟通结构。你在把它从一个“外部承包商”变成一个“团队成员”。
2006 年亚马逊 CTO Werner Vogels 发布了一个后来被神话化的内部决定：亚马逊内部所有服务必须通过 API 通信，不通过 API 通信的团队会被解雇。这通常被解读为微服务架构的起源，但更深的层面是：亚马逊强迫它的组织沟通结构与系统结构对齐——人类团队之间的所有通信都必须在 API 契约中显式化，不能通过走廊交谈或共享数据库来作弊。这是康威定律的主动操演：不等待设计结构被动地反映沟通结构，而是强制沟通结构变成一种可审计的形式。
Brier 的步调节奏堆栈在做一个类似的事。他不仅定义了规范层（最慢）和架构层（较慢），还让这些层的信息向下渗透到代码层（最快）。当他的团队为代理创建 onboarding 活动——比如“你的第一个任务是构建一个量化模块”——他在做的事情不是技能培训，而是 API 契约化：他迫使代理暴露它理解了什么，以及它是如何做出选择的。第一个任务成为一个诊断窗口。
问题在于，Brier 正确识别了这个框架，但他暗示这可以“解决”对齐问题。亚马逊的经验恰恰说明，即使强制执行 API 契约，对齐问题也不会消失——它只是转移到了层与层之间的接口上。当一个代理在快层生成了 200 行代码，而架构文档在慢层说“这里应该有一个抽象层”，谁来负责接口翻译？谁来决定“足够接近”的定义？
康威本人在 50 年后（2018 年的一次访谈中）补充说，他最初的观察不是为了给出解决方案，而是为了警告：你无法通过局部优化来解决系统性问题。如果代理在快层生产代码的速度已经远超人类在慢层做出决策的速度，那么不管你建立多少层步调节奏，都会面临一个根本性的瓶颈——慢层跟不上快层。
Aha 瞬间
“步调节奏框架的价值不在于把东西分好层，而在于暴露那个致命的瓶颈：当代理的代码生成速度超过了架构决策的制定速度，你建的就不是一座金字塔，而是一个倒金字塔——顶部的每小时更新十次，底座还在上个月的文档里。”
发芽 03：从“员工的员工”到“员工”——AI 代理在组织中的身份迁移
种子
Brier 有一段关键但未充分展开的观察：“AI 代理让人想起一个还没完成 onboarding 的新工程师。”如果只是把代理当作一个更快的初级工程师来管理，Brier 的 onboarding 方案是够用的。但如果代理开始承担原来由高级工程师、甚至架构师承担的决策工作，onboarding 文档就不够了——你需要代理参与 writing 那些文档，而不仅仅是 learning 它们。这是什么意思？
这迫使我们面对一个 Brier 没有直接问的问题：AI 代理从“工具”变成“同事”的阈值在哪里？
2014 年，认知科学家 Gary Klein 在研究消防员、护士和军事指挥官时，提出了一个框架：专家和新手的区别不在于知识量，而在于“模式库”的丰富度。专家不是在推理——他们是在识别。一个经验丰富的消防员进入燃烧建筑时，不是在心里跑一个风险评估清单；他看到的是“这个楼梯的烟雾颜色不对——立刻撤退”。这个判断来自数万小时的模式积累，而非规则匹配。
当 Brier 说他让新工程师在入职第一周“构建一个量化模块”，他在尝试做的不是传授知识，而是植入模式库——他希望新成员不只是“理解了量化是什么”，而是“识别出我们团队做量化的方式”。但对 AI 代理来说，模式库的植入面临一个悖论：代理的模式库（训练数据）远远大于任何人类工程师，但它的模式库是 untuned 的——它无法分辨“我在这个团队里遇到这种情况时应该优先哪个模式”。
这就产生了一个微妙但重要的身份问题。如果代理是一个工具，它的输出由人类签字负责——这是 Brier 方案中隐含的前提。但如果代理的输出质量已经与训练良好的中级工程师持平（或更好），当人类开始默认接受代理的代码而不深入审查时，代理实际上在承担判断功能——它在选择“这么做比那么做更好”。从那一刻起，它不再是“员工的员工”，而是“员工”。
D.A. Norman 在 1993 年的《Things That Make Us Smart》中预言过这个陷阱：当自动化系统接管了人类的操作职责，人类就变成了监控者。而监控是人类最不擅长的工作——我们会注意力漂移，然后在自动化故障时惊恐地接管。但如果 AI 代理不只是操作层，它们开始在判断层输出——比如它们不是接受“请实现这个 API”的指令，而是说“我认为你应该废弃这个 API 并重新设计”——那么人类被重新定位为“元判断者”：不是判断代码是否正确，而是判断代理的判断是否正确。
Brier 的步调节奏堆栈在这里暴露出它的局限。为代理建立 onboarding 文档的前提是：人类仍然掌握着“选择正确的事”的能力，而代理只需要学会“以正确的方式做事”。但如果代理能够提出“正确的事是什么”的候选答案，那么 onboarding 这个词就不够了——你需要的是 co-designing：你不再把代理当作“刚加入团队的成员”，而是当作“在这个问题上可能比团队里任何人都更熟悉潜在模式的外部顾问”。
2019 年 AlphaGo 团队在一篇论文中提到，职业棋手在与 AlphaGo 对弈后改变了他们对“正确走法”的理解——某些被职业传统视为错误的开局，被 AI 证明是可行的。这不仅是工具使用问题，更是知识权威的重新分配。
当 Brier 说“代理自己也在独立交付工作”时，他已经站在了这个门槛上。接下来的问题不是“如何为代理写更好的 onboarding 文档”，而是“当代理的输出可能改变你对‘正确做法’的理解时，你的步调节奏堆栈中最慢的那几层（nature, culture, governance）——在 Stewart Brand 框架中那些变化最慢的层——是否也允许被硅基智能重塑？”
Aha 瞬间
“当你第一次发现自己认为代理写得比你计划时更好，你已经不是在管理代理了——你在与一个外部判断来源进行谈判。而组织文化在不承认这个时刻之前，都不会真正准备好。”
你的思考空间
如果一个 AI 代理在三个月内生成了你的团队五年积累的代码量，且其中 30% 的代码推翻了原有架构约定（不是因为错误，而是因为它发现了更优解），你的步调节奏堆栈的哪个层会最先崩溃？不是代码层，也不是规范层——是信任层。
如果你为代理准备了完美的 onboarding 文档，但三个月后代理通过实际参与项目告诉你说“文档里第三条抽象原则在 87% 的场景下是错的”——你把这个反馈当作 bug report 还是 architecture proposal？这两者的权力结构完全不同。
Brier 的框架假设了一个相对稳定的业务愿景。但如果一个创业公司在持续探索 PMF（产品市场契合），这个愿景每两周可能就会调整一次，那么最慢层的东西被强迫以快层的速度移动。在这种情况下，代理的“文化”应该被设计成什么样子？
沃霍尔工厂的终结不是因为创意死了，而是因为 1968 年一位被工厂拒之门外的边缘人物开枪射伤了沃霍尔。当 AI 代理成为“员工”，它们不会开枪。但它们会产生一种更温和的伤害：它们会安静地、持续地输出平均值，直到你的软件不会犯错，也再不会说出任何独特的语言。