RAG 没死、MCP 没被杀死，那些 AI 热门观点究竟对不对

「你不需要阅读 AI 生成的代码」是流传最广的断言之一。现实是：你仍然对代码负责，但这并不意味着每一行生成代码都需要同等程度的审查。生产环境的身份验证重构与一个 CSS 实验理应有不同的审查流程。真正的技能在于判断风险所在——有时这项工作发生在 AI 动笔之前，你需要先读懂现有实现、梳理依赖关系、识别边界情况；有时则需要在生成结果出来后仔细检查错误处理、权限控制和性能表现。AI 改变的是精力的分配方式，而不是让工作本身消失。

关于「不使用 AI 就不会被录用」的说法，现实要更为微妙。越来越多的团队会在面试中询问候选人如何使用 AI，这本身合情合理，因为这些工具正在成为软件开发的组成部分。但真正重要的信号是判断力：你能解释何时使用 AI、何时手动完成工作吗？你能描述自己如何审查生成代码吗？对速度、质量、安全性和可维护性的权衡，你能说清楚吗？完全依赖和完全拒绝都不是好答案，清晰表达自己工作方式的能力，正在成为工程素养的一部分。

「Skills 杀死了 MCP」这一断言混淆了两种不同层面的工具。模型上下文协议（MCP）为智能体提供了连接工具和数据的标准化方式，解决的是系统间可靠互操作的问题。Skills 则更接近于打包好的专业知识，可以用 Markdown 编写，说明团队的工作方式、项目的修改规范或工具的使用惯例，人和模型都能读懂。MCP 提供访问能力，Skills 解释如何善用这种访问能力。两者并不竞争，组合使用比单独争论哪个更优远更有意义。

「RAG 已死」的说法同样站不住脚。检索增强生成（RAG）让 AI 系统能够获取训练数据之外的相关信息，包括文档、支持历史、产品细节和代码库上下文。没有良好的检索机制，模型只能依赖已有知识或花费额外时间搜索上下文，这会浪费 token、拖慢速度、增加答案不完整的概率。RAG 让模型从更接近答案的起点出发，缩小搜索空间。智能体、Skills、MCP 和 RAG 完全可以在同一个工作流中共存，把它们视为竞争关系只会妨碍对实际构建方式的理解。

「如果你需要对模型进行微调才能理解你的代码库，说明你的代码写得很糟糕」——这个观点有一定道理，但需要补充背景。现代模型已经见过大量常见框架、命名规范和架构模式。如果模型难以理解某个代码库，新加入的团队成员很可能也会遇到同样困难。AI 辅助开发正在成为可维护性的又一项压力测试，与代码审查、测试和新人上手并列。清晰的结构、一致的命名、可读的测试和有效的文档，既让智能体更容易理解代码，更重要的是让人更容易审查、调试和扩展。

真正的工程工作比这些争论本身更有趣。面对一个有价值的观点，更好的回应不是再抛出一个反驳，而是去测试这个想法、构建一些东西、记录发生了什么。Pollinations AI 正在实验一个贡献者可以通过改进项目赚取积分的生成式 AI 平台，探索开源贡献在 AI 降低参与门槛后的新形态；Avian Visitors 则是一个将阳台访客鸟类转化为电子墨水壁画的构建日志，结合了麦克风、树莓派和 3D 打印部件。这些项目不能解决所有 AI 争论，但它们提供了真实的学习素材——这比任何热门观点都更有价值。

要点

• AI 生成代码不免除开发者的审查责任，真正的技能是判断风险集中在哪里，并相应分配审查精力
• MCP 与 Skills 解决不同层面的问题，前者提供标准化工具访问，后者提供上下文与最佳实践，两者可以协同使用
• RAG 并未过时，它仍是让模型获取训练数据之外相关信息的核心机制，与智能体、MCP、Skills 并不冲突
• 代码库是否需要模型微调，在一定程度上反映了其可维护性水平，AI 正在成为代码质量的新一轮压力测试
• 对 AI 热门观点最有价值的回应不是站队，而是在真实工作中测试假设、记录结果、提炼可复用的判断框架