该读代码吗？RAG 已死？Skills 干掉了 MCP？

热门观点往往把复杂议题浓缩成一句斩钉截铁的结论。这很能吸引眼球，却未必有助于真正理解。

从表面看，这些观点似乎无关紧要：你赞同、反对、转发，争论几分钟后便继续前行。有时这种看法方向大致正确，有时则纯属无稽之谈。

热门观点的价值在于，当你不再只是被动反应，而是开始拆解它们时。在什么条件下它才成立？还缺少哪些背景信息？它基于哪些假设？

应用到实际工作中又会发生怎样的变化？

真正的深度就藏在这里。一个好的热门观点会提供一个足够犀利的切入点，让你去质疑；而那些问题，正是孕育有用洞见的源泉。

在GitHub播客的最新一期节目中，我们将深入探讨这一切，以及更多内容。

还没准备好深入吗？以下是我们在节目中讨论过的几种常见AI热门观点，以及我们能从中获得的启示。

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

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

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

生产环境中的认证重构，其审查流程理应不同于一次CSS实验。维护了十年的代码库，会让你的直觉与今天刚接手的代码库大相径庭。假装每一次改动都承担同样的风险，并不是严谨，只是浪费时间。

一条简单的原则：审查到你能解释并为结果负责为止。

有时，这项工作甚至在AI开始生成之前就已经展开。你会先阅读现有实现，梳理依赖关系，识别边界情况，并制定计划。等到第一版实现出现时，你已经清楚它该做什么、可能出错在哪里。

另一些时候，生成的代码本身才是关注的重点。你需要仔细检查错误处理、权限控制、数据访问、性能、可访问性以及测试用例。

AI只是重新分配了工作重心，并不会让工作凭空消失。

真正的关键在于，知道风险究竟藏在哪里。

热门观点二：“如果你不使用AI，公司就不会录用你”

现实要微妙得多。越来越多的团队会在面试中询问候选人如何使用AI，这很合理——毕竟这些工具正逐渐融入软件开发流程。

但没人认为每个开发者都需要完全相同的流程、工具，或同样高的热情。

更关键的是判断力。

你能说明何时使用AI、何时手动编码吗？能否描述如何审查AI生成的代码？能否坦诚地谈论速度、质量、安全性与可维护性？当工具迭代时，你是否能及时调整自己的工作方式？

如果一家公司在开发AI产品，或者在工程流程中大量使用AI，那么拒绝接触AI可能会让你显得不太合适——这点无可争议。但一味依赖或彻底排斥，都不是好答案。

更好的做法是清晰地阐述自己的工作方式，明确信任工具的部分，以及自己始终参与的关键环节。

这种熟练度正逐渐成为专业技能的一部分。

热门观点三：“Skills杀死了MCP”

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

模型上下文协议（MCP）为智能体提供了一种连接工具与数据的标准化方式。当需要系统间可靠协作时，这种标准至关重要。智能体需要结构化的途径来调用工具、获取上下文并采取行动。

而“Skills”更像是封装好的专业知识。它可以解释团队的工作方式、项目的改进建议、工具的使用方法，或哪些规范最为重要。由于Skills通常以Markdown格式编写，人类也能轻松阅读——这种可读性正是其价值所在。

MCP提供接入能力，而Skills则指导如何高效利用这种接入。

不必非得分出胜负。用标准来构建共享接口，用Skills来传递上下文、流程与最佳实践。

两者的结合远比彼此对立更有意义。

热门观点四：“RAG已死”

RAG并未消亡，只是不再是当下最热门的话题。

检索增强生成（RAG）为AI系统提供了模型训练数据之外的相关信息，包括文档、支持记录、产品细节、内部知识库，乃至代码库上下文。

如果没有良好的检索机制，模型只能依赖自身已知的知识，或花费额外时间寻找上下文，这既浪费计算资源，又拖慢效率，还容易导致回答不完整。

优质的检索能让模型更接近答案，缩小搜索范围，并将回应锚定在真正相关的信息上。

智能体、Skills、MCP与RAG完全可以共存于同一工作流中。一个智能体可能通过MCP调用工具，遵循特定项目的Skill指引，并借助检索找到合适的辅助信息。

这些技术并非相互对立，视它们为敌人反而会错过AI的实际应用之道。

热门观点五：“如果你必须为自己的代码库微调模型，那说明你的代码写得很糟”

确实存在正当理由需要微调模型。不过，现代大模型已经见过海量常见的框架、模式、命名习惯与架构。如果模型都无法理解你的代码库，那么新加入的同事也很可能面临同样的困难。

AI正成为继代码评审、测试、新人培训，以及半年后那位可怜的调试者之后，又一项关于可维护性的压力测试。

清晰的结构有帮助，一致的命名有帮助，易读的测试、合理的抽象与及时的文档也同样重要。

这些因素不仅让智能体更容易理解代码，更重要的是，也让人类更便于审查、调试与扩展。

AI辅助开发青睐那些意图清晰的代码库。

这是件好事。

真实的工作远比争论有趣

AI领域总会不断涌现各种鲜明的观点，因为工具更新迅速，而我们仍在摸索各自的工作方式。

你无需在每次争论中都选边站。

面对有趣的见解，最好的回应不是再抛出另一个观点，而是去验证它、动手实践、记录过程，为所有人提供可借鉴的真实经验。

授粉人工智能正在这样做：他们试验了一个生成式AI平台，贡献者可以通过改进项目赚取名为“花粉”的积分。人们可以打开并解决各类问题，贡献模型，完成任务。

该项目引发了关于激励机制、质量、规模，以及当AI降低参与门槛时，开源贡献可能呈现何种形态等切实的问题。

鸟类访客则选择了完全不同的路径。它是一个关于一款鸟类监测电子墨水屏的建造日志：这款设备将光临公寓阳台的鸟儿转化为不断变换的墙面艺术。

它集成了麦克风、树莓派、电子墨水屏、3D打印部件、由AI生成的鸟类图像，以及详尽的文档说明。

这些项目并未解决所有关于AI的争论，但它们做了更有用的事：创造证据、揭示权衡，并为他人提供一个起点。

阅读足够的代码，以便对结果负责；培养足够的AI素养，能够清晰阐述自己的工作方式；在需要标准化接口时使用MCP；在注重上下文与流程时采用Skills；当扎实的信息能提升系统表现时，坚持RAG；如果你的代码连人和模型都感到困惑，那就把它当作可维护性问题来对待。

最重要的是，把学到的东西付诸实践。

订阅GitHub播客，不错过任何一期！