#开发者

1个月前
一次又一次的「开发者要被取代了」的炒作潮 作者:Danilo Alonso 从「无代码」到「AI 辅助开发」 每隔几年,总会冒出一种全新的技术,声称可以彻底取代程序员。各种夸张的新闻标题接踵而来,比如「编程的终结」、「人人都能开发App」,甚至还有我最喜欢的一条:「我的孩子五岁还没学会识字,就会写代码了!」 高管们为之振奋,咨询师们像鲨鱼般蜂拥而至,PPT 幻灯片疯狂增长,预算也随之倾斜。 然后,现实终于到来了。 真正发生的并不是取代,而是转型。那些号称能让技术岗位消失的新技术,最终却催生了全新的技术岗位,并且这些新岗位通常薪资更高。无代码(NoCode)运动并未淘汰程序员,而是创造了无代码专家和后台整合工程师。云计算也没有淘汰系统管理员,而是将他们转型为薪水翻倍的 DevOps 工程师。 如今,我们正目睹着同样的现象再次发生在 AI 辅助开发领域。「AI 能为你写全部代码」的承诺,逐渐演变成需要工程师来有效组织和调控 AI 系统。这些人本质上还是原来的工程师,但需要具备新技能,并获得更高的薪酬。 但这一次的转型有更深刻的含义。不同于以往只改变实现方式的技术变革,AI 辅助开发清晰地揭示出软件工程中的一个根本真相: 软件行业中最宝贵的技能不是写代码,而是设计和构建系统的架构。 而这,恰恰是 AI 至今远未能取代的技能。 一再重复的「开发者被取代」神话 回顾一下历史,我们已经经历了多少次类似的「革命」呢?我们一起来数数看: 1. 无代码/低代码革命 还记得那些承诺「让业务人员通过拖拽就能开发 App」的工具吗?当初的说法听起来很动人:「既然人人都能自己搭建应用,为什么还要雇佣昂贵的程序员呢?」 可现实呢?这些工具带来了新的问题:背后的数据模型还是要人来设计,跟已有系统的对接依然复杂,边缘情况无法通过图形化界面解决,维护和升级同样离不开技术人员。 最终,这些工具没减少开发人员,反而催生了一批懂业务又懂技术局限性的「无代码专家」。而且,这些专家的薪资甚至超过了当初被宣称会取代的程序员。 2. 云计算革命 「迁移到云上后,你再也不需要系统管理员了!」 仿佛把服务器托管给别人,就真的不需要管理了似的。实际情况却是,云计算没有消除系统运维的需求,而是改变了运维工作的形态,并极大地拓展了运维工作的范畴。 系统管理员们并没有消失,他们重生为 DevOps 工程师,有了新的高大上的职称和明显更高的收入。工作内容并未消失,而是演变成了基础设施即代码、自动化部署流程和分布式系统管理。 正如我之前在 LinkedIn 关于微服务的帖子中所写:「我看过很多团队花费数月时间将功能完好的单体应用拆成微服务,最后却发现他们只是在用更昂贵的新问题换掉旧问题。」云计算推动了这种复杂性,而处理这种复杂性的人依然是技术专家,只不过工作层次更高了。 3. 海外外包开发潮 「既然可以用更便宜的价格在海外完成开发,为什么还要付高薪请本地的程序员?」 成本大幅降低的承诺,很快碰到了现实的障碍:沟通不畅、质量控制困难,以及开发过程中深度的背景知识和持续的协作需求。 最后出现的方案,是更精细的分工、更清晰的职责界限、更成熟的架构实践,以及——意料之外的——更高的综合成本。 4. AI 编程助手革命 如今又有 AI 出来宣称「只要你描述一下需求,AI 就会自动生成代码!」 但现实很快浮现:AI 写出的代码虽然看起来合理,却经常隐藏着细微的错误和不一致性。资深工程师花费大量时间检查和修正 AI 生成的代码。所谓的「意念编程」(vibe coding)现象表明,经验丰富的开发人员能从 AI 中获得远多于新手的价值。纯靠 AI 搭建的系统,往往缺乏整体性和架构一致性。 > 「在木匠们还在使用凿子的时代,你给木匠们送一台数控机床。你猜谁能做出更好的家具?」 模式再次重演:技术没有取代技能,而是把技能推到了更高的抽象层次。 为什么这次的情况有些不同? 那些认为「AI 将取代程序员」的人,忽略了一个重要事实:代码并不是资产,而是负债。每行代码都需要被维护、调试、安全防护,并最终被替换掉。真正的资产是代码背后的业务能力。 如果 AI 大幅降低了写代码的成本和速度,那其实是在让人们更快、更轻易地制造更多的负债。当负债的产生速度空前提升时,能够战略性地管理、减少这些负债的人才价值也会随之大幅提升。 尤其因为 AI 擅长局部优化,却无法进行整体设计。它能优化单个函数,却无法决定服务是否应该存在,或服务应如何与更广泛的系统协作。当开发速度加快时,架构问题往往会在你意识到之前就已深度植入系统之中。 对于搭建短期使用的营销网站,这可能无伤大雅;但对需要长期演进的系统,这种情况将是灾难性的。 虽然技术转型的模式始终如一——系统管理员变成了 DevOps 工程师,后台开发变成了云架构师——但 AI 正在加速这一过程。而最终留下来的技能,不是写代码。 而是设计和构建系统的架构。这,正是 AI 无法取代的核心能力。 (完)
1个月前
#BestBlogs 一文带你 "看见" MCP 的过程,彻底理解 MCP 的概念 | 阿里云开发者 深度解析 AI 上下文协议(MCP),对比 RAG 与 Function Calling,并通过实践演示理解其工作流程。 摘要: 文章详细介绍了模型上下文协议(MCP),一个旨在标准化 AI 助手与外部系统连接的开放标准。作者首先回顾了 RAG 和 Function Calling 等相关概念,阐述了它们与 MCP 的联系和区别。接着,文章深入讲解了 MCP 的核心组件(主机、客户端、服务器)及客户端-服务器架构,并对比分析了 MCP 相较于传统 API 在动态适应性方面的优势。随后,文章通过 ModelScope 的 MCP 市场和 Cherry Studio 客户端,一步步演示了 MCP 的实际配置和调用过程,通过开发者模式让读者“看见”并理解模型选择工具并请求服务器的数据交互流程。最后,文章总结了 RAG、Function Calling 和 MCP 在借助外部工具增强大模型能力上的共同本质。 主要内容: 1. MCP 是连接 AI 助手与外部数据/工具的开放标准 -- 模型上下文协议(MCP)由 Anthropic 开源,旨在为 AI 模型访问内容、工具提供标准化的“USB-C”式接口,提升 AI 应用的互操作性。 2. MCP 采用客户端-服务器架构,组件包括主机、客户端、服务器 -- 主机提供 AI 交互环境,客户端运行于主机内与 MCP 服务器通信,服务器暴露工具、资源、提示等功能,实现结构化互动。 3. MCP 通过动态能力描述克服传统 API 硬编码问题 -- 客户端能查询服务器当前功能并动态适应,无需硬编码参数变更,提高了 AI 应用与外部系统集成的灵活性和稳定性。 4. RAG、Function Calling、MCP 本质都是增强大模型外部能力 -- 这几种技术殊途同归,都是为了让大模型能够获取外部信息或使用外部工具,以完成更复杂、更准确的任务。 5. 通过开发者工具可“看见”MCP 调用的实际过程 -- 文章通过工具演示,展示了 AI 应用选择 MCP 工具、发送请求、接收结果,并最终由大模型生成回复的完整流程,增强体感理解。 文章链接: