“你用AI，那我也会用AI，我还要你干什么？”

当我敏锐地察觉到AI可以提高工作效率之后，我就对AI展开了一系列的思考。比如思考AI会不会让人的思维能力退化的《努比亚M153和DeepSeek-Math-V2发布后，我对AI的思考》、思考AI时代下应试教育还有没有必要存在的《计算机应届生想成为人才，就不要去力扣刷题（文章合集）》、AI是不是先进生产力，以及为什么AI导致了失业的《程序员发明了AI，为何反被AI革了命？》。我个人非常推荐看最后一篇文章，这是最AI最根本的思辨，算是从根上论证了支持AI发展的正当性、合理性。根据这篇文章的逻辑，可以推导出以下结论：

• AI是先进生产力，之所以现在没有产生新的工作岗位，反而引发了裁员潮，本质上是因为生产关系正处在变革的开始，生产力想真正冲破旧的生产关系的桎梏需要时间。生产关系改变的过程就是利益再分配的过程，等生产关系变革完毕了，也就淘汰了旧的岗位、诞生了新的岗位。而且技术越先进，需要的人才反而越多，无论是军事还是AI，抑或是所有产业，都是这样的。这其中的关键就在于AI作为先进生产力，一定要国有化，要让先进生产力变成公有制。
  
• 一个新技术的出现，在前期肯定会出现资本泡沫，这其中有虚的，但里边也有实心的。无论是用实心的部分否定虚的部分，还是反过来，都不是实事求是的体现。
  

flowchart TD    subgraph OuterCircle [AI的泡沫]        direction TB        CoreValue((AI实实在在的价值))    end    %% 样式设置    style CoreValue fill:#0052CC,stroke:#0052CC,stroke-width:2px,color:#fff    style OuterCircle fill:#E3F2FD,stroke:#0288D1,stroke-width:2px,stroke-dasharray: 5 5,color:#0288D1但是就在我写完这篇文章的不久，我发现网上又有以前老生常谈的东西重新出现了：一方面，有些公司里的技术老手在去负责面试的时候，看见前来应聘的人擅长AI编程，就会说一句“那我也会用AI编程啊，你的价值体现在哪里？我为什么要专门雇你来用AI呢？”；另一方面，有些不具备计算机科学基础和软件工程专业素质培训的文科生开始在网上抱怨vibe coding（氛围编程）就是个骗局：“AI只能实现一些简单的需求，做出来的东西也只是一个简单的demo，一旦想让它实现复杂的需求，它写出来的代码就会报错。”
这些人的思想还停留在提示词工程的阶段，那只是第一代的AI编程，那时候以web对话框为主要交互界面，想让AI干活只能用海量的提示词配合文件上传功能实现AI编程。IDE里面的AI只能实现tab补全、局部代码预测这种简单的功能。但是现在已经进化到“上下文工程”了，虽然也属于提示词的范畴，但是本质上是把提示词扩展到文件大小，而且是由多个文件共同实现约束，指导AI正确地干活。最关键的是，提示词和提示词之间亦有差距。比如有一个人在网上曾经对我说过这么一段话：

你可能没写过三四百行的代码，特别是十多个表联查，AI在这方面会有逻辑错误，还得人工去理解里面的表结构关系来纠正。

对此我的回答是：

像你这样的人是用不好AI的。首先这十多个表之间是什么关系？这些表分别有哪些字段？字段属性又是什么？有什么约束条件？数据库是哪个，什么版本？AI又是用的哪一家的什么型号？最后这个项目的业务逻辑是什么，需要你十多个表联查？你看，我一个人类都能问出这么多问题，假如我是AI，我又能交付给你什么质量的代码？

所以，对于那些能够完成独立开发的工程师来说，总有一个幻觉，叫“你用AI编程，那我也会用AI，我为什么还要找你来使唤AI？”
其实不然。会独立开发的人不一定会用AI，比如他们不知道有更好用的Agent（智能体）工具、不知道最新的大模型已经进化到了何种程度，甚至像上面那个人一样，只知道笼统地描述问题，等等；而擅长用AI编程的人一定会独立开发，即使做不到独立开发，软件工程的专业素养也不会太差，因为AI是输入决定输出的，为了让AI有更好的输出，他一定得懂得软件工程和计算机科学相关的基础知识作为输入。
AI替代的是程序员，而不是软件工程师。我对这句话深以为然。
我在读本科的时候，我们的计算机系主任给我们开了一门《软件工程》课，教材上是这么解释软件工程的——

