7.0
热点
AI SCORE
观点评论2026-02-03 12:48
AI 编程时代程序员的核心竞争力在何处
DEV Community · Daniel Nwaneri#AI 编程#职业发展#思维转变
Editor brief · 编辑速览
探讨当 AI 能写代码时，程序员的真正价值转向系统设计、需求理解、架构决策。强调高阶思维和代码审查能力的重要性。
一位 AI 研究员对我说过一句让我始终无法忘怀的话：
“如果一个人在某项任务上的表现无法超过前沿模型，也无法为其提供有意义的指导，那么这个人的边际价值实际上就是零。”
现在，我们有数据可以验证这一点了。Anthropic 针对初级工程师开展的研究表明：在不理解的情况下使用 AI，会导致掌握程度下降 17%——相当于成绩降低两个等级。
但有些 AI 用户依然取得了高分。区别在哪里？他们使用 AI 是为了学习，而不是为了把任务委托出去。
现在的问题不再是“我能不能使用 AI？”
而是“我是在使用 AI 加深理解，还是在逃避理解？”
软件开发领域正在形成一条分界线。它区分的不是高级开发者和初级开发者，也不是经验丰富者和初学者。
这条分界线要深刻得多。
与之相对的是：
问题是：你站在这条分界线的哪一边？
API 之下：能够执行 AI 给出的建议
API 之上：能够判断 AI 的建议究竟好不好
这条分界线关注的并不是你能构建什么，而是你能验证、简化和维护什么。
Tiago Forte 在观察 AI 辅助开发时发现了一个至关重要的现象：
“Claude Code 让从头构建某个东西变得比修改现有系统更加容易。构建 v1 版本的价值将大幅下降，而维护 v2 版本的价值将急剧上升。”
一名初级开发者使用 Claude 构建了一套身份验证系统。200 行代码，20 分钟完成，测试通过，然后发布到生产环境。他的作品集看起来令人印象深刻。
六个月后，业务需要集成 SSO。现在，他不得不调试并非由自己编写的身份验证逻辑，遵循 AI 出于某些他不理解的原因所选择的模式，同时完全不了解其中的架构背景。原本 4 小时可以完成的工作却花了 3 天——因为他从未学会在构建 v1 时就把 v2 考虑进去。
这就是 v1/v2 陷阱的实际表现。
AI 让其商品化的技能（v1 领域）：
AI 无法取代的技能（v2+ 领域）：
陷阱就在这里：初级开发者正在使用 AI 构建令人印象深刻的 v1 项目，并把它们放进自己的作品集。但他们始终没有学会真正能够获得高额报酬的 v2+ 维护技能。
正如 Ben Podraza 在回复 Tiago 时指出的：
“它一开始表现得很好，直到你要求它创建两个格式相同的网页。然后你会花上几个小时反复迭代，烧掉成千上万个 token。”
保持一致性很难。理解上下文很难。理解遗留系统也很难。
而这些恰恰是你在成熟代码库中工作、阅读他人代码以及艰难权衡重构决策时才能学到的技能。
公共知识体系教会人们 v2+ 技能。AI 教给人们的是 v1 技能。
猜猜到了 2027 年，市场愿意为哪一种技能付费？
《Clean Code》的作者 Uncle Bob Martin 一直在使用 Claude 编程。他的观察直指人类仍然能够贡献的核心价值：
“Claude 的编码速度比我快得多。它能在自己的‘脑海’中容纳比我更多的细节。但 Claude 无法把握全局。它不理解架构。尽管它认同重构的价值，却没有表现出主动将这种价值内化的倾向。它无法预见自己正在制造的灾难。”
危险在于：AI 让添加功能变得如此容易，以至于你会跳过“慢下来认真思考”这个步骤。
“如果不加约束，AI 会不断地在代码之上堆砌代码，最终弄得一团糟。同样，由于人类使用 AI 添加功能实在太容易，他们也会不断叠加功能，把一切搞得混乱不堪。”
有人问：“当我们不再直接与代码交互时，代码质量还有多重要？”Uncle Bob 的回答十分尖锐：
“我开始觉得，代码质量变得更加重要了。”
为什么？因为仍然需要有人在 AI 生成的混乱代码中维持架构一致性。这个人不仅要理解代码做了什么，还要理解它为什么要以这样的方式组织。
自 Claude Code 和 Anthropic 的 Model Context Protocol（MCP）发布以来，开发者一直在尝试 AI 优先的工作流。结果与 Uncle Bob 的观察完全一致：AI 在实现层面速度惊人，却看不到架构层面的后果。
Claude Code 擅长：
它无法做到的事情（由其设计所决定）：
这个工具非常强大。我每天都在使用它。但如果把它当成自动驾驶系统，而不是指南针，最终就会形成 Uncle Bob 所警告的“代码堆”。
这并不是 Claude 自身的局限，而是当前 AI 架构的一项根本性约束。正如 Peter Truchly 在评论中解释的：
“LLM 并不是为了追求真相而构建的。它们的训练目标是输出连贯性（也就是所谓的有用性）。”
LLM 会自信地生成能够编译和运行的代码。但这些代码是不是正确的代码——架构是否合理、是否可维护、是否足够简单——则需要人类在 Ben Santora 所说的“高成本验证领域”中作出判断。
正是这种判断力，让你得以留在 API 之上。
根据围绕我的知识崩塌文章展开的讨论，以下这些技能能够让你留在 API 之上：
正如 Ben Santora 在研究 AI 推理局限时所解释的：
“当求解者的输出在缺少强大、独立的评判层进行验证的情况下被循环利用时，知识崩塌就会发生。风险并不在于 AI 编写内容，而在于 AI 成为自己的权威。”
低成本验证领域：
高成本验证领域：
AI 在这两类领域中听起来同样自信。但在高成本验证领域，直到几个月后系统在生产环境中崩溃，你才会意识到自己错了。
在评论中，Doogal Simpson 重新阐释了从稀缺走向丰富这一转变：
“我们正在用编辑的自律，换取搜索摩擦的消失。现在的挑战不再是生成代码，而是要有勇气拒绝 AI 提供的‘厨房水槽式’大而全方案。”
旧经济：稀缺迫使人们保持简单（寻找答案的成本很高）
新经济：丰富要求人们保持自律（AI 什么都能生成，而你必须进行删减）
技能的重心正从“添加”转向“删除”，从生成转向筛选，从解决问题转向作出判断。
在评论中，John H 解释了自己作为一家单人开发工作室，是如何有效使用 AI 的：
“我可以专注于扮演知识工作者的角色，确保业务规则得到满足，并确保产品符合客户的可用性要求。”
John 并没有把 AI 当成自动驾驶系统。他是在自己继续担任评判者的同时，把 AI 用作能力倍增器。
这种模式是：拥有深厚上下文的资深开发者能够有效使用 AI。他们可以验证输出、发现错误，也知道什么时候应该否决 AI 的建议。
问题在于：如果初级开发者没有先积累那些来之不易、让验证成为可能的经验，他们还能学会这种方法吗？
就在我撰写这篇文章期间，Anthropic 发布了实验数据，验证了 API 之上与 API 之下的分界。
在一项针对初级工程师的随机对照试验中：
然而，AI 辅助组中仍有一些人在使用 AI 的同时取得了高分。
区别在哪里？他们会"提出概念性和澄清性问题来理解他们正在处理的代码——而不是委托给 AI 或依赖 AI"。
调用 API 以下（委托）："AI，为我写这个函数" → 快速 → 没有理解 → 测验失败
调用 API 以上（用 AI 学习）："AI，解释一下为什么这个方法有效" → 速度慢但理解了 → 得分高
不理解的速度 = 调用 API 以下。边用 AI 边理解 = 调用 API 以上。
工具是一样的。你的方式决定了你在哪一边。
[来源：Anthropic 的研究，2026 年 1 月]
最后一代问题
在评论中，Maame Afua 揭示了一些关键的事实：她是初级开发者，但她有效地使用了 AI，因为她有导师。
"我得到了很多来自那些经历过老一套系统（没有 AI）的优秀开发者的建议。我一直在遵循他们的建议。"
传递机制：前 AI 时代的开发者向 AI 时代的初级开发者教授验证技能。
Maame 能够验证 AI 输出，不是因为她经验丰富，而是因为经验丰富的开发者教她保持怀疑。她的学习路径：
第一步：先打好基础（书籍、文档、认可的资源）
第二步：用 AI 作为助手，不是主要学习工具
第三步：对标权威来源进行验证
第四步：从不实施她无法解释的东西
但我们正在接近一个悬崖：
现在，有足够的前 AI 时代开发者来指导新人。在 5-10 年内，大多数高级开发者将主要通过 AI 学习。
谁来教下一代去怀疑？当没人有验证习惯时，谁来传递验证技能？
我们离完全失去这一传递机制只有一代人的距离。
Maame 很幸运。她在窗口关闭前找到了好导师。2030 年开始的初级开发者就没有这个选择了。
人们如何学会验证
评论中两位开发者展示了不同的验证技能培养路径：
ujja 通过痛苦的经历学会了"零信任推理"：
"我对 AI 的信任有点太多了，速度很快，但直到几天后才意识到一个核心假设是错的。到那时它已经嵌入到设计和逻辑中了，所以我不得不废弃大块代码重新开始。"
他的心智模式转变了：
之前："这听起来对吗？"
之后："什么会让这个错误？"
他现在把 AI 当作"一个非常自信的初级开发者——超级有帮助，但需要审查"。
他的洞察："我不认为痛苦是必需的，但没有某种反馈循环，比如浪费的时间或损坏的构建，很难内化。AI 消除了摩擦，所以人们会跳过验证，直到成本稍后显现。"
有意识的方式（Fernando）
Fernando Fornieles 几个月前就认识到了这个问题，并在被惹恼前采取了行动：
关闭私人社交媒体账户
迁移到联邦网络
搭建家庭云服务器（树莓派上的 Nextcloud）
积极避免平台"质量下滑"
他没有通过痛苦学习。他按照原则行动。
问题是：我们能否在不经历痛苦的情况下传授 ujja 学到的怀疑精神？我们能否大规模推行 Fernando 的有意识行动？
或者每个初级开发者都需要废弃一周的工作才能学会验证 AI 输出？
知识共享社区教了什么
Stack Overflow 的辩论教了架构。有人会提议一个解决方案，其他人会批评它，共识会通过冲突浮现。那种冲突建立了判断力。
代码审查文化教了"放慢速度思考"。你不能直接发布——有人会问"为什么是这个方法？"，你必须为架构决策辩护。
痛苦的 bug 教了预见灾难。你会实施看起来不错的东西，它会在生产中爆炸，你会学会提前看到那些模式。
遗留代码库教了重构判断。你会维护别人的决策，理解他们的约束，学会何时保留与何时重建。
这一切都发生在公共场所。在 Stack Overflow 上。在代码审查评论中。在 GitHub issue 中。在会议演讲中。
AI 辅助发生在私人空间。个体优化。没有公共冲突。没有集体提炼。
让你处于调用 API 以上的技能是由我们正在摧毁的知识共享社区教授的。
如果你是初级/早期职业开发者：
积极寻求前 AI 导师
找出在 ChatGPT 前学习的开发者
请他们审查你的 AI 生成代码
学习他们的怀疑模式
在成熟的代码库中工作
不只是构建绿地项目
为已建立的开源做贡献
从技术债务决策中学习
公开记录你的推理
写出你选择方法的原因
发布调试历程，不仅仅是解决方案
为你消费的共享社区做贡献
明确建立验证习惯
总是对照文档检查 AI 输出
测试假设，不只是发布
学会识别"自信的错误"
像 ujja 那样对待 AI
"非常自信的初级开发者"
超级有帮助，但需要审查
问"什么会让这个错误？"，而不是"这听起来对吗？"
如果你是高级/经验丰富的开发者：
教验证，而不仅仅是语法
分享你的怀疑模式
大声解释架构思维
保留架构知识
记录决策的原因
发布架构决策记录
写出你预见的灾难
有意识地为共享社区做贡献
在 Stack Overflow 上回答问题
写详细的技术博客文章
开源你的推理，而不仅仅是代码
让"放慢速度思考"可见
向初级开发者展示你何时暂停思考
解释你对 AI 的问题
演示编辑/简化过程
不舒服的问题
在我关于知识崩溃的文章评论中，Leob 提出了终极问题：如果 AI 实现真实发明呢？
"AI 的下一个突破将是如果它能自己'发明'一些东西，提出新问题，自主创建内容，而不仅仅是重新组织被馈送给它的东西。"
如果发生这种情况，"调用 API 以上"可能会变得无关。
但正如 Uncle Bob 观察到的："AI 无法掌握全局。它不理解架构。"
Peter Truchly 为这个限制增加了技术深度：
"LLM 不是为了寻求真理而构建的。哥德尔/图灵限制确实适用，但 LLM 甚至不在乎。LLM 只是为了输出连贯性（也就是有用性）而训练的。"
两种可能的未来：
场景 1：AI 仍然是复杂的重组器 知识崩溃毒害训练数据。模型质量下降。调用 API 以上/以下的分差至关重要。你的架构思维和验证技能在数十年内保持有价值。
场景 2：AI 实现 AGI 和真实发明 知识崩溃不重要，因为 AI 生成新知识。但那样的话……人类贡献什么？
当我们已经看到崩溃发生时，把一切赌在"AGI 将拯救我们脱离知识崩溃"感觉很冒险。
也许我们应该修复我们知道存在的问题，而不是希望一个可能让一切变得更糟的突破。
软件甚至需要人类吗？
Mike Talbot 对我的整个前提提出了质疑：
"为什么人类需要构建知识库？这样他们和其他人能制造东西？如果 AI 能在没有人类知识库的情况下构建软件，谁在乎知识库？"
他的论证：知识库存在是为了帮助人类构建软件。如果 AI 能在没有人类知识库的情况下构建软件，Stack Overflow 死了谁在乎？
他用了一个个人例子：
"我写了我的第一个电脑游戏。我清楚地记得在 90 年代在一个迪士尼项目上工作，并想出了编译精灵。所有那些知识，所有那些文档，被显卡消灭了。没有人在乎我的编译精灵；他们在乎工作的软件。"
他的观点：每一个范式转变都会使以前的知识过时。也许 AI 只是下一个转变。
我的回应：显卡没有在他的编译精灵文档上训练。它们是一个根本不同的方法。AI 在 Stack Overflow、Wikipedia、GitHub 上训练。如果这些死了，AI 在 AI 输出上训练，我们得到的是模型崩溃，而不是范式转变。
Mike 的挑战很重要，因为它迫使澄清：我们保留人类知识是因为它本身有价值？还是因为它对 AI 持续改进是必需的？
如果 AGI 出现，他的问题变得更紧迫。如果没有，保留人类知识变得更关键。
你实际贡献什么
回到原始问题："你贡献什么是 AI 无法做到的？"
你贡献验证。AI 解决问题。你判断解决方案是否真的好。
你贡献架构。AI 写代码。你看到它无法掌握的全局。
你贡献远见。AI 局部优化。你防止它看不到的灾难。
你贡献上下文。AI 有模式。你有领域专业知识、客户知识、历史理解。
你贡献在成本高昂的验证域中的判断。AI 在验证成本低的地方表现出众（它能编译吗？）。你在验证成本高的地方表现出众（这会扩展吗？这能维护吗？这是正确的方法吗？）。
你贡献的是简化。AI 生成全面的解决方案。你拥有删除复杂性的纪律。
你贡献的是连续性。AI 是无状态的。你跨系统、团队和时间维持一致性。
但这里有个令人不适的真相：这些技能都不是天生的。
它们是学来的。通过摩擦。通过痛苦。通过公开的奋斗。通过向那些吃过苦头的人学习。
如果我们摧毁知识共享，我们就摧毁了"超越 API"技能的训练场。
如果我们停止显式的指导，我们将在一代人内失去这种知识传承。
如果我们纯粹为速度优化，我们会失去"慢下来思考"的肌肉。
保持在 API 之上不是自动的。这是你每天都要做的选择。
选择验证，而不仅仅是接受。选择简化，而不仅仅是生成。选择预见，而不仅仅是反应。选择指导，而不仅仅是构建。选择发布，而不仅仅是消费。
API 线是真实的。你会站在哪一边？
这篇文章源于与公开探讨这些问题的开发者的讨论。特别感谢 Uncle Bob Martin、Tiago Forte、Maame Afua、ujja、Fernando Fornieles、Doogal Simpson、Ben Santora、John H、Mike Talbot、Leob、Peter Truchly，以及所有思考这个转变的人。
你认为哪些技能能让开发者保持在 API 之上？我遗漏了什么？让我们一起搞清楚。
我的 Chrome 标签页讲述了一个我们还没有处理的故事
我们正在造就一场知识崩溃，没有人在谈论它
超越 API：开发者在 AI 能编程时的贡献（你在这里）
建立基础（即将推出）
某些评论可能仅对已登录的访客可见。登录以查看所有评论。
如需进一步操作，你可以考虑屏蔽此人和/或举报滥用行为