AI 是坏的吗？

AI 到底是不是个坏东西？

这问题现在满天飞。论坛、社区、群聊、周会、产品 demo、投资人 pitch——谁都能发表一通看法。

有一派人恨不得什么都往 AI 上靠。写代码用 AI，写作用 AI，总结用 AI，做计划用 AI，连思考都想让 AI 代劳。只要世上存在一种工作流，就有人想在前面塞一个 AI 助手。

另一派人躲得远远的。观望的、怀疑的、觉得 AI 让人变懒的、觉得 AI 会让你因为不碰基础而变蠢的——而且他们也不全错。

我自己是 AI 的坚定用户。我觉得 AI 有用、强大，而且已经强到足以改变工程师的工作方式。但它会让我变蠢吗？

看情况。

这答案听着像和稀泥，但我认为这是唯一诚实的回答。大多数技术都不是非黑即白。答案取决于你看重什么、愿意承担什么风险、拿到了什么好处，以及——有哪些知识你因为工具能代劳而选择不再深入。

AI 并没有取消权衡

关于 AI 的讨论，最偷懒的论证是：

AI 让我能做更多事。
所以 AI 是好的。

最偷懒的反驳是：

AI 替我干活。
所以 AI 让我退化。

两边都太简单了。

真正的问题更接近这样：

我把什么外包出去了？
我得到了什么？
我失去了什么？
这种失去，对我的人生或工作而言，真的要紧吗？

比如我用 AI 写一个一次性的 shell 命令，大概也就是少练了几个平时不常用的 flag。但如果我用 AI 设计 authentication 或支付逻辑，而我自己搞不懂安全模型——那就是完全不同的风险了。

AI 不会因为"降低了摩擦"就自动变成坏事。洗碗机降低了摩擦，计算器降低了摩擦，高级编程语言也降低了摩擦。真正的问题出在：你把那些必须自己理解才能做出好判断的东西，外包出去了。

聊到这里，讨论才开始有价值。

我的草坪不需要我成为草坪科学家

作为工程师、作为 AI 的早期用户，我一直反复问自己一个问题：

AI 到底能帮我把现实生活中的什么事情做得更好？

不是 demo，不是玩具，不是那种"看，AI 也能做这个诶"的炫技。我说的是那种无聊但真正实用的改善。

我自己搭了 N8N 服务器，家里有 Rain Bird 智能灌溉系统。在把 AI 引入这个工作流之前，我就已经有自动化了——调天气 API，拉当天预报，然后用硬编码的逻辑决定要不要浇水。

大概长这样：

天气 API
  -> 降雨概率
  -> 预计降水量
  -> 温度
  -> 硬编码 if/else 规则
  -> 启动或跳过喷灌计划

能用，也够 deterministic，但判断太粗糙。

佛罗里达的天气不是几个简单规则就能搞定的。湿度、降水量、日照、最近下过雨没有、土壤干湿程度、季节、草坪健康状况——这些变量互相影响。我可以为其中一些写规则，但每加一个变量，就多一个要手动调的阈值，永远调不完。

所以我换了个思路：

天气 API
  -> 当前湿度
  -> 降水预报
  -> 近期降雨
  -> 日照
  -> AI 角色：佛州专业草坪养护员
  -> 建议
  -> 确定性的安全限制
  -> Rain Bird API

重点不是"AI 控制了我的喷头"。重点是：在硬编码逻辑太僵硬的地方，AI 给我提供了一个能真正"判断"的层。

我可以问它：

今天该不该浇水？

如果该，浇多久？

理由是什么？

但因为工程素养告诉我不能裸奔，我在外面套了一层护栏：

• 正在下雨的时候绝不浇水。
• 限制单次最大浇水时长。
• 记录 AI 给出的理由。
• 支持手动覆盖。
• 天气 API 或 AI 响应挂掉时，默认不执行。

AI 的价值就在这里。它把一堆天气信号变成了一个靠谱的决策，而我不用花几个小时去学草坪养护的专业知识。

AI 让这件事变好了吗？

我觉得是的。灌溉计划更精准了，时间省了，对数据点的理解也够用了，结果确实更好。

那它让我变蠢了吗？

也可以说，在某个很窄的意义上——是的。我仍然没有深刻理解湿度、降水、日照、土壤行为和草坪健康之间的全部关联。如果 AI 给了一个自信但错误的答案，而我一直盲信下去，那是我自己的问题。

但我真的在乎到要在这个领域深耕吗？

说实话，不太在乎。

我在乎的是草坪健康、不浪费水、周末不用花时间去调阈值。我不需要成为那个能给人开讲座的佛州草坪科学专家。

这就是那笔交易。

真正的问题是：哪些知识对你重要

很多人喜欢把"用 AI"和"自己学"对立起来。

其实它们不矛盾。

你可以用 AI 研究一个话题，也可以用 Google，可以读书，可以问领域专家，可以自己动手试。这些都是通往同一个目标的不同路径：拿到更好的信息，做出更好的决策。

问题不是"用 AI"在道德上比"手动搜索"更高尚还是更低级。问题是：这些知识，值不值得你自己拥有。

对我来说，知识分三档。

草坪灌溉对我来说属于第三档。

软件架构不是。

如果 AI 帮我写了代码，而我讲不清楚设计、failure mode、数据流、安全影响——那不叫生产力，那叫向机器借自信。

但如果 AI 帮我搭 N8N workflow、画 Rain Bird API 集成的草图、生成自动化初稿，而我在 review 和测试的过程中搞懂了每个环节——这就是工具的正确用法。

这个区别很重要。

AI 应该让浅层的活变便宜，而不应该让重要的思考变得不可见。

是的，AI 会冲击就业

AI 会让人丢饭碗。

真的。

我不想拿"新的工作机会会出现"这种话来轻描淡写——好像这么说就能缓解那些正在经历岗位缩减或被替代的人的痛苦。新机会出现需要时间，而眼下的人正在承受冲击。

AI 可以减少某些任务需要的人数。它可以让一个人干出一个团队的活。它可以在新的职业路径成形之前，先把入门级岗位砍掉。它可以让公司用更少的人要更多的产出。对开发者、工程师、设计师、写作者、客服、分析师，以及大量知识工作者来说，这种压力已经是现实了。

从宏观视角看，我理解为什么有人把 AI 形容得像病毒、像又一场砸向社会的疫情。如果 AI 爆发之前就已经在裁员、劳动力就已经过剩，那 AI 只会把这种失衡推得更猛。

乐观的说法是：社会最终会创造新的工作，人们会以不同的方式继续贡献。

也许吧。

但"也许以后会好"付不起这个月的房租。

这里有个很多人没意识到的错位：个人策略和社会影响，根本不是同一个问题。

社会层面，AI 确实会伤害到人。

个人层面，拒绝学这个工具也不会让工具消失。

这话不好听，但确实是事实。

我不怕 AI 取代我

经常有人问我：你怕不怕 AI 取代开发者？

说实话，不太怕。

不是因为我觉得开发者铁饭碗——我们当然不是。我认为软件开发是当下受冲击最猛的职业之一，因为我们的工作文本密集、工具密集，而且本来就围着机器转。

我不怕，是因为我把 AI 看作一次工具演进。

高级语言开始好用的时候，assembly 程序员也有理由慌。一些工作变了，一些技能不那么吃香了，有些人可能恨透了新的 abstraction——因为它把他们在意的细节藏起来了。

但如果我生在那个年代，我肯定去学 C。

不是因为 C 比 assembly 道德上更高尚。

而是因为它让我用更少的摩擦造出更多的东西。

AI 给我的感觉很像。它不完美，不是魔法。它会给出烂答案，会过度迎合，会误解上下文，会写出看着漂亮但边界情况就崩的代码。

它犯错的时候我照样会骂。工具烂的时候我照样说烂。但光骂技术本身不会让我活干得更好。

学会用它才会。

对工程师来说，真正值钱的能力不是"写 prompt"，而是知道 AI 应该出现在系统的哪个位置。

用 AI 做探索。

用 AI 打草稿。

用 AI 干那些无聊的胶水活。

用 AI 比较不同方案。

用 AI 生成测试——然后你自己检查。

用 AI 找盲点。

但该 deterministic 的地方，保留 deterministic code。失败代价高的地方，保留 review。架构的所有权自己握着。上线的东西你得能讲清楚。

这不是反 AI。这才是认真地用 AI。

AI 会让你变蠢，如果你放任的话

这里怀疑派是对的。

如果你在需要理解的地方用 AI 替代了理解，它会让你变蠢。

它会让你接受那些"听起来挺对"的解释。

它会让你跳过基础。

它会让你不再看源码。

它会让你不再查文档。

它会让你觉得自己很高效，而判断力在悄悄退化。

这是真实的危险。

但反过来说也成立。如果你把 AI 当成互动老师，它能让你学得更快。它能让你接触到你根本不会主动去搜的想法。它能把一个模糊的话题变成一张知识地图。它能给你正例、反例、练习题。它能帮你发现自己理解错的地方。

工具不会替你选走哪条路。

你的使用方式才会。

让 AI 干活，然后自己从不看——你在把大脑外包出去。

让 AI 解释、挑战、比较、测试，帮你构建一个你仍然拥有的东西——你在延伸自己的能力边界。

这就是我在意的那条线。

所以 AI 到底是好是坏？

我的答案还是那三个字：看情况。

AI 帮你拿到更好的结果、省下真正有意义的时间、减少无聊工作、让你接触到原本成本太高的知识——它是好的。

AI 隐藏风险、消解责任、在理解重要的地方替代了理解、或者让经济权力集中到伤害普通人的地步——它是坏的。

对我的浇灌系统，我很乐意让 AI 搭把手。我不需要成为草坪科学专家。

对我的工程工作，我希望 AI 无处不在，但不能让它控制一切。离我足够近来加速我，但也足够有批判性来挑战我——重要的东西外面要有测试、review 和 deterministic 的边界。

我现在的立场：

积极用 AI。
有选择地信它。
在失败代价高的地方验证它。
决策权留给自己。

所以 AI 到底是好是坏？

你猜。

评论区见，来吵一架。