目前围绕 AI 充斥着大量噪音和炒作，其中许多讨论都集中在岗位替代，以及工程师可能失去什么。我想谈谈相反的方面：过去几个月里，我将 AI agents(AI 代理)融入平台团队的日常工作后，获得了什么。

我不会假装这是什么魔法：代理会犯错，而要给它们清晰的指令，仍然需要工程知识。我用代理完成的一些工作，确实让人感觉发生了真正的跃迁。我写代码的速度更快了，但更大的变化在于工作范围：我可以接手那些过去只能推迟的工作。

平台团队的问题

如果你读过我之前写的平台团队面临的挑战，就会了解这样的背景：一个小团队，却要负责很大的覆盖面。我们随时都在维护共享服务和库、横跨 28 个项目的 micro-frontend architecture(微前端架构)、CI 流水线，以及更多东西。

平台工作的现实令人沮丧：最棘手的问题并不总是技术问题。很多时候，它们是组织层面的问题。你可能发现有件事需要在 20 多个项目中修复，也清楚地知道修复方案是什么，但最终还是可能耗时数月。这是因为每个团队都有自己的优先事项，而这些事项不一定与平台团队的计划一致。平台团队面临的挑战，是弥合“这件事应该完成”和“团队有能力完成这件事”之间的差距。

代理开始以我意想不到的方式缩小这一差距。

研究任务：让跨项目决策变得可行

在平台团队中，最重要的决策往往也是最难有把握地做出的决策。在决定弃用一项服务、替换一个库，或在整个组织中强制执行一项新标准之前，你需要了解哪些人会受到影响，以及边界情况是什么样的。这类调查工作过去一直成本很高，常常导致团队跳过调查、在信息不完整的情况下做出决定，或者因为没有人有能力妥善完成调查而无限期推迟决定。

了解一项遗留服务

我们有一项已经运行多年的服务。它没有明确的负责人，文档也很少，而且一个问题不断被提出来：到底是谁在使用它，以及如何使用？我们认为应该退役这项服务，但在了解实际使用情况之前，无法明确决定迁移方案。要找到答案，就意味着手动追踪 GitLab 中的依赖关系，深入研究一个遗留 SVN 仓库，并从多年前由早已离职的人编写的代码中拼凑出整体情况。

借助代理，我可以把大部分发现工作交出去。它遍历了 GitLab 和 SVN 中的使用项目，识别调用位置，总结服务在不同场景下的使用方式，并标记出我需要注意的边界情况。原本可能需要几天的工作，变成了我可以在极短时间内审查并继续推进的内容。

这并不能取代人的判断，也不能取代与受影响团队的后续沟通，但确实让调查工作变得容易处理得多。

图标使用与 WCAG 合规

另一个例子是我们评估 WCAG AA 标准合规性的工作，其中一部分是评估各个应用中图标是否被一致且正确地使用。为了了解问题的范围以及解决方式，我们需要知道使用了哪些图标组件，它们在具体上下文中是否使用正确，以及实际存在哪些 WCAG AA 缺口。

如果逐个项目手动检查，会非常繁琐。于是，我使用代理根据我们的design system usage data(设计系统使用数据)，在具体上下文中评估每一处图标使用情况，并将结果填入电子表格。

我审查了结果，并在需要时进行修正，但我投入的时间大幅减少。更重要的是，我们可以根据实际数据决定下一步该做什么。

迁移与升级：真正完成工作，而不只是设计方案

一旦能够快速确定问题的范围，自然的下一个问题就是：能不能用同样的方式解决它？对我来说，代理在这里产生的影响最大，让我们不再只是分享迁移指南，而是真正交付变更。

在 28 个微前端中升级 React

如果你读过我关于微前端 React 升级的文章，就会知道这类工作需要多少协调。每个项目都由不同团队负责，而每个团队的优先事项也不同。让所有团队都执行迁移，即使迁移指南文档完善、步骤清晰，也是一项重大挑战。

