你该不该读代码？RAG 已经死了吗？Skills 真把 MCP 干掉了吗？
热门观点（hot take）把复杂话题浓缩成一句自信满满的断言。这样容易引发互动，却未必有助于理解。
这类观点在表面上其实无关紧要——你同意、反对、转发，争论几分钟，然后翻篇。它有时大方向是对的，有时纯属胡说。热门观点的价值，在于你不再跟着情绪走、开始动手拆解它的时候：它在什么条件下成立？缺了哪些背景？默认了哪些假设？用到实际工作中又会发生什么变化？深度就藏在这些追问里。好的热门观点会给你一个足够锋利、值得追问的靶子，而真正有用的想法，往往就在这些追问中浮现。
我们在最新一期 GitHub Podcast 里聊了这些，还有更多内容。还没准备好收听？下面是我们讨论过的几个常见 AI 热门观点，以及它们能带给我们什么。
热门观点一：“你不需要读 AI 生成的代码”
恰恰需要。代码出了问题，责任还是你的。但这不意味着每一行生成的代码都要同等关注。
生产环境的认证重构和一次 CSS 小实验，审查流程本来就不该一样。维护了十年的代码库，和今早刚打开的代码库，也会引导你做出不同的直觉判断。假装每个改动的风险都相同，这不是严谨，只是浪费时间。
有个简单原则：审查到你能够解释并担起结果为止。
有时这项工作在智能体（agent）写下任何代码之前就开始了。你先读现有实现，梳理依赖关系，找出边界情况，再制定方案。等第一版实现出来时，你已经清楚它该做什么、可能在哪里出错。另一些时候，注意力主要得放在生成的代码本身：检查错误处理、权限、数据访问、性能、无障碍支持和测试。
AI 只是把精力挪了地方，活并不会消失。真正的本事，是知道风险藏在哪里。
热门观点二：“不用 AI 就没人雇你”
现实要更微妙一些。越来越多团队会问候选人如何使用 AI。这很合理。
这些工具正在成为软件开发的一部分。但没人认为每个开发者都需要相同的工作流程、相同的工具，或者相同的热情程度。更重要的信号是判断力。你能说清楚什么时候用 AI、什么时候手动干活吗？你能描述自己怎么审查生成的代码吗？你能坦诚地聊速度、质量、安全和可维护性吗？工具变了，你能跟着调整流程吗？如果一家公司在做 AI 产品，或者工程流程中大量使用 AI，而你拒绝碰 AI，那可能确实不太合适。这没什么争议。但完全依赖和完全拒绝，通常都不是好答案。更好的做法是清楚地说明你怎么工作、你信任工具做什么、以及你在哪些环节保持自己的参与。这种熟练度正在成为这门手艺的一部分。
热门观点 3：“Skills 杀死了 MCP”
不是。它们解决的是不同问题。
模型上下文协议（MCP）给智能体提供了一种标准方式，去连接工具和数据。当你希望系统之间可靠地协作时，这种标准很重要。智能体需要结构化的方式来调用工具、获取上下文、执行操作。
Skills 更接近打包好的专业知识。一个 skill 可以说明团队怎么运作、项目该怎么改、工具该怎么用、哪些约定重要。由于 skills 通常用 Markdown 写，人也能直接阅读。这种可读性本身就是价值的一部分。
MCP 提供访问能力。Skills 解释如何用好这种访问能力。你不需要二选一。共享接口用标准，上下文、流程和最佳实践用 skills。两者结合比争论谁赢有意思得多。
热门观点 4：“RAG 已死”
RAG 没死。它只是不再是人们最想发帖讨论的新鲜事了。
检索增强生成（RAG）让 AI 系统获取模型训练数据之外的相关信息。这些信息可以包括文档、支持历史、产品详情、内部知识或代码库上下文。没有好的检索，模型就只能依赖已知的东西，或者花额外时间去搜索上下文。这会浪费 token、拖慢速度，也更容易给出不完整的答案。
好的检索能让模型起步时更接近答案。它缩小了搜索范围，让回答落在真正相关的信息上。智能体、技能、MCP 和 RAG 完全可以共存于同一套工作流里。一个智能体可以用 MCP 去调用工具，按照技能里写的项目专属说明来操作，再用检索找到合适的支撑上下文。这些东西并不互相打架，把它们当成对立面，反而忽略了人们实际是怎么用 AI 干活的。
争议观点 #5：“如果你需要针对代码库微调模型，那说明你的代码很糟”
微调模型确实有正当理由。不过话说回来，现代模型见过大量常见的框架、模式、命名习惯和架构。如果模型都看不懂你的代码库，那大概率新来的同事也会一头雾水。AI 正在成为可维护性的又一道压力测试，和代码评审、测试、新人上手，以及六个月后那个倒霉的调试者并列。清晰的结构有帮助，一致的命名有帮助，可读的测试、有用的抽象、跟得上进度的文档，都有帮助。这些能让智能体更容易理解代码库，但更重要的是，它们让人更容易评审、调试和扩展。AI 辅助开发会奖励那些把意图表达得明明白白的代码库，这是好事。
真正动手，比争论有意思得多
AI 还会不断冒出各种强烈观点，因为工具变化太快，我们也都还在摸索自己的工作流。你不需要在每场辩论里都选一个永久立场。面对一个有意思的观点，更好的回应不是再抛一个观点，而是去验证它。动手做点东西出来，把结果记录下来，给大家一些真正能学的东西。
Pollinations AI 就是这么做的：他们试验了一个生成式 AI 平台，贡献者通过改进项目来赚取名为 pollen 的积分。人们可以提 issue 并解决 issue、贡献模型、完成任务。这个项目提出了一些很实在的问题——关于激励机制、质量、规模，以及当 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 上。