附录 3：关于 AI 辅助开发与 AI 指导开发之间的界限——我们如何控制

提示

下文所说的 “现阶段” 都指本文编写的时间，即 2026 年。 以下观点均为作者个人观点，仅供参考。

虽然我们现在可以看到各种 AI 工具在疯狂刷屏——从最开始的 ChatGPT 到 DeepSeek、Claude Sonnet 再到 Claude Code、Codex，再到今年（2026 年）开始大火的 ClawBot、OpenClaw 以及基于这个概念的 AI 工具（例如 QoderWork、TraeWork、DeepSeek Harness 等），我们已经能感受到 AI 对我们的开发流程的影响了。

也许现在有人会说 “既然 AI 已经这么强了，那我把所有事情都交给 AI 不就好了”“AI 这么强，人类程序员该向何方前进？”“AI 是否会替代人类程序员？”“现在不学习 AI 就注定被淘汰” 等等一系列话语，甚至现在已经有人在利用我们对 AI 时代下的能力焦虑来为我们提供一系列课程，然后告诉我们诸如 “再不学 AI 你就要被淘汰了，赶快来买我们的课程学习 AI 吧” 这种话。

其实如果我们冷静下来想一想就会发现，很多时候，我们会认为一种机器会替代另一种需要人参与的活动，但是实际情况是其实并不会，反而是这些自动化产物的加入使得人类的作用变得越发紧要。例如在计算机刚开始在国外普及的 1980-1990 年代，就有很多人预计会计这个行业将会被淘汰。他们认为以后都是计算机自动算账的天下，会计以及金融分析已经没有未来了。但是结果呢？我们现在还是会盯着同花顺的一片绿深深感到无奈。那么在软件行业，情况是否也类似呢？关于这个问题，Frederick Brooks 在 1980 年代就给出了他的答案。在他的 The Mythical Man-Month（《人月神话》）的 “No Silver Bullet”（没有银弹）一章中，他做出了这样的表述：

所有软件活动包括根本任务 -- 打造由抽象软件实体构成的复杂概念结构，次要任务 -- 使用编程语言表达这些抽象实体，在空间和时间限制内将它们映射成机器语言。软件生产率在近年内取得的巨大进步来自对后天障碍的突破，例如硬件的限制、笨拙的编程语言、机器时间的缺乏等等。这些障碍使次要任务实施起来异常艰难，相对必要任务而言，软件工程师在次要任务上花费了多少时间和精力？除非它占了所有工作的 9/10，否则即使全部次要任务的时间缩减到零，也不会给生产率带来数量级上的提高。

这段话是什么意思呢？Brooks 在这里想要表达的是：所有软件系统的设计都包含一个根本任务（包括理解需求、根据现有约束进行技术选型、进行架构设计、进行验收等）与一个次要任务（包括设计程序内部的数据结构与算法、进行编码实现、进行测试等）。

而近 40 年间出现的所有工具——包括高级程序语言、IDE、先进操作系统与硬件、互联网资料库、现代开发范式、现代系统基础硬件与软件设施等，大部分情况下只提高了这里的次要问题的解决效率。例如高级程序语言避免了程序员编写汇编代码与机器码、IDE 使程序的编译与调试更方便、先进操作系统与硬件提高了我们的编码速度、互联网资料库能解决我们在编码时遇到的大部分问题、面向互联网时代的敏捷开发方法（例如 Agile、Scrum 等）以及更先进的代码组织方法（例如面向对象编程、面向接口编程、面向切片编程、设计模式等）提高了我们的产品开发与迭代效率，降低了我们编写的代码出错或不能复用于其他项目的概率、Docker、Kubernetes（K8S）、现代 Linux 操作系统、服务器管理面板等提高了我们的服务器运维效率。

