GitHub Blog 上的一篇文章讨论了关于在软件开发中使用人工智能的五个流行假设，其中包括生成的代码不需要阅读、RAG 已经终结，以及 Skills 已经取代了 Model Context Protocol（MCP）。作者认为，这些说法的价值不在于其简短表述是否正确，而在于将它们应用于实际工作时，拆解其成立条件和边界。
代码责任不会转移给模型
文章提出的基本原则是，开发者应当审查代码，直到自己能够解释结果并对此承担责任。这并不意味着需要以同样的深度检查每一行代码；生产环境中的身份验证系统变更，与简单的 CSS 实验应当接受不同的审查。
审查可能在代理编写任何代码之前就开始，包括了解当前实现、确定依赖关系和边界情况，以及制定计划。在其他情况下，生成的代码则需要直接检查错误处理、权限、数据访问、性能、可访问性和测试。文章认为，人工智能改变了工作投入的位置，但并没有消除工作本身。
最重要的技能是良好的判断力
文章反驳了“完全不使用人工智能的人将不会被公司雇用”这一观点，但也承认，越来越多的工作团队会询问候选人如何使用这些工具。根据文章的观点，最有力的信号并不是对工具本身的热情，而是开发者能否解释何时使用工具、何时手动工作，如何审查工具的输出，以及如何在速度、质量、安全性和可维护性之间取得平衡。
在一家构建人工智能产品或高度依赖人工智能的公司中，避免使用人工智能可能成为障碍，但完全依赖人工智能并不是更好的解决方案。需要做的是让人始终处于闭环之中，并清楚解释开发者信任什么、不信任什么。
MCP、Skills 和 RAG 各司其职、相互补充
文章区分了这三种工具。MCP 为代理访问和调用工具与数据提供了标准化方式，而 Skills 则提供了围绕团队工作方式、项目修改规则或既定约定打包的知识。由于 Skills 通常以 Markdown 格式编写，其可读性也是其价值的一部分。
RAG，即检索增强生成，则将与任务相关、位于模型训练数据之外的信息带入系统，例如文档、支持记录、产品详情、内部知识和代码库上下文。良好的检索能够帮助模型从更接近答案的上下文开始工作，同时缩小搜索范围，并降低给出不完整回答的可能性。
因此，作者并不认为 Skills 杀死了 MCP，也不认为 RAG 已经消亡；代理可以使用 MCP 访问工具，遵循 Skill 应用项目特定的指令，并借助检索获取支持性上下文。这些组件之间的争论忽视了它们可以在同一工作流中相互配合的方式。
可维护性面临新的考验
文章还讨论了这样一种观点：需要针对特定代码库训练模型，必然意味着代码质量很差。定制训练有其正当原因，但模型无法理解代码库，也可能暴露出一个新同事同样会遇到的问题。
清晰的结构、一致的命名、可读的测试、有用的抽象以及及时更新的文档，会让代码更容易被代理和人类共同理解。这里的编辑性解读是，人工智能工具并不能让团队免于遵循软件工程实践；相反，它们可能会让可维护性方面的缺陷更加明显。
从讨论走向实验
文章最后呼吁实际测试各种观点，而不是用一个相反的观点替代另一个观点。文章引用了 Pollinations AI 项目，贡献者可以通过改进项目赚取名为 pollen 的积分；还引用了 Avian Visitors 项目，该项目记录了一种电子墨水屏：它使用麦克风、Raspberry Pi、3D 打印组件和生成的图像聆听鸟类，并将鸟类的到访转化为不断变化的画面。
这些项目无法解决关于人工智能的所有争论，但能够产生证据并揭示各种权衡。本文的主要限制在于，它提供的是一般性的指导框架和示例，而不是证明某一特定工作流更优越的对比测量结果。因此，应将其建议视为实践中的测试点，而不是最终规则。