【转载】AI 时代下对编程的一些思考-zhiyuanzhou

AI 时代下对编程的一些思考

在2026年11月这个时间节点，AI 对 IT 行业的渗透已经进入白热化阶段。从基层研发人员到上层管理者，都充满了焦虑。担心自己做的事情没有价值，被 AI 替代；更担心自己跟不上节奏，被时代彻底抛弃。AI 提效的声音充斥在每个人的耳边，似乎 AI 已经被定义成一个 Super Hero，无所不能。正如大洋彼岸的川建国同志，要求联邦政府部门在各类官方文件中以“超级智能”（Super Intelligence，SI）取代沿用多年的“人工智能”（Artificial Intelligence，AI）这一称谓。

有人说，不了解 AI 基本原理的人，很容易对 AI 产生极高的幻觉。但也有人说，你觉得 AI 有幻觉，是因为你没用过世界上最厉害的大模型，再配上世界上最厉害的 Agent。譬如，Codex + Atlas / Claude + Fable，一个“天才程序员”就此诞生。从计算机科学的角度来看，AI 的幻觉是真实存在的，而且在可预见的未来也不会完全消失。因为 AI 模型的本质是一个复杂的数学模型，通过不断计算预测值与真实值之间的误差，调整模型参数，最终使误差收敛到一个可接受的范围，从而得到一组合理的权重，由此训练出一个模型。也就是说，我们每一次向大模型的输入，经过模型的推理（运算）后，得到的都是模型基于已有参数和上下文生成的预测结果。既然是预测，就有可能给出错误的答案，只不过是概率高低的问题。所以，在 AI 参与人类生产的过程中，如果要保证最终的交付质量，就不能忽视人对 AI 输出内容的判断力。所谓的“天才程序员”，并不完全是 AI 的能力，而应该是这样一个公式：AI 能力 × 程序员的能力系数 = “天才程序员”。也就是说，不能简单地认为，大街上随便拉一个毫无计算机专业背景的人，给他一个最顶级的 AI，就能做出一个企业级的软件项目。这让我想起一个段子：有人用 AI Vibe Coding 了一个网页，随后甩给别人一个 localhost 地址，让别人访问他的站点。虽然这只是一个段子，大家一笑而过，但我相信，这样的事情在现实中真实发生过。

我是从2022年开始接触网页端 ChatGPT ，当时确实被震撼到了。但使用一段时间后发现，想让它完成一个相对满意的结果，得来回和他拉扯很多次。再到DeepSeek问世，OpenAI 和 Anthropic 感受到了前所未有的压力，也逐步向用户开放了更多模型能力。以至于白嫖党都能体验到美国大厂开放的免费高阶模型，并且在响应速度上也比之前快了很多。但真正让我体验到 AI 的威力，是 Claude Code Agent 的发布。不仅如此，这对 IT 行业，也可以说是具有划时代意义的。通过自然语言与 AI 交互，就可以实现相对复杂的代码逻辑。这对程序员的冲击，不亚于让人产生一种即将原地失业的感觉。事实上，就当前这个时间节点而言，全行业的收缩已经让一部分人失业。再加上 AI 的冲击，更是雪上加霜。网上有人说：“2026年是程序员过的最后一个寒冬。”看似一句玩梗的话，却也真实反映了当下 IT 行业严峻的就业形势。

形势虽然严峻，但该走的路还得继续往前走。当下我们应该思考的，是如何利用好 AI，以及如何反思自己在使用 AI 过程中发现的问题。结合我使用 AI Agent 参与公司内部项目研发的实践经历，梳理一下自己踩过的一些坑：

第一点，AI 生成的代码，很难 Review。

比如，一个 Patch 修改了2000行代码，又生成了3000行代码。这种大块的变动，可以说在古法编程时代是难以想象的。这得出了多大的问题，才能下这么大的决心去重写？

第二点，AI 的实现容易缺失一些逻辑细节。

