Factory AI 值得用吗？Droids 功能、价格与团队选型指南

Factory AI 是什么？

Factory 是一个软件开发平台，其智能体名为 Droids。它们可以查看代码仓库、提出计划、修改文件、运行检查，并准备拉取请求，也就是供团队审查、随后合并进代码库的一组变更。你可以通过终端、集成开发环境（IDE），以及 Factory 的桌面端和网页端使用它。“智能体原生开发”的意思是：把预期结果交给智能体，再审查它完成的工作，无需逐项指定每一次编辑。这个产品连接模型与开发工具，既不是新的编程语言，也不是需要自行训练的模型。Factory 产品页介绍了这一定位。

本文依据 Factory 的在线价格页和文档，于 2026 年 10 月 21 日核验。这是一篇基于文档的评估，包含工作流示例和费用计算；文中不声称进行过编程基准测试或上手实测。

谁适合用 Factory，谁应该继续用现有智能体？

如果工程负责人希望使用不同编辑器的开发者都能按同一套流程委派任务，或希望切换模型供应商时无需重建所有工作流，Factory 就值得考虑。对于现有智能体已经能处理仓库、测试和审查流程，且很少需要干预的创业者，它的吸引力就没有那么大。

值得一起比较的产品包括：Anthropic 的开发智能体 Claude Code、OpenAI 的编程智能体 Codex，以及编辑器与智能体平台 Cursor。比较的重点是：买下这个产品，究竟会怎样改变团队的工作方式。

这些是选购判断，不是基准测试排名。Claude Code、Codex 和 Cursor 都早已不局限于一个聊天框或终端。仅凭入口多，Factory 并不能胜出。

Factory AI 与 Claude Code，怎么选？

如果你希望在更广泛的工作流中，把 Claude 模型作为可选项之一，Factory 值得考虑。如果组织已经围绕 Claude Code 建立了有效的指令、集成和审查实践，继续使用它会更简单。在 Droid 中运行 Claude 模型，并不等于复现 Claude Code：配套工具、上下文选择和执行行为，取决于智能体产品本身。

例如，后端开发者用 JetBrains，前端开发者用 Cursor，负责人想引入 Factory 来处理一个共用的维护任务队列。这是合理的引入理由。仅仅因为另一个模型的演示很惊艳，就让所有人换工具，则不是。

如果主要问题是需求含糊、测试不可靠，或拉取请求排着队却无人审查，暂时不必引入 Factory。这些问题同样会限制 Droids。先保留 Claude Code、Codex 或 Cursor，把工作变得更容易验证。Codex 与 Claude Code 对比聚焦这两者的选择；AI 编程智能体选型清单则覆盖更广的产品范围。

下文围绕四个标准展开：上下文质量、执行控制、不同入口之间的连续性，以及让一次变更通过验收的成本。

Factory AI Droid：沿用编辑器，把任务说清楚

Factory Droid 可以在现有编辑器中运行，因此无需迁移编辑器，就能开展小范围试用。在 VS Code、Cursor 和 Windsurf 中，集成会提供当前文件、选中文本、已打开的文件，以及诊断信息，也就是编辑器给出的错误和警告。它也支持原生差异视图。在集成终端中运行 droid，再用 /ide 查看连接状态。Factory 的 IDE 文档说明了配置方法。

设想一位后端负责人要调整应用验证账户权限的方式。有效的任务描述不应只有“重构鉴权”，而应明确要求：找出所有调用位置，保留现有用户的既有行为，提出迁移顺序，并指出哪些测试能发现意外的权限变更。

这样的描述给了智能体清晰的边界，也给了审查者明确的否决依据。代码改动再多，也不能单凭差异量证明迁移正确。

Factory AI 如何根据规格说明推进任务？

Factory 的 Spec Mode 将调查和规划与实际实现分开。它先读取相关上下文、提出计划，再请求批准；在 CLI 中，使用 Shift+Tab 可切换 Normal 和 Spec 模式。自主级别（Autonomy level） 是另一项独立设置，用来决定哪些操作无需再次确认即可执行。模式文档明确区分了这两者。

