当下AI开发圈有三个流传甚广的”暴论”：“你不需要读AI生成的代码”、“RAG已死”、“Skills杀了MCP”。这些说法在社交媒体上转发量极高，但它们到底有多少道理？GitHub官方博客近日在播客节目中系统性地拆解了这三个话题，结论出人意料——这些”暴论”背后的逻辑，比表面上看到的要复杂得多。
AI生成的代码，到底要不要读？
最常见的说法是：既然让AI写代码了，为什么还要自己读？
GitHub播客的观点很明确：要读，而且必须读。因为最终为代码负责的人还是你。AI只是移动了工作量，但没有让工作消失。
关键在于风险在哪里。GitHub指出了一个实用的判断原则：review直到你能解释和承担结果为止。
具体来说：
- 写代码之前先读：在AI动手之前，你先理解现有的实现、依赖关系和边界情况。这样当第一行AI生成的代码出现时，你已经知道它应该做什么、哪里可能出错。
- 写代码之后重点检查：错误处理、权限、数据访问、性能、可访问性、测试——这些是AI生成代码最常出问题的区域，需要仔细审核。
- 场景不同，审查力度不同：一个维护了10年的认证重构项目，和一个CSS实验，需要的审查深度完全不同。用同一套标准对待所有变更，不是严谨，是浪费时间。
AI改变了工作的分布，但没有让工作消失。真正重要的技能，是知道风险藏在哪里。
RAG已死？——它只是不新鲜了
“检索增强生成（RAG）已死”是另一个广为流传的说法。GitHub播客的判断是：RAG没有死，它只是不再是人们发推特的新话题了。
RAG的核心价值在于：让AI系统能够获取模型训练数据之外的相关信息。这包括文档、支持历史、产品详情、内部知识，或代码库上下文。没有良好的检索，模型的回答就只能依赖自身的记忆——而那是静态的、有限的。
这意味着RAG在以下场景仍然不可或缺：
- 企业知识库问答：产品文档、内部流程、历史决策记录——这些内容随时变化，不可能全部塞进模型参数里。
- 代码辅助：让AI理解一个庞大的代码库结构、依赖关系、变更历史，没有检索机制几乎不可能做到。
- 实时数据查询：需要引用最新价格、库存、新闻事件等动态信息的场景。
RAG之所以给人”已死”的错觉，是因为它已经足够成熟、足够稳定，以至于不再刺激讨论欲。但成熟不等于过时——它意味着这项技术已经通过了概念验证期，真正进入了生产环境。
Skills和MCP：不是对手，是搭档
“Skills杀死了MCP”这个说法在开发者社区颇有市场。GitHub播客明确反驳了这个观点：它们解决的是不同层次的问题，根本不是竞争关系。
MCP（Model Context Protocol）提供的是标准化的接入方式：给AI Agent一个标准的方法来调用工具、获取上下文、执行操作。当你想让不同的AI系统互操作时，这个标准至关重要。
Skills提供的是打包的专业知识：团队如何工作、项目应该如何变更、工具应该怎么用、哪些约定重要——这些是”知识”而不是”接口”。Skills通常用Markdown编写，因此人类也可以直接阅读，这本身就是其价值的一部分。
用GitHub的话来说：“MCP可以提供访问，Skills可以解释如何使用访问。”
两者结合的场景很清晰：一个AI Agent通过MCP连接到代码库（标准接口），同时通过Skills理解这个代码库的架构约定、最新的重构方向、以及团队的工作流程。这样Agent不仅能干活，还能”理解”为什么要这样干。
不是选一个放弃另一个，而是各司其职：用标准实现共享接口，用Skills传递上下文、流程和最佳实践。
从”AI会取代程序员”到”AI经济研究”：Google的新动作
与这些技术讨论并行，Google在同一天宣布扩大其AI经济研究项目（AI & Economy Research Program），新加入的顾问包括诺贝尔经济学奖得主Philippe Aghion、Ajay Agrawal等顶级学者。他们的研究方向将覆盖AI对就业、生产力、全球技术扩散的影响。
这从侧面印证了AI开发领域正在发生的深层变化：AI工具不只是改变程序员的个人工作效率——它在重塑整个软件产业的分工逻辑、技能需求和经济结构。
当”读不读AI生成的代码”成为值得在GitHub播客里花一个小时讨论的话题，当Skills和MCP的边界需要在播客里被仔细澄清，这本身就说明：AI在开发领域的渗透，已经从”能不能用”进入到了”怎么用好”的阶段。
在这个阶段，简单的工具推荐不够用了，需要的是对工作流程、风险边界和工具协同的精细理解。
AI 会员开通推荐
免 KYC 虚拟卡，可开通各类 AI 会员：立即注册