这类问题很大程度上来自需求描述不完整，也就是所谓的“许愿式编程”留下的坑。以为自己已经把需求说清楚了，但实际上，很多隐含条件和边界情况并没有明确告诉 AI。

第三点，AI 生成的大段代码，可能存在过度设计的问题。

如果真的逐行去 Review，就会发现有些逻辑写得十分啰嗦，甚至存在不必要的抽象和过度设计。

第四点，实现类似功能时，生成的代码结构可能不一致。

比如，封装多个功能相似的接口，按道理说，每个接口的实现结构都应该保持一致。而实际上，AI 可能会生成五花八门的代码结构，看起来自由得像个没有烦恼的孩子。

第五点，过分相信 AI 的设计和代码实现。

直到联调测试阶段，才发现各种各样的问题。更可怕的是，就像打地鼠一样，解决了一个问题，又冒出来一个新的问题。

第六点，对提交的代码，心里没有底。

因为代码基本没怎么看，只是简单测试了一下功能。更极端的情况是，有些连功能测试都是交给 AI 完成的。这样一来，研发人员面对自己做出来的产品，竟然变成了一个黑盒。但最终，还是需要研发人员对产品质量负责。

第七点，AI 并没有让大家的工作变得轻松，反而让大家背负了更大的交付压力。

比如，以前需要半年完成的需求，现在被压缩到一个月。即使有 AI 实现代码，也仍然需要人去完成方案设计，以及最终交付前的验收工作。

下面聊一聊我对ai agent编程的一些思考：

第一点，我不认为 AI 可以完全替代程序员的工作。

首先，需求的理解、对齐、边界定义等工作，仍然需要人来完成。AI 很难在一堆零散且不连续的上下文中，准确地整理出一份可以直接执行的方案。其次，即使 AI 能够帮你制定出一份完美的方案，也一定需要有人来拍板，决定是否推进，以及如何推进。

第二点，我非常认同 AI 可以接管一些对质量要求没那么高的业务实现。

首当其冲的，就是前端开发。比如一些静态页面，即使存在一些 Bug，对业务的影响也可能微乎其微。那么，这类工作交给 AI 去完成就非常合适。

第三点，要有模板化思维。

比如，一个大的需求中包含很多具有共性的逻辑。我们可以先实现上层共性逻辑的基座，然后在基座之上实现第一个具体功能。此时，就可以将这套实现过程沉淀为一个 Skill，约定好具体的实现规范。后续其他具有共性的功能，就可以在 Skill 的约束下，让 AI 按照模板批量生产。

第四点，我非常反对无脑地放手让 AI 写代码。

这很容易造成前面提到的那种大段重写代码的情况。针对这一点，我的看法是：在让 AI 动手之前，你自己必须对整体的实现脉络有清晰的认识。以小步快跑的节奏，将一个大的需求拆解成多个小块。每完成一个小块，就提交一个 Patch。多个连续的 Patch 组合起来，完成一个大的需求。这样既能让我们有机会对 AI 生成的代码进行 Review，也能更好地把控整体方向，避免实现过程逐渐偏离预期。

第五点，即使 AI 已经大行其道，也不要放弃对技术的积累。

当下我认为，反而应该更加主动地去了解自己以前没有接触过的技术和业务场景。可以预见的是，未来企业级软件的开发形态，必然是 AI 与人协同推进的模式。那么，人的价值就在于驱动 AI。这要求研发人员对业务和技术都具备足够深入的理解，才能高效地完成产品设计，并对最终的生产质量进行把控。这里我斗胆说一句：“AI 时代，所有研发都应该是架构师。”

写到这里，也算是把自己与 AI 打交道过程中的一些所见、所闻、所思记录了下来。当然，其中一些个人见解，可能过段时间再回过头来看，也会发现是错的。不过没关系，能够发现错误，又何尝不是一种成长呢？是啊，我们得成长起来，才能拥有面对不确定未来的解题能力。最后，引用徐涛老师说过的一段话，与大家共勉：“我们人生当中遇到的一切困难、矛盾和挫折，解决这所有问题的总钥匙，就是个人的进步。”