后来，人们逐步认识到编写程序仅是软件开发过程中的一个幻觉，在典型的软件开发工作中，编写程序所需的工作量只占软件开发全部工作量的10%~20%。软件开发工作应包括需求分析、软件设计和编写程序等几个阶段，于是形成了“结构化分析”“结构化设计”、面向数据结构的Jackson方法等传统软件开发方法。20世纪80年代广泛应用了面向对象设计方法。

软件工程是一整个体系。教材上是这么说的——

软件工程下的主要内容是软件开发技术和软件工程管理。
软件开发技术包含软件工程方法学、软件工具和软件开发环境。软件工程管理学包含软件工程经济学和软件工程管理学。本身只介绍有关软件工程管理的内容。

也就是说，程序员和软件工程师的区别，就在于程序员只负责实现别人提出的需求，而不考虑这里为什么要设计这个功能、这个功能到底有没有必要实现、还有什么功能是没想到的；而软件工程师不仅要会软件开发技术，更懂得软件工程管理，包括费用管理、人员组织、工程计划管理、软件配置管理等。而其中的工程计划管理，就需要明确软件系统的目标、功能规模等，然后设计解决方案，接着分析可行性，最后制定项目开发计划。而且软件工程也有需求分析，不过和产品经理的需求分析不同的是，产品经理的需求分析指的是深度挖掘用户的需求，而软件工程的需求分析则是在产品经理挖掘的用户需求的基础上，将用户的需求转化成技术指标，比如接口（API）怎么设计、选用什么技术栈（有些产品经理不懂技术，就只能让软件工程师干了）、怎么检查数据完整性和正确性……
换句话说，程序员就是软件生产流水线上的螺丝钉，不需要有自己的思想，只负责执行就完事了，可替换性强；而软件工程师则是一个具有“工匠精神”和主观能动性的团队领导者。
在这里我必须要给“工匠精神”正名。网上总是用日本的那种“xx仙人”的梗来讽刺“工匠精神”，用“米饭仙人”“寿司仙人”等来讽刺工匠精神，这是对工匠精神赤裸裸的歪曲和污蔑。但凡仔细研读过官方的宣传稿，就会发现“工匠精神”往往离不开一个词汇——创新精神。创新，才是工匠精神的精神内核。
网上还有人说，“底下的人都是真正做事的，领导啥事也不做，只知道把任务分配给下属，出了事还把责任往下推，明明AI更适合代替领导层才对”。我承认，领导和领导之间亦有差距。领导是把握整个团队的前进方向的角色，一个领导若是不合格，容易把整个团队带到沟里去。但正因为领导是把握整个团队的前进方向的角色，因此领导才需要有远见、要有智慧、要会管理，擅长人情世故。从这方面来说，应试教育的流水线生产出来的木讷的“产品”，只能去当一个程序员，而无法胜任软件工程师。我看网上有人观察出一个现象——那些月薪过万的程序员，大部分家境都不太好，导致他们不谙世事，而外界则夸他们“有自己的个性”“特立独行”。可是AI代替的就是程序员，这也成了他们悲剧故事的根源。AI+机器人未来会代替领导者吗？从生产关系的角度讲，确实可以，因为老板除了掌握生产资料以外，一无所有。但是从“领导”这个角色本身出发，等什么时候AI可以理解因果关系了、有远见了，它什么时候才能代替领导做出决策。
人的意识从实践中得来，从劳动中得来，从改造世界的过程中总结而来。因此程序员若想进化到软件工程师，也必须从实践中、从劳动中、从解决实际的用户需求中成长。落实到具体的方法论，就是氛围编程。现在AI代替了那10%~20%的开发工作，但是剩下的那80%以上的软件工程层面的工作无法代替。因此程序员可以用AI锻炼自己的“大局思维”，试试自己一个人完成整个软件生命周期。我个人推荐采用最经典的“瀑布模型”，其优点就是所有的工作流程都是顺序性的，必须做完前面的才能做后面的，容易培养对软件工程的成体系认知。且为了保证质量，每个阶段都要完成规定的文档，而且每个阶段都要对已完成的文档进行复审。这些文档就是AI最好的上下文，自然而然地就做到了“上下文工程”。