最积极的团队完成迁移后，仍有相当数量的项目阻碍着最终发布。与其等待各团队执行迁移，我使用代理逐个处理项目：遵循迁移指南，完成必要的配置修改，解决该项目特有的问题，并创建 MR。对于每个项目，代理负责迁移中的机械性工作，团队收到的是可以直接合并的代码变更，而不是一个要求他们采取行动的请求。

之前

之后

每一个 MR 最终都被合并了。整个推广过程中遇到的唯一问题，来自一个在我的 MR 发出之前就已手动完成迁移的团队。代理生成的变更记录比人工驱动的变更更干净。

从“创建 MR”到“MR 合并”的转化率，明显高于从“发送迁移指南”到“工作完成”的转化率。团队仍然会审查、仍然会合并、仍然对代码负责，但在合并之前需要完成的工作少了。

CI 流水线重构

最近一次 GitLab CI 重构也有类似的经历。我们需要将共享流水线从已弃用的 only 关键字迁移到 rules 语法。变更本身并不复杂，但需要在每个使用该流水线的项目中完成，而每个项目都有自己的特殊情况，偶尔还需要处理会导致破坏性变更的问题。

通常，这类变更在各项目中的采用进度并不一致，团队会一直拖延，直到被迫采用为止。当不同项目的流水线表现不同时，这种不一致可能会造成困惑。

通过使用代理以编程方式识别所有受影响的项目，逐个完成迁移，处理遇到的破坏性变更，并提交 MR，我得以在远短于手动完成所需时间的情况下，将变更交付到所有项目。

实用技巧

回头看上面的例子，它们可能听起来很简单。实际上，在这些任务开始稳定可靠地运行之前，我们经历了不少试错。自定义 glab skill(技能)是最大的收获，下面的其他技巧也都来自那些实践。

为工具定义技能

我做过的影响最大的一件事，是为 glab CLI 编写自定义 agent skill(代理技能)。glab 是 GitLab 的命令行工具。技能是一个 Markdown 文件，为代理如何完成某件具体事情提供清晰且有明确取舍的指令：在这个例子中，包括如何跨项目搜索、如何创建 MR，以及如何通过 REST API 修改文件。

没有这些指令，代理要么会拒绝与 GitLab 交互，要么会生成不一致且脆弱的 bash 单行命令。有了定义良好的技能，它们就拥有了一套可靠的操作手册。Agent Skills 是一项开放标准，Cursor、Claude Code 和 GitHub Copilot 等工具都支持它。

通过 MCP 让代理访问内部上下文

开箱即用的代理对你的内部系统一无所知。它们可以阅读代码，但不知道组件应该做什么，也不知道共享库预期的 API 是什么样的。

我通过我们的design system MCP server(设计系统 MCP 服务器)解决了这个问题。MCP（Model Context Protocol）是一项开放标准，允许你以结构化、可查询的方式公开内部数据和文档，供代理使用。我们的服务器构建在 Storybook 之上，让代理能够访问组件属性、使用指南和示例。当代理审查图标的无障碍使用情况时，它可以查询设计系统中与图标相关的组件应如何使用。

由于 MCP 是开放标准，同一个服务器可以跨工具使用。不过，维护 MCP 服务器确实需要持续投入，并不是一次性投资。对我们来说，这项投入是值得的，但你也可以只把代理指向一些本地 Markdown 文件；如果内部文档存放在 Confluence 中，也可以使用类似 Atlassian MCP 这样的工具。

将审计数据作为起点输入

与其让代理从头发现哪些项目使用了某个库，不如直接把答案给它。我们有一套设计系统使用分析，能够准确告诉我们哪些项目使用了哪些组件，以及使用的是什么版本。在任务开始时将这些数据提供给代理，意味着它可以从我们的使用数据出发，而不是靠猜测，这样既更快也更准确。

我一直在试验一个项目，帮助扫描并解析整个组织中的依赖使用情况，为代理提供可以直接查询这些数据的 MCP 工具。

提前设定结构可以减少研究任务中的错误

在平台团队中，研究任务通常会为影响 20 多个项目的决策提供依据，因此准确性很重要。遗漏边界情况的模糊总结不仅没有帮助，还会导致错误决策。

