眼下关于 AI 的喧嚣和炒作很多，其中大量讨论都集中在岗位替代以及工程师可能会失去什么上。我想聊聊相反的一面：在平台团队的日常工作中深度使用 AI 智能体，过去几个月里我收获了什么。

我不会把它说成是什么魔法，智能体也会犯错，也无法取代为它们下达清晰指令所必需的工程知识。但我用智能体完成的一些工作，确实带来了质的飞跃。写代码更快了，但更大的变化在于工作范围：那些原本会被我搁置的工作，现在也能着手去做了。

平台团队的困境

如果你读过我之前那篇关于平台团队挑战的文章，就会了解这个背景：团队很小，却要负责非常大的技术面。任何时候，我们都在同时维护共享服务与公共库、覆盖 28 个项目的微前端架构、CI 流水线等等。

平台工作的令人沮丧之处在于，最棘手的问题往往不是技术问题，而是组织问题。你可能已经发现了横跨 20 多个项目需要修复的问题，也完全清楚修复方案是什么，却依然要花上数月才能落地。因为每个团队都有自己的优先级，未必与平台团队的目标一致。平台团队的挑战，就在于弥合“这件事应该做”与“团队有空去做”之间的鸿沟。

而智能体正开始以我未曾预料的方式弥合这一鸿沟。

调研类工作：让跨项目的决策真正可行

在平台团队里，最重要的决策往往也是最难有把握做出的。在决定废弃某个服务、替换某个库，或是在全组织推行一项新规范之前，你需要搞清楚会影响到谁、边界情况有哪些。而这类摸底工作成本一直很高，团队常常要么跳过它、在信息不全的情况下仓促做决定，要么因为没人有精力好好去做而无限期推迟决策。

理解一个遗留服务

我们有一个存在多年的服务。没有明确的负责人，文档也极少，但有一个问题反复出现：到底是谁在用它，又是怎么用的？我们觉得这个服务应该下线，但在摸清真实的使用情况之前，无法就如何迁移做出明确决策。要得到答案，就得在 GitLab 上手动追踪依赖，去翻历史遗留的 SVN 仓库，再把多年前早已离职的人写的代码一点点拼凑起来。

借助智能体，我把大部分摸排工作都交了出去。它遍历了 GitLab 和 SVN 上的所有调用方项目，定位到调用点，总结了该服务在不同上下文中的使用方式，并标出了我需要注意的边界情况。原本可能需要花上几天的工作，现在只用一小部分时间就能完成复核并在此基础上继续推进。

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

图标使用与 WCAG 合规性

另一个例子是我们评估 WCAG AA 合规性的工作，其中一部分是检查在各个应用中是否一致、正确地使用了图标。要了解问题的范围以及该如何修复，我们需要知道哪些图标组件正在被使用、在上下文中是否使用得当，以及真正的 WCAG AA 缺口在哪里。

如果逐个项目手动排查会非常繁琐。于是，我利用智能体，结合我们的设计系统使用数据，在上下文中逐一评估每个图标的使用情况，并将结果填入表格。

我按需进行了复核和修正，但自己投入的时间大幅减少。更重要的是，我们得以基于真实数据来决定下一步该怎么做。

迁移与升级：不只是设计，更要落地

一旦能快速明确问题的范围，自然会想到下一个问题：能否用同样的方式直接把问题修掉。这正是智能体对我帮助最大的地方——让我们不再只是分享迁移指南，而是直接交付变更。

横跨 28 个微前端的 React 升级

如果你读过我那篇关于微前端 React 升级的文章，就会知道这类工作需要多少协调。每个项目都归不同团队所有，大家的优先级各不相同。要让所有团队都去执行一次迁移，哪怕文档再完善、步骤再清晰，也是一项巨大的挑战。

