> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # 我确认：AI不会取代开发者 - URL: https://www.hubwiz.com/blog/i-confirm-ai-will-not-replace-developers/ - Published: 2026-05-18T11:01:45.000Z - Updated: 2026-10-13T16:05:07.000Z - Description: 我每天都在使用 AI 工具。我在这里要告诉你："AI 取代开发者"的说法被夸大了——至少夸大了十年。 - Author: admin - Tags: JOB MARKET, #Import 2026-10-14 14:41 每隔几个月，就会有一波新的头条新闻袭来。"AI 将取代程序员。""开发者已过时。""你再也不需要学习编程了。" 每一次，讨论都会爆发——Twitter 帖子、LinkedIn 帖子、YouTube 视频，都在争论软件开发者是否是自动化的下一个牺牲品。 我想提供一个不同的视角。不是防御性的。不是恐慌性的。只是一个来自真正在这个领域工作、每天都在使用这些工具的人的诚实观点。 在开始之前让我说清楚——我不是在故意煽动情绪。我也不是什么拒绝接触 AI 的卢德分子。我确实在不断地使用它：用于编码、文档、学习新技术和加速重复性任务。它让我更快了。它确实有帮助。 然而，在所有这些实际操作经验之后，我仍然认为 AI 距离在任何有意义、广泛的意义上取代软件开发者还有 **10 到 20 年** 的时间。 让我详细说明我为什么这么想。 ## 1、AI 现在到底能做什么 让我们从公正的角度开始。 现在，AI 本质上是一个非常精密的聊天机器人。即使是人们如此兴奋的"代理"，本质上也是在循环中运行的聊天机器人，将响应链接在一起直到得出结果。这不是贬低——这只是对其架构的准确描述。 像 OpenAI 和 Anthropic 这样的公司正在筹集和花费*数十亿*美元来构建这些系统。它们向企业收取数百万美元的订阅费。而所有这些投资的部分原因是一个有些奇怪的动态：你和我每次与这些工具交互时产生的使用数据会被反馈到训练未来更好的模型中。这是一个值得思考的悖论： > AI 还不够好——所以要广泛使用 AI 来让它变得足够好。 我们既是客户，也是训练数据。这就是商业模式。 现在，在这些限制下，AI 做得好的地方确实令人印象深刻。它以极快的速度生成文本。它自信地编写样板代码。它在几秒钟内生成文档、摘要和解释——这些工作以前需要人类花费数小时。这部分非常真实，并且已经在改变我们的工作方式。 但*编写代码*和*理解系统*之间存在有意义的区别。而这正是事情开始出问题的地方。 ## 2、幻觉问题仍然非常真实 我想分享一个我自己工作中的例子，因为抽象的论证只能走这么远。 我的代码库中有一个 API 调用，从后端获取一些数据。没什么不寻常的。我让 **Claude Opus**——被广泛认为是最适合开发任务的模型之一——审查代码并提出改进建议。 以下是它做了什么。 它添加了一个 `distinct` 条件来过滤从后端返回的原始 JSON。这挺合理。但随后，在同一次处理中，它*还*编写了一个完全独立的函数，并创建了一个 HashSet 专门来检查项目列表中是否有重复元素。 问题在于？它**已经**用那个 distinct 条件处理了重复项。两段代码做的是完全相同的事情。AI 没有意识到这两个解决方案是冗余的——它只是继续生成代码，将一个解决方案叠在另一个上面，完全不理解一个已经抵消了另一个。 结果呢？更多的代码。无用的代码。除了呆在代码库中、让未来的开发者困惑、悄悄积累技术债务之外，什么都不做的代码。 这是一个小例子，但我认为它指向了根本性的东西。这也是我希望你从整篇文章中得到的最重要的东西： **AI 擅长编写代码。它不擅长理解你的业务逻辑。** 每个 LLM 的核心都是在大规模数据上训练的模式匹配引擎。这些模式最终是数值表示——令牌之间的统计关系。模型不知道你的系统*为什么*以这种方式构建。它不知道两年前做出的架构决策解释了为什么某个函数存在。它不知道代码库的哪些部分是脆弱的、哪些是承重的、以及*不应该*碰什么。 它看到代码。它生成代码。但它不*理解*软件。 ## 3、上下文长度问题 AI 不断碰到的第二堵墙同样重要：**上下文长度**。 ![Context Length](https://www.hubwiz.com/blog/content/images/2026/05/1-ML78RWTmzdwnVEsHdMgtYQ-1.png) 想想人类开发者是如何随着时间的推移积累对系统的了解的。你加入一家公司，花几周时间阅读代码、提问、观察生产环境中的故障、理解某些决策的原因。慢慢地，你构建了整个系统的心理模型——它的历史、它的怪癖、它隐藏的依赖关系。 人类大脑记忆，更重要的是，*连接*了它遇到的几乎一切。运动、人际关系、工作、情感——它们都融入一个统一的世界模型，为我们的推理和决策提供信息。那种积累的上下文，在所有实际目的上，对我们工作的意义而言是无限的。 现在对比一下企业代码库。我们说的是数千个文件。通常整个项目 25GB 或更多。数百个相互关联的服务。功能是由三年前离开公司的人构建的，叠加在五年前离开的人所做决策之上。 即使今天最好的 AI 模型，单次会话的上下文也最多约 **200k 到 256k 令牌**。DeepSeek 因为提供 100 万令牌上下文窗口的模型而上了头条——纸面上令人印象深刻——但由于实际和地缘政治原因，它在真正的开发者工具中的广泛采用仍然有限。 这个观点很简单，但其含义是巨大的：**AI 无法将整个软件部门装进脑子里。** 它知道前端是什么。它在抽象层面上理解 CI/CD 意味着什么。但它不能从零开始设计一个可扩展的产品，保持对每个权衡的感知，并理解系统中一个部分的变更如何波及到其他一切。 现在还不行。很长时间内都不会。 ## 4、软件开发生命周期不仅仅是编码 当人们在想象 AI "取代"开发者时，软件开发之外的人常常遗漏一件事：编写代码只占实际工作的一小部分。 构建软件有一个完整的生命周期： - 理解功能需求——产品需要做什么 - 理解非功能需求——需要多快、多可靠、多安全 - 在时间和资源限制下决定纳入什么、砍掉什么 - 设计在真实条件下正确通信的前端和后端 - 正确使用 Docker 容器化服务 - 设置 CI/CD 流水线以避免部署变成噩梦 - 部署到云基础设施并就成本和规模做出正确的架构选择 - 然后——最重要的——一旦上线，监控、调试和维护一切 最后一项是我想要放慢速度讨论的，因为这是工作中最被低估的部分。 **在生产环境中调试才是真正的工作所在。** 它不光鲜。它不适合发 LinkedIn 帖子。没有人会写关于他们花了三个小时阅读 Cloud 日志的深度思考文章。但它是保持系统运转和业务运行的关键。 以下是每个读到这里的开发者都经历过的场景。同一段代码在开发环境中完美运行。你推到 beta——它坏了。你修复了它，它在 beta 中运行。你推到生产环境——完全是不同的问题。环境变量、流量模式、只有在大规模时才出现的边缘情况——这些都不会在本地测试中出现。 AI 确实可以帮助你理解错误消息。它可以建议你查看什么。但大多数时候，真正解决问题的是你对*那个特定系统*的理解，这是你在几个月或几年的工作中积累起来的。你的大脑、你的模式识别、你关于什么是脆弱的什么不是的直觉。 这不是你通过提示就能获得的。 ## 5、"现在任何人都能编程"的论点，为什么它不完整 目前有一个正在获得真正动力的叙事：产品经理、创始人和非技术人员可以"氛围编程"出一个可用的产品。说实话——在一定程度上，他们确实可以。AI 确实降低了构建早期原型的门槛，这是一件好事。 但故事中不常被提及的部分是这样的。 原型不是产品。演示不是系统。 当真正的用户到来时，情况会发生变化。规模随之而来。边缘情况成倍增加。当是五十个文件时看起来很整洁的代码库，到了五百个文件时开始变得真正难以导航。功能不断堆积。业务需求在构建过程中发生变化。有人问为什么上周二还能用的东西这周二不能用了，而且没有明显的答案。 代码变得更难阅读。文件大小增长。有一天，你盯着一个再也没有人完全理解的函数——它是六个月前由 AI 生成的，从那时起被修改了三次，现在处于一个每小时都在让公司赔钱的 Bug 的中心。 那就是你需要真正的工程师的时候。不是来编写新功能，而是来*理解*——并理清——已经存在的东西。 解决那些生产环境问题不是什么光鲜的工作。它无聊、困难、确实令人烦恼。但它不会因为一个产品经理用了 Cursor 到达版本一就消失。 ## 6、那么 AI 会取代谁？ 我想对这部分诚实，因为假装没有发生任何颠覆是不诚实的。 一些角色和人群确实处于风险之中： **多年来一直在自动驾驶模式下做同样事情的开发商**，没有成长或适应，处于脆弱的境地。如果你的价值主张是"我能可靠地做这件重复性的事情"，AI 已经在这方面与你竞争了。 **传统的应届生/毕业生期望已经消失了。** 过去有一种模式：初级开发者进来，接受大量指导，通过实践慢慢学习。这种模式已经被大幅压缩。公司现在期望职业早期的人从一开始就能做出有意义的贡献，并且已经手握 AI 工具。 **做范围狭窄、重复性任务的入门级开发者**——基本的 CRUD 操作、简单的集成、模板化的功能——随着 AI 在这些特定方面变得更好，面临着部分风险。 门槛以真实而具体的方式发生了变化。以前一个四五个人的团队可能负责一个系统，现在公司越来越多地期望一个更小的团队——甚至一个开发者——就能管理和维护同样的范围，由 AI 处理日常工作中的繁重任务。 *（需要明确的是：我不是在说顶尖 1% 的工程师。无论模型能做什么，那些人都不会被取代。我说的是我们其余的人——有能力、擅长自己所做的事情、希望继续成长而不是被浪潮取代的人。）* ## 7、如何为未来 10-20 年定位自己 考虑到以上所有内容，以下是我认为真正能让你在这个行业持续保持竞争力的因素。有两条真实的路径，两者都有效。 ![Two Paths](https://www.hubwiz.com/blog/content/images/2026/05/1-DTHlxIxeRL8m_c3NYRToaQ-1.png) ### 路径一：成为通才 通才是能够以真正的能力处理很多事情的人——不是对一切都浅尝辄止的人，而是对足够多的领域有足够理解，从而真正实现端到端有用的人。 在实践层面，这可能是：在前端框架和后端框架中构建和部署功能，设置 Docker 容器，使用 Jenkins 或 GitHub Actions 管理 CI/CD 流水线，部署到 AWS 或 GCP，理解基本的安全漏洞以及如何解决它们，编写真正的文档，以及设置自动化测试流水线来减少手动回归工作。 你不需要所有这些的认证。你不需要成为任何一个领域的世界顶级专家。你需要的是能够端到端地看待一个产品并*拥有它*——不仅仅是你的工单，而是整个东西。 简而言之，目标是成为公司根本承受不起失去的人。不是因为你以某种抽象意义不可替代，而是因为失去你意味着失去整个系统的机构知识、所有权和连续性。 ### 路径二：成为专家 第二条路径几乎向相反的方向延伸，但它因不同的原因而有效。 想想技术层是如何工作的。我们曾经用 1 和 0 编写代码。然后编译器出现了。然后是更高级的编程语言。然后是框架。然后是托管服务。然后是 AI 驱动的代码生成。每一层都构建在下面一层之上。 你在这些层中越深入，与你在一起的人就越少——AI 就越难取代你所做的事情。 想想为特定运行时用 C++ 编写垃圾回收算法的工程师。或者研究神经网络训练数学的人——优化梯度下降、进行量化以使模型运行更便宜、研究新架构。这些人不仅仅是在*使用* AI。他们直接意义上是在*构建*它。而他们构建它所依赖的基础——概率论、统计学、线性代数、计算机体系结构——不是语言模型可以自动化的东西。 当你在技术层中深入到足够深时，AI 就变成了你*在上面工作*的东西，而不是*代替你工作*的东西。 这些深度的就业市场很小。路径更难。但天花板更高，而且这些工作本身实际上对 AI 免疫。 ## 8、这把我们带到了哪里 AI 是一个真正强大的工具。我每天都在使用它，无意停止。但在所有的炒作和令人屏息的头条之后，它仍然是一个工具——不是真正的软件开发所需的判断力、上下文、业务理解和系统思维的替代品。 那些将 AI 视为增强工具——让它处理重复性工作而自己专注于更困难问题——的开发者将会蓬勃发展。完全忽视它的开发者将会落后。而关于软件开发作为一门学科将在未来几年内被完全自动化的叙事？那主要是卖 AI 订阅服务的人的好营销。 行业在变化。门槛在提高。对个人开发者的期望比以往任何时候都高。 但工作仍然是我们做的。 我们还有时间。明智地使用它。继续构建。 *如果这篇文章引起了你的共鸣，请关注我，了解更多关于真实软件开发的观点——不是高光集锦版本。* --- 原文链接：[AI Will Not Replace Software Developers — And I'll Say It Loud](https://medium.com/towards-artificial-intelligence/ai-will-not-replace-software-developers-and-ill-say-it-loud-ae1975c326ec?ref=hubwiz.com) 汇智网翻译整理，转载请标明出处 > **这是「AI 编程 / Vibe Coding」专题的一部分。**完整地图见：[AI 编程 / Vibe Coding 完全指南](https://www.hubwiz.com/blog/vibe-coding-stack/)