AI时代，还要不要学编程？

AI时代还要不要学习编程

9 月初 GPT-6 Astra 刚出来的时候，我刷到不少演示，确实有点夸张。以前我们说 AI 会写代码，更多还是补全一个函数、解释一个报错，或者根据需求生成一段代码。现在已经越来越不一样了，它可以自己读项目、改很多文件、跑测试，再根据结果继续修改。一个原来可能要程序员折腾几天的事情，现在一句话交代下去，AI 自己就能往前推进很远。

看到这些东西以后，一个问题其实很自然：那我们还要不要学编程？还要不要花很多时间去练习手工写代码？

这个问题对我来说有点复杂。

这不是一个旁观者的问题

我自己写了很多年代码，也开发过不少项目。早些年还做过编程教育，教过小朋友 Scratch，也教过 Python、C++，做过 Arduino、无人机这些软硬件结合的课程。我出版过面向零基础读者的 C++ 入门书，也做过不少编程学习相关的课程和内容。我的 GitHub 上有一个 Python 编程练习项目，到现在还有接近三万 Star。

C++漫画版

所以当我今天重新问自己“AI 时代还要不要学编程”时，这不是一个旁观者的问题。某种程度上，也是我在重新看自己过去十几年一直相信、一直在教别人的东西。

编程真正教的是什么

过去我们教孩子、教学生学习编程，当然会教语法、变量、循环、函数，但我一直觉得这些并不是最重要的。真正重要的是编程背后的那套思维：怎么把一个大问题拆成小问题，怎么把模糊的需求变成明确的步骤，怎么发现错误，怎么验证自己的判断。

再往后做真正的软件项目，就会发现光有“编程思维”也不够，还要有软件工程的方法。软件工程里有一篇很经典的文章，Fred Brooks 的《没有银弹》（No Silver Bullet）。它说的其实很朴素：软件的复杂性没有什么神奇技术可以一下子消灭掉。后来我们有了各种更好的语言、框架、工具，也有敏捷开发这样的工程方法，但它们都不是银弹。

我自己做项目的时候也真正用过敏捷开发。把大需求拆小，短周期迭代，做完以后看结果，再调整下一步。现在回头看，我觉得这些方法真正训练的也不是某一种流程，而是一种面对复杂系统的习惯：不要指望一次把所有事情想对，要拆开、反馈、验证、修正。

现在的问题是，当 AI 已经可以替我们写掉大量代码以后，这些训练还有没有必要？

连 Karpathy 都不怎么敲代码了

先说一个我觉得很有代表性的人：Andrej Karpathy。可能不是所有读者都熟悉他。Karpathy 是 OpenAI 的创始成员之一，后来做过 Tesla 的 AI 负责人，在斯坦福读博士时还设计并主讲过很有名的 CS231n 深度学习课程。他既是一个很强的 AI 研究者，也一直是非常典型的“会自己动手写东西”的程序员。

2025 年，他提出了一个后来很火的词：vibe coding。大意就是，不再盯着每一行代码，而是直接跟 AI 说自己想要什么，看结果，再继续说、继续改。今年 3 月，他甚至在一次访谈里提到，自己已经有几个月几乎没有手工敲过代码了。

如果连 Karpathy 这样的人都越来越少自己敲代码，那“手工编程是不是还重要”这个问题，显然不是杞人忧天。

一个最近的例子：Second Brain Graph

我自己的感受也差不多。最近我做几个小项目，AI 写掉的代码比例已经非常高了。甚至很多时候我根本不会先去查某个框架的文档，而是直接告诉 Codex 或 Claude Code 我想做什么，让它先实现，再看结果。

比如我最近做的 Second Brain Graph。这个项目并不是从零开始重新做一套“第二大脑”，它实际上是给 Hermes Agent 里的 LLM-Wiki 做了一个可视化和交互界面。LLM-Wiki 本身会把长期积累的知识组织成互相链接的 Markdown Wiki；我希望能把这些节点和关系直接画出来，可以在 2D、3D 图上浏览，也可以点一个节点，带着这个节点的上下文继续和 Hermes Agent 对话。

Second Brain Graph

从代码量看，这种项目现在让 AI 来做确实很快。React 页面、Three.js 的图、Node.js 后端、接口、实时同步，甚至部署脚本，AI 都可以帮忙完成。

但真正做的时候，我花时间想的往往不是某一行 JavaScript 怎么写。比如 Wiki 里的关系怎么映射到图上，节点点进去到底展示什么，跟 Hermes 对话时应该带多少上下文，Wiki 本身应该只读还是允许前端直接修改，聊天产生的新内容以什么方式再写回 Wiki，以及这个东西以后到底只是一个我自己用的小工具，还是可以做成一个独立产品。

这些事情 AI 都能跟我讨论，甚至它给的建议常常也不错。但最后怎么取舍，还是得我自己决定。

