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 没有死。它只是不再是人们最想发帖讨论的新鲜事物。

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

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

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

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

这些东西并不是在互相打架。把它们当成在打架，就误解了人们实际是如何用 AI 构建东西的。

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

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

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

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

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

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

这是好事。

真实工作比争论更有意思

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

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

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

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

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

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

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

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

订阅 GitHub Podcast，不错过任何一集！

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