2026 年 7 月 1 日，Latent.Space 连续发布了两篇很有意思的访谈。一篇谈 Cursor 的 Forward Deployed Engineering，另一篇谈 Warp CEO Zach Lloyd 对 software factories 的判断。前者讲 Cursor 如何派出前向部署工程师，帮助企业把 AI agent 接进真实的软件开发生命周期；后者讲 Warp 为什么从终端工具走向 Oz 这样的 agent 编排平台，并预测大型软件项目会越来越像一座自动化的软件工厂。

这两篇文章放在一起看，信息量比单独看更大。

如果只看 Cursor，会觉得这是一家 AI 编程工具公司在做企业服务：客户有复杂流程、遗留系统、权限边界和组织阻力，所以需要一批懂工程也懂客户现场的人，把工具真正部署进去。如果只看 Warp，会觉得这是一个开发者工具公司在重做产品定位：终端不再只是人敲命令的地方，而要变成多个 agent 持续执行研发任务的控制台。

但两者指向的是同一个方向：AI 编程正在从“帮个人写代码”走向“帮组织生产软件”。过去两年，大家讨论最多的是补全、聊天、生成函数、修 bug、写测试。现在新问题变成了：如果 agent 可以长期运行，可以理解任务，可以提交改动，可以触发测试，可以接入 issue、Slack、Jira、GitHub、CI/CD，那么软件开发本身会不会被重新组织？

这就是“AI 软件工厂”这个词突然变得重要的原因。

它不只是一个更大的 agent，也不是把 Claude Code、Codex CLI、Cursor、Warp、Gemini CLI 这些工具简单堆在一起。更准确地说，它是一套新的生产结构：人定义目标和边界，AI 执行大量可拆分任务，系统持续反馈结果，组织通过流程、权限、评估和审查来决定哪些产出可以进入生产。

换句话说，软件工厂不是“无人写代码”，而是“写代码”这件事不再是研发流程的唯一中心。

从个人助手到组织级生产系统

过去的 AI 编程工具，最容易被理解成个人生产力工具。一个工程师打开编辑器，让模型补全代码、解释报错、生成脚手架、补测试、重构局部模块。这个阶段的核心问题是：它能不能让一个人更快？

这个问题很重要，但也有边界。

个人效率提升到一定程度后，组织会遇到新的瓶颈。比如，一个开发者用 agent 很快写出了代码，但需求是否清楚？设计是否经过讨论？测试是否覆盖关键路径？代码审查是否可信？变更是否符合安全策略？上线后如何监控？如果出现问题，反馈如何回流到下一个任务？

这些问题都不是“再生成一点代码”能解决的。它们属于软件工程的完整链路。

Cursor 在访谈中谈到的软件工厂，重点就在这里。Pauline Brunet 介绍 Cursor 的 Forward Deployed Engineering 团队时，并不是把 FDE 描述成普通的售前、交付或客户成功，而是把它放在企业 AI 转型的现场。Cursor 的客户主要是工程组织，FDE 要和客户一起看他们怎样计划、设计、写代码、测试、审查、部署和维护应用。也就是说，Cursor 关心的不是某个开发者有没有打开 AI 补全，而是 agent 如何进入端到端的软件开发生命周期。

Warp 的说法更直接。Zach Lloyd 在访谈中把软件工厂描述为从交互式开发走向自动化开发的转变。他关注的主循环包括 triage、specification、implementation、review、verification、shipping 和 monitoring。翻成团队日常语言，就是从问题分诊、需求规格、实现、审查、验证、发布到监控，把软件工程的主要环节串成一个可以被 agent 持续推动的循环。

这两个视角非常互补。

Cursor 从企业现场切入：真实组织很复杂，agent 必须接入客户已有的系统、流程和团队习惯。Warp 从产品架构切入：未来会有一个平台，让团队选择仓库、选择要自动化的生命周期环节、选择哪些节点需要人类介入，然后让系统开始循环。

一个更像“把 AI 工具部署进企业”，一个更像“把企业研发流程产品化”。但它们背后的判断一致：AI 编程的下一阶段，不会停留在个人和模型之间的对话框里。

Cursor 的路线：前向部署工程师把 agent 带进真实研发链路

Cursor 的访谈里，最值得注意的不是“AI 软件工厂”这个词本身，而是它为什么需要 Forward Deployed Engineering。

