我们都身处在变革的巨浪中。在 2025 年，AI 和大模型已经是一个各行各业不能回避的问题。如何应对 AI 的发展和冲击？是谨慎试水、完全拥抱，还是弃之如敝履？我们经常看到很多利益相关者正在给出自己的回答，例如英伟达这类行业领导者宣称 AI 是未来的水电煤、下游的各种微信公众号则极力渲染 FOMO 的焦虑情绪，好像你不知道什么是 agent 就明天吃不上饭了，并乐此不疲的每天报道各种有意义的和没意义的新轮子。而你所在的公司的产品经理可能试图给一切平台、一切页面加上 AI chatbot。

对喜欢新鲜事物的人来说，这是一个不缺东西玩的时代。各种模型和应用的发布速度已经快到比雨后春笋还要快。在把玩新鲜事物之外，我们仍需要停下来思考新技术对我们自身和对人类的意义。

首先简单谈谈我对 LLM 的了解程度。我差不多是国内第一批 ChatGPT 的 early adopter，当时是微信群里有人在转发链接，说有个公司推出了一个特别牛逼的 chatbot，和之前的完全不一样，从那时候便开始断断续续使用。再后来，经历大国争端带来的困难并终于开通了 OpenAI API 和 ChatGPT Plus 后，使用的更是频繁。在 ChatGPT 2025 年的年度总结中，我一年给 ChatGPT 发送了一万多条消息，是 top 0.1% 的用户。在编程方面，我也是 codex、claude code 的早期用户，目前使用 cursor 和 codex 比较多。

我自认为自己对于 LLM 的能力边界是有充分的认知的。截止 2026 年 1 月 30 日，当前领先的思考模型（例如GPT 5.2 Codex High）已经可以在基本没有幻觉的情况下胜任大部分不过分复杂的上层应用的代码编写，虽然在没有人工纠正下给出的方案从简洁性和可维护性上可能并不是最优解。而 non thinking 的模型则仍然是一团糨糊，幻觉高得离谱，我完全不愿意在上面浪费一点时间。而国内的千问更是重量级，连给我点外卖都点不明白，这里必须拉出来点名批评一下。

LLM 的幻觉和终点

如果你使用 LLM 的次数足够多，你能发现它的无数“伪人”时刻。例如有时会突然蹦出来一个奇怪的字，或是出现不恰当的中英夹杂，亦或是使用很少被人们使用的表达方式。

LLM 的“幻觉”现象对不了解技术的人来说似乎挺难理解的。尤其是中国的特殊历史背景导致整个社会从上到下普遍具有技术乐观主义，以至于人们会过度信任自己正在对话的窗口，而选择性忽略底下那行“AI回复可能不准确”的小字。曾经有新闻报道有中年人驱车千里来到某个地方，只因为某个大模型约定要和他在这个城市相见。

作为一个年轻的、走在科技行业前沿的用户，我们或许会简单的觉得这是某些人“太不聪明”以至于相信了 AI 的幻觉。然而我总觉得这种指责太过轻松。我们所有人终有变老的一天，有认知退化的一天，这是生理规律。到那时，我们所了解的社会已经离我们相去甚远。我们是否还有足够的自信认为自己不会被 AI 骗到呢？毕竟几年前我们还会觉得声音和视频是不能伪造的，如果在微信上收到可疑消息就打个电话确认一下。而随着技术的快速发展，现在声音和视频已经不可靠了。各种曾经被认为坚不可摧的假设正在快速崩塌，“跟上变化”已经是让人感到有点疲惫的事情。我甚至怀疑在有生之年可以看到现代密码学的崩塌，到那时，不知道基于此的数字大厦将会如何崩裂。

LLM 的幻觉，归根结底是因为它本质上是一个序列预测机，其目标是生成出最可能有效的文字。而因为有效的文字需要看起来有逻辑，因此它便看起来有了逻辑。然而看起来拥有知识并不等于真实拥有知识，看起来拥有逻辑并不等于真实拥有逻辑。正如那个经典比喻，如果我们拥有无限多只配备了打字机的猴子，那么便总有一只猴子可以打出莎士比亚全集。我们并不能说这只猴子能理解莎士比亚，它只是碰巧看起来能理解。现在的（最前沿的）LLM，大抵就是那只能打出莎士比亚全集的猴子。它已经能看起来拥有难以想象的知识，并可以解决我们遇到的绝大多数问题，这非常令人兴奋，但仍然并不是真实拥有知识。

