我们组是怎么使用 AI 的：从 MCP、Skill 到研发工作流
我们组是怎么使用 AI 的：从 MCP、Skill 到研发工作流
这篇文章其实来自一次组内分享。
一开始我想写得很简单：先讲一下 AI 现在发展到什么阶段，再介绍 MCP 和 Skill，最后说说我们组平时怎么用 AI 写代码、排障。
但真开始整理的时候，我发现这个话题不能只写成“工具介绍”。
因为过去一年，我们对 AI 的使用方式其实变了很多。
刚开始大家更多是把 AI 当成一个问答工具。遇到一个概念不会，就问一下；写一段 SQL 卡住了，就让它帮忙改改；报错看不懂，就把堆栈丢进去解释一下。
这种用法当然有价值，但它更像是“个人临时提效”。
现在更值得讨论的是另一件事：AI 怎么进入团队的真实工作流。
也就是：
- 需求来了，它能不能帮我们更快理解和拆解？
- 写代码时，它能不能参与实现，而不是只给建议？
- Review 时，它能不能先帮我们扫一遍低级问题？
- 排障时，它能不能帮我们从日志和监控里理出线索？
- 更进一步，团队踩过的坑、总结出来的方法，能不能沉淀下来，让 AI 下次继续用？
我觉得这才是这轮 AI 对研发团队真正有意思的地方。
所以这篇文章我想围绕一个主线来讲：
AI 的价值，不是让某个人偶尔快一点，而是让团队把好的工作方法持续复用起来。
一、AI 发展到今天，已经不只是一个聊天窗口
过去我们说 AI，很多时候说的是一些比较“后台”的能力。
比如图像识别、语音识别、搜索排序、推荐系统、风控模型。这些东西很早就存在，也确实改变了很多产品体验。但对大多数普通用户来说，AI 当时并不是一个可以直接协作的对象。
它更像是藏在系统后面。
你能感受到推荐变准了，搜索变好了，语音识别更顺了，但你不会真的打开一个窗口，跟它一起讨论怎么完成一件事。
真正让大家感受到变化的，是大模型出现之后。
ChatGPT 之后，AI 第一次大规模变成了一个可以直接对话的“工作入口”。我们可以用自然语言描述问题，让它写文档、总结材料、生成代码、解释报错、翻译内容，甚至帮我们一起讨论方案。
这个变化很关键。
过去我们使用软件，通常要先学习软件的操作方式。按钮在哪、菜单在哪、命令怎么写，都得自己记。
大模型出现之后，很多事情变成了：你把目标说清楚，AI 先帮你走一步。
比如：
- 不知道一个模块怎么改，可以先让它读代码、解释结构
- 不知道一个报错什么意思，可以先让它翻译成人话
- 不知道一个方案怎么写，可以先让它给一个草稿
- 不知道测试用例怎么补，可以先让它列边界条件
这已经不是简单的“搜索增强”了。它更像是工作方式变了。
但很快我们也会发现，只会聊天的 AI 其实有很明显的天花板。
它可以告诉你“应该怎么做”，但不一定能真的帮你做。 它可以根据已有上下文回答问题，但不知道你公司内部系统里的真实数据。 它可以写一段代码，但如果不了解完整项目结构，很容易写出看起来对、实际跑不通的东西。 它也可以分析报错，但如果拿不到日志、监控、发布记录和配置变化，它的判断就只能停留在猜测。
所以 AI 往下走，很自然就到了 Agent 这个阶段。
所谓 Agent，我觉得不用把它讲得太玄。
简单说，就是 AI 不只是回答一句话，而是可以围绕一个目标，自己拆步骤、调工具、看结果、再调整。
比如写代码时，一个 Agent 可以做的不只是“帮我写一个函数”。它可以先读需求，再查项目结构，找到相关文件，提出修改方案，改代码，跑测试，看到报错后继续修，最后生成提交说明。
这时候 AI 的角色就变了。
它不再只是一个问答窗口，而是开始有点像一个能参与具体工作的协作者。
但 Agent 真正要好用，又会遇到两个问题。
第一个问题是：AI 怎么连接外部世界？
我们的代码在 Git 仓库里，文档在知识库里，问题在工单系统里，日志在日志平台里，数据在数据库里。AI 如果拿不到这些上下文，就很难真正完成任务。
第二个问题是：AI 怎么复用团队经验？
同样是“帮我排查问题”，不同团队的路径可能完全不一样。
有人先看日志，有人先看监控，有人先查发布记录，有人先看链路追踪。写代码也一样，每个团队都有自己的分支规范、代码风格、测试要求和 Review 标准。
如果每次都靠人把这些东西重新写进 Prompt 里，AI 的使用就很难稳定。
于是就出现了两个很重要的方向：MCP 和 Skill。
MCP 主要解决的是“连接”的问题。 Skill 主要解决的是“经验复用”的问题。
MCP 让 AI 可以通过统一协议连接工具和数据。Skill 则让 AI 可以按某个稳定的方法去完成一类任务。
放在一起看，它们其实代表了 AI 从“会回答”走向“能干活”的关键一步。
二、MCP：先解决 AI 怎么接入真实系统
先说 MCP。
MCP 全称是 Model Context Protocol。直译有点硬，简单理解就是：让 AI 连接外部系统的一套标准协议。
Anthropic 在 2024 年 11 月发布 MCP 时，提到一个很现实的问题：模型能力越来越强，但它们仍然被困在数据孤岛里。
这句话听起来有点官方，但放到工作场景里很好理解。
一个模型再聪明，如果它不知道你们项目的代码结构，不知道线上最近发了什么版本，不知道某个接口最近的错误日志，不知道内部文档里写了什么约定，它就只能凭空猜。
而研发工作最怕的就是凭空猜。
过去如果想让 AI 接入一个外部系统，通常要单独写一套集成。
接 GitHub，写一套。 接数据库，写一套。 接日志平台，再写一套。 接知识库、工单系统、CI 平台，又分别写一套。
这样做当然能跑，但维护起来很麻烦。
每个工具的接入方式都不一样，每接一个新系统都要重新适配。到最后很容易变成一堆胶水代码，短期能用，长期很难管。
MCP 的思路就是：不要每家都重新发明一遍连接方式。我们约一套标准。
外部系统可以通过 MCP Server 暴露能力。AI 应用或者 Agent 作为 MCP Client 去连接这些 Server。这样 AI 就可以用比较统一的方式拿上下文、调用工具、执行动作。
举个例子。
如果我们希望 AI 帮忙查日志，过去可能要给某个日志平台单独写插件。AI 得知道怎么鉴权、怎么查、结果长什么样。
但如果日志平台有 MCP Server，AI 就可以通过 MCP 标准接口去查询日志。它拿到结果之后，再结合用户描述继续分析。
再比如代码仓库。
AI 如果能通过 MCP 访问仓库，就可以自己查文件、看提交、理解目录结构。它不需要你把相关代码一段一段复制给它。
所以 MCP 的价值，我觉得可以概括成一句话：
它让 AI 从一个封闭的聊天框，变成了可以连接真实系统的工作入口。
不过这里要注意，MCP 解决的是“接得上”的问题。
它不直接解决“接上之后怎么把事情做好”的问题。
AI 能查日志，不代表它知道应该先查哪段日志。 AI 能读代码，不代表它知道怎么按团队规范改代码。 AI 能访问工单，不代表它知道怎么判断优先级和风险。
所以接下来就需要 Skill。
三、Skill：真正让 AI 复用团队经验
我自己更想重点讲 Skill。
因为 MCP 更像基础设施，重要，但离日常体感稍微远一点。Skill 则更贴近团队每天怎么做事。
Skill 可以理解为一种“任务能力包”。
它不是一句 Prompt，而是一组可以长期保存的说明、步骤、脚本、模板、示例和注意事项。AI 在遇到某类任务时，可以加载对应 Skill，然后按照里面沉淀的方法去做。
这个概念听起来不复杂，但我觉得它对团队很关键。
因为我们平时工作里，大量经验其实都不是写在系统里的，而是散落在人的脑子里。
比如：
- 老同事知道线上问题应该先看哪个监控面板
- 资深开发知道某个模块不能随便改
- TL 知道 Review 时最容易漏掉哪些边界条件
- 测试同学知道哪些场景每次都容易出问题
- 运维同学知道某类告警通常和什么配置有关
这些经验很有价值，但它们经常靠口口相传。
新人不知道。 AI 也不知道。 甚至老同事忙起来也可能忘。
Skill 的意义就在这里：把这些方法沉淀成 AI 可以读取、可以执行、可以复用的工作手册。
Skill 不是高级 Prompt
很多人第一次听到 Skill，会觉得它是不是就是一个更长的 Prompt。
我觉得不是。
Prompt 更像是一次性的指令。 Skill 更像是可复用的工作手册。
Prompt 适合临时任务。
比如：
帮我把这段话改得口语化一点。
或者：
帮我解释一下这个报错。
这种场景直接写 Prompt 就够了。
但如果任务会反复出现，而且每次都要遵守同一套规范，Skill 就更合适。
比如“代码 Review Skill”里可以写：
- 先看需求背景，不要上来就挑语法
- 先检查核心逻辑，再看边界条件
- 必须关注测试覆盖
- 涉及数据库变更时，要检查迁移脚本
- 涉及接口变更时，要看调用方影响
- 最后输出结论，不要只列一堆问题
这样就比每次说一句“帮我 Review 一下代码”稳定得多。
再比如“线上排障 Skill”里可以写：
- 先确认故障现象和影响范围
- 拉清楚时间线
- 对齐最近发布和配置变更
- 从日志里提取异常关键词
- 对比正常请求和异常请求
- 建立可能原因列表
- 每个原因必须配验证方法
- 最后输出根因、修复动作和复盘建议
这时候 AI 就不是随便猜一下，而是沿着团队认可的排障路径往下走。
Skill 和 MCP 的关系
如果用一个简单比喻：
MCP 是接口，Skill 是方法。
MCP 解决的是 AI 怎么连接工具。 Skill 解决的是 AI 怎么完成任务。
MCP 让 AI 能“拿到东西”。 Skill 告诉 AI “拿到东西以后怎么处理”。
比如排障场景。
MCP 可以让 AI 连接日志平台、监控系统、工单系统、Git 仓库。
但 Skill 会告诉它：
- 先看影响范围，不要先猜根因
- 先查最近变更，不要只盯日志
- 每个怀疑点都要给证据
- 没验证之前不要下结论
- 最后要把过程整理成复盘
再比如写代码场景。
MCP 可以让 AI 访问代码仓库、Issue、CI、文档。
但 Skill 会告诉它：
- 先理解需求，不要直接改文件
- 先列实现计划，让人确认方向
- 改完必须跑测试
- 提交前要总结影响范围
- PR 描述要写清楚验证方式
所以 MCP 和 Skill 不是替代关系，而是互补关系。
没有 MCP，AI 很容易缺上下文。 没有 Skill，AI 就算拿到了上下文，也可能不知道怎么按团队习惯做事。
为什么我觉得 Skill 对团队更重要
如果只从“技术先进性”看，MCP 可能更像一个基础设施方向。
但如果从团队落地看，我反而觉得 Skill 更容易先产生价值。
原因很简单：很多团队现在的问题不是“完全没有工具接入”，而是“大家用 AI 的方式太不稳定”。
同样一个需求，有的人会先让 AI 读代码再改，有的人直接让 AI 生成一段实现。 同样一个报错，有的人会让 AI 先梳理时间线，有的人直接问“根因是什么”。 同样一个 Review，有的人会让 AI 看边界条件，有的人只让它检查语法。
最后效果当然不一样。
Skill 的价值，是把这些隐性的好方法变成显性的流程。
这会带来几个变化。
第一，AI 的输出会更稳定。
不是每次都靠临场发挥，而是按照固定步骤做事。
第二，团队经验可以复用。
不是只有某个“会用 AI 的人”才能用得好，而是大家都可以基于同一套方法开始。
第三，新人上手会更快。
新人不一定马上理解所有系统细节，但可以先通过 Skill 了解团队处理问题的标准路径。
第四，复杂任务更容易被拆解。
因为 Skill 可以把复杂任务拆成几个稳定步骤，让 AI 一步一步执行，而不是一上来就给一个大而全的答案。
所以我现在看 Skill，不太会把它当成一个功能点。
它更像是团队经验资产的一种新形式。
以前我们把经验写在文档里，靠人去读。 现在我们可以把经验写成 Skill，让 AI 在执行任务时主动加载。
这件事听起来小，但长期看会很有价值。
四、我们组怎么用 AI 写代码
回到我们组自己的使用。
写代码这块，我们大概分成两类：本地插件 和 远端工作空间。
这两类不是谁替代谁，而是适合不同场景。
本地插件：适合小范围、高频、即时的问题
本地插件更像是开发过程中的“随手助手”。
比如你正在看一个模块，想快速理解某段逻辑。 比如你要改一个小需求，涉及两三个文件。 比如你遇到一个报错，想让 AI 先帮你解释一下调用链。 比如你写完一个函数，想让 AI 顺手补几个测试用例。
这些场景上下文比较集中，反馈链路也短。
开发同学自己就在 IDE 里，可以很快判断 AI 说得对不对。错了就改，方向不对就打断，成本很低。
一个比较常见的流程是这样的：
- 先把需求或者问题说清楚
- 让 AI 看当前文件和相关上下文
- 让它先给实现思路，不要急着改
- 人确认方向
- AI 辅助修改代码
- 本地跑测试或者启动服务验证
- 人做最后调整，再提交
这里 AI 的价值主要不是“替我写完所有代码”。
更准确地说，它帮我们省掉了很多中间动作。
比如理解陌生代码时，它可以先把调用链讲一遍。 写样板代码时，它可以先搭一个骨架。 补测试时，它可以提醒一些边界条件。 看报错时，它可以把堆栈翻译成更容易理解的说明。
这些事情单个看都不大，但每天发生很多次。省下来就很明显。
不过本地插件也有边界。
它更适合“人主导，AI 辅助”的场景。
如果任务很大，涉及多个模块、完整测试、环境依赖、CI 和 PR 流程，本地插件就不一定够用了。
这时候就适合远端工作空间。
远端工作空间：适合更完整的任务交付
远端工作空间更像是让 AI 在一个独立环境里完整跑一遍任务。
它可以拉代码、建分支、查文件、改代码、跑测试，最后生成变更总结甚至 PR。
这种方式更适合中等复杂度以上的需求。
我理想中的流程大概是：
- 我们先把需求写清楚
- AI 读取需求，分析相关代码
- AI 输出实现计划
- 人先 Review 计划，确认方向
- AI 开始修改代码
- AI 运行单测、构建或必要验证命令
- 如果失败，AI 根据报错继续修
- 最后生成变更总结和 PR
- 人做 Code Review
这里最关键的一点是：不要把 AI 当成完全自动提交代码的黑盒。
更合理的定位，是把它当成一个执行力很强的初级协作者。
它可以帮我们做大量检索、修改、验证和总结。 但方向判断、架构取舍、风险评估，还是要由人来把关。
尤其是实现计划这一步，我觉得很重要。
如果一上来就让 AI 直接改代码，后面很容易出现一个问题：它确实改了很多文件，但你不知道它为什么这么改。等你 Review 时，成本反而变高。
更好的方式是先让它说清楚：
- 它理解的需求是什么
- 它准备改哪些文件
- 每个文件大概改什么
- 有哪些风险点
- 准备怎么验证
人确认之后，再让它动手。
这样 AI 的执行力能用上，人也不会失去控制感。
Code Review：先让 AI 扫一遍，但最后还是人负责
Review 阶段也很适合用 AI。
它可以帮我们先扫一些模式化问题：
- 需求有没有覆盖完整
- 边界条件有没有遗漏
- 测试是不是缺了
- 有没有空指针、异常处理、并发问题
- 是否可能影响旧逻辑
- 命名和结构是否清晰
- PR 描述有没有说清楚验证方式
这些问题人工当然也能看，但人看多了会疲劳。AI 先扫一遍，至少能减少一些低级遗漏。
但我不建议把 AI Review 当成最终审批。
因为 AI 对业务背景、历史包袱、团队取舍，不一定理解得足够深。它很容易发现代码层面的模式问题，但不一定知道这个业务为什么当年要这么写。
所以我的理解是：
AI 负责帮我们扩大检查面，人负责最终判断。
这其实已经很有价值了。
因为 Review 最怕两件事：一是漏，二是被琐碎问题耗掉注意力。AI 如果能帮我们把明显问题先捞出来，人就可以把精力放在真正重要的判断上。
五、我们组怎么用 AI 排障
第二个方向是排障。
我觉得排障是非常适合 AI 参与的场景。
原因也简单：排障过程中有大量信息需要快速处理。
日志、监控、报错堆栈、用户反馈、发布时间线、配置变更、代码变更、上下游依赖、历史类似问题……
这些东西以前都要靠人一点点看。
人当然能看，但非常耗注意力。而且排障的时候往往还有时间压力，越急越容易漏东西。
AI 在这里的价值，不是“神奇地一下子告诉你根因”。
我反而觉得，如果一上来就问 AI：
这个问题根因是什么？
这不是一个好问法。
因为它很可能会猜。
更好的方式，是让 AI 帮我们把混乱的信息整理成一个可以验证的排查路径。
排障时，我更愿意让 AI 做这几件事
第一，帮我整理现象。
比如把用户反馈、错误码、时间点、影响范围整理到一起。很多故障刚开始的信息是散的，AI 可以先帮忙归纳成一段比较清楚的描述。
第二，帮我拉时间线。
什么时候开始异常？ 异常前有没有发布？ 有没有配置变更？ 监控指标从什么时候开始抖？ 日志里第一条异常大概出现在哪里？
排障时，时间线非常重要。它能帮助我们避免乱猜。
第三，帮我从日志里提取异常模式。
比如同一种报错是不是集中在某个接口。 是不是只影响某些租户。 是不是和某个下游服务有关。 是不是某个字段一直为空。 是不是某个错误码突然增多。
这些事情 AI 很擅长，因为它读文本快。
第四，帮我列假设，但每个假设必须配验证方法。
这一点很重要。
我不太喜欢 AI 直接说“根因可能是 XXX”。这种话没有意义。更好的输出应该是：
- 可能原因 A：依据是什么，怎么验证
- 可能原因 B：依据是什么，怎么验证
- 可能原因 C：依据是什么，怎么验证
这样人就可以按验证成本和可能性排序，一步一步排除。
第五，帮我整理复盘。
故障处理完之后，其实还有一堆文档工作：时间线、影响范围、根因、修复动作、后续改进。
这部分让 AI 先整理一版非常合适。人再补充业务细节和最终结论。
一个比较顺的排障流程
如果把它整理成流程，大概是这样：
-
先描述故障现象 什么时间发生，影响哪些用户，具体表现是什么，是否可复现，有没有明显错误码。
-
收集上下文 相关日志、监控指标、最近发布记录、配置变更、相关代码片段、依赖服务状态。
-
让 AI 提炼异常点 哪些日志是关键异常，哪些指标变化最明显，时间线是否和某次发布重合，报错是否集中在某个接口或版本。
-
让 AI 建立可能原因列表 每个原因要说明依据，不能只给结论。每个猜测都要配验证方法。
-
人执行验证 查具体数据、回滚配置、对比版本、复现问题，验证假设是否成立。
-
最后让 AI 辅助生成复盘 故障时间线、根因、修复过程、影响范围、后续改进项。
这里我想强调一点：排障里最重要的不是“AI 有没有猜对”。
真正有价值的是，它能不能帮我们减少信息噪音，让排查路径更清楚。
有时候问题最后不是 AI 找到的，但 AI 帮我们把信息整理好了，已经能省很多时间。
所以我更愿意把 AI 当成排障过程里的“分析助手”，而不是“判官”。
它可以提出假设。 但结论必须靠数据验证。
六、最后：AI 真正改变的是团队工作方式
回头看这轮 AI 的变化，我觉得最重要的地方，不是多了一个聊天工具，也不是某个模型又强了多少。
真正的变化是：AI 开始进入我们的工作流。
它可以参与写代码，参与 Review，参与排障，参与文档整理，参与知识沉淀。
它不再只是一个“有问题时问一下”的工具，而是可以在很多任务中承担一部分执行工作。
但这也带来一个新的问题。
如果每个人都只是按照自己的习惯随手用 AI，团队很难获得稳定收益。
有人用得很好，有人用得一般。 有人会让 AI 先读上下文再动手，有人一上来就让 AI 直接改代码。 有人会让 AI 给验证步骤，有人直接让 AI 猜根因。 有人会把好的流程沉淀下来，有人每次都从零开始。
最后效果肯定不一样。
所以我现在越来越觉得，团队使用 AI 的关键，不是追逐每一个新工具，而是慢慢沉淀自己的 AI 工作方式。
这里面大概有三层。
第一层，是工具使用。
比如我们会用本地插件、远端工作空间、AI Review、日志分析工具。
第二层，是流程嵌入。
比如需求开发怎么用 AI，Code Review 怎么用 AI，线上排障怎么用 AI，复盘总结怎么用 AI。
第三层，是经验沉淀。
也就是把我们已经验证过的方法，沉淀成 Skill、模板、检查清单和标准流程。
只有到第三层，AI 才不只是个人效率工具，而会变成团队能力的一部分。
对我们组来说，后面真正值得做的事情，可能不是简单比较“哪个 AI 工具更好用”，而是持续回答几个问题：
- 哪些工作适合交给 AI 做第一版？
- 哪些环节必须由人来判断？
- 哪些经验应该沉淀成 Skill？
- 哪些场景需要接入 MCP 或内部工具？
- AI 生成的结果应该如何验证？
- 怎么让不同成员都能稳定地用好 AI？
我觉得这才是 AI 在团队里的长期价值。
它不是替代我们思考，也不是替代我们负责。
它更像是把很多重复、琐碎、信息密集型的工作压缩掉，让人可以把更多精力放在判断、设计、沟通和决策上。
最后用一句话收尾：
MCP 让 AI 连接系统，Skill 让 AI 继承经验，而真正决定效果的，是团队能不能把这些能力放进自己的日常工作流里。
如果我们只是偶尔问一问 AI，它就是一个更聪明的搜索框。 如果我们把流程、工具和经验都沉淀进去，它才会慢慢变成团队真正的工作伙伴。