如果 AI 编程只是一个编辑器功能，那么产品足够好、文档足够清楚、用户自己安装就可以了。可一旦目标变成“让 agent 在组织级研发流程中承担更完整的角色”，事情就复杂很多。不同公司有不同的代码库结构、权限模型、测试体系、发布流程、安全要求、合规规则和团队边界。一个云端 agent 能不能读某些仓库？能不能自动开 PR？能不能触发部署？能不能访问客户数据？能不能把外部 issue 内容直接作为上下文？这些问题都不是默认配置可以轻松回答的。

所以 Cursor 需要 FDE。

在 Latent.Space 的访谈中，Brunet 把 FDE 描述为一种深入客户系统和工具的工程角色。这个团队不只是帮助客户“用上 Cursor”，而是把 AI 能力部署到能解决规模化问题的位置。她提到 Cursor 希望帮助客户建立覆盖软件开发生命周期的 AI software factory，包括计划、设计、写代码、测试、审查、部署和维护。

这件事的难点在于，企业里的 AI 采用往往先从少数早期用户开始。一个团队里可能有 10% 或 20% 的人非常积极，会自己使用本地 agent 或云端 agent，把个人任务做得很快。但这并不等于组织已经完成转型。真正困难的是：如何让 agent 跨越个人习惯，进入团队流程，并且以一致的方式服务多个项目、多个角色、多个系统。

这也是软件工厂和个人助手的分水岭。

个人助手重视即时反馈。你问一个问题，它回答；你让它改一段代码，它尝试；你不满意，继续追问。组织级软件工厂则重视流程稳定性。它要知道什么任务可以自动跑，什么任务必须等待审批，什么上下文可信，什么输出必须验证，什么失败需要升级给人类。

Cursor 的 FDE 模式，本质上是在帮企业做这层“从个人工具到组织机制”的翻译。

这里的翻译不是把英语文档翻成中文，也不是把配置项填好，而是把组织真实的工作方式翻译成 agent 可以执行、系统可以追踪、人类可以验收的流程。比如，同样是“修一个 bug”，在个人工作流里可能只是打开 issue、读代码、改文件、跑测试。但在企业工作流里，它可能还涉及优先级判断、客户影响评估、数据权限、版本分支策略、回归测试范围、审查人选择、上线窗口和事故复盘。

AI 软件工厂要处理的是后者。

这也解释了为什么 Cursor 的 FDE 要求很高。访谈中提到，他们寻找的是有多年软件工程经验、做过生产系统、懂架构取舍、也有客户面对面经验的人。这类人不是单纯的 prompt 工程师，而是能把一个真实业务问题拆成系统、流程、权限、指标和落地步骤的人。

换句话说，当 agent 变强以后，靠近客户现场的工程能力反而变得更重要，而不是更不重要。

Warp 的路线：把研发主循环做成可管理的 factory floor

如果说 Cursor 的关键词是“部署进企业”，Warp 的关键词就是“自动化主循环”。

Warp 起初是一个现代终端。后来 AI 编程兴起，它变成带有 coding agents 的终端。再后来，CLI 工具竞争越来越激烈，Claude Code、Codex CLI、Gemini CLI 等产品不断出现，Warp 选择把核心 CLI 开源，并把更大的产品重心转向 Oz 这样的 agent orchestration platform。

这个转向很有代表性。它说明终端、编辑器、CLI 这些入口本身正在发生变化：过去它们是工程师亲手操作系统的界面，现在它们开始变成工程师管理 agent 工作的界面。

Zach Lloyd 在访谈中说得很清楚，他认为关键变化不是“factory”这个词会不会流行，而是从 interactive development 转向 automated development。也就是说，工程师不再只是一轮一轮地和 agent 对话，而是要把有价值的开发循环自动化。

这个判断很关键。

很多人第一次使用 AI 编程工具时，会把它当作一个更聪明的同事：我问，它答；我说需求，它写代码；我指出错误，它修复。这种交互模式很自然，也很适合探索。但大型项目真正消耗时间的地方，往往不是某一次对话，而是大量重复、分散、需要上下文切换的循环。

例如：

