平台鸿沟：如何在不增加人员的情况下扩展您的工程团队（暂时）
简而言之：“谁构建，谁负责”（You build it, you run it）的口号诞生于一个更简单的时代。如今，它正因过重的认知负荷压垮小团队。Continue 的 Mission Control 充当了虚拟平台团队的角色，自动化处理了“负责”（运营）这一端的工作，使全栈开发者能够跨越“平台差距”，以便在当下验证产品，从而在未来有能力聘请专门的基础设施人员。
2006 年，亚马逊首席技术官 Werner Vogels 在一次采访中定义了一代工程文化。他曾名言道：“谁构建，谁负责。”
这成为了 DevOps 运动的集结号，承诺拆除开发与运维之间的隔阂。很长一段时间里，我们将其奉为圭臬。
但正如 Humanitec 在其精彩的分析中所指出的那样，“‘谁构建，谁负责’带有一张警告标签”。当 Vogels 说这句话时，亚马逊的规模仅是如今的一小部分。那时没有微服务，云服务尚处于起步阶段。“负责”所要求的认知负荷还在可控范围内。
快进到今天，“负责”意味着要管理 Kubernetes 清单、IAM 角色、安全合规性、数据库迁移以及可观测性管道。
如果你是一个没有专门平台工程团队的全栈团队，你可能正淹没其中，而不仅仅是在“运行”它。你正生活在“平台差距”之中。
平台差距是指中小型工程团队中出现的一种运营真空。在这里，维护工具（Sentry、Snyk、CI/CD）的复杂性超过了团队的能力，而组织又太小，无法聘请专门的平台工程师。
这是尴尬的增长阶段：你有真实的基础设施头痛问题，但没有足够的预算来聘请团队去解决它们。你既要构建功能，又要疲于救火。你既是建筑师，又是清洁工。
在 Continue，我们相信 Mission Control 是弥合这一差距的答案。它通过自动化处理“运行”工作，帮助小团队减轻维护税，从而让他们专注于“构建”。
1. 在招聘到位前自动进行分类处理（Sentry + GitHub）
现状：你还没有 SRE 轮班制。
差距：当生产环境崩溃时，你的首席开发人员必须停止编写代码去修复它。
桥梁：将 Sentry 连接到 Mission Control 以处理生产环境中的“噪音”。不要让每一个问题都去惊动人工，而是将我们的集成用作“第一响应者”代理（Agent）。
- 触发条件：Sentry 中出现新的异常。
- 动作：代理分析堆栈跟踪（stack trace）和代码库。
- 结果：它会打开一个包含修复建议的 PR，并将其链接到对应问题，或将其添加到你的机会面板中。
这并不能取代深入的架构调试。它只是清除了低垂的果实，让你的团队不再陷入琐事的消耗中。
2. 在不产生瓶颈的前提下自动化合规性检查（Snyk + GitHub）
现状：你没有 DevSecOps 负责人。
差距：由于没有人有时间优先处理依赖项升级，安全补丁不断堆积。
桥梁：使用 Snyk 集成来自动化你的安全基线。
- 触发条件：Snyk 检测到 npm 包中的漏洞。
- 动作：“安全代理”运行升级并验证构建。
- 结果：一个包含修复方案和背景信息的 PR 出现。
这确保了你在试图达成合作或筹集下一轮融资时，不会被安全审计所阻碍。它让你在专注于增长的同时保持合规。
3. 自动保持数据卫生（Supabase 和 PostHog）
现状：你没有数据工程师。
差距：分析跟踪中断，RLS 策略变得过时，造成了未来会造成损害的技术债务。
桥梁：使用 Mission Control 工作流来自动保持环境整洁。
为什么小团队会面临“平台差距”？
小团队面临“平台差距”是因为现代开发工具栈产生的维护信号（警报、升级、漏洞）远超以产品为中心的团队人工处理的极限。Continue 的 AI 通过云端代理自动化处理维护的“杂活”，充当虚拟平台工程师，从而弥合了这一差距。
结论：让“谁构建，谁负责”再次成为可能
Werner Vogels 并没有错，但他面对的是一个不同的世界。在 2025 年，“谁构建，谁负责”只有在拥有处理繁重工作的平台时才是可持续的。
对于企业巨头来说，那个平台是由 50 名工程师组成的、构建内部开发者门户的团队。
对于精简的全栈团队来说，那个平台就是 Mission Control。
通过使用代理来标准化工作流并自动化维护，你弥合了“平台差距”。你获得了 Vogels 所承诺的自主权，而无需承担他未曾预见到的倦怠。
弥合差距。
在 Mission Control 中连接你的工具，立即开始自动化你的维护工作。