在最积极的几个团队完成迁移后，仍有相当数量的项目卡住了最终发布。与其等待各团队自行行动，我让智能体逐个处理每个项目：按照迁移指南操作，完成必要的配置修改，解决该项目特有的问题，然后提交 MR。对每一个项目，智能体都处理了迁移中机械性的部分，团队收到的是可直接合并的代码变更，而不是一份待办请求。

之前

之后

所有 MR 最终都被合并了。整个 rollout 过程中遇到的唯一一个问题，来自一个在我提交 MR 之前就已手动完成迁移的团队。智能体生成的变更记录反而比人工操作的更干净。

从“提交 MR”到“合并 MR”的转化率，远高于从“发送迁移指南”到“完成迁移”。团队依然会审查、合并并对代码负责，只是在合并前需要做的事情少了很多。

CI 流水线重构

最近一次 GitLab CI 重构也是类似的情况。我们需要将共享流水线从已废弃的 only 关键字迁移到 rules 语法。改动本身并不复杂，但需要在所有接入该流水线的项目中逐一落地，每个项目都有自己的特殊情况，时不时还会遇到需要处理的破坏性变更。

这类变更通常在不同项目中的落地进度参差不齐，团队往往会拖到不得不改时才去处理。这种不一致会导致不同项目的流水线表现各异，进而引发混乱。

通过让智能体以编程方式识别所有受影响的项目，逐个完成迁移、处理遇到的破坏性变更并提交 MR，我只用了手动操作所需时间的一小部分，就在所有项目中完成了这次变更。

实践心得

回头看上面的例子，听起来似乎很简单。但在实践中，这些任务能够稳定跑通之前，经历了不少试错。其中最大的收获是定制了一个 glab skill，其他经验也都来自这些尝试。

为你的工具定义一个 skill

我做过的最有成效的一件事，就是为 glab CLI——也就是 GitLab 的命令行工具——编写了一个定制的 agent skill。skill 是一个 markdown 文件，它为智能体提供了清晰、明确的操作指引，告诉它如何完成特定任务：在这个场景下，就是如何跨项目搜索、如何创建 MR、如何通过 REST API 修改文件

没有它，智能体要么会拒绝与 GitLab 交互，要么会生成不一致、脆弱的 bash 单行命令。有了一个定义良好的 skill，它们就有了可靠的操作手册。Agent Skills 是一项开放标准，在 Cursor、Claude Code 和 GitHub Copilot 等工具中都得到了支持。

通过 MCP 让智能体访问内部上下文

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

我通过我们的设计系统 MCP 服务解决了这个问题。MCP（Model Context Protocol，模型上下文协议）是一项开放标准，能让你以结构化、可查询的方式对外暴露内部数据和文档，供智能体使用。我们的服务构建在 Storybook 之上，让智能体可以访问组件的 props、使用指南和示例。当智能体为无障碍审查图标用法时，就可以查询设计系统中图标相关组件的预期用法。

由于 MCP 是开放标准，同一个服务可以在不同工具间通用。不过，维护一个 MCP 服务是有持续成本的，并非一劳永逸。对我们来说这是值得的，但你也可以直接让智能体读取本地的 markdown 文件，或者如果内部文档在 Confluence 上，也可以使用类似 Atlassian MCP 这样的方案。

以审计数据作为起点

与其让智能体从零开始去发现哪些项目使用了某个库，不如直接把答案给它。我们有设计系统的使用分析数据，能准确告诉我们哪些项目正在使用哪些组件、版本是多少。在任务开始时就把这些数据喂给智能体，意味着它是从我们的实际使用数据出发，而不是靠猜测，这既更快也更准确。

我一直在尝试一个项目，用于扫描和解析整个组织内的依赖使用情况，并为智能体提供可直接查询这些数据的 MCP 工具。

事先定义结构，减少调研任务中的错误

在平台团队中，调研任务的成果通常会支撑影响 20 多个项目的决策，因此准确性至关重要。一份遗漏边界情况的含糊总结不仅毫无帮助，还会导致错误的决策。