所以我现在越来越强烈的一个感觉是：AI 帮我省掉了大量“写代码”的时间，但没有帮我省掉“想清楚”的时间。 很多时候，后者占的比例反而越来越高。

从“会 Prompt 就行”，到 Harness Engineering

最近这一两年，AI 编程也开始从最初的“会 Prompt 就行”，很快往工程化方向走。大家不再只盯着模型本身，而是开始讨论模型外面那一整套东西。我最近常听到的一个词是 Harness，或者 Harness Engineering：上下文怎么给，规则怎么定义，工具怎么开放，任务怎么拆，测试怎么跑，失败以后怎么恢复，怎样让 Agent 不要反复犯同一个错误。

GitHub 上这类项目过去一年多尤其多。比如 GitHub 自己做的 Spec Kit，强调先把规格写清楚，再让 Agent 实现；Garry Tan 做的 gstack，把产品、架构、代码 Review、QA、发布这些角色和流程做成一组可以直接调用的 Skills；还有 Superpowers，把需求澄清、计划、TDD、Review、验证这些过去软件团队里很熟悉的东西，重新包装成 AI Coding Agent 可以执行的工作流。再加上 AGENTS.md、各种 Skills，本质上都是在做同一件事情：不能只给 AI 一句话，然后祈祷它一直做对。

我看到这些东西时，反而觉得挺有意思。我们绕了一圈，好像又回到了软件工程。

过去面对的是人写代码以后容易失控，所以需要需求、设计、规范、测试、Code Review、持续集成和敏捷迭代。现在变成 Agent 写代码以后容易失控，于是我们又开始写 Spec、写 AGENTS.md、做 Skills、设计 Harness、加测试、加 Review、加反馈环。

工具完全变了，但要解决的问题其实并没有变。 Fred Brooks 当年说“没有银弹”，到了 AI 时代好像仍然成立。大模型非常强，但大模型本身也不是银弹。

这也是为什么，我现在并不赞成简单地说：“AI 都会写代码了，以后不用学编程了。”

但我也不赞成另外一种说法：因为编程思维很重要，所以编程开发者还是应该像十年前一样，从语法、API、框架细节一路苦练，最好什么代码都自己手工写。AI 已经改变了工具，我们没有必要假装什么都没有发生。

什么在贬值，什么在升值

很多过去必须靠记忆和熟练度解决的问题，价值确实在下降。一个 API 的参数怎么写，一个 CSS 属性叫什么，一个框架某个配置放在哪个文件里，这些东西以后很可能越来越不值得花大量时间去背。

真正需要重新讨论的，是我们到底为什么学编程。

如果学习编程只是为了记住 Python 的语法，或者能够不查资料手工写出一个排序算法，那它的价值确实正在快速下降。

但如果学习编程是在训练另外一些东西——把复杂问题拆开，把模糊的问题说清楚，建立抽象，理解系统的边界，发现错误，并且验证结果——我反而觉得这些能力在 AI 时代更重要了。

能跑，就算完成了吗？

因为以前程序写错了，很多时候直接报错。现在 AI 给你的东西，最麻烦的情况不是它完全不会做，而是它做出了一个“看起来挺对”的东西。页面出来了，测试也许过了几个，Demo 也能跑，然后你很容易觉得事情已经结束了。

如果没有足够的判断能力，很容易就在这里停下来：能跑，就算完成。

而真正做过项目的人往往会继续问：为什么要这么设计？这个结构以后能不能维护？这里有没有把两个本来应该分开的东西耦合在一起？异常情况怎么办？安全边界在哪里？测试到底覆盖了什么？如果数据量变成现在的一百倍，它还能不能跑？

这些问题不一定需要你亲手去改每一行代码。AI 完全可以继续帮你改。但你至少得知道应该问什么，也得有能力判断它给你的答案靠不靠谱。

AI不是取代程序员，而是放大程序员

如果让我重新设计课程

所以，如果现在再让我去设计一套编程学习或者开发者训练课程，我大概率不会再按照过去的方式来。手工编程依然应该学，但不会占那么大的比例。我会更早让学习者使用 AI，同时要求他看懂 AI 做了什么，解释为什么这么做，修改它，给它补测试，故意把东西弄坏，再把它修回来。

我甚至会把写 Spec、拆任务、设计测试、Code Review、调试一个 AI 写出来的系统，当成新的基础训练。

因为未来真正拉开差距的，可能已经不是谁能更快地敲出一百行代码。

而是谁能把问题想得更清楚，能把 AI 驾驭得更好，也能在 AI 做错的时候知道它错在哪里。

AI 让写代码越来越容易，但它并没有让思考变得多余。

也许我们真正应该问的，不再是“AI 时代还要不要学编程”，而是：当代码越来越便宜以后，还有哪些能力，值得我们继续花时间去刻意训练？