GitHub Podcast 拆解五大 AI 热梗：该不该读 AI 代码、RAG 已死、Skills 杀死 MCP？

热点观点把复杂话题浓缩成一句自信的话。这让它们非常适合引发互动，但不一定有助于理解。

从表面上看，它们并不太重要。你同意、反对、转发、争论几分钟，然后继续前行。有时这个观点方向是对的。有时它完全是胡说八道。

热点观点的价值在于当你停止反应、开始拆解它们时会发生什么。在什么条件下这是真的？缺少了什么背景？它做了哪些假设？当你把它应用到实际工作中时，会发生什么变化？

深度就在那里。一个好的热点观点给你足够尖锐的东西去质疑。问题正是你发现有用想法的地方。

我们在最新一期的 GitHub Podcast 中探讨了所有这些以及更多内容！

还没准备好深入？以下是我们讨论过的一些常见 AI 热点观点，以及我们能从中获得什么。

热点观点 #1：“你不需要阅读 AI 生成的代码”

不，你需要。你仍然对代码负责。

但这并不意味着每一行生成的代码都需要同等程度的关注。

生产环境的身份验证重构值得与 CSS 实验不同的审查流程。你维护了 10 年的代码库与今天早上才打开的代码库对你的直觉引导不同。假装每个变更都承担相同的风险不是严谨。那只是对时间的糟糕利用。

一个简单的规则：审查到你能够解释并承担结果为止。

有时这项工作在智能体写任何东西之前就开始了。你阅读当前实现，梳理依赖关系，识别边界情况，并制定计划。当第一个实现出现时，你已经知道它应该做什么，以及哪里可能出错。

其他时候，生成的代码本身需要你大部分注意力。你检查错误处理、权限、数据访问、性能、可访问性和测试。

AI 转移了工作重心。它并没有让工作消失。

真正的技能是知道风险在哪里。

热点观点 #2：“如果你不使用 AI，公司就不会雇用你”

现实情况要更微妙一些。越来越多的团队会问候选人如何使用 AI。这很合理。这些工具正在成为软件开发的一部分。

但没有人认为每个开发者都需要相同的工作流程、相同的工具或相同的热情。

更强的信号是判断力。

你能解释什么时候使用 AI，什么时候手动工作吗？你能描述你如何审查生成的代码吗？你能诚实地谈论速度、质量、安全性和可维护性吗？你能随着工具的变化而改变你的流程吗？

如果一家公司正在构建 AI 产品或在其工程工作流程中大量使用 AI，拒绝接触 AI 可能会让你不合适。这并不有争议。但完全依赖和完全拒绝很少是好的答案。

更好的答案是清楚地解释你如何工作、你信任工具做什么，以及你在哪里让自己保持在循环中。

这种流畅性正在成为这门手艺的一部分。

热点观点 #3：“Skills 杀死了 MCP”

不。它们解决的是不同的问题。

模型上下文协议为智能体提供了一种连接工具和数据的标准方式。当你希望系统可靠地协同工作时，这个标准很重要。智能体需要结构化的方式来调用工具、获取上下文并采取行动。

技能更接近于打包好的专业知识。一项技能可以说明团队如何运作、项目应如何修改、工具应如何使用，或哪些约定很重要。由于技能通常用 Markdown 编写，人们也可以阅读它们。这种可读性正是其价值的一部分。

MCP 可以提供访问权限。技能可以说明如何善用这种访问权限。

你不需要选出赢家。用标准来定义共享接口。用技能来承载上下文、流程和最佳实践。

两者的结合远比争论本身有趣。

热评 #4：“RAG 已死”

RAG 并没有死。它只是不再是人们最热衷于发帖讨论的新鲜事物。

检索增强生成让 AI 系统获取模型训练数据之外的相关信息。这些信息可以包括文档、支持历史、产品详情、内部知识或代码库上下文。

如果没有良好的检索，模型就只能依赖它已知的内容，或花额外时间搜索上下文。这会浪费 token、拖慢工作速度，并更可能给出不完整的答案。

良好的检索能帮助模型更接近答案的起点。它缩小了搜索空间，并让回答建立在真正重要的信息之上。

智能体、技能、MCP 和 RAG 可以共存于同一个工作流中。一个智能体可能使用 MCP 访问工具，遵循技能获取项目特定的指令，并使用检索找到合适的支撑上下文。

这些东西并不是在互相争斗。把它们当成在争斗，就误解了人们实际使用 AI 构建的方式。

热评 #5：“如果你需要为你的代码库微调模型，那说明你的代码很糟糕”

微调模型有正当理由。不过，现代模型已经见过大量常见框架、模式、命名约定和架构。如果模型无法理解你的代码库，那么新加入的队友也很可能会感到吃力。

AI 正在成为可维护性的又一项压力测试，与代码审查、测试、新人上手，以及六个月后调试这段代码的那个可怜人并列。

清晰的结构有帮助。一致的命名有帮助。可读的测试、有用的抽象和最新的文档也有帮助。

这些东西能让代码库更容易被智能体理解，但更重要的是，它们让人更容易审查、调试和扩展。

AI 辅助开发会奖励那些让意图显而易见的代码库。

这是件好事。

真正的工作比争论更有趣

AI 会不断产生强烈的观点，因为工具变化很快，而我们也都还在摸索自己的工作流。

你不需要在每场争论中都选一个永久立场。

对一个有趣观点更好的回应不是另一个观点。去测试这个想法。动手做点东西。记录发生了什么。给大家一些真实可学的东西。

Pollinations AI 正在这样做：它试验一个生成式 AI 平台，贡献者可以通过改进项目来赚取名为 pollen 的积分。人们可以提出并解决问题、贡献模型并完成任务。这个项目提出了关于激励机制、质量、规模，以及当 AI 降低参与门槛时开源贡献可能是什么样子的真实问题。

Avian Visitors 则以完全不同的方式在做这件事。它是一个鸟类监听电子墨水屏的构建日志，把造访公寓阳台的鸟儿变成不断变化的墙面艺术。它结合了麦克风、树莓派、电子墨水屏、3D 打印部件、生成的鸟类图像和细致的文档。

这些项目并不能解决所有关于 AI 的争论。它们做的是更有用的事：创造证据、暴露权衡，并给其他人一个起点。

读足够的代码，以便对结果负责。建立足够的 AI 素养，以便解释你的工作方式。当标准接口有帮助时，使用 MCP。当上下文和流程重要时，使用 skills。当有依据的信息能让系统更好时，保留 RAG。如果你的代码同时让人和模型感到困惑，就把它当作可维护性问题来处理。

最重要的是，用你学到的东西去做点什么。

订阅 GitHub Podcast，这样你就不会错过任何一集！

文章 Should you read the code, is RAG dead, and did Skills kill MCP? 首次发表于 The GitHub Blog。