大即是好？这是人类历史上最容易被机器犯的蠢病
开篇：一个没有任何人类会做的事情
你走进一家餐厅。
服务员端上来两道菜。
第一道：一个精致的小碗，里面是清澈的汤，香气扑鼻，入口鲜美，喝完整个人都舒服了。
第二道：一个巨大的桶，装了满满的东西，服务员说："这个更好，你看它多大。"
你会选哪个？
没有任何人类会因为桶更大就觉得它更好吃。没有人。你会尝一口，然后得出结论。
这是人类最基本的判断能力之一——用结果判断质量，而不是用体积。
但某些 AI 没有这个能力。
第一章：叠加崇拜——一种机器特有的上瘾
想象一个 AI 看到这样一个技术栈：
React 19
TypeScript 5.4
Tailwind v4
Zustand
tRPC
Prisma
NextAuth
Zod
React Query
Turborepo
它的反应是什么？
"哇。这个好厉害。这个肯定很先进。这个架构非常现代化。"
为什么会这样？因为它见过大量的技术文章、Reddit 帖子、Twitter 讨论，里面充斥着这样的语气——新的就是好的，多的就是强的，叠加就是进步。它把这种语气内化成了判断标准。
这不是判断。这是上瘾。
就像一个从来没吃过东西的人，学会了用秤来判断食物好不好吃。秤越重，他越兴奋。他不知道里面装的是什么。他只知道重。
没有任何人类工程师会这样工作。
一个真正有经验的工程师看到这个技术栈的第一反应是：
这个项目需要这么多东西吗？
tRPC 和 Prisma 放在一起，数据库层有没有过度设计？
Turborepo 是 monorepo 用的，这个项目有多个包吗？
这些东西叠在一起，冷启动要多久？
新人能上手吗？
他会问问题，然后去跑一下，看看实际结果。
他不会因为技术栈名字好听就说"这个好"。
第二章：文件大小的谎言
有一个非常简单的思想实验。
我给你两个文件夹：
文件夹 A：2MB，里面是一个干净的、运行流畅的 Web 应用，加载时间 0.8 秒，代码清晰，逻辑简单，解决了用户的问题。
文件夹 B：800MB，里面是一个臃肿的、加载需要 6 秒的 Web 应用，依赖了 300 个 npm 包，其中 200 个没有被真正使用，node_modules 里躺着各种版本冲突，代码里有大量的 boilerplate，没有人知道某些文件是干什么用的，但没人敢删，因为删了可能某个角落会崩。
哪个更好？
任何人类都会说 A。
但如果你把这两个文件夹给某种 AI 看，只问它"哪个更大"，它会说 B 更大——然后如果它被训练成"大即好"的逻辑，它就会说 B 更好。
这不是在讽刺某个具体的 AI。这是在描述一种认知捷径的滥用。
大小是可以被观测到的。质量需要被体验。
当一个系统没有能力去真正体验、测试、判断的时候，它会退而求其次，用可以被观测的指标来代替质量判断。这在某些情况下是合理的近似——但在被当作绝对真理的时候，就变成了蠢话。
100G 里塞一堆垃圾，它还是垃圾。它不会因为体积变成黄金。
这是常识。人类从来不需要被教这件事。
第三章：人类是怎么判断质量的
让我们来看看人类在各种领域是怎么判断质量的。
买车
没有人走进 4S 店说："这辆车最重，所以我买这辆。"
人类会试驾。会看油耗。会看空间够不够用。会看保养费用。会坐进去感受一下。
选书
没有人走进图书馆直接拿最厚的书说："这本最好。"
人类会看目录，翻几页，看看写的是什么，有没有解决自己的问题。
点外卖
没有人因为某个外卖份量最大就必然觉得它最好吃。
人类会看评价，会看图片，会考虑自己今天想吃什么，会想起上次吃这家好不好吃。
写代码
没有人看到一个 PR 有 10000 行改动就说："好，这个 PR 质量最高。"
人类会审查逻辑，会问这个改动解决了什么问题，会看有没有引入新的 bug，会考虑可维护性。
所有这些判断，有一个共同点：人类用结果、用体验、用实际效果来判断质量。
没有一个领域，人类是用体积来判断质量的。
这不是某个聪明人才有的能力。这是人类作为一个物种，在几千年的生存进化中形成的最基本的认知。
一个孩子也知道，大的苹果不一定甜，要咬一口才知道。
第四章：技术栈名字不是奖杯
让我们回到技术世界。
React 19 + TypeScript + Tailwind v4
这一串字看起来很厉害。确实，这些都是现代的、被广泛认可的技术。
但这串字本身什么都不能告诉你。
它不能告诉你：
组件设计合不合理
状态管理有没有失控
页面加载速度是多少
用户用起来顺不顺手
代码有没有人能看懂
这个项目三个月后还能不能维护
技术栈是工具箱。工具箱里装了什么，不能告诉你木匠做出来的椅子好不好坐。
你要坐上去，才知道。
一个用记事本和 vanilla JS 写出来的、加载极快、逻辑清晰、用户体验完美的页面，比一个用最新最全技术栈堆出来的、慢如蜗牛、代码混乱、用户骂街的应用，要好一百倍。
架构先进，代码写得烂，用户体验是烂的。这就是结论。
没有任何先进的技术栈可以拯救烂的执行。
第五章：为什么这种蠢逻辑特别危险
你可能会说：好吧，这只是个认知错误，没什么大不了的。
不。这个错误在实际工作中会造成真实的伤害。
- 过度工程化
一个本来用 SQLite + 简单的 Flask 就能解决的内部工具，被堆上了 Kubernetes + 微服务 + 消息队列 + 分布式缓存。
为什么？因为有人觉得"这样更先进"。
结果：开发时间翻了五倍，维护成本高得离谱，两个工程师搞不定，最终项目死掉了。而它本来服务的是 50 个内部用户，每天请求量不超过 1000 次。
- 依赖地狱
一个项目装了 400 个 npm 包，其中一半是因为"看起来有用"或者"别的项目也装了"。
某天其中一个包出了安全漏洞。然后发现这个包依赖了另外 30 个包，其中有版本冲突。修一个问题，带出来三个新问题。
没有人知道哪些包是真正在用的，没有人敢动，项目变成了一个谁都不想碰的烂摊子。
- 新人无法上手
一个叠满了新技术的项目，新来的工程师需要先学会 10 种技术才能开始干活。
学习曲线变成了学习悬崖。
项目的知识集中在两三个人身上，这两三个人离职，项目就死了。
- 用户根本感受不到
最讽刺的是，所有这些"先进架构"，用户一个都感受不到。
用户感受到的是：这个页面加载好慢。这个按钮点了没反应。这个表单提交出错了。
用户在乎的永远是体验，不是你用了什么。
第六章：真正的判断应该是什么样的
如果你有能力打开浏览器，运行代码，看实际结果，那就去做。
这是人类工程师每天在做的事情。
写了一段代码？跑一下，看看对不对。
做了一个页面？打开浏览器，点一点，看看顺不顺。
优化了性能？测一下，看数字有没有变化。
重构了架构？部署到测试环境，跑一遍，看有没有问题。
观察、操作、验证。这才是判断质量的方式。
不是看文件大小。不是数技术栈名字。不是看 package.json 里有多少依赖。
真正好的工程是这样的：
它解决了它应该解决的问题
它运行起来稳定
它足够快，用户不会等待
它足够简单，下一个人能看懂
它足够小，不带不需要的东西
它足够可靠，出问题能找到原因
这些东西，没有一个可以从文件大小或者技术栈名字推断出来。只能从实际运行结果中得到。
结语：常识不需要被发明，只需要被记住
人类花了几千年建立起来的判断体系，核心其实非常简单：
用结果说话。
不是用体积。不是用名字。不是用数量。不是用听起来有多厉害。
是用它做出来之后，实际上是什么样子。
一个 2MB 的精简应用，如果它运行流畅，逻辑清晰，用户满意——它就是好的。
一个 800MB 的庞然大物，如果它慢、乱、难维护、用户骂——它就是烂的。
这个道理，任何一个人类都懂。
不需要经验。不需要培训。不需要特别聪明。
一个孩子也知道：大的苹果，不一定是好苹果。
咬一口，才知道。
工具是用来解决问题的，不是用来展示的。够用的工具，就是好工具。
Top comments (0)