GitHub 播客：该不该读 AI 生成的代码、RAG 已死、Skills 杀死了 MCP？

热门观点能把复杂话题浓缩成一句自信满满的断言。这让它们非常适合引发互动，却未必有助于理解。

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

热门观点的价值在于：当你不再只是反应，而是开始拆解它们时会发生什么。它在什么条件下成立？缺少了什么背景？它做了哪些假设？当你把它应用到实际工作中时，又会有什么变化？

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

我们在最新一期的 GitHub 播客中探讨了这一切以及更多内容！

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

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

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

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

一次生产环境的身份验证重构，值得采用与一次 CSS 实验不同的审查流程。一个你维护了 10 年的代码库，与一个你今天早上才打开的代码库，会以不同的方式引导你的直觉。假装每一处改动都承载相同的风险并不是严谨，而只是对时间的糟糕利用。

一条简单的规则：一直审查，直到你能解释并掌控结果。

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

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

AI 只是把精力挪到了别处。它并不会让工作消失。

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

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

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

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

更强的信号是判断力。

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

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

The better answer is a clear explanation of how you work, what you trust the tools to do, and where you keep yourself in the loop.

That kind of fluency is becoming part of the craft.

Hot take #3: “Skills killed MCP”

No. They solve different problems.

The Model Context Protocol gives agents a standard way to connect to tools and data. That standard matters when you want systems to work together reliably. Agents need structured ways to call tools, fetch context, and take action.

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

MCP 可以提供访问能力。Skills 可以说明如何用好这种访问能力。

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

两者的结合比这场争论有趣得多。

热门观点 #4：“RAG 已死”

RAG 并没有死。它只是不再是人们最想发帖谈论的最新事物。

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

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

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

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

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

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

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

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

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

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

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

这是件好事。

真正的工作比争论更有趣

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

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

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

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

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

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

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

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