对于调研类任务，我发现事先花时间定义好输出格式是值得的。与其让智能体“去调研我们项目中的图标使用情况”，不如直接给它一个表格模板，每个项目一行，并明确需要填写的列。

这会迫使智能体有条理地工作，逐个项目、逐列完成，每一行都有清晰的完成标准。当智能体面对一个开放式、缺乏结构的调研任务时，往往会以比你期望的更高层次进行概括，或者因为自认为已完成而过早结束。

照常编写迁移指南，并把它当作提示词

对于平台团队来说，无论如何你都会编写一份迁移指南来向接入团队传达变更。而我发现，把同一份指南喂给智能体本身就是一个很有用的验证步骤。

如果智能体感到困惑或走错了方向，往往说明指南中存在缺口或表述不清。那些指南未覆盖的边界情况，会在智能体处理真实项目时被暴露出来。当你在几个项目上跑通智能体后，也就相当于对文档做了一次压力测试，这会让指南对于那些最终需要复核变更或手动按步骤操作的团队来说更加完善。

关于工具

这类工作我主要使用 Cursor，也在 Claude Code 和 GitHub Copilot 上做过一些尝试。说实话，工具之间的差异远不如你提供给它们的上下文质量重要。一个定义良好的 skill 和一个好的 MCP 服务，比频繁更换工具更有价值。

这里的开放标准（用于上下文的 MCP、用于智能体行为的基于 markdown 的 skill 文件）意味着你在某个工具上的投入很大程度上可以迁移到其他工具上。在不同厂商和模型的定价不断波动的情况下，与其被某一种工作流深度绑定，不如记住这一点。

这带来了什么改变

智能体会犯错。它们需要清晰的上下文和定义良好的任务。你仍然需要复核输出、理解它们做了什么，并运用自己的判断。有些任务它们处理得并不好，我在规划阶段依然需要经过几轮迭代才能得到想要的结果。

“AI 取代工程师”这种叙事忽略了真正有意思的地方。我的实际体验更接近于：单个工程师能够承担的工作上限被抬高了。

以前，我可能会发现一个影响 28 个项目的问题，并接受修复它需要数月协调的现实。现在，我可以直接把问题修好，让团队来复核，而不是请他们自己去改。以前，一项横跨数十个仓库的调研任务可能需要投入一周时间，现在或许一个下午就能完成。

这很重要，因为平台团队相对于所负责的技术面几乎总是人手不足。我们一直不得不在“值得做什么”上做出艰难取舍。AI 智能体正在扩大那些在经济上可行的工作范围——不是通过取代其中涉及的人的判断，而是通过承接那些曾让这些任务成本过高的机械性执行工作。

除此之外，还有一些更个人的感受，我觉得这是平台工作特有的。身处平台团队，一个持续的困扰是对影响力的疏离感。你做了一次变更，但采纳缓慢、推广参差不齐，等到发现哪里不太对时，已经过去了数月。工作很容易变得被动：响应需求、为团队扫清障碍、等待被需要。

我注意到，智能体可以改变这种局面。向每个接入团队交付一个可直接合并的 MR，不只是更快，也意味着我能立刻看到结果。阻塞问题在几天内而非数月后就会浮现。一种真正端到端的 ownership 感——在以往的平台岗位中很难实现，因为太多交付都依赖其他团队来优先处理你的工作——如今变得可及了。

有一种观点认为，AI 主要关乎削减成本，用更少的人做同样的事。在某些场景下也许确实如此。但就我的体验而言，更有意思的故事是关于去做那些以前不值得做的事：覆盖更广的范围、维持更高的标准、承接那些否则会永远躺在 backlog 里的迁移，并最终在平台决策与实际落地之间形成闭环。

这正是我感到兴奋的原因。不是对“什么会被取代”的恐惧，而是对“什么变得可能”的好奇。