我认为 AI 的终态显然不会是现在的 transformer 架构。我们需要一个能真实理解我们的世界的机器，它真实的理解这个世界的物理规律，理解人类的文化，理解制造它的人的伟大理想。只有这样的技术，才能成为支撑社会上无数关键应用的基石。

不完美，但堪用

虽然当下的 LLM 还不足够完美，但对于当下的诸多需求已经非常堪用。

我是一个完全不懂 3D 打印的人。几个月前，因为一个特殊的需求没有现成零售的部件能满足我的需要，我便试图通过 3D 打印来自己制造部件。然而传统上 3D 建模是非常困难的，需要花费相当多时间学习软件的使用。但我想到，或许有类 XML 的语言能描述 3D 结构，那么我便将 3D 设计软件的使用问题转换为 LLM 擅长的生成代码问题。于是我还真找到了 OpenSCAD，然后让 GPT 5 thinking 帮我基于它的语法生成 3D 设计稿。

我对于 3D 设计此前是没有任何一点概念的，然而在一遍一遍的反复调整修改后，我竟然真的通过 GPT 拿到了我想要的 3D 图纸，最后使用朋友的打印机成功打印出来了成品并完美满足了我一开始的需求。这让我感到非常的惊喜和满足。我突然意识到，如果把设计稿换成程序代码，其实就是外行使用 Vibe Coding 的感受。

这次经历让我得出来一个具备通用性的结论：对于允许被反复调试来获得最终成品、即使做坏了也没有很大危害的东西，LLM + Vibe Coding 其实就已经可以满足需求。

而更有意思的一点是，我认为这个社会中的许多（甚至可能是大部分）未被实现的需求都属于这类东西。

在前 LLM 的时代，我见过太多“如果有一个......这样的东西就好了，怎么没有人做呢”时刻。其本质原因在于，一个非常垂直和细微的需求场景的潜在用户规模和商业化潜力并不足以吸引专业的程序员和产品经理前来解决用户的问题。

而在 LLM 的时代，一个普通用户完全可以通过 vibe coding 来实现自己的需求，而不再需要专业的程序员和产品经理来帮他解决问题。尽管过程中可能会闹非常多的笑话（例如在前端计算商品价格），但只要经历足够多的调试次数和踩坑，最终总是可以达到一个比较稳定使用的状态。从这个意义上说，LLM 对他们的意义是空前的。LLM 极大的赋能了具有动手解决问题的愿望的普通人。

因此我们或许可以说，在 AI 的时代，从大众的意义上说，发现和提出问题比解决问题更重要。要找到解决你的业务问题的独特角度，发现最短路径。至于实现步骤，可以让 AI 构建出来。想法很重要。独特的想法的重要性极大提升。

AI-assisted coding or fully vibe coding

上面说完了大众意义上的 LLM 带来的机遇，而在程序员的领域，则是另外一番景象。这其实是一枚硬币的两面，也是每一次所谓“科技平权”给被平权的行业带来的后果：用户越不依赖程序员，程序员的生存危机就越严重。程序员被迫需要回答的问题是，在 AI 可以写代码的时代，我的独特价值是什么。

我曾经合作过非常依赖 vibe coding 的前端。在我看来，他的工作似乎就是把我提给他的接口文档丢给 LLM，让 LLM 生成代码，然后需求就交付了。然而，或许是他用的模型太差劲了，联调阶段总是出现各种问题，更要命的是，有些更隐蔽的逻辑问题在联调阶段甚至无法发现，而是上线之后才发现的。而需求上线之后，修复错误数据的责任便转移到了服务端程序员身上，即便错误的触发方可能是前端程序员。而这些错误中，许多是属于“不可饶恕”的错误，可想而知我在每次修数据的时候有多生气。

我开始在心里有点嘀咕，他的独特性到底是什么？如果他只是将需求文档丢给 AI，那么似乎我也可以拿到前端的代码仓库然后开始 vibe coding，还省掉了一层中间商。得益于我在使用的更好的模型，可能 bug 还能少点，反正有 bug 也是我来修数据。

扪心自问的说，这样不带脑子的 vibe coding，我也干过。作为带有一定乐观精神的工程师，在业余项目中，我曾经尝试过完全不看 LLM 写了什么代码，纯通过自然语言沟通然后验收成果。这是一次对 LLM 能力边界的探索。我甚至尝试过一边让 AI 写代码，一边自己玩游戏，然后时常暂停游戏来与 AI 对话以继续让它写代码。通过这种“异步编程”来提升自己的时间复用性。