• 新 issue 进来后，需要判断它是 bug、需求、文档问题还是重复反馈。
• 需求进入开发前，需要生成可执行的规格说明和验收条件。
• 代码改动后，需要跑测试、看失败原因、补覆盖、重新提交。
• PR 进入审查，需要找出风险点、解释变更、确认影响范围。
• 发布之后，需要观察监控、收集反馈、把问题回流到下一轮任务。

如果 agent 只能在这些环节里偶尔帮忙，那它仍然是助手。如果 agent 能持续推动这些环节，并且把结果交给人类在关键节点判断，那它就开始像工厂。

Warp 的 Oz 想做的就是这个方向。访谈中提到，Oz 会让用户选择仓库、选择要自动化的软件生命周期环节，以及决定哪些地方要把人带回流程里。系统可能从 Jira、Linear、Slack、Teams、GitHub 等已有工具中接收任务，再让 agent 在本地环境或隔离的云沙箱里执行，并与团队原有流程衔接。

这点也很重要：软件工厂不一定意味着一个全新的界面。对大多数团队来说，真正可落地的工厂，很可能是嵌入现有工具的。开发者仍然看 GitHub，产品经理仍然看 Linear，团队仍然在 Slack 或 Teams 沟通，CI/CD 仍然跑在已有平台上。变化在于，原来需要人反复搬运、解释、跟进、验证的部分，被一个自动化循环接管了更多。

这也是为什么 Lloyd 会把 factory engineering 说成一种新的工程学科。它不是让工程师失去创造性，而是把创造性从“逐行写实现”转移到“设计生产系统”。工程师需要问的问题变了：为什么 agent 在这个任务上表现好，在另一个任务上表现差？它缺少什么上下文？反馈应该怎么设计？哪些任务可以自动合并，哪些必须人审？如何让系统输出可解释、可追踪、可回滚？

这已经不是单纯的代码能力，而是系统工程能力。

“软件工厂”不是新瓶装旧酒

软件行业一直喜欢借用工业隐喻。流水线、工厂、管道、平台、生产环境、供应链，这些词早就存在。所以有人可能会说，AI 软件工厂是不是又一个新词？是不是把 CI/CD、DevOps、低代码、自动化测试换个说法？

这个怀疑有道理，但这一次确实有一些新东西。

CI/CD 自动化的是构建、测试、发布。DevOps 自动化的是开发和运维之间的协作与交付流程。低代码试图降低应用搭建门槛。传统自动化脚本擅长做确定性任务：给定输入，执行固定步骤，输出可预期结果。

AI 软件工厂的不同之处在于，它开始自动化过去很难自动化的“半结构化工程判断”。

比如，读一个 issue 并判断可能涉及哪些模块；根据模糊需求生成初版规格；在一个大型代码库里找到相关实现；写出修改方案；根据测试失败信息继续迭代；总结 PR 的风险点；在监控异常后尝试定位可疑变更。这些任务不是完全创造性的，也不是完全机械的。它们介于二者之间，过去依赖工程师经验和上下文，现在被大模型和工具调用能力推到了可自动化的边缘。

这就是新变化。

软件工厂并不是把所有研发工作变成机械劳动，而是把大量“需要理解，但不一定需要最高创造力”的环节放进自动化系统。人类仍然处理模糊目标、架构方向、复杂权衡、责任归属和高风险决策。agent 则承担更多探索、生成、检查、修补、搬运和反馈工作。

这里也有一个容易被忽略的点：AI 软件工厂不只是模型能力问题，更是组织设计问题。

模型越强，组织越需要回答这些问题：

• 谁有权让 agent 修改哪些仓库？
• 哪些变更可以自动合并？
• 什么样的测试结果才算验收通过？
• agent 读取外部输入时，如何防止不可信内容影响关键操作？
• 自动生成的代码出了事故，责任在谁？
• 如何度量 agent 的真实 ROI，而不是只看生成了多少行代码？
• 如何避免自动化把技术债扩散得更快？

如果这些问题没有答案，软件工厂就会变成一堆失控的自动化脚本。它看起来很忙，产出很多，但组织不一定更快，也不一定更安全。

因此，“工厂”这个比喻真正有价值的地方，不是让我们想象一群 agent 在屏幕里疯狂写代码，而是提醒我们：当生产变得自动化，管理生产系统本身就变成核心能力。

工程师的角色会怎么变

