该读代码吗？RAG 已死？Skills 终结了 MCP 吗？
英文标题：Should you read the code, is RAG dead, and did Skills kill MCP?
GitHub Podcast 最新一期围绕多项 AI 热议观点展开分析，包括是否需要审查 AI 生成代码、企业是否要求开发者使用 AI、Skills 与 MCP 的关系，以及 RAG 和模型微调的价值。文章指出，AI 并未消除开发工作，而是改变了开发者应投入审查、判断和风险管理精力的位置。MCP、Skills、RAG 与 Agent 并非相互替代的竞争关系，而可在同一工作流中分别承担工具连接、上下文指导和信息检索等职责。对开发者而言，关键能力是能够解释自己的 AI 使用方式、验证产出，并持续维护代码库的可读性与可维护性。
75.6 KB
33.6 KB
84.8 KB
40.0 KB
60.5 KB
30.0 KB
127.1 KB
52.6 KB
77.9 KB
37.0 KB
70.2 KB
34.5 KB
84.0 KB
42.8 KB
1.2 MB
8.5 KB
22.1 KB
143.7 KB
20.1 KB
中文
犀利观点会把复杂议题压缩成一句充满自信的话。这使它们很适合吸引互动，但未必有助于理解问题。
从表面上看，它们并不太重要。你会赞同、反对、转发、争论几分钟，然后继续做别的事。有时，这种观点在方向上是正确的；有时，它则完全是无稽之谈。
犀利观点的价值，在于你不再只是作出反应，而是开始拆解它时所发生的事。在什么条件下它成立？缺失了哪些背景？它作出了哪些假设？当你把它应用到实际工作中时，会发生什么变化？
深度就在那里。一个好的犀利观点能提供一个足够鲜明、值得质疑的命题。而问题本身，才是你发现有用想法的地方。
我们将在最新一期 GitHub Podcast 中探讨这些话题及更多内容！
还没准备好深入收听？以下是我们讨论的一些常见 AI 热议观点，以及能从中得到的启示。
热议观点 #1：“你不需要阅读 AI 生成的代码”
不，你需要。你依然要对代码负责。
但这并不意味着每一行生成的代码都需要投入同等程度的注意力。
一次面向生产环境的身份验证重构，理应采用不同于 CSS 实验的审查流程。一个你维护了 10 年的代码库，与你今天早上才打开的代码库，会以不同方式影响你的直觉。假装每一处改动都带有同样的风险，并不是严谨，只是浪费时间。
一条简单的原则：审查到你能够解释并承担结果为止。
有时，这项工作在 Agent 写出任何内容之前就开始了。你会阅读当前实现、梳理依赖关系、识别边界情况，并制定计划。当第一个实现出现时，你已经理解它应该做什么，以及哪些地方可能出错。
另一些时候，生成的代码本身才是你需要投入大部分注意力的对象。你需要检查错误处理、权限、数据访问、性能、无障碍性和测试。
AI 改变了投入精力的位置，但不会让工作消失。
真正的能力，是知道风险在哪里。
热议观点 #2：“如果你不用 AI，公司就不会雇用你”
现实情况稍微更复杂一些。越来越多的团队会询问候选人如何使用 AI。这很合理，因为这些工具正在成为软件开发的一部分。
但没有人认为每位开发者都必须采用同样的工作流、同样的工具，或抱持同样程度的热情。
更有力的信号是判断力。
你能否解释自己在什么时候使用 AI、什么时候手动工作？你能否说明如何审查生成的代码？你能否坦诚讨论速度、质量、安全性和可维护性？当工具发生变化时，你能否调整自己的流程？
如果一家公司在构建 AI 产品，或者在工程工作流中大量使用 AI，那么拒绝接触 AI 可能意味着你并不适合。这并不具争议性。但完全依赖和完全拒绝，通常都不是好答案。
更好的答案，是清楚说明你的工作方式、你信任工具完成哪些工作，以及你在哪些环节让自己始终参与其中。
这种熟练度正逐渐成为这门技艺的一部分。
热议观点 #3：“Skills 终结了 MCP”
没有。它们解决的是不同的问题。
Model Context Protocol 为 Agent 提供了一种连接工具和数据的标准方式。当你希望系统能够可靠协作时，这种标准至关重要。Agent 需要结构化的方法来调用工具、获取上下文并采取行动。
Skills 则更接近于被封装的专业知识。一个 Skill 可以说明团队如何工作、项目应如何修改、工具应如何使用，或者哪些约定很重要。由于 Skills 通常以 Markdown 编写，人们也可以直接阅读它们。这种可读性正是其价值的一部分。
MCP 可以提供访问能力；Skills 可以解释如何善用这种访问能力。
你不需要选出一个赢家。将标准用于共享接口；将 Skills 用于上下文、流程和最佳实践。
二者的结合，远比这场争论本身更有意思。
热议观点 #4：“RAG 已死”
RAG 没有死。它只是不再是人们最想发帖讨论的新鲜事物。
检索增强生成（retrieval-augmented generation，RAG）能为 AI 系统提供模型训练数据之外的相关信息。这些信息可以包括文档、支持历史、产品细节、内部知识或代码库上下文。
如果缺少良好的检索，模型就只能依赖它已经知道的内容，或花费额外时间搜索上下文。这会浪费 token、拖慢工作，并增加答案不完整的可能性。
良好的检索能帮助模型从更接近答案的位置开始。它缩小搜索空间，并让响应建立在真正相关的信息基础上。
Agent、Skills、MCP 和 RAG 可以同时存在于同一个工作流中。一个 Agent 可能通过 MCP 访问工具，遵循某个 Skill 中的项目特定指引，并使用检索来找到合适的辅助上下文。
这些东西并非彼此对抗。把它们当作竞争关系，会忽视人们实际上是如何使用 AI 构建产品的。
热议观点 #5：“如果你的代码库需要为此微调模型，说明你的代码很差”
微调模型有合理的应用场景。不过，现代模型已经见过数量庞大的常见框架、模式、命名约定和架构。如果模型无法理解你的代码库，那么一位新加入的团队成员也很可能会感到困难。
除了代码审查、测试、入职流程，以及六个月后那个不得不排查问题的人之外，AI 正在成为代码可维护性的另一项压力测试。
清晰的结构很有帮助，一致的命名很有帮助。易读的测试、有用的抽象和及时更新的文档也都有帮助。
这些因素会让代码库更容易被 Agent 理解；但更重要的是，它们也让人更容易审查、调试和扩展代码。
AI 辅助开发会奖励那些能够清晰表达意图的代码库。
这是件好事。
实际工作比争论更有意思
AI 会继续催生强烈观点，因为工具变化很快，而我们都还在摸索自己的工作流。
你不需要在每一场争论中都永久站队。
面对一个有意思的观点，更好的回应不是再抛出一个观点，而是测试这个想法、构建一些东西、记录发生的结果，并给每个人留下可从中学习的真实材料。
Pollinations AI 正在通过实验这样做：它打造了一个生成式 AI 平台，贡献者可通过改进项目赚取称为 pollen 的积分。人们可以创建并解决 issue、贡献模型，以及完成任务。这个项目提出了关于激励机制、质量、规模，以及当 AI 降低参与门槛时开源贡献可能呈现何种形态等真实问题。
Avian Visitors 则以完全不同的方式实践这一点。它是一份构建日志，记录了一个用于聆听鸟鸣的电子墨水显示器：它会把公寓阳台上来访的鸟类转化为不断变化的墙面艺术。该项目结合了麦克风、Raspberry Pi、电子墨水屏、3D 打印部件、生成的鸟类图像和周到的文档。
这些项目并未为所有 AI 争论一锤定音。它们做了一件更有用的事：创造证据、暴露权衡，并为其他人提供一个起点。
阅读足够多的代码，以便能够对结果负责。培养足够的 AI 熟练度，以便解释你的工作方式。当标准接口有帮助时使用 MCP；当上下文和流程重要时使用 Skills；当有事实依据的信息能让系统更好时保留 RAG。如果你的代码同时让人和模型感到困惑，就应把它视为一个可维护性问题。
最重要的是，把你学到的东西付诸行动。
订阅 GitHub Podcast，这样你就不会错过任何一期节目！
作者
GPS 是 GitHub 的高级开发者体验倡导者。她通过社区交流、会议演讲、实操工作坊、有用的演示，以及大量表情包，帮助 GitHub 更好地服务开发者。业余时间，她会在 learntocloud.guide 构建广受欢迎的云工程课程内容。
English / 原文
Hot takes turn complicated topics into one confident sentence. That makes them great for engagement, but not necessarily for understanding.
At the surface level, they do not matter much. You agree, disagree, repost, argue for a few minutes, and move on. Sometimes the take is directionally right. Sometimes it is complete nonsense.
The value of hot takes is in what happens when you stop reacting and start pulling them apart. Under what conditions is this true? What context is missing? What assumptions does it make? What changes when you apply it to real work?
That is where the depth is. A good hot take gives you something sharp enough to question. The questions are where you find the useful ideas.
We explore all this and more in the latest episode of the GitHub Podcast!
Not ready to dive in yet? Here are a few of the common AI hot takes we discussed and what we can get from them.
Hot take #1: “You do not need to read AI-generated code”
Yes, you do. You are still responsible for the code.
But that does not mean every generated line needs the same level of attention.
A production authentication refactor deserves a different review process than a CSS experiment. A codebase you have maintained for 10 years steers your instincts differently than one you opened this morning. Pretending every change carries the same risk is not rigor. It is just a bad use of time.
A simple rule: review until you can explain and own the outcome.
Sometimes that work starts before the agent writes anything. You read the current implementation, map the dependencies, identify edge cases, and make a plan. By the time the first implementation exists, you already understand what it should do and where it could go wrong.
Other times, the generated code itself needs most of your attention. You inspect the error handling, permissions, data access, performance, accessibility, and tests.
AI moves the effort around. It does not make the work disappear.
The actual skill is knowing where the risk lives.
Hot take #2: “Companies will not hire you if you do not use AI”
The reality is a little more nuanced. More teams are asking candidates how they use AI. That makes sense. These tools are becoming part of software development.
But no one thinks every developer needs the same workflow, the same tools, or the same level of enthusiasm.
The stronger signal is judgment.
Can you explain when you use AI and when you work manually? Can you describe how you review generated code? Can you talk honestly about speed, quality, security, and maintainability? Can you change your process as the tools change?
If a company is building AI products or uses AI heavily in its engineering workflow, refusing to touch AI may make you a bad fit. That is not controversial. But total dependence and total refusal are rarely good answers.
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 are closer to packaged expertise. A skill can explain how a team works, how a project should be changed, how a tool should be used, or which conventions matter. Since skills are often written in Markdown, people can read them too. That readability is part of their value.
MCP can provide access. Skills can explain how to use that access well.
You do not need to pick a winner. Use standards for shared interfaces. Use skills for context, process, and best practices.
The combination is much more interesting than the argument.
Hot take #4: “RAG is dead”
RAG is not dead. It is just not the newest thing people want to post about.
Retrieval-augmented generation gives an AI system relevant information outside the model’s training data. That can include documentation, support history, product details, internal knowledge, or codebase context.
Without good retrieval, the model has to rely on what it already knows or spend extra time searching for context. That wastes tokens, slows down the work, and makes incomplete answers more likely.
Good retrieval helps the model start closer to the answer. It narrows the search space and grounds the response in information that actually matters.
Agents, skills, MCP, and RAG can all exist in the same workflow. An agent might use MCP to access a tool, follow a skill for project-specific instructions, and use retrieval to find the right supporting context.
These things are not fighting each other. Treating them like they are misses how people actually build with AI.
Hot take #5: “If you need to fine-tune a model for your codebase, your code is bad”
There are valid reasons to fine-tune a model. Still, modern models have seen a huge number of common frameworks, patterns, naming conventions, and architectures. If a model cannot make sense of your codebase, there is a decent chance a new teammate will struggle too.
AI is becoming another pressure test for maintainability, alongside code review, testing, onboarding, and the poor person debugging this six months from now.
Clear structure helps. Consistent naming helps. Readable tests, useful abstractions, and current documentation help.
Those things make a codebase easier for an agent to understand, but more importantly, they make it easier for a person to review, debug, and extend.
AI-assisted development rewards codebases that make their intent obvious.
That is a good thing.
Real work is more interesting than the debate
AI will keep producing strong opinions because the tools are changing quickly, and we are all still figuring out our workflows.
You do not need to pick a permanent side in every debate.
The better response to an interesting take is not another take. Test the idea. Build something. Document what happened. Give everyone something real to learn from.
Pollinations AI is doing that by experimenting with a generative AI platform where contributors can earn credits, called pollen, by improving the project. People can open and solve issues, contribute models, and complete quests. The project raises real questions about incentives, quality, scale, and what open source contribution could look like when AI lowers the barrier to participation.
Avian Visitors is doing it in a completely different way. It is a build log for a bird-listening e-ink display that turns birds visiting an apartment balcony into changing wall art. It combines a microphone, Raspberry Pi, e-ink screen, 3D-printed parts, generated bird images, and thoughtful documentation.
These projects do not settle every AI debate. They do something more useful: they create evidence, expose tradeoffs, and give other people a place to start.
Read enough code to own the result. Build enough AI fluency to explain how you work. Use MCP when a standard interface helps. Use skills when context and process matter. Keep RAG when grounded information makes the system better. If your code confuses both people and models, treat that as a maintainability problem.
Most importantly, do something with what you learn.
Subscribe to the GitHub Podcast so you never miss an episode!
Written by
GPS is a Senior Developer Experience Advocate at GitHub. She helps make GitHub better for developers through community conversations, conference talks, hands-on workshops, useful demos, and a healthy number of memes. In her free time, she builds popular cloud engineering courseware at learntocloud.guide.