对于研究任务，我发现值得在一开始就投入时间定义输出格式。与其让代理“研究我们各个项目中的图标使用情况”，不如给它一份电子表格模板，其中每个项目占一行，并指定需要填写的列。

这样会迫使代理采取系统的方法。它会逐个项目、逐列处理，并且每一行都有清晰的完成标准。当代理面对没有结构的开放式研究任务时，它们往往会在比你期望的更高抽象层次上进行总结，或者因为认为自己已经完成而过早停止。

仍然要编写迁移指南，并将其用作提示词

对于平台团队来说，无论如何都需要编写迁移指南，向使用方团队传达变更内容。我发现，将同一份指南提供给代理，本身也是一种有用的验证步骤。

如果代理感到困惑或走错方向，往往会暴露出指令中的缺口或歧义。指南没有涵盖的边界情况，会在代理于真实项目中遇到它们时显现出来。当你让代理在几个项目中运行过之后，也相当于对文档进行了压力测试，这会让指南对那些最终需要审查变更或手动执行步骤的团队更有帮助。

关于工具

我主要使用 Cursor 完成这类工作，也在 Claude Code 和 GitHub Copilot 中进行了一些尝试。说实话，工具之间的差异并没有你提供给它们的上下文质量那么重要。定义良好的技能和优秀的 MCP 服务器，比更换工具更能帮助你推进工作。

这里的开放标准（用于提供上下文的 MCP，以及用于定义代理行为的基于 Markdown 的技能文件）意味着，你在一个工具上的投入大多可以迁移到其他工具上。随着不同提供商和模型的价格不断变化，值得记住这一点，不要过度绑定到某一种工作流。

这带来了什么变化

代理会犯错。它们需要清晰的上下文和定义明确的任务。你仍然需要审查输出、理解它们做了什么，并运用自己的判断。有些任务它们处理起来仍然很困难，而为了得到想要的结果，我在规划阶段仍然需要进行几轮迭代。

“AI 会取代工程师”这种说法忽略了这里真正有意思的地方。我的体验更接近于：一个工程师能够承担的工作上限提高了。

过去，我可能发现一个影响 28 个项目的问题，然后接受修复它需要数月协调这一事实。现在，我可以直接修复它，让各团队审查成果，而不是要求他们自己完成变更。过去，一项涉及几十个代码仓库的研究任务可能需要投入一周时间。现在，它可能只需要一个下午。

这很重要，因为相对于负责的覆盖面，平台团队几乎总是资源不足。我们一直都必须艰难地判断哪些事情值得处理。AI 代理正在扩大那些在经济上可行的工作范围。它们并不是取代其中涉及的人类判断，而是处理那些机械性的执行工作，而正是这些工作过去让任务的成本高到难以承受。

我还注意到其中有更个人化的一面，我认为这与平台工作尤其相关。身处平台团队时，一个长期存在的挫败感是感觉自己与成果之间存在距离。你做出一项变更，但采用速度很慢，推广也不均衡；等你发现哪里不太对时，几个月已经过去了。这会让人感觉自己总是在被动响应：回应请求、帮助团队解除阻塞、等待别人需要你。

我注意到，代理可以改变这种局面。向每个使用方团队交付一个可以直接合并的 MR，不仅速度更快，也意味着我能立即看到结果。阻塞点在几天内就会暴露，而不是几个月后才出现。在平台岗位中，交付结果往往高度依赖其他团队是否将你的工作列为优先事项，因此过去很难实现真正端到端的责任感；而现在，这种责任感变得真实可见。

有一种说法认为，AI 主要是为了削减成本，也就是用更少的人完成同样的工作。在某些场景下也许确实如此。但根据我的经验，更有意思的故事是去做那些过去不值得做的事情：覆盖更大的范围、维持更高的标准、承担那些否则会无限期留在待办列表中的迁移工作，并最终弥合平台决策与现实结果之间的闭环。

这才是让我感到兴奋的地方。不是害怕什么会被取代，而是思考什么将成为可能。