每当有人谈自动化，工程师最自然的反应就是：那我还做什么？

这个问题不能用一句“AI 不会替代你，会用 AI 的人替代你”糊弄过去。它太轻巧，也太像口号。更实际的答案是：工程师的工作会被重新分层。

第一层，是仍然需要人直接写的代码。

在可预见的阶段里，复杂架构、关键性能路径、安全敏感逻辑、创新性产品设计、遗留系统中的高风险改造，仍然需要经验丰富的工程师深度参与。agent 可以给出方案，可以生成候选实现，可以帮忙补测试，但最终判断不能完全外包。

第二层，是可以由 agent 主要执行、人类审查的工作。

这可能包括常规 bug 修复、简单功能补全、测试补充、文档更新、依赖升级、类型修复、代码风格统一、部分迁移任务、重复性重构。这里的关键不是“agent 能不能写”，而是“团队能不能定义清楚验收标准，并让系统可靠地验证结果”。

第三层，是人类设计和管理自动化循环的工作。

这会越来越重要。工程师需要把模糊的团队习惯变成明确的流程：issue 如何进入队列，任务如何拆分，agent 如何选择上下文，失败如何重试，审查如何分级，测试如何触发，部署如何隔离，监控如何反馈。这些工作过去往往散落在团队经验里，现在需要被显式设计出来。

这就是 Warp 所说的 meta-engineering，也是 Cursor FDE 模式背后的能力要求。

未来优秀工程师不只会问“这段代码怎么写”，还会问“这类代码以后是否应该由系统自动生成”。不只会问“这个 bug 怎么修”，还会问“为什么这个 bug 没有被自动发现、自动定位、自动回归”。不只会问“这个 PR 能不能合”，还会问“哪些信号足够支持它自动进入下一阶段，哪些信号必须升级给人”。

这会让一部分工程师不适应。尤其是那些享受手写每一行代码的人，会觉得“工厂”这个词削弱了工程的手艺感。这个担忧不荒唐。写代码确实有创造性，也有审美和掌控感。把一部分工作交给 agent，会改变工程师与代码之间的关系。

但从另一个角度看，软件工程过去几十年一直在抽象。高级语言替代汇编，框架替代重复样板，云服务替代自建基础设施，CI/CD 替代手工发布，基础设施即代码替代人工点控制台。每一次抽象都会拿走一些手工控制，也会创造新的复杂度和新的专业能力。

AI 软件工厂可能是同一条路上的下一步。

它不会让工程判断消失，只会把判断的位置往上推。

企业落地不要从“全自动研发部”开始

如果一个团队听完软件工厂的概念，第一反应是“我们能不能下个月让 agent 自动完成 80% 的开发”，那大概率会踩坑。

更稳妥的落地方式，是从低风险、重复、高频、验收标准明确的环节开始。

比如，先让 agent 处理文档和测试补充。它可以根据代码变更更新 README，可以补充明显缺失的单元测试，可以为内部 API 生成使用示例。这类任务的风险相对可控，结果也容易审查。

再比如，选择一类结构稳定的 issue。不是所有用户反馈都适合自动化，但某些类型的问题可能很适合：UI 文案修正、配置项补充、错误信息优化、简单兼容性修复、已知模式的 bug。团队可以先让 agent 生成 PR，再由人审查，观察它的成功率、返工率、测试失败率和审查耗时。

再进一步，团队可以把自动化放进完整循环：issue 进入后自动分类，生成规格草案，关联可能的代码区域，提出实现计划，等待人确认后执行，跑测试，生成 PR 说明，标记风险点，最后交给人审。这里的目标不是完全无人化，而是减少人类在低价值上下文切换上的消耗。

这和 Warp 访谈里的建议很接近。Lloyd 提到，公司会从特定用例、特定 issue 类型或低风险仓库开始，而不是一夜之间替代所有工作。工程挑战会变成：如果现在 20% 的 PR 可以自动进入合并路径，能否提高到 30%、40%、50%？剩下那些困难、模糊、需要从零思考的工作，仍然由人来做。

这个渐进路线比宏大的“AI 研发革命”更可信。

因为真正的企业软件开发不是 demo。它有历史包袱，有隐性规则，有合规要求，有事故教训，有跨团队协作成本。软件工厂必须在这些约束里慢慢扩大自动化边界，而不是靠一句“模型已经很强了”越过所有风险。

