AI 写代码时代：该不该读代码、RAG 是否过时、Skills 能否取代 MCP

背景：AI 编程工具正在重塑开发工作流

随着 GitHub Copilot、Cursor、Windsurf 等 AI 编程助手的普及，开发者的日常实践正在发生深刻变化。GitHub 开发者体验倡导者 GPS 在一篇博客中抛出了三个值得深思的问题：我们是否还需要阅读 AI 生成的代码？RAG 技术是否已经过时？Skills 是否取代了 MCP？ 这些问题直指当前 AI 辅助开发的核心矛盾，值得每一位开发者和 AI 使用者认真思考。

问题一：AI 生成的代码，到底该不该读？

常见的两种极端态度

在实际工作中，开发者对 AI 生成代码的阅读态度往往走向两个极端：

• "全信"派：直接复制粘贴，不做任何审查，认为 AI 不会出错。
• "全读"派：逐行阅读每一行代码，完全失去使用 AI 的效率优势。

实用建议：分层阅读策略

更合理的方式是按风险分层审查：

1. 低风险代码（如格式化、简单工具函数）：快速扫一遍逻辑即可，关注是否引入不必要的依赖。
2. 中风险代码（如业务逻辑、数据处理）：重点审查边界条件、错误处理和安全性。
3. 高风险代码（如认证授权、支付流程、数据迁移）：必须逐行审查，甚至手动重写关键路径。

核心原则：AI 生成代码的质量取决于提示词质量和上下文完整性。你越了解业务需求，越能判断 AI 输出是否合理。盲目信任或盲目怀疑都是不可取的。

问题二：RAG 技术是否已经过时？

RAG 的价值没有被取代

RAG（检索增强生成）的核心思路是：先从外部知识库检索相关信息，再交给大模型生成回答。有人质疑 RAG 已经过时，但实际情况是：

• 大模型的知识截止问题依然存在：模型训练数据有固定截止日期，无法覆盖最新信息。
• 私有数据无法注入模型：企业内部文档、代码仓库、API 文档等需要通过检索方式引入。
• 幻觉问题仍需缓解：RAG 通过提供真实上下文，显著降低模型"编造"的概率。

RAG 的局限性

但 RAG 确实面临挑战：

• 检索质量决定生成质量：如果检索到的文档不相关或过时，生成结果同样不可靠。
• 上下文窗口限制：即使检索到大量文档，模型能处理的上下文长度有限。
• 复杂推理场景表现不佳：对于需要多步逻辑推理的问题，简单的检索+生成模式力不从心。

结论：RAG 没有死，但需要与更高级的技术（如 Agent 框架、工具调用）结合使用，才能发挥最大价值。

问题三：Skills 是否杀死了 MCP？

先厘清概念

• MCP（Model Context Protocol）：一种开放协议，定义了 AI 模型与外部工具、数据源交互的标准方式，类似于 AI 领域的"USB 接口"。
• Skills：指 AI 模型具备的特定能力或技能，如代码生成、图像理解、多轮对话等。

两者不是替代关系

将 Skills 与 MCP 对立起来是一种误解：

• Skills 关注"模型能做什么"：是模型自身的能力集合。
• MCP 关注"模型如何连接外部世界"：是模型与外部系统交互的协议标准。

打个比方：Skills 是人的技能（会开车、会游泳），MCP 是交通法规和交通规则。你不会因为一个人会开车就说交通规则没用了——两者解决的是不同层面的问题。

实际开发中的选择

对于开发者来说，选择哪种方案取决于具体场景：

• 需要连接多个外部工具/数据源 → MCP 更合适，提供标准化的集成方式。
• 需要模型具备特定领域能力 → Skills 更直接，通过微调或提示工程实现。
• 两者结合 → 最灵活的方式，用 Skills 处理核心逻辑，用 MCP 连接外部资源。

对开发者的实用建议

1. 不要放弃代码审查能力：AI 是加速器，不是替代品。你的判断力决定了 AI 输出的最终质量。
2. RAG 仍是构建 AI 应用的核心组件：但要注意检索质量、上下文管理和结果验证。
3. MCP 和 Skills 各有适用场景：不要非此即彼，根据实际需求选择或组合使用。
4. 持续学习新工具：AI 编程工具迭代极快，保持开放心态，但也要建立自己的评估标准。

AI 辅助开发不是"要不要用"的问题，而是"怎么用得更好"的问题。理解这些底层概念，才能在实际工作中做出正确的技术决策。