对于程序员来说，软件开发技术不是问题，有问题的是技术选型、确定软件功能、规划开发计划等环节。因此首先需要观察用户有哪些没有解决的需求，像番茄时钟、待办软件这些就别做了，苹果应用商店里面全是这些东西，不缺你一个。不妨观察一下同事们有哪些工作是可以用软件解决的重复性工作，这才是从实践中总结经验。然后像产品经理一样挖掘用户需求，根据这些需求确定系统功能，并评估这些功能能不能实现、有没有必要实现，然后写《产品需求文档》。这里我推荐《人人都是产品经理》系列丛书，产品经理和开发人员需要沟通、互相谅解，产品经理需要谅解永远都有改不完的bug和无法实现需求的怨气，开发人员也要谅解产品经理绞尽脑汁挖掘用户需求的头疼。现在有了AI，“人人都是产品经理”也不再是遥不可及的神话。
当你借助AI完整跑通了这一整个软件生命周期，我相信你也就对软件工程有了真正意义上的系统性理解，同时也对产品设计方法论有了自己的独到见解。在AI时代下，这才是真正的护城河。此时，你既可以转行去当产品经理，也可以额外学习曾仕强教授的“中国式管理”，准备晋升真正的软件工程师，去领导一个软件开发团队。
以前的软件是一个非常稀缺的商品，因为生产这个商品的“手艺人”都有着很强的专业能力，每一个都有着发明全新的系统内核或者编程语言的能力。而这些人的时间和精力都是有限的，产能自然也是有限的，再加上当时硬件非常昂贵，科技没有惠及千家万户。
后来人们在多年的开发经历中总结了一整套经验，也就是今天的软件工程。从此，软件开发开始向工程化、标准化发展，开发软件的人也由个人开发者向商业公司转变，生产过程变成了集群化生产。这就是软件开发行业从手工业向工业化发展的历史过程。
但是现在有了AI，随便某个人都能用AI氛围编程出一个样品（demo），实现了某个小需求，然后给大家用，或者自用。这表面上看上去好像是逆工业化、逆商品化，违背经济发展规律，似乎软件开发行业重新回到了“小农经济”模式。但我看见的，是以前没有AI的传统开发流程不仅没有满足大部分人的需求，反而把这些海量的需求掩埋了。而在AI的刺激下，大浪淘沙，这些需求“重现天日”而已。潮水退去，方知谁在裸泳，可现在是涨潮，虽然有人趁此机会浑水摸鱼，但更多的还是满足了非专业人士对软件的需求。以前业务和技术之间有着巨大的鸿沟，业务不懂技术，而技术有劲没处使，现在AI填平了这个鸿沟。这恰恰是生产关系正在发生重塑，利益正在重新分配的过程。这个过程，现在才刚刚开始呢。
有的人又要说了，“现在的AI只能复现大概率的东西，无法满足个性化需求。”“现在的AI还是太傻了，我让它往东，它偏往西，气死我了。”“中国的大模型比不过美国的大模型，你用一次就知道了。”
但是Trae（字节跳动旗下的AI IDE）团队却不这样认为。前两天他们发布了《2026 企业级AI编程实践手册》，在《1.1Context Engineering — 真正的护城河》章节中，他们明确说明，

在AI编程中，模型能力趋同，真正拉开差距的是上下文工程能力。就像人类开发者需要理解业务背景、技术架构和历史决策才能写出好代码，AI同样依赖高质量的上下文来生成符合企业实际的代码。
Context Engineering不是简单地“把代码扔给AI”，而是一套系统化的方法：如何识别关键信息、如何结构化地组织项目级和模块级的上下文、如何在有限的token窗口内精准传递最相关的信息，以及随着项目发展如何持续优化这些上下文。这是企业AI编程的护城河——它无法被模型升级替代，只能通过持续实践积累。

大模型本身的能力确实是影响落地场景的因素之一，但是现阶段中国的大模型和美国的大模型的差距已经压缩到3个月以内了，这样的差距已经体现不出什么了。那些嘴上说着“美国的大模型好，中国的大模型差”的人，本质上就是崇洋媚外的香蕉人，只是他们本人不愿意承认罢了，因此硬要把他们的主观感受给偷换成客观事实，这样他们就能标榜他们对AI有着“真知灼见”了。但是他们的错误在于，他们把别人都当成傻子，以为别人看不出他们的小九九。
现在人们对AI的态度是焦虑的，在明知道这是时代红利的发展浪潮下，没人愿意被时代淘汰。但是，需求决定供给，科技要以人为本，这才是实事求是。应该用技术去满足需求，而不是反过来，否则就陷入唯生产力论的反动谬误中了。

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！