但所有这些工具都没有触及到我们本质的问题——即上面提到的根本任务。我们稍微思考一下就会发现，这些语言、工具与开发范式，本质上都是在帮我们降低次要任务的解决难度，而这些任何一样东西都没有触及到最本质的问题，也就是说这些工具无法帮我们组织用户需求、无法帮我们细化需求清单、无法帮我们搞清楚 “这个软件系统到底做到什么程度才算完成、如何具体定义完成” 这个问题、无法帮我们搞定最后的验收流程与用户反馈流程——因为我们的软件系统编写完以后，最终用户一定是人。这里我们暂时忽略 AGI 与更高阶段的意识形态问题，即便未来 AI Agent 可以充当 “用户” 来调用我们的系统，系统的设计目标与价值判断，依然来源于人类，并且这与我们现在要讨论的问题，即我们如何在 AI 时代下学习没有直接关系。

当然这里可能有人说：那现在面向 AI 进行编写的一系列 Skills、记忆相关的代码、MCP 工具等，那不都是 AI 这类机器在使用吗？话是这么说没错。但它们的产物最终的使用者还是人类，这些工具与规范的出现，只是人们为了规范 AI 的行为、将 AI 引导至正确的路径上所采取的外部限制措施。我们甚至可以推测——在目前的 AI 辅助开发实践下，我们的软件开发几乎一定会回到以前的文档先行模式。因为文档本质上就是在规范 AI 的行为、将 AI 引导至正确的开发路径，从而开发出我们想要的产品。这与前面的 Skills 等的本质是一样的。区别在于——Skills 这些工具是在所有项目中可以复用的、可以在任意地方被调用的，而产品相关的文档只为这一个软件系统或产品服务。

这里还有可能有人问：现在 AI 也能够对创意类的问题提出一些解决方案，是否能视为它也解决了软件开发的本质问题呢？答案是——对，但不完全对。问题在于，它是没有自主意识的。目前，基于 Transformer 架构的 LLM（大语言模型，Large Language Model）的本质都是一种 “贪心随机状态机”，它能做的只是根据数据库与外部数据源的各种信息输入，通过自己内部的矩阵运算来得到一个流畅的回答。它本身并不知道这个答案合不合理——它只知道它的数据库中有这些解法。我们都知道算法具有有穷性，LLM 算法也不例外。如果 LLM 真的有自主思想的话，那么算法的有穷性就不再适用于 LLM——那就已经是 AGI（通用人工智能，Artificial General Intelligence）的领域了，而我们至今仍未点出 AGI 这个科技树节点。也就是说，现今的 AI 就算再强，它也只能给我们一些尤里卡让我们能够更快点出相关科技，而不是一个足以让我们点出从未预想的科技树的超级科技外挂。

我们甚至可以在现在推测，未来随着 AI 理解代码的能力不断深入，代码本身反而会成为为 AI 准备的最好的文档。到那时，AI 辅助开发可能会再次回到现在的代码先行模式。

那么这与我们的学习有什么关系呢？关系在于，现在的 AI 是会犯错的。当我们询问 AI 一个并不存在的概念时，AI 就会为我们自信地回答一些错误的内容。这些内容大多是从它们自己的数据库中拼合而来的 “拼好解”。这种现象已经不再是新鲜事，有一个专门的名词来描述它——AI 幻觉。而我们现在学习的意义在于一件事情：如何发觉 AI 可能出现幻觉，从而及时停止 AI 进一步误导我们并给予纠正。现在如果我们在网上看 Vibe Coder（指只凭借 AI 与对产品的直觉，通过给 AI 下达指令来进行开发的开发者）们对 AI 工具的评价，我们就会发现这些评价几乎是两极分化的。觉得它好用的会认为它省下了大量的时间与重复劳动，觉得它不好用的会认为它既费钱，最后也得不到真正的产品。对于后者，非常有可能正是因为他们自己的知识基础（包括程序设计语言基础、计算机理论基础、对 AI 工具的理解基础等）过浅，认为仅仅凭借 AI 就能够完成整个产品的开发，甚至以此为论据抨击现在学习计算机相关基础课程的必要。这并非危言耸听，而是一些上层管理者的真实想法。他们可能被焦虑所侵蚀，认为 “AI 这个技术必须今天引入，不能再等”，之后在实施时又不了解相关的风险、开支、与该行业的适配度，最后造成上下层两败俱伤的场面。