企业要建设 AI 软件工厂，至少需要四类基础设施。

第一是上下文基础设施。agent 需要知道代码库、架构文档、接口规范、历史决策、测试策略和业务背景。但上下文不是越多越好。外部 issue、客户反馈、代码注释、网页内容都可能包含不可信信息。团队需要区分可信上下文和不可信输入，并限制 agent 在不同上下文下能执行的操作。

第二是权限基础设施。不同 agent、不同任务、不同仓库应该有不同权限。能读代码不等于能改代码，能开 PR 不等于能合并，能跑测试不等于能部署。权限设计越粗糙，自动化规模越大时风险越高。

第三是验证基础设施。没有测试、静态检查、类型检查、安全扫描、回归环境和可观测性，agent 的产出就只能靠人肉审查。那样软件工厂很快会卡在审查瓶颈上。自动化研发必须和自动化验证一起建设。

第四是度量基础设施。团队不能只看“agent 写了多少代码”。更重要的指标包括任务完成率、一次通过率、测试失败率、返工率、审查耗时、线上问题率、开发周期缩短情况、工程师满意度，以及自动化是否让技术债变多还是变少。

这些基础设施听起来不如“让 AI 写代码”刺激，但它们决定了软件工厂能不能从演示走向生产。

风险：自动化越强，边界越重要

AI 软件工厂最大的诱惑，是让人误以为速度可以单独存在。

它当然能提高速度。一个长期运行的 agent 可以不睡觉，可以同时处理多个任务，可以自动重试，可以在云端持续工作。Cursor 访谈中也提到，云端 agent 的吸引力之一，就是任务不必依赖开发者一直开着电脑。Warp 的愿景更进一步，让多个 agent 在一个持续循环里推动软件项目。

但软件工程从来不是只比速度。

速度如果没有边界，可能只是更快地产生混乱。agent 可以更快地生成代码，也可以更快地制造重复实现、更快地引入不一致、更快地绕过团队约定、更快地把一个误解扩散到多个模块。

这里有几类风险特别值得提前处理。

第一是质量责任风险。agent 生成的代码不等于可靠代码。即使它通过了部分测试，也可能隐藏边界条件、并发问题、安全问题、性能问题或产品语义错误。团队需要明确：哪些变更必须人审，哪些审查可以自动化，出了问题如何追责和复盘。

第二是上下文污染风险。软件工厂会接触很多外部输入，比如 issue、工单、客户反馈、聊天消息、文档和网页。外部内容可能是错误的，也可能带有诱导 agent 执行不当操作的指令。仅靠提示词分隔符不能保证安全，系统需要在工具权限、上下文来源、操作确认和审计日志上做防护。

第三是自动化技术债风险。agent 很擅长在局部完成任务，但未必天然理解长期架构一致性。如果团队只奖励“任务完成”，不检查设计质量，软件工厂可能把短期补丁生产得非常快，最后让代码库更难维护。

第四是组织错配风险。软件工厂不是买一个平台就能完成。它会改变产品、工程、测试、运维、安全之间的协作方式。如果组织仍然把需求写得含糊，把测试当作上线前的形式，把审查当作找语法问题，那么 agent 只会把这些旧问题自动化。

第五是工程师信任风险。开发者如果看不懂 agent 做了什么，不知道它为什么这么改，也无法方便地回滚和介入，就很难信任这个系统。软件工厂必须让过程可观察、结果可解释、失败可恢复。否则它会从效率工具变成心理负担。

这些风险并不说明软件工厂不值得做。恰恰相反，它们说明软件工厂是一项工程系统建设，而不是一个口号。

为什么 Cursor 和 Warp 会同时走到这里

Cursor 和 Warp 的出发点不同，但它们现在同时谈软件工厂，并不偶然。

一方面，大模型的代码能力、工具调用能力和长任务执行能力正在逼近一个临界点。只做个人补全会越来越拥挤，也越来越难形成足够大的差异。工具公司自然会往更高价值的位置走：团队流程、企业部署、自动化治理、组织级 ROI。

另一方面，企业客户也开始从“员工能不能用 AI”转向“公司如何系统性获得 AI 红利”。早期采用者已经证明个人效率可以提升，但组织真正关心的是整体吞吐量、交付质量、风险控制和成本结构。一个人每天多写几百行代码不是终点，整个研发系统能否更快、更稳、更可度量才是问题。