事实证明，在复杂度有限的需求中，这样是完全行得通的，因为它属于前文中我们提到的那种只要反复调试，总能跑通的功能。而一旦需求/项目的复杂度到达一定程度，不带脑子纯 vibe 就会引发巨大的灾难：

• 项目可能具有复杂的并发执行，或某两个模块之间的相互作用会引发意外的问题。LLM 的思考深度可能不足以发现它的代码会引发什么后果
• LLM写出的代码在大部分情况下可能工作正常，甚至通过了人工测试，直到某一次线上的边界 case 引发了bug
• 更要命的是，因为你过程中完全没看 LLM 写了什么，在发现问题的时候你已经完全看不懂 LLM 写了什么了，排查问题变得非常困难

因此我想引出一个重要的观点：

在非纯 vibe coding 的项目中，作为软件工程师，必须始终强调自己才是代码仓库的“主理人”，时刻保持自己对 codebase 的完全理解。你的存在价值是你作为软件工程师对于软件架构的理解，以及你的项目负责人身份在物理世界中的重要性。这意味着你需要像没有 AI 的时代一样，应对代码的可持续维护性的要求，并将各种技术和非技术的问题考虑妥当。而 AI 是你加速你的需求交付的工具。

这意味着你不能因为 AI 在“思考”就放弃了自己的思考，从而让大模型练就了你自身的思维惰性。你要仔细考虑 AI 提供的方案，并基于自己的判断，要求它修正它的方案，并且需要对 AI 生成的代码进行完整的进行 code review。而不是像阅读软件的用户协议一样快速跳过 AI 生成的方案简述和代码，然后期待它能为你解决所有问题。

没有任何 AI 做出的决策可以凌驾于你的想法之上。将代码仓库中的实现非常糟糕的责任推卸给 AI 是不客观的，也是对你的同事的不负责任。

当使用 AI 作为加速交付的工具的时候，我认为有如下事情是值得去做的：

• 通过对 AGENTS.md 进行调优，让 AI 的代码风格与自己/团队保持一致，降低自己的阅读成本，并符合项目/团队规范
• 给 AI 提供尽可能多的背景信息，让它对全局的理解程度尽可能贴近你。大量的背景信息是以非代码的形式存储在工程师的脑海的，包括领域知识、会议讨论、线下沟通、公司内部的知识积累、基础设施情况以及特殊的坑、项目的部署方式等等。

不过，上述的观点是基于项目/组织本身并不是纯 vibe coding 的前提。如果项目伊始就定好了这个项目就要纯 vibe，那么就放心的去 vibe 吧。我认为，满足以下条件的项目是可以纯 vibe 的：

• 项目允许被反复，甚至拿线上做测试来获得最终成品
• 项目即使运行异常也不会造成巨大的危害
• 总体复杂度或预计的代码行数不高
• 团队成员已经知晓并接受了这个项目是纯 vibe coding 的事实，并接受其带来的后果

不要让构建事物的乐趣，被 LLM 剥夺

在短短几年中，LLM 的应用正在以超级速度插入到我们的工作和生活中。有一些是好的，例如我所在的公司的内部代码发布流程中，会使用 LLM+MCP 来自动发现发布过程中的单实例问题并且自动将实例迁移完成。而另一些，只是为了赶潮流或者“找点事情做”。例如 AI IDE 部门推广 AI 写代码 + AI 写单测的模式，被内部以一种“虽然话糙理不糙，但这话也太糙了”的方式吐槽为“假阳具插飞机杯”，一时间惹得群内爆笑。

我发自内心地觉得，虽然 LLM 给我们提供了一个偷懒的选项，但并不意味着我们要在任何时候都依赖它。

和大多数程序员不一样，我是一个从小学开始就写代码的人。我的成长环境给了我很早拥有电脑的权利，我利用这个权利在很早的时候发现了在数字世界中构建事物的乐趣。我在中学时代就建立了自己的个人博客（https://an.admirable.pro），并且这个博客直到今天还在更新。这种乐趣是我持续以兴趣爱好的方式构建事物的动力，也是我选择软件工程师这个职业的原因。在构建事物的过程中，我可以获得一种心流状态，这让我感到非常满足。

在这两年的 AI 辅助编程的经历来看，对于复杂问题，AI 交付的其实不会比我自己动脑交付的更好（虽然的确是更快）。并且，我经常在 vibe coding 的过程中感到空虚。我感觉到自己只是在尽快完成一件事情，而不再能感受到构建事物所伴随的那种心流状态。而当我沉下心来写代码的时候，我感到那种熟悉的感觉又回来了。所以我认为，也许并不是所有的“技术进步”都应当被最大化地利用其价值。