然而事实又真的如此吗？其实不然。我们可以在这里做一个大胆的推测——未来随着 AI 的发展，最先被淘汰的往往是那些只会进行重复操作的程序员。他们的工作已经有大量的重复结果，自动化程序很容易就能够完成他们所能完成的所有操作，自然会最先被淘汰。而最难被淘汰的往往是那些能够做到 AI 做不到的大部分事情的程序员——他们能够分析用户的需求，能够根据用户的需求提出相关产品的灵感，也能够根据这个灵感进一步细化需求，最后通过严谨的语言指导 AI 来开发产品的程序员。

在 AI 时代，我们又需要保留多少能力呢？我们不仅需要保留创造力。我们还需要保留对底层的理解，以便在 AI 出错或不可用时仍然能够正确地完成我们的工作。此前 Claude Fable5 的禁令已经足以让我们明白，AI 可能会耗尽配额，可能会搞地区封锁，服务器可能会崩溃，网络可能不可达，但我们脑子里的知识不会。我们的大脑只要有充足的营养供应就能正常运作，不可能封锁自己，除非疾病或其他原因也不可能遇到崩溃，更不可能遇到网络不可达的问题。所以我们在这里需要理解 AI 对我们的作用——它是一个超级加速器，可以帮我们完成一些底层的、重复的工作，而不是一台轮椅，一台我们离了它就不能自己走路的轮椅。

我们再说回 AI 对创意类问题提出的解决方案。虽然 AI 现在能为我们的应用提出很多具有创意，甚至很多是我们自己想不到的方案，但是这些方案最终采纳与否，还是要由我们人来决定。它自己并不能脱离人类的操控来决定采纳或拒绝某版方案——因为 AI 的本质还是机器，而机器的职责是服务人类。虽然 AI 对创意类问题的解决方案收缩了一部分我们所谓的 “本质问题” 的范围，但它并没有令收缩范围后的问题消失。恰恰相反，它暴露了一些初学者不会面对的问题，包括涉及用户价值判断、涉及风险权衡、涉及系统边界的任务，这些任务恰恰是现阶段的 AI 最难替代的。

这时可能有人还要说：在多年的软件工程实践中，很多部分都是经验复用和模式匹配，那这些部分不能被 AI 替代吗？答案是——基本上能，但是这并不属于我们收缩范围后的本质问题。在收缩范围前，这些问题仍然属于本质问题，但当 AI 能够解决这部分模式匹配问题时，这部分问题就已经被划归到偶然问题上了。而本质问题还在那里，等待我们的决策。

那么，这对我们意味着什么？

如果我们把 AI 看作一个能力不断膨胀的实习生，那么我们的角色正在从 “编码工人” 转变为 “技术决策者”。我们需要掌握的，不再是某个框架的 API 细节，而是：

• 需求辨析能力——能从模糊的对话中提炼出真正的问题；
• 架构权衡能力——能在多个可行方案之间做出有依据的选择；
• 边界感知能力——能判断什么时候该让 AI 做，什么时候该自己上；
• AI 批判能力——能识别 AI 输出的幻觉与偏见，而不是盲从。

这些能力，不会因为 AI 变得更强而贬值——恰恰相反，AI 越强，它们就越珍贵。

未来的软件开发，不是 “AI 替代人类” 的零和博弈，而是 “人类借助 AI” 的协作进化。我们手中的工具变了，但我们工作的核心没有变：理解需求、创造价值、服务他人。 而这一切的起点，依然是那颗不断学习和思考的大脑，它不会被淘汰，也不会被替代，因为它是所有工具的最终解释者。