Cursor 的 FDE 模式是在回答“怎么把 AI agent 放进复杂企业现场”。Warp 的 Oz 和 software factory 叙事是在回答“怎么把 agent 组成可管理的研发系统”。这两个问题合在一起，就是 AI 编程下一阶段的核心问题。

这也意味着竞争格局会变化。

过去，AI 编程工具比的是补全质量、聊天体验、上下文窗口、模型选择、编辑器集成。接下来，还会比流程集成、权限治理、任务编排、评估体系、审查体验、云端执行、安全隔离和企业改造能力。

谁能让 agent 不只是“写得出代码”，而是“能在真实组织里稳定交付软件”，谁就更接近软件工厂的入口。

对普通团队的现实建议

如果你是一个普通工程团队，暂时不需要立刻引入完整的软件工厂平台，也不需要马上设置一个“AI 工厂负责人”。更现实的做法，是从三个问题开始。

第一，你们团队最烦、最重复、最容易验收的研发环节是什么？

可能是补测试，可能是处理低级 bug，可能是更新文档，可能是整理 issue，可能是迁移旧 API，可能是给 PR 写说明。不要从最复杂、最有争议、最依赖产品判断的任务开始。先找一个团队愿意交给自动化尝试的环节。

第二，这个环节的验收标准能不能写清楚？

如果一个任务连人类都说不清做完的标准，agent 也很难稳定完成。软件工厂真正需要的不是更长的提示词，而是更清楚的输入、边界、测试和反馈。比如，“修复这个 bug”太模糊，“在不改变公开 API 的前提下修复登录页空状态崩溃，并补一个覆盖空用户信息的测试”就更适合自动化。

第三，失败以后系统如何反馈？

agent 第一次做错并不可怕，可怕的是错了以后没有记录、没有分类、没有改进路径。团队应该观察 agent 经常在哪些任务失败，是缺少上下文、测试不足、权限不够、需求模糊，还是代码库结构本身太混乱。软件工厂的建设过程，本质上也是团队重新认识自己研发系统的过程。

如果一个团队能围绕这三个问题持续迭代，它已经在走向软件工厂了。

不一定需要一开始就叫 factory，也不一定需要把所有流程都自动化。更重要的是建立一种意识：不要只把 AI 当作临时帮手，而要思考哪些工作可以被设计成稳定循环。

结语：未来不是没人写代码，而是软件生产方式变了

Cursor 和 Warp 同时谈“AI 软件工厂”，真正值得关注的不是这个词有多新，而是它背后的重心转移。

AI 编程的第一阶段，是让单个开发者更快。第二阶段，是让 agent 承担更完整的任务。正在到来的第三阶段，是把 agent、工具、流程、权限、验证和反馈组织成软件生产系统。

这不会在一夜之间发生，也不会让工程师第二天醒来发现自己已经被工厂替代。更可能的过程是，团队先自动化一些烦人的环节，再自动化一些低风险 issue，再把 agent 接入 PR、测试、发布和监控，最后形成一套持续推动项目向前的研发循环。

到那时，工程师的价值不会消失，但会被重新定义。

过去，工程师的核心产出常常被理解为代码。未来，代码仍然重要，但更重要的可能是：你能不能定义一个好问题，设计一个可靠流程，给 agent 足够但不过量的上下文，建立有效的验证机制，在关键节点做出判断，并对系统最终交付的结果负责。

这就是软件工厂最值得讨论的地方。它不是把软件开发变成冰冷的机械劳动，而是把软件生产中大量可重复、可验证、可循环的部分交给系统，把人的注意力推向更高层次的设计、判断和责任。

所以，Cursor 的 FDE 和 Warp 的 Oz 看似是两条路线，其实都在回答同一个问题：当 AI 不再只是代码助手，而开始进入完整的软件生命周期，我们应该怎样重新设计软件开发？

这个问题的答案，可能会决定下一代开发工具的形态，也会决定下一代工程团队的工作方式。

参考来源

• How Cursor deploys AI inside the enterprise，Latent.Space，2026-07-01。
• Warp CEO Zach Lloyd on why software factories are the next phase of coding，Latent.Space，2026-07-01。