AI 写的代码不读就上线，责任还是在你自己

最近在论坛里看到很多关于 AI 编程的讨论，我发现大家很容易陷入两种极端的思维陷阱：一种是极端的“乐观派”，觉得 AI 已经进化到可以完全接管编码，人类只需要点个“接受”按钮就行；另一种是极端的“技术焦虑派”，觉得只要出了个新协议或新功能，之前的架构就得全部推翻重来。

其实，把这些所谓的“激进观点”拆解开来看，你会发现真正的价值并不在于争论谁赢了，而在于弄清楚这些技术在什么具体的场景下成立，以及在实际的工程落地中到底怎么操作。今天我想结合自己的经验，把这几个争议点详细聊聊。

读 AI 生成的代码，本质上是一场风险管理

现在很多声音在鼓吹“AI 编程不需要读代码了”，这在某种程度上是一个巨大的误区。我们要意识到一个最基本的事实：代码最终是跑在生产环境里的，而当系统崩溃、数据丢失或者出现安全漏洞时，承担责任的依然是那个提交代码的开发者，而不是那个提供 API 的模型。

但这里有一个关键的认知偏差，很多人认为“读代码”意味着每一行都要像审合同一样死磕，这确实太低效了。正确的做法应该是：根据风险等级，动态分配你的注意力。

举个例子，如果你现在是在做一个前端页面的 CSS 样式实验，或者写一个简单的内部小工具，AI 给出方案后，你随便扫一眼，确认视觉效果没问题，直接上线也无妨。但如果你是在重构生产环境的身份验证逻辑（Authentication Logic），或者在处理核心的资金结算模块，那么你必须进入“严谨模式”。

这里有一个很重要的对比：一个维护了 10 年、充满了历史包袱的老项目，和一个今天刚打开、结构清晰的新项目，你对 AI 生成代码的直觉判断标准应该是完全不同的。如果你把所有变更都当成同等风险对待，那不叫严谨，那叫浪费时间。

我给大家一个实操建议：审核代码的底线应该是——直到你能完全解释清楚这段代码的逻辑，并且在它出 Bug 时能够迅速定位并为结果负责。

而且，我想提醒大家，这种“审核”其实很多时候发生在 AI 写代码之前。一个资深的开发者在让 AI 生成代码前，会先花时间读一遍现有的实现，理清复杂的依赖关系，预判潜在的边缘情况（Edge Cases）并制定好实施计划。这样当 AI 给出方案时，你一眼就能看出它哪里写对了，哪里在一本正经地胡说八道。

现在的重点已经发生了转移：你不需要在“打字”上花时间，但你必须在检查错误处理、权限控制、数据访问效率、性能损耗以及可访问性（Accessibility）上花更多精力。AI 只是把你的精力从“体力活”转移到了“审查活”上，工作量并没有消失，真正的核心竞争力已经变成了你对风险点的把控能力。

雇主现在看重的，不是你会不会用 AI，而是你的判断力

现在很多面试环节都会问候选人：“你是怎么使用 AI 辅助开发的？”这很正常，因为 AI 已经成了现代开发流程的一部分，就像当年大家开始用 IDE 代替记事本一样。但很多开发者误以为，只要展示自己用了多少 AI 工具，或者表现出对 AI 的狂热，就能拿到高分。

其实，公司并不要求每个开发者都用同一套工作流，也不要求你对 AI 展现出某种特定的崇拜。面试官真正想挖掘的是你的 Judgment（判断力）。

他们想看的是：你能不能清晰地解释在什么场景下应该信任 AI，而在什么场景下必须坚持手动编写？当你审核 AI 生成的代码时，你的检查清单（Checklist）里包含什么？对于代码的执行速度、运行质量、安全性以及长期的可维护性，你是否有过诚实的思考，还是仅仅追求一个“能跑通”的结果？

当然，这里存在一种匹配问题。如果你申请的公司本身就在深耕 AI 产品，或者他们的工程流已经高度依赖 AI 自动化，而你依然固守旧有的纯手动模式且拒绝接触，那确实不匹配。但我想说的是，无论是完全依赖 AI 还是完全拒绝 AI，都不是最优解。

最高级的状态是，你能流畅且专业地描述你的工作方式：哪些环节你信任工具的效率，哪些环节你必须介入把关。这种对工具的掌控感，以及在“效率”与“质量”之间寻找平衡的能力，正在成为现代工程师的基本功。

MCP 和 Skills 之间，真的存在竞争关系吗？

最近社区里有一波争论，说 Skills 出现了，MCP（Model Context Protocol）是不是就被杀死了？其实这种看法把问题简单化了，这两者解决的是完全不同的维度。

我们先看 MCP。Model Context Protocol 提供的是一套标准化的协议，它的核心目的是让 Agent 能够以一种标准化的方式连接到各种工具和数据源。这种标准化在需要系统之间进行可靠协作时至关重要。想象一下，如果每个工具的接口都不同，Agent 每次都要学习一遍怎么调用，那效率太低了。Agent 需要一种结构化的方式来调用工具、获取上下文并执行动作，MCP 解决的就是这个“基础设施”问题。

而 Skills 更多的是在定义“封装好的专业经验”。一个 Skill 可以定义一个团队内部的协作方式、某个特定项目的修改规范、工具的组合使用指南，或者一些关键的约定。最关键的一点是，Skills 通常是用 Markdown 编写的，这意味着它不仅给 AI 看，人类也能读懂。这种可读性正是它的核心价值所在。

简单来说，MCP 解决了“如何访问”的问题（通道问题），而 Skills 解决了“如何高效使用这些访问权限”的问题（方法论问题）。

你完全不需要在两者之间做二选一。最理想的架构应该是：利用 MCP 这种标准接口来实现数据的共享和工具的互通，同时利用 Skills 来传递上下文、业务流程和最佳实践。这两者结合起来，才能真正让 AI Agent 变得像一个懂业务的资深同事，而不是一个只会调用 API 的机器人。

关于 RAG 是否死亡的思考

最后聊聊 RAG（检索增强生成）。虽然最近大家在讨论长上下文窗口（Long Context Window）会让 RAG 失效，但我觉得 RAG 依然是目前解决大模型幻觉和获取实时数据最核心的手段。

虽然讨论的热度在变化，但 RAG 在企业级应用中的实用性依然不可替代。毕竟，企业内部的私有数据量之大，且更新频率之快，单纯依赖上下文窗口或者微调（Fine-tuning）是无法低成本解决的。在实际的工程实践中，RAG 依然是确保 AI 输出准确性、实时性的基石。

总结一下：不要被技术名词的更迭带节奏。无论是 AI 生成代码、MCP 还是 RAG，它们都只是工具。工具的价值不在于它本身，而在于你如何定义风险、如何运用判断力，以及如何将这些工具组合在一起解决实际的业务问题。