处理权限迁移时，先进入 Spec Mode，要求计划列明受影响的文件、兼容性假设和验证步骤。如果计划打算修改访问规则，却没有解释如何保留既有行为，就应驳回。只有这些决策明确之后，才批准实施。

可以按以下顺序推进：

1. 让 Droid 找出授权逻辑的入口和相关测试。
2. 要求它提出保留现有行为的计划，并标出尚不明确的需求。
3. 审查计划，再根据获准执行的工作选择合适的自主级别。
4. 在发起或接受拉取请求之前，检查代码差异和测试证据。

这样做的好处，是在智能体生成大量代码之前设置一道审查关口。局限在于：看似合理的计划，仍然可能出错。验收标准必须覆盖实际行为，不能只看有没有测试。

还有一个与编辑器有关的限制：Factory 文档说明，JetBrains 集成不会自动共享已打开的文件、选区、诊断信息或原生 Droid 差异视图。在多种编辑器混用的团队中推广时，必须考虑这一差异，不能假定所有人都能获得 VS Code 上的体验。

切换模型，不必重建整套工作流

Factory 允许选择不同系列的模型，同时保留 Droid 的操作入口和任务结构。对于希望统一任务委派方式、又不愿把所有工作流绑定到单一模型供应商的团队，这很有价值。

在线的 Factory 模型目录列出了以下模型，支持范围不限于此：

• Anthropic Claude Opus 5.5 和 Claude Sonnet 5.5。
• OpenAI GPT-6.1 Sol 和 GPT-6 Astra。
• Google Gemini 3.1 Pro 和 xAI Grok 4.7。
• 开放模型，包括 Mistral Large 4、Kimi K3 和 DeepSeek V4.1 Flash。

这只是受支持模型的部分示例，不是质量排名，也不代表每个账户的策略都允许使用全部模型。

以一批依赖更新任务为例。给每个候选模型相同的依赖变更、测试要求和完成标准，记录它是否完成更新、检查是否通过，以及需要审查者介入多少。更少需要监督的模型，可能值得更高的用量消耗；价格更低、却反复留下失败测试的模型，则未必划算。

比较时，任务和环境应保持一致。如果同时改动模型、仓库指令和自主设置，就无法解释结果来自哪里。Factory 目录中的模型有不同的用量倍率和推理设置，因此“提示词数量相同”并不是可靠的消耗比较方法。

自带密钥（BYOK） 指配置自己的模型供应商凭据，或兼容的服务端点。Factory 支持个人自定义模型，包括本地配置，但其 BYOK 文档明确了一项关键限制：这些个人模型只能用于 CLI 和桌面应用，无法用于托管的网页端或移动端。

这对选购的影响很具体。Factory 能降低在工作流内切换模型的成本，但仍要核对：目标模型能否在实际执行任务的入口使用。本地模型试用成功，并不能自动证明网页端的委派流程也走得通。

桌面端与网页端，让委派结果更容易审查

当你需要一边查看对话、一边检查可视化成果时，Factory 桌面应用会很有用。产品页列出的可预览内容包括代码差异、文档、演示文稿、电子表格、PDF 和实时网站，还能把评论附在代码行或选中的元素上。应用支持 macOS 和 Windows。Factory Desktop 也介绍了桌面端、网页端、移动端和 CLI 之间的会话延续能力。

对于要修改账户设置页的技术型创业者，流程很直观：描述预期行为，查看渲染结果，把反馈附到相关元素上，再在发布前审查代码变更。可视化反馈有助于准确表达“这条错误提示应该放在邮箱输入框旁边”这样的要求。但它不能证明服务器会拒绝无效更新，也不能证明用户无法访问其他人的设置。

委派工作时，这个区别很重要。批准界面的人，与检查应用行为的人，可能不是同一个。交付要求应同时包含可见的改动，以及底层行为正确的证据。一个看起来很像样的预览，不应成为唯一的完成标准。

