AI 生成代码需审查，责任仍在开发者身上

论坛里关于 AI 编程的讨论，总能看到两种截然不同的立场。乐观派相信 AI 能把编码任务全部接管，只要点一下“接受”按钮即可；技术焦虑派则担心每当出现新协议或新功能时，旧有架构就会被迫重写。拆开来看，这两种声音的价值不在于谁对谁错，而在于弄清技术适用的边界，以及在落地时需要采取的具体措施。以下结合常见的工程实践，对几个核心争议点进行展开。

读 AI 生成的代码是一场风险管理的对弈

有人宣称“AI 编程不需要读代码”，其实是一种误读。代码无论如何生成，最终都会在生产环境中运行；系统崩溃、数据泄露或安全漏洞出现时，承担责任的仍是提交代码的开发者，而不是提供生成能力的模型。审阅代码并不等同于逐行比对，每行都像审合同那样死抠，否则效率会急剧下降。合理的做法是依据风险等级动态分配注意力。

举例来说，在前端 CSS 样式实验或内部小工具的开发阶段，AI 给出的方案只需快速扫视，确认视觉效果符合预期，即可直接提交。相反，涉及生产环境的身份验证逻辑或核心资金结算模块时，必须切换到“严谨模式”。一个维护了十年的老项目与一个刚启动、结构清晰的新项目，对 AI 生成代码的直觉判断标准截然不同。把所有变更视为同等风险，只会导致时间浪费，而非风险管控。

实务上，审核的底线是：在出现 Bug 时，开发者能够完整解释代码逻辑并快速定位根因。这种“审核”往往在 AI 产生代码之前就已经完成。资深开发者在让 AI 生成方案前，会先通读现有实现，梳理复杂依赖，预判边缘情况并制定验证计划。这样，当 AI 把方案提交时，能够一眼辨别出哪部分符合预期，哪部分仍需人工纠正。

重点已经转移：不必在“敲键盘”上投入大量时间，但必须在错误处理、权限控制、数据访问效率、性能损耗以及可访问性上投入更多精力。AI 把体力活转移为审查活，工作量没有消失，核心竞争力变成对风险点的把控能力。

雇主关注的不是工具的使用频次，而是判断力

当前不少面试会问：“你是怎么用 AI 辅助开发的？”这类问题已经成为常规，因为 AI 已经渗透到现代开发流程，类似当年 IDE 取代记事本的过程。某些开发者误以为，展示使用了多少 AI 工具或表现出对 AI 的狂热就能获得高分。事实上，企业并不要求每位开发者使用同一套工作流，也不要求对 AI 产生特定的崇拜。面试官真正想探查的是候选人的 Judgment（判断力）。

他们关注的点包括：在何种场景下信任 AI，何种场景下坚持手动编写；在审查 AI 生成代码时，检查清单里包含哪些维度；对于执行速度、运行质量、安全性以及长期可维护性，是否进行了诚实思考，而不是仅仅追求“能跑通”。如果应聘的公司深耕 AI 产品，工程流高度依赖 AI 自动化，而候选人坚持纯手动模式且拒绝接触，那么匹配度自然会下降。但同样，完全依赖 AI 或完全排斥 AI 都不是最佳答案。最高级的状态是，能够流畅且专业地描述工作方式：哪些环节信任工具提升效率，哪些环节必须亲自把关。对工具的掌控感以及在“效率”与“质量”之间找到平衡的能力，正成为现代工程师的基本功。

MCP 与 Skills 是否构成竞争关系

社区最近出现争论，称 Skills 出现后，MCP（Model Context Protocol）会被淘汰。实际上，两者解决的是完全不同的层面。MCP 提供一套标准化协议，核心目的是让 Agent 能以统一方式连接各种工具和数据源。此类标准化在系统间可靠协作时至关重要。如果每个工具接口都各异，Agent 每次都要重新学习调用方式，效率会大幅下降。Agent 需要结构化方式来调用工具、获取上下文并执行动作，MCP 正是为此提供基础设施的。官方说明 对此有详细阐述。

Skills 则更侧重于定义“封装好的专业经验”。一个 Skill 可以描述团队内部协作方式、项目修改规范、工具组合使用指南，或关键约定。通常使用 Markdown 编写，既能让 AI 读取，也方便人类阅读，这种可读性是其核心价值。简言之，MCP 解决“如何访问”（通道问题），Skills 解决“如何高效使用这些访问权限”（方法论问题）。

两者不必二选一。理想的架构是：利用 MCP 的标准接口实现数据共享和工具互通，同时借助 Skills 传递上下文、业务流程和最佳实践。如此组合，AI Agent 能像懂业务的资深同事，而非仅会调用 API 的机器人。

RAG 是否已成过去式的思考

关于 RAG（retrieval‑augmented generation），最近有声音认为，长上下文窗口的出现会使 RAG 失效。尽管窗口大小在提升，但在企业级应用中，RAG 仍是解决大模型幻觉和获取实时数据的核心手段。企业内部私有数据量大、更新频率快，单纯依赖上下文窗口或微调难以低成本实现实时、准确的返回。实际工程实践表明，RAG 仍是确保 AI 输出准确性、实时性的基石。

技术名词的更迭不应成为节奏的主导。无论是 AI 生成代码、MCP 还是 RAG，它们都只是工具。工具的价值不在于本身，而在于如何定义风险、如何运用判断力，以及如何组合这些工具解决真实业务问题。

通过上述几个维度的展开，能够看到技术本身并非决定因素，关键在于使用者对风险的认知、对流程的把控以及对工具的合理组合。只有在这些层面达成共识，AI 才能真正成为提升研发效率的可靠伙伴，而不是潜在的风险源。