AI 是坏的吗？

AI 是坏的吗？

这个问题现在到处都是。论坛、讨论区、群聊、会议、产品演示、投资人幻灯片，每个人都有立场。

有些人强烈建议所有事情都用 AI。写代码用 AI，写作用 AI，总结用 AI，计划用 AI，思考也用 AI。只要存在一个工作流，就会有人想在前面放一个 AI 助手。

另一些人会躲开它。采用比较慢的人、怀疑者、认为 AI 会让人变懒的人、认为 AI 会让你因为不再理解基础而变笨的人。他们也不总是错。

我算是支持 AI 的人。我认为 AI 有用、强大，而且已经足够改变工程师的工作方式。但它会让我变笨吗？

看情况。

这个答案听起来无聊，但我认为它是唯一诚实答案。大多数技术不是 100% 好或 100% 坏。答案取决于你重视什么、接受什么风险、获得什么收益，以及你因为工具能替你承担某部分而选择不再深入学习哪些知识。

AI 没有取消权衡

AI 争论的懒惰版本是：

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

懒惰的反方是：

AI 替我完成工作。
所以 AI 会让我退化。

两边都太简单。

真正的问题更接近：

我把什么外包出去了？
我获得了什么？
我失去了什么？
这种损失对我生活或工作中的这个具体部分重要吗？

如果我用 AI 写一次性的 shell 命令，也许只是少练了一点很少用到的参数。如果我用 AI 设计身份认证或支付逻辑，而自己不理解安全模型，那就是完全不同的风险。

AI 不是因为降低摩擦就自动变坏。洗碗机降低摩擦。计算器降低摩擦。高级编程语言降低摩擦。问题从你外包了那些你必须理解、才能做出好决策的东西开始。

这时讨论才变得有用。

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

作为工程师和早期 AI 采用者，我经常问同一个问题：

AI 能帮我把现实生活中的什么东西变得更好吗？

不是演示，不是玩具，不是那种“看，AI 也能做这个”的把戏。我说的是无聊但实用的改善。

我有一台自托管 N8N 服务器，也有带 Wi-Fi 模块的 Rain Bird 灌溉系统。在把 AI 放进这个工作流前，我已经有自动化。它会调用天气 API，拉今天预报，然后用硬编码逻辑决定要不要浇草坪。

大概这样：

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

它能工作，也足够确定，但判断很粗。

佛州天气不总是适合简单规则。湿度、降水量、日照、近期降雨、土壤干燥程度、季节、草坪健康都会相互作用。我可以给其中一些写规则，但每加一个变量，就要手动调一个阈值。

所以我试了另一个形状：

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

重点不是“AI 控制我的喷头”。重点是 AI 在硬编码逻辑太僵硬的地方，提供一个判断层。

我可以问：

今天该不该浇水？

如果该，浇多久？

原因是什么？

因为这仍然是工程工作流，我会在外面放护栏：

• 下雨时绝不浇水。
• 限制最大浇水时长。
• 记录 AI 的理由。
• 允许手动覆盖。
• 天气 API 或 AI 响应缺失时，默认不执行浇水。

这就是 AI 有帮助的地方。它把一堆天气信号变成实际决策，而我不需要花很多小时成为草坪养护专家。

AI 让这件事更好吗？

我认为是的。它让我灌溉计划更准确，省时间，也让我理解足够多数据点，拿到更好结果。

它让我更笨了吗？

也可以说是，在一个很窄的意义上。我仍然没有深刻理解湿度、降水量、日照、土壤状态、草坪健康之间的所有关系。如果 AI 自信但错误，而我一直盲信它，那是我的问题。

但我在乎到要掌握那个领域吗？

没有。

我在乎草坪健康，不浪费水，不把周末花在调阈值上。我不需要成为那个能给所有人讲佛州草坪科学的人。

这就是权衡。

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

人们经常把 AI 描述得像学习和委托是敌人。

它们不是。

你可以用 AI 研究一个主题。你可以用 Google，可以读书，可以问领域专家，可以自己测试。这些都是通往同一个目标的不同路径：获得更好信息和更好结果。

问题不是使用 AI 是否在道德上比手动搜索互联网更好或更坏。问题是这个知识是否重要到你需要拥有它。

对我来说，有三个桶。

草坪灌溉对我属于第三类。

软件架构不是。