Factory 还列出了 GitHub、Linear、Slack 和 Sentry 等工具的连接器。它们能提供获准访问的上下文，但接上任务管理工具，并不会自动让含糊的工单变清楚。任务仍然需要负责人、范围和明确的结果。

远程执行还带来另一层区别：审查工作的界面，不等于执行工作的那台计算机。Factory 托管的 Droid Computers 是持久化环境，能够跨会话保留文件、已安装的软件包、服务和配置。对于已经由你管理的机器，Factory 文档另有 Remote Control 选项。Droid Computers 文档介绍了这两种方式。

环境配置成本高时，持久化很有帮助，但这也意味着必须有人负责环境状态。Factory 明确表示，重新构建 Environment，不会更新此前从该环境快照创建的 Droid Computer。因此，平台负责人在认定一次成功运行能在其他地方复现之前，应先核对机器的实际状态。

搭建 AI 软件工厂，从一项可重复的任务开始

当 Droid 能处理一个定义清楚的任务队列，而不再需要开发者手动开启每次对话时，Factory 的价值就更值得关注。Droid Exec 是它的无界面模式：通过非交互命令执行任务，并向脚本或持续集成（CI）系统返回输出。它默认只读；修改文件和执行更广泛的命令，需要显式设置自主级别。Exec 文档涵盖了输出格式、工作目录和隔离的 Git worktree。

适合作为起点的工作流，是分析仓库并产出维护者可以核查的证据。安装 Droid 并完成身份验证后，在仓库中运行：

droid exec --output-format json \
  "Identify exported functions without direct test coverage. Return file paths, the evidence for each gap, and suggested test cases. Do not edit files."

这是调用示例，并非本次评估中实际执行的命令。它本身也不能证明测试覆盖情况：动态调用、集成测试和生成代码，都可能让简单判断出错。它的输出应被视为供维护者筛选的候选任务清单。

下一步，是让 Droid 在独立分支或 worktree 中，实施已获批准、范围明确的测试变更，再运行仓库的检查。验收依据应独立于智能体自己的文字说明。是否完成，应由 CI 结果和审查者的决定来判定。

自动化中有一道容易忽略的障碍：即使自主级别设为 High，生效的命令策略 ask 仍然要求批准，而一次性任务无法取得交互式批准。因此，提高自主级别未必能让被阻塞的自动化任务运行起来。Factory 文档提供了 droid rules check，用于在执行前预览策略判定。这是需要有意识地解决的配置问题，不是关闭所有权限检查的理由。

对于更大规模的工作，Mission Mode 会协调工作智能体和验证流程。它要求 High 自主级别，或使用文档所述的不安全覆盖选项；个人套餐的 Missions 可能因触及速率限制而暂停。在承诺大型迁移可以无人值守地完成之前，应先从常规、范围明确的任务做起。

收益在于可重复：每次采用相同的任务接入流程、权限边界和验收证据。难点在于运维责任。必须有人维护依赖、凭据、任务范围和失败处理机制。如果这一运行管理层比单次编程会话更重要，下一步可以看 AI 软件工厂平台对比。

Factory AI 价格：按工作流需要选套餐

如果小团队只需要集中结算，Factory Teams 是直接的选择。如果需要按合同共享用量、身份管理或管理策略，则应与 Factory 洽谈 Business。不要假定从个人套餐升级到 Teams，就能获得这些控制能力。

以下为 Factory 在线价格页列出的月度方案，核验日期为 2026 年 10 月 21 日：

价格页没有公布 token 配额，用量仅以 Pro 的倍数表示。 这些倍数不是承诺可完成的任务数量，也无法可靠地换算成通过验收的拉取请求数量。组织套餐文档进一步说明：Teams 每个席位采用 Pro 的速率限制；Business 和 Enterprise 则按合同条款共享用量。

