作为一名在编码代理时代之前拥有七年以上经验的软件工程师我从来不喜欢氛围编程vibe coding这个概念——凭感觉写代码缺乏工程约束。但我清楚它与用编码代理生成简洁、可维护的代码之间存在一条清晰的界限。这条界限即优秀软件原则与编码代理的交汇处正是由软件工厂来定义的。因此三个月前我搭建了自己的软件工厂 Squid目标是以最小的人工干预交付 Decoding AI 的所有中小型项目。第一个版本因为过度设计我很快就放弃使用了。与此同时,我不断看到有人痴迷于追逐下一个____工程标签,而不是关注可落地的成果——先是提示工程Prompt Engineering然后是上下文工程Context Engineering再是利用工程/框架工程Harness Engineering。到目前为止都还说得过去。但过去几周我写这篇文章时是 2026 年 7 月“循环工程”Loop Engineering和图工程Graph Engineering开始跑偏——这些说法听起来更像营销话术而不是在解决真正的问题。图工程把团队从 2024 年前后 LangGraph 时代就已经在做的直觉性工作过度理论化了。别误会,这些术语本身没有错(Anthropic 旗下 Claude Code 负责人 Boris Cherny 就说过,“我的工作就是写循环”),但我们确实在给几年前就已经存在的朴素做法,套上一层又一层新名词。当你忙着定义什么是循环的时候,你其实并没有真正思考交付软件的完整过程。在 2026 年人工智能工程师世界博览会AI Engineer World’s Fair上,软件工厂是核心主题之一。Factory.ai 的增长负责人 Tereza Tížková 将其定义为:“具有自主性的软件开发的整个循环、整个生命周期”。相信你对软件工厂已经有了初步概念。这篇文章想把它进一步系统化,并映射到完整的软件开发生命周期(SDLC)中——探讨工厂的自动化边界应该划在哪里、什么时候该停止自动化(以免摩擦成本超过收益),以及最重要的:人在这个过程中扮演什么角色——即便在所有代码都由 AI 生成的世界里,人依然不可替代。那么,究竟哪些环节值得自动化?人类在哪些环节能创造最大价值?哪些环节该自建,哪些该采购?软件工厂的设计和实体工厂一样,软件工厂用最少的人工干预实现软件生产的自动化:原始输入(缺陷报告、功能创意、生产事件)进去,最终交付的软件出来。它需要少数关键人物在关键节点做决策,还需要明确的质量关卡——没通过关卡,工作就流转不下去。Factory.ai 把自己的产品定义为用于软件开发生命周期(SDLC)的自我改进系统。Addy Osmani 把这套技术栈概括为**循环(Loop)、工具(Tool)、工厂(Factory)**三层:循环是原子;工厂则是由循环构成的组织架构图。Warp 的 CEO Zach Lloyd 也提出:“软件工程将演变为工厂工程”。(原文配图:软件工厂流水线——八个阶段共享同一个上下文层,生产信号回流,形成新任务的闭环。)这座工厂由八个阶段组成,可归纳为三大板块:① 决定要做什么。分诊/接收阶段负责对新任务分类、去重、路由;头脑风暴阶段通过市场分析、用户数据和技术调研,挖掘高影响力的功能方向;规划阶段是最关键的一环——它把调研结果转化为可执行的详细方案,过程中不断反问、细化,并把决策沉淀进架构决策记录(ADR)日志和术语表。这一阶段的产出是带文档的工单,供工程团队去实现,可以存放在纯文本文件里,也可以用 GitHub Issues、Linear 或 Notion 等项目管理工具追踪。在这一阶段,代理以只读模式工作,遍历代码库、AGENTS.md 文件,以及最重要的——上下文层。② 真正动手构建与检验。实现阶段是软件工程师代理与质量保证(QA)代理循环协作的过程,逐条完成工单,同时查阅相关文档;代码评审依据产品需求、架构规范和代码标准检查 PR 的差异;CI 评审运行测试套件,失败则自动触发修复;发布阶段负责把产品持续交付到预发布/生产环境,并保留人工的部署确认关卡。③ 自我改进。监控/事件响应把生产环境的信号(告警、报错、事故)反馈回分诊阶段,作为下一轮该做什么的新输入,从而形成完整闭环。与这八个阶段正交存在的,是上下文层。它在流程的早期阶段尤为关键:头脑风暴的质量完全取决于你手上有什么数据——用户分析、竞品分析、调研资料、对话记录、文档。如果这一层质量差,可探索的空间会被直接锁死。规划阶段同理:把一个想法转化为技术方案和工单,极大程度依赖上下文层中示例的质量。如果你想做一个全新的推荐功能,却没有任何参考案例,大语言模型(LLM)只会给出最常见的做法——但那往往并不适合你的产品。上下文层可以有多种形式。其中日渐流行的一种是LLM Wiki,这个术语由 Andrej Karpathy 提出,本质上是只用文件、不用数据库,把原始数据转化为结构化知识库的一种做法。Factory 通过其 AutoWiki 功能,把常用代码库自动转换成结构化知识库供代理查询,而不必每次都重新解析整个代码库。LangChain 最近也发布了 OpenWiki,一个用于管理代理记忆版 Wiki的命令行工具。如果你想深入了解如何把 Obsidian、Readwise、Google Drive 中的数据转化为代理记忆,可以参考这篇文章。人的位置在哪里为了说明人的作用,我们走一遍端到端的例子:给一个类似亚马逊的电商平台的购物助手做功能优化。假设数据显示用户对现有推荐不感兴趣,我们需要改进。头脑风暴阶段是灵感的源头。代理负责繁琐的重体力活:分析用户行为、扫描竞品的助手产品、把调研结果导入知识库。接下来,人开始分析数据、弄清用户为什么不买账、研究竞品方案,并提出改进思路,写成一份功能规格说明。注意,这一阶段的规格只需说清要解决什么业务问题,还不必给出具体技术方案。规划阶段是人借助软件工厂,把业务规格转化为技术实现方案的过程。假设要改的是推荐算法本身:人需要查阅知识库判断改动是否可行,权衡架构、接口、数据流、成本和延迟等因素;然后让代理扫描代码库,反复来回打磨,直到方案与代码库现状完全对齐。最终产出一系列工单,附带一份说明算法改动的**架构决策记录(ADR)**和一份术语表更新。代理在这两个阶段都能帮上忙——快速扫描海量数据、辅助完善方案——但人始终是核心决策者。头脑风暴和规划阶段建议用最强(前沿)模型。这两个阶段消耗的 token 远少于后续的执行阶段,但整条流水线的质量都取决于它们。一份打磨到位的方案,能让成本较低的模型(如 Opus、Sonnet)顺畅执行、不会卡壳;而一份粗糙的方案,会让它们反复试错,直到多花的 token 成本追平了模型价差。我发现即便方案不够完善,Sonnet 在高成本的推理任务中也常常反超 Opus:较小的模型需要更多轮尝试才能达到同样效果。总成本 token 数量 × 单价,而不是简单看模型等级。所以失败次数越多,推理轮次越多,token 消耗越大,总成本就越高。接下来才真正进入循环工程和图工程的地盘。(原文配图寓意:一份周密的方案能让廉价的执行模型物美价廉;而一份糟糕的方案反而会让便宜的模型变得昂贵。)实现阶段由软件工程师代理运行,接收所有已经准备好的工单——由于循环的范围限定在某个具体功能上,它只处理与之相关的工单。每完成一个工单,QA 代理就会介入,通过压力测试寻找应用缺陷。因为代理往往会高估自己的作业质量,所以工程师代理和 QA 代理必须严格分工——正如 Addy Osmani 所说,写代码的模型给自己打分总是过于宽容。个人规模下,这个循环可以很简单,几个终端窗口分别处理不同工单就够了;大规模部署时,则需要 7×24 小时运行的远程代理。这个循环要能正常运转,前提是代理能够真正与应用交互。QA 代理只需一条命令就能启动整套流程,且过程必须可复现——之后它可以在浏览器里跑应用、调用数据或微调管道,或者直接访问服务器 API。不管应用的界面是什么形式,代理都得像真实用户一样能用它。关键在于:尽可能让反馈循环原生地嵌入你的软件工厂。理想情况下,你需要多层反馈,按运行成本从低到高排列:代码检查(lint)→ 单元测试 → 集成测试 → 端到端测试。当循环反复失败时,根源几乎总是底层架构设计的缺失,而不是代理本身的问题。评审阶段分三步:第一步,把产品/架构需求与工单、ADR 逐一比对,任何偏差都会生成新工单打回实现循环;第二步,检查代码质量(模块化程度、命名规范),防止出现AI 味的问题,比如冗余注释、含义模糊的函数名;第三步,检查 CI/CD 流水线是否通过。每一步中,任何失败都会自动创建任务,交由代理去处理。并不是每个项目都需要走完全部三步。整套工厂流程的最终产物是一个等待人工审核并合并的 PR。但现实是——只要你在方案阶段花足够的时间打磨,提交上来的 PR 往往可以直接发布。(原文配图:软件工厂流水线中,人与代理之间所有权的动态分布。)那么,人到底在哪里最不可或缺?——头脑风暴和规划阶段,你必不可少;最终审核阶段,你依然要参与。除此之外的所有环节,基本可以交给代理。OpenAI 把这套理念推到了极致:五个月内完成约 100 万行代码、1500 个合并的 PR,没有一行是人工手写的。他们的原则是:“人类负责导航,代理负责执行。”别把工厂建得太大我的第一版 Squid(自建的软件工厂)野心太大,一心追求完全自主:庞大的远程工作流、并行代理集群,以及一条端到端运转的巨型流水线。它一开始跑得不错,直到出现意料之外的问题——这种情况几乎必然会发生。我没法调试,没法在运行中暂停,也没法在不放弃整次运行的情况下改变方向。它变成了一个巨大的单体系统,让我彻底失去了掌控,根本驾驭不了。我后来意识到,你需要两种模式并存:第一种是细粒度命令——让你能仔细检查方案、单独执行某个任务、或审查某一具体步骤;第二种是端到端命令——把若干小命令串联成一张完整的流程图,供你在愿意让代理全天候自主运行时使用,比如一个大的/plan命令,或/implement-review-all命令。本质上,每一步都是一个循环,整套流程就是你软件工厂的流程图。但请注意:规划环节应该始终独立于其他环节,单独作为一个命令——因为方案制定必须由人主导,否则结果很难真正贴合你的目标。总之,你需要能够随时介入、暂停、引导、打断这套系统,同时又保留完全自主运行的选项。瓶颈就是我自己——而这是我刻意为之的选择。说实话,自从编码代理兴起以来,我基本上是单人作战,我完全不明白那些能同时发布上百个功能的人是怎么做到的。我负责的大部分功能(以项目为单位)彼此高度耦合,根本无法并行。项目规模越大,能独立并行的功能自然会变多,但我依然认为这个数量是有上限的。所以在需要并行时,我只用本地代理,每个代理通过 git worktree 在独立的代码副本中运行。到目前为止,我从未真正需要过 7×24 小时运行的远程代理,也不想承担管理它们的额外负担。团队规模扩大后,自然有理由加大自动化投入——但这需要先积累经验。所以和任何软件产品一样:从小处着手,先自动化那些最耗时的瓶颈,等团队对系统足够熟悉之后,再逐步增加复杂度。别像我一样,在 Squid 上栽了跟头。自建还是采购无论选哪条路,你都会从一个预构建的编码框架开始。目前最主流的(带厂商锁定的)框架是 Claude Code 和 Codex;也可以选开源方案,比如 OpenCode,或者凭借极简、易扩展架构迅速走红的 Pi——它们都便于你在其之上继续搭建。但选定一个框架,不等于你就懂得如何配置它、把它整合进自己的软件工厂。所以每个人都需要理解编码代理的底层工作原理,至少要知道:终端里运行的代理循环是怎样的、远程运行时环境有何不同、如何评估代理表现,以及哪些上下文工程策略既能降低成本、又不会让代理变得笨拙。如果你想从零开始学习构建编码代理,可以参考我在 GitHub 上的开源课程。即便你从未打算自己造框架,这种底层直觉也会让你成为真正的高级用户。对于小团队来说,只需定义一套技能(skills)和代理(agents),把流程编码在现有编码框架(也就是你的软件工厂)之上,就能取得显著效果——我自己就是这么做的,用 Squid 支撑了我所有的项目。也有一些现成的轻量级软件工厂,完全靠.md文件里定义的技能和代理驱动,比如 Matt Pocock 的技能库,或者 BMad Method。但请记住:工厂的核心是流程,不是工具。一套与团队现有工作方式不匹配的工厂,只会增加摩擦,永远不会被真正采用,最终形同废弃。一旦你让未被你亲自监督的工程师去运行代理,你就已经跨过了该考虑采购的门槛。可观测性、调用链追踪、成本核算、按 token 计费——这些不再是可选项,而会变成需要有人专职负责的工作。把一堆代理接入 Linear、Slack、CI 等分布式基础设施,会带来巨大的后勤负担,而这本身并不是你产品的核心价值。这种时候,选用现成方案(比如自带 Droid 代理的 Factory.ai,或 Warp 的 Oz)就完全合理。正如 Warp CEO Zach Lloyd 所说:“工厂的大部分工作量,并不在于造一个新界面,而在于把它嵌入到人们已有的工作流程中。”反过来,当平台的限制给你带来的成本,已经超过了自己组队重建它的成本时——正如 OpenAI 关于其 Codex 相关产品的报告所展示的那样——你就该考虑重新自建。一个大致的经验法则:小规模自建,中等规模采购,超大规模再自建。接下来会发生什么此刻,肯定已经有人在琢磨下个季度的新____工程标签了。但你用来交付真实代码的软件工程流程,并不会因为换个名字而经常改变。所以,保持开放心态没问题,但更重要的是聚焦可落地的成果,而不是纠结怎么给事物贴标签。正如 Zach Lloyd 所建议的:找到工作中最让人头疼的那一个点,然后构建一个足够小的循环去解决它。残酷的现实是:软件工厂仍处于早期阶段,远未完美,更谈不上真正完全自主。通常,如果有人告诉你他们已经解决了软件工厂这个问题,那大概率是他们测试得还不够充分,或者只是想把这个概念卖给你。我相信,除了头脑风暴和规划这两个环节之外,整个软件开发生命周期终将实现高度自动化——但眼下,我们仍在摸索前进。留一个问题给你:在你的工厂里,哪个环节最离不开你?我这边一路自动化下来,瓶颈始终停留在规划阶段。延伸阅读Osmani, A. (2025). “Loop Engineering.” X. 链接MacManus, R. (2026). “AIEWF Daily Dispatch: Loops, Software Factories, and the Frontier Deployment Engineer.”Latent Space. 链接Factory.ai. “Native Agentic Software Development Platform.” factory.aiOsmani, A. (2025). “Software Factories: The Light and the Dark.” X. 链接Karpathy, A. “LLM Wiki.” GitHub Gist. 链接Abboud, M. “How Coding Agents Actually Work: OpenCode Internals.” 链接Kapoor, S. “Building and Evaluating AI Agents.”AI Engineer. YouTubeOpenAI. “Harness Engineering: Leveraging Codex in an Agent-First World.” 链接Parsons, C. “Ralph Loops: Building Ship-Ready Simple AI Loops.”AI Engineer. YouTubePocock, M. “Software Fundamentals Matter More Than Ever.”AI Engineer. YouTubeMacManus, R. (2026). “Warp CEO Zach Lloyd on Why Software Factories Are the Next Phase of Coding.”Latent Space. 链接Iusztin, P. (2026). “Building a Coding Agent from Scratch: Harness Architecture.”Decoding AI. 链接Iusztin, P. (2026). “Building a Coding Agent from Scratch” 课程. GitHub. 链接Iusztin, P., Bouchard, L.-F. (2026). “LLM Wiki as Living Memory for AI Agents.”Decoding AI. 链接Decoding AI Magazine