夜雨聆风2026年7月，旧金山AI Engineer World's Fair现场，HumanLayer创始人Dex Horthy站在主舞台上抛出了一个尖锐的问题："你们所有人都在忙着搭建Agent的Harness（运行框架），但没有人认真思考过——当几百个Agent同时开始写代码时，你的软件交付系统会变成什么样？"
一周后，谷歌Chrome工程负责人Addy Osmani发表了《Software Factories, Light and Dark》一文，将Dex在大会上的思想提炼成一个简洁而深刻的二元模型：轻量软件工厂（Light Software Factory）与无光软件工厂（Dark Software Factory）。
这篇文章迅速在全球工程圈引发震荡。它不是又一篇"AI将取代程序员"的炒作文，恰恰相反，它戳破了很多团队正在陷入的集体幻觉：以为买了Agent工具、接了API、搭了几套Prompt模板，就建成了"AI软件工厂"。
真实情况是，绝大多数团队至今停留在"Harness工程"阶段——他们给Agent装上了工具、沙箱和内存，却从未真正回答一个核心问题：当代码生成的成本趋近于零时，真正昂贵且不可替代的东西究竟是什么？
一、从Copilot到Software Factory：软件工程的第三次范式转移
让我们先把时间拉回到三年前。
2023年，GitHub Copilot X发布时，整个行业讨论的是"AI能帮我写多少行代码"；2024年，Cursor、Cline等Agent编辑器兴起，话题变成了"AI能独立完成多大的任务"；到了2025年，人们开始意识到：单个Agent写代码的能力再强，如果每次都要人去启动、要人去调试、要人去合并，那本质上还是"高级自动补全"。
真正的革命，发生在当Agent不再需要人类逐次触发，而是可以从任务队列中自主取数、自主执行、自主校验，形成持续运转的生产线之时。
这就是软件工厂（Software Factory）概念的起源。
软件工程的前两次范式转移
理解软件工厂，需要放在历史坐标系中来看。软件工程发展至今，经历了两次真正意义上的范式跃迁：
第一次范式转移：从手工编码到工业化工具链
上世纪七八十年代，程序员在打孔纸上写代码，调试全靠人脑推演。编译器、IDE、版本控制系统的出现，第一次将编码行为工程化。个体生产力提升了数倍，但本质上仍然是"手工作坊"模式——一个工程师负责一个模块，从头到尾。
第二次范式转移：从单体交付到DevOps与云原生
2010年前后，CI/CD、容器、微服务、可观测性体系成熟，交付从"项目制"变成了"持续流"。代码提交后自动构建、自动测试、自动部署，工程师不再需要关心机器和环境。这一次跃迁，解决的是"交付后半场"的自动化问题。
而我们正在亲历的第三次范式转移，是编码本身的工厂化——生成代码的主体从人类工程师逐渐转向AI Agent，交付前半场也开始进入自动化流水线。
这不是简单的"效率提升"，而是整个生产关系的重构。
Addy在文中用一张图清晰地勾勒出了软件工厂的完整形态：业务意图、故障告警、用户反馈从上游流入任务队列；搭载了运行环境的Agent从队列中取任务，生成代码变更；自动测试、静态扫描、安全检测流水线完成校验；最后经过一道审核闸门，部署到生产环境；生产监控数据再回流到队列入口，形成闭环。
整套系统中，生成、测试、扫描这些环节几乎可以零成本无限扩容。唯一无法无限扩容、成本最高的瓶颈，就是那道审核闸门（Review Gate）。
而Light与Dark两种工厂范式的分野，恰恰就落在这道闸门上。
二、三元模型底层拆解：Loop、Harness与Factory的本质
在深入讨论Light与Dark之前，我们必须先搞清楚Dex Horthy提出的三层基础模型。很多团队对软件工厂的理解之所以混乱，就是因为混淆了这三个层级。
第一层：Loop——Agent的原子执行单元
什么是Loop？简单说，就是一个Agent自主完成任务的完整闭环：收集上下文→制定计划→执行动作→校验结果→如果不满足条件就继续迭代，直到达成目标或触发终止条件。
在Copilot时代，没有Loop的概念——你给一句提示，它吐一段代码，完事。你需要自己判断对不对、自己运行测试、自己修复问题。
而Agent时代的核心标志就是自动闭环能力。Agent写完代码后，会自己运行测试，发现报错了会自己回去改，改完再测，直到通过为止。它不是一次性输出，而是持续迭代的循环体。
Loop工程，本质上就是设计这套自动驱动机制。你不再是逐轮写Prompt，而是设计一套规则，让Agent知道什么时候该继续、什么时候该停止、什么时候该求助。
但Loop本身是脆弱的。没有边界的Loop会无限空转、会调用危险的工具、会忘记上下文、会在错误的方向上越跑越远。于是就有了第二层：Harness。
第二层：Harness——为什么Dex说"只做Harness远远不够"
Harness直译是"马具"，引申为Agent运行的约束框架。它包含了沙箱环境、可用工具集、权限边界、持久内存、错误处理机制、终止判定规则等一整套运行环境。
Dex Horthy有一句被广泛引用的话："裸模型没有Harness就像汽车没有底盘——发动机再强也开不出去。"
Harness决定了Agent能不能安全地干活。没有权限控制，Agent可能删库；没有沙箱隔离，Agent可能把本地环境搞崩；没有错误处理，Agent遇到异常就会死循环。
这也是为什么过去两年，整个行业投入了大量精力做Harness工程——LangChain、LangGraph、CrewAI这些框架，本质上都是在提供Harness层的能力。HumanLayer自己的核心产品，也是企业级Agent的Harness与人工审核接口。
但Dex在AI Engineer World's Fair上明确警告：Harness工程只是入场券，不是成功的保证。
很多团队陷入了一个误区：以为把Agent的运行环境搭好了，工具接好了，权限控制住了，就建成了软件工厂。然后他们困惑：为什么Agent确实能干活了，但整体研发效率并没有质的飞跃？
答案很简单：一个Agent跑得快，不代表一百个Agent能协同生产。
单个Agent的问题是工程问题，一百个Agent的问题是系统问题。这就进入了第三层：Software Factory。
第三层：Software Factory——规模化生产的系统工程
什么是真正的软件工厂？Addy给出的定义是：大量搭载了Harness的Agent循环，在统一的任务调度下持续运转，通过标准化的校验与审核闸门，稳定地产出可交付的软件变更。
这里有几个关键词：
任务队列化：所有工作以标准化工单形式进入队列，而不是工程师随手丢给Agent一个需求。队列是工厂的进料口。
调度系统化：任务如何分配给Agent、优先级如何排序、依赖关系如何处理、失败了如何重试——这些是工厂的调度系统。
校验标准化：所有产出必须经过统一的自动化校验流水线，而不是每个Agent自己测自己的。这是工厂的质检车间。
审核闸门化：所有变更必须经过同一道审核关口才能进入生产。这是工厂的出厂总检。
观测闭环化：生产环境的运行数据持续回流，驱动下一轮迭代。这是工厂的反馈闭环。
换句话说，Harness解决的是"单个Agent能不能安全干活"的问题，而Factory解决的是"大量Agent能不能稳定、持续、可控地规模化交付"的问题。
这两者之间的差距，就是实验室Demo与生产系统的差距。
三、Light与Dark：两种工厂范式的深层分野
理解了三元模型，我们终于可以进入全文的核心命题：Light Factory与Dark Factory，到底有什么本质区别？
Light Software Factory：人类驻守终审关口
轻量软件工厂的定义非常清晰：自动化流水线承担所有可标准化的工作，但每一条代码变更最终必须经过人类工程师的审阅和批准，才能合并上线。
在Light模式下：
• Agent负责写代码、跑测试、做静态检查、修复简单问题 • CI/CD流水线负责自动化构建、兼容性检测、安全扫描 • 人类工程师负责最终的代码审查、架构判断、风险评估
这是当下绝大多数企业正在走，或者说应该走的路线。它的逻辑很直白：Agent生成速度再快、自动化检查再全，也无法覆盖所有隐性风险。架构设计的合理性、业务逻辑的微妙性、技术债务的累积效应，这些东西很难被转化为机器可执行的校验规则。
人类守住最后一道闸门，本质上是用人力吞吐量换取风险可控性。
Addy在文中明确指出，Light模式不是"过渡方案"，不是技术不成熟时期的权宜之计。它是一种独立的、可持续的稳态范式。对于大多数业务系统，尤其是涉及资金、用户数据、核心链路的系统，Light模式应该是长期默认选项。
Light工厂的优势显而易见：风险可控、变更可溯源、架构偏离能及时拦截。它完美适配存量复杂系统（Brownfield）——那些积累了十年以上、充满了隐式知识和历史包袱的代码库。
它的短板也同样明显：人工评审成为吞吐量的天花板。你可以一夜之间扩容一百个Agent实例，但你不可能一夜之间培养出一百个能做终审的资深工程师。
Dark Software Factory：无人审阅的全自动交付
Dark Factory（无光工厂）这个名字，借鉴自制造业的"熄灯工厂"概念——最著名的是发那科的无人工厂，车间里只有机器人在运转，不需要灯光，因为没有人类在场。
对应到软件工程中，Dark Factory的核心定义是：代码变更从生成到部署上线，全程没有人类阅读过源代码，仅依靠机器校验体系放行。
注意这个判定标准非常严格：只要你的PR还需要人点一下"合并"按钮，那就不属于Dark Factory。
很多人第一次接触这个概念时的反应是："这怎么可能？太激进了，太危险了。"
但Dex和Addy都反复强调：Dark不是目的，吞吐量才是目的。Dark模式不是为了炫技而存在的，它针对的是特定场景下的特定问题——当你有海量的、标准化的、低风险的代码工作需要处理时，人工审核会成为不可承受的瓶颈。
什么样的工作适合Dark模式？Dex在演讲中列举了几类：
• 依赖版本批量升级与安全补丁 • 大规模代码格式统一与API迁移 • 日志、埋点等样板代码的批量添加 • 技术债务的机械化清理 • 测试用例的批量生成与补充
这些任务有一个共同特点：目标清晰、校验标准明确、即使出错影响范围也有限。
Dark Factory有三个不可逾越的前提条件，Addy称之为"三重硬性闸门"：
第一，意图必须可被机器解析。 需求不能是模糊的自然语言描述，必须能转化为精确、可验证的客观规范。比如"把所有React类组件改成函数组件"是可解析的，"优化一下用户体验"就不是。
第二，结果必须可被机器观测。 上线之后，成功还是失败，必须能通过自动化指标客观判定。错误率有没有上升？性能有没有下降？功能测试有没有通过？这些都需要有明确的量化标准。
第三，爆炸半径必须可控。 必须有完善的功能开关、灰度发布、自动回滚机制。即使Agent搞砸了，影响范围也能被严格限制在极小范围内，并且可以秒级回滚。
这三个条件缺一不可。缺少任何一个，Dark模式就是在裸奔。
更重要的是，Dark Factory不代表"不需要人"。人类并没有消失，只是从生产线上退到了工厂的维护层：
• 设计约束规则与校验标准 • 迭代Harness与审核机制 • 处理机器无法判定的高复杂度任务 • 修复工厂自身的失效场景
用Dex的话说："Human-in-the-loop变成了Human-on-the-loop。人不再在流水线上干活，而是站在旁边监督整个系统。"
核心分歧：判断力的归属权
读到这里你应该已经明白了，Light与Dark的争论，本质上不是技术路线之争，而是判断力归属权之争。
代码生成可以自动化，测试运行可以自动化，安全扫描可以自动化——但"这个变更到底应不应该上线"这个最终判断，到底应该交给人，还是可以交给机器？
这不是一个有标准答案的问题。它取决于任务性质、风险承受能力、系统成熟度、团队工程能力等诸多变量。
但行业里有一个非常危险的倾向：很多人把Dark Factory当成了"更高级"的形态，觉得Light是初级阶段，Dark是终极目标，仿佛越自动化就越先进。
Addy在文章中专门驳斥了这个观点。他的核心论点是：不要为了Dark而Dark。吞吐量提升才是目标，无光只是手段之一。
强行推进全流程无光，本质上是把所有风险都转移到了自动化校验体系上。而只要你的测试用例、约束规则、扫描工具有盲区——而这是必然的——故障就会以你意想不到的方式溜进生产环境。
更隐蔽的代价是技术债务。人工评审时，工程师会顺手修正一些不规范的写法、调整不合理的结构。机器不会。它只会严格按照你给的规则执行。规则覆盖不到的地方，债务就会默默累积，直到某天集中爆发。
四、中国语境下的软件工厂：热潮、误区与真实进展
把视线拉回国内。2026年的今天，"软件工厂"、"Agent工厂"、"AI超级工厂"已经成了科技圈的热词。几乎每周都有公司发布自己的"XX工厂"产品。
但如果用Addy和Dex的标准来衡量，真实情况如何？
国内"AI工厂"的三层现状
我把国内目前宣称做"软件工厂/Agent工厂"的玩家分成了三类：
第一类：工具封装层
绝大多数厂商停留在这一层。他们的"工厂"本质上是Agent开发平台——提供可视化编排、预置工具、知识库接入，帮你快速搭建一个能干活的Agent。
这对应Dex模型中的Harness层。它解决的是"Agent怎么跑起来"的问题，还没到"工厂"的层面。很多厂商把Harness包装成Factory来宣传，本质上是概念升级。
第二类：场景流水线层
少数头部厂商走到了这一层。他们针对特定行业场景，把Agent能力和业务流程深度结合，形成了可复用的交付流水线。
比如蚂蚁数科的Agentar 2.0，在金融、能源、餐饮等场景落地了"智能化决策流水线"、"电力交易流水线"、"餐饮运营工厂"等方案。宁波银行用它把复杂问答准确率从68%提升到91%，林洋智维的电力交易人力成本下降60%。
再比如和鲸科技走的"工厂+商店"模式，把RAG构建、模型托管、可视化编排、应用发布整合成一条智能体生产线，在光伏质检、航天研发等制造业场景落地了完整闭环。
这类方案已经具备了Factory的雏形——有标准化输入、有流水线处理、有确定性产出。但它们大多面向业务运营场景，而非软件工程本身。
第三类：代码交付工厂层
真正在软件工程领域实践软件工厂理念的团队，国内其实非常少。
大部分互联网公司的做法还是"工程师人手一个Cursor/Cline"，散点式提效，没有形成系统化的工厂级交付能力。少数走在前面的团队开始尝试建立内部的Agent代码生成流水线，但基本都停留在Light模式，并且覆盖的任务范围非常有限。
这很正常。毕竟Addy这篇文章7月20号才发表，整个行业对软件工厂的认知才刚刚开始统一。
国内团队最容易踩的三个坑
结合我观察到的情况，国内团队在落地软件工厂时，普遍存在三个认知误区：
误区一：把Demo能力当生产能力
很多团队做POC的时候，找一个干净的小项目，让Agent从头开发一个功能，效果惊艳。然后就得出结论："Agent可以替代初级工程师了"，开始大张旗鼓搞"无人开发"。
一放到真实的存量代码库里就傻眼了。隐式依赖、历史包袱、架构约束、业务规则——这些东西Agent根本理解不了，产出的代码看起来没问题，一跑全是坑。
这就是典型的混淆了Greenfield（全新项目）与Brownfield（存量系统）。全新项目里Agent确实很强，但真实世界绝大多数工作都是在存量系统上做迭代。
误区二：只看生成效率，不看校验成本
很多团队算帐只算"Agent写代码比人快多少倍"，不算"人来检查Agent写的代码要花多少时间"。
真实情况往往是：Agent写代码用了10分钟，工程师审查+修复用了两小时。算总账反而更慢了。
Addy模型的精妙之处就在于，它明确指出了Review Gate才是瓶颈。软件工厂的设计目标，不应该是最大化Agent的生成速度，而应该是最小化人工审核的负担。
误区三：试图一步到位上Dark模式
有些团队管理层一听"无光工厂"就兴奋，觉得这才是未来，要求技术团队尽快实现"全自动无人开发"。
这是非常危险的倾向。Dark模式对工程基础设施的要求极高——完善的测试覆盖、严格的架构约束、全面的可观测性、成熟的灰度回滚体系，缺一不可。
而国内很多团队，连基本的单测覆盖率都达不到50%，CI流水线经常挂，线上问题全靠人查。这种基础上搞Dark Factory，等于在沙滩上建摩天大楼。
五、混合工厂：Addy给出的最优解与落地路线图
既然纯Light有瓶颈，纯Dark太危险，那答案是什么？
Addy在文章中给出了明确的终局判断：混合软件工厂（Hybrid Software Factory）。
同一套平台上同时运行两条通道：Light主通道和Dark支线通道。通过任务分类器，把不同风险等级、不同标准化程度的工作路由到对应的通道。
这不是折中主义，而是经过制造业百年历史验证的最优解——即使是自动化程度最高的工厂，也不是所有工序都无人化。高精密、高风险的环节，永远有人把守。
任务分级路由机制
混合工厂的核心是任务分级。你需要建立一套分类标准，把所有研发工作分门别类：
Dark通道候选任务（高度标准化、低风险、易校验）：
• 第三方依赖版本升级与安全补丁修复 • 代码风格统一、Lint规则批量修复 • 日志、埋点、监控指标的批量添加 • 废弃API的批量替换与迁移 • 单测、集成测试用例的批量生成 • 文档自动生成与同步更新 • 简单的Bug修复（空指针、参数校验等）
Light通道必选任务（高复杂度、高风险、需要架构判断）：
• 核心业务逻辑开发与变更 • 支付、权限、安全相关的代码修改 • 跨模块架构调整与重构 • 新技术方案选型与落地 • 线上疑难故障的根因分析与修复 • 数据库表结构变更 • 对外接口协议变更
分类的标准不是"任务难不难"，而是"风险能不能被自动化校验完整覆盖"。有些任务看起来简单，但影响面大，就必须走Light通道。有些任务代码量很大，但逻辑高度机械，就可以尝试Dark通道。
四阶段落地路线图
Addy在文中给出了非常务实的四阶段落地路径，我结合国内团队的实际情况做了适配：
阶段一：搭建基础Light Factory（0-6个月）
这是绝大多数团队的起点。不要上来就想搞全自动。
核心动作：
1. 构建标准化的Agent Harness，统一权限、工具、上下文、沙箱环境 2. 强化自动化门禁体系：单元测试、集成测试、静态分析、安全扫描、架构规则 3. 建立标准流程：Agent生成PR → 自动检查全量通过 → 工程师人工评审合并 4. 配套机制：建立Agent产出质量的持续统计与反馈闭环
这个阶段的目标不是提效多少，而是建立安全基线——确保Agent产出的代码，在经过人工审核之前，已经排除了所有机器能发现的问题。
阶段二：任务分级，隔离流量（6-12个月）
当Light模式跑稳了，再开始梳理工作清单，划分任务池。
核心动作：
1. 全面盘点研发团队的日常工作类型，按风险等级和标准化程度打分 2. 筛选出第一批候选Dark任务池，通常从依赖升级、代码格式化这类最低风险的工作开始 3. 为Dark任务池设计专项校验规则，确保机器能100%判定对错 4. 建立灰度机制：Dark通道产出的变更，初期还是要人抽查，逐步降低抽查比例
这个阶段最容易犯的错误是贪多。不要一下子放太多任务类型进Dark池，宁可慢一点，也要稳。
阶段三：小范围试点Dark Lane（12-18个月）
在隔离的任务池中试运行全自动通道。
核心动作：
1. 选定1-2类最成熟的任务，开通真正的Dark通道——全自动生成、全自动校验、全自动合并、全自动部署 2. 配套完善的观测与回滚机制，确保任何问题秒级发现、秒级恢复 3. 持续统计故障率，不断补充自动化约束与校验规则 4. Dark通道始终保留一键切换回Light模式的能力
记住：Dark支线是增量，不是替代。它是在Light主通道之外额外开的一条快车道，不是把主通道关掉改造成快车道。
阶段四：混合工厂稳态（18个月以上）
最终形成稳定的混合交付体系。
核心动作：
1. 任务分类器自动化：新任务进入队列后，系统自动判断应该走哪条通道 2. 动态调整机制：根据线上故障率数据，自动调整任务分类边界 3. 人类工作转型：工程师从逐行写代码、逐条做评审，转向设计约束、优化规则、处理高难度问题 4. 持续迭代工厂本身：Harness升级、校验体系增强、任务池扩容
这才是软件工厂的成熟形态——不是全亮，也不是全黑，而是明暗交织、各司其职。
六、更深层的命题：人类判断力的价值重估
聊到这里，我们可以往更深一层走了。
Addy这篇文章表面上讲的是软件工厂的两种模式，背后其实藏着一个更大的命题：在AI时代，人类工程师的核心价值到底是什么？
过去一年，整个行业都在讨论"AI会不会取代程序员"。乐观派说"只会取代低级重复劳动"，悲观派说"大部分程序员都会失业"。但双方都默认了一个前提：编码能力是工程师的核心价值。AI越会写代码，人的价值就越低。
软件工厂模型彻底推翻了这个前提。
为什么Review Gate是最贵的瓶颈
在软件工厂的所有环节中，生成代码最便宜，测试扫描也便宜，唯独人工审核最贵，而且最难扩容。
为什么？因为审核需要的不是编码能力，而是判断力。
判断力是什么？是你看到一段代码，立刻就能意识到"这个写法在高并发下会有问题"；是你知道"这个模块下个月要重构，现在改这里会给后面埋坑"；是你能权衡"这个方案性能好但维护成本高，那个方案保守但更稳妥"。
判断力来自哪里？来自对整个系统架构的全局理解，来自对业务历史的深度认知，来自踩过无数坑积累的直觉，来自对技术债务的敏感度。
这些东西，没有办法写成规则输入给机器。它们是隐性知识（Tacit Knowledge），是工程师这个职业最核心的护城河。
很多人没有意识到：AI越擅长生成代码，"判断代码应不应该上线"的能力就越值钱。
因为生成端的成本趋近于零，审核端的稀缺性就会指数级上升。以前十个工程师写代码，两个资深工程师做审核；以后两个Agent顶十个工程师的产出，你还是需要两个资深工程师做审核——甚至需要更多，因为产出速度太快了。
这就是Addy在另一篇文章《Own the Outer Loop》中提出的核心观点：人类应该拥有外层循环的所有权。 Agent负责内层的"生成-验证"循环，人类负责外层的"裁决-问责"循环。
技术债务的隐形转移
Dark Factory还有一个很少被讨论的隐性成本：技术债务的转移。
人类工程师写代码的时候，会不自觉地做很多"额外工作"——顺手重构一下不合理的结构、修正一下不规范的命名、补充一下缺失的注释、提前考虑一下扩展性。这些工作没有写在需求里，但它们是代码质量的重要保障。
机器不会做这些。它只会严格完成你下达的指令。你让它改一个Bug，它就只改那一行，周围的代码再乱也不会碰。你让它加一个功能，它就用最快的方式实现，完全不考虑长期可维护性。
短期看，效率很高。长期看，技术债务会以远超以往的速度累积。
这就是为什么很多团队用了AI编码工具之后，前半年感觉效率飙升，一年之后开始觉得代码越来越难改、问题越来越多——因为债务到期了。
Dark模式下这个问题会更严重。连最后一道人工审核都没有了，债务会悄无声息地越堆越高，直到系统变得不可维护。
这不是危言耸听。软件工程几十年的历史反复证明：任何只关注交付速度、不关注代码质量的方案，最终都会付出沉重的代价。AI没有改变这个规律，只是加速了它的显现。
架构师的黄金时代
那么，什么样的工程师在软件工厂时代会越来越值钱？
Addy给出了三个方向：
第一，系统思考能力。 能hold住复杂架构、理解组件间的交互关系、预判变更影响范围的人。这种能力越往上越稀缺，AI完全替代不了。
第二，约束设计能力。 能把业务需求和架构原则转化为清晰的机器可执行规则的人。未来的工程师不是写代码，而是写"约束代码的代码"。
第三，风险判断力。 能在信息不完整的情况下权衡利弊、做出合理决策的人。这是人类相对于机器的终极优势。
换句话说，打字快的工程师会贬值，判断力强的工程师会升值。
这其实是好事。过去很多优秀的工程师把大量时间消耗在重复的体力编码上，是人才的巨大浪费。软件工厂把人从机械劳动中解放出来，去做真正需要智慧和经验的工作。
七、终局猜想：软件工厂的下一步会走向哪里
文章的最后，我们可以稍微展望一下未来。
Light与Dark的二元划分，是当前阶段的认知框架。五年、十年之后，软件工厂会演化成什么样子？
我有三个判断：
第一，Dark通道的范围会持续扩大，但永远不会覆盖全部。
随着模型能力提升、自动化校验技术进步、工程基础设施完善，越来越多的任务类型会进入Dark通道。今天很多需要人工审核的工作，未来机器都能可靠地完成。
但总有一些工作，永远需要人类的最终判断。涉及核心价值、重大风险、伦理权衡、创新探索的工作，人类的决策权不应该也不可能完全交出。
工厂的车间会越来越暗，但控制室永远灯火通明。
第二，软件工厂会从"代码工厂"进化为"系统工厂"。
今天的软件工厂主要产出代码变更。未来，Agent能做的事情会越来越多——设计架构、编写文档、配置环境、排查故障、优化性能，甚至设计整个系统。
工厂的产出不再是一行行代码，而是完整的、可运行的软件系统。人类的工作，从审核代码变成审核系统设计、审核风险方案、审核业务影响。
抽象层级不断上移，这是软件工程发展的永恒主线。
第三，人机协作的界面会持续重构，但人的主体性不会改变。
每一次技术革命都会引发"人会不会被取代"的焦虑，但历史的答案永远是：人会升级，不会消失。
编译器没有取代程序员，只是让程序员从汇编的细节中解放出来；IDE没有取代程序员，只是让程序员不用再手动管理内存；DevOps没有取代程序员，只是让程序员不用再操心服务器运维。
软件工厂也一样。它不会取代工程师，它会把工程师从编码执行层提升到设计决策层。
Addy在文章结尾写了一句话，我非常认同：
"The goal is not to build a dark factory. The goal is to build better software, faster and more safely. Use the light where you need judgment, use the dark where you need scale."
目标不是建造一座无光的工厂。目标是更快、更安全地构建更好的软件。需要判断力的地方，留一盏灯；需要规模化的地方，让机器去跑。
是的。软件工厂的终局，从来不是一片漆黑。而是明与暗的边界，恰好落在它应该在的地方。
写在最后
现在的我们，就像站在DevOps革命前夜的工程师——隐约感觉到有大事要发生，但还看不清具体的形状。有人兴奋，有人怀疑，有人已经在躬身入局，有人还在冷眼旁观。
历史不会重复，但总会押韵。上一次范式转移中，那些最早理解DevOps、最早落地持续交付的团队，获得了巨大的竞争优势。这一次，应该也不会例外。
不管你选择什么时候入场，至少先搞清楚Light和Dark这两个概念。至少别再把Harness当成Factory。
至少记住：代码生成的成本趋近于零的时候，判断力才是真正的硬通货。
