作者：GPS

排版：Alan Wang

在最新一期 GitHub Podcast 中，我们围绕这些 AI 热门观点以及更多 AI 话题展开了深入讨论。

热门观点会把复杂的话题浓缩成一句听起来非常笃定的话。因此，它们非常适合引发互动，却未必有助于真正理解问题。

从表面上看，它们并没有那么重要。你赞同、反对、转发、争论几分钟，然后继续做自己的事。有时候，这个观点方向上是对的；有时候，它完全就是无稽之谈。

热门观点真正的价值，在于当你停止“下意识反应”，开始拆解它的时候。它在什么条件下成立？缺少了哪些背景？它建立了哪些假设？当你把它应用到真实工作中，又会发生哪些变化？

真正的深度就在这里。一个好的热门观点，会提供一个足够尖锐、值得质疑的论断。而这些问题，正是你找到有价值想法的地方。

我们在最新一期 GitHub Podcast 中深入探讨了这些话题，以及更多 AI 热门观点。这里先看看我们讨论的几个常见 AI 热门观点，以及我们能从中获得什么启发。

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

需要，你当然需要。因为最终对代码负责的人仍然是你。

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

一次生产环境中的身份认证重构，与一次 CSS 样式实验，理应采用不同的代码审查流程。一个你维护了 10 年的代码库，与你今天早上刚打开的代码库，会引导你做出完全不同的判断。假装每一次代码变更都承担着同样的风险，并不是严谨，而只是低效地使用时间。

一个简单的原则：一直审查，直到你能够解释它，并愿意为结果负责。

有时候，这项工作甚至开始于智能体写下第一行代码之前。你会阅读当前实现、梳理依赖关系、识别边界情况，并制定实现方案。等第一版代码生成时，你已经知道它应该完成什么，以及最有可能出错的地方。

而另一些时候，你的大部分注意力应该放在 AI 生成的代码本身。你需要检查错误处理、权限控制、数据访问、性能、可访问性，以及测试。

AI 改变的是工作的重心，而不是让工作消失。

真正重要的能力，是知道风险在哪里。

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

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

但没有人认为，每一位开发者都必须拥有相同的工作流、使用相同的工具，或者对 AI 保持同样程度的热情。

真正更重要的信号，是判断力。

你能否解释什么时候使用 AI，什么时候选择手动完成？你能否描述自己如何审查 AI 生成的代码？你能否坦诚讨论速度、质量、安全性和可维护性之间的权衡？随着工具不断变化，你能否调整自己的工作方式？

如果一家公司的产品本身就是 AI 产品，或者其工程工作流高度依赖 AI，那么完全拒绝接触 AI，确实可能意味着你并不适合这个岗位。这一点并不具有争议。但完全依赖 AI，和完全拒绝 AI，通常都不是好的答案。

更好的答案，是清楚说明你的工作方式：哪些事情交给 AI，哪些事情由你亲自把关，以及你如何始终参与整个流程。

这种熟练程度，正在成为开发者职业技能的一部分。

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

没有。它们解决的是不同的问题。

Model Context Protocol（MCP） 为智能体提供了一种连接工具和数据的标准方式。当你希望不同系统能够可靠地协同工作时，这种标准就非常重要。智能体需要结构化的方式来调用工具、获取上下文，并执行操作。

Skills 更接近于封装好的专业经验。一个 Skill 可以说明团队如何协作、项目应该如何修改、工具应该如何使用，以及哪些约定和规范最重要。由于 Skills 通常使用 Markdown 编写，人类也能够阅读它们，而这种可读性正是 Skills 的一部分价值。

MCP 提供访问能力。Skills 则解释如何正确使用这种访问能力。

你不需要在两者之间选出赢家。使用标准来构建共享接口；使用 Skills 来沉淀上下文、流程和最佳实践。

两者结合，远比“谁取代谁”的争论更有意思。

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

RAG 并没有死。它只是已经不是大家最喜欢发布的新热点了。

检索增强生成（Retrieval-Augmented Generation，RAG） 为 AI 系统提供模型训练数据之外的相关信息。这些信息可以来自文档、支持记录、产品信息、企业内部知识，或者代码库上下文。

如果没有良好的检索能力，模型只能依赖自己已经知道的内容，或者花费额外时间搜索上下文。这不仅会浪费 Token，还会拖慢工作速度，并提高生成不完整答案的可能性。

好的检索能够帮助模型从距离答案更近的位置开始推理。它缩小了搜索空间，并让回答建立在真正相关的信息之上。

智能体、Skills、MCP 和 RAG 完全可以存在于同一个工作流中。一个智能体可以通过 MCP 调用工具，遵循某个 Skill 中定义的项目规范，再通过检索获取正确的上下文信息。

这些能力之间并不是相互竞争的。把它们看成彼此对立，恰恰忽略了人们真实构建 AI 应用的方式。

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

微调模型有很多合理的理由。不过，如今的大模型已经学习了大量常见框架、设计模式、命名规范和系统架构。如果模型都无法理解你的代码库，那么新加入团队的一位开发者，很可能也会遇到同样的问题。

AI 正在成为可维护性的又一次压力测试，与代码审查、自动化测试、新人入职，以及半年后负责调试这段代码的人一样。

清晰的代码结构很重要。一致的命名规范很重要。易读的测试、合理的抽象，以及保持最新的文档，同样很重要。

这些实践会让代码库更容易被智能体理解，但更重要的是，它们也会让人更容易阅读、调试和扩展代码。

AI 辅助开发，更青睐那些能够清晰表达设计意图的代码库。

这是一件好事。

真正的实践，比争论更有意思

AI 领域还会不断出现各种鲜明的观点，因为工具变化得太快，而我们每个人也都还在摸索自己的工作方式。

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

面对一个有趣的观点，更好的回应不是抛出另一个观点，而是去验证它。测试这个想法，构建一些东西，记录发生了什么，并让其他人能够从真实结果中学习。

Pollinations AI 正在这样做。它尝试构建一个生成式 AI 平台，贡献者可以通过改进项目获得一种名为 pollen 的积分。人们可以创建并解决 Issue、贡献模型、完成 Quest。这个项目提出了一些真实的问题：如何设计激励机制、如何保证质量、如何实现规模化，以及当 AI 降低了参与门槛之后，开源贡献会变成什么样子。

Avian Visitors 则采用了完全不同的方式。它记录了一个能够“聆听鸟鸣”的电子墨水屏项目，将公寓阳台上出现的鸟类变成不断变化的墙面艺术。项目结合了麦克风、Raspberry Pi、电子墨水屏、3D 打印部件、AI 生成的鸟类图像，以及完整而细致的项目文档。

这些项目并没有终结所有关于 AI 的争论。它们做了一件更有价值的事情：提供证据，展示权衡，并为其他人提供一个开始实践的起点。

阅读足够多的代码，直到你能够为结果负责。培养足够的 AI 素养，能够解释自己的工作方式。当标准接口能够带来价值时，就使用 MCP。当上下文、流程和最佳实践很重要时，就使用 Skills。当真实信息能够让系统变得更好时，就继续使用 RAG。如果你的代码同时让人和模型都感到困惑，就把它视为一个可维护性问题。

最重要的是，把你学到的东西真正用起来。

订阅 GitHub Podcast，不错过每一期节目。