独立工作流线性扩展。组合工作流产生复利。

在上一篇文章中，我探讨了 Linear 的自动驾驶 SaaS 愿景，以及为什么它需要开发者构建的工作流。但当你开始构建时，会发生这样的情况：一个工作流的输出可以触发下一个。这就是“持续 AI (Continuous AI)”不再仅仅是“更快的开发”，而演变为“一种构建软件的新方式”的时刻。

单个工作流可以节省时间。而组合的工作流系统则能改变一切可能。

考虑一个简单的工作流：Sentry 错误触发智能体进行调查并提交 PR。这很有价值。你已经实现了事故响应的自动化。

现在将其组合起来：Sentry 错误 → 调查 → GitHub Issue → PR → 代码审查 → 合并 → 更新更新日志 → Slack 总结 → 关闭 Linear Issue。

每一个箭头都是一个自治的工作流。前一个的输出成为后一个的输入。你节省的不再是 30 分钟，而是实现了从检测到解决再到沟通的整个生命周期的自动化。

单个工作流带来线性的改进。组合工作流则产生复利。

通过一个工作流，你可以自动化一个任务。通过两个工作流，你可以自动化两个任务。但如果这些工作流能够相互连接，你甚至可以自动化它们之间的衔接部分。

示例：你有一个工作流用于监控 PostHog 的功能采用模式。你还有另一个工作流用于更新文档。单独来看，它们都很有用。

组合后：PostHog 显示功能普及率达到 80% → 工作流起草文档更新 → 工作流创建 PR → 工作流更新营销网站 → 工作流起草发布说明 → 工作流发布到更新日志 → 工作流在 Slack 中进行总结。

你不仅是在自动化任务，你是在自动化任务之间的协同。

并非所有工作流都能很好地组合。能够组合的工作流具有以下共同特征：

清晰的输出。 工作流产生具体的结果：GitHub Issue、PR、Linear 评论、Slack 消息。不是“我调查了这件事”，而是“这是我调查后的 GitHub Issue”。

可靠的触发器。 下一个工作流可以依赖上一个工作流的输出。如果一个工作流产出 PR，你可以可靠地触发评审工作流。如果它有时产出 PR，有时只产出评论，组合就会失效。

低人工干预率。 如果一个工作流 40% 的时间需要人工干预，你就无法将其与其他工作流组合。链条会断裂。你需要低于 5% 的人工干预率才能实现可靠的组合。

标准格式。 输出 GitHub Issue、PR、Linear 评论的工作流运行良好，因为其他工作流知道如何处理这些格式。自定义输出需要自定义的消费者。

在 Continue 运行组合工作流的团队

客户支持 → 产品开发： Slack 问题 → 文档搜索 → 起草答案 → 如果答案不存在则创建 Linear Issue → 智能体执行 → PR → 审查 → 合并 → 文档更新 → 将答案发布到原始 Slack 线程。

事故响应 → 知识库： Sentry 错误 → 调查 → GitHub Issue → 修复 PR → 合并 → 提取根本原因 → 更新运行手册 → 将总结发布到团队 Slack。

功能发布 → 沟通： PostHog 功能开关达到 100% → 更新功能文档 → 更新营销文案 → 起草公告 → 发布到更新日志 → 安排社交媒体发布 → 创建客户邮件草稿。

这些不是理论。团队今天就在运行这些工作流。

不要从这里开始。组合是第四阶段，而不是第一阶段。

首先，构建能可靠运行的独立工作流。将人工干预率降至 5% 以下。运行几周，直到你信任它们为止。

然后开始连接它们。挑选两个工作流，其中一个的输出自然地成为另一个的输入。将它们连接起来。观察组合系统的运行情况。衡量端到端的人工干预率。

如果成功了，再增加第三个工作流。然后是第四个。

拥有最复杂“持续 AI”系统的团队并非在一个月内就构建完成。他们构建了一个工作流，使其可靠，添加了另一个，将它们组合起来，然后不断扩展。

这就是为什么组合对竞争优势至关重要：它很难被复制。

竞争对手可以看到你快速交付功能，并猜到你在使用 AI 智能体。他们可以复制单个工作流。

但组合工作流反映了你特定团队的工作方式。你关心的触发器。你使用的工具。对你们文化至关重要的沟通模式。符合你们流程的步骤顺序。

这是随着时间推移不断积累的基础设施。每一个新的工作流都会放大之前的工作流。每一次组合都会创造出新的能力。

这就是为什么现在就开始构建“持续 AI”工作流的团队将很难被超越。不是因为某一个单一的工作流，而是因为他们组合起来的整个工作流系统。

但你究竟该如何实现这一目标？团队如何从手动编码转向运行组合的自主工作流？这就是我接下来要讨论的内容。

个人工作流线性扩展。组合工作流复合增长。