Teams 五个席位的费用是每月 $260，即 $60 + 5 × $40。十个席位为 $460。假设一个五人团队每月接受 20 个 Droid 拉取请求，那么每个通过验收的拉取请求，分摊的订阅费为 $13。这只是算术，不是产能预测；比较总成本时，还必须加入额外用量、计算资源和审查时间。

工作流需要的能力，往往超出了所选套餐。Pro 不提供 Business 所列的企业管理控制；Teams 也没有承诺每个席位都享有 Plus 用量。此外，个人套餐文档把托管的 Droid Computers 列在 Pro 下，而商业价格页将其列为 Plus 新增权益。编制预算时应以价格页为依据，在依赖托管计算资源之前，确认实际可用权益。

哪些限制可能让推广卡住？

Factory 最值得关注的限制，是不同入口和套餐之间的能力不一致。即使单次编程会话表现不错，这些问题仍可能阻碍推广。

支持某款编辑器，不等于功能完全一致。 JetBrains 缺少 VS Code 系列编辑器所具备的自动文件、选区和诊断信息共享能力。Zed 的 Agent Panel 无法恢复先前的 Factory Droid 会话。即使团队统一使用 Droids，也仍需针对不同编辑器安排上手流程，并制定上下文恢复方案。Factory 文档列明了这些差异。

个人 BYOK 配置不能带到托管网页端或移动端。 本地配置的模型，可能是你控制成本或决定数据处理方式的关键，但并非每个 Factory 入口都能使用这套配置。在因本地演示效果而决定购买之前，先验证预期的远程执行流程。这一限制在文档中写得很明确。

用量倍数，不等于可依赖的交付能力。 个人套餐文档列明了彼此独立的 5 小时、7 天和 30 天滚动窗口。订阅更高档的套餐，并不会让这些窗口变成公开的 token 配额，更不构成完成任务的保证。如果客户交付期限依赖无人值守执行，应讨论合同约定的容量，而不是从短期试用推算。Factory 的个人用量规则也说明，Missions 会在触及速率限制时暂停。

托管计算资源的权益需要确认。 对于希望任务离开笔记本电脑也能运行的创业者，Pro 与 Plus 之间的文档差异会直接影响决策。本文套餐表以在线价格页为依据；相互冲突的文档不能作为免费升级的凭据。同时，应把计算资源条款与模型用量分开核对，不要把“云端智能体”理解为包含完整的基础设施额度。

权限规则不等于操作系统级隔离。 Factory 自己的自主执行文档也强调了这一点。某条命令获准执行，并不能证明它无害；用自然语言要求避开生产环境，也不构成网络隔离边界。试用时，应配置与任务相适应的访问权限和环境；若要在组织层面强制执行规则，则应评估单独报价套餐中的控制能力。

这些限制意味着，采用 Factory 时应从明确的小范围开始。先把它放进环境、模型、权限和审查者都已确定的工作流。若在这些选择尚未明确前，就推广到所有仓库，新增的协调工作可能抵消任务委派带来的收益。

Factory AI 评测结论：用验收结果决定去留

只有当 Factory 能减少把明确任务转化为已验收变更所需的人力，它才值得进入工作流。模型选择、多种入口和远程执行，都应服务于这一结果。

如果团队目前缺少合适的方式来处理共用维护队列、跨编辑器协作，或有计划地比较模型，可以先让它与现有智能体并行使用。只有在可比任务中，它能在不降低验收要求的前提下减少审查投入或降低总成本，才替换该类任务中的原有工具。如果 Claude Code、Codex 或 Cursor 已经把同样的工作流处理得很好，就不必再引入它。

下周一就能启动的行动，是由一位对结果负责的负责人组织一次小规模评估：

Factory 是值得纳入这类评估的候选产品。它的文档支持这样一个判断：这是一个覆盖面广、可配置的智能体系统。但文档并不能证明，只要把工程师熟悉的智能体换成 Droid，交付质量就会提高。

常见问题

通过邮件订阅获取 AI 业务工作流审计清单，在扩大智能体使用范围之前，梳理任务、权限、审查负责人和运行成本。