该读AI代码吗？RAG已死？Skills取代MCP？

“热观点”把复杂话题压缩成一句笃定的断言。这对提升互动很有用，但不一定有助于真正理解问题。

表面上看，它们无伤大雅。你表示赞同、反驳、转发，吵上几分钟，然后翻篇。有时候观点方向没错，有时候则纯属胡扯。

热观点的价值，在于你停下反应、开始拆解它的那一刻。在什么条件下才成立？缺失了什么背景？它默认了哪些假设？落地到实际工作时会发生什么变化？

深度就在这里。一个出色的热观点，足以让你提出尖锐的追问。而追问之中，才能挖出真正有用的洞见。

在最新一期 GitHub Podcast 中，我们深入探讨了这些话题，还涉及更多内容！

还没准备好深入？以下是我们讨论的几个常见 AI 热观点，以及能从中获得什么。

热观点 1：“你不必阅读 AI 生成的代码”

不，你还是要读。你对代码负有责任。

但这并不意味着每一行生成代码都值得同等程度的审视。

生产环境的认证重构和一段 CSS 实验，需要的审查流程完全不同。你维护了十年的代码库和今早刚打开的新项目，触发的直觉也截然不同。假装所有变更风险等同，那不是严谨，只是浪费时间。

一条简单的原则：审查到你能解释并完全掌控结果为止。

有时这项工作要在 agent 写任何代码之前开始。你先读当前实现，梳理依赖关系，识别边界情况，制定计划。当第一版实现出现时，你已经清楚它该做什么、哪里可能出错。

其他时候，生成代码本身才是你关注的重点。你需要检查错误处理、权限控制、数据访问、性能、可访问性和测试。

AI 只是调整了精力的分配，并没有让工作消失。

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

热观点 2：“不用 AI，公司就不会雇你”

现实比这句话复杂一些。越来越多团队在询问候选人如何使用 AI。这合乎情理。这些工具正在成为软件开发的一部分。

但没人认为每位开发者都该遵循相同的工作流、使用相同的工具，或保持同等程度的热情。

更强的信号是判断力。

你能说明何时用 AI、何时手动操作吗？能描述你如何审查生成的代码吗？能否坦诚讨论速度、质量、安全性与可维护性？当工具变化时，你能随之调整流程吗？

如果公司正在开发 AI 产品，或在工程流程中大量使用 AI，拒绝接触 AI 可能会让你不合群。这点没什么争议。但完全依赖与完全排斥，都很难是好答案。

更好的答案，是清晰说明你如何工作、你信任工具做什么、以及你在哪些环节保持自己在回路中。

这种熟练度，正在成为手艺的一部分。

激进观点 #3：“Skills 杀死 MCP”

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

Model Context Protocol 给智能体提供了一种标准方式去连接工具和数据。当你希望系统可靠协作时，这种标准很重要。智能体需要结构化的方式来调用工具、获取上下文并采取行动。

Skills 更接近打包好的专业知识。一项 Skill 可以说明团队如何工作、项目应如何修改、工具应如何使用，以及哪些约定俗成很重要。由于 Skills 通常用 Markdown 写成，人也能读。这种可读性正是其价值的一部分。

MCP 可以提供访问权限。Skills 可以解释如何善用这种访问。

你不必选一个赢家。用标准来定义共享接口，用 Skills 来承载上下文、流程与最佳实践。

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

激进观点 #4：“RAG 已死”

RAG 没死。它只是不再是人们最爱聊的最新话题。

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

没有好的检索，模型只能靠已有知识，或花额外时间搜索上下文。这会浪费 tokens、拖慢工作，并让答案更容易不完整。

好的检索让模型离答案更近。它缩小了搜索空间，并将回答锚定在真正重要的信息上。

Agent、Skills、MCP 和 RAG 完全可以共存于同一个工作流中：一个 Agent 可以用 MCP 访问工具，按照 Skill 执行项目特定的指令，再用检索找到需要的上下文。 这些东西并不互相冲突。把它们当成对立面，就看不清人们实际是怎么用 AI 构建应用的。

暴论 #5：“如果你的代码库需要微调模型才能读懂，那说明代码写得太烂”

微调模型当然有合理的场景。不过话说回来，现代模型已经见过海量的常见框架、设计模式、命名规范和架构。如果连模型都读不懂你的代码库，新同事大概率也会一头雾水。

AI 正在成为衡量代码可维护性的又一块试金石，和代码评审、测试、新人上手，以及半年后接手 debug 的那个可怜人一样。

清晰的结构有用，一致的命名有用，可读的测试、合理的抽象和及时的文档也都有用。

这些能让 Agent 更容易理解代码库，但更重要的是，它们也让人更容易评审、调试和扩展代码。

AI 辅助开发奖励的是那些把意图表达得清清楚楚的代码库。

这是件好事。

比争论更有意思的是实际工作

AI 领域的暴论还会源源不断地出现，因为工具变化太快，我们都还在摸索自己的工作流。

你不必在每场争论中都选边站。

面对一个有意思的观点，更好的回应不是抛出另一个观点，而是去验证它：动手做点东西，记录下发生了什么，给大家留下真正值得学习的东西。

Pollinations AI 就在这么做：他们试验了一个生成式 AI 平台，贡献者可以通过改进项目来赚取名为 pollen 的积分——提交和解决 issue、贡献模型、完成任务都行。这个项目提出了一些很实际的问题：激励机制、质量、规模，以及当 AI 降低了参与门槛之后，开源贡献会是什么样子。

Avian Visitors 采用了截然不同的思路。这是一份电子墨水屏鸟类监听设备的构建日志，其功能是捕捉来公寓阳台栖息的鸟类，并将这些访客转化为不断变化的墙面艺术。项目融合了麦克风、树莓派、电子墨水屏、3D 打印部件、生成的鸟类图像，以及详尽的文档。

这些项目或许无法终结所有关于 AI 的争论。但它们做了一件更有价值的事：提供实证、揭示权衡取舍，并为后来者搭建起步平台。

多读代码，才能对结果拥有主控权。建立足够的 AI 认知度，以便解释你的工作流程。若标准接口能提升效率，就使用 MCP。若上下文与流程是关键，就使用 skills。若接地气的信息能让系统表现更优，就保留 RAG。如果你的代码既让人类困惑，也让模型难以理解，请将其视为一个可维护性问题。

最重要的是，把你学到的知识落地实践。