自动驾驶式 SaaS 需要开放的道路 | Continue 博客

Linear 上周发布了他们关于自动驾驶式 SaaS (Self-Driving SaaS) 的愿景。这是我在上一篇文章中提到的一个具体案例：软件不再仅仅是辅助你，而是代表你自主工作。

他们的愿景是：软件不仅能帮你工作，还能代表你自主工作。从支持工单中自动提取客户需求；分析问题并分配给合适的团队；将简单的变更派发给编程智能体（Coding Agents）；让文档保持自动更新。

这并非空谈，它正在发生。Linear 所描述的实际上是应用于产品开发的“持续智能 (Continuous AI)”。

Linear 的案例可以清晰地映射到持续智能工作流中。每一个工作流都有一个触发器、一个执行工作的智能体，以及一个最终结果。

支持工单 → Linear 问题单

新问题单 → 团队分配

简单问题单 → 合并 PR

需求 → 更新文档

这不仅仅是一个 AI 功能，而是一个由多个自主工作流组成的系统，每一个都建立在前一个的输出之上。

Linear 明确使用了自动驾驶汽车的隐喻来划分自主等级。这与团队实际采用持续智能的方式直接对应。

在低自主等级下，系统提供操作建议。例如 Linear 推荐将问题分配给哪个团队。你可以选择采纳建议，也可以不采纳。这就像自动补全——虽然有用，但仍需人工监管。

在中等自主等级下，系统先进行第一轮处理，你再对不合适的地方进行修正。Linear 在你定义的条件下自动应用建议，你进行审核和调整。这就像是在你编排的同时，并行运行多个智能体。

在全自主等级下，你完全不必插手。系统从头到尾自主驱动，你只需确认最终到达了正确的目的地。这是无需人工启动的事件驱动型工作流。

他们说得对，你不可能通过按下一个开关就直接实现这一目标。信任是靠反复实践建立起来的。能力和文化都需要共同进步。

Linear 的博客没有解决一个问题：他们无法构建每个团队所需的所有工作流。

你的公司有独特的工作流。你的支持系统可能是 Zendesk、Intercom 或定制系统；你的部署有特殊的步骤；你的代码评审标准是团队特定的；你的文档存放在 Notion、Confluence 或 GitHub 中；你对“简单变更”的定义也与众不同。

Linear 可以构建 20 个标准化的工作流，但你的团队可能需要 200 个定制化的。

如果只有 Linear 能为 Linear 创建工作流，那么你只能等待他们的路线图。他们会优先考虑那些能让大多数客户受益的功能。而那个能让你明天就解除瓶颈的独特工作流？肯定不在他们的清单上。

自动驾驶式 SaaS 的愿景是正确的，但只有在开发者能够构建自己的工作流时，它才能真正发挥作用。

你需要定义自己的触发器。不仅仅是“新的 Linear 问题单”，而是“Sentry 错误 > 100 次”或“PostHog 功能开关达到 80% 覆盖率”或“客户在 Slack 中提到了某个 Bug”。

你需要组合自己的链式反应。不仅仅是 Linear → GitHub，而是 Slack 问题 → Notion 搜索 → 起草回复 → Linear 问题单 → GitHub PR → Slack 摘要。

你需要连接自己的工具。不仅仅是官方支持的集成，而是通过 MCP 服务器连接任何系统。

你需要衡量自己的结果。不是看 Linear 固有的指标，而是看对你业务至关重要的干预率和成功率。

Linear 正在将自动驾驶功能内置到他们的产品中，这很有价值。但你的竞争优势在于那些他们永远不会构建的工作流中。

在 Continue，我们看到各个团队正在构建能够扩展 Linear 愿景的工作流：

这些工作流将 Linear 与你的整个技术栈连接起来。它们针对你的团队工作方式进行了定制，而且无需等待 Linear 的更新路线图。

Linear 的自动驾驶愿景是正确的。软件应该代表你自主工作。但这一愿景需要一个能够让开发者构建自己工作流的生态系统。

最终胜出的团队，是那些今天就开始构建自定义工作流的团队。他们不会等待供应商来交付，也不会租用别人强加的自动化方案，而是构建符合他们实际工作方式的工作流。

自动驾驶式 SaaS 不是买来的，而是造出来的。

一旦你开始构建，单个的工作流很快就会演变成更强大的系统。这也是我接下来要探讨的内容。

无人驾驶的梦想需要开放的道路