如果 AI 替我写代码，而我解释不了设计、失败模式、数据流、安全影响，那不是生产力。那是向机器借自信。

但如果 AI 帮我创建 N8N 工作流，画 Rain Bird API 集成草图，生成自动化初稿，并在我审查和测试时解释组成部分，那就是好用法。

这个区别很重要。

AI 应该让浅层任务变便宜。它不应该让重要思考变得不可见。

是的，AI 会伤害工作

不是吗？AI 可能会让人丢工作。

是真的。

我不想用”新工作会出现”来轻描淡写，好像这能解决那些正在经历岗位缩减或被替代的人的痛苦。

AI 可以减少某些任务需要的人数。它可以让一个人产出过去一个团队的东西。它可以在新职业路径完全成形前移除入门级工作。它可以让公司期待更少的人产出更多。对开发者、工程师、设计师、写作者、客服、分析师以及许多知识工作者来说，这种压力已经是真的。

从人类层面视角看，我理解为什么有人把它描述得像病毒或另一场大流行砸向社会。如果 AI 爆发前就已经有裁员、劳动力过剩，那么 AI 会把这种失衡推得更狠。

乐观版本是社会会创造新工作，人们会以不同方式贡献。

也许。

但 “也许最终” 不能支付这个月房租。

我觉得两边经常在这里错位。个人策略和社会影响不是同一个问题。

在社会层面，AI 绝对会伤害人。

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

这很不舒服，但是真的。

我不害怕 AI 替代我

人们问我是否害怕 AI 替代开发者。

我不太怕。

不是因为我觉得开发者不可触碰。不是。软件开发现在是受冲击最大的职业之一，因为我们的工作文本密集、工具密集，而且本来就围绕机器组织。

我不怕，是因为我把 AI 看作工具转变。

高级语言变得实用时，汇编程序员有理由担心。一些工作改变，一些技能变少见，一些人可能讨厌新抽象，因为它隐藏了他们在意的细节。

但如果我是那个时代的汇编开发者，我会去学 C。

不是因为 C 在道德上比汇编更好。

而是因为它让我用更少摩擦构建更多东西。

AI 对我来说类似。它不完美，不是魔法。它会产生坏答案，会太顺从，会误解上下文，会写出看起来干净但边界失败的代码。

它做错时我仍然会抱怨。工具烂时我仍然会说工具烂。但责怪技术本身不会让我工作做得更好。

学会使用它会。

对工程师来说，有用技能不是孤立的 “提示词写作”。而是知道 AI 应该放在系统哪里。

用 AI 探索。

用 AI 草稿。

用 AI 做无聊胶水。

用 AI 比较方案。

用 AI 创建测试，然后你检查。

用 AI 找盲点。

但在确定性重要的地方保留确定性代码。失败代价高的地方，保留审查。保留架构所有权。保留解释交付物如何运作的能力。

这不是反对 AI，而是认真使用 AI。

AI 会让你变笨，如果你允许

这里怀疑者是对的。

如果你在需要理解的地方，把 AI 当作理解的替代品，它会让你变笨。

它会让你接受听起来正确的解释。

它会让你跳过基础。

它会让你不再读源代码。

它会让你不再查文档。

它会让你感觉高效，而实际判断力在变弱。

这是真风险。

反过来也是真的。如果你把 AI 当互动老师，它可以让你学得更快。它可以让你接触到本来不会搜索的想法。它可以把模糊主题变成地图。它可以给示例、反例、练习问题。它可以帮你调试自己的误解。

工具不会决定你走哪条路。

你的使用模式会。

如果你让 AI 做工作，然后从不检查，你是在把大脑外包出去。

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

这就是我在意的线。

所以 AI 是好是坏？

我的答案仍然是：看情况。

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

AI 隐藏风险、移除问责、在理解重要的地方替代理解，或者把经济权力集中到伤害人的程度时，它是坏的。

对我的灌溉系统，我很乐意让 AI 帮忙。我不需要掌握草坪科学每个细节。

对我的工程工作，我想让 AI 到处存在，但不控制一切。我希望它足够近，能加速我，也足够批判性，能挑战我；重要事项外面要有测试、审查、确定性边界。

这是我当前立场：

积极使用 AI。
有选择地信任它。
在失败代价高的地方验证它。
自己承担决策。

所以我认为 AI 是好是坏？

你猜